IAMユーザーを理解する

IAMユーザーのID、コンソールパスワード、アクセスキー、許可ポリシーを区別し、必要な用途だけに管理します。

この単元で学ぶこと

  • ユーザーのIDと認証情報を区別する
  • 認証成功と操作権限の関係を説明する
  • 長期認証情報の必要性と管理を判断する

本文解説

1. ユーザーというID IAMユーザーはAWSアカウントに作成するIDで、名前と識別子を持ちます。AWSアカウントのrootユーザーとは別です。管理者向けのポリシーを付けてもrootそのものになるわけではありません。日常操作にroot認証情報を共有しないでください。

2. 認証方法を分ける コンソール用パスワードとAPI用アクセスキーは別々に管理します。コンソールだけを使う人へ、理由なくプログラム用キーまで作る必要はありません。パスワードを変更しただけでアクセスキーも自動的に失効すると思わないようにします。

3. 長期キーの構成 長期アクセスキーはIDとシークレットの組合せで、API要求の署名に使います。ポリシー文書はこの秘密値の代わりにはなりません。秘密値を共有リポジトリへ置かず、キーを作る前にロール等の一時的認証情報で代替できるか確認します。

4. 初期の権限 ユーザーを作って認証可能にしても、業務の操作権限が自動で付くわけではありません。例えばS3の読取りに必要なAllowがなければ認可されません。接続できるかだけではなく、具体的なAPIと資源について権限を検証します。

5. ユーザーとグループ 共通の閲覧権限を持つ複数ユーザーはグループで整理できます。個別に同じインラインポリシーを複製すると変更漏れが起こりやすくなります。グループへ入れてもユーザーごとの認証情報は個別であり、グループ共通パスワードを使う方式ではありません。

6. 人向けのアクセス 新しい従業員へアクセスを用意する場合は、IAM Identity Center等のフェデレーションを先に検討します。IAMユーザーはその方式を使えない用途や緊急用設計等で必要になる場合があります。古いツールが長期キー必須なら、その制約を確認して権限を絞ります。

7. MFAと最小権限 MFAを設定しても、ユーザーに与えた広い許可は狭くなりません。本人確認と権限の両方を管理します。参照担当へ更新・削除を許可しないなど、必要なAPIと対象資源を明示します。認証の強さだけを安全性の完成条件にしません。

8. 変更と廃止 担当者が異動したら所属グループ、直接ポリシー、アクセスキーの利用を見直します。パスワードを無効にしてもAPIキーが残れば別のアクセス手段が残る場合があります。使っている処理への影響を確認し、不要な認証情報と許可をそれぞれ整理します。

図解

ユーザーの確認を三つに分ける
認証情報の変更と操作権限の変更は同じ作業ではありません。

重要ポイント

  • ユーザーとrootは異なるID。
  • コンソールパスワードとAPIキーを別々に管理する。
  • 新規の人向けアクセスは一時的認証情報の方式を検討する。

間違えやすい点

  • パスワード変更でアクセスキーも自動更新されると思う。
  • ユーザー作成だけでAWS操作が許可されると考える。
  • MFAが権限を自動的に最小化すると考える。

用語解説

アクセスキー
API署名で使うアクセスキーIDと秘密値の組合せ。
rootユーザー
AWSアカウントの特別な権限を持つIDで、通常のIAMユーザーとは異なる。
フェデレーション
外部のID基盤等の認証を使ってAWSへのアクセスを実現する方式。

関連教材

参考資料

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

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