AWS IAMポリシーのAllowとDenyの違いを検証してみた

Last updated at 2026-11-04Posted at 2026-11-04

こんにちは、ソーイ株式会社の髙﨑です。

私は業務でIAMロールやIAMポリシー、IAMユーザーを作成することがありますが、それぞれの役割や違いについては曖昧な理解のままでした。

そこで今回は、IAMの基本的な仕組みを整理し、IAMポリシーのAllowとDenyがどのように評価されるのか、IAM Policy Simulatorを使って検証しました。

本記事は、AWSを使い始めた方や、IAMを利用したことはあるものの、権限の仕組みについて理解を深めたい方を対象としています。

検証を通して確認したポイントは、以下の3つです。

IAMでは、明示的に許可されていない操作は原則として拒否される（暗黙的なDeny）
Allowを設定することで対象の操作を許可できるが、明示的なDenyがある場合は拒否される
IAMポリシーでAllowを設定していても、SCPなどのほかのアクセス制御によって拒否される場合がある

1. IAMとは

IAM（Identity and Access Management）は、AWSのサービスやリソースに対するアクセス権限を管理するためのサービスです。

AWSでは、S3やEC2などのさまざまなサービスを利用できますが、すべてのユーザーやサービスが自由にリソースを操作できる状態では、意図しない操作や情報漏洩につながる可能性があります。

そこでIAMを使用することで、「誰が」「どのリソースに対して」「どのような操作を行えるのか」を制御できます。

例えば、特定のユーザーにはS3のファイルを閲覧する権限のみを付与し、ファイルの削除は許可しないといった設定が可能です。

2. IAMユーザー・IAMロール・IAMポリシーの違い

IAMで使用する主な仕組みとして、IAMユーザー・IAMロール・IAMポリシーがあります。それぞれの役割を整理すると、以下のようになります。

項目	役割	使用例
IAMユーザー	AWSアカウント内で作成するID	特定のユーザーやアプリケーションの認証
IAMロール	ユーザーやAWSサービスなどが引き受け、一時的な認証情報を取得できるIAMのID	EC2からS3へのアクセス
IAMポリシー	AWSリソースに対する操作の許可・拒否を定義する	S3の読み取りを許可する

IAMユーザー

IAMユーザーは、AWSアカウント内で作成するIDです。

IAMユーザーには、AWSマネジメントコンソールにログインするためのパスワードや、AWS CLIなどからアクセスするためのアクセスキーを設定できます。

また、IAMポリシーを直接付与したり、IAMグループを通じて権限を付与したりすることで、操作できるAWSリソースを制御します。

ただし、現在は人がAWSにアクセスする場合、長期的な認証情報を持つIAMユーザーよりも、IAM Identity Centerなどを利用した一時的な認証情報の使用が推奨されています。

IAMロール

IAMロールは、IAMユーザーやAWSサービスなどが引き受けることのできるIAMのIDです。

IAMユーザーとは異なり、固定のパスワードや長期的なアクセスキーを持たず、ロールを引き受けた際に発行される一時的な認証情報を使用します。

例えば、EC2上で動作するアプリケーションからS3にアクセスする場合、EC2にIAMロールを設定することで、アプリケーション内にアクセスキーを直接記述せずにS3を操作できます。

IAMロールには、主に次の2つのポリシーが関係します。

信頼ポリシー：誰がそのIAMロールを引き受けられるかを定義する
許可ポリシー：そのIAMロールを使用して、どのような操作ができるかを定義する

IAMポリシー

IAMポリシーは、AWSリソースに対する操作の許可や拒否を定義するものです。

基本的にはJSON形式で記述し、IAMユーザーやIAMロールなどに関連付けて使用します。

例えば、以下は特定のS3バケット内のオブジェクトを取得する操作を許可するポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    }
  ]
}

このポリシーでは、EffectにAllowを指定することで、Actionに記述したs3:GetObjectを許可しています。

一方、EffectにDenyを指定すると、対象の操作を明示的に拒否できます。

IAMポリシーはIAMユーザーやIAMロールに付与するものだけでなく、S3バケットなどのリソースに設定するリソースベースポリシーもあります。

