ルール をクリックします。GuardDuty-Event-IAMUser-InstanceCredentialExfiltration をクリックします。[イベントパターン]を詳しく見てみましょう。特定の検出結果のイベントパターンを条件にトリガーしていることがわかります。
特定の検出結果に対してトリガーされる EventBridge ルールを作成できますが、一元化されたワークフローを実現するために、GuardDuty の全ての検出結果に基づいてトリガーされるルールを作成することもできます。以下は、GuardDuty の全ての検出結果に対してトリガーされるイベントパターンの例です。
{
"detail-type": [
"GuardDuty Finding"
],
"source": [
"aws.guardduty"
]
}事前に設定した Lambda 関数のコードを調べて自動修復の仕組みを確認してください。
Lambda コンソール (us-west-2)に移動して、GuardDuty-Example-Remediation-InstanceCredentialExfiltration を選択してください。
Lambda 関数は、検出結果の情報からロール名を取得し、そのロールのすべてのアクティブなセッションを無効化する IAM ポリシーをアタッチします。
Lambda 関数が修復を実行するために必要な権限は何ですか？このレベルの権限に関連するリスクはありますか？
InstanceCredentialExfiltration の検出結果に対する自動の修復を確認するためには、以前に実行した AWS CLI コマンドの成否で確認できます。
`
aws dynamodb list-tables --profile badbob
`
コマンドが明示的に拒否されていることを示す応答が表示されます。
ロールを表示して、アタッチされたポリシーを評価します。
ロール をクリックします。GuardDuty-Example-EC2-Compromised) をクリックします。RevokeOldSessions ポリシーをクリックします。修復用 Lambda が実行された時点で、過去のセッションが Deny になっていることが確認できます。