AWS アカウントアクセスマネージャーの提供開始: IAM ロールの柔軟性とワークフォースアクセスの一元管理を両立

本ブログは 2026 年 11 月 5 日に公開された AWS Blog “Introducing AWS account access manager: IAM role flexibility with centralized workforce access” を翻訳したものです。

AWS Identity and Access Management (IAM) は、アカウントアクセスマネージャーの提供を開始しました。これは、Amazon Web Services (AWS) アカウントへのワークフォースアクセスを管理するための、柔軟な新しい方法です。チームが既に活用している IAM ロールの柔軟性を、AWS IAM Identity Center の一元的なフェデレーションを通じて提供します。さらに、ユーザーレベルの可視性も標準で備えています。

アカウントアクセスマネージャーを使用すると、個々の AWS アカウントにある既存の IAM ロールを、IAM Identity Center の組織インスタンス内のワークフォースユーザーとグループに効率よく割り当てることができます。これにより、大規模な環境でも一元的なアクセス管理を実現しやすくなります。アカウントアクセスマネージャーは単独で導入することも、IAM Identity Center のアクセス許可セットと併用することもできます。どちらの場合も、企業の ID プロバイダー (IdP) から既に同期しているユーザーとグループをそのまま利用します。そのため、ID を重複して作成したり、アカウントごとにフェデレーションポイントを管理したりすることなく、既存の IAM ロールをそれらのユーザーとグループに直接割り当てることができます。

アカウントアクセスマネージャーを使用する理由とは？

AWS の利用規模を拡大している企業は、ワークフォースアクセスについて、IAM ロールの柔軟性と IAM Identity Center による一元管理のどちらを取るかという難しい選択を長年迫られてきました。これまで AWS アカウントへのワークフォースアクセスを付与するには、一般的に 2 つのアプローチのいずれかを選ぶ必要があり、どちらにもトレードオフがありました。IAM ロールを使用して各アカウントに個別にフェデレーションする方法では、カスタム信頼ポリシー、タグ、パスといった IAM ロールの柔軟性を最大限に活用できます。しかし、アカウントごとに IdP を設定し、ロールの割り当てを個別に管理する必要があるため、複数のアカウントにまたがってグループを割り当てたり、誰がどこにアクセスできるかを一元的に把握したりすることが難しくなります。一方、アクセス許可セットを使用して IAM Identity Center 経由で一度だけフェデレーションする方法では、単一のフェデレーションポイントから、一元的にプロビジョニングされた統一的なアクセスを提供できます。しかし、アカウントごとにロールが異なるチームや、既存のロールを汎用化して統一的なセットにまとめにくいチームにとっては、アクセス許可セットは制約が多く感じられる場合があります。

アカウントアクセスマネージャーは、こうしたトレードオフを解消します。IAM Identity Center の単一のフェデレーションポイントと ID 伝播のメリットを、IAM ロールの柔軟性と組み合わせて利用したいお客様向けに設計されています。既に所有している IAM ロールをそのまま使用するため、現在活用しているきめ細かなカスタマイズ機能も引き続き利用できます。

属性ベースのアクセス制御 (ABAC) – IAM ロールのタグや、IdP から SAML クレームとして渡されるセッションタグを使用して、属性に基づくきめ細かな認可を実現します。
厳密な信頼ポリシー – ネットワーク条件や、IdP がアサートするクレーム (グループメンバーシップ、部署、コストセンターなど) を信頼ポリシーの条件として使用し、ロールの引き受けを制限します。
大規模な環境を整理するロールパス – IAM ロールパスを使用してロールをグループ化し、環境の拡大に合わせて管理を簡素化します。

ロールはアクセスのプロビジョニング先となるアカウント内で管理されるため、アカウントアクセスマネージャーは Identity Center 固有のクォータに依存せず、アカウントの使用状況に応じてスケールします。また、割り当てはユーザーとグループに対して行うため、管理上のオーバーヘッドを削減できます。さらに、アクセスしたユーザーと使用されたロールを特定できるため、説明責任と監査可能性も確保できます。

仕組み

