【AWS IAM②】ポリシー、グループ、ロール（Role）の役割と使い分けを完全図解

URLをコピーしました！

AWS IAM（Identity and Access Management）は、AWS環境のセキュリティを支える中核サービスです。
前回の記事では、「ルートユーザー」「IAMユーザー」「MFA（多要素認証）」について学びました。

この記事でわかること

IAMポリシーとは何か
IAMグループとは何か
IAMロールとは何か
3つの違いと役割
AWSサービスとIAMロールの関係
実務での権限設計
SAA試験で頻出のポイント

📚 SAA試験対策ボックス

試験頻出度	★★★★★
重要度	★★★★★
学習優先度	最優先
関連ドメイン	ドメイン1：セキュアなアーキテクチャの設計
関連サービス	AWS IAM・EC2・Lambda・ECS・CloudFormation

この記事で覚えること

ポリシー＝権限を定義するもの
グループ＝IAMユーザーをまとめるもの
ロール＝一時的に権限を引き受ける仕組み
IAMロールはAWSサービスでも利用される

IAM①のおさらい

前回の記事では、AWSアカウントにはルートユーザーとIAMユーザーが存在し、日常業務ではIAMユーザーを利用することを学びました。

しかし、IAMユーザーを作成しただけでは、EC2やS3などのAWSサービスを操作することはできません。

AWSでは、「どのユーザーが」「どのサービスに」「どこまでアクセスできるか」をIAMによって制御しています。

このアクセス制御を実現するために利用するのが、以下の3つです。

IAMポリシー
IAMグループ
IAMロール

まずは、それぞれがどのような役割を持っているのかを理解しましょう。

IAMポリシーとは？

IAMポリシー（IAM Policy）とは、「どの操作を許可するか・拒否するか」を定義したアクセス権限のルールです。

IAMポリシー自体はユーザーではなく、「権限の設定内容」を記述したJSON形式のドキュメントです。

例えば、「EC2の起動・停止だけ許可する」「S3は閲覧のみ許可する」といった権限を細かく定義できます。

ポリシーで定義できること	例
サービス	EC2・S3・RDSなど
実行できる操作	起動・停止・作成・削除
対象リソース	特定バケット・特定インスタンス
条件	特定IPのみ・特定時間帯のみ

IAMグループとは？

IAMグループ（IAM Group）とは、複数のIAMユーザーをまとめて管理するための機能です。

例えば、同じ部署の社員全員に同じ権限を付与したい場合、ユーザーごとにポリシーを設定すると管理が煩雑になります。

そこでIAMグループを利用すると、グループへポリシーを割り当てるだけで、そのグループに所属するすべてのIAMユーザーへ同じ権限を付与できます。

グループ名	付与する権限
Developers	EC2・Lambda・CloudWatch
Operators	EC2・VPC・Route53
DatabaseAdmins	RDS・Secrets Manager
ReadOnlyUsers	閲覧のみ

新しい社員が入社した場合も、IAMユーザーを作成して適切なグループへ追加するだけで、必要な権限を一括で付与できます。

IAMロールとは？

IAMロール（IAM Role）は、一時的に権限を引き受けるための仕組みです。

IAMユーザーは「人」に対して作成するアカウントですが、IAMロールは人だけでなくAWSサービスや他のAWSアカウントも利用できます。

例えば、EC2インスタンスがS3へアクセスする場合、アクセスキーをEC2へ保存するのではなく、EC2へIAMロールを割り当てることで安全にS3へアクセスできます。

この「必要なときだけ権限を利用する」という仕組みが、IAMロールの最大の特徴です。

IAMポリシー・IAMグループ・IAMロールの違い

ここまで、それぞれの概要について解説してきました。しかし、AWS初心者の多くが「結局、この3つは何が違うの？」という疑問を持ちます。

まずは、それぞれの役割を表にまとめて整理してみましょう。

項目	IAMポリシー	IAMグループ	IAMロール
役割	権限を定義する	ユーザーをまとめる	一時的に権限を付与する
対象	IAMユーザー・IAMグループ・IAMロール	IAMユーザー	IAMユーザー・AWSサービス・他AWSアカウント
利用者	管理者	管理者	人・AWSサービス
権限を持つか	〇（権限を定義）	×（ポリシーを受け取る）	〇（ポリシーを受け取る）
代表例	AmazonS3ReadOnlyAccess	Developers	EC2Role

このように、役割は明確に異なります。

IAMポリシー・・・「何ができるか」を決める
IAMグループ・・・「誰をまとめるか」を決める
IAMロール・・・「誰が一時的に権限を利用するか」を決める

覚え方

ポリシー＝権限のルールブック
グループ＝ユーザーのチーム
ロール＝一時的に借りる権限

IAMの権限はどのように付与されるのか？

