securing-aws-iam-permissions

AWS IAM 権限の保護

使用する場面

• IAM ポリシーを適切な範囲に限定する必要がある新しい AWS アカウントやワークロードをオンボーディングするとき
• IAM Access Analyzer が過度に許容的なポリシーや未使用の権限を報告したとき
• 最小権限の証拠が求められるコンプライアンス監査（SOC 2、PCI-DSS）に備えるとき
• 長期間有効なアクセスキーから、有効期間の短いロールベースの認証情報に移行するとき
• IAM の設定ミスに関連する AWS Security Hub の検出結果を修正するとき

次の場合は使用しないでください：Azure AD や Google Cloud IAM の設定、アプリケーションレベルの認可ロジック、フェデレーション ID プロバイダーのセットアップ（managing-cloud-identity-with-okta を参照）。

前提条件

• 管理者アクセス権または IAM:FullAccess 権限を持つ AWS アカウント
• インストール済みで、名前付きプロファイルを設定した AWS CLI v2
• 少なくとも 90 日分の API アクティビティ履歴を記録するように有効化された AWS CloudTrail
• JSON ベースの IAM ポリシー構文と ARN リソース表記に関する知識

ワークフロー

ステップ 1：既存の IAM エンティティとポリシーを棚卸しする

AWS CLI と IAM 認証情報レポートを使用して、すべての IAM ユーザー、ロール、グループ、アタッチ済みポリシーの包括的な一覧を作成します。コンソールアクセスやプログラムによるアクセスキーを持つアカウントと、それらが最後に使用された日時を特定します。

# Generate IAM credential report
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > iam-report.csv

# List all IAM roles and their attached policies
aws iam list-roles --query 'Roles[*].[RoleName,Arn,CreateDate]' --output table

# Find users with access keys older than 90 days
aws iam list-users --query 'Users[*].UserName' --output text | while read user; do
  aws iam list-access-keys --user-name "$user" \
    --query "AccessKeyMetadata[?CreateDate<='$(date -d '-90 days' +%Y-%m-%d)'].[UserName,AccessKeyId,Status,CreateDate]" \
    --output table
done

ステップ 2：IAM Access Analyzer の検出結果を有効化して分析する

組織またはアカウントレベルで IAM Access Analyzer を有効化し、外部と共有されているリソースを特定するとともに、CloudTrail のアクティビティに基づいた最小権限ポリシーの推奨事項を生成します。

# Create an Access Analyzer for the account
aws accessanalyzer create-analyzer \
  --analyzer-name account-analyzer \
  --type ACCOUNT

# List active findings for external access
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/account-analyzer \
  --filter '{"status": {"eq": ["ACTIVE"]}}'

# Generate a policy based on CloudTrail activity for a specific role
aws accessanalyzer start-policy-generation \
  --policy-generation-details '{
    "principalArn": "arn:aws:iam::123456789012:role/AppRole",
    "cloudTrailDetails": {
      "trailArn": "arn:aws:cloudtrail:us-east-1:123456789012:trail/management-trail",
      "startTime": "2025-01-01T00:00:00Z",
      "endTime": "2025-03-01T00:00:00Z"
    }
  }'

ステップ 3：ポリシーを特定のリソースと条件に限定する

ワイルドカードを含むリソース ARN を特定のリソース識別子に置き換えます。MFA の強制、送信元 IP の制限、時間ベースのアクセス許可期間に関する IAM ポリシー条件を追加します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::production-data-bucket",
        "arn:aws:s3:::production-data-bucket/*"
      ],
      "Condition": {
        "Bool": {"aws:MultiFactorAuthPresent": "true"},
        "IpAddress": {"aws:SourceIp": "10.0.0.0/8"},
        "DateGreaterThan": {"aws:CurrentTime": "2025-01-01T00:00:00Z"}
      }
    }
  ]
}

ステップ 4：アクセス許可の境界を実装する

IAM ロールとユーザーにアクセス許可の境界をアタッチし、エンティティが受け取れるアクセス許可の最大範囲を定義します。これにより、管理者が過度に許容的なポリシーをアタッチした場合でも、権限昇格を防止できます。