アクセスは IAM Identity Center を経由し、信頼できる ID の伝播 (trusted identity propagation) によってユーザーの ID が引き継がれます。複数のユーザーが共有の IAM ロールを引き受ける場合でも、各ロールセッションにはユーザーコンテキストが含まれるため、すべてのアクションを個々のユーザーにひも付けることができます。アクセスは実際のユーザーに対して付与および監査されるため、誰がどのアカウントでどのロールを引き受けたかを確認できます。その結果、サインインの時点だけでなく、組織全体にわたってユーザーレベルの可視性が得られます。また、ロールパス、タグ付け、命名規則、その他の IAM プリミティブなど、IAM ロールのすべての機能も引き続き利用できます。

Figure 1: Account access manager connects IAM Identity Center federated workforce users and groups to AWS accounts specific IAM roles

図 1: アカウントアクセスマネージャーは、IAM Identity Center でフェデレーションされたワークフォースユーザーとグループを、各 AWS アカウント固有の IAM ロールに接続します

アカウントアクセスマネージャーを使用して、アカウント内の特定のロールへのアクセスをユーザーに付与するには、管理者がエンタイトルメント (entitlement) を作成します。その後、ユーザーは新しいアカウントアクセスマネージャーアプリケーションポータルまたは IAM Identity Center アクセスポータルからそのアカウントにアクセスできます。また、コマンドラインで aws login を使用して認証情報を取得することもできます。

アカウントアクセスマネージャーは、AWS マネジメントコンソールの IAM 画面で管理できるほか、AWS コマンドラインインターフェイス (AWS CLI) の aws login コマンドと account-access API 名前空間、AWS SDK、AWS CloudFormation、HashiCorp Terraform、Pulumi を使用してプログラムで管理することもできます。そのため、他の AWS インフラストラクチャを管理するのと同じ方法で、この機能を有効化し、ロールの割り当てを管理できます。この機能は、IAM API とは別に独自の API 名前空間 account-access を公開しており、専用のアクセス許可と AWS CloudTrail イベントを備えています。

アカウントアクセスマネージャーを有効化する方法

ここでは、前提条件の確認から最初のロールの割り当てまで、ご自身の環境でアカウントアクセスマネージャーを有効化する方法を説明します。

前提条件

IAM Identity Center の組織インスタンスが有効になっていること。
個々の AWS アカウントの IAM ロールへのエンタイトルメントを付与する対象となる、IAM Identity Center のユーザーまたはグループが存在すること。ユーザーまたはグループがまだ存在しない場合は、次のいずれかを実行してください。
- Identity Center を外部 IdP に接続し、SCIM を使用して企業の ID を Identity Center に自動的にプロビジョニングします。
- Identity Center ディレクトリにユーザーとグループを作成します。
IAM Identity Center のユーザーとグループに割り当てる IAM ロールが、個々の AWS アカウントに存在すること。必要なロールが存在しない場合は、まずカスタム信頼ポリシーを使用してロールを作成してください。
アカウントアクセスマネージャーを有効化し、割り当てを管理するための適切なアクセス許可があること (この記事で後述する IAM ポリシーの例を参照してください)。
IAM Identity Center の組織インスタンスとアカウントアクセスマネージャーの両方が、組織の管理アカウントで有効化されていること。
CLI アクセスの場合: AWS コマンドラインインターフェイス (AWS CLI) の最新バージョン (v2.36.0 以降) をインストールするか、最新バージョンに更新します。

ステップ 1: アカウントアクセスマネージャーを有効化する

アカウントアクセスマネージャーを有効化する前に、組織の管理アカウントで次のコマンドを実行し、アカウントアクセスマネージャーに組織へのアクセスを許可します。

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

次に、以下のいずれかの方法でアカウントアクセスマネージャーを有効化します。

コンソール:

組織の管理アカウントにサインインします。
AWS マネジメントコンソールの IAM 画面で、ナビゲーションペインの [Multi-account access] の下にある [account access manager] を選択します。
コンソールのリージョンは、IAM Identity Center インスタンスのプライマリリージョンに設定しておく必要があります。
IAM Identity Center の組織インスタンスが存在しない場合は、先に進む前に有効化するよう求められます。組織インスタンスが存在する場合は、[Enable account access manager] を選択します。

