はじめに
AWS SAA取得に向けて学習を始めました。
最初に出てきたのが「IAM」です。
ただ、最初はこう感じました。
- IAMって結局なに？
- 何をしているのか分からない
- ロールとかポリシーとか用語が多い
この記事では、IAMでまず理解すべきポイントを学習ログとして整理します。
IAMとは？
IAM（Identity and Access Management）は、
→ AWSのリソースに対するアクセス権限を管理する仕組み
簡単に言うと
→ 「誰が」「何をできるか」を決める
なぜIAMが必要なのか
もしIAMがなかった場合
- 誰でもデータ削除ができる
- 誰でも本番環境を変更できる
- 誰でも全リソースにアクセスできる
→ システムとして成立しない
そこでIAMでは
→ 必要な人に必要な権限だけを付与する（最小権限の原則）
これにより、セキュリティと運用の安全性を保っています。
IAMで理解すべき4つの要素
① ユーザー（User）
→ 人が使うアカウント
- 開発者
- 運用担当者
② グループ（Group）
- ユーザーをまとめる
- グループに権限を付けるのが基本
③ ロール（Role）
- 一時的に権限を使う仕組み
- サービスや別アカウントに権限を渡すときに使う
④ ポリシー（Policy）
- 権限の中身（JSONで定義）
- IAMの理解＝ポリシーの理解
ロールの具体例
例えば、EC2からS3にアクセスしたい場合
最初は
- アクセスキーをコードに書く？
→ これはNG（セキュリティ的に危険）
正しい方法
- EC2にIAMロールを付与する
すると
- 一時的な認証情報が自動で使われる
- アクセスキーを持たなくていい
→ これがロールの役割
理解すべき重要ポイント
① IAMは「認可」の仕組み
→ 何ができるかを決める
② ロールはサービス連携で必須
→ 実務ではほぼ確実に使う
③ ポリシーが権限の本体
→ IAM＝ポリシー
④ 最小権限の原則
→ 必要最小限だけ許可
つまずいたポイント
❌ ロールの使いどころが分からない
→ 「一時的に借りる権限」と理解すると分かりやすい
❌ ポリシーのJSONが難しい
→ 最初は読めなくてOK
学習して気づいたこと
IAMは単なる設定ではなく
→ セキュリティ設計そのもの
だと感じました。
特にロールの考え方は
- 権限を「持つ」のではなく
- 必要なときだけ「使う」
まとめ
IAMは単なるユーザー管理機能ではなく、
→ AWS全体のセキュリティとアクセス制御を担う仕組み
最初は難しく感じましたが、
- 「誰が何をできるかを決めるもの」
- 「必要な権限だけを付与するもの」
と理解するとイメージしやすくなりました。
→ 「必要なときだけ権限を使う（ロール）」
という考え方が重要だと感じました。