TL;DR
Security Hub CSPMの是正を進めるときは、まず どのControl IDが失敗していて、どのリソースに対する指摘なのか を切り分けるのが重要です。- コンソールでは
Control ID、Compliance.Status、Resources、AwsAccountId、Regionを見ると整理しやすいです。 AWS CLIではget-findingsを使い、Compliance.SecurityControlIdとResources[].Idを軸に絞ると、対象リソースの洗い出しがしやすくなります。
はじめに
前回の記事では、Security Hub Finding の中に Security Hub CSPM 由来のものがあり、それは Control ID を起点に読むと整理しやすい、という話を書きました。
ただ、実際に是正を進める段階では、そこからさらに一歩進めて
- どのコントロールが
- どのリソースに対して
- どのアカウント / リージョンで
- どう失敗しているのか
を特定しないと、実作業に入れません。
この記事では、Security Hub CSPM の Finding を読むときに、どのコントロールがどのリソースに対して失敗しているかを特定する方法 を整理します。
まず前提: Finding 1件 = コントロール評価結果の1レコードとして見る
AWS 公式では、Security Hub CSPM はコントロールごとにセキュリティチェックを実行し、その結果として Finding を生成・更新すると説明されています。
docs.aws.amazon.comつまり、Security Hub CSPM 由来の Finding は、
- あるコントロールに対する
- あるリソースの
- ある時点での評価結果
として捉えると分かりやすいです。
この見方をしておくと、「Finding をどう読むか」がかなり整理しやすくなります。
最初に見るべき項目
私がまず見るのは以下です。
Compliance.SecurityControlIdTitleCompliance.StatusResourcesAwsAccountIdRegion
この6つが見えると、かなり動けます。
1. どのコントロールが失敗しているかを見る
Security Hub CSPM 由来の Finding では、まず Control ID を見ます。
AWS 公式でも、コントロールは IAM.1 や CodeBuild.3 のような Security control ID を持ち、標準横断で一貫した識別子として使われると説明されています。
docs.aws.amazon.comそのため、まずは
IAM.1S3.8EC2.13
のような Control ID が何かを確認します。
タイトルや説明文は将来変わることがありますが、Control ID は軸として扱いやすいです。
2. 失敗している状態なのかを確認する
次に Compliance.Status を見ます。
Security Hub CSPM 由来の Finding は、コントロール評価結果として Compliance.Status を持ちます。
公式の ASFF 関連ドキュメントでも、control findings の評価結果として扱われる前提です。
docs.aws.amazon.com実務上はまず
FAILEDPASSEDWARNING
のどれかを確認し、基本的には FAILED を中心に見ます。
3. どのリソースに対する指摘かを見る
次に重要なのが Resources です。
Security Hub の Finding は AWS Security Finding Format (ASFF) に正規化されており、その中に対象リソース情報が入ります。
docs.aws.amazon.com実際に見たいのは以下です。
Resources[].TypeResources[].Id
たとえば、
AwsS3BucketAwsEc2SecurityGroupAwsIamPolicy
のようなリソース種別と、
- バケット名
sg-xxxxxxxx- ポリシー ARN
のようなリソース識別子を確認します。
ここが把握できると、どのサービスの何を確認すればよいかが明確になります。
4. どのアカウント / リージョンの話かを見る
複数アカウント・複数リージョン環境では、ここを見落とすとかなり危ないです。
見るポイントは以下です。
AwsAccountIdRegion
AWS 公式でも、Finding には AWS アカウント ID やリージョンが含まれます。
docs.aws.amazon.com同じ Control ID でも、
- 本番アカウントなのか
- 検証アカウントなのか
- 東京リージョンなのか
- 別リージョンなのか
で対応方針が変わることがあります。
コンソールで確認するときの見方
コンソールでは、私は次の順で見ます。
1. Findings 一覧で絞る
まず Findings 一覧で、RecordState や Workflow.Status、必要に応じて Compliance.Status で絞ります。
AWS 公式でも、Findings 一覧は各種フィルタで絞り込めると説明されています。
docs.aws.amazon.com2. Finding 詳細で項目を確認する
詳細画面で、以下を確認します。
Control ID- タイトル
- Severity
- 対象リソース
- アカウント
- リージョン
- Remediation
AWS 公式でも、Finding の詳細画面では履歴、Severity、影響リソースなどを確認できるとされています。
docs.aws.amazon.com3. コントロール詳細へ飛ぶ
そこから該当コントロールの詳細ページや、元のサービス設定へ辿ります。
CLI で確認するときの見方
現場では AWS CLI の方が早いことも多いです。
特に、
- 仮想ブラウザ環境で作業している
- コンソールの一覧が見づらい
- 同じ
Control IDで横展開したい
ときは CLI が便利です。
まずは失敗中の Finding をざっくり取る
aws securityhub get-findings \
--region ap-northeast-1 \
--filters '{
"ComplianceStatus":[{"Value":"FAILED","Comparison":"EQUALS"}],
"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}]
}' \
--query 'Findings[].{
ControlId:Compliance.SecurityControlId,
Title:Title,
ResourceType:Resources[0].Type,
ResourceId:Resources[0].Id,
Account:AwsAccountId,
Region:Region
}' \
--output table
特定の Control ID で絞る
aws securityhub get-findings \
--region ap-northeast-1 \
--filters '{
"ComplianceSecurityControlId":[{"Value":"S3.8","Comparison":"EQUALS"}],
"ComplianceStatus":[{"Value":"FAILED","Comparison":"EQUALS"}],
"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}]
}' \
--query 'Findings[].{
ResourceType:Resources[0].Type,
ResourceId:Resources[0].Id,
Account:AwsAccountId,
Region:Region,
Severity:Severity.Label
}' \
--output table
リソース ID を軸に詳細を見る
aws securityhub get-findings \
--region ap-northeast-1 \
--filters '{
"ResourceId":[{"Value":"arn:aws:s3:::example-bucket","Comparison":"EQUALS"}]
}' \
--query 'Findings[].{
ControlId:Compliance.SecurityControlId,
Title:Title,
Status:Compliance.Status,
Workflow:Workflow.Status
}' \
--output table
AWS CLI の get-findings 出力は ASFF ベースなので、Compliance.SecurityControlId や Resources の構造をそのまま参照できます。
docs.aws.amazon.comconsolidated control findings が ON か OFF かで少し見え方が変わる
ここは少しハマりやすいポイントです。
AWS 公式のコントロールリファレンスでは、
- consolidated control findings が ON の場合
- Finding で security control ID を使う
- OFF の場合
- 一部で標準ごとの control ID 差分が見える
と説明されています。
docs.aws.amazon.comそのため、環境によっては
Compliance.SecurityControlId- 標準依存の Control 表示
の見え方が少し異なることがあります。
実務では、まず consolidated control findings の有無を意識しておくと混乱しにくいです。
実際の切り分け方
私なら、次の順で切り分けます。
1. まず FAILED の Finding を見る
最初から全件見ない方が整理しやすいです。
2. Control ID ごとにまとめる
同じ Control ID が複数件あるなら、まずは横展開可能なパターンかを見ます。
3. Resources[].Type と Resources[].Id を見る
ここで、対象サービスと対象リソースを明確にします。
4. アカウント / リージョンを確認する
本番か検証か、東京か他リージョンかで優先度が変わります。
5. 公式のコントロールページを確認する
最後に、
- なぜ失敗しているか
- どう直すべきか
- 対象外候補があるか
を判断します。
よくある見落とし
1. タイトルだけで判断する
タイトルだけだと、何のリソースに対するものか曖昧なことがあります。
2. 1件直して終わる
実際には同じ Control ID が別リソースにも出ていることが多いです。
3. リージョン違いを見落とす
集約表示だと、どのリージョンの話かを見落としやすいです。
4. Security Hub と Security Hub CSPM の由来を混同する
Finding の発生源が違えば、対処の仕方も変わります。
まとめ
Security Hub CSPM の是正を進めるときは、まず
- どの
Control IDが - どのリソースに対して
- どのアカウント / リージョンで
- どの状態で失敗しているか
を切り分けることが重要です。
そのためには、
- コンソールで
Control ID、Resources、Compliance.Statusを確認する - CLI で
Compliance.SecurityControlIdとResources[].Idを軸に絞る
という見方がかなり有効です。
前回の記事で書いた「どこ由来の Finding なのか」を踏まえた上で、今回はさらに どのコントロールがどのリソースに対して失敗しているか を見る方法を整理しました。
次に実際の是正に入るときは、この切り分け結果をベースに
- 横展開できるもの
- 顧客と合意が必要なもの
- すぐ直せるもの
を分けて進めるとやりやすいと思います。