AWS IAM 最小権限ポリシー設計ガイド｜Condition Key・SCP・Access Analyzer（2026）

IAM最小権限（Least Privilege）とは

最小権限の原則（Principle of Least Privilege） は、各プリンシパルに業務遂行に必要な最小限の権限だけを与え、それ以外は付与しない（または明示的に拒否する）設計です。AWSでは IAMポリシー がその中核ですが、2026年のクラウドセキュリティ監査（CIS AWS Foundations Benchmark、SOC2、PCI-DSS）では次の問いが標準化されています。

• なぜ AdministratorAccess が付いているのか
• s3:* や ec2:* のワイルドカードは本当に必要か
• 開発者ロールが本番データに届く経路はあるか
• 侵害されたワークロードロールから他アカウントへ sts:AssumeRole できないか

最小権限は「一度きりの設計」ではなく、デプロイのたびに権限が膨らむのが常態です。Terraformの policy_attachment コピペ、障害対応時の暫定 * 付与、新サービス追加時のテンプレートポリシー——これらを Access Analyzer + CI検証 + SCPガードレール で継続的に戻す運用が求められます。

最小権限が破綻しやすい典型パターン

パターン	よくある原因	リスク
管理者ロールの常態化	初速優先で AdministratorAccess	侵害＝アカウント全滅
ワイルドカードAction	s3:* で「とりあえず動く」	削除・ポリシー変更まで許可
Resource *	ARNが動的で面倒	他バケット・他テーブルへ到達
ConditionなしのPassRole	Lambda/ECS作成権限のみ付与	高権限ロールへのすり替え
信頼ポリシーの *	クロスアカウント連携の簡略化	任意アカウントからのAssumeRole

IAMポリシーの評価モデル

ポリシーはリクエストごとに次の順で評価されます（簡略化）。

flowchart TD
  A[APIリクエスト] --> B{SCPで明示Deny?}
  B -->|Yes| Z[拒否]
  B -->|No| C{Permission Boundaryで許可?}
  C -->|No| Z
  C -->|Yes| D{Resource Policy / Session Policy}
  D --> E{Identity Policyで許可?}
  E -->|No| Z
  E -->|Yes| F{明示Denyあり?}
  F -->|Yes| Z
  F -->|No| Y[許可]

理解すべきポリシー種別は次のとおりです。

Condition Keyによる文脈制約

Condition Key は、同じ s3:GetObject でも「どの条件下なら許可するか」を述語で絞り込みます。最小権限設計の2026年版では、Action/Resourceに加えて 少なくとも1つはConditionを付ける ことをチームルールにするケースが増えています。

よく使うグローバルCondition Key

Condition Key	用途例
aws:RequestedRegion	東京・大阪以外のAPI呼び出し拒否
aws:SourceIp	オフィスIP・egress固定NATのみ許可（補助的）
aws:SourceVpc / aws:SourceVpce	VPC内・特定VPCエンドポイント経由のみ
aws:PrincipalTag / aws:ResourceTag	環境タグ env=prod 一致時のみ
aws:MultiFactorAuthPresent	本番破壊的操作はMFA必須
aws:PrincipalArn	特定ロールARN以外は拒否（Deny側で有効）
aws:SecureTransport	HTTP（非TLS）拒否

サービス固有のCondition Key（抜粋）

サービス	Key	用途
S3	s3:prefix, s3:ExistingObjectTag	オブジェクトキープレフィックス・タグ制限
KMS	kms:ViaService, kms:EncryptionContext	特定サービス経由の暗号化のみ
IAM	iam:PassedToService	PassRole先サービス制限
STS	sts:ExternalId	クロスアカウントAssumeRoleのなりすまし防止
EC2	ec2:ResourceTag	タグ付きインスタンスのみ停止許可

実装例1：S3アップロード用ロール（Condition付き）

