概要
AWS アカウントを作成すると、すべての AWS サービスにフルアクセスできるルートユーザーが作成されます。しかし、日常的な運用でルートユーザーを使い続けることはセキュリティ上のリスクが高く、誰がどの操作を行ったかの追跡も困難になります。
AWS Identity and Access Management(IAM)は、AWS リソースへのアクセスを安全に管理するためのサービスです。ユーザー、グループ、ロール、ポリシーを使って「誰が」「どのリソースに対して」「どのような操作を」許可・拒否するかを細かく制御できます。
本記事では、IAM の基本概念を理解し、ユーザー・グループ・ロール・ポリシーの作成を通じてアクセス制御の仕組みを体験します。

この記事のメリット
- IAM ユーザーとグループを作成し、権限をグループ単位で管理する方法を習得できる
- IAM ポリシーの構造(Effect、Action、Resource)を理解し、カスタムポリシーを作成できる
- IAM ロールを作成して EC2 インスタンスなどの AWS サービスに権限を付与する方法を体験できる
- 最小権限の原則に基づいたアクセス制御の考え方を理解できる
- マネージドポリシーとインラインポリシーの違いを把握できる
執筆者とキャラクター紹介
執筆者:土肥(とひ)
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。

クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。



基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。



猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説



とひさん、IAM ってよく聞くんですけど、どんなサービスなんですか?
IAM は、AWS リソースへのアクセスを認証(Authentication)と認可(Authorization)で制御するサービスだよ。追加料金なしで使えて、AWS アカウントのセキュリティの基盤になるんだ。



認証と認可って、別のものなんですか?
そうだね。認証は「あなたは誰?」を確認すること、認可は「あなたは何をしていい?」を決めることだよ。IAM はこの両方を担っているんだ。主なユースケースとしてはこんな感じだね。
- 開発者や運用担当者ごとに適切な権限を持つユーザーを作成する
- チームごとにグループを作成し、権限を一括管理する
- EC2 インスタンスやLambda 関数に IAM ロールを割り当て、安全に他の AWS サービスにアクセスさせる
- 外部システムやサードパーティアプリケーションに一時的なアクセス権を付与する



けっこういろいろできるんですね!IAM の中にはどんな要素があるんですか?
IAM には 4 つの主要コンポーネントがあるよ。
| コンポーネント | 説明 |
|---|---|
| ユーザー | AWS にアクセスする個人やアプリケーションを表すエンティティ |
| グループ | ユーザーの集合。グループにポリシーをアタッチすると所属する全ユーザーに権限が適用される |
| ロール | AWS サービスや外部エンティティが一時的に引き受ける権限のセット |
| ポリシー | アクセス許可を定義する JSON ドキュメント |





ポリシーが権限を定義するものなんですね。ポリシーってどういう構造になっているんですか?
ポリシーは JSON 形式で書くんだけど、主に以下の要素で構成されるよ。
| 要素 | 説明 | 例 |
|---|---|---|
Effect | 許可(Allow)または拒否(Deny) | "Effect": "Allow" |
Action | 許可・拒否する API アクション | "Action": "s3:GetObject" |
Resource | 対象の AWS リソース(ARN) | "Resource": "arn:aws:s3:::my-bucket/*" |
Condition | ポリシーが適用される条件(オプション) | IP アドレス制限、MFA 要求など |



なるほど…。具体的にはどんな感じで書くんですか?
例えば、S3 バケットの読み取り専用アクセスを許可するポリシーはこんな感じだよ。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::example-bucket",
"arn:aws:s3:::example-bucket/*"
]
}
]
}



Effect で許可して、Action で操作を指定して、Resource で対象を決めるんですね。わかりやすいです。
そうそう。それから、ポリシーには 3 つの種類があるんだ。
| ポリシー種類 | 説明 | 用途 |
|---|---|---|
| AWS マネージドポリシー | AWS が作成・管理する汎用ポリシー | AmazonS3ReadOnlyAccess など標準的な権限の付与 |
| カスタマーマネージドポリシー | ユーザーが作成・管理するポリシー | 組織固有の要件に合わせた権限定義 |
| インラインポリシー | 特定のユーザー・グループ・ロールに直接埋め込むポリシー | 1 対 1 の関係で権限を定義する場合 |



どの種類を使うのがいいんですか?
再利用性の観点から、マネージドポリシー(AWS マネージドまたはカスタマーマネージド)の使用が推奨されているよ。インラインポリシーは特定のエンティティに直接埋め込むから、使い回しがしにくいんだ。



さっきコンポーネントの表に「ロール」がありましたけど、ユーザーとは何が違うんですか?
IAM ロールは、ユーザーとは違って特定の個人に紐づかない権限のセットなんだ。ロールには 2 つのポリシーが関連するよ。
| ポリシー | 説明 |
|---|---|
| 信頼ポリシー(Trust Policy) | 誰がそのロールを引き受けられるかを定義する |
| 許可ポリシー(Permissions Policy) | ロールに付与する権限を定義する |



