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

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

　運用あってこそのID管理システム

　ID管理もそのほかのシステム同様に、システム化して終わりではなく、運用こそが大切である。ここではID管理システムを運用していく上で、どのような注意が必要かを考えてみたい。

　事故防止のためにできること

　移行が終わるとID管理のシステム化は一段落である。省力化、内部統制の強化、セキュリティの強化などさまざまな効果が出てくるだろう。

　ここで1点付け加えておきたいことがある。ID管理をシステム化することで、基本的には自動化や省力化が図れるのだが、一方でシステム化によるリスクも存在している。

　従来のように個別のシステムについて、それぞれの管理、運用担当者が、それぞれにマスタメンテナンスを行っていた場合、ミスやデータの誤りなどの事故の影響範囲は、その担当者が管理するシステムに限られていた。

　一方、ID管理がシステム化され、複数システムのマスタを一括でメンテナンスするような場合、ミスやデータの誤りは、一斉に複数のシステムに反映されてしまう。最悪の場合、朝出社してみると、ことごとくシステムが使えなくなるという場合もある。

　また、ID管理をシステム化した企業では、大小の差はあれ、何らかの事故を体験しているのも実情である。ここで典型的な事故の例を紹介し、どう事故を防止するべきかを考えてみたい。

　事故の例1：ミスによるデータの全削除

【人事データの誤りで、ユーザーのID・アクセス権が全削除されてしまった。】

　こんなことが起こったのでは、何のためのID管理システムなのかという話だが、しょせんはID管理システムもコンピュータシステムであり、ゴミをインプットすると、ゴミがアウトプットされる。例えば、以下のようなケースである。

　要件定義の項で触れたが、多くの企業で組織と役職に基づいたIDの付与がなされている。「経理部のメンバー全員が経理システムにアクセスできる」といったケースである。

　おそらくID管理システムの仕様・設定では、「経理部」ということを組織名ではなく、その組織コードから判断しているだろう。もし、この組織コードが、人事システムなどで誤って変更されてID管理システムに投入されれば、当然のように「経理部のメンバー＝0人」という事態が発生し、結果、経理システムのIDが削除されてしまうということになる。

　「まさか、そんなことはないだろう」と思われるかもしれないが、もともと人事システムは人事、給与の管理を目的に運用されており、組織コードが誤って変わってしまっても、人事システム上は問題なく使えるということはありえるのである。また、そのような人的ミスが原因ではなく、意図的な変更でもこれは起こりうる。「組織コードの使い回し」がそれに当たる。

　4月や10月など大規模な組織変更・人事異動がなされるタイミングでは、下図のような「組織コードの使い回し」が発生する場合がある。

	旧	新
組織コード／名称	A0002／経理部 A0004／法務部	A0002／法務部 A0003／経理部

　組織コードの設計は、システム構築時の組織階層モデルに沿って作られている。当時より階層が増えたり、組織数が増えたりしたなどの理由でけた数を増やしたい場合もあるだろう。しかし同じコードを別のホストコンピュータでも使用しており、簡単にはけた数を増やせない、というような企業は多い。

　上の図のようなデータが、ID管理システムに投入されると、組織名ではなく組織コードで判断するため、「経理部は引き続き存在するが、メンバーが総入れ替えになった」と判断されてしまう。結果、経理システムには、新・法務部のメンバーが追加され、旧・経理部のメンバーが削除されることになる。

　「組織コードに加えて、組織名で判断する」という手法も難しいことがお分かりいただけるだろう。例えば、「組織コード：001、組織名：第一営業部」が「組織コード：001、組織名：営業一部」という変更（名称変更）がなされた場合、人間であれば、きっと同じ組織なのだろうと想像できるが、システムはこれを判断できない。このようにミスではなくとも、システムの限界が事故の温床となる。

　事故の例2：想定外のID付与

【システムの想定外の動作で、期待しないユーザーにIDが付与（あるいは削除）されてしまった。】

　この事例は単純なミスであるが、これもあり得ないことではない。組織に限らずとも、従業員データの属性を判断基準に、システムのIDを発行するケースもあるだろう。

　例えば、「社員区分が正社員であれば自動的にメールアドレスが発行され、メールシステムへの登録、メールボックスの作成がなされる（派遣社員などは申請による）」などといったケースである。

　社員区分のような判断基準であれば、あまりミスは起こりにくい。しかし「ある従業員属性に基づき、ファイルサーバのアクセス権を決定している」というような場合、ID管理システムにてそのように定義されていることを知らずに、緊急のユーザー追加などで「ここの値はとりあえずNULLにしておこう」などという操作をした結果、アクセス権が予期せず発行されてしまうようなことが起こる。

　これは、「安易にオペレーションするのが悪い」という見方もあるが、プロビジョニング先が多岐にわたる場合や、さまざまなポリシーが定義されているような場合、オペレーションをする担当者の注意力に依存するような状態は望ましいものではない。

2/3

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

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

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