Webアプリがユーザーアップロードを中継するロールの例です。バケット全体ではなくプレフィックスとKMS経由に限定します。Presigned URL設計との整合はS3 Presigned URLのセキュリティ設計を参照してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListUploadPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::my-app-uploads-prod",
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "uploads/${aws:PrincipalTag/tenantId}/*"
          ]
        }
      }
    },
    {
      "Sid": "PutObjectWithKms",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": "arn:aws:s3:::my-app-uploads-prod/uploads/${aws:PrincipalTag/tenantId}/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        },
        "StringLike": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:ap-northeast-1:111122223333:key/abcd1234-5678-90ab-cdef-EXAMPLE11111"
        }
      }
    },
    {
      "Sid": "KmsEncryptViaS3",
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKey",
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:ap-northeast-1:111122223333:key/abcd1234-5678-90ab-cdef-EXAMPLE11111",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "s3.ap-northeast-1.amazonaws.com"
        }
      }
    }
  ]
}

ロールには tenantId タグをセッションごとに付与する（sts:TagSession）か、アプリごとにロールを分ける設計が必要です。プリンシパルタグをポリシー変数 ${aws:PrincipalTag/tenantId} で参照するパターンは、マルチテナントSaaSで2026年に主流になっています。

実装例2：リージョン・VPC固定の読み取り専用ロール

コスト分析・監査用に、東京リージョンのVPC内からのみEC2/RDSをDescribeできるロールです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeInTokyoFromVpc",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeVolumes",
        "ec2:DescribeTags",
        "rds:DescribeDBInstances",
        "rds:ListTagsForResource"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-1",
          "aws:SourceVpc": "vpc-0a1b2c3d4e5f67890"
        },
        "Bool": {
          "aws:SecureTransport": "true"
        }
      }
    },
    {
      "Sid": "DenyOutsideTokyo",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    }
  ]
}

Resource: "*" が残っていても、ActionがDescribe系に限定され、リージョンとVPCで文脈が固定されています。さらに厳しくするなら ec2:ResourceTag/Environment で prod リソースのみに絞ります。

実装例3：信頼ポリシー（ExternalId + MFA）

クロスアカウントで監査ベンダーが読み取りロールをAssumeする信頼ポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowVendorAssumeWithExternalId",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999988887777:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-vendor-external-id-7f3a9c2e"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "IpAddress": {
          "aws:SourceIp": [
            "203.0.113.10/32",
            "203.0.113.11/32"
          ]
        }
      }
    }
  ]
}

sts:ExternalId は confused deputy問題 への定石対策です。ルート arn:aws:iam::ACCOUNT:root をPrincipalにする場合、ベンダー側の具体ロールARNへ絞れるなら絞るべきです。

Permission Boundary：委譲設計の上限

開発者やCIに iam:CreateRole / iam:AttachRolePolicy を渡すと、理論上は任意の高権限ロールを作れます。Permission Boundary で「作れるロールの上限」を決めます。

Boundaryポリシー例（アプリデプロイ担当）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAppRuntimeServices",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "sqs:SendMessage",
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:GetQueueAttributes",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "ssm:GetParameter",
        "ssm:GetParameters"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyIamAndOrgAdmin",
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "account:*",
        "aws-portal:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyUntaggedPassRole",
      "Effect": "Deny",
      "Action": "iam:PassRole",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "iam:PassedToService": [
            "lambda.amazonaws.com",
            "ecs-tasks.amazonaws.com"
          ]
        }
      }
    }
  ]
}

Boundaryを持つユーザーが作成するロールにも同じBoundaryを必須にするには、IAMポリシーで iam:CreateRole に iam:PermissionsBoundary 条件を付けます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreateRoleOnlyWithBoundary",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "arn:aws:iam::111122223333:role/app-*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/AppDeployBoundary"
        }
      }
    },
    {
      "Sid": "AttachLimitedPolicies",
      "Effect": "Allow",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy"
      ],
      "Resource": "arn:aws:iam::111122223333:role/app-*",
      "Condition": {
        "ArnEquals": {
          "iam:PolicyARN": [
            "arn:aws:iam::111122223333:policy/AppRuntimePolicy",
            "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
          ]
        }
      }
    }
  ]
}

