IAMユーザによる権限制御

はじめに

このドキュメントの主旨はAWSセキュリティを体系的に整理する方法の一案に書かれています。

概要

ルートユーザは、AWSアカウント内のすべてのリソースに対して無制限の権限を持つ。そのため、日常的な作業にルートユーザを使用すると、設定ミスや操作ミスが重大なセキュリティインシデントにつながるおそれがある。

この問題に対し、AWSでは、必要最低限の権限を持つ認証主体を用いて運用する仕組みを提供している。この認証主体をIAMユーザと呼ぶ。IAMユーザに対し、「どのリソースに対してどの操作を行えるか」を設定することで、最小権限の原則[1]に基づいた運用が可能となる。設定ルールのことはIAMポリシーと呼ばれる。

権限による制御の例

2つのS3バケット(Bucket1、Bucket2)が存在するとする。また、以下のIAMポリシー（オレンジ枠の箇所）を持つ2つのIAMユーザが存在するとする。

• IAMユーザA：Bucket1に対するRead操作のみが許可されている
• IAMユーザB：両方のバケットに対するFull Accessが許可されている

このとき、IAMユーザAは Bucket1 の読み取りのみ可能であり、Bucket1への書き込み操作や Bucket2 へのアクセスはPermission Checkによってブロックされる。一方、IAMユーザBは両方のバケットに対するすべての操作を実行できる。

最初のIAMユーザはルートユーザによって作成される。実運用では、ルートユーザの使用頻度を抑えるため、
"ルートユーザが管理者権限を持つIAMユーザを作成し、そのIAMユーザが他のIAMユーザ（および付与するIAMポリシー）などを管理する"
といった運用が考えられる。

IAMユーザの認証は、AWSアカウントID、IAMユーザ名、パスワードで行う[2]。これらは、IAMユーザを作成するルートユーザもしくは管理者権限をもつIAMユーザによって作成される。

AWSが担うこと、ユーザが担うこと

IAMユーザによるアクセス権限制御においては、以下のようにAWSとユーザの責任範囲が分離されている。

AWS： IAMポリシーのフォーマットおよびユーザが指定したIAMポリシーに基づいて権限を適切にチェックする仕組みを提供する。

ユーザ： IAMポリシーの設定をする。

以降では、ユーザが設定するIAMポリシーについて説明する。さらにPermission Checkについて説明する。

IAMポリシー

代表的なIAMポリシーは以下のとおりである。

• Identity-based policy：「どのリソースに対してどの操作を実行できるか（許可：Allow）。またはできないか（拒否：Deny）」を定義する。これは、IAMユーザなどのプリンシパルに付与される。
• Resource-based policy：「どのプリンシパルが、どの操作を実行できる、またはできないか」を定義する。このポリシーはリソースに付与される。

AWSにはポリシーが大きく分けて7種類存在するが[3]、ここでは代表的な Identity-based policy と Resource-based policy のみを扱う。

IAMポリシーのフォーマット

IAMポリシーはJSON形式で表現され、主に以下の要素で構成される。

項目	説明
Effect	許可（Allow）または拒否（Deny）
Action	許可または拒否する操作（例：s3:GetObject など）
Resource	操作対象となるリソース（例：特定の S3 バケットやオブジェクト）

ActionとResourceの組み合わせで対象となる操作とリソースが特定され、それに対してEffectに基づく認可判断が行われる。

Identity-based Policyの具体例

{
  "Version": "2026-01-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::bucket1/*"
    }
  ]
}

このポリシーでは、「bucket1 内のオブジェクトを取得する操作」のみが許可され、それ以外の操作はすべて拒否される。

Resource-based Policyの具体例

{
  "Version": "2026-01-17",
  "Statement": [
    {
      "Sid": "AllowReadFromSpecificUser",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/UserA"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::bucket1/*"
    }
  ]
}

このポリシーでは、UserAはbucket1のオブジェクトを読み取ることができる。

Permission Check

Permission Checkは、次の手順で行われる。

