AWS Security Hubのコントロールで一部のリソースが評価対象から外れる原因と解決方法

平井裕二
2025.02.06
 困っていることAWS Security Hubの「AWS基礎セキュリティのベストプラクティス」における「SSM.1」コントロールは、Amazon EC2インスタンスがAWS Systems Manager（以下、SSM）によって管理されているか（マネージドインスタンスであるか）を評価します。
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/ssm-controls.html#ssm-1
しかし、一部のEC2インスタンスが「SSM.1」コントロールの評価対象から外れており、検出結果に表示されませんでした。
EC2インスタンスが評価されなかった原因を教えて下さい。
 問題の詳細AWSアカウント内のEC2インスタンスの総数は、AWS Resource Explorerでビューを作成することで確認できます。
また、Security Hubの「SSM.1」コントロールでも同様に確認できますが、以下のような状況が発生しました。
Resource Explorerでは、10個のEC2インスタンスが確認されました。
ビューのクエリ条件
resourcetype:ec2:instance


Security Hubの「SSM.1」コントロールでは、9個のインスタンスが評価されました（マネージド8個 + アンマネージド1個）。
検出結果のフィルター条件
リソースタイプ: AwsEc2Instance
レコードの状態: ACTIVE
コンプライアンスセキュリティコントロール ID: SSM.1


このように、両サービスで取得したインスタンスの総数に差異が見られ、「SSM.1」コントロールでは、一部のEC2インスタンスが評価されていませんでした。
Resource Explorerについては以下の記載があり、変更の反映に数分かかるとされていますが、数分待っても結果は変わりませんでした。
インデックスは自動的に更新されます。これらの更新は非同期であるため、変更が反映されるまでに時間が (通常は数分) かかることがあります。

https://aws.amazon.com/jp/blogs/news/introducing-aws-resource-explorer-quickly-find-resources-in-your-aws-account/
 Security Hubの「SSM.1」コントロールの仕組みインスタンスの総数に差異がある原因の前に、Security Hubの「SSM.1」コントロールの仕組みについて説明します。
「SSM.1」コントロールのAWS Config ルールは、以下の条件でEC2インスタンスを評価します。
Configルール名：ec2-instance-managed-by-systems-manager
評価対象リソース: AWS::EC2::Instance
必要なAWS Config記録リソース: AWS::EC2::Instance、AWS::SSM::ManagedInstanceInventory
評価トリガー: 設定変更が発生した場合
https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html
評価結果は以下の2つのタイミングで更新されます。
AWS Configが記録した設定変更時
Security Hubによる定期更新（18時間ごと）
この仕組みにより、EC2インスタンスの設定変更の有無に関わらず、「SSM.1」コントロールの評価結果は継続的に維持・更新されます。

そのため、「SSM.1」コントロールが有効な環境では、基本的にすべてのEC2インスタンスが評価対象となり、評価結果が継続して表示されることが期待されます。
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-standards-schedule.html
 評価されなかった原因Security Hubの「SSM.1」コントロールでEC2インスタンスが評価されなかった原因として、対象インスタンスのコンプライアンスステータスがNOT_AVAILABLEになったことが推測されます。
検出結果のコンプライアンスステータスがNOT_AVAILABLEになった場合、次の処理が実行されます。
レコードの状態がACTIVEからARCHIVEDへ自動的に変更されます。
ARCHIVED状態となってから90日後に、検出結果が自動的に削除されます。
通常、コンプライアンスステータスはPASSEDまたはFAILEDのいずれかの状態となります。
Security Hubのドキュメントによると、NOT_AVAILABLEは以下の要因で発生します
サーバーの障害
リソースの削除
AWS Config の評価結果が適用不可（NOT_APPLICABLE）
NOT_AVAILABLE

サーバーの障害、リソースの削除、または AWS Config の評価結果がNOT_APPLICABLEであるために、チェックを完了できないことを示します。

AWS Config の評価結果がNOT_APPLICABLEであった場合、Security Hub は自動的にその検出結果をアーカイブします。

https://docs.aws.amazon.com/securityhub/latest/userguide/controls-overall-status.html#controls-overall-status-compliance-status
AWS Config の評価結果が適用不可（NOT_APPLICABLE）の定義は以下の通りです。
NOT_APPLICABLE

ルールのロジックを適用できないリソースを除外するために使用されます。例えば、alb-desync-mode-checkルールは Application Load Balancer のみをチェックし、Network Load Balancer と Gateway Load Balancer は無視します。

