IAMとアイデンティティのセキュリティ

なぜIAMが最優先事項なのか

オンプレミスのセキュリティがネットワーク境界を主戦場にしていたのに対し、クラウドでは「アイデンティティが新しい境界線」になります。ネットワークがどれだけ堅牢でも、過剰な権限を持つIAMロールやサービスプリンシパルが1つでも漏洩すれば、攻撃者はAPI経由でリソースの作成・データの窃取・権限昇格を直接実行できます。

典型的なアイデンティティアーキテクチャ

多くの組織では、外部IdP(Identity Provider)でユーザーを一元管理し、フェデレーションを通じて各クラウドの一時的な権限にマッピングします。長期的なクラウド固有の認証情報を減らすことが設計の核心です。

ポリシー評価の段階が「Security Gate」です。ここで最小権限のポリシー・条件付きアクセス・MFA要求が正しく評価されなければ、後段のリソースは無防備になります。

主要概念とAWS/Azure/GCPの対応

よくある設定ミス

• ワイルドカード権限 High Risk

  "Action": "*", "Resource": "*" のような包括的な許可を持つポリシーが、検証用に作成されたまま本番に残るケース。

• 長期アクセスキーの放置 High Risk

  ローテーションされないIAMユーザーの長期アクセスキーがCIやスクリプトにハードコードされ、漏洩経路になる。

• 未使用ロール・権限の放置 Medium Risk

  一度付与された権限が、用途がなくなった後も棚卸しされず「権限のクリープ」として蓄積する。

• クロスアカウント Trust Policy の過剰許可 High Risk

  Principal を特定のアカウント/条件に絞らず、意図せず他アカウントからのAssumeRoleを許可してしまう。

• 特権アカウントのMFA未設定 High Risk

  管理者権限を持つアカウントにMFAが強制されておらず、パスワード漏洩だけで乗っ取りが成立する。

攻撃シナリオ: 漏洩した長期キーからの権限昇格

攻撃者がGitHubリポジトリに誤ってコミットされたAWSアクセスキーを発見した、という想定です。

1. 盗んだ認証情報が有効かを確認する。
2. そのアイデンティティにアタッチされたポリシーを列挙する。
3. 過剰な権限(例: iam:CreateUser や iam:AttachUserPolicy)を発見する。
4. バックドア用のIAMユーザーを作成し、管理者ポリシーを付与して永続化する。

# 1. 認証情報が有効か確認
$ aws sts get-caller-identity

# 2. アタッチされているポリシーを列挙
$ aws iam list-attached-user-policies --user-name svc-ci-deploy

# 3. 過剰な権限(AdministratorAccess相当)を発見
$ aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --version-id v1

# 4. バックドア用ユーザーを作成し永続化
$ aws iam create-user --user-name backup-admin
$ aws iam attach-user-policy --user-name backup-admin --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
$ aws iam create-access-key --user-name backup-admin

検知

CloudTrail/Entra監査ログ/GCP Audit Logsを継続的に監視し、以下のようなシグナルにアラートを設定します。

• CreateUser / CreateAccessKey / AttachUserPolicy が普段使われないIAMユーザーから短時間で連続して呼び出される。
• 普段利用しないリージョン・IPレンジからのsts:GetCallerIdentityやAPI列挙系コールの急増。
• GuardDutyの UnauthorizedAccess:IAMUser/* や PrivilegeEscalation:IAMUser/* 系ファインディング。

SELECT eventTime, userIdentity.arn, eventName, sourceIPAddress
FROM cloudtrail_lake
WHERE eventName IN ('CreateUser', 'AttachUserPolicy', 'CreateAccessKey')
  AND eventTime > date_sub(now(), 1h)
ORDER BY eventTime DESC;

是正

発見したバックドアユーザーを無効化し、漏洩したキーをローテーションし、根本原因である過剰権限を縮小します。

# バックドアユーザーを無効化・削除
$ aws iam detach-user-policy --user-name backup-admin --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
$ aws iam delete-user --user-name backup-admin

# 漏洩した長期キーを無効化してローテーション
$ aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name svc-ci-deploy
$ aws iam create-access-key --user-name svc-ci-deploy

# Access Analyzerで未使用権限を洗い出し、最小権限ポリシーへ差し替える
$ aws accessanalyzer list-findings --analyzer-arn <analyzer-arn>

実際に手を動かす

このページで扱った「ワイルドカード権限を持つIAMポリシー」の検出と是正を、実際のシナリオ形式で体験できます。Scenario → Architecture → CLI Commands → Misconfiguration → Detection → Remediation → Verification の流れで進めます。

実装チェックリスト

• すべての人間ユーザーがフェデレーション経由でアクセスしており、長期IAMユーザーに依存していない
• ワイルドカード(*:*)を含むポリシーが本番環境に存在しない
• サービス間の認証がハードコードされた長期キーではなく、Roleやマネージドアイデンティティを使っている
• 特権アカウントすべてにMFAが強制されている
• Access Analyzer / Access Reviews / IAM Recommenderを定期的に確認し、未使用権限を棚卸ししている
• クロスアカウントのTrust PolicyにPrincipalとアカウントID/条件の制限がある
• IAM関連の変更(CreateUser, AttachUserPolicy等)がログ監視・アラート対象になっている
• アクセスキーのローテーション期限が設定・運用されている