Security Hub CSPM コントロールが UNKNOWN になる原因パターンを調べてみた
はじめに
AWS Security Hub CSPMを運用していると、コントロールのステータスが「Passed」以外になるケースに遭遇します。
Failed であれば「設定を直せばよい」と分かりますが、Unknown は「何が起きているのか分からない」状態です。本記事では単一アカウント環境を前提に、Unknown が発生する原因パターンと具体的な対処法を整理します。
コントロールステータス「Unknown」とは
Security Hub のコントロールステータスは、配下の Finding の Compliance.Status から導出されます。
| コントロールステータス | 条件 |
|---|---|
| Passed | すべての Finding が PASSED |
| Failed | 1つ以上の Finding が FAILED |
| Unknown | Finding が WARNING または NOT_AVAILABLE を含み、かつ FAILED が1つもない |
| No data | Finding が存在しない（コントロール有効化直後、全 Finding が SUPPRESSED、リージョン非対応） |
Unknown の元になる Finding レベルの値は以下の2つです。
| Compliance.Status | 意味 |
|---|---|
WARNING |
PASSED / FAILED を判定できない（例: AWS Config のリソース記録が無効） |
NOT_AVAILABLE |
チェックを完了できない（サーバー障害、リソース削除、Config 評価結果が NOT_APPLICABLE） |
つまり Unknown は「問題がある」のではなく「評価自体が完了できなかった」状態を示しています。
Unknown が発生する例と対処法
AWS Config でリソースタイプが記録対象外
Security Hub のコントロールの多くは、AWS Config のルールを使用してリソースを評価します。対象リソースタイプが Config の記録対象に含まれていない場合、評価が実行できず WARNING となります。
マネジメントコンソールでは、下記のスクリーンショットのようになります。
RDS.1 RDS snapshot should be private の場合
筆者の検証環境では AWS Config の記録戦略を「特定のリソースタイプを記録する」に指定しており、AWS::RDS::DBSnapshot,AWS::RDS::DBClusterSnapshot を記録対象としていないことから、WARNING となっています。
対処法:
- AWSドキュメント（Required AWS Config resources for control findings） を参照し、対象コントロールに必要なリソースタイプを確認する
もちろん、前述のスクリーンショットのようにコンソールから確認しても問題ありません。
- Config の記録対象にリソースタイプを追加する
put-configuration-recorder の recording-group は完全上書きです。既存の記録対象リソースタイプに追加する場合は、現在の設定を取得した上で、追加したいリソースタイプを含めた全量を指定してください。
# 現在の記録対象を確認
aws configservice describe-configuration-recorders \
--query 'ConfigurationRecorders[].recordingGroup.resourceTypes'
# 既存のリソースタイプ一覧に追加して指定（上書きされるため全量を指定する）
aws configservice put-configuration-recorder \
--configuration-recorder name=default,roleARN=arn:aws:iam::123456789012:role/config-role \
--recording-group '{
"allSupported": false,
"includeGlobalResourceTypes": false,
"resourceTypes": [
"（既存のリソースタイプ一覧）",
"AWS::RDS::DBSnapshot",
"AWS::RDS::DBClusterSnapshot"
]
}'
補足:
allSupported=trueに設定している場合は、サポートされるすべてのリソースタイプが記録されるため、このパターンには該当しません。特定のリソースタイプのみを記録する設定にしている場合には注意が必要です。
補足: グローバルリソースの場合: CloudFront などのグローバルリソースを評価するコントロールは、us-east-1 の Config で対象リソースタイプを記録する必要があります。確認先のリージョンが異なるだけで、原因と対処法は同じです。
Unknown になりそうでならないケース
以下のケースは一見 Unknown になりそうですが、検証の結果コントロールステータスは Unknown にならないことが確認できました。
ケース1: 対象リソースを削除した場合
公式ドキュメントには以下の記述があります。
コントロールに対応するリソースがあっても、そのリソースを削除すると、Security Hub CSPM は NOT_AVAILABLE 検出結果を作成し、すぐにアーカイブします。18 時間後、コントロールに対応するリソースがなくなったため、PASSED 検出結果が表示されます。
検証内容
ACM 証明書を作成し、リソースレベルの Finding が生成された状態で証明書を削除しました。
# 証明書を作成
aws acm request-certificate \
--domain-name test-unknown.example.com \
--validation-method DNS \
--region ap-northeast-1
# リソースレベルの Finding 生成を確認後、証明書を削除
aws acm delete-certificate \
--certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/XXXXXXXX \
--region ap-northeast-1
# 削除後に Finding を確認（Config 再評価は手動トリガーしない）
aws securityhub get-findings \
--filters '{"Title":[{"Value":"ACM.1","Comparison":"PREFIX"}]}' \
--query 'Findings[].{Resource:Resources[0].Id,Status:Compliance.Status,RecordState:RecordState,Workflow:Workflow.Status}' \
--region ap-northeast-1
結果:
[
{
"Resource": "arn:aws:acm:ap-northeast-1:123456789012:certificate/XXXXXXXX",
"Status": "NOT_AVAILABLE",
"RecordState": "ARCHIVED",
"Workflow": "SUPPRESSED"
},
{
"Resource": "AWS::::Account:123456789012",
"Status": "PASSED",
"RecordState": "ACTIVE",
"Workflow": "RESOLVED"
}
]
なぜ Unknown にならないか
NOT_AVAILABLEの Finding は生成されるが、即座にRecordState: ARCHIVEDとなる- コントロールステータスの計算対象は
RecordState: ACTIVEかつWorkflow.StatusがSUPPRESSED以外の Finding のみ - 結果として ACTIVE に残るのはアカウントレベルの
PASSEDだけとなり、コントロールステータスは Passed のまま
注意: 削除後に手動で Config ルールの再評価をトリガーすると、Config が既に存在しないリソースを評価しようとして
FAILEDを返すケースがあります。実際の検証では以下の Finding が生成されました。{ "Compliance": {"Status": "FAILED"}, "ProductFields": { "aws/securityhub/annotation": "Certificate data could not be retrieved" } }
ケース2: Config ロールの権限が不足している場合
Config レコーダーのロールを、権限を一切持たないカスタムロール config-insufficient-permissions に切り替えて検証しました。
# Config レコーダーのロールを権限不足ロールに切り替え
aws configservice put-configuration-recorder \
--configuration-recorder name=default,roleARN=arn:aws:iam::123456789012:role/config-insufficient-permissions \
--region ap-northeast-1
# Config ルールの再評価をトリガー
aws configservice start-config-rules-evaluation \
--config-rule-names securityhub-s3-bucket-blacklisted-actions-prohibited-XXXXXXXX \
--region ap-northeast-1
Config ルールの評価状況:
[{
"LastError": "Unable to perform config:PutEvaluations due to the lack of permissions on the role."
}]
Security Hub の Finding は以前の状態（PASSED）のまま変化はありませんでした。
なぜ Unknown にならないか
Config が PutEvaluations に失敗した場合、新しい評価結果を Security Hub に送信できない。Finding は更新されず、コントロールステータスにも変化はありません。
補足: Security Hub のサービスリンクロール（
AWSServiceRoleForSecurityHub）は Security Hub が有効な間は削除できない仕様であるため、正常に運用されている環境で権限不足が発生する可能性は低いと考えられます。
Unknown 解消後の確認方法
Config の記録対象にリソースタイプを追加した後、Config ルールの再評価をトリガーすることでステータスの反映を早められます。
# 対象コントロールに対応する Config ルール名を確認
aws configservice describe-config-rules \
--query 'ConfigRules[?starts_with(ConfigRuleName, `securityhub-`)].ConfigRuleName'
# 再評価をトリガー
aws configservice start-config-rules-evaluation \
--config-rule-names "<ルール名>"
再評価後、Security Hub の Finding は数分以内に更新されます。ただしコントロールステータスの更新は最大24時間かかります（24時間ごとの定期更新のため）。
まとめ
| ケース | コントロールステータスが Unknown になるか |
|---|---|
| Config の記録対象にリソースタイプが含まれていない | なる |
| 対象リソースを削除した | ならない（NOT_AVAILABLE は即アーカイブ → Passed に遷移） |
| Config ロールの権限が不足している | ならない（Finding が更新されないだけ） |
Unknown が発生した場合、まず確認すべきは AWS Config の記録対象リソースタイプの設定です。グローバルリソースの場合は us-east-1 の Config 設定を確認してください。
参考リンク
- コンプライアンスステータスとコントロールステータスの評価 - AWS Security Hub
- Required AWS Config resources for control findings - AWS Security Hub
- Setting the workflow status of findings - AWS Security Hub
