Security Command Center エラーの修正

このページでは、SCC エラーを修正するためのリファレンス ガイドと手法の一覧を示します。

準備

検出結果の表示や編集と、Google Cloud リソースへのアクセスや変更を行うには、Identity and Access Management(IAM)の適切なロールが必要です。Google Cloud コンソールで Security Command Center にアクセスする際に権限エラーが発生した場合は、管理者にサポートを依頼してください。ロールの詳細については、アクセス制御をご覧ください。リソースエラーを解決する方法については、影響を受けたプロダクトのドキュメントをご覧ください。

Google Cloud コンソールで検出結果を確認する

SCC エラーは、Security Command Center が想定どおりに機能しない構成エラーです。これらの検出結果は、Security Command Center ソースによって生成されます。

Security Command Center は、組織またはプロジェクトで設定されている限り、エラーを検出するとエラーの検出結果を生成します。SCC エラーは Google Cloud コンソールで確認できます。

Google Cloud コンソールで検出結果を確認するには、次の操作を行います。

Google Cloud Console

  1. Google Cloud コンソールで、Security Command Center の [検出結果] ページに移動します。

    [検出結果] に移動

  2. Google Cloud プロジェクトまたは組織を選択します。
  3. [クイック フィルタ] セクションの [ソースの表示名] サブセクションで、[Security Command Center] を選択します。検出結果クエリの結果は、このソースからの検出結果のみを表示するように更新されます。
  4. 特定の検出結果の詳細を表示するには、[カテゴリ] 列の検出結果の名前をクリックします。検出結果の詳細パネルが開き、[概要] タブが表示されます。
  5. [概要] タブで、検出された内容、影響を受けるリソース、検出結果の修正手順(ある場合)に関する情報など、検出結果の詳細を確認します。
  6. 省略可: 検出結果の完全な JSON 定義を表示するには、[JSON] タブをクリックします。

Security Operations コンソール

  1. Security Operations コンソールで、[検出結果] ページに移動します。
    https://CUSTOMER_SUBDOMAIN.backstory.chronicle.security/posture/findings
    

    CUSTOMER_SUBDOMAIN は、お客様固有の ID に置き換えます。

  2. [集計] セクションで、[ソース表示名] サブセクションをクリックして展開します。
  3. [Security Command Center] を選択します。検出結果クエリの結果は、このソースからの検出結果のみを表示するように更新されます。
  4. 特定の検出結果の詳細を表示するには、[カテゴリ] 列の検出結果の名前をクリックします。検出結果の詳細パネルが開き、[概要] タブが表示されます。
  5. [概要] タブで、検出された内容、影響を受けるリソース、検出結果の修正手順(ある場合)に関する情報など、検出結果の詳細を確認します。
  6. 省略可: 検出結果の完全な JSON 定義を表示するには、[JSON] タブをクリックします。

修正後の SCC エラーの無効化

SCC error の検出結果を修正すると、Security Command Center では、次のスキャン時に検出結果の状態が INACTIVE に自動的に設定されます。Security Command Center が修正された検出結果の状態を INACTIVE に設定するまでの時間は、検出結果を修正するタイミングと、エラーを検出するスキャンのスケジュールによって異なります。

検出結果 SCC error のスキャン頻度については、エラー検出ツールにおける検出結果の概要をご覧ください。

SCC エラーを修正する

このセクションでは、SCC エラーの修正手順を説明します。

API disabled

API のカテゴリ名: API_DISABLED

プロジェクトで次のいずれかのサービスが無効になっています。

無効なサービスは検出結果を生成できません。

この検出結果を修正するには、次の操作を行います。

  1. 検出結果を確認して、無効になっている API を特定します。
  2. API を有効にする:

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

APS no resource value configs match any resources

API のカテゴリ名: APS_NO_RESOURCE_VALUE_CONFIGS_MATCH_ANY_RESOURCES

リソース値の構成は、攻撃パス シミュレーション用に定義されていますが、環境内のリソース インスタンスと一致しません。シミュレーションでは、代わりにデフォルトの高価値リソースセットが使用されます。

リソース値の構成は、Google Cloud コンソールの検出結果の説明で示されている次の理由により、リソースと一致しない場合があります。

  • どのリソース値の構成も、どのリソース インスタンスとも一致しない。
  • NONE を指定する 1 つ以上のリソース値の構成が、他のすべての有効な構成をオーバーライドする。
  • 定義済みのすべてのリソース値の構成で、NONE の値が指定されている。

