このページでは、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 コンソールで、Security Command Center の [検出結果] ページに移動します。
Google Cloud プロジェクトまたは組織を選択します。
[クイック フィルタ] セクションの [ソースの表示名] サブセクションで、[Security Command Center] を選択します。
特定の検出の詳細を表示するには、[
Category
] の下にある検出結果の名前をクリックします。検出結果の詳細ペインが開き、次の情報が表示されます。- AI 生成の概要プレビュー: 検出された問題に対して動的に生成された説明
- 説明: 検出されたエラーの簡単な説明。
- イベントの日時: 検出が発生した日時
- リソースの表示名: 影響を受けるリソース
- 次のステップ: エラーの解決手順
- 検出結果の正規名: 検出結果の一意の識別子
- ソースの表示名:
Security Command Center
省略可: 検出結果の完全な JSON 定義を表示するには、[JSON] タブをクリックします。
このペインには、検出結果の JSON 定義が表示され、すべての検出結果の属性を調べることができます。
修正後の SCC エラーの無効化
SCC error
の検出結果を修正すると、Security Command Center では、次のスキャン時に検出結果の状態が INACTIVE
に自動的に設定されます。Security Command Center が修正された検出結果の状態を INACTIVE
に設定するまでの時間は、検出結果を修正するタイミングと、エラーを検出するスキャンのスケジュールによって異なります。
検出結果 SCC error
のスキャン頻度については、エラー検出ツールにおける検出結果の概要をご覧ください。
SCC エラーを修正する
このセクションでは、SCC エラーの修正手順を説明します。
API disabled
API のカテゴリ名: API_DISABLED
プロジェクトで次のいずれかのサービスが無効になっています。
無効なサービスは検出結果を生成できません。
この検出結果を修正するには、次の操作を行います。
- 検出結果を確認して、無効になっている API を特定します。
API を有効にします。
サポートされているアセットとスキャンの設定についての説明をご覧ください。
この検出結果のタイプのAPS no resource value configs match any resources
API のカテゴリ名: APS_NO_RESOURCE_VALUE_CONFIGS_MATCH_ANY_RESOURCES
リソース値の構成は、攻撃パス シミュレーション用に定義されていますが、環境内のリソース インスタンスと一致しません。シミュレーションでは、代わりにデフォルトの高価値リソースセットが使用されます。
リソース値の構成は、Google Cloud コンソールの検出結果の説明で示されている次の理由により、リソースと一致しない場合があります。
- どのリソース値の構成も、どのリソース インスタンスとも一致しない。
NONE
を指定する 1 つ以上のリソース値の構成が、他のすべての有効な構成をオーバーライドする。- 定義済みのすべてのリソース値の構成で、
NONE
の値が指定されている。
この検出結果を修正するには、次の操作を行います。
Security Command Center の [設定] で、[攻撃パス シミュレーション] ページに移動します。
組織を選択します。[攻撃パス シミュレーション] ページが開き、既存の構成が表示されます。
[Resource value configuration] リストの [リソース値] 列で、
None
の値を確認します。None
を指定した構成の場合は、次の操作を行います。リソース値の構成の名前をクリックして、構成の仕様を表示します。
必要に応じて、リソース属性の仕様を編集して、構成に一致するリソース インスタンスの数を減らします。
問題が過剰に広範な
None
仕様に起因するものではない場合は、次の操作を行います。HIGH
、MEDIUM
、またはLOW
の値を指定する各構成の名前をクリックして、リソース属性の仕様を表示します。構成を確認し、必要に応じて編集して、目的のリソースと一致するようにスコープ、リソースタイプ、タグ、ラベルの仕様を修正します。
必要に応じて、新しいリソース値の構成を作成します。
変更は、次の攻撃パス シミュレーションに適用されます。
サポートされているアセットとスキャンの設定についての説明をご覧ください。
この検出結果のタイプでAPS resource value assignment limit exceeded
API のカテゴリ名: APS_RESOURCE_VALUE_ASSIGNMENT_LIMIT_EXCEEDED
最後の攻撃パス シミュレーションで、リソース値の構成で識別される高価値リソースのインスタンス数が、高価値リソースセットに含まれる 1,000 のリソース インスタンスの上限を超えています。その結果、Security Command Center は、高価値リソースセットから余分なインスタンス数を除外しました。
この検出結果を修正するには、次の操作を試します。
- タグまたはラベルを使用して、特定のリソースタイプまたは指定したスコープ内の一致数を減らします。タグまたはラベルは、リソース値の構成と照合する前に、リソース インスタンスに適用する必要があります。
- 別の構成で指定されたリソースのサブセットに
NONE
のリソース値を割り当てるリソース値の構成を作成します。NONE
の値を指定すると、他の構成がオーバーライドされ、高価値リソースセットからリソース インスタンスが除外されます。 - リソース値の構成で、スコープ リソース属性の仕様を削減します。
LOW
の値を割り当てるリソース値の構成を削除します。
リソース値の構成を作成、編集、削除する手順については、高価値リソースセットを定義して管理するをご覧ください。
サポートされているアセットとスキャンの設定についての説明をご覧ください。
この検出結果のタイプで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 オブジェクトのデプロイを拒否しているかどうかを確認します。
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"}.
クラスタを含むプロジェクトの管理アクティビティ Cloud Audit Logs で、検出結果の詳細の [説明] フィールドに表示されるエラー メッセージを探します。
アドミッション コントローラが機能していても、Container Threat Detection DaemonSet オブジェクトのデプロイを拒否している場合は、Container Threat Detection の Google マネージド サービス アカウントに
kube-system
Namespace のオブジェクトの管理を許可するように、アドミッション コントローラを構成します。Container Threat Detection のサービス アカウントは、特定の Kubernetes オブジェクトを管理できるように設定する必要があります。
Container Threat Detection でアドミッション コントローラを使用する方法については、PodSecurityPolicy とアドミッション コントローラをご覧ください。
修正を確認する
エラーを修正すると、Security Command Center は Container Threat Detection を自動的に有効にしようとします。有効化が完了するのを待って、Container Threat Detection が有効かどうかを確認するには、次の操作を行います。
コンソールで Kubernetes Engine の [ワークロード] ページに移動します。
必要に応じて、[システム ワークロードを表示] を選択します。
[ワークロード] ページで、最初にクラスタ名でワークロードをフィルタします。
container-watcher
ワークロードを探します。container-watcher
が存在し、そのステータスがOK
の場合、Container Threat Detection は有効です。
KTD image pull failure
API のカテゴリ名: KTD_IMAGE_PULL_FAILURE
必要なコンテナ イメージを gcr.io
(Container Registry イメージホスト)から pull(ダウンロード)できないため、クラスタで Container Threat Detection を有効にできません。
コンテナ イメージの pull またはダウンロードが失敗する場合、複数の理由が考えられます。
以下をご確認ください。
- VPC ネットワーク、DNS、ファイアウォールの設定で、クラスタから
gcr.io
イメージホストへのネットワーク アクセスがブロックされていないことを確認します。 - クラスタが非公開の場合は、限定公開の Google アクセスを有効にして、
gcr.io
イメージホストへのアクセスを許可していることを確認します。 - ネットワーク設定または限定公開の Google アクセスが障害の原因でない場合は、GKE のトラブルシューティング ドキュメントの ImagePullBackOff と ErrImagePull エラーをご覧ください。
サポートされているアセットとスキャンの設定についての説明をご覧ください。
この検出結果のタイプのKTD service account missing permissions
API のカテゴリ名: KTD_SERVICE_ACCOUNT_MISSING_PERMISSIONS
Google Cloud コンソールの検出結果で特定された Container Threat Detection サービス アカウントには、必要な権限がありません。Container Threat Detection のすべてまたは一部の検出結果が Security Command Center に送信されていません。
この検出結果を修正するには、次の操作を行います。
Container Threat Detection サービス エージェント ロール(
roles/containerthreatdetection.serviceAgent
)を、サービス アカウントに付与します。詳細については、単一のロールを付与するをご覧ください。また、カスタムロールを使用する場合は、そのロールに Container Threat Detection サービス エージェント ロールの権限が付与されていることを確認してください。
サービス アカウントが Container Threat Detection サービス エージェント ロールのいかなる権限も使用できないようにする IAM 拒否ポリシーがないことを確認してください。アクセスをブロックする拒否ポリシーがある場合は、サービス アカウントを、拒否ポリシーの例外プリンシパルとして追加します。
Container Threat Detection サービス アカウントと、必要なロールおよび権限の詳細については、以下をご覧ください。
サポートされているアセットとスキャンの設定についての説明をご覧ください。
この検出結果のタイプでMisconfigured Cloud Logging Export
API のカテゴリ名: MISCONFIGURED_CLOUD_LOGGING_EXPORT
Cloud Logging に継続的なエクスポートを行うために構成したプロジェクトが使用できません。このため、Security Command Center から Logging に検出結果を送信できません。
この検出結果を修正するには、次のいずれかを行います。
プロジェクトの復元までの期間がまだ経過していない場合は、見つからないプロジェクトを復元します。
プロジェクトが完全に削除されている場合は、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 をブロックしているサービス境界を特定する
- 検出結果に関連付けられた VPC Service Controls の一意の ID とプロジェクト ID を取得します。
- 検出結果の詳細を表示するには、カテゴリ名をクリックします。
- [説明] フィールドで、VPC Service Controls の一意の ID をコピーします(例:
5e4GI409D6BTWfOp_6C-uSwmTpOQWcmW82sfZW9VIdRhGO5pXyCJPQ
)。 - [リソースのパス] フィールドで、プロジェクトの ID をコピーします。
アクセス ポリシー ID とサービス境界の名前を取得します。
Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。
ツールバーで、検出結果に関連付けられたプロジェクトを選択します。
検索ボックスに、エラーの一意の ID を入力します。
クエリ結果にエラーが表示されない場合は、[ヒストグラム] でタイムラインを開き、クエリを再実行します。
表示されたエラーをクリックします。
[ネストされたフィールドを開く] をクリックします。
servicePerimeterName
フィールドの値をコピーします。値は次の形式になります。accessPolicies/ACCESS_POLICY/servicePerimeters/SERVICE_PERIMETER
この例で、
accessPolicies/540107806624/servicePerimeters/vpc_sc_misconfigured
はサービス境界の完全なリソース名です。- ACCESS_POLICY はアクセス ポリシー ID です(例:
540107806624
)。 - SERVICE_PERIMETER はサービス境界の名前です(例:
vpc_sc_misconfigured
)。
- ACCESS_POLICY はアクセス ポリシー ID です(例:
アクセス ポリシー 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 で特定したサービス境界に対して上り(内向き)ルールを作成します。
サービス アカウントにサービス境界へのインバウンド アクセスを許可するには、次の手順を行います。
[VPC Service Controls] に移動します。
ツールバーで Google Cloud 組織を選択します。
プルダウン リストで、アクセスを許可するサービス境界を含むアクセス ポリシーを選択します。
アクセス ポリシーに関連付けられているサービス境界がリストに表示されます。
サービス境界の名前をクリックします。
[
境界を編集] をクリックします。ナビゲーション メニューで、[上り(内向き)ポリシー] をクリックします。
[ルールを追加] をクリックします。
次のようにルールを構成します。
API クライアントの FROM 属性
- [ソース] で [すべてのソース] を選択します。
- [ID] で、[選択した ID] を選択します。
- [ユーザー アカウント / サービス アカウントの追加] フィールドで [選択] をクリックします。
- サービス アカウントのメールアドレスを入力します。組織レベルとプロジェクト レベルの両方にサービス アカウントがある場合は、両方を追加します。
- [保存] をクリックします。
GCP サービス / リソースの TO 属性
[プロジェクト] で [すべてのプロジェクト] を選択するか、検出結果で指定されたプロジェクトを選択します。
[サービス] で [すべてのサービス] を選択するか、Security Health Analytics に必要な次の各サービスを選択します。
- BigQuery API
- Binary Authorization API
- Cloud Logging API
- Cloud Monitoring API
- Compute Engine API
- Kubernetes Engine API
サービス境界で必要なサービスへのアクセスを制限している場合、Security Health Analytics はこのサービスの検出結果を生成できません。
ナビゲーション メニューで、[保存] をクリックします。
詳細については、上り(内向き)ポリシーと下り(外向き)ポリシーの構成をご覧ください。
サポートされているアセットとスキャンの設定についての説明をご覧ください。
この検出結果のタイプのSecurity Command Center service account missing permissions
API のカテゴリ名: SCC_SERVICE_ACCOUNT_MISSING_PERMISSIONS
Security Command Center の Google 管理のサービス アカウントには、正常に機能するために必要な権限がありません。
サービス アカウントの ID は、次の形式のメールアドレスです。
service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com
次のように置き換えます。
- RESOURCE_KEYWORD: キーワード
org
またはproject
(サービス アカウントを所有するリソースによって異なります) - RESOURCE_ID: 次のいずれかが設定されています。
- サービス アカウントが組織によって所有されている場合は組織 ID
- サービス アカウントがプロジェクトによって所有されている場合はプロジェクト番号
組織レベルとプロジェクト レベルの両方にサービス アカウントがある場合は、両方に修正を適用します。
この検出結果を修正するには、次の操作を行います。
サービス アカウントにセキュリティ センター サービス エージェント(
roles/securitycenter.serviceAgent
)のロールを付与します。詳細については、単一のロールを付与するをご覧ください。
また、カスタムロールを使用する場合は、そのロールにセキュリティ センター サービス エージェントのロールの権限が付与されていることを確認してください。
必要なロールのあらゆる権限をサービス アカウントが使用できないようにする IAM 拒否ポリシーがないことを確認してください。アクセスをブロックする拒否ポリシーがある場合は、サービス アカウントを、拒否ポリシーの例外プリンシパルとして追加します。
サポートされているアセットとスキャンの設定についての説明をご覧ください。
この検出結果のタイプの次のステップ
Security Command Center のエラーについて確認する。