AWS模擬問題集（２）：ランサムウェアから守る！セキュアな構成ベストプラクティスとは？

投稿更新日: 2025/11/21

#セキュリティ

仮想のAWS認定試験を解きつつ、実務に役立つクラウドコンピューティングの知識を身に付けられるという企画です。今回は、連日報道を賑わせているランサムウェアを元に考えてみました。

問題：

KMS 鍵とランサム対策の関係で適切なのは？

A. ルートユーザーのアクセスキーで運用

B. 各ワークロードで独立 CMKを使い分け、最小権限のキーポリシーを適用

C. ひとつの CMK を全用途で共用

D. 自動ローテーションを無効化

正解：B

なぜ B が正解？

爆発半径の最小化： 用途別の CMK（カスタマー管理キー）分離で、侵害時の影響範囲を限定。
鍵“管理”と“使用”の職務分離： キーポリシーと IAM/Grant を使い分け、管理者は使えない、アプリは管理できない状態に。
サービス限定や暗号化コンテキストで意図しない復号を防ぐ（kms:ViaService、kms:EncryptionContext:*）。

1. 脅威モデル：KMS が狙われる典型パス

Disable/Deletion： 侵害者が DisableKey や ScheduleKeyDeletion を実行 → 事業継続不能リスク
ポリシー改ざん： kms:* を持つ主体がキーポリシーを書き換え、秘密裏に Decrypt を許可。
横展開： 共用 CMK 1 本で多システムを暗号化 → 1 キー失陥で全環境停止。

対応の肝：「使える人を絞る」「使う場面を絞る」「消せない／気づける」

2. 実装パターン（サンプル付き）

2-1. 最小権限キーポリシー（サービス限定＋暗号化コンテキスト）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AdminNoUse",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::111122223333:role/SecurityKeyAdmin"},
      "Action": ["kms:DescribeKey","kms:CreateAlias","kms:UpdateAlias","kms:EnableKeyRotation","kms:DisableKeyRotation"],
      "Resource": "*"
    },
    {
      "Sid": "AppUseWithContext",
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::111122223333:role/OrderApiRole"},
      "Action": ["kms:Encrypt","kms:Decrypt","kms:GenerateDataKey*","kms:ReEncrypt*"],
      "Resource": "*",
      "Condition": {
      "StringEquals": {"kms:ViaService": "s3.ap-northeast-1.amazonaws.com"},
      "ForAllValues:StringLike": {"kms:EncryptionContext:AppName": "OrderService"}
      }
    }
  ]
}

ポイント： kms:ViaService で S3 経由に限定、kms:EncryptionContext:* で復号要求にコンテキスト必須。管理者ロールは鍵を使えない（Describe など管理系のみに限定）。

2-2. Grant を活用した“使わせ方”の分離

**アプリや AWS サービスには Grant で Decrypt/Encrypt を付与。取り消しは RevokeGrant。キーポリシーは管理の土台、実利用は Grant/IAM に逃がすと運用が楽。

2-3.削除・無効化ガードレール（EventBridge + SSM で自動巻き戻し）

ScheduleKeyDeletion / DisableKey / キーポリシー変更イベントを EventBridge で捕捉→ SNS 通知＋SSM Automation で CancelKeyDeletion / EnableKey を自動実行、チケット起票。
待機期間は 7〜30日（既定 30 日）。この猶予中に誤操作・不正を検知して巻き戻す。
EventBridge ルール例（CloudTrail パターン）

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
  "eventSource": ["kms.amazonaws.com"],
  "eventName": ["ScheduleKeyDeletion","DisableKey","PutKeyPolicy"]
  }
}

2-4. SCP（Organizations）で削除系 API を網かけ

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyKmsDestructiveOps",
    "Effect": "Deny",
    "Action": [
    "kms:ScheduleKeyDeletion",
    "kms:DisableKey"
  ],
  "Resource": "*",
  "Condition": {
  "StringNotEquals": {"aws:PrincipalArn": "arn:aws:iam::111122223333:role/BreakGlass"}
    }
  }]
}

ポイント： 通常ユーザー・ロールから削除／無効化を一律 Deny。**BreakGlass（二人承認で昇格）**だけ許可。

2-5. クロスアカウント×クロスリージョン

バックアップ先に別アカウントの CMKを用意し、コピー時に再暗号化。
**マルチリージョンキー（mrk-）**を使うと、復旧先リージョンでシームレスに復号できる（用途に応じて採用）。

2-6. XKS（External Key Store）という選択肢

規制要件で「鍵は社外 HSM にのみ保管」が必要なら XKS。ただし性能/可用性要件やプロキシ運用の複雑さを理解して適用。

3. 監視・検知（ダッシュボード項目）

CloudTrail： ScheduleKeyDeletion / DisableKey / PutKeyPolicy を検知し、未承認なら自動打ち消し。
Security Hub： KMS 関連のベンチマーク逸脱（不要な kms:* やローテーション設定など）を集約。
メトリクス： 鍵の状態（Enabled/PendingDeletion）件数、Decrypt 失敗率などを可視化。

4. よくある NG パターン

共用 CMK： 開発/本番/別ドメインのデータを 1 本で暗号化。
kms:* 付与： 管理・使用の境界が消える。
コンテキスト未使用： 誤ったワークロードからも復号できてしまう。
削除イベント無監視： 猶予 30 日を活かせずキー消失。

参考リンク（公式）

最小権限と条件キー（ViaService / EncryptionContext）
キー削除と待機期間、検知・自動対応
マルチリージョンキー（mrk-）
- https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html
XKS（外部キーストア）
- https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html
- https://docs.aws.amazon.com/kms/latest/developerguide/create-xks-keystore.html

AWS模擬問題集（２）：ランサムウェアから守る！セキュアな構成ベストプラクティスとは？

問題：

KMS 鍵とランサム対策の関係で適切なのは？

正解：B

なぜ B が正解？

1. 脅威モデル：KMS が狙われる典型パス

2. 実装パターン（サンプル付き）

2-1. 最小権限キーポリシー（サービス限定＋暗号化コンテキスト）

2-2. Grant を活用した“使わせ方”の分離

2-3.削除・無効化ガードレール（EventBridge + SSM で自動巻き戻し）

2-4. SCP（Organizations）で削除系 API を網かけ

2-5. クロスアカウント×クロスリージョン

2-6. XKS（External Key Store）という選択肢

3. 監視・検知（ダッシュボード項目）

4. よくある NG パターン

参考リンク（公式）

この記事をシェアする

最新記事

タグ