SJ blog
security
A

信頼度ランク

S 公式ソース確認済み
A 成功実績多数・失敗例少数
B 賛否両論
C 動作未確認・セキュリティリスク高
Z 個人所感

IAMパーミッションバウンダリー — 権限委任を安全に実現する仕組み

IAMパーミッションバウンダリーの仕組み、有効な権限の計算方法、開発者への権限委任パターン、SCPとの違いを試験対策の観点から解説します。

一言結論

パーミッションバウンダリーは権限を付与するものではなく上限を設けるだけであり、開発者へのIAM権限委任を安全に行うには「バウンダリー付きロールのみ作成可能・バウンダリー自体の変更はDeny」という2段構えの設計が権限昇格を防ぐ唯一の確実な方法だ。

パーミッションバウンダリーとは何か

IAMパーミッションバウンダリー(Permissions Boundary)は、IAMエンティティ(ユーザー・ロール)に設定できる権限の上限(最大権限)を定義するマネージドポリシーだ。

重要な点:バウンダリーは権限を付与しない。「この範囲内でしか権限を行使できない」という天井を設けるだけだ。

有効な権限の計算式

有効な権限 = アイデンティティベースポリシー ∩ パーミッションバウンダリー

(ただし明示的DenyとSCPは別途適用される)

具体例

アイデンティティポリシー: s3:*, ec2:*, iam:*
バウンダリー:             s3:*, rds:*

有効な権限: s3:* のみ

→ ec2:* はポリシーにはあるがバウンダリーにない → 使えない
→ rds:* はバウンダリーにあるがポリシーにない → 使えない

主なユースケース:権限委任(Developer Delegation)

管理者が開発者に「自分でIAMロールを作れる権限」を与えつつ、「自分以上の権限のロールは作れない」制約をかけるパターン。

// 管理者が開発者に付与するポリシー
{
  "Statement": [
    {
      "Sid": "CreateRoleWithBoundaryOnly",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:PutRolePolicy",
        "iam:AttachRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary":
            "arn:aws:iam::ACCOUNT:policy/DeveloperBoundary"
        }
      }
    },
    {
      "Sid": "NoBoundaryModification",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRolePermissionsBoundary",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "*"
    }
  ]
}

このポリシーにより:

  • 開発者は DeveloperBoundary が設定されたロールだけ作成できる
  • バウンダリー自体の削除・変更はできない(権限昇格を防止)

DeveloperBoundaryの定義例

// 開発者が作れるロールの最大権限
{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "account:*"
      ],
      "Resource": "*"
    }
  ]
}

バウンダリーが適用されないケース

バウンダリーは以下には適用されない

対象バウンダリー適用
IAMユーザー(直接設定時)✅ 適用される
IAMロール(直接設定時)✅ 適用される
リソースベースポリシー❌ 適用されない
SCPs❌ 別途独立して評価
AWS Organizations管理アカウント❌ SCPが適用されないのと同様

重要: リソースベースポリシーからの直接アクセス(Principal指定)にはバウンダリーが介在しない。

SCPとパーミッションバウンダリーの違い

SCP                              パーミッションバウンダリー
───────────────────────────────────────────────────────
適用先: アカウント全体             適用先: 個別のIAMエンティティ
設定者: Organizations管理者        設定者: IAM管理者
適用範囲: 全IAMエンティティ         適用範囲: 設定したエンティティのみ
目的: アカウントの最大権限制御      目的: 個別エンティティの最大権限制御

複合した場合:有効な権限 = SCP ∩ バウンダリー ∩ アイデンティティポリシー

バウンダリーの確認・設定

# ロールに設定されているバウンダリーを確認
aws iam get-role --role-name MyRole \
  --query 'Role.PermissionsBoundary'

# ロールにバウンダリーを設定
aws iam put-role-permissions-boundary \
  --role-name MyRole \
  --permissions-boundary arn:aws:iam::ACCOUNT:policy/MyBoundary

# バウンダリーを削除(管理者のみ実行可能にするべき)
aws iam delete-role-permissions-boundary \
  --role-name MyRole

試験対策チェックリスト

  • バウンダリーは権限を与えない(上限を設けるだけ)
  • 有効な権限は「ポリシーとバウンダリーの交差部分」
  • リソースベースポリシーにはバウンダリーが効かない
  • バウンダリー削除を Deny することで権限昇格を防ぐ
  • IAMグループにはバウンダリーを設定できない(ユーザーとロールのみ)
  • バウンダリーなしで作られたロールは無制限になる(危険)

まとめ

パーミッションバウンダリーは「開発者へのIAM権限委任を安全に行う」ための仕組みだ。バウンダリー設定なしのロール作成を禁止し、かつバウンダリー自体の変更も Deny することで、管理者が意図した範囲内に開発者の権限を封じ込めることができる。SCSでは特に権限昇格防止のシナリオとして出題される。