AWS IAM
AWS IAMとは
IAM(Identity and Access Management)は、[[AWS]]上の「誰が」「何に対して」「何をしてよいか」を管理する仕組みです。IAMなしにはAWSのどのサービスも安全には使えないため、AWSを扱ううえで最初に理解すべき基盤のひとつです。
登場する要素はシンプルです。
| 要素 | 役割 |
|---|---|
| ユーザー / ロール | 「誰が」に相当する主体。人間のユーザーだけでなく、プログラムやAWSサービス自体もロールを持てる |
| ポリシー | 「何に対して・何をしてよいか」を[[JSON]]形式で記述した許可・拒否のルール |
| 実行ロール | プログラムやサービスが処理を実行する際に一時的に引き受ける権限のまとまり |
たとえば「S3のこのバケットの、このプレフィックス配下だけ読み取り・書き込みを許可する」といった細かい粒度でポリシーを書けます。逆に言えば、明示的に許可されていない操作はデフォルトですべて拒否されます([[最小権限の原則]])。
実行ロールという考え方
AIエージェントやバッチ処理のようにプログラムが自律的に動く仕組みでは、そのプログラム専用の実行ロールを用意し、そこに必要最小限の権限だけを割り当てるのが基本設計です。
- 読み取り専用でよい処理には読み取り権限だけを与える
- 書き込みが必要でも、対象を特定の[[Amazon S3]]プレフィックスに限定する
- 「万一エージェントが誤動作しても、実行ロールの権限を超える操作はできない」という状態を作るのが目的
人間の管理者アカウントとプログラムの実行ロールを同じ権限で運用しないことも重要です。人間には広い権限、プログラムには狭い権限、という分離が基本です。
初学者向けポイント
- IAMは「認証(誰であるか)」と「認可(何をしてよいか)」の両方を扱いますが、実務で設計に頭を使うのはほとんど認可(ポリシー)側です([[認証と認可]]参照)
- 動作確認のためだけに広い権限を付け、そのまま本番稼働させてしまうのはよくある失敗です。動かない原因を都度絞り込みながら権限を足していくほうが安全です
- APIキーやアクセスキーを直接コードに埋め込むのはアンチパターンです。IAMロールと[[シークレット管理]]の仕組みを組み合わせて管理します
関連技術とのつながり
- [[AWS]] — IAMが管理対象とするクラウド基盤
- [[最小権限の原則]] — IAMのポリシー設計が実践する中核原則
- [[認証と認可]] — IAMが担う2つの機能のうち「認可」側の実装
- [[シークレット管理]] — IAMロールと組み合わせて使う認証情報の管理手法
- [[Amazon S3]] — IAMポリシーで細かくアクセス制御される代表的なリソース
- [[短期クレデンシャル]] — 実行ロールが「一時的に」権限を引き受けられるのは、裏で期限付きの認証情報が自動発行・自動更新されるため
Q: IAMのポリシーで明示的に許可されていない操作はどう扱われる?
- [x] デフォルトですべて拒否される
- [ ] デフォルトですべて許可される
- [ ] 管理者にのみ確認メールが送られる
解説: IAMは「許可リスト方式」であり、明示的な許可がなければ操作はできません。
Q: プログラム専用の「実行ロール」を用意する目的として正しいのはどれ?
- [x] 誤動作した場合でも影響範囲をその実行ロールの権限内に限定するため
- [ ] プログラムの実行速度を上げるため
- [ ] AWSの利用料金を無料にするため
解説: 人間の広い権限とプログラムの狭い権限を分離し、事故の被害範囲を小さくします。
Q: APIキーの扱いとして本文が「アンチパターン」としているのはどれ?
- [x] アクセスキーを直接コードに埋め込む
- [ ] IAMロールを使って一時的な権限を付与する
- [ ] シークレット管理の仕組みと組み合わせて運用する
解説: キーの直書きは漏洩リスクが高く、IAMロールやシークレット管理と組み合わせるのが基本です。