AWS IAM 権限境界と SCP

IAMのアイデンティティベースポリシーは、ユーザーやロールに対してAWS APIの操作を許可します。しかし、権限を委任する環境では、管理者が付与した許可の範囲を超えないよう、主体ごとに「これ以上の権限は持てない」という上限を設けたいことがあります。そのためのIAMの仕組みが**権限境界（Permissions boundary）**です。

権限境界は、許可を追加するポリシーではなく、許可可能な最大範囲を定めるガードレールです。許可ポリシーと境界の両方が認める操作だけが、通常のアイデンティティベース権限として実効権限になります。AWS Organizationsの**サービスコントロールポリシー（SCP）**も上限を管理するガードレールですが、適用する階層が異なります。権限境界は個々のIAMユーザー／ロールに、SCPは組織階層上のアカウントに適用されます。

権限境界が制御するもの

権限境界はIAMユーザーまたはIAMロールに設定し、そのエンティティにアタッチされたアイデンティティベースポリシーが許可できる最大範囲を決めます。境界にはAWS管理ポリシーまたはカスタマー管理ポリシーを使います。境界を設定したからといって、境界文書に列挙された操作がそのユーザー／ロールに実行可能になるわけではありません。

たとえば、バッチ処理用ロールのアイデンティティポリシーが、ログ記録、構成値の読み取り、データベース更新を許可している一方、権限境界がログ記録と構成値の読み取りだけを許可しているとします。このロールの通常の実効権限には、ログ記録と構成値の読み取りは残りますが、データベース更新は含まれません。アイデンティティポリシー側に許可が書かれていても、境界が上限の外に置いた操作は認められません。

許可の共通部分で考える

権限境界の基本的な評価は、アイデンティティベースポリシーによる許可と権限境界による許可の**共通部分（AND）**です。

アイデンティティベースポリシー	権限境界	基本的な結果
対象操作を許可	対象操作を許可	他の制限がなければ許可され得る
対象操作を許可	対象操作を許可しない	境界が上限として働き、許可されない
対象操作を許可しない	対象操作を許可	境界だけでは権限が生まれず、許可されない
対象操作を許可しない	対象操作を許可しない	許可されない

ここでいう「許可しない」には、対象アクションを許すAllowがない状態（暗黙的Deny）が含まれます。通常、境界ポリシーのAllow文は許可の上限を表し、境界に許可が書かれていない操作を許可可能範囲から外します。どこかに適用されるポリシーが対象リクエストを明示的にDenyしていれば、その拒否はAllowより優先されます。

このため、境界を設計・変更するときは「境界に何を許可するか」だけでなく、IAM権限ポリシーが何を許可しているかも併せて確認します。境界を広げても権限ポリシーが許可していない操作は実行できず、逆に権限ポリシーを広げても境界を越える権限は得られません。

JSONで表す境界の例

次の権限境界の例では、デプロイ用ロールに対して、特定のAWSリージョン・アカウントにあるアプリケーション設定用Systems Manager Parameter Store値の読み取りだけを上限として認めます。ARN中のアカウントIDやパラメータパスは説明用です。実環境では、対象のアカウント・リージョン・パスに合わせて設計します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LimitToApplicationConfigurationReads",
      "Effect": "Allow",
      "Action": "ssm:GetParameter",
      "Resource": "arn:aws:ssm:ap-northeast-1:111122223333:parameter/service-config/*"
    }
  ]
}

この文書を境界としてロールに設定しても、それだけでssm:GetParameterが実行できるわけではありません。ロールのアイデンティティベースポリシーにも、そのアクションと対象パラメータへの許可が必要です。また、他のポリシーが同じロールに追加で広い許可を与えた場合でも、この境界が許可しない操作は通常のアイデンティティベース権限として認められません。

権限委任と最小権限のガードレール

権限境界は、チームや開発者にIAMロール作成などの運用を委任しながら、その委任先が付与できる権限の最大範囲を制御する場合に役立ちます。たとえば、各アプリケーションチームが自分たちの実行ロールに必要なポリシーを付けられるようにしつつ、ロールには組織共通の境界を設定する運用が考えられます。

