![[アップデート]AWS IAM Identity CenterによるAWSアカウントのアクセス管理がオプションとなり、アプリケーションへのアクセス専用で使えるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-14065d3d54d195fc74d726c1950f7e3a/c847507d538044ec935625e716d204aa/aws-iamidentity-center?w=3840&fm=webp)
[アップデート]AWS IAM Identity CenterによるAWSアカウントのアクセス管理がオプションとなり、アプリケーションへのアクセス専用で使えるようになりました
初めに
先日のアップデートでAWS IAM Identity Centerで従来必須となっていたAWSアカウントへのアクセス管理設定を任意とできる設定が追加されました。
IAM Identity Centerは従来ではAWSのアカウントへのアクセス権限の管理に加えて、AWS管理アプリケーションや外部アプリでSSOを利用したい場合のIdPとして利用することができました。
KiroやAmazon Managed Grafanaなど一部のサービスはユーザの管理のためにIAM Identity Centerもしくは外部IdPでのユーザ管理が必須となっていたためAWSアカウントへのアクセス管理は不要ではあるものの既存のIdPを保持していない等で利用していたケースもあるのではないでしょうか。
従来ではそういったケースでもAWSアカウントへのアクセス管理機能がついてきてしまうため、経路を塞ぎたい場合はSCPなり管理者のポリシーで機能を利用できないように塞ぐ必要がありました。
今後はIAM Identity Center側の機能でAWSアカウントへのアクセス管理機能をOFFにし他の場所での設定を入れなくとも実現できるようになります。
有効にできるのは組織インスタンスの有効化時のみ
本機能は新規に作成する組織インスタンスのみが対象となり、既存の組織インスタンスでは利用できないものとなります。
これは本設定はUpdateInstanceにより切り替え可能ですが、AWSアカウント管理の許可は後から「有効」にすることのみができ、無効化はできないためです。
https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_UpdateInstance.html
Enables permission sets for this Identity Center instance. The only accepted value is true . After permission sets are enabled, they cannot be disabled.Note
You can't set EncryptionConfiguration and PermissionSetsEnabled in the same request. To configure both, make two separate UpdateInstance calls. These calls can be made in parallel.
そのため既に組織インスタンスをご利用いただいている方が本機能を利用する場合は一度無効化した上で再度設定し直す必要がありそれなりの移行コストが発生するためご注意ください。
AWSアカウントへのアクセスを無効化して作成してみる
さて実際に無効化した状態で作成してみましょう。
作成については通常通りマネジメントコンソールの案内に従って作成するのですが、現時点では事前に用意されているプリセットではアカウントアクセスが有効化されてしまうため、カスタムインスタンスで作成します。
ここで「マルチアカウントのアクセス許可を有効にする」をOFFにして作成します。
無効化して作成できていると「マルチアカウントのアクセス許可」がない形で有効化される形になります。
ユーザ情報もタブに本来であればAWSアカウントというタブがあり、ここでユーザやグループがどのアカウントにアクセスできるかが確認できるのですが、
AWSアカウントのアクセス管理を無効化している場合は表示がなくなります。
無効化されているAWSアカウントのアクセス管理はインスタンスの設定から有効化可能です(もしくはCLI)。
有効化前に注意書きも出ますが一度有効化すると無効状態には戻せず、万が一無効化したい場合はインスタンスを削除するしかないためご注意ください。
さっきの画面どこかで見覚えが...？
先ほどの左メニューやユーザ画面どこかで見覚えが...？という方もいらっしゃるかと思いますが...そうですアカウントインスタンスと同じですね。
アカウントインスタンスもAWSのアカウントへのアクセスを許可を管理せずにAWSマネージドアプリケーションのID基盤としてのみ利用するため、そういう意味では近いものがあります。
では組織インスタンスを使う意味はないのでは？となるかもしれませんがそんなことはありません。
アカウントインスタンスではそのアカウント内のAWSマネージドアプリケーションの認証のみに利用可能ため、アプリケーションが複数アカウントに分かれている場合は活用が難しいものとなっておりました。
また連携できる対象もAWSマネージドアプリケーションのみ(外部アプリとのSAML連携はNG)、AWSマネージドアプリケーションでも一部ものはアカウントインスタンス非対応といった形で機能的に制限はありました。
組織インスタンスであればこの辺りの制約を受けずに利用可能となります。
終わりに
AWSアカウントへのアクセスを管理しない形での組織インスタンスの設定を確認してみました。
アカウントインスタンスでも似たようなことはできますが、アカウントを跨いでAWSアプリケーションを利用する場合や外部のサービスとのSAML連携といった組織インスタンスにしかできないメリットを受けられるのは強みではあります。
一方、既に有効化されている組織インスタンスから切り替えたい場合は一度無効化しないといけないためユーザやグループの再作成、アプリケーションの再連携と手間も多いですし、このためにOrganizationsを組むのもオーバースペックな感じにはなりそうです。
とは言いつつ前述の通りAWS管理アプリケーションでも一部は組織インスタンスもしくは外部IdPを構える必要がありつつも、別のサービスを選定するのもなぁ...というケースもあるかと思いますのでOrganizationsは入れていてまだ使ってないけど組織的に需要は出てるようなケースには検討してみても良いのではないでしょうか。
