セキュリティ状況の分析の検出項目を修正する

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

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

Security Health Analytics の修正

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

CIS ベンチマークにマッピングされている検出結果の種類については、特に明記されていない限り、Center for Internet Security（CIS）の修正ガイダンスが適用されます。詳細については、検出機能とコンプライアンスをご覧ください。

修復後の検出結果の無効化

脆弱性または構成ミスの検出結果を修正した後、Security Health Analytics は次に検出結果をスキャンするときに、検出結果の状態を自動的に INACTIVE に設定します。Security Health Analytics で修正された検出結果を INACTIVE に設定するのに要する時間は、検出結果が修正された日時と、検出結果を検出するスキャンのスケジュールによって異なります。

Security Health Analytics では、検出結果の影響を受けたリソースが削除されたことがスキャンによって検出されると、検出結果の状態が INACTIVE に設定されます。 Security Health Analytics でリソースの削除が検出されるのを待つ間に、削除されたリソースの検出結果を表示から削除する場合は、検出結果をミュートできます。検出結果をミュートするには、Security Command Center で検出結果をミュートするをご覧ください。

ミュートを使用して、既存のリソースの修正済みの検出結果を非表示にしないでください。問題が再発し、Security Health Analytics で検出結果の ACTIVE 状態が復元された場合、ミュートされた検出結果が NOT mute="MUTED" を指定する検索クエリ（デフォルトの検索クエリなど）から除外されるため、最有効化された検出結果が表示されないことがあります。

スキャン間隔の詳細については、Security Health Analytics のスキャンタイプをご覧ください。

Access Transparency disabled

API のカテゴリ名: ACCESS_TRANSPARENCY_DISABLED

アクセスの透明性では、Google Cloud の従業員が組織内のプロジェクトにアクセスしてサポートを提供した時間が記録されます。アクセスの透明性を有効にして、Google Cloud の従業員がお客様の情報にアクセスした日時と理由を記録します。詳細については、アクセスの透明性をご覧ください。

プロジェクトでアクセスの透明性を有効にするには、プロジェクトを請求先アカウントに関連付ける必要があります。

必要なロール

このタスクの実行に必要な権限を取得するには、組織レベルでアクセスの透明性管理者（roles/axt.admin）の IAM ロールを付与するよう管理者に依頼してください。ロールの付与の詳細については、アクセスの管理をご覧ください。

この事前定義ロールには、このタスクの実行に必要な権限（axt.labels.get と axt.labels.set）が含まれています。カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

修正手順

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

1. 組織レベルの権限を確認します。

   1. Google Cloud コンソールで [Identity and Access Management] ページに移動します。

      [Identity and Access Management] に移動

   2. プロンプトが表示されたら、セレクタ メニューで Google Cloud 組織を選択します。

2. セレクタ メニューを使用して、組織内の Google Cloud プロジェクトを選択します。

   Google Cloud プロジェクト ページではアクセスの透明性が構成されていますが、アクセスの透明性は組織全体に対して有効にされます。

3. [IAM と管理] > [設定] ページに移動します。

4. [アクセスの透明性を有効化する] をクリックします。

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

AlloyDB auto backup disabled

API のカテゴリ名: ALLOYDB_AUTO_BACKUP_DISABLED

AlloyDB for PostgreSQL クラスタで自動バックアップが有効になっていません。

データの損失を防止するには、クラスタの自動バックアップを有効にします。詳細については、追加の自動バックアップを構成するをご覧ください。

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

1. Google Cloud コンソールで AlloyDB for PostgreSQL クラスタのページに移動します。

   AlloyDB for PostgreSQL クラスタに移動する

2. [リソース名] 列でクラスタをクリックします。

3. [データ保護] をクリックします。

4. [自動バックアップ ポリシー] セクションで、[自動バックアップ] 行の [編集] をクリックします。

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

6. [更新] をクリックします。

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

AlloyDB backups disabled

API のカテゴリ名: ALLOYDB_BACKUPS_DISABLED

AlloyDB for PostgreSQL クラスタで自動バックアップと継続バックアップのどちらも有効になっていません。

データの損失を防止するには、クラスタの自動バックアップまたは継続的なバックアップを有効にします。詳細については、追加のバックアップを構成するをご覧ください。

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

1. Google Cloud コンソールで AlloyDB for PostgreSQL クラスタのページに移動します。

   AlloyDB for PostgreSQL クラスタに移動する

2. [リソース名] 列で、検出結果で識別されたクラスタの名前をクリックします。

3. [データ保護] をクリックします。

4. バックアップ ポリシーを設定します。

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

AlloyDB CMEK disabled

API のカテゴリ名: ALLOYDB_CMEK_DISABLED

AlloyDB クラスタが顧客管理の暗号鍵（CMEK）を使用していません。

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

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

1. Google Cloud コンソールで AlloyDB for PostgreSQL クラスタのページに移動します。

   AlloyDB for PostgreSQL クラスタに移動する

2. [リソース名] 列で、検出結果で識別されたクラスタの名前をクリックします。

3. [Create Backup] をクリックします。 バックアップ ID を設定します。

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

5. [バックアップ/復元] セクションで、選択した [バックアップ ID] エントリの横にある [復元] をクリックします。

6. 新しいクラスタ ID とネットワークを設定します。

7. [Advanced Encryption Options] をクリックします。新しいクラスタを暗号化する CMEK を選択します。

8. [復元] をクリックします。

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

AlloyDB log min error statement severity

API のカテゴリ名: ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY

AlloyDB for PostgreSQL インスタンスで、log_min_error_statement データベース フラグが error または推奨値に設定されていません。

log_min_error_statement フラグは、エラー状態の原因である SQL ステートメントをサーバーログに記録するかどうかを制御します。指定した重要度以上の SQL ステートメントがログに記録されます。重要度の設定を高くするほど、記録されるメッセージは少なくなります。重大度が高すぎると、エラー メッセージがログに記録されない場合があります。

詳細については、データベース フラグの構成をご覧ください。

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

1. Google Cloud コンソールで AlloyDB for PostgreSQL クラスタのページに移動します。

   AlloyDB for PostgreSQL クラスタに移動する

2. [リソース名] 列でクラスタをクリックします。

3. [クラスタ内のインスタンス] セクションで、インスタンスの [編集] をクリックします。

4. [Advanced Configuration Options] をクリックします。

5. [フラグ] セクションで、組織のロギング ポリシーに応じて、log_min_error_statement データベース フラグに次のいずれかの推奨値を設定します。

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

6. [Update Instance] をクリックします。

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

AlloyDB log min messages

API のカテゴリ名: ALLOYDB_LOG_MIN_MESSAGES

AlloyDB for PostgreSQL インスタンスで、log_min_messages データベース フラグが warning 以上に設定されていません。

log_min_messages フラグは、サーバーログに記録されるメッセージ レベルを制御します。重要度が高いほど、記録されるメッセージは少なくなります。しきい値を低く設定しすぎると、ログのストレージ サイズと長さが増加し、実際のエラーを見つけるのが困難になります。

詳細については、データベース フラグの構成をご覧ください。

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

1. Google Cloud コンソールで AlloyDB for PostgreSQL クラスタのページに移動します。

   AlloyDB for PostgreSQL クラスタに移動する

2. [リソース名] 列でクラスタをクリックします。

3. [クラスタ内のインスタンス] セクションで、インスタンスの [編集] をクリックします。

4. [Advanced Configuration Options] をクリックします。

5. [フラグ] セクションで、組織のロギング ポリシーに応じて、log_min_messages データベース フラグに次のいずれかの推奨値を設定します。

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

6. [Update Instance] をクリックします。

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

AlloyDB log error verbosity

API のカテゴリ名: ALLOYDB_LOG_ERROR_VERBOSITY

AlloyDB for PostgreSQL インスタンスで、log_error_verbosity データベース フラグが default または制限の少ない別の値に設定されていません。

log_error_verbosity フラグは、ログに記録されるメッセージの詳細情報の量を制御します。詳細度が高いほど、より詳細な情報がメッセージに記録されます。このフラグを default または制限の少ない別の値に設定することをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

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

1. Google Cloud コンソールで AlloyDB for PostgreSQL クラスタのページに移動します。

   AlloyDB for PostgreSQL クラスタに移動する

2. [リソース名] 列でクラスタをクリックします。

3. [クラスタ内のインスタンス] セクションで、インスタンスの [編集] をクリックします。

4. [Advanced Configuration Options] をクリックします。

5. [フラグ] セクションで、組織のロギング ポリシーに応じて、log_error_verbosity データベース フラグに次のいずれかの推奨値を設定します。

   • default
   • verbose

6. [Update Instance] をクリックします。

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

AlloyDB Public IP

API のカテゴリ名: ALLOYDB_PUBLIC_IP

AlloyDB for PostgreSQL データベース インスタンスにはパブリック IP アドレスがあります。

組織の攻撃対象を減らすには、パブリック IP アドレスではなくプライベート IP アドレスを使用します。プライベート IP アドレスを使用すると、ネットワーク セキュリティを高め、アプリケーションのレイテンシを低減できます。

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

1. Google Cloud コンソールで AlloyDB for PostgreSQL クラスタのページに移動します。

   AlloyDB for PostgreSQL クラスタに移動する

2. [リソース名] 列で、検出結果で識別されたクラスタの名前をクリックします。

3. [クラスタ内のインスタンス] セクションで、インスタンスの [編集] をクリックします。

4. [接続] セクションで、[パブリック IP を有効にする] チェックボックスをオフにします。

5. [Update Instance] をクリックします。

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

AlloyDB SSL not enforced

API のカテゴリ名: ALLOYDB_SSL_NOT_ENFORCED

AlloyDB for PostgreSQL データベース インスタンスが、すべての受信接続に SSL の使用を必要としていない。

暗号化されていない通信での転送中の機密データの漏洩を回避するために、AlloyDB データベース インスタンスへのすべての着信接続で SSL を使用する必要があります。 詳しくは、SSL / TLS の構成をご覧ください。

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

1. Google Cloud コンソールで AlloyDB for PostgreSQL クラスタのページに移動します。

   AlloyDB for PostgreSQL クラスタに移動する

2. [リソース名] 列で、検出結果で識別されたクラスタの名前をクリックします。

3. [クラスタ内のインスタンス] セクションで、インスタンスの [編集] をクリックします。

4. [ネットワーク セキュリティ] セクションで、[SSL 暗号化が必要] ボックスをクリックします。

5. [Update Instance] をクリックします。

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

Admin service account

API のカテゴリ名: ADMIN_SERVICE_ACCOUNT

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

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

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

   [IAM ポリシー] に移動

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

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

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

Alpha cluster enabled

API のカテゴリ名: ALPHA_CLUSTER_ENABLED

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

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

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

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

API key APIs unrestricted

API のカテゴリ名: API_KEY_APIS_UNRESTRICTED

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

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

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

1. Google Cloud コンソールで [暗号鍵] ページに移動します。

   [API キー] に移動

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

   1. [API キー] セクションで、API を制限する必要がある API キーの行で、more_vert [操作] をクリックします。
   2. 操作メニューから [API キー編集] をクリックします。[API キーを編集] ページが開きます。
   3. [API の制限] で [キーを制限] を選択します。[Select APIs] プルダウン メニューが表示されます。
   4. [API を選択] プルダウン リストで、許可する API を選択します。
   5. [保存] をクリックします。設定が有効になるまで、最長で 5 分かかる場合があります。

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

API key apps unrestricted

API のカテゴリ名: API_KEY_APPS_UNRESTRICTED

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

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

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

1. Google Cloud コンソールで [暗号鍵] ページに移動します。

   [API キー] に移動

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

   1. [API キー] セクションで、アプリケーションを制限する必要がある API キーの行で、more_vert [操作] をクリックします。
   2. 操作メニューから [API キー編集] をクリックします。[API キーを編集] ページが開きます。
   3. [API キーを編集] ページの [アプリケーションの制限] で、制限カテゴリを選択します。アプリケーションの制限はキーごとに 1 つ設定できます。
   4. 制限を選択すると表示される [項目を追加] フィールドで、[項目を追加] をクリックして、アプリケーションのニーズに基づいて制限を追加します。
   5. アイテムの追加が完了したら、[完了] をクリックします。
   6. [保存] をクリックします。

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

API key exists

API のカテゴリ名: API_KEY_EXISTS

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

API キーは、暗号化されたシンプルな文字列であり、誰でも容易に検出して使用できるため、他の認証方法よりも安全性が低くなります。API キーは、キーが格納されているデバイス上で取得でき、ブラウザなどで誰でも参照できます。また、API キーは、リクエストを行っているユーザーやアプリケーションの特定も行いません。代わりに、サービス アカウントまたはユーザー アカウントで標準の認証フローを使用することもできます。

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

1. アプリケーションが代替形式の認証を使用して構成されていることを確認してください。

2. Google Cloud コンソールで [API の 認証情報] ページに移動します。

   API の認証情報に移動

3. 削除する API キーの行にある [API キー] セクションで、more_vert [操作] をクリックします。

4. [操作] メニューから [API キーを削除] をクリックします。

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

API key not rotated

API のカテゴリ名: API_KEY_NOT_ROTATED

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

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

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

1. Google Cloud コンソールで [暗号鍵] ページに移動します。

   [API キー] に移動

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

   1. ローテーションが必要な API キーの行にある [API キー] セクションで、more_vert [操作] をクリックします。
   2. 操作メニューから [API キー編集] をクリックします。[API キーを編集] ページが開きます。
   3. [API キーを編集] ページで、[作成日] フィールドの日付が 90 日以上経過している場合は、[refresh キーを再生成] をクリックします。新しいキーが生成されます。
   4. [保存] をクリックします。
   5. アプリケーションを中断なく動作させるには、新しい API キーを使用するようにアプリケーションを更新してください。古い API キーは 24 時間後に完全に無効となります。

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