# Create a permission boundary policy
aws iam create-policy \
  --policy-name DeveloperPermissionBoundary \
  --policy-document file://developer-boundary.json

# Attach the boundary to an IAM role
aws iam put-role-permissions-boundary \
  --role-name DeveloperRole \
  --permissions-boundary "arn:aws:iam::123456789012:policy/DeveloperPermissionBoundary"

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCommonServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*",
        "cloudwatch:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyIAMChanges",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:DeleteUser",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:AttachRolePolicy",
        "iam:PutRolePermissionsBoundary"
      ],
      "Resource": "*"
    }
  ]
}

ステップ 5：MFA を強制し、長期間有効な認証情報をなくす

AWS コンソールと CLI にアクセスするすべての人間ユーザーに MFA を必須とします。ワークロードを IAM ユーザーのアクセスキーから、STS AssumeRole を介して一時的な認証情報を使用する IAM ロールに移行します。

# Enforce MFA via SCP at the organization level
aws organizations create-policy \
  --name RequireMFA \
  --type SERVICE_CONTROL_POLICY \
  --content '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "DenyAllExceptMFA",
        "Effect": "Deny",
        "NotAction": [
          "iam:CreateVirtualMFADevice",
          "iam:EnableMFADevice",
          "iam:ListMFADevices",
          "iam:ResyncMFADevice",
          "sts:GetSessionToken"
        ],
        "Resource": "*",
        "Condition": {
          "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
        }
      }
    ]
  }'

# Deactivate unused access keys
aws iam update-access-key --user-name old-user --access-key-id AKIAEXAMPLE --status Inactive

ステップ 6：継続的な IAM モニタリングを自動化する

AWS Config ルールと Security Hub のコントロールを導入し、IAM のセキュリティ状況を継続的に評価します。EventBridge ルールを設定して、新しいルートアクセスキーの作成やポリシーの変更など、リスクの高い IAM の変更を通知します。

# Enable AWS Config rule for IAM password policy
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "iam-password-policy",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "IAM_PASSWORD_POLICY"
    },
    "InputParameters": "{\"RequireUppercaseCharacters\":\"true\",\"RequireLowercaseCharacters\":\"true\",\"RequireSymbols\":\"true\",\"RequireNumbers\":\"true\",\"MinimumPasswordLength\":\"14\",\"MaxPasswordAge\":\"90\"}"
  }'

# EventBridge rule to detect root account usage
aws events put-rule \
  --name DetectRootUsage \
  --event-pattern '{
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "userIdentity": {"type": ["Root"]}
    }
  }'

主な概念

用語	定義
最小権限	ID がその機能を実行するために必要な最小限のアクセス許可のみを付与すること
アクセス許可の境界	アタッチ済みポリシーにかかわらず、エンティティが持てるアクセス許可の最大範囲を設定する IAM の高度な機能
IAM Access Analyzer	自動推論を使用して外部と共有されているリソースを特定し、CloudTrail のアクティビティから最小権限ポリシーを生成する AWS サービス
サービスコントロールポリシー（SCP）	AWS Organization 内のすべてのアカウントに対してアクセス許可のガードレールを設定する、組織レベルのポリシー
ロールの引き受け	アカウント間またはサービス間のアクセスに使用する、一時的なセキュリティ認証情報を返す STS オペレーション
認証情報レポート	すべての IAM ユーザーと、そのアクセスキー、MFA の状態、最終アクティビティのタイムスタンプを一覧にした、AWS が生成する CSV
ポリシー条件	MFA の要件や IP 範囲など、アクセス許可を適用する条件や方法を制限する IAM ポリシーの制約
ID フェデレーション	IAM ユーザーを作成せずに、外部 ID プロバイダーから一時的な AWS アクセスを許可できるようにすること

ツールとシステム

• AWS IAM Access Analyzer：CloudTrail のアクティビティから最小権限のポリシーを生成し、外部のエンティティと共有されているリソースを特定します
• AWS Config：管理ルールおよびカスタムルールに照らして、IAM 設定のコンプライアンスを継続的に評価します
• AWS Security Hub：Access Analyzer、Config、サードパーティ製ツールからの IAM セキュリティ検出結果を統合し、統一されたダッシュボードに集約します
• IAM Policy Simulator：ポリシー評価ロジックに照らして API 呼び出しをシミュレートし、デプロイ前に IAM ポリシーの効果をテストします
• Prowler：IAM のベストプラクティスや CIS ベンチマークのコントロールを含む 300 件以上のチェックを実行する、オープンソースの AWS セキュリティ評価ツールです

