Microsoft Entra ID と SAML フェデレーションでジャンプアカウント経由の個人識別ログインを実現してみた

クラウド事業統括本部 コンサルティング部のいたくらです。

はじめに

AWS Organizations を使っていない環境では、IAM Identity Center が利用できません。そのため複数の AWS アカウントを扱う場合でも、各アカウントに個別の IAM ユーザーを作って運用しているケースをよく見かけます。
各アカウントに個別の IAM ユーザー作成は面倒なので、ジャンプアカウントを作成して、そこから各アカウントへスイッチロールする構成とするのも多いですよね。

今回は、「Microsoft Entra ID と連携して個人を識別しつつ MFA を効かせてジャンプアカウントにログインし、各アカウントへスイッチロールできるか」を検証してみました。

結論としては、IAM ユーザーを 1 つも作らずに実現できることが確認できたので、検証した構成と手順をまとめます。

三行まとめ

• AWS Organizations を使っていない（IAM Identity Center が使えない）環境でも、Microsoft Entra ID と IAM の SAML フェデレーションを組み合わせれば、IAM ユーザーを作らずに個人識別と MFA 強制を実現できることを確認しました
• 複数アカウントを扱う場合は、1 つの「ジャンプアカウント」に SAML ログインしてから各アカウントへスイッチロールする構成にすると、Entra ID 側の設定変更を最小限に抑えられます
• Entra ID の Security Defaults（Free ライセンス）^[1] はリスクベースで MFA を要求する仕組みのため、AWS へのログインで毎回確実に MFA を求めたい場合は Premium P1 の条件付きアクセスが必要です

前提

検証環境は以下のとおりです。

• Microsoft Entra ID: Free（個人テナント）
• AWS アカウントを 2 つ使用
  • ジャンプアカウント（Entra ID から SAML ログインする先）
  • ターゲットアカウント（ジャンプアカウントからスイッチロールする先）

なぜ「ジャンプアカウント方式」にしたのか

AWS 側に IAM の SAML プロバイダーを作る場合、大きく 2 つの構成が考えられます。

• 直接ログイン方式: すべての AWS アカウントに個別の SAML プロバイダーとロールを作り、Entra ID から各アカウントへ直接ログインする
• ジャンプアカウント方式: 1 つのアカウント（ジャンプアカウント）にだけ SAML プロバイダーとロールを作り、そこから各アカウントへスイッチロール（クロスアカウントロールの引き受け）する

アカウントが数個であれば直接ログイン方式でも問題ないのですが、アカウント数が増えるほど Entra ID 側の設定（アプリロールの登録）もアカウント数 × ロール種類の分だけ必要になります。
ジャンプアカウント方式であれば、AWS 側にアカウントを追加してもクロスアカウントロールを 1 つ追加するだけで済み、Entra ID 側の設定変更が不要になります。

そのため今回はジャンプアカウント方式で検証しました。

やってみた

1. Entra ID にエンタープライズアプリケーションを追加する

Entra 管理センターから、エンタープライズアプリケーション → 新しいアプリケーション と進み、ギャラリーから「AWS Single-Account Access」を追加します。

ギャラリーアプリを使うと、シングルサインオンの基本的な SAML 構成が自動で入力されます。

属性とクレームも AWS 向けの値が自動設定されているので、内容を確認するだけで大丈夫です。

最後に、SAML 証明書のセクションからフェデレーションメタデータの XML をダウンロードしておきます。この XML は、あとで AWS 側の IAM SAML プロバイダーを作るときに使います。

2. AWS のジャンプアカウントに SAML プロバイダーとロールを作成する

ジャンプアカウントにログインし、IAM から ID プロバイダーを追加します。

続けて、この SAML プロバイダーを信頼するロールを作成します。信頼されたエンティティタイプで「SAML 2.0 フェデレーション」を選び、先ほど作った EntraID プロバイダーを指定します。信頼ポリシーは以下のような内容が自動生成されます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ジャンプアカウントID>:saml-provider/EntraID"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

このロール（ここでは EntraID-Jump という名前にしました）には、ターゲットアカウントのロールを引き受けるための許可ポリシーをインラインで追加しておきます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::<ターゲットアカウントのアカウントid>:role/CrossAccount-FromJump"
    }
  ]
}

3. AWS の ターゲットアカウントにクロスアカウントロールを作成する

ターゲットアカウント側にも IAM ロールを作成します。信頼されたエンティティタイプは「AWS アカウント」を選び、ジャンプアカウントの ID を指定します。

ここで 1 点注意が必要です。ロール作成時に「MFA が必要」というオプションが表示されますが、今回の構成では チェックしません。MFA は Entra ID 側で制御する前提としているため、AWS 側で MFA を要求すると SAML フェデレーション経由のスイッチロールがうまく通らなくなります。

権限ポリシーには、検証用として ReadOnlyAccess を付与し、ロール名は CrossAccount-FromJump としました。

4. Entra ID でアプリロールを登録し、ユーザーを割り当てる

