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

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

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

注: プレミアムのお客様でスタンダード ティアに切り替える予定がある場合は、ティアを変更する前にすべての検出結果を解決することをおすすめします。プレミアム検出機能によってレポートされた検出結果は、スタンダード ティアで自動的に解決できません。詳細については、ティアの切り替えをご覧ください。

Security Health Analytics の修正

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

注意: 適切に修正を行わない場合、リソースの構成を変更すると、本番環境に悪影響が及ぶ可能性があります。また、推奨されている Google Cloud サービスを有効にすると、クラウドの費用が増加する可能性があります。変更を行う前に、すべての修正手順の影響を理解してください。

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

脆弱性または構成ミスの検出結果を修正した後、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. [アクセスの透明性を有効化する] をクリックします。

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

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. [更新] をクリックします。

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

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] をクリックします。

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

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] をクリックします。

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

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] をクリックします。

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

Admin service account

API のカテゴリ名: ADMIN_SERVICE_ACCOUNT

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

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

1. Google Cloud コンソールで IAM ポリシーのページに移動します。

   IAM ポリシーに移動

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

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

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

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 アルファ版の機能を有効にする] が無効になっていることを確認します。

   注: GKE Autopilot を選択した場合、アルファ版クラスタはサポートされていないため、このオプションは表示されません。

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

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

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

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

API key APIs unrestricted

API のカテゴリ名: API_KEY_APIS_UNRESTRICTED

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

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

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

1. Google Cloud コンソールで API キーのページに移動します。

   API キーに移動

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

   1. [API キー] セクションで、API を制限する必要がある API キーの行で アイコンをクリックして、操作メニューを表示します。
   2. 操作メニューから [API キー編集] をクリックします。[API キーを編集] ページが開きます。
   3. [API の制限] で [キーを制限] を選択します。[Select APIs] プルダウン メニューが表示されます。
   4. [Select APIs] プルダウン リストで、許可する API を選択します。

      警告: API 制限を Google Cloud APIs に設定しないでください（Google Cloud APIs は、Google Cloud が提供するすべてのサービスへのアクセスを許可しているため）。

   5. [保存] をクリックします。設定が有効になるまで、最長で 5 分かかる場合があります。

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

API key apps unrestricted

API のカテゴリ名: API_KEY_APPS_UNRESTRICTED

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

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

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