Audit config not monitored

API のカテゴリ名: AUDIT_CONFIG_NOT_MONITORED

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

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

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

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

指標を作成

1. Google Cloud コンソールで [ログベースの指標] ページに移動します。

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

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

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

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

   1. [ログ指標の名前] を設定します。
   2. 説明を追加します。
   3. [単位] に「1」を設定します。

5. [フィルタの選択] で、次のテキストをコピーして [ビルドフィルタ] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

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

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

アラート ポリシーを作成

1. Google Cloud コンソールで、[ログベースの指標] ページに移動します。

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

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。

3. [その他 more_vert] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [Next（次へ）] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [Create Policy] をクリックします。

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

Audit logging disabled

API のカテゴリ名: AUDIT_LOGGING_DISABLED

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

1 つ以上の Google Cloud サービスで監査ロギングが無効になっているか、1 つ以上のプリンシパルがデータアクセス監査ロギングから除外されています。

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

デフォルトのデータアクセス監査ロギング構成または個々のサービスのロギング構成で、プリンシパルがデータアクセス監査ロギングの対象から除外されている場合は、除外を削除します。

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

1. Google Cloud コンソールの [データアクセス監査ログのデフォルト構成] ページに移動します。

   デフォルト構成に移動

2. [ログタイプ] タブで、デフォルト構成のデータアクセス監査ロギングを有効にします。

   1. [管理読み取り]、[データ読み取り]、[データ書き込み] を選択します。
   2. [保存] をクリックします。

3. [除外されたプリンシパル] タブで、デフォルトの構成から除外されたすべてのユーザーを削除します。

   1. それぞれの名前の横にある [delete削除] をクリックして、リストされた各プリンシパルを削除します。
   2. [保存] をクリックします。

4. [監査ログ] ページに移動します。

   監査ログに移動

5. 個々のサービスのデータアクセス監査ログ構成から除外されたプリンシパルを削除します。

   1. [データアクセス監査ログの構成] で、除外されたプリンシパルを表示するサービスごとに、サービスをクリックします。サービスの監査ログ構成のパネルが開きます。
   2. [除外されたプリンシパル] タブで、各名前の横にあるdelete [削除] をクリックして、除外されたプリンシパルをすべて削除します。
   3. [保存] をクリックします。

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

Auto backup disabled

API のカテゴリ名: AUTO_BACKUP_DISABLED

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

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

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

1. Google Cloud コンソールで、Cloud SQL の [インスタンス] ページに移動します。

   [インスタンス] に移動

2. インスタンス名をクリックします。

3. [バックアップ] をクリックします。

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

5. [自動バックアップ（毎日）] チェックボックスをオンにします。

6. 省略可: [日数] ボックスに、保持するバックアップの日数を入力します。

7. 省略可: [バックアップ時間枠] リストで、バックアップを取得する時間枠を選択します。

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

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

Auto repair disabled

API のカテゴリ名: AUTO_REPAIR_DISABLED

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

Auto upgrade disabled

API のカテゴリ名: AUTO_UPGRADE_DISABLED

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

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 鍵を設定するには、データセットのデフォルト鍵の設定をご覧ください。

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

Binary authorization disabled

API のカテゴリ名: BINARY_AUTHORIZATION_DISABLED

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

   Binary Authorization に移動

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

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

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

Bucket CMEK disabled

API のカテゴリ名: BUCKET_CMEK_DISABLED

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

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

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

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

Bucket IAM not monitored

API のカテゴリ名: BUCKET_IAM_NOT_MONITORED

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

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

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

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

指標を作成

1. Google Cloud コンソールで [ログベースの指標] ページに移動します。

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

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

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

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

   1. [ログ指標の名前] を設定します。
   2. 説明を追加します。
   3. [単位] に「1」を設定します。

5. [フィルタの選択] で、次のテキストをコピーして [ビルドフィルタ] ボックスに貼り付け、必要に応じて既存のテキストを置き換えます。

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

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

アラート ポリシーを作成

1. Google Cloud コンソールで、[ログベースの指標] ページに移動します。

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

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。

3. [その他 more_vert] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [Next（次へ）] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [Create Policy] をクリックします。

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

Bucket logging disabled

API のカテゴリ名: BUCKET_LOGGING_DISABLED

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

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

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

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

Bucket policy only disabled

API のカテゴリ名: BUCKET_POLICY_ONLY_DISABLED

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

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

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

1. Google Cloud コンソールで [Cloud Storage ブラウザ] ページに移動します。

   Cloud Storage ブラウザに移動

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

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

4. [権限] の [アクセス制御] の行で、[edit アクセス制御モデルを編集] をクリックします。

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

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

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

Cloud Asset API disabled

API のカテゴリ名: CLOUD_ASSET_API_DISABLED

プロジェクトで Cloud Asset Inventory サービスが有効になっていません。

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

1. Google Cloud コンソールで [API ライブラリ] ページに移動します。

   [API ライブラリ] に移動

2. Cloud Asset Inventory を検索します。

3. Cloud Asset API サービスの結果を選択します。

4. 「API が有効です」と表示されていることを確認します。

Cluster logging disabled

API のカテゴリ名: CLUSTER_LOGGING_DISABLED

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

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

情報量によっては、Cloud Logging の費用が高額になる場合があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

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

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

Cluster monitoring disabled

API のカテゴリ名: CLUSTER_MONITORING_DISABLED

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

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

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

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

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

Cluster private Google access disabled

API のカテゴリ名: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

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

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

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

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

1. Google Cloud コンソールで [Virtual Private Cloud ネットワーク] ページに移動します。

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

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

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

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

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

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

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

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

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

Cluster secrets encryption disabled

API のカテゴリ名: CLUSTER_SECRETS_ENCRYPTION_DISABLED

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

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

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

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

   [Cloud KMS 鍵] に移動

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

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

   [Kubernetes クラスタ] に移動

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

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

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

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

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

Cluster shielded nodes disabled

API のカテゴリ名: CLUSTER_SHIELDED_NODES_DISABLED

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

Compute project wide SSH keys allowed

API のカテゴリ名: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

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

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

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

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

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

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

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

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

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

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

Compute Secure Boot disabled

API のカテゴリ名: COMPUTE_SECURE_BOOT_DISABLED

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

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

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

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

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

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

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

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

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

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

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

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

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

Compute serial ports enabled

API のカテゴリ名: COMPUTE_SERIAL_PORTS_ENABLED

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

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

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

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

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

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

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

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

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

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

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. Google Cloud コンソールで [VM インスタンス] ページに移動します。

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

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

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

4. Google Cloud コンソールを使用して Confidential VMs を作成します。

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

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. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

Custom role not monitored

API のカテゴリ名: CUSTOM_ROLE_NOT_MONITORED

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

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

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

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

指標を作成

1. Google Cloud コンソールで [ログベースの指標] ページに移動します。

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

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. Google Cloud コンソールで、[ログベースの指標] ページに移動します。

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

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。

3. [その他 more_vert] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [Next（次へ）] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [Create Policy] をクリックします。

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

Dataproc CMEK disabled

API のカテゴリ名: DATAPROC_CMEK_DISABLED

暗号化構成の CMEK を使用せずに Dataproc クラスタが作成されました。CMEK を使用すると、Cloud Key Management Service で作成、管理する鍵は、Google Cloud がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより細かく制御できます。

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

1. Google Cloud コンソールで Dataproc の [クラスタ] ページに移動します。

   Dataproc のクラスタに移動

2. プロジェクトを選択して、[クラスタを作成] をクリックします。

3. [セキュリティ管理] セクションで、[暗号化] をクリックして [顧客管理の暗号鍵] を選択します。

4. リストから顧客管理の暗号鍵を選択します。

   顧客管理の暗号鍵がない場合は、使用する鍵を作成する必要があります。詳細については、顧客管理の暗号鍵をご覧ください。

5. 選択した KMS 鍵が Cloud KMS 暗号鍵の暗号化 / 復号のロールを Dataproc クラスタ サービス アカウントに割り当てていることを確認します（serviceAccount:service-project_number@compute-system.iam.gserviceaccount.comiam.gserviceaccount.com）。

6. クラスタが作成されたら、すべてのワークロードを古いクラスタから新しいクラスタに移行します。

7. Dataproc の [クラスタ] に移動し、プロジェクトを選択します。

8. 古いクラスタを選択して、[delete 削除] をクリックします。

9. 選択したプロジェクトで使用可能な他の Dataproc クラスタについて、上記のすべての手順を繰り返します。

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

Dataproc image outdated

API のカテゴリ名: DATAPROC_IMAGE_OUTDATED

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

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

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

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

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

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

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

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. データを正常にコピーしたら、元のデータセットを削除します。

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

Default network

API のカテゴリ名: DEFAULT_NETWORK

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

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

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

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

1. Google Cloud コンソールで [VPC ネットワーク] ページに移動します。

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

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

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

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

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

Default service account used

API のカテゴリ名: DEFAULT_SERVICE_ACCOUNT_USED

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

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

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

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

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

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

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

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

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

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

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

Disk CMEK disabled

API のカテゴリ名: DISK_CMEK_DISABLED

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

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

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

1. Google Cloud コンソールで [Compute Engine ディスク] ページに移動します。

   [Compute Engine ディスク] に移動

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

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

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

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

Disk CSEK disabled

API のカテゴリ名: DISK_CSEK_DISABLED

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

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

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

ディスクの削除と作成

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

1. Google Cloud コンソールで [Compute Engine ディスク] ページに移動します。

   [Compute Engine ディスク] に移動

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

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

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

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

検出機能を有効にする

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

   [アセット] に移動

2. [クイック フィルタ] パネルの [リソースタイプ] セクションで、[compute.Disk] を選択します。

   [compute.Disk] が表示されない場合、さらに表示をクリックし、検索フィールドに Disk を入力して [適用] をクリックします。

   [結果] パネルが更新され、compute.Disk リソースタイプのインスタンスのみが表示されます。

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

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

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

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

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

DNS logging disabled

API のカテゴリ名: DNS_LOGGING_DISABLED

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

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

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

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

1. Google Cloud コンソールで [VPC ネットワーク] ページに移動します。

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

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

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

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

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

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

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

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

DNSSEC disabled

API のカテゴリ名: DNSSEC_DISABLED

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

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

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

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

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

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

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

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

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

Effectively Anonymous Users Granted GKE Cluster Access

API のカテゴリ名: GKE_PRIVILEGE_ESCALATION_DEFAULT_USERS_GROUPS

誰かが、次のいずれかのユーザーまたはグループを参照する RBAC バインディングを作成しました。

• system:anonymous
• system:authenticated
• system:unauthenticated

これらのユーザーとグループは実質的に匿名であるため、RoleBinding または ClusterRoleBinding で使用しないでください。詳細については、デフォルトのロールとグループを使用しないをご覧ください。

この検出結果を修正するには、影響を受けるリソースに次の手順を適用します。

1. 影響を受ける ClusterRoleBinding または RoleBinding のマニフェストを開きます。
2. 次の制限付きフィールドに、使用できる値のいずれかを設定します。

制限付きフィールド

• subjects[*].name

使用できる値

• system:anonymous、system:authenticated、system:unauthenticated を含まないグループ、ユーザー、サービス アカウント。

Egress deny rule not set

API のカテゴリ名: EGRESS_DENY_RULE_NOT_SET

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

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

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

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

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

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

Essential contacts not configured

API のカテゴリ名: ESSENTIAL_CONTACTS_NOT_CONFIGURED

組織で、Google Cloud 組織内の攻撃、脆弱性、データ インシデントなどの重要なイベントに関する通知を Google Cloud から受け取る個人またはグループが指定されていません。組織の 1 人以上の個人またはグループをエッセンシャル コンタクトとして指定することをおすすめします。

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

1. Google Cloud コンソールの [エッセンシャル コンタクト] ページに移動します。

   [エッセンシャル コンタクト] に移動

2. ページの上部にあるリソース セレクタに組織が表示されていることを確認します。リソース セレクタは、現在どのプロジェクト、フォルダ、組織の連絡先を管理しているかを示します。

3. [+連絡先を追加] をクリックします。[連絡先を追加する] パネルが開きます。

4. [メール] フィールドと [メールの確認] フィールドに、連絡先のメールアドレスを入力します。

5. [通知のカテゴリ] セクションで、連絡先が受信する通知カテゴリを選択します。次の通知カテゴリで適切なメールアドレスが構成されていることを確認します。

   1. 法務
   2. セキュリティ
   3. 停止
   4. 技術

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

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

Firewall not monitored

API のカテゴリ名: FIREWALL_NOT_MONITORED

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

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

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

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

指標を作成

1. Google Cloud コンソールで [ログベースの指標] ページに移動します。

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

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. Google Cloud コンソールで、[ログベースの指標] ページに移動します。

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

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。

3. [その他 more_vert] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [Next（次へ）] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [Create Policy] をクリックします。

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

Firewall rule logging disabled

API のカテゴリ名: FIREWALL_RULE_LOGGING_DISABLED

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

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

Flow logs disabled

API のカテゴリ名: FLOW_LOGS_DISABLED

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

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

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

1. Google Cloud コンソールで [VPC ネットワーク] ページに移動します。

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

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

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

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

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

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

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

Flow logs settings not recommended

API のカテゴリ名: VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

VPC ネットワーク内のサブネットの構成では、VPC フローログ サービスは、無効になっているか、CIS ベンチマーク 1.3 の推奨事項に従って構成されていません。VPC フローログは、VM インスタンスによって送受信され、脅威の検出に使用できる、ネットワーク フローのサンプルを記録します。

