AWSフェデレーション設定をSCS視点で完全理解する

この記事はAWS公式ドキュメントを前提に、SCS-C03で問われるAWSフェデレーション設定を、設計とトラブルシュートの両方から整理します。

フェデレーションとは、AWSの外にあるIDを使ってAWSへアクセスする仕組みです。企業のIdP、Microsoft Entra ID、Okta、Ping Identity、AD FS、Google Workspace、GitHub Actions、Kubernetes service accountなどが認証元になり、AWS側では一時認証情報やロールセッションとして扱います。

SCS視点での本質は、次の分離です。

認証: 外部IdPやIAM Identity Centerが「本人か」を確認する
認可: AWS IAM Roleやpermission setが「何をしてよいか」を決める
監査: CloudTrailが「誰として何をしたか」を残す

IAMユーザーを各アカウントに作る設計は、退職者対応、MFA強制、権限棚卸し、アクセスキー管理で破綻しやすくなります。多アカウント環境では、フェデレーションで人間のアクセスを集中管理し、AWS側では短命なセッションに変換するのが基本です。

画像解説: 図の上段は、利用者が外部IdPで認証し、IAM Identity Centerを経由して各AWSアカウントの AWSReservedSSO_ ロールを使う流れです。下段は、直接SAML/OIDCでSTSへ入る構成や、監査で見るべきCloudTrailの観点を示しています。SCSでは「IdPでログインできる」ことと「AWSで何ができる」ことを分けて判断します。

まず結論

人間のAWSアクセスは、多くの場合IAM Identity Centerを中心に考えます。

Workforce IdP
  -> IAM Identity Center
  -> Group assignment
  -> Permission set
  -> AWS account
  -> Short-lived role session

一方、特定のSAML IdPやOIDC providerから直接ロールを引き受ける設計もあります。

SAML IdP
  -> AssumeRoleWithSAML
  -> IAM role session

OIDC provider
  -> AssumeRoleWithWebIdentity
  -> IAM role session

SCSの選択肢では、次の判断が重要です。

IAM Identity Centerの基本構成

IAM Identity Centerは、AWSアカウントやアプリケーションへのアクセスを中央管理するサービスです。AWS Organizationsと組み合わせると、複数アカウントへの人間アクセスをpermission setで管理できます。

基本要素は4つです。

Permission setをアカウントへ割り当てると、IAM Identity Centerは対象アカウントにIAM roleを作ります。多くの場合、名前は AWSReservedSSO_ で始まります。このロールはIdentity Centerが管理するため、手で編集する対象ではありません。

SCSで大事なのは、permission setは単なる名前ではなく、実際にIAM policyとして各アカウントのロールへ反映されるという点です。変更後は対象アカウントへの再プロビジョニングが関係します。

Permission set設計

Permission setは職務で分けます。個人名で分けると棚卸しが難しくなります。

例:

SecurityAuditReadOnly
IncidentResponseOperator
NetworkAdministrator
DatabaseReadOnly
BillingReadOnly
BreakGlassAdministrator

設計のコツは、環境と職務を混ぜすぎないことです。

良い例:

Group: sec-auditors
  Account: security-prod
  Permission set: SecurityAuditReadOnly

Group: app-team-alpha
  Account: app-alpha-dev
  Permission set: DeveloperPowerUser

Group: app-team-alpha-prod-operators
  Account: app-alpha-prod
  Permission set: ProductionReadOnly + IncidentLimitedOperator

悪い例:

User: alice
  Account: all
  Permission set: AdministratorAccess

SCSでは「最小権限」「職務分離」「退職者管理」「MFA」「監査」が出たら、個別IAMユーザーを増やす選択肢よりIdentity Centerとグループ割り当てが強くなります。

Session durationとMFA

Permission setにはセッション期間を設定できます。短すぎると運用が壊れ、長すぎると漏えい時の影響が増えます。公式仕様では、新しいpermission setのセッション期間はデフォルト1時間で、最大12時間まで設定できます。

