第3回 ID管理システム、要件定義から基本設計まで

徳毛　博幸
京セラコミュニケーションシステム株式会社
BPO事業部　副事業部長
2009/6/19

いまからID管理システムを導入するならば、先人の知恵や実例を踏まえた形で設計すべきです。第3回では過去の事例を基に、要件定義フェイズ以降で注意すべき点を解説します（編集部）

　第2回「いま、あなたの会社にID管理システムが必要な理由」では、ID管理のシステム化の目的・目標・効果・ゴールを考えてきた。今回からはいよいよID管理のシステム化プロジェクトをスタートしよう。第3回では要件定義からシステム構築までを述べてみたい。

　要件定義フェイズで決めるべきこと

　要件定義フェイズにおいて検討・決定すべき事項の柱となるのは、以下の3点である。

• ID管理の対象となるシステム
• アカウント変更のトリガーとなる、入社、退職、部署異動、昇格／降格、休職、復職、出向、改姓などの人事イベント
• 人事イベントを各システムへどう反映するのかのポリシー

　まず「ID管理の対象となるシステム」を選定することからはじめよう。以前は、1人の従業員が業務で使用するIDの数は4〜8個といわれていた。現在はもう少し増えているかもしれないが、少なくとも8種類前後のID管理対象があるといえる。そのような中で、システム化の目的に応じて、どのシステムをID管理の対象とすべきかを抽出する必要がある。

　筆者が多くの企業のID管理システム化を支援させていただいた中で、選定するケースの多い代表的なものが次の3システムである。

• Active Directory（および全社ファイルサーバ）
• SAP R/3などの基幹システム
• LDAPサーバ

　各企業のID管理システム化の目的にもよるが、システム運用管理コストの削減と内部統制の強化という観点で、大きな効果がある、あるいは急ぎで対応する必要があるという判断で抽出されたシステム群といえる。これらの3システムを対象とされた企業の例について、少し触れてみよう。

●Active Directory

　セキュリティの基盤として、WindowsのActive Directory構築を行った。ユーザーへのセキュリティポリシー適用やファイルサーバのアクセス権制御など、さまざまな集中管理が可能になる。反面、タイムリーに更新していかなければならない。

　これを情報システム部門で運用管理しているような場合、現場からの依頼を受けIDを発行・停止する、パスワードをリセットする、グループポリシーを設定する、アクセス権グループのメンバーを異動のたびに変更するなど、その維持には多大な労力が必要となっている。これを効率化したい。

●基幹システム

　財務系の基幹システムは、内部統制の観点で最重要視されるため、当然ではあるが、J-SOX初年度は手作業で何とか乗り切れる見込みだが、承認権限などを定義するロールの管理などが非常に煩雑になっている。翌年度以降もこれを繰り返すのは避けたい。

　また、以下のような点の確認が課題となりがちである。

• 業務上必要以上の権限が付与されていないか
• 特権を付与されたユーザーについてはその権限付与について承認の記録があるか
• 退職者のIDは速やかに削除されているか

　これらは、悪意を持ったユーザーによる、データ改ざんのリスクにつながることを防止するためのものであるが、実際に、SAPなどの代表的な製品であっても、ロール管理、アクセス権管理は多くの会社でそのコストとリスクが問題となっている。

　監査は1回きりの話ではないため、継続的に発生する運用については、自動化・システム化しておきたいというのは、各社共通の思いだろう。

●LDAPサーバ

　現在は一部のシステムの認証サーバとして使用されている程度で、活用度が高いわけではないが、将来的にはすべての認証を集約したいと考えている。今後、ここで管理するID／パスワードについては、厳密な管理、タイムリーな管理が必要となるため、ID管理の対象としておきたい。

　ID管理のシステム化は、なるべく広い範囲をその管理対象とした方が効果は大きい。しかし、管理対象となるシステム数に比例し、必要となる時間やコストが大きくなるのも事実である。まずは重要度・緊急度の高いシステムから対象とし、その効果を見ながら段階的に適用範囲を広げていくのがよいだろう。

　トリガーとなる人事イベント

　次に「アカウント変更のトリガーとなる人事イベント」について考えてみる。

　ID管理とは、「従業員の出入り、職務の変更に応じて、利用するシステムのIDの登録、更新、削除を行うこと」である。つまり、従業員の出入り、職務の変更といった現実世界の人事イベントをトリガーに、各システムのIDを変更していくことになる。「IDの変更につながる人事イベントとは何か」というのを明確にするのが、この要件定義において考えるべきことになる。

　システム側で意識すべきイベントとしては、例えば、

• 定期新入社員が入社した（IDの登録）
• ある従業員が退職した（IDの削除）
• 人事異動した
• 昇進した
• 関連会社に出向した
• 育児休暇で休職に入った

などさまざまなものが考えられる。また、正社員に限らず、システム利用を行う派遣社員なども考えると、雇用形態によっても人事イベントの取り扱いは変わってくるだろう。

　併せて、これらの人事イベントをどうやってID管理システム側で、把握するのかも要件定義のタイミングで明確にしておきたい。

　多くの人事イベントは、人事部門において管理されていると考えることができる。そしてそれらの人事イベントは、システムとしても人事データの変更という形で知ることができるだろう。一方、派遣社員などの人事システムの管理下にない従業員については、別の方法を考えなければいけない。

　多くの場合、システム部門では、現場から「派遣社員のAさんに入ってもらったのだけど、メール使えるようにして！」とか「Aさんに○○システムを使ってもらうにはどうしたらいいの？」といった連絡がきて、初めてAさんという派遣社員が増えたことを知る。

　このように現場が声を上げてくれる場合はまだよいのだが、Aさんとの契約が終わったとしても、「Aさんとの契約が終わったから、メールアドレス消しておいて」といった連絡をしてくれる現場は非常にまれである。

　このように、正社員以外の人事イベントが発生したことを検知する方法も検討しなければならない。

1/3

Index
ID管理システム、要件定義から基本設計まで
	Page1 要件定義フェイズで決めるべきこと トリガーとなる人事イベント
	Page2 人事イベントをシステムにどう反映させるか 状況の変化に合わせてIDを維持／管理 システムの属性項目も確認すべし
	Page3 ID管理システムの基本設計 IDのライフサイクル、タイミング

実践・アフターJ-SOX時代のID管理 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）