Figure 2: Account access manager enablement from the IAM console

図 2: IAM コンソールからのアカウントアクセスマネージャーの有効化

AWS CLI:

IAM Identity Center の組織インスタンスの Amazon リソースネーム (ARN) を取得し、リージョンコードがそのプライマリリージョンと一致していることを確認してから、次のコマンドを実行します。

aws account-access create-application \
 	--region <Region> \
  	--identity-source '{
    		"identityCenter": {
      			"instanceArn": "<IAM Identity Center Instance ARN>"
    		}
 	}'

コマンドを実行すると、アカウントアクセスマネージャーアプリケーションの ARN が出力されます。

アカウントアクセスマネージャーを (コンソールまたは AWS CLI で) 有効化すると、アカウントアクセスポータル URL、アカウントアクセスマネージャーの ARN、およびこの機能に関するその他の詳細情報が表示されます。

アカウントアクセスポータル URL は、ワークフォース向けのシングルサインオンのエントリポイントです。ユーザーはここから AWS アカウントにアクセスします。形式は - https://[Tenant-ID].account-access.[Region].app.aws で、アカウントアクセスマネージャーコンソールの [Settings] タブで確認できます。
アカウントアクセスマネージャーの ARN: アカウントアクセスマネージャーを有効化したときに作成されるアプリケーションインスタンスの識別子です。この ARN を控えておき、IAM ロールの信頼ポリシーで指定して、特定のアカウントアクセスマネージャーアプリケーションのみがそれらのロールを引き受けられるようにします。これにより、「混乱した代理」問題 (confused deputy) に対する保護が得られます (詳細はステップ 3 を参照してください)。また、AWS CLI でエンタイトルメントを作成する際に、この ARN を --application-arn に指定することで、各割り当てを正しいアプリケーションインスタンスに関連付けることができます。

Figure 3: Account access manager settings after enablement

図 3: 有効化後のアカウントアクセスマネージャーの設定

AWS CLI で aws account-access list-applications コマンドを実行すると、有効化したアカウントアクセスマネージャーインスタンスのアプリケーション ARN とテナント ID を取得できます。

ステップ 2: ファイアウォールとゲートウェイを更新する

次世代ファイアウォール (NGFW) やセキュアウェブゲートウェイ (SWG) を使用して、特定の AWS ドメインや URL エンドポイントへのアクセスをフィルタリングしている場合は、次のアカウントアクセスポータルのドメインとエンドポイントを許可リストに追加してください。アカウントアクセスマネージャーには IPv4 専用のエンドポイントはなく、すべてのエンドポイントがデュアルスタックです。

