導入
「とりあえず動くように」とルートユーザーのアクセスキーをアプリに埋め込む——これはSAAでは確実に不正解です。まず、IAMの基本要素と、SAA全体を貫く設計原則を復習しておきましょう。
説明
IAMには4つの基本要素があります。
| 要素 | 役割 |
|---|---|
| ユーザー（User） | 個人やアプリを表す恒久的なID |
| グループ（Group） | ユーザーの集まり。ポリシーをまとめて付与する単位 |
| ロール（Role） | 誰か・何かが「一時的に」引き受ける権限のセット |
| ポリシー（Policy） | 「何を許可/拒否するか」を定義したJSONドキュメント |
flowchart LR
U["ユーザー"] -- 所属 --> G["グループ"]
G -- アタッチ --> P["ポリシー"]
R["ロール"] -- アタッチ --> P
U -. 引き受ける .-> R
SAAで繰り返し問われる設計原則は次の3つです。
- 最小権限の原則（Least Privilege）：必要な操作・リソースにだけ権限を絞る。「とりあえずAdministratorAccess」は不正解の典型パターン
- ルートユーザーは使わない：ルートユーザーは請求方法の変更など特別な操作のみに使い、MFAを必ず有効化して普段はしまっておく。日常業務はIAMユーザー/ロールで行う
- MFA（多要素認証）の徹底：特に強い権限を持つユーザーには必須
SAAの問題文に「セキュリティを強化しつつ運用の手間を最小化したい」とあれば、まず「最小権限」「ロールの活用」「MFA」のどれかが答えの方向性になります。
読んでみよう
「アクセスキーをコードやEC2に直接埋め込んでいる」という記述が問題文にあれば、それ自体が”アンチパターン”のサインです。レッスン8で学ぶロールに置き換えるのが定番の解答パターンだと覚えておいてください。