AWSアカウント払い出しですが、毎回、ユーザーを追加するたびに権限の設定をしていては管理が大変です。そこで、安全かつ運用が楽なIAM設計をまとめてみました!
本ドキュメントの目的と適用範囲
目的
- AWS Organizations 配下でのアカウント払い出しを標準化し、権限の属人化と運用負債（IAMユーザー乱立・棚卸し困難）を防ぐ
- 人のアクセスはIAMユーザーではなく IAM Identity Center（SSO）で統一し、最小権限を実運用できる形に落とす
- OUにより 環境境界（dev/stg/prod 等)を用意する
適用範囲
- 社内の AWS Organizations 配下の全アカウント(DEV環境/STG環境/PROD環境)
- 人間ユーザーの認証・権限付与（SSOグループ / Permission Set / Account Assignment）
1. AWS アクセス設計思想 / SSO中心運用
1.1 目指す内容
- 人間のアクセスは IAMユーザーではなく AWS IAM Identity Center（SSO）で統一
- 権限付与は 個人ではなく「グループ」単位
- アカウントは 環境・用途ごとに分離（dev/stg/prod 等）し、Organizations/OUで統制
- アカウント内で利用される権限は Permission Set（= SSOが払い出すIAM Role） で定義
1.2 期待する効果
- 入退社/異動時の変更が SSOグループのメンバー変更だけで完結
- 権限が個人依存にならず、役割（ロール）として再利用できる
- アカウント分離で事故影響範囲を限定（prod誤操作抑止など）
1.3 全体アーキテクチャ
1.4 Organizations / OU / アカウント設計
1.4.1 Organizations 前提
- 組織で使う基盤サービス（例：Identity Center / CloudTrail / Access Analyzer 等）のOrganizations連携を有効化（必要に応じて）
1.4.2 OU設計思想
OUは「用途」で分け、下に環境をぶら下げます。
-
service：プロダクト/サービスの環境アカウント
service/prodservice/stgservice/dev
1.4.3 アカウント分離の思想
- 環境別（prod/stg/dev)でアカウントを分ける
- Organizations は All features（すべての機能）
- これにより「権限が強すぎる人がprodへ誤操作」などの事故を 境界で抑止しやすい
1.5 IAMユーザーの扱い
1.5.1 原則
- 人間用のIAMユーザーは作らない
- 認証はSSO、権限はPermission Setで払い出す（アカウント内ではRoleで実行）
1.6 SSOグループ設計（権限の入口は「グループ」）
1.6.1 グループは「プロダクト × 役割」
- 誰に何を付けるべきかが判断しやすい
- 異動・増員・退職の処理が簡単
-
SSOグループ：グループに役割を与える
- education-DEV-Administrator
- education-DEV-ReadOnly
- education-DEV-Developer
- education-DEV-Operator
1.7 Permission Set（役割定義）の標準
Permission Setは「ロールのカタログ」。個人ではなく ロール単位で設計します。
標準セット（最低限）
| Permission Set | 目的 | 付与対象 |
|---|---|---|
| AdministratorAccess | 緊急対応・基盤変更・権限設計変更 | 管理者・リーダー |
| OperatorAccess | 日常運用（監視、再起動、デプロイ補助） | 運用担当 |
| DeveloperAccess | 開発・デプロイ・調査（開発者向け） | 開発担当 |
| ReadOnlyAccess | 参照専用（監査、状況確認） | 操作の必要ない関係者 |
1.8 Account Assignment（割り当ての原則）
- SSO Group × Permission Set × Target Account の組み合わせで割り当てる
- 追加/変更時の原則：
- 人を増やす → SSOグループへ追加（権限定義は触らない）
- 権限を変える → Permission Setを変更（メンバーは触らない）
- 対象アカウントを増やす → Account Assignmentを追加
1.9 アンチパターン
- 個人IAMユーザーを量産し、各アカウントにポリシー直付け
- 権限不足のたびに個人へAdminを付与
- グループ命名がバラバラで、担当者しか分からない
2. 標準テンプレート（命名規則 / Permission Set標準 / SCP注意点）
2.1 命名規則（必須）
2.1.1 SSOグループ命名（標準）
<product> <env> <role>
-
<product>：プロダクト名（例：xxxx） -
<env>：Prod / Stg / Dev / DevOps -
<role>：Administrator / Operator / Developer / ReadOnly
例：
xxxx Dev Developerxxxx Prod Operator
2.1.2 Permission Set命名（標準）
AdminAccessOperatorAccessDeveloperAccessReadOnlyAccess
（増やす場合は乱立防止のため、原則「追加は審査」）
2.1.3 AWSアカウント命名（標準）
<org>-<product>-<env> または <product>-<env>
例：
xxxx-devxxxx-stgxxxx-prod
2.2 Permission Setの実装ガイド
2.2.1 AdminAccess
- AWS管理ポリシー：
AdministratorAccess - 付与：最小人数 + ブレイクグラス運用
2.2.2 ReadOnlyAccess
- AWS管理ポリシー：
ReadOnlyAccess
2.2.3 OperatorAccess
- ベース：
ReadOnlyAccess - 追加：運用に必要な操作だけをインラインで許可
追加するインラインポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"account:*",
"aws-marketplace:*",
"aws-marketplace-management:*",
"billing:*",
"budgets:*",
"cloudtrail:*",
"config:*",
"consolidatedbilling:*",
"directconnect:*",
"ec2:*ReservedInstances*",
"freetier:*",
"iam:*Group*",
"iam:*Login*",
"iam:*User*",
"invoicing:*",
"payments:*",
"tax:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"acm:*",
"apigateway:*",
"cloudfront:*",
"dynamodb:*",
"ec2:*",
"ecr:*",
"ecs:*",
"elasticache:*",
"elasticloadbalancing:*",
"es:*",
"events:*",
"iam:*",
"kms:*",
"lambda:*",
"logs:*",
"rds:*",
"route53:*",
"s3:*",
"secretsmanager:*",
"servicediscovery:*",
"ses:*",
"ssm:*",
"states:*",
"wafv2:*",
"iot:*",
"apprunner:*",
"amplify:*"
],
"Resource": "*"
}
]
}
まとめ
いかがでしたでしょうか？個人的には、担当者追加のたびにIAMユーザーを発行しアクセスキーを管理する運用は、手間もリスクも増えやすいため、基本はSSO（AWS IAM Identity Center）での認証・権限管理が扱いやすいと考えています。
もちろんSSOは「便利な反面セキュリティは大丈夫？」という懸念もありますが、最小権限を前提に、役割ごとのグループ（例：管理者・リーダー／運用担当／開発担当）にPermission Setを割り当て、MFAや監査ログ（CloudTrail等）とセットで運用することで統制しやすくなります。
また、人の操作はSSO、システム間連携はIAM Role（必要に応じてOIDC等）と使い分けることで、アクセスキー配布を最小化できます。
まだ改善の余地はあると思いますが、今後も運用しやすく安全なAWS設計を継続的にアップデートしていきたいと思います。興味のある方は参考にしてみてください！