信頼ポリシーと許可ポリシー…2 つもあるんですね。どういうときにロールを使うんですか?
代表的なユースケースを挙げるとこんな感じだね。
- EC2 インスタンスプロファイル: EC2 インスタンスに権限を付与し、インスタンス上のアプリケーションが S3 や DynamoDB にアクセスできるようにする
- クロスアカウントアクセス: 別の AWS アカウントのユーザーやサービスにアクセスを許可する
- フェデレーションアクセス: 外部 IdP のユーザーに一時的な AWS アクセスを許可する



EC2 に権限を持たせたいときはロールを使うんですね!
そのとおり。最後に、IAM を使う上で一番大事な考え方を紹介するよ。「最小権限の原則」だね。ユーザーやロールに対して、業務に必要な最小限の権限のみを付与するという考え方なんだ。



必要以上に権限を与えちゃうと危ないってことですよね…。具体的にはどう気をつければいいんですか?
こういったポイントを意識するといいよ。
- まず必要な権限を特定し、それだけを許可する
*(ワイルドカード)の使用は避ける- 定期的にアクセスアドバイザーで未使用の権限を確認し、不要な権限を削除する



なるほど、こまめに見直すのも大事なんですね。
実践
前提条件
- リージョン:
ap-northeast-1(東京)(IAM はグローバルサービスですが、リソース作成時のリージョンとして使用) - 管理者権限を持つ IAM ユーザーまたはロールでログインしていること
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| IAM グループ | basic-developers | 開発者グループ |
| IAM ユーザー | basic-dev-user | ハンズオン用の開発者ユーザー |
| IAM ポリシー | BasicS3ReadPolicy | S3 読み取り専用カスタムポリシー |
| IAM ロール | BasicEC2S3AccessRole | EC2 インスタンス用の S3 アクセスロール |
ステップ1: IAM グループの作成
AWS マネジメントコンソールにログインし、上部の検索バーに IAM と入力し、表示された「IAM」を選択します。
左側ナビゲーションの「アクセス管理」→「IAM ユーザーグループ」を選択し、「グループを作成」をクリックします。
「グループに名前を付ける」セクションで以下を入力します。
- ユーザーグループ名:
basic-developers
「ユーザーをグループに追加 – オプション」は空のままにします(ユーザーは次のステップで作成します)。
「許可ポリシーを添付 – オプション」セクションで、検索ボックスに AmazonEC2ReadOnlyAccess と入力して Enter キーを押し、表示されたポリシーのチェックボックスを選択します。
ページ下部の「ユーザーグループを作成」をクリックします。


ステップ2: IAM ユーザーの作成
左側ナビゲーションの「アクセス管理」→「IAM ユーザー」を選択し、「ユーザーを作成」をクリックします。
「ユーザーの詳細を指定」画面で以下を入力します。
- ユーザー名:
basic-dev-user - 「AWS マネジメントコンソールへのユーザーアクセスを提供する – オプション」にチェック
- ユーザータイプ: 「IAM ユーザーを作成します」を選択(「Identity Center でユーザーを指定する」が推奨と表示されますが、今回は IAM ユーザーを使います)
- コンソールパスワード: 「自動生成されたパスワード」を選択(デフォルト)
- 「ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります – 推奨」にチェック(デフォルトでチェック済み)
「次へ」をクリックします。


「許可を設定」画面で以下を設定します。
- 許可のオプション: 「ユーザーをグループに追加」を選択(デフォルト)
- 「ユーザーグループ」の検索ボックスに
basicと入力して絞り込み、basic-developersのチェックボックスを選択
「次へ」をクリックします。


「確認して作成」画面で内容を確認します。「許可の概要」にはグループ basic-developers のほか、パスワード変更を許可する IAMUserChangePassword ポリシーが自動で追加されています。「ユーザーの作成」をクリックします。
「パスワードを取得」画面が表示されます。「コンソールサインイン URL」と、「表示」をクリックして表示したコンソールパスワードを控えておきます。この画面を離れるとパスワードは二度と表示できないため、必要なら「.csv ファイルをダウンロード」で保存します。


ステップ3: カスタムポリシーの作成
左側ナビゲーションの「アクセス管理」→「ポリシー」を選択し、「ポリシーを作成」をクリックします。
「アクセス許可を指定」画面の「ポリシーエディタ」で「JSON」を選択し、エディタの内容を以下の JSON に置き換えます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:ListAllMyBuckets"
],
"Resource": "*"
}
]
}
「次へ」をクリックします。