この構成では、権限を委任する管理者が、境界を設定する操作や境界を変更・削除する操作も適切に制御しなければなりません。境界の設定を必須にするためのポリシー条件を設けたり、権限を委任された主体が境界自体を自由に差し替えられないようにしたりします。境界を付け忘れたアイデンティティを作成できる構成では、意図した上限管理が成立しない可能性があります。

境界はIAMユーザーやロールに個別に設定する制御です。IAMグループに境界を付けて、そのグループの全メンバーへ一括で適用する仕組みではありません。対象となるエンティティと、その境界の付与・更新・削除権限を明確に管理します。

OrganizationsのSCPとの関係

SCPはAWS Organizationsで使用する組織ポリシーです。組織のルート、組織単位（OU）、アカウントにアタッチして、組織のメンバーアカウントにあるIAMユーザーとIAMロールが利用できる権限の最大範囲を管理します。権限境界が特定のユーザー／ロール単位であるのに対し、SCPは組織階層を通してアカウント内のIAM主体にガードレールを適用します。

例として、組織全体ではデータベース運用を許可できる状態にしていても、本番環境を格納するOUに対してデータベース削除操作を拒否するSCPを適用できます。そのOU配下のアカウントでは、IAMポリシーに削除のAllowがあっても、SCPの明示的な拒否が優先されます。アカウント内の全IAM主体を対象にした組織レベルの制約であり、特定ロールだけを狙う権限境界とは目的・適用範囲が違います。

組織階層におけるSCPの評価

SCPはルートからOU、アカウントへ継承される適用階層を持ちます。メンバーアカウントで操作できる範囲は、組織階層上で適用されるSCPが許可する範囲を満たしたうえで、IAMポリシーなど実際に権限を付与するポリシーによって許可される必要があります。祖先階層で許可されていても、子OUやアカウントに適用されるポリシーがその操作を許可しない、または明示的に拒否するなら、その制約が作用します。

SCPはIAMユーザーやロールに直接の許可を付与しません。SCPであるサービスを利用可能にしていても、IAMアイデンティティポリシーやリソースポリシーなどによる許可が別途必要です。逆にIAMポリシーが許可していても、適用されるSCPがその操作を許さない場合は実行できません。

SCPは組織のすべてのアカウントに同じように作用するわけではありません。SCPはメンバーアカウント内のIAMユーザーやロールに適用され、Organizationsの管理アカウントのユーザー／ロールには適用されません。また、サービスリンクロールの権限はSCPで制限されません。AWS公式ドキュメントに記載された対象外タスクやサービスの例外もあるため、組織全体の制限を設計するときは適用対象を確認してください。

SCPと権限境界の比較

比較項目	IAM権限境界	Organizations SCP
主な設定対象	個々のIAMユーザーまたはロール	組織ルート、OU、AWSアカウント
主な役割	エンティティのアイデンティティベースポリシーが許可できる上限を定める	メンバーアカウントのIAMユーザー／ロールが利用できる権限の上限を組織階層で定める
それ自体で許可を付与するか	付与しない	付与しない
実際に操作するための許可	アイデンティティポリシー等が別途必要	IAMポリシーやリソースポリシー等が別途必要
適用範囲の特徴	対象エンティティ単位	階層上の対象アカウント内にある主体へ横断的に適用（例外あり）

どちらもJSON形式のポリシー文書を使い、Version、Statement、Effect、Action、Resource、Conditionなどのポリシー要素を記述します。ただし、同じJSON形式だからといって同じ種類のポリシーになるわけではありません。SCPにはIAMアイデンティティポリシーとは異なる適用先・評価規則があり、たとえばIAMの主体を表すPrincipalをSCPに記述するものではありません。ポリシー種別に応じた対応要素と制約を確認し、権限境界の文書をそのままSCPとして、またはSCPをそのままIAM権限ポリシーとして扱わないでください。

評価時に見落としやすい点

明示的DenyはAllowを上書きする

アイデンティティベースポリシーや境界に許可があっても、対象リクエストに適用されるポリシーが明示的なDenyを返す場合、最終結果は拒否です。権限境界やSCPだけではなく、リソースベースポリシーなども含め、該当する拒否がないか確認します。

リソースポリシーによる直接許可には評価上の違いがある

