3.4. 対応の自動化
事前に設定された EventBridge ルール によって、検出結果をメールで受信して、脅威に対する自動修復が実行されました。EventBridge コンソールを調べて、何が設定されれているかを理解し、修復がどのようにトリガーされたかを確認します。
EventBridge ルールの確認
- EventBridge コンソール（us-west-2）に移動します。左側のナビゲーションで、[イベント]セクションの
ルールをクリックします。CloudFormation テンプレートによって作成された 4 つのルールがリストに表示されます。これらは全てプレフィックスが「GuardDuty-Event-」で始まります。
- 事前に設定されたルール名の
GuardDuty-Event-EC2-MaliciousIPCallerをクリックします。
[ターゲット]セクションの下に、Lambda 関数と SNS トピックの2つのエントリが表示されます。EventBridge ルールは、結果を SNS トピックに公開し、SNS トピックは通知メールを送信します。発行されたイベントの JSON 全体を送信するのではなく、入力トランスフォーマー機能を使用して、メールをカスタマイズしています。EventBridgeの入力トランスフォーマー機能を使用すると、ルールで指定されたターゲットに入力される前にイベントから取得されるテキストをカスタマイズできます。詳細をクリックして入力トランスフォーマーの設定を確認して下さい。
修復用 Lambda 関数
Lambda 関数は、この検出結果の自動修復ロジックを処理する関数です。事前に Lambda 関数をセットアップして、侵害されたインスタンスを現在のセキュリティグループから削除し、インスタンスがネットワークから隔離されるように、入出力を拒否するルール をインスタンスに追加します。
[ターゲット]セクションの下の Lambda 関数名 をクリックして、修復ロジックを確認します。
関数の概要タブを折りたたんで下にスクロールすると、この関数のコードが表示されます（コードロジックをウォークスルーすることは、このシナリオの範囲外です）。モニタリングタブをクリックして、この関数の呼び出しの詳細を表示することもできます。
Lambda関数が修復を実行するために必要な権限は何ですか？
修復成功の確認
次に、修復の効果を再確認して、インスタンスが確実に隔離されていることを確認します。この時点で、通知メールから侵害されたインスタンスのインスタンス ID と、Lambda 関数コードの確認からの隔離用のセキュリティグループの名前が得られます。
EC2コンソール（us-west-2）に移動します。
インスタンス(実行中)クリックします。[GuardDuty-Example] で始まる 4 つのインスタンスが表示されます。
GuardDuty の検出結果または通知メールで表示されたインスタンスIDを持つインスタンスをクリックします。インスタンス名は、
GuardDuty-Example: Compromised Instance: Scenario 1です。修復用 Lambda 関数を確認すると、インスタンスに [ForensicSecurityGroup] を含む名前のセキュリティグループを追加することがわかります。
セキュリティタブで、インスタンスにこのセキュリティグループが関連付けられていることを確認します。当初、CloudFormation テンプレートによって起動された4つのインスタンスはすべて、[TargetSecurityGroup] を含む名前のセキュリティグループが関連付けされてました。Lambda 関数は、インスタンスから [TargetSecurityGroup] を削除し、インスタンスを隔離するために [ForensicsSecurityGroup] を追加しました。
ForensicSecurityGroupをクリックして、入力ルールと出力ルールを表示してすべて通信を拒否していることを確認して下さい。
以上で、侵害を受けた EC2 インスタンスを自動で隔離できたことを確認できました。