日本版SOX法・徹底解析

　今回はデータ保護について“群”管理を考えてみる。ITに関するセキュリティがパソコン単体で考えられることが多いように，情報保護についても個別の対策が考察されることが多く，構造的な対策に触れているケースは少ないように思う。

http://itpro.nikkeibp.co.jp/article/COLUMN/20090409/328134/

　情報が外部に漏れるルートは数多く存在するが，今回は情報をデータ（ファイル）の内容と定義し，「データの入手」（データへのアクセス），「データの移動」（外部記憶媒体などへのコピー），「情報の流出」（社外でのデータ流通）の三つのフェーズでとらえ，実施すべき対策と具体的な手法について解説する。具体的には，ユーザー認証とアクセス権限管理の徹底，グループポリシーを使った設定の統一，データの暗号化といった手法である。

図1●情報の流出ルート

[画像のクリックで拡大表示]

データに対するアクセスを制限する

　情報保護の基本は，データに対するアクセスを制限することにある。そもそもデータを入手するためには，（1）データへのアクセスが許可されている，（2）本来はデータへのアクセスが許可されているべきではないが，設定漏れなどによってアクセスできる状態にある，（3）技術的にアクセスが禁止されている，の三つのケースに分類できる。これをまとめると表1のようになる。

表1●アクセスコントロール

　不適切なデータの入手を防ぐことに焦点を当てると，重要なのは（2）のコントロールである。サーバーごとのアカウント管理や，アクセス権付与の正当性チェックは欠かせない。人事異動や入退社に合わせて常にメンテナンスを続けていく必要もある。ここで重要になるのが，アカウント管理やアクセス権付与の作業を一元化し，ルールを徹底することである。

　データ共有のために使うファイル・サーバーなどは小規模な単位で五月雨式に導入され，サーバーごとに独立に管理されるケースが多い。部門ごとに予算と管理が独立している場合や，特定のプロジェクトに関連して導入したサーバーなども，独立して管理される場合がある。こうなると，アカウントやアクセス権の管理がおろそかになりやすい。

図2●サーバーごとに独立したアカウント管理

　こうしたアカウントを統一的に管理する仕組みとして，ディレクトリ・サービスが利用される。マイクロソフトの場合はActive Directoryというシステムがこれに相当する。

図3●ディレクトリ・サービスを使ったアカウント管理

　ディレクトリ・サービスを使った場合，アカウントを破られると多くのシステム・リソースにアクセスできてしまう懸念がある。またサーバーの数が少なければ，独立したアカウント管理でもさほど問題が表面化しない。このためディレクトリ・サービスの有効性は理解されにくい面がある。ただ，「すべてのサーバーでアカウントが確実かつ適切に管理されること」，それを「定期的に確認すること」は作業負担が極めて大きい。

　実は筆者自身，どちらかというと独立したアカウントを管理の方が有利だと考えていた。ところが前職でSOX法（サーベンス・オクスレー法）対応のために独立して運用されているサーバーのアカウントをチェックした際，管理の難しさを痛感した。不備のあったシステムが適切に運用されるよう，ワークフローを設計して修正を試みたものの，無視できない例外処理が多かったからだ。

　ここで取り上げている（2）のケースは，サーバーばかりでなくクライアント・パソコンにも当てはまる。例えば複雑なパスワードの利用，ワークステーションの自動的なロックは，内部からの不正や不適切なアクセスに対する対策だが，すべてのパソコンに対して確実に実施しようとすると，ツールの手助けなしでは作業が進まない。

　ここでもディレクトリ・サービスが一つの対策になる。Active Directoryでは，グループポリシーという仕組みがあり，様々な設定を強制適用できる。セキュリティ・パッチや，ソフトウエアの利用についてもコントロールできる。持ち込みパソコンや，何らかの方法で社内ネットワークに接続された管理外のパソコンから，データを持ち出されたり，不正アクセスされたりする場合はある。ただこれも，グループポリシーでIPsecを利用するよう設定しておけば，管理外のパソコンはIPsecの確立に必要な情報や証明書を持っていないため，ネットワークから排除できる 。

図4●IPsecポリシーの活用による持ち込みパソコンの排除

データの移動（持ち出し）を制限する

　正規のデータであれ，不正に入手したデータであれ，それが組織内にとどまっている限りは，比較的問題の解決が容易な場合が多い。つまり予防策として，データを組織外（管理外）への持ち出しを制限することが重要になる。

　データの移動を防ぐためにパソコンの持ち出しが禁止されるケースがあるが，実際のところ，情報漏えい事故の大半は紙などの媒体で発生している。筆者としては，紙など他の媒体で持ち出しが行われるよりは，これから紹介するデータ保護をしっかり実践したパソコンの持ち出しを許可する方が，むしろリスクが少ないと考えている。

