3.1IAM とアプリの認可

アプリが AWS サービスへアクセスする際、アクセスキーをコードに埋め込むのは厳禁です。代わりに IAM ロール を使い、一時認証情報を安全に受け取ります。

3.1.1コードに権限を与える方法

• IAM ロール：Lambda や EC2 に付与すると、SDK が自動で一時認証情報を取得する。長期キー不要。
• 最小権限：ポリシーで必要な操作（Action）・リソース（Resource）だけを許可する。明示的 Deny は常に優先。
• AssumeRole（STS）：別アカウントや別ロールの権限を一時的に引き受ける（STS が一時認証情報を発行）。クロスアカウントアクセスの定番。
• ポリシーの種類：アイデンティティベース（ユーザー/ロールにアタッチ）とリソースベース（S3 バケットポリシー等）。両者の評価で可否が決まる。

DVA-C02 の「セキュリティ」で最重要なのは「アプリにアクセスキーを埋め込まない」ことです。Lambda や EC2 には IAM ロール（実行ロール）を付与し、SDK が自動で一時認証情報を取得します。権限は最小権限で、必要な Action と Resource だけを Allow にし、評価では明示的な Deny が常に勝つ点を押さえます。別アカウントや別ロールの権限が必要なときは STS の AssumeRole で一時的に引き受けます（キーの受け渡しは不要）。ポリシーにはアイデンティティベース（ロール/ユーザーにアタッチ）とリソースベース（S3 バケットポリシー等）があり、両方の評価でアクセス可否が決まります。誤り選択肢の定番は「アクセスキーをコードや環境変数に平文で置く」です。

もう一段細かく見ると、ポリシーの評価には順序があります。まず明示的 Deny があれば即拒否。次にいずれかの Allow があり、かつ Deny が無ければ許可。デフォルトは暗黙的な拒否です。条件キー（Condition） を使えば「特定の IP からのみ」「MFA 必須」「タグが一致する場合のみ」といったきめ細かな制御ができます。アクセス許可境界（Permissions Boundary） は、ロール/ユーザーが持てる権限の上限を定め、開発者が自分用ロールを作るときの過剰付与を防ぎます。ポリシーは AWS 管理ポリシー・カスタマー管理ポリシー・インラインポリシーの3種があり、再利用や監査のしやすさからカスタマー管理ポリシーが推奨されます。Lambda では実行ロールに加えて、リソースベースポリシーで「どのサービス（S3・API Gateway 等）が関数を呼べるか」を制御する点も押さえます。

3.1.2この節のまとめ

• アプリの認可＝IAM ロール（一時認証情報）、キーは埋め込まない
• 最小権限＋明示的 Deny 優先、クロスアカウントはSTS AssumeRole、ポリシーはアイデンティティ/リソースの両評価