この検出結果を修正するには、次の操作を行います。

  1. Security Command Center の [設定] で、[攻撃パス シミュレーション] ページに移動します。

    [設定] に移動

  2. 組織を選択します。[攻撃パス シミュレーション] ページが開き、既存の構成が表示されます。

  3. [Resource value configuration] リストの [リソース値] 列で、None の値を確認します。

  4. None を指定した構成の場合は、次の操作を行います。

    1. リソース値の構成の名前をクリックして、構成の仕様を表示します。
    2. 必要に応じて、リソース属性の仕様を編集して、構成に一致するリソース インスタンスの数を減らします。
  5. 問題が過剰に広範な None 仕様に起因するものではない場合は、次の操作を行います。

    1. HIGHMEDIUM、または LOW の値を指定する各構成の名前をクリックして、リソース属性の仕様を表示します。
    2. 構成を確認し、必要に応じて編集して、目的のリソースと一致するようにスコープ、リソースタイプ、タグ、ラベルの仕様を修正します。
  6. 必要に応じて、新しいリソース値の構成を作成します。

変更は、次の攻撃パス シミュレーションに適用されます。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

APS resource value assignment limit exceeded

API のカテゴリ名: APS_RESOURCE_VALUE_ASSIGNMENT_LIMIT_EXCEEDED

最後の攻撃パス シミュレーションで、リソース値の構成で識別される高価値リソースのインスタンス数が、高価値リソースセットに含まれる 1,000 のリソース インスタンスの上限を超えています。その結果、Security Command Center は、高価値リソースセットから余分なインスタンス数を除外しました。

この検出結果を修正するには、次の操作を試します。

  • タグまたはラベルを使用して、特定のリソースタイプまたは指定したスコープ内の一致数を減らします。タグまたはラベルは、リソース値の構成と照合する前に、リソース インスタンスに適用する必要があります。
  • 別の構成で指定されたリソースのサブセットに NONEリソース値を割り当てるリソース値の構成を作成します。

    NONE の値を指定すると、他の構成がオーバーライドされ、高価値リソースセットからリソース インスタンスが除外されます。

  • リソース値の構成で、スコープ リソース属性の仕様を削減します。

  • LOW の値を割り当てるリソース値の構成を削除します。

リソース値の構成を作成、編集、削除する手順については、高価値リソースセットを定義して管理するをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

CIEM service account missing permissions

API のカテゴリ名: CIEM_SERVICE_ACCOUNT_MISSING_PERMISSIONS

CIEM サービスで使用されるサービス アカウントに権限がありません。CIEM が 1 つ以上の検出結果カテゴリを生成できない。

この検出結果を修正するには、CIEM サービス アカウントで必要な IAM ロールを復元します。

  1. Google Cloud コンソールの [IAM] ページに移動します。

    [IAM] に移動

  2. 組織の CIEM サービス アカウントを選択します。サービス アカウントの ID は、次の形式のメールアドレスです。

    service-org-ORGANIZATION_ID@gcp-sa-ciem.iam.gserviceaccount.com
    

    ORGANIZATION_ID は、組織の数値 ID に置き換えます。

    サービス アカウントが表示されない場合は、ページ上部の [アクセス権を付与] をクリックし、サービス アカウントを新しいプリンシパルとして入力します。

  3. サービス アカウントに CIEM サービス エージェント ロール(roles/ciem.serviceAgent)を付与します。カスタムロールを使用する場合は、次の権限が含まれていることを確認してください。

    • cloudasset.assets.exportResource
    • cloudasset.assets.exportIamPolicy
  4. [保存] をクリックします。

CIEM AWS CloudTrail configuration error

API のカテゴリ名: AWS_CLOUDTRAIL_CONFIGURATION_ERROR

CIEM AWS の検出結果の一部またはすべてが Security Command Center に送信されません。構成エラーが原因で AWS CloudTrail フィードが失敗し、データを正常に取得できません。

