AWSセキュリティ運用の本当の難所は“検知”ではなく“説明”である（その１）

0. はじめに

Amazon Inspector・Security Hub・WAFログを、監査・主管部門に説明できる判断材料へ変換する

AWSのセキュリティサービスを有効化すると、検知結果は出る。

・Amazon Inspectorは脆弱性を検出する。
・Security Hub CSPMは設定不備をFAILEDとして表示する。
・AWS WAFはリクエストを評価し、BLOCKやCOUNTとして記録する。
・GuardDutyは認証情報侵害や不審なAPI操作の兆候を検知する。

ここまでは、サービスを正しく設定すればある程度実現できる。

しかし、AWSセキュリティ運用で本当に難しいのは、検知そのものではない。難しいのは、検知結果を見たあとに、次の問いへ答えることである。

「これは本当に危険なのか」
「今すぐ対応すべきなのか」
「放置すると何が起きるのか」
「主管部門にどう説明するのか」
「監査ではどう答えるのか」
「通知にどこまで詳細情報を含めてよいのか」

検知結果は、そのままでは説明にならない。

Amazon InspectorのCRITICALは、常に即時対応を意味するわけではない。
Security HubのFAILEDは、常に実害が発生していることを意味するわけではない。
WAFのCOUNTは、常に攻撃を意味するわけではない。
GuardDutyが沈黙しているからといって、設定不備がないことを意味するわけでもない。

必要なのは、検知結果をそのまま眺めることではなく、検知結果を「説明可能な判断材料」に変換することである。

本記事では、Amazon Inspector、Security Hub CSPM、AWS WAFログ、GuardDutyを例に、AWSセキュリティ運用における検知結果を、対応優先度、放置リスク、通知範囲、監査説明へ変換する考え方を整理する。

1. AWSセキュリティサービスは「判断」まではしてくれない

AWSには、セキュリティ運用を支える多くのサービスがある。

代表的なものだけでも、次のようなサービスがある。

これらのサービスは非常に強力である。

ただし、共通しているのは、基本的には「シグナル」を出すサービスだという点である。

• Inspectorは、脆弱性を出す。

• Security Hubは、コントロールのFAILEDを出す。

• WAFは、リクエストの評価結果を出す。

• GuardDutyは、不審なふるまいを出す。

• Configは、設定準拠状況を出す。

しかし、それらの結果を見て、最終的にどう扱うかは利用者側で決める必要がある。

例えば、InspectorでCRITICALの脆弱性が検出されたとする。
そのときに必要なのは、単に「CRITICALです」と報告することではない。

必要なのは、次のような判断である。