Entra 管理センターの「アプリの登録」から、手順 1 で追加した「AWS Single-Account Access」を開き、アプリロールを作成します。

値の項目には、ロール ARN と SAML プロバイダーの ARN をカンマ区切り・スペースなしで入力する必要があります。ここでフォーマットを間違えると、SAML ログイン時に Invalid SAML response のようなエラーになるので注意してください。

アプリロールを作成したら、エンタープライズアプリケーションの「ユーザーとグループ」から、自分のアカウントに JumpAdmin ロールを割り当てます。

5. 動作確認

シークレットウィンドウで myapps.microsoft.com を開き、Entra ID のアカウントでログインします。「AWS Single-Account Access」をクリックすると、ジャンプアカウントの AWS マネジメントコンソールにログインできました。

続けて、コンソール右上のアカウント名からロールの切り替えを選び、ターゲットアカウントの ID と CrossAccount-FromJump ロールを指定します。これで ターゲットアカウントのコンソールにもログインできることを確認しました。

6. CloudTrail で個人識別ができているか確認する

最後に、SAML ログインの記録が CloudTrail に残っているかを確認します。今回はジャンプアカウント → ターゲットアカウントという構成のため、2 つのアカウントの CloudTrail をそれぞれ確認する必要があります。

■ ① ジャンプアカウント側：EntraID → ジャンプアカウントへのログイン

SAML ログインに関する AssumeRoleWithSAML イベントは、us-east-1（バージニア北部） リージョンに記録されます。東京リージョンでイベント履歴を見ても何も表示されないので、リージョンを切り替えて確認してください。

responseElements.assumedRoleUser.arn を見ると、以下のように Entra ID の UPN（ユーザープリンシパル名、メールアドレス形式）が RoleSessionName の部分に記録されていました。

arn:aws:sts::<ジャンプアカウントID>:assumed-role/EntraID-Jump/user@example.onmicrosoft.com

これで、IAM ユーザーを 1 つも作らずに「誰が」「いつ」「どのロールで」ジャンプアカウントにログインしたかを追跡できることが確認できました。

■ ② ターゲットアカウント側：ジャンプアカウント → ターゲットアカウントへのロール切り替え

ただし、これだけでは「ジャンプアカウントに入った」ことしか分かりません。実際にどのターゲットアカウントへ入ったかを追跡するにはターゲットアカウント側の CloudTrail も確認する必要があります。

マネジメントコンソール上の「ロールの切り替え（Switch Role）」による移動は、STS の AssumeRole イベントとしてではなく、signin.amazonaws.com が発行する SwitchRole という別イベントとして記録されます。AssumeRole でイベント名を絞り込んでも、この遷移はヒットしません。

{
    "userIdentity": {
        "type": "AssumedRole",
        "arn": "arn:aws:sts::<ターゲットアカウントID>:assumed-role/CrossAccount-FromJump/user@example.onmicrosoft.com"
    },
    "eventSource": "signin.amazonaws.com",
    "eventName": "SwitchRole",
    "sourceIPAddress": "<クライアントの実IP>",
    "additionalEventData": {
        "SwitchFrom": "arn:aws:sts::<ジャンプアカウントID>:assumed-role/EntraID-Jump/user@example.onmicrosoft.com",
        ...
    }
}

additionalEventData.SwitchFrom に、遷移元であるジャンプアカウントのロールセッション ARN がそのまま記録されており、これが「ジャンプアカウント経由でターゲットアカウントに入った」ことを直接示す証跡になります。ジャンプアカウント側の AssumeRoleWithSAML の eventTime と突き合わせることで、一連のログインセッションとして紐付けることができました。

なお、SwitchRole イベントの userIdentity には accessKeyId が含まれないため、アクセスキーでの横断検索はできません。追跡する際は SwitchFrom の ARN や、前段の SAML ログインとの時刻の近さで紐付ける必要がある点に注意してください。

以上により、IAM ユーザーを 1 つも作らずに、ジャンプアカウント経由でターゲットアカウントに「誰が」「いつ」「どのルート・どのロールで」入ったかを、2 つのアカウントの CloudTrail を突き合わせることで追跡できることが確認できました。

参考ドキュメント

• SAML 2.0 フェデレーション - AWS Identity and Access Management
• Configure AWS Single-Account Access for Single sign-on with Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn
• Microsoft Entra licensing - Microsoft Entra | Microsoft Learn
• How to Configure AWS IAM SAML 2.0 Federation with Microsoft Entra ID for Single-Account Access | AWS re:Post

さいごに

Organizations も IAM Identity Center も使えない環境だと、複数アカウントの ID 管理はどうしても IAM ユーザーの個別管理に頼りがちです。
ただ、ジャンプアカウント方式であれば AWS 側の変更を最小限にしつつ、Entra ID などの既存の ID 基盤に統合できることが確認できました。

同じような制約のある環境で認証方式を検討されている方の参考になれば幸いです。

この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業統括本部 コンサルティング部のいたくら（@itkr2305）でした！