よくあるシナリオ

シナリオ：開発者ロールに AdministratorAccess が過剰に付与されている

コンテキスト：あるスタートアップ企業は、初期開発を迅速に進めるため、すべての開発者ロールに AWS 管理の AdministratorAccess ポリシーをアタッチしていました。セキュリティ監査の結果、開発者が使用しているのは S3、Lambda、DynamoDB のみである一方、15 個のロールにアカウント全体へのアクセス権が付与されていることが判明しました。

アプローチ：

1. IAM Access Analyzer を有効にし、各ロールについて過去 90 日間の CloudTrail データに基づいてポリシーの推奨事項を生成します
2. 各チームがアクセスする特定の S3 バケット、Lambda 関数、DynamoDB テーブルのみを許可する、範囲を限定したポリシーを作成します
3. IAM、Organizations、請求関連のアクションを拒否する権限境界をアタッチします
4. 元のロールを置き換える前に、新しいポリシーを並行するロールにデプロイし、CloudTrail で監視します
5. AdministratorAccess を削除し、すべてのアクセスキーをローテーションします

注意点：並行テスト期間を設けずにポリシーを置き換えると、サービスの中断につながります。Lambda:InvokeFunction の対象を特定の関数 ARN に限定し忘れると、横展開の経路が残ります。

シナリオ：複数のサービスで漏えいしたアクセスキーをローテーションする

コンテキスト：パブリックな GitHub リポジトリでアクセスキーが見つかりました。このキーは、3 つの AWS アカウントにまたがる S3 および EC2 の権限を持つ IAM ユーザーのものです。

アプローチ：

1. aws iam update-access-key --status Inactive を使って、漏えいしたキーを直ちに無効化します
2. 過去 30 日間に漏えいしたキーで実行されたすべての API 呼び出しについて、CloudTrail ログを確認します
3. ユーザー用の新しいアクセスキーを作成し、依存するすべてのサービスと CI/CD パイプラインを更新します
4. すべてのサービスで新しい認証情報が使われていることを確認してから、漏えいしたキーを削除します
5. 今後のキー漏えいを防ぐため、ワークロードを STS の一時認証情報を使用する IAM ロールへ移行します

注意点：キーを無効化する前に削除すると、どのサービスがキーに依存していたかをフォレンジック分析できなくなります。3 つすべてのアカウントで不正なアクティビティを確認しないと、潜在的なバックドアを見逃すおそれがあります。

出力形式

IAM Security Assessment Report
==============================
Account ID: 123456789012
Assessment Date: 2025-02-23
Analyzer: IAM Access Analyzer + Prowler v4.3

CRITICAL FINDINGS:
[C-001] Root account has active access keys
  - Resource: arn:aws:iam::123456789012:root
  - Remediation: Delete root access keys, enable MFA on root
  - CIS Benchmark: 1.4 (Ensure no root account access key exists)

[C-002] IAM user 'deploy-bot' has AdministratorAccess with no MFA
  - Resource: arn:aws:iam::123456789012:user/deploy-bot
  - Last Activity: 2025-02-20
  - Remediation: Replace with IAM role, enforce MFA condition

HIGH FINDINGS:
[H-001] 3 IAM policies use wildcard Resource "*" with sensitive actions
  - Policies: DevPolicy, CIPolicy, LegacyAdminPolicy
  - Remediation: Scope resources to specific ARNs using Access Analyzer

[H-002] 7 access keys older than 90 days detected
  - Users: svc-backup, svc-monitoring, dev-alice, dev-bob, ...
  - Remediation: Rotate keys, migrate to role-based access

SUMMARY:
  Total Findings: 14
  Critical: 2 | High: 4 | Medium: 5 | Low: 3
  Compliance Score: 62% (CIS AWS Foundations Benchmark v3.0)