Security Health Analytics の検出結果を修正する

このページでは、Security Command Center を使用して Security Health Analytics の検出結果を修正するための参照ガイドと手法の一覧を示しています。

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

Security Health Analytics の修正

このセクションでは、すべての Security Health Analytics の検出結果の修正手順について説明します。

Admin service account

API のカテゴリ名: ADMIN_SERVICE_ACCOUNT

組織のサービス アカウントには、管理者オーナー、または編集者の特権が割り当てられています。これらのロールは広範な権限を持つため、サービス アカウントには割り当てないでください。サービス アカウントと、サービス アカウントに使用可能なロールについては、サービス アカウントをご覧ください。

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

  1. Cloud Console の [IAM ポリシー] ページに移動します。

    [IAM ポリシー] に移動

  2. 検出結果で特定されたプリンシパルごとに、次のことを行います。

    1. プリンシパルの横にある [編集] をクリックします。
    2. 権限を削除するには、問題となっているロールの横にある [削除] をクリックします。
    3. [保存] をクリックします。

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

Alpha cluster enabled

API のカテゴリ名: ALPHA_CLUSTER_ENABLED

アルファ クラスタ機能は Google Kubernetes Engine(GKE)クラスタで有効になっています。

アルファ クラスタにより、新機能が一般にリリースされる前に、新機能を使用するワークロードを先行ユーザーがテストできます。アルファ クラスタは、GKE API のすべての機能が有効になっていますが、GKE SLA の対象外です。つまり、セキュリティ アップデートを受信せず、ノードの自動アップグレードとノードの自動修復は無効であり、アップグレードすることもできません。また、30 日後に自動的に削除されます。

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

アルファ クラスタは無効にできません。アルファ機能を無効にして新しいクラスタを作成する必要があります。

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. [作成] をクリックします。

  3. 作成するクラスタのタイプの横にある [構成] を選択します。

  4. [機能] タブで、[このクラスタで Kubernetes アルファ版の機能を有効にする] が無効になっていることを確認します。

  5. [作成] をクリックします。

  6. ワークロードを新しいクラスタに移動するには、異なるマシンタイプへのワークロードの移行をご覧ください。

  7. 元のクラスタを削除するには、クラスタの削除をご覧ください。

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

API key APIs unrestricted

API のカテゴリ名: API_KEY_APIS_UNRESTRICTED

過度に広範囲にわたって使用されている API キーが存在します。

制限されていない API キーは、キーが保存されているデバイスから取得される可能性や、ブラウザなどで誰からでも参照される可能性があるため、安全ではありません。最小権限の原則に従って、アプリケーションに必要な API のみを呼び出すように API キーを構成してください。詳細については、API キーの使用をご覧ください。

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

  1. Cloud Console の [API キー] ページに移動します。

    [API キー] に移動

  2. API キーごとに、以下のように設定します。

    1. [編集] をクリックします。
    2. [API 制限] で [キーを制限] をクリックします。
    3. [API を選択] プルダウン リストで、許可する API を選択します。
    4. [保存] をクリックします。設定が有効になるまで、最長で 5 分かかる場合があります。

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

API key apps unrestricted

API のカテゴリ名: API_KEY_APPS_UNRESTRICTED

無制限に使用され、信頼できないアプリによる使用が許可されている API キーがあります。

制限されていない API キーは、キーが格納されているデバイス上で取得できます。つまり、ブラウザなどで誰でも参照できるため、安全ではありません。最小権限の原則に従って、API キーの使用を、信頼できるホスト、HTTP リファラー、アプリに制限します。詳細については、アプリケーションの制限を追加するをご覧ください。

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

  1. Cloud Console の [API キー] ページに移動します。

    [API キー] に移動

  2. API キーごとに、以下のように設定します。

    1. [編集] をクリックします。
    2. [アプリケーションの制限] で、制限カテゴリを選択します。アプリケーションの制限はキーごとに 1 つ設定できます。
    3. アプリケーションのニーズに基づいて制限を追加するには、[アイテムを追加] をクリックします。
    4. アイテムの追加が完了したら、[完了] をクリックします。
    5. [保存] をクリックします。

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

API key exists

API のカテゴリ名: API_KEY_EXISTS

プロジェクトが標準認証ではなく API キーを使用しています。

API キーは、シンプルな暗号化された文字列であり、誰でも容易に見つけて使用できるため、安全ではありません。API キーは、キーが格納されているデバイス上で取得でき、ブラウザなどで誰でも参照できます。また、API キーは、リクエストを行っているユーザーやアプリケーションの特定も行いません。API キーを使用するのではなく、標準の認証フローを使用してください。詳細については、エンドユーザーとして認証をご覧ください。

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

  1. アプリケーションが代替形式の認証を使用して構成されていることを確認してください。
  2. Cloud Console の [API 認証情報] ページに移動します。

    [API 認証情報] に移動

  3. [API キー] セクションで、それぞれの API キーの横にある [削除] をクリックします。

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

API key not rotated

API のカテゴリ名: API_KEY_NOT_ROTATED

API キーが 90 日以上ローテーションされていません。

API キーには有効期限がないため、盗難に遭った場合、プロジェクト オーナーがキーを取り消すかローテーションするまで、いつまでも使用される恐れがあります。API キーを頻繁に再生成すると、セキュリティ侵害を受けたアカウントや使用停止となったアカウントで、盗難に遭った API キーがデータへのアクセスに使用され得る期間を短縮できます。API キーは、少なくとも 90 日ごとにローテーションします。詳細については、API キーを保護するをご覧ください。

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

  1. Cloud Console の [API キー] ページに移動します。

    [API キー] に移動

  2. API キーごとに、以下のように設定します。

    1. [作成日] の日付を確認します。
    2. キーが生成されてから 90 日以上経過している場合は、キーの名前をクリックするか、[編集] をクリックします。
    3. ページ上部の [キーを再生成] をクリックします。
    4. [キーを交換] をクリックします。
    5. アプリケーションを中断なく動作させるには、新しい API キーを使用するようにアプリケーションを更新してください。古い API キーは 24 時間後に完全に無効となります。

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

Audit config not monitored

API のカテゴリ名: AUDIT_CONFIG_NOT_MONITORED

ログ指標とアラートが、監査構成の変更をモニタリングするように構成されていません。

Cloud Logging では、管理アクティビティとデータアクセスのログが生成され、セキュリティ分析、リソース変更の追跡、コンプライアンスについての監査を実施できます。監査構成の変更をモニタリングすることで、プロジェクト内のすべてのアクティビティを随時監査できます。詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

この検出結果を修正するには、指標を作成し、必要に応じてアラート ポリシーも作成します。

指標の作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動

  2. [指標を作成] をクリックします。

  3. [指標タイプ] で [カウンター] を選択します。

  4. [詳細] で、以下の手順を行います。

    1. [ログ指標の名前] を設定します。
    2. 説明を追加します。
    3. [単位] に「1」を設定します。
  5. [フィルタの選択] で、次のテキストをコピーして [フィルタの作成] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

      protoPayload.methodName="SetIamPolicy"
      AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*
    

  6. [指標を作成] をクリックします。確認メッセージが表示されます。

アラート ポリシーを作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動
  2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。
  3. [その他 ] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

    残りの手順は、以前のアラート インターフェースを対象としています。プレビュー版のインターフェースについては、指標ベースのアラート ポリシーの管理をご覧ください。

  4. 表示されたページで、条件のタイトルを入力し、[保存] をクリックします。
  5. [何をトラッキングしますか?] で [条件を追加] をクリックし、モニタリングするリソースと、アラートがトリガーされるタイミングを定義して、ダイアログを完了します。条件のフィールドの詳細については、条件の指定をご覧ください。
  6. 完了したら、[追加] をクリックして、[次へ] をクリックします。
  7. [通知するユーザーは?] で [通知チャンネル] プルダウンをクリックして通知方法を選択します。詳細については、通知チャンネルの管理をご覧ください。
  8. [OK] をクリックし、[次へ] をクリックします。
  9. [問題を解決する手順は?] で、[アラート名] を設定します。
  10. [保存] をクリックします。

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

Audit logging disabled

API のカテゴリ名: AUDIT_LOGGING_DISABLED

このリソースの監査ロギングが無効になっています。

すべての管理アクティビティ、読み取りアクセス権、ユーザーデータに対する書き込みアクセス権を追跡するため、すべてのサービスで Cloud Logging を有効にします。情報量によっては、Cloud Logging の費用が高額になる場合があります。サービスと使用量、費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

  1. Cloud Console の [デフォルトの監査構成] ページに移動します。

    [デフォルトの監査構成] に移動

  2. [ログタイプ] タブで、[管理読み取り]、[データ読み取り]、[データ書き込み] を選択します。

  3. [保存] をクリックします。

  4. [除外ユーザー] タブで、それぞれの名前の横にある [削除] をクリックして、リストに記載されているユーザーをすべて削除します。

  5. [保存] をクリックします。

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

Auto backup disabled

API のカテゴリ名: AUTO_BACKUP_DISABLED

Cloud SQL データベースに、有効な自動バックアップがありません。

データ損失を防ぐために、SQL インスタンスの自動バックアップを有効にします。詳細については、オンデマンド バックアップと自動バックアップの作成と管理をご覧ください。

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

  1. Cloud Console の [SQL インスタンスのバックアップ] ページに移動します。

    [SQL インスタンスのバックアップ] に移動

  2. [設定] の横にある [編集] をクリックします。

  3. [バックアップを自動化する] のチェックボックスをオンにします。

  4. プルダウン メニューで、データを自動的にバックアップするための時間枠を選択します。

  5. [保存] をクリックします。

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

Auto repair disabled

API のカテゴリ名: AUTO_REPAIR_DISABLED

Google Kubernetes Engine(GKE)クラスタの自動修復機能(ノードの稼働状態を正常に保つ機能)が無効になっています。

この機能を有効にすると、GKE でクラスタ内の各ノードのヘルス状態が定期的にチェックされます。ノードが長期にわたって連続してヘルスチェックに失敗すると、GKE はそのノードの修復プロセスを開始します。詳細については、ノードの自動修復をご覧ください。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. [ノード] タブをクリックします。

  3. ノードプールごとに、以下を行います。

    1. ノードプールの名前をクリックして、詳細ページに移動します。
    2. [編集] をクリックします。
    3. [管理] で、[自動修復を有効化] を選択します。
    4. [保存] をクリックします。

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

Auto upgrade disabled

API のカテゴリ名: AUTO_UPGRADE_DISABLED

GKE クラスタの自動アップグレード機能(最新の安定したバージョンの Kubernetes でクラスタとノードプールを保持する機能)が無効になっています。

詳細については、ノードの自動アップグレードをご覧ください。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. クラスタのリストで、クラスタ名をクリックします。

  3. [ノード] タブをクリックします。

  4. ノードプールごとに、以下を行います。

    1. ノードプールの名前をクリックして、詳細ページに移動します。
    2. [編集] をクリックします。
    3. [管理] で [自動アップグレードを有効化] を選択します。
    4. [保存] をクリックします。

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

BigQuery table CMEK disabled

API のカテゴリ名: BIGQUERY_TABLE_CMEK_DISABLED

BigQuery テーブルが顧客管理の暗号鍵(CMEK)を使用するように構成されていません。

CMEK を使用すると、Cloud KMS で作成、管理する鍵は、Google Cloud がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより細かく制御できます。詳細については、Cloud KMS 鍵によるデータの保護をご覧ください。

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

  1. Cloud Key Management Service で保護されるテーブルを作成します
  2. 新しい CMEK 対応テーブルにテーブルをコピーします
  3. 元のテーブルを削除します

データセット内のすべての新しいテーブルを暗号化するデフォルトの CMEK 鍵を設定するには、データセットのデフォルト鍵の設定をご覧ください。

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

Binary authorization disabled

API のカテゴリ名: BINARY_AUTHORIZATION_DISABLED

GKE クラスタで Binary Authorization が無効になっています。

Binary Authorization には、開発プロセス中に信頼できる機関によって署名されたコンテナ イメージのみをクラスタにデプロイできるようにすることで、サプライ チェーンのセキュリティを保護するオプション機能が用意されています。署名ベースのデプロイを適用することで、コンテナ環境をより厳密に管理し、確認済みのイメージのみをデプロイできます。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. [セキュリティ] セクションで、[Binary Authorization] 行の編集アイコン()をクリックします。

    クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

  3. ダイアログで、[Binary Authorization を有効にする] を選択します。

  4. [変更を保存] をクリックします。

  5. [Binary Authorization の設定] ページに移動します。

    Binary Authorization に移動

  6. 認証者を必要とするポリシーが構成されており、プロジェクトのデフォルト ルールが [すべてのイメージを許可] に構成されていないことを確認します。詳細については、GKE の設定をご覧ください。

    ポリシーに違反するイメージのデプロイが許可され、違反が Cloud Audit Logs に記録されるようにするには、ドライラン モードを有効にします

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

Bucket CMEK disabled

API のカテゴリ名: BUCKET_CMEK_DISABLED

バケットは、顧客管理の暗号鍵(CMEK)を使用して暗号化されていません。

バケットにデフォルトの CMEK を設定すると、データへのアクセスをより詳細に制御できます。詳細については、顧客管理の暗号鍵をご覧ください。

この検出項目を修正するには、顧客管理の暗号鍵の使用に沿って、バケットで CMEK を使用します。CMEK を使用すると、Cloud KMS に関連する追加費用が発生します。

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

Bucket IAM not monitored

API のカテゴリ名: BUCKET_IAM_NOT_MONITORED

ログ指標とアラートが、Cloud Storage IAM 権限の変更をモニタリングするように構成されていません。

Cloud Storage バケットの権限に対する変更をモニタリングすることで、過剰な権限を持つユーザーや、不審なアクティビティを特定できます。詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

指標の作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動

  2. [指標を作成] をクリックします。

  3. [指標タイプ] で [カウンター] を選択します。

  4. [詳細] で、以下の手順を行います。

    1. [ログ指標の名前] を設定します。
    2. 説明を追加します。
    3. [単位] に「1」を設定します。
  5. [フィルタの選択] で、次のテキストをコピーして [フィルタの作成] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

      resource.type=gcs_bucket
      AND protoPayload.methodName="storage.setIamPermissions"
    

  6. [指標を作成] をクリックします。確認メッセージが表示されます。

