Evolveumのドキュメントから学ぶ、ID管理・アクセス管理とIGAの要点

どうも おかしん です。

最近、IGAについてご相談を受けることが増えてきました。

入社、異動、退職のたびに、各サービスのアカウントや権限を手作業で変更するのは大変です。一方で、不要な権限が残っていないか、退職者や委託先のアクセスをちゃんと回収できているか、という心配もあります。

工数とセキュリティの両方から、ID管理をもう一段高度化したいというニーズが高まっているのだと思います。

というわけで、今回はIGAについてのお話です。ただ、IGAを理解するには、ID管理やIAMとの関係から押さえておきたいところです。

そこで、EvolveumのIdentity and Access Managementのドキュメントを参考に、基本から順に見ていきましょう。

EvolveumとmidPoint、そしてID管理の考え方

ところで皆さんEvolveumという会社をご存知ですか？

Evolveumは、オープンソースのID管理・ガバナンス製品midPointを開発している会社です。midPointは、人事システムや各アプリに分散するID情報をつなぎ、アカウントや権限の管理、業務上のポリシーの適用や見直しを支えるプラットフォームです。

同社は、製品の設定手順に加えて、ID管理の背景や考え方を学べる資料も公開しています。たとえばe-bookの『Practical Identity Management with MidPoint』は、IAMの基本概念から始まり、midPointの仕組みや設定へ進む構成で、HTML・PDF・EPUBで読めます。今回参照するIAMドキュメントにも、アクセス管理、企業のID管理、IGA、設計上の注意点などの説明があります。

私がこれらの資料に感じるのは、ID管理についての成熟した哲学です。技術的な機能と、業務上の判断、その後の運用までを、つながった問題として考えているところがよいと思います。その考え方は、次のように読み取れます。

ID管理には、技術と業務の両方が必要である。 同社のIGAの説明は、属性の同期やアカウント管理から、業務上のポリシーまでを扱っています。何を反映するかという技術の話と、なぜその権限を与えるかという業務の話を、同じ取り組みの中で考えます。

決めたルールと、実際の状態をつなぐ。 midPointの概要では、同期に際してロールやライフサイクル、対象システムとの整合性などを評価することが説明されています。さらに、ポリシー自体も変化するものとして扱われます。一度決めた設定を流し込み続けるだけでは、組織や業務の変化に追いつけません。

小さく始め、実務の効果を見ながら改善する。 同じmidPointの概要では、一般的な課題から着手し、反復して成果を積み上げる進め方が示されています。そのうえで、次のようにも書かれています。

The project may eventually reach a point where the effort outweighs the benefits.
日本語訳：いずれ、取り組みにかかる労力が、得られる効果を上回る段階に達することもあります。

原文は、その段階で立ち止まり、後で再開することも選択肢にしています。理想の機能をすべて揃えることより、組織にとって役立つ管理を続けることを重視している、と私は読みました。

もちろん、製品開発元としての視点は含まれます。それでも、こうした考え方はmidPointを使うかどうかにかかわらず、自社のIDと権限の管理を設計するうえで参考になります。この哲学を具体的に理解するため、ID管理・アクセス管理・IGAの役割と、それぞれが必要になる理由を見ていきましょう。

まず、IAMとIGAの関係を整理する

IAM（Identity and Access Management）は、IDとアクセスの管理を扱う広い概念です。その中で、IGA（Identity Governance and Administration）は、IDに関する情報の管理とガバナンスを扱う領域です。アカウントや権限を維持する処理に加え、業務上の必要性を判断し、実態を検証して、問題を是正するところまで扱います。

IGAをやるなら、権限を付ける基準や見直す責任者まで決めて、日々の業務で回していく必要があります。製品の導入も、その運用をどう支えるかという話です。

用語や機能の境界には製品間の違いもあります。ここではEvolveumの整理を出発点に、企業での運用へ読み替えて考えます。

ID管理は、人とアカウントと属性を対応づける

ある社員が、メール、営業支援、経費精算のサービスを使っているとします。会社から見ると同じ人ですが、各サービスにはそれぞれ別のアカウントがあります。管理者用に別アカウントを持っていれば、さらに増えます。

ID管理では、この人が誰で、どの組織に属し、どのアカウントや権限と結びついているかを扱います。対象は社員だけとは限りません。委託先の利用者や、処理を実行するアプリなども、管理対象を考えるときに含める必要があります。

EvolveumのEnterprise Identity and Access Managementでは、ID情報を保存する場所と、それを複数のシステム間で管理・同期する仕組みを分けて説明しています。利用者一覧を保管しているだけでは、各サービスの状態を揃えることはできません。

情報源を決め、同じ主体の情報をつなぐ