アカウントアクセスポータル URL – https://[Tenant-ID].account-access.[Region].app.aws
ポータル API – [Tenant-ID].account-access.[Region].app.aws/api/* and /auth/*
コントロールプレーン – account-access.[Region].api.aws
ランタイム – account-access-runtime.[Region].api.aws
コンソール – console.aws.amazon.com/account-access

ステップ 3: IAM ロールを準備する

IAM ロールをユーザーとグループに割り当てる前に、ロールの信頼ポリシーを更新し、アカウントアクセスマネージャーサービスがそのロールを引き受けられるようにします。

ロールの信頼ポリシーに次のステートメントを追加します (新しいロールを作成する場合は、以下のポリシー全体を貼り付けます)。<your-account-id>、<region> (IAM Identity Center のプライマリリージョン)、<application-id> (コンソールの [Settings] ページで確認) は、実際の値に置き換えてください。

Figure 4: Account access manager ARN details

図 4: アカウントアクセスマネージャーの ARN の詳細

IAM ロールの信頼ポリシー:

{
  "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 ブロックを定義して、「混乱した代理」問題に対する保護を適用します。これは、サービスの有効化時に作成された特定のアカウントアクセスマネージャーアプリケーションインスタンス (アプリケーション ARN で指定) だけが、そのインスタンスが存在する AWS アカウントから送信されたリクエストの場合に限り、ロールを引き受けられるようにするのに役立ちます。

ベストプラクティス:

ABAC で ID 属性を伝播する – 前述の IAM ロールの信頼ポリシーに含まれる sts:TagSession アクションにより、上流の IdP から渡される属性 (グループメンバーシップ、部署、コストセンター) を、セッションのプリンシパルタグとして引き継ぐことができます。このアクションがなくてもロールの引き受け自体は成功しますが、セッションタグは伝播されません。下流の IAM ポリシーで aws:PrincipalTag/<key> を使用しており、そのタグの値が IdP の SAML クレームから設定される場合は、このアクションを追加してください。それ以外の場合は省略してください。
信頼ポリシーの更新を自動化する – IAM ロールの作成ワークフローを更新し、必要な箇所にこの信頼ポリシーステートメントが自動的に追加されるようにすることをお勧めします。これにより、新しいロールを作成直後から割り当てられるようになります。参考として、sample-aam-migration ツールを利用できます。

ステップ 4: ユーザーとグループにアクセスを割り当てる

IAM Identity Center ロールのエンタイトルメントと同様に、アカウントアクセスマネージャーのエンタイトルメントには、ユーザーまたはグループの ID、アカウント ID、IAM ロール ARN (アクセス許可セット ARN の代わり) の 3 つの要素が必要です。割り当ては、コンソールの [Accounts]、[Users]、[Groups] のいずれかのタブから作成するか、API または AWS CLI を使用して作成できます。同じロールを複数のユーザーに割り当てる場合は、割り当てを 1 つずつ作成する必要があります。この作業は、アカウントアクセス API、AWS SDK、または AWS CLI を使用して自動化できます。

コンソールから割り当てる:

[Users] タブを選択し、ユーザー名または表示名で検索します。
ユーザーを選択し、[Assign new access] を選択します。

図 5: アカウントアクセスマネージャーでの新しいアクセスの割り当て
[Assign account access] ページで、ワークフォースユーザーまたはグループ、アカウント ID、IAM ロール名を入力し、[Assign access] を選択します。

AWS CLI を使用してユーザーを割り当てる:

aws account-access create-entitlement \
  --region <Region> \
  --application-arn "<Account_access_manager_ARN>" \
  --entitlement '{
    "principalRole": {
      "principal": {
        "identityCenter": {
          "userId": "<Identity_Center_User_ID>"
        }
      },
      "roleArn": "arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
    }
  }'

グループを割り当てる場合は、userId ブロックを "groupId": "<IDC_GROUP_ID>" に置き換えます。アクセスを削除するには、エンタイトルメント ID を指定して aws account-access delete-entitlement を実行します。

注:

コンソールではユーザー、グループ、アカウントを検索できますが、IAM ロールは組織内のさまざまな AWS アカウントに存在する可能性があるため、検出できません。ロール名は事前に把握しておく必要があります。

割り当ての対象にできるのは、信頼ポリシーでアカウントアクセスマネージャーが許可されたサービスプリンシパルとして指定されている IAM ロールのみです。

アカウントアクセスマネージャーによって割り当てられた IAM ロールセッションには、各 AWS アカウントで基になる IAM ロールに設定された最大セッション期間 (上限 12 時間) が適用されます。

ステップ 5: ワークフォースユーザーのサインイン方法

ワークフォースユーザーは、アカウントアクセスマネージャーで割り当てられた IAM ロールを使用して、次のいずれかの方法で AWS アカウントにフェデレーションできます。

アカウントアクセスポータル URL から直接アクセスする – ポータル URL (例: https://aa-xxxxxxxxx.account-access.us-east-2.app.aws、またはバニティ URL) にアクセスしてサインインします。
AWS アクセスポータル経由でアクセスする – [Applications] タブで [Account Access] アプリケーションを選択すると、アカウントアクセスポータルにリダイレクトされます。ポータルには、割り当てられたアカウントとそれぞれのロールが一覧表示されます。

ヒント: すばやくアクセスできるように、アカウントアクセスポータルと AWS アクセスポータルの両方をブックマークしておくよう、ユーザーに案内することをお勧めします。さらに、Okta、Microsoft Entra ID、Ping Identity などのサポートされている IdP を使用している場合は、IdP のダッシュボードにアカウントアクセスポータルをブックマークアプリとして追加できます。これにより、ユーザーは日常的にサインインしているツールから、認証済みの状態のままワンクリックでポータルにアクセスできます。

ウェブブラウザからのアクセス

ウェブブラウザからアカウントアクセスマネージャーを使用するには、次の手順に従います。

アカウントアクセスポータル URL にアクセスし、認証情報を使用してサインインします。
ポータルで、目的の AWS アカウントを探します。アカウント名または ID で検索すると、割り当てられているアカウントの一覧を絞り込めます。
アカウントを展開し、引き受け可能なロールを表示します。
ロール (例: [Developer]) を選択します。新しいタブが開き、選択したロールでそのアカウントにサインインした状態になります。

AWS CLI からのアクセス

アカウントアクセスマネージャーは aws login コマンドに対応しています。使用を開始するには、次の手順に従います。

最新の AWS CLI (v2.36.0 以降) をインストールします。
デフォルトのブラウザでサインインします – アカウントアクセスポータルにサインインし、割り当てられたロールのいずれかを使用して対象の AWS アカウントにサインインします。
AWS CLI で、次のコマンドを実行します。
aws login
入力を求められた場合はデフォルトのリージョンを設定します – リージョンを設定していない場合は、AWS CLI からリージョン (例: us-east-2) の入力を求められます。
セッションを選択します – AWS CLI によってブラウザのページが開きます。開始したセッションのタイルを選択します。
確認して CLI に戻ります – 認証情報が正常に共有されたことがページに表示されます。タブを閉じ、セッションの有効期間中は AWS CLI で作業を続けます。

一時的な認証情報は、AWS CLI、AWS Tools for PowerShell、AWS SDK によって自動的にローテーションされ、IAM ロールのデフォルトのセッション期間中は有効です。セッションの有効期限が切れると、ブラウザで再度サインインするよう求められます。

注: aws sso configure などの IAM Identity Center 固有のコマンドは、アカウントアクセスマネージャーの割り当てには使用できません。代わりに aws login を使用してください。aws sso login を引き続き使用したい場合は、「AWS CLI Integration for IAM Account access manager」を参照してください。

特定のコンソール画面へのショートカットリンクを作成する

ポータルでは、特定のアカウントとロールで、コンソールの特定の画面を直接開くショートカットリンクを作成することもできます。ショートカットリンクは、ユーザーに既に割り当てられているアカウントとロールでのみ機能し、新しいアクセスを付与するものではありません。また、URL パラメータは URL エンコードする必要があります。ショートカットリンクはリージョン固有であり、アカウント ID とロール名がプレーンテキストで含まれるため、試す前に組織の共有ポリシーを確認してください。

カスタマーマネージドキーに関する考慮事項

IAM Identity Center インスタンスが AWS Key Management Service (AWS KMS) のカスタマーマネージドキーで暗号化されている場合は、アカウントアクセスマネージャーを有効化する前にキーポリシーを確認してください。なお、IAM Identity Center を追加のリージョンにレプリケートする場合は、カスタマーマネージドキーによる暗号化が必須です。アカウントアクセスマネージャーが IAM Identity Center からユーザー、グループ、インスタンスのデータを読み取れるように、最新のベースライン KMS キーポリシーを適用することをお勧めします。

ベストプラクティスのまとめ

適切な場所で有効化する – アカウントアクセスマネージャーは、組織の管理アカウントにおいて、IAM Identity Center インスタンスと同じリージョンで有効化します。また、作業を開始する前に、組織インスタンスが用意されていることを確認します。
信頼ポリシーの更新を自動化する – アカウントアクセスマネージャーの信頼ポリシーステートメントをロール作成パイプラインに組み込み、手動の作業なしで、すべての新しいロールを作成直後から割り当てられるようにします。
必要な場合にのみ sts:TagSession を追加する – 下流のポリシーでプリンシパルタグを使用する場合にのみ追加します。それ以外の場合は省略し、セッションを軽量に保ち、最小権限を維持します。
個々のユーザーではなくグループにロールを割り当てる – グループ単位でアクセスを付与することで、管理上のオーバーヘッドを削減でき、ユーザーレベルのアクセスの監査可能性も高まります。
管理者のアクセス許可の範囲を厳密に設定する – 機能自体の管理と割り当ての管理を分離し、管理の委任を有効にして、日常的な運用を管理アカウントで行わずに済むようにします。
展開前にポータルのドメインを許可リストに追加する – アクセスが中断されないよう、展開前にアカウントアクセスポータルのドメインとエンドポイントを次世代ファイアウォールまたはセキュアウェブゲートウェイの許可リストに追加します。
ワークフォースユーザーの準備を整える – アカウントアクセスポータルと AWS アクセスポータルの両方をブックマークするようユーザーに案内し、開発者には aws login の流れを明確に伝えます。

アカウントアクセスマネージャーのローンチパートナー

アカウントアクセスマネージャーは、AWS の ID およびアクセスガバナンス分野のパートナーによる幅広いエコシステムとともにローンチされました。これらのパートナーは既存のソリューションにこのサービスを統合しており、AWS とパートナー共通のお客様はローンチ当日から利用できます。主要な IdP である Okta、PingIdentity、Cisco Duo はアカウントアクセスマネージャーを拡張しており、お客様は既に使用している ID プラットフォームから、ワークフォースユーザーによる AWS アカウントへのアクセスを直接管理できます。また、アクセスガバナンスおよび特権アクセス管理のパートナーである Apono、BeyondTrust、Britive、Sonrai Security、C1.ai、Lumos、SailPoint は、お客様が既に活用しているツールを通じて、そのアクセスを統制、プロビジョニング、監査する機能を追加しました。

アカウントアクセスマネージャーは、インフラストラクチャのコード化 (IaC) 分野の主要パートナーとも統合されています。そのため、チームは他の AWS インフラストラクチャと併せて、アクセスの割り当てを宣言的に定義して管理できます。Pulumi を使用すると、既存のプロビジョニングワークフローの一部としてアカウントアクセスマネージャーのロールの割り当てをコード化できるため、大規模なワークフォースアクセスの管理を、再現性がありバージョン管理された形で自動化できます。

まとめ

アカウントアクセスマネージャーは、チームが既に所有している IAM ロールの柔軟性と、IAM Identity Center が提供する一元化された単一のフェデレーションポイントを組み合わせたものです。さらに、組織全体でユーザーやロールが何を行ったかを、ユーザーレベルで可視化します。既存の IAM ロールをユーザーとグループに一元的に割り当てることができ、固定のクォータに縛られることなく、アカウントの使用状況に応じてスケールします。また、開発者は aws login を使用して、高速かつ安全にコマンドラインから作業できます。この機能は追加料金なしで利用でき、商用リージョン (オプトインが必要な商用リージョン、AWS GovCloud (US)、中国、その他の非商用リージョンを除く) ではデフォルトで有効になっています。

アカウントアクセスマネージャーの実際の動作は、有効化の手順を紹介する動画でご確認いただけます。この動画では、サービスの有効化から、IAM ロールの準備、ワークフォースへのアクセスの割り当てまでをひととおり説明しています。また、ローンチパートナーのソリューションを通じてアカウントアクセスマネージャーを拡張することもできます。ローンチパートナーは、このサービスを自社のプラットフォームに統合している主要な ID、アクセスガバナンス、IaC のプロバイダーです。既に活用しているツールを使用して、AWS へのワークフォースアクセスを統制、プロビジョニング、自動化できます。前述のパートナー統合を確認し、ご利用の環境に適したものを見つけてください。

詳細と使用開始の方法については、「AWS Identity and Access Management User Guide」を参照してください。まずはテスト用の組織でアカウントアクセスマネージャーを有効化し、最初のエンタイトルメントを割り当てて、ユーザー単位で追跡できる一元的なアクセス管理によって AWS 環境をどのように簡素化できるかを、ぜひご確認ください。

本ブログは Security Solutions Architect の中島章博が翻訳しました。

Amazon Web Services ブログ