3. IAMポリシーの評価ルール

IAMポリシーでは、EffectにAllow（許可）またはDeny（拒否）を指定することで、AWSリソースに対する操作を制御できます。

ただし、IAMではAllowを設定していない操作も原則として拒否されます。そのため、アクセスが拒否される場合には「暗黙的なDeny」と「明示的なDeny」の2つがあります。

明示的なAllow

IAMでは、デフォルトですべての操作が拒否されており、ポリシーで明示的にAllowを設定することで、対象の操作が許可されます。

例えば、s3:GetObjectをAllowに設定すると、指定したS3オブジェクトの取得を許可します。

ただし、ほかのポリシーなどで明示的に拒否されている場合は、Allowを設定していても操作できません。

暗黙的なDeny

暗黙的なDeny（Implicit Deny）は、対象の操作を許可するポリシーが存在しないため、アクセスが拒否される状態です。

例えば、s3:GetObjectのみをAllowに設定している場合、s3:PutObjectは許可されていないため、暗黙的なDenyとなります。

明示的なDeny

明示的なDeny（Explicit Deny）は、ポリシーのEffectにDenyを指定して、対象の操作を拒否するものです。

IAMでは、同じ操作に対してAllowとDenyの両方が設定されている場合、明示的なDenyが優先されます。

例えば、あるポリシーでs3:GetObjectをAllowに設定していても、別のポリシーで同じ操作をDenyに設定していれば、その操作は拒否されます。

実務では、基本的に必要な操作をAllowで許可し、本番環境のリソース削除など、ほかのポリシーで許可されていても禁止したい操作がある場合に、明示的なDenyを使用します。

評価ルールのまとめ

ここまでの評価ルールを整理すると、以下のようになります。

Allow	明示的なDeny	評価結果
あり	なし	許可
なし	なし	暗黙的なDeny
あり	あり	明示的なDeny
なし	あり	明示的なDeny

※ この表は、基本的なIAMポリシーの評価ルールを示したものです。

IAMポリシーでAllowを設定していても、ほかのアクセス制御によって操作が拒否される場合があります。

想定どおりに操作できない場合は、以下の設定も確認するとよいでしょう。

SCP（サービスコントロールポリシー）：AWS Organizationsで、アカウント内の権限を制限する
アクセス許可の境界：IAMユーザーやIAMロールに付与できる権限の上限を設定する
リソースベースポリシー：S3バケットポリシーなど、リソース側でアクセスを制御する
セッションポリシー：一時的な認証情報を使用するセッションの権限を制限する

詳しくは、AWS公式ドキュメントの「ポリシーの評価論理」を参照してください。

4. IAMポリシーの動作を検証する

これまでの業務では、IAMポリシーを設定した後、AWS CLIなどで実際にコマンドを実行し、想定どおりの権限が付与されているかを確認していました。

今回は、IAM Policy Simulatorを使用して、AllowとDenyの評価ルールを検証します。

IAM Policy Simulatorは、AWSリソースを実際に操作することなく、IAMポリシーによって操作が許可・拒否されるかを確認できるツールです。
AWSマネジメントコンソールのIAM画面から、ナビゲーションメニューの「ポリシーシミュレーター」を選択すると利用できます。

明示的なAllow：許可した操作が実行可能と判定されるか
暗黙的なDeny：許可していない操作が拒否されるか
明示的なDeny：AllowとDenyの両方を設定した場合、Denyが優先されるか

4.1 検証環境

検証用のIAMユーザーを作成し、Amazon S3に対する操作をシミュレーションしました。

検証にはIAM Policy Simulatorを使用するため、実際のS3バケットやオブジェクトは作成していません。

項目	設定内容
検証ツール	IAM Policy Simulator
IAMユーザー	`iam-policy-test-user`
対象サービス	Amazon S3
対象リソース	`arn:aws:s3:::iam-policy-test-bucket/test.txt`

4.2 明示的なAllowを検証する