Organizations SCP：アカウント横断ガードレール

SCP（Service Control Policy） は管理アカウントからOU単位で適用します。IAMで Allow されていてもSCPで拒否されればAPIは失敗します。ルートユーザーにも効くため、組織の最後の防波堤です。

SCP例：特権操作と危険リージョンの拒否

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUserActions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    },
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "ap-northeast-3",
            "us-east-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/OrganizationAccountAccessRole",
            "arn:aws:iam::*:role/BreakGlassAdmin"
          ]
        }
      }
    },
    {
      "Sid": "DenyWildcardAdminPolicies",
      "Effect": "Deny",
      "Action": [
        "iam:CreatePolicyVersion",
        "iam:SetDefaultPolicyVersion"
      ],
      "Resource": "arn:aws:iam::*:policy/*",
      "Condition": {
        "ForAnyValue:StringLike": {
          "iam:PermissionsBoundary": "*"
        }
      }
    },
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

SCP例：S3パブリックアクセスの組織Deny

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPublicAclAndPolicy",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketAcl",
        "s3:PutBucketPolicy",
        "s3:PutObjectAcl",
        "s3:PutAccountPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "s3:PublicAccess": "true"
        }
      }
    }
  ]
}

IAM Access Analyzer（2026）の活用

IAM Access Analyzer は2026年時点で、次の用途に分割して考えるのが実務的です。

機能	内容
ポリシー検証（validate-policy）	新規・変更ポリシーの構文・ベストプラクティス・セキュリティ警告
未使用アクセス（Unused access）	ロール・ユーザーで90日以上使われていないActionを可視化
外部アクセス（External access）	S3・IAM・KMS等が外部アカウントやインターネットに開いていないか
カスタムポリシーチェック	組織独自ルール（例: Action に * 禁止）をCIで強制
内部アクセス分析	同一アカウント内の過剰到達経路（Preview機能の活用）

CIでの validate-policy 例（GitHub Actions）

name: iam-policy-validate
on:
  pull_request:
    paths:
      - 'infrastructure/iam/**'
