AWSを安全に利用する上で、避けては通れないのがAWS IAM (Identity and Access Management)です。セキュリティの根幹であり、AWS認定ソリューションアーキテクト – アソシエイト（SAA-C03）試験でも最重要項目として扱われます。
本記事では、IAMの基本概念から、試験で問われる「アタッチ関係」、実務で事故を防ぐための「ベストプラクティス」までを網羅的に解説します。この記事を読めば、IAMの全体像と具体的な運用イメージが掴めるはずです。
IAMとはなにか？：認証と認可の分離
IAMは、AWSリソースへのアクセスを安全に管理するためのサービスです。大きく分けて「認証（Authentication）」と「認可（Authorization）」の2つの役割を担います。
- 認証：「あなたは誰か？」を確認する（ログインID、パスワード、MFAなど）
- 認可：「あなたは何ができるか？」を決定する（S3のバケットを消せるか、EC2を止められるかなど）
IAMはグローバルサービスであり、リージョンを指定する必要がありません。また、AWSの「共有責任モデル」において、ユーザー側の責任範囲の核となるサービスです。
IAMの主要コンポーネントと「アタッチ」の関係図
IAMの理解を難しくしているのは、「AをBに付ける」という関係性が多方向にある点です。以下の表で、主要な要素と、それらが「どこに紐付くのか（アタッチ先）」、そして識別するための視点を整理しました。
| IAM要素 | 何にアタッチできるか？（紐付け先） | 識別子 / 認証の視点 |
|---|---|---|
| IAM ユーザ | ・IAM グループ（所属する） ・AWSアカウント（ID/Passで紐付く） | ユーザARN、アクセスキーID、アカウントID |
| IAM グループ | ・IAM ユーザ（ユーザを内包する） | 複数のユーザへの権限一括付与用 |
| IAM ロール | ・AWS サービス（EC2, Lambda等） ・別アカウント / 外部ID（クロスアカウント） | 信頼ポリシー内の「Principal」 （Account ID等で定義） |
| IAM ポリシー | ・IAM ユーザ / グループ / ロール ・AWS リソース（S3バケット, KMS等） | JSON形式の権限定義文書 |
【試験対策】EC2にアタッチできるのは「ロール」だけ
試験対策として非常に重要なのが、「AWSリソース（EC2など）に対して直接IAMユーザをアタッチすることはできない」という点です。リソースには必ずIAMロールをアタッチします。
- NG： EC2インスタンスに「IAMユーザ：田中さん」を紐付ける
- OK： EC2インスタンスに「S3閲覧用のIAMロール」を付与したインスタンスプロファイルを紐付ける
IAMロールの核心：AssumeRole（ロールの引き受け）
IAMロールは、ユーザと違い「永続的なパスワード」を持ちません。代わりに、AWS STS (Security Token Service)から一時的な認証情報を取得して動作します。この仕組みをAssumeRole（ロールの引き受け）と呼びます。
信頼ポリシー（Trust Relationship）
「誰がこのロールを使ってよいか」を定義するのが信頼ポリシーです。ここでAccount IDやサービス名を指定します。
"AWS": "arn:aws:iam::123456789012:root"→ アカウントID 123456789012 に属するエンティティに許可。"Service": "ec2.amazonaws.com"→ EC2サービスに対してロールの使用を許可。
IAMポリシーの評価論理（Evaluation Logic）
複数のポリシーが適用されている場合、AWSは以下の「評価論理」に従って最終的な可否を判断します。試験のトラブルシューティング問題で最も重要な知識です。
- 明示的な拒否（Explicit Deny）： どこか1箇所でも
"Effect": "Deny"があれば、即座にアクセス拒否されます。これが最強のルールです。 - 明示的な許可（Explicit Allow）： Denyがなく、いずれかのポリシーに
"Effect": "Allow"があれば許可されます。 - デフォルトの拒否（Implicit Deny）： AllowもDenyも設定されていない場合、アクセスは拒否されます（拒否がデフォルト）。
IAM運用のベストプラクティス（セキュリティ面）
AWS公式の IAM セキュリティベストプラクティス に基づいた、実務で必須の運用ルールです。
- ルートユーザの封印： 最初のアカウント作成以外でルートユーザは使いません。強力なMFAを設定し、日常業務はIAMユーザやIdentity Centerで行います。
- 最小権限の原則（Least Privilege）： 必要な作業に必要な権限だけを与えます。最初は強い権限を与えず、必要に応じて
ReadOnlyAccessなどから広げていきます。 - アクセスキーの利用を最小限に： プログラムからのアクセスには、可能な限りIAMロールを使用します。アクセスキーをコードにハードコードするのは最も危険な行為の一つです。
- 許可の境界（Permissions Boundary）： 強い権限を持つユーザーが、自分より強い権限を持つユーザーを勝手に作成できないよう制限をかけます。
IAMの関連サービスと最新トレンド
現在のAWS環境では、IAM単体ではなく以下の関連サービスを組み合わせた運用が標準となっています。
IAM Identity Center (旧 AWS SSO)
現在、AWSが「人間」のログイン管理に最も推奨しているサービスです。1つのIDで複数のAWSアカウントにシングルサインオン（SSO）でき、[AWS Organizations](https://aws.amazon.com) との相性も抜群です。
IAM Access Analyzer
意図せず外部（他アカウントやインターネット）からアクセス可能になっているリソースがないか、自動で分析・警告してくれる監査ツールです。[IAM Access Analyzer](https://aws.amazon.com) を活用することで、設定ミスによる情報漏洩を防げます。
IAM Roles Anywhere
オンプレミスのサーバなど、AWSの外にある環境から「アクセスキー」を使わずにIAMロールの権限を利用できるようにする仕組みです。デジタル証明書を用いて、安全にAWSリソースへアクセスできます。
まとめ：SAA試験合格へのチェックリスト
最後に、試験対策として以下のポイントを復習しておきましょう。
- IAMユーザ、グループ、ロール、ポリシーの四角関係を説明できるか？
- EC2などのリソースに権限を与えるときは「ロール」を使うと即答できるか？
- 信頼ポリシーで「誰が（Account ID等）」、許可ポリシーで「何を」定義するか分かっているか？
- 「明示的な拒否」がすべての許可を上書きすることを理解しているか？
IAMはAWSの入り口であり、出口でもあります。まずはマネジメントコンソールを触り、実際にポリシーを作成して「アクセス拒否」の画面を見ることから始めてみてください。その実体験こそが、試験突破と実務スキルの最大の武器になります。
コメント