最初に、s3:GetObjectを許可するポリシーを作成し、IAMユーザーに設定しました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::iam-policy-test-bucket/*"
    }
  ]
}

このポリシーでは、iam-policy-test-bucket内のオブジェクトを取得する操作を許可しています。

IAM Policy Simulatorで、以下の条件を指定してシミュレーションを実行しました。

項目	設定内容
Action	`s3:GetObject`
Resource	`arn:aws:s3:::iam-policy-test-bucket/test.txt`
期待結果	`許可`

シミュレーション結果は許可となり、想定どおりの結果が得られました。

4.3 暗黙的なDenyを検証する

次に、4.2で設定したポリシーを変更せず、許可していないs3:PutObjectをシミュレーションしました。

項目	設定内容
Action	`s3:PutObject`
Resource	`arn:aws:s3:::iam-policy-test-bucket/test.txt`
期待結果	`暗黙的な拒否`

結果は暗黙的な拒否となりました。

今回のポリシーではs3:GetObjectのみを許可しているため、s3:PutObjectは明示的なDenyがなくても拒否されます。

4.4 明示的なDenyを検証する

最後に、AllowとDenyの両方が設定されている場合の動作を検証しました。

4.2で設定したAllowポリシーはそのまま残し、新たに以下のDenyポリシーを追加しました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::iam-policy-test-bucket/*"
    }
  ]
}

これにより、IAMユーザーには同じs3:GetObjectに対して、AllowとDenyの両方が設定された状態になります。

ポリシー	Effect	Action
AllowGetObject	Allow	`s3:GetObject`
DenyGetObject	Deny	`s3:GetObject`

この状態で、4.2と同じ条件でシミュレーションを実行しました。

項目	設定内容
Action	`s3:GetObject`
Resource	`arn:aws:s3:::iam-policy-test-bucket/test.txt`
期待結果	`明示的な拒否`

シミュレーション結果は明示的な拒否となりました。

4.2では許可されていたs3:GetObjectが、Denyポリシーの追加によって拒否されるようになりました。このことから、AllowとDenyの両方が設定されている場合は、明示的なDenyが優先されることがわかります。

4.5 検証結果のまとめ

今回の検証結果をまとめると、以下のようになりました。

検証内容	対象操作	評価結果
明示的なAllow	`s3:GetObject`	許可
暗黙的なDeny	`s3:PutObject`	暗黙的な拒否
明示的なDeny	`s3:GetObject`	明示的な拒否

4.6 IAM Policy SimulatorでSCPによる拒否が表示されたケース

検証中、IAMポリシーでAllowを設定しているにもかかわらず、IAM Policy SimulatorでAWS Organizationsによる拒否が表示されることがありました。

設定を確認したところ、IAM Policy Simulatorの「サービスコントロールポリシー（SCP）」のトグルが有効になっていました。

今回の目的はIAMポリシーのAllowとDenyの評価ルールを確認することだったため、SCPのトグルを無効にして再度シミュレーションを実行しました。

その結果、想定どおりの評価結果を確認できました。

IAM Policy Simulatorでは、IAMポリシーだけでなくSCPなどのアクセス制御も評価対象になる場合があります。IAMポリシーで許可している操作が拒否された場合は、シミュレーション結果の詳細やSCPの評価設定も確認するとよいでしょう。

なお、SCPのトグルを無効にする操作は、シミュレーションの評価条件を変更するものであり、実際に適用されているSCPの設定を変更するものではありません。

そのため、シミュレーション上で許可と判定された場合でも、実際の環境では適用されているSCPによって操作が拒否される可能性があります。

5. まとめ

今回は、IAMユーザー・IAMロール・IAMポリシーの役割を整理し、IAM Policy Simulatorを使ってAllowとDenyの評価ルールを検証しました。

これまでの業務では、IAMポリシーを設定した後にAWS CLIなどでコマンドを実行して権限を確認していたため、IAM Policy Simulatorを使うのは今回が初めてでした。
実際のAWSリソースを操作せずに権限を検証でき、許可・拒否の判定も画面上でわかるため、使いやすかったです。

今後は、IAMポリシーを作成・変更する際の事前確認や、アクセス拒否の原因調査にも活用していきたいと思います。

6. 参考資料

お知らせ

技術ブログを週1〜2本更新中、ソーイをフォローして最新記事をチェック！
https://qiita.com/organizations/sewii

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up