　データが組織外に移動する代表的なケースは，（1）USBメモリーやCDといったメディアにコピーしたデータを持ち出すケース，（2）パソコンやサーバーが物理的に移設されるケース，（3）メールなどネットワークを使って持ち出されるケースなどが考えられる。

　（1）USBメモリーやCDによるデータの持ち出しを防ぐ方法としては，パソコンのUSBポートを物理的にふさぐケースがある。ただこの方法は，パソコンを導入する際やメンテナンスの際に，作業コストが上がってしまう。

　これに対し，ソフトウエア的にUSBポートの利用を制御する手法もある。例えばグループポリシーを使って，パソコンに対するドライバのインストールを制限する。書き込みの禁止，読み込みの禁止といった制限や，特定のUSB大容量デバイスに限定して利用を許可することも可能。さらに，暗号化機能を持ったUSBメモリーへのコピーだけを許可すれば，USBメモリーを紛失した際の情報流出対策を兼ねることにもなる。この手法ですべてのケースの予防ができるわけではないが，監査イベントの収集と合わせることで，安価で現実的な対処が可能になる。

図5●USBデバイスのきめ細かい制限（Windows Vista　Enterprise）

　（2）の問題は，パソコンのディスク・ボリューム全体を暗号化することで対処できる。Windows Vista, Windows Server 2008では，BitLockerを使ってボリュームごと暗号化できる。

　最も厄介な問題が（3）である。意図的な漏えいばかりでなく，P2Pに絡んだ事故によって重要なデータが流出することが少なくないからだ。BitLockerやEFS（Encrypted File System）によって暗号化していたとしても，データが電子メールに添付される際や，ウイルスによってネットワークに送出される際には復号が済んでいる（暗号が解除されている）。このため暗号化による保護は期待できない。このようなケースの対策としては，データ・レベルの暗号化（または永続的な暗号化）が有効である。

情報の流出を防ぐ（データ・レベルの暗号化）

　データ・レベルの暗号化手法の最も簡単な例は，パスワード付きのデータシートや，パスワード付きのアーカイブである。これらのファイルは，外部に流出してもパスワードが漏れなければ内容を見られることはない。ただ，パスワードという比較的弱い仕組みで守っているため，パスワードを推測され，暗号化を解除される可能性は無視できない。

　そこでマイクロソフトでは，証明書などを使ったRMS（Rights Management Service），またはIRM（Information Rights Management）と呼ぶ手法を用意している。ファイルを復号する際にユーザー認証と資格の確認を行う仕組みで，なりすましが困難になる。さらに，サーバー側で管理している資格情報を変更すれば，事後的にデータの復号を防げる。

　このようにデータ・レベルの暗号化は非常に強力な技術だが，ファイルごとに個別に設定を施す必要があることから，暗号化を忘れてしまう場合がある。この問題の現実的な対策として，ファイルを共有サーバーに格納する際に，強制的に暗号化する方法がある。例えばMOSS（Microsoft Office SharePoint Server）は，フォルダに対して強制的にIRMを実行する機能を備えている。フォルダに対するアクセス権に沿ってIRMを設定することで，ファイル・サーバー上でのアクセス制限に加え，データそのものに対してアクセス権限を埋め込めることになる。

　適切な設定を行ったMOSSから読み込まれたデータは，ファイルが外部に流出した場合や，不正・不適切なアクセスによって入手した場合でも，IRMにより保護されており，内容にアクセスすることはできない。

図6●サーバーを使ったIRMによる保護の自動化

[画像のクリックで拡大表示]

　MOSSでは履歴の管理も行える。例えば財務情報を管理しているExcelのシートを，修正の履歴管理を行ったうえで，RMSにより強制的に暗号化することができる。SOX法など内部統制の対応ではExcelシートの統制が問題となることが多いが，この手法でアクセス管理，修正履歴の記録，バックアップを自動化することで，必要な統制を実現できる。

　パソコンを“群”として管理していくためには，統一的な制御の仕組みが必要である。実際に使ってみるまでは，余計な作業が増えるだけで不必要な責任を負うように思われるかもしれない。しかし，結果として管理者に何度も設定変更を依頼するようでは，非効率なうえ，見落としが生じやすい。といって，一足飛びに”群”を厳密に管理しようとすると，技術面でも運用面でもうまくいかないことが少なくない。現実的な展開方法を検討する必要があるだろう。

<<前ページ 1 2 3 4

　[2009/04/20]