最初に必要なのは、どの情報をどこから得るかです。雇用状態や入退社日は人事システム、委託契約の有効期間は契約を管理する部門、アプリ連携の所有者はその業務を担う部門、というように考えます。

人事システムを使うとしても、全属性や全種類のIDの唯一の正とする必要はありません。情報ごとに責任を持つ場所を決めないと、更新内容が食い違ったときに判断できなくなります。

次に、各システムのアカウントが誰のものかを対応づけます。これが相関付けです。同姓同名、改姓、メールアドレスの変更などを考えると、表示名が一致するだけで同一人物と判断する運用は危ういでしょう。

属性の名前や値も、そのままでは揃いません。部署コードを別システムの部署名へ変換したり、雇用状態をアカウントの有効・無効へ対応させたりする、マッピングが必要になります。データをコピーする前に、その値が何を意味するかを決めるわけです。

作成・変更・停止を反映し、実態と照合する

必要なアカウントや権限を対象システムへ作成・反映する処理がプロビジョニング、不要になったアクセスを取り除く処理がデプロビジョニングです。入社時の作成だけでなく、異動や契約終了などの変更も対象になります。

EvolveumのIGAの機能整理では、変更を反映する機能と、接続先の情報を継続的に揃える同期の機能を区別しています。変更を送信できたことと、その後も正しい状態が続いていることは、別の確認だからです。

APIの処理が失敗することも、対象サービスの管理画面から直接権限が追加されることも考えられます。想定する状態と実際のアカウント・権限を取得して照合する、リコンシリエーションが必要になる理由です。

たとえば、異動で不要になった営業の閲覧権限を回収する場合、アプリから取得した権限が「なし」になったことを確かめて完了にします。

退職時も、IdP（認証を提供する基盤）側で退職者のアカウントを停止しただけで、全サービスへの対応が終わったとは判断できません。アプリのローカルアカウント、既存のセッション、トークンについて、それぞれの仕組みに応じた停止・失効と確認が必要です。一方、業務記録の保持や引き継ぎもあるので、すべてを即座に削除することが正解とも限りません。Microsoftのアクセス失効の説明も、認証基盤とアプリ側のセッションを分けて扱っています。

ID管理でアクセスの前提となる状態を維持し、アクセス管理やアプリがその情報を使って利用を制御する。この接続が次の話です。

アクセス管理は、アクセス時の認証と認可を扱う

アクセス管理（Access Management、AM）は、システムを利用するときのアクセスを制御します。

認証は、アクセスしてきた主体が誰かを確かめることです。認可は、その主体に何を許すかを判断することです。本人だと確認できても、全社の給与データを見てよいとは限りません。

SSOやフェデレーションは、複数のサービスで認証を連携するための仕組みです。セッション管理は、認証後の利用をいつまで続けさせ、どの条件で終了させるかを扱います。退職時の既存セッションの失効も、この観点で確認します。

ただし、アクセス管理の仕組みだけでアプリ内の細かな認可まで完結するとは限りません。たとえば営業支援システムで、どの顧客情報を閲覧できるか、誰がエクスポートできるかは、アプリ側の権限と認可処理にも依存します。

EvolveumのEnterprise Identity and Access Management「Practical Access Management」では、次のように説明されています。

Therefore applications must very often implement their own additional authorization mechanisms.
日本語訳：そのため、多くの場合、アプリケーション側にも独自の追加の認可の仕組みを実装する必要があります。

ログイン時の連携だけでは、変更を届けきれない

SSOのログイン時に、利用者の属性をアプリへ渡し、アカウントを作成・更新できる構成があります。これで必要な管理をすべて行えるでしょうか。

退職後、その人がもうログインしなければ、ログイン時の処理は動きません。アカウント停止や権限の回収を、その人の次回アクセスに依存させることはできないわけです。

EvolveumのAccess Management and Provisioningは、利用者のアクセスに合わせてプロファイルを同期する方式について、次のように説明しています。

The updates are always bound to user accessing the system (hence "access management").
日本語訳：更新は常に、利用者がシステムにアクセスすることに結びついています（そのため「アクセス管理」と呼ばれます）。

この方式では、アクセスしなくなった利用者の変更を届けられません。ID管理側のプロビジョニングは、ログインを待たずに状態の変更を対象システムへ伝えるために使います。もちろん、伝播の遅延や失敗もあるので、反映の確認まで必要です。

弊社ブログのSSOとSCIMを含めたサービス選定の考え方も、この違いに関係します。ログインの連携と、アカウントのライフサイクルを管理する連携を、それぞれ確認する必要があります。

IGAは、IDと権限の管理に業務上の判断と責任を加える

ここまでで、ID管理はアカウントや属性、権限の状態を維持・反映し、アクセス管理はそれらを使ってアクセス時の制御を行う、という関係が見えてきました。

では、反映する権限が適切かどうかは、誰がどう判断するのでしょうか。

