Tweet

最終回 ID管理システム導入の総仕上げ、移行と運用

前回まででID管理システム化の要件定義・基本設計のポイントを見てきました。最終回では、構築したID管理システムへの移行、運用を中心に解説します（編集部）

　移行――最後の山場

　要件が決まり、設計が終わり、システムが構築されるといよいよ稼働を迎える。その前の最後の山場が、移行フェイズである。

　移行フェイズにおいては、新しく構築したシステムに既存のデータを反映、適用していくのだが、特にID管理に関しては、既存データの整理に大きな負荷がかかる。

　要件定義、設計、システム構築などのフェイズは、その作業の多くをSI業者やベンダが主導権を握って進めてくれる。しかし、移行フェイズはユーザー企業側が主担当となって進めなければならない。これは、ベンダではそのデータの要、不要が判断できないからである。

　同じように、IT部門においても要、不要が判断できない場合がある。例えば、経理部門でSAPのユーザー登録を行っているというような、現場が運用、管理を行っているシステムなどである。

　このような場合、システム部門から現場に対して「いつまでに移行対象となるユーザーを教えてください」や「移行すべきユーザーは、このリストにある人たちでよいか確認してください」といったアナウンスをすることになる。

　現場からの返答が「使っているかどうか、必要かどうか分からないけど、取りあえず残しておいて」という内容であると、ID管理をシステム化しても内部統制の観点では不適切な、いわゆる「幽霊ID」が結局残ってしまうことになる。

　このようなやりとりや現場との調整が多く発生し、当初想定したスケジュールどおりに移行がなかなか進まないことはよくある話だ。ある企業では、移行が終わらずに、結局、本稼働を数カ月遅らせたというケースもある。

　このように、多大な労力を要する移行作業であるが、ID管理システム自体は“本来あるべき姿”、“今後運用していきたいポリシー”に沿って、前フェイズにてすでに構築されている。そのため、このシステムを使用すれば、多少は移行作業を効率化できる。

　ID管理システムに現在の人事データを登録することで、そのシステムには、そもそもどういったユーザーがID発行をされているべきなのかをリスト化できる。そのあるべき姿のリストと、現在発行済みのIDのリストを付き合わせ、その差異について消し込んでいく方法を取れば、1件ずつ要、不要を判断するよりは効率的である。

　システム仕様の整理

　移行の課題はもう1つある。それは、システムの仕様による移行方式の検討だ。

　プロビジョニング先のシステムのマスタメンテナンス仕様により、用意すべきデータが変わってくる。列挙すると以下のようになる。

• プロビジョニング先のマスタを全削除し、ID管理システムから全件新規登録しても、運用上影響のないもの（例えばLDAP上に構築されたアドレス帳など）
• プロビジョニング先のシステムが、システム内部でIDを別途発行するため、ID管理システムからのデータ更新に注意を要するもの

　前者の場合、既存データをいったんクリアし、人事システムなど源泉となるシステムからのデータをそのまま流せば、マスタはあるべき姿に整理されることになる。つまり、ID管理システムの機能のみで移行、つなぎ込みが可能になる。

　一方、後者の場合、ID管理システム側に用意すべきデータは、現システムのマスタを、内部で採番されるIDを含めてそのまま持ってこなければならない。また内部IDの取得が不可能な場合、プロビジョニング後にシステム側権限を再設定することが必要になる。

　この典型的な例がActive Directoryである。Active Directoryにおいて、人間がIDとして認識するものはログインIDであるが、内部的には別のIDが存在している。このため、同じログインIDでユーザーを作り直しても、従来持っていたフォルダへのアクセス権が剥奪されるため、入れ替え後のIDではアクセスできないことになる。

　そのため、事前にファイルサーバのアクセス権をリストアップしておき、ID管理システムで更新後にアクセス権を設定し直すなどの作業が必要になる。その作業ボリュームを見て、コストやリスク要因なども加味したうえで移行手段を判断しなければならない。

　これを乗り越えてしまえば、システム部門としても、企業としても、大いに効果のあるID管理ではあるが、なかなか道は険しい。最後の山場と思って取り組んでいただきたい。

1/3

Index
ID管理システム導入の総仕上げ、移行と運用
	Page1 移行――最後の山場 システム仕様の整理
	Page2 運用あってこそのID管理システム 事故防止のためにできること 事故の例1：ミスによるデータの全削除 事故の例2：想定外のID付与
	Page3 ID管理システムに必須の機能、それは「運用の支援」 ID管理システムの力を確認できる「レポーティング」 ID管理システム導入のプロジェクトスケジュール ID管理システムの今後

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

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

RSSフィード