Account Access ManagerでIdentity Centerをより柔軟に利用する

はじめに

2026/8/10にAccount Access Managerがリリースされました。

新しくリリースされたアカウントアクセスマネージャーは、IAM Identity Center の単一のフェデレーションポイントとユーザーの認識、および IAM ロールの柔軟性を必要とする顧客向けのソリューションを提供します。

Identity CenterにおいてIAMロールをより柔軟に利用できるようになったようです。
具体的にどんなものか見ていきたいと思います。

何がどう変わるのか

これまで、ユーザーに対してAWSアカウントへのアクセスを提供する方法は下記の2つ（①②）がありました。

① IAMロール + IAMフェデレーション

1つ目は、各AWSアカウントにユーザーを個別にフェデレーションし、各AWSアカウントのIAMロールを使用してユーザーの権限を制御する方法です。

この方法ではフェデレーション設定がAWSアカウントの数だけ必要になります。権限は各アカウントのIAMロールで自由に定義できる代わりに、アカウントの増加に比例して設定箇所が増えます。

② Identity Centerの許可セット

2つ目は、Identity Centerを介してユーザーを一度フェデレーションし、許可セットを調整・プロビジョニングすることで、アクセスを一元的にカスタマイズ・管理する方法です。

入口が1つに集約され、権限セットを更新すれば割当先の全アカウントにロールが展開されます。一方で、生成されるロールは AWSReservedSSO_* という固定の形になり、信頼ポリシーやロールパスには手を入れられません。

③ IAMロール + Account Access Manager

こちらが今回のリリースにより実現可能になった構成です。

②との違いは下記2点です。

• ロール・ID・アカウントのマッピング場所が「Identity Center」から「Account Access Manager」になった
• ロールの供給元が「Identity Centerによる自動プロビジョニング」から「自作（IAMコンソール・SDK・CloudFormation/CDK）」になった

今回のリリースにより、

IDの入口が1つという利点はそのままに、ロール側は信頼ポリシー・タグ・パスを自由に設計できるようになりました。

なお、Identity Centerには、各AWSアカウント上の自作ポリシーを利用する カスタマー管理ポリシー は以前からありましたが、ロールのカスタマイズはできませんでした。

ドキュメントから、自作ロールが利用可能になったことによる利点を引用します。

• IAMロールタグを設定し、セッションタグを使用して属性ベースアクセス制御（ABAC）を実行します。
• IAMロールの信頼ポリシーを設定して、ロールの引き受けを制限したり、ネットワークベースの条件を適用したり、IdPが主張するクレームを信頼ポリシーの条件として使用したりできます。
• IAMロールパスを設定して、ロールを論理的にグループ化し、管理を簡素化します。

前提条件

ドキュメントにある前提条件を見ておきたいと思います。
以下は意訳です。

• すべての商用リージョンにおいてデフォルトで有効
• 単一のIdentity Center組織インスタンスに接続する（アカウントインスタンスでは利用不可）
• Account Access ManagerとIdentity Centerは同一リージョンである必要がある
• 組織の管理アカウントではIdentity Centerの組織インスタンスとAccount Access Managerの両方を有効にする必要がある

使ってみた

Account Access Managerを有効にする

まず管理アカウントにて下記コマンドを実行し、組織にAccount Access Managerのアクセス権を付与します。

aws organizations enable-aws-service-access --service-principal account-access.amazonaws.com

検索からAccount Accessというサービスに移動します。

バージニアとオレゴンがサポートされており、東京リージョンは利用できません。

検証を行った8/14時点ではリージョンに制限がありましたが、8/15時点では東京リージョンで利用可能になっていました。

すべての商用リージョンでデフォルト有効というのは誤記だったのでしょうか？
Builder Centerでリージョンごとのサービス利用可否を見てみましたが、東京は利用可能になっています。

とりあえず今回はバージニアを選択して画面遷移すると、IAMの画面の下の方に「マルチアカウントアクセス」という項目が増えています。

私の検証環境ではIdentity Center組織インスタンスが東京リージョンにデプロイされていたため、Identity Centerが無効になっている状態と判断されています。

