統制の鍵となるシステムセキュリティ保証とは：セキュリティツールで作る内部統制（4）（2/3 ページ）

[中島 浩光，＠IT]

アイデンティティ管理で求められること

　アイデンティティ管理とアクセス管理は密接に結び付いているため、どこまでをアイデンティティ管理とするかは難しいのですが、SOX法対応におけるアイデンティティ管理の要件として、「システム上のIDとIDにひも付く情報の管理」の要件をまとめてみました。

1. 利用者個人とIDが1対1であること
   
   当たり前のことですが、データ・プログラムに対して、アクセスするのは利用者個人（人間）であり、システム上で利用者の制御を行うために、利用者個人を特定する（Identify）IDが使われます。従って、システム上において、利用者個人とIDは1対1の関係である必要があります。
   
   　通常この関係は保たれているのですが、この関係が保たれていない場合があります。
   
   　まず、「ゴーストID」と呼ばれる退職者のIDや利用者不明のIDです。この場合、利用者とIDの関係は、0対1となります。このためゴーストIDが利用された場合、誰が使用したのか特定ができなくなるため、これは排除すべきものとなります。
   
   　次に共有IDです。この場合、利用者とIDの関係はN対1であり、このIDが利用された場合も利用者の特定は難しくなります。共有IDもゴーストIDのように排除できればよいのですが、問題は共有IDに「管理者ID」が含まれてしまうことなのです。
   
   　UNIXにおける「root」や、Windowsの「administrator」、そのほかにもDB管理者や業務アプリの管理者など管理者IDはたくさんあり、これらを排除するわけにはいかないのが現実です。管理者が1人だけならいいのですが、実際にはそうはいかないのが一般的です。このため、これらの管理者IDを利用する際には管理者IDの利用者を識別する何らかの手段が必要となります。
   
   　例えば、OSレベルにおける管理者IDの解決手段の例を挙げると、セキュアOS（例：CAのeTrust Access Control）を導入し、システムへのログインについては個人IDを利用し、その後、管理者IDにスイッチする運用を行うことで実現するといったものがあります。
   
   
2. IDが持つアクセス権が役割ベースで定義されること
   
   　利用者のデータ・プログラムへのアクセス権は、「利用者個人」に対して付与されるものではなく、利用者の業務上の役割に対して付与されるものです。分かりやすくいうと、業務上の役割、○○部とか、部長クラス、××担当者といった役割に対してアクセス権を割り当て、利用者はその役割にひも付いていることが必要になります。例えば、システム部門の課長が部長へ昇進した場合、アクセス権限もそれに伴って変わるのが一般的です。
   
   　従って、システム上におるアクセス権の設定についても、個人IDに直接アクセス権を設定するのではなく、個人IDが持つ役割（システムによっては、「個人IDが属するグループ」）にアクセス権を設定し、個人IDと役割（グループ）をひも付けておく必要があります。
   
   　OSレベルや一般的なディレクトリなどであればこれは可能ですが、業務アプリケーションレベルでは各業務アプリケーションでの実装がどうなっているかに依存するため、もし、うまく実装していない場合は運用などでの補完が必要になります。
   
   
3. ID情報・アクセス権情報の管理における権限の分離
   
   　ID作成やアクセス権の変更、ID削除などの管理作業では、申請→承認→実装という手順を踏む必要があります。申請自体は利用者本人からだったり、人事からだったりかもしれませんが、承認は申請者とは別の「システム・オーナー」が行う必要があります。
   
   　また、IDの実装（システム上での作成・変更・削除）は申請者・承認者とは別のシステム管理者が行う必要があります。この申請者・承認者・実装者のどれかが同一人物であった場合、不正を防げない可能性が高くなるため、これらの権限を分離する必要があります。
   
   
4. ID情報・アクセス権情報の集中管理
   
   　システムが多くなればなるほど、ID情報・アクセス権情報は増えていき、各システム間での整合性を保つのが難しくなります。管理は複雑になり、ゴーストIDなどを生む原因となります。そのため、ID情報とアクセス権の情報は集中管理することが望まれます。
   
   
5. ユーザーIDの管理、ユーザー認証、アクセス制御における適切なシステムの利用
   
   　ID情報・アクセス権情報の管理やアクセス制御について、場合によっては紙での運用や、ユーザーIDを管理しているテーブルにSQLで直接アクセスしたりすることも可能です。しかし、そういった運用については適切なシステムやツールを利用することによって、その部分でのミス・不正をなくすようにする必要があります。
   
   　つまり、ユーザーID管理ツール、アクセス制御システムの採用、認証強度のより高い技術の採用といったものが求められます。極端な例かもしれませんが、「○○フォルダには××さんしかアクセスしてはいけません」とアナウンスし、システム的な制御は掛けないのもアクセス制御を実施しているといえなくはないのですが、許可されていない利用者が不注意でアクセスしてしまうことが考えられ、アクセス制御機能としては不十分といえます。
   
   　このような場合には、やはりシステム的なアクセス制御を掛けることが必要です。また、別の例で、重要な機密ファイルへのアクセスについてはアクセスした利用者を厳密に特定したいため、ユーザー認証をパスワードよりも認証強度のより強い、指紋認証などの生体認証を採用する場合もあります。
   
   
6. ID管理プロセスの明文化
   
   　当たり前のことですが、ID管理プロセスは統制の対象となりますので、プロセスが明文化され、それに従って実行される必要があります。
   
   
7. IDにひも付けられる業務上の役割の網羅と明確化
   
   　役割ベースのアクセス制御と密接に関係しますが、利用者の持つIDが特定のデータ・プログラムにアクセスする必要性は、必ず業務上明確にされる必要があります。そのため、それらの業務上の役割をきちんと網羅するとともに、明確化してアクセス権情報の管理ではそれらを使用することが必要となります。
   
   
8. ID情報・アクセス権情報のレビュー
   
   　ID情報・アクセス権情報は、利用者の異動などによる変化に合わせて管理作業を行っていくことになります。そのため、定期的にID情報・アクセス権情報のレビューを行うことによってゴーストIDや利用者IDが持つ、不要なアクセス権を取り除いていくことが必要になります。
   
   
9. ID管理作業におけるログの取得
   
   　ID管理作業が定義されたとおりに行われているかを保証し、確認するためにID管理作業自身の監査ログの取得が必要となります。
   
   

　SOX法対応としては、以上のような要件を対象となる各システムで実現されているかをチェックしていくわけですが、対象となるシステムの数が多くなるにつれ、運用負荷が非常に高くなることから、アイデンティティ統合管理システムの導入が求められます。しかしながら、アイデンティティ統合管理システムを導入する際には、事前にいくつか整理すべき点があります。