AWS IAM設計書の書き方（サンプル＋解説付き）

はじめに

AWS環境の運用において、IAM設計はセキュリティの土台です。しかし、実務で参考にできるIAM設計書のサンプルはあまり公開されておらず、初めて設計書を作成する際、「何から始めればいいのか？」と悩まれる方も多いのではないかと思います。

そこで本記事では、私がサンプル的に作成したAWS IAM設計書を、各章の目的や活用方法の解説を添えて全文公開してみました。

IAM設計書を作成するうえでの参考資料としてご活用いただければ幸いです。

AWS IAM設計書（サンプル）

1. 文書情報

文書名：AWS IAM設計書
バージョン：1.0
作成者：〇〇
作成日：20YY-MM-DD
更新履歴：

バージョン	日付	変更内容	作成者
1.0	20YY-MM-DD	初版作成	〇〇

文書情報は、設計書について、「いつ」「誰が」「どのような更新を行ったか」を証跡として残すための章です。
監査対応・プロジェクト管理の観点で重要な章になります。

2. 目的

本書は、AWS環境におけるIAM（Identity and Access Management）およびAWS IAM Identity Center（以下、IIC）を用いた権限管理の設計方針を定義することを目的とする。

目的は、設計書が何を目的としたドキュメントであるかを明確にするための章です。
プロジェクト関係者が迷わず参照できる基準点・指針を記載します。

3. 適用範囲

本設計書は以下の環境に適用する。

• AWS Organizations配下の全アカウント
• IICで提供される認証基盤
• IAMロール、IAMポリシー、Permission Set
• ポリシー／ロールの命名規則
• 権限運用ルール（棚卸し・監査）

適用範囲は、設計書がどの環境・どのAWSリソースに適用されるかを明示する章です。
IAM設計の対象範囲を明確にすることで、設計漏れや境界の誤解を防ぎ、監査やレビュー時に判断基準として役立ちます。

4. 設計方針

1. 最小権限の原則（Least Privilege）
   業務に必要な最小限の権限のみ付与する。

2. 人ではなくロールへ権限付与
   個人IAMユーザーは使用せず、IIC経由でロールに権限を渡す。

3. アカウントごとの権限境界を明確化
   開発・検証・本番環境の境界を分離する。

4. インフラ運用ロールとアプリ運用ロールの分離
   権限の混在を防止する。

5. 変更のトレーサビリティ確保
   CloudTrailにより操作ログを記録し、レビュー可能な状態を維持する。

設計方針は、IAM運用の“判断基準”となる原則を定義する章です。
ロールやポリシーを設計する際の基準になり、レビュー時にも一貫した評価軸として役立ちます。

5. アカウント構成（Organizations）

アカウント名	用途
Root	組織の最上位
Security	セキュリティ統制・ログ集約
Shared Services	共通サービス（CI/CD等）
Development	開発環境
Staging	検証環境
Production	本番環境

環境ごとに権限を明確に分離し、必要な操作はクロスアカウントロールで実現する。

アカウント構成（Organizations） は、AWS環境をどのようなアカウントに分け、各環境がどのような役割を担うかを定義する章です。
環境ごとの責任範囲を明確にすることで、運用・監査・セキュリティ設計の方針がブレないようにします。

6. 認証方式（IIC）

6.1 認証

• 利用者は社内IdP（Azure AD / Google Workspaceなど）で認証を行う
• IICと社内IdPを連携し、AWSへのログインはSSO（シングルサインオン）とする
• MFA（多要素認証）を必須化し、セキュリティ強度を確保する
• パスワードポリシーは社内セキュリティ基準に準拠する

6.2 グループ設計

AWS上の権限は、個人ではなくIICのグループ単位で付与する。
これにより以下を実現する。

• 権限管理のばらつき防止
• 異動や退職時の権限削除漏れ防止
• 変更のトレーサビリティ向上

原則：個人にPermission Setを直接付与しない

6.3 グループと権限の設計例

グループ → Permission Set → AWSロールという流れで権限を付与する。

IICグループ名	対象環境	Permission Set	権限内容
AWS-Admin	全環境	AdministratorAccess	全アカウント管理権限
AWS-DevOps	Dev/Staging	PowerUser-DevOps	開発・検証環境のインフラ運用
AWS-ReadOnly	全環境	ReadOnlyAccess	監査・確認用の読み取り専用

認証方式（IIC） は、利用者がどのようにAWSにログインするか（IdP連携・MFA・パスワード基準）を定義する章です。
安全なログイン環境を整えるうえで最も重要な章であり、社内の認証ルールとAWSの統制を統一する役割を担います。

