アクセス管理は、それ自体で独立・完結するプロセスではなく、他のプロセスや機能と常に連携して動く関係にあるものです。

したがって、アクセス管理プロセスのトリガーは様々です。サービスデスク（機能）からの依頼が起点になる場合もあれば、人事部からの変更依頼・・・すなわち、変更管理プロセスからの依頼が起点になる場合もあります。

また、管理対象はあくまでもアクセス権限そのものであって、その結果、ユーザがどのようなサービスを利用できるべきかどうかまでを関知あるいは決定するものではありません。この部分は情報セキュリティ管理プロセスが担います。
 

【図：アクセス管理を取り巻く関連プロセスの一例】 

※上記に記載したプロセスはあくまで例であり、状況によりほかにも関連するプロセスが存在します。

上図で示したとおり、アクセス管理は様々なプロセスと連携しつつ、大きく次に示す5つのステップで実施していきます。

(1) アクセス要求
人事関連の変更(採用、昇格、異動、退職など)ユーザに何等かの変更があった場合にアクセス要求のトリガーが発生します。

(2) 検証
次にアクセス要求が妥当なものか、適切な管理者により承認されたものかを検証します。どのユーザを登録していいか、またどこまでの権限をもたせるかは、サービスデザインの情報セキュリティ管理プロセスにて事前に決定されたプロセスに従うことになります。

(3) ID・権限の付与
承認されたアクセス要求をもとに、IDとアクセス権限を付与します。あらかじめ部門や役職ごとに必要なITサービスのIDと権限の紐付けを行なっておくことで、ID・権限付与に伴う作業負荷を軽減することができます。

(4) 監視（モニタリング）
一般的に、組織やこれを構成する人員の役割は頻繁に変わります。アクセス管理では、こうした変化に対する監視を行います。変更があった場合に速やかにアクセス権限の変更や削除がなされているか、その変更は正しく実施されているかを確認します。

(5) ログの取得と追跡
付与したアクセス権限が適正に利用されていることを確認します。必要に応じて、特定IDのアクセス状況の詳細を追跡し、不正なアクセスや操作を行っていないかを検証します。

アクセス管理はITIL V3になり、新規に追加されたプロセスです。V2が発行されたのが2000年から2001年にかけて、V3が発行されたのが2007年ですから、この間にアクセス管理が重要視されるにいたる要因が多々あったことは容易に推測できます。

実際に例を挙げてみましょう。

【図２：不正アクセスにより事件となった事例】
このようにITIL V3の1プロセスとして取り上げられるようになった背景には、ずさんなアクセス管理に起因した情報漏洩事故が多発したためと思われます。

ちなみに、こうした一連の事故の余波は2006年6月に施行となった金融商品取引法(JSOX法)にも及んでいます。JSOX法では、本番環境へのアクセスを制限するために開発と運用を明かうに分離することを求めており、IDの重複利用など情報漏洩の抜け道となる要点箇所を適切に管理することを求めています。

いずれにしても、昨今の情勢からもアクセス管理は重要度を増しており、時期バージョンではさらなる改善が図られることでしょう。

最後に、アクセス管理が有効に機能しているかどうかを具体的かつ客観的に測るKPI(重要業績評価指標）」をご紹介します。以下のような項目を評価することによってアクセス管理プロセスのサービスへの貢献度合いを確認でき、改善につなげることができます。

• アクセスの要求数（サービス、ＲＦＣなど）
• サービス、ユーザ、部門ごとに付与されたアクセス権の事例数
• アクセス権のメリットが必要となったインシデントの数
• 不正なアクセス設定によって発生したインシデントの数