VPC フローログとその費用についての詳細は、VPC フローログの使用をご覧ください。

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

1. Google Cloud コンソールで [VPC ネットワーク] ページに移動します。

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

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

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

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

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

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

   1. 必要に応じて、[ログを構成] ボタンをクリックしてタブを展開し、ログの構成を変更します。CIS ベンチマークでは、次の設定をおすすめします。
      1. [集約の間隔] を [5 秒] に設定します。
      2. [その他のフィールド] チェックボックスで、[メタデータを含める] オプションを選択します。
      3. [サンプルレート] を [100%] に設定します。
      4. [保存] をクリックします。

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

Full API access

API のカテゴリ名: FULL_API_ACCESS

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

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

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

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

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

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

3. インスタンスが実行中の場合は、stop [停止] をクリックします。

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

5. [セキュリティとアクセス] セクションの [サービス アカウント] で、[Compute Engine のデフォルトのサービス アカウント] を選択します。

6. [アクセス スコープ] で、[デフォルトのアクセスを許可する] または [各 API にアクセス権を設定] を選択します。これにより、デフォルトの VM サービス アカウントを使用するプロセスまたはワークロードがアクセスできる API が制限されます。

7. [各 API にアクセス権を設定] を選択した場合は、次の手順を行います。

   • [Cloud Platform] を [なし] に設定して無効にします。
   • デフォルトの VM サービス アカウントがアクセスする必要がある特定の API を有効にします。

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

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

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

HTTP load balancer

API のカテゴリ名: HTTP_LOAD_BALANCER

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

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

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

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

1. Google Cloud コンソールで [ターゲット プロキシ] ページに移動します。

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

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

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

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

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

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

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

Instance OS login disabled

API のカテゴリ名: INSTANCE_OS_LOGIN_DISABLED

この Compute Engine インスタンスでは OS Login が無効になっています。

OS Login により、IAM を使用した一元的な SSH 認証鍵管理ができるようになり、プロジェクト内のすべてのインスタンスにおけるメタデータ ベースの SSH 認証鍵の構成が無効になります。詳しくは、OS Login を設定および構成する方法をご覧ください。

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

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

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

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

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

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

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

5. [カスタム メタデータ] セクションで、enable-oslogin キーを持つアイテムの値が TRUE になっていることを確認します。

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

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

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

Integrity monitoring disabled

API のカテゴリ名: INTEGRITY_MONITORING_DISABLED

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

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

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

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

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

Intranode visibility disabled

API のカテゴリ名: INTRANODE_VISIBILITY_DISABLED

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

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

IP alias disabled

API のカテゴリ名: IP_ALIAS_DISABLED

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

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

IP forwarding enabled

API のカテゴリ名: IP_FORWARDING_ENABLED

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

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

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

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

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

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

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

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

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

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

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

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

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

KMS key not rotated

API のカテゴリ名: KMS_KEY_NOT_ROTATED

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

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

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

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

   [Cloud KMS 鍵] に移動

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

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

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

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

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

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

KMS project has owner

API のカテゴリ名: KMS_PROJECT_HAS_OWNER

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

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

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

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

   [IAM] ページに移動

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

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

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

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

KMS public key

API のカテゴリ名: KMS_PUBLIC_KEY

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

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

1. Google Cloud コンソールで [暗号鍵] ページに移動します。

   暗号鍵

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

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

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

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

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

1. Google Cloud コンソールで [暗号鍵] ページに移動します。

   暗号鍵

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

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

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

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

KMS role separation

API のカテゴリ名: KMS_ROLE_SEPARATION

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

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

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

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

   [IAM] に移動

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

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

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

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

Legacy authorization enabled

API のカテゴリ名: LEGACY_AUTHORIZATION_ENABLED

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

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

Legacy metadata enabled

API のカテゴリ名: LEGACY_METADATA_ENABLED

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

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

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

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

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

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

Legacy network

API のカテゴリ名: LEGACY_NETWORK

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

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

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

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

1. Google Cloud コンソールで [VPC ネットワーク] ページに移動します。

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

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

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

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

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

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

Load balancer logging disabled

API のカテゴリ名: LOAD_BALANCER_LOGGING_DISABLED

ロードバランサのバックエンド サービスでロギングが無効になっています。

ロードバランサのロギングを有効にすると、ウェブ アプリケーションの HTTP(S) ネットワーク トラフィックを表示できます。詳細については、ロードバランサをご覧ください。

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

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

   [Cloud Load Balancing] に移動

2. ロードバランサの名前をクリックします。

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

4. [バックエンドの構成] をクリックします。

5. [バックエンドの構成] ページで、edit[編集] をクリックします。

6. [ロギング] セクションで [ロギングを有効にする] を選択し、プロジェクトに最適なサンプルレートを選択します。

7. バックエンド サービスの編集を終了するには、[更新] をクリックします。

8. ロードバランサの編集を終了するには、[更新] をクリックします。

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

Locked retention policy not set

API のカテゴリ名: LOCKED_RETENTION_POLICY_NOT_SET

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

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

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

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

1. Google Cloud コンソールで [Storage ブラウザ] ページに移動します。

   Storage の [ブラウザ] に移動

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

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

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

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

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

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

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

Log not exported

API のカテゴリ名: LOG_NOT_EXPORTED

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

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

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

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

1. Google Cloud コンソール で [ログルーター] ページに移動します。

   [ログルーター] に移動

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

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

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

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

Master authorized networks disabled

API のカテゴリ名: MASTER_AUTHORIZED_NETWORKS_DISABLED

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

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

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

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

MFA not enforced

API のカテゴリ名: MFA_NOT_ENFORCED

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

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

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

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

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

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

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

このタイプの検出結果を抑制する

このタイプの検出結果を抑制するには、このタイプの今後の検出結果を自動的にミュートするミュートルールを定義します。詳細については、Security Command Center で検出結果をミュートするをご覧ください。

検出結果を抑制する方法はおすすめできませんが、アセットに専用のセキュリティ マークを追加して、Security Health Analytics の検出機能でこれらのアセットのセキュリティの検出結果が作成されないようにすることもできます。

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

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

Network not monitored

API のカテゴリ名: NETWORK_NOT_MONITORED

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

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

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

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

指標を作成

1. Google Cloud コンソールで [ログベースの指標] ページに移動します。

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

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. Google Cloud コンソールで、[ログベースの指標] ページに移動します。

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

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。

3. [その他 more_vert] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [Next（次へ）] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [Create Policy] をクリックします。

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

Network policy disabled

API のカテゴリ名: NETWORK_POLICY_DISABLED

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

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

Nodepool boot CMEK disabled

API のカテゴリ名: NODEPOOL_BOOT_CMEK_DISABLED

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

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

Nodepool secure boot disabled

API のカテゴリ名: NODEPOOL_SECURE_BOOT_DISABLED

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

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

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

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

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

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

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

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

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

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

Non org IAM member

API のカテゴリ名: NON_ORG_IAM_MEMBER

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

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

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

   IAM に移動

2. 組織またはプロジェクト以外のユーザーの横にあるチェックボックスをオンにします。

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

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

Object versioning disabled

API のカテゴリ名: OBJECT_VERSIONING_DISABLED

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

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

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

この検出結果を修正するには、gcloud storage buckets update コマンドで --versioning フラグを使用して適切な値を指定します。

    gcloud storage buckets update gs://finding.assetDisplayName --versioning

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

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

Open Cassandra port

API のカテゴリ名: OPEN_CASSANDRA_PORT

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

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

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

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open ciscosecure websm port

API のカテゴリ名: OPEN_CISCOSECURE_WEBSM_PORT

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

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

• TCP - 9090

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open directory services port

API のカテゴリ名: OPEN_DIRECTORY_SERVICES_PORT

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

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

• TCP - 445
• UDP - 445

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open DNS port

API のカテゴリ名: OPEN_DNS_PORT

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

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

• TCP - 53
• UDP - 53

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open Elasticsearch port

API のカテゴリ名: OPEN_ELASTICSEARCH_PORT

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

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

• TCP - 9200, 9300

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open firewall

API のカテゴリ名: OPEN_FIREWALL

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

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

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

1. Google Cloud コンソールで [ファイアウォール ルール] ページに移動します。

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

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

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

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

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

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

Open FTP port

API のカテゴリ名: OPEN_FTP_PORT

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

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

• TCP - 21

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open group IAM member

API のカテゴリ名: OPEN_GROUP_IAM_MEMBER

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

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

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

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

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

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

   IAM に移動

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

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

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

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

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

Open HTTP port

API のカテゴリ名: OPEN_HTTP_PORT

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

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

• TCP - 80

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open LDAP port

API のカテゴリ名: OPEN_LDAP_PORT

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

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

• TCP - 389, 636
• UDP - 389

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open Memcached port

API のカテゴリ名: OPEN_MEMCACHED_PORT

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

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

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

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open MongoDB port

API のカテゴリ名: OPEN_MONGODB_PORT

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

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

• TCP - 27017, 27018, 27019

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open MySQL port

API のカテゴリ名: OPEN_MYSQL_PORT

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

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

• TCP - 3306

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open NetBIOS port

API のカテゴリ名: OPEN_NETBIOS_PORT

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

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

• TCP - 137, 138, 139
• UDP - 137, 138, 139

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open OracleDB port

API のカテゴリ名: OPEN_ORACLEDB_PORT

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

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

• TCP - 1521, 2483, 2484
• UDP - 2483, 2484

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open POP3 port

API のカテゴリ名: OPEN_POP3_PORT

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

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

• TCP - 110

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open PostgreSQL port

API のカテゴリ名: OPEN_POSTGRESQL_PORT

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

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

• TCP - 5432
• UDP - 5432

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open RDP port

API のカテゴリ名: OPEN_RDP_PORT

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

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

• TCP - 3389
• UDP - 3389

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open Redis port

API のカテゴリ名: OPEN_REDIS_PORT

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

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

• TCP - 6379

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open SMTP port

API のカテゴリ名: OPEN_SMTP_PORT

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

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

• TCP - 25

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

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

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

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

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

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

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

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

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

Open SSH port

API のカテゴリ名: OPEN_SSH_PORT

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

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

• SCTP - 22
• TCP - 22

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

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

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

   [ファイアウォール] に移動

2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

3. edit [編集] をクリックします。

4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

5. インスタンスに接続する特定の IP アドレスや IP 範囲を追加します。

6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

7. [保存] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Open Telnet port

API のカテゴリ名: OPEN_TELNET_PORT

ファイアウォール ルールで任意の IP アドレスから Telnet ポートへの接続を許可すると、Telnet サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

Telnet サービスのポートは次のとおりです。

• TCP - 23

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [ファイアウォール] ページに移動します。

   [ファイアウォール] に移動

2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

3. edit [編集] をクリックします。

4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

5. インスタンスに接続する特定の IP アドレスや IP 範囲を追加します。

6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

7. [保存] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Org policy Confidential VM policy

API のカテゴリ名: ORG_POLICY_CONFIDENTIAL_VM_POLICY

Compute Engine リソースが constraints/compute.restrictNonConfidentialComputing 組織ポリシーを遵守していません。この組織ポリシーの制約の詳細については、組織ポリシーの制約の適用をご覧ください。

組織には、この VM に有効な Confidential VM サービスがあることが必要です。このサービスが有効になっていない VM は、ランタイム メモリの暗号化を使用しないため、ランタイム メモリの攻撃にさらされます。

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

この検出結果を修正するには、次の操作を行います。

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

   [VM インスタンス] に移動

2. インスタンスのリストで、検出結果内のインスタンスの名前をクリックします。

3. VM が Confidential VM サービスを必要としない場合は、それを新しいフォルダまたはプロジェクトに移動します。

4. VM に Confidential VM が必要な場合は、delete [削除] をクリックします。

5. Confidential VM を有効にして新しいインスタンスを作成するには、クイックスタート: Confidential VM インスタンスの作成をご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Org policy location restriction

API のカテゴリ名: ORG_POLICY_LOCATION_RESTRICTION

組織のポリシーの gcp.resourceLocations 制約を使用すると、新しいリソースの作成を、選択したクラウド リージョンに制限できます。詳細については、リソース ロケーションの制限をご覧ください。

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

この検出結果を修正するには、次の操作を行います。

ORG_POLICY_LOCATION_RESTRICTION 検出機能は多くのリソースタイプをカバーしており、リソースごとに修正手順が異なります。ロケーション違反を修正するための一般的なアプローチには、次のようなものがあります。

1. リージョン外のリソースまたはそのデータを、リージョン内のリソースにコピー、移動、またはバックアップします。リソースの移動の手順については、各サービスのドキュメントをご覧ください。
2. 元のリージョン外のリソースまたはそのデータを削除する。

このアプローチは、すべてのリソースタイプに適用できるわけではありません。指針としては、検出結果で個別に示された推奨事項をご覧ください。

その他の考慮事項

この検出結果を修正する場合は、次の点を考慮してください。

マネージド リソース

リソースのライフサイクルは、他のリソースによって管理や制御されることがあります。たとえば、マネージド Compute Engine インスタンス グループは、インスタンス グループの自動スケーリング ポリシーに従って Compute Engine インスタンスの作成と破棄を行います。マネージド リソースとマネージング リソースがロケーション適用の対象である場合は、両方とも組織のポリシーの違反として警告される場合があります。運用の安定性を確保するため、マネージング リソースにマネージド リソースの検出結果の修正が行われる必要があります。

使用中のリソース

特定のリソースは、他のリソースによって使用されます。たとえば、実行中の Compute Engine インスタンスにアタッチされた Compute Engine ディスクは、インスタンスによって使用中とみなされます。使用中のリソースがロケーションの組織のポリシーに違反している場合は、ロケーションの違反に対処する前に、そのリソースが使用中ではないことを確認する必要があります。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

