同一アカウント・Regionの承認済みEC2 finding種別で、数値severityが8のGuardDutyイベントに対応する。対象EC2はENIが1つで、findingにresource.instanceDetails.instanceIdが含まれている。
承認済みのAPIベースのAutomation runbookで、新規の通常通信を隔離用SGにより制限したい。必要な実行ロール・隔離SG・復旧手順は準備済み。証跡を保持し、既存接続の即時切断は別途確認する。
イベントの選別と対応について適切な構成を2つ選べ。
対象findingを選別してEC2 IDを渡し、既存SGを承認済み隔離SGへ置き換える。証跡と設定を保持し、通信制限の結果を確認する。
詳細解説
InstanceIdにはrunbookが定義する形式でEC2 IDを渡す必要がある。finding全体はその入力ではなく、対象フィールドの抽出と実際のイベントによる検証が必要になる。
SGのconnection trackingにより既存接続が継続する場合がある。設定変更と接続の切断を同一視せず実通信を確認し、即時遮断が必要なら承認された別の制御も設計する。
複数SGの許可ルールは合算される。制限的なSGを追加しても他のSGの許可は打ち消されないため、通常通信を許可する既存SGを残したままでは要件を満たさない。
本問の単一ENIで、通常の通信を許可するSGを残さず隔離SGへ置き換える。結果と新規通信の制限を確認し、元の構成は調査・復旧用に記録する。既存接続の即時切断を保証する操作とは扱わない。
aws.guarddutyとGuardDuty Findingを識別し、対象の種別とseverity=8を選別する。$.detail.resource.instanceDetails.instanceIdから対象IDを取り出し、runbookのInstanceIdへ渡す。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
承認された検証EC2とfindingのサンプルでイベント条件・InstanceId変換・Automation入力と実行履歴を確認し、SG一覧と新規通信、既存接続の挙動を比較する。
参考にした公式資料
確認できる内容
対象EC2とrunbook入力が一致し、既存SGの記録と隔離SGへの置換を確認できる。新規通信と既存接続の結果を分けて記録し、findingを調査用に保持する。
理解のポイント
- GuardDuty finding
- EventBridge
- 隔離runbook
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
findingの対象をrunbook入力へつなぐ
source=aws.guardduty、detail-type=GuardDuty Findingと、承認されたdetail.type・数値detail.severity=8を選別する。Input Transformerで$.detail.resource.instanceDetails.instanceIdをInstanceIdへ渡す。対象アカウント・Region・現在のEC2を検証し、EventBridgeによるAutomation起動権限とAutomationAssumeRoleによるEC2操作権限を分ける。
SGの追加と置換、設定と通信を区別する
複数のSGは許可ルールを合算するため、隔離SGの追加だけでは元の許可を無効にできない。この単一ENIの前提では既存SGを記録して隔離SGへ置換する。ただしconnection trackingされた既存接続が即時に切れる保証はない。新規通信と既存接続を実測し、必要な即時遮断は別の承認済み制御を検討する。複数ENIの実環境では全ENIの関連付けも確認する。
検出を証拠として保持し、繰り返しにも備える
GuardDuty findingは不審な活動の検出であり、単独で侵害の確定や隔離完了を意味しない。対象・finding・元のSG・実行結果を保持して調査する。更新通知や再試行にも備え、同じEC2への対応を冪等にし、実行失敗を監視する。承認済みの調査経路と復旧手順も確認し、通知条件を作っただけで完了としない。