アラート ポリシーを作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動
  2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。
  3. [その他 ] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

    残りの手順は、以前のアラート インターフェースを対象としています。プレビュー版のインターフェースについては、指標ベースのアラート ポリシーの管理をご覧ください。

  4. 表示されたページで、条件のタイトルを入力し、[保存] をクリックします。
  5. [何をトラッキングしますか?] で [条件を追加] をクリックし、モニタリングするリソースと、アラートがトリガーされるタイミングを定義して、ダイアログを完了します。条件のフィールドの詳細については、条件の指定をご覧ください。
  6. 完了したら、[追加] をクリックして、[次へ] をクリックします。
  7. [通知するユーザーは?] で [通知チャンネル] プルダウンをクリックして通知方法を選択します。詳細については、通知チャンネルの管理をご覧ください。
  8. [OK] をクリックし、[次へ] をクリックします。
  9. [問題を解決する手順は?] で、[アラート名] を設定します。
  10. [保存] をクリックします。

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

Bucket logging disabled

API のカテゴリ名: BUCKET_LOGGING_DISABLED

ロギングが有効になっていないストレージ バケットがあります。

Cloud Storage のバケット向けにアクセスログとストレージ情報を有効にすると、セキュリティの問題の調査とストレージ消費のモニタリングを行う際に有効です。アクセスログにより、特定のバケット上で行われたすべてのリクエストに関する情報が提供されます。また、ストレージログにより、そのバケットのストレージの消費に関する情報が提供されます。

この検出結果を修正するには、使用状況ログとストレージログ ガイドの手順を完了して、Security Health Analytics の検出結果によって特定されたバケットのロギングを設定します。

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

Bucket policy only disabled

API のカテゴリ名: BUCKET_POLICY_ONLY_DISABLED

均一なバケットレベルのアクセス(以前の「バケット ポリシーのみ」)が構成されていません。

均一なバケットレベルのアクセスは、オブジェクト レベルのアクセス許可(ACL)を無効にすることにより、バケット アクセス制御を簡素化します。有効にすると、バケットレベルの IAM 権限のみが、バケットとバケットに含まれるオブジェクトへのアクセス権を付与します。詳細については、均一なバケットレベルのアクセスをご覧ください。

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

  1. Cloud Console の [Cloud Storage ブラウザ] ページに移動します。

    Cloud Storage ブラウザに移動

  2. バケットのリストで、目的のバケットの名前をクリックします。

  3. [構成] タブをクリックします。

  4. [権限] の [アクセス制御] の行で、[編集] アイコン()をクリックします。

  5. ダイアログで [均一] を選択します。

  6. [保存] をクリックします。

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

Cluster logging disabled

API のカテゴリ名: CLUSTER_LOGGING_DISABLED

GKE クラスタのロギングが有効になっていません。

セキュリティ問題の調査と使用状況のモニタリングに役立てるために、クラスタ上で Cloud Logging を有効にします。

情報量によっては、Cloud Logging の費用が高額になる場合があります。サービスと使用量、費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. Security Health Analytics の検出結果に表示されているクラスタを選択します。

  3. [編集] をクリックします。

    クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

  4. [以前の Stackdriver Logging] または [Stackdriver Kubernetes Engine Monitoring] のプルダウン リストで、[有効] を選択します。

    これらのオプションに互換性はありません。Stackdriver Kubernetes Engine Monitoring のみ、または以前の Stackdriver Logging と一緒に以前の Stackdriver Monitoring を使用するようにしてください。

  5. [保存] をクリックします。

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

Cluster monitoring disabled

API のカテゴリ名: CLUSTER_MONITORING_DISABLED

GKE クラスタでモニタリングが無効になっています。

セキュリティ問題の調査と使用状況のモニタリングに役立てるために、クラスタ上で Cloud Monitoring を有効にします。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. Security Health Analytics の検出結果に表示されているクラスタを選択します。

  3. [編集] をクリックします。

    クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

  4. [以前の Stackdriver Logging] または [Stackdriver Kubernetes Engine Monitoring] のプルダウン リストで、[有効] を選択します。

    これらのオプションに互換性はありません。Stackdriver Kubernetes Engine Monitoring のみ、または以前の Stackdriver Monitoring と一緒に以前の Stackdriver Logging を使用するようにしてください。

  5. [保存] をクリックします。

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

Cluster private Google access disabled

API のカテゴリ名: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

クラスタホストが、Google API にアクセスするためのプライベートの内部 IP アドレスのみを使用するように構成されていません。