OS login disabled

API のカテゴリ名: OS_LOGIN_DISABLED

この Compute Engine インスタンスでは OS Login が無効になっています。

OS Login により、IAM を使用した一元的な SSH 認証鍵管理ができるようになり、プロジェクト内のすべてのインスタンスにおけるメタデータ ベースの SSH 認証鍵の構成が無効になります。詳しくは、OS Login を設定および構成する方法をご覧ください。

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

この検出結果を修正するには、次の操作を行います。

1. Google Cloud コンソールで [メタデータ] ページに移動します。

   [メタデータ] に移動

2. [編集] をクリックし、[項目を追加] をクリックします。

3. キーが enable-oslogin で、値が TRUE のアイテムを追加します。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Over privileged account

API のカテゴリ名: OVER_PRIVILEGED_ACCOUNT

GKE ノードは、Compute Engine のデフォルトのサービスノードを使用しています。このノードには、デフォルトで広範なアクセス権が付与されており、GKE クラスタを稼働するための過剰な権限を保有している可能性があります。

この検出結果を修正するには、次の手順を行います。

最小限の権限の Google サービス アカウントを使用するの手順に沿って操作します。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Over privileged scopes

API のカテゴリ名: OVER_PRIVILEGED_SCOPES

ノードのサービス アカウントに、範囲の広いアクセス スコープがあります。

アクセス スコープは、インスタンスの権限を指定するレガシーな方法です。攻撃における権限昇格の可能性を減少させるには、最小限の特権サービス アカウントを作成して、GKE クラスタの稼働にはそのサービス アカウントを使用します。

この検出項目を修正するには、最小限の権限の Google サービス アカウントを使用するの手順に沿って操作してください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Over privileged service account user

API のカテゴリ名: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

ユーザーに特定のサービス アカウントに対するロールではなく、プロジェクト、フォルダ、または組織レベルで iam.serviceAccountUser または iam.serviceAccountTokenCreator のロールが付与されています。

そうしたロールをプロジェクト、フォルダまたは組織のユーザーに付与すると、そのユーザーは、その範囲にある既存および今後作成されるすべてのサービス アカウントにアクセスできるようになります。その結果、意図しない権限昇格につながる可能性があります。詳細については、サービス アカウント権限をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [IAM] ページに移動します。

   [IAM] ページに移動

2. 必要に応じて、検出結果のプロジェクト、フォルダ、または組織を選択します。

3. roles/iam.serviceAccountUser または roles/iam.serviceAccountTokenCreator が割り当てられたプリンシパルごとに、次の操作を行います。

   1. [edit 編集] をクリックします。
   2. [権限の編集] パネルで、ロールの横にある delete [削除] をクリックします。
   3. [保存] をクリックします。

4. このガイドに沿って、1 つのサービス アカウントの権限の使用を個々のユーザーに許可します。選択したユーザーに権限の使用を許可するサービス アカウントごとで、このガイドに沿って操作を行う必要があります。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Owner not monitored

API のカテゴリ名: OWNER_NOT_MONITORED

ログ指標とアラートが、プロジェクト所有権の割り当て、または変更をモニタリングするように構成されていません。

IAM オーナーのロールは、プロジェクトで最高レベルの権限を持っています。リソースを保護するために、オーナーが新しく追加または削除されたときに、通知を受け取るようにアラートを設定します。詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

この検出結果を修正するには、次の操作を行います。

指標を作成

1. Google Cloud コンソールで [ログベースの指標] ページに移動します。

   [ログベースの指標] に移動

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. Google Cloud コンソールで、[ログベースの指標] ページに移動します。

   [ログベースの指標] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。

3. [その他 more_vert] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [Next（次へ）] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [Create Policy] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Pod security policy disabled

API のカテゴリ名: POD_SECURITY_POLICY_DISABLED

PodSecurityPolicy が GKE クラスタで無効になっています。

PodSecurityPolicy は、クラスタ上で Pod を作成および更新するリクエストを検証するアドミッション コントローラ リソースです。クラスタは、PodSecurityPolicy で定義された条件を満たさない Pod を受け入れません。

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

この検出結果を修正するには、PodSecurityPolicies を定義して承認し、PodSecurityPolicy コントローラを有効にします。手順については、PodSecurityPolicies の使用をご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Primitive roles used

API のカテゴリ名: PRIMITIVE_ROLES_USED

IAM の基本ロール（roles/owner、roles/editor、roles/viewer のいずれか）を持つユーザーがいます。このようなロールは制限が緩すぎるため、使用しないでください。代わりに、ロールはプロジェクトごとのみに割り当てる必要があります。

詳しくは、ロールについてをご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [IAM] ページに移動します。

   [IAM ポリシー] に移動

2. 基本ロールが割り当てられているユーザーごとに、より細かいロールの使用を検討してください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Private cluster disabled

API のカテゴリ名: PRIVATE_CLUSTER_DISABLED

GKE クラスタに、無効な限定公開クラスタがあります。

限定公開クラスタのノードに割り当てられるのはプライベート IP アドレスだけです。この機能は、ノードへの送信インターネット アクセスを制限します。クラスタノードにパブリック IP アドレスがない場合、クラスタノードは検出不能であるか、インターネットに公開されません。内部ロードバランサを使用してノードにトラフィックをルーティングすることは可能です。詳細については、限定公開クラスタをご覧ください。

既存のクラスタをプライベートにすることはできません。この検出結果を修正するには、新しい限定公開クラスタを作成します。

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. [クラスタを作成] をクリックします。

3. ナビゲーション メニューの [クラスタ] で、[ネットワーキング] を選択します。

4. [限定公開クラスタ] のラジオボタンを選択します。

5. [高度なネットワーキングのオプション] で、[VPC ネイティブのトラフィック ルーティングを有効にする（エイリアス IP を使用）] チェックボックスをオンにします。

6. [作成] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Private Google access disabled

API のカテゴリ名: PRIVATE_GOOGLE_ACCESS_DISABLED

Google の公開 API にアクセスできない限定公開サブネットがあります。

限定公開の Google アクセスを使用すると、内部（プライベート）IP アドレスのみを持つ VM インスタンスが Google API とサービスのパブリック IP アドレスにアクセスできます。

詳細については、限定公開の Google アクセスの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [VPC ネットワーク] ページに移動します。

   [VPC ネットワーク] に移動

2. ネットワークのリストで、目的のネットワークの名前をクリックします。

3. [VPC ネットワークの詳細] ページで、[サブネット] タブをクリックします。

4. サブネットのリストで、検出結果内の Kubernetes クラスタに関連付けられているサブネットの名前をクリックします。

5. [サブネットの詳細] ページで、[edit編集] をクリックします。

6. [限定公開の Google アクセス] で [オン] を選択します。

7. [保存] をクリックします。

8. Google API に対してのみ外部トラフィックを送信する VM インスタンスからパブリック（外部）IP を削除するには、静的外部 IP アドレスの割り当て解除をご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public bucket ACL

API のカテゴリ名: PUBLIC_BUCKET_ACL

バケットが一般公開されており、インターネット上の誰でもアクセスできるようになっています。

詳細については、アクセス制御の概要をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Storage ブラウザ] ページに移動します。

   Storage の [ブラウザ] に移動

2. Security Health Analytics の検出結果に表示されているバケットを選択します。

3. [バケットの詳細] ページで、[権限] タブをクリックします。

4. [表示] の横の [ロール] をクリックします。

5. [フィルタ] ボックスで、allUsers と allAuthenticatedUsers を検索します。

6. [delete削除] をクリックして、allUsers と allAuthenticatedUsers に付与されているすべての IAM 権限を削除します。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public Compute image

API のカテゴリ名: PUBLIC_COMPUTE_IMAGE

Compute Engine イメージが一般公開されており、インターネット上の誰でもアクセスできるようになっています。allUsers はインターネット上の全員を表し、allAuthenticatedUsers は Google アカウントで認証されている全員を表します。どちらも組織内のユーザーに限定されません。

Compute Engine イメージには、暗号鍵やライセンス付きソフトウェアなどの機密情報が含まれる場合があります。このような機密情報は一般公開しないでください。この Compute Engine イメージを公開する場合は、機密情報が含まれていないことを確認してください。

詳細については、アクセス制御の概要をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Compute Engine イメージ] ページに移動します。

   [Compute Engine イメージ] に移動

2. [public-image] イメージの横にあるボックスを選択し、[情報パネルを表示] をクリックします。

3. [フィルタ] ボックスで、allUsers と allAuthenticatedUsers のプリンシパルを検索します。

4. ユーザーを削除するロールを展開します。

5. delete [削除] をクリックして、そのロールからユーザーを削除します。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public dataset

API のカテゴリ名: PUBLIC_DATASET

BigQuery データセットが一般公開されており、インターネット上の誰でもアクセスできるようになっています。IAM プリンシパルの allUsers はインターネット上のすべてのユーザーを表し、allAuthenticatedUsers は Google サービスにログインしているすべてのユーザーを表します。どちらでも組織内のユーザーに限定されていません。

詳細については、データセットへのアクセスの制御をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで BigQuery の [エクスプローラ] ページに移動します。

   BigQuery データセットに移動

2. データセットのリストで、検出結果にあるデータセットの名前をクリックします。[データセット情報] パネルが開きます。

3. [データセット情報] パネルの上部にある [共有] をクリックします。

4. プルダウン メニューで [権限] をクリックします。

5. [データセットの権限] パネルで、「allUsers」と「allAuthenticatedUsers」を入力し、これらのプリンシパルのアクセス権を削除します。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public IP address

API のカテゴリ名: PUBLIC_IP_ADDRESS

Compute Engine インスタンスにパブリック IP アドレスがあります。

組織の攻撃対象を減らすために、VM にパブリック IP アドレスを割り当てるのは避けてください。停止されたインスタンスは、ネットワーク インターフェースが起動時にエファメラルなパブリック IP を割り当てるように構成されている場合など、パブリック IP 検出で警告される場合があります。停止されたインスタンスのネットワーク構成に、外部アクセスが含まれていないことを確認してください。

詳細については、VM インスタンスへの安全な接続をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

   [VM インスタンス] に移動

2. インスタンスのリストで、検出結果のインスタンスの名前の横にあるチェックボックスをオンにします。

3. [edit 編集] をクリックします。

4. [ネットワーク インターフェース] にあるインターフェースごとに、edit [編集] をクリックして、[外部 IP] を [なし] に設定します。

5. [完了] をクリックし、[保存] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public log bucket

API のカテゴリ名: PUBLIC_LOG_BUCKET

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

ストレージ バケットは一般公開されており、ログシンクとして使用されています。これは、インターネット上の誰でも、このバケットに保存されているログにアクセスできることを意味します。allUsers はインターネット上の全員を表し、allAuthenticatedUsers は Google サービスにログインしている全員を表しています。どちらも組織内のユーザーに限定されていません。

詳細については、アクセス制御の概要をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud Storage ブラウザ] ページに移動します。

   Cloud Storage ブラウザに移動

2. バケットのリストで、検出結果に示されているバケットの名前をクリックします。

3. [権限] タブをクリックします。

4. プリンシパルのリストから allUsers と allAuthenticatedUsers を削除します。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public SQL instance

API のカテゴリ名: PUBLIC_SQL_INSTANCE

SQL インスタンスで、許可されるネットワークとして 0.0.0.0/0 が設定されています。この状況は、許可する意図のないクライアントを含め、あらゆる IPv4 クライアントがネットワーク ファイアウォールを通過して、インスタンスへのログインを試行できることを意味します。なお、クライアントがインスタンスに正常にログインするには、有効な認証情報が必要です。

詳細については、承認済みネットワークでの承認をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. ナビゲーション パネルで [接続] をクリックします。

5. [承認済みネットワーク] で 0.0.0.0/0 を削除し、インスタンスに接続する特定の IP アドレスまたは IP 範囲を指定します。

6. [完了] をクリックし、[保存] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Pubsub CMEK disabled

API のカテゴリ名: PUBSUB_CMEK_DISABLED

Pub/Sub トピックが、顧客管理の暗号鍵（CMEK）で暗号化されません。

CMEK を使用すると、Cloud KMS で作成、管理する鍵は、Google がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより細かく制御できます。

この検出結果を修正するには、既存のトピックを削除して新しいトピックを作成します。

1. Google Cloud コンソールで Pub/Sub の [トピック] ページに移動します。

   トピックに移動

2. 必要に応じて、Pub/Sub トピックを含むプロジェクトを選択します。

3. 検索結果に表示されたトピックの横にあるチェックボックスをオンにして、[削除] をクリックします。delete

4. CMEK を有効にして新しい Pub/Sub トピックを作成するには、顧客管理の暗号鍵の使用をご覧ください。CMEK を使用すると、Cloud KMS に関連する追加費用が発生します。

5. CMEK を有効化した Pub/Sub トピックに検出結果や他のデータを公開します。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Route not monitored

API のカテゴリ名: ROUTE_NOT_MONITORED

ログ指標とアラートが、VPC ネットワーク ルートの変更をモニタリングするように構成されていません。

Google Cloud ルートは、ネットワーク トラフィックが VM インスタンスから宛先 IP に到達する際に通過する経路を定義する宛先とホップです。ルートテーブルに対する変更をモニタリングすると、すべての VPC トラフィックが想定どおりの経路を通過するようにできます。

詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

この検出結果を修正するには、次の操作を行います。

指標を作成

1. Google Cloud コンソールで [ログベースの指標] ページに移動します。

   [ログベースの指標] に移動

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. Google Cloud コンソールで、[ログベースの指標] ページに移動します。

   [ログベースの指標] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。