「確認して作成」画面で以下を入力します。説明には日本語が使えない(英数字と一部の記号のみ)ため、英語で入力します。
- ポリシー名:
BasicS3ReadPolicy - 説明 – オプション:
S3 bucket and object read-only access for hands-on
「このポリシーで定義されている許可」に S3 のアクセスレベルが 制限あり: リスト, 読み取り と表示されていることを確認し、「ポリシーの作成」をクリックします。
ポリシー一覧に戻り、上部に「ポリシー BasicS3ReadPolicy が作成されました。」と表示されます。検索ボックスに BasicS3ReadPolicy と入力すると、タイプが カスタマーマネージド で作成されたことが確認できます。


ステップ4: カスタムポリシーをユーザーにアタッチ
左側ナビゲーションの「アクセス管理」→「IAM ユーザー」を選択し、basic-dev-user をクリックします。
「許可」タブの「許可ポリシー」セクションで、「許可を追加」→「許可を追加」を選択します。
「許可を追加」画面の「許可のオプション」で「ポリシーを直接アタッチする」を選択します。
「許可ポリシー」の検索ボックスに BasicS3ReadPolicy と入力して Enter キーを押し、表示されたポリシーのチェックボックスを選択します。
「次へ」をクリックし、「確認」画面で「許可を追加」をクリックします。
ユーザーの「許可」タブに戻り、「次を経由してアタッチ」列で AmazonEC2ReadOnlyAccess が グループ basic-developers 経由、BasicS3ReadPolicy が 直接 アタッチされていることを確認します。


ステップ5: IAM ロールの作成
左側ナビゲーションの「アクセス管理」→「ロール」を選択し、「ロールを作成」をクリックします。
「信頼されたエンティティを選択」画面で以下を設定します。
- 信頼されたエンティティタイプ:
AWS のサービスを選択(デフォルト) - ユースケースの「サービスまたはユースケース」: ドロップダウンから
EC2を選択 - ユースケース:
EC2(Allows EC2 instances to call AWS services on your behalf.)を選択
「次へ」をクリックします。


「許可を追加」画面で、「許可ポリシー」の検索ボックスに AmazonS3ReadOnlyAccess と入力して Enter キーを押し、表示されたポリシーのチェックボックスを選択します。
「次へ」をクリックします。
「名前、確認、および作成」画面で以下を入力します。説明は英数字のみ使えるため英語で入力します。
- ロール名:
BasicEC2S3AccessRole - 説明:
Read-only access to S3 from EC2 instances (hands-on)
同じ画面の「ステップ 1: 信頼されたエンティティを選択する」に、EC2 を信頼する信頼ポリシーが自動で生成されていることも確認できます。


「ロールを作成」をクリックします。
ステップ6: ロールの信頼ポリシーの確認
ロール作成後、上部に「ロール BasicEC2S3AccessRole が作成されました。」と表示されるので「ロールを表示」をクリックします(左側ナビゲーションの「ロール」から検索して開くこともできます)。
「信頼関係」タブを選択します。
信頼ポリシーに以下の内容が自動的に設定されていることを確認します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
この信頼ポリシーにより、EC2 サービスがこのロールを引き受けることが許可されています。


ステップ7: ユーザーの権限テスト
ステップ2 で控えたコンソールサインイン URL にブラウザのシークレットウィンドウでアクセスします。
「IAM user sign in」画面で basic-dev-user のユーザー名と控えたパスワードを入力し、「Sign in」をクリックします。初回は「Password reset」画面が表示されるので、古いパスワードと新しいパスワードを入力して「Confirm Password Change」をクリックします。
ログイン後、上部の検索バーに S3 と入力し、S3 コンソールを開きます。バケットの一覧が表示されることを確認します(BasicS3ReadPolicy の s3:ListAllMyBuckets による読み取り権限)。
試しに「バケットを作成」をクリックし、任意のバケット名を入力してページ下部の「バケットを作成」をクリックします。権限がないため「バケットを作成できませんでした」「バケットを作成するには、s3:CreateBucket アクセス許可が必要です。」というエラーが表示されます。


これにより、BasicS3ReadPolicy が読み取り専用であることが確認できます。
まとめ
- AWS IAM は、AWS リソースへのアクセスを認証と認可で制御するサービスであり、追加料金なしで利用できる
- IAM の主要コンポーネントはユーザー、グループ、ロール、ポリシーの 4 つである
- ポリシーは JSON 形式で記述し、Effect(許可/拒否)、Action(操作)、Resource(対象リソース)で構成される
- AWS マネージドポリシー、カスタマーマネージドポリシー、インラインポリシーの 3 種類があり、マネージドポリシーの使用が推奨される
- IAM ロールは EC2 インスタンスなどの AWS サービスに権限を付与する際に使用し、一時的な認証情報で安全にアクセスを提供する
- 最小権限の原則に基づき、業務に必要な最小限の権限のみを付与することがベストプラクティスである