https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/evaluate-config.html
今回のケースでは、EC2インスタンスは削除されていないため、NOT_AVAILABLEになったと考えられる原因は以下の2点です。
AWS Configの評価結果が適用不可
サーバーの障害
ただし、以下の理由によりNOT_AVAILABLEになった具体的な原因の特定は難しいです。
AWS Configの評価結果が適用不可となるConfigルール（ec2-instance-managed-by-systems-manager）の具体的なケースの記載がAWSドキュメントにない
サーバー障害が発生する条件の詳細な記載がAWSドキュメントにない
Security Hubの検出結果やCloudTrail証跡でも確認不可（後述します）
今回、一部のEC2インスタンスで検出結果が存在しない理由は、以下の流れで削除されたと推測されます。
「SSM.1」コントロールのうち、特定ののEC2インスタンスの検出結果が何かしらの原因でNOT_AVAILABLEになる
検出結果のレコードの状態がACTIVEからARCHIVEDへ自動的に変更される
Security Hubの定期チェック（18時間ごと）の対象外となる
EC2インスタンスに対して設定変更されず、90日経過後に検出結果が自動削除される
NOT_AVAILABLEになった後、EC2インスタンスで何かしらの設定変更をした場合、設定変更が記録されるため、 SSM.1 コントロールが再評価されることが期待されます。

 NOT_AVAILABLEの検出結果例NOT_AVAILABLEの検出結果は90日で自動削除されるため、90日以内にSecurity Hubの検出結果を確認すると、NOT_AVAILABLEの理由が表示されているのか確認してみます。
NOT_AVAILABLEは以下の３つの要因で発生すると説明しました。
サーバーの障害
リソースの削除
AWS Config の評価結果が適用不可（NOT_APPLICABLE）
再現がしやすい、リソースの削除をした場合のSecurity Hubの検出結果は以下となりました。
{
~中略~
  "Compliance": {
    "Status": "NOT_AVAILABLE",
    "StatusReasons": [
      {
        "Description": "This finding has a compliance status of NOT AVAILABLE because AWS Config sent Security Hub a finding with a compliance state of Not Applicable. The potential reasons for a Not Applicable finding from Config are that (1) a resource has been moved out of scope of the Config rule; (2) the Config rule has been deleted; (3) the resource has been deleted; or (4) the logic of the Config rule itself includes scenarios where Not Applicable is returned. The specific reason why Not Applicable is returned is not available in the Config rule evaluation.",
        "ReasonCode": "CONFIG_RETURNS_NOT_APPLICABLE"
      }
    ],
    "SecurityControlId": "SSM.1",
~省略~
このファインディングのコンプライアンス状態は「利用不可（NOT AVAILABLE）」となっています。これは、AWS ConfigがSecurity Hubに「Not Applicable（適用外）」というコンプライアンス状態のファインディングを送信したためです。Configから「Not Applicable」のファインディングが生成される可能性のある理由は以下の通りです：

(1)リソースがConfig ruleの対象範囲外に移動された

(2)Config ruleが削除された

(3)リソースが削除された

(4)Config rule自体のロジックに「Not Applicable」を返すシナリオが含まれている

Config ruleの評価において、「Not Applicable」が返される具体的な理由は利用できません。
検出結果からは、NOT_AVAILABLEになった具体的な理由は確認できませんでした。
そして、評価されていないので、Configルール（ec2-instance-managed-by-systems-manager）にも評価対象外のEC2インスタンスは確認できません。
また、CloudTrail証跡からAWS ConfigのPutEvaluations APIの実行履歴を確認しましたが、以下のように特に理由は記載されていませんでした。
{
  ~中略~
  "eventSource": "config.amazonaws.com",
  "eventName": "PutEvaluations",
  "awsRegion": "ap-northeast-1",
  "sourceIPAddress": "config.amazonaws.com",
  "userAgent": "config.amazonaws.com",
  "requestParameters": {
      "resultToken": "HIDDEN_DUE_TO_SECURITY_REASONS",
      "testMode": false,
      "evaluations": [
          {
              "orderingTimestamp": "Feb 5, 2025 11:31:15 PM",
              "complianceResourceType": "AWS::EC2::Instance",
              "complianceResourceId": "i-04fd08503190ad9bb",
              "complianceType": "NOT_APPLICABLE"
          }
      ]
  },
  "additionalEventData": {
      "configRuleName": "securityhub-ec2-instance-managed-by-ssm-8bff2145",
      "configRuleArn": "arn:aws:config:ap-northeast-1:111111111111:config-rule/aws-service-rule/securityhub.amazonaws.com/config-rule-ynz0ap",
      "notificationJobType": "NOTIFIED",
      "configRuleInputParameters": "{}",
      "managedRuleIdentifier": "EC2_INSTANCE_MANAGED_BY_SSM"
  }
}
AWSドキュメントにはrequestParameters.evaluations.Annotationフィールドに評価判断の補足情報が記録されると記載がありますが、実際の結果ではAnnotation自体が存在しませんでした。
Annotation：評価がどのようにしてコンプライアンスを判断したかに関する補足情報。

https://docs.aws.amazon.com/config/latest/APIReference/API_PutEvaluations.html
 評価対象にする解決方法評価対象外となったインスタンスを再度評価対象とするためには、設定変更による再評価のトリガーが必要です。
次のいずれかの操作を実行することで、設定変更が記録され、再評価が行われる可能性があります。
EC2インスタンスの停止および再起動
インスタンスタグの追加または変更
セキュリティグループの追加または変更
本事例では、インスタンスへのタグ追加により再評価が正常に実行されたことを確認しました。