今回の記事では、企業のシステム管理者であれば最低限知っておいてほしいITにおける「セキュリティ対策」に関する知識を初心者向けに幅広く紹介していきます。
システム管理者が知っておくべきセキュリティ対策とは
ITの世界における「セキュリティ対策」という言葉は非常に広義であり、何を対象にしたセキュリティ対策かによって求められる知識や技術レベルも異なります。
ITにおけるセキュリティ対策において一般的な対象としては以下になります。
- アプリケーションの設計や実装におけるセキュリティ対策
- ネットワーク設計におけるセキュリティ対策
- OSやミドルウェアの脆弱性におけるセキュリティ対策
- 内部不正防止におけるセキュリティ対策
同じ「セキュリティ」でも、上記の内容は、個々に必要とされる技術分野も異なり、これらの全ての知識を深く理解することは大変ですが、セキュリティはすべての分野に対して満遍なく適用する必要があり、特定の分野の知識不足で脆弱性が残ったままであれば意味を成しません。
よって、各分野を広く理解することはシステム管理者にとっては非常に重要です。
個々の分野に関するセキュリティ上のリスクを理解し、必要な対策や気を付けるべきポイントをしっかり押さえておくことが必要です。
次項では上記の個々の分野に対するセキュリティについて解説していきます。
アプリケーションの設計や実装におけるセキュリティ対策
システム管理者にとって、自社で使用する様々な業務システムや自社がインターネット上で公開するウェブサービスやウェブアプリケーションに関して、セキュリティにおけるどのようなリスクが存在するかを理解し、適切に対策を施していくことは非常に重要です。
この分野に対するセキュリティが脆弱な場合、自社のシステムやウェブサービスに対して部外者からのログインを許してしまったり、データベースへの認証情報を奪取されたり、データベース内に格納されている機密データを持ち出される恐れがあります。
当項では、アプリケーションの設計や実装においてシステム管理者が知っておくべき攻撃やリスク、また、それに対する対策を紹介していきます。
SQLインジェクションとは
特にウェブアプリケーションにおいて非常にメジャーな攻撃手法の一つです。
システム管理者であれば必ず仕組みを理解しておきましょう。
まずは、Wikipediaの記事を引用します。
SQLインジェクション（英: SQL Injection）とは、アプリケーションのセキュリティ上の不備を意図的に利用し、アプリケーションが想定しないSQL文を実行させることにより、データベースシステムを不正に操作する攻撃方法のこと。また、その攻撃を可能とする脆弱性のことである。
SQLインジェクション -Wikipedia
アプリケーションの入力フォームのテキストボックスに対して、設計者の意図しないSQL文字列の一部を文字通り「注入＝Inject」することで、そのアプリケーションに対して誤動作をさせる攻撃手法です。
上記のWikipediaの記事でも実際の攻撃例が紹介されていますが、当記事でも簡単に紹介しておきます。
例えばウェブアプリケーションのログイン画面では、ユーザーIDとパスワードを入力させて、そのユーザーIDがユーザーマスタのユーザーとして存在し、そのユーザーとして登録されているパスワードと一致した場合にログインを許可するといった実装がされているとします。
そのような画面では、データベース内のユーザーマスタに対してSELECT文を発行し、そのSQLのWHEREでユーザーIDとパスワードを条件にしてユーザーマスタを参照します。
でたらめなユーザーIDやパスワードを入力してログインを試みた場合、そのユーザーIDとパスワードをWHERE条件で付与されたSELECT文を実行しても対象のレコードは取れないため、そのログイン処理は失敗します。
上記の図で言えば、Loginボタンを押下すると、テーブルUsersに対して、入力されたUserIDとPasswordの文字列を元にプログラム内部でSQLを生成します。
このSQLが設計者の意図通りに実行された場合は、実在するUserIDとPasswordの組み合わせが正しくないとレコードが取れず、ログインに失敗するはずです。
ただ、SQLインジェクションへの対策がされていないフォームでは以下のように入力することで、設計者の意図と異なる動きになります。
Password：1' OR '1' = '1
このように入力された場合、プログラム内部で生成されるSQL文は以下のようになります。
SELECT UserID
FROM Users
WHERE UserID = 'でたらめな値'
AND Password = '1' OR '1' = '1'
このSQLでは、WHERE句内の末尾の OR 1 = 1 が付けたされたことで、Trueが返り、UserIDやPasswordに何が入力されようが、テーブルUsersの全行を返してしまいます。
仮にこのログインフォームのログイン可否の判定条件が「条件に合う行が取れること」になっていた場合、行が取得出来てしまっていることから、このままログインに成功してしまう可能性があります。
SQL文が実行できるという事は、SELECT文以外の構文も実行できるということです。
脆弱性のある入力フォームから、UPDATE文でデータを更新したり、ストアドプロシージャをCREATEして実行したり、デーブルをドロップするなど、あらゆる処理が行えてしまう可能性があります。
SQLインジェクションへの対策
ウェブアプリケーションのセキュリティ対策として、IPA(情報処理推進機構)が積極的に情報を発信しています。
当項で解説した「SQLインジェクション」についても以下のリンク先で有効な対策を紹介しています。
IPAが紹介している対策も幾つか抜粋して簡単に紹介していきます。
動的なSQL文の生成はプレースホルダを使用する
動的なSQL文を生成する場合に、パラメーターを文字列で連結するのではなく「プレースホルダ」を使用することが重要です。
プレースホルダでは、いったん暫定的なSQL文をプログラム内で生成し、あとからパラメーターを「値」として差し込みます(バインド)。
プレースホルダで差し込んだパラメーターは値としてしか扱われないため、意図しないSQLが生成されてしまうことを防ぎます。
SQLインジェクションの回避において、プレースホルダは非常に有効です。
入力値のエスケープ処理をしてからSQLを生成する
実装時のプログラム言語の制約で、前項のプレースホルダが利用できない場合は、入力値のエスケープ処理を実装することで、SQLインジェクションを防ぎます。
「エスケープ処理」とは、フォームで入力された値で、SQLやプログラミング言語上の特殊な文字として扱われる値を別の文字に置き換えて無効化する処理を言います。
例えば、「;」や「’」、「¥」などの文字が入力されていたら、それを別の文字に置き換えてサーバー側を送るといった処理です。
エスケープ処理を実装しておくことも、SQLインジェクションを防ぐためには非常に有効です。
※エスケープ処理は後述する「クロスサイトスクリプティング」でも有効な対策であり、詳しくはクロスサイトスクリプティングの対策内で解説します。
データベース内のアカウントに適切なロールを設定
一般的なRDBMSでは、そのデータベースに接続して操作をするためのユーザーを作成し、そのユーザーごとにどこまでの操作を許すかの権限設定を行います。
この様な権限グループを「ロール」と呼びます。
万が一SQLインジェクションが成功してしまうような脆弱な実装でも、そのアプリケーションで使用しているデータベースのユーザーが特定のテーブルのSELECTのみしか権限を有していないなら、データを更新したり、テーブルをDROPするような攻撃は行えません。
SELECTできるテーブルも限定されており、被害を最小限に抑えることができます。
データベースのユーザーに適切なロールを適用して管理することは、万が一攻撃が成功してしまった場合において、非常に有効な対策になります。
クロスサイトスクリプティング(XSS)とは
ウェブアプリケーションにとって、前項で紹介したSQLインジェクションと同様に、非常にメジャーな攻撃手法です。
「クロスサイトスクリプティング」は名前の通り、ウェブサイトを横断して悪意のあるスクリプトを実行させる攻撃手法です。
こちらも例によってWikipediaの記事を引用してみます。
クロスサイトスクリプティング（英: cross site scripting）とは、Webアプリケーションの脆弱性もしくはそれを利用した攻撃。
〜中略〜
攻撃者の作成したスクリプトを脆弱性のある標的サイトのドメインの権限において閲覧者のブラウザで実行させる攻撃一般を指す。
クロスサイトスクリプティング -Wikipedia
クロスサイトスクリプティングでは、脆弱性のあるウェブサイト上で悪意のあるスクリプトをユーザーに実行させて、攻撃者が用意したフィッシングサイトに遷移させてクレジット情報を入力させたり、ユーザーの端末内で保持しているデータを勝手に取得することができます。
非常に危険な攻撃です。
前項で紹介した「SQLインジェクション」は比較的攻撃の仕組みが理解し易い手法ですが、「クロスサイトスクリプティング」はウェブアプリケーションの開発経験が無いと仕組みがイメージし辛いかもしれません。
攻撃例としては、企業のウェブサイトでよくあるお問合せフォームで説明します。
まず、以下のような問い合わせフォームがあるとします。
まず、ユーザーはregist.phpで問い合わせを入力して登録ボタンを押下します。
登録ボタン押下時には入力値をPOSTやGETなどでconfirm.phpに渡し、confirm.php内で渡された値は変数などに格納したうえで、その値をフォーム内にそのまま表示します。
入力内容に問題が無いことを確認したら、ユーザーは送信ボタンを押下して、その押下時の処理で実際に問い合わせデータが登録され、result.phpを読み込んで処理が終了します。
これは設計者が想定した本来の画面遷移です。
この問い合わせフォームは入力値に対して値のチェックやセキュリティ上の処理を実施しておらず、入力された値はそのまま入力内容確認画面のconfirm.phpで読ま込まれます。
よって、入力値としてスクリプトを埋め込むことで、confirm.phpを読み込む際に、そのスクリプトも読み込まれて実行されてしまいます。
クロスサイトスクリプティングにおける攻撃の一連の流れを以下のイメージ図で解説します。
- 攻撃者は脆弱性のあるウェブサイトへのリンクにスクリプトを埋め込んで匿名掲示板などに貼り付けます(罠リンク)。
- 掲示板のユーザーが罠リンクをクリックします。
- 脆弱性のあるリンク先に遷移し、リンクに埋め込まれたスクリプトがリンク先のページ上で実行されます。
- このスクリプトでは攻撃者が用意したサイトに自身のCookie情報が渡されてしまいます。
ウェブサイトやウェブアプリケーションにおけるスクリプトは、Webサーバー側ではなく、実行する端末側(ブラウザ上)で実行されます。
よって、実行された端末から不正に情報を取得したり、ブラウザ側で表示されているウェブページを書き換えて表示したり、攻撃者が用意したフィッシングサイトへ強制的に飛ばすことも可能です。
前述した「SQLインジェクション」は主にサーバー上で被害が発生しますが、「クロスサイトスクリプティング」ではウェブページを閲覧するユーザー側で被害が発生します。
その意味ではより広範囲に影響が及ぶ深刻なサイバー攻撃とも言えます。
クロスサイトスクリプティングへの対策
クロスサイトスクリプティングでも、IPAから有効な対策が紹介されています。
IPAのページでもいくつか対策が紹介されていますが、軽く内容を抜粋して紹介していきます。
記号文字に対するエスケープ処理を徹底する
IPAが紹介する対策としては、フォームからの入力値を元にした出力か否かに関わらず、ウェブページに出力する全ての記号文字に対してエスケープ処理を施すこととあります。
エスケープ処理とは、htmlのタグなどで使用される < >といった小なり大なり記号や ‘ ” といったシングルクォーテーションやダブルクォーテーション、; セミコロンなどの特殊な記号文字を、html上で同じ文字として表示される別の文字列に置き換える処理です。
| 記号文字 | エスケープ文字 | 名前 |
|---|---|---|
| < | < | 大なり記号 |
| > | > | 小なり記号 |
| & | & | アンパサンド |
| " | " | ダブルクォーテーション |
| ' | ' | シングルクォーテーション |
クロスサイトスクリプティングでは、脆弱性のあるページの入力項目に対してスクリプトを文字列として渡し、その入力値を次のページで読み込ませることでそのスクリプトが実行されます。
入力値として渡されたきた値の特殊な記号を全てエスケープすることで、入力値として渡されたスクリプト文字列をブラウザはスクリプトとして扱われずに、ただの文字列として次のページで読み込んで表示します。
入力値ごとの適切なバリデーションを適用する
バリデーションとは、入力されたデータに対して、論理的なチェックを行うことです。
例えば何らかのID番号を入力させるなら、入力された値はデータベースのID値に格納できる値の範囲にあるか否か。
数値を格納するべき項目にアルファベットなどの文字が含まれていないか。
メールアドレスを入力された場合に、メールアドレスとして定められた書式に適合するか。
このように、設計者が意図しない値が入力値として入れられていないかをバリデーションすることも、クロスサイトスクリプティングを防ぐためにはとても重要です。
ただ、入力内容によって、コメントのような文章的なデータを扱うこともあり、その場合はバリデーションしきれないため、前述した「エスケープ」処理と併用して実装することが必要です。
ネットワーク設計におけるセキュリティ対策
システム管理者は業務システムの運用だけではなく、その業務システムを動かしているサーバー群を管理したり、そのサーバー群やクライアント端末が通信をするためのネットワークの運用や管理も行います。
なかでもネットワークはセキュリティ対策において必ず押さえておくべき基本的、且つ非常に重要な要素になります。
当項では、ネットワーク設計におけるセキュリティの重要性や、実施するべきセキュリティ対策を紹介していきます。
ネットワーク設計の脆弱性における問題点
「ネットワーク設計」を一言で説明するなら「用途によって適切にネットワークを分断する」ことです。
ネットワークは繋がることが当たり前であり、必要な通信だけを通して不必要な通信は遮断する。
また、ネットワークをグループ化して、グループ間の通信を分離して管理するために「ネットワーク設計」を行います。
もしネットワーク設計を適切に実施していない環境ではどのような脆弱性があるのでしょうか。
例えばWindows Serverでウェブサーバーを稼働させる際に、通常はIISがウェブページを公開する場合に80番ポートを使用し、SSL証明書でhttpsを使用して公開する場合は443番ポートを使用します。
よって、一般的にはウェブサーバーをインターネットに公開する場合、ファイアーウォールなどで、ウェブの通信で使われる80番ポートと443番ポートのみを許可して、それ以外の通信は遮断します。
因みに、Windows Serverでは、前述するIISのようなウェブサーバー機能のサービス以外にも、様々なサービスが稼働しています。
Windows間の名前ベースでの通信などで使用されるNetBIOSのポート番号は137番、138番、139番です。
また、ファイルやプリンターの共有で使われるポート番号は445番です。
ファイルやプリンターの共有機能では、NetBIOSの139番も使用します。
上記以外にも様々なサービスが稼働しており、それらがポートを開いて通信を待ち受けています。
もしウェブサーバーに対して通信の遮断をせずにすべての通信を許可してしまった場合、インターネットを介して、上記のNetBIOSのポートにアクセスして、Windowsの様々な情報を引き出すことができたり、ファイルやプリンター共有機能を悪用し、本来公開されてはいけない、サーバーに作られている共有フォルダにインターネットを介してアクセスできてしまいます。
そして、攻撃者はインターネットから開いているポート番号を確認して、個々のポートへ様々な攻撃を試すことができてしまいます。
不正アクセスを試みる攻撃者は、インターネットに公開されている様々なサーバーのIPアドレスに対して、ポートの開放状況を「ポートスキャンツール」で常にチェックをしています。
不必要なポートが開放された状態でインターネット上に公開されていた場合は、上記のような攻撃者によって瞬時に発見され、攻撃を受けてしまいます。
また、現在のランサムウェアなどのコンピューターウィルスを使用した攻撃では必ずネットワークが使われます。
ランサムなどのコンピューターウィルスはインターネットからメールなどに添付されて送信されてくるのが一般的であり、感染後は端末が所属するネットワーク内で活動し、更に別の端末や別のネットワークへも活動を広げようとします。
適切にネットワーク設計がされていない環境では、ウィルス感染したパソコンなどの端末から、他の端末や機密情報が含まれるサーバーまで自由に通信ができてしまいます。
他にも以下のようなリスクがあります。
- 機器の不具合などで発生したネットワーク障害がネットワーク全体に影響してしまう。
- 企業のオフィスネットワークで本来アクセスが許されていない機器や場所へアクセスできてしまう。
- 一部のデバイスが大きな帯域を使用した通信を行った場合に、ネットワーク全体が不安定になる。
前項で説明した「アプリケーションの設計や実装におけるセキュリティ対策」では、前提条件として、攻撃対象のサーバーは適切にネットワーク設計がされており、ウェブサーバーであれば、80番ポートと443番ポートでしかアクセスできないように制限をかけている想定です。
ウェブ用の通信しか許可されていないがために、その制限下で攻撃する手法になります。
もし、80番ポートや443番ポート以外にも通信できるポートがあれば、攻撃者は別の攻撃手法も積極的に試すことでしょう。
よって、セキュリティにおいて真っ先に実施しないといけない対策は、適切なネットワークを構築することです。
セキュリティを意識したネットワーク設計のポイント
適切なネットワークを構築することは、セキュリティにおいて最も基本的な対策です。
通信を通すポートを適切に制限し、通信の送信元や送信先を適切に管理し、ネットワークを用途などで適切に分離することで、大半の攻撃は遮断することができて、万が一攻撃に成功してネットワークに侵入できたとしても、その被害は限定されます。
当項では、ネットワークにおけるセキュリティ対策のポイントを紹介していきます。
OSI参照モデルを理解する
コンピューター通信の黎明期には、コンピューターメーカーや研究機関が独自に開発したデータ通信方式が存在していました。
独自に開発した通信方式を使用している場合、異なる通信方式を採用したネットワークとは互換性が無く、相互に通信ができずに大変不便です。
よって、国際標準化機構により、ネットワークにおけるデータ通信方式の共通のモデルを提唱したのが「OSI参照モデル」です。
このモデルを提唱し、各ネットワーク機器メーカーやOSなどのデベロッパーはこのモデルを元にデータ通信方式を実装することで、データ通信の技術が広く普及しました。
このOSI参照モデルはネットワークの入門知識を学習する際には必ず出てくる概念ですが、現在広く普及している実際のEthernetのデータ構造とは乖離していたり、厳密に言えば正確ではありません。
しかし、ネットワークを扱ううえで、各階層ごとにどのような機能があるかを知ることは非常に有効です。
今やただの概念であるOSI参照モデルですが、ネットワークで使用する機能を階層で分離して扱い、各階層ごとで使用するデータをカプセル化して各階層は互いに影響を受けないという考え方は、ネットワークを学ぶ上で非常に都合が良い定義です。
よって、ネットワークにおけるセキュリティ設計を理解するためには、まずOSI参照モデルを改めて理解しておきましょう。
| 階層 | 階層名 | 役割 |
|---|---|---|
| 1 | 物理層 | 物理的な光ケーブルなどでデータを運ぶために使用される階層 |
| 2 | データリンク層 | MACアドレスを使用して、HUBやL2スイッチが通信データを機器間で転送するための階層 |
| 3 | ネットワーク層 | IPアドレスを使用して、ルーターを介して通信データを目的地まで運ぶための階層 |
| 4 | トランスポート層 | スリーハンドシェイクでの確実なデータ転送を実現するTCPと、データが欠けることを許容して高速なデータ転送を実現するUDPのどちらのデータ転送方式を使用するかを決める階層 |
| 5 | セッション層 | 上位のアプリケーションごとのセッション管理をする役割の階層 |
| 6 | プレゼンテーション層 | 上位のアプリケーションが使用する文字コードなどのデータの表現方式を扱う階層 |
| 7 | アプリケーション層 | 個々のアプリケーションごとの基本的な通信方式やルールを定義する階層 |
階層5から7はOSI参照モデルのうえでは別れていますが、実際にはこれらをまとめて「アプリケーション層」として扱っています。
また、ネットワークにおけるセキュリティを理解するうえで必ず必要になる階層の知識は、第二層の「データリンク層」、第三層の「ネットワーク層」、第七層の「アプリケーション層」です。
当記事では各層の詳細な解説までは割愛しますが、ネットワークの基礎として必ず押さえておいて欲しい知識です。
各層ではどのような機能があり、具体的な機能名や技術名に何があるかは答えられるようにしておきましょう。
必要なポートのみ通信を通す
ネットワーク設計において、基本的な設計方針の一つです。
OSI参照モデルで言えば第七層のアプリケーション層が関連します。
サーバーやパソコン、ネットワーク機器で様々なアプリケーションが通信をする際には、アプリケーションごとにそのアプリケーション固有の「ポート番号」を使用します。
一般的なアプリケーションの場合、ポート番号は予め決まっており、そのポート番号を使用して通信を行います。
例えばsshの通信であれば22番ポート、httpの通信であれば80番ポートを使用します。
このポート番号を識別することで、ネットワークを流れる通信データはどのアプリケーションが使用しているかがわかります。
また、ポート番号はIPアドレスとセットで通信データ内に組み込まれます。
よくある例えでは、IPアドレスが建物までの住所を指定し、ポート番号が建物内でその通信を待ち受ける部屋番号を指定するようなイメージです。
ネットワーク設計をする場合に、まず実施しないといけないことの一つは、そのネットワークではどのホストがどのアプリケーションで通信をするのかを把握することです。
そこを把握したら、ファイアーウォールでそのホスト間の通信を全て遮断したうえで、使用するポート番号のみ通信を許可します。
インターネットに公開するウェブサーバーの場合であれば、そのサーバーにアクセスしてくるユーザーの接続元IPでは制限が掛けられない場合も多々ありますが、そのサーバーのサービスで使われるポート番号は確定しているため、必ずそのサービスで使用するポート番号だけを許可します。
ネットワーク設計に関わる技術者であれば当たり前のルールですが、このポート番号でのアクセス制限を徹底するだけでもセキュリティは大幅に向上します。
セグメントを適切に分離する
ネットワークは「セグメント」と呼ばれるネットワークのグループを作成して、一つの大きなネットワークを用途ごとに分けて分離することができます。
OSI参照モデルで言えば、第三層のネットワーク層が関連します。
このセグメントはIPアドレスとサブネットマスクを使用して設定します。
例えば、以下の様なネットワークがあるとします。
192.168.0.0/24
この/24はサブネットマスクの 255.255.255.0 と同じ意味合いです。
ネットワーク部は第三オクテットの192.168.0までです。
ホスト部は第四オクテットです。
このネットワークで使用できる(端末に割り当てできる)IPアドレスは以下の範囲です。
192.168.0.1 〜 192.168.0.254
このIPアドレスを割り当てられた端末間は遮るものが何もなく、直接相互に通信ができます。
このネットワークに以下のIPアドレスを持つ端末を設置してみます。
192.168.1.1/24
第三オクテットが0から1に変わっただけですが、上記の192.168.0.0/24のネットワーク内に、
192.168.0.1/24の端末が居たと仮定し、192.168.0.1 から 192.168.1.1 の端末に通信は通りません。
これはサブネットマスクで表現されるネットワーク部のIPアドレスが一致しないことにより、「セグメント」が異なることが原因です。
ネットワークが分離されたことを意味します。
では、192.168.0.1 の端末と 192.168.1.1 の端末が相互に通信するためにはどうすれば良いでしょうか？
それは、両ネットワークの間にルーターを設置してルーティングをします。
ルーターを介して、片側のポートの先は 192.168.0.0/24 のネットワーク。
もう片側のポートの先は 192.168.1.0/24 のネットワークといったように境界線を設けます。
さらに、192.168.0.0/24 のネットワークから 192.168.1.0/24 のネットワークに通信したい場合は「こっちのポートから抜けてね」とルーターに設定します。
これがルーティングです。
セグメントを適切に設計することで、以下のメリットがあります。
- 異なるセグメント間の通信を遮断して必要な通信だけを許可する構成が作れる。
- 不正アクセスによりそのネットワークに侵入された場合に異なるセグメントへの移動を防ぐことができる。
- ブロードキャストストームなどのネットワーク異常が発生した場合に異なるセグメントへ影響を与えない。
例えば、パソコンなどのクライアントが所属するネットワークと、サーバーが所属するネットワークを分離したり、さらにサーバー用のネットワークからDBサーバーを個別で抜き出して、別のネットワークに分離する、クライアントが所属するネットワークもフロアや部署ごとにネットワークを分離する、といった設計が一般的です。
当然、セグメントを増やすほどネットワークの管理は面倒になりますが、セキュリティ的には非常に有効な対策の一つです。
OSやミドルウェアの脆弱性におけるセキュリティ対策
システム管理者は、自社で様々なサーバーを管理して運用します。
サーバーOSであれば、Windows ServerやLinux系OSなどが使われ、そのサーバーOSにデータベースやウェブサーバーなどのミドルウェアをインストール、構築して稼働させます。
プログラミングにおいて、コードの記述ミスや設計時の想定漏れなどによる不具合は必ず発生します。
プログラマーであれば、アプリケーション開発で不具合は必ず発生するものという認識で共通していますが、同じようにプログラムをもとに動いているサーバーOSやミドルウェアに関しても同じように不具合はあります。
不具合も色々あり、画面に表示される文章や名称の誤字といった軽微なものから、プロセスの停止や誤動作といった致命的なものなど様々です。
致命的な不具合を抱えたOSやミドルウェアを使用する場合、その環境で稼働するアプリケーションを正常に使用できなくなるだけではなく、内容によってはそれが大きなセキュリティ上の脆弱性にも繋がります。
当項では、OSやミドルウェアの脆弱性における具体的な問題点の紹介と、それに対する対策を紹介していきます。
OSやミドルウェアの脆弱性における問題点
仕事やプライベートでWindowsを搭載したパソコンを使用している人も多いかと思いますが、皆さんもよくご存知の「Windows Update」によって、WindowsのOSそのものの機能やMicrosoftの提供している様々なアプリケーションの修正プログラムが配信されています。
このWindows Updateでは、OSやアプリケーションの機能改善や利便性向上目的の修正プログラムもありますが、見つかった不具合を修正することを目的とした修正プログラムも多く配信されています。
Windows10やWindows11などの個人向けOSだけに不具合が発生する訳では無く、当然サーバーOSであるWindows Serverや、サーバー上で稼働するウェブサーバーソフトやデータベースソフトなどのミドルウェアでも同様に不具合は発生します。
また、Windows系サーバーだけではなく、LinuxやUNIXなどのWindows以外のサーバーOSやそのOS上で稼働するミドルウェアも同様です。
サーバー系OSでも同様に不具合の修正プログラムが配信されるため、本来は都度そのプログラムを適用して不具合を修正する必要があります。
不具合のなかには、例えばOSやミドルウェアに対して、テレビゲームの裏技のように特定の操作をすることで、本来は制限が掛かっていて実行できないはずの操作ができてしまったり、プロセスを強制的に終了させてシステムを停止させることができてしまう事象などもあったりします。
また、本来はOSやミドルウェアの特定の用途でのみ有効なはずの内部的な権限を悪用して、不正なソフトやスクリプトを実行できてしまうといったものもあります。
そういった不具合はセキュリティにおける深刻な脆弱性になります。
OSやミドルウェアに対する脆弱性の対策
当項では、OSやミドルウェアに対する脆弱性への対策について紹介していきます。
提供されるパッチを適用して最新の環境を維持する
非常に当たり前の対策ですが、OSやミドルの開発ベンダーが提供している修正パッチを都度適用して、可能な限り使用しているサーバーのOSやミドルウェア、ネットワーク機器ならファームウェアを最新の状態に維持することが重要です。
しかし、常にパッチを適用して最新の状態に保てば安心かと言えば、そういうものでもありません。
OSやミドルウェアなどの不具合による脆弱性が発見されて、それに対応した修正パッチが開発されて配信されるまでの間は、その脆弱性に対して無防備な状態です。
修正パッチが配信されるまでの間にその脆弱性を利用してサイバー攻撃を行う手法を「ゼロディ攻撃」と呼びます。
このような問題がある以上、パッチを都度適用することを徹底すればOSやミドルウェアの脆弱性への対策は完璧であるとは言えないのですが、OSやミドルウェアの脆弱性を利用したサイバー攻撃の多くはゼロディ脆弱性ではなく、修正パッチが適用されていないサーバーやミドルウェアに対する既知の脆弱性を利用した攻撃です。
その意味では、可能な限り都度修正パッチを適用して、OSやミドルウェアを最新の状態で維持するということは非常に有効なセキュリティ対策と言えます。
パッチ適用を試験できる専用の検証環境を用意する
前項では、都度パッチを適用することが重要だと紹介しましたが、実際にそれを徹底することは非常に難しい現実があります。
修正パッチを適用することで、対象となっている脆弱性は解消できますが、その代わりに以下のリスクをあります。
- 現在の設定が変更されたり初期化される。
- 正常に動作していた別の機能が動かなくなったり挙動が変わる。
- 別の不具合の要因になる。
システムを運用するシステム管理者としては、現在安定して稼働している環境に対してパッチを適用する場合は上記のリスクもあり、できることならやりたくありません。
しかし、OSやミドルウェアに脆弱性を含んだ状態で稼働させ続ける場合、当記事で紹介したウェブアプリケーションへのセキュリティ対策や、ネットワーク設計におけるセキュリティ対策を適切に実施していたとしても、それらは意味を成しません。
よって、リスクがあってもパッチ適用を実施していく必要があります。
よって、パッチ適用を実施するとなった場合に、いきなり本番環境へ行うのは当然リスクが大きいため、パッチ適用時の検証環境を用意しておくことが必要です。
この環境はパッチ適用が必要になってから用意するのではなく、パッチ適用の運用を予め想定したうえで、本番環境の構築と併せて用意しておくのが理想的です。
有償サポートを受けられる製品を利用する
OSやミドルウェアについては、購入したり利用料を支払って有償で利用する製品と、OSS(Open Source Software)などにより無償で利用できる製品があります。
OSS製品などは無償で提供されており、その製品を商用利用することも許可されている製品であれば、それを使用することでシステムを構築する際のイニシャルコストやランニングコストを大きく下げることができて非常に便利です。
ただ、そういった製品では不具合やトラブル時のサポートは提供されていない場合が殆どです。
不具合やトラブル時にはユーザーサイトなどのコミュニティで質問などをしながら自己解決することが必要になります。
脆弱性に対する修正パッチも提供はされますが、有償製品のように高い品質で迅速に提供を受けられるかはわかりません。
コストを掛けずにシステムを導入したつもりが、適切なサポートを受けられなかったがために、大きな代償を支払うことになる場合もあります。
内部不正におけるセキュリティ対策
システム管理者は、当記事で紹介してきたウェブアプリケーションやサーバー、ネットワークに対するセキュリティ対策をするだけではなく、システムを使用する社内のユーザーによる不正や関係者による不正にも目を光らせる必要があります。
当項では、ユーザーや関係者による「内部不正におけるセキュリティ対策」を紹介していきます。
内部不正防止対策を実施していない場合の問題点
これまで紹介してきたセキュリティ対策は、主に外部からの攻撃に備えた内容でした。
これらの対策を徹底することは、外部からの攻撃に対して非常に有効ですが、自社の社員や関係者などの「内部」から不正を働こうとした場合、これまで紹介してきた対策では防ぐことはできません。
当項では、内部不正としてどのようなリスクや影響があるのかを紹介していきます。
機密データを外部に流出させてしまう
企業では様々なデータを扱いますが、なかには、顧客の個人情報のように、個人情報保護法などによって厳格な扱いを求められるデータや、自社製品の製造手順や素材の原材料や製法といった企業独自のノウハウなどの機密データも多くあります。
外部からの不正アクセス対策やアンチウイルスソフトなどでセキュリティを高めても、内部の社員がそれらのデータに容易にアクセスできるなら、それをメールに添付する、オンライストレージにアップロードするなどして、不正に持ち出すことができてしまいます。
いったん流出してしまったら、その後はライバル企業に機密データが売られて、自社のノウハウを利用した模造品が販売されてしまうかもしれないですし、顧客データが名簿屋に売られて拡散してしまうかもしれません。
そうなってしまったら経営的にはおしまいです。
自社の会計データや販売管理データを操作して横領される
業務で使われるシステムでは、前提としてユーザーが正しくデータを入力することが前提です。
お金を扱うシステムでは、最近のPOSレジのように、紙幣や硬貨を機械で自動的に数える機器と連携していれば誤魔化しようがないですが、金額の数字を手入力するシステムでは、実態とは異なる金額をいくらでも入力できてしまいます。
このように、不正な金額をシステムに打ち込み、実態の金額差を着服するような事件は昔から非常に多いです。
また、そのような不正をはたらく社員に会計知識があったり、会計に近い立場で働いている場合は、その不正を発見することは非常に困難です。
取引先やグループ会社経由でのデータ流出やウィルス感染
「内部不正」は自社の従業員による不正と受け止められますが、この「内部」には自社の従業員だけではなく、取引先などの他社やグループ会社なども含まれます。
日本の企業は欧米の企業と比べて、取引先やグループ会社といった「サプライチェーン」へのセキュリティ管理に対して関心が薄いといった調査結果もあります。
多くの大企業では自社内のセキュリティは非常に強固に構築されていますが、サプライチェーンのなかにはセキュリティが脆弱な企業もあり、そういった企業を狙って攻撃を仕掛け、その企業からターゲットである大企業の情報を取得したり、大企業への攻撃の足掛かりとして利用するケースが近年は多く見られます。
内部不正におけるセキュリティ対策
内部不正対策についても、IPAがガイドラインを公開しています。
詳しくは以下のリンク先をご参照ください。
このガイドラインのなかでは、内部不正対策の基本原則として以下の提言を行っています。
- 犯行を難しくする（やりにくくする）
- 捕まるリスクを高める（やると見つかる）
- 犯行の見返りを減らす（割に合わない）
- 犯行の誘因を減らす（その気にさせない）
- 犯罪の弁明をさせない（言い訳させない）
この基本原則をベースにして、個々の項目ごとにどのような対策ができるかを検討していく必要があります。
また、内部不正対策の推進は情報システム部門だけに任せるものではなく、企業の経営者や重役なども含めたプロジェクトチームや専門部署を作り、会社で一丸となり検討したり対策を打ち出していくことが必要です。
次項では、IPAのガイドラインも踏まえつつ、内部不正防止として有効な対策を紹介していきます。
IT資産管理ツールを導入する
IPAのガイドラインにおける基本原則のうち、以下の効果が期待できます。
- 捕まるリスクを高める
- 犯罪の弁明をさせない
当ブログでは、過去にテレワークに関する記事を掲載した際にも、「IT資産管理ツール」についても紹介しております。
このテレワークに関する記事でも紹介していますが、一般的なIT資産管理ツールは内部不正対策としても非常に強力なツールです。
IT資産管理ツールでは、クライアントの端末の操作ログを自動的に収集します。
- 誰がいつどのファイルを開いた。
- ファイルをどこにコピーした。
- どんなソフトを起動した。
などといった様々な操作が記録され、その操作ログでは特定の文字列を監査対象として設定することで、管理者にアラートを飛ばすこともできます。
このような操作ログを収集していることを社内が知れば、非常に強力な抑止力になります。
また、もし内部不正が発生した場合は、この操作ログが確固たる証拠になります。
IT資産管理ツールには操作ログの収集以外にも様々な機能があり、それらは内部不正対策とおいても非常に有効です。
導入していない企業は是非導入することを検討していただきたいですし、導入している企業は、効果的に活用できるように運用を見直すことをおススメします。
USBフラッシュメモリーを徹底的に制限し代替ツールを提供する
IPAのガイドラインにおける基本原則のうち、以下の効果が期待できます。
- 犯行を難しくする
- 犯行の誘因を減らす
データの不正に持ち出す際に最も利用されているのはUSBフラッシュメモリーです。
紹介したIPAのガイドラインにもそのデータが記載されています。
であれば、そのUSBフラッシュメモリーを使用できないように徹底することが必要だと言えます。
ただ、USBフラッシュメモリーが不正なデーテの持ち出しに多く使われるのは、その利便性にあります。
悪用することを想定しなければ、大きなデータを手軽に移動する手段として最適です。
USBフラッシュメモリーを端末で使えないようにするには、ActiveDirectoryを導入している環境であれば、グループポリシーを利用して制限を掛けることができます。
また、前述した「IT資産管理ツール」を導入している場合は、IT資産管理ツールの機能としてUSBメモリーに制限を掛けることも可能です。
管理下の端末のUSBフラッシュメモリーを使えなくすること自体は内部不正対策として有効な対策ですが、USBフラッシュメモリーありきで行われている業務があったり、正規のデータ移動を伴う業務に支障が出るかもしれません。
便利な道具を使用不可にした場合、今度は電子メールなど別の仕組みで代替されることは明白です。
よって、USBフラッシュメモリーを使えなくするのであれば、その代わりとなる仕組みやツールも併せて提供する必要があります。
例えば、法人向けのオンラインストレージを代わりに提供することで、ユーザーのファイルのアップロードやダウンロードをシステム管理者が管理できます。
クライアント証明書認証などと組み合わせることで、利用できる端末の制限を掛けることも可能です。
このように、USBフラッシュメモリーに制限を掛けることをしつつ、システム管理者が管理しやすいような別の代替ツールも併せて提供することが重要です。
職位や職務によりアクセス権をデータと物理の両面で管理
IPAのガイドラインにおける基本原則のうち、以下の効果が期待できます。
- 犯行を難しくする
- 犯行の誘因を減らす
内部不正の加害者で多いのは、その企業内でも比較的下層に位置する人たちです。
IPAの基本原則で言えば、元の報酬が低く、不正を犯すことで相対的に大きな見返りを得ることになる人たちです。
そのような人たちに重要なデータにアクセスできる権限があれば、それは「犯行の誘因を作っている」とも言えます。
企業内において、情報は広く共用されることが業務の効率化やイノベーションの促進に不可欠だと考えますが、企業の経営に影響がある機密情報を広く共有してはいけません。
電子データであれば、ファイルサーバーなどでそういったデータが保存されており、そのデータにアクセスできるユーザーは限定されている必要があります。
また、それらのデータに対しては、ファイルサーバーが持つ監査機能を有効にして、管理下のファイルに誰がいつアクセスしたかを記録しておくことが望ましいです。
ユーザーの企業内の職位や職務によって、ユーザーアカウントをグルーピングし、アクセスできるデータに制限を設けることは、内部不正を未然に防ぐ意味でも非常に有効です。
また、このような対策はデジタルデータだけに目が行きがちですが、電子化されていない紙などの情報であっても同様です。
例えば、個人情報が記載された契約書などの書類については施錠された部屋に保管し、その部屋に対する入退室は管理帳簿で記録に残し、不正な書き換えや持ち出しが後から確認できるように監視カメラを設置します。
また、従業員が業務において立ち入ることができるオフィス内の場所もゾーンで区分けします。
機密情報や個人情報を業務で扱う部署のあるフロアや区画については、許可のない一般の社員には立ち入りを禁止します。
機密情報や個人情報が含まれた紙の書類を移動できるのは、限られたフロアや区画のなかだけに限定します。
この様に、電子化されていない紙などの扱いにおいても、デジタルデータと同様にグルーピングやゾーニングを行い、アクセスできる社員を厳格に制限しながら運用することは非常に重要です。
最後に
今回の記事では、企業のシステム管理者向けとして、様々な分野のセキュリティ対策についてまとめてみました。
今回紹介したセキュリティ対策に関する個々の分野を詳細に理解するには以下の業務経験が必要です。
- プログラマーとして大規模なウェブアプリケーション開発経験
- ネットワークエンジニアとして多くのサーバーやクライアントが所属するある程度の規模のネットワークを設計、運用経験
- サーバーやミドルウェアエンジニアとしてパッチ適用で厳格な運用をした経験
- 企業のシステム管理者で個人情報保護責任者の経験やIT監査や内部統制経験
ただ、世のIT技術者のなかでも、上記の分野すべてに精通している人はそれほど多くはありません。
普通はどれか一つの分野に精通するだけで精一杯です。
例えば、システム管理者がセキュリティ対策をするうえでは、セキュリティを考慮したウェブアプリケーションのプログラムが書ける必要はありませんし、ネットワーク機器のConfigを設定したり、コンソールからコマンドを実行してネットワーク機器を操作できる必要もありません。
そのように深い知識は必要ではなく、今回紹介したような、各分野における脆弱性の内容や予想される被害、実施すべき対策を大まかに理解していただければ十分だと思います。
これらの知識があれば、外部のシステムベンダーに対して、十分なセキュリティを確保したシステム要件を提示することができます。
また、万が一セキュリティにおける事故が発生した場合、原因やその影響度を正確に理解することができるようになります。
今回の記事をシステム管理者の業務に活かしていただきたいのは、まさにこの部分になります。
是非参考にしてみてください。
今回も長々と読んでいただきましてありがとうございます。
それでは皆さまごきげんよう！
