「IdPからAzureやGCPにSSOしたとき、権限ってどうやって割り当てるの？」と時間を溶かしてるAWSエンジニア（主に自分）へ
안녕하신게라！パナソニック コネクト株式会社クラウドソリューション部の加賀です。
前回の記事では、AWSのAssumeRoleを軸に、各クラウドのワークロードID（機械のID） の権限管理について比較しました。
今回はその続編として、「ユーザID（人間のID）」に焦点を当てます。
多くの企業では、OktaやMicrosoft Entra ID（以下Entra ID）といったIDプロバイダ（IdP）でユーザ情報を一元管理しています。そして、そのIdPを起点に各クラウドへシングルサインオン（SSO）するのが当たり前になりました。
しかし、ここで新たな疑問が湧いてきます。
「IdPの『AWS-Admins』グループに所属するユーザがAWSにログインすると、当然のように管理者権限が付与されている。このIdPのグループとクラウド上のロール（権限）の紐付けって、各クラウドでどう実現しているんでしたっけ？」
この「IdPの属性（グループなど）に基づく動的な権限付与」の仕組みこそが、セキュアで効率的なマルチクラウドID管理の要です。
この記事では、
- IdPと連携したクラウドのSSOの裏側を知りたい方
- AWS IAM Identity Centerの知識をベースに、GCP/AzureのIdP連携を理解したい方
- IdPのグループ情報を、各クラウドの権限にどうマッピングするのか具体的に知りたい方
に向けて、AWSのIAM Identity Centerを基準に、GCPとAzureでのIdP連携と権限マッピングの仕組みを、思想の違いから解説します。
先にこの記事の結論をまとめると、以下の3点となります。
- AWSは、IAM Identity Centerという専用ハブを介してIdPと連携。Permission Setを用いてIdPグループとAWSロールをマッピングする。
- GCPは、Workforce Identity Federationを利用。IdPの属性（グループ情報など）を直接GCPのロールの条件にマッピングする、より純粋なフェデレーションモデルを採用。
- Azureは、Entra ID自体がIdPであり、権限管理の基盤。外部IdPとの連携もEntra IDがハブとなり、Entra IDのグループを介してAzureロールを割り当てるのが基本。
それでは、各クラウドのID連携の旅に出かけましょう。
※この記事も概念的な理解を目的としており、詳細な設定手順には触れません。
【AWS】IAM Identity Center
まずは、多くのクラウド連携の基準となるAWSの仕組みから見ていきましょう。AWSでは、IdP連携のハブとしてIAM Identity Center (旧 AWS SSO)を利用するのが現在のベストプラクティスです。
権限管理の仕組み → Permission Setとプロビジョニング
IAM Identity Centerは、外部IdP（Okta, Entra IDなど）とAWSアカウント群の間に立ち、認証と権限割り当てを仲介します。この仕組みを理解する上で重要なのが、「Permission Set」と「プロビジョニング(SCIM)」です。
-
プロビジョニング (SCIM)
まず、IdPとIAM Identity CenterをSCIMというプロトコルで接続します。これにより、IdP上で作成されたユーザやグループの情報が、自動的にIAM Identity Center内に同期（コピー）されます。
この時点では、まだAWSアカウントへの権限はありません。単に「ユーザAがグループXに所属している」という情報がIdentity Centerに伝わっただけです。 -
Permission Set (権限セット)
次に、IAM Identity Centerで「Permission Set」を作成します。これは、IAMポリシーの集合体であり、IAM Identity Centerがこれを元に各アカウントへIAMロールを自動生成するためのテンプレートとして機能します。 -
割り当て (Assignment)
最後に、プロビジョニングされたグループ（例、IdPのAWS-Adminsグループ）に対して、作成したPermission Set（AdministratorAccessやReadOnlyAccess）を、利用させたいAWSアカウントに割り当てます。
この割り当てを行うと、IAM Identity Centerは裏側で、対象のAWSアカウント内にAWSReservedSSO-...(PermissionSet名)という名前のIAMロールを自動で作成・管理してくれます。
AWSの認証と権限付与のフロー
ユーザがSSOでAWSにアクセスする際のフローは以下のようになります。
- ユーザがIdPにログイン認証する。
- IdPはSAMLアサーション（認証情報と属性）をIAM Identity Centerに送る。
- IAM Identity Centerは、受け取ったユーザのグループ所属情報などに基づき、そのユーザにどのAWSアカウントのどのPermission Setが割り当てられているかを判断し、利用可能なロールの一覧を提示します。
- ユーザが利用したいロールを選択すると、IAM Identity CenterはAWS STSを利用してそのロールに対応する一時的な認証情報を生成し、ユーザを対象アカウントのマネジメントコンソールにシームレスにサインインさせます。これにより、ユーザは直接クレデンシャルを扱うことなくアクセスが可能になります。
この**「IdP → Identity Center（でグループと権限を紐付け）→ 各AWSアカウントのIAMロール」** という、間に専用ハブを挟むアーキテクチャがAWSの大きな特徴です。
【補足】属性ベースのアクセス制御 (ABAC) との連携
さらに、IAM Identity CenterではIdPからSAMLアサーションで送られてくる属性（部署、コストセンターなど）を、AWSセッションの「セッションタグ」として引き渡す設定が可能です。
このタグをIAMポリシーの条件（aws:PrincipalTag）で利用することで、「自分の所属部署のタグが付いたS3バケットしか操作できない」といった、より動的でスケーラブルな権限管理（ABAC）を実現できます。これは、Permission Setによる静的な権限割り当てを補完する強力な機能です。
【GCP】Workforce Identity Federation
GCPは、AWSとは少し異なるアプローチを取ります。その名もWorkforce Identity Federation（ワークフォース・アイデンティティ・フェデレーション）。この機能の最大の思想は「GCP内にユーザIDを複製しない」ことです。
Workforce vs Workload
GCPにはよく似た名前の「Workload Identity Federation」という機能もあります。こちらは前回の記事で触れた、GitHub Actionsのような外部システム（機械）がGCPにアクセスするための仕組みです。今回は人間（Workforce） のためのIdP連携である「Workforce Identity Federation」を解説します。
権限管理の仕組み → 属性マッピング
Workforce Identity Federationでは、SCIMによるユーザ同期は必須ではありません（もちろん、ユーザがコンソール上で誰なのかを分かりやすく表示する等、利便性の目的でSCIMプロビジョニングを併用することも可能です）。IdPから送られてくるSAMLアサーションやOIDCトークンに含まれる属性（Attribute）を直接利用して、動的に権限を付与します。
SCIMによる事前プロビジョニングとは異なり、認証時に必要な情報だけを使ってアクセスを許可する、いわばJust-In-Time (JIT) アクセスの考え方に近いモデルです。
-
Workforce Pool Provider
まず、外部IdPの情報をGCPに登録します。これが「Workforce Pool Provider」です。 -
属性マッピング (Attribute Mapping)
次に、IdPから送られてくる属性（例saml.groups）を、GCPが理解できる属性（例assertion.groups）にマッピングするルールを定義します。 -
IAMポリシーの条件 (Conditions)
最後に、プロジェクトやフォルダなどのリソースに対するIAMポリシーで、このマッピングされた属性を条件 (Condition) として使用します。
例えば、IAMポリシーを以下のように設定すると「my-poolというWorkforce Poolを利用するユーザの中で、groups属性にGCP-Adminsという値を含むユーザに対して、Ownerロールを付与する」という意味になります。
# IAMポリシーの例（抜粋）
bindings:
- role: roles/owner
members:
- principalSet://iam.googleapis.com/locations/global/workforcePools/my-pool/*
condition:
title: gcp-admins-group
expression: assertion.groups.contains('GCP-Admins')
これは、特定のユーザではなく「特定の属性を持つユーザの集合」をプリンシパルとして定義する、GCPならではの強力な機能です。
GCPの認証と権限付与のフロー
- ユーザがIdPにログイン認証する。
- IdPはSAMLアサーションをGCPに送る。
- GCP（Workforce Identity Federation）は、SAMLアサーション内のグループ情報などの属性を検証し、それを元にフェデレーショントークンを発行する。このトークンには、マッピングされたGCP用の属性情報が含まれる。
- ユーザはこのフェデレーショントークンを使い、GCPリソースにアクセスする。GCPのIAMは、リクエストの都度、トークン内の属性とIAMポリシーの条件を照合し、アクセスを許可/拒否する。
AWSがIdentity Centerにユーザ情報を同期するのに対し、GCPは認証のたびにIdPからの属性情報を信頼し、動的に権限を判断します。
これにより、GCP側にIDを持たない、より疎結合で純粋なフェデレーションが実現されています。
【Azure】「ID中心」の思想を貫く、Entra IDの世界
最後にAzureです。AWS/GCPのモデルに慣れたエンジニアが、その思想の違いに最も戸惑うのがこのAzureでしょう。「使いにくい」「なぜAssumeRoleがないんだ？」と感じる背景には、Azureの歴史と設計哲学が存在します。
その核心は、前回の記事でも触れた通り、ID基盤である Entra IDが、企業のオンプレミス環境で長年ID管理の中核を担ってきた Active Directory (AD) の思想を色濃く受け継いでいる点にあります。
AWSやGCPが「ステートレス」なWeb技術を前提にゼロからID管理を設計したのに対し、Azureは既に世界中の企業で利用されていたActive Directoryという「ステートフル」なID管理の巨大資産をクラウドに拡張する形で発展してきました。
そのため、AWS/GCPが「疎結合なフェデレーション」を志向するのに対し、Azureは「既存AD資産との親和性」と「Entra IDによる一元管理」を最優先する設計思想となっているのです。
権限管理の仕組み → Entra IDグループとロール割り当て
Azureでは、まずすべてのIDをEntra IDのオブジェクトとして表現することが大前提です。その上で、RBACの仕組みに則ってIDに権限を割り当てます。
-
フェデレーション設定とプロビジョニング (SCIM)
外部IdPを、Entra IDの「IDプロバイダ」として登録します（SAML/OIDCフェデレーション）。
同時に、SCIMを設定し、IdP上のユーザやグループをEntra IDに「メンバーユーザ」（または制限された「ゲストユーザ」）や「同期されたグループ」としてプロビジョニングします。これにより、外部IdPのIDがEntra IDのオブジェクトとして表現されます。 -
Entra ID グループへのロール割り当て
Azureの権限管理は、AWSのPermission SetやGCPのIAM Conditionとは異なり、非常にシンプルです。
プロビジョニングされたEntra ID上のグループ（例、IdPから同期されたAzure-Adminsグループ）に対して、Azureのサブスクリプションやリソースグループのスコープで、直接Azureロール（例共同作成者）を割り当てます。
つまり、「どのID（グループ）に、どの権限（ロール）を、どの範囲（スコープ）で与えるか」 というAzure RBACの基本モデルに、外部IdPから同期されたIDをそのまま当てはめるだけです。
Azureの認証と権限付与のフロー
- ユーザが（会社のポータルなどを通じて）Azureにアクセスしようとすると、Entra IDにリダイレクトされる。
- Entra IDはユーザが外部IdP管理下にあることを認識し、ユーザをIdPにリダイレクトする（フェデレーション）。
- ユーザがIdPで認証されると、IdPは認証情報をEntra IDに送り返す。
- Entra IDは認証を完了し、ユーザにトークンを発行する。このユーザはEntra ID内のグループに所属しているため、そのグループに割り当てられたAzureロールの権限でAzureリソースにアクセスできる。
Azureのアプローチは、すべてのIDをまずEntra IDの世界に取り込み、Entra IDのガバナンス下で一元的に権限を管理するという、強力な中央集権モデルと言えます。
【AWS/GCP/Azure】監査ログでの追跡
SSOでログインしたユーザの操作は、各クラウドの監査ログで以下のようにしっかりと追跡可能です。
-
AWS (CloudTrail)
userIdentityオブジェクトにtype: AssumedRoleと記録されます。sessionContext.sessionIssuer.userNameなどのフィールドに、IAM Identity Center経由でログインしたユーザのID（IdP上のユーザ名）が記録されます。 -
GCP (Cloud Audit Logs)
authenticationInfo.principalEmailにWorkforce Federation経由でログインしたユーザの一意な識別子（例principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/user-id）が記録されます。 -
Azure (Activity Log)
イベントのCallerプロパティに、Entra ID上のユーザ名（UPN）が直接記録されます。
これにより「IdPのどのユーザが、いつ、何をしたか」を各クラウドの監査ログで追跡できます。
まとめ、各クラウドのIdP連携モデル比較
| 目的/機能 | AWS | GCP | Azure |
|---|---|---|---|
| 連携ハブ | IAM Identity Center | Workforce Identity Federation | Microsoft Entra ID |
| IDの持ち方 | Identity Center内に同期 (SCIM) | 原則、GCP内にIDを持たない | Entra ID内に同期 (SCIM) |
| 権限マッピング | Permission Set をグループに割り当て | IAMポリシーの Condition で属性を評価 | Entra IDグループに Azureロール を割り当て |
| 思想 |
専用ハブ＆スポーク型 Identity CenterがAWSアカウント群へのアクセスを抽象化・仲介する。 |
純粋なフェデレーション型 IdPの属性を信頼し、動的に権限を評価する。 |
ネイティブIdP統合型 すべてのIDをEntra IDの管理下に置き、RBACで統制する。 |
前回のワークロードIDと同様、今回のユーザID管理においても、各クラウドの設計思想が色濃く反映されています。
-
AWS ＝ 専用ハブ＆スポーク型
IAM Identity Centerという中間層を設けることで、複雑なマルチアカウント環境への権限委任をうまく抽象化しています。-
利点
マルチアカウントの権限設定をIAM Identity Centerに集約できるため、監査や棚卸しがしやすい。 -
考慮点
IdPとIAM Identity Centerの2段階で設定が必要になり、構成がやや複雑になる。
-
利点
-
GCP ＝ 純粋なフェデレーション型
「IDをクラウド内に作らない」という思想で、IdPからの情報を直接信頼する、クリーンで疎結合なフェデレーションを実現します。-
利点
GCP内にIDの複製が残らず、IdPが唯一の信頼できる情報源（Single Source of Truth）となる。 -
考慮点
IdP側のグループ名変更などが直接IAMポリシーに影響するため、両者の設定を同期させる運用が求められる。
-
利点
-
Azure ＝ ネイティブIdP統合型
Entra IDという強力なID基盤にすべてを集約させることで、ガバナンスと一元管理を最優先した堅牢なセキュリティモデルを構築しています。-
利点
すべてのIDと権限をEntra IDで一元管理でき、Microsoft 365など他のサービスとの親和性も高い。 -
考慮点
すべてのIDを一度Entra IDに取り込む思想のため、Entra ID自体の設計・運用に関する深い知識が不可欠となる。
-
利点
マルチクラウド環境でID管理を設計する際は、「どのクラウドが優れているか」ではなく、「どのクラウドの思想が、自社のセキュリティポリシーや運用モデルに最もフィットするか」を考えることが重要です。
この記事が、SSOの裏側で動く魔法の正体を解き明かし、皆さんのセキュアなID管理設計の一助となれば幸いです。
お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。