LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてID管理基盤の開発・運用を受託

滞留する権限——アクセス権が「盛られていく」構造的な課題

社員が入社し、異動を重ね、やがて退職していく。その過程で付与されたアクセス権は、意識的に整理しないかぎり積み上がっていきます。プロジェクトのたびに追加された共有フォルダやSaaSの権限が、担当を外れた後も残り続ける、という状況は珍しくありません。

過剰なアクセス権は、そのままセキュリティ上のリスクになります。Microsoftは、過剰なアクセス権限が侵害につながり得ること、そして統制の欠如を示す監査指摘の原因にもなり得ることを指摘しています^*2。付与のプロセスはあっても、剥奪(はくだつ)のプロセスが弱いと、権限は片方向に膨らむだけになりがちです。

この非対称を正すには、「誰に、どのリソースへの、どんな権限を持たせるべきか」を組織として継続的に見直す仕組みが要ります。個々の管理者の善意や記憶に頼る運用では、規模が大きくなるほど破綻します。ここで登場するのが、本稿で扱うIGA(アイデンティティガバナンス管理)という統制のレイヤーです。まずはIDが組織の中を流れていく様子を、下の図で確認しましょう。

この図のとおり、IDは付与されたら終わりではなく、異動での見直しや定期的な棚卸し、退職での剥奪、そして監査までが一連の流れとしてつながります。IGAは、この流れ全体を統制の対象として扱う考え方だといえるでしょう。以降の章で、その中身を具体的に見ていきます。

IGA(アイデンティティガバナンス管理)とは、IDとアクセス権を統制する仕組み

IGA(Identity Governance and Administration。アイデンティティガバナンス管理)とは、組織内のIDと、そのIDが持つアクセス権を、ライフサイクルを通じて統制する仕組みの総称です。Microsoftは自社のガバナンス製品について、適切な人が適切なリソースへ適切なアクセスを持つ状態を自動的に確保するものだと説明しています^*1。

この統制が答えるべき問いは、4つに整理されています。すなわち「どのIDがどのリソースにアクセスすべきか」「それらのIDはそのアクセスで何をしているか」「アクセスを管理する組織的な統制が備わっているか」「その統制が有効に働いていることを監査人が検証できるか」の4点です^*1。この4つは、単なる技術要件ではなく、内部統制や監査対応の要件そのものにあたります。

IGAが土台に置くのが、IDライフサイクル管理です。Microsoftは、IDライフサイクル管理をアイデンティティガバナンスの基礎(foundation)と位置づけています^*1。多くの組織では、社員のIDは人事(HR)システム上の情報と結びついており、入社の signal を受けて自動でIDを作り、退職時にはIDとアクセスを遅滞なく取り除く運用が求められます^*1。

設計思想の背骨にあるのは、最小権限(least privilege)の原則です。NISTは最小権限を、利用者(や利用者に代わって動くプロセス)のアクセス権限を、割り当てられた業務の遂行に必要な最小限に制限するというセキュリティ原則だと定義しています^*6。IGAは、この原則を組織の規模で継続的に実現するための運用基盤だと捉えると、位置づけが明確になります。

認証基盤(IDaaS)・特権ID管理(PAM)との役割分担

IGAは、しばしば認証基盤(IDaaS)や特権ID管理(PAM)と混同されます。いずれもIDとアクセスに関わる仕組みですが、担うレイヤーは別物です。ここを曖昧にしたまま製品選定に進むと、機能の重複や抜け漏れが起きやすくなります。

IDaaS(認証基盤)との違い——「ログインさせる」層か「妥当性を統制する」層か

IDaaSが担う中心はAuthN(認証)、つまり「本人であることを確かめてログインさせる」処理です。シングルサインオン(SSO)や多要素認証(MFA)がその代表例にあたります。Microsoftのガバナンス基盤でも、利用者がアプリにサインインする際には条件付きアクセス(Conditional Access)のポリシーが評価され、利用規約への同意などを求められます^*1。

一方でIGAが問うのは、そもそも「その人がその権限を持つべきか」という妥当性です。認証は入口で本人を確認する仕組みであり、IGAは入口の手前で誰にどの鍵を渡すべきかを決め、渡した鍵を定期的に回収・点検する仕組みだといえます。認証が強固でも、渡すべきでない権限が渡ったままなら統制は効かないのです。両者は競合ではなく、補完の関係にあります。

PAM(特権ID管理)との違い——全ユーザーの統制か、特権アカウントの利用制御か