この検出結果には、次の 3 つの原因が考えられます。

  • AWS CloudTrail フィードが見つからない

    この問題を解決するには、Security Operations コンソールでフィードを作成して構成し、AWS CloudTrail ログを取り込みます。取り込みラベルの Key-Value ペアを CIEMTRUE に設定します。

    フィードの作成手順については、Google SecOps ドキュメントのフィードを作成するをご覧ください。

  • フィードの構成エラー

    フィードが正しく設定されていることを確認します。

    フィードを構成するには、Google SecOps ドキュメントの AWS ログを取り込むように Google Security Operations でフィードを構成するをご覧ください。

  • AWS CloudTrail の構成が不完全である

    この問題を解決するには、AWS CloudTrail 構成で S3 バケットを設定して、予定しているすべての CIEM を使用する AWS アカウントからデータイベント管理イベントの両方をログに記録します。

    CloudTrail を設定するには、Google SecOps のドキュメントの AWS CloudTrail(またはその他のサービス)を構成するをご覧ください。

GKE service account missing permissions

API のカテゴリ名: GKE_SERVICE_ACCOUNT_MISSING_PERMISSIONS

クラスタの GKE のデフォルトのサービス アカウントに権限が不足しているため、Container Threat Detection は Google Kubernetes Engine クラスタの検出結果を生成できません。これにより、クラスタで Container Threat Detection を有効にできません。

この検出結果を修正するには、GKE のデフォルト サービス アカウントを復元し、さらに、サービス アカウントに Kubernetes Engine サービス エージェントroles/container.serviceAgent)ロールがあることを確認してください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

KTD blocked by admission controller

API のカテゴリ名: KTD_BLOCKED_BY_ADMISSION_CONTROLLER

サードパーティのアドミッション コントローラによって必要な Kubernetes DaemonSet オブジェクトのデプロイが妨げられているため、クラスタで Container Threat Detection を有効にできません。

この検出結果を修正するには、クラスタ上で実行されているアドミッション コントローラで、Container Threat Detection に必要な Kubernetes オブジェクトの作成が許可されるようにします。

アドミッション コントローラを確認する

クラスタ内のアドミッション コントローラが Container Threat Detection DaemonSet オブジェクトのデプロイを拒否しているかどうかを確認します。

  1. Google Cloud コンソールの検出結果の詳細に記載された検出結果の説明で、Kubernetes から送信されたエラー メッセージを確認します。Kubernetes のエラー メッセージは次のメッセージのようになります。

    generic::failed_precondition: incompatible admission webhook:
    admission webhook "example.webhook.sh" denied the request:
    [example-constraint] you must provide labels: {"example-required-label"}.
    
  2. クラスタを含むプロジェクトの管理アクティビティ Cloud Audit Logs で、検出結果の詳細の [説明] フィールドに表示されるエラー メッセージを探します。

  3. アドミッション コントローラが機能していても、Container Threat Detection DaemonSet オブジェクトのデプロイを拒否している場合は、Container Threat Detection の サービス エージェントkube-system Namespace のオブジェクトの管理を許可するように、アドミッション コントローラを構成します。

    Container Threat Detection のサービス エージェントは、特定の Kubernetes オブジェクトを管理できるように設定する必要があります。

Container Threat Detection でアドミッション コントローラを使用する方法については、PodSecurityPolicy とアドミッション コントローラをご覧ください。

修正を確認する

エラーを修正すると、Security Command Center は Container Threat Detection を自動的に有効にしようとします。有効化が完了するのを待って、Container Threat Detection が有効かどうかを確認するには、次の操作を行います。

  1. コンソールで Kubernetes Engine の [ワークロード] ページに移動します。

    Kubernetes Engine の [ワークロード] に移動

  2. 必要に応じて、[システム ワークロードを表示] を選択します。

  3. [ワークロード] ページで、最初にクラスタ名でワークロードをフィルタします。

  4. container-watcher ワークロードを探します。container-watcher が存在し、そのステータスが OK の場合、Container Threat Detection は有効です。

KTD image pull failure

API のカテゴリ名: KTD_IMAGE_PULL_FAILURE

必要なコンテナ イメージを gcr.ioContainer Registry イメージホスト)から pull(ダウンロード)できないため、クラスタで Container Threat Detection を有効にできません。

コンテナ イメージの pull またはダウンロードが失敗する場合、複数の理由が考えられます。

以下をご確認ください。

  • VPC ネットワーク、DNS、ファイアウォールの設定で、クラスタから gcr.io イメージホストへのネットワーク アクセスがブロックされていないことを確認します。
  • クラスタが非公開の場合は、限定公開の Google アクセスを有効にして、gcr.io イメージホストへのアクセスを許可していることを確認します。
  • ネットワーク設定と限定公開の Google アクセスが障害の原因でない場合は、GKE のトラブルシューティング ドキュメントの ImagePullBackOffErrImagePull エラーをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