AWSでは、IAMポリシーをユーザーへ直接付与することもできますが、実際の運用ではIAMグループを経由して権限を付与するケースが一般的です。

例えば、開発部門の社員全員にEC2やLambdaを操作する権限を付与したい場合、以下のような構成になります。

「Developers」というIAMグループを作成する
Developersグループへポリシーをアタッチする
IAMユーザーをDevelopersへ所属させる

すると、そのグループに所属している全員へ同じ権限が自動的に付与されます。

💼 実務ではこう考える

企業では数百人〜数千人規模でAWSを利用することもあります。そのため、IAMユーザー1人ずつへポリシーを設定することはほとんどありません。

部署や役職ごとにIAMグループを作成し、グループへIAMポリシーを割り当てることで、効率的かつ安全に権限を管理します。

IAMポリシーはどこへアタッチできる？

IAMポリシーは、以下の3つへアタッチできます。

アタッチ先	利用例
IAMユーザー	個人へ直接権限を付与
IAMグループ	部署・チームへ一括付与
IAMロール	AWSサービスへ権限付与

SAA試験では、「IAMポリシーはIAMグループへ付与できるか？」というような問題も出題されます。

IAMポリシーはユーザー・グループ・ロールのすべてにアタッチできることを覚えておきましょう。

IAMロールはなぜ必要なのか？

AWS初心者の多くが、「IAMユーザーがあるならIAMロールはいらないのでは？」と考えます。

しかし、AWSサービスは人ではありません。

例えば、EC2がS3へアクセスしたい場合、EC2へIAMユーザーを作成することはできません。

そこで利用するのがIAMロールです。

IAMロールをEC2へ割り当てることで、EC2は一時的に必要な権限を取得し、安全にS3へアクセスできます。

💡 イメージすると理解しやすい

IAMユーザーは「社員証」のようなものです。

一方、IAMロールは「作業するときだけ貸し出される入館証」のようなものです。

作業が終われば返却されるため、アクセスキーを長期間保持する必要がなく、セキュリティも向上します。

ここまでのまとめ

サービス	役割
IAMポリシー	何ができるかを決める
IAMグループ	IAMユーザーをまとめる
IAMロール	一時的に権限を利用する

✔ このパートで覚えること

ポリシーは権限を定義する
グループはユーザー管理を簡単にするための機能
ロールは一時的な権限委任を実現する仕組み
ポリシーはユーザー・グループ・ロールへアタッチできる
実務ではグループ経由で権限管理することが一般的

IAMロールはなぜ重要なのか？

前のパートでは、IAMロールは「一時的に権限を引き受ける仕組み」であることを説明しました。

では、なぜAWSではIAMロールがこれほど重要なのでしょうか。

理由は、AWSサービス自身が他のAWSサービスへ安全にアクセスするためです。

例えば、EC2インスタンスからAmazon S3へファイルを保存したい場合を考えてみましょう。

以前はアクセスキー（Access Key ID / Secret Access Key）をEC2内へ保存して利用するケースもありました。しかし、この方法では認証情報が漏えいするリスクがあり、現在ではAWSは推奨していません。

そこで利用するのがIAMロールです。

EC2へIAMロールを割り当てることで、一時的な認証情報（テンポラリクレデンシャル）が自動的に払い出され、安全にS3へアクセスできます。

💼 実務ではこう考える

現在のAWSでは、アクセスキーをサーバーやアプリケーションへ保存する設計は避けることが推奨されています。

EC2・Lambda・ECS・CloudFormationなどのAWSサービスでは、IAMロールを利用することがベストプラクティスです。

IAMロールを利用する代表的なサービス

IAMロールは、人だけではなくAWSサービスにも権限を付与できます。

SAA試験でも頻繁に登場する代表的なサービスを見てみましょう。

AWSサービス	IAMロールの利用例
Amazon EC2	S3やSecrets Managerへアクセスする
AWS Lambda	DynamoDB・CloudWatch Logsへアクセスする
Amazon ECS	コンテナからS3やRDSへアクセスする
AWS CloudFormation	AWSリソースを自動作成する
AWS Glue	S3やRedshiftへアクセスする
AWS Backup	各AWSサービスのバックアップを取得する

これらのサービスはいずれも、IAMロールを利用することで必要な権限だけを取得し、安全にAWSリソースを操作しています。

EC2へIAMロールを割り当てる流れ

EC2インスタンスへIAMロールを割り当てる場合の流れを確認しましょう。

IAMロールを作成する
S3へのアクセス権限を持つIAMポリシーをアタッチする
EC2インスタンスへIAMロールを関連付ける
EC2は一時的な認証情報を自動取得する
S3へ安全にアクセスする

この仕組みにより、EC2内へアクセスキーを保存する必要がありません。

試験ポイント

