AWS IAM Permission Boundaries入門｜委任管理を安全に実現するアクセス制御の実践ガイド

クラウド環境でチームが拡大すると、こんな課題が生まれます。「開発者が自分のマイクロサービス用IAMロールを自分で作れるようにしたい。でも AdministratorAccess を自由に付けられると困る」。最小権限の原則を守りながらIAM操作を委任するには、どうすればよいのでしょうか。

その答えが AWS IAM Permission Boundaries（アクセス許可の境界）です。通常のIAMポリシーだけでは防げない「権限昇格（Privilege Escalation）」のリスクを抑えつつ、開発者や運用担当者に必要最小限のIAM操作権限を委任できます。

この記事では、Permission Boundaries の仕組みから実際の設定手順まで解説します。オンプレのActive Directory委任管理との比較も交えながら、「なぜこの機能が必要なのか」を現場視点で順を追って説明します。

Permission Boundaries が必要な理由 ── 権限昇格の仕組みを知る

まず、Permission Boundaries なしで開発者にIAM操作を委任するとどうなるか考えてみます。

たとえば、開発者Aに iam:CreateRole と iam:AttachRolePolicy の権限を付与したとします。本来の目的は、アプリ用のIAMロールを自分で作れるようにすることです。しかしここに落とし穴があります。

開発者Aは次の操作が可能になります。

・新しいIAMロールを作成する
・そのロールに AdministratorAccess ポリシーを付与する
・自分自身が sts:AssumeRole でそのロールを引き受ける

結果として、開発者Aは事実上の管理者権限を手に入れてしまいます。本人に付与したポリシーは限定的でも、IAM操作権限を通じて間接的に権限を昇格させられるのです。これが「権限昇格（Privilege Escalation）」と呼ばれる問題です。

オンプレのActive Directoryには、OU（組織単位）レベルで委任範囲を制限する機能がありました。「この管理者はこのOU配下のパスワードリセットのみ可能」といった細かい委任設計です。AWSでは Permission Boundaries がこれに相当します。

Permission Boundaries の仕組み ── 2つのポリシーの「積」で有効権限が決まる

Permission Boundaries を理解するには、IAMの権限評価ロジックを押さえる必要があります。

通常、IAMエンティティ（ユーザー/ロール）の有効な権限（Effective Permissions）はアイデンティティベースポリシーの内容で決まります。Permission Boundaries を設定すると、評価式が変わります。

有効な権限 = アイデンティティベースポリシー ∩ Permission Boundary

つまり、両方のポリシーで許可されているアクションだけが実際に実行できます。どちらか一方しか許可していない場合、そのアクションは拒否されます。

Permission Boundaries は権限を「追加」するものではありません。あくまでアイデンティティベースポリシーで許可されている範囲の上限を定めるものです。Permission Boundary のみ設定してもアイデンティティベースポリシーがなければ何もできません。

1. 具体例：S3 フルアクセスポリシーでも境界で制限される

以下の状況を考えます。

・アイデンティティベースポリシー: AmazonS3FullAccess（S3の全操作を許可）
・Permission Boundary: S3 の Read 操作のみ許可

この場合、開発者は S3 の読み取りしか実行できません。アイデンティティベースポリシーがフルアクセスでも、Permission Boundary が上限として機能するためです。

2. 評価ロジックの全体像

AWSの権限評価は、複数のポリシーが重なります。評価順序は次のとおりです。

①明示的な Deny（最優先） → ②SCPによる制限 → ③リソースベースポリシー → ④Permission Boundary → ⑤アイデンティティベースポリシー → ⑥暗黙の Deny（デフォルト拒否）

Permission Boundary は SCP よりも後に評価されます。SCP で禁止されているアクションは Permission Boundary で許可しても実行できません。SCP はアカウント全体のガードレール、Permission Boundary は特定エンティティの上限ライン、という役割分担です。

Permission Boundaries でできること・できないこと

実践シナリオ ── 開発チームへの安全な委任管理を実装する

Permission Boundaries の最も典型的な使い方は、開発者自身がアプリ用のIAMロールを作成・管理できるようにするケースです。3つのステップで実装します。

1. 境界ポリシー（Permission Boundary 用ポリシー）を作成する

まず、開発者が作成するロールに付与できる権限の「上限」を定めた境界ポリシーを作成します。たとえば、S3 と DynamoDB の操作のみ許可するポリシーです。

# AWS CLI: Permission Boundary として使うポリシーを作成する
aws iam create-policy \
  --policy-name dev-team-boundary-policy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "s3:*",
          "dynamodb:*",
          "logs:*",
          "iam:PassRole"
        ],
        "Resource": "*"
      }
    ]
  }'

# 作成後にARNを確認する
# 出力例: arn:aws:iam::123456789012:policy/dev-team-boundary-policy

iam:PassRole を含めているのは、Lambda や ECS からIAMロールを渡す際に必要なためです。これを忘れると、後述するはまりポイントに引っかかります。

2. 開発者ロールに委任管理ポリシーを付与する

次に、開発者のIAMロール（またはグループ）に次のポリシーを付与します。ポイントは Condition で Permission Boundary の指定を強制していることです。