そこで組織インスタンスのデプロイ先をバージニアに変えてみました。「有効化」ボタンが登場したのでこれを押してみます。

数秒で有効になりました。

設定タブにはアプリケーションURLが載っています。

アクセスポータルのアプリケーションタブにもアカウントアクセスが登場しています。

アプリケーションURLにアクセスしてみます。まだAccount Access Managerで何も権限を付与していないため空の状態です。

さらっとログイン用の画面が登場しましたが、Account Access Managerで付与されたアクセスは、従来のIdentity CenterのAWSアクセスポータルとは別に、Identity Centerの一つのアプリケーションとして、個別のアクセスポータル（通称アカウントアクセスポータル）として提供されます。

アカウントアクセスポータル
これは、従業員がアカウントアクセスマネージャーを使用して割り当てられたAWSアカウントにアクセスできるポータル（URL）です。このポータル（URL）はブックマークして直接アクセスできるほか、AWSアクセスポータルからAWSマネージドアプリケーションとして利用することもできます。

AWSアクセスポータル
これは、IAM Identity Center ユーザーが AWS にアクセスする際の主要な入り口です。このポータルには、アカウントアクセス ポータルを含め、ユーザーがアクセスできるすべての AWS アプリケーションが表示されます。

メンバーアカウントにロールを作成する

Account Access Managerで管理するロールには、以下のような信頼ポリシーを付与する必要があります。

信頼ポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AccountAccessManagerIAMRoleTrustPolicyStatement",
      "Effect": "Allow",
      "Principal": {
        "Service": "account-access.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetContext",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "<your-account-id>",
          "aws:SourceArn": "arn:aws:account-access:<region>:<your-account-id>:application/<application-id>"
        }
      }
    }
  ]
}

Conditionのaws:SourceAccountには管理アカウントのアカウントID、aws:SourceArnにはAccount Access ManagerのARNを書きます。
sts:TagSessionアクションはオプションで、属性ベースのアクセス制御（ABAC）を利用したいときに許可します。IDプロバイダ側でグループやユーザーに対して付与した何らかの属性（チーム名など）を、IAMポリシーのCondtionにて条件キーaws:PrincipalTag/<key>で指定することで、属性を使った権限制御ができます。

今回、管理ポリシーReadOnlyAccessと、ABAC検証用に下記のカスタムポリシーを付与したロールを作成しました。カスタムポリシーは、自身のユーザーに付与されているCostCenterタグの値と、リソースに付与されているCostCenterの値が一致している場合に、SNSのフルコントロールを付与する、というものです。

カスタムポリシー

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sns:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"
                }
            }
        }
    ]
}

アクセス権を割り当てる

グループに対してアクセス権を割り当ててみます。

「組織を参照」からアカウントを選択し、IAMロール名は直接入力し、アクセス権を割り当てます。

割り当てられました。

アクセスしてみる

アカウントアクセスポータルにアクセスすると、先ほどAccount Access Managerで割り当てたアクセス権が付与されています。

マネコンにアクセスできました。

このあと、属性ベースのアクセス制御（ABAC）の検証としてSNSトピックの変更操作を試しましたが、うまくいきませんでした。IDソースとしてIdentity Centerディレクトリを利用していたことが原因なのかもしれませんが、それ以上深堀できていません。また別の機会に外部IdPを利用して試してみたいと思います。

委任管理者

Account Access ManagerはOrganizationsと統合されており、メンバーアカウントに管理を委任することができます。

登録をクリックします。

委任先のメンバーアカウントを選択し、登録します。（タイトル部分が「登録解除」になっていますが、登録画面です）

さいごに

Account Access Managerは、Identity Centerにおいてロールのカスタマイズという選択肢を増やしてくれた有用な機能アップデートであることがわかりました。
実際に運用していく場合、メンバーアカウント上のカスタムロールを誰がどのようにデプロイおよび管理するのか、どのような運用設計とするかが重要なポイントになってくるように感じました。ここはまだ深く考えられていませんが、ユースケースによって最適な運用を見つけていく必要がありそうです。

弊社では一緒に働く仲間を募集中です！

現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！

募集内容等詳細は、是非採用サイトをご確認ください。