SAA試験では、「EC2からS3へ安全にアクセスさせたい」という問題が頻繁に出題されます。

正解はIAMロールをEC2へ割り当てるです。アクセスキーをEC2へ保存する選択肢は誤りとして出題されることが多いため注意しましょう。

AssumeRole（ロールの引き受け）とは？

IAMロールは「一時的に権限を借りる仕組み」です。

この「権限を借りる」という動作をAssumeRole（ロールの引き受け）と呼びます。

AssumeRoleを実行すると、AWS Security Token Service（STS）が一時的な認証情報を発行し、そのロールに設定された権限でAWSリソースを操作できます。

例えば、以下のようなケースで利用されます。

EC2がS3へアクセスする
LambdaがDynamoDBへアクセスする
CloudFormationがEC2を作成する
他のAWSアカウントのリソースへアクセスする

💼 実務ではこう考える

AssumeRoleによって発行される認証情報には有効期限があります。

そのため、万が一認証情報が漏えいした場合でも、永続的なアクセスキーと比べてリスクを大幅に低減できます。

IAMポリシーの種類

IAMポリシーには、大きく分けて3種類あります。

種類	概要	利用シーン
AWS管理ポリシー	AWSが提供する標準ポリシー	一般的な権限付与
カスタマー管理ポリシー	利用者が自由に作成するポリシー	企業独自の権限設計
インラインポリシー	特定のユーザー・グループ・ロール専用のポリシー	個別設定

AWS管理ポリシーとは？

AWS管理ポリシー（AWS Managed Policy）とは、AWSがあらかじめ用意しているIAMポリシーです。

代表的なAWSサービスに対する一般的な権限が定義されており、利用者はポリシーを選択してアタッチするだけで利用できます。

例えば、S3を読み取り専用で利用したい場合は「AmazonS3ReadOnlyAccess」、EC2をフルコントロールしたい場合は「AmazonEC2FullAccess」といったAWS管理ポリシーを利用できます。

ポリシー名	付与される権限
AdministratorAccess	ほぼすべてのAWSサービスを操作可能
AmazonS3ReadOnlyAccess	S3の読み取り専用
AmazonEC2FullAccess	EC2をフルコントロール
ReadOnlyAccess	AWSサービス全体を閲覧のみ可能

💼 実務ではこう考える

検証環境や学習用途ではAWS管理ポリシーを利用すると素早く権限設定ができます。一方、本番環境では権限が広すぎることも多いため、後述するカスタマー管理ポリシーを利用するケースが一般的です。

カスタマー管理ポリシーとは？

カスタマー管理ポリシー（Customer Managed Policy）は、利用者が独自に作成するIAMポリシーです。

必要なサービス・操作・対象リソースを細かく指定できるため、企業で最も多く利用されるポリシーです。

例えば、「EC2は起動・停止だけ許可する」「S3は特定バケットのみアクセス可能」といった要件にも柔軟に対応できます。

メリット	内容
細かい権限制御	必要最小限の権限を付与できる
再利用できる	複数のユーザー・グループ・ロールへ共通利用できる
保守しやすい	ポリシーを更新すると全体へ反映される

試験ポイント

SAAでは「最小権限の原則（Principle of Least Privilege）」が重要です。そのため、本番環境ではAWS管理ポリシーよりも、必要な権限だけを持つカスタマー管理ポリシーを利用するケースが適切な選択肢になることが多くあります。

インラインポリシーとは？

インラインポリシー（Inline Policy）は、特定のIAMユーザー・IAMグループ・IAMロールに直接埋め込まれるポリシーです。

他のIAMエンティティへ使い回すことはできず、その対象専用のポリシーとなります。

比較項目	カスタマー管理ポリシー	インラインポリシー
再利用	〇	×
管理性	高い	低い
利用頻度	高い	限定的

現在では、保守性や再利用性を考慮し、インラインポリシーよりもカスタマー管理ポリシーを利用することが推奨されています。

クロスアカウントアクセスとは？

企業では、AWSアカウントを用途ごとに分けて運用することが一般的です。

例えば、「開発環境」「検証環境」「本番環境」でAWSアカウントを分離しているケースでは、他のAWSアカウントへアクセスする必要があります。

このような場合に利用されるのが、IAMロールによるクロスアカウントアクセスです。

アクセスの流れは以下のとおりです。

AWSアカウントAに所属するIAMユーザーがログインする
AWSアカウントBのIAMロールをAssumeRoleする
STSが一時的な認証情報を発行する
AWSアカウントBのリソースを操作する

💼 実務ではこう考える

複数アカウントを運用する企業では、アクセスキーを共有することはありません。 IAMロールとAssumeRoleを利用することで、安全に他アカウントのリソースへアクセスします。

実務で推奨される権限設計