# 開発者に付与する委任管理ポリシーの例（policy.json として保存）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateRoleOnlyWithBoundary",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePolicy",
        "iam:DeleteRolePolicy",
        "iam:TagRole"
      ],
      "Resource": "arn:aws:iam::123456789012:role/dev-*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary":
            "arn:aws:iam::123456789012:policy/dev-team-boundary-policy"
        }
      }
    },
    {
      "Sid": "AllowReadIAM",
      "Effect": "Allow",
      "Action": [
        "iam:GetRole",
        "iam:ListRoles",
        "iam:ListAttachedRolePolicies",
        "iam:GetPolicy",
        "iam:ListPolicies"
      ],
      "Resource": "*"
    }
  ]
}

Resource を arn:aws:iam::123456789012:role/dev-* に絞っているのも重要です。開発者が作成できるロール名を dev- プレフィックス付きに限定することで、既存の運用ロールへの誤操作を防ぎます。

3. 開発者が実際にロールを作成する

# 開発者がアプリ用ロールを作成する際は --permissions-boundary を必ず指定する
aws iam create-role \
  --role-name dev-myapp-lambda-role \
  --assume-role-policy-document file://lambda-trust-policy.json \
  --permissions-boundary arn:aws:iam::123456789012:policy/dev-team-boundary-policy

# --permissions-boundary を省略すると Condition 違反で拒否される
# エラー例: User: ... is not authorized to perform: iam:CreateRole on resource: ...
# with an explicit deny in an identity-based policy

このコマンドを実行すれば、dev-myapp-lambda-role に後からどんなポリシーを付けても、dev-team-boundary-policy が許可している範囲（S3・DynamoDB・CloudWatch Logs・iam:PassRole）以外は実行できません。開発者はIAM管理の自由度を得ながら、管理者が設定した「上限ライン」を超えられない設計になります。

SCPとPermission Boundariesの違いを整理する

マルチアカウント環境では SCP（Service Control Policy）と組み合わせて使うことが多いため、違いを明確にしておきます。

SCP と Permission Boundaries は「同じ機能の別バージョン」ではなく、役割が異なります。SCP はマルチアカウント環境でアカウント単位のガードレールを設ける。Permission Boundaries は特定のユーザーやロールへの権限委任を安全に行う。両者は補完関係にあり、組み合わせて使うのが理想的な設計です。

SCP の詳細については、AWS Organizations入門｜マルチアカウント管理とSCPでガバナンスを統制する実践ガイドで解説しています。

IAM Identity Center（SSO）との組み合わせ

AWS IAM Identity Center（旧 AWS SSO）を使ってフェデレーションIDでAWSにアクセスする環境では、Permission Boundaries はどう機能するのでしょうか。

IAM Identity Center のアクセス許可セット（Permission Set）を使ってロールを作成する際にも、Permission Boundary を付与できます。マルチアカウント環境で統一した委任管理ポリシーを適用する場合は、IAM Identity Center + SCP + Permission Boundaries の3層構造が強固なガバナンス基盤になります。

・SCP: アカウント横断の禁止操作を定義する
・Permission Boundaries: 各エンティティの権限上限を定義する
・アクセス許可セット: 各チーム・役割に与える実際の権限セットを定義する

IAM Identity Center の詳細は、AWS IAM Identity Center入門｜マルチアカウント環境のシングルサインオン設計と運用ガイドを参照してください。

よくあるトラブルと対処法

1. ポリシーを付けているのに操作が拒否される

「アイデンティティベースポリシーでは許可しているが Permission Boundary に含まれていないアクション」を実行しようとすると拒否されます。まず対象エンティティに Permission Boundary が設定されているかを確認し、境界ポリシーの内容に必要なアクションが含まれているか見直してください。

# ロールに設定された Permission Boundary を確認する
aws iam get-role --role-name dev-myapp-lambda-role \
  --query 'Role.PermissionsBoundary'

2. iam:PassRole が拒否される

EC2 や Lambda にIAMロールを渡す際に使う iam:PassRole が境界ポリシーに含まれていないと拒否されます。ECS タスク定義や Lambda 関数作成時に「User is not authorized to pass role」エラーが出た場合は、境界ポリシーに iam:PassRole を追加してください。

3. 境界ポリシーのARNを Condition に書き忘れる

委任管理ポリシーの Condition で iam:PermissionsBoundary を省略すると、開発者が Permission Boundary なしでロールを作成できてしまいます。設定後は AWS IAM Access Analyzer で外部共有リスクや意図しないアクセス設定がないか定期的に確認することを推奨します。

4. 既存ロールに後から Permission Boundary を付ける

稼働中のロールに Permission Boundary を後から付けると、これまで動いていた操作が突然拒否される場合があります。本番環境への適用前に必ずステージング環境で動作確認し、CloudTrail の Deny ログを確認してから切り替えてください。

# 既存ロールに Permission Boundary を付与する
aws iam put-role-permissions-boundary \
  --role-name existing-role-name \
  --permissions-boundary arn:aws:iam::123456789012:policy/dev-team-boundary-policy

# Permission Boundary を削除する（元に戻す場合）
aws iam delete-role-permissions-boundary \
  --role-name existing-role-name

5. ロールの削除ができない

Permission Boundary を設定した状態でロールを削除しようとしてもエラーになる場合、委任管理ポリシーの Resource が正しく設定されているか確認してください。ロールの ARN がポリシーの Resource パターンと一致していないと削除権限が付与されません。

本記事のまとめ

AWS IAM Permission Boundaries の要点を整理します。

Permission Boundaries を使いこなすことで、開発者に自律性を与えながらも、セキュリティ管理者が設定した「上限ライン」を守らせる設計が実現できます。IAMの基礎（最小権限の設計と運用ベストプラクティス）を押さえた上で、チームが増えてきたタイミングで導入を検討してみてください。