週1AWS基礎＋ IAM2026年8月2日(日)

2026-08-02（日）AWS基礎＋IAM（権限管理）

週1の計画を見る →

1. 【このハンズオンで使うAWSサービスと役割】

AWS IAM (Identity and Access Management) [p.181]:
- 役割: AWSリソースへのアクセスを安全に制御するための認証・認可システムです [p.181]。本日はルートユーザーの使用を止め、適切な権限を割り当てた作業アカウントへ移行するために使用します [p.176-177]。
IAM グループ [p.183-184]:
- 役割: 同じ権限（ポリシー）を持ったIAMユーザーを論理的にまとめる「コンテナ」です **[p.184]もだないず。グループ自体はアクセス用認証情報（パスワード等）を持ちませんが、所属するユーザーへ権限を一括継承させます [p.184]。
IAM ユーザー [p.183]:
- 役割: 実際の人間やプログラムに1対1で割り当てる「個別のID」です [p.183]。ログイン用のユーザー名とパスワード、またはAPI/CLI操作用のアクセスキーペアを保持します [p.183]。
IAM ポリシー（AdministratorAccess） [p.181-182]:
- 役割: 「どのような操作を、どのリソースに対して許可/拒否するか」をJSON形式で記述した権限の定義書です [p.182]。本ハンズオンで使用する「AdministratorAccess」は、AWSが事前に用意したすべての操作を許可する強力な「AWS管理ポリシー」です [p.182]。

2. 【操作前に知っておくべき設定項目】

12桁のアカウントID（またはアカウントエイリアス）:
- ルートユーザーはメールアドレスでログインしますが、IAMユーザーは専用の「サインインURL（アカウントIDが含まれる）」からログインする必要があります [p.181]。
IAM グループ名:
- 権限が明確に伝わる名前（例：Administrators、AdminGroup など）。
IAM ユーザー名とパスワード:
- ハンズオン用に作成する作業者の個別ユーザー名と、初回ログイン時に強制変更させるための初期パスワード設定 [p.183]。

3. 【よくある詰まりポイント・注意点】

注意点①：「ログインできない！」という罠（サインイン画面の混同）
- 原因: ルートユーザーと同じ通常のログイン画面（メールアドレス入力）から作成したIAMユーザー名でログインしようとするとエラーになります [p.181]。
- 解決理由: IAMユーザーでのサインインには、必ず 「https://[アカウントIDまたはエイリアス].signin.aws.amazon.com/console」 の形式のURLを使用し、12桁のアカウントID、ユーザー名、パスワードの3つを正しく入力しなければなりません [p.181]。
注意点②：個別ユーザーへの直接のポリシー適用（アンチパターン）
- 考え方の本質: ユーザー個別に対して直接ポリシーをアタッチ（インラインポリシーなど）してしまうと、メンバーの追加・変更・退職のたびに個別の設定変更が必要になり、設定漏れや不要な「過剰権限の残存」といった重大な管理ミス（セキュリティホール）を招きます [p.182-184]。
- 解決理由: 日常の運用においては、「権限ポリシーは必ず『グループ』にアタッチし、ユーザーはそのグループに所属させることで、間接的に権限を継承させる」 というグループベースの権限管理を徹底します [p.181, p.184]。
注意点③：グループ構造の階層化は不可
- 組織図のように「グループの中にさらにサブグループを作成して権限を細分化する」といったグループの階層化（ネスト）はAWS IAMの物理仕様上サポートされていません [p.184]。

4. 【このハンズオンが対応する試験論点】

① 「なぜ管理者作業でもルートユーザーを封印すべきなのか」という設計原則 [p.176-177]

試験上の要点: ルートユーザーは、請求情報の変更やアカウント解約を含む「すべての権限」を無制限に持ち、これを部分的に制限・剥奪することができません [p.176]。
ベストプラクティス: 万が一の漏洩による壊滅的被害を防ぐため、日常のシステム構築・管理においては、たとえ最高管理者権限（AdministratorAccess）を必要とする作業であっても、ルートユーザーは完全にサインアウトして封印し、「AdministratorAccessポリシーをアタッチした管理者用IAMユーザー」を別に用意して作業を行うのがAWSの絶対的なセキュリティ鉄則です [p.176-177, p.181]。

② 「インラインポリシー」と「管理ポリシー」の決定的な違い [p.182-183]

試験問題で使い分けを問われるため、その境界線を理解します。

比較項目	管理ポリシー（AWS管理 / カスタマー管理） [p.182]	インラインポリシー [p.182]
再利用性	高い。1つのポリシーを複数のグループ、ユーザー、ロールに共通して適用可能 [p.182-183]。	なし。アタッチした特定の1つのユーザーやロールと1対1で運命を共にする。
主なユースケース	管理者権限（AdministratorAccess）や、複数メンバーで共有する「開発者用権限」などの標準的な役割定義 [p.182-183]。	「特定の1名にだけ、例外的に今週中だけこの一時フォルダ（S3）の閲覧を許可したい」といった固有で限定的な例外設定 [p.182]。
試験での判断	権限の共通管理、ガバナンス確保、ポリシーのバージョン管理を行いたい場合は一択で管理ポリシー [p.182]。	1対1の厳格な排他管理、他への流用を防ぎたい特殊要件の場合に限定 [p.182]。

③ 認証情報の厳密な使い分け [p.183]

ユーザーIDとパスワード: 「マネジメントコンソール（Webブラウザ画面）」 へ人間が手動ログインするためだけに利用する情報です [p.183]。
アクセスキーとシークレットアクセスキー: プログラムやツール、「CLI（コマンドライン）/ API」 を介して外部システムから自動実行させるためだけに利用するキーペアです [p.183]。試験では「プログラムにコンソール用パスワードを埋め込む」などの選択肢はすべて誤答として除外します [p.183]。

🛠️ アカウントを安全に統制するための「IAMグループ・ユーザー設計」の基本を、本日の実習を通じてしっかりと身につけましょう！このIAMの初期設定を完了させたら、いよいよインフラ構築の土台となる「Amazon VPC（第2章）」のネットワーク設定ハンズオンへと進んでみましょうか？