7. 権限付与方式（Permission Set / IAM Role）

7.1 Permission Setの分類

1. Admin権限
2. PowerUser権限
3. ReadOnly権限
4. サービス単位の最小権限（S3運用、Lambda運用など）

7.2 ロール命名規則

<環境>-<機能>-role
例：prod-app-operator-role

7.3 Permission Set命名規則

<権限レベル>-<用途>
例：PowerUser-AppTeam

権限付与方式（Permission Set / IAM Role） は、利用者に付与する権限セット（Permission Set）やIAMロールを、どのようなルールで作成するか定義する章です。
命名規則や権限レベルを統一しておくことで、誰がどの権限を持っているのかが分かりやすくなり、設定ミスや過剰な権限付与を防止します。

8. IAMポリシー設計

8.1 基本ルール

• カスタムポリシーはJSONファイルとしてGitでバージョン管理する
• AWS管理ポリシーは原則使用しない
  • 理由：AWS側のアップデートにより、付与権限が変動する可能性があるため
  • 例外：ReadOnlyAccessなど、安定していて変更影響の少ないものは使用可

8.2 ポリシー命名規則

<環境>-<サービス>-<用途>-policy
例：dev-s3-uploader-policy

8.3 ポリシー内容例

例：最小権限のS3アップロード

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::xxxxx-bucket",
        "arn:aws:s3:::xxxxx-bucket/*"
      ]
    }
  ]
}

IAMポリシー設計は、ポリシーの命名規則・管理方法・最小権限ポリシーの作成方針を標準化するための章です。
標準化により、ポリシーの乱立や権限過多を防ぎ、Gitでの変更履歴管理により監査性と保守性を担保します。

9. 権限レビュー

9.1 レビュー頻度

• 半年に1回
• 本番アカウントは四半期に1回推奨

9.2 レビュー項目

• 不要なPermission Setが付与されていないか
• 管理者権限の使用頻度
• 期限切れのロールはないか
• CloudTrailの異常ログチェック

権限レビューは、利用者に付与されている権限を定期的に見直すためのルールをまとめた章です。
確認の頻度と確認対象項目を明確にすることで、不要な権限の放置や過剰権限を防ぎ、セキュリティ強化と監査対応の両方に役立ちます。

10. 運用ルール

10.1 権限付与フロー

1. Jira / Backlogで申請
2. IAM管理者が内容を確認
3. 適用するPermission Setを決定
4. 付与結果を申請者へ通知

10.2 禁止事項

禁止事項	理由
IAMユーザーの新規作成	認証をIICに集約するため
AWS管理ポリシーの直接付与	AWS側の更新による予期しない権限変更を避けるため
個人への直接Permission Set付与	グループ経由で権限管理を統一するため

運用ルールは、権限付与の流れや禁止事項を明文化し、標準化するための章です。
運用を標準化することで、個々人の判断に左右されない安定した権限管理を実現可能です。

11. SCP（Service Control Policy）の設計

11.1 SCPの目的

• 本番環境での過度なオペレーションを制限
• 必要なIAMリソースのみ許可する

11.2 SCP例

例：本番でEC2のTerminate（削除）を禁止

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyTerminate",
      "Effect": "Deny",
      "Action": "ec2:TerminateInstances",
      "Resource": "*"
    }
  ]
}

SCP（Service Control Policy）の設計は、AWS Organizationsでアカウント全体にかける強制ルールを定義する章です。
SCPは誤操作防止のために重要な仕組みで、本番環境の保護に役立ちます。

12. ログ・監査

12.1 CloudTrail

• 全アカウントで有効化
• 管理イベントは全件、データイベントは必要なサービス（S3 / Lambda 等）を記録
• ログはSecurityアカウントのS3バケットに集約

12.2 IAM Access Analyzer

• 外部公開設定（パブリックアクセス）や不要なクロスアカウントアクセスを検出
• 月次で結果を確認し、必要に応じて修正

ログ・監査は、CloudTrailやAccess Analyzerなどを中心としたログ基盤と、ログの扱い方・確認頻度などの運用方針を定義する章です。
監査証跡の確保やインシデント対応に欠かせない重要な章になります。

まとめ

以上、IAM設計書のサンプルを解説と共に紹介しました。

IAM設計で特に重要なポイントをまとめると、以下の4点になります。

• 権限は個人ではなくロール単位で付与する
• 最小権限・命名規則・変更トレーサビリティを徹底する
• SCPやログ監査で本番環境の安全性を確保する
• 定期的なレビューで不要な権限を削除し、権限の健全性を維持する

より良いIAM設計の参考になれば幸いです。