3. [その他 more_vert] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [Next（次へ）] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [Create Policy] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. Google Cloud コンソールで [IAM] ページに移動します。

   [IAM ポリシー] に移動

2. 検出結果に示された Redis IAM ロールを削除し、代わりに個々のプロジェクトにそれらのロールを追加します。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Release channel disabled

API のカテゴリ名: RELEASE_CHANNEL_DISABLED

GKE クラスタはリリース チャンネルに登録されていません。

リリース チャンネルに登録して、GKE クラスタのバージョン アップグレードを自動化します。また、バージョン管理の複雑さを軽減し、必要な機能の数と安定性のレベルを引き下げることもできます。詳細については、リリース チャンネルをご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. [クラスタの基本] セクションで、[リリース チャンネル] 行の [edit クラスタ マスター バージョンをアップグレード] をクリックします。

   クラスタの構成を変更した直後は、編集ボタンが無効になっていることがあります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

3. ダイアログで [リリース チャンネル] を選択し、登録するリリース チャンネルを選択します。

   クラスタのコントロール プレーン バージョンをリリース チャンネルにアップグレードできない場合、そのチャンネルはオプションとして無効になることがあります。

4. [変更を保存] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

RSASHA1 for signing

API のカテゴリ名: RSASHA1_FOR_SIGNING

RSASHA1 が Cloud DNS ゾーンにログインする鍵に使用されている。鍵署名に使用するアルゴリズムは、堅牢である必要があります。

この検出項目を修正するには、高度な署名オプションの使用のガイドに沿って、アルゴリズムを推奨のアルゴリズムに置き換えます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Service account key not rotated

API のカテゴリ名: SERVICE_ACCOUNT_KEY_NOT_ROTATED

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

ユーザー管理のサービス アカウント キーが 90 日以上ローテーションされていません。

一般的に、ユーザー管理のサービス アカウント キーは少なくとも 90 日ごとにローテーションさせて、紛失、不正使用、盗難にあった古い鍵でデータにアクセスしないようにしてください。詳しくは、鍵の漏えいによって発生するセキュリティ リスクを軽減するためにサービス アカウント キーをローテーションするをご覧ください。

公開鍵/秘密鍵のペアを自分で生成し、ハードウェア セキュリティ モジュール（HSM）に秘密鍵を保存して、Google に公開鍵をアップロードした場合は、鍵のローテーションを 90 日ごとに行う必要はありません。その代わりに、鍵が侵害された可能性がある場合に鍵をローテーションします。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [サービス アカウント] ページに移動します。

   [サービス アカウント] に移動

2. 必要に応じて、検出結果内で示されているプロジェクトを選択します。

3. サービス アカウントのリストで、検索結果に記載されたサービス アカウントを見つけて、delete [削除] をクリックします。続行する前に、サービス アカウントの削除が本番環境のリソースに及ぼす可能性のある影響を検討してください。

4. 新しいサービス アカウント鍵を作成し、古い鍵に置換します。詳細については、サービス アカウント キーの作成をご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Service account role separation

API のカテゴリ名: SERVICE_ACCOUNT_ROLE_SEPARATION

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

組織内の 1 人または複数のプリンシパルに、複数のサービス アカウントの権限が割り当てられています。どのアカウントにも、他のサービス アカウントの権限とともにサービス アカウント管理者の権限を同時に与えないでください。サービス アカウントと、サービス アカウントに使用可能なロールについては、サービス アカウントをご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [IAM] ページに移動します。

   [IAM] に移動

2. 検出結果に記載されているプリンシパルごとに、次の操作を行います。

   1. [継承] 列を調べて、ロールがフォルダまたは組織リソースから継承されているかどうかを確認します。列に親リソースへのリンクが含まれている場合は、そのリンクをクリックして親リソースの [IAM] ページに移動します。
   2. プリンシパルの横にある [edit編集] をクリックします。
   3. 権限を削除するには、[サービス アカウント管理者] の横にある delete[削除] をクリックします。すべてのサービス アカウントの権限を削除するには、他の権限の横にある [削除] をすべてクリックします。

3. [保存] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Shielded VM disabled

API のカテゴリ名: SHIELDED_VM_DISABLED

この Compute Engine インスタンスで、Shielded VM が無効になっています。

Shielded VM は、ルートキットやブートキットによる攻撃を防御する一連のセキュリティ制御により強化された、Google Cloud 上の仮想マシン（VM）です。Shielded VM を使用すると、ブートローダーとファームウェアの署名と検証を確実にできるようになります。Shielded VM について理解する。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [VM インスタンス] ページに移動します。

   [VM インスタンス] に移動

2. Security Health Analytics の検出結果に関連するインスタンスを選択します。

3. 読み込まれた [インスタンスの詳細] ページで、stop [停止] をクリックします。

4. インスタンスが停止したら、edit [編集] をクリックします。

5. [Shielded VM] セクションで、[vTPM をオンにする] と [整合性のモニタリングを有効にする] を切り替えて、Shielded VM を有効にします。

6. 必要に応じて、カスタム ドライバまたは署名されていないドライバを使用しない場合に、セキュアブートも有効にします。

7. [保存] をクリックします。新しい構成が [インスタンスの詳細] ページに表示されます。

8. [play_arrow開始] をクリックしてインスタンスを起動します。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL CMEK disabled

API のカテゴリ名: SQL_CMEK_DISABLED

SQL データベース インスタンスが顧客管理の暗号鍵（CMEK）を使用していません。

CMEK を使用すると、Cloud KMS で作成、管理する鍵は、Google がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより細かく制御できます。詳細については、ご使用のプロダクト（Cloud SQL for MySQL、Cloud SQL for PostgreSQL、Cloud SQL for SQL Server）の CMEK の概要をご覧ください。CMEK を使用すると、Cloud KMS に関連する追加費用が発生します。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [delete 削除] をクリックします。

4. CMEK を有効にして新しいインスタンスを作成するには、次の手順に沿って、ご使用のプロダクト用に CMEK を構成します。

   1. Cloud SQL for MySQL
   2. Cloud SQL for PostgreSQL
   3. Cloud SQL for SQL Server

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL contained database authentication

API のカテゴリ名: SQL_CONTAINED_DATABASE_AUTHENTICATION

Cloud SQL for SQL Server データベース インスタンスで、含まれているデータベース認証のデータベース フラグがオフに設定されていません。

含まれているデータベース認証フラグは、含まれるデータベースの作成とデータベースの Compute Engine への接続を可能にするかどうかを制御します。含まれているデータベースには、データベースの定義に必要なすべてのデータベース設定とメタデータが含まれており、データベースがインストールされているデータベースエンジンのインスタンスに構成の依存関係はありません。

次の理由により、このフラグを有効にすることはおすすめしません。

• ユーザーは、データベース エンジン レベルで、認証なしでデータベースに接続できる。
• データベースをデータベース エンジンから分離すると、データベースを SQL Server の別のインスタンスに移動できる。

含まれているデータベースは、SQL Server Database Engine 管理者が理解し緩和する必要があるような、固有の脅威に直面します。ほとんどの脅威は、USER WITH PASSWORD 認証プロセスで発生します。このプロセスでは、認証の境界線が Database Engine レベルからデータベース レベルに移動します。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. [データベース フラグ] セクションで、含まれているデータベース認証のデータベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. [データベース フラグ] セクションで、cross db ownership chaining データベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL external scripts enabled

API のカテゴリ名: SQL_EXTERNAL_SCRIPTS_ENABLED

Cloud SQL for SQL Server データベース インスタンスで、external scripts enabled データベース フラグが [オフ] に設定されていません。

この設定を有効にすると、特定のリモート言語の拡張機能でスクリプトの実行が有効になります。この機能はシステムのセキュリティに悪影響を与える可能性があるため、無効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、[外部スクリプトが有効] データベース フラグをオフに設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL instance not monitored

API のカテゴリ名: SQL_INSTANCE_NOT_MONITORED

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

ログ指標とアラートが、Cloud SQL インスタンスの構成の変更をモニタリングするように構成されていません。

SQL インスタンス オプションの構成に誤りがあると、セキュリティ リスクの原因になる可能性があります。自動バックアップと高可用性オプションを無効にすると、ビジネスの継続性に影響を与えることがあり、承認済みネットワークを制限しなければ、信頼できないネットワークへの露出が増加する可能性があります。SQL インスタンスの構成の変更をモニタリングすると、構成ミスの検出と修正にかかる時間を短縮できます。

詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、Google Cloud Observability の料金をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

この検出結果を修正するには、次の操作を行います。

指標を作成

1. Google Cloud コンソールで [ログベースの指標] ページに移動します。

   [ログベースの指標] に移動

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. Google Cloud コンソールで、[ログベースの指標] ページに移動します。

   [ログベースの指標] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。

2. [ユーザー定義の指標] セクションで、前のセクションで作成した指標を選択します。

3. [その他 more_vert] をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [Next（次へ）] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [Create Policy] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL local infile

API のカテゴリ名: SQL_LOCAL_INFILE

Cloud SQL for MySQL データベース インスタンスで、local_infile のデータベース フラグがオフに設定されていません。local_infile フラグに関連するセキュリティの問題があるため、これを無効にする必要があります。詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. [データベース フラグ] セクションで、local_infile データベース フラグをオフに設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log checkpoints disabled

API のカテゴリ名: SQL_LOG_CHECKPOINTS_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_checkpoints のデータベース フラグがオンに設定されていません。

