【要約】「設定は開放、でも本当に届くの？」をSecurity Hub Network Scanningで5パターン検証してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
クラウド運用者がセキュリティ設定を見直す際、設定値の正しさだけでは実際の通信到達性を確信できない課題がある。設定上の「道」が開いていても、中身が伴っていない場合に誤った判断を下すリスクが存在する。
- ・設定監査では、サービスが未起動でも「到達可能」と誤判定される。
- ・OS側のファイアウォールによる遮断を検知できない。
- ・設定上の経路と、実際の応答の乖離がセキュリティリスクを招く。
// Approach
著者は、設定と現実の乖離を実証するため、5つの異なるネットワーク構成を用いてNetwork Scanningの精度を検証した。
- ・CloudFormationでEC2を5台構築し、遮断条件を変化させた。
- ・コントロールプレーン分析とNetwork Scanningの判定結果を比較した。
- ・CloudShellからcurlを用いて、手動での到達性を検証の基準とした。
// Result
検証を通じて、Network Scanningが設定上の誤検知を排除し、実際の応答に基づいた判定を行うことが確認された。
- ・パターン2や3の誤検知に対し、Network Scanningは正しく「検出なし」とした。
- ・非標準ポートはスキャン対象外となるため、設定監査との併用が必要である。
- ・安定した検出には、自動割り当てIPではなくEIPの使用が推奨される。
Senior Engineer Insight
> 設定監査とアクティブスキャンの併用は、クラウドセキュリティの死角を埋めるために不可欠だ。コントロールプレーン分析は「経路」を、Network Scanningは「応答」を担保する。ただし、スキャン対象ポートの限定やIPの特性による検知漏れのリスクを考慮せねばならない。運用現場では、これらを単体で盲信するのではなく、多層的な検証プロセスとして組み込むべきである。