OU (Organizations Unit) 再構成後に Temporary elevated access management (TEAM) for AWS IAM Identity Center のリクエスト作成時にアカウントが選択できなくなった

OU (Organizations Unit) 再構成後に Temporary elevated access management (TEAM) for AWS IAM Identity Center のリクエスト作成時にアカウントが選択できなくなった

2026.01.03

いわさです。

AWS Organizations を使っていると OU (Organizations Unit) の再設計などで階層などを再構築することがあると思います。
RAM やリソースベースポリシーなどいくつかの AWS の機能では OU を指定することがあって、その場合は OU の再構築時に影響が出る場合があり注意が必要です。

IAM Identity Center の許可ポリシーを使ってマルチアカウントの権限管理を行う場合、Temporary elevated access management (TEAM) for AWS IAM Identity Center という AWS 公式がメンテナンスしているオープンソースソリューションを導入することで、利用者からの権限昇格リクエストを受けて管理者が一時的な権限昇格を許可する運用が可能です。

https://aws-samples.github.io/iam-identity-center-team/

この TEAM を運用している時に、先述の OU 再構築が影響する場合があることに気が付きました。
仕様上当たり前ではあるのですが、ネイティブの AWS サービスではない TEAM を触ったことがない方も多いと思いますので紹介します。

TEAM for IAM Identity Center の権限昇格リクエスト

TEAM for IAM Identity Center ですが、これは IAM Identity Center のカスタムアプリケーションになります。
実体は AWS Amplify でホスティングされているアプリケーションで、認証は IAM Identity Center と IdP 統合された Cognito ユーザープールが使われています。

A94445A9-0108-432E-B386-A1FEE989A511.png

そのため、TEAM for IAM Identity Center にアクセスできるのは IAM Identity Center のカスタムアプリケーションで割り当てられたユーザーのみです。

A9B3E9BC-00BC-42C9-830C-F1640F4649D9_4_5005_c.jpeg

割り当てられたユーザーであれば、AWS Amplify アプリケーションのドメインから TEAM のポータルサイトにアクセスすることができます。
そしてログイン後は、次のメニューから昇格リクエストを作成することができます。

image.png

事前に TEAM の管理者権限から対象ユーザーにポリシーを割り当てられていれば次のようにリクエスト時に対象アカウントを選択することができます。

709E657D-9E21-4F52-8EB7-37C0B4572E3C.png

この権限リクエストを管理者が承認すると次のように一時的に AWS アカウントへのアクセス権限が付与されます。

C5578C61-8DF0-44CF-9111-C46A33A63817.png

内部的には IAM Identity Center のマルチアカウント許可機能によって対象ユーザーが対象アカウントの許可セットが割り当てられる感じです。

923E9B3B-18E7-4AF1-B2B7-5CFDC551F165.png

OU 変更後にリクエストが作成できなくなってしまった

AWS Organizations を使っていると複数のアカウントと Organizations Unit (OU) という階層で管理することができます。
先日ちょっとした理由でこの OU の階層を変える必要が生じました。

具体的にはアカウント1〜4が hogeOU-A という OU 配下に存在していたのですが...

8DEF8C8A-3080-43FC-8148-A01F7ECF2977.png

次のように別の OU に移動させました。

9973B336-C81E-46AD-B9F4-821675A124F9.png

この後から、TEAM 上で昇格リクエストを作成する際にアカウントリストからアカウントが選択できなくなりました。短時間のローディングののちNo eligible accounts foundと表示されます。

F3E2BEFF-D1BE-4E59-B2EF-B6447D6A262F.png

ポリシーでの OU 指定を変更する

これは TEAM for IAM Identity Center の管理者権限で Approver policy や Eligibility policy をメンテナンスしている方からすると当たり前の事象ではあるのですが、ポリシー側で OU 指定が出来るので、その場合に OU 再構築によって影響がでました。

TEAM for IAM Identity Center では、IAM Identity Center のユーザーやグループごとに、「どのアカウントに対して、どの許可セットをリクエストできるか」を Eligibility Policy というポリシーで定義します。

9A13AE57-021F-4726-9439-8C59F46460BF.png

このポリシー、アカウントが多くなかったり OU 設計がされていない場合は次のようにアカウントを直接指定することが多いと思います。

image.png

しかし、今回使った環境では OU 運用が行われており、かつルート OU ではなくて特定の OU のみに制限してポリシーを当てたかったので次のように特定の子 OU のみをポリシーで直接指定していました。

FC7C984D-3693-4C88-80B0-C987528F8A9C.png

そのため、対象 OU から別 OU にアカウントが移動されたことで、昇格リクエストの際に表示できるアカウントがなくなってしまっていた感じですね。
なので、解決方法としては移行先の OU をポリシーで再指定してあげる形になります。

C76C5A6D-FB01-43D2-9EF6-F07873F19A70.png

Eligibility Policy の再設定後、次のようにアカウントリストが表示され、リクエストを作成できるようになりました。

B025386E-186B-4586-8673-E6B6649AEB1D.png

同様に Approver Policy でも OU の指定が可能なので、承認側でも OU 変更によって挙動の変化が発生した場合はポリシー設定を見直してみると良さそうです。

さいごに

本日は OU (Organizations Unit) 再構成後に Temporary elevated access management (TEAM) for AWS IAM Identity Center のリクエスト作成時にアカウントが選択できなくなったので原因を調べて対応をしてみました。

OU 再設計は既存アプリケーションの挙動に影響がでる場合があって、こういったカスタムアプリケーションでも OU を指定している場合があるので注意が必要ですね。

この記事をシェアする

FacebookHatena blogX