log_checkpoints を有効にすると、チェックポイントと再起動のポイントがサーバーログに記録されます。書き込まれたバッファの数やバッファの書き込みにかかった時間など、一部の統計情報はログメッセージに含まれます。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. [データベース フラグ] セクションで、log_checkpoints データベース フラグを [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log connections disabled

API のカテゴリ名: SQL_LOG_CONNECTIONS_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_connections のデータベース フラグがオンに設定されていません。

log_connections 設定を有効にすると、サーバーへの接続の試行とクライアント認証の完了がログに記録されます。このログは、問題のトラブルシューティングや、サーバーへの異常な接続の確認に役立ちます。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. [データベース フラグ] セクションで、log_connections データベース フラグを [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log disconnections disabled

API のカテゴリ名: SQL_LOG_DISCONNECTIONS_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_disconnections のデータベース フラグがオンに設定されていません。

log_disconnections 設定を有効にすると、各セッションの終了時にログエントリが作成されます。これらのログは、問題のトラブルシューティングを行い、一定期間の異常なアクティビティを確認するうえで有用です。詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. [データベース フラグ] セクションで、log_connections データベース フラグを [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log duration disabled

API のカテゴリ名: SQL_LOG_DURATION_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_duration データベース フラグが [オン] に設定されていません。

log_duration が有効になっている場合、完了した各ステートメントの実行時刻と実行時間がログに記録されます。クエリの実行時間をモニタリングすることは、遅いクエリの特定やデータベースの問題のトラブルシューティングにおいて非常に重要です。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、log_duration データベース フラグを [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log error verbosity

API のカテゴリ名: SQL_LOG_ERROR_VERBOSITY

Cloud SQL for PostgreSQL データベース インスタンスで、log_error_verbosity データベース フラグが default または verbose に設定されていません。

log_error_verbosity フラグは、ログに記録されるメッセージの詳細情報の量を制御します。詳細度が高いほど、より詳細な情報がメッセージに記録されます。このフラグを default または verbose に設定することをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit 編集] をクリックします。

4. [データベース フラグ] セクションで、log_error_verbosity データベース フラグを default または verbose に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log lock waits disabled

API のカテゴリ名: SQL_LOG_LOCK_WAITS_DISABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_lock_waits のデータベース フラグがオンに設定されていません。

log_lock_waits 設定を有効にすると、セッション待機が deadlock_timeout よりも長くなるとログエントリが作成されます。このログは、ロック待機がパフォーマンスを低下の原因であるかどうかの判断に役立ちます。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. [データベース フラグ] セクションで、[log_lock_waits] データベース フラグに値「オン」を設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. [データベース フラグ] セクションで、log_min_duration_statement データベース フラグを値「-1」に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、組織のロギング ポリシーに応じて、log_min_error_statement データベース フラグに次のいずれかの推奨値を設定します。

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、組織のロギング ポリシーに応じて、log_min_error_statement データベース フラグに次のいずれかの推奨値を設定します。

   • error
   • log
   • fatal
   • panic

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log min messages

API のカテゴリ名: SQL_LOG_MIN_MESSAGES

Cloud SQL for PostgreSQL データベース インスタンスで、log_min_messages データベース フラグが warning 以上に設定されていません。

log_min_messages フラグは、サーバーログに記録されるメッセージ レベルを制御します。重要度が高いほど、記録されるメッセージは少なくなります。しきい値を低く設定しすぎると、ログのストレージ サイズと長さが増加し、実際のエラーを見つけるのが困難になります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、組織のロギング ポリシーに応じて、log_min_messages データベース フラグに次のいずれかの推奨値を設定します。

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log executor stats enabled

API のカテゴリ名: SQL_LOG_EXECUTOR_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_executor_stats データベース フラグが [オフ] に設定されていません。

log_executor_stats フラグを有効にすると、各クエリの PostgreSQL ログにエグゼキュータのパフォーマンス統計が記載されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit 編集] をクリックします。

4. [データベース フラグ] セクションで、log_executor_stats データベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log hostname enabled

API のカテゴリ名: SQL_LOG_HOSTNAME_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_hostname データベース フラグが [オフ] に設定されていません。

log_hostname フラグを有効にすると、接続しているホストのホスト名が記録されます。デフォルトでは、接続のログ メッセージには IP アドレスのみが表示されます。この設定はトラブルシューティングに役立ちます。ただし、ログに記録される各ステートメントで、IP アドレスをホスト名に変換するために DNS 解決が必要なため、サーバーのパフォーマンスにオーバーヘッドが発生する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、log_hostname データベース フラグをオフに設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log parser stats enabled

API のカテゴリ名: SQL_LOG_PARSER_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_parser_stats データベース フラグが [オフ] に設定されていません。

log_parser_stats フラグを有効にすると、各クエリの PostgreSQL ログにパーサー パフォーマンス統計が記録されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、log_parser_stats データベース フラグをオフに設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log planner stats enabled

API のカテゴリ名: SQL_LOG_PLANNER_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_planner_stats データベース フラグが [オフ] に設定されていません。

log_planner_stats フラグを有効にすると、PostgreSQL プランナーのパフォーマンス統計をロギングするための粗分析のプロファイリング メソッドが使用されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、log_planner_stats データベース フラグをオフに設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log statement

API のカテゴリ名: SQL_LOG_STATEMENT

Cloud SQL for PostgreSQL データベース インスタンスで、log_statement データベース フラグが ddl に設定されていません。

このフラグの値により、ログに記録される SQL ステートメントを制御できます。ロギングによって、運用上の問題のトラブルシューティングとフォレンジック分析が可能になります。このフラグが正しい値に設定されていないと、関連する情報がスキップされるか、多くのメッセージで非表示になる可能性があります。組織のロギング ポリシーで別途指示がない限り、値「ddl」（すべてのデータ定義ステートメント）をおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit 編集] をクリックします。

4. [データベース フラグ] セクションで、log_statement データベース フラグを ddl に設定します。

5. [Save] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log statement stats enabled

API のカテゴリ名: SQL_LOG_STATEMENT_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_statement_stats データベース フラグが [オフ] に設定されていません。

log_statement_stats フラグを有効にすると、各クエリの PostgreSQL ログにエンドツーエンドのパフォーマンス統計が記録されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、log_statement_stats データベース フラグを オフ に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log temp files

API のカテゴリ名: SQL_LOG_TEMP_FILES

Cloud SQL for PostgreSQL データベース インスタンスで、log_temp_files のデータベース フラグが「0」に設定されていません。

一時ファイルを、並べ替え、ハッシュ、一時的なクエリ結果のために作成できます。log_temp_files フラグを 0 に設定すると、すべての一時ファイルの情報がログに記録されます。一時ファイルをすべてログに記録すると、潜在的なパフォーマンスの問題の特定に役立ちます。詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. edit [編集] をクリックします。

4. [データベース フラグ] セクションで、log_temp_files データベース フラグに値「0」を設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL no root password

API のカテゴリ名: SQL_NO_ROOT_PASSWORD

MySQL データベース インスタンスの root アカウントのパスワードが設定されていません。MySQL データベース インスタンスにパスワードを追加する必要があります。詳細については、MySQL ユーザーをご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. 読み込まれた [インスタンスの詳細] ページで、[ユーザー] タブを選択します。

4. root ユーザーの横にある [その他] をクリックしてから、[パスワードを変更] を選択します。

5. 新しい強力なパスワードを入力してから [OK] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL public IP

API のカテゴリ名: SQL_PUBLIC_IP

Cloud SQL データベースに、パブリック IP アドレスがあります。

組織の攻撃対象を軽減するために、Cloud SQL データベースにはパブリック IP アドレスを含めないでください。プライベート IP アドレスを使用すると、ネットワーク セキュリティを高め、アプリケーションのレイテンシを低減できます。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. 左側のメニューで [接続] をクリックします。

4. [ネットワーキング] タブをクリックし、[パブリック IP] チェックボックスをオフにします。

5. インスタンスでまだプライベート IP を使用するように構成されていない場合は、既存のインスタンスにプライベート IP を構成するをご覧ください。

6. [保存] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL remote access enabled

API のカテゴリ名: SQL_REMOTE_ACCESS_ENABLED

Cloud SQL for SQL Server データベース インスタンスで、remote access データベース フラグが [オフ] に設定されていません。

有効にすると、リモート サーバーからローカル ストアド プロシージャを実行する権限またはローカル サーバーからリモート ストアド プロシージャを実行する権限が付与されます。この機能が悪用されて、クエリ処理をターゲットにオフロードすることにより、リモート サーバーに対するサービス拒否（DoS）攻撃が開始される恐れがあります。不正使用を防ぐため、この設定を無効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [フラグ] セクションで、[remote access] をオフに設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL skip show database disabled

API のカテゴリ名: SQL_SKIP_SHOW_DATABASE_DISABLED

Cloud SQL for MySQL データベース インスタンスで、skip_show_database データベース フラグが [オン] に設定されていません。

このフラグをオンにすると、SHOW DATABASES 権限のないユーザーによる SHOW DATABASES ステートメントの使用を防止できます。この設定では、明示的な権限のないユーザーは、他のユーザーに属するデータベースを表示できません。このフラグを有効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [フラグ] セクションで、skip_show_database を [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL trace flag 3625

API のカテゴリ名: SQL_TRACE_FLAG_3625

Cloud SQL for SQL Server データベース インスタンスで、3625（トレースフラグ）データベース フラグが [オン] に設定されていません。

このフラグは、一部のエラー メッセージのパラメータをアスタリスク（******）でマスクすることで、sysadmin 固定サーバーロールのメンバーではないユーザーに返される情報の量を制限します。機密情報の漏洩を防ぐため、このフラグを有効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、[3625] をオンに設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、[ユーザー接続] の横にある [削除] をクリックします。delete

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL user options configured

API のカテゴリ名: SQL_USER_OPTIONS_CONFIGURED

Cloud SQL for SQL Server データベース インスタンスで、user options データベース フラグが構成されています。

この設定により、すべてのユーザーの SET オプションのグローバル デフォルト値がオーバーライドされます。ユーザーおよびアプリケーションは、デフォルトのデータベース SET オプションが使用されていることを前提としている場合があるため、ユーザー オプションを設定すると予期しない結果が生じる可能性があります。このため、ユーザー オプション データベース フラグを構成することはおすすめしません。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [edit編集] をクリックします。

4. [データベース フラグ] セクションで、[ユーザー オプション] の横にある [削除] をクリックします。delete

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL weak root password

API のカテゴリ名: SQL_WEAK_ROOT_PASSWORD

MySQL データベース インスタンスのルート アカウントに脆弱なパスワードが設定されています。インスタンスに安全なパスワードを設定する必要があります。詳細については、MySQL ユーザーをご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. 読み込まれた [インスタンスの詳細] ページで、[ユーザー] タブを選択します。

4. root ユーザーの横にある [その他] をクリックしてから、[パスワードを変更] を選択します。

5. 新しい強力なパスワードを入力してから [OK] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

SSL not enforced

API のカテゴリ名: SSL_NOT_ENFORCED

Cloud SQL データベース インスタンスが、すべての受信接続に SSL の使用を必要としていません。

暗号化されていない通信でのセンシティブ データの漏洩を回避するために、SQL データベース インスタンスへのすべての着信接続で SSL を使用する必要があります。詳しくは、SSL / TLS の構成をご覧ください。

この検出結果を修正するには、SQL インスタンスに対して SSL 接続のみを許可します。

1. Google Cloud コンソールで [Cloud SQL インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [接続] タブで、[SSL 接続のみ許可] または [信頼できるクライアント証明書を必須にする] をクリックします。詳細については、SSL / TLS 暗号化を適用するをご覧ください。

4. [信頼できるクライアント証明書を必須にする] を選択した場合は、新しいクライアント証明書を作成します。詳細については、新しいクライアント証明書を作成するをご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Too many KMS users

API のカテゴリ名: TOO_MANY_KMS_USERS

暗号鍵を使用できるプリンシパル ユーザーの数を 3 人に制限します。事前定義された以下のロールは、暗号鍵を使用してデータを暗号化、復号、署名する権限を付与します。

• roles/owner
• roles/cloudkms.cryptoKeyEncrypterDecrypter
• roles/cloudkms.cryptoKeyEncrypter
• roles/cloudkms.cryptoKeyDecrypter
• roles/cloudkms.signer
• roles/cloudkms.signerVerifier

詳細については、権限とロールをご覧ください。

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

この検出結果を修正するには、次の操作を行います。

1. Google Cloud コンソールで [Cloud KMS 鍵] ページに移動します。

   [Cloud KMS 鍵] に移動

2. 検出結果内に示されたキーリングの名前をクリックします。

3. 検出結果内に示されたキーの名前をクリックします。

4. メインのバージョンの横にあるボックスをオンにしてから、[情報パネルを表示] をクリックします。

5. データの暗号化、復号、署名を行う権限を持つプリンシパルの数を 3 以下に減らします。権限を取り消すには、各プリンシパルの横にある [delete削除] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Unconfirmed AppArmor profile

API のカテゴリ名: GKE_APP_ARMOR

コンテナは、AppArmor による制約を受けないように明示的に構成できます。 これにより、AppArmor プロファイルはコンテナに適用されないため、プロファイルによって制約されません。予防的なセキュリティ管理が無効であるため、コンテナ エスケープのリスクが高くなります。

この検出結果を修正するには、影響を受けるワークロードに次の手順を適用します。

1. 影響を受けるワークロードのマニフェストを開きます。
2. 次の制限付きフィールドに、使用できる値のいずれかを設定します。

制限付きフィールド

• metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]

使用できる値

• false

User managed service account key

API のカテゴリ名: USER_MANAGED_SERVICE_ACCOUNT_KEY

ユーザーがサービス アカウント キーを管理しています。 サービス アカウント キーが正しく管理されていない場合は、セキュリティ リスクが発生します。可能であれば、サービス アカウント キーよりも安全な代替手段を選択してください。サービス アカウント キーで認証する必要がある場合は、秘密鍵のセキュリティと、サービス アカウント キーの管理のベスト プラクティスで説明されているその他の操作は、ユーザーの責任になります。サービス アカウント キーを作成できない場合は、組織でサービス アカウント キーの作成が無効になっている可能性があります。詳細については、デフォルトで安全な組織リソースの管理をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [サービス アカウント] ページに移動します。

   [サービス アカウント] に移動

2. 必要に応じて、検出結果内で示されているプロジェクトを選択します。

3. 検出結果で示されているユーザー管理のサービス アカウント キーを削除します（どのアプリケーションでも使用されていない場合）。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Weak SSL policy

API のカテゴリ名: WEAK_SSL_POLICY

Compute Engine インスタンスに脆弱な SSL ポリシーがあるか、TLS バージョン 1.2 より前のデフォルトの Google Cloud SSL ポリシーを使用しています。

HTTPS および SSL プロキシ ロードバランサは、SSL ポリシーを使用して、ユーザーとインターネットの間で確立される TLS 接続で使用されるプロトコルと暗号スイートを決定します。これらの接続は、悪意のある傍受者がそのデータにアクセスできないようにデータを暗号化します。弱い SSL ポリシーの場合、古いバージョンの TLS を使用するクライアントは、安全性の低い暗号スイートまたはプロトコルを使用して接続できます。推奨されている暗号スイートと古い暗号スイートのリストについては、[iana.org の TLS パラメータ ページ] をご覧ください。

Security Command Center プレミアム ティアをプロジェクト レベルで有効にする場合は、親組織でスタンダード ティアが有効になっている場合に限りこの検出結果を利用できます。

この検出結果の修正手順は、この検出結果が、デフォルトの Google Cloud SSL ポリシーの使用によってトリガーされたのか、脆弱な暗号スイートや TLS バージョン 1.2 より前の最小バージョンを許可する SSL ポリシーの使用によってトリガーされたのかによって異なります。検出結果のトリガーに対応する以下の手順を行います。

デフォルトの Google Cloud SSL ポリシーのデフォルトの修正

1. Google Cloud コンソールで [ターゲット プロキシ] ページに移動します。

   [ターゲット プロキシ] に移動

2. 検出結果内で示されているターゲット プロキシを見つけて、[使用中] 列の転送ルールをメモします。

3. 新しい SSL ポリシーを作成するには、SSL ポリシーの使用をご覧ください。ポリシーには、最小 TLS バージョンが 1.2 で、モダンまたは制限付きのプロファイルが必要です。

4. カスタム プロファイルを使用するには、次の暗号スイートが無効になっていることを確認してください。

   • TLS_RSA_WITH_AES_128_GCM_SHA256
   • TLS_RSA_WITH_AES_256_GCM_SHA384
   • TLS_RSA_WITH_AES_128_CBC_SHA
   • TLS_RSA_WITH_AES_256_CBC_SHA
   • TLS_RSA_WITH_3DES_EDE_CBC_SHA

5. 以前にメモした各転送ルールに SSL ポリシーを適用します。

脆弱な暗号スイートまたは下位レベルの TLS バージョンで許可される修正

1. Google Cloud コンソールで、[SSL ポリシー] ページに移動します。

   [SSL ポリシー] に移動

2. [使用中] 列に示されているロードバランサを見つけます。

3. ポリシー名の下をクリックします。

4. [edit編集] をクリックします。

5. [TLS の最小バージョン] を TLS 1.2 に、[プロファイル] を [モダン] または [制限付き] に変更します。

6. カスタム プロファイルを使用するには、次の暗号スイートが無効になっていることを確認してください。

   • TLS_RSA_WITH_AES_128_GCM_SHA256
   • TLS_RSA_WITH_AES_256_GCM_SHA384
   • TLS_RSA_WITH_AES_128_CBC_SHA
   • TLS_RSA_WITH_AES_256_CBC_SHA
   • TLS_RSA_WITH_3DES_EDE_CBC_SHA

7. [保存] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Web UI enabled

API のカテゴリ名: WEB_UI_ENABLED

GKE ウェブ UI（ダッシュボード）が有効になっています。

高い権限を持つ Kubernetes サービス アカウントは、Kubernetes ウェブ インターフェースに貢献します。不正使用が発生すると、サービス アカウントが不正使用される可能性があります。すでに Google Cloud コンソールを使用している場合、Kubernetes のウェブ インターフェースを使用すると、攻撃対象領域が不必要に広がります。詳しくは、Kubernetes ウェブ インターフェースを無効にするをご覧ください。

この検出結果を修正するには、Kubernetes ウェブ インターフェースを無効にします。

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. Security Health Analytics の検出結果に記載されたクラスタの名前をクリックします。

3. edit [編集] をクリックします。

   クラスタの構成を変更した直後は、編集ボタンが無効になっていることがあります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

4. [アドオン] をクリックします。セクションが展開され、使用可能なアドオンが表示されます。

5. [Kubernetes ダッシュボード] プルダウン リストで、[無効] を選択します。

6. [保存] をクリックします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Workload Identity disabled

API のカテゴリ名: WORKLOAD_IDENTITY_DISABLED

Workload Identity が GKE クラスタで無効になっています。

Workload Identity は、セキュリティのプロパティと管理性が優れているため、GKE 内から Google Cloud サービスにアクセスするためのおすすめの方法です。有効にすると、潜在的に機密性の高い一部のシステム メタデータを、クラスタ上で実行中のユーザーのワークロードから保護できます。詳しくは、メタデータ隠蔽をご覧ください。

この検出結果を修正するには、クラスタで Workload Identity を有効にするためのガイドに沿って操作してください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

AWS の構成ミスを修正する

AWS Cloud Shell Full Access Restricted

API のカテゴリ名: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

AWS CloudShell は、AWS サービスに対して CLI コマンドを実行するための便利な方法です。マネージド IAM ポリシー（「AWSCloudShellFullAccess」）は、CloudShell への完全アクセス権を提供し、ユーザーのローカル システムと CloudShell 環境の間でファイルのアップロードとダウンロードを可能にします。CloudShell 環境内ではユーザーに sudo 権限が付与され、インターネットにアクセスできます。そのため、たとえばファイル転送ソフトウェアをインストールして、CloudShell から外部インターネット サーバーにデータを移動できます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Access Keys Rotated Every 90 Days or Less

API のカテゴリ名: ACCESS_KEYS_ROTATED_90_DAYS_LESS

アクセスキーは、アクセスキー ID とシークレット アクセスキーで構成されます。これらは、AWS に対するプログラムによるリクエストに署名するために使用されます。AWS ユーザーは、AWS コマンドライン インターフェース（AWS CLI）、Tools for Windows PowerShell、AWS SDK から AWS へのプログラムでの呼び出し、または個々の AWS サービスの API を使用して直接 HTTP 呼び出しを実行するために、独自のアクセスキーが必要です。すべてのアクセスキーを定期的にローテーションすることをおすすめします。

aws iam create-access-key

aws iam get-access-key-last-used

aws iam update-access-key

aws iam delete-access-key

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

All Expired Ssl Tls Certificates Stored Aws Iam Removed

API のカテゴリ名: ALL_EXPIRED_SSL_TLS_CERTIFICATES_STORED_AWS_IAM_REMOVED

AWS でウェブサイトまたはアプリケーションへの HTTPS 接続を有効にするには、SSL / TLS サーバー証明書が必要です。ACM または IAM を使用して、サーバー証明書の格納とデプロイを行うことができます。
IAM を証明書マネージャーとして使用するのは、ACM でサポートされていないリージョンで HTTPS 接続をサポートする必要がある場合のみです。IAM は秘密鍵を安全に暗号化し、暗号化されたバージョンを IAM SSL 証明書ストレージに保存します。IAM は、すべてのリージョンでサーバー証明書のデプロイをサポートしていますが、AWS で使用する証明書は外部プロバイダから取得する必要があります。ACM 証明書は IAM にアップロードできません。また、IAM コンソールから証明書を管理することはできません。

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Autoscaling Group Elb Healthcheck Required

API のカテゴリ名: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

これにより、ロードバランサに関連付けられた自動スケーリング グループが Elastic Load Balancing のヘルスチェックを使用しているかどうかを確認します。

これにより、ロードバランサによって提供される追加テストに基づいて、グループがインスタンスの健全性を判断できるようになります。Elastic Load Balancing ヘルスチェックを使用すると、EC2 自動スケーリング グループを使用するアプリケーションの可用性をサポートできます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Auto Minor Version Upgrade Feature Enabled Rds Instances

API のカテゴリ名: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

指定したメンテナンスの時間枠内にマイナー エンジン アップグレードを自動的に受け取るために、RDS データベース インスタンスでマイナー バージョン アップグレード フラグが有効になっていることを確認します。これにより、RDS インスタンスは、データベース エンジンの新機能、バグ修正、セキュリティ パッチを取得できます。

aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'

aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately

aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Aws Config Enabled All Regions

API のカテゴリ名: AWS_CONFIG_ENABLED_ALL_REGIONS

AWS Config は、アカウント内でサポートされている AWS リソースの構成管理を行い、ログファイルを配信するウェブサービスです。記録される情報には、構成項目（AWS リソース）、構成項目（AWS リソース）間の関係、リソース間の構成変更が含まれます。AWS Config をすべてのリージョンで有効にすることをおすすめします。

aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::012345678912:role/myConfigRole --recording-group allSupported=true,includeGlobalResourceTypes=true

{
 "name": "default",
 "s3BucketName": "my-config-bucket",
 "snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
 "configSnapshotDeliveryProperties": {
 "deliveryFrequency": "Twelve_Hours"
 }
}

aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json

aws configservice start-configuration-recorder --configuration-recorder-name default

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Aws Security Hub Enabled

API のカテゴリ名: AWS_SECURITY_HUB_ENABLED

Security Hub は、AWS アカウント、サービス、サポートされているパートナー事業者のプロダクトからセキュリティ データを収集し、セキュリティの傾向を分析し、優先度が最も高いセキュリティ問題を特定するのに役立ちます。Security Hub を有効にすると、有効にした AWS サービス（Amazon GuardDuty、Amazon Inspector、Amazon Macie など）の検出結果の使用、集計、整理、優先付けが開始されます。AWS のパートナー セキュリティ プロダクトとの統合を有効にすることもできます。

aws securityhub enable-security-hub --enable-default-standards

aws securityhub enable-security-hub --no-enable-default-standards

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Cloudtrail Logs Encrypted Rest Using Kms Cmks

API のカテゴリ名: CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS

AWS CloudTrail は、アカウントの AWS API 呼び出しを記録し、IAM ポリシーに従ってユーザーとリソースがこれらのログを利用できるようにするウェブサービスです。AWS 鍵管理サービス（KMS）は、アカウント データの暗号化に使用する暗号鍵の作成と制御を支援するマネージド サービスで、ハードウェア セキュリティ モジュール（HSM）を使用して暗号鍵のセキュリティを保護します。CloudTrailログは、サーバー側での暗号化（SSE）と KMS のお客様が作成したマスターキー（CMK）を活用して、CloudTrail ログをさらに保護するように構成できます。SSE-KMS を使用するように CloudTrail を構成することをおすすめします。

aws cloudtrail update-trail --name <trail_name> --kms-id <cloudtrail_kms_key>
aws kms put-key-policy --key-id <cloudtrail_kms_key> --policy <cloudtrail_kms_key_policy>

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Cloudtrail Log File Validation Enabled

API のカテゴリ名: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

CloudTrail ログファイルの検証では、CloudTrail が S3 に書き込む各ログのハッシュを含むデジタル署名されたダイジェスト ファイルが作成されます。これらのダイジェスト ファイルを使用すると、CloudTrail がログを配信した後にログファイルが変更されたか、削除されたか、変更されていないかを判断できます。すべての CloudTrail でファイル検証を有効にすることをおすすめします。

aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation

aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Cloudtrail Trails Integrated Cloudwatch Logs

API のカテゴリ名: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS

AWS CloudTrail は、特定の AWS アカウントで行われた AWS API 呼び出しを記録するウェブサービスです。記録される情報には、API 呼び出し元の ID、API 呼び出しの時刻、API 呼び出し元のソース IP アドレス、リクエスト パラメータ、AWS サービスから返されるレスポンス要素が含まれます。CloudTrail は、ログファイルの保存と配信に Amazon S3 を使用するため、ログファイルは永続的に保存されます。長期分析のために指定した S3 バケット内の CloudTrail ログをキャプチャするだけでなく、CloudWatch Logs にログを送信するように CloudTrail を構成することでリアルタイム分析を実行できます。アカウント内のすべてのリージョンで有効になっている証跡の場合、CloudTrail はすべてのリージョンのログファイルを CloudWatch Logs ロググループに送信します。CloudTrail ログを CloudWatch Logs に送信することをおすすめします。

注: この推奨事項の目的は、AWS アカウントのアクティビティキャプチャされ、監視され、適切に警告されるようにすることです。CloudWatch Logs は、AWS サービスを使用してこれを行うネイティブな方法ですが、代替ソリューションの使用が排除されるわけではありません。

aws cloudtrail update-trail --name <trail_name> --cloudwatch-logs-log-group-arn <cloudtrail_log_group_arn> --cloudwatch-logs-role-arn <cloudtrail_cloudwatchLogs_role_arn>

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Cloudwatch Alarm Action Check

API のカテゴリ名: CLOUDWATCH_ALARM_ACTION_CHECK

これにより、Amazon Cloudwatch で、アラームが「OK」、「ALARM」、「INSUFFICIENT_DATA」の状態の間で遷移したときのアクションが定義されているかどうかがチェックされます。

Amazon CloudWatch のアラームで ALARM 状態に対するアクションを構成することは、モニタリング対象指標のしきい値に達したときに即時に応答するために非常に重要です。
これにより、問題を迅速に解決し、ダウンタイムを低減できます。また、自動修正やシステムの健全性の維持、システム停止の防止を実現できます。

アラームには少なくとも 1 つのアクションがあります。
アラームが他の状態から「INSUFFICIENT_DATA」状態に移行するとき、アラームには少なくとも 1 つのアクションがあります。
（省略可）アラームが他の状態から「OK」状態に移行すると、アラームには少なくとも 1 つのアクションがあります。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Cloudwatch Log Group Encrypted

API のカテゴリ名: CLOUDWATCH_LOG_GROUP_ENCRYPTED

このチェックにより、CloudWatch ログが KMS で構成されていることを確認できます。

ロググループのデータは、CloudWatch Logging で常に暗号化されます。デフォルトでは、CloudWatch Logs は保存ログデータにサーバーサイド暗号化を使用します。この暗号化には、代わりに AWS 鍵管理サービスを使用できます。暗号化が必要な場合は、AWS KMS 鍵を使用して暗号化が行われます。AWS KMS を使用した暗号化は、ロググループの作成時または作成後に KMS 鍵をロググループに関連付けることで、ロググループ レベルで有効になります。

詳細については、Amazon CloudWatch ユーザーガイドの AWS Key Management Service を使用して CloudWatch Logs のログデータを暗号化するをご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

CloudTrail CloudWatch Logs Enabled

API のカテゴリ名: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

このコントロールは、CloudWatch Logs にログを送信するように CloudTrail の証跡が構成されているかどうかを確認します。証跡の CloudWatchLogsLogGroupArn プロパティが空の場合、コントロールは失敗します。

CloudTrail は、特定のアカウントで行われた AWS API 呼び出しを記録します。記録される情報には次のようなものがあります。

• API 呼び出し元の ID
• API 呼び出しの時間
• API 呼び出し元の送信元 IP アドレス
• リクエストのパラメータ
• AWS サービスから返されたレスポンス要素

CloudTrail は、ログファイルの保存と配信に Amazon S3 を使用します。長期的な分析のために、指定した S3 バケット内の CloudTrail ログをキャプチャできます。リアルタイム分析を実行するには、CloudWatch Logs にログを送信するように CloudTrail を構成します。

アカウント内のすべてのリージョンで有効になっている証跡の場合、CloudTrail はすべてのリージョンから CloudWatch Logs ロググループにログファイルを送信します。

Security Hub では、CloudTrail ログを CloudWatch Logs に送信することをおすすめします。この推奨事項は、アカウント アクティビティを確実にキャプチャ、モニタリングし、適切に警告することを目的としています。CloudWatch Logs を使用して、AWS サービスでこれを設定できます。この推奨事項は、別のソリューションの使用を排除するものではありません。

CloudTrail のログを CloudWatch Logs に送信すると、ユーザー、API、リソース、IP アドレスに基づいたリアルタイムと過去のアクティビティ ロギングが容易になります。このアプローチを使用すると、異常なアカウント アクティビティや機密性の高いアカウント アクティビティに対するアラームと通知を設定できます。

CloudTrail と CloudWatch ログを統合するには、AWS CloudTrail ユーザーガイドの CloudWatch ログにイベントを送信するをご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

No AWS Credentials in CodeBuild Project Environment Variables

API のカテゴリ名: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK

これにより、プロジェクトに環境変数 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY が含まれているかどうかをチェックします。

認証情報 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY は、意図しないデータ漏洩や不正アクセスにつながる可能性があるため、クリアテキストで保存しないでください。

CodeBuild プロジェクトから環境変数を削除するには、AWS CodeBuild ユーザーガイドの AWS CodeBuild でビルド プロジェクトの設定を変更するをご覧ください。[環境変数] で何も選択されていないことを確認します。

AWS Systems Manager Parameter Store または AWS Secrets Manager に機密性の高い値を含む環境変数を保存し、ビルド仕様からそれらを取得できます。手順については、AWS CodeBuild ユーザーガイドの環境セクションで重要というラベルの付いたボックスをご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Codebuild Project Source Repo Url Check

API のカテゴリ名: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

これにより、AWS CodeBuild プロジェクトの Bitbucket ソース リポジトリ URL に個人用アクセス トークンが含まれているか、ユーザー名とパスワードが含まれているかをチェックします。Bitbucket ソース リポジトリの URL に個人用アクセス トークンまたはユーザー名とパスワードが含まれている場合、コントロールは失敗します。

ログイン認証情報を、クリアテキストで保存または送信することや、ソース リポジトリの URL に表示することはしないでください。個人用アクセス トークンまたはログイン認証情報の代わりに、CodeBuild でソース プロバイダにアクセスし、ソース リポジトリの URL を変更して Bitbucket リポジトリのロケーションへのパスのみを含める必要があります。個人用のアクセス トークンやログイン認証情報を使用すると、意図しないデータ漏洩や不正アクセスが発生する可能性があります。

OAuth を使用するように CodeBuild プロジェクトを更新できます。

CodeBuild プロジェクト ソースから基本認証 /（GitHub）個人用アクセス トークンを削除するには

1. https://console.aws.amazon.com/codebuild/ で CodeBuild コンソールを開きます。
2. 個人用アクセス トークンまたはユーザー名とパスワードを含むビルド プロジェクトを選択します。
3. [編集] で [ソース] を選択します。
4. [GitHub / Bitbucket との接続を解除] を選択します。
5. [OAuth を使用して接続] を選択してから、[GitHub / Bitbucket に接続] を選択します。
6. メッセージが表示されたら、必要に応じて承認を選択します。
7. 必要に応じて、リポジトリ URL とその他の構成設定を再構成します。
8. [ソースを更新] を選択します。

詳細については、AWS CodeBuild ユーザーガイドの CodeBuild のユースケース ベースのサンプルをご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Credentials Unused 45 Days Greater Disabled

API のカテゴリ名: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

AWS IAM ユーザーは、パスワードやアクセスキーなど、さまざまな種類の認証情報を使用して AWS リソースにアクセスできます。45 日以上未使用の認証情報はすべて無効にするか削除することをおすすめします。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Default Security Group Vpc Restricts All Traffic

API のカテゴリ名: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

VPC にはデフォルトのセキュリティ グループがあり、初期設定では、すべての受信トラフィックが拒否され、すべての送信トラフィックが許可され、セキュリティ グループに割り当てられたインスタンス間のすべてのトラフィックが許可されます。インスタンスを起動するときにセキュリティ グループを指定しない場合、インスタンスは自動的にこのデフォルト セキュリティ グループに割り当てられます。セキュリティ グループは、AWS リソースに上り（内向き）と下り（外向き）のネットワーク トラフィックのステートフル フィルタリングを提供します。デフォルト セキュリティ グループですべてのトラフィックを制限することをおすすめします。

すべてのリージョンのデフォルトの VPC では、準拠するようにデフォルトのセキュリティ グループを更新する必要があります。新しく作成された VPC には、この推奨事項に準拠する修復が必要なデフォルトのセキュリティ グループが自動的に含まれます。

注: この推奨事項を実装する際には、VPC フローロギングによって現在のセキュリティ グループで発生したすべてのパケットの受け入れと拒否をログに記録できるため、システムが正常に動作するために必要な最小権限のポートアクセスを決定するうえで、VPC フローロギングが役立ちます。これにより、環境内のシステムで必要とされる最小限のポートの検出、すなわち最小権限エンジニアリングへの主要な障壁が劇的に軽減します。このベンチマークの VPC フローロギングの推奨事項が永続的なセキュリティ対策として導入されていない場合でも、最小限の権限のセキュリティ グループの検出とエンジニアリングの実行中に使用する必要があります。

セキュリティ グループのメンバー

規定の状態を実装するには、次の操作を行います。

1. デフォルトのセキュリティ グループ内に存在する AWS リソースを特定する
2. これらのリソースに最小権限のセキュリティ グループを作成します。
3. これらのセキュリティ グループにリソースを配置する
4. #1 でメモしたリソースをデフォルトのセキュリティ グループから削除する

セキュリティ グループの状態

1. https://console.aws.amazon.com/vpc/home で AWS 管理コンソールにログインする
2. 各 AWS リージョンのデフォルト VPC を含むすべての VPC に対して、次の手順を繰り返します。
3. 左側のペインで [Security Groups] をクリックする
4. デフォルトのセキュリティ グループごとに、次の操作を行います。
5. default セキュリティ グループを選択する
6. [Inbound Rules] タブをクリックする
7. インバウンド ルールを削除する
8. [Outbound Rules] タブをクリックする
9. アウトバウンド ルールを削除する

推奨:

IAM グループでは、[name] フィールドを編集できます。すべてのリージョンのすべての VPC のデフォルト グループルールを修正したら、このフィールドを編集して「使用しないこと。ルールを追加しない」のようなテキストを追加する

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Dms Replication Not Public

API のカテゴリ名: DMS_REPLICATION_NOT_PUBLIC

AWS DMS レプリケーション インスタンスがパブリックかどうかを確認します。これを行うには、PubliclyAccessible フィールドの値を調べます。

プライベート レプリケーション インスタンスにはプライベート IP アドレスがあり、レプリケーション ネットワークの外部からアクセスすることはできません。ソース データベースとターゲット データベースが同じネットワークにある場合、レプリケーション インスタンスにはプライベート IP アドレスが必要です。また、ネットワークは、VPN、AWS Direct Connect、または VPC ピアリングを使用してレプリケーション インスタンスの VPC に接続する必要があります。パブリック レプリケーション インスタンスとプライベート レプリケーション インスタンスの詳細については、AWS Database Migration Service ユーザーガイドのパブリック レプリケーション インスタンスとプライベート レプリケーション インスタンスをご覧ください。

また、AWS DMS インスタンス構成へのアクセスが、承認されたユーザーのみに制限されていることも確認する必要があります。これを行うには、AWS DMS の設定とリソースを変更するユーザーの IAM 権限を制限します。

DMS レプリケーション インスタンスの公開アクセス設定は、作成後に変更できません。公開アクセスの設定を変更するには、現在のインスタンスを削除してから再作成します。[パブリック アクセス可能] のオプションは選択しないでください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Do Setup Access Keys During Initial User Setup All Iam Users Console

API のカテゴリ名: DO_SETUP_ACCESS_KEYS_DURING_INITIAL_USER_SETUP_ALL_IAM_USERS_CONSOLE

AWS コンソールでは、新しい IAM ユーザーの作成時に、デフォルトでチェックボックスがオンになっていません。IAM ユーザー認証情報を作成するときに、必要なアクセス権の種類を決定する必要があります。

プログラムからのアクセス: IAM ユーザーは、API 呼び出し、AWS CLI の使用、または Windows PowerShell のツールの使用が必要になる場合があります。その場合は、そのユーザーのアクセスキー（アクセスキー ID とシークレット アクセスキー）を作成します。

AWS 管理コンソールへのアクセス: ユーザーが AWS 管理コンソールにアクセスする必要がある場合、ユーザーのパスワードを作成します。

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Dynamodb Autoscaling Enabled

API のカテゴリ名: DYNAMODB_AUTOSCALING_ENABLED

これにより、Amazon DynamoDB テーブルが、必要に応じて読み取りおよび書き込み容量をスケーリングできるかどうかを確認します。このコントロールは、テーブルがオンデマンド容量モードまたは自動スケーリングが構成されたプロビジョニング モードのいずれかを使用している場合にパスします。需要に応じて容量をスケーリングすると、スロットリング例外を回避でき、アプリケーションの可用性を維持できます。

オンデマンド容量モードの DynamoDB テーブルは、DynamoDB スループットのデフォルトのテーブル割り当てによってのみ制限されます。これらの割り当てを増やすには、AWS サポートからサポート チケットを提出します。

自動スケーリングが有効なプロビジョニング モードの DynamoDB テーブルは、トラフィック パターンに応じてプロビジョニングされたスループット容量を動的に調整します。DynamoDB リクエスト スロットリングについて詳しくは、Amazon DynamoDB デベロッパー ガイドの「リクエスト スロットリングとバースト容量」をご覧ください。

容量モードの既存のテーブルで DynamoDB 自動スケーリングを有効にする手順については、Amazon DynamoDB デベロッパー ガイドの既存のテーブルで DynamoDB 自動スケーリングを有効にするをご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Dynamodb In Backup Plan

API のカテゴリ名: DYNAMODB_IN_BACKUP_PLAN

このコントロールは、DynamoDB テーブルがバックアップ プランの対象かどうかを評価します。DynamoDB テーブルがバックアップ プランの対象とならない場合、コントロールは失敗します。このコントロールは、アクティブ状態の DynamoDB テーブルのみを評価します。

バックアップを使用すると、セキュリティ インシデントからより速やかに復旧できます。また、システムのレジリエンスも強化されます。バックアップ プランに DynamoDB テーブルを含めると、意図しない損失や削除からデータを保護できます。

DynamoDB テーブルを AWS Backup のバックアップ プランに追加するには、AWS Backup デベロッパー ガイドのバックアップ プランへのリソースの割り当てをご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Dynamodb Pitr Enabled

API のカテゴリ名: DYNAMODB_PITR_ENABLED

ポイントインタイム リカバリ（PITR）は、DynamoDB テーブルをバックアップするためのメカニズムの 1 つです。

ポイントインタイムのバックアップは 35 日間保持されます。長期保存が必要な場合は、AWS ドキュメントの AWS Backup を使用して Amazon DynamoDB のスケジュールされたバックアップを設定するをご覧ください。

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  point_in_time_recovery {
    enabled = true
  }
}

aws dynamodb update-continuous-backups \
  --table-name "GameScoresOnDemand" \
  --point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Dynamodb Table Encrypted Kms

API のカテゴリ名: DYNAMODB_TABLE_ENCRYPTED_KMS

すべての DynamoDB テーブルが、顧客管理の KMS 鍵（デフォルト以外）で暗号化されているかどうかを確認します。

resource "aws_kms_key" "dynamodb_encryption" {
  description         = "Used for DynamoDB encryption configuration"
  enable_key_rotation = true
}

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  server_side_encryption {
    enabled     = true
    kms_key_arn = aws_kms_key.dynamodb_encryption.arn
  }
}

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ebs Optimized Instance

