はじめに
前回の記事で、私は「AWSは別にネット上のADじゃない」と言い切った。
- グループに入れても安全じゃない
- メタデータエンドポイントという抜け道がある
- リソースベースポリシーで全部台無しになる
こういう「罠」にハマらないように、ADの感覚を捨てろって話だった。
でも、実は...
IAM設定を深く掘り下げていくと、「あれ？これってADの〇〇と同じじゃん」という瞬間が何度も訪れる。特にTrust関係と権限委譲の仕組みは、Active Directoryの設計思想と驚くほど似ているんだ。
今回は前回と真逆の視点から、「AWSとADが本質的に似ている3つの例」を見ていく。
なぜ「似ていない」と「似ている」が両立するのか
答えは簡単。
- 表面的な実装 → 全く違う（前回の記事）
- 根底にある設計思想 → 驚くほど似ている（今回の記事）
では具体的にどこが似ているのか？
驚愕の1対1マッピング
| AWS | ↔ | Active Directory | 相似度 |
|---|---|---|---|
AssumeRole |
= | Domain Trust + 外部信頼 | ★★★★★ |
iam:PassRole + Condition |
= | Constrained Delegation | ★★★★★ |
| Resource-based Policy (S3, SQS, etc.) | = | オブジェクトのDACL | ★★★★☆ |
| Identity Policy ∩ Resource Policy | = | ユーザー権限 ∩ オブジェクトACL | ★★★★★ |
| Service Control Policy (SCP) | = | Group Policy (GPO) | ★★★★☆ |
1. AssumeRole = クロスドメインTrust
ADの場合
Active Directoryでは、ドメインAがドメインBを「信頼」することで、ドメインAのユーザーがドメインBのリソースにアクセスできる。
[Domain A] ←Trust→ [Domain B]
UserA@DomainA が DomainBのFileServerにアクセス可能
AWSの場合
AWSでも同じ。アカウントAがアカウントBのロールを「信頼」することで、アカウントAのユーザーがそのロールを引き受けられる。
{ "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::ACCOUNT-B:root"}, "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::ACCOUNT-A:role/CrossAccountRole" }
→ これ、まんま「Account A が Account B を信頼」 だよね？
ADで言う Forest Trust や External Trust のクラウド版。
2. PassRole = Constrained Delegation
{ "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::123:role/LambdaExecRole", "Condition": { "StringEquals": {"iam:PassedToService": "lambda.amazonaws.com"} } }
→ 「Lambdaだけに委譲OK」
ADの Kerberos Constrained Delegation と完全に同じ発想。
3. Resource-based Policy = オブジェクトACL
S3バケットポリシー例
{ "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::456:user/Bob"}, "Action": "s3:*", "Resource": "arn:aws:s3:::my-bucket/*" }
→ リソース側が「誰に権限を与えるか」を決める
ADで言う NTFSのACE（Access Control Entry）そのもの。
IAMで制限してても、バケットポリシーがこうなってたら
{ "Effect": "Allow", "Principal": "*", // ❌ 全世界に公開！ "Action": "s3:GetObject", "Resource": "arn:aws:s3:::corporate-secrets/*" }
これが前回記事で言った「見えない権限」の正体。
何が分かったか
表面は違っても、本質は同じ
- 信頼関係の管理 → どちらも明示的な信頼設定が必要
- 権限の委譲 → サービス間の権限移譲で攻撃リスク
- リソースベースの制御 → オブジェクト単位のACL管理
防御の共通点
前回の記事で挙げた対策は、実はADでも同じことをやってる。
- ログ監視が命
- AD → Security Event Log (4768, 4769, 4776)
- AWS → CloudTrail (AssumeRole, PassRole, PutBucketPolicy)
- MFAは必須（これは前回も言った）
- 両方の環境で、特権アクセスには必ずMFA
- 定期的な権限監査
最後に
「AWSはADじゃない」 → 正しい
「AWSはADに似てる」 → もっと正しい
「ADを知ってるとAWSが理解しやすい」 → 超正しい
補充
AWS vs AD 對比圖
[AD Forest] [AWS Organization] │ │ ├─ Domain Trust ├─ AssumeRole (跨帳戶) ├─ Constrained Delegation ├─ PassRole + Condition ├─ Object DACL ├─ Resource-based Policy ├─ Group Policy ├─ SCP (Service Control Policy)
AD脳を「アップデート」せよ
| AD脳 | → | AWS脳 |
|---|---|---|
| 「グループに入れたら安全」 | → | 「ポリシー＋条件＋境界」で安全 |
| 「ドメイン＝境界」 | → | 「アカウント＝境界」＋Organizations |
| 「GPOで一括制御」 | → | SCP + Tag Policy |
| 「Kerberosチケット」 | → | AssumeRole + Session Policy |