限定公開の Google アクセスを使用すると、プライベートの内部 IP アドレスしか持たない仮想マシン(VM)インスタンスが、Google API とサービスのパブリック IP アドレスにアクセスできます。詳細については、限定公開の Google アクセスの構成をご覧ください。

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

  1. Cloud Console の [Virtual Private Cloud ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. ネットワークのリストで、目的のネットワークの名前をクリックします。

  3. [VPC ネットワークの詳細] ページで、[サブネット] タブをクリックします。

  4. サブネットのリストで、検出結果内の Kubernetes クラスタに関連付けられているサブネットの名前をクリックします。

  5. [サブネットの詳細] ページで、[編集] をクリックします。

  6. [限定公開の Google アクセス] で [オン] を選択します。

  7. [保存] をクリックします。

  8. Google API に対してのみ外部トラフィックを送信する VM インスタンスからパブリック(外部)IP を削除するには、静的外部 IP アドレスの割り当て解除をご覧ください。

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

Cluster secrets encryption disabled

API のカテゴリ名: CLUSTER_SECRETS_ENCRYPTION_DISABLED

アプリケーション レイヤでのシークレットの暗号化は GKE クラスタで無効になっています。

アプリケーション レイヤでのシークレットの暗号化により、GKE のシークレットが Cloud KMS 鍵で暗号化されます。この機能は、ユーザー定義のシークレットやクラスタの操作に必要なシークレット(サービス アカウント キーなど)の機密データのセキュリティを強化します。これらの情報はすべて etcd に保存されます。

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

  1. Cloud Console で [Cloud KMS 鍵] ページに移動します。

    [Cloud KMS 鍵] に移動

  2. アプリケーション キーを確認するか、データベース暗号鍵(DEK)を作成します。詳細については、Cloud KMS 鍵を作成するをご覧ください。

  3. [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  4. 検出結果でクラスタを選択します。

  5. [セキュリティ] の [アプリケーション レイヤでのシークレットの暗号化] フィールドで、 [アプリケーション レイヤでのシークレットの暗号化を編集] をクリックします。

  6. [アプリケーション レイヤでの Secret の暗号化を有効にする] チェックボックスをオンにして、作成した DEK を選択します。

  7. [変更を保存] をクリックします。

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

Cluster shielded nodes disabled

API のカテゴリ名: CLUSTER_SHIELDED_NODES_DISABLED

シールドされた GKE ノードがクラスタで有効になっていません。

シールドされた GKE ノードが存在しない場合、攻撃者は Pod の脆弱性を悪用してブートストラップ認証情報を抜き取って、クラスタ内のノードになりすますことができます。この脆弱性により、攻撃者はクラスタのシークレットにアクセスできます。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. 検出結果でクラスタを選択します。

  3. [セキュリティ] の [シールドされた GKE ノード] フィールドで、 [シールドされた GKE ノードを編集] をクリックします。

  4. [シールドされた GKE ノード] チェックボックスをオンにします。

  5. [変更を保存] をクリックします。

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

Compute project wide SSH keys allowed

API のカテゴリ名: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

プロジェクト全体の SSH 認証鍵が使用され、プロジェクト内のすべてのインスタンスにログインできるようになっています。

プロジェクト全体の SSH 認証鍵を使用すると SSH 認証鍵の管理が容易になりますが、不正使用された場合は、プロジェクト内のすべてのインスタンスに影響を及ぼす可能性のあるセキュリティ リスクが発生します。インスタンス固有の SSH 認証鍵を使用してください。SSH 認証鍵が不正使用された場合に攻撃対象が限定されます。詳細については、メタデータ内の SSH 認証鍵の管理をご覧ください。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. インスタンスのリストで、検出結果内のインスタンスの名前をクリックします。

  3. [VM インスタンスの詳細] ページで、 [編集] をクリックします。

  4. [SSH 認証鍵] で、[プロジェクト全体の SSH 認証鍵をブロック] を選択します。

  5. [保存] をクリックします。

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

Compute Secure Boot disabled

API のカテゴリ名: COMPUTE_SECURE_BOOT_DISABLED

Shielded VM で、セキュアブートが有効になっていません。

セキュアブートを使用すると、ルートキットとブックキットから仮想マシンが保護されます。Compute Engine はデフォルトではセキュアブートを有効にしません。これは、署名されていないドライバと低レベルのソフトウェアには互換性がない場合があるためです。VM に互換性のないソフトウェアを使用せず、セキュアブートを有効にすると起動される場合は、セキュアブートを使用することをおすすめします。Nvidia ドライバを含むサードパーティ モジュールを使用している場合は、有効にする前にセキュアブートと互換性があることを確認してください。

詳細については、セキュアブートをご覧ください。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. インスタンスのリストで、検出結果内のインスタンスの名前をクリックします。

  3. [VM インスタンスの詳細] ページで、 [編集] をクリックします。

  4. インスタンスが停止したら、 [編集] をクリックします。

  5. [Shielded VM] で [セキュアブートをオンにする] を選択します。

  6. [保存] をクリックします。

  7. [開始] をクリックしてインスタンスを起動します。

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

Compute serial ports enabled

API のカテゴリ名: COMPUTE_SERIAL_PORTS_ENABLED

インスタンスのシリアルポートが有効になっているため、インスタンスのシリアル コンソールへ接続できるようになっています。

インスタンス上でインタラクティブなシリアル コンソールを有効にした場合、クライアントは任意の IP アドレスからそのインスタンスへの接続を試行できます。そのため、インタラクティブなシリアル コンソールのサポートは無効にしてください。詳しくは、プロジェクトのアクセスを有効にするをご覧ください。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. インスタンスのリストで、検出結果内のインスタンスの名前をクリックします。

  3. [VM インスタンスの詳細] ページで、 [編集] をクリックします。

  4. [リモート アクセス] で、[シリアルポート接続を有効化] を消去します。

  5. [保存] をクリックします。

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

Confidential Computing disabled

API のカテゴリ名: CONFIDENTIAL_COMPUTING_DISABLED

Compute Engine インスタンスで Confidential Computing が有効になっていません。

Confidential Computing は、使用中にデータを暗号化することで、エンドツーエンドの暗号化に 3 つ目の軸を追加します。Confidential Computing と AMD Secure Encrypted Virtualization(SEV)によって実現する機密実行環境によって、Google Cloud は機密コードとその他のデータがメモリで処理されている最中も暗号化された状態に保ちます。

Confidential Computing はインスタンスの作成時にのみ有効にできます。このため、現在のインスタンスを削除して新しいインスタンスを作成する必要があります。

詳細については、Confidential VMs と Compute Engine をご覧ください。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. インスタンスのリストで、検出結果内のインスタンスの名前をクリックします。

  3. [VM インスタンスの詳細] ページで、[削除] をクリックします。

  4. Cloud Console を使用して Confidential VMs を作成します

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

COS not used

API のカテゴリ名: COS_NOT_USED

Compute Engine VM が、Google Cloud で Docker コンテナを安全に動作させるように設計されている Container-Optimized OS を使用していません。

Container-Optimized OS は、Google Cloud 上でのコンテナのホスティングと実行を目的とした、Google が推奨する OS です。OS フットプリントは小さいため、セキュリティの脅威にさらされる可能性が最小限に抑えられます。また、セキュリティ脆弱性のパッチが適切なタイミングで自動更新されます。詳細については、Container-Optimized OS の概要をご覧ください。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. クラスタのリストで、検出結果にあるクラスタの名前をクリックします。

  3. [ノード] タブをクリックします。

  4. ノードプールごとに、以下を行います。

    1. ノードプールの名前をクリックして、詳細ページに移動します。
    2. [編集] をクリックします。
    3. [ノード] -> [イメージの種類] で、[変更] をクリックします。
    4. [Container-Optimized OS] を選択し、[変更] をクリックします。
    5. [保存] をクリックします。

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

Custom role not monitored

API のカテゴリ名: CUSTOM_ROLE_NOT_MONITORED

ログ指標とアラートが、カスタムロールの変更をモニタリングするように構成されていません。

IAM には、特定の Google Cloud リソースへのアクセス権を付与する事前定義ロールとカスタムロールが用意されています。ロールの作成、削除、更新のアクティビティをモニタリングすると、権限が過剰なロールを早い段階で特定できます。詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

指標の作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動

  2. [指標を作成] をクリックします。

  3. [指標タイプ] で [カウンター] を選択します。

  4. [詳細] で、以下の手順を行います。

    1. [ログ指標の名前] を設定します。
    2. 説明を追加します。
    3. [単位] に「1」を設定します。
  5. [フィルタの選択] で、次のテキストをコピーして [フィルタの作成] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

      resource.type="iam_role"
      AND (protoPayload.methodName="google.iam.admin.v1.CreateRole"
      OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
      OR protoPayload.methodName="google.iam.admin.v1.UpdateRole")
    

  6. [指標を作成] をクリックします。確認メッセージが表示されます。

アラート ポリシーを作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動
  2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。
  3. [その他 ] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

    残りの手順は、以前のアラート インターフェースを対象としています。プレビュー版のインターフェースについては、指標ベースのアラート ポリシーの管理をご覧ください。

  4. 表示されたページで、条件のタイトルを入力し、[保存] をクリックします。
  5. [何をトラッキングしますか?] で [条件を追加] をクリックし、モニタリングするリソースと、アラートがトリガーされるタイミングを定義して、ダイアログを完了します。条件のフィールドの詳細については、条件の指定をご覧ください。
  6. 完了したら、[追加] をクリックして、[次へ] をクリックします。
  7. [通知するユーザーは?] で [通知チャンネル] プルダウンをクリックして通知方法を選択します。詳細については、通知チャンネルの管理をご覧ください。
  8. [OK] をクリックし、[次へ] をクリックします。
  9. [問題を解決する手順は?] で、[アラート名] を設定します。
  10. [保存] をクリックします。

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

Dataproc image outdated

API のカテゴリ名: DATAPROC_IMAGE_OUTDATED

Dataproc クラスタは、Apache Log4j 2 ユーティリティのセキュリティの脆弱性による影響を受ける Dataproc イメージ バージョン(CVE-2021-44228)と CVE-2021-45046)を使用して作成されています。

この検出項目では、Clusterconfig プロパティの softwareConfig.imageVersion フィールドに、影響を受ける次のいずれかのバージョンがあるかどうかチェックして脆弱性を見つけます。

  • 1.3.95 より前のイメージ バージョン。
  • 1.4.77、1.5.53、および 2.0.27 より前のサブマイナー イメージ バージョン。

カスタム Dataproc イメージのバージョン番号は手動でオーバーライドできます。次のようなシナリオを考えます。

  • 影響を受けるカスタム イメージのバージョンを変更して、影響を受けないようにすることができます。この場合、この検出項目は検出結果を出力しません。
  • 脆弱性のないカスタム イメージを、脆弱性のあることがわかっているバージョンでオーバーライドできます。この場合、この検出項目は偽陽性の結果を出力します。このような偽陽性結果を抑制するには、検出結果をミュートします。

この検出結果を修正するには、影響を受けるクラスタを再作成して更新してください。

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

Dataset CMEK disabled

API のカテゴリ名: DATASET_CMEK_DISABLED

BigQuery データセットが、デフォルトの顧客管理の暗号鍵(CMEK)を使用するように構成されていません。

CMEK を使用すると、Cloud KMS で作成、管理する鍵は、Google Cloud がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより細かく制御できます。詳細については、Cloud KMS 鍵によるデータの保護をご覧ください。

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

デフォルトの暗号化と CMEK の暗号化の間でテーブルを切り替えることはできません。データセット内のすべての新しいテーブルを暗号化するためのデフォルトの CMEK 鍵を設定するには、データセットのデフォルト鍵を設定するの手順に沿って操作してください。

デフォルトの鍵を設定しても、バケット内にある現在のオブジェクトは、新しい鍵で遡及的に再暗号化されません。既存のデータに CMEK を使用するには、次のようにします。

  1. 新しいデータセットを作成します。
  2. 作成したデータセットにデフォルトの CMEK 鍵を設定します。
  3. CMEK を有効にしたデータセットにテーブルをコピーするには、テーブルのコピーの手順に沿って操作します。
  4. データを正常にコピーしたら、元のデータセットを削除します。

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

Default network

API のカテゴリ名: DEFAULT_NETWORK

デフォルト ネットワークがプロジェクト内に存在しています。

デフォルト ネットワークでは、ファイアウォール ルールとネットワーク構成が自動的に作成され、安全性の低い場合があります。詳細については、デフォルト ネットワークをご覧ください。

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

  1. Cloud Console の [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. ネットワークのリストで、デフォルト ネットワークの名前をクリックします。

  3. [VPC ネットワークの詳細] ページで、 [VPC ネットワークの削除] をクリックします。

  4. カスタム ファイアウォール ルールがある新しいネットワークを作成するには、ネットワークの作成をご覧ください。

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

Default service account used

API のカテゴリ名: DEFAULT_SERVICE_ACCOUNT_USED

Compute Engine インスタンスが、デフォルトのサービス アカウントを使用するように構成されています。

デフォルトの Compute Engine サービス アカウントには、プロジェクトの編集者のロールが付与されています。このロールでは、ほとんどの Google Cloud サービスに対する読み取りと書き込みのアクセスが許可されています。権限昇格や不正アクセスを防止するには、デフォルトの Compute Engine サービス アカウントを使用しないでください。代わりに、新しいサービス アカウントを作成して、インスタンスで必要な権限のみを割り当てます。ロールと権限については、アクセス制御をご覧ください。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. Security Health Analytics の検出結果に関連するインスタンスを選択します。

  3. 読み込まれた [インスタンスの詳細] ページで、 [停止] をクリックします。

  4. インスタンスが停止したら、 [編集] をクリックします。

  5. [サービス アカウント] セクションで、デフォルトの Compute Engine サービス アカウントではないサービス アカウントを選択します。最初に新しいサービス アカウントを作成することが必要な場合があります。IAM ロールと権限については、アクセス制御をご覧ください。

  6. [保存] をクリックします。新しい構成が [インスタンスの詳細] ページに表示されます。

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

Disk CMEK disabled

API のカテゴリ名: DISK_CMEK_DISABLED

この VM のディスクは顧客管理の暗号鍵(CMEK)で暗号化されていません。

CMEK を使用すると、Cloud KMS で作成、管理する鍵は、Google Cloud がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより細かく制御できます。詳細については、Cloud KMS 鍵によるリソースの保護をご覧ください。

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

  1. Cloud Console の [Compute Engine ディスク] ページに移動します。

    [Compute Engine ディスク] に移動

  2. ディスクのリストで、検出結果内に示されたディスクの名前をクリックします。

  3. [ディスクの管理] ページで、[ 削除] をクリックします。

  4. CMEK を有効にして新しいディスクを作成するには、独自の鍵で新しい Persistent Disk を暗号化するをご覧ください。CMEK を使用すると、Cloud KMS に関連する追加費用が発生します。

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

Disk CSEK disabled

API のカテゴリ名: DISK_CSEK_DISABLED

この VM のディスクは顧客指定の暗号鍵(CSEK)で暗号化されていません。重要な VM のディスクは CSEK で暗号化する必要があります。

お客様が独自の暗号鍵を提供した場合、Compute Engine はその鍵を使用して、データの暗号化と復号に使用される Google 生成の鍵を保護します。詳細については、顧客指定の暗号鍵をご覧ください。CSEK を使用すると、Cloud KMS に関連する追加費用が発生します。

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

ディスクの削除と作成

顧客指定の暗号鍵で暗号化できるのは、新しい永続ディスクだけです。既存の永続ディスクを独自の鍵で暗号化することはできません。

  1. Cloud Console の [Compute Engine ディスク] ページに移動します。

    [Compute Engine ディスク] に移動

  2. ディスクのリストで、検出結果内に示されたディスクの名前をクリックします。

  3. [ディスクの管理] ページで、[ 削除] をクリックします。

  4. CSEK を有効にして新しいディスクを作成するには、顧客指定の暗号鍵でディスクを暗号化するをご覧ください。

  5. 残りの手順を完了して検出機能を有効にします。

検出機能を有効にする

  1. Cloud Console で Security Command Center の [アセット] ページに移動します。

    [アセット] に移動

  2. [表示] の横にある [リソースの種類] をクリックします。

  3. リソースのリストで、[ディスク] を選択します。テーブルにディスクのリストが表示されます。

  4. [resourceProperties.name] で、CSEK で使用するディスクの名前の横にあるチェックボックスをオンにして、[セキュリティ マークの設定] をクリックします。

  5. ダイアログで [マークを追加] をクリックします。

  6. [キー] フィールドに「enforce_customer_supplied_disk_encryption_keys」を入力し、[] フィールドに「true」を入力します。

  7. [保存] をクリックします。

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

DNS logging disabled

API のカテゴリ名: DNS_LOGGING_DISABLED

Cloud DNS ログのモニタリングにより、VPC ネットワーク内のクライアントによってリクエストされた DNS 名が可視化されます。これらのログ内で異常なドメインがないかモニタリングし、脅威がないかを評価します。VPC ネットワークで DNS ロギングを有効にすることをおすすめします。

情報量によっては、Cloud DNS ロギングの費用が高額になる場合があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの料金: Cloud Logging をご覧ください。

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

  1. Cloud Console の [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. ネットワークのリストで、VPC ネットワークの名前をクリックします。

  3. 新しいサーバー ポリシーを作成するか(存在しない場合)、既存のポリシーを編集します。

    • ネットワークに DNS サーバー ポリシーがない場合は、次の手順を行います。

      1. [編集] をクリックします。
      2. [DNS サーバー ポリシー] フィールドで、[新しいサーバー ポリシーを作成] をクリックします。
      3. 新しいサーバー ポリシーの名前を入力します。
      4. [ログ] を [オン] に設定します。
      5. [保存] をクリックします。
    • ネットワークに DNS サーバー ポリシーがある場合は、次の手順を行います。

      1. [DNS サーバー ポリシー] フィールドで、DNS ポリシーの名前をクリックします。
      2. [ポリシーの編集] をクリックします。
      3. [ログ] を [オン] に設定します。
      4. [保存] をクリックします。

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

DNSSEC disabled

API のカテゴリ名: DNSSEC_DISABLED

Cloud DNS ゾーンでは、Domain Name System Security Extensions(DNSSEC)が無効になっています。

DNSSEC は DNS レスポンスを検証し、DNS レコードの暗号的な署名によって、DNS ハイジャックや中間者攻撃などのリスクを軽減します。DNSSEC を有効にする必要があります。詳細については、DNSSEC(DNS Security Extensions)の概要をご覧ください。

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

  1. Cloud Console で [Cloud DNS] ページに移動します。

    [Cloud DNS ネットワーク] に移動

  2. 検出結果内に示された DNS ゾーンを含む行を見つけます。

  3. その行の [DNSSEC 設定] をクリックし、[DNSSEC] で [オン] を選択します。

  4. 表示されるダイアログを確認します。問題がなければ、[有効にする] をクリックします。

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

Egress deny rule not set

API のカテゴリ名: EGRESS_DENY_RULE_NOT_SET

下り(外向き)拒否ルールがファイアウォールに設定されていません。

すべての下り(外向き)ネットワーク トラフィックを拒否するファイアウォールは、他のファイアウォールが明示的に認可する接続を除き、不要な送信ネットワーク接続を防ぎます。詳細については、下り(外向き)の場合をご覧ください。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. [ファイアウォール ルールを作成] をクリックします。

  3. ファイアウォールに名前を付け、必要に応じて説明を記載します。

  4. [トラフィックの方向] で、[下り(外向き)] を選択します。

  5. [一致したときのアクション] で [拒否] を選択します。

  6. [ターゲット] プルダウンで、[ネットワーク上のすべてのインスタンス] を選択します。

  7. [送信先フィルタ] プルダウン メニューで [IP 範囲] を選択し、[送信先 IP の範囲] ボックスに「0.0.0.0/0」と入力します。

  8. [プロトコルとポート] で [すべて拒否] を選択します。

  9. [ルールを無効にする] をクリックし、[適用] で [有効] を選択します。

  10. [作成] をクリックします。

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

Firewall not monitored

API のカテゴリ名: FIREWALL_NOT_MONITORED

ログ指標とアラートが、VPC ネットワーク ファイアウォール ルールの変更をモニタリングするように構成されていません。

ファイアウォール ルールの作成イベントと更新イベントをモニタリングすると、ネットワーク アクセスの変更についての分析が可能になり、不審なアクティビティをすばやく検出できます。詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

指標の作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動

  2. [指標を作成] をクリックします。

  3. [指標タイプ] で [カウンター] を選択します。

  4. [詳細] で、以下の手順を行います。

    1. [ログ指標の名前] を設定します。
    2. 説明を追加します。
    3. [単位] に「1」を設定します。
  5. [フィルタの選択] で、次のテキストをコピーして [フィルタの作成] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

      resource.type="gce_firewall_rule"
      AND (protoPayload.methodName:"compute.firewalls.insert"
      OR protoPayload.methodName:"compute.firewalls.patch"
      OR protoPayload.methodName:"compute.firewalls.delete")
    

  6. [指標を作成] をクリックします。確認メッセージが表示されます。

アラート ポリシーを作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動
  2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。
  3. [その他 ] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

    残りの手順は、以前のアラート インターフェースを対象としています。プレビュー版のインターフェースについては、指標ベースのアラート ポリシーの管理をご覧ください。

  4. 表示されたページで、条件のタイトルを入力し、[保存] をクリックします。
  5. [何をトラッキングしますか?] で [条件を追加] をクリックし、モニタリングするリソースと、アラートがトリガーされるタイミングを定義して、ダイアログを完了します。条件のフィールドの詳細については、条件の指定をご覧ください。
  6. 完了したら、[追加] をクリックして、[次へ] をクリックします。
  7. [通知するユーザーは?] で [通知チャンネル] プルダウンをクリックして通知方法を選択します。詳細については、通知チャンネルの管理をご覧ください。
  8. [OK] をクリックし、[次へ] をクリックします。
  9. [問題を解決する手順は?] で、[アラート名] を設定します。
  10. [保存] をクリックします。

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

Firewall rule logging disabled

API のカテゴリ名: FIREWALL_RULE_LOGGING_DISABLED

ファイアウォール ルールのロギングが無効になっています。

ファイアウォール ルール ロギングを使用すると、ファイアウォール ルールの効果を監査、検証、分析できます。これは、ネットワーク アクセスを監査する、またはネットワークが承認されていない方法で使用されていることを早期に警告する場合に有効です。ログの費用が高額になる場合があります。ファイアウォール ルールのロギングとその費用についての詳細は、ファイアウォール ルール ロギングの使用をご覧ください。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、目的のファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ログ] で [オン] を選択します。

  5. [保存] をクリックします。

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

Flow logs disabled

API のカテゴリ名: FLOW_LOGS_DISABLED

無効なフローログを持つ VPC サブネットワークがあります。

VPC フローログは、VM インスタンスによって送受信されるネットワーク フローのサンプルを記録します。これらのログは、ネットワーク モニタリング、フォレンジック、リアルタイム セキュリティ分析、および費用の最適化に使用できます。フローログとその費用についての詳細は、VPC フローログの使用をご覧ください。

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

  1. Cloud Console の [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. ネットワークのリストで、目的のネットワークの名前をクリックします。

  3. [VPC ネットワークの詳細] ページで、[サブネット] タブをクリックします。

  4. サブネットのリストで、検出結果で示されているサブネットの名前をクリックします。

  5. [サブネットの詳細] ページで、[編集] をクリックします。

  6. [フローログ] で [オン] を選択します。

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

Full API access

API のカテゴリ名: FULL_API_ACCESS

Compute Engine インスタンスは、すべての Google Cloud APIs に対する完全アクセス権を持つデフォルトのサービス アカウントを使用するように構成されています。

デフォルトのサービス アカウント スコープ(すべての Cloud APIs への完全アクセス権を許可する)で構成されたインスタンスは、IAM 権限がないオペレーションまたは API 呼び出しを行うことを、ユーザーに許可する場合があります。詳しくは、Compute Engine のデフォルトのサービス アカウントをご覧ください。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. インスタンスのリストで、検出結果内のインスタンスの名前をクリックします。

  3. 現在インスタンスが起動済みの場合は、 [停止] をクリックします。

  4. インスタンスが停止したら、 [編集] をクリックします。

  5. [サービス アカウント] のプルダウン メニューで、[Compute Engine のデフォルトのサービス アカウント] を選択します。

  6. [アクセス スコープ] セクションで、[すべての Cloud APIs への完全アクセス権を許可] が選択されていないことを確認します。

  7. [保存] をクリックします。

  8. [開始] をクリックしてインスタンスを起動します。

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

HTTP load balancer

API のカテゴリ名: HTTP_LOAD_BALANCER

Compute Engine インスタンスは、ターゲット HTTPS プロキシではなく、ターゲット HTTP プロキシを使用するように構成されているロードバランサを使用しています。

データの整合性を保護し、侵入者が通信を改ざんできないようにするには、HTTP(S) ロードバランサを構成して HTTPS トラフィックのみを許可します。詳細については、外部 HTTP(S) ロード バランシングの概要をご覧ください。

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

  1. Cloud Console の [ターゲット プロキシ] ページに移動します。

    [ターゲット プロキシ] に移動

  2. ターゲット プロキシのリストで、検出結果内のターゲット プロキシの名前をクリックします。

  3. [URL マップ] のリンクをクリックします。

  4. [編集] をクリックします。

  5. [フロントエンドの構成] をクリックします。

  6. HTTP トラフィックを許可するすべてのフロントエンドの IP とポート構成を削除し、HTTPS トラフィックを許可する新しい構成を作成します。

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

Integrity monitoring disabled

API のカテゴリ名: INTEGRITY_MONITORING_DISABLED

GKE クラスタで整合性モニタリングが無効になっています。

整合性モニタリングを使用すると、シールドされたノードの実行時の起動の整合性を Monitoring でモニタリングして検証できます。これにより、整合性の問題に対応できます。また、セキュリティの状態に問題があるノードがクラスタにデプロイされるのを防止できます。

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

ノードをプロビジョニングすると、整合性モニタリングを有効にするようにノードを更新できなくなります。整合性モニタリングを有効にした新しいノードプールを作成する必要があります。

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. 検出結果にあるクラスタの名前をクリックします。

  3. [ノードプールを追加] をクリックします。

  4. [セキュリティ] タブで [整合性モニタリングを有効にする] を有効にします。

  5. [作成] をクリックします。

  6. 既存の非準拠のノードプールから新しいノードプールにワークロードを移行するには、異なるマシンタイプへのワークロードの移行をご覧ください。

  7. ワークロードを移動したら、元の非準拠のノードプールを削除します。

    1. [Kubernetes クラスタ] ページの [ノードプール] メニューで、削除するノードプールの名前をクリックします。
    2. [ノードプールを削除] をクリックします。

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

Intranode visibility disabled

API のカテゴリ名: INTRANODE_VISIBILITY_DISABLED

GKE クラスタでノード内の可視化が無効になっています。

ノード内の可視化を有効にすると、ノード内の Pod 間トラフィックがネットワーク ファブリックに表示されます。この機能を使用すると、VPC フローロギングなどの VPC 機能を使用してノード内のトラフィックをモニタリングまたは制御できます。ログを取得するには、選択したサブネットワークで VPC フローログを有効にする必要があります。詳細については、VPC フローログの使用をご覧ください。

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

ノードをプロビジョニングすると、整合性モニタリングを有効にするようにノードを更新できなくなります。整合性モニタリングを有効にした新しいノードプールを作成する必要があります。

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. [ネットワーキング] セクションで、[ノード内の可視化] 行の編集アイコン()をクリックします。

    クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

  3. ダイアログで、[ノード内の可視化の有効化] を選択します。

  4. [変更を保存] をクリックします。

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

IP alias disabled

API のカテゴリ名: IP_ALIAS_DISABLED

GKE クラスタが無効なエイリアス IP 範囲で作成されています。

エイリアス IP 範囲を有効にすると、既知の CIDR ブロックから GKE クラスタが IP アドレスを割り振るため、クラスタのスケーラビリティが高まり、Google Cloud プロダクトやエンティティとの対話の効率も向上します。詳細については、エイリアス IP 範囲の概要をご覧ください。

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

エイリアス IP を使用するために既存のクラスタを移行できません。エイリアス IP を有効にして新しいクラスタを作成する手順は、次のとおりです。

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. [作成] をクリックします。

  3. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

  4. [高度なネットワーキングのオプション] で、[VPC ネイティブのトラフィック ルーティングを有効にする(エイリアス IP を使用)] を選択します。

  5. [作成] をクリックします。

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

IP forwarding enabled

API のカテゴリ名: IP_FORWARDING_ENABLED

Compute Engine インスタンスで IP 転送が有効になっています。

VM についてデータパケットの IP 転送を無効にすると、データの損失と情報の漏洩を防止できます。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. インスタンスのリストで、検出結果のインスタンスの名前の横にあるチェックボックスをオンにします。

  3. [削除] をクリックします。

  4. [インスタンスを作成] を選択して、新しいインスタンスを作成して、削除したインスタンスと置き換えます。

  5. IP 転送が無効になっていることを確認するには、[管理、ディスク、ネットワーク、SSH 認証鍵] をクリックして、[ネットワーキング] をクリックします。

  6. [ネットワーク インターフェース] で、 [編集] をクリックします。

  7. [IP 転送] のプルダウン メニューで、[オフ] が選択されていることを確認します。

  8. その他のインスタンス パラメータを指定し、[作成] をクリックします。詳しくは、VM インスタンスの作成と起動をご覧ください。

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

KMS key not rotated

API のカテゴリ名: KMS_KEY_NOT_ROTATED

Cloud KMS 暗号鍵にローテーションが構成されていません。

暗号鍵をローテーションすると、鍵が不正使用された場合に保護され、特定の鍵バージョンの暗号解読に使用される暗号化されたメッセージの数が制限されます。詳細については、鍵のローテーションをご覧ください。

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

  1. Cloud Console で [Cloud KMS 鍵] ページに移動します。

    [Cloud KMS 鍵] に移動

  2. 検出結果内に示されたキーリングの名前をクリックします。

  3. 検出結果内に示された鍵の名前をクリックします。

  4. [ローテーション期間を編集] をクリックします。

  5. ローテーション期間は最長 90 日間までに設定してください。

  6. [保存] をクリックします。

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

KMS project has owner

API のカテゴリ名: KMS_PROJECT_HAS_OWNER

暗号鍵を含むプロジェクトに対する roles/Owner 権限がユーザーに与えられています。詳細については、権限とロールをご覧ください。

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

  1. Cloud Console の IAM ページに移動します。

    [IAM] ページに移動

  2. 必要に応じて、検出結果のプロジェクトを選択します。

  3. オーナーのロールが割り当てられているプリンシパルごとに、次の操作を行います。

    1. [編集] をクリックします。
    2. [権限の編集] パネルで、[オーナー] ロールの横にある [削除] をクリックします。
    3. [保存] をクリックします。

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

KMS public key

API のカテゴリ名: KMS_PUBLIC_KEY

Cloud KMS 暗号鍵または Cloud KMS キーリングは一般公開されており、インターネット上の誰もがアクセスできます。詳細については、IAM と Cloud KMS の使用をご覧ください。

検出結果が暗号鍵に関連する場合、この検出結果を修正するには、次の操作を行います。

  1. Cloud Console で [暗号鍵] ページに移動します。

    暗号鍵

  2. [名前] で、Security Health Analytics の検出結果に関連する暗号鍵を含むキーリングを選択します。

  3. 読み込まれた [キーリングの詳細] ページで、暗号鍵の横にあるチェックボックスをオンにします。

  4. [情報パネル] が表示されていない場合は、[情報パネルを表示] ボタンをクリックします。

  5. 前の [ロール / プリンシパル] のフィルタ ボックスを使用して、[allUsers] と [allAuthenticatedUsers] のプリンシパルを検索し、[削除] をクリックしてプリンシパルのアクセス権を削除します。

検出結果がキーリングと関連する場合、この検出結果を修正するには、次の操作を行います。

  1. Cloud Console で [暗号鍵] ページに移動します。

    暗号鍵

  2. 検出結果のキーリングが含まれる行を見つけて、チェックボックスをオンにします。

  3. [情報パネル] が表示されていない場合は、[情報パネルを表示] ボタンをクリックします。

  4. 前の [ロール / プリンシパル] のフィルタ ボックスを使用して、[allUsers] と [allAuthenticatedUsers] のプリンシパルを検索し、[削除] をクリックしてプリンシパルのアクセス権を削除します。

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

KMS role separation

API のカテゴリ名: KMS_ROLE_SEPARATION

1 人または複数のプリンシパルに複数の Cloud KMS の権限が割り当てられています。どのアカウントにも、他の Cloud KMS 権限とともに Cloud KMS 管理者の権限を同時に持たせないことをおすすめします。詳細については、権限とロールをご覧ください。

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

  1. Cloud Console の IAM ページに移動します。

    IAM に移動

  2. 検出結果に記載されているプリンシパルごとに、次の操作を行います。

    1. [継承] 列を調べて、ロールがフォルダまたは組織リソースから継承されているかどうかを確認します。列に親リソースへのリンクが含まれている場合は、そのリンクをクリックして親リソースの [IAM] ページに移動します。
    2. プリンシパルの横にある [編集] をクリックします。
    3. 権限を削除するには、[クラウド KMS 管理者] の横にある [削除] をクリックします。プリンシパルのすべての権限を削除するには、他の権限の横にある [削除] をすべてクリックします。
  3. [保存] をクリックします。

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

Legacy authorization enabled

API のカテゴリ名: LEGACY_AUTHORIZATION_ENABLED

GKE クラスタで、以前の承認が有効になっています。

Kubernetes では、ロールベースのアクセス制御(RBAC)によって一連の権限を含むルールでロールを定義して、クラスタレベルと Namespace レベルで権限を付与できます。この機能により、ユーザーに特定のリソースへのアクセス権のみを付与することで、セキュリティが向上します。以前の属性ベースのアクセス制御(ABAC)を無効にすることを検討してください。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. Security Health Analytics の検出結果に表示されているクラスタを選択します。

  3. [編集] をクリックします。

    クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

  4. [以前の承認] プルダウン リストで、[無効] を選択します。

  5. [保存] をクリックします。

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

Legacy metadata enabled

API のカテゴリ名: LEGACY_METADATA_ENABLED

GKE クラスタで以前のメタデータが有効になっています。

Compute Engine のインスタンス メタデータ サーバーが公開する、以前の /0.1//v1beta1/ のエンドポイントは、メタデータ クエリ ヘッダーを適用しません。これは /v1/ API の機能であり、これにより潜在的な攻撃者はインスタンス メタデータを取得することがより困難になります。必要な場合を除き、こうした以前の /0.1/ API と /v1beta1/ API は無効にすることをおすすめします。

詳細については、以前のメタデータ API の無効化と移行をご覧ください。

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

以前のメタデータ API を無効にできるのは、新しいクラスタを作成するとき、または既存のクラスタに新しいノードプールを追加するときのみです。既存のクラスタを更新して以前のメタデータ API を無効にするには、異なるマシンタイプへのワークロードの移行をご覧ください。

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

Legacy network

API のカテゴリ名: LEGACY_NETWORK

以前のネットワークがプロジェクト内に存在します。

レガシー ネットワークは新しい Google Cloud セキュリティ機能の多くをサポートしないため、おすすめしません。代わりに VPC ネットワークを使用してください。詳細については、レガシー ネットワークをご覧ください。

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

  1. Cloud Console の [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. 以前のネットワークではなく、新しいネットワークを作成するには、[ネットワークを作成] をクリックします。

  3. [VPC ネットワーク] ページに戻ります。

  4. ネットワークのリストで、[legacy_network] をクリックします。

  5. [VPC ネットワークの詳細] ページで、 [VPC ネットワークの削除] をクリックします。

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

Locked retention policy not set

API のカテゴリ名: LOCKED_RETENTION_POLICY_NOT_SET

ログにロックされた保持ポリシーが設定されていません。

ロックされた保持ポリシーにより、ログが上書きされ、ログバケットが削除されることを回避できます。詳細については、保持ポリシーと保持ポリシーのロックをご覧ください。

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

  1. Cloud Console の [ストレージ ブラウザ] ページに移動します。

    Storage の [ブラウザ] に移動

  2. Security Health Analytics の検出結果に表示されているバケットを選択します。

  3. [バケットの詳細] ページで、[保持] タブをクリックします。

  4. 保持ポリシーが設定されていない場合は、[保持ポリシーの設定] をクリックします。

  5. 保持期間を入力します。

  6. [保存] をクリックします。[保持] タブに保持ポリシーが表示されます。

  7. [ロック] をクリックして、保持期間が短縮または削除されないようにします。

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

Log not exported

API のカテゴリ名: LOG_NOT_EXPORTED

リソースに適切なログシンクが構成されていません。

Cloud Logging を使用すると、システムやアプリケーションで発生している問題の根本原因を迅速に突き止められます。ただし、デフォルトでは、ほとんどのログの保持期間は 30 日間に限られます。保存期間は、すべてのログエントリのコピーをエクスポートして延長します。詳細については、ログのエクスポートの概要をご覧ください。

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

  1. Cloud Console の [ログルーター] ページに移動します。

    [ログルーター] に移動

  2. [シンクの作成] をクリックします。

  3. すべてのログをエクスポートするには、包含フィルタと除外フィルタを空白のままにします。

  4. [シンクを作成] をクリックします。

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

Master authorized networks disabled

API のカテゴリ名: MASTER_AUTHORIZED_NETWORKS_DISABLED

GKE クラスタでコントロール プレーン承認済みネットワークが有効になっていません。

コントロール プレーン承認済みネットワークでは、指定された IP アドレスからクラスタのコントロール プレーンへのアクセスをブロックすることによって、コンテナ クラスタのセキュリティが向上します。詳細については、コントロール プレーン アクセス用の承認済みネットワークの追加をご覧ください。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. Security Health Analytics の検出結果に表示されているクラスタを選択します。

  3. [編集] をクリックします。

    クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

  4. [コントロール プレーン承認済みネットワーク] プルダウン リストで、[有効] を選択します。

  5. [承認済みネットワークを追加] をクリックします。

  6. 使用する承認済みネットワークを指定します。

  7. [保存] をクリックします。

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

MFA not enforced

API のカテゴリ名: MFA_NOT_ENFORCED

組織内に多要素認証が無効になっているユーザーがいます。お客様の組織の多要素認証は 2 段階認証プロセス(2SV)です。

多要素認証を使用すると、アカウントを不正なアクセスから保護できます。多要素認証は、不正使用されているログイン認証情報から組織を保護するうえで、最も重要なツールです。詳細については、2 段階認証プロセスでビジネスを保護するをご覧ください。

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

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

    [管理コンソール] にアクセス

  2. すべての組織部門に 2 段階認証プロセスを適用します。

セキュリティ マークを使用する

専用のセキュリティ マークをアセットに追加して、検出機能がこれらのアセットのセキュリティ検出結果を生成しないようにすることもできます。

  • この検出結果が再び有効にならないようにするには、値が true のセキュリティ マーク allow_mfa_not_enforced をアセットに追加します。
  • 特定の組織部門の潜在的な違反を無視するには、value フィールドに組織部門パスのカンマ区切りリストを指定して、excluded_orgunits セキュリティ マークをアセットに追加します。例: excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA

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

Network not monitored

API のカテゴリ名: NETWORK_NOT_MONITORED

ログ指標とアラートが、VPC ネットワークの変更をモニタリングするように構成されていません。

ネットワークの設定への不適切または不正な変更を検出するには、VPC ネットワークの変更をモニタリングします。詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

指標の作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動

  2. [指標を作成] をクリックします。

  3. [指標タイプ] で [カウンター] を選択します。

  4. [詳細] で、以下の手順を行います。

    1. [ログ指標の名前] を設定します。
    2. 説明を追加します。
    3. [単位] に「1」を設定します。
  5. [フィルタの選択] で、次のテキストをコピーして [フィルタの作成] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

      resource.type="gce_network"
      AND (protoPayload.methodName:"compute.networks.insert"
      OR protoPayload.methodName:"compute.networks.patch"
      OR protoPayload.methodName:"compute.networks.delete"
      OR protoPayload.methodName:"compute.networks.removePeering"
      OR protoPayload.methodName:"compute.networks.addPeering")
    

  6. [指標を作成] をクリックします。確認メッセージが表示されます。

アラート ポリシーを作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動
  2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。
  3. [その他 ] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

    残りの手順は、以前のアラート インターフェースを対象としています。プレビュー版のインターフェースについては、指標ベースのアラート ポリシーの管理をご覧ください。

  4. 表示されたページで、条件のタイトルを入力し、[保存] をクリックします。
  5. [何をトラッキングしますか?] で [条件を追加] をクリックし、モニタリングするリソースと、アラートがトリガーされるタイミングを定義して、ダイアログを完了します。条件のフィールドの詳細については、条件の指定をご覧ください。
  6. 完了したら、[追加] をクリックして、[次へ] をクリックします。
  7. [通知するユーザーは?] で [通知チャンネル] プルダウンをクリックして通知方法を選択します。詳細については、通知チャンネルの管理をご覧ください。
  8. [OK] をクリックし、[次へ] をクリックします。
  9. [問題を解決する手順は?] で、[アラート名] を設定します。
  10. [保存] をクリックします。

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

Network policy disabled

API のカテゴリ名: NETWORK_POLICY_DISABLED

GKE クラスタでネットワーク ポリシーが無効になっています。

デフォルトでは、Pod 間通信はオープンです。オープンな通信では、ネットワーク アドレス変換の有無にかかわらず、Pod はノード間で直接接続できるようになります。NetworkPolicy リソースが接続を明示的に許可しない限り、NetworkPolicy リソースは Pod 間の接続を制限する Pod レベルのファイアウォールのようなものです。詳しくは、ネットワーク ポリシーを定義する方法をご覧ください。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. Security Health Analytics の検出結果に記載されたクラスタの名前をクリックします。

  3. [ネットワーキング] の [ネットワーク ポリシー] の行で、[編集] をクリックします。

    クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

  4. ダイアログで、[コントロール プレーンのネットワーク ポリシーの有効化] と [ノードのネットワーク ポリシーの有効化] を選択します。

  5. [変更を保存] をクリックします。

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

Nodepool boot CMEK disabled

API のカテゴリ名: NODEPOOL_BOOT_CMEK_DISABLED

このノードプール内のブートディスクは、顧客管理の暗号鍵(CMEK)で暗号化されていません。CMEK を使用すると、ノードプールのブートディスク用にデフォルトの暗号鍵を構成できます。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. クラスタのリストで、検出結果にあるクラスタの名前をクリックします。

  3. [ノード] タブをクリックします。

  4. default-pool ノードプールごとに、[削除] をクリックします。

  5. 確認のメッセージが表示されたら、[削除] をクリックします。

  6. CMEK を使用して新しいノードプールを作成するには、顧客管理の暗号鍵(CMEK)を使用するをご覧ください。CMEK を使用すると、Cloud KMS に関連する追加費用が発生します。

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

Nodepool secure boot disabled

API のカテゴリ名: NODEPOOL_SECURE_BOOT_DISABLED

GKE クラスタのセキュアブートが無効になっています。

シールドされた GKE ノードに対してセキュアブートを有効にして、ノードブート コンポーネントのデジタル署名を検証します。詳細については、セキュアブートをご覧ください。

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

ノードプールをプロビジョニングすると、セキュアブートを有効にするようにノードプールを更新することはできません。セキュアブートを有効にした新しいノードプールを作成する必要があります。

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. 検出結果にあるクラスタの名前をクリックします。

  3. [ノードプールを追加] をクリックします。

  4. [ノードプール] メニューで、次の操作を行います。

    1. 新しいノードプールの名前をクリックして、タブを展開します。
    2. [セキュリティ] を選択し、[シールド オプション] で [セキュアブートを有効にする] を選択します。
    3. [作成] をクリックします。
    4. 既存の非準拠のノードプールから新しいノードプールにワークロードを移行するには、異なるマシンタイプへのワークロードの移行をご覧ください。
    5. ワークロードを移動したら、元の非準拠のノードプールを削除します。

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

Non org IAM member

API のカテゴリ名: NON_ORG_IAM_MEMBER

組織外のユーザーにプロジェクトまたは組織の IAM 権限が付与されています。詳しくは、IAM 権限をご覧ください。

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

  1. Cloud Console の IAM ページに移動します。

    IAM に移動

  2. 組織外のユーザーの横にあるチェックボックスを選択します。

  3. [削除] をクリックします。

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

Object versioning disabled

API のカテゴリ名: OBJECT_VERSIONING_DISABLED

シンクが構成されているストレージ バケットで、オブジェクトのバージョニングが有効になっていません。

削除または上書きされたオブジェクトを取得できるようにするため、Cloud Storage にはオブジェクトのバージョニング機能があります。オブジェクトのバージョニングを有効にすると、上書きされる、または誤って削除されることがないように Cloud Storage データを保護できます。詳しくは、オブジェクトのバージョニングを有効にする方法をご覧ください。

この検出結果を修正するには、以下のように適切な値を指定して gsutil versioning set on コマンドを使用します。

    gsutil versioning set on gs://finding.assetDisplayName

finding.assetDisplayName は、関連するバケットの名前に置き換えます。

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

Open Cassandra port

API のカテゴリ名: OPEN_CASSANDRA_PORT

ファイアウォール ルールで、任意の IP アドレスから Cassandra ポートへの接続を許可すると、Cassandra サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

Cassandra サービスポートは次のとおりです。

  • TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open ciscosecure websm port

API のカテゴリ名: OPEN_CISCOSECURE_WEBSM_PORT

ファイアウォール ルールで任意の IP アドレスから CiscoSecure/WebSM ポートへの接続を許可すると、CiscoSecure/WebSM サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

CiscoSecure / WebSM のサービスポートは次のとおりです。

  • TCP - 9090

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open directory services port

API のカテゴリ名: OPEN_DIRECTORY_SERVICES_PORT

ファイアウォール ルールで任意の IP アドレスからディレクトリ ポートへの接続を許可すると、ディレクトリ サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

ディレクトリのサービスのポートは次のとおりです。

  • TCP - 445
  • UDP - 445

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open DNS port

API のカテゴリ名: OPEN_DNS_PORT

ファイアウォール ルールで任意の IP アドレスから DNS ポートへの接続を許可すと、DNS サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

DNS サービスのポートは次のとおりです。

  • TCP - 53
  • UDP - 53

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open Elasticsearch port

API のカテゴリ名: OPEN_ELASTICSEARCH_PORT

ファイアウォール ルールで任意の IP アドレスから Elasticsearch ポートへの接続を許可すると、Elasticsearch サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

Elasticsearch サービスのポートは次のとおりです。

  • TCP - 9200, 9300

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open firewall

API のカテゴリ名: OPEN_FIREWALL

すべての IP アドレス(0.0.0.0/0 など)またはすべてのポートからの接続を許可するファイアウォールのルールにより、意図しないソースからの攻撃にリソースが不必要に公開される可能性があります。このようなルールは削除するか、意図するソース IP 範囲またはポートを明示的に指定する必要があります。たとえば、一般に公開することを意図したアプリケーションの場合、許可するポートをアプリケーションに必要なポート(80、443 など)に制限することを検討してください。アプリケーションですべての IP アドレスまたはポートからの接続を許可する必要がある場合は、アセットを許可リストに追加することを検討してください。詳しくはファイアウォール ルールの更新をご覧ください。

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール ルール] ページに移動します。

    [ファイアウォール ルール] に移動

  2. Security Health Analytics の検出結果に記載されたファイアウォール ルールをクリックしてから、 [編集] をクリックします。

  3. [ソース IP の範囲] で IP 値を編集して、許可する IP の範囲を制限します。

  4. [プロトコルとポート] で [指定したプロトコルとポート] を選択し、許可するプロトコルを選択して、許可するポートを入力します。

  5. [保存] をクリックします。

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

Open FTP port

API のカテゴリ名: OPEN_FTP_PORT

どの IP アドレスでも FTP ポートに接続できるファイアウォール ルールでは、FTP サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

FTP サービスのポートは次のとおりです。

  • TCP - 21

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open group IAM member

API のカテゴリ名: OPEN_GROUP_IAM_MEMBER

組織、プロジェクト、フォルダにアクセスできる 1 つ以上のプリンシパルは、承認なしで参加可能な Google グループ アカウントです。

Google Cloud のお客様は、Google グループを使用して組織内のメンバーのロールと権限を管理し、ユーザーのコレクションにアクセス ポリシーを適用できます。ロールをメンバーに直接付与する代わりに、管理者は Google グループにロールと権限を付与し、そのメンバーを特定のグループに追加できます。グループ メンバーは、グループのすべてのロールと権限を継承します。これにより、メンバーは特定のリソースとサービスにアクセスできます。

オープンな Google グループ アカウントが IAM バインディングのプリンシパルとして使用されている場合、誰でもグループに直接的または間接的(サブグループを介して)に参加するだけで、関連するロールを継承できます。オープン グループのロールを取り消すか、こういったグループへのアクセスを制限することをおすすめします。

この検出結果を対処するには、次のいずれかの手順を行います。

IAM ポリシーからグループを削除する

  1. Cloud Console の IAM ページに移動します。

    IAM に移動

  2. 必要に応じて、検出結果のプロジェクト、フォルダ、または組織を選択します。

  3. 検出結果で特定されたオープン グループのロールを取り消します

オープン グループへのアクセスを制限する

  1. Google グループにログインします。
  2. オープン グループとそのサブグループの設定を更新して、グループに参加できるユーザーと、そのユーザーを承認する必要があるユーザーを指定します。

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

Open HTTP port

API のカテゴリ名: OPEN_HTTP_PORT

ファイアウォール ルールで任意の IP アドレスから HTTP ポートへの接続を許可すると、HTTP サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

HTTP サービスのポートは次のとおりです。

  • TCP - 80

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open LDAP port

API のカテゴリ名: OPEN_LDAP_PORT

ファイアウォール ルールで任意の IP アドレスから LDAP ポートへの接続を許可すると、LDAP サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

LDAP サービスのポートは次のとおりです。

  • TCP - 389, 636
  • UDP - 389

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open Memcached port

API のカテゴリ名: OPEN_MEMCACHED_PORT

ファイアウォール ルールで任意の IP アドレスから Memcached ポートへの接続を許可すると、Memcached サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

Memcached サービスのポートは次のとおりです。

  • TCP - 11211, 11214, 11215
  • UDP - 11211, 11214, 11215

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open MongoDB port

API のカテゴリ名: OPEN_MONGODB_PORT

ファイアウォール ルールで任意の IP アドレスから MongoDB ポートへの接続を許可すると、MongoDB サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

MongoDB サービスのポートは次のとおりです。

  • TCP - 27017, 27018, 27019

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open MySQL port

API のカテゴリ名: OPEN_MYSQL_PORT

ファイアウォール ルールで任意の IP アドレスから MySQL ポートへの接続を許可すると、MySQL サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

MySQL サービスポートは次のとおりです。

  • TCP - 3306

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open NetBIOS port

API のカテゴリ名: `OPEN_NETBIOS_PORT

ファイアウォール ルールで任意の IP アドレスから NetBIOS ポートへの接続を許可すると、NetBIOS サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

NetBIOS サービスのポートは次のとおりです。

  • TCP - 137, 138, 139
  • UDP - 137, 138, 139

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open OracleDB port

API のカテゴリ名: OPEN_ORACLEDB_PORT

任意の IP アドレスに OracleDB ポートへの接続を許可するファイアウォール ルールによって、OracleDB サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

Oracle DB サービスのポートは次のとおりです。

  • TCP - 1521, 2483, 2484
  • UDP - 2483, 2484

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open POP3 port

API のカテゴリ名: OPEN_POP3_PORT

ファイアウォール ルールで任意の IP アドレスから POP3 ポートへの接続を許可すると、攻撃者に POP3 サービスが公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

POP3 サービスのポートは次のとおりです。

  • TCP - 110

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open PostgreSQL port

API のカテゴリ名: OPEN_POSTGRESQL_PORT

ファイアウォール ルールで任意の IP アドレスから PostgreSQL ポートへの接続を許可すると、PostgreSQL サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

PostgreSQL サービスのポートは次のとおりです。

  • TCP - 5432
  • UDP - 5432

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open RDP port

API のカテゴリ名: OPEN_RDP_PORT

ファイアウォール ルールで任意の IP アドレスから RDP ポートへの接続を許可すると、RDP サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

RDP サービスのポートは次のとおりです。

  • TCP - 3389
  • UDP - 3389

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open Redis port

API のカテゴリ名: OPEN_REDIS_PORT

ファイアウォール ルールで、任意の IP アドレスから Redis ポートへの接続を許可すると、Redis サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

Redis サービスのポートは次のとおりです。

  • TCP - 6379

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open SMTP port

API のカテゴリ名: OPEN_SMTP_PORT

ファイアウォール ルールで任意の IP アドレスから SMTP ポートへの接続を許可すると、SMTP サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

SMTP サービスのポートは次のとおりです。

  • TCP - 25

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open SSH port

API のカテゴリ名: OPEN_SSH_PORT

ファイアウォール ルールで任意の IP アドレスから SSH ポートへの接続を許可すると、SSH サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

SSH サービスのポートは次のとおりです。

  • SCTP - 22
  • TCP - 22

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Open Telnet port

API のカテゴリ名: OPEN_TELNET_PORT

ファイアウォール ルールで任意の IP アドレスから Telnet ポートへの接続を許可すると、Telnet サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

Telnet サービスのポートは次のとおりです。

  • TCP - 23

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

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

  1. Cloud Console の [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

  3. [編集] をクリックします。

  4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

  5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

  6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

  7. [保存] をクリックします。

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

Org policy Confidential VM policy

API のカテゴリ名: ORG_POLICY_CONFIDENTIAL_VM_POLICY

Compute Engine リソースが constraints/compute.restrictNonConfidentialComputing 組織ポリシーを遵守していません。この組織ポリシーの制約の詳細については、組織ポリシーの制約の適用をご覧ください。

組織のこの VM で Confidential VM サービスが有効になっていることが必要です。このサービスが有効になっていない VM は、ランタイム メモリの暗号化を使用しないため、ランタイム メモリの攻撃にさらされます。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. インスタンスのリストで、検出結果内のインスタンスの名前をクリックします。

  3. VM が Confidential VM サービスを必要としない場合は、それを新しいフォルダまたはプロジェクトに移動します。

  4. VM に Confidential VM が必要な場合は、 [削除] をクリックします。

  5. Confidential VM を有効にして新しいインスタンスを作成するには、クイックスタート: Confidential VM インスタンスの作成をご覧ください。

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

Org policy location restriction

API のカテゴリ名: ORG_POLICY_LOCATION_RESTRICTION

組織のポリシーの gcp.resourceLocations 制約を使用すると、新しいリソースの作成を、選択したクラウド リージョンに制限できます。詳細については、リソース ロケーションの制限をご覧ください。

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

ORG_POLICY_LOCATION_RESTRICTION 検出機能は多くのリソースタイプをカバーしており、リソースごとに修正手順が異なります。ロケーション違反を修正するための一般的なアプローチには、次のようなものがあります。

  1. リージョン外のリソースまたはそのデータを、リージョン内のリソースにコピー、移動、またはバックアップします。リソースの移動の手順については、各サービスのドキュメントをご覧ください。
  2. 元のリージョン外のリソースまたはそのデータを削除する。

このアプローチは、すべてのリソースタイプに適用できるわけではありません。指針としては、検出結果で個別に示された推奨事項をご覧ください。

その他の考慮事項

この検出結果を修正する場合は、次の点を考慮してください。

マネージド リソース

リソースのライフサイクルは、他のリソースによって管理および制御される場合があります。たとえば、マネージド Compute Engine インスタンス グループは、インスタンス グループの自動スケーリング ポリシーに従って Compute Engine インスタンスの作成と破棄を行います。マネージド リソースとマネージング リソースがロケーション適用の対象である場合は、両方とも組織のポリシーの違反として警告される場合があります。運用の安定性を確保するため、マネージング リソースにマネージド リソースの検出結果の修正が行われる必要があります。

使用中のリソース

特定のリソースは、他のリソースによって使用されます。たとえば、実行中の Compute Engine インスタンスにアタッチされた Compute Engine ディスクは、インスタンスによって使用中とみなされます。使用中のリソースがロケーションの組織のポリシーに違反している場合は、ロケーションの違反に対処する前に、そのリソースが使用中ではないことを確認する必要があります。

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

OS login disabled

API のカテゴリ名: OS_LOGIN_DISABLED

この Compute Engine インスタンスでは OS Login が無効になっています。

OS Login により、IAM を使用した一元的な SSH 認証鍵管理ができるようになり、プロジェクト内のすべてのインスタンスにおけるメタデータ ベースの SSH 認証鍵の構成が無効になります。詳しくは、OS Login を設定および構成する方法をご覧ください。

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

  1. Cloud Console の [メタデータ] ページに移動します。

    [メタデータ] に移動

  2. [編集] をクリックし、[項目を追加] をクリックします。

  3. キーが enable-oslogin で、値が TRUE のアイテムを追加します。

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

Over privileged account

API のカテゴリ名: OVER_PRIVILEGED_ACCOUNT

GKE ノードは、Compute Engine のデフォルトのサービスノードを使用しています。このノードには、デフォルトで広範なアクセス権が付与されており、GKE クラスタを稼働するための過剰な権限を保有している可能性があります。

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

最小限の権限の Google サービス アカウントを使用するの手順に沿って操作します。

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

Over privileged scopes

API のカテゴリ名: OVER_PRIVILEGED_SCOPES

ノードのサービス アカウントに、範囲の広いアクセス スコープがあります。

アクセス スコープは、インスタンスの権限を指定するレガシーな方法です。攻撃における権限昇格の可能性を低減するには、最小限の特権サービス アカウントを作成して、GKE クラスタの稼働にはそのサービス アカウントを使用します。

この検出項目を修正するには、最小限の権限の Google サービス アカウントを使用するの手順に沿って操作してください。

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

Over privileged service account user

API のカテゴリ名: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

ユーザーに特定のサービス アカウントに対するロールではなく、プロジェクト、フォルダ、または組織レベルで iam.serviceAccountUser または iam.serviceAccountTokenCreator のロールが付与されています。

そうしたロールをプロジェクト、フォルダまたは組織のユーザーに付与すると、そのユーザーは、その範囲にある既存および今後作成されるすべてのサービス アカウントにアクセスできるようになります。その結果、意図しない権限昇格につながる可能性があります。詳細については、サービス アカウント権限をご覧ください。

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

  1. Cloud Console の IAM ページに移動します。

    [IAM] ページに移動

  2. 必要に応じて、検出結果のプロジェクト、フォルダ、または組織を選択します。

  3. roles/iam.serviceAccountUser または roles/iam.serviceAccountTokenCreator が割り当てられたプリンシパルごとに、次の操作を行います。

    1. [編集] をクリックします。
    2. [権限の編集] パネルで、ロールの横にある [削除] をクリックします。
    3. [保存] をクリックします。
  4. このガイドに沿って、1 つのサービス アカウントの権限の使用を個々のユーザーに許可します。選択したユーザーに権限の使用を許可するサービス アカウントごとで、このガイドに沿って操作を行う必要があります。

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

Owner not monitored

API のカテゴリ名: OWNER_NOT_MONITORED

ログ指標とアラートが、プロジェクト所有権の割り当て、または変更をモニタリングするように構成されていません。

IAM オーナーのロールは、プロジェクトで最高レベルの権限を持っています。リソースを保護するために、オーナーが新しく追加または削除されたときに通知を受け取るようにアラートを設定します。詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

指標の作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動

  2. [指標を作成] をクリックします。

  3. [指標タイプ] で [カウンター] を選択します。

  4. [詳細] で、以下の手順を行います。

    1. [ログ指標の名前] を設定します。
    2. 説明を追加します。
    3. [単位] に「1」を設定します。
  5. [フィルタの選択] で、次のテキストをコピーして [フィルタの作成] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

      (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
      AND (ProjectOwnership OR projectOwnerInvitee)
      OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
      AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
      OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
      AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
    

  6. [指標を作成] をクリックします。確認メッセージが表示されます。

アラート ポリシーを作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動
  2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。
  3. [その他 ] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

    残りの手順は、以前のアラート インターフェースを対象としています。プレビュー版のインターフェースについては、指標ベースのアラート ポリシーの管理をご覧ください。

  4. 表示されたページで、条件のタイトルを入力し、[保存] をクリックします。
  5. [何をトラッキングしますか?] で [条件を追加] をクリックし、モニタリングするリソースと、アラートがトリガーされるタイミングを定義して、ダイアログを完了します。条件のフィールドの詳細については、条件の指定をご覧ください。
  6. 完了したら、[追加] をクリックして、[次へ] をクリックします。
  7. [通知するユーザーは?] で [通知チャンネル] プルダウンをクリックして通知方法を選択します。詳細については、通知チャンネルの管理をご覧ください。
  8. [OK] をクリックし、[次へ] をクリックします。
  9. [問題を解決する手順は?] で、[アラート名] を設定します。
  10. [保存] をクリックします。

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

Pod security policy disabled

API のカテゴリ名: POD_SECURITY_POLICY_DISABLED

PodSecurityPolicy が GKE クラスタで無効になっています。

PodSecurityPolicy は、クラスタ上で Pod を作成および更新するリクエストを検証するアドミッション コントローラ リソースです。クラスタは、PodSecurityPolicy で定義された条件を満たさない Pod を受け入れません。

この検出結果を修正するには、PodSecurityPolicies を定義して承認し、PodSecurityPolicy コントローラを有効にします。手順については、PodSecurityPolicies の使用をご覧ください。

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

Primitive roles used

API のカテゴリ名: PRIMITIVE_ROLES_USED

IAM の基本ロール(roles/ownerroles/editorroles/viewer のいずれか)を持つユーザーがいます。これらのロールには過剰な権限が付与されるため、使用を回避する必要があります。代わりに、ロールはプロジェクトごとのみに割り当てる必要があります。

詳しくは、ロールについてをご覧ください。

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

  1. Cloud Console の [IAM ポリシー] ページに移動します。

    [IAM ポリシー] に移動

  2. 基本ロールが割り当てられているユーザーごとに、より詳細なロールの使用を検討してください。

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

Private cluster disabled

API のカテゴリ名: PRIVATE_CLUSTER_DISABLED

GKE クラスタに、無効な限定公開クラスタがあります。

限定公開クラスタのノードに割り当てられるのはプライベート IP アドレスだけです。この機能は、ノードへの送信インターネット アクセスを制限します。クラスタノードにパブリック IP アドレスがない場合、クラスタノードは検出不能であるか、インターネットに公開されません。内部ロードバランサを使用してノードにトラフィックをルーティングすることは可能です。詳細については、限定公開クラスタをご覧ください。

既存のクラスタをプライベートにすることはできません。この検出結果を修正するには、新しい限定公開クラスタを作成します。

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. [クラスタを作成] をクリックします。

  3. ナビゲーション メニューの [クラスタ] で、[ネットワーキング] を選択します。

  4. [限定公開クラスタ] のラジオボタンを選択します。

  5. [高度なネットワーキングのオプション] で、[VPC ネイティブのトラフィック ルーティングを有効にする(エイリアス IP を使用)] チェックボックスをオンにします。

  6. [作成] をクリックします。

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

Private Google access disabled

API のカテゴリ名: PRIVATE_GOOGLE_ACCESS_DISABLED

Google の公開 API にアクセスできない限定公開サブネットがあります。

限定公開の Google アクセスを使用すると、内部(プライベート)IP アドレスのみを持つ VM インスタンスが Google API とサービスのパブリック IP アドレスにアクセスできます。

詳細については、限定公開の Google アクセスの構成をご覧ください。

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

  1. Cloud Console の [VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. ネットワークのリストで、目的のネットワークの名前をクリックします。

  3. [VPC ネットワークの詳細] ページで、[サブネット] タブをクリックします。

  4. サブネットのリストで、検出結果内の Kubernetes クラスタに関連付けられているサブネットの名前をクリックします。

  5. [サブネットの詳細] ページで、[編集] をクリックします。

  6. [限定公開の Google アクセス] で [オン] を選択します。

  7. [保存] をクリックします。

  8. Google API に対してのみ外部トラフィックを送信する VM インスタンスからパブリック(外部)IP を削除するには、静的外部 IP アドレスの割り当て解除をご覧ください。

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

Public bucket ACL

API のカテゴリ名: PUBLIC_BUCKET_ACL

バケットが一般公開されており、インターネット上の誰でもアクセスできるようになっています。

詳細については、アクセス制御の概要をご覧ください。

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

  1. Cloud Console の [ストレージ ブラウザ] ページに移動します。

    Storage の [ブラウザ] に移動

  2. Security Health Analytics の検出結果に表示されているバケットを選択します。

  3. [バケットの詳細] ページで、[権限] タブをクリックします。

  4. [表示] の横の [ロール] をクリックします。

  5. [フィルタ] ボックスで、allUsersallAuthenticatedUsers を検索します。

  6. [削除] をクリックして、allUsersallAuthenticatedUsers に付与されているすべての IAM 権限を削除します。

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

Public Compute image

API のカテゴリ名: PUBLIC_COMPUTE_IMAGE

Compute Engine イメージが一般公開されており、インターネット上の誰でもアクセスできるようになっています。allUsers はインターネット上の全員を表し、allAuthenticatedUsers は Google アカウントで認証されている全員を表します。どちらも組織内のユーザーに限定されません。

Compute Engine イメージには、暗号鍵やライセンス付きソフトウェアなどの機密情報が含まれる場合があります。このような機密情報は一般公開しないでください。この Compute Engine イメージを公開する場合は、機密情報が含まれていないことを確認してください。

詳細については、アクセス制御の概要をご覧ください。

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

  1. Cloud Console の [Compute Engine イメージ] ページに移動します。

    [Compute Engine イメージ] に移動

  2. [public-image] イメージの横にあるボックスを選択し、[情報パネルを表示] をクリックします。

  3. [フィルタ] ボックスで、allUsersallAuthenticatedUsers のプリンシパルを検索します。

  4. ユーザーを削除するロールを開きます。

  5. [削除] をクリックして、そのロールからユーザーを削除します。

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

Public dataset

API のカテゴリ名: PUBLIC_DATASET

BigQuery データセットが一般公開されており、インターネット上の誰でもアクセスできるようになっています。IAM プリンシパルの allUsers はインターネット上のすべてのユーザーを表し、allAuthenticatedUsers は Google サービスにログインしているすべてのユーザーを表します。どちらでも組織内のユーザーに限定されていません。

詳細については、データセットへのアクセスの制御をご覧ください。

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

  1. Cloud Console の [BigQuery データセット] ページに移動します。

    [BigQuery データセット] に移動

  2. [共有データセット] をクリックします。

  3. [データセットの権限] パネルで、[プリンシパル検索] ボックスを使用して allUsersallAuthenticatedUsers を検索し、これらのプリンシパルのアクセス権を削除します。

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

Public IP address

API のカテゴリ名: PUBLIC_IP_ADDRESS

Compute Engine インスタンスにパブリック IP アドレスがあります。

組織の攻撃対象を減らすために、VM にパブリック IP アドレスを割り当てるのは避けてください。停止されたインスタンスは、ネットワーク インターフェースが起動時にエファメラルなパブリック IP を割り当てるように構成されている場合など、パブリック IP 検出で警告される場合があります。停止しているインスタンスのネットワーク構成に、外部アドレスが含まれていないことを確認してください。

詳細については、VM インスタンスへの安全な接続をご覧ください。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. インスタンスのリストで、検出結果のインスタンスの名前の横にあるチェックボックスをオンにします。

  3. [編集] をクリックします。

  4. [ネットワーク インターフェース] にあるインターフェースごとに、 [編集] をクリックして、[外部 IP] を [なし] に設定します。

  5. [完了] をクリックし、[保存] をクリックします。

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

Public log bucket

API のカテゴリ名: PUBLIC_LOG_BUCKET

ストレージ バケットは一般公開されており、ログシンクとして使用されています。これは、インターネット上の誰でも、このバケットに保存されているログにアクセスできることを意味します。allUsers はインターネット上の全員を表し、allAuthenticatedUsers は Google サービスにログインしている全員を表しています。どちらも組織内のユーザーに限定されていません。

詳細については、アクセス制御の概要をご覧ください。

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

  1. Cloud Console の [Cloud Storage ブラウザ] ページに移動します。

    Cloud Storage ブラウザに移動

  2. バケットのリストで、検出結果に示されているバケットの名前をクリックします。

  3. [権限] タブをクリックします。

  4. プリンシパルのリストから allUsersallAuthenticatedUsers を削除します。

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

Public SQL instance

API のカテゴリ名: PUBLIC_SQL_INSTANCE

SQL インスタンスで、許可されるネットワークとして 0.0.0.0/0 が設定されています。この状況は、許可する意図のないクライアントを含め、あらゆる IPv4 クライアントがネットワーク ファイアウォールを通過して、インスタンスへのログインを試行できることを意味します。なお、クライアントがインスタンスに正常にログインするには、有効な認証情報が必要です。

詳細については、承認済みネットワークでの承認をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. ナビゲーション パネルで [接続] をクリックします。

  5. [承認済みネットワーク] で 0.0.0.0/0 を削除し、インスタンスに接続する特定の IP アドレスまたは IP 範囲を指定します。

  6. [完了] をクリックし、[保存] をクリックします。

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

Pubsub CMEK disabled

API のカテゴリ名: PUBSUB_CMEK_DISABLED

Pub/Sub トピックが、顧客管理の暗号鍵(CMEK)で暗号化されません。

CMEK を使用すると、Cloud KMS で作成、管理する鍵は、Google がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより詳細に制御できます。

この検出結果を修正するには、既存のトピックを削除して新しいトピックを作成します。

  1. Cloud Console で Pub/Sub の [トピック] ページに移動します。

    トピックに移動

  2. 必要に応じて、Pub/Sub トピックを含むプロジェクトを選択します。

  3. 検索結果に表示されたトピックの横にあるチェックボックスをオンにして、 [削除] をクリックします。

  4. CMEK を有効にして新しい Pub/Sub トピックを作成するには、顧客管理の暗号鍵の使用をご覧ください。CMEK を使用すると、Cloud KMS に関連する追加費用が発生します。

  5. CMEK を有効化した Pub/Sub トピックに検出結果や他のデータを公開します。

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

Route not monitored

API のカテゴリ名: ROUTE_NOT_MONITORED

ログ指標とアラートが、VPC ネットワーク ルートの変更をモニタリングするように構成されていません。

Google Cloud ルートは、ネットワーク トラフィックが VM インスタンスから宛先 IP に到達する際に通過する経路を定義する宛先とホップです。ルートテーブルに対する変更をモニタリングすると、すべての VPC トラフィックが予想どおりのパスを通過するようにできます。

詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

指標の作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動

  2. [指標を作成] をクリックします。

  3. [指標タイプ] で [カウンター] を選択します。

  4. [詳細] で、以下の手順を行います。

    1. [ログ指標の名前] を設定します。
    2. 説明を追加します。
    3. [単位] に「1」を設定します。
  5. [フィルタの選択] で、次のテキストをコピーして [フィルタの作成] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

      resource.type="gce_route"
      AND (protoPayload.methodName:"compute.routes.delete"
      OR protoPayload.methodName:"compute.routes.insert")
    

  6. [指標を作成] をクリックします。確認メッセージが表示されます。

アラート ポリシーを作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動
  2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。
  3. [その他 ] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

    残りの手順は、以前のアラート インターフェースを対象としています。プレビュー版のインターフェースについては、指標ベースのアラート ポリシーの管理をご覧ください。

  4. 表示されたページで、条件のタイトルを入力し、[保存] をクリックします。
  5. [何をトラッキングしますか?] で [条件を追加] をクリックし、モニタリングするリソースと、アラートがトリガーされるタイミングを定義して、ダイアログを完了します。条件のフィールドの詳細については、条件の指定をご覧ください。
  6. 完了したら、[追加] をクリックして、[次へ] をクリックします。
  7. [通知するユーザーは?] で [通知チャンネル] プルダウンをクリックして通知方法を選択します。詳細については、通知チャンネルの管理をご覧ください。
  8. [OK] をクリックし、[次へ] をクリックします。
  9. [問題を解決する手順は?] で、[アラート名] を設定します。
  10. [保存] をクリックします。

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

Redis role used on org

API のカテゴリ名: REDIS_ROLE_USED_ON_ORG

Redis IAM ロールが組織レベルまたはフォルダレベルで割り当てられています。

次の Redis IAM ロールは、組織またはフォルダレベルでではなく、プロジェクトごとのみに割り当てる必要があります。

  • roles/redis.admin
  • roles/redis.viewer
  • roles/redis.editor

詳細については、アクセス制御と権限をご覧ください。

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

  1. Cloud Console の [IAM ポリシー] ページに移動します。

    [IAM ポリシー] に移動

  2. 検出結果に示された Redis IAM ロールを削除し、代わりに個々のプロジェクトにそれらのロールを追加します。

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

Release channel disabled

API のカテゴリ名: RELEASE_CHANNEL_DISABLED

GKE クラスタはリリース チャンネルに登録されていません。

リリース チャンネルに登録して、GKE クラスタのバージョン アップグレードを自動化します。また、バージョン管理の複雑さを軽減し、必要な機能の数と安定性のレベルを引き下げることもできます。詳細については、リリース チャンネルをご覧ください。

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

  1. Cloud Console の [Kubernetes クラスタ] ページに移動します。

    Kubernetes クラスタに移動

  2. [クラスタの基本] セクションで、[リリース チャンネル] 行の編集アイコン()をクリックします。

    クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

  3. ダイアログで [リリース チャンネル] を選択し、登録するリリース チャンネルを選択します。

    クラスタのコントロール プレーン バージョンをリリース チャンネルにアップグレードできない場合、対象のチャンネルはオプションとして無効になる可能性があります。

  4. [変更を保存] をクリックします。

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

署名に RSASHA1 が使用されている

API のカテゴリ名: RSASHA1_FOR_SIGNING

RSASHA1 が Cloud DNS ゾーンにログインする鍵に使用されている。鍵署名に使用するアルゴリズムは、堅牢である必要があります。

この検出項目を修正するには、高度な署名オプションの使用のガイドに沿って、アルゴリズムを推奨のアルゴリズムに置き換えます。

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

Service account key not rotated

API のカテゴリ名: SERVICE_ACCOUNT_KEY_NOT_ROTATED

ユーザー管理のサービス アカウント キーが 90 日以上ローテーションされていません。

一般に、ユーザー管理のサービス アカウント キーは少なくとも 90 日ごとにローテーションさせて、紛失、不正使用、盗難にあった古い鍵でデータにアクセスしないようにしてください。詳しくは、鍵の漏えいによって発生するセキュリティ リスクを軽減するためにサービス アカウント キーをローテーションするをご覧ください。

公開鍵/秘密鍵のペアを自分で生成し、ハードウェア セキュリティ モジュール(HSM)に秘密鍵を保存して、Google に公開鍵をアップロードした場合は、鍵のローテーションを 90 日ごとに行う必要はありません。その代わりに、鍵が侵害された可能性がある場合に鍵をローテーションします。

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

  1. Cloud Console の [サービス アカウント] ページに移動します。

    [サービス アカウント] に移動

  2. 必要に応じて、検出結果内で示されているプロジェクトを選択します。

  3. サービス アカウントのリストで、検索結果に記載されたサービス アカウントを見つけて、 [削除] をクリックします。続行する前に、サービス アカウントの削除が本番環境のリソースに及ぼす可能性のある影響を検討してください。

  4. 新しいサービス アカウント キーを作成し、古い鍵に置換します。詳細については、サービス アカウント キーの作成をご覧ください。

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

Service account role separation

API のカテゴリ名: SERVICE_ACCOUNT_ROLE_SEPARATION

組織内の 1 人または複数のプリンシパルに、複数のサービス アカウントの権限が割り当てられています。どのアカウントにも、他のサービス アカウントの権限とともにサービス アカウント管理者の権限を同時に付与しないでください。サービス アカウントと、サービス アカウントに使用可能なロールについては、サービス アカウントをご覧ください。

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

  1. Cloud Console の IAM ページに移動します。

    IAM に移動

  2. 検出結果に記載されているプリンシパルごとに、次の操作を行います。

    1. [継承] 列を調べて、ロールがフォルダまたは組織リソースから継承されているかどうかを確認します。列に親リソースへのリンクが含まれている場合は、そのリンクをクリックして親リソースの [IAM] ページに移動します。
    2. プリンシパルの横にある [編集] をクリックします。
    3. 権限を削除するには、[サービス アカウント管理者] の横にある [削除] をクリックします。すべてのサービス アカウントの権限を削除するには、他の権限の横にある [削除] をすべてクリックします。
  3. [保存] をクリックします。

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

Shielded VM disabled

API のカテゴリ名: SHIELDED_VM_DISABLED

この Compute Engine インスタンスで、Shielded VM が無効になっています。

Shielded VM は、ルートキットやブートキットによる攻撃を防御する一連のセキュリティ制御により強化された、Google Cloud 上の仮想マシン(VM)です。Shielded VM を使用すると、ブートローダーとファームウェアの署名と検証を確実にできるようになります。Shielded VM について理解する。

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

  1. Cloud Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] に移動

  2. Security Health Analytics の検出結果に関連するインスタンスを選択します。

  3. 読み込まれた [インスタンスの詳細] ページで、 [停止] をクリックします。

  4. インスタンスが停止したら、 [編集] をクリックします。

  5. [Shielded VM] セクションで、[vTPM をオンにする] と [整合性のモニタリングを有効にする] を切り替えて、Shielded VM を有効にします。

  6. 必要に応じて、カスタム ドライバまたは署名されていないドライバを使用しない場合に、セキュアブートも有効にします。

  7. [保存] をクリックします。新しい構成が [インスタンスの詳細] ページに表示されます。

  8. [開始] をクリックしてインスタンスを起動します。

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

SQL CMEK disabled

API のカテゴリ名: SQL_CMEK_DISABLED

SQL データベース インスタンスが顧客管理の暗号鍵(CMEK)を使用していません。

CMEK を使用すると、Cloud KMS で作成、管理する鍵は、Google がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより詳細に制御できます。詳細については、ご使用のプロダクト(Cloud SQL for MySQLCloud SQL for PostgreSQLCloud SQL for SQL Server)の CMEK の概要をご覧ください。CMEK を使用すると、Cloud KMS に関連する追加費用が発生します。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [削除] をクリックします。

  4. CMEK を有効にして新しいインスタンスを作成するには、次の手順に沿って、ご使用のプロダクト用に CMEK を構成します。

    1. Cloud SQL for MySQL
    2. Cloud SQL for PostgreSQL
    3. Cloud SQL for SQL Server

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

SQL contained database authentication

API のカテゴリ名: SQL_CONTAINED_DATABASE_AUTHENTICATION

Cloud SQL for SQL Server データベース インスタンスで、含まれているデータベース認証のデータベース フラグがオフに設定されていません。

包含データベース認証フラグは、包含データベースを作成できるかどうか、また包含データベースをデータベース エンジンに接続できるかどうかを制御します。包含データベースには、データベースの定義に必要なすべてのデータベース設定とメタデータが含まれており、データベースがインストールされているデータベース エンジンのインスタンスに対する構成の依存関係はありません。

次の理由により、このフラグを有効にすることはおすすめしません。

  • ユーザーは、データベース エンジン レベルで、認証なしでデータベースに接続できる。
  • データベースをデータベース エンジンから分離すると、データベースを SQL Server の別のインスタンスに移動できる。

包含データベースには固有の脅威があり、SQL Server データベース エンジンの管理者はそうした脅威を把握して対処する必要があります。ほとんどの脅威は、USER WITH PASSWORD 認証プロセスで発生します。このプロセスでは、認証の境界線が Database Engine レベルからデータベース レベルに移動します。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、contained database authentication データベース フラグを [オフ] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL cross DB ownership chaining

API のカテゴリ名: SQL_CROSS_DB_OWNERSHIP_CHAINING

Cloud SQL for SQL Server データベース インスタンスで、cross db ownership chaining のデータベース フラグがオフに設定されていません。

cross db ownership chaining フラグを使用すると、データベース レベルでデータベース間の所有権チェーンを管理できるようになります。また、すべてのデータベース ステートメントに対して、データベース間の所有権チェーンを許可します。

SQL Server インスタンスでホストされているすべてのデータベースが、データベース間の所有権チェーンに参加しており、この設定のセキュリティへの影響を把握している場合を除き、このフラグを有効にすることはおすすめしません。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、cross db ownership chaining データベース フラグを [オフ] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL external scripts enabled

API のカテゴリ名: SQL_EXTERNAL_SCRIPTS_ENABLED

Cloud SQL for SQL Server データベース インスタンスで、external scripts enabled データベース フラグが [オフ] に設定されていません。

この設定を有効にすると、特定のリモート言語の拡張機能でスクリプトの実行が有効になります。この機能はシステムのセキュリティに悪影響を与える可能性があるため、無効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、external scripts enabled データベース フラグを [オフ] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL instance not monitored

API のカテゴリ名: SQL_INSTANCE_NOT_MONITORED

ログ指標とアラートが、Cloud SQL インスタンスの構成の変更をモニタリングするように構成されていません。

SQL インスタンス オプションの構成に誤りがあると、セキュリティ リスクの原因になる可能性があります。自動バックアップと高可用性オプションを無効にすると、ビジネスの継続性に影響を与えることがあり、承認済みネットワークを制限しなければ、信頼できないネットワークへの露出が増加する可能性があります。SQL インスタンスの構成の変更をモニタリングすると、構成ミスの検出と修正にかかる時間を短縮できます。

詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量と費用については、Google Cloud のオペレーション スイートの費用の最適化をご覧ください。

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

指標の作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動

  2. [指標を作成] をクリックします。

  3. [指標タイプ] で [カウンター] を選択します。

  4. [詳細] で、以下の手順を行います。

    1. [ログ指標の名前] を設定します。
    2. 説明を追加します。
    3. [単位] に「1」を設定します。
  5. [フィルタの選択] で、次のテキストをコピーして [フィルタの作成] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

      protoPayload.methodName="cloudsql.instances.update"
      OR protoPayload.methodName="cloudsql.instances.create"
      OR protoPayload.methodName="cloudsql.instances.delete"
    

  6. [指標を作成] をクリックします。確認メッセージが表示されます。

アラート ポリシーを作成

  1. Cloud Console の [ログベースの指標] ページに移動します。

    [ログベースの指標] に移動
  2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。
  3. [その他 ] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

    残りの手順は、以前のアラート インターフェースを対象としています。プレビュー版のインターフェースについては、指標ベースのアラート ポリシーの管理をご覧ください。

  4. 表示されたページで、条件のタイトルを入力し、[保存] をクリックします。
  5. [何をトラッキングしますか?] で [条件を追加] をクリックし、モニタリングするリソースと、アラートがトリガーされるタイミングを定義して、ダイアログを完了します。条件のフィールドの詳細については、条件の指定をご覧ください。
  6. 完了したら、[追加] をクリックして、[次へ] をクリックします。
  7. [通知するユーザーは?] で [通知チャンネル] プルダウンをクリックして通知方法を選択します。詳細については、通知チャンネルの管理をご覧ください。
  8. [OK] をクリックし、[次へ] をクリックします。
  9. [問題を解決する手順は?] で、[アラート名] を設定します。
  10. [保存] をクリックします。

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

SQL local infile

API のカテゴリ名: SQL_LOCAL_INFILE

Cloud SQL for MySQL データベース インスタンスで、local_infile のデータベース フラグがオフに設定されていません。local_infile フラグに関連するセキュリティの問題があるため、これを無効にする必要があります。詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、local_infile データベース フラグを [オフ] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log checkpoints disabled

API のカテゴリ名: SQL_LOG_CHECKPOINTS_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_checkpoints のデータベース フラグがオンに設定されていません。

log_checkpoints を有効にすると、チェックポイントと再起動のポイントがサーバーログに記録されます。書き込まれたバッファの数やバッファの書き込みにかかった時間など、一部の統計情報はログメッセージに含まれます。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_checkpoints データベース フラグを [オン] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log connections disabled

API のカテゴリ名: SQL_LOG_CONNECTIONS_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_connections のデータベース フラグがオンに設定されていません。

log_connections 設定を有効にすると、サーバーへの接続の試行とクライアント認証の完了がログに記録されます。これらのログは、問題のトラブルシューティングや、サーバーへの異常な接続試行を確認する際に有用です。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_connections データベース フラグを [オン] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log disconnections disabled

API のカテゴリ名: SQL_LOG_DISCONNECTIONS_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_disconnections のデータベース フラグがオンに設定されていません。

log_disconnections 設定を有効にすると、各セッションの終了時にログエントリが作成されます。これらのログは、問題のトラブルシューティングや、一定期間での異常なアクティビティの確認を行う際に有用です。詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、[log_disconnections] データベース フラグを [オン] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log duration disabled

API のカテゴリ名: SQL_LOG_DURATION_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_duration データベース フラグが [オン] に設定されていません。

log_duration が有効になっている場合、完了した各ステートメントの実行時刻と実行時間がログに記録されます。クエリの実行時間をモニタリングすることは、遅いクエリの特定やデータベースの問題のトラブルシューティングにおいて非常に重要です。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_duration データベース フラグを [オン] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log error verbosity

API のカテゴリ名: SQL_LOG_ERROR_VERBOSITY

Cloud SQL for PostgreSQL データベース インスタンスで、log_error_verbosity データベース フラグが default かそれよりも厳格に設定されていません。

log_error_verbosity フラグは、ログに記録されるメッセージの詳細情報の量を制御します。詳細度が高いほど、より詳細な情報がメッセージに記録されます。このフラグを default かそれよりも厳格に設定することをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_error_verbosity データベース フラグを default かそれよりも厳格に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log lock waits disabled

API のカテゴリ名: SQL_LOG_LOCK_WAITS_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_lock_waits のデータベース フラグがオンに設定されていません。

log_lock_waits 設定を有効にすると、ロックを取得する際にセッションの待機時間が deadlock_timeout の設定値よりも長くなるとログエントリが作成されます。このログは、ロック待機がパフォーマンス低下の原因であるかどうかを判断する際に有用です。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、[log_lock_waits] データベース フラグに値「オン」を設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log min duration statement enabled

API のカテゴリ名: SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_min_duration_statement のデータベース フラグが「-1」に設定されていません。

log_min_duration_statement フラグを指定すると、指定された時間よりも長く実行される SQL ステートメントがログに記録されます。SQL ステートメントには、ログへの記録を回避する必要がある機密情報が含まれている可能性があるため、この設定を無効にすることを検討してください。詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_min_duration_statement データベース フラグに値 -1 を設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log min error statement

API のカテゴリ名: SQL_LOG_MIN_ERROR_STATEMENT

Cloud SQL for PostgreSQL データベース インスタンスで、log_min_error_statement データベース フラグが適切に設定されていません。

log_min_error_statement フラグは、エラー状態の原因である SQL ステートメントをサーバーログに記録するかどうかを制御します。指定した重要度以上の SQL ステートメントは、エラー ステートメントのメッセージとともにログに記録されます。重要度が高いほど、記録されるメッセージは少なくなります。

log_min_error_statement が正しい値に設定されていない場合は、メッセージがエラー メッセージとして分類されない可能性があります。重要度の設定が低すぎると、メッセージの数が増え、実際のエラーを見つけるのが困難になります。重要度の設定が高すぎると、実際のエラーのエラー メッセージが記録されない可能性があります。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、組織のロギング ポリシーに応じて、log_min_error_statement データベース フラグに次のいずれかの推奨値を設定します。

    • debug5
    • debug4
    • debug3
    • debug2
    • debug1
    • info
    • notice
    • warning
    • error
  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log min error statement severity

API のカテゴリ名: SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY

Cloud SQL for PostgreSQL データベース インスタンスで、log_min_error_statement データベース フラグが適切に設定されていません。

log_min_error_statement フラグは、エラー状態の原因である SQL ステートメントをサーバーログに記録するかどうかを制御します。指定した重要度以上の SQL ステートメントは、エラー ステートメントのメッセージとともにログに記録されます。重要度が高いほど、記録されるメッセージは少なくなります。

log_min_error_statement が正しい値に設定されていない場合は、メッセージがエラー メッセージとして分類されない可能性があります。重要度の設定が低すぎると、メッセージの数が増え、実際のエラーを見つけるのが困難になります。重要度が高すぎる(厳しくなりすぎる)と、実際のエラーのエラー メッセージが記録されない可能性があります。

このフラグを error かそれよりも厳格に設定することをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、組織のロギング ポリシーに応じて、log_min_error_statement データベース フラグに次のいずれかの推奨値を設定します。

    • error
    • log
    • fatal
    • panic
  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log min messages

API のカテゴリ名: SQL_LOG_MIN_MESSAGES

Cloud SQL for PostgreSQL データベース インスタンスで、log_min_messages データベース フラグが warning に設定されていません。

log_min_messages フラグは、サーバーログに記録されるメッセージ レベルを制御します。重要度が高いほど、記録されるメッセージは少なくなります。このフラグを warning に設定することをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_min_messages データベース フラグを warning に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log executor stats enabled

API のカテゴリ名: SQL_LOG_EXECUTOR_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_executor_status データベース フラグが [オフ] に設定されていません。

log_executor_status フラグを有効にすると、各クエリの PostgreSQL ログにエグゼキュータのパフォーマンス統計が記載されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_executor_status データベース フラグを [オフ] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log hostname enabled

API のカテゴリ名: SQL_LOG_HOSTNAME_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_hostname データベース フラグが [オフ] に設定されていません。

log_hostname フラグを有効にすると、接続しているホストのホスト名が記録されます。デフォルトでは、接続のログ メッセージには IP アドレスのみが表示されます。この設定はトラブルシューティングに役立ちます。ただし、ログに記録される各ステートメントで、IP アドレスをホスト名に変換するために DNS 解決が必要なため、サーバーのパフォーマンスにオーバーヘッドが発生する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_hostname データベース フラグを [オフ] に設定してください。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log parser stats enabled

API のカテゴリ名: SQL_LOG_PARSER_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_parser_stats データベース フラグが [オフ] に設定されていません。

log_parser_stats フラグを有効にすると、各クエリの PostgreSQL ログにパーサー パフォーマンス統計が記録されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_parser_stats データベース フラグを [オフ] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log planner stats enabled

API のカテゴリ名: SQL_LOG_PLANNER_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_planner_stats データベース フラグが [オフ] に設定されていません。

log_planner_stats フラグを有効にすると、PostgreSQL プランナーのパフォーマンス統計をロギングするための粗分析のプロファイリング メソッドが使用されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_planner_stats データベース フラグを [オフ] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log statement

API のカテゴリ名: SQL_LOG_STATEMENT

Cloud SQL for PostgreSQL データベース インスタンスで、log_statement データベース フラグが Ddl に設定されていません。

このフラグの値により、ログに記録される SQL ステートメントを制御できます。ロギングによって、運用上の問題のトラブルシューティングとフォレンジック分析が可能になります。このフラグが正しい値に設定されていないと、関連する情報がスキップされるか、多くのメッセージで非表示になる可能性があります。組織のロギング ポリシーで別途指示がない限り、値 Ddl(すべてのデータ定義ステートメント)をおすすめします。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_statement データベース フラグを Ddl に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log statement stats enabled

API のカテゴリ名: SQL_LOG_STATEMENT_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_statement_stats データベース フラグが [オフ] に設定されていません。

log_statement_stats フラグを有効にすると、各クエリの PostgreSQL ログにエンドツーエンドのパフォーマンス統計が記録されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_statement_stats データベース フラグを [オフ] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL log temp files

API のカテゴリ名: SQL_LOG_TEMP_FILES

Cloud SQL for PostgreSQL データベース インスタンスで、log_temp_files のデータベース フラグが「0」に設定されていません。

一時ファイルを、並べ替え、ハッシュ、一時的なクエリ結果のために作成できます。log_temp_files フラグを 0 に設定すると、すべての一時ファイルの情報がログに記録されます。一時ファイルをすべてログに記録することは、潜在的なパフォーマンスの問題を特定する際に有効です。詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、log_temp_files データベース フラグを値 0 に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL no root password

API のカテゴリ名: SQL_NO_ROOT_PASSWORD

MySQL データベース インスタンスの root アカウントのパスワードが設定されていません。MySQL データベース インスタンスにパスワードを追加する必要があります。詳細については、MySQL ユーザーをご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. 読み込まれた [インスタンスの詳細] ページで、[ユーザー] タブを選択します。

  4. root ユーザーの横にある [その他] をクリックしてから、[パスワードを変更] を選択します。

  5. 新しい強力なパスワードを入力してから [OK] をクリックします。

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

SQL public IP

API のカテゴリ名: SQL_PUBLIC_IP

Cloud SQL データベースに、パブリック IP アドレスがあります。

組織の攻撃対象を軽減するために、Cloud SQL データベースにはパブリック IP アドレスを含めないでください。プライベート IP アドレスを使用すると、ネットワーク セキュリティを高め、アプリケーションのレイテンシを低減できます。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [接続] タブで、[パブリック IP] チェックボックスをオフにします。

  4. インスタンスでまだプライベート IP を使用するように構成されていない場合は、既存のインスタンスにプライベート IP を構成するをご覧ください。

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

SQL remote access enabled

API のカテゴリ名: SQL_REMOTE_ACCESS_ENABLED

Cloud SQL for SQL Server データベース インスタンスで、remote access データベース フラグが [オフ] に設定されていません。

有効にすると、リモート サーバーからローカル ストアド プロシージャを実行する権限またはローカル サーバーからリモート ストアド プロシージャを実行する権限が付与されます。この機能が悪用されて、クエリ処理をターゲットにオフロードすることにより、リモート サーバーに対するサービス拒否(DoS)攻撃が開始される恐れがあります。不正使用を防ぐため、この設定を無効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [フラグ] セクションで、[remote access] を [オフ] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL skip show database disabled

API のカテゴリ名: SQL_SKIP_SHOW_DATABASE_DISABLED

Cloud SQL for MySQL データベース インスタンスで、skip_show_database データベース フラグが [オン] に設定されていません。

このフラグをオンにすると、SHOW DATABASES 権限のないユーザーによる SHOW DATABASES ステートメントの使用を防止できます。この設定では、明示的な権限のないユーザーは、他のユーザーに属するデータベースを表示できません。このフラグを有効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [フラグ] セクションで、skip_show_database を [オン] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL trace flag 3625

API のカテゴリ名: SQL_TRACE_FLAG_3625

Cloud SQL for SQL Server データベース インスタンスで、3625(トレースフラグ)データベース フラグが [オン] に設定されていません。

このフラグは、一部のエラー メッセージのパラメータをアスタリスク(******)でマスクすることで、sysadmin 固定サーバーロールのメンバーではないユーザーに返される情報の量を制限します。機密情報の漏洩を防ぐため、このフラグを有効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、[3625] を [オン] に設定します。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL user connections configured

API のカテゴリ名: SQL_USER_CONNECTIONS_CONFIGURED

Cloud SQL for SQL Server データベース インスタンスで、user connections データベース フラグが構成されています。

[user connections] オプションは、SQL Server のインスタンスで許可される同時ユーザー接続の最大数を指定します。これは動的な(自己構成型の)オプションであるため、SQL Server は、必要に応じてユーザー接続の最大数を許容値まで自動的に調整します。デフォルト値は 0 です。つまり、最大 32,767 のユーザー接続が許可されます。このため、user connections データベース フラグを構成することはおすすめしません。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

  3. [編集] をクリックします。

  4. [データベース フラグ] セクションで、[user connections] の横にある [削除] をクリックします。

  5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

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

SQL user options configured

API のカテゴリ名: SQL_USER_OPTIONS_CONFIGURED

Cloud SQL for SQL Server データベース インスタンスで、user options データベース フラグが構成されています。

この設定により、すべてのユーザーの SET オプションのグローバル デフォルト値がオーバーライドされます。ユーザーとアプリケーションは、デフォルトのデータベース SET オプションが使用されていることを前提としている場合があるため、user options を設定すると、予期しない結果が生じる可能性があります。このため、user options データベース フラグを構成することはおすすめしません。

詳細については、データベース フラグの構成をご覧ください。

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

  1. Cloud Console で [Cloud SQL インスタンス] ページに移