AWSでは、管理しやすく安全な権限設計が重要です。

推奨事項	理由
IAMグループで権限管理する	ユーザー追加・削除が容易
カスタマー管理ポリシーを利用する	最小権限を実現しやすい
AWSサービスにはIAMロールを利用する	アクセスキーが不要になる
アクセスキーを埋め込まない	認証情報漏えい防止
定期的に権限を見直す	不要な権限を削除する

AWS公式ベストプラクティス

AWSでは、人・アプリケーション・AWSサービスを問わず、「長期的なアクセスキーではなく、一時的な認証情報を利用すること」が推奨されています。 IAMロールは、この考え方を実現する重要な仕組みです。

このパートのポイント

AWS管理ポリシーはAWSが提供する標準ポリシー
カスタマー管理ポリシーは企業独自の権限設計に利用する
インラインポリシーは特定のIAMエンティティ専用
クロスアカウントアクセスはIAMロールとAssumeRoleで実現する
アクセスキーではなくIAMロールを利用することがAWSのベストプラクティス

🔥 SAA試験頻出ポイント

AWS Certified Solutions Architect – Associate（SAA-C03）では、IAMは毎回のように出題される最重要分野です。

単純な用語を問う問題だけでなく、「どのIAM機能を利用するべきか」を判断するシナリオ問題が多く出題されます。

特に覚えておくべきポイント

IAMポリシーは「何ができるか（権限）」を定義する
IAMグループはIAMユーザーをまとめて管理する
IAMロールは一時的な認証情報を利用する仕組みである
AWSサービスにはIAMロールを利用する
アクセスキーをEC2へ保存してはいけない
AssumeRoleにより一時的な認証情報（STS）が発行される
最小権限の原則（Principle of Least Privilege）を常に意識する
企業ではカスタマー管理ポリシーを利用するケースが多い

⚠ 初心者が混同しやすいポイント

誤解	正しい理解
IAMポリシーがユーザーを管理する	IAMポリシーは権限を定義するだけ
IAMグループにログインできる	ログインできるのはIAMユーザーのみ
IAMロールはIAMユーザーと同じもの	IAMロールは一時的に権限を引き受ける仕組み
EC2にはアクセスキーを設定する	IAMロールを割り当てる
AdministratorAccessを付与すれば安全	必要最小限の権限のみ付与する
インラインポリシーが標準	現在はカスタマー管理ポリシーが推奨される

シナリオ問題でよくある出題例

SAA試験では、「どのサービスを利用するべきか」を選択するシナリオ問題が数多く出題されます。

シナリオ	選ぶべきサービス・機能
EC2からS3へ安全にアクセスしたい	EC2へIAMロールを割り当てる
複数の開発者へ同じ権限を付与したい	IAMグループへIAMポリシーをアタッチする
特定のS3バケットだけ操作を許可したい	カスタマー管理ポリシーを作成する
他AWSアカウントのリソースへアクセスしたい	IAMロール＋AssumeRoleを利用する
AWSサービスへ長期的なアクセスキーを設定したい	誤り（IAMロールを利用する）

💼 実務ではこう考える

試験では「アクセスキーをEC2へ保存する」という選択肢が誤答として登場することがあります。 AWSではIAMロールを利用することがベストプラクティスであることを覚えておきましょう。

IAMユーザー・グループ・ポリシー・ロールの関係

ここまで学習した内容を、最後に整理しておきましょう。

機能	役割	対象
IAMユーザー	AWSへログインする利用者	人
IAMグループ	複数ユーザーをまとめる	IAMユーザー
IAMポリシー	アクセス権限を定義する	ユーザー・グループ・ロール
IAMロール	一時的な権限を付与する	人・AWSサービス・他AWSアカウント

この4つの役割を正しく理解できれば、IAMの基本は十分に身に付いています。

AWS公式試験ガイドとの対応

本記事はAWS Certified Solutions Architect – Associate（SAA-C03）の「ドメイン1：セキュアなアーキテクチャの設計」に対応しています。

特に以下の知識は試験で頻繁に問われます。

IAMポリシーによるアクセス制御
IAMグループによる権限管理
IAMロールとAssumeRole
最小権限の原則
一時的な認証情報（STS）の利用
AWSサービスへの安全なアクセス方法

まとめ

IAMはAWSにおけるアクセス管理の中核サービスです。

IAMポリシーは「何ができるか」を定義し、IAMグループはユーザーをまとめて管理し、IAMロールは人やAWSサービスへ一時的な権限を付与します。

これらを適切に使い分けることで、安全かつ効率的なAWS環境を構築できます。

また、AWSでは長期的なアクセスキーの利用ではなく、IAMロールによる一時的な認証情報を利用することがベストプラクティスです。SAA試験でも、この考え方を前提とした問題が数多く出題されます。