PAM(特権ID管理)は、管理者権限のような強い権限に絞って、その利用を制御する仕組みです。Microsoftは、特権アクセスの統制を現代のアイデンティティガバナンスの重要な一部と位置づけ、Privileged Identity Management(PIM)が just-in-time(必要なときだけ有効化する)アクセスやロール変更のアラートといった制御を提供すると説明しています^*1。

つまりPAMは、IGAという広い統制のなかで、とりわけ悪用リスクの高い特権アカウントに焦点を当てた層だと整理できます。IGAが全ユーザーのIDとアクセス権のライフサイクルを対象にするのに対し、PAMは特権の「いつ・誰が・どう使ったか」を厳しく制御します。なお特権ロールの割り当ても、定期的なアクセスレビューによる再認証の対象になります^*1。役割分担を表に整理しておきましょう。

IGAを構成する5つの機能要素

IGAは単一の機能ではなく、複数の機能要素の組み合わせで成り立ちます。ここでは代表的な5つの要素を、公式ドキュメントの記述に沿って整理します。自社に必要な要件を洗い出す際の、チェックリストとして使ってください。

1. IDライフサイクル管理——入退社・異動のプロビジョニング／デプロビジョニング

最初の要素は、入社・異動・退職に合わせてIDとアクセスを自動で整える仕組みです。Microsoftは、この3つの局面を「Joiner(参加)」「Mover(異動)」「Leaver(離脱)」と呼び、ライフサイクルワークフローで自動化できると説明しています^*3。入社時には初日から必要なアクセスがそろい、退職時には遅滞なくアクセスが取り消される状態が理想です^*3。

人事システムを起点にIDを生成する連携(プロビジョニング)と、退職時にアカウントを無効化・削除する処理(デプロビジョニング)が、この要素の両輪になります^*1。手作業に依存すると、退職者のアカウントが残る、いわゆる「幽霊アカウント」が生まれやすくなる点に注意が必要でしょう。

2. アクセスレビュー——アクセス権の棚卸しと定期的な再認証

2つ目は、付与済みのアクセス権を定期的に見直す棚卸し(アクセスレビュー)です。Microsoftは、アクセスレビューをグループのメンバーシップ、エンタープライズアプリへのアクセス、ロールの割り当てを効率的に管理する仕組みだと説明しています^*2。適切な人だけがアクセスを持ち続けている状態を、定期的に確認するのが狙いです^*2。

レビューは週次・月次・四半期・年次といった頻度で繰り返し実施でき、開始時にレビュー担当者へ通知が届きます^*2。特に管理者ロールの割り当ては、棚卸しの重点対象になります^*2。この定期的な再認証(recertification)こそ、権限の片方向の膨張を食い止める要の機能だといえます。

3. 職務分掌(SoD)違反の検知——両立してはいけない権限を防ぐ

3つ目は、職務分掌(SoD。Separation of Duties)違反を防ぐ検知の仕組みです。NISTはSoDを、いかなる利用者にも単独でシステムを悪用できるほどの権限を与えるべきではない、という原則として説明しています^*5。給与を承認する人が、同じ給与を作成することもできてはならない、という例が挙げられています^*5。

これを技術的に担保する例が、エンタイトルメント管理の「両立しないアクセス」設定です。Microsoftの仕組みでは、あるアクセスパッケージやセキュリティグループを既に持つ利用者が、別のアクセスパッケージを要求できないように構成できます^*4。たとえば「西日本営業」と「東日本営業」を同時に持てないよう、互いを両立しない関係として設定する運用が可能です^*4。こうしたルールで、危険な権限の組み合わせを申請の段階でブロックできます。

4. ロール設計と承認ワークフロー——申請と承認を制御する

4つ目は、誰がどうやってアクセスを申請し、誰が承認するかを設計する要素です。Microsoftのエンタイトルメント管理では、グループやチームのメンバーシップ、アプリのロールなどを「アクセスパッケージ」としてまとめ、その申請方法と承認の流れを定義できます^*1。たとえば、ある機密データへのアクセスには、上長・リソース所有者・セキュリティ担当者の承認を要求する、といった多段階の承認も組めます^*1。

属性の変化に応じて、アクセスを自動で付与・削除する運用も可能です。ライフサイクルワークフローやエンタイトルメント管理が、利用者をグループやアクセスパッケージへ自動で追加・削除し、アプリやリソースへのアクセスを更新します^*1。ロールを軸に権限を束ねておくと、個別に権限を付け外しする手間が減り、統制も効きやすくなります。

5. 監査証跡とレポート——統制が働いていることを証明する

最後の要素は、これらの統制が実際に機能していることを、後から検証できるようにする監査証跡です。前述の4つの問いのうち最後の1つは、統制が有効に働いていることを監査人が検証できるか、というものでした^*1。証跡が残っていなければ、この問いには答えられません。

