AWSは別にネット上のADじゃない - IAM設定で気づいた3つの罠

はじめに

「AWSってActive Directoryのクラウド版みたいなもんでしょ?」オンプレのAD管理に慣れた人なら、そう思うかもしれない。実際、IAMにはユーザーもグループもあるし、権限管理の概念も似ている。でも実は全然違う。そしてこの「似てるけど違う」が、セキュリティインシデントの温床になる。

最近いくつかのクラウド侵害事例を調べていて、「ああ、これADの感覚で設定してたらハマるやつだ」と思ったポイントを3つまとめてみる。

1. グループに入れれば安心、じゃない

ADだと

1. セキュリティグループを作る
2. ユーザーを追加する
3. グループに権限を付与する
4. (原則として)完了

もちろんADでも権限昇格の余地はある。GPO編集権限とか、ACLのGenericAll やWriteDaclとか。でもそういうのは「明らかに危険な権限」として認識されてる。

AWSだと

例えばこんなポリシーを持ってるユーザーがいたとする

{
  "Effect": "Allow",
  "Action": "iam:AttachUserPolicy",
  "Resource": "*"
}

一見無害そう。でもこのユーザーは自分自身に AdministratorAccess をアタッチできる。実際にやってみるとこう

# 低権限ユーザーとしてログイン
aws iam attach-user-policy \
  --user-name 自分 \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

つまり

低権限ユーザー
  └─ iam:AttachUserPolicy あり
      └─ 自分にAdminポリシーをアタッチ
          └─ 全リソースにアクセス可能

従来の考え方

iam:CreatePolicy → 危険
iam:AttachUserPolicy → 危険
ec2:RunInstances → 安全（単にEC2起動するだけ）

でも実際は

ec2:RunInstances + iam:PassRole = EC2経由で権限昇格
lambda:CreateFunction + iam:PassRole = Lambda経由で権限昇格
iam:CreatePolicyVersion だけ = Admin化可能

このあたりの組み合わせで権限昇格できる
Rhino Security Labsの調査だと、20種類以上の昇格パターンがあるらしい。

何が違うのか

ADだと「GPO編集権限」みたいな明らかに強い権限が必要。でもIAMは 一見無害な権限の組み合わせ で昇格できてしまうこの「気づきにくさ」が問題。

2. EC2のメタデータエンドポイントという抜け道

ADには「サーバーにログインしたら自動で認証情報が手に入る」みたいな仕組みはない。
でもAWSにはある。それがEC2インスタンスロール。

どういう仕組みか

EC2インスタンスにIAMロールをアタッチすると、そのインスタンス内から自動で認証情報が取得できる。アプリケーションがAWSサービスにアクセスするのに便利。

でもこれが侵害されたインスタンスだったら?

# インスタンス内で実行
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# ロール名が返ってくる
production-s3-access-role

# 認証情報を取得
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/production-s3-access-role

返ってくるJSON

{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2025-11-10T12:00:00Z"
}

169.254.169.254 って何？
- IMDS（Instance Metadata Service） の固定IP
- リンクローカルアドレス（ルーティング不可、インスタンス内限定）
- AWSが提供する HTTP API（ポート80）
- IMDSv1（デフォルト）と IMDSv2（トークン必須）の2バージョン

実例: Capital One侵害事件 (2019)

WebアプリのSSRF脆弱性を発見
メタデータエンドポイントにアクセス
EC2ロールの認証情報を窃取
S3バケットから1億件の個人情報を取得

攻撃者が使ったのはたった1つのSSRF。そこから芋づる式に情報が取れた。なのでIMDSv2を生まれた。 IMDSv2を使うと、認証トークンが必要になる。単純なSSRFでは突破できない。

3. 「見えない権限」が原因のデータ漏洩

IAMでS3へのアクセスを制限

{
  "Effect": "Deny",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::sensitive-data/*"
}

「これでsensitive-dataバケットは守られた」と思う。
でもS3バケットポリシーでこうなってたら

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::sensitive-data/*"
}

結果誰でもアクセス可能、IAMの設定は関係ない。

実際にあった事例

Tesla (2018)

Kubernetes ダッシュボードが無認証で公開
AWSアクセスキーが流出
EC2で仮想通貨マイニングされる

Twitch (2021)

S3バケット設定ミス
ソースコード125GB流出
IAMは適切に設定されていた

どちらも「IAMは大丈夫だった」。問題はリソースレベルの設定。

じゃあどうすればいいのか

１．その前にMFAは絶対
他の対策の前に、これだけは絶対やっておく

# 確認
aws iam get-account-summary | grep "AccountMFAEnabled"

２．AWS Access Analyzerを有効化
これだけで外部からアクセス可能なリソースを自動検出してくれる。

aws accessanalyzer create-analyzer \
  --analyzer-name security-check \
  --type ACCOUNT

３．CloudTrailをちゃんと設定
デフォルトだと90日しか残らない。しかもコンソールからのイベントのみ。

全リージョンで有効化
S3データイベントも記録
ログは別アカウントのS3に転送
S3バケットのMFAデリートを有効化

４．IAMポリシーシミュレーターで検証
「このユーザーは本当にこのアクションができないのか?」を事前確認できる。

もうちょっと本気出すなら

GuardDuty：異常なAPI呼び出しを検知。侵害されたEC2からのC2通信も検知する。
SCPで組織全体に制限：たとえば「Tokyo/Osaka以外のリージョンは使用禁止」。
IAC(Terraform/CloudFormation)で管理：手動設定は必ず事故る。コードで管理してGit履歴に残す。

まとめ

AWSは「インターネット上のAD」じゃない。
違いはこう、特にユーザーやグループ関連。

特徴	Active Directory	AWS IAM
権限昇格	明らかに危険な権限が必要	無害に見える権限の組み合わせで可能
認証情報	パスワード/Kerberos	アクセスキー/トークン/ロール
権限評価	比較的シンプル	複数のポリシータイプが絡む
デフォルト	Domain Usersに基本権限あり	何も権限なし

オンプレの経験は活きる。でもクラウド特有の脅威モデルを理解しないと痛い目を見る。
「設定したつもり」が一番怖い。

Slapdash Safeguards

にわか仕込みのセキュリティ