Select Identityは、効率的なIDライフサイクル管理を実現するパッケージソフトウェアです。ではIDライフサイクル管理とはどういったことを行うのでしょうか?
企業の内部統制強化が叫ばれる昨今では、多くの企業で、インフラのIT化が確実に進んでいます。かつては紙ベースで手渡されていた給与明細が、今ではWebベースで各自が閲覧したり、各部門のデータや情報をWeb上で掲載して共有している企業もあるかと思います。
このように高度なIT化が進んだ企業においては、これまで社員を一意に特定する手段であったFace to faceの識別や書類を介した識別は、その多くが通信上でのやりとりに置き換わり、その人のアクセスはコンピュータ上の代理物である”ID”と共に識別されるようになります。そして、正しいIDを伴うアクセスに対してのみ正しい権限が付与される必要があるのです。
つまり、IDライフサイクル管理とは、企業内のこのような何百何千というIDを過不足なく管理し、必要な人に必要なIDを正しく払い出し、適切な閲覧権限、適切な実行権限を付与し、不要になった権限は剥奪する、または不要になったIDは休止する、削除するという一連の活動を指します。例えば、財務報告を算出するITシステムにIDライフサイクル管理が施されていなければならないのは火を見るより明らかです。
ただ、「それは分かっているけど、中々効率よくそれを実現できなくてね。」とおっしゃられるIT管理者もいらっしゃるでしょう。そこでお勧めなのがSelect Identityで実現するEntitle Managementです。
Select Identityでは、従来用いられてきた、権限を定義した役割(role)を作成し、その役割をIDに直接付与するというRule & Roleベースの管理は行いません。運用が長期に亘ると役割とIDの紐付け管理が煩雑になり、いずれ活動が破綻する恐れがあるからです。
Select Identityでは権限(Entitle)が払い出されるべき対象はIDではなく、実はID(人)が持つ何らかの側面属性であることに着目し、これを管理する論理設計が成されています。例えば、ある研究結果の閲覧権限は、実は個人(ID)に払い出されているのではなく、個人の所属部署(研究所勤務)という側面属性に払い出されているという発想です。
これをシステム的に見ていくと、社内情報共有のWebシステムにあるそれぞれのページ(営業用、総務用、人事用、研究所用)にアクセスできるグループ(Sales-G、Admin-G、HR-G、LAB-G)を作成し、リソース(Unix OS、ディレクトリサーバ…)上に配置し、そして所属を表す属性(department)を定義して属性値の候補(Sales、Admin、HR、LAB)を決めます。リソースのこれらのグループはSelect IdentityからEntitlement(権限)として参照可能なので、これら全てを一括りのサービス(Web閲覧サービス)と定義します。
後は特定の属性値を持った人、例えば太郎さん(ID=taro)がこのサービスに参加させれば、その属性値(LAB)により自動的にOS上のLAB-Gにtaroが加わり、その結果として研究所用Webページにアクセスできる仕組みになっています。太郎さんが営業部に異動して属性値がSalesに変われば、自動的に研究所用のWebページの閲覧は不可能になり、代わりに営業用のWebページの閲覧が可能になります。

≫拡大画像(新規Window)
更にSelect Identityでは、サービスの定義の一環として、適切な管理ユーザの承認無しには実際の値の反映を実行させないようなワークフロー・テンプレートや、人事DBからの自動データ反映を行わせる機能、分単位の粒度で時間を指定しその間だけEntitleを払い出すような運用機能も提供されているので、一から全てを定義・設定する必要はなく、現在のアクセスを見渡し交通整理をして、適切なサービス設計を行えば長期に亘って効率的なEntitle Managementが実現できます。 |