導入
「EC2インスタンスにアクセスキーを設定してS3にアクセスする」——これはよくある初心者の実装ですが、SAAでは不正解です。正解は「ロールを付与する」ことです。なぜロールが安全なのかを理解しましょう。
説明
IAMロール は、ユーザーではなく「誰か・何かが一時的に引き受ける権限のセット」です。ロール自体はパスワードやアクセスキーを持たず、STS（Security Token Service） が発行する 一時的な認証情報（有効期限付きのアクセスキー・シークレットキー・セッショントークン）を使って権限を行使します。
ロールを引き受ける操作を AssumeRole と呼びます。
sequenceDiagram
participant E as "EC2インスタンス"
participant S as "STS"
participant B as "S3バケット"
E->>S: "AssumeRole（ロールを引き受ける）"
S-->>E: "一時的な認証情報（有効期限あり）"
E->>B: "一時的な認証情報でアクセス"
代表的な使い方が インスタンスプロファイル です。EC2インスタンスにIAMロールを直接アタッチすると、インスタンス内のアプリはアクセスキーを一切持たずに、自動的に一時認証情報を取得してAWSサービスを呼び出せます。
| 方式 | アクセスキーの管理 | 有効期限 | SAAでの評価 |
|---|---|---|---|
| アクセスキーを埋め込む | 手動（漏洩リスク・ローテーション必要） | 恒久（自分で失効させない限り有効） | 原則不正解 |
| ロール（インスタンスプロファイル） | 不要（AWSが自動管理） | 一時的（自動更新） | 推奨される正解パターン |
同じ理由で、Lambda関数には 実行ロール、ECSタスクには タスクロール を付与し、いずれもアクセスキーを持たせません。
具体例
なぜロールが安全なのかを、実際に起きうる事故で考えます。
ある会社が、EC2上のアプリからS3へアクセスするために、アクセスキーをアプリの設定ファイルに書き込んでいました。ある日、その設定ファイルが誤って公開GitHubにコミットされ、キーが外部に流出。攻撃者はその恒久的な鍵で、深夜に大量のリソースを不正起動しました。鍵は自分で失効させない限りずっと有効だったため、被害が広がりました。
ロール（インスタンスプロファイル）に置き換えると、この事故は起きません。
- EC2にロールを付けると、アプリはアクセスキーを一切持たず、必要な時にSTSから有効期限つきの一時認証情報を自動取得してS3を呼ぶ
- 一時認証情報は自動で更新・失効するので、GitHubに漏らす“恒久的な鍵”がそもそも存在しない
- 権限を変えたいときも、コードを触らずロールのポリシーを直すだけ
だからSAAでは「EC2/Lambda/ECSがAWSサービスにアクセスする」と来たら、反射的にロールを付与。選択肢にある「アクセスキーを埋め込む」は引っ掛けだと考えて構いません。
読んでみよう
「EC2/Lambda/ECSがAWSサービスにアクセスする必要がある」という問題文が出たら、反射的に「ロールを付与する」を選んでください。アクセスキーの直接管理が選択肢にあっても、それは不正解を誘う”引っ掛け”だと考えて構いません。