EvolveumのIdentity Governance and Administrationでは、IGAをID管理とIDガバナンスなどを含む領域として整理しています。ID管理の技術的な処理に、業務上のポリシーやその検証を組み合わせる形です。

同じIGAの説明には、認可との関係が明記されています。

IGA is not directly concerned with authorization either, although management of entitlements that influence authorization is part of IGA.
日本語訳：IGAは認可そのものにも直接関与しません。ただし、認可に影響する権限の管理はIGAの一部です。

認可に使う権限やポリシーを管理することと、アクセス時にそれを評価・強制することは、役割が違います。認証もアクセス管理の役割であり、IGAがアクセス管理を置き換える、という関係ではありません。

ID管理にも承認やポリシーの機能はありますし、実装上の境界には重なりがあります。これらの役割ごとに別々の製品を購入する、という意味ではありません。

なぜ申請、棚卸し、監査まで必要になるのか

権限の反映を自動化できても、元のルールが「異動時には新しい部署の権限を追加するだけ」なら、旧部署の権限は残り続けます。自動化が正確に動いていても、業務上は過剰なアクセスになり得ます。

そこで、誰に何を許すか、その判断を誰が引き受けるか、いつ見直すかが必要になります。Evolveumが挙げるIGAの機能を、企業の運用へ読み替えると、次のように整理できます。

承認ボタンが押されたことだけでは、適切な権限管理の証拠にはなりません。何を見て承認したのか、承認した内容が反映されたのか、不要と判断した権限が実際に回収されたのかが問われます。

権限の妥当性を判断することと、その判断が実態に反映されていることを、つなげて管理する。 ID管理の処理にこの視点を加えると、IGAが必要になる理由が分かりやすくなります。

異動する社員を、架空の例で考える

営業部の社員が、経理部へ異動するとします。営業の案件引き継ぎのため、営業支援システムを一定期間だけ使い続ける必要があります。

ID管理では、部署の属性を更新し、決められた経理の権限を反映します。アクセス管理と各アプリは、その状態を使ってログインや操作を許可・拒否します。

IGAのうちガバナンスの観点では、さらに判断が必要です。営業支援の権限をどこまで残すのか。引き継ぎの終了は誰が確認するのか。例外の期限が来たら、誰が権限を回収するのか。経理の新しい権限と組み合わせて、職務分離に反しないか。

EvolveumのJoiner–Mover–Leaverの説明も、異動時の古い権限の残存や兼務などを扱っています。部署名を書き換えただけで異動対応を完了扱いにすると、こうした業務上の判断が抜けます。

この例なら、引き継ぎに必要な閲覧範囲を決め、期限と責任者を記録し、期限後に対象システムの実態を確認する。自動でも手動でも、ここまでつながっていることが大切です。

インシデントから、管理対象の広さを考える

IDや権限の問題は、社員のログインだけには収まりません。2024〜2025年に公表された事例から、管理対象を考えてみます。

以下の事例で、被害組織がIGAを実施していなかったと断定できるわけではありません。確認できる攻撃経路と、そこから企業の管理に生かせる考え方を分けて扱います。

Microsoft：テスト環境とOAuthアプリの権限も対象になる

Microsoftが2024年1月に公表したMidnight Blizzardの事例では、攻撃者は2023年11月に、MFAが設定されていない古い非本番テストテナントのアカウントを侵害しました。Microsoftの分析では、初期侵害を足がかりに悪用された古いテスト用OAuthアプリが、企業環境への高いアクセス権を持っていたことも説明されています。

ここには、認証の保護と、アプリに与えたアクセス権の管理という、両方の論点があります。MFAは必要な対策ですが、それだけでアプリの権限の必要性まで判断してくれるわけではありません。

企業の運用へ引き寄せるなら、テスト用アカウントや古い連携にも、所有者と利用目的を持たせる必要があります。本番環境へ届く権限がないか、使わなくなった主体が残っていないかも確認対象です。社員一覧だけを棚卸ししていては、こうしたアクセスを見落とす可能性があります。

Salesloft Drift：第三者連携への権限委任も管理する

2025年8月下旬に公表されたSalesloft Driftを経由したデータ窃取の分析では、攻撃者がDrift連携のOAuthトークンを使い、顧客のSalesforce環境などへアクセスしたことが報告されています。後続の調査や対応はSalesloftの公式情報でも公表されています。

これは、利用者本人がログインする経路とは別に、連携サービスへ委ねたアクセスが存在する、という話でもあります。ここでは初期侵入の詳細よりも、企業側が何を管理対象に含めるかに注目します。

ある業務のために連携を許可したなら、目的、許可したデータや操作、責任者、廃止時の失効方法を確認できる状態にしておきたいところです。単に「このSaaSを使っている」という契約台帳だけでは、委ねた権限までは分かりません。