SCSでの読み方:

• 管理者権限や本番操作は短めにする
• 読み取り専用や監査業務は業務時間に合わせる
• Break Glassは短時間、強い監査、承認付きにする
• 長時間が必要な自動処理は人間セッションではなくワークロード用ロールにする

MFAはIdP側またはIAM Identity Center側で設計します。外部IdPを使う場合、MFAやデバイス条件はIdP側の条件付きアクセスで強制することが多いです。ただしAWS側のpermission set、アカウント割り当て、CloudTrail監査とセットで考えます。

SAMLフェデレーションの設定

IAM Identity Centerを使わず、SAML IdPから直接AWS IAM roleを引き受ける構成では、IAMにSAML providerを作り、ロールのtrust policyでそのproviderを信頼します。

典型的なtrust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:saml-provider/CorporateIdP"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

ここで見るべき点:

• Principal.Federated が正しいSAML providerか
• Action が sts:AssumeRoleWithSAML か
• SAML:aud でAWSサインイン先を制限しているか
• SAML assertionにロールとprincipalの属性が正しく含まれるか
• RoleSessionNameやNameIDが監査に使える値か

SAML連携では「IdPで認証できるがAWSに入れない」トラブルがよくあります。原因は、SAML assertionの属性名、role ARN、provider ARN、audience、署名証明書、時刻ずれ、ロールtrust policyの不一致です。

OIDCフェデレーションの設定

OIDCは、Web identity tokenを使って AssumeRoleWithWebIdentity でロールを引き受ける方式です。代表例はGitHub Actions OIDC、EKS IRSA、外部CI/CD、モバイル/WebアプリのID連携です。

信頼ポリシーでは、OIDC providerだけでなく aud と sub を必ず絞ります。

GitHub Actionsの例:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:example-org/example-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

EKS IRSAの例:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.ap-northeast-1.amazonaws.com/id/EXAMPLE"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "oidc.eks.ap-northeast-1.amazonaws.com/id/EXAMPLE:aud": "sts.amazonaws.com",
      "oidc.eks.ap-northeast-1.amazonaws.com/id/EXAMPLE:sub": "system:serviceaccount:prod:payment-api"
    }
  }
}

SCSの落とし穴は、OIDC providerだけを信頼して sub を広くしすぎることです。

危険な例:

"StringLike": {
  "token.actions.githubusercontent.com:sub": "repo:example-org/*"
}

これでは同じ組織内の別リポジトリから本番デプロイロールを使える可能性があります。ブランチ、環境、リポジトリ、service account、namespaceなど、ワークロードを識別する属性で絞ります。

画像解説: SAML、OIDC、IAM Identity Centerはいずれも「外部IDをAWS権限に変換する」仕組みですが、絞る場所が違います。SAMLはproviderとaudience、OIDCはproviderに加えて aud と sub、Identity Centerはpermission setとaccount assignmentが中心です。監査ではSTS API、AWSReservedSSO_ ロール、sessionContextを見ます。

ABACとSession Tags

ABACは、属性ベースのアクセス制御です。フェデレーションでは、IdPのグループや部署、プロジェクト、コストセンターなどをAWSセッションタグに変換し、IAM policyで aws:PrincipalTag として使えます。

例:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::company-project-data/${aws:PrincipalTag/Project}/*"
}

この設計では、ユーザーのProject属性が alpha なら company-project-data/alpha/ のみ扱えます。ロールをプロジェクトごとに大量作成しなくてよい一方、属性の信頼性が重要になります。

注意点:

• IdPから渡す属性を誰が管理できるか
• セッションタグのキー名と値の正規化
• sts:TagSession を誰に許可するか
• transitive tagとしてロールチェーンに引き継ぐか
• CloudTrailでタグを監査できるか

SCSでは「ユーザー属性に基づいてS3 prefixを制限」「部署ごとに同じロールで異なるリソースへアクセス」と出たら、ABACとsession tagsが候補です。

SCIMとライフサイクル管理

外部IdPを使う場合、ユーザーとグループの同期が重要です。SCIMを使うと、IdP側のユーザー作成、グループ変更、無効化をIAM Identity Centerへ同期できます。

SCSでの読み方:

• 退職者のAWSアクセスを速やかに止める
• グループ変更をAWS側のaccount assignmentに反映する
• 手作業のユーザー棚卸しを減らす
• IdPを信頼元として一元管理する

ただし、SCIMでユーザーが消えても、既存のAWSセッションが即時にすべて消えるとは限りません。重要操作ではセッション期間を短くし、緊急時にセッション失効や権限剥奪の手順を持ちます。

CloudTrailで何を見るか

フェデレーションの調査では、CloudTrailのイベント名と userIdentity を見ます。

直接STSの場合:

AssumeRoleWithSAML
AssumeRoleWithWebIdentity
AssumeRole

IAM Identity Center経由の場合:

AWSReservedSSO_... role session
sessionIssuer
principalId
userName / roleSessionName
sourceIPAddress
MFAやIdP側ログとの相関

重要なのは、AWS側CloudTrailだけで本人確認のすべてが完結しないことです。外部IdPでのMFA、条件付きアクセス、デバイス状態、ログイン失敗、グループ変更はIdP側ログにあります。インシデント対応では、CloudTrailとIdP監査ログを時刻で相関します。

Break Glass設計

フェデレーションは便利ですが、IdP障害やIdentity Center障害、設定ミスで管理者がAWSへ入れなくなる可能性があります。そのため、Break Glassアクセスを設計します。

良いBreak Glass:

• 通常時は使わない
• MFA必須
• 強い通知とCloudTrail監視
• 短時間で棚卸し
• 利用手順と事後レビューがある
• rootではなく、専用の緊急用ロールまたは厳格管理された管理者経路を使う

悪いBreak Glass:

• 共有IAMユーザー
• 長期アクセスキーを保管
• MFAなし
• 利用通知なし
• 誰が使ったか分からない

SCSでは「IdP障害時にも管理アクセスが必要」「通常経路とは分離」「監査可能」が出たらBreak Glass設計を考えます。

ユースケース別の設定パターン

企業ユーザーを全AWSアカウントへ安全に入れたい

推奨:

• IAM Identity CenterをOrganizationsインスタンスで使う
• 外部IdPをidentity sourceにする
• SCIMでユーザー/グループを同期
• グループ単位でaccount assignment
• 職務別permission set
• セッション期間とMFAを権限の強さに合わせる

個別アカウントにIAM userを作る設計は避けます。

CI/CDから本番アカウントへデプロイしたい

推奨:

• OIDC federationを使う
• aud を sts.amazonaws.com に固定
• sub でリポジトリ、ブランチ、環境を限定
• デプロイロールの権限を最小化
• session policyやpermissions boundaryを検討
• CloudTrailでリポジトリと実行IDを追えるようにする

長期アクセスキーをGitHub Secretsなどに入れる設計は、ローテーションと漏えい時の影響が大きくなります。

EKS PodにAWS権限を渡したい

推奨:

• IRSAまたはEKS Pod Identityを検討
• namespaceとservice account単位でロールを分ける
• OIDC trust policyの sub を固定
• Podにノードロールの広い権限を使わせない
• CloudTrailでロールセッションを追跡する

SCSでは「アプリごとに最小権限」「ノード全体の権限を避ける」と出たら、Pod単位のフェデレーションが強いです。

部署属性でS3アクセスを分けたい

推奨:

• IdP属性をsession tagへマップ
• IAM policyで aws:PrincipalTag を使う
• タグを変更できる管理者を限定
• CloudTrailでsession tagsを確認
• 例外処理を別ロールに逃がさず、属性の管理プロセスを整える

ABACはロール爆発を防げますが、属性が壊れると権限境界も壊れます。

外部委託先に監査権限を渡したい

推奨:

• 可能なら委託先IdPとSAML/OIDC連携
• もしくは外部ベンダー用クロスアカウントロール
• Confused Deputy対策としてExternal ID
• ReadOnlyでもKMS、S3、CloudWatch Logsなどresource policyを確認
• セッション名、SourceIdentity、CloudTrailで追跡

「第三者」「複数顧客」「ロールARNを渡す」文脈ならExternal IDが重要です。

トラブルシュート

IdPログインは成功するがAWSアカウントが見えない

確認:

• IAM Identity Centerにユーザー/グループが同期されているか
• 対象アカウントへのaccount assignmentがあるか
• permission setがプロビジョニング済みか
• IdP側グループ名とIdentity Center側グループが一致しているか

SAMLでAccessDeniedになる

確認:

• IAM SAML providerのメタデータが最新か
• ロールtrust policyの Principal.Federated が正しいか
• SAML:aud が一致しているか
• assertionにRole属性が正しいARNペアで含まれるか
• ユーザー時刻、IdP時刻、証明書期限に問題がないか

OIDCでAccessDeniedになる

確認:

• OIDC provider URLとthumbprint/issuerが正しいか
• trust policyの aud がトークンと一致するか
• sub 条件が実際のトークンと一致するか
• ブランチ名、環境名、service account名が想定通りか
• ロールのpermission policyに後続API権限があるか

AWSに入れるが操作できない

確認:

• permission setまたはrole policyに対象Actionがあるか
• SCPでDenyされていないか
• permissions boundaryで落ちていないか
• session policyで絞りすぎていないか
• S3/KMSなどresource policy側で拒否されていないか

フェデレーション成功は「認証成功」です。後続APIのAccessDeniedは、IAM評価ロジックの問題として切り分けます。

試験での落とし穴

IAMユーザーを増やす選択肢

多アカウントの人間アクセスでIAMユーザーを各アカウントに作る選択肢は弱いです。Identity Center、SAML、OIDC、STS一時認証情報を優先します。

IdPだけで認可が完結すると思う

IdPは本人確認と属性管理を担います。AWS上の許可はpermission set、IAM role policy、SCP、resource policyで決まります。

OIDCのtrust policyが広すぎる

OIDC providerを登録しただけでは安全ではありません。aud と sub を具体的に絞ります。

Session policyを権限追加だと思う

AssumeRole系のsession policyは権限を増やしません。ロール権限との交差でセッションを縮小します。

CloudTrailだけでIdP側MFAを証明しようとする

AWS側ログとIdP側ログの相関が必要です。MFA、デバイス条件、グループ変更はIdP側にも証跡があります。

まとめ

AWSフェデレーションは、IAMユーザーを減らすための機能ではなく、認証、認可、監査、ライフサイクル管理を分離する設計です。

SCSでは次の形で覚えます。

人間の多アカウントアクセス
  -> IAM Identity Center + permission set + group assignment

企業IdPから直接ロール
  -> SAML provider + AssumeRoleWithSAML + SAML:aud

CI/CDやPodなどのワークロード
  -> OIDC provider + AssumeRoleWithWebIdentity + aud/sub条件

属性ベース制御
  -> session tags + aws:PrincipalTag + ABAC

監査
  -> CloudTrail + IdP logs + session duration + SourceIdentity

フェデレーション設定で一番大事なのは、「ログインできる」ことではなく、「正しい主体だけが、正しい期間だけ、正しい権限に変換され、後から説明できる」ことです。

参考

• Permissions for AssumeRole, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity
• Manage AWS accounts with permission sets
• Create, manage, and delete permission sets
• Use IAM policies in permission sets
• Set session duration for AWS accounts
• IAM roles created by IAM Identity Center