「権限境界の許可範囲とIAMポリシーの許可範囲の共通部分」という説明は、アイデンティティベース権限の基本をつかむためのものです。リソースベースポリシーがIAMロールそのもの、ロールセッション、IAMユーザーなどのどのプリンシパルを直接許可するかによって、暗黙的Denyの扱いを含む評価が異なる場合があります。特にロールセッションARNへの直接許可は、ロールに付いた権限境界やセッションポリシーによる制限と同じ扱いにならないケースがあります。

したがって、アクセス拒否の調査では「境界にAllowがあるか」だけで結論を出さず、要求に使われた実際のプリンシパル（ロールかロールセッションか）、リソースポリシーの許可先、明示的Denyの有無、各ポリシーの適用条件を併せて調べます。境界を設けても、リソースベースポリシーを含むすべての認可経路が常に単純な共通部分として動くとは限りません。

NotPrincipalとDenyの組み合わせ

AWS IAMでは、権限境界が設定されたユーザーまたはロールに対して、リソースベースポリシーのNotPrincipalとEffect: "Deny"を組み合わせると、NotPrincipalの値にかかわらず境界を持つプリンシパルが拒否される問題が起こり得ます。AWSは、この目的ではNotPrincipalの代わりにaws:PrincipalArnコンテキストキーとArnNotEqualsなどの条件演算子を使って対象を除外する方法を推奨しています。

この挙動は、一般的な「許可と境界の共通部分」という説明だけでは読み違えやすい重要な例外です。境界を設定した後にリソースベースポリシーを追加・変更する場合も、PrincipalやNotPrincipal、条件の組み合わせを検証します。

アクセス拒否を調べる手順

境界やSCPがある環境でAPI呼び出しが拒否されたときは、許可をむやみに追加するのではなく、要求の各要素を順番に照合します。

1. 要求主体を特定する：IAMユーザー、IAMロール、ロールセッション、AWSサービスなど、実際にAPIを呼び出した主体を確認する。
2. 対象アクションとリソースを確認する：AWS APIアクション名、対象ARN、リージョン、リソースタグやリクエスト条件を照合する。
3. 権限を付与するポリシーを確認する：アイデンティティベースポリシーまたは該当するリソースベースポリシーに、要求を許可するAllowがあるか調べる。
4. IAMユーザー／ロールの境界を確認する：権限境界が付いているか、境界がアクション・リソース・条件を許可するかを調べる。
5. Organizationsの適用ポリシーを確認する：メンバーアカウントか管理アカウントか、所属OUやアカウントへどのSCPが適用され、階層全体で操作が認められるかを追う。
6. 明示的Denyと他の制限を調べる：リソースポリシー、セッションポリシー、VPCエンドポイントポリシーなど、要求に適用される拒否・制限と、プリンシパルを直接指定した許可を確認する。

IAMポリシーにAllowが見つかったことだけでは、API要求が成功する根拠になりません。許可を与えるポリシーと、許可の上限を定める境界・組織ポリシーを別々に確認することが、権限評価を読み解く基本です。

DVA試験での判断ポイント

• 権限境界はIAMユーザーまたはロールの最大権限を定める。IAMグループやAWSアカウント全体に設定するポリシーではない。
• 権限境界のAllowは権限を付与しない。アクションを実行するには、別の権限付与ポリシーによる許可が必要。
• 通常のアイデンティティベース権限は、権限ポリシーと境界の両方が認める範囲に制限される。片方だけのAllowでは足りない。
• 明示的Denyは適用されるAllowに優先する。境界やSCPにAllowがあっても、明示的Denyを打ち消せない。
• SCPはOrganizationsのルート／OU／アカウントに適用する組織レベルの上限であり、メンバーアカウントのIAM主体に権限を付与しない。
• IAM権限境界とSCPはどちらもガードレールだが、対象と適用範囲が異なる。複数の上限が適用されるなら、すべてを満たす必要がある。
• SCPは管理アカウントのIAM主体やサービスリンクロールには適用されない。例外を含む適用対象を確認する。
• JSONの見た目が似ていても、SCP・権限境界・IAM権限ポリシーは別のポリシー種別である。適用先と許可を与えるかどうかを区別する。
• リソースポリシーがロールセッションなどを直接許可する場合や、境界付きプリンシパルに対するNotPrincipalとDenyには評価上の注意がある。

公式ドキュメント

• IAMエンティティの権限境界
• ポリシー評価ロジック
• AWS Organizationsのサービスコントロールポリシー（SCP）
• SCPの評価