導入
「とりあえず動くように」とルートユーザーのアクセスキーをアプリに埋め込む——これは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」のどれかが答えの方向性になります。
具体例
新人エンジニアが「早く動かしたい」一心で作った構成と、SAA的に正しい設計を対比してみましょう。
アンチパターン（不正解）：急いでいたので、ルートユーザーのアクセスキーを発行し、AdministratorAccess（全権限）を付けたIAMユーザーを1つ作って、その鍵をチーム全員で共有。EC2アプリのコードにもその鍵を直書き。
この設計の何が危ういか——鍵が1本漏れれば全リソースを乗っ取られ、誰が何をしたかも追えず、ルートまで危険にさらされます。
正しい設計：
- ルートユーザーはMFAをかけてしまい込み、普段は使わない
- 開発者にはそれぞれ最小権限のIAMユーザー（＋MFA）。「S3のこのバケットだけ」のように業務に必要な範囲に絞る
- EC2アプリには鍵を直書きせず、次のレッスンのロールを付与する
SAAの問題文に「アクセスキーを直書き」「AdministratorAccessを付与」という記述が出たら、それは不正解を誘うサイン。答えは「最小権限」「ロール」「MFA」の方向にあります。
読んでみよう
「アクセスキーをコードやEC2に直接埋め込んでいる」という記述が問題文にあれば、それ自体が”アンチパターン”のサインです。レッスン8で学ぶロールに置き換えるのが定番の解答パターンだと覚えておいてください。