ID管理のシステム構築はなぜ難しいのか：今、見直されるアイデンティティ管理（2/3 ページ）

[�ﾔ嶋秀規、岡本孝，ITmedia]

ビジネスロジックから要求される属性情報と権限コントロール

　部署、役職などの属性情報を検討する上で、近い将来導入が見込まれるシステムがあれば、そのシステムで必要となる属性情報も考慮しておくべきである。DBやIDMの構造として将来的なシステムも考慮しておかないと、システム拡張時に反映されない属性情報を個別に入力申請するなどの対応作業が発生してしまう。

　また、この属性情報の持ち方や職務の兼務に対するルールを設計にうまく反映しなければ、その企業のビジネスロジックに沿ったIDMシステムは構築できない。所属部署も属性情報の一部であるが、例えば、図1のようなA社のグループ企業であるB社からA社に出向した社員の所属部署について考えてみる。

図1●2つの所属部署情報を持つユーザーの管理

　ここで権限コントロールを部署や役職のグループで行うと考えると、出向した社員は、本籍としての表示上の所属である「B-b」と権限上の所属となる「A-a」の、2つの所属部署を持つこととなる。すると当然、IDM上ではこの社員に対する「A-a」「B-b」2つの所属部署を使い分けるルールが必要となる。このようなケースはまれだが、関連会社のシステムまでをIDMの対象とする場合は、十分考えられるものだ。

　そのほかの例として、営業部の担当者が業務上、経理システムへのアクセスが必要となるような場合には、経理システムに直接アカウントを作成するか、担当者の属性情報に本来所属している営業部とは別に経理部の部署を追加することで、アクセスが可能となる。本来の所属という意味では兼務ではないが、システムの利用を考えたときには複数の部署に所属する兼務となる。こうした情報は、人事を基にする正規の兼務とは別にIDMで管理されなくてはならない。

　次に、権限コントロールやロール（役割）を設計する上で必要となるのが、職務分掌の把握だ。この職務分掌は、内部統制においても重要な要素となっているが、国内の企業ではお互いの役割を重複させながら業務を進めるという一見あいまいな業務フローに慣れているため、職務分掌を明確化しにくいケースが多い。

　職務分掌とは、「誰がどのシステムに対してデータ入力や申請を行い、その申請を承認できる人はどの権限を持つのか」というアクセスコントロールのことである。そして、部署、役職、職位レベルやプロパーかどうかといった属性情報を基にロジックを反映したものがロールとなる。

　職務が組織や役職に単純にはひも付かない、あるいは非常に複雑なロジックで計算されなければならない場合、任意に権限が適用される場合には、ロールが適用できず、アクセス要求を手動エントリーで行い、それを人間系で判断することになってしまう。属性情報の反映やロール設計に関しては、企業が固有に持つビジネスロジックをどこまでIDM上で実現できるかが重要となる。