Q13 — AWS SAA-C03 第17章
第 13/89 問 | ← 第17章
Q1313. ある企業では、AWS Control Tower で管理されるアカウント内に AWS CloudFormation を使用して IAM リソースをデプロイしています。セキュリティチームは、以下のステートメントを含むインラインポリシーを持つ IAM ロールのデプロイを防止したいと考えています:「Effect」: 「Allow」、「Action」: 「*」、「Resource」: 「*」。この要件を満たす解決策はどれですか?
- A. AWS Control Tower の予防的コントロール(proactive controls)を使用して、これらのインラインポリシーステートメントに一致する CloudFormation スタックのデプロイをブロックします。
- B. AWS Control Tower の検出型コントロール(detective controls)を使用して、デプロイ後にこれらのステートメントを含む IAM インラインポリシーを検出し、自動的に削除します。
- C. AWS Config を使用して、インライン IAM ポリシー内のこれらのステートメントを検出するルールを作成します。このルールを、AWS-DeleteIAMInlinePolicy の修復アクションを用いて自動的にこれらのステートメントを削除するように設定します。
- D. AWS Config を使用して、インライン IAM ポリシー内のこれらのステートメントを検出するルールを作成し、検出時にセキュリティチームに通知を送信します。 ✓
正解: D. AWS Config を使用して、インライン IAM ポリシー内のこれらのステートメントを検出するルールを作成し、検出時にセキュリティチームに通知を送信します。
解説
IAM ロールに過剰な許可(「Action」: 「*」および「Resource」: 「*」を含む「Allow」ステートメント)を持つインラインポリシーのデプロイを防止するための最も適切な解決策は、選択肢 D です。AWS Config を使用してこれらのステートメントを検出し、セキュリティチームに通知を送信するという手法です。 選択肢 D が正しい理由: ・AWS Config によるコンプライアンス監視:AWS Config は、カスタムルール(Lambda ベース)または利用可能なマネージドルールを活用して、禁止されたステートメント(「Effect」: 「Allow」、「Action」: 「*」、「Resource」: 「*」)を含む IAM インラインポリシーを検出できます。検出時には Amazon SNS を介してセキュリティチームへアラートを送信し、不正なアクセス発生前の早期対応を可能にします。 ・予防的 vs 検出型コントロール:AWS Control Tower の予防的コントロール(選択肢 A)は、CloudFormation テンプレート内の IAM ポリシーの内容を直接検査してデプロイをブロックすることはできません。Control Tower のガードレール(例:パブリック S3 バケットのブロック)は、IAM ポリシーの細かい内容に基づく制御には対応していません。AWS Control Tower の検出型コントロール(選択肢 B)は、違反を検出後もポリシーを自動削除せず、単にアラートを生成するのみです。AWS Config の自動修復機能(選択肢 C)は、例えば AWS-DeleteIAMInlinePolicy を用いてポリシーを削除できますが、これは反応的であり、必要な権限を誤って失うリスクやサービス障害を引き起こす可能性があります。 ・セキュリティ上のベストプラクティス:まず通知して、その後手動で対応するアプローチが推奨されます。これにより、正当な権限が誤って削除されるのを防ぎ、また AWS Config が保持するコンプライアンスチェックの履歴を活用したフォレンジック分析も可能になります。 他の選択肢が不適切な理由: ・選択肢 A:AWS Control Tower の予防的ガードレール(例:Service Control Policies: SCP)は、アカウント/OU レベルでのアクションブロックは可能ですが、CloudFormation テンプレート内のインライン IAM ポリシーの内容を検査することはできません。たとえば、SCP で iam:CreateRole 全体をブロックすることはできても、「*」権限を持つロールのみを選択的にブロックすることはできません。 ・選択肢 B:AWS Control Tower の検出型コントロール(例:Control Tower と統合された AWS Config ルール)は違反を検出できますが、ポリシーの自動削除は行わず、手動対応または外部自動化(例:Lambda 関数)が必要です。 ・選択肢 C:AWS Config の自動修復機能は、インラインポリシーを削除できますが、本番環境ではリスクが高いです。過剰な許可が意図的に設定されている場合(例:緊急時のブレイクグラス用)もあり、自動削除によってサービス停止を招く可能性があります。 選択肢 D の実装手順: 1. AWS Config ルールの作成:Lambda ベースのカスタム AWS Config ルールを作成し、禁止されたステートメントを含む IAM インラインポリシーをスキャンします。例として、Lambda 関数内でポリシードキュメントを解析し、該当ステートメントを検出したら SNS 通知を送信する処理を実装します。 2. SNS 通知の設定:SNS トピックを作成し、セキュリティチームのメールアドレスまたは Slack チャネルをサブスクライブします。この SNS トピックを、AWS Config ルールの非コンプライアンス通知先として関連付けます。 3. (オプション)AWS Security Hub との統合:AWS Config の検出結果を Security Hub に転送し、セキュリティイベントを一元管理します。 代替案(より予防的なアプローチ):デプロイそのものを完全にブロックしたい場合は、AWS IAM Access Analyzer を CloudFormation フックと組み合わせてテンプレートの事前検証を行う方法や、AWS Service Catalog を用いて承認済みのテンプレートのみをデプロイ可能にする方法もあります。ただし、本問の要件においては、選択肢 D が最もシンプルかつ安全な解決策です。