1. Google Cloud コンソールで API キーのページに移動します。

   API キーに移動

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

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

      警告: 任意または広範な HTTP リファラーへのアクセスを許可するワイルドカード文字（例: *、*.[TLD]、.[TLD]/*）を HTTP リファラーに設定しないでください。任意のホストを許可する IP アドレスとリファラー（0.0.0.0、::0、0.0.0.0/0）を設定しないでください。

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

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

API key exists

API のカテゴリ名: API_KEY_EXISTS

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

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

   API の認証情報に移動

3. 削除する API キーの行にある [API キー] セクションで、 アイコンをクリックして操作メニューを表示します。

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

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

API key not rotated

API のカテゴリ名: API_KEY_NOT_ROTATED

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

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

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

1. Google Cloud コンソールで API キーのページに移動します。

   API キーに移動

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

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

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

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. 「その他の操作」 をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

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

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

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

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

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

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

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. それぞれの名前の横にある [削除] をクリックして、リストされた各プリンシパルを削除します。
   2. [保存] をクリックします。

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

   監査ログに移動

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

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

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

Auto backup disabled

API のカテゴリ名: AUTO_BACKUP_DISABLED

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

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

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

1. Google Cloud コンソールで SQL インスタンスのバックアップ ページに移動します。

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

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

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

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

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

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

Auto repair disabled

API のカテゴリ名: AUTO_REPAIR_DISABLED

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

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

Auto upgrade disabled

API のカテゴリ名: AUTO_UPGRADE_DISABLED

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

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

BigQuery table CMEK disabled

API のカテゴリ名: BIGQUERY_TABLE_CMEK_DISABLED

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

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

注意: この修正の手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

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

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

Binary authorization disabled

API のカテゴリ名: BINARY_AUTHORIZATION_DISABLED

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

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

   Binary Authorization に移動

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

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

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

Bucket CMEK disabled

API のカテゴリ名: BUCKET_CMEK_DISABLED

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

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

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

注: デフォルトの鍵を設定しても、バケット内にある現在のオブジェクトは、新しい鍵で遡及的に再暗号化されません。

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

Bucket IAM not monitored

API のカテゴリ名: BUCKET_IAM_NOT_MONITORED

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

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

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、 Google Cloud 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. 「その他の操作」 をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

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

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

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

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

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

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

Bucket logging disabled

API のカテゴリ名: BUCKET_LOGGING_DISABLED

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

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

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

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

Bucket policy only disabled

API のカテゴリ名: BUCKET_POLICY_ONLY_DISABLED

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

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

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

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

   Cloud Storage ブラウザに移動

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

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

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

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

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

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

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. [編集] をクリックします。

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

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

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

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

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

Cluster monitoring disabled

API のカテゴリ名: CLUSTER_MONITORING_DISABLED

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

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

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

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

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

Cluster private Google access disabled

API のカテゴリ名: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cluster secrets encryption disabled

API のカテゴリ名: CLUSTER_SECRETS_ENCRYPTION_DISABLED

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

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

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

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

   Cloud KMS 鍵に移動

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

Cluster shielded nodes disabled

API のカテゴリ名: CLUSTER_SHIELDED_NODES_DISABLED

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

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

Compute project wide SSH keys allowed

API のカテゴリ名: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

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

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

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

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

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

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

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

   注: インスタンス テンプレートを使用して作成されたインスタンスは編集できません。インスタンス テンプレートの構成を変更するには、インスタンス テンプレートを更新する方法をご覧ください。

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

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

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

Compute Secure Boot disabled

API のカテゴリ名: COMPUTE_SECURE_BOOT_DISABLED

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

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

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

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

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

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

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

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

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

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

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

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

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

Compute serial ports enabled

API のカテゴリ名: COMPUTE_SERIAL_PORTS_ENABLED

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

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

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

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

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

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

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

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

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

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

Confidential Computing disabled

API のカテゴリ名: CONFIDENTIAL_COMPUTING_DISABLED

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

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

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

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

注: Confidential Computing は N2D マシンタイプでのみサポートされています。

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

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

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

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

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

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

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

COS not used

API のカテゴリ名: COS_NOT_USED

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

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

Custom role not monitored

API のカテゴリ名: CUSTOM_ROLE_NOT_MONITORED

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

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

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、 Google Cloud 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. 「その他の操作」 をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

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

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

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

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

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

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

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:[e-mail]）。

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

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

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

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

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

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 イメージのバージョン番号は手動でオーバーライドできます。次のようなシナリオを考えます。

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

注意: この修正の手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

Dataset CMEK disabled

API のカテゴリ名: DATASET_CMEK_DISABLED

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

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

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

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

Default network

API のカテゴリ名: DEFAULT_NETWORK

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

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

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

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

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

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

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

Default service account used

API のカテゴリ名: DEFAULT_SERVICE_ACCOUNT_USED

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

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

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

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

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

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

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

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

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

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

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

Disk CMEK disabled

API のカテゴリ名: DISK_CMEK_DISABLED

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

   Compute Engine の [ディスク] に移動

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

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

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

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

Disk CSEK disabled

API のカテゴリ名: DISK_CSEK_DISABLED

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

ディスクの削除と作成

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

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

   Compute Engine の [ディスク] に移動

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

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

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. [保存] をクリックします。

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

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. ネットワークのリストで、VPC ネットワークの名前をクリックします。

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

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

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

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

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

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

DNSSEC disabled

API のカテゴリ名: DNSSEC_DISABLED

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

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

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

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

   [Cloud DNS] に移動

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

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

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

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

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. [作成] をクリックします。

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

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. [保存] をクリックします。 この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Firewall not monitored

API のカテゴリ名: FIREWALL_NOT_MONITORED

注: この検出機能のログベースの指標フィルタは 2021 年 10 月 27 日に変更されました。

ログ指標とアラートが、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. 「その他の操作」 をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

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

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

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

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

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

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

Firewall rule logging disabled

API のカテゴリ名: FIREWALL_RULE_LOGGING_DISABLED

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

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

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

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

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

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

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

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

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

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

Flow logs disabled

API のカテゴリ名: FLOW_LOGS_DISABLED

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

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

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

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

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

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

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

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

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

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

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

Flow logs settings not recommended

API のカテゴリ名: VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

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

注: VPC フローログにより費用が発生する可能性があります。また、CIS ベンチマークの推奨事項は、費用を削減するようには最適化されていません。費用を抑えるには、使用する集計間隔を 15 分、サンプルレートを 5%～10% にします。このようにすると、費用と脅威検出の間で適切なバランスを実現できます。ただし、バランス重視の設定は現在の CIS ベンチマークの推奨事項と一致しないため、このようなバランス重視の設定を使用すると、今後もこのような検出結果が得られます。

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

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

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

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

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

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

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

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

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

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

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

Full API access

API のカテゴリ名: FULL_API_ACCESS

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP load balancer

API のカテゴリ名: HTTP_LOAD_BALANCER

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

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

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

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

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

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

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

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

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

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

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

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

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. 読み込まれた [インスタンスの詳細] ページで、 [停止] をクリックします。

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

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

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

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

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

Integrity monitoring disabled

API のカテゴリ名: INTEGRITY_MONITORING_DISABLED

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

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

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

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

Intranode visibility disabled

API のカテゴリ名: INTRANODE_VISIBILITY_DISABLED

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

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. [作成] をクリックします。

   注: 再構成中のクラスタは変更できません。

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

IP forwarding enabled

API のカテゴリ名: IP_FORWARDING_ENABLED

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

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

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

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

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

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

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

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

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

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

KMS key not rotated

API のカテゴリ名: KMS_KEY_NOT_ROTATED

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

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

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

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

   Cloud KMS 鍵に移動

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

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

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

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

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

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

KMS project has owner

API のカテゴリ名: KMS_PROJECT_HAS_OWNER

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

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

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

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

   [IAM] ページに移動

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

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

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

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

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] のプリンシパルを検索し、[削除] をクリックしてプリンシパルのアクセス権を削除します。

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

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

   暗号鍵

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

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

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

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

KMS role separation

API のカテゴリ名: KMS_ROLE_SEPARATION

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

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

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

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

   [IAM] に移動

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

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

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

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

Legacy authorization enabled

API のカテゴリ名: LEGACY_AUTHORIZATION_ENABLED

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

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

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

Legacy metadata enabled

API のカテゴリ名: LEGACY_METADATA_ENABLED

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

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

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

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

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

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

Legacy network

API のカテゴリ名: LEGACY_NETWORK

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

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

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

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

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

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

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

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

Load balancer logging disabled

API のカテゴリ名: LOAD_BALANCER_LOGGING_DISABLED

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

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

注意: サンプルレートが高いと、ログファイルのストレージ コストが上がる可能性があります。サンプルレートと、ビジネスに適切なストレージ費用のバランスを取る必要があります。

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

1. Google Cloud コンソールの [ロード バランシング] ページに移動します。

   [ロード バランシング] に移動

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

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

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

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

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

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

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

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

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

   注意: 保持ポリシーのロックは元に戻すことができません。バケット全体を削除することによってのみ下に戻せます。詳しくは、バケットロックをご覧ください。

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

Log not exported

API のカテゴリ名: LOG_NOT_EXPORTED

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

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

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

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

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

   [ログルーター] に移動

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

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

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

   注: この手順では、プロジェクト レベルでシンクを作成します。シンクはフォルダレベルや組織レベルでも作成できます。詳細については、Google Cloud コンソールでのログのエクスポートをご覧ください。

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

Master authorized networks disabled

API のカテゴリ名: MASTER_AUTHORIZED_NETWORKS_DISABLED

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

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

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

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

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

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

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

Network not monitored

API のカテゴリ名: NETWORK_NOT_MONITORED

注: この検出機能のログベースの指標フィルタは 2021 年 10 月 27 日に変更されました。

ログ指標とアラートが、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. 「その他の操作」 をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

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

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

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

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

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

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

Network policy disabled

API のカテゴリ名: NETWORK_POLICY_DISABLED

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

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

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

Nodepool boot CMEK disabled

API のカテゴリ名: NODEPOOL_BOOT_CMEK_DISABLED

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

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

Nodepool secure boot disabled

API のカテゴリ名: NODEPOOL_SECURE_BOOT_DISABLED

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

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

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

   Kubernetes クラスタに移動

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

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

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

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

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

Non org IAM member

API のカテゴリ名: NON_ORG_IAM_MEMBER

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

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

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

   [IAM] に移動

2. 組織またはプロジェクト以外のユーザーの横にあるチェックボックスをオンにします。

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

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

Object versioning disabled

API のカテゴリ名: OBJECT_VERSIONING_DISABLED

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

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

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

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

    gsutil versioning set on gs://finding.assetDisplayName

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

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

Open Cassandra port

API のカテゴリ名: OPEN_CASSANDRA_PORT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Open ciscosecure websm port

API のカテゴリ名: OPEN_CISCOSECURE_WEBSM_PORT

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

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

• TCP - 9090

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

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

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

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

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

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

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

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

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

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

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

Open directory services port

API のカテゴリ名: OPEN_DIRECTORY_SERVICES_PORT

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

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

• TCP - 445
• UDP - 445

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

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

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

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

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

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

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

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

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

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

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

Open DNS port

API のカテゴリ名: OPEN_DNS_PORT

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

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

• TCP - 53
• UDP - 53

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

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

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

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

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

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

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

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

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

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

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

Open Elasticsearch port

API のカテゴリ名: OPEN_ELASTICSEARCH_PORT

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

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

• TCP - 9200, 9300

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

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

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

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

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

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

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

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

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

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

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

Open firewall

API のカテゴリ名: OPEN_FIREWALL

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

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

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

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

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

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

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

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

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

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

Open FTP port

API のカテゴリ名: OPEN_FTP_PORT

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

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

• TCP - 21

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

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

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

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

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

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

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

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

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

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

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

Open group IAM member

API のカテゴリ名: OPEN_GROUP_IAM_MEMBER

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

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

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

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

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

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

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

   [IAM] に移動

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

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

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

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

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

Open HTTP port

API のカテゴリ名: OPEN_HTTP_PORT

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

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

• TCP - 80

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

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

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

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

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

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

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

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

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

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

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

Open LDAP port

API のカテゴリ名: OPEN_LDAP_PORT

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

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

• TCP - 389, 636
• UDP - 389

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

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

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

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

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

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

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

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

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

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

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

Open Memcached port

API のカテゴリ名: OPEN_MEMCACHED_PORT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Open MongoDB port

API のカテゴリ名: OPEN_MONGODB_PORT

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

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

• TCP - 27017, 27018, 27019

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

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

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

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

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

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

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

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

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

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

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

Open MySQL port

API のカテゴリ名: OPEN_MYSQL_PORT

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

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

• TCP - 3306

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

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

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

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

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

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

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

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

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

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

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

Open NetBIOS port

API のカテゴリ名: OPEN_NETBIOS_PORT

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

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

• TCP - 137, 138, 139
• UDP - 137, 138, 139

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

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

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

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

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

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

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

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

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

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

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

Open OracleDB port

API のカテゴリ名: OPEN_ORACLEDB_PORT

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

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

• TCP - 1521, 2483, 2484
• UDP - 2483, 2484

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

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

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

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

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

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

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

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

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

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

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

Open POP3 port

API のカテゴリ名: OPEN_POP3_PORT

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

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

• TCP - 110

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

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

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

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

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

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

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

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

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

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

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

Open PostgreSQL port

API のカテゴリ名: OPEN_POSTGRESQL_PORT

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

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

• TCP - 5432
• UDP - 5432

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

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

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

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

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

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

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

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

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

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

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

Open RDP port

API のカテゴリ名: OPEN_RDP_PORT

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

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

• TCP - 3389
• UDP - 3389

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

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

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

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

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

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

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

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

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

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

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

Open Redis port

API のカテゴリ名: OPEN_REDIS_PORT

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

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

• TCP - 6379

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

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

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

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

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

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

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

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

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

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

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

Open SMTP port

API のカテゴリ名: OPEN_SMTP_PORT

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

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

• TCP - 25

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

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

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

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

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

3. [編集] をクリックします。

4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

7. [保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Open SSH port

API のカテゴリ名: OPEN_SSH_PORT

ファイアウォール ルールで任意の IP アドレスから SSH ポートへの接続を許可すると、SSH サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

SSH サービスのポートは次のとおりです。

• SCTP - 22
• TCP - 22

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールの [ファイアウォール] ページに移動します。

   [ファイアウォール] に移動

2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

3. [編集] をクリックします。

4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

7. [保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Open Telnet port

API のカテゴリ名: OPEN_TELNET_PORT

ファイアウォール ルールで任意の IP アドレスから Telnet ポートへの接続を許可すると、Telnet サービスが攻撃者に公開される可能性があります。詳細については、VPC ファイアウォール ルールの概要をご覧ください。

Telnet サービスのポートは次のとおりです。

• TCP - 23

この検出結果は、ルールを意図的に無効にした場合でも、脆弱なファイアウォール ルールに対して生成されます。無効にしたファイアウォール ルールに対するアクティブな検出結果では、有効にすると望ましくないトラフィックを許可する、安全でない構成が警告されます。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールの [ファイアウォール] ページに移動します。

   [ファイアウォール] に移動

2. ファイアウォール ルールのリストで、検出結果内にあるファイアウォール ルールの名前をクリックします。

3. [編集] をクリックします。

4. [ソース IP の範囲] で、0.0.0.0/0 を削除します。

5. インスタンスに接続する特定の IP アドレスまたは IP 範囲を追加します。

6. インスタンスへの接続を開放する特定のプロトコルとポートを指定します。

7. [保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Org policy Confidential VM policy

API のカテゴリ名: ORG_POLICY_CONFIDENTIAL_VM_POLICY

Compute Engine リソースが constraints/compute.restrictNonConfidentialComputing 組織ポリシーを遵守していません。この組織ポリシーの制約の詳細については、組織ポリシーの制約の適用をご覧ください。

組織のこの VM で Confidential VM サービスが有効になっていることが必要です。このサービスが有効になっていない VM は、ランタイム メモリの暗号化を使用しないため、ランタイム メモリの攻撃にさらされます。

注: Confidential VM を使用すると、Compute Engine の料金に別途追加料金が発生します。詳細については、料金をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

この検出結果を修正するには、次の操作を完了します。

1. Google Cloud コンソールの [VM インスタンス] ページに移動します。

   [VM インスタンス] に移動

2. インスタンスのリストで、検出結果内のインスタンスの名前をクリックします。

3. VM が Confidential VM サービスを必要としない場合は、それを新しいフォルダまたはプロジェクトに移動します。

4. VM に Confidential VM が必要な場合は、 [削除] をクリックします。

5. Confidential VM を有効にして新しいインスタンスを作成するには、クイックスタート: Confidential VM インスタンスの作成をご覧ください。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Org policy location restriction

API のカテゴリ名: ORG_POLICY_LOCATION_RESTRICTION

組織のポリシーの gcp.resourceLocations 制約を使用すると、新しいリソースの作成を、選択したクラウド リージョンに制限できます。詳細については、リソース ロケーションの制限をご覧ください。

注: リソース ロケーションの制約は過去にさかのぼって適用されないので、制約値が変更されても、既存のリソースは変更されません。既存のリソース ロケーションが新しい制約に違反すると、ORG_POLICY_LOCATION_RESTRICTION の検出結果が生成される可能性があります。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

この検出結果を修正するには、次の操作を完了します。

ORG_POLICY_LOCATION_RESTRICTION 検出機能は多くのリソースタイプをカバーしており、リソースごとに修正手順が異なります。ロケーション違反を修正するための一般的なアプローチには、次のようなものがあります。

1. リージョン外のリソースまたはそのデータを、リージョン内のリソースにコピー、移動、またはバックアップします。リソースの移動の手順については、各サービスのドキュメントをご覧ください。
2. 元のリージョン外のリソースまたはそのデータを削除する。

このアプローチは、すべてのリソースタイプに適用できるわけではありません。指針としては、検出結果で個別に示された推奨事項をご覧ください。

その他の考慮事項

この検出結果を修正する場合は、次の点を考慮してください。

マネージド リソース

リソースのライフサイクルは、他のリソースによって管理および制御される場合があります。たとえば、マネージド Compute Engine インスタンス グループは、インスタンス グループの自動スケーリング ポリシーに従って Compute Engine インスタンスの作成と破棄を行います。マネージド リソースとマネージング リソースがロケーション適用の対象である場合は、両方とも組織のポリシーの違反として警告される場合があります。運用の安定性を確保するため、マネージング リソースにマネージド リソースの検出結果の修正が行われる必要があります。

使用中のリソース

特定のリソースは、他のリソースによって使用されます。たとえば、実行中の Compute Engine インスタンスにアタッチされた Compute Engine ディスクは、インスタンスによって使用中とみなされます。使用中のリソースがロケーションの組織のポリシーに違反している場合は、ロケーションの違反に対処する前に、そのリソースが使用中ではないことを確認する必要があります。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

OS login disabled

API のカテゴリ名: OS_LOGIN_DISABLED

この Compute Engine インスタンスでは OS Login が無効になっています。

OS Login により、IAM を使用した一元的な SSH 認証鍵管理ができるようになり、プロジェクト内のすべてのインスタンスにおけるメタデータ ベースの SSH 認証鍵の構成が無効になります。詳しくは、OS Login を設定および構成する方法をご覧ください。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

この検出結果を修正するには、次の操作を完了します。

1. Google Cloud コンソールで [メタデータ] ページに移動します。

   [メタデータ] に移動

2. [編集] をクリックし、[項目を追加] をクリックします。

3. キーが enable-oslogin で、値が TRUE のアイテムを追加します。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Over privileged account

API のカテゴリ名: OVER_PRIVILEGED_ACCOUNT

GKE ノードは、Compute Engine のデフォルトのサービスノードを使用しています。このノードには、デフォルトで広範なアクセス権が付与されており、GKE クラスタを稼働するための過剰な権限を保有している可能性があります。

この検出結果を修正するには、次の手順を行います。

最小限の権限の Google サービス アカウントを使用するの手順に沿って操作します。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Over privileged scopes

API のカテゴリ名: OVER_PRIVILEGED_SCOPES

ノードのサービス アカウントに、範囲の広いアクセス スコープがあります。

アクセス スコープは、インスタンスの権限を指定するレガシーな方法です。攻撃における権限昇格の可能性を低減するには、最小限の特権サービス アカウントを作成して、GKE クラスタの稼働にはそのサービス アカウントを使用します。

この検出項目を修正するには、最小限の権限の Google サービス アカウントを使用するの手順に沿って操作してください。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Over privileged service account user

API のカテゴリ名: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

ユーザーに特定のサービス アカウントに対するロールではなく、プロジェクト、フォルダ、または組織レベルで iam.serviceAccountUser または iam.serviceAccountTokenCreator のロールが付与されています。

そうしたロールをプロジェクト、フォルダまたは組織のユーザーに付与すると、そのユーザーは、その範囲にある既存および今後作成されるすべてのサービス アカウントにアクセスできるようになります。その結果、意図しない権限昇格につながる可能性があります。詳細については、サービス アカウント権限をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [IAM] ページに移動します。

   [IAM] ページに移動

2. 必要に応じて、検出結果のプロジェクト、フォルダ、または組織を選択します。

3. roles/iam.serviceAccountUser または roles/iam.serviceAccountTokenCreator が割り当てられたプリンシパルごとに、次の操作を行います。

   1. [編集] をクリックします。
   2. [権限の編集] パネルで、ロールの横にある [削除] をクリックします。
   3. [保存] をクリックします。

4. このガイドに沿って、1 つのサービス アカウントの権限の使用を個々のユーザーに許可します。選択したユーザーに権限の使用を許可するサービス アカウントごとで、このガイドに沿って操作を行う必要があります。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Owner not monitored

API のカテゴリ名: OWNER_NOT_MONITORED

ログ指標とアラートが、プロジェクト所有権の割り当て、または変更をモニタリングするように構成されていません。

IAM オーナーのロールは、プロジェクトで最高レベルの権限を持っています。リソースを保護するために、オーナーが新しく追加または削除されたときに通知を受け取るようにアラートを設定します。詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、 Google Cloud 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. 「その他の操作」 をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [次へ] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [ポリシーを作成] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Pod security policy disabled

API のカテゴリ名: POD_SECURITY_POLICY_DISABLED

PodSecurityPolicy が GKE クラスタで無効になっています。

PodSecurityPolicy は、クラスタ上で Pod を作成および更新するリクエストを検証するアドミッション コントローラ リソースです。クラスタは、PodSecurityPolicy で定義された条件を満たさない Pod を受け入れません。

Security Command Center のプレミアム ティアをプロジェクト レベルで有効にする場合、この検出結果を得ることができるのは、親の組織でスタンダード ティアが有効になっている場合のみです。

この検出結果を修正するには、PodSecurityPolicies を定義して承認し、PodSecurityPolicy コントローラを有効にします。手順については、PodSecurityPolicies の使用をご覧ください。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Primitive roles used

API のカテゴリ名: PRIMITIVE_ROLES_USED

IAM の基本ロール（roles/owner、roles/editor、roles/viewer のいずれか）を持つユーザーがいます。これらのロールには過剰な権限が付与されるため、使用を回避する必要があります。代わりに、ロールはプロジェクトごとのみに割り当てる必要があります。

詳しくは、ロールについてをご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで IAM ポリシーのページに移動します。

   IAM ポリシーに移動

2. 基本ロールが割り当てられているユーザーごとに、より詳細なロールの使用を検討してください。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Private cluster disabled

API のカテゴリ名: PRIVATE_CLUSTER_DISABLED

GKE クラスタに、無効な限定公開クラスタがあります。

限定公開クラスタのノードに割り当てられるのはプライベート IP アドレスだけです。この機能は、ノードへの送信インターネット アクセスを制限します。クラスタノードにパブリック IP アドレスがない場合、クラスタノードは検出不能であるか、インターネットに公開されません。内部ロードバランサを使用してノードにトラフィックをルーティングすることは可能です。詳細については、限定公開クラスタをご覧ください。

既存のクラスタをプライベートにすることはできません。この検出結果を修正するには、新しい限定公開クラスタを作成します。

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. [クラスタを作成] をクリックします。

3. ナビゲーション メニューの [クラスタ] で、[ネットワーキング] を選択します。

4. [限定公開クラスタ] のラジオボタンを選択します。

5. [高度なネットワーキングのオプション] で、[VPC ネイティブのトラフィック ルーティングを有効にする（エイリアス IP を使用）] チェックボックスをオンにします。

6. [作成] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Private Google access disabled

API のカテゴリ名: PRIVATE_GOOGLE_ACCESS_DISABLED

Google の公開 API にアクセスできない限定公開サブネットがあります。

限定公開の Google アクセスを使用すると、内部（プライベート）IP アドレスのみを持つ VM インスタンスが Google API とサービスのパブリック IP アドレスにアクセスできます。

詳細については、限定公開の Google アクセスの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [VPC ネットワーク] ページに移動します。

   [VPC ネットワーク] に移動

2. ネットワークのリストで、目的のネットワークの名前をクリックします。

3. [VPC ネットワークの詳細] ページで、[サブネット] タブをクリックします。

4. サブネットのリストで、検出結果内の Kubernetes クラスタに関連付けられているサブネットの名前をクリックします。

5. [サブネットの詳細] ページで、[編集] をクリックします。

6. [限定公開の Google アクセス] で [オン] を選択します。

7. [保存] をクリックします。

8. Google API に対してのみ外部トラフィックを送信する VM インスタンスからパブリック（外部）IP を削除するには、静的外部 IP アドレスの割り当て解除をご覧ください。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public bucket ACL

API のカテゴリ名: PUBLIC_BUCKET_ACL

バケットが一般公開されており、インターネット上の誰でもアクセスできるようになっています。

詳細については、アクセス制御の概要をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Storage の [ブラウザ] ページに移動します。

   Storage の [ブラウザ] に移動

2. Security Health Analytics の検出結果に表示されているバケットを選択します。

3. [バケットの詳細] ページで、[権限] タブをクリックします。

4. [表示] の横の [ロール] をクリックします。

5. [フィルタ] ボックスで、allUsers と allAuthenticatedUsers を検索します。

6. [削除] をクリックして、allUsers と allAuthenticatedUsers に付与されているすべての IAM 権限を削除します。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [削除] をクリックして、そのロールからユーザーを削除します。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public dataset

API のカテゴリ名: PUBLIC_DATASET

BigQuery データセットが一般公開されており、インターネット上の誰でもアクセスできるようになっています。IAM プリンシパルの allUsers はインターネット上のすべてのユーザーを表し、allAuthenticatedUsers は Google サービスにログインしているすべてのユーザーを表します。どちらでも組織内のユーザーに限定されていません。

詳細については、データセットへのアクセスの制御をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで BigQuery の [エクスプローラ] ページに移動します。

   BigQuery データセットに移動

2. データセットのリストで、検出結果にあるデータセットの名前をクリックします。[データセット情報] パネルが開きます。

3. [データセット情報] パネルの上部にある [共有] をクリックします。

4. プルダウン メニューで [権限] をクリックします。

5. [データセットの権限] パネルで、「allUsers」と「allAuthenticatedUsers」を入力し、これらのプリンシパルのアクセス権を削除します。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public IP address

API のカテゴリ名: PUBLIC_IP_ADDRESS

Compute Engine インスタンスにパブリック IP アドレスがあります。

組織の攻撃対象を減らすために、VM にパブリック IP アドレスを割り当てるのは避けてください。停止されたインスタンスは、ネットワーク インターフェースが起動時にエファメラルなパブリック IP を割り当てるように構成されている場合など、パブリック IP 検出で警告される場合があります。停止しているインスタンスのネットワーク構成に、外部アドレスが含まれていないことを確認してください。

詳細については、VM インスタンスへの安全な接続をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールの [VM インスタンス] ページに移動します。

   [VM インスタンス] に移動

2. インスタンスのリストで、検出結果のインスタンスの名前の横にあるチェックボックスをオンにします。

3. [編集] をクリックします。

4. [ネットワーク インターフェース] にあるインターフェースごとに、 [編集] をクリックして、[外部 IP] を [なし] に設定します。

5. [完了] をクリックし、[保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public log bucket

API のカテゴリ名: PUBLIC_LOG_BUCKET

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

ストレージ バケットは一般公開されており、ログシンクとして使用されています。これは、インターネット上の誰でも、このバケットに保存されているログにアクセスできることを意味します。allUsers はインターネット上の全員を表し、allAuthenticatedUsers は Google サービスにログインしている全員を表しています。どちらも組織内のユーザーに限定されていません。

詳細については、アクセス制御の概要をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで、Cloud Storage ブラウザページに移動します。

   Cloud Storage ブラウザに移動

2. バケットのリストで、検出結果に示されているバケットの名前をクリックします。

3. [権限] タブをクリックします。

4. プリンシパルのリストから allUsers と allAuthenticatedUsers を削除します。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

4. ナビゲーション パネルで [接続] をクリックします。

5. [承認済みネットワーク] で 0.0.0.0/0 を削除し、インスタンスに接続する特定の IP アドレスまたは IP 範囲を指定します。

6. [完了] をクリックし、[保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Pubsub CMEK disabled

API のカテゴリ名: PUBSUB_CMEK_DISABLED

Pub/Sub トピックが、顧客管理の暗号鍵（CMEK）で暗号化されません。

CMEK を使用すると、Cloud KMS で作成、管理する鍵は、Google がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより詳細に制御できます。

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

この検出結果を修正するには、既存のトピックを削除して新しいトピックを作成します。

1. Google Cloud コンソールで Pub/Sub の [トピック] ページに移動します。

   [トピック] に移動

2. 必要に応じて、Pub/Sub トピックを含むプロジェクトを選択します。

3. 検索結果に表示されたトピックの横にあるチェックボックスをオンにして、 [削除] をクリックします。

4. CMEK を有効にして新しい Pub/Sub トピックを作成するには、顧客管理の暗号鍵の使用をご覧ください。CMEK を使用すると、Cloud KMS に関連する追加費用が発生します。

5. CMEK を有効化した Pub/Sub トピックに検出結果や他のデータを公開します。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Route not monitored

API のカテゴリ名: ROUTE_NOT_MONITORED

注: この検出機能のログベースの指標フィルタは 2021 年 10 月 27 日に変更されました。

ログ指標とアラートが、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. 「その他の操作」 をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [次へ] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [ポリシーを作成] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Redis role used on org

API のカテゴリ名: REDIS_ROLE_USED_ON_ORG

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

Redis IAM ロールが組織レベルまたはフォルダレベルで割り当てられています。

次の Redis IAM ロールは、組織またはフォルダレベルでではなく、プロジェクトごとのみに割り当てる必要があります。

• roles/redis.admin
• roles/redis.viewer
• roles/redis.editor

詳細については、アクセス制御と権限をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで IAM ポリシーのページに移動します。

   IAM ポリシーに移動

2. 検出結果に示された Redis IAM ロールを削除し、代わりに個々のプロジェクトにそれらのロールを追加します。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Release channel disabled

API のカテゴリ名: RELEASE_CHANNEL_DISABLED

GKE クラスタはリリース チャンネルに登録されていません。

リリース チャンネルに登録して、GKE クラスタのバージョン アップグレードを自動化します。また、バージョン管理の複雑さを軽減し、必要な機能の数と安定性のレベルを引き下げることもできます。詳細については、リリース チャンネルをご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. [クラスタの基本] セクションで、[リリース チャンネル] 行の編集アイコン（）をクリックします。

   クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

3. ダイアログで [リリース チャンネル] を選択し、登録するリリース チャンネルを選択します。

   クラスタのコントロール プレーン バージョンをリリース チャンネルにアップグレードできない場合、対象のチャンネルはオプションとして無効になる可能性があります。

4. [変更を保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

RSASHA1 for signing

API のカテゴリ名: RSASHA1_FOR_SIGNING

RSASHA1 が Cloud DNS ゾーンにログインする鍵に使用されています。鍵署名に使用するアルゴリズムは、堅牢である必要があります。

この検出項目を修正するには、高度な署名オプションの使用のガイドに沿って、アルゴリズムを推奨のアルゴリズムに置き換えます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Service account key not rotated

API のカテゴリ名: SERVICE_ACCOUNT_KEY_NOT_ROTATED

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

ユーザー管理のサービス アカウント キーが 90 日以上ローテーションされていません。

一般に、ユーザー管理のサービス アカウント キーは少なくとも 90 日ごとにローテーションさせて、紛失、不正使用、盗難にあった古い鍵でデータにアクセスしないようにしてください。詳しくは、鍵の漏えいによって発生するセキュリティ リスクを軽減するためにサービス アカウント キーをローテーションするをご覧ください。

公開鍵/秘密鍵のペアを自分で生成し、ハードウェア セキュリティ モジュール（HSM）に秘密鍵を保存して、Google に公開鍵をアップロードした場合は、鍵のローテーションを 90 日ごとに行う必要はありません。その代わりに、鍵が侵害された可能性がある場合に鍵をローテーションします。

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [サービス アカウント] ページに移動します。

   [サービス アカウント] に移動

2. 必要に応じて、検出結果内で示されているプロジェクトを選択します。

3. サービス アカウントのリストで、検索結果に記載されたサービス アカウントを見つけて、 [削除] をクリックします。続行する前に、サービス アカウントの削除が本番環境のリソースに及ぼす可能性のある影響を検討してください。

4. 新しいサービス アカウント キーを作成し、古い鍵に置換します。詳細については、サービス アカウント キーの作成をご覧ください。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Service account role separation

API のカテゴリ名: SERVICE_ACCOUNT_ROLE_SEPARATION

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

組織内の 1 人または複数のプリンシパルに、複数のサービス アカウントの権限が割り当てられています。どのアカウントにも、他のサービス アカウントの権限とともにサービス アカウント管理者の権限を同時に付与しないでください。サービス アカウントと、サービス アカウントに使用可能なロールについては、サービス アカウントをご覧ください。

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [IAM] ページに移動します。

   [IAM] に移動

2. 検出結果に記載されているプリンシパルごとに、次の操作を行います。

   1. [継承] 列を調べて、ロールがフォルダまたは組織リソースから継承されているかどうかを確認します。列に親リソースへのリンクが含まれている場合は、そのリンクをクリックして親リソースの [IAM] ページに移動します。
   2. プリンシパルの横にある [編集] をクリックします。
   3. 権限を削除するには、[サービス アカウント管理者] の横にある [削除] をクリックします。すべてのサービス アカウントの権限を削除するには、他の権限の横にある [削除] をすべてクリックします。

3. [保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Shielded VM disabled

API のカテゴリ名: SHIELDED_VM_DISABLED

この Compute Engine インスタンスで、Shielded VM が無効になっています。

Shielded VM は、ルートキットやブートキットによる攻撃を防御する一連のセキュリティ制御により強化された、Google Cloud 上の仮想マシン（VM）です。Shielded VM を使用すると、ブートローダーとファームウェアの署名と検証を確実にできるようになります。Shielded VM について理解する。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールの [VM インスタンス] ページに移動します。

   [VM インスタンス] に移動

2. Security Health Analytics の検出結果に関連するインスタンスを選択します。

3. 読み込まれた [インスタンスの詳細] ページで、 [停止] をクリックします。

4. インスタンスが停止したら、 [編集] をクリックします。

5. [Shielded VM] セクションで、[vTPM をオンにする] と [整合性のモニタリングを有効にする] を切り替えて、Shielded VM を有効にします。

6. 必要に応じて、カスタム ドライバまたは署名されていないドライバを使用しない場合に、セキュアブートも有効にします。

7. [保存] をクリックします。新しい構成が [インスタンスの詳細] ページに表示されます。

8. [開始] をクリックしてインスタンスを起動します。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL CMEK disabled

API のカテゴリ名: SQL_CMEK_DISABLED

SQL データベース インスタンスが顧客管理の暗号鍵（CMEK）を使用していません。

CMEK を使用すると、Cloud KMS で作成、管理する鍵は、Google がデータの暗号化に使用する鍵をラップするため、データへのアクセスをより詳細に制御できます。詳細については、ご使用のプロダクト（Cloud SQL for 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. [削除] をクリックします。

4. CMEK を有効にして新しいインスタンスを作成するには、次の手順に沿って、ご使用のプロダクト用に CMEK を構成します。

   1. Cloud SQL for MySQL
   2. Cloud SQL for PostgreSQL
   3. Cloud SQL for SQL Server

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL contained database authentication

API のカテゴリ名: SQL_CONTAINED_DATABASE_AUTHENTICATION

Cloud SQL for SQL Server データベース インスタンスで、含まれているデータベース認証のデータベース フラグが [オフ] に設定されていません。

包含データベース認証フラグは、包含データベースを作成できるかどうか、また包含データベースをデータベース エンジンに接続できるかどうかを制御します。包含データベースには、データベースの定義に必要なすべてのデータベース設定とメタデータが含まれており、データベースがインストールされているデータベース エンジンのインスタンスに対する構成の依存関係はありません。

次の理由により、このフラグを有効にすることはおすすめしません。

• ユーザーは、データベース エンジン レベルで、認証なしでデータベースに接続できる。
• データベースをデータベース エンジンから分離すると、データベースを SQL Server の別のインスタンスに移動できる。

包含データベースには固有の脅威があり、SQL Server データベース エンジンの管理者はそうした脅威を把握して対処する必要があります。ほとんどの脅威は、USER WITH PASSWORD 認証プロセスで発生します。このプロセスでは、認証の境界線が Database Engine レベルからデータベース レベルに移動します。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、contained database authentication データベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL cross DB ownership chaining

API のカテゴリ名: SQL_CROSS_DB_OWNERSHIP_CHAINING

Cloud SQL for SQL Server データベース インスタンスで、cross db ownership chaining のデータベース フラグがオフに設定されていません。

cross db ownership chaining フラグを使用すると、データベース レベルでデータベース間の所有権チェーンを管理できるようになります。また、すべてのデータベース ステートメントに対して、データベース間の所有権チェーンを許可します。

SQL Server インスタンスでホストされているすべてのデータベースが、データベース間の所有権チェーンに参加しており、この設定のセキュリティへの影響を把握している場合を除き、このフラグを有効にすることはおすすめしません。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、cross db ownership chaining データベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL external scripts enabled

API のカテゴリ名: SQL_EXTERNAL_SCRIPTS_ENABLED

Cloud SQL for SQL Server データベース インスタンスで、external scripts enabled データベース フラグが [オフ] に設定されていません。

この設定を有効にすると、特定のリモート言語の拡張機能でスクリプトの実行が有効になります。この機能はシステムのセキュリティに悪影響を与える可能性があるため、無効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、external scripts enabled データベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL instance not monitored

API のカテゴリ名: SQL_INSTANCE_NOT_MONITORED

プロジェクト レベルで有効にしている場合、この検出結果は利用できません。

ログ指標とアラートが、Cloud SQL インスタンスの構成の変更をモニタリングするように構成されていません。

SQL インスタンス オプションの構成に誤りがあると、セキュリティ リスクの原因になる可能性があります。自動バックアップと高可用性オプションを無効にすると、ビジネスの継続性に影響を与えることがあり、承認済みネットワークを制限しなければ、信頼できないネットワークへの露出が増加する可能性があります。SQL インスタンスの構成の変更をモニタリングすると、構成ミスの検出と修正にかかる時間を短縮できます。

詳しくは、ログベースの指標の概要をご覧ください。

情報の量によっては、Cloud Monitoring の費用が高額になる可能性があります。サービスの使用量とその費用については、 Google Cloud 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. 「その他の操作」 をクリックしてから、[指標に基づいて通知を作成する] をクリックします。

   指標とデータ変換オプションが入力された状態で、[New condition] ダイアログが開きます。

4. [次へ] をクリックします。
   1. 事前に入力された設定を確認します。しきい値を変更することをおすすめします。
   2. [条件名] をクリックし、条件の名前を入力します。
5. [次へ] をクリックします。

6. アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャネルを選択し、[OK] をクリックします。

   インシデントが開かれたときと閉じられたときに通知を受け取るには、[Notify on incident closure] をオンにします。デフォルトでは、インシデントが開かれたときにのみ通知が送信されます。

7. （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
8. （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
9. [アラート名] をクリックして、アラート ポリシーの名前を入力します。
10. [ポリシーを作成] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

4. [データベース フラグ] セクションで、local_infile データベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

4. [データベース フラグ] セクションで、log_checkpoints データベース フラグを [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

4. [データベース フラグ] セクションで、log_connections データベース フラグを [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

4. [データベース フラグ] セクションで、[log_disconnections] データベース フラグを [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

4. [データベース フラグ] セクションで、log_duration データベース フラグを [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [ 編集] をクリックします。

4. [データベース フラグ] セクションで、log_error_verbosity データベース フラグを default または verbose に設定します。

5. [Save] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

4. [データベース フラグ] セクションで、[log_lock_waits] データベース フラグに値「オン」を設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log min duration statement enabled

API のカテゴリ名: SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_min_duration_statement のデータベース フラグが「-1」に設定されていません。

log_min_duration_statement フラグを指定すると、指定された時間よりも長く実行される SQL ステートメントがログに記録されます。SQL ステートメントには、ログへの記録を回避する必要がある機密情報が含まれている可能性があるため、この設定を無効にすることを検討してください。詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、log_min_duration_statement データベース フラグに値 -1 を設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log min error statement

API のカテゴリ名: SQL_LOG_MIN_ERROR_STATEMENT

Cloud SQL for PostgreSQL データベース インスタンスで、log_min_error_statement データベース フラグが適切に設定されていません。

log_min_error_statement フラグは、エラー状態の原因である SQL ステートメントをサーバーログに記録するかどうかを制御します。指定した重要度以上の SQL ステートメントは、エラー ステートメントのメッセージとともにログに記録されます。重要度が高いほど、記録されるメッセージは少なくなります。

log_min_error_statement が正しい値に設定されていない場合は、メッセージがエラー メッセージとして分類されない可能性があります。重要度の設定が低すぎると、メッセージの数が増え、実際のエラーを見つけるのが困難になります。重要度の設定が高すぎると、実際のエラーのエラー メッセージが記録されない可能性があります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、組織のロギング ポリシーに応じて、log_min_error_statement データベース フラグに次のいずれかの推奨値を設定します。

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log min error statement severity

API のカテゴリ名: SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY

Cloud SQL for PostgreSQL データベース インスタンスで、log_min_error_statement データベース フラグが適切に設定されていません。

log_min_error_statement フラグは、エラー状態の原因である SQL ステートメントをサーバーログに記録するかどうかを制御します。指定した重要度以上の SQL ステートメントは、エラー ステートメントのメッセージとともにログに記録されます。重要度が高いほど、記録されるメッセージは少なくなります。

log_min_error_statement が正しい値に設定されていない場合は、メッセージがエラー メッセージとして分類されない可能性があります。重要度の設定が低すぎると、メッセージの数が増え、実際のエラーを見つけるのが困難になります。重要度が高すぎる（厳しくなりすぎる）と、実際のエラーのエラー メッセージが記録されない可能性があります。

このフラグを error かそれよりも厳格に設定することをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、組織のロギング ポリシーに応じて、log_min_error_statement データベース フラグに次のいずれかの推奨値を設定します。

   • error
   • log
   • fatal
   • panic

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log min messages

API のカテゴリ名: SQL_LOG_MIN_MESSAGES

Cloud SQL for PostgreSQL データベース インスタンスで、log_min_messages データベース フラグが warning 以上に設定されていません。

log_min_messages フラグは、サーバーログに記録されるメッセージ レベルを制御します。重要度が高いほど、記録されるメッセージは少なくなります。しきい値を低く設定しすぎると、ログのストレージ サイズと長さが増加し、実際のエラーを見つけるのが困難になります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. 組織のロギング ポリシーに従い、[データベース フラグ] セクションで、log_min_messages データベース フラグに次のいずれかの推奨値を設定します。

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [ 編集] をクリックします。

4. [データベース フラグ] セクションで、log_executor_stats データベース フラグを [オフ] に設定します。

5. [Save] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

4. [データベース フラグ] セクションで、log_hostname データベース フラグを [オフ] に設定してください。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log parser stats enabled

API のカテゴリ名: SQL_LOG_PARSER_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_parser_stats データベース フラグが [オフ] に設定されていません。

log_parser_stats フラグを有効にすると、各クエリの PostgreSQL ログにパーサー パフォーマンス統計が記録されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、log_parser_stats データベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log planner stats enabled

API のカテゴリ名: SQL_LOG_PLANNER_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_planner_stats データベース フラグが [オフ] に設定されていません。

log_planner_stats フラグを有効にすると、PostgreSQL プランナーのパフォーマンス統計をロギングするための粗分析のプロファイリング メソッドが使用されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、log_planner_stats データベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log statement

API のカテゴリ名: SQL_LOG_STATEMENT

Cloud SQL for PostgreSQL データベース インスタンスで、log_statement データベース フラグが ddl に設定されていません。

このフラグの値により、ログに記録される SQL ステートメントを制御できます。ロギングによって、運用上の問題のトラブルシューティングとフォレンジック分析が可能になります。このフラグが正しい値に設定されていないと、関連する情報がスキップされるか、多くのメッセージで非表示になる可能性があります。組織のロギング ポリシーで別途指示がない限り、値 ddl（すべてのデータ定義ステートメント）をおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [ 編集] をクリックします。

4. [データベース フラグ] セクションで、log_statement データベース フラグを ddl に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log statement stats enabled

API のカテゴリ名: SQL_LOG_STATEMENT_STATS_ENABLED

Cloud SQL for PostgreSQL データベース インスタンスで、log_statement_stats データベース フラグが [オフ] に設定されていません。

log_statement_stats フラグを有効にすると、各クエリの PostgreSQL ログにエンドツーエンドのパフォーマンス統計が記録されます。これはトラブルシューティングに役立つ場合があるものの、ログの数とパフォーマンスのオーバーヘッドが大幅に増加する可能性があります。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、log_statement_stats データベース フラグを [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL log temp files

API のカテゴリ名: SQL_LOG_TEMP_FILES

Cloud SQL for PostgreSQL データベース インスタンスで、log_temp_files のデータベース フラグが「0」に設定されていません。

一時ファイルを、並べ替え、ハッシュ、一時的なクエリ結果のために作成できます。log_temp_files フラグを 0 に設定すると、すべての一時ファイルの情報がログに記録されます。一時ファイルをすべてログに記録することは、潜在的なパフォーマンスの問題を特定する際に有効です。詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、log_temp_files データベース フラグを値 0 に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL no root password

API のカテゴリ名: SQL_NO_ROOT_PASSWORD

MySQL データベース インスタンスの root アカウントのパスワードが設定されていません。MySQL データベース インスタンスにパスワードを追加する必要があります。詳細については、MySQL ユーザーをご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. 読み込まれた [インスタンスの詳細] ページで、[ユーザー] タブを選択します。

4. root ユーザーの横にある [その他] をクリックしてから、[パスワードを変更] を選択します。

5. 新しい強力なパスワードを入力してから [OK] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL public IP

API のカテゴリ名: SQL_PUBLIC_IP

Cloud SQL データベースに、パブリック IP アドレスがあります。

組織の攻撃対象を軽減するために、Cloud SQL データベースにはパブリック IP アドレスを含めないでください。プライベート IP アドレスを使用すると、ネットワーク セキュリティを高め、アプリケーションのレイテンシを低減できます。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. 左側のメニューで [接続] をクリックします。

4. [ネットワーキング] タブをクリックし、[パブリック IP] チェックボックスをオフにします。

5. インスタンスでまだプライベート IP を使用するように構成されていない場合は、既存のインスタンスにプライベート IP を構成するをご覧ください。

6. [保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

4. [フラグ] セクションで、[remote access] を [オフ] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL skip show database disabled

API のカテゴリ名: SQL_SKIP_SHOW_DATABASE_DISABLED

Cloud SQL for MySQL データベース インスタンスで、skip_show_database データベース フラグが [オン] に設定されていません。

このフラグをオンにすると、SHOW DATABASES 権限のないユーザーによる SHOW DATABASES ステートメントの使用を防止できます。この設定では、明示的な権限のないユーザーは、他のユーザーに属するデータベースを表示できません。このフラグを有効にすることをおすすめします。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [フラグ] セクションで、skip_show_database を [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL trace flag 3625

API のカテゴリ名: SQL_TRACE_FLAG_3625

Cloud SQL for SQL Server データベース インスタンスで、3625（トレースフラグ）データベース フラグが [オン] に設定されていません。

このフラグは、一部のエラー メッセージのパラメータをアスタリスク（******）でマスクすることで、sysadmin 固定サーバーロールのメンバーではないユーザーに返される情報の量を制限します。機密情報の漏洩を防ぐため、このフラグを有効にすることをおすすめします。

注: CIS ベンチマークの特定のバージョンでは、3625（トレースフラグ）を Off に設定することが推奨されていますが、これは誤りです。最も安全な設定は On です。詳細については、CIS の変更提案 Ensure '3625 (trace flag)' database flag for all Cloud SQL Server instances is set to 'on' をご覧ください（これを閲覧するには登録が必要です）。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、[3625] を [オン] に設定します。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL user connections configured

API のカテゴリ名: SQL_USER_CONNECTIONS_CONFIGURED

Cloud SQL for SQL Server データベース インスタンスで、user connections データベース フラグが構成されています。

[user connections] オプションは、SQL Server のインスタンスで許可される同時ユーザー接続の最大数を指定します。これは動的な（自己構成型の）オプションであるため、SQL Server は、必要に応じてユーザー接続の最大数を許容値まで自動的に調整します。デフォルト値は 0 です。つまり、最大 32,767 のユーザー接続が許可されます。このため、user connections データベース フラグを構成することはおすすめしません。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、[user connections] の横にある [削除] をクリックします。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

SQL user options configured

API のカテゴリ名: SQL_USER_OPTIONS_CONFIGURED

Cloud SQL for SQL Server データベース インスタンスで、user options データベース フラグが構成されています。

この設定により、すべてのユーザーの SET オプションのグローバル デフォルト値がオーバーライドされます。ユーザーとアプリケーションは、デフォルトのデータベース SET オプションが使用されていることを前提としている場合があるため、user options を設定すると、予期しない結果が生じる可能性があります。このため、user options データベース フラグを構成することはおすすめしません。

詳細については、データベース フラグの構成をご覧ください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

   Cloud SQL の [インスタンス] に移動

2. Security Health Analytics の検出結果に表示されているインスタンスを選択します。

3. [編集] をクリックします。

4. [データベース フラグ] セクションで、[user options] の横にある [削除] をクリックします。

5. [保存] をクリックします。新しい構成が [インスタンスの概要] ページに表示されます。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [信頼できるクライアント証明書を必須にする] を選択した場合は、新しいクライアント証明書を作成します。詳細については、新しいクライアント証明書を作成するをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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 以下に削減します。権限を取り消すには、各プリンシパルの横にある [削除] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

User managed service account key

API のカテゴリ名: USER_MANAGED_SERVICE_ACCOUNT_KEY

ユーザーがサービス アカウント キーを管理しています。 サービス アカウント キーが正しく管理されていない場合は、セキュリティ リスクが発生します。可能であれば、サービス アカウント キーよりも安全な代替手段を選択してください。サービス アカウント キーで認証する必要がある場合は、秘密鍵のセキュリティと、サービス アカウント キーを管理するためのベスト プラクティスで説明されているその他の操作は、ユーザーの責任で実施してください。サービス アカウント キーを作成できない場合は、組織でサービス アカウント キーの作成が無効になっている可能性があります。詳細については、デフォルトで安全な組織リソースの管理をご覧ください。

注意: この修正手順により、本番環境が中断される可能性があります。必要に応じて、既存のアセットを削除する前に、ワークロード、データ、権限を新しいリソースに移動してください。

この検出結果を修正するには、次の手順を行います。

1. Google Cloud コンソールで [サービス アカウント] ページに移動します。

   [サービス アカウント] に移動

2. 必要に応じて、検出結果内で示されているプロジェクトを選択します。

3. 検出結果で示されているユーザー管理のサービス アカウント キーを削除します（どのアプリケーションでも使用されていない場合）。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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 パラメータ ページをご覧ください。

注: SSL ポリシーを更新すると、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. [編集] をクリックします。

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. [保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

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. [編集] をクリックします。

   クラスタの構成を変更した直後は、編集ボタンが無効になっている場合があります。クラスタ設定を編集できない場合は、数分待ってからもう一度試してください。

4. [アドオン] をクリックします。セクションが展開され、使用可能なアドオンが表示されます。

5. [Kubernetes ダッシュボード] プルダウン リストで、[無効] を選択します。

6. [保存] をクリックします。

この検出結果のタイプのサポートされているアセットとスキャンの設定についての説明をご覧ください。

Workload Identity disabled

API のカテゴリ名: WORKLOAD_IDENTITY_DISABLED

Workload Identity が GKE クラスタで無効になっています。

Workload Identity は、セキュリティのプロパティと管理性が優れているため、GKE 内から Google Cloud サービスにアクセスするためのおすすめの方法です。有効にすると、一部の潜在的なシステムの機密メタデータを、クラスタ上で実行中のユーザーのワークロードから保護できます。詳しくは、メタデータ隠蔽をご覧ください。

この検出結果を修正するには、クラスタで Workload Identity を有効にするためのガイドに沿って操作してください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

AWS の構成ミスを修正する

Enterprise ティアのみ: この機能は、Security Command Center Enterprise ティアでのみご利用いただけます。

AWS Cloud Shell Full Access Restricted

API のカテゴリ名: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

AWS CloudShell は、AWS サービスに対して CLI コマンドを実行するための便利な方法です。マネージド IAM ポリシー（「AWSCloudShellFullAccess」）は、CloudShell への完全アクセス権を提供します。これによって、ユーザーのローカル システムと CloudShell 環境の間でファイルのアップロードとダウンロードを行うことができます。CloudShell 環境内ではユーザーに sudo 権限が付与され、インターネットにアクセスできます。そのため、たとえばファイル転送ソフトウェアをインストールして、CloudShell から外部インターネット サーバーにデータを移動できます。

推奨事項: AWSCloudShellFullAccess へのアクセスが制限されていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. https://console.aws.amazon.com/iam/ で IAM コンソールを開く
2. 左側のペインで [ポリシー] を選択する
3. AWSCloudShellFullAccess を検索して選択する
4. [アタッチされたエンティティ] タブで、各アイテムのチェックボックスをオンにして、[切断] を選択します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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 呼び出しを実行するために、独自のアクセスキーが必要です。すべてのアクセスキーを定期的にローテーションすることをおすすめします。

推奨事項: アクセスキーが 90 日以内のサイクルでローテーションされていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. 管理コンソール（https://console.aws.amazon.com/iam）に移動する
2. [Users] をクリックする
3. [Security Credentials] をクリックする
4. 管理者として
   - 90 日間ローテーションされていないキーの [Make Inactive] をクリックする
5. IAM ユーザーとして
   - 90 日間ローテーションされていない、または使用されていないキーの [Make Inactive] または [Delete] をクリックする
6. [Create Access Key] をクリックする
7. 新しいアクセスキー認証情報でプログラムによる呼び出しを更新する

AWS CLI

1. 最初のアクセスキーがアクティブな間に、デフォルトでアクティブな 2 つ目のアクセスキーを作成します。次のコマンドを実行します。

aws iam create-access-key

この時点で、ユーザーは 2 つのアクティブなアクセスキーを持っています。

2. 新しいアクセスキーを使用するようにすべてのアプリケーションとツールを更新します。
3. 次のコマンドを使用して、最初のアクセスキーがまだ使用中かどうかを確認します。

aws iam get-access-key-last-used

4. 1 つの方法は、数日待ってから、続行する前に古いアクセスキーが使われているかどうかを確認します。

ステップ 3 で古いキーが使用されていなくても、最初のアクセスキーをすぐに削除しないことをおすすめします。代わりに、次のコマンドを使用して、最初のアクセスキーの状態を Inactive に変更します。

aws iam update-access-key

5. 新しいアクセスキーのみを使用して、アプリケーションが動作していることを確認します。元のアクセスキーを引き続き使用しているアプリケーションやツールは、AWS リソースにアクセスできなくなるため、この時点で動作を停止します。該当するアプリケーションやツールが見つかった場合は、その状態を Active に戻すと、最初のアクセスキーを再度有効にできます。その後、ステップ 2 に戻り、新しいキーを使用するようにこのアプリケーションを更新します。

6. すべてのアプリケーションとツールが更新されたことを確認するまでしばらく待ってから、次のコマンドで最初のアクセスキーを削除できます。

aws iam delete-access-key

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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 を使用して、サーバー証明書の格納とデプロイを行うことができます。
ACM でサポートされていないリージョンで HTTPS 接続をサポートする必要がある場合にのみ、IAM を証明書マネージャーとして使用します。IAM は秘密鍵を安全に暗号化し、暗号化されたバージョンを IAM SSL 証明書ストレージに保存します。IAM ではすべてのリージョンでサーバー証明書をデプロイできますが、AWS で使用するには外部プロバイダから証明書を取得する必要があります。ACM 証明書は IAM にアップロードできません。また、IAM コンソールから証明書を管理することはできません。

推奨事項: AWS IAM に保存されていた期限切れの SSL / TLS 証明書がすべて削除されていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

現在、AWS 管理コンソールから期限切れの証明書を削除することはできません。AWS API を介して IAM に保存されている SSL/TLS 証明書を削除するには、コマンドライン インターフェース（CLI）を使用します。

AWS CLI

期限切れの証明書を削除するには、CERTIFICATE_NAME を削除する証明書の名前に置き換えて、次のコマンドを実行します。

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

上記のコマンドが成功した場合、出力は返されません。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Autoscaling Group Elb Healthcheck Required

API のカテゴリ名: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

これにより、ロードバランサに関連付けられた自動スケーリング グループが Elastic Load Balancing のヘルスチェックを使用しているかどうかを確認します。

これにより、ロードバランサによって提供される追加テストに基づいて、グループがインスタンスの健全性を判断できるようになります。Elastic Load Balancing ヘルスチェックを使用すると、EC2 自動スケーリング グループを使用するアプリケーションの可用性をサポートできます。

推奨事項: ロードバランサに関連付けられたすべての自動スケーリング グループがヘルスチェックを使用していることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

Elastic Load Balancing ヘルスチェックを有効にするには

1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。
2. ナビゲーション パネルの [自動スケーリング] で、[自動スケーリング グループ] を選択します。
3. グループのチェックボックスをオンにします。
4. [編集] を選択します。
5. [ヘルスチェック] の [ヘルスチェックのタイプ] で、[ELB] を選択します。
6. [ヘルスチェックの猶予期間] に「300」と入力します。
7. ページの下部にある [更新] を選択します。

自動スケーリング グループでロードバランサを使用する方法について詳しくは、AWS 自動スケーリング ユーザーガイドをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Auto Minor Version Upgrade Feature Enabled Rds Instances

API のカテゴリ名: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

指定したメンテナンスの時間枠内にマイナー エンジン アップグレードを自動的に受け取るために、RDS データベース インスタンスでマイナー バージョン アップグレード フラグが有効になっていることを確認します。これにより、RDS インスタンスは、データベース エンジンの新機能、バグ修正、セキュリティ パッチを取得できます。

推奨事項: RDS インスタンスで、マイナー バージョンの自動アップグレード機能が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/rds/ で RDS ダッシュボードに移動します。
2. 左側のナビゲーション パネルで、[Databases] をクリックします。
3. 更新する RDS インスタンスを選択します。
4. 右上にある [Modify] ボタンをクリックします。
5. [Modify DB Instance: <instance identifier>] ページの [Maintenance] セクションで、[Yes] ラジオボタンの [Auto minor version upgrade] を選択します。
6. ページの下部にある [Continue] をクリックします。変更をすぐに適用する場合は [Apply Immediately] をオンにします。ダウンタイムが発生しないようにするには [Apply during the next scheduled maintenance window] を選択します。
7. 変更内容を確認し、[Modify DB Instance] をクリックします。インスタンスのステータスが available から modifying に変わり、再び available になります。この機能が有効になると、Auto Minor Version Upgrade ステータスが Yes に変わります。

AWS CLI

1. describe-db-instances コマンドを実行して、選択した AWS リージョンで使用可能なすべての RDS データベース インスタンス名を一覧表示します。

aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'

2. コマンド出力で、各データベース インスタンス ID が返されます。
3. modify-db-instance コマンドを実行して、選択した RDS インスタンスの構成を変更します。このコマンドは、変更を直ちに適用します。次回の定期メンテナンスの時間枠内で変更を適用し、ダウンタイムを回避するには、--apply-immediately を削除します。

aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately

4. コマンド出力に、RDS インスタンスの新しい構成メタデータが表示され、AutoMinorVersionUpgrade パラメータ値を確認します。
5. describe-db-instances コマンドを実行して、自動マイナー バージョン アップグレード機能が正常に有効になっているかどうかを確認します。

aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'

6. コマンド出力では、true に設定された機能の現在のステータスが返されます。機能は enabled であり、マイナー エンジンのアップグレードが選択した RDS インスタンスに適用されます。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Aws Config Enabled All Regions

API のカテゴリ名: AWS_CONFIG_ENABLED_ALL_REGIONS

AWS Config は、アカウント内でサポートされている AWS リソースの構成管理を行い、ログファイルを配信するウェブサービスです。記録される情報には、構成項目（AWS リソース）、構成項目（AWS リソース）間の関係、リソース間の構成変更が含まれます。AWS Config をすべてのリージョンで有効にすることをおすすめします。

推奨事項: すべてのリージョンで AWS Config が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. コンソールの右上で、重視するリージョンを選択する
2. [サービス] をクリックする
3. [構成] をクリックする
4. このリージョンで構成レコーダーが有効になっている場合は、左側のナビゲーション メニューから [設定] ページに移動します。このリージョンで構成レコーダーがまだ有効になっていない場合は、[開始] を選択してください。
5. [このリージョンでサポートされるすべてのリソースを記録] を選択します。
6. グローバル リソース（IAM リソース）を含めるよう選択する
7. 同じアカウントまたは別のマネージド AWS アカウントの S3 バケットを指定する
8. 同じ AWS アカウントまたは別のマネージド AWS アカウントから SNS トピックを作成する

AWS CLI

1. AWS Config Service の前提条件に従って、適切な S3 バケット、SNS トピック、IAM ロールがあることを確認します。
2. 次のコマンドを実行して、新しい構成レコーダーを作成します。

aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::012345678912:role/myConfigRole --recording-group allSupported=true,includeGlobalResourceTypes=true

3. 以前に設定した前提条件から入力されたチャネル属性を指定する配信チャネル構成ファイルをローカルに作成します。

{
 "name": "default",
 "s3BucketName": "my-config-bucket",
 "snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
 "configSnapshotDeliveryProperties": {
 "deliveryFrequency": "Twelve_Hours"
 }
}

4. 次のコマンドを実行して、前のステップで作成した json 構成ファイルを参照する新しい配信チャネルを作成します。

aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json

5. 次のコマンドを実行して、構成レコーダーを起動します。

aws configservice start-configuration-recorder --configuration-recorder-name default

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Aws Security Hub Enabled

API のカテゴリ名: AWS_SECURITY_HUB_ENABLED

Security Hub は、AWS アカウント、サービス、サポートされているパートナー事業者のプロダクトからセキュリティ データを収集し、セキュリティの傾向を分析し、優先度が最も高いセキュリティ問題を特定するのに役立ちます。Security Hub を有効にすると、Amazon GuardDuty、Amazon Inspector、Amazon Macie などの有効にした AWS サービスからの検出結果の利用、集約、整理、優先順位付けが開始されます。AWS のパートナー セキュリティ プロダクトとの統合を有効にすることもできます。

推奨事項: AWS Security Hub が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. IAM ID の認証情報を使用して、Security Hub コンソールにログインします。
2. Security Hub コンソールを初めて開いた場合は、[AWS Security Hub を有効にする] を選択します。
3. スタートページには、セキュリティ標準によって Security Hub でサポートされているセキュリティ標準が一覧表示されます。
4. [Security Hub を有効にする] を選択します。

AWS CLI

1. enable-security-hub コマンドを実行します。デフォルトの標準を有効にするには、--enable-default-standards を含めます。

aws securityhub enable-security-hub --enable-default-standards

2. デフォルトの標準なしでセキュリティ ハブを有効にするには、--no-enable-default-standards を含めます。

aws securityhub enable-security-hub --no-enable-default-standards

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Cloudtrail Logs Encrypted Rest Using Kms Cmks

API のカテゴリ名: CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS

AWS CloudTrail は、アカウントの AWS API 呼び出しを記録し、IAM ポリシーに従ってユーザーとリソースがそのログを利用できるようにするウェブサービスです。AWS 鍵管理サービス（KMS）は、アカウント データの暗号化に使用する暗号鍵の作成と制御を支援するマネージド サービスで、ハードウェア セキュリティ モジュール（HSM）を使用して暗号鍵のセキュリティを保護します。サーバー側の暗号化（SSE）と KMS のお客様が作成したマスター鍵（CMK）を活用して、CloudTrail ログをさらに保護するように構成できます。SSE-KMS を使用するように CloudTrail を構成することをおすすめします。

推奨事項: CloudTrail ログが保存時に KMS CMK で暗号化されていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/cloudtrail で CloudTrail コンソールを開きます。
2. 左側のナビゲーション パネルで [Trails] を選択します。
3. 証跡をクリックする
4. S3 セクションで、編集ボタン（鉛筆アイコン）をクリックする
5. [Advanced] をクリックします。
6. [KMS key Id] プルダウン メニューから既存の CMK を選択します。
   - 注: CMK が S3 バケットと同じリージョンにあることを確認してください
   - 注: サービスとしての CloudTrail が提供された CMK を使用してログファイルを暗号化および復号するために、選択した CMK に KMS 鍵ポリシーを適用する必要があります。選択した CMK 鍵ポリシーを編集する手順については、こちらをご覧ください。
7. [Save] をクリックします。
8. ログファイルを復号するには、指定した KMS 鍵に対する復号権限が必要であることを示す通知メッセージが表示されます。
9. [Yes] をクリックします。

AWS CLI

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>

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Cloudtrail Log File Validation Enabled

API のカテゴリ名: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

CloudTrail ログファイルの検証では、CloudTrail が S3 に書き込む各ログのハッシュを含むデジタル署名されたダイジェスト ファイルが作成されます。これらのダイジェスト ファイルを使用して、CloudTrail がログを配信した後にログファイルが変更されたか、削除されたか、変更されていないかを判断できます。すべての CloudTrail でファイル検証を有効にすることをおすすめします。

推奨事項: CloudTrail ログファイルの検証が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/cloudtrail から IAM コンソールを開く
2. 左側のナビゲーション パネルで [Trails] をクリックする
3. ターゲット証跡をクリックする
4. [General details] セクションで [edit] をクリックする
5. [Advanced settings] セクション
6. [Log file validation] で [有効にする] チェックボックスをオンにする
7. [Save changes] をクリックします。

AWS CLI

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>

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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 サービスを使用してこれを行うネイティブな方法ですが、代替ソリューションの使用が排除されるわけではありません。

推奨事項: CloudTrail トレイルが CloudWatch Logs に統合されていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. https://console.aws.amazon.com/cloudtrail/ で CloudTrail コンソールにログインする
2. 更新が必要な Trail を選択します。
3. CloudWatch Logs まで下にスクロールする
4. [Edit] をクリックします。
5. CloudWatch Logs でボックス [Enabled] をクリックする
6. Log Group で、新規のロググループを選択するか、既存のロググループを選択する
7. CloudTrail と一致するように Log group name を編集するか、既存の CloudWatch グループを選択します。
8. IAM Role で、新規を選択するか、既存のものを選択します。
9. Role name を CloudTrail と一致するように編集するか、既存の IAM ロールを選択します。
10. [変更を保存] をクリックします。

AWS CLI

aws cloudtrail update-trail --name <trail_name> --cloudwatch-logs-log-group-arn <cloudtrail_log_group_arn> --cloudwatch-logs-role-arn <cloudtrail_cloudwatchLogs_role_arn>

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Cloudwatch Alarm Action Check

API のカテゴリ名: CLOUDWATCH_ALARM_ACTION_CHECK

これにより、Amazon Cloudwatch で、アラームが「OK」、「ALARM」、「INSUFFICIENT_DATA」の状態の間で遷移したときにアクションが定義されているかどうかがチェックされます。

Amazon CloudWatch のアラームで ALARM 状態に対するアクションを構成することは、モニタリング対象指標のしきい値に達したときに即時に応答するために非常に重要です。
これにより、問題を迅速に解決し、ダウンタイムを低減できます。また、自動修正やシステムの健全性の維持、システム停止の防止を実現できます。

アラームには少なくとも 1 つのアクションがあります。
アラームが他の状態から「INSUFFICIENT_DATA」状態に移行するとき、アラームには少なくとも 1 つのアクションがあります。
（省略可）アラームが他の状態から「OK」状態に移行すると、アラームには少なくとも 1 つのアクションがあります。

推奨事項: CloudWatch アラームで、少なくとも 1 つのアラーム アクション、1 つの INSUFFICIENT_DATA アクション、1 つの OK アクションのいずれかが有効になっているかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

Amazon CloudWatch アラームの ALARM アクションを構成するには、次の手順を行います。

1. https://console.aws.amazon.com/cloudwatch/ で Amazon CloudWatch コンソールを開きます。
2. ナビゲーション パネルの [アラーム] の下の [すべてのアラーム] を選択します。
3. 変更する Amazon CloudWatch アラームを選択し、[アクション] を選択して [編集] を選択します。
4. 左側で [ステップ 2 - オプションのアクションの設定] を選択します。
5. [アラーム状態トリガー] で [アラーム中] オプションを選択して、ALARM ベースのアクションを設定します。
6. 新しく作成した SNS トピックに通知を送信するには、[新しいトピックを作成] を選択します。
7. [新しいトピックを作成...] ボックスに、固有の SNS トピック名を指定します。
8. [通知を受信するメール エンドポイント] ボックスに、1 つ以上のメールアドレスを指定します。
9. 次に、[トピックを作成] を選択して、必要な Amazon SNS トピックを作成します。
10. 右下の [次へ]、[次へ] を選択し、[アラームを更新] を選択して変更を適用します。
11. メール クライアントを開き、AWS Notifications からのメール内のリンクをクリックして、該当する SNS トピックへの登録を確認します。
12. ステップ 4 ～ 11 を繰り返し、ステップ 5 で [アラーム状態トリガー] で [OK] と [データ不足] を選択して、この 2 つの状態に対応するアクションを設定します。
13. 同じ AWS リージョン内の他のすべての CloudWatch アラームについて、この手順を繰り返します。
14. 他のすべての AWS リージョンの他のすべての CloudWatch アラームについて、この手順を繰り返します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Cloudwatch Log Group Encrypted

API のカテゴリ名: CLOUDWATCH_LOG_GROUP_ENCRYPTED

このチェックにより、CloudWatch ログが KMS で構成されていることを確認できます。

ロググループ データは、CloudWatch Logs で常に暗号化されます。デフォルトでは、CloudWatch Logs は保存ログデータにサーバーサイド暗号化を使用します。この暗号化には、代わりに AWS 鍵管理サービスを使用できます。その場合、暗号化は AWS KMS 鍵を使用して行われます。AWS KMS を使用した暗号化は、ロググループの作成時または作成後に KMS 鍵をロググループに関連付けることで、ロググループ レベルで有効になります。

推奨事項: Amazon CloudWatch Logs のすべてのロググループが KMS を使用して暗号化されていることを確認してください

詳細については、Amazon CloudWatch ユーザーガイドの AWS Key Management Service を使用して CloudWatch ログ内のログデータを暗号化するをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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 トレイルが AWS CloudWatch にログを送信するように設定されていることを確認してください

CloudTrail を CloudWatch Logs と統合するには、AWS CloudTrail ユーザーガイドの CloudWatch ログへのイベントの送信をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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 は、意図しないデータ漏洩や不正アクセスにつながる可能性があるため、クリアテキストで保存しないでください。

推奨事項: 環境変数 AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY を含むすべてのプロジェクトが平文でないことを確認してください

CodeBuild プロジェクトから環境変数を削除するには、AWS CodeBuild ユーザーガイドの AWS CodeBuild でビルド プロジェクトの設定を変更するをご覧ください。環境変数に何も選択されていないことを確認します。

AWS Systems Manager Parameter Store または AWS Secrets Manager に機密性の高い値を含む環境変数を保存し、ビルド仕様からそれらを取得できます。手順については、AWS CodeBuild ユーザーガイドの環境セクションで重要というラベルの付いたボックスをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Codebuild Project Source Repo Url Check

API のカテゴリ名: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

これにより、AWS CodeBuild プロジェクトの Bitbucket ソース リポジトリ URL に個人用アクセス トークンが含まれているか、ユーザー名とパスワードが含まれているかをチェックします。Bitbucket ソース リポジトリの URL に個人用アクセス トークンまたはユーザー名とパスワードが含まれている場合、コントロールは失敗します。

ログイン認証情報を、クリアテキストで保存または送信することや、ソース リポジトリの URL に表示することはしないでください。個人用アクセス トークンまたはログイン認証情報の代わりに、CodeBuild でソース プロバイダにアクセスし、ソース リポジトリの URL を変更して Bitbucket リポジトリのロケーションへのパスのみを含める必要があります。個人用のアクセス トークンやログイン認証情報を使用すると、意図しないデータ漏洩や不正アクセスが発生する可能性があります。

推奨事項: github または bitbucket をソースとして使用するすべてのプロジェクトが OAuth を使用していることを確認してください

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 のユースケースベースのサンプルをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Credentials Unused 45 Days Greater Disabled

API のカテゴリ名: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

AWS IAM ユーザーは、パスワードやアクセスキーなど、さまざまな種類の認証情報を使用して AWS リソースにアクセスできます。45 日以上未使用の認証情報はすべて無効にするか削除することをおすすめします。

推奨事項: 45 日以上使用されていない認証情報が無効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

未使用のパスワード（IAM ユーザー コンソール アクセス）を管理するには、次の手順を行います

1. AWS 管理コンソールにログインします。
2. [Services] をクリックします。
3. [IAM] をクリックします。
4. [Users] をクリックする
5. [Security Credentials] をクリックする
6. Console last sign-in が 45 日を超えるユーザーを選択する
7. [Security credentials] をクリックします。
8. セクション [Sign-in credentials] で Console password [Manage] をクリックする
9. [コンソール アクセス] で Disable
   10 を選択し [Apply] をクリックする

アクセスキーを無効にするには、次の手順を行います。

1. AWS 管理コンソールにログインします。
2. [Services] をクリックします。
3. [IAM] をクリックします。
4. [Users] をクリックする
5. [Security Credentials] をクリックする
6. 45 日以上になっていて、使用されたアクセスキーを選択し、
   - [Make Inactive] をクリックする
7. 45 日以上経過し、まだ使用されていないアクセスキーを選択し、
   - Delete に対する [X] をクリックする

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Default Security Group Vpc Restricts All Traffic

API のカテゴリ名: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

VPC にはデフォルトのセキュリティ グループがあり、初期設定では、すべての受信トラフィックが拒否され、すべての送信トラフィックが許可され、セキュリティ グループに割り当てられたインスタンス間のすべてのトラフィックが許可されます。インスタンスの起動時にセキュリティ グループを指定しない場合、インスタンスはこのデフォルトのセキュリティ グループに自動的に割り当てられます。セキュリティ グループは、AWS リソースに上り（内向き）と下り（外向き）のネットワーク トラフィックのステートフル フィルタリングを提供します。デフォルトのセキュリティ グループですべてのトラフィックを制限することをおすすめします。

すべてのリージョンのデフォルトの VPC では、準拠するようにデフォルトのセキュリティ グループを更新する必要があります。新しく作成された 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 グループを使用すると、「名前」フィールドを編集できます。すべてのリージョンのすべての VPC のデフォルトのグループルールを修正した後、このフィールドを編集して「使用しない。ルールを追加しない」のようなテキストを追加する

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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 権限を制限します。

推奨事項: AWS Database Migration Service レプリケーション インスタンスがパブリックかどうかを確認してください

DMS レプリケーション インスタンスのパブリック アクセス設定は、作成後に変更することはできません。パブリック アクセスの設定を変更するには、現在のインスタンスを削除してから再作成します。[パブリック アクセス可能] のオプションは選択しないでください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

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 または Tools for Windows PowerShell の使用が必要な場合があります。その場合は、そのユーザーのアクセスキー（アクセスキー ID とシークレット アクセスキー）を作成します。

AWS 管理コンソールへのアクセス: ユーザーが AWS 管理コンソールにアクセスする必要がある場合、ユーザーのパスワードを作成します。

推奨事項: コンソール パスワードを持つすべての IAM ユーザーには、初期ユーザー設定時にアクセスキーを設定しないでください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインします。
2. [Services] をクリックします。
3. [IAM] をクリックします。
4. [Users] をクリックする
5. [Security Credentials] をクリックする
6. 管理者として
   - ユーザー プロファイルと同時に作成され、使用されていないキーの [X (Delete)] をクリックします。
7. IAM ユーザーとして
   - ユーザー プロファイルと同時に作成され、使用されていないキーの [X (Delete)] をクリックします。

AWS CLI

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Dynamodb Autoscaling Enabled

API のカテゴリ名: DYNAMODB_AUTOSCALING_ENABLED

これにより、Amazon DynamoDB テーブルが、必要に応じて読み取りおよび書き込み容量をスケーリングできるかどうかを確認します。このコントロールは、テーブルがオンデマンド容量モードまたは自動スケーリングが構成されたプロビジョニング モードのいずれかを使用している場合にパスします。需要に応じて容量をスケーリングすると、例外のスロットリングが回避され、アプリケーションの可用性を維持できます。

オンデマンド容量モードの DynamoDB テーブルは、DynamoDB スループットのデフォルトのテーブル割り当てによってのみ制限されます。これらの割り当てを増やすには、AWS サポートからサポート チケットを提出します。

自動スケーリングを使用するプロビジョニング モードの DynamoDB テーブルは、トラフィック パターンに応じてプロビジョニングされたスループット容量を動的に調整します。DynamoDB リクエスト スロットリングについて詳しくは、Amazon DynamoDB デベロッパー ガイドの「リクエスト スロットリングとバースト容量」をご覧ください。

推奨事項: DynamoDB テーブルは需要に合わせて容量を自動的にスケーリングする必要があります

容量モードで既存のテーブルで DynamoDB 自動スケーリングを有効にする詳細な手順については、Amazon DynamoDB デベロッパー ガイドの既存のテーブルでの DynamoDB 自動スケーリングの有効化をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Dynamodb In Backup Plan

API のカテゴリ名: DYNAMODB_IN_BACKUP_PLAN

このコントロールは、DynamoDB テーブルがバックアップ プランの対象となるかどうかを評価します。DynamoDB テーブルがバックアップ プランでカバーされていない場合、コントロールは失敗します。このコントロールは、ACTIVE 状態の DynamoDB テーブルのみを評価します。

バックアップを使用すると、セキュリティ インシデントからより速やかに復旧できます。また、システムの復元力も強化されます。バックアップ プランに DynamoDB テーブルを含めると、意図しない損失や削除からデータを保護できます。

推奨事項: DynamoDB テーブルはバックアップ プランの対象にする必要があります

DynamoDB テーブルを AWS Backup のバックアップ プランに追加するには、AWS Backup デベロッパー ガイドのバックアップ プランへのリソースの割り当てをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Dynamodb Pitr Enabled

API のカテゴリ名: DYNAMODB_PITR_ENABLED

ポイントインタイム リカバリ（PITR）は、DynamoDB テーブルをバックアップするために使用できるメカニズムの 1 つです。

ポイントインタイムのバックアップは 35 日間保持されます。長期保存が必要な場合は、AWS ドキュメントの AWS Backup を使用して Amazon DynamoDB のスケジュールされたバックアップを設定するをご覧ください。

推奨事項: すべての AWS DynamoDB テーブルでポイントインタイム リカバリ（PITR）が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

DynamoDB テーブルの PITR を設定するには、point_in_time_recovery ブロックを設定します。

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  point_in_time_recovery {
    enabled = true
  }
}

AWS コンソール

既存のテーブルの DynamoDB ポイントインタイム リカバリを有効にするには

1. https://console.aws.amazon.com/dynamodb/ で DynamoDB コンソールを開きます。
2. 対象のテーブルを選択し、[バックアップ] を選択します。
3. [ポイントインタイム リカバリ] セクションの [ステータス] で、[有効] を選択します。
4. [もう一度有効にする] を選択して変更を確定します。

AWS CLI

aws dynamodb update-continuous-backups \
  --table-name "GameScoresOnDemand" \
  --point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Dynamodb Table Encrypted Kms

API のカテゴリ名: DYNAMODB_TABLE_ENCRYPTED_KMS

すべての DynamoDB テーブルが、顧客管理の KMS 鍵（デフォルト以外）で暗号化されているかどうかを確認します。

推奨事項: すべての DynamoDB テーブルが AWS Key Management Service（KMS）で暗号化されていることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

このコントロールを修正するには、AWS KMS 鍵を作成し、それを使用して違反している DynamoDB リソースを暗号化します。

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 の暗号化に使用できる既存の AWS KMS 鍵があるとします。

DynamoDB テーブルの暗号化を顧客管理の KMS 鍵に変更するには。

1. https://console.aws.amazon.com/dynamodb/ で DynamoDB コンソールを開きます。
2. 対象の表を選択し、[追加の設定] を選択します。
3. 暗号化で、[暗号化を管理] を選択します。
4. 保存データの暗号化で [アカウントに保存し、ユーザーが所有、管理] を選択します。
5. 使用する AWS 鍵を選択します。変更を保存します

AWS CLI

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ebs Optimized Instance

API のカテゴリ名: EBS_OPTIMIZED_INSTANCE

EBS 用に最適化できる EC2 インスタンスで EBS の最適化が有効になっているかどうかを確認する

推奨事項: EBS 最適化をサポートするすべてのインスタンスで EBS 最適化が有効になっていることを確認してください

EBS の最適化インスタンス設定を構成するには、Amazon EC2 ユーザーガイドの Amazon EBS 用に最適化されたインスタンスをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ebs Snapshot Public Restorable Check

API のカテゴリ名: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

Amazon Elastic Block Store のスナップショットが公開されていないかどうかを確認します。Amazon EBS スナップショットを誰でも復元できる場合、コントロールは失敗します。

EBS スナップショットは、特定の時点で EBS ボリューム上のデータを Amazon S3 にバックアップするために使用されます。スナップショットを使用して、EBS ボリュームの以前の状態を復元できます。スナップショットを一般公開で共有することはほとんどありません。通常、スナップショットを一般公開する決定は誤りか、その影響を十分に理解することなく行われたものです。このチェックにより、そのような共有がすべて完全に計画され、意図されたものであることを確認できます。

推奨事項: Amazon EBS スナップショットは公的に復元可能であってはなりません

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

この問題を修正するには、EBS スナップショットを更新して、公開ではなく非公開にします。

公開 EBS スナップショットを非公開にするには:

1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。
2. ナビゲーション パネルの [Elastic Block Store] で [スナップショット] メニューを選択し、公開スナップショットを選択します。
3. [アクション] から [権限の変更] を選択します。
4. [非公開] を選択します。
5. （省略可）スナップショットを共有する承認済みアカウントの AWS アカウント番号を追加し、[権限を追加] を選択します。
6. [保存] を選択します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ebs Volume Encryption Enabled All Regions

API のカテゴリ名: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS

Elastic Compute Cloud（EC2）は、Elastic Block Store（EBS）サービス使用時の保存データの暗号化をサポートしています。デフォルトでは無効になっていますが、EBS ボリューム作成時の強制暗号化がサポートされています。

推奨事項: すべてのリージョンで EBS ボリュームの暗号化が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS マネジメント コンソールにログインし、https://console.aws.amazon.com/ec2/ を使用して Amazon EC2 コンソールを開く
2. [Account attributes] で [EBS encryption] をクリックします。
3. [Manage] をクリックします。
4. Enable チェックボックスをオンにします。
5. [Update EBS encryption] をクリックします。
6. 変更が必要なリージョンごとに手順を繰り返します。

注: EBS ボリュームの暗号化はリージョンごとに構成されます。

AWS CLI

1. 実行

aws --region <region> ec2 enable-ebs-encryption-by-default

2. "EbsEncryptionByDefault": true が表示されていることを確認します。
3. 変更が必要なリージョンごとに手順を繰り返します。

注: EBS ボリュームの暗号化はリージョンごとに構成されます。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ec2 Instances In Vpc

API のカテゴリ名: EC2_INSTANCES_IN_VPC

Amazon VPC は、EC2 Classic よりも多くのセキュリティ機能を提供します。すべてのノードを Amazon VPC に所属させることをおすすめします。

推奨事項: すべてのインスタンスが VPC に属していることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

Terraform で EC2 Classic インスタンスを定義している場合は、リソースを変更して VPC の一部にすることができます。この移行は、ニーズに最適なアーキテクチャによって変わります。以下は、VPC で一般公開されている EC2 を示す簡単な Terraform の例です。

  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 [e-mail]"
  }

  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"
    }
  }

AWS コンソール

EC2 Classic を VPC に移行するには、EC2-Classic から VPC への移行をご覧ください。

AWS CLI

この AWS CLI の例は、Terraform で定義されたのと同じインフラストラクチャを示しています。VPC で一般公開されている EC2 インスタンスの簡単な例

VPC を作成

  aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16

パブリック サブネットを作成する

  aws ec2 create-subnet \
  --availability-zone 1a \
  --cidr-block 10.0.1.0/24 \
  --vpc-id <id_from_create-vpc_command>

インターネット ゲートウェイを作成する

  aws ec2 create-internet-gateway

インターネット ゲートウェイを VPC に接続する

  aws ec2 attach-internet-gateway \
  --internet-gateway-id <id_from_create-internet-gateway_command> \
  --vpc-id <id_from_create-vpc_command>

鍵ペアを作成する - 秘密鍵が /.ssh/web-instance-key.pem に保存される

  aws ec2 create-key-pair \
  --key-name web-instance-key \
  --query "KeyMaterial" \
  --output text > ~/.ssh/web-instance-key.pem && \
  chmod 400 ~/.ssh/web-instance-key.pem

セキュリティ グループを作成する

  aws ec2 create-security-group \
  --group-name "http and ssh" \
  --vpc-id <id_from_create-vpc_command>

セキュリティ グループのルールを作成する - アクセスをさらに制限するには、ポート 22 で SSH をより制限した CIDR を定義する

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-egress \
  --group-id <id_from_create-security-group_command>
  --protocol -1 \
  --port 0 \
  --cidr 0.0.0.0/0

EC2 インスタンスを作成する

  aws ec2 run-instances \
  --image-id <ami_id> \
  --instance-type <instance_flavor> \
  --metadata-options "HttpEndpoint=enabled,HttpTokens=required" \
  --monitoring true \
  --key-name web-instance-key \
  --subnet-id <id_from_create-subnet_command> \
  --security-group-ids <id_from_create-security-group_command>

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ec2 Instance No Public Ip

API のカテゴリ名: EC2_INSTANCE_NO_PUBLIC_IP

パブリック IP アドレスを持つ EC2 インスタンスは、侵害のリスクが高くなります。EC2 インスタンスは、パブリック IP アドレスで構成しないようにすることをおすすめします。

推奨事項: インスタンスにパブリック IP がないことを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

aws_instance リソースで associate_public_ip_address = false 引数を使用して、パブリック IP アドレスなしで EC2 インスタンスがプロビジョニングされるようにする

resource "aws_instance" "no_public_ip" {
  ...
  associate_public_ip_address = false
}

AWS コンソール

デフォルトでは、デフォルト以外のサブネットの IPv4 パブリック アドレス属性は false に設定されており、デフォルトのサブネットではこの属性が true に設定されています。例外は、Amazon EC2 起動インスタンス ウィザードによって作成されたデフォルト以外のサブネットです。ウィザードはこの属性を true に設定します。この属性は、Amazon VPC コンソールを使用して変更できます。

サブネットのパブリック IPv4 アドレス指定の動作を変更する

1. https://console.aws.amazon.com/vpc/ で Amazon VPC コンソールを開きます。
2. ナビゲーション パネルで [サブネット] を選択します。
3. サブネットを選択し、[アクション]、[サブネット設定を編集] を選択します。
4. [パブリック IPv4 アドレスの自動割り当てを有効にする] チェックボックスをオンにすると、選択したサブネットで起動されたすべてのインスタンスにパブリック IPv4 アドレスをリクエストします。必要に応じてチェックボックスをオンまたはオフにしてから、[保存] を選択します。

AWS CLI

次のコマンドは、パブリック IP アドレスを関連付けずに、デフォルト サブネットで EC2 インスタンスを実行します。

aws ec2 run-instances \
--image-id <ami_id> \
--instance-type <instance_flavor> \
--no-associate-public-ip-address \
--key-name MyKeyPair

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ec2 Managedinstance Association Compliance Status Check

API のカテゴリ名: EC2_MANAGEDINSTANCE_ASSOCIATION_COMPLIANCE_STATUS_CHECK

State Manager の関連付けは、マネージド インスタンスに割り当てられる構成です。この構成は、インスタンスで維持する状態を定義します。関連付けでは、たとえば、インスタンスにウイルス対策ソフトウェアをインストールして実行する必要があることや、特定のポートを閉じる必要があることを指定できます。AWS Systems Managerと関連付けられている EC2 インスタンスは Systems Manager の管理下にあるため、パッチの適用、構成ミスの修正、セキュリティ イベントへの対応が容易になります。

推奨事項: AWS システム マネージャーの関連付けのコンプライアンス ステータスを確認します

この検出結果を修正するには、次の操作を完了します。

Terraform

次の例は、単純な EC2 インスタンス、AWS Systems Manager（SSM）ドキュメント、および SSM と EC2 インスタンスとの関連付けを作成する方法を示しています。サポートされているドキュメントは、Command タイプと Policy タイプです。

resource "aws_instance" "web" {
  ami           = "<iam_id>"
  instance_type = "<instance_flavor>"
}

resource "aws_ssm_document" "check_ip" {
  name          = "check-ip-config"
  document_type = "Command"

  content = <<DOC
  {
    "schemaVersion": "1.2",
    "description": "Check ip configuration of a Linux instance.",
    "parameters": {

    },
    "runtimeConfig": {
      "aws:runShellScript": {
        "properties": [
          {
            "id": "0.aws:runShellScript",
            "runCommand": ["ifconfig"]
          }
        ]
      }
    }
  }
DOC
}

resource "aws_ssm_association" "check_ip_association" {
  name = aws_ssm_document.check_ip.name

  targets {
    key    = "InstanceIds"
    values = [aws_instance.web.id]
  }
}

AWS コンソール

コンソールを使用して AWS Systems Manager との関連付けを構成する方法については、AWS Systems Manager のドキュメントの関連付けの作成をご覧ください。

AWS CLI

SSM ドキュメントを作成する

aws ssm create-document \
--name <document_name> \
--content  file://path/to-file/document.json \
--document-type "Command"

SSM 関連付けを作成する

aws ssm create-association \
--name <association_name> \
--targets "Key=InstanceIds,Values=<instance-id-1>,<instance-id-2>"

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ec2 Managedinstance Patch Compliance Status Check

API のカテゴリ名: EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK

このコントロールは、インスタンスで関連付けが実行された後、AWS Systems Manager の関連付けのコンプライアンス ステータスが COMPLIANT または NON_COMPLIANT かどうかを確認します。関連付けのコンプライアンス ステータスが NON_COMPLIANT の場合、コントロールは失敗します。

State Manager の関連付けは、マネージド インスタンスに割り当てられる構成です。この構成は、インスタンスで維持する状態を定義します。関連付けでは、たとえば、インスタンスにウイルス対策ソフトウェアをインストールして実行する必要があることや、特定のポートを閉じる必要があることを指定できます。

1 つ以上の State Manager の関連付けを作成すると、コンプライアンス ステータス情報を直ちに入手できます。コンプライアンス ステータスは、コンソールで、または AWS CLI コマンドや対応する Systems Manager API アクションに応じて確認できます。関連付けについては、[設定のコンプライアンス] にコンプライアンス ステータス（準拠または非準拠）が表示されます。また、関連付けに割り当てられた重大度レベル（重大、中など）も表示されます。

State Manager の関連付けのコンプライアンスの詳細については、AWS Systems Manager ユーザーガイドの State Manager の関連付けのコンプライアンスについてをご覧ください。

推奨事項: AWS Systems Manager のパッチ コンプライアンスのステータスを確認してください

関連付けの失敗は、ターゲットや SSM ドキュメント名など、異なるものに関連している可能性があります。この問題を解決するには、まず関連付け履歴を表示して関連付けを特定および調査する必要があります。関連付け履歴を表示する手順については、AWS Systems Manager ユーザーガイドの関連付け履歴の表示をご覧ください。

調査後に、関連付けを編集して、特定された問題を修正できます。関連付けを編集して、新しい名前、スケジュール、重大度、ターゲットを指定できます。関連付けを編集すると、AWS Systems Manager によって新しいバージョンが作成されます。関連付けを編集する手順については、AWS Systems Manager ユーザーガイドの関連付けの新しいバージョンの編集と作成をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ec2 Metadata Service Allows Imdsv2

API のカテゴリ名: EC2_METADATA_SERVICE_ALLOWS_IMDSV2

AWS EC2 インスタンスでメタデータ サービスを有効にする場合、ユーザーはインスタンス メタデータ サービス バージョン 1（IMDSv1、リクエスト / レスポンス メソッド）またはインスタンス メタデータ サービス バージョン 2（IMDSv2、セッション指向メソッド）のいずれかを使用できます。

推奨事項: EC2 メタデータ サービスが IMDSv2 のみを許可するようにしてください

コンソールから:
1. AWS マネジメント コンソールにログインし、https://console.aws.amazon.com/ec2/ を使用して Amazon EC2 コンソールを開く
2. [インスタンス] メニューで [インスタンス] を選択します。
3. 各インスタンスで、インスタンスを選択し、[アクション] > [インスタンス メタデータの変更] を選択します。
4. インスタンス メタデータ サービスが有効になっている場合は、IMDSv2 を [必須] に設定します。

コマンドラインから:

aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-tokens required

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Ec2 Volume Inuse Check

API のカテゴリ名: EC2_VOLUME_INUSE_CHECK

AWS の毎月の請求費用を削減するために、AWS アカウントでアタッチされていない（未使用の）Elastic Block Store（EBS）ボリュームを特定して削除します。未使用の EBS ボリュームを削除することで、機密データやセンシティブ データが漏洩するリスクも軽減されます。さらに、このコントロールでは、EC2 インスタンスが終了時にボリュームを削除するように構成されたかどうかも確認します。

デフォルトでは、EC2 インスタンスは、インスタンスに関連付けられた任意の EBS ボリュームのデータを削除し、インスタンスのルート EBS ボリュームを削除するように構成されています。ただし、起動時または実行中にインスタンスにアタッチされたルート以外の EBS ボリュームは、デフォルトで終了後に保持されます。

推奨事項: EBS ボリュームが EC2 インスタンスにアタッチされており、インスタンスの終了時に削除されるように構成されているかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

Terraform を使用してこのシナリオを回避するには、EBS ブロックが埋め込まれた EC2 インスタンスを作成します。これにより、属性 ebs_block_device.delete_on_termination がデフォルトの true に設定されるため、インスタンスに関連付けられている EBS ブロック（ルートだけでなく）が、インスタンスの終了時に削除されるようになります。

resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    ebs_block_device {
      delete_on_termination = true # Default
      device_name           = "/dev/sdh"
    }

AWS コンソール

コンソールを使用して EBS ボリュームを削除するには

1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。
2. ナビゲーション パネルで、[ボリューム] を選択します。
3. 削除するボリュームを選択し、[アクション]、[ボリュームを削除] を選択します。
4. 注: [ボリュームを削除] がグレー表示されている場合、ボリュームはインスタンスにアタッチされています。ボリュームを削除する前に、インスタンスからボリュームを切断する必要があります。
5. 確認のダイアログ ボックスで、[削除] を選択します。

AWS CLI

次のコマンドの例では、vol-049df61146c4d7901 のボリューム ID を持つ使用可能なボリュームを削除します。コマンドが成功した場合、出力は返されません。

aws ec2 delete-volume --volume-id vol-049df61146c4d7901

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Efs Encrypted Check

API のカテゴリ名: EFS_ENCRYPTED_CHECK

Amazon EFS では、ファイル システムの暗号化形式として、転送中のデータの暗号化と保存データの暗号化の 2 つをサポートしています。これにより、アカウントで有効なすべてのリージョンで、すべての EFS ファイル システムに保存データの暗号化が構成されていることを確認します。

推奨事項: KMS を使用してファイルデータを暗号化するように EFS が構成されているかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

次のコード スニペットを使用して、KMS で暗号化された EFS を作成できます（注: kms_key_id 属性はオプションです。KMS 鍵 ID が渡されない場合、鍵が作成されます）

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-kms-encrypted-efs"
  encrypted      = true
  kms_key_id     = "arn:aws:kms:us-west-2:12344375555:key/16393ebd-3348-483f-b162-99b6648azz23"

  tags = {
    Name = "MyProduct"
  }
}

AWS コンソール

AWS コンソールを使用して暗号化で EFS を構成するには、コンソールを使用して保存ファイル システムを暗号化するをご覧ください。

AWS CLI

コンソールから EFS を作成すると、デフォルトで保存データの暗号化が有効になりますが、CLI、API、SDK を使用して作成した EFS には当てはまりません。次の例では、インフラストラクチャ内に暗号化されたファイル システムを作成できます。

aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Efs In Backup Plan

API のカテゴリ名: EFS_IN_BACKUP_PLAN

Amazon のベスト プラクティスでは、Elastic File Systems（EFS）のバックアップを構成することをおすすめします。これにより、AWS アカウントの有効なすべてのリージョンで、有効なバックアップについてすべての EFS を確認します。

推奨事項: EFS ファイル システムが AWS バックアップ プランに含まれているかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

aws_efs_backup_policy リソースを使用して、EFS ファイル システムのバックアップ ポリシーを構成します。

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-encrypted-efs"
  encrypted      = true

  tags = merge({
    Name = "${local.resource_prefix.value}-efs"
    }, {
    git_file             = "terraform/aws/efs.tf"
    git_org              = "your_git_org"
    git_repo             = "your_git_repo"
  })
}

resource "aws_efs_backup_policy" "policy" {
  file_system_id = aws_efs_file_system.encrypted-efs.id

  backup_policy {
    status = "ENABLED"
  }
}

AWS コンソール

EFS をバックアップする方法は、AWS Backup サービスと EFS から EFS へのバックアップ ソリューションの 2 つです。コンソールを使用してバックアップされていない EFS を修正するには、以下をご覧ください。

1. AWS Backup を使用して Amazon EFS ファイル システムをバックアップおよび復元する
2. EFS から EFS へのバックアップ

AWS CLI

CLI を使用して準拠する EFS ファイル システムを作成するには、いくつかの方法があります。

1. 自動バックアップを有効にして EFS を作成する（デフォルトは 1 ゾーン ストレージで、AWS リージョンのバックアップの可用性を条件とする）
2. EFS を作成してバックアップ ポリシーを配置する

ただし、既存の EFS で修復を行う必要がある場合の最善のオプションは、バックアップ ポリシーを作成し、それを非準拠の EFS に関連付けることです。インフラストラクチャ内の EFS ごとに 1 つのコマンドが必要です。

arr=( $(aws efs describe-file-systems | jq -r '.FileSystems[].FileSystemId') )
for efs in "${arr[@]}"
do
  aws efs put-backup-policy \
  --file-system-id "${efs}" \
  --backup-policy "Status=ENABLED"
done

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Elb Acm Certificate Required

API のカテゴリ名: ELB_ACM_CERTIFICATE_REQUIRED

従来型ロードバランサが AWS Certificate Manager（ACM）によって提供される HTTPS/SSL 証明書を使用するかどうかを確認します。HTTPS/SSL リスナーで構成された従来型ロードバランサが ACM から提供された証明書を使用しない場合、コントロールは失敗します。

証明書を作成するには、ACM、または SSL プロトコルと TLS プロトコルをサポートするツール（OpenSSL など）を使用できます。Security Hub では、ロードバランサの証明書を作成またはインポートするために ACM を使用することをおすすめします。

ACM は従来型ロードバランサと統合されているため、ロードバランサに証明書をデプロイできます。また、これらの証明書を自動更新する必要があります。

推奨事項: すべての従来型ロードバランサで AWS Certificate Manager が提供する SSL 証明書を使用していることを確認してください

ACM SSL/TLS 証明書を従来型ロードバランサに関連付ける方法については、AWS Knowledge Center の記事 ACM SSL/TLS 証明書を従来型、アプリケーション、ネットワーク ロードバランサに関連付ける方法をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Elb Deletion Protection Enabled

API のカテゴリ名: ELB_DELETION_PROTECTION_ENABLED

アプリケーション ロードバランサで削除保護が有効になっているかどうかを確認します。削除保護が構成されていない場合、コントロールは失敗します。

削除保護を有効にして、アプリケーション ロードバランサを削除から保護します。

推奨事項: アプリケーション ロードバランサの削除保護を有効にする必要があります

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

ロードバランサが誤って削除されないように、削除保護を有効にできます。デフォルトでは、ロードバランサの削除保護は無効になっています。

ロードバランサの削除保護を有効にした場合は、ロードバランサを削除する前に削除保護を無効にする必要があります。

コンソールからの削除保護を有効にするには。

1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。
2. ナビゲーション パネルの [ロード バランシング] で、[ロードバランサ] を選択します。
3. ロードバランサを選択します。
4. [説明] タブで [属性を編集] を選択します。
5. [ロードバランサの属性を編集] ページで、[削除からの保護を有効にする] を選択し、[保存] を選択します。
6. [Save] を選択します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Elb Logging Enabled

API のカテゴリ名: ELB_LOGGING_ENABLED

これにより、アプリケーション ロードバランサと従来型ロードバランサでロギングが有効になっているかどうかを確認します。access_logs.s3.enabled が false の場合、コントロールは失敗します。

Elastic Load Balancing は、ロードバランサに送信されたリクエストに関する詳細情報をキャプチャするアクセスログを提供します。各ログには、リクエストの受信時刻、クライアントの IP アドレス、レイテンシ、リクエストパス、サーバー レスポンスなどの情報が含まれます。これらのアクセスログを使用して、トラフィック パターンを分析し、問題のトラブルシューティングを行うことができます。

詳細については、従来型ロードバランサのユーザーガイドの 従来型ロードバランサのログにアクセスするをご覧ください。

推奨事項: 従来型ロードバランサとアプリケーション ロードバランサのロギングが有効になっているかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

この問題を修正するには、ロードバランサを更新してロギングを有効にします。

アクセスログを有効にするには

1. https://console.aws.amazon.com/ec2/ で Amazon EC2 コンソールを開きます。
2. ナビゲーション パネルで、[ロードバランサ] を選択します。
3. アプリケーション ロードバランサまたは従来のロードバランサを選択します。
4. [アクション] から [属性を編集] を選択します。
5. [アクセスログ] で [有効にする] を選択します。
6. S3 のロケーションを入力します。このロケーションは、存在するか、自動的に作成することもできます。接頭辞を指定しない場合、アクセスログは S3 バケットのルートに保存されます。
7. [Save] を選択します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Elb Tls Https Listeners Only

API のカテゴリ名: ELB_TLS_HTTPS_LISTENERS_ONLY

このチェックにより、すべての従来のロードバランサが安全な通信を使用するように構成されていることを確認します。

リスナーは接続リクエストを確認するプロセスです。フロントエンド（クライアントからロードバランサ）接続用のプロトコルとポート、バックエンド（ロードバランサからインスタンス）接続用のプロトコルとポートで構成されます。Elastic Load Balancing でサポートされているポート、プロトコル、リスナー構成については、従来型ロードバランサのリスナーをご覧ください。

推奨事項: すべての従来型ロードバランサが SSL リスナーまたは HTTPS リスナーを使用して構成されていることを確認してください

従来型ロードバランサの SSL または TLS を構成するには、AWS 管理コンソールを使用して HTTPS/SSL ロードバランサを作成するをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Encrypted Volumes

API のカテゴリ名: ENCRYPTED_VOLUMES

アタッチされた状態の EBS ボリュームが暗号化されているかどうかを確認します。このチェックに合格するには、EBS ボリュームが使用中であり、暗号化されている必要があります。EBS ボリュームがアタッチされていない場合、このチェックの対象ではありません。

EBS ボリューム内の機密データのセキュリティを強化するには、EBS の保存データの暗号化を有効にする必要があります。Amazon EBS の暗号化は、独自の鍵管理インフラストラクチャを構築、維持、保護しなくても、EBS リソース用の簡単な暗号化ソリューションを提供します。暗号化されたボリュームとスナップショットを作成するときに、KMS 鍵を使用します。

Amazon EBS の暗号化の詳細については、Linux インスタンス用の Amazon EC2 ユーザーガイドの Amazon EBS 暗号化をご覧ください。

推奨事項: アタッチされた Amazon EBS ボリュームは保存時に暗号化される必要があります

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

暗号化されていない既存のボリュームまたはスナップショットを直接暗号化する方法はありません。新しいボリュームまたはスナップショットは作成時にのみ暗号化できます。

デフォルトで暗号化を有効にしている場合、Amazon EBS は、Amazon EBS の暗号化のデフォルトの鍵を使用して、生成された新しいボリュームまたはスナップショットを暗号化します。デフォルトで暗号化が有効になっていない場合でも、個々のボリュームまたはスナップショットを作成する際に暗号化を有効にできます。どちらの場合も、Amazon EBS の暗号化用のデフォルトの鍵をオーバーライドし、対称の顧客管理の暗号鍵を選択できます。

詳細については、Linux インスタンス用の Amazon EC2 ユーザーガイドの Amazon EBS ボリュームの作成と Amazon EBS スナップショットのコピーをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Encryption At Rest Enabled Rds Instances

API のカテゴリ名: ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES

Amazon RDS 暗号化 DB インスタンスは、業界標準の AES-256 暗号化アルゴリズムを使用して、Amazon RDS DB インスタンスをホストするサーバー上のデータを暗号化します。データを暗号化した後、Amazon RDS は、パフォーマンスへの影響を最小限に抑えながら、データのアクセス認証と復号を透過的に処理します。

推奨事項: RDS インスタンスに対して保存データの暗号化が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/rds/ で RDS ダッシュボードを開きます。
2. 左側のナビゲーション パネルで、[Databases] をクリックする
3. 暗号化が必要なデータベース インスタンスを選択します。
4. 右上にある [Actions] ボタンをクリックして、[Take Snapshot] を選択します。
5. [スナップショットを取得] ページで、[Snapshot Name] フィールドにスナップショットを作成するデータベース名を入力し、[Take Snapshot] をクリックします。
6. 新しく作成したスナップショットを選択し、右上にある [Action] ボタンをクリックし、[操作] メニューから [Copy snapshot] を選択します。
7. [DB スナップショットのコピーを作成] ページで、次の操作を行います。

• [新しい DB スナップショット ID] フィールドに、new snapshot の名前を入力します。
• Copy Tags を確認します。新しいスナップショットには、ソース スナップショットと同じタグが必要です。
• [Enable Encryption] プルダウン リストから [Yes] を選択して暗号化を有効にします。AWS のデフォルトの暗号鍵、または [マスター鍵] プルダウン リストからカスタム鍵のどちらを使用するかを選択できます。

8. [Copy Snapshot] をクリックして、選択したインスタンス スナップショットの暗号化されたコピーを作成します。
9. 新しいスナップショットの暗号化コピーを選択し、右上にある [Action] ボタンをクリックし、[操作] メニューから [Restore Snapshot] ボタンを選択します。これにより、暗号化されたスナップショットが新しいデータベース インスタンスに復元されます。
10. [DB インスタンスの復元] ページで、[DB インスタンス ID] フィールドに新しいデータベース インスタンスの一意の名前を入力します。
11. インスタンス構成の詳細を確認し、[Restore DB Instance] をクリックします。
12. 新しいインスタンスのプロビジョニング プロセスが完了したら、新しい暗号化されたデータベース インスタンスのエンドポイントを参照するようにアプリケーションの構成を更新できます。アプリケーション レベルでデータベース エンドポイントを変更すると、暗号化されていないインスタンスを削除できます。

AWS CLI

1. describe-db-instances コマンドを実行して、選択した AWS リージョンで使用可能なすべての RDS データベース名を一覧表示します。コマンド出力で、データベース インスタンス ID が返されます。

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

2. create-db-snapshot コマンドを実行して、選択したデータベース インスタンスのスナップショットを作成します。コマンド出力で、名前 DB Snapshot Name を持つ new snapshot が返されます。

aws rds create-db-snapshot --region <region-name> --db-snapshot-identifier <DB-Snapshot-Name> --db-instance-identifier <DB-Name>

3. list-aliases コマンドを実行して、指定したリージョンで使用可能な KMS 鍵のエイリアスを一覧表示します。コマンド出力で各 key alias currently available が返されます。RDS 暗号化の有効化プロセスでは、AWS のデフォルトの KMS 鍵の ID を確認します。

aws kms list-aliases --region <region-name>

4. 前に返された RDS インスタンス用のデフォルトの KMS 鍵 ID を使用して copy-db-snapshot コマンドを実行し、データベース インスタンス スナップショットの暗号化されたコピーを作成します。コマンド出力で encrypted instance snapshot configuration が返されます。

aws rds copy-db-snapshot --region <region-name> --source-db-snapshot-identifier <DB-Snapshot-Name> --target-db-snapshot-identifier <DB-Snapshot-Name-Encrypted> --copy-tags --kms-key-id <KMS-ID-For-RDS>

5. restore-db-instance-from-db-snapshot コマンドを実行して、前の手順で作成した暗号化されたスナップショットを新しいデータベース インスタンスに復元します。正常な場合、コマンド出力で、暗号化された新しいデータベース インスタンスの構成が返されます。

aws rds restore-db-instance-from-db-snapshot --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --db-snapshot-identifier <DB-Snapshot-Name-Encrypted>

6. describe-db-instances コマンドを実行して、選択した AWS リージョンで使用可能なすべての RDS データベース名を一覧表示します。出力で、データベース インスタンス ID 名が返されます。今作成した DB-Name-Encrypted のデータベースの暗号化データベース名を選択します。

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

7. 先ほど返された RDS インスタンス ID を使用して describe-db-instances コマンドを再度実行し、選択したデータベース インスタンスが暗号化されているかどうかを確認します。コマンド出力で、暗号化ステータス True が返されます。

aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Encryption Enabled Efs File Systems

API のカテゴリ名: ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS

EFS データは、AWS KMS（鍵管理サービス）を使用して保存時に暗号化する必要があります。

推奨事項: EFS ファイル システムで暗号化が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインし、Elastic File System (EFS) ダッシュボードに移動します。
2. 左側のナビゲーション パネルで [File Systems] を選択します。
3. ダッシュボードのトップメニューで [Create File System] ボタンをクリックして、ファイル システムの設定プロセスを開始します。

4. [Configure file system access 構成] ページで、次の手順を行います。
   - VPC プルダウン リストから適切な VPC を選択します。
   - [マウント ターゲットの作成] セクション内で、選択した VPC 内のすべてのアベイラビリティ ゾーン（AZ）のチェックボックスをオンにします。これらがマウント ターゲットになります。
   - [Next step] をクリックして続行します。

5. [Configure optional settings] ページで次の操作を行います。
   - tags を作成して新しいファイル システムを記述します。
   要件に基づいて [performance mode] を選択します。
   - [Enable encryption] チェックボックスをオンにして、[KMS マスター鍵を選択] プルダウン リストから [aws/elasticfilesystem] を選択し、AWS KMS によって提供、管理されるデフォルトのマスター鍵を使用した新しいファイル システムの暗号化を有効にします。
   - [Next step] をクリックして続行します。

6. [review and create] ページでファイル システム構成の詳細を確認し、[Create File System] をクリックして新しい AWS EFS ファイル システムを作成します。

7. データを暗号化されていない古い EFS ファイル システムから、新しく作成した暗号化ファイル システムにコピーします。
8. 新しく作成された暗号化されたファイル システムへのデータ移行が完了したら、すぐに暗号化されていないファイル システムを削除します。
9. ナビゲーション バーから AWS リージョンを変更し、他の AWS リージョンについて手順全体を繰り返します。

CLI から:
1. describe-file-systems コマンドを実行して、選択した（暗号化されていない）ファイル システムで使用できる構成情報を記述します（適切なリソースを特定するには監査セクションを参照してください）。

aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>

2. コマンド出力で、リクエストされた構成情報が返されます。
3. 新しい AWS EFS ファイル システムをプロビジョニングするには、create-file-system コマンドに必要なトークンを作成するために、Universally Unique Identifier（UUID）を生成する必要があります。必要なトークンを作成するには、「https://www.uuidgenerator.net」からランダムに生成された UUID を使用します。
4. 前の手順で作成した一意のトークンを使用して、create-file-system コマンドを実行します。

aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted

5. コマンド出力で、新しいファイル システム構成メタデータが返されます。
6. 前の手順で返された新しく作成した EFS ファイル システム ID と、マウント ターゲットを表す可用性ゾーン（AZ）の ID を使用して、create-mount-target コマンドを実行します。

aws efs create-mount-target --region <region> --file-system-id <file-system-id> --subnet-id <subnet-id>

7. コマンド出力で、新しいマウント ターゲットのメタデータが返されます。
8. これで、EC2 インスタンスからファイル システムをマウントできるようになりました。
9. データを暗号化されていない古い EFS ファイル システムから、新しく作成した暗号化ファイル システムにコピーします。
10. 新しく作成された暗号化されたファイル システムへのデータ移行が完了したらすぐに、暗号化されていないファイル システムを削除します。

aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>

11. --region を更新して AWS リージョンを変更し、他の AWS リージョンに対してプロセス全体を繰り返します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Iam Password Policy

API のカテゴリ名: IAM_PASSWORD_POLICY

AWS では、AWS アカウントのカスタム パスワード ポリシーで、IAM ユーザーのパスワードに複雑な要件と必須のローテーション期間を指定できます。カスタム パスワード ポリシーを設定しない場合、IAM ユーザー パスワードはデフォルトの AWS パスワード ポリシーを満たしている必要があります。AWS のセキュリティに関するベスト プラクティスでは、次のパスワード要件が推奨されています。

• パスワードに大文字を 1 つ以上含めることを必須とします。
• パスワードに小文字を 1 つ以上含めることを必須とします。
• パスワードに記号を 1 つ以上含めることを必須とします。
• パスワードに 1 つ以上の数字を含めることを必須とします。
• パスワードは 14 文字以上にすることを必須とします。
• 再利用を許可する前に 24 個以上のパスワードを必須とします。
• パスワードの有効期限は 90 日以上を必須とします

このコントロールにより、指定されたすべてのパスワード ポリシー要件が確認されます。

推奨事項: IAM ユーザーのアカウント パスワード ポリシーで指定の要件が満たされているかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

resource "aws_iam_account_password_policy" "strict" {
  allow_users_to_change_password = true
  require_uppercase_characters   = true
  require_lowercase_characters   = true
  require_symbols                = true
  require_numbers                = true
  minimum_password_length        = 14
  password_reuse_prevention      = 24
  max_password_age               = 90
}

AWS コンソール

カスタム パスワード ポリシーを作成するには

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. ナビゲーション パネルで [アカウント設定] を選択します。
3. [パスワード ポリシー] セクションで、[パスワード ポリシーを変更] を選択します。
4. パスワード ポリシーに適用するオプションを選択し、[変更を保存] を選択します。

カスタム パスワード ポリシーを変更するには

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. ナビゲーション パネルで [アカウント設定] を選択します。
3. [パスワード ポリシー] セクションで、[変更] を選択します。
4. パスワード ポリシーに適用するオプションを選択し、[変更を保存] を選択します。

AWS CLI

aws iam update-account-password-policy \
--allow-users-to-change-password \
--require-uppercase-characters \
--require-lowercase-characters \
--require-symbols \
--require-numbers \
--minimum-password-length 14 \
--password-reuse-prevention 24 \
--max-password-age 90

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Iam Password Policy Prevents Password Reuse

API のカテゴリ名: IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE

IAM パスワード ポリシーを使用すると、同じユーザーが特定のパスワードを再利用しないようにすることができます。パスワード ポリシーで、パスワードの再利用を防止することをおすすめします。

推奨事項: IAM パスワード ポリシーでパスワードの再利用が禁止されていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS コンソールにログインする（Identity Access Management のアカウント設定を表示するための適切な権限を使用して）
2. AWS コンソールで IAM サービスに移動する
3. 左側のペインで [アカウント設定] をクリックする
4. [パスワードの再利用を防止する] チェックボックスをオンにする
5. [保存するパスワードの数] を 24 に設定する

AWS CLI

 aws iam update-account-password-policy --password-reuse-prevention 24

注:「aws iam update-account-password-policy」で始まるコマンドはすべて、1 つのコマンドに結合できます。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Iam Password Policy Requires Minimum Length 14 Greater

API のカテゴリ名: IAM_PASSWORD_POLICY_REQUIRES_MINIMUM_LENGTH_14_GREATER

パスワード ポリシーの一部は、パスワードの複雑さに関する要件を適用するために使用されます。IAM パスワード ポリシーを使用して、パスワードが所定の長さ以上になるようにできます。パスワード ポリシーでは、最小のパスワードの長さを 14 文字にすることをおすすめします。

推奨事項: IAM パスワード ポリシーで 14 文字以上の長さが必須になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS コンソールにログインする（Identity Access Management のアカウント設定を表示するための適切な権限を使用して）
2. AWS コンソールで IAM サービスに移動する
3. 左側のペインで [アカウント設定] をクリックする
4. [パスワードの最小文字数] を 14 以上に設定します。
5. [パスワード ポリシーを適用] をクリックする

AWS CLI

 aws iam update-account-password-policy --minimum-password-length 14

注:「aws iam update-account-password-policy」で始まるコマンドはすべて、1 つのコマンドに結合できます。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Iam Policies Allow Full Administrative Privileges Attached

API のカテゴリ名: IAM_POLICIES_ALLOW_FULL_ADMINISTRATIVE_PRIVILEGES_ATTACHED

IAM ポリシーは、権限をユーザー、グループ、ロールに付与する方法です。一般的なセキュリティに関するアドバイスとして「最小権限」を付与する（つまり、タスクの実行に必要な権限のみを付与する）ことが推奨されます。ユーザーが行う必要がある操作を決定し、完全な管理者権限を許可するのではなく、ユーザーがそのタスクのみを実行できるようにするポリシーを作成します。

推奨事項: 完全な管理者権限（*:*）を許可する IAM ポリシーがアタッチされていないことを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

完全な管理者権限を持つポリシーを接続解除するには、次のコマンドを実行します。

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. ナビゲーション パネルで [ポリシー] をクリックし、監査ステップで見つかったポリシー名を検索します。
3. 削除するポリシーを選択します。
4. ポリシーのアクションメニューで、最初の [Detach] を選択します。
5. このポリシーが適用されているすべてのユーザー、グループ、ロールを選択します。
6. [Detach Policy] をクリックします。
7. ポリシーのアクションメニューで、[Detach] を選択する

AWS CLI

監査手順で完全な管理者権限があるポリシーを接続解除するには、次のコマンドを実行します。

1. 指定したマネージド ポリシーがアタッチされているすべての IAM ユーザー、グループ、ロールを一覧表示します。

 aws iam list-entities-for-policy --policy-arn <policy_arn>

2. すべての IAM ユーザーからポリシーを接続解除します。

 aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>

3. すべての IAM グループからポリシーを接続解除します。

 aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>

4. すべての IAM ロールからポリシーを接続解除します。

 aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Iam Users Receive Permissions Groups

API のカテゴリ名: IAM_USERS_RECEIVE_PERMISSIONS_GROUPS

IAM ユーザーに、IAM ポリシーによってサービス、関数、データへのアクセス権が付与されます。ユーザーのポリシーを定義するには、次の 4 つの方法があります。1）ユーザー ポリシーを直接編集する。別名インライン ポリシー、またはユーザー、ポリシー。2）ポリシーをユーザーに直接アタッチする。3）ポリシーがアタッチされている IAM グループにユーザーを追加する。4）インライン ポリシーを持つ IAM グループにユーザーを追加する。

3 つ目の実装のみをおすすめします。

推奨事項: IAM ユーザーがグループを介してのみ権限を取得していることを確認してください

次の手順を実行して IAM グループを作成し、ポリシーを割り当てます。

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. ナビゲーション パネルで [Groups] をクリックしてから、[Create New Group] をクリックします。
3. Group Name ボックスにグループの名前を入力してから、[Next Step] をクリックします。
4. ポリシーのリストで、グループのすべてのメンバーに適用するポリシーのチェックボックスをオンにします。次に [Next Step] をクリックします。
5. [Create Group] をクリックします。

特定のグループにユーザーを追加するには、次の手順を行います。

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. ナビゲーション パネルで [Groups] をクリックする
3. ユーザーを追加するグループを選択する
4. [Add Users To Group] をクリックします。
5. グループに追加するユーザーを選択する
6. [Add Users] をクリックします。

ユーザーとポリシー間の直接的な関連付けを削除するには、次の手順に従います。

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. 左側のナビゲーション パネルで [ユーザー] をクリックする
3. 各ユーザーに対して:
   - ユーザーを選択する
   - [Permissions] タブをクリックする
   - [Permissions policies] を展開する
   - 各ポリシーの [X] をクリックしてから、[接続解除] または [削除] をクリックする（ポリシーの種類によって異なります）

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Iam User Group Membership Check

API のカテゴリ名: IAM_USER_GROUP_MEMBERSHIP_CHECK

IAM のセキュリティのベスト プラクティスに準拠するには、IAM ユーザーは常に IAM グループの一部である必要があります。

グループにユーザーを追加することで、ユーザータイプ間でポリシーを共有できます。

推奨事項: IAM ユーザーが少なくとも 1 つの IAM グループのメンバーであるかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

resource "aws_iam_user" "example" {
  name = "test-iam-user"
  path = "/users/dev/"
}

resource "aws_iam_group" "example" {
  name = "Developers"
  path = "/users/dev/"
}

resource "aws_iam_user_group_membership" "example" {
  user   = aws_iam_user.example.name
  groups = [aws_iam_group.example.name]
}

AWS コンソール

AWS 管理コンソールを使用して IAM ユーザーを削除すると、IAM は次の情報を自動的に削除します。

1. ユーザー
2. すべてのユーザー グループ メンバーシップ。つまり、ユーザーがメンバーであった IAM ユーザー グループからそのユーザーが削除される
3. ユーザーに関連付けられているパスワード
4. ユーザーに属するすべてのアクセスキー
5. ユーザーに埋め込まれたすべてのインライン ポリシー（ユーザー グループの権限を介してユーザーに適用されるポリシーには影響しません）

IAM ユーザーを削除するには:

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. ナビゲーション パネルで [ユーザー] を選択し、削除するユーザー名の横にあるチェックボックスをオンにします。
3. ページ上部の [削除] を選択します。
4. 確認ダイアログ ボックスで、テキスト入力フィールドにユーザー名を入力して、ユーザーの削除を確定します。
5. [削除] を選択します。

IAM ユーザー グループにユーザーを追加するには:

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. ナビゲーション パネルで [ユーザー グループ] を選択し、グループの名前を選択します。
3. [ユーザー] タブを選択し、[ユーザーを追加] を選択します。追加するユーザーの横にあるチェックボックスをオンにします。
4. [ユーザーを追加] を選択します。

AWS CLI

Amazon ウェブサービス管理コンソールとは異なり、ユーザーをプログラムで削除する場合は、そのユーザーにアタッチされたアイテムを手動で削除する必要があります。そうしないと削除に失敗します。

ユーザーを削除する前に、次のアイテムを削除します。

1. パスワード（DeleteLoginProfile）
2. アクセスキー（DeleteAccessKey）
3. 署名証明書（DeleteSigningCertificate）
4. SSH 公開鍵（DeleteSSHPublicKey）
5. Git 認証情報（DeleteServiceSpecificCredential）
6. 多要素認証（MFA）デバイス（DeactiveMFADevice、DeleteVirtualMFADevice）
7. インライン ポリシー（DeleteUserPolicy）
8. アタッチされたマネージド ポリシー（DetachUserPolicy）
9. グループ メンバー（RemoveUserFromGroup）

ユーザーを削除するには、ユーザーにアタッチされたアイテムをすべて削除した後、次の操作を行います。

aws iam delete-user \
  --user-name "test-user"

IAM ユーザーを IAM グループに追加するには:

aws iam add-user-to-group \
  --group-name "test-group"
  --user-name "test-user"

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Iam User Mfa Enabled

API のカテゴリ名: IAM_USER_MFA_ENABLED

多要素認証（MFA）は、ユーザー名とパスワードの上に保護レイヤを追加できるベスト プラクティスです。MFA では、ユーザーが AWS 管理コンソールにログインする際に、登録済みの仮想デバイスまたは実機で提供される、時間的制約のある認証コードの入力を求められます。

推奨事項: AWS IAM ユーザーが多要素認証（MFA）を有効にしていることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

Terraform に関しては、MFA デバイスがない場合でも、いくつかの対処方法があります。おそらく、ユーザーをグループに分類する有効な構造と制限付きのポリシーがすでにあるかもしれません。

次の例では、次の方法を示します。

1. ユーザーを作成します。
2. PGP 公開鍵を使用してユーザーのログイン プロファイルを作成します。
3. IAM プロファイルの自己管理を許可するグループとグループ ポリシーを作成します。
4. ユーザーをグループにアタッチします。
5. ユーザー用の仮想 MFA デバイスを作成します。
6. 各ユーザーに出力 QR コードとパスワードを提供します。

variable "users" {
  type = set(string)
  default = [
    "[e-mail]",
    "[e-mail]"
  ]
}

resource "aws_iam_user" "test_users" {
  for_each = toset(var.users)
  name     = each.key
}

resource "aws_iam_user_login_profile" "test_users_profile" {
  for_each                = var.users
  user                    = each.key
  # Key pair created using GnuPG, this is the public key
  pgp_key = file("path/to/gpg_pub_key_base64.pem")
  password_reset_required = true
  lifecycle {
    ignore_changes = [
      password_length,
      password_reset_required,
      pgp_key,
    ]
  }
}

resource "aws_iam_virtual_mfa_device" "test_mfa" {
  for_each                = toset(var.users)
  virtual_mfa_device_name = each.key
}

resource "aws_iam_group" "enforce_mfa_group" {
  name = "EnforceMFAGroup"
}

resource "aws_iam_group_membership" "enforce_mfa_group_membership" {
  name  = "EnforceMFAGroupMembership"
  group = aws_iam_group.enforce_mfa_group.name
  users = [for k in aws_iam_user.test_users : k.name]
}

resource "aws_iam_group_policy" "enforce_mfa_policy" {
  name   = "EnforceMFAGroupPolicy"
  group  = aws_iam_group.enforce_mfa_group.id
  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
        "Sid": "AllowViewAccountInfo",
        "Effect": "Allow",
        "Action": [
            "iam:GetAccountPasswordPolicy",
            "iam:ListVirtualMFADevices"
        ],
        "Resource": "*"
    },
    {
        "Sid": "AllowManageOwnPasswords",
        "Effect": "Allow",
        "Action": [
            "iam:ChangePassword",
            "iam:GetUser"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnAccessKeys",
        "Effect": "Allow",
        "Action": [
            "iam:CreateAccessKey",
            "iam:DeleteAccessKey",
            "iam:ListAccessKeys",
            "iam:UpdateAccessKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSigningCertificates",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSigningCertificate",
            "iam:ListSigningCertificates",
            "iam:UpdateSigningCertificate",
            "iam:UploadSigningCertificate"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSSHPublicKeys",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSSHPublicKey",
            "iam:GetSSHPublicKey",
            "iam:ListSSHPublicKeys",
            "iam:UpdateSSHPublicKey",
            "iam:UploadSSHPublicKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnGitCredentials",
        "Effect": "Allow",
        "Action": [
            "iam:CreateServiceSpecificCredential",
            "iam:DeleteServiceSpecificCredential",
            "iam:ListServiceSpecificCredentials",
            "iam:ResetServiceSpecificCredential",
            "iam:UpdateServiceSpecificCredential"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnVirtualMFADevice",
        "Effect": "Allow",
        "Action": [
            "iam:CreateVirtualMFADevice",
            "iam:DeleteVirtualMFADevice"
        ],
        "Resource": "arn:aws:iam::*:mfa/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnUserMFA",
        "Effect": "Allow",
        "Action": [
            "iam:DeactivateMFADevice",
            "iam:EnableMFADevice",
            "iam:ListMFADevices",
            "iam:ResyncMFADevice"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "DenyAllExceptListedIfNoMFA",
        "Effect": "Deny",
        "NotAction": [
            "iam:CreateVirtualMFADevice",
            "iam:EnableMFADevice",
            "iam:GetUser",
            "iam:ListMFADevices",
            "iam:ListVirtualMFADevices",
            "iam:ResyncMFADevice",
            "sts:GetSessionToken"
        ],
        "Resource": "*",
        "Condition": {
            "BoolIfExists": {
                "aws:MultiFactorAuthPresent": "false"
            }
        }
    }
  ]
}
POLICY
}

output "user_password_map" {
  # Outputs a map in the format {"[e-mail]": <PGPEncryptedPassword>, "[e-mail]": <PGPEncryptedPassword>}
  value = { for k, v in aws_iam_user_login_profile.test_users_profile : k => v.password }
}

output "user_qr_map" {
  # Outputs a map in the format {"[e-mail]": <QRCode>, "[e-mail]": <QRCode>}
  value = { for k, v in aws_iam_virtual_mfa_device.test_mfa : k => v.qr_code_png }
}

AWS コンソール

AWS コンソールにアクセスできるすべてのユーザー アカウントの MFA を有効にするには、AWS ドキュメントの仮想多要素認証（MFA）デバイスの有効化（コンソール）をご覧ください。

AWS CLI

MFA デバイスを作成する

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name "[e-mail]" \
  --outfile ./QRCode.png \
  --bootstrap-method QRCodePNG

既存のユーザーの MFA デバイスを有効にする

aws iam enable-mfa-device \
  --user-name "[e-mail]" \
  --serial-number "arn:aws:iam::123456976749:mfa/[e-mail]" \
  --authentication-code1 123456 \
  --authentication-code2 654321

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Iam User Unused Credentials Check

API のカテゴリ名: IAM_USER_UNUSED_CREDENTIALS_CHECK

これにより、過去 90 日間に使用されていない IAM パスワードまたはアクティブなアクセスキーを確認します。

90 日以上使用されていないすべての認証情報を削除、無効化、またはローテーションすることをおすすめします。これにより、不正使用されたアカウントや放棄されたアカウントに関連付けられた認証情報が使用される機会が減少します。

推奨事項: すべての AWS IAM ユーザーが、maxCredentialUsageAge 日間使用されていないパスワードまたはアクティブなアクセスキーを持っていることを確認してください（デフォルトは 90 日）

この検出結果を修正するには、次の操作を完了します。

Terraform

Terraform を使用して作成された期限切れのアクセスキーを削除するには、モジュールから aws_iam_access_key リソースを削除して変更を適用します。

IAM ユーザーのログイン パスワードをリセットするには、terraform apply を実行するときに -replace を使用します。

次のユーザー ログイン プロファイルを作成する

resource "aws_iam_user" "example" {
  name          = "[e-mail]"
  path          = "/users/"
  force_destroy = true
}

resource "aws_iam_user_login_profile" "example" {
  user    = aws_iam_user.example.name
  pgp_key = "keybase:some_person_that_exists"
}

次のコマンドを実行して、ユーザーのログイン プロファイルのパスワードを再設定する

terraform apply -replace="aws_iam_user_login_profile.example"

AWS コンソール

アクティブでないアカウントの認証情報を無効にするには:

1. https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. ユーザーを選択します。
3. 認証情報が過去 90 日以上経過している（または最後に使用された）ユーザーの名前を選択します。
4. [セキュリティ認証情報] を選択します。
5. 90 日以上使用されていないログイン認証情報とアクセスキーごとに、[無効にする] を選択します。

次回のログイン時にコンソール ユーザーに新しいパスワードを要求するには:

1. https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. ユーザーを選択します。
3. 認証情報が過去 90 日以上経過している（または最後に使用された）ユーザーの名前を選択します。
4. [セキュリティ認証情報] を選択します。
5. [ログイン認証情報とコンソール パスワード] で [管理] を選択します。
6. 新しいパスワードを設定します（自動生成またはカスタム）。
7. [パスワードのリセットを必須にする] チェックボックスをオンにします。
8. [適用] を選択します。

AWS CLI

アクセスキーを非アクティブにするには

aws iam update-access-key \
  --access-key-id <value> \
  --status "Inactive"

アクセスキーを削除するには

aws iam delete-access-key \
  --access-key-id <value>

ユーザー ログイン プロファイルのパスワードを再設定するには

aws iam update-login-profile \
  --user-name "[e-mail]" \
  --password <temporary_password> \
  --password-reset-required

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Kms Cmk Not Scheduled For Deletion

API のカテゴリ名: KMS_CMK_NOT_SCHEDULED_FOR_DELETION

このコントロールでは、KMS 鍵が削除されるようにスケジュールされているかどうかを確認します。KMS 鍵の削除がスケジュールされている場合、このコントロールは失敗します。

一度削除した KMS 鍵は復元できません。KMS 鍵で暗号化されたデータも、KMS 鍵が削除されると完全に回復不能となります。削除がスケジュールされている KMS 鍵で意味のあるデータが暗号化されている場合は、暗号消去を意図的に実行していない限り、データを復号するか、新しい KMS 鍵でデータを再暗号化することを検討してください。

KMS 鍵の削除がスケジュールされているときには、必須の待機期間が適用され、誤って削除されるようにスケジュールされていた場合に削除を元に戻すことができます。デフォルトの待機期間は 30 日間ですが、KMS 鍵の削除がスケジュールされている場合は、7 日間まで短縮できます。待機期間中は、スケジュール設定された削除をキャンセルでき、KMS 鍵は削除されません。

KMS 鍵の削除の詳細については、AWS 鍵管理サービス デベロッパー ガイドの KMS 鍵の削除をご覧ください。

推奨事項: すべての CMK で削除がスケジュールされていないことを確認してください

スケジュール設定された KMS 鍵の削除をキャンセルするには、AWS 鍵管理サービス デベロッパー ガイドの鍵の削除のスケジューリングとキャンセルで鍵の削除をキャンセルするには（コンソール）をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Lambda Concurrency Check

API のカテゴリ名: LAMBDA_CONCURRENCY_CHECK

Lambda 関数が、関数レベルの同時実行制限で構成されているかどうかを確認します。Lambda 関数が関数レベルの同時実行制限で構成されていない場合、ルールは NON_COMPLIANT になります。

推奨事項: Lambda 関数に関数レベルの同時実行制限が構成されているかどうかを確認してください

関数レベルの同時実行の制限を構成するには、AWS Lambda ドキュメントの予約済みの同時実行を構成するをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Lambda Dlq Check

API のカテゴリ名: LAMBDA_DLQ_CHECK

Lambda 関数にデッドレター キューで構成されているかどうかを確認します。Lambda 関数がデッドレター キューで構成されていない場合、ルールは NON_COMPLIANT です。

推奨事項: Lambda 関数にデッドレター キューが構成されていることを確認してください

DLQ を使用するように Lambda 関数を更新するには、AWS ドキュメントのデッドレター キューをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Lambda Function Public Access Prohibited

API のカテゴリ名: LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED

AWS のベスト プラクティスでは、Lambda 関数を公開しないことをおすすめします。このポリシーは、アカウント内のすべての有効なリージョンでデプロイされたすべての Lambda 関数を確認し、公開アクセスを許可するように構成されている場合は失敗します。

推奨事項: Lambda 関数にアタッチされたポリシーが公開アクセスを禁止しているかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

次の例では、Terraform を使用して、Lambda 関数へのアクセスを制限する IAM ロールをプロビジョニングし、そのロールを Lambda 関数にアタッチする例を示します。

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

resource "aws_lambda_function" "test_lambda" {
  filename      = "lambda_function_payload.zip"
  function_name = "lambda_function_name"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "index.test"

  source_code_hash = filebase64sha256("lambda_function_payload.zip")

  runtime = "nodejs12.x"

}

AWS コンソール

Lambda 関数がこのコントロールに失敗した場合、Lambda 関数のリソースベースのポリシー ステートメントは公開アクセスを許可していることを示します。

問題を修正するには、ポリシーを更新して権限を削除するか、AWS:SourceAccount 条件を追加する必要があります。リソースベースのポリシーは Lambda API からのみ更新できます。

次の手順では、コンソールを使用してポリシーを確認し、AWS コマンドライン インターフェースを使用して権限を削除します。

Lambda 関数のリソースベースのポリシーを表示するには

1. https://console.aws.amazon.com/lambda/ で AWS Lambda コンソールを開きます。
2. ナビゲーション パネルで [関数] を選択します。
3. 関数を選択します。
4. [権限] を選択します。リソースベースのポリシーには、別のアカウントまたは AWS サービスが関数にアクセスしようとしたときに適用される権限が表示されます。
5. リソースベースのポリシーを調べます。
6. ポリシーを公開するプリンシパル フィールド値を持つポリシー ステートメントを特定します。たとえば、"*" や { "AWS": "*" } の許可などです。

コンソールでポリシーを編集することはできません。関数から権限を削除するには、AWS CLI から remove-permission コマンドを使用します。

削除するステートメントのステートメント ID（Sid）の値をメモします。

AWS CLI

CLI を使用して Lambda 関数から権限を削除するには、次のように remove-permission コマンドを発行します。

aws lambda remove-permission \
--function-name <value> \
--statement-id <value>

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Lambda Inside Vpc

API のカテゴリ名: LAMBDA_INSIDE_VPC

Lambda 関数が VPC 内にあるかどうかを確認します。Lambda@Edge リソースで失敗した検出結果が表示されることがあります。

VPC サブネット ルーティング構成の評価は、公開ネットワーク到達性を判断しません。

推奨事項: Lambda 関数が VPC 内に存在することを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

アカウントの Virtual Private Cloud（VPC）のプライベート サブネットに接続する関数を構成するには:

1. https://console.aws.amazon.com/lambda/ で AWS Lambda コンソールを開きます。
2. [関数] に移動し、Lambda 関数を選択します。
3. [ネットワーク] までスクロールし、関数の接続要件を含む VPC を選択します。
4. 高可用性モードで関数を実行するには、Security Hub で少なくとも 2 つのサブネットを選択することをおすすめします。
5. 機能の接続要件を持つセキュリティ グループを少なくとも 1 つ選択します。
6. [保存] を選択します。

詳しくは、AWS Lambda デベロッパー ガイドの「VPC 内のリソースにアクセスするように Lambda 関数を設定する」のセクションをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Mfa Delete Enabled S3 Buckets

API のカテゴリ名: MFA_DELETE_ENABLED_S3_BUCKETS

プライベートで機密性の高い S3 バケットで MFA 削除を有効にすると、ユーザーは 2 つの形式の認証が必要になります。

推奨事項: S3 バケットで MFA の削除が有効になっていることを確認してください

S3 バケットで MFA の削除を有効にするには、次の手順を行います。

注:
- AWS 管理コンソールを使用して MFA の削除を有効にすることはできません。AWS CLI または API を使用する必要があります。
- S3 バケットで MFA の削除を有効にするには、「root」アカウントを使用する必要があります。

コマンドラインから:

1. s3api put-bucket-versioning コマンドを実行する

aws s3api put-bucket-versioning --profile my-root-profile --bucket Bucket_Name --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa “arn:aws:iam::aws_account_id:mfa/root-account-mfa-device passcode”

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Mfa Enabled Root User Account

API のカテゴリ名: MFA_ENABLED_ROOT_USER_ACCOUNT

「root」ユーザー アカウントは、AWS アカウント内で最も権限のあるユーザーです。多要素認証（MFA）によって、ユーザー名とパスワードの上に保護レイヤが追加されます。MFA を有効にすると、ユーザーが AWS ウェブサイトにログインするときに、ユーザー名とパスワードおよび AWS MFA デバイスの認証コードの入力を求められます。

注:「root」アカウントに仮想 MFA を使用する場合は、個人用デバイスではなく、個人用のデバイスとは別に充電され、保護されるように管理された専用のモバイル デバイス（タブレットまたはスマートフォン）を使用することをおすすめします。（「非個人用の仮想 MFA」）これにより、デバイスの紛失、デバイスの下取り、またはデバイスを所有している個人が会社を退職した場合に MFA にアクセスできなくなるリスクを軽減できます。

推奨事項:「root」ユーザー アカウントで MFA が有効になっていることを確認してください

「root」ユーザー アカウントの MFA を確立するには、次の手順を行います。

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。

注: AWS アカウントの MFA デバイスを管理するには、「root」アカウントの認証情報を使用して AWS にログインする必要があります。他の認証情報を使用して「root」アカウントの MFA デバイスを管理することはできません。

2. Dashboard を選択し、root アカウントの Security Status で Activate MFA を展開します。
3. Activate MFA を選択
4. ウィザードで、[A virtual MFA] デバイスを選択してから、[Next Step] を選択します。
5. IAM が、仮想 MFA デバイスの構成情報（QR コードの画像など）を生成して表示します。この画像は、QR コードをサポートしていないデバイスで手動で入力できる「シークレット構成キー」を表現しています。
6. 仮想 MFA アプリケーションを開きます。（仮想 MFA デバイスのホスティングに使用できるアプリのリストについては、仮想 MFA アプリケーションをご覧ください）。仮想 MFA アプリケーションが複数のアカウント（複数の仮想 MFA デバイス）をサポートしている場合は、新しいアカウントを作成するオプションを選択します（新しい仮想 MFA デバイス）。
7. MFA アプリが QR コードをサポートしているかどうかを確認し、次のいずれかを行います。

• アプリを使用して QR コードをスキャンします。たとえば、カメラアイコンを選択するか、[コードをスキャン] と同様のオプションを選択し、デバイスのカメラを使用してコードをスキャンできます。
• [MFA デバイスの管理] ウィザードで、[手動構成用の秘密鍵を表示] を選択してから、MFA アプリケーションにシークレット構成キーを入力します。

完了すると、仮想 MFA デバイスがワンタイム パスワードの生成を開始します。

[MFA デバイスの管理] ウィザードの [認証コード 1] ボックスに、仮想 MFA デバイスに現在表示されているワンタイム パスワードを入力します。デバイスが新しいワンタイム パスワードを生成するまで 30 秒ほど待ちます。次に、2 つ目のワンタイム パスワードを [認証コード 2] ボックスに入力します。[仮想 MFA の割り当て] を選択します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Multi Factor Authentication Mfa Enabled All Iam Users Console

API のカテゴリ名: MULTI_FACTOR_AUTHENTICATION_MFA_ENABLED_ALL_IAM_USERS_CONSOLE

多要素認証（MFA）は、従来の認証情報だけでなく、認証の保証レイヤを追加します。MFA を有効にすると、ユーザーが AWS コンソールにログインするときに、ユーザー名とパスワード、および物理または仮想の MFA トークンの認証コードの入力を求められます。コンソール パスワードを持つすべてのアカウントで MFA を有効にすることをおすすめします。

推奨事項: コンソール パスワードを持つすべての IAM ユーザーに対して、多要素認証（MFA）が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインし、「https://console.aws.amazon.com/iam/」で IAM コンソールを開きます。
2. 左側のペインで [Users] を選択します。
3. [User Name] リストで、目的の MFA ユーザーの名前を選択します。
4. [Security Credentials] タブを選択してから、[Manage MFA Device] を選択します。
5. Manage MFA Device wizard で、[Virtual MFA] デバイスを選択してから、[Continue] を選択します。

IAM が、仮想 MFA デバイスの構成情報（QR コードの画像など）を生成して表示します。この画像は、QR コードをサポートしていないデバイスで手動で入力できる「シークレット構成キー」を表現しています。

6. 仮想 MFA アプリケーションを開きます。（仮想 MFA デバイスのホスティングに使用できるアプリのリストについては、https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications の仮想 MFA アプリケーションをご覧ください）。仮想 MFA アプリケーションが複数のアカウント（複数の仮想 MFA デバイス）をサポートしている場合は、新しいアカウントを作成するオプションを選択します（新しい仮想 MFA デバイス）。
7. MFA アプリが QR コードをサポートしているかどうかを確認し、次のいずれかを行います。

• アプリを使用して QR コードをスキャンします。たとえば、カメラアイコンを選択するか、[コードをスキャン] と同様のオプションを選択し、デバイスのカメラを使用してコードをスキャンできます。
• [MFA デバイスの管理] ウィザードで、[手動構成用の秘密鍵を表示] を選択してから、MFA アプリケーションにシークレット構成キーを入力します。

完了すると、仮想 MFA デバイスがワンタイム パスワードの生成を開始します。

8. Manage MFA Device wizard の MFA Code 1 box に、仮想 MFA デバイスに現在表示されている one-time password を入力します。デバイスが新しいワンタイム パスワードを生成するまで 30 秒ほど待ちます。次に、2 番目の one-time password を MFA Code 2 box に入力します。

9. [Assign MFA] をクリックします。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

No Network Acls Allow Ingress 0 0 0 0 Remote Server Administration

API のカテゴリ名: NO_NETWORK_ACLS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

ネットワーク アクセス制御リスト（NACL）関数は、AWS リソースへの上り（内向き）と下り（外向き）のネットワーク トラフィックのステートレス フィルタリングを提供します。TDP（6）、UDP（17）、または ALL（-1）プロトコルのいずれかを使用して、リモート サーバー管理ポートへの無制限の上り（内向き）アクセス（ポート 22 への SSH、3389 への RDP など）を NACL で許可しないことをおすすめします。

推奨事項: 0.0.0.0/0 からリモート サーバー管理ポートへの上り（内向き）を許可するネットワーク ACL がないことを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

手順は次のとおりです。
1. https://console.aws.amazon.com/vpc/home で AWS 管理コンソールにログインする
2. 左側のペインで [Network ACLs] をクリックする
3. 修正するネットワーク ACL ごとに、次の操作を行います。
- ネットワーク ACL を選択する
- [Inbound Rules] タブをクリックする
- [Edit inbound rules] をクリックする
- A）ソース フィールドを 0.0.0.0/0 以外の範囲に更新する、または B）[Delete] をクリックして問題のある受信ルールを削除する
- [Save] をクリックする

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

No Root User Account Access Key Exists

API のカテゴリ名: NO_ROOT_USER_ACCOUNT_ACCESS_KEY_EXISTS

「root」ユーザー アカウントは、AWS アカウント内で最も権限のあるユーザーです。AWS アクセスキーを使用すると、特定の AWS アカウントにプログラムからアクセスできます。「root」ユーザー アカウントに関連付けられているすべてのアクセスキーを削除することをおすすめします。

推奨事項: 「root」ユーザー アカウントのアクセスキーが存在しないことを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS マネジメント コンソールに「root」としてログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. 右上の [<root_account>] をクリックし、プルダウン リストから [My Security Credentials] を選択します。
3. ポップアウト画面で [Continue to Security Credentials] をクリックします。
4. [Access Keys]（アクセスキー ID とシークレット アクセスキー）をクリックします。
5. [Status] 列の下（アクティブなキーがある場合）。
6. [Delete] をクリックします（注: 削除したキーは復元できません）。

注: キーを非アクティブにできますが、この非アクティブなキーは監査手順の CLI コマンドに表示され、キーが誤って非準拠としてフラグ付けされる場合があります。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

No Security Groups Allow Ingress 0 0 0 0 Remote Server Administration

API のカテゴリ名: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

セキュリティ グループは、AWS リソースに上り（内向き）と下り（外向き）のネットワーク トラフィックのステートフル フィルタリングを提供します。TDP（6）、UDP（17）、または ALL（-1）プロトコルのいずれかを使用して、リモート サーバー管理ポートへの無制限の上り（内向き）アクセス（ポート 22 への SSH、3389 への RDP など）を セキュリティ グループで許可しないことをおすすめします。

推奨事項: 0.0.0.0/0 からリモート サーバー管理ポートへの上り（内向き）を許可するセキュリティ グループがないことを確認してください

所定の状態を実装するには、次の手順を行います。

1. https://console.aws.amazon.com/vpc/home で AWS 管理コンソールにログインする
2. 左側のペインで [Security Groups] をクリックする
3. セキュリティ グループごとに、次の操作を行います。
4. セキュリティ グループを選択する
5. [Inbound Rules] タブをクリックする
6. [Edit inbound rules] ボタンをクリックする
7. 編集または削除するルールを特定する
8. A）ソース フィールドを 0.0.0.0/0 以外の範囲に更新する、または B）[Delete] をクリックして、問題のある受信ルールを削除する
9. [Save rules] をクリックします。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

No Security Groups Allow Ingress 0 Remote Server Administration

API のカテゴリ名: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_REMOTE_SERVER_ADMINISTRATION

セキュリティ グループは、AWS リソースに上り（内向き）と下り（外向き）のネットワーク トラフィックのステートフル フィルタリングを提供します。リモート サーバー管理ポートへの無制限の上り（内向き）アクセス（ポート 22 への SSH、ポート 3389 への RDP など）をセキュリティ グループで許可しないことをおすすめします。

推奨事項 ::/0 からリモート サーバー管理ポートへの上り（内向き）を許可するセキュリティ グループがないことを確認してください

所定の状態を実装するには、次の手順を行います。

1. https://console.aws.amazon.com/vpc/home で AWS 管理コンソールにログインする
2. 左側のペインで [Security Groups] をクリックする
3. セキュリティ グループごとに、次の操作を行います。
4. セキュリティ グループを選択する
5. [Inbound Rules] タブをクリックする
6. [Edit inbound rules] ボタンをクリックする
7. 編集または削除するルールを特定する
8. A）ソース フィールドを ::/0 以外の範囲に更新する、または B）[Delete] をクリックして、問題のある受信ルールを削除する
9. [Save rules] をクリックします。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

One Active Access Key Available Any Single Iam User

API のカテゴリ名: ONE_ACTIVE_ACCESS_KEY_AVAILABLE_ANY_SINGLE_IAM_USER

アクセスキーは、IAM ユーザーまたは AWS アカウントの「root」ユーザーの長期的な認証情報です。アクセスキーを使用して、AWS CLI または AWS API へのプログラムによるリクエストに署名できます（直接または AWS SDK を使用）。

推奨事項: 単一の IAM ユーザーが利用できるアクティブなアクセスキーが 1 つだけであることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ の IAM ダッシュボードに移動します。
2. 左側のナビゲーション パネルで [Users] を選択します。
3. 確認する IAM ユーザー名をクリックします。
4. IAM ユーザー構成ページで、[Security Credentials] タブを選択します。
5. Access Keys セクションで、90 日以内のアクセスキーを 1 つ選択します。これは、この IAM ユーザーがプログラムで AWS リソースにアクセスするために使用する唯一のアクティブなキーである必要があります。アプリケーションをテストして、選択したアクセスキーが機能していることを確認します。
6. 同じ [Access Keys] セクションで、運用中のアクセスキー（選択したもの以外）を特定し、[Make Inactive] をクリックして無効にします。
7. [Change Key Status] 確認ボックスが表示されたら、[Deactivate] をクリックして選択したキーをオフにします。
8. AWS アカウントの IAM ユーザーごとに 3 ～ 7 の手順を繰り返します。

AWS CLI

1. Audit CLI で提供される IAM ユーザーとアクセスキーの情報を使用して、90 日以内のアクセスキーを 1 つ選択します。これは、この IAM ユーザーがプログラムで AWS リソースにアクセスするために使用する唯一のアクティブなキーである必要があります。アプリケーションをテストして、選択したアクセスキーが機能していることを確認します。

2. IAM ユーザー名と運用以外のアクセスキー ID を使用して次の update-access-key コマンドを実行し、不要なキーを無効にします。監査セクションを参照して、選択した IAM ユーザーの不要なアクセスキー ID を特定します

注 - このコマンドは出力を返しません。

aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>

3. 選択したアクセスキーペアが正常に deactivated されたことを確認するには、その IAM ユーザーに対して list-access-keys 監査コマンドを再度実行します。

aws iam list-access-keys --user-name <user-name>

• コマンド出力は、IAM ユーザーに関連付けられた各アクセスキーのメタデータを公開します。非運用鍵ペア Status が Inactive に設定されている場合、鍵は正常に無効化され、IAM ユーザー アクセス構成はこの推奨事項に準拠しています。

4. AWS アカウントの IAM ユーザーごとに 1 ～ 3 の手順を繰り返します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Public Access Given Rds Instance

API のカテゴリ名: PUBLIC_ACCESS_GIVEN_RDS_INSTANCE

セキュリティ リスクを最小限に抑えるために、AWS アカウントでプロビジョニングされている RDS データベース インスタンスで不正アクセスが制限されていることを確認してください。一般公開されている RDS データベース インスタンスへのアクセスを制限するには、データベースの Publicly Accessible フラグを無効にして、インスタンスに関連付けられた VPC セキュリティ グループを更新する必要があります。

推奨事項: RDS インスタンスにパブリック アクセスが付与されていないことを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/rds/ で RDS ダッシュボードに移動します。
2. ナビゲーション パネルの RDS ダッシュボードで [Databases] をクリックします。
3. 更新する RDS インスタンスを選択します。
4. ダッシュボードのトップメニューから [Modify] をクリックします。
5. [DB インスタンスを変更] パネルの [Connectivity] セクションで [Additional connectivity configuration] をクリックし、Publicly Accessible の値を [非公開] に更新し、公開アクセスを制限します。サブネット構成を更新する手順は次のとおりです。
   - [Connectivity and security] タブを選択し、[Networking] セクション内の VPC 属性値をクリックします。
   - VPC ダッシュボードの下部パネルで [Details] タブを選択し、[ルートテーブルの構成属性値] をクリックします。
   - [ルートテーブルの詳細] ページで、ダッシュボードの下部パネルから [ルート] タブを選択し、[Edit routes] をクリックします。
   [ルートを編集] ページで、ターゲットの宛先（igw-xxxxx に設定）を更新し、[Save ルート] をクリックします。
6. [DB インスタンスを変更] パネルで、[Continue] をクリックし、[変更のスケジュール設定] セクションで、要件に応じて次のいずれかの操作を行います。
   - 次回の定期メンテナンスの時間枠で変更を自動的に適用するには、[次回の定期メンテナンスの時間枠で適用] を選択します。
   - 変更をすぐに適用するには、[すぐに適用] を選択します。このオプションを使用すると、この RDS データベース インスタンスのメンテナンスの時間枠の設定に関係なく、保留中の変更は可能な限り早く非同期に適用されます。保留中の変更キューで利用可能な変更も適用されます。保留中の変更のいずれかでダウンタイムが必要な場合は、このオプションを選択すると、アプリケーションで予期しないダウンタイムが発生する可能性があります。
7. 現在のリージョンで使用可能な RDS インスタンスごとに手順 3 ～ 6 を繰り返します。
8. ナビゲーション バーの AWS リージョンを変更して、他のリージョンに対しても手順を繰り返します。

AWS CLI

1. describe-db-instances コマンドを実行して、選択した AWS リージョンで使用可能なすべての RDS データベース名 ID を一覧表示します。

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

2. コマンド出力で、各データベース インスタンス ID が返されます。
3. modify-db-instance コマンドを実行して、選択した RDS インスタンス構成を変更します。次のコマンドを使用して、選択した RDS インスタンスの Publicly Accessible フラグを無効にします。このコマンドでは、apply-immediately フラグを使用します。to avoid any downtime --no-apply-immediately flag can be used が必要な場合:

aws rds modify-db-instance --region <region-name> --db-instance-identifier <db-name> --no-publicly-accessible --apply-immediately

4. コマンド出力には、保留中の値の下に PubliclyAccessible 構成が表示され、指定された時間に適用されます。
5. AWS CLI を介したインターネット ゲートウェイの宛先の更新は現在サポートされていません。インターネット ゲートウェイに関する情報を更新するには、AWS Console Procedure を使用してください。
6. 現在のリージョンにプロビジョニングされている RDS インスタンスごとに、手順 1 ～ 5 を繰り返します。
7. --region フィルタを使用して AWS リージョンを変更し、他のリージョンに対してこの手順を繰り返します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Rds Enhanced Monitoring Enabled

API のカテゴリ名: RDS_ENHANCED_MONITORING_ENABLED

拡張モニタリングは、インスタンスにインストールされているエージェントを介して、RDS インスタンスが実行されているオペレーティング システムに関するリアルタイム指標を提供します。

詳細については、拡張モニタリングを使用した OS 指標のモニタリングをご覧ください。

推奨事項: すべての RDS DB インスタンスに対して拡張モニタリングが有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

このコントロールを修正するには、次のように RDS インスタンスで拡張モニタリングを有効にします。

RDS 用の IAM ロールを作成します。

resource "aws_iam_role" "rds_logging" {
  name = "CustomRoleForRDSMonitoring"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = "CustomRoleForRDSLogging"
        Principal = {
          Service = "monitoring.rds.amazonaws.com"
        }
      },
    ]
  })
}

RDS 拡張モニタリングの AWS マネージド ポリシーを取得します。

data "aws_iam_policy" "rds_logging" {
  name = "AmazonRDSEnhancedMonitoringRole"
}

ポリシーをロールにアタッチします。

resource "aws_iam_policy_attachment" "rds_logging" {
  name       = "AttachRdsLogging"
  roles      = [aws_iam_role.rds_logging.name]
  policy_arn = data.aws_iam_policy.rds_logging.arn
}

違反のある RDS インスタンスに対するモニタリング間隔とモニタリングのロールを定義して、拡張モニタリングを有効にします。

resource "aws_db_instance" "default" {
  identifier           = "test-rds"
  allocated_storage    = 10
  engine               = "mysql"
  engine_version       = "5.7"
  instance_class       = "db.t3.micro"
  db_name              = "mydb"
  username             = "foo"
  password             = "foobarbaz"
  parameter_group_name = "default.mysql5.7"
  skip_final_snapshot  = true
  monitoring_interval  = 60
  monitoring_role_arn  = aws_iam_role.rds_logging.arn
}

AWS コンソール

拡張モニタリングは、DB インスタンス、マルチ AZ DB クラスタ、リードレプリカを作成するとき、または DB インスタンスまたはマルチ AZ DB クラスタを変更するときに有効にできます。DB インスタンスを変更して拡張モニタリングを有効にする場合は、変更を有効にするために DB インスタンスを再起動する必要はありません。

[データベース] ページで次のいずれかの操作を行うと、RDS コンソールで拡張モニタリングを有効にできます。

• DB インスタンスまたはマルチ AZ DB クラスタを作成する - [データベースを作成] を選択します。
• リードレプリカを作成する - [アクション] を選択してから[リードレプリカを作成] を選択します。
• DB インスタンスまたはマルチ AZ DB クラスタを変更する - [変更] を選択します。

RDS コンソールで拡張モニタリングをオンまたはオフにするには

1. [追加構成] までスクロールします。
2. [モニタリング] で、[DB インスタンスまたはリードレプリカの拡張モニタリングを有効にする] を選択します。拡張モニタリングをオフにするには、[拡張モニタリングを無効にする] を選択します。
3. Amazon RDS が Amazon CloudWatch Logs と通信できるように作成した IAM ロールにモニタリング ロールを設定するか、[デフォルト] を選択して、RDS で rds-monitoring-role という名前のロールを作成できるようにします。
4. 粒度プロパティを、DB インスタンスまたはリードレプリカで指標を収集するポイントの間隔（秒単位）に設定します。粒度プロパティは、1、5、10、15、30、60 のいずれかの値に設定できます。RDS コンソールの更新が最も速くなるのは 5 秒ごとです。RDS コンソールで粒度を 1 秒に設定しても、5 秒ごとにのみ更新された指標が表示されます。CloudWatch Logs を使用して、1 秒の指標の更新を取得できます。

AWS CLI

RDS IAM ロールを作成します。

aws iam create-role \
  --role-name "CustomRoleForRDSMonitoring" \
  --assume-role-policy-document file://rds-assume-role.json

ポリシー AmazonRDSEnhancedMonitoringRole をロールにアタッチします。

aws iam attach-role-policy \
  --role-name "CustomRoleForRDSMonitoring"\
  --policy-arn "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole"

--monitoring-interval と --monitoring-role-arn を設定して、RDS インスタンスを変更して拡張モニタリングを有効にします。

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --monitoring-interval 30 \
  --monitoring-role-arn "arn:aws:iam::<account_id>:role/CustomRoleForRDSMonitoring"

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Rds Instance Deletion Protection Enabled

API のカテゴリ名: RDS_INSTANCE_DELETION_PROTECTION_ENABLED

インスタンスの削除保護を有効にすると、データベースの偶発的な削除や権限のないエンティティによる削除に対して保護レイヤを追加できます。

削除保護が有効になっている場合は、RDS DB インスタンスを削除できません。削除リクエストが成功するには、削除保護を無効にする必要があります。

推奨事項: すべての RDS インスタンスで削除保護が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

このコントロールを修正するには、aws_db_instance リソースの deletion_protection を true に設定します。

resource "aws_db_instance" "example" {
  # ... other configuration ...
  deletion_protection = true
}

AWS コンソール

RDS DB インスタンスの削除保護を有効にするには

1. https://console.aws.amazon.com/rds/ で Amazon RDS コンソールを開きます。
2. ナビゲーション パネルで、[データベース] を選択してから、変更する DB インスタンスを選択します。
3. [変更] を選択します。
4. [削除からの保護] で [削除からの保護を有効にする] を選択します。
5. [続行] を選択します。
6. [変更のスケジュール設定] で、変更を適用するタイミングを選択します。オプションは、[次回の定期メンテナンスの時間枠内で適用] または [すぐに適用] です。
7. [DB インスタンスを変更] を選択します。

AWS CLI

AWS CLI についても同様です。次のように --deletion-protection を設定します。

aws rds modify-db-instance \
  --db-instance-identifier = "test-rds" \
  --deletion-protection

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Rds In Backup Plan

API のカテゴリ名: RDS_IN_BACKUP_PLAN

このチェックにより、Amazon RDS DB インスタンスがバックアップ プランの対象かどうかを評価します。RDS DB インスタンスがバックアップ プランでカバーされていない場合、このコントロールは失敗します。

AWS Backup は、AWS サービス間でデータのバックアップを一元化して自動化するフルマネージド バックアップ サービスです。AWS Backup では、バックアップ プランと呼ばれるバックアップ ポリシーを作成できます。これらのプランを使用して、データをバックアップする頻度やバックアップを保持する期間などのバックアップ要件を定義できます。バックアップ プランに RDS DB インスタンスを含めると、意図しない損失や削除からデータを保護できます。

推奨事項: RDS DB インスタンスをバックアップ プランの対象にする必要があります

この検出結果を修正するには、次の操作を完了します。

Terraform

このコントロールを修正するには、aws_db_instance リソースの backup_retention_period を 7 より大きい値に設定します。

resource "aws_db_instance" "example" {
  # ... other Configuration ...
  backup_retention_period = 7
}

AWS コンソール

自動バックアップをすぐに有効にするには

1. https://console.aws.amazon.com/rds/ で Amazon RDS コンソールを開きます。
2. ナビゲーション パネルで、[データベース] を選択し、変更する DB インスタンスを選択します。
3. [変更] を選択して [DB インスタンスの変更] ページを開きます。
4. [バックアップの保持期間] で、ゼロ以外の正の値（30 日など）を選択し、[続行] を選択します。
5. [変更のスケジュール設定] セクションを選択し、変更を適用するタイミングを選択します。[次回の定期メンテナンスの時間枠内で適用]、または [すぐに適用] を選択できます。
6. 次に、確認ページで [DB インスタンスを変更] を選択して変更を保存し、自動バックアップを有効にします。

AWS CLI

AWS CLI についても同様です。自動バックアップを有効にするには、backup-retention-period を 0 より大きい値（デフォルト）に変更します。

aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Rds Logging Enabled

API のカテゴリ名: RDS_LOGGING_ENABLED

これにより、次の Amazon RDS のログが有効で、CloudWatch に送信されるかどうかを確認します。

RDS データベースで関連するログが有効になっている必要があります。データベース ロギングでは、RDS に対して行われたリクエストの詳細レコードが提供されます。データベース ログは、セキュリティとアクセスの監査、可用性の問題の診断に役立ちます。

推奨事項: エクスポートされたログがすべての RDS DB インスタンスに対して有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

resource "aws_db_instance" "example" {
  # ... other configuration for MySQL ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
}

resource "aws_db_parameter_group" "example" {
  name   = "${aws_db_instance.example.dbInstanceIdentifier}-parameter-group"
  family = "mysql5.7"

  parameter {
    name  = "general_log"
    value = 1
  }

  parameter {
    name  = "slow_query_log"
    value = 1
  }

  parameter {
    name  = "log_output"
    value = "FILE"
  }
}

MariaDB の場合は、さらにカスタム オプション グループを作成し、aws_db_instance リソースに option_group_name を設定します。

resource "aws_db_instance" "example" {
  # ... other configuration for MariaDB ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
  option_group_name               = aws_db_option_group.example.name
}

resource "aws_db_option_group" "example" {
  name                     = "mariadb-option-group-for-logs"
  option_group_description = "MariaDB Option Group for Logs"
  engine_name              = "mariadb"
  option {
    option_name = "MARIADB_AUDIT_PLUGIN"
    option_settings {
      name  = "SERVER_AUDIT_EVENTS"
      value = "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  }
}

AWS コンソール

カスタム DB パラメータ グループを作成するには

1. https://console.aws.amazon.com/rds/ で Amazon RDS コンソールを開きます。
2. ナビゲーション パネルで [パラメータ グループ] を選択します。
3. [パラメータ グループを作成] を選択します。
4. [パラメータ グループ ファミリー] リストで、DB パラメータ グループ ファミリーを選択します。
5. [タイプ] リストで、DB パラメータ グループを選択します。
6. [グループ名] に、新しい DB パラメータ グループの名前を入力します。
7. [説明] に、新しい DB パラメータ グループの説明を入力します。
8. [作成] を選択します。

コンソールを使用して MariaDB ロギング用の新しいオプション グループを作成するには

1. https://console.aws.amazon.com/rds/ で Amazon RDS コンソールを開きます。
2. ナビゲーション パネルで [オプション グループ] を選択します。
3. [グループを作成] を選択します。
4. [オプション グループを作成] ウィンドウで、次の情報を入力します。
   * 名前: AWS アカウント内で一意にする必要があります。英字、数字、ハイフンのみ使用できます。
   * 説明: 表示目的にのみ使用されます。
   * エンジン: DB エンジンを選択します。
   * メジャー エンジン バージョン: DB エンジンのメジャー バージョンを選択します。
5. [作成] を選択します。
6. 作成したオプション グループの名前を選択します。
7. [オプションを追加] を選択します。
8. オプション名のリストから MARIADB_AUDIT_PLUGIN を選択します。
9. SERVER_AUDIT_EVENTS を CONNECT、QUERY、TABLE、QUERY_DDL、QUERY_DML、QUERY_DCL に設定します。
10. [オプションを追加] を選択します。

SQL Server DB、Oracle DB、PostgreSQL のログを AWS 管理コンソールから CloudWatch Logs にパブリッシュするには

1. https://console.aws.amazon.com/rds/ で Amazon RDS コンソールを開きます。
2. ナビゲーション パネルで [データベース] を選択します。
3. 変更する DB インスタンスを選択します。
4. [変更] を選択します。
5. [ログのエクスポート] で、すべてのログファイルを選択して CloudWatch Logs へのパブリッシュを開始します。
6. ログのエクスポートは、CloudWatch Logs への公開をサポートするデータベース エンジンのバージョンでのみ使用できます。
7. [続行] を選択します。次に、概要ページで [DB インスタンスを変更] を選択します。

新しい DB パラメータ グループまたは DB オプション グループを RDS DB インスタンスに適用する

1. https://console.aws.amazon.com/rds/ で Amazon RDS コンソールを開きます。
2. ナビゲーション パネルで [データベース] を選択します。
3. 変更する DB インスタンスを選択します。
4. [変更] を選択します。
5. [データベース オプション] で、必要に応じて DB パラメータ グループと DB オプション グループを変更します。
6. 変更が完了したら、[続行] を選択します。変更の概要を確認します。
7. [DB インスタンスを変更] を選択して変更を保存します。

AWS CLI

エンジン ファミリーを取得し、DB インスタンス エンジンとバージョンに一致するエンジン ファミリーを選択します。

aws rds describe-db-engine-versions \
  --query "DBEngineVersions[].DBParameterGroupFamily" \
  --engine "mysql"

エンジンとバージョンに従ってパラメータ グループを作成します。

aws rds create-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --db-parameter-group-family "mysql5.7" \
  --description "Example parameter group for logs"

DB エンジンに従って、必要なパラメータを含む rds-parameters.json ファイルを作成します。この例では、MySQL5.7 を使用しています。

[
  {
    "ParameterName": "general_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "slow_query_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "log_output",
    "ParameterValue": "FILE",
    "ApplyMethod": "immediate"
  }
]

DB エンジンに従ってパラメータを追加するようにパラメータ グループを変更します。この例では MySQL5.7 を使用しています。

aws rds modify-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --parameters file://rds-parameters.json

DB インスタンスを変更してパラメータ グループを関連付けます。

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --db-parameter-group-name "rds-mysql-parameter-group"

また、MariaDB の場合は、次のようにオプション グループを作成します。

aws rds create-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --engine-name "mariadb" \
  --major-engine-version "10.6" \
  --option-group-description "Option group for MariaDB logs"

次のように rds-mariadb-options.json ファイルを作成します。

{
  "OptionName": "MARIADB_AUDIT_PLUGIN",
  "OptionSettings": [
    {
      "Name": "SERVER_AUDIT_EVENTS",
      "Value": "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  ]
}

オプション グループにオプションを追加します。

aws rds add-option-to-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --options file://rds-mariadb-options.json

MariaDB インスタンスを変更して、オプション グループを DB インスタンスに関連付けます。

aws rds modify-db-instance \
  --db-instance-identifier "rds-test-mariadb" \
  --option-group-name "rds-mariadb-option-group"

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Rds Multi Az Support

API のカテゴリ名: RDS_MULTI_AZ_SUPPORT

RDS DB インスタンスは、複数のアベイラビリティ ゾーン（AZ）用に構成する必要があります。これにより、保存されたデータの可用性が確保されます。マルチ AZ デプロイでは、アベイラビリティ ゾーンの可用性で問題が発生した場合や、RDS の定期メンテナンス中に自動フェイルオーバーが可能になります。

推奨事項: すべての RDS DB インスタンスに対して高可用性が有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

このコントロールを修正するには、aws_db_instance リソースで multi_az を true に設定します。

resource "aws_db_instance" "example" {
  # ... other configuration ...
  multi_az                = true
}

AWS コンソール

1 つの DB インスタンスに対して複数のアベイラビリティ ゾーンを有効にするには

1. https://console.aws.amazon.com/rds/ で Amazon RDS コンソールを開きます。
2. ナビゲーション パネルで、[データベース] を選択し、変更する DB インスタンスを選択します。
3. [変更] を選択します。[DB インスタンスを変更] ページが表示されます。
4. [インスタンスの仕様] で、[マルチ AZ デプロイ] を [Yes] に設定します。
5. [続行] を選択してから、変更の概要を確認します。
6. （省略可）変更をすぐに適用するには、[すぐに適用] を選択します。このオプションを選択すると、サービスが停止することがあります。詳細については、Amazon RDS ユーザーガイドの「すぐに適用」の設定の使用をご覧ください。
7. 確認ページで変更内容を確認します。正しい場合は、[DB インスタンスを変更] を選択して変更を保存します。

AWS CLI

AWS CLI の場合も同様です。--multi-az オプションを指定して、マルチ AZ のサポートを有効にします。

modify-db-instance
  --db-instance-identifier "test-rds" \
  --multi-az

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Redshift Cluster Configuration Check

API のカテゴリ名: REDSHIFT_CLUSTER_CONFIGURATION_CHECK

これにより、Redshift クラスタの重要な要素（保存データの暗号化、ロギング、ノードタイプ）を確認。

これらの構成項目は、安全で監視可能な Redshift クラスタのメンテナンスにおいて重要です。

推奨事項: すべての Redshift クラスタに保存データの暗号化、ロギング、ノードタイプがあることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

resource "aws_kms_key" "redshift_encryption" {
  description         = "Used for Redshift encryption configuration"
  enable_key_rotation = true
}

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  encrypted                           = true
  kms_key_id                          = aws_kms_key.redshift_encryption.id
  logging {
    enable               = true
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
}

AWS コンソール

クラスタ監査ロギングを有効にするには

1. https://console.aws.amazon.com/redshift/ で Amazon Redshift コンソールを開きます。
2. ナビゲーション メニューで [クラスタ] を選択し、変更するクラスタの名前を選択します。
3. [プロパティ] を選択します。
4. [編集] を選択し、監査ログを編集します。
5. [監査ロギングを構成] をオンに設定し、ログのエクスポート タイプを CloudWatch（推奨）に設定して、エクスポートするログを選択します。

AWS S3 を使用して Redshift 監査ログを管理するには、AWS ドキュメントの Redshift - データベース監査ロギングをご覧ください。

6. [変更を保存] をクリックします。

クラスタのデータベース暗号化を変更するには

1. AWS マネジメント コンソールにログインし、https://console.aws.amazon.com/redshift/ で Amazon Redshift コンソールを開きます。
2. ナビゲーション メニューで [クラスタ] を選択してから、暗号化を変更するクラスタを選択します。
3. [プロパティ] を選択します。
4. [編集] を選択し暗号化を編集します。
5. 使用する暗号化（KMS または HSM）を選択し、次の情報を指定します。

• KMS の場合: 使用する鍵
• HSM の場合: 接続とクライアント証明書

AWS CLI

1. KMS 鍵を作成し、鍵 ID を取得する

aws kms create-key \
  --description "Key to encrypt Redshift Clusters"

2. クラスタを変更する

aws redshift modify-cluster \
  --cluster-identifiers "test-redshift-cluster" \
  --encrypted \
  --kms-key-id <value>

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Redshift Cluster Maintenancesettings Check

API のカテゴリ名: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK

メジャー バージョンの自動アップグレードはメンテナンスの時間枠に従って行われます

推奨事項: すべての Redshift クラスタで allowVersionUpgrade が有効になっており、preferredMaintenanceWindow とautomaticSnapshotRetentionPeriod が設定されていることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

このチェックは、Terraform で提供されるすべてのデフォルト値に準拠しています。Redshift クラスタで障害が発生した場合は、要件を確認し、aws_redshift_cluster リソースの次の属性のデフォルトのオーバーライドを削除します。

resource "aws_redshift_cluster" "example" {

  # ...other configuration ...

  # The following values are compliant and set by default if omitted.
  allow_version_upgrade               = true
  preferred_maintenance_window        = "sat:10:00-sat:10:30"
  automated_snapshot_retention_period = 1
}

AWS コンソール

AWS コンソールから Redshift クラスタを作成する場合、デフォルト値はすでにこのコントロールに準拠しています。

詳細については、コンソールを使用したクラスタの管理をご覧ください。

AWS CLI

AWS CLI を使用してこのコントロールを修正するには、次の手順に従います。

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --allow-version-upgrade

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Redshift Cluster Public Access Check

API のカテゴリ名: REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK

Amazon Redshift クラスタ構成の PubliclyAccessible 属性は、クラスタが一般公開されているかどうかを示します。クラスタが PubliclyAccessible を true に設定して構成されている場合、これは一般公開された解決可能な DNS 名を持つインターネット接続インスタンスであり、パブリック IP アドレスに解決されます。

一般公開されていないクラスタは、プライベート IP アドレスに解決される DNS 名を持つ内部インスタンスとなります。クラスタを一般公開する場合を除き、クラスタでは PubliclyAccessible を true に設定しないでください。

推奨事項: Redshift クラスタが公開されていてアクセス可能かどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

このコントロールを修正するには、redshift クラスタ リソースを変更して、publicly_accessible を false に設定する必要があります。デフォルト値は true です。

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  publicly_accessible = false
}

AWS コンソール

Amazon Redshift クラスタへの公開アクセスを無効にするには

1. https://console.aws.amazon.com/redshift/ で Amazon Redshift コンソールを開きます。
2. ナビゲーション メニューで [クラスタ] を選択してから、変更するセキュリティ グループを含むクラスタの名前を選択します。
3. [アクション] を選択し、[公開アクセスの設定を変更] を選択します。
4. [VPC 外のインスタンスとデバイスが、クラスタ エンドポイントを介してデータベースに接続することを許可する] で、[No] を選択します。
5. [確認] を選択します。

AWS CLI

modify-cluster コマンドを使用して、--no-publicly-accessible を設定します。

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --no-publicly-accessible

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Restricted Common Ports

API のカテゴリ名: RESTRICTED_COMMON_PORTS

これにより、セキュリティ グループへの無制限の受信トラフィックが、リスクが最も高い、指定されたポートにアクセスできるかどうかを確認します。セキュリティ グループ内のいずれかのルールでこれらのポートの「0.0.0.0/0」または「::/0」からの上り（内向き）トラフィックが許可される場合、このコントロールは失敗します。

無制限のアクセス（0.0.0.0/0）は、ハッキング、サービス拒否攻撃、データ損失などの悪意のあるアクティビティを発生させる機会を増やします。

セキュリティ グループは、AWS リソースに上り（内向き）と下り（外向き）のネットワーク トラフィックのステートフル フィルタリングを提供します。どのセキュリティ グループでも、次のポートへの無制限の上り（内向き）アクセスを許可しないでください。

• 20、21（FTP）
• 22（SSH）
• 23（Telnet）
• 25（SMTP）
• 110（POP3）
• 135（RPC）
• 143（IMAP）
• 445（CIFS）
• 1433、1434（MSSQL）
• 3000（Go、Node.js、Ruby ウェブ開発フレームワーク）
• 3306（mySQL）
• 3389（RDP）
• 4333（ahsp）
• 5000（Python ウェブ開発フレームワーク）
• 5432（postgresql）
• 5500（fcp-addr-srvr1）
• 5601（OpenSearch ダッシュボード）
• 8080（プロキシ）
• 8088（以前の HTTP ポート）
• 8888（代替 HTTP ポート）
• 9200 または 9300（OpenSearch）

推奨事項: セキュリティ グループでは、リスクの高いポートへの無制限のアクセスを許可しないでください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

セキュリティ グループのルールを削除するには:

1. Amazon EC2 コンソール（https://console.aws.amazon.com/ec2/）を開きます。
2. ナビゲーション パネルで [セキュリティ グループ] を選択します。
3. 更新するセキュリティ グループを選択し、[アクション] を選択し、[受信ルールを編集] を選択して受信ルールを削除するか、[送信ルールを編集] を選択して送信ルールを削除します。
4. 削除するルールの右側にある [削除] ボタンを選択します。
5. [変更をプレビュー]、[確認] の順に選択します。

セキュリティ グループからルールを削除する方法については、Linux インスタンス用の Amazon EC2 ユーザーガイドのセキュリティ グループからルールを削除するをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Restricted Ssh

API のカテゴリ名: RESTRICTED_SSH

セキュリティ グループは、AWS リソースに上り（内向き）と下り（外向き）のネットワーク トラフィックのステートフル フィルタリングを提供します。

CIS は、セキュリティ グループでポート 22 への無制限の上り（内向き）アクセスを許可しないことを推奨しています。SSH などのリモート コンソール サービスへの無制限の接続を削除することで、サーバーの露出リスクが軽減されます。

推奨事項: セキュリティ グループでは、0.0.0.0/0 からポート 22 への上り（内向き）を許可しないでください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

VPC に関連付けられているセキュリティ グループごとに次の手順を行います。

https://console.aws.amazon.com/vpc/ で Amazon VPC コンソールを開きます。

1. 左側のペインで [セキュリティ グループ] を選択します。
2. セキュリティ グループを選択します。
3. ページの下部にある [受信ルール] タブを選択します。
4. [ルールを編集] を選択します。
5. ポート 22 経由のアクセスを許可するルールを特定し、[X] を選択して削除します。
6. [ルールを保存] を選択します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Rotation Customer Created Cmks Enabled

API のカテゴリ名: ROTATION_CUSTOMER_CREATED_CMKS_ENABLED

鍵ごとに鍵の自動ローテーションが有効になっているかどうか、顧客作成の AWS KMS 鍵の鍵 ID と一致するかどうかを確認します。リソースの AWS Config レコーダーのロールに kms:DescribeKey 権限がない場合、ルールは NON_COMPLIANT です。

推奨事項: 顧客作成の CMK のローテーションが有効になっていることを確認してください

AWS KMS の鍵の自動ローテーションを有効にするには、AWS ドキュメントの AWS KMS 鍵のローテーションをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Rotation Customer Created Symmetric Cmks Enabled

API のカテゴリ名: ROTATION_CUSTOMER_CREATED_SYMMETRIC_CMKS_ENABLED

AWS 鍵管理サービス（KMS）では、顧客作成の顧客マスター鍵（CMK）の鍵 ID に関連付けられた KMS に保存されている鍵のマテリアルを、顧客がローテーションできます。これは、暗号化や復号などの暗号オペレーションの実行に使用されるバックアップ鍵です。現在、鍵の自動ローテーションでは以前のバッキング鍵がすべて保持されるため、暗号化されたデータの復号は透過的に行うことができます。対称鍵に対して CMK 鍵のローテーションを有効にすることをおすすめします。非対称 CMK では鍵のローテーションを有効にできません。

推奨事項: 顧客作成の対称 CMK のローテーションが有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. AWS 管理コンソールにログインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
2. 左側のナビゲーション パネルで [Customer managed keys] を選択します。
3. Key spec = SYMMETRIC_DEFAULT の顧客管理の CMK を選択します。
4. [全般構成] パネルの下にある [鍵のローテーション] タブを開きます。
5. [この KMS 鍵を毎年自動的にローテーションする] チェックボックスをオンにします。

AWS CLI

1. 鍵のローテーションを有効にするには、次のコマンドを実行します。

 aws kms enable-key-rotation --key-id <kms_key_id>

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Routing Tables Vpc Peering Are Least Access

API のカテゴリ名: ROUTING_TABLES_VPC_PEERING_ARE_LEAST_ACCESS

VPC ピアリングのルートテーブルが、最小権限のプリンシパルで構成されているかどうかを確認します。

推奨事項: VPC ピアリングのルーティング テーブルが「最小限のアクセス権」であることを確認してください

VPC ピアリングのルートテーブルを更新するには、AWS VPC ユーザーガイドの VPC ピアリング接続のルートテーブルを更新するをご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

S3 Account Level Public Access Blocks

API のカテゴリ名: S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS

Amazon S3 Block Public Access では、Amazon S3 リソースへの公開アクセスを管理するためのアクセス ポイント、バケット、アカウントを設定できます。デフォルトでは、新しいバケット、アクセス ポイント、オブジェクトは公開アクセスを許可しません。

推奨事項: 必要な S3 公開アクセス ブロック設定がアカウント レベルで構成されているかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

次の Terraform リソースでは、アカウント レベルの S3 へのアクセスを構成します。

resource "aws_s3_account_public_access_block" "s3_control" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

AWS コンソール

AWS アカウント内のすべての S3 バケットについて、公開アクセスのブロック設定を編集するには。

1. AWS マネジメント コンソールにログインし、https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
2. このアカウントの [公開アクセスのブロック設定] を選択します。
3. [編集] を選択して、AWS アカウントのすべてのバケットに対する公開アクセスのブロック設定を変更します。
4. 変更する設定を選択し、[変更を保存] を選択します。
5. 確認のメッセージが表示されたら、「確認」と入力します。次に、[確認] を選択して変更を保存します。

AWS CLI

aws s3control put-public-access-block \
--account-id <value> \
--public-access-block-configuration '{"BlockPublicAcls": true, "BlockPublicPolicy": true, "IgnorePublicAcls": true, "RestrictPublicBuckets": true}'

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

S3 Bucket Logging Enabled

API のカテゴリ名: S3_BUCKET_LOGGING_ENABLED

AWS S3 サーバー アクセス ロギング機能は、ストレージ バケットへのアクセス リクエストを記録します。これは、セキュリティ監査に役立ちます。デフォルトでは、S3 バケットではサーバー アクセス ロギングは有効になっていません。

推奨事項: すべての S3 バケットでロギングが有効になっているか確認します

この検出結果を修正するには、次の操作を完了します。

Terraform

次の例は、2 つのバケットを作成する方法を示しています。

1. ロギング バケット
2. 準拠しているバケット

variable "bucket_acl_map" {
  type = map(any)
  default = {
    "logging-bucket"   = "log-delivery-write"
    "compliant-bucket" = "private"
  }
}

resource "aws_s3_bucket" "all" {
  for_each            = var.bucket_acl_map
  bucket              = each.key
  object_lock_enabled = true
  tags = {
    "Pwd"    = "s3"
  }
}

resource "aws_s3_bucket_acl" "private" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  acl      = each.value
}

resource "aws_s3_bucket_versioning" "enabled" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_logging" "enabled" {
  for_each      = var.bucket_acl_map
  bucket        = each.key
  target_bucket = aws_s3_bucket.all["logging-bucket"].id
  target_prefix = "log/"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  for_each = var.bucket_acl_map
  bucket   = each.key

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
    }
  }
}

AWS コンソール

AWS コンソールを介して S3 アクセス ロギングを有効にする方法については、AWS ドキュメントの Amazon S3 サーバー アクセス ロギングの有効化をご覧ください。

AWS CLI

以下の例は、次の方法を示しています。

1. ロギング サービス プリンシパルに、ロギング バケットで PutObject の権限を付与するバケット ポリシーを作成します。

policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ServerAccessLogsPolicy",
            "Effect": "Allow",
            "Principal": {"Service": "logging.s3.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::MyBucket/Logs/*",
            "Condition": {
                "ArnLike": {"aws:SourceARN": "arn:aws:s3:::SOURCE-BUCKET-NAME"},
                "StringEquals": {"aws:SourceAccount": "SOURCE-AWS-ACCOUNT-ID"}
            }
        }
    ]
}

aws s3api put-bucket-policy \
  --bucket my-bucket
  --policy file://policy.json

2. ロギング バケットにポリシーを適用する

logging.json

{
    "LoggingEnabled": {
        "TargetBucket": "MyBucket",
        "TargetPrefix": "Logs/"
    }
}

aws s3api put-bucket-logging \
  --bucket MyBucket \
  --bucket-logging-status file://logging.json

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

S3 Bucket Policy Set Deny Http Requests

API のカテゴリ名: S3_BUCKET_POLICY_SET_DENY_HTTP_REQUESTS

Amazon S3 バケットレベルでは、バケット ポリシーを使用して権限を構成し、HTTPS 経由でのみオブジェクトにアクセスできるようにできます。

推奨事項: S3 バケット ポリシーが HTTP リクエストを拒否するように設定されていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

AWS Policy Generator を使用。

1. 上記のステップ 1 ～ 4 を繰り返します。
2. バケット ポリシー エディタの下部にある [Policy Generator] をクリックする
3. ポリシータイプを選択する
   S3 Bucket Policy
4. ステートメントを追加する
   - Effect = Deny
   - Principal = *
   - AWS Service = Amazon S3
   - Actions = *
   - Amazon Resource Name =
5. ポリシーを生成する
6. テキストをコピーして、バケット ポリシーに追加します。

AWS CLI

1. バケット ポリシーを json ファイルにエクスポートします。

aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json

2. このステートメントに追加して、policy.json ファイルを変更します。

{
 "Sid": <optional>",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::<bucket_name>/*",
 "Condition": {
 "Bool": {
 "aws:SecureTransport": "false"
 }
 }
 }

3. この変更したポリシーを S3 バケットに適用します。

aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

S3 Bucket Replication Enabled

API のカテゴリ名: S3_BUCKET_REPLICATION_ENABLED

このコントロールでは、Amazon S3 バケットでクロスリージョン レプリケーションが有効になっているかどうかを確認します。バケットでクロスリージョン レプリケーションが有効になっていない場合、または同一リージョン レプリケーションが有効になっている場合でも、コントロールは失敗します。

レプリケーションは、同じまたは異なる AWS リージョン内のバケット間でのオブジェクトの自動非同期コピーです。レプリケーションにより、新しく作成されたオブジェクトとオブジェクトの更新が、ソースバケットから宛先バケットにコピーされます。AWS のベスト プラクティスでは、同じ AWS アカウントが所有するソースバケットと宛先バケットのレプリケーションが推奨されています。可用性だけでなく、他のシステム強化設定も検討する必要があります。

推奨事項: S3 バケットでクロスリージョン レプリケーションが有効になっているか確認します

S3 バケットでリージョン間レプリケーションを有効にするには、Amazon Simple Storage Service ユーザーガイドの同じアカウントが所有するソースバケットと宛先バケットのレプリケーションの構成をご覧ください。ソースバケットに対して、[バケット内のすべてのオブジェクトに適用] を選択します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

S3 Bucket Server Side Encryption Enabled

API のカテゴリ名: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED

これにより、S3 バケットで Amazon S3 のデフォルトの暗号化が有効になっていること、またはサーバーサイドの暗号化なしで put-object リクエストが S3 バケット ポリシーで明示的に拒否されているかどうかを確認します。

推奨事項: すべての S3 バケットで保存データの暗号化が使用されていることを確認してください

この検出結果を修正するには、次の操作を完了します。

Terraform

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

AWS コンソール

S3 バケットでデフォルトの暗号化を有効にするには

1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
2. 左側のナビゲーション パネルで [バケット] を選択します。
3. リストから S3 バケットを選択します。
4. [プロパティ] を選択します。
5. [デフォルトの暗号化] を選択します。
6. 暗号化には、AES-256 または AWS-KMS を選択します。
7. デフォルトの暗号化に Amazon S3 が管理する鍵を使用するには、AES-256 を選択します。Amazon S3 サーバー側の暗号化を使用してデータを暗号化する方法については、Amazon Simple Storage Service ユーザーガイドをご覧ください。
8. デフォルトの暗号化に AWS KMS が管理する鍵を使用するには、AWS-KMS を選択します。次に、作成した AWS KMS マスターキーのリストからマスターキーを選択します。
9. 使用する AWS KMS 鍵の Amazon リソース名（ARN）を入力します。AWS KMS 鍵の ARN は、IAM コンソールの [暗号鍵] で確認できます。または、プルダウン リストから鍵名を選択することもできます。
10. 重要: デフォルトの暗号化構成で AWS KMS オプションを使用すると、AWS KMS の RPS（1 秒あたりのリクエスト数）の割り当てが適用されます。AWS KMS の割り当てと、割り当ての増加をリクエストする方法の詳細については、AWS 鍵管理サービス デベロッパー ガイドをご覧ください。
11. [保存] を選択します。

AWS KMS 鍵の作成の詳細については、AWS 鍵管理サービス デベロッパー ガイドをご覧ください。

Amazon S3 で AWS KMS を使用する方法の詳細については、Amazon Simple Storage Service ユーザーガイドをご覧ください。

デフォルトの暗号化を有効にするときは、バケット ポリシーの更新が必要になることがあります。バケット ポリシーからデフォルトの暗号化への移行の詳細については、Amazon Simple Storage サービス ユーザーガイドをご覧ください。

AWS CLI

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

S3 Bucket Versioning Enabled

API のカテゴリ名: S3_BUCKET_VERSIONING_ENABLED

Amazon S3 を使用すると、1 つのオブジェクトの複数のバリアントを同じバケット内に維持できるため、意図しないユーザー操作やアプリケーションの障害から容易に復旧できます。

推奨事項: すべての S3 バケットでバージョニングが有効になっていることを確認します

この検出結果を修正するには、次の操作を完了します。

Terraform

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"

  versioning {
    enabled = true
  }
}

AWS コンソール

S3 バケットでバージョニングを有効または無効にするには

1. AWS マネジメント コンソールにログインし、https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
2. [バケット] リストで、バージョニングを有効にするバケットの名前を選択します。
3. [プロパティ] を選択します。
4. [バケットのバージョニング] で [編集] を選択します。
5. [一時停止] または [有効化] を選択してから、[変更を保存] を選択します。

AWS CLI

aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

S3 Default Encryption Kms

API のカテゴリ名: S3_DEFAULT_ENCRYPTION_KMS

Amazon S3 バケットが AWS 鍵管理サービス（AWS KMS）で暗号化されているかどうかを確認する

推奨事項: すべてのバケットが KMS を使用して暗号化されていることを確認します

この検出結果を修正するには、次の操作を完了します。

Terraform

resource "aws_kms_key" "s3_encryption" {
  description         = "Used for S3 Bucket encryption configuration"
  enable_key_rotation = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket   = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.s3_encryption.arn
      sse_algorithm     = "aws:kms"
    }
  }
}

AWS コンソール

S3 バケットでデフォルトの暗号化を有効にするには

1. https://console.aws.amazon.com/s3/ で Amazon S3 コンソールを開きます。
2. 左側のナビゲーション パネルで [バケット] を選択します。
3. リストから S3 バケットを選択します。
4. [プロパティ] を選択します。
5. [デフォルトの暗号化] を選択します。
6. 暗号化には、AWS-KMS を選択します。
7. デフォルトの暗号化に AWS KMS が管理する鍵を使用するには、AWS-KMS を選択します。次に、作成した AWS KMS マスターキーのリストからマスターキーを選択します。KMS 鍵の作成方法については、AWS ドキュメント - 鍵の作成をご覧ください。
8. 使用する AWS KMS 鍵の Amazon リソース名（ARN）を入力します。AWS KMS 鍵の ARN は、IAM コンソールの [暗号鍵] で確認できます。または、プルダウン リストから鍵名を選択することもできます。
9. 重要: このソリューションは、AWS KMS の RPS（1 秒あたりのリクエスト数）の割り当ての対象です。AWS KMS の割り当てと、割り当ての増加をリクエストする方法の詳細については、AWS 鍵管理サービス デベロッパー ガイドをご覧ください。
10. [保存] を選択します。

Amazon S3 で AWS KMS を使用する方法の詳細については、Amazon Simple Storage Service ユーザーガイドをご覧ください。

デフォルトの暗号化を有効にするときは、バケット ポリシーの更新が必要になることがあります。バケット ポリシーからデフォルトの暗号化への移行の詳細については、Amazon Simple Storage サービス ユーザーガイドをご覧ください。

AWS CLI

KMS 鍵を作成する

aws kms create-key \
  --description "Key to encrypt S3 buckets"

鍵のローテーションを有効にする

aws kms enable-key-rotation \
  --key-id <key_id_from_previous_command>

バケットを更新

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"KMSMasterKeyID": "<id_from_key>", "SSEAlgorithm": "AES256"}}]}'

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Sagemaker Notebook Instance Kms Key Configured

API のカテゴリ名: SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED

Amazon SageMaker ノートブック インスタンスに AWS 鍵管理サービス（AWS KMS）鍵が構成されているかどうかを確認します。SageMaker ノートブック インスタンスに「KmsKeyId」が指定されていない場合、ルールは NON_COMPLIANT です。

推奨事項: すべての SageMaker ノートブック インスタンスが KMS を使用するように構成されていることを確認してください

SageMaker 用の KMS を構成するには、Amazon SageMaker ドキュメントの鍵管理をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Sagemaker Notebook No Direct Internet Access

API のカテゴリ名: SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS

SageMaker ノートブック インスタンスでインターネットからの直接アクセスが無効になっているかどうかを確認します。これを行うには、ノートブック インスタンスの DirectInternetAccess フィールドが無効になっているかどうかを確認します。

VPC を使用せずに SageMaker インスタンスを構成すると、デフォルトでインスタンスで直接インターネット アクセスが有効になります。VPC を使用してインスタンスを構成し、デフォルト設定を [無効 - VPC 経由でインターネットにアクセス] に変更します。

ノートブックからモデルをトレーニングまたはホストするには、インターネット アクセスが必要です。インターネット アクセスを有効にするには、VPC に NAT ゲートウェイがあり、セキュリティ グループでアウトバウンド接続が許可されていることを確認します。ノートブック インスタンスを VPC のリソースに接続する方法の詳細については、Amazon SageMaker デベロッパー ガイドの「VPC 内のリソースにノートブック インスタンスを接続する」をご覧ください。

また、SageMaker 構成へのアクセスは、承認されたユーザーのみに制限する必要もあります。SageMaker の設定とリソースを変更するユーザーの IAM 権限を制限します。

推奨事項: すべての Amazon SageMaker ノートブック インスタンスでインターネットからの直接アクセスが無効になっているかどうかを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

ノートブック インスタンスの作成後に、インターネット アクセスの設定を変更することはできません。停止、削除、再作成する必要があります。

直接インターネット アクセスを拒否するように SageMaker ノートブック インスタンスを構成するには:

1. https://console.aws.amazon.com/sagemaker/ で SageMaker コンソールを開きます。
2. ノートブック インスタンスに移動します。
3. 直接インターネット アクセスが有効になっているインスタンスを削除します。インスタンスを選択し、[アクション] を選択して [停止] を選択します。
4. インスタンスが停止したら、[アクション] を選択してから [削除] を選択します。
5. [ノートブック インスタンスを作成] を選択します。構成の詳細を入力します。
6. [ネットワーク] セクションを開いてから、VPC、サブネット、セキュリティ グループを選択します。[直接インターネット アクセス] で [無効 - VPC 経由でインターネットにアクセス] を選択します。
7. [ノートブック インスタンスを作成] を選択します。

詳細については、Amazon SageMaker デベロッパー ガイドの「VPC 内のリソースにノートブック インスタンスを接続する」をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Secretsmanager Rotation Enabled Check

API のカテゴリ名: SECRETSMANAGER_ROTATION_ENABLED_CHECK

AWS Secret Manager に保存されているシークレットが自動ローテーションで構成されているかどうかを確認します。シークレットが自動ローテーションで構成されていない場合、コントロールは失敗します。maximumAllowedRotationFrequency パラメータにカスタム値を指定すると、指定した時間枠内にシークレットが自動的にローテーションされた場合にのみ、コントロールがパスします。

Secret Manager は、組織のセキュリティ対策の強化に役立ちます。シークレットには、データベースの認証情報、パスワード、サードパーティの API キーが含まれます。Secret Manager を使用すると、シークレットの一元的な保存、シークレットの自動暗号化、シークレットへのアクセスの制御、シークレットの安全かつ自動的なローテーションを行えます。

Secret Manager はシークレットをローテーションできます。ローテーションを使用して、長期的なシークレットを短期的なシークレットに置き換えることができます。シークレットをローテーションすると、権限のないユーザーが不正使用されたシークレットを使用できる期間が制限されます。このため、シークレットは頻繁にローテーションする必要があります。ローテーションの詳細については、AWS Secret Manager ユーザーガイドの AWS Secret Manager シークレットのローテーションをご覧ください。

推奨事項: すべての AWS Secret Manager シークレットでローテーションが有効になっていることを確認してください

Secret Manager のシークレットの自動ローテーションを有効にするには、AWS Secret Manager のユーザーガイドの「コンソールを使用して AWS Secret Manager のシークレットの自動ローテーションを設定する」をご覧ください。ローテーション用の AWS Lambda 関数を選択して構成する必要があります。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Sns Encrypted Kms

API のカテゴリ名: SNS_ENCRYPTED_KMS

SNS トピックが AWS KMS を使用して保存時に暗号化されているかどうかを確認します。SNS トピックがサーバーサイドの暗号化（SSE）に KMS 鍵を使用していない場合、コントロールは失敗します。

保存データを暗号化することで、ディスクに保存されているデータに AWS で認証されていないユーザーがアクセスするリスクを軽減できます。また、権限のないユーザーのデータへのアクセスを制限するアクセス制御セットも追加します。たとえば、データを読み取る前に復号するには、API 権限が必要です。セキュリティ強化のために、SNS トピックを保存時に暗号化する必要があります。

推奨事項: すべての SNS トピックが KMS で暗号化されていることを確認してください

SNS トピックの SSE を有効にするには、Amazon Simple Notification Service デベロッパー ガイドの「Amazon SNS トピックのサーバーサイド暗号化（SSE）を有効にする」をご覧ください。SSE を使用する前に、トピックの暗号化とメッセージの暗号化と復号を許可するように AWS KMS 鍵ポリシーも構成する必要があります。詳細については、Amazon Simple Notification Service デベロッパー ガイドの「AWS KMS 権限の構成」をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Vpc Default Security Group Closed

API のカテゴリ名: VPC_DEFAULT_SECURITY_GROUP_CLOSED

このコントロールでは、VPC のデフォルトのセキュリティ グループが受信トラフィックと送信トラフィックのどちらを許可しているかを確認します。セキュリティ グループが受信トラフィックまたはアウトバウンド トラフィックを許可している場合、このコントロールは失敗します。

デフォルトのセキュリティ グループのルールでは、同じセキュリティ グループに割り当てられているネットワーク インターフェース（および関連するインスタンス）からのすべてのアウトバウンド トラフィックとインバウンド トラフィックが許可されます。デフォルトのセキュリティ グループは使用しないことをおすすめします。デフォルトのセキュリティ グループは削除できないため、デフォルトのセキュリティ グループのルール設定を変更して、インバウンド トラフィックとアウトバウンド トラフィックを制限する必要があります。これにより、EC2 インスタンスなどのリソースに対してデフォルトのセキュリティ グループが誤って構成されている場合に、意図しないトラフィックが発生するのを防ぎます。

推奨事項: それぞれの VPC のデフォルト セキュリティ グループがすべてのトラフィックを制限することを確認してください

この問題を解決するには、まず最小権限のセキュリティ グループを作成してください。手順については、Amazon VPC ユーザーガイドの「セキュリティ グループを作成する」をご覧ください。次に、新しいセキュリティ グループを EC2 インスタンスに割り当てます。手順については、Linux インスタンス用の Amazon EC2 ユーザーガイドの「インスタンスのセキュリティ グループを変更する」をご覧ください。

新しいセキュリティ グループをリソースに割り当てたら、デフォルトのセキュリティ グループからすべての受信ルールと送信ルールを削除します。手順については、Amazon VPC ユーザーガイドの「セキュリティ グループのルールを削除する」をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Vpc Flow Logging Enabled All Vpcs

API のカテゴリ名: VPC_FLOW_LOGGING_ENABLED_ALL_VPCS

VPC フローログは、VPC 内のネットワーク インターフェースを経由する IP トラフィックに関する情報を取得できる機能です。フローログを作成すると、Amazon CloudWatch Logs でそのデータを表示および取得できます。VPC のパケットの「拒否」に対して、VPC フローログを有効にすることをおすすめします。

推奨事項: すべての VPC で VPC フローロギングが有効になっていることを確認してください

この検出結果を修正するには、次の操作を完了します。

AWS コンソール

1. 管理コンソールにログインする
2. [Services]、[VPC] の順に選択する
3. 左側のナビゲーション パネルで、[Your VPCs] を選択する
4. VPC を選択する
5. 右ペインで [Flow Logs] タブを選択します。
6. フローログが存在しない場合は、Create Flow Log をクリックする
7. フィルタの場合、Reject を選択する
8. Role と Destination Log Group を入力する
9. [Create Log Flow] をクリックします。
10. [CloudWatch Logs Group] をクリックする

注: フィルタを「拒否」に設定すると、この推奨事項のロギングデータの蓄積が大幅に減少し、違反の検出、調査、修復の目的で十分な情報が提供されます。ただし、最小権限のセキュリティ グループ エンジニアリング期間中は、このフィルタを「すべて」に設定すると、すでに実行されている環境が適切に動作するために必要な既存のトラフィック フローを検出するのに非常に便利です。

AWS CLI

1. ポリシー ドキュメントを作成し、role_policy_document.json という名前を付け、次の内容を貼り付けます。

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "test",
 "Effect": "Allow",
 "Principal": {
 "Service": "ec2.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
 ]
}

2. 別のポリシー ドキュメントを作成して iam_policy.json という名前を付け、次の内容を貼り付けます。

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action":[
 "logs:CreateLogGroup",
 "logs:CreateLogStream",
 "logs:DescribeLogGroups",
 "logs:DescribeLogStreams",
 "logs:PutLogEvents",
 "logs:GetLogEvents",
 "logs:FilterLogEvents"
 ],
 "Resource": "*"
 }
 ]
}

3. 次のコマンドを実行して IAM ロールを作成します。

aws iam create-role --role-name <aws_support_iam_role> --assume-role-policy-document file://<file-path>role_policy_document.json

4. 次のコマンドを実行して IAM ポリシーを作成します。

aws iam create-policy --policy-name <ami-policy-name> --policy-document file://<file-path>iam-policy.json

5. 前の手順で返された IAM ポリシー ARN を使用して attach-group-policy コマンドを実行し、ポリシーを IAM ロールにアタッチします（コマンドが成功した場合、出力は返されません）。

aws iam attach-group-policy --policy-arn arn:aws:iam::<aws-account-id>:policy/<iam-policy-name> --group-name <group-name>

6. describe-vpcs を実行して、選択したリージョンで使用可能な VpcId を取得します。

aws ec2 describe-vpcs --region <region>

7. コマンド出力で、選択したリージョンで使用可能な VPC ID が返されます。
8. create-flow-logs を実行して VPC のフローログを作成します。

aws ec2 create-flow-logs --resource-type VPC --resource-ids <vpc-id> --traffic-type REJECT --log-group-name <log-group-name> --deliver-logs-permission-arn <iam-role-arn>

9. 選択したリージョンで使用可能な他の VPC について、手順 8 を繰り返します。
10. --region を更新してリージョンを変更し、他の VPC について修復手順を繰り返します。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Vpc Sg Open Only To Authorized Ports

API のカテゴリ名: VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS

このコントロールは、Amazon EC2 セキュリティ グループが未承認のポートからの無制限の受信トラフィックを許可するかどうかを確認します。コントロール ステータスは次のように決定されます。

AuthorizationTcpPorts にデフォルト値を使用する場合、セキュリティ グループがポート 80 と 443 以外のポートからの無制限の受信トラフィックを許可すると、コントロールが失敗します。

authorizedTcpPorts または authorizedUdpPorts にカスタム値を指定した場合、セキュリティ グループがリストされていないポートからの無制限の受信トラフィックを許可すると、コントロールが失敗します。

パラメータが使用されていない場合、無制限の受信トラフィックのルールがあるセキュリティ グループに対するコントロールが失敗します。

セキュリティ グループは、AWS への上り（内向き）および下り（外向き）ネットワーク トラフィックのステートフル フィルタリングを提供します。セキュリティ グループのルールは、最小権限アクセスのプリンシパルに従う必要があります。無制限のアクセス（/0 接尾辞を持つ IP アドレス）は、ハッキング、サービス拒否攻撃、データ損失などの悪意のあるアクティビティを発生させる可能性が高くなります。ポートが特に許可されていない限り、そのポートは無制限のアクセスを拒否する必要があります。

推奨事項: 任意の VPC の 0.0.0.0/0 を持つセキュリティ グループが、特定のインバウンド TCP/UDP トラフィックのみを許可していることを確認してください

セキュリティ グループを変更するには、Amazon VPC ユーザーガイドのセキュリティ グループの操作をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。

Both VPC VPN Tunnels Up

API のカテゴリ名: VPC_VPN_2_TUNNELS_UP

VPN トンネルは、AWS サイト間 VPN 接続内で顧客ネットワークと AWS との間でデータをやり取りできる暗号化されたリンクです。各 VPN 接続には 2 つの VPN トンネルがあり、高可用性を確保するためにそれらを同時に使用できます。AWS VPC とリモート ネットワーク間の安全で可用性の高い接続を確保するために、両方の VPN トンネルが VPN 接続で稼働していることを確認することが重要です。

このコントロールにより、AWS サイト間 VPN によって提供される両方の VPN トンネルが UP ステータスであることを確認します。1 つまたは両方のトンネルが DOWN ステータスの場合、コントロールは失敗します。

推奨事項: AWS サイト間で提供される両方の AWS VPN トンネルが UP ステータスになっていることを確認してください

VPN トンネル オプションを変更するには、AWS サイト間 VPN ユーザーガイドのサイト間 VPN トンネル オプションの変更をご覧ください。

この検出結果のタイプでサポートされているアセットとスキャンの設定についての説明をご覧ください。