IAM Identity Center 設計は AWS アカウント構成から順に考える

Posted at 2026-02-23

IAM Identity Center ではユーザー、グループ、AWS アカウント、許可セット、とリソースがたくさんあります。
これらはどのような設定、構成であれば望ましいのでしょうか？

設計思想についてまとめてみました。

1. アンチパターン

設計なく進めてしまうと、このあたりはやりがちになると感じました。

これらは、アカウントのスケールに対応できない、過剰権限に繋がる、などのリスクを抱えています。

例えばこんな問題に直面することになるかもしれません。

それではどのように考えて進めていったらよいのでしょうか？

Identity Center はユーザーから考えたくなりますが、実際は逆です。
以下の順で考えていくと綺麗な流れなのではないかと思います。

順を追って見ていきます。

マルチアカウントの構成を検討します。
多くが AWS Organizations の設計に準ずることになるかと思います。

アカウント分離の例

何ができるか、という役割ベースで作っていきます。
ただし必要な権限を逐一カスタムで作成していては、作成も管理も煩雑です。

そこで、AWS が事前定義した許可ポリシーを利用して、許可セットを作成することができます。
まずは AWS 管理ポリシーをベースに始め、必要に応じてカスタマイズしていくのが現実的だと思います。

以下のようにリソース全体にアクセスする共通ポリシーから、特定の職務を想定したポリシーまで揃っています。

どのアカウントに対してどの役割を持つか、枠となるのがグループです。
管理アカウントと本番アカウントは、その他のアカウント (検証、開発など) とは重要度が変わってくるため、操作権限を持たせるグループは別に作成しています。

アカウント	Admin グループ	Power グループ	ReadOnly グループ
管理	mgmt-admin	なし	all-readonly
本番	prod-admin	なし	all-readonly
その他	nonprod-admin	nonprod-power	all-readonly

また、実際の設定時に AWS アカウントに対してグループと許可セットを割り当てるのですが、それぞれ複数選択して一括で割り当てることができます。
しかし全ての「AWS アカウント」x「グループ」x「許可セット」の組み合わせが登録されてしまうため、意図した設定になっているかは慎重になる必要があります。

例えば、グループに all-readonly と prod-admin、許可セットに AdministratorAccess と ReadOnlyAccess を設定して一括割り当てをしたとします。

すると、all-readonly グループにも AdministratorAccess の権限が割り当てられてしまいます。
つまり、チェックボックスで選択した組み合わせはすべて登録されます。

これでは閲覧ユーザーが管理者権限でログインできてしまうことになります。

便利な一括割当ですが、管理アカウントや本番環境への適用は慎重に行いましょう。

ユーザー単位では権限を割り当てず、どのグループに所属するかのみを管理します。
入社や退職によるユーザーの変動は、グループへの追加と除外で対応します。

IAM Identity Center の設計について、改めてまとめると以下のポイントとなります。

ユーザーは最後に所属させるだけ。
設計の中心は常に「アカウントと役割」にあります。

Identity Center は単なるユーザー管理サービスではなく、マルチアカウントのアクセス設計基盤とも言えます。
スケールを前提とするサービスであるため、設計がより一層大切になると実感しました。

今日も小さな学びを。