KTD service account missing permissions

API のカテゴリ名: KTD_SERVICE_ACCOUNT_MISSING_PERMISSIONS

Google Cloud コンソールの検出結果の詳細で識別された Container Threat Detection サービス アカウントに、必要な権限がありません。Container Threat Detection の検出結果の一部またはすべてが Security Command Center に送信されません。

この検出結果を修正するには、次の操作を行います。

  1. Container Threat Detection サービス エージェント ロール(roles/containerthreatdetection.serviceAgent)を、サービス アカウントに付与します。詳細については、単一のロールを付与するをご覧ください。

    また、カスタムロールを使用する場合は、そのロールに Container Threat Detection サービス エージェント ロールの権限が付与されていることを確認してください。

  2. サービス アカウントが Container Threat Detection サービス エージェント ロールのいかなる権限も使用できないようにする IAM 拒否ポリシーがないことを確認してください。アクセスをブロックする拒否ポリシーがある場合は、サービス アカウントを、拒否ポリシーの例外プリンシパルとして追加します。

Container Threat Detection サービス アカウントと、必要なロールおよび権限の詳細については、必要な IAM 権限をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Misconfigured Cloud Logging Export

API のカテゴリ名: MISCONFIGURED_CLOUD_LOGGING_EXPORT

Cloud Logging への継続的なエクスポート用に構成されたプロジェクトを使用できません。このため、Security Command Center から Logging に検出結果を送信できません。

この検出結果を修正するには、次のいずれかを行います。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

VPC Service Controls Restriction

API のカテゴリ名: VPC_SC_RESTRICTION

プロジェクトがサービス境界で保護されているため、Security Health Analytics で特定の検出結果を生成できません。サービス境界へのインバウンド アクセス権を Security Command Center サービス アカウントに付与する必要があります。

サービス アカウントの ID は、次の形式のメールアドレスです。

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

次のように置き換えます。

  • RESOURCE_KEYWORD: キーワード org または project(サービス アカウントを所有するリソースによって異なります)
  • RESOURCE_ID: 次のいずれかです。

    • サービス アカウントが組織によって所有されている場合は組織 ID
    • サービス アカウントがプロジェクトによって所有されている場合は プロジェクト番号

組織レベルとプロジェクト レベルの両方にサービス アカウントがある場合は、両方に修正を適用します。

この検出結果を修正するには、次の手順を行います。

手順 1: Security Health Analytics をブロックしているサービス境界を特定する

  1. 検出結果に関連付けられた VPC Service Controls の一意の ID とプロジェクト ID を取得します。

    1. 検出結果の詳細を表示するには、カテゴリ名をクリックします。
    2. [説明] フィールドで、VPC Service Controls の一意の ID をコピーします(例: 5e4GI409D6BTWfOp_6C-uSwmTpOQWcmW82sfZW9VIdRhGO5pXyCJPQ)。
    3. [リソースのパス] フィールドで、プロジェクトの ID をコピーします。
  2. アクセス ポリシー ID とサービス境界の名前を取得します。

    1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

      [ログ エクスプローラ] に移動

    2. ツールバーで、検出結果に関連付けられたプロジェクトを選択します。

      プロジェクト セレクタ

    3. 検索ボックスに、エラーの一意の ID を入力します。

      エラーの UID で検索

      クエリ結果にエラーが表示されない場合は、[ヒストグラム] でタイムラインを開き、クエリを再実行します。

    4. 表示されたエラーをクリックします。

    5. [ネストされたフィールドを展開] をクリックします。

    6. servicePerimeterName フィールドの値をコピーします。値は次の形式になります。

      accessPolicies/ACCESS_POLICY/servicePerimeters/SERVICE_PERIMETER
      

      この例で、accessPolicies/540107806624/servicePerimeters/vpc_sc_misconfigured はサービス境界の完全なリソース名です。

      • ACCESS_POLICY はアクセス ポリシー ID です(例: 540107806624)。
      • SERVICE_PERIMETER はサービス境界の名前です(例: vpc_sc_misconfigured)。

        サービス境界の完全なリソース名

    7. アクセス ポリシー ID に対応する表示名を取得するには、gcloud CLI を使用します。

      組織レベルのクエリを実行できない場合は、管理者にこの操作を行うよう依頼してください。

      gcloud access-context-manager policies list \
          --organization ORGANIZATION_ID
      

      ORGANIZATION_ID は、組織の数値 ID に置き換えます。

      次のような出力が表示されます。

      NAME          ORGANIZATION  SCOPES                 TITLE           ETAG
      540107806624  549441802605                         default policy  2a9a7e30cbc14371
      352948212018  549441802605  projects/393598488212  another_policy  d7b47a9ecebd4659
      

      表示名は、アクセス ポリシー ID に対応するタイトルです。アクセス ポリシーの表示名とサービス境界の名前をメモします。メモしたものは、次のセクションで必要になります。

