AWS IAM ポリシー設計で権限の過剰付与を防ぐ実践テクニック

本記事では、AWS IAMポリシー設計の実践的なベストプラクティスを解説します。最小権限の原則（Principle of Least Privilege）に基づいた具体的な設計パターンを学ぶことで、セキュリティリスクを大幅に低減させながら、チーム運用を効率化できます。

なぜIAMポリシー設計が重要なのか

AWS環境のセキュリティリスクの大多数は、IAMの設定ミスに起因しています。開発初期段階で過度な権限を付与すると、その後の権限管理が複雑化し、意図しないデータ漏洩やリソース削除といったインシデントが発生しやすくなります。

多くの企業が陥る罠は「とりあえず動かすため」に AdministratorAccess やワイルドカード（*）を使用してしまうこと。これは非常に危険です。逆に最初から最小権限原則に基づいてポリシーを設計することで、監査対応も容易になり、長期的な保守コストも削減できます。

最小権限の原則（Principle of Least Privilege）の実装

具体例：S3バケットへのアクセスポリシー

過度な権限付与の典型例と、改善されたポリシーを比較してみましょう。

❌ 悪い例：権限が広すぎる

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

このポリシーではS3のすべての操作がすべてのバケットで許可されており、極めて危険です。

✅ 良い例：最小権限に基づいた設計

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketVersioning"
      ],
      "Resource": "arn:aws:s3:::my-application-data"
    },
    {
      "Sid": "ReadOnlyObjectAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::my-application-data/read-only/*"
    },
    {
      "Sid": "WriteSpecificPath",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": "arn:aws:s3:::my-application-data/uploads/user-${aws:username}/*"
    }
  ]
}

このポリシーでは、以下の制限を実装しています：

• 特定のバケットのみ対象：すべてのS3リソースではなく、my-application-dataバケットに限定
• アクション単位での制御：必要な操作（Get、List）のみ許可
• リソースパスの制限：書き込み権限は uploads/user-${aws:username}/* のようにユーザー別ディレクトリに限定
• わかりやすいSid：各ステートメントに説明的なID付けで意図が明確

ロールベースのアクセス制御（Role-Based Access Control）の実装

信頼ポリシーの設計

IAM ロールを作成する際、信頼ポリシー（Trust Policy）も同等に重要です。以下は、特定のAWSアカウントのEC2インスタンスのみがロールを引き受けられるように設計した例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        }
      }
    }
  ]
}

Condition ブロックを使用してアカウントIDを指定することで、想定外のリソースからの権限昇格を防ぎます。

実装時の一般的なハマりポイントと解決策

問題1：ワイルドカードの過度な使用

多くの開発者が "Resource": "*" を使用してしまいますが、これは極めて危険です。

症状：ローカルテストでは動作しても、本番環境でセキュリティスキャンが引っかかる

解決策：ARN（Amazon Resource Name）を明示的に指定します。

// ❌ 避けるべき記述
"Resource": "*"

// ✅ 推奨される記述
"Resource": [
  "arn:aws:s3:::my-bucket",
  "arn:aws:s3:::my-bucket/*"
]

問題2：条件分岐の未使用

同じロールで複数の環境（開発・本番）を運用する場合、Condition を活用してアクセスを制御できます。

症状：開発環境と本番環境で別ロールを管理するのが煩雑

解決策：Condition ブロックを使用して環境ごとのアクセス制御を実装

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProductionDatabaseAccess",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances",
        "rds:DescribeDBClusters"
      ],
      "Resource": "arn:aws:rds:*:123456789012:db/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "10.0.0.0/8",
            "172.16.0.0/12"
          ]
        },
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    }
  ]
}

問題3：リソースベースのポリシーとアイデンティティベースのポリシーの混同

S3バケットポリシーとIAMユーザーポリシーの関係性を理解していないと、権限が反映されないというトラブルが発生します。

症状：IAMユーザーに権限を付与したはずなのに、S3にアクセスできない

解決策：両者の権限は「AND」の関係です。ユーザーポリシーとリソースポリシー両方で許可される場合のみアクセス可能です。以下のように明示的に許可を設定します。

// S3バケットポリシー側での設定例
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificIAMUser",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/alice"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

ポリシーの検証とモニタリング

IAM Access Analyzerの活用

設計したポリシーが想定通りに動作するか検証することは重要です。AWS IAM Access Analyzerを使用して、外部アクセスのリスクを検出できます。

CLIでの検証例：

// IAM ポリシーシミュレーターでアクセス可否を確認
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/alice \
  --action-names s3:GetObject s3:PutObject \
  --resource-arns arn:aws:s3:::my-bucket/uploads/*

このコマンドにより、ユーザー「alice」がそのアクション・リソースに対してアクセス可能かどうかを事前に確認できます。

使うべき場面と使うべきでない場面

✅ 最小権限ポリシー設計を使うべき場面

• 本番環境で複数のスタッフが運用する場合
• 外部ベンダーにAWSアカウントへのアクセスを提供する場合
• CI/CDパイプラインでAWSリソースをデプロイする場合
• セキュリティ監査やコンプライアンス対応が必要な場合

❌ 過度な権限付与で問題が発生する場合

• 開発初期段階で機能検証に時間を費やす
• セキュリティインシデント発生時に対象範囲を特定しにくくなる
• コンプライアンス要件に対応できない
• 従業員の誤った操作による本番障害が拡大しやすい

代替手段との比較

AWS SSO（Single Sign-On）との組み合わせ：大規模な組織では、IAMユーザーの一元管理よりもAWS SSOを使用する方が運用効率が良い場合があります。SSO経由で一時的な認証情報が発行されるため、長期アクセスキーの管理が不要になります。

IAM Identity Center：AWS SSOの後継サービスで、より柔軟なアクセス管理が可能です。複数のAWSアカウント間での権限管理を一元化できます。

よくある質問