連携停止やトークンの失効と、すでに窃取されたデータへの対応も別です。分析では、窃取したデータ内の資格情報を探す活動も報告されています。露出した秘密情報があれば、その失効や更新も対応の対象になります。

IGAの取り組みは、不要なアクセスの削減や管理対象の把握、回収の実行に役立ちます。ただし、これらの事故をIGAだけで防げたとは言えません。認証の保護、連携先の安全性、検知、インシデント対応も必要です。

企業で実装するなら、重要業務から是正まで回す

ここからは、概念を企業の運用へ落とすための私の整理です。最初から全システムを一度に揃えるより、重要な業務とデータを選び、そのアクセスを管理できるか確かめるところから始めるのがよいと考えます。

たとえば顧客データを扱う営業業務なら、社員だけでなく、委託先、管理者用アカウント、データを読み出す連携も対象にします。誰が何にアクセスでき、その権限はどの業務のために必要なのか。これを対象システムの実態と対応づけます。

必要性を判断する人と、反映・回収する人を決める

情シスだけで、すべての権限の業務上の必要性を判断するのは難しいでしょう。責任分担は、たとえば次のように設計できます。

• 業務責任者は、誰がどのデータや操作を必要とするかを判断する。
• 情シスは、その判断を各システムへ反映し、変更や回収が完了したかを確認する。
• 情報セキュリティの担当者は、特権や職務分離などの基準を定め、違反や管理から漏れたアクセスを検証する。
• 通常の基準を超える例外は、リスクを受容できる権限を持つ責任者が判断する。影響が大きい場合は経営の判断につなぐ。

小規模な企業では兼務もあると思います。それでも、強い権限を自分で申請し、自分だけで承認する、といった状態は避けたいところです。役職名を揃えるより、判断と実行、例外の引き受け先を明確にすることを優先します。

変更のきっかけと、失敗時の扱いを決める

入社、異動、退職、契約終了、連携の廃止などを、アカウントと権限を見直すきっかけにします。どの情報を受けたら何を変更するか、いつまでに反映するかを決めます。

例外には理由、承認者、期限を持たせます。期限を迎えた後の回収や再承認も、担当者が分かる状態にします。処理に失敗したとき、誰へ通知し、どう再処理するかも運用の一部です。

そして、申請台帳だけでなく対象システムからアカウントや権限を取得して、決めた状態との差を確認します。不要な権限を見つけたら回収し、その結果を確認するまで追います。

レビューの頻度や反映期限は、全システムで一律にする必要はありません。特権、機密データへのアクセス、停止の遅れが業務へ与える影響などで優先順位を決めます。定期レビューに加え、異動や連携廃止などの変化を捉えて見直す設計が必要です。

自動化する範囲は、管理の複雑さに合わせる

少数のシステムなら、台帳と申請チケット、対象システムからの一覧取得を組み合わせた手動運用で始めることもできます。ただし、記録があるだけでなく、更新と確認を続けられることが条件です。

人数や権限、変更件数が増えて手動では追えなくなれば、自動化の価値が高まります。その段階で、プロビジョニング連携やIGA製品が、実態の取得、ポリシー評価、承認、失敗時の再処理、監査にどこまで対応するかを確認します。

SCIM（システム間でID情報を管理するための標準）の仕様や対応範囲も確認します。SCIMに対応しているという表示だけで、アプリ内の全権限や既存トークンまで回収できると判断せず、対象ごとの変更・失効の範囲を確かめます。自動化する仕組み自体も強い権限を持つので、その管理アカウントや連携資格情報の保護が必要です。

運用が機能しているかは、たとえば、管理対象をどこまで把握できているか、回収期限を過ぎたものは何件あるか、所有者不明のアカウントや権限は残っているか、是正が完了するまでどれほどかかるかで確かめられます。チケットを閉じた時刻ではなく、対象システムで必要な変更を確認した時刻を完了とするのがポイントです。

まとめ

まずは、顧客データや機密情報を扱うサービスを一つ選び、実際のアカウントと権限の一覧を取得してみてください。業務責任者とその一覧を見て、何のために必要か説明できない権限や、異動・退職後も残っているアクセスを探すところから始められます。

見つかったものについて、残すか回収するかを判断する人と、変更を実行する人を決めます。残すなら理由を記録し、一時的な利用なら期限も決める。回収するなら、対象システムで権限が外れたことまで確認する。さらに、次の異動や退職でも同じ確認ができるよう、誰から通知を受け、誰が対応するかを決めておきます。

その作業を通じて、一覧の取得に手間がかかるのか、承認が滞るのか、権限の回収を追いきれないのかが分かります。IGA製品や自動化を検討するときも、そこで見つかった課題を解消できるかで選べます。