手順 2: プロジェクトへのアクセスを許可する上り(内向き)ルールを作成する

このセクションでは、VPC Service Controls に対する組織レベルのアクセス権が必要です。組織レベルのアクセス権がない場合は、これらの操作を行うよう管理者に依頼してください。

次の手順では、ステップ 1 で特定したサービス境界に対して上り(内向き)ルールを作成します。

サービス アカウントにサービス境界へのインバウンド アクセスを許可するには、次の手順を行います。

  1. [VPC Service Controls] に移動します。

    [VPC Service Controls] に移動

  2. ツールバーで Google Cloud 組織を選択します。

    プロジェクト セレクタ

  3. プルダウン リストで、アクセスを許可するサービス境界を含むアクセス ポリシーを選択します。

    アクセス ポリシー リスト

    アクセス ポリシーに関連付けられているサービス境界がリストに表示されます。

  4. サービスの名前をクリックします。

  5. [境界を編集] をクリックします。

  6. ナビゲーション メニューで、[上り(内向き)ポリシー] をクリックします。

  7. [ルールの追加] をクリックします。

  8. 次のようにルールを構成します。

    API クライアントの FROM 属性

    1. [ソース] で [すべてのソース] を選択します。
    2. [ID] で、[選択した ID] を選択します。
    3. [ユーザー アカウント / サービス アカウントの追加] フィールドで [選択] をクリックします。
    4. サービス アカウントのメールアドレスを入力します。組織レベルとプロジェクト レベルの両方にサービス アカウントがある場合は、両方を追加します。
    5. [保存] をクリックします。

    GCP サービス / リソースの TO 属性

    1. [プロジェクト] で [すべてのプロジェクト] を選択するか、検出結果で指定されたプロジェクトを選択します。

    2. [サービス] で [すべてのサービス] を選択するか、Security Health Analytics に必要な次の各サービスを選択します。

      • BigQuery API
      • Binary Authorization API
      • Cloud Logging API
      • Cloud Monitoring API
      • Compute Engine API
      • Kubernetes Engine API

    サービス境界で必要なサービスへのアクセスを制限している場合、Security Health Analytics はこのサービスの検出結果を生成できません。

  9. ナビゲーション メニューで、[保存] をクリックします。

詳細については、上り(内向き)ポリシーと下り(外向き)ポリシーの構成をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Security Command Center service account missing permissions

API のカテゴリ名: SCC_SERVICE_ACCOUNT_MISSING_PERMISSIONS

Security Command Center のサービス エージェントに、正常に機能するために必要な権限がありません。

サービス アカウントの ID は、次の形式のメールアドレスです。

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

次のように置き換えます。

  • RESOURCE_KEYWORD: キーワード org または project(サービス アカウントを所有するリソースによって異なります)
  • RESOURCE_ID: 次のいずれかです。

    • サービス アカウントが組織によって所有されている場合は組織 ID
    • サービス アカウントがプロジェクトによって所有されている場合は プロジェクト番号

組織レベルとプロジェクト レベルの両方にサービス アカウントがある場合は、両方に修正を適用します。

この検出結果を修正するには、次の操作を行います。

  1. サービス アカウントにセキュリティ センター サービス エージェント(roles/securitycenter.serviceAgent)のロールを付与します。

    詳細については、単一のロールを付与するをご覧ください。

    また、カスタムロールを使用する場合は、そのロールにセキュリティ センター サービス エージェントのロールの権限が付与されていることを確認してください。

  2. 必要なロールのあらゆる権限をサービス アカウントが使用できないようにする IAM 拒否ポリシーがないことを確認してください。アクセスをブロックする拒否ポリシーがある場合は、サービス アカウントを、拒否ポリシーの例外プリンシパルとして追加します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

次のステップ

Security Command Center のエラーについて確認する。