IAMポリシー条件キー完全ガイド — MFA・IP・タグ・リージョン制御

Conditionブロックで何ができるか

IAMポリシーのConditionは「どんな状況でこのポリシーを適用するか」を細かく制御する。IP制限・MFA有無・リージョン・タグ・時間帯など多様な条件を組み合わせることで、最小権限の原則をより精密に実装できる。

条件演算子の種類

文字列系: StringEquals / StringNotEquals / StringLike（ワイルドカード）
数値系:   NumericEquals / NumericLessThan / NumericGreaterThan
日時系:   DateEquals / DateBefore / DateAfter
IPアドレス: IpAddress / NotIpAddress
ARN:      ArnEquals / ArnLike
Boolean:  Bool
Null:     Null（キーが存在するかどうか）

末尾に IfExists を付けると「キーが存在しない場合は条件を無視」
例: StringEqualsIfExists

主要な条件キー

aws:RequestedRegion — リージョン制限

// 東京・大阪以外への操作をすべて拒否（SCP等で使う）
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["ap-northeast-1", "ap-northeast-3"]
    }
  }
}

注意: IAMグローバルサービス（IAM, CloudFront, Route53等）はus-east-1として処理される。リージョン制限SCP適用時はこれらを除外する必要がある。

aws:MultiFactorAuthPresent — MFA強制

// MFA未使用時はEC2停止・削除を禁止
{
  "Effect": "Deny",
  "Action": [
    "ec2:StopInstances",
    "ec2:TerminateInstances"
  ],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

Bool と BoolIfExists の違い：

Bool: キーが存在しない場合はConditionが false 扱い
BoolIfExists: キーが存在しない場合はConditionを無視（Pass through）

aws:SourceIp — IP制限

// 社内IPからのみAWS CLIアクセスを許可
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "NotIpAddress": {
      "aws:SourceIp": [
        "203.0.113.0/24",
        "198.51.100.0/24"
      ]
    }
  }
}

aws:SourceIp vs aws:VpcSourceIp：

aws:SourceIp: クライアントのパブリックIPアドレス
aws:VpcSourceIp: VPC内部からのリクエスト時のプライベートIP（VPCエンドポイント経由等）

aws:ResourceTag / aws:RequestTag — タグによる動的制御

// 自分のチームのEC2インスタンスのみ操作可能（タグ制御）
{
  "Effect": "Allow",
  "Action": [
    "ec2:StartInstances",
    "ec2:StopInstances"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/Team": "${aws:PrincipalTag/Team}"
    }
  }
}

${aws:PrincipalTag/Team} は実行者自身のIAMタグを参照する変数だ。ABACと呼ばれる属性ベースのアクセス制御を実現できる。

aws:CalledVia — サービス連鎖制御

// CloudFormation経由のDynamoDB操作のみ許可
{
  "Effect": "Allow",
  "Action": "dynamodb:*",
  "Resource": "*",
  "Condition": {
    "ForAnyValue:StringEquals": {
      "aws:CalledVia": ["cloudformation.amazonaws.com"]
    }
  }
}

aws:PrincipalOrgID — Organizations全体への制限

// S3バケットへのアクセスを同一Organizationsメンバーのみに限定
{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ],
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalOrgID": "o-xxxxxxxxxxxx"
    }
  }
}

ForAllValues / ForAnyValue 演算子

複数値を返す条件キーに対して使う演算子だ。

// ユーザーがdeveloperまたはadminのグループに属する場合のみ許可
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "*",
  "Condition": {
    "ForAnyValue:StringEquals": {
      "aws:PrincipalOrgPaths": ["o-xxx/r-xxx/ou-xxx/"]
    }
  }
}

試験頻出の条件キー一覧

条件キー	用途
`aws:RequestedRegion`	リージョン制限
`aws:MultiFactorAuthPresent`	MFA必須
`aws:MultiFactorAuthAge`	MFA認証からの経過秒数
`aws:SourceIp`	クライアントIP制限
`aws:VpcSourceIp`	VPC内部IP制限
`aws:PrincipalOrgID`	Organizations内制限
`aws:ResourceTag/*`	リソースタグ条件
`aws:RequestTag/*`	リクエスト時タグ条件
`aws:PrincipalTag/*`	実行者のIAMタグ参照
`aws:CalledVia`	サービス経由制限
`s3:prefix`	S3プレフィックス制限
`iam:PermissionsBoundary`	バウンダリー必須

まとめ

条件キーを活用することで、単純なAllow/Denyを超えた精密なアクセス制御が実現できる。特にABACパターン（タグベース）はアカウント規模が大きくなるほど有効だ。SCS試験では「この状況で最小権限を実現するには？」という問いに対して条件キーが解答のカギになるケースが多い。

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