1）アクセス元の主体に付与された Identity-based policy と、アクセス先リソースに付与された Resource-based policy のそれぞれについて独立の評価を行う。

2）個々のポリシー評価を踏まえて最終的な認可判断を行う。

以降では、それぞれの評価について説明する。

1）"各"ポリシーのPermission Check

まず、個々のIAMポリシーの評価について説明する。IAMにおける認可判断は、設定ミスによる過剰な権限付与を防ぐため、明示的な許可が存在しない限り操作を拒否する設計となっている[3,4]。具体的なルールは以下のとおりである。

1. 明示的な拒否は最優先される
   評価対象となるポリシーのいずれかでDenyが指定されている場合、他にAllowが存在していてもその操作は拒否される。
2. 明示的な許可が存在する場合のみ許可される
3. 上記のいずれにも該当しない場合は暗黙的に拒否（Implicit Deny）される

「明示的な許可が存在し、かつ拒否が存在しない場合」にのみ操作が許可される。

フローチャートで示すと以下のとおりである。

上記の図は、IAM における認可判断の基本的な流れ[5]を簡略化して示したものである。AWS は、アクセス要求が発生すると、まずアクセス先リソースに設定されたポリシーと、アクセス主体に設定されたポリシーを順に評価し、それらの結果を組み合わせて最終的な許可・拒否を判断する。

最初に確認されるのは、アクセス先リソースに Resource-based policy が設定されているかである。Resource-based policy が存在する場合、次に、そのポリシーの中に Allow が存在し、かつ呼び出し元のプリンシパル（またはその所属アカウント）に対する許可であるかが評価される。ここで該当する Allow が存在しない場合、そのポリシーによってアクセスは許可されない。

次に、アクセス主体である IAM ユーザに Identity-based policy が付与されているかが確認される。Identity-based policy が存在する場合、その中に 対象となるリソースおよび操作に対する Allow が含まれているかが評価される。

2）Permission Checkの全体評価

この判断方法は、同一 AWS アカウント内のアクセスか、異なる AWS アカウント間（クロスアカウント）のアクセスかによって異なる。

• 同一 AWS アカウント内の場合[5]：Identity-based policy または Resource-based policyのどちらか一方で明示的に拒否された場合は、最終的なアクセスは拒否される。そうでない場合、いずれか一方で明示的に許可されていれば、最終的にアクセスは許可される。

明示的な拒否がない場合において、主体またはリソースのいずれか一方で許可していれば最終的に許可されるという挙動は、"本来、認可は主体側またはリソース側のいずれか一方で定義すれば十分である"という設計思想に基づくものであると考えられる。

• クロスアカウントアクセスの場合[6]：アクセス元の Identity-based policy による許可と、アクセス先リソースに設定された Resource-based policy による許可の両方が満たされた場合にのみ、アクセスは許可される。

この評価は、異なる AWS アカウントがそれぞれ独立した管理主体であることを前提とし、信頼境界を越えるアクセスについては、双方の管理者による明示的な合意を要求する設計思想に基づくものであると考えられる。この二重の認可により、意図しない権限付与（設定ミス）を防ぐことが可能となるのリスクを軽減できる。

参考文献

[1] AWS. (n.d.). Adopting a least privilege architecture in AWS. https://pages.awscloud.com/rs/112-TZM-766/images/SANS_AWS%20Marketplace_Least%20privilege_Whitepaper.pdf

[2] 松本照吾 他. 2023年12月. AWSではじめるクラウドセキュリティ：クラウドで学ぶセキュリティ設計／実装.

[3]AWS. (n.d.). Policies and permissions in AWS Identity and Access Management. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html (Accessed on 2026-01-11)

[4]AWS. (n.d.). How AWS enforcement code logic evaluates requests to allow or deny access. Available at: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html (Accessed on 2026-01-11)

[5]AWS. (n.d.). Policy evaluation for requests within a single account. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-basics.html (Accessed on 2026-01-17)

[6]AWS. (n.d.). Cross-account policy evaluation logic. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html (Accessed on 2026-01-11)