API のカテゴリ名: EBS_OPTIMIZED_INSTANCE

EBS 用に最適化できる EC2 インスタンスで EBS の最適化が有効になっているかどうかを確認する

EBS の最適化インスタンス設定を構成するには、Amazon EC2 ユーザーガイドの Amazon EBS 用に最適化されたインスタンスをご覧ください。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ebs Snapshot Public Restorable Check

API のカテゴリ名: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

Amazon Elastic Block Store スナップショットが公開されていないことを確認します。Amazon EBS スナップショットが誰でも復元可能である場合、コントロールは失敗します。

EBS スナップショットは、特定の時点で EBS ボリューム上のデータを Amazon S3 へバックアップするのに使用されます。スナップショットを使用して、EBS ボリュームの以前の状態を復元できます。スナップショットを一般公開することが許容されることはほとんどありません。通常、スナップショットを一般公開する決定は誤りか、その影響を十分に理解することなく行われたものです。このチェックにより、そのような共有がすべて完全に計画され、意図されたものであることを確認できます。

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ebs Volume Encryption Enabled All Regions

API のカテゴリ名: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS

Elastic Compute Cloud（EC2）は、Elastic Block Store（EBS）サービスを使用する場合の保存時の暗号化をサポートしています。デフォルトでは無効になっていますが、EBS ボリューム作成時の強制暗号化がサポートされています。

