IAMユーザー・グループ・ロール・ポリシーの全体像

IAMのユーザー・グループ・ロール・ポリシーを、本人確認と操作の許可という二つの段階から整理します。

この単元で学ぶこと

  • 四つのIAM要素の役割を説明する
  • 認証情報と権限を区別する
  • 人とアプリに合うアクセス方法を選ぶ

本文解説

1. 誰かと何をできるか AWSへ接続するときは、要求者が誰かを確認する認証と、その操作を認める認可を分けます。コンソールへ入れたことは、すべてのS3バケットを読めることを意味しません。ログイン成功後でも操作の権限は評価されます。

2. IAMユーザー IAMユーザーは一つのAWSアカウント内に作成するIDです。必要ならパスワードやアクセスキー等を設定できます。作成しただけで全権限を得るわけではなく、認証方法と許可する業務を別々に決めます。

3. グループ IAMグループは複数のIAMユーザーへ共通の権限を管理する集合です。監査担当者をAuditグループへ入れて閲覧権限を配る例があります。グループとしてログインしたり、グループ用アクセスキーを発行したりはしません。

4. ロール IAMロールは、人・アプリ・AWSサービス等が条件に従って引き受けるIDです。固定の長期キーをロールへ作るのではなく、セッションの一時的認証情報を使います。EC2アプリがS3を読むなら、ロールを利用して長期キーの埋込みを避けます。

5. ポリシー ポリシーは許可や拒否を表す文書です。例えばGetObjectをreports/のオブジェクトへ許すように、操作と対象を絞ります。ポリシーは利用者本人や認証情報ではなく、何を許すかの規則です。

6. ロールには二つの問い 信頼ポリシーは誰がロールを引き受けられるか、権限ポリシーは引受け後に何をできるかを扱います。EC2が引き受けられるだけではS3読取り許可は完成しません。必要なS3操作の許可も設計します。

7. 人とアプリの推奨 従業員アクセスにはIAM Identity Center等のフェデレーションと一時的認証情報を検討します。IAMユーザーの知識は既存環境や対応できない用途の判断にも必要ですが、新規従業員へ長期キーを一律配布することを基本にしません。

8. 安全性を確認する MFAは本人確認を強め、最小権限はできる操作を絞ります。両者の役割は異なります。認証できること、必要な操作が成功すること、不要な操作が拒否されることを別々に確かめ、使われなくなったIDやキーを見直します。

図解

IDと権限を分ける
グループ・ロール・ポリシーは、同じ認証情報の別名ではありません。

重要ポイント

  • 認証と認可を分ける。
  • グループはユーザー集合、ロールは引受けるID。
  • ポリシーは許可・拒否の規則であり認証情報ではない。

間違えやすい点

  • グループへロールを入れると考える。
  • ロールに固定アクセスキーを作ると考える。
  • MFAで過大な権限まで自動縮小されると思う。

用語解説

認証
要求する主体が誰かを確認すること。
認可
要求操作が許可されるかを判断すること。
ロールセッション
ロールを引き受け、一時的認証情報で活動する期間。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。