ライフサイクルワークフローには履歴と監査ログがあり、入社・退職のプロセスの記録を追跡できます^*3。アクセスレビューは、ポリシーの例外を定期的に見直した証跡を監査人へ提示する用途にも使えます^*2。誰の権限を、いつ、誰が承認し、いつ棚卸ししたか。この一連の記録が、内部統制の説明責任を支える土台になります。

IGA基盤の開発を外注する際に確認したい要件

IGAの導入は、製品を入れれば完了するものではありません。自社の人事プロセスや既存のIDインフラに合わせた設計・連携の作り込みが必要です。外部パートナーへ委託する場合、次の5点を具体的に確認しておくと、後戻りを抑えやすくなります。

1. 人事(HR)システムとの連携

まず、入退社・異動の起点となる人事システムと、どう連携するかを確認します。多くの組織で、IDライフサイクルは人事システム上の従業員情報と結びついています^*1。委託先が、WorkdayやSuccessFactorsのようなHRソースからのプロビジョニングに対応した設計を示せるかが見極めどころです^*1。連携の設計が甘いと、退職者のアカウントが残る、といった統制の穴につながります。

2. 既存のIDaaS・PAMとの統合

次に、すでに導入済みの認証基盤(IDaaS)や特権ID管理(PAM)と、どう役割分担して統合するかです。IGAはこれらと競合するものではなく、統制のレイヤーとして重ねるものだと前述しました。委託先が、認証・特権・ガバナンスの各レイヤーの境界を理解したうえで、重複や抜け漏れのない設計を描けるかを確認しましょう。既存資産を活かす連携方式は、性能や運用負荷にも直結する要素です。

3. ロールとSoDルールの設計支援

三つ目は、ロール設計と職務分掌(SoD)ルールの設計を支援できるかどうかです。両立してはいけない権限の組み合わせは、業務を深く理解していないと洗い出せません^*4*5。委託先が、現行の業務プロセスをヒアリングしながらロールとSoDルールの初期設計を支援できるかは、選定の分かれ目になります。技術的な実装だけでなく、業務側の整理に踏み込めるかが問われます。

4. 監査要件・レポートへの対応

四つ目は、自社が受ける監査の要件に、証跡とレポートで応えられるかです。アクセスレビューの記録やワークフローの監査ログを、監査人が求める形で出力できるかを確認します^*2*3。監査対応で必要になる項目は業種や制度で異なるため、どのレポートを、どの粒度で残すべきかを、契約前にすり合わせておくとよいでしょう。

5. 内製移管のしやすさ

五つ目は、将来自社で運用を引き取れるかという観点です。ロール定義やSoDルール、ワークフローの構成がドキュメント化されていないと、委託先への依存が続きます。設計思想と設定内容が整理されているか、運用手順が引き継げる形で残るかを確認しておくとよいでしょう。属人的な作り込みは、統制の継続性そのものを損ないかねません。

まとめ：IGA導入で押さえる3つの判断軸

本稿では、IGA(アイデンティティガバナンス管理)の位置づけと機能要素を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、IGAはIDライフサイクル管理とアクセス権の統制を担う層であり、ログインを担う認証基盤(IDaaS)や、特権に絞ったPAMとは役割が異なります^*1。第二に、機能の中心はプロビジョニング／デプロビジョニング・アクセス権の棚卸し・SoD違反の検知・ロール設計と承認・監査証跡の5つに整理でき、これらが最小権限の原則を組織規模で支えます^*4*5*6。第三に、外注時は人事連携・既存基盤との統合・ロールとSoDの設計支援・監査対応・内製移管のしやすさが確認の軸になります^*2*3。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Microsoft「What is Microsoft Entra ID Governance?」（Microsoft Learn）（https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview）
2. *2　出典：Microsoft「What are access reviews?」（Microsoft Entra ID Governance、Microsoft Learn）（https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview）
3. *3　出典：Microsoft「What are lifecycle workflows?」（Microsoft Entra ID Governance、Microsoft Learn）（https://learn.microsoft.com/en-us/entra/id-governance/what-are-lifecycle-workflows）
4. *4　出典：Microsoft「Configure separation of duties for an access package in entitlement management」（Microsoft Entra ID Governance、Microsoft Learn）（https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-access-package-incompatible）
5. *5　出典：NIST「separation of duty (SOD)」（Computer Security Resource Center Glossary、出典元 NIST SP 800-192）（https://csrc.nist.gov/glossary/term/separation_of_duty）
6. *6　出典：NIST「least privilege」（Computer Security Resource Center Glossary）（https://csrc.nist.gov/glossary/term/least_privilege）

Tweet