jobs:
  validate:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/GitHubActionsIamValidator
          aws-region: ap-northeast-1
      - name: Validate IAM policies
        run: |
          for f in infrastructure/iam/policies/*.json; do
            echo "Validating $f"
            aws accessanalyzer validate-policy \
              --policy-type IDENTITY_POLICY \
              --policy-file "file://$f" \
              --locale JA \
              --output json > "validation-$(basename "$f").json"
            if jq -e '.findings[] | select(.findingType=="ERROR")' "validation-$(basename "$f").json" >/dev/null; then
              echo "Policy validation failed: $f"
              exit 1
            fi
          done

LOCALE JA を指定すると finding メッセージが日本語化され、レビュアーの負荷が下がります。ERRORでCIを落とし、SECURITY_WARNINGは週次で消化する運用が一般的です。

カスタムポリシーチェックの考え方

組織でよく使うルール例です。

• Action にサービスワイルドカード s3:* を含めない
• Resource: "*" と Effect: Allow の組み合わせは iam:PassRole 等の例外リストのみ
• 本番OUのポリシーに iam:CreateUser を含めない
• KMSキーポリシーに Principal: "*" を含めない

AWSマネージドのチェックに加え、組織のTerraformモジュールが出力するJSONを対象にすることで、インフラ変更と権限変更の同期が取れます。

PassRole・AssumeRoleチェーンの監査

最小権限で最も見落とされるのが 権限の委譲チェーン です。

flowchart LR
  Dev[開発者ロール] -->|iam:PassRole| Lambda[Lambda実行ロール]
  Lambda -->|sts:AssumeRole| Data[高権限データアクセスロール]
  Data --> S3[(本番S3)]

開発者ロールに iam:PassRole と lambda:CreateFunction があるとき、PassRole先を高権限ロールにすれば間接的に侵害できます。対策は次の三点セットです。

1. iam:PassedToService で Lambda / ECS に限定
2. PassRole可能なロールARNを arn:aws:iam::111122223333:role/app-* に限定
3. 高権限ロールの信頼ポリシーで lambda.amazonaws.com のみ許可し、開発者ロールからの直接AssumeRoleを拒否

EC2/ECS上のアプリがAWS APIを呼ぶ場合、インスタンスプロファイル・タスクロールの権限がそのまま侵害面になります。コンテナ間通信はmTLSでサービス主体を固定し、クラウドAPI権限はタスクロールに閉じ込めます。

ABAC：タグベースアクセス制御

ABAC（Attribute-Based Access Control） は、IAMプリンシパルとリソースのタグを aws:PrincipalTag / aws:ResourceTag で照合する方式です。ロール乱立を減らし、テナント数増加にスケールします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TenantScopedDynamoRead",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query",
        "dynamodb:BatchGetItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:ap-northeast-1:111122223333:table/AppData",
        "arn:aws:dynamodb:ap-northeast-1:111122223333:table/AppData/index/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/tenantId": "${aws:PrincipalTag/tenantId}",
          "aws:PrincipalTag/env": "prod"
        },
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": [
            "${aws:PrincipalTag/tenantId}"
          ]
        }
      }
    }
  ]
}

ABAC導入時は タグ改ざん権限（ec2:CreateTags, dynamodb:TagResource 等）を別ロールに分離し、タグ付与はデプロイパイプラインのみが実行するのが安全です。

セッションポリシーと一時クレデンシャル

sts:AssumeRole 時に Session Policy を渡すと、そのセッションだけ権限をさらに絞れます。サポートデスクが顧客バケットを1件だけ閲覧する場合などに有効です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OneBucketReadonlySession",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::customer-abc-backup",
        "arn:aws:s3:::customer-abc-backup/reports/2026-06/*"
      ]
    }
  ]
}

セッションポリシーはロールのIdentity Policyと積集合になります。ロール側が広くてもセッションで縮小できますが、ロール側が狭いActionはセッションで拡大できません。

Break Glassと最小権限の両立

完全最小権限のみだと、Organizations障害やKMSキー誤削除時に復旧できないことがあります。Break Glass ロールを用意し、次で厳格化します。

• 通常は無効（信頼ポリシーにダミーPrincipal、またはSCPで明示Deny）
• インシデント時のみSCP例外手順で有効化
• aws:MultiFactorAuthPresent + 専用ハードウェアMFA
• CloudTrail + SNS + SlackでAssumeRoleを即時通知
• セッション時間 DurationSeconds を900秒以下に制限

最小権限と矛盾しないよう、「普段使わない・使ったら必ず検知される」設計にします。

ロール設計の命名・ライフサイクル

慣習	例	理由
環境プレフィックス	prod-app-api, stg-app-api	SCP・Analyzerフィルタが容易
用途サフィックス	-readonly, -deploy, -breakglass	意図がポリシー名から読める
最大セッション	1h（人間）/ 1h〜12h（CI）	侵害時のクレデンシャル寿命
定期レビュー	四半期ごとにLast Accessed	未使用Action削除

人間ユーザーへの長期アクセスキー発行は2026年のベストプラクティスから外れています。IAM Identity Center（SSO）+ 短期ロール が標準です。

Terraform/CDKでのポリシー管理

Infrastructure as Codeでは次を徹底します。

• ポリシーJSONは infrastructure/iam/policies/ にフラット配置し、PR diffでレビュー可能にする
• aws_iam_policy の policy に heredoc 直書きせずファイル参照
• terraform plan 前に validate-policy を pre-commit / CI で実行
• AdministratorAccess アタッチを checkov / tfsec / OPAで禁止

resource "aws_iam_role" "app_api" {
  name = "prod-app-api"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Service = "ecs-tasks.amazonaws.com"
      }
      Action = "sts:AssumeRole"
      Condition = {
        StringEquals = {
          "aws:SourceAccount" = "111122223333"
        }
        ArnLike = {
          "aws:SourceArn" = "arn:aws:ecs:ap-northeast-1:111122223333:task/*"
        }
      }
    }]
  })
  permissions_boundary = aws_iam_policy.app_deploy_boundary.arn
}

導入手順（実務チェックリスト）

よくある失敗と対策

監査・コンプライアンスとの対応

フレームワーク	IAM最小権限で聞かれること
CIS AWS 1.16〜1.22	ルートアクセスキー無効、MFA、フルアクセスポリシー回避
SOC2 CC6	論理アクセス・権限レビューの証跡
PCI-DSS 7	必要最小限のシステムコンポーネントアクセス
ISO 27001 A.9	アクセス権の付与・レビュー・削除

CloudTrailの AssumeRole / CreatePolicyVersion / AttachUserPolicy を SIEM に送り、Access Analyzerのfindingと突き合わせると、監査証跡として説明しやすくなります。

2026年のトレンドまとめ

1. validate-policyのCI標準化 — ERRORはマージブロック、WARNINGはバックログ管理
2. Unused accessによる継続的右サイジング — 四半期の「権限棚卸し」から常時運用へ
3. ABAC + プリンシパルタグ — マルチテナントSaaSのロール数爆発を抑制
4. SCP + Boundaryの二層キャップ — 委譲型プラットフォーム（社内PaaS）で必須
5. ゼロトラストとの役割分担 — クラウドAPIはIAM、サービス間はmTLS、オブジェクト配布はPresigned URL設計

関連記事

この記事は セキュリティ テーマの一環です。あわせて読むと理解が深まる関連記事をまとめました。

トピック	記事
XSS攻撃と防御の完全ガイド	XSS攻撃と防御の完全ガイド｜反射型・蓄積型・DOM型の対策
CSRF対策の実装ガイド	CSRF対策の実装ガイド｜SameSite・Synchronizer Token・Laravel/Expressコード
Double Submit Cookie完全実装	Double Submit Cookie完全実装｜Synchronizer Token比較・SPA+JWT・サブドメイン攻撃
Content Security Policy (CSP) 設定ガイド	Content Security Policy (CSP) 設定ガイド｜XSS・クリックジャッキング対策
CSP Report-Only 段階導入ガイド	CSP Report-Only 段階導入ガイド｜本番を壊さずポリシーを検証する
セキュリティヘッダー一覧と設定ガイド	セキュリティヘッダー一覧と設定ガイド｜CSP・HSTS・Referrer-Policy・Permissions-Policy
セキュアなCookie設定ガイド	セキュアなCookie設定ガイド｜HttpOnly・Secure・SameSiteの使い分けとCSRF対策
CORSエラーの対処法	CORSエラーの対処法｜「Access-Control-Allow-Origin」で解決する
CORSプリフライトリクエスト	CORSプリフライトリクエスト｜OPTIONSが飛ぶ条件と正しい応答
ローカル開発でCORSエラーが出る原因と3つの回避策	ローカル開発でCORSエラーが出る原因と3つの回避策
OAuth2 PKCE SPA実装ガイド	OAuth2 PKCE SPA実装ガイド｜Authorization Code + S256 + BFFパターン
Passkeys・WebAuthn実装の基礎	Passkeys・WebAuthn実装の基礎｜FIDO2・Resident Key・@simplewebauthn/server

まとめ

AWS IAMの最小権限は、狭いAllowポリシーを一度書いて終わりではありません。Condition Keyで文脈を固定し、Permission BoundaryとSCPで上限を決め、Access Analyzerで外部共有・未使用権限・ポリシー品質を継続監視する——この四層が2026年の実務セットです。侵害は「いつ起きるか」ではなく「起きたときにどこまで届くか」の問題なので、PassRoleチェーン・セッションポリシー・Break Glass手順まで含めた到達経路分析をセットで行ってください。