この記事でわかること

IAMポリシーの最小権限設計で「使いやすさ」と「セキュリティ」を両立する方法
条件キー（Condition）を使った細粒度のアクセス制御パターン
Permission Boundaryを使って開発者に安全にIAM権限を委任する方法
IAM Access Analyzerでポリシーの問題を自動検出する方法

実務での背景

IAMポリシーの設計でよくある失敗パターンがあります。

よくある失敗パターン：

"Action": "*" や "Resource": "*" を安易に使ってしまう
「とりあえずAdministratorAccess」を付けてしまう
開発者にIAMフル権限を与えてしまい、意図しないリソース作成が起きる
手作業でポリシーを作るたびに過剰な権限になる

最小権限の原則は「理想論」ではなく、実際にインシデントを防ぐための実践的な設計です。

解決方法

設計の基本3原則

最小権限（Least Privilege）: 必要最低限のアクションのみ許可
タグベース制御: 自分が作ったリソースだけ操作可能
Permission Boundary: 開発者が作れるIAMロールに上限を設ける

具体的な手順

Step 1: よく使うポリシーパターン集

パターン1: 特定のS3バケットにのみアクセス

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3BucketListAccess",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-app-prod-data"
    },
    {
      "Sid": "S3ObjectAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-app-prod-data/*"
    }
  ]
}

パターン2: 自分が作ったリソースのみ操作可能（タグ制御）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEC2DescribeAll",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowEC2ManageOwnedResources",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Owner": "${aws:username}"
        }
      }
    },
    {
      "Sid": "RequireOwnerTagOnCreate",
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/Owner": "${aws:username}"
        }
      }
    }
  ]
}

⚠️ ${aws:username} は IAMユーザーでのみ展開される変数です。AssumeRoleで操作する運用（推奨構成）では空文字列になり機能しません。ロールで同等の制御をしたい場合は後述の「ハマりポイント」を参照してください。

パターン3: MFA認証済みの場合のみ許可

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyWithoutMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Step 2: Permission Boundary の実装

開発者にIAMロールの作成権限を与えつつ、過剰な権限を付与できないように制限します。

// permission-boundary.json（開発者が作成するロールの上限）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "cloudwatch:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "account:*"
      ],
      "Resource": "*"
    }
  ]
}

// developer-policy.json（開発者に与えるポリシー：Boundary強制部分の抜粋）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:PutRolePolicy",
        "iam:AttachRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT_ID:policy/DeveloperBoundary"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:GetRole",
        "iam:ListRoles",
        "iam:DeleteRole",
        "iam:DetachRolePolicy",
        "iam:DeleteRolePolicy"
      ],
      "Resource": "*"
    }
  ]
}

💡 ポイント：iam:PutRolePolicy / iam:AttachRolePolicy 側にも iam:PermissionsBoundary 条件を付けることで、開発者が「Boundary無しのロールを後から作り替える」抜け道を塞げます。iam:DeleteRole などのライフサイクル系は Boundary 条件を付けると失敗するので別Statementに分けています。

Step 3: IAM Access Analyzer で問題を自動検出

# アナライザーの作成
# ※ --type ORGANIZATION は AWS Organizations の管理アカウント（または委任管理アカウント）でのみ実行可能。
#    単一アカウントで使う場合は --type ACCOUNT に変更してください。
aws accessanalyzer create-analyzer \
  --analyzer-name "my-org-analyzer" \
  --type ORGANIZATION

# 検出結果の確認
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:ap-northeast-1:123456789:analyzer/my-org-analyzer \
  --filter '{"status": {"eq": ["ACTIVE"]}}' \
  --query 'findings[*].[id,resourceType,resource,isPublic]' \
  --output table

# ポリシーの検証（作成前にチェック）
aws accessanalyzer validate-policy \
  --policy-type IDENTITY_POLICY \
  --policy-document file://my-policy.json \
  --query 'findings[*].[findingType,issueCode,learnMoreLink]' \
  --output table

構成図

[組織管理者]
     |
     v
+------------------------+
| SCP (Service Control   |
| Policy)                |
| - 全アカウント共通制限  |
| - root操作の禁止など   |
+------------------------+
     |
     v
[開発者アカウント]
     |
     +---> Permission Boundary（上限制限）
     |         |
     v         v
+------------------------+
| 開発者IAMユーザー/ロール|
| - developer-policy     |
| - PermBoundary強制付与 |
+------------------------+
     |
     v
+------------------------+
| 開発者が作成するロール  |
| - Permission Boundary  |
|   の範囲内に自動制限   |
+------------------------+

[IAM Access Analyzer]
定期スキャン → 外部公開リソース・過剰権限を検出 → SNS通知

ハマりポイント

❌ Denyポリシーの順序を誤解する

IAMポリシーの評価順序は「Explicit Deny > Allow > Default Deny」です。どこかで Deny があれば、どんなに Allow があっても拒否されます。

評価順序:
1. 明示的Deny (Explicit Deny) → 即座に拒否（他のポリシーは無視）
2. 明示的Allow             → 許可
3. 暗黙のDeny (Default Deny) → デフォルト拒否

❌ `aws:username` はIAMロールでは使えない

"${aws:username}" の変数はIAMユーザーにのみ有効です。IAMロール（AssumeRole）では aws:userid を使います。IAMロールの aws:userid は AROAXXXXXXXXXX:session-name の形式になるため、セッション名を規則化（例：ユーザー名をセッション名にする）した上で照合します。

// IAMロール向け（roleセッション名で照合する例）
// ※ AssumeRole時に --role-session-name にユーザー名を指定する運用が前提
"StringLike": {
  "aws:userid": "*:targeted-session-name"
}

❌ `iam:PassRole` を忘れる

EC2インスタンスにIAMロールをアタッチするには、実行者に iam:PassRole が必要です。「EC2の起動権限があるのにロールがアタッチできない」というときはこれが原因です。

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::*:role/ec2-*"
}

まとめ

手法	効果	対象
リソースARN指定	対象リソースを明示的に限定	全ユーザー
タグベース制御	自分のリソースのみ操作可能	開発者
MFA Condition	重要操作にMFA必須化	管理者
Permission Boundary	開発者のIAM権限に上限を設定	組織
Access Analyzer	過剰権限の自動検出	運用チーム

IAMは「とりあえず動けばいい」ではなく、設計の良し悪しがセキュリティインシデントに直結します。Permission Boundary + Access Analyzer の組み合わせが最も効果的な防御策です。