aws --region <region> ec2 enable-ebs-encryption-by-default

read_more この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ec2 Instances In Vpc

API のカテゴリ名: EC2_INSTANCES_IN_VPC

Amazon VPC は、EC2 Classic よりも多くのセキュリティ機能を提供します。すべてのノードを Amazon VPC に所属させることをおすすめします。

  resource "aws_vpc" "example_vpc" {
    cidr_block = "10.0.0.0/16"
  }

  resource "aws_subnet" "example_public_subnet" {
    vpc_id            = aws_vpc.example_vpc.id
    cidr_block        = "10.0.1.0/24"
    availability_zone = "1a"
  }

  resource "aws_internet_gateway" "example_igw" {
    vpc_id = aws_vpc.example_vpc.id
  }

  resource "aws_key_pair" "example_key" {
    key_name   = "web-instance-key"
    public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3F6tyPEFEzV0LX3X8BsXdMsQz1x2cEikKDEY0aIj41qgxMCP/iteneqXSIFZBp5vizPvaoIR3Um9xK7PGoW8giupGn+EPuxIA4cDM4vzOqOkiMPhz5XK0whEjkVzTo4+S0puvDZuwIsdiW9mxhJc7tgBNL0cYlWSYVkz4G/fslNfRPW5mYAM49f4fhtxPb5ok4Q2Lg9dPKVHO/Bgeu5woMc7RY0p1ej6D4CKFE6lymSDJpW0YHX/wqE9+cfEauh7xZcG0q9t2ta6F6fmX0agvpFyZo8aFbXeUBr7osSCJNgvavWbM/06niWrOvYX2xwWdhXmXSrbX8ZbabVohBK41 email@example.com"
  }

  resource "aws_security_group" "web_sg" {
    name   = "http and ssh"
    vpc_id = aws_vpc.some_custom_vpc.id

    ingress {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    ingress {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    egress {
      from_port   = 0
      to_port     = 0
      protocol    = -1
      cidr_blocks = ["0.0.0.0/0"]
    }
  }

  resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    key_name               = aws_key_pair.example_key.name
    monitoring             = true
    subnet_id              = aws_subnet.example_public_subnet.id
    vpc_security_group_ids = [aws_security_group.web_sg.id]
    metadata_options {
      http_tokens = "required"
    }
  }