コンピューティング セキュリティに関する推奨事項

  • [アーティクル]

この記事では、Microsoft Defender for Cloud に表示される可能性があるすべてのマルチクラウド コンピューティング セキュリティの推奨事項を示します。

環境に表示される推奨事項は、保護するリソースとカスタマイズした構成に基づいています。

これらの推奨事項に応じて実行できるアクションについては、「Defender for Cloud で推奨事項を 修復するを参照してください。

ヒント

推奨事項の説明に 関連ポリシーがない、通常は、その推奨事項が別の推奨事項に依存しているためです。

たとえば、推奨事項 エンドポイント保護の正常性エラーを修復する必要があります は、エンドポイント保護ソリューションがインストールされているかどうかを確認する推奨事項に依存します (エンドポイント保護ソリューションをインストールする必要があります)。 基になる推奨事項にはポリシーが存在します。 ポリシーを基本的な推奨事項のみに制限すると、ポリシー管理が簡略化されます。

Azure コンピューティングの推奨事項

システム更新プログラムをマシンにインストールする必要がある (更新センターを利用)

説明: コンピューターにシステム、セキュリティ、および重要な更新プログラムがありません。 多くの場合、ソフトウェア更新プログラムには、セキュリティ ホールに対する重要なパッチが含まれています。 このようなホールはマルウェア攻撃で頻繁に悪用されるため、ソフトウェアを最新の状態に保つことが不可欠です。 未処理のパッチをすべてインストールし、マシンをセキュリティで保護するには、修復手順に従います。

重大度: 低

不足しているシステム更新プログラムを定期的に確認するようにマシンを構成する必要がある

説明: 不足しているシステム更新プログラムの定期的な評価が 24 時間ごとに自動的にトリガーされるようにするには、AssessmentMode プロパティを "AutomaticByPlatform" に設定する必要があります。 Windows の AssessmentMode プロパティの詳細については、 https://aka.ms/computevm-windowspatchassessmentmode、Linux の場合: https://aka.ms/computevm-linuxpatchassessmentmode。

重大度: 低

安全なアプリケーションの定義のために適応型アプリケーション制御をマシンで有効にする必要がある

説明: アプリケーション制御を有効にして、コンピューターで実行されている既知の安全なアプリケーションの一覧を定義し、他のアプリケーションの実行時にアラートを生成します。 これは、マルウェアに対してマシンを強化するのに役立ちます。 ルールの構成と保守のプロセスを簡略化するために、Defender for Cloud で機械学習を使用して各マシンで実行されているアプリケーションを分析し、既知の安全なアプリケーションの一覧を提示します。 (関連ポリシー: 安全なアプリケーションを定義するための適応型アプリケーション制御は、マシンで有効にする必要があります)。

重大度: 高

適応型アプリケーション制御ポリシーの許可リスト ルールを更新する必要がある

説明: Defender for Cloud の適応型アプリケーション制御による監査用に構成されたマシンのグループでの動作の変化を監視します。 Defender for Cloud では、Machine Learning を使用して、マシン上の実行中のプロセスを分析し、既知の安全なアプリケーションの一覧を提示します。 これらは、適応型アプリケーション制御ポリシーで許可する推奨アプリとして提供されています。 (関連ポリシー: アダプティブ アプリケーション制御ポリシーの許可リスト ルールを更新する必要があります)。

重大度: 高

Linux マシンに対する認証では SSH キーを要求する必要がある

説明: SSH 自体は暗号化された接続を提供しますが、SSH でパスワードを使用しても、VM はブルートフォース攻撃に対して脆弱なままです。 Azure Linux 仮想マシンに対して SSH による認証を行うための最も安全な方法は、公開キー/秘密キー ペア (SSH キーとも呼ばれます) を使用することです。 詳細については、「詳細な手順: Azure の Linux VM に対する認証用に SSH キーを作成して管理する」を参照してください。 (関連ポリシー: 認証に SSH キーを使用していない Linux マシンを監査します)。

重大度: 中

Automation アカウント変数は、暗号化する必要がある

説明: 機密データを格納するときは、Automation アカウント変数資産の暗号化を有効にすることが重要です。 (関連ポリシー: Automation アカウント変数は暗号化する必要があります)。

重大度: 高

仮想マシンに対して Azure Backup を有効にする必要がある

説明: Azure Backup を使用して Azure 仮想マシン上のデータを保護します。 Azure Backup は、Azure ネイティブで費用対効果の高いデータ保護ソリューションです。 geo 冗長 Recovery コンテナーに保存される復旧ポイントが作成されます。 復旧ポイントから復元するときは、VM 全体を復元するか、特定のファイルを復元することができます。 (関連ポリシー: 仮想マシン) に対して Azure Backup を有効にする必要があります。

重大度: 低

(プレビュー): Azure Stack HCI サーバーは、セキュリティで保護されたコアの要件を満たす必要がある

説明: すべての Azure Stack HCI サーバーがセキュリティで保護されたコア要件を満たしていることを確認します。 (関連ポリシー: ゲスト構成拡張機能は、マシンにインストールする必要があります - Microsoft Azure)。

重大度: 低

(プレビュー): Azure Stack HCI サーバーは、アプリケーション制御ポリシーを一貫して適用する必要がある

説明: 少なくとも、Microsoft WDAC 基本ポリシーをすべての Azure Stack HCI サーバーに適用モードで適用します。 適用される Windows Defender アプリケーション制御 (WDAC) ポリシーは、同じクラスター内のサーバー間で一貫している必要があります。 (関連ポリシー: ゲスト構成拡張機能は、マシンにインストールする必要があります - Microsoft Azure)。

重大度: 高

(プレビュー): Azure Stack HCI システムは、暗号化されたボリュームを使用する必要がある

説明: BitLocker を使用して、Azure Stack HCI システム上の OS とデータ ボリュームを暗号化します。 (関連ポリシー: ゲスト構成拡張機能は、マシンにインストールする必要があります - Microsoft Azure)。

重大度: 高

コンテナーのホストを安全に構成する必要がある

説明: Docker がインストールされているマシンのセキュリティ構成設定の脆弱性を修復して、攻撃から保護します。 (関連ポリシー: コンテナー のセキュリティ構成の脆弱性を修復する必要があります)。

重大度: 高

Azure Stream Analytics で診断ログを有効にする必要がある

説明: ログを有効にし、最大 1 年間保持します。 これにより、セキュリティ インシデントが発生した場合やネットワークが侵害された場合に、調査目的でアクティビティ証跡を再作成できます。 (関連ポリシー: Azure Stream Analytics の診断ログを有効にする必要があります)。

重大度: 低

Batch アカウントで診断ログを有効にする必要がある

説明: ログを有効にし、最大 1 年間保持します。 これにより、セキュリティ インシデントが発生した場合やネットワークが侵害された場合に、調査目的でアクティビティ証跡を再作成できます。 (関連ポリシー: Batch アカウントの診断ログを有効にする必要があります)。

重大度: 低

Event Hubs の診断ログを有効にする必要がある

説明: ログを有効にし、最大 1 年間保持します。 これにより、セキュリティ インシデントが発生した場合やネットワークが侵害された場合に、調査目的でアクティビティ証跡を再作成できます。 (関連ポリシー: Event Hubs の診断ログを有効にする必要があります)。

重大度: 低

Logic Apps における診断ログを有効にする必要がある

説明: セキュリティ インシデントが発生した場合やネットワークが侵害された場合に、調査目的でアクティビティ 証跡を再作成できるようにするには、ログ記録を有効にします。 診断ログが Log Analytics ワークスペース、Azure Storage アカウント、または Azure Event Hubs に送信されていない場合は、プラットフォーム メトリックとプラットフォーム ログを関連する宛先に送信するように診断設定を構成していることを確認します。 詳細については、「プラットフォーム ログとメトリックを異なる宛先に送信するための診断設定を作成する」をご覧ください。 (関連ポリシー: Logic Apps の診断ログを有効にする必要があります)。

重大度: 低

Service Bus で診断ログを有効にする必要がある

説明: ログを有効にし、最大 1 年間保持します。 これにより、セキュリティ インシデントが発生した場合やネットワークが侵害された場合に、調査目的でアクティビティ証跡を再作成できます。 (関連ポリシー: Service Bus の診断ログを有効にする必要があります)。

重大度: 低

仮想マシン スケール セットの診断ログを有効にする必要がある

説明: ログを有効にし、最大 1 年間保持します。 これにより、セキュリティ インシデントが発生した場合やネットワークが侵害された場合に、調査目的でアクティビティ証跡を再作成できます。 (関連ポリシー: 仮想マシン スケール セットの診断ログを有効にする必要があります)。

重大度: 高

仮想マシンで EDR 構成の問題を解決する必要がある

説明: 最新の脅威と脆弱性から仮想マシンを保護するには、インストールされているエンドポイント検出と応答 (EDR) ソリューションで特定されたすべての構成の問題を解決します。 現時点では、この推奨事項は、Microsoft Defender for Endpoint が有効になっているリソースにのみ適用されます。

このエージェントレス エンドポイントの推奨事項は、Defender for Servers プラン 2 または Defender CSPM プランがある場合に使用できます。 詳細については エージェントレス エンドポイント保護の推奨事項に関するページを参照してください。

重大度: 低

EDR ソリューションを Virtual Machines にインストールする必要がある

説明: 高度な脅威から保護するには、仮想マシンにエンドポイント検出および応答 (EDR) ソリューションをインストールすることが重要です。 EDR は、これらの脅威の防止、検出、調査、対応に役立つ。 Microsoft Defender for Servers を使用して、Microsoft Defender for Endpoint を展開できます。

  • リソースが "異常" として分類されている場合は、サポートされている EDR ソリューションがないことを示します。
  • EDR ソリューションがインストールされているが、この推奨事項では検出できない場合は、除外できます
  • EDR ソリューションがない場合、仮想マシンは高度な脅威の危険にさらされます。

このエージェントレス エンドポイントの推奨事項は、Defender for Servers プラン 2 または Defender CSPM プランがある場合に使用できます。 詳細については エージェントレス エンドポイント保護の推奨事項に関するページを参照してください。

重大度: 高

Virtual Machine Scale Sets で Endpoint Protection の正常性の問題を解決する必要がある

説明: 仮想マシン スケール セットで、エンドポイント保護の正常性エラーを修復して、脅威や脆弱性から保護します。 (関連ポリシー: エンドポイント保護ソリューションは、仮想マシン スケール セット) にインストールする必要があります。

重大度: 低

Virtual Machine Scale Sets に Endpoint Protection をインストールする必要がある

説明: エンドポイント保護ソリューションを仮想マシン スケール セットにインストールして、脅威や脆弱性から保護します。 (関連ポリシー: エンドポイント保護ソリューションは、仮想マシン スケール セット) にインストールする必要があります。

重大度: 高

マシンでファイルの整合性の監視を有効にする必要がある

説明: Defender for Cloud では、ファイル整合性監視ソリューションがないマシンが特定されました。 サーバー上の重要なファイルやレジストリ キーなどの変更を監視するには、ファイルの整合性の監視を有効にします。 ファイル整合性監視ソリューションが有効になっている場合は、監視するファイルを定義するデータ収集ルールを作成します。 ルールを定義したり、既存のルールを持つマシンで変更されたファイルを確認したりするには、 ファイル整合性監視管理ページに移動します。 (関連ポリシーはありません)

重大度: 高

サポートされている Linux 仮想マシンのスケール セットに Guest Attestation 拡張機能をインストールする必要がある

説明: サポートされている Linux 仮想マシン スケール セットにゲスト構成証明拡張機能をインストールして、Microsoft Defender for Cloud が起動の整合性を事前に証明して監視できるようにします。 インストール後は、リモート構成証明を通じて、ブート整合性の構成証明が行われるようになります。 この評価が適用されるのは、トラステッド起動が有効な Linux 仮想マシン スケール セットのみです。

  • トラステッド起動を使用するには、新しい仮想マシンを作成する必要があります。
  • 最初に作成されたときにトラステッド起動が有効にされていない既存の仮想マシンで、トラステッド起動を有効にすることはできません。

詳細については、「Azure Virtual Machines のトラステッド起動」を参照してください。 (関連ポリシーはありません)

重大度: 低

Guest Attestation 拡張機能を、サポートしている Linux 仮想マシンにインストールする必要があります

説明: サポートされている Linux 仮想マシンにゲスト構成証明拡張機能をインストールして、Microsoft Defender for Cloud が起動の整合性を事前に証明して監視できるようにします。 インストール後は、リモート構成証明を通じて、ブート整合性の構成証明が行われるようになります。 この評価が適用されるのは、トラステッド起動が有効な Linux 仮想マシンのみです。

  • トラステッド起動を使用するには、新しい仮想マシンを作成する必要があります。
  • 最初に作成されたときにトラステッド起動が有効にされていない既存の仮想マシンで、トラステッド起動を有効にすることはできません。

詳細については、「Azure Virtual Machines のトラステッド起動」を参照してください。 (関連ポリシーはありません)

重大度: 低

サポートされている Windows 仮想マシンのスケール セットに Guest Attestation 拡張機能をインストールする必要がある

説明: サポートされている仮想マシン スケール セットにゲスト構成証明拡張機能をインストールして、Microsoft Defender for Cloud が起動の整合性を事前に証明して監視できるようにします。 インストール後は、リモート構成証明を通じて、ブート整合性の構成証明が行われるようになります。 この評価が適用されるのは、トラステッド起動が有効な仮想マシン スケール セットのみです。

  • トラステッド起動を使用するには、新しい仮想マシンを作成する必要があります。
  • 最初に作成されたときにトラステッド起動が有効にされていない既存の仮想マシンで、トラステッド起動を有効にすることはできません。

詳細については、「Azure Virtual Machines のトラステッド起動」を参照してください。 (関連ポリシーはありません)

重大度: 低

Guest Attestation 拡張機能を、サポートしている Windows 仮想マシンにインストールする必要があります

説明: サポートされている仮想マシンにゲスト構成証明拡張機能をインストールして、Microsoft Defender for Cloud が起動の整合性を事前に証明して監視できるようにします。 インストール後は、リモート構成証明を通じて、ブート整合性の構成証明が行われるようになります。 この評価が適用されるのは、トラステッド起動が有効な仮想マシンのみです。

  • トラステッド起動を使用するには、新しい仮想マシンを作成する必要があります。
  • 最初に作成されたときにトラステッド起動が有効にされていない既存の仮想マシンで、トラステッド起動を有効にすることはできません。

詳細については、「Azure Virtual Machines のトラステッド起動」を参照してください。 (関連ポリシーはありません)

重大度: 低

マシンにゲスト構成拡張機能がインストールされている必要がある

説明: コンピューターのゲスト内設定のセキュリティで保護された構成を確保するには、ゲスト構成拡張機能をインストールします。 この拡張機能によって監視されるゲスト内設定には、オペレーティング システムの構成、アプリケーションの構成またはプレゼンス、環境設定が含まれます。 インストールすると、 Windows Exploit guard を有効にする必要があるなど、ゲスト内ポリシーが使用可能になります。 (関連ポリシー: 仮想マシンにはゲスト構成拡張機能) が必要です。

重大度: 中

(プレビュー): Azure Stack HCI システムでホストと VM ネットワークを保護する必要がある

説明: Azure Stack HCI ホストのネットワークと仮想マシン ネットワーク接続上のデータを保護します。 (関連ポリシー: ゲスト構成拡張機能は、マシンにインストールする必要があります - Microsoft Azure)。

重大度: 低

仮想マシンにエンドポイント保護ソリューションをインストールする

説明: エンドポイント保護ソリューションを仮想マシンにインストールして、脅威や脆弱性から保護します。 (関連ポリシー: Azure Security Center で不足している Endpoint Protection を監視する)。

重大度: 高

Linux 仮想マシンでは、Azure Disk Encryption か EncryptionAtHost を有効にする必要があります

説明: 既定では、仮想マシンの OS ディスクとデータ ディスクは、プラットフォームマネージド キーを使用して保存時に暗号化されます。一時ディスクとデータ キャッシュは暗号化されず、コンピューティング リソースとストレージ リソースの間を流れるときはデータは暗号化されません。 Azure Disk Encryption または EncryptionAtHost を使用してこのデータをすべて暗号化します。 マネージド ディスク暗号化オプションの概要で暗号化オファリングを比較してください。 このポリシーは、そのポリシー割り当てスコープに 2 つの前提条件がデプロイされている必要があります。 詳細については、「 Azure Machine Configuration の概要を参照してください。 (関連ポリシー: [プレビュー]: Linux 仮想マシンで Azure Disk Encryption または EncryptionAtHost) を有効にする必要があります。

古い推奨事項 仮想マシンでコンピューティング リソースとストレージ リソース間の一時ディスク、キャッシュ、データ フローを暗号化する必要があるを置き換えます。 推奨事項を使用すると、VM 暗号化コンプライアンスを監査できます。

重大度: 高

Linux 仮想マシンでカーネル モジュール署名の検証を強制する必要がある

説明: カーネル モードでの悪意のあるコードまたは未承認のコードの実行を軽減するには、サポートされている Linux 仮想マシンにカーネル モジュール署名の検証を適用します。 カーネル モジュール署名の検証により、信頼されたカーネル モジュールのみの実行が許可されるようになります。 この評価は、Azure Monitor エージェントがインストールされている Linux 仮想マシンにのみ適用されます。 (関連ポリシーはありません)

重大度: 低

Linux 仮想マシンでは、署名された信頼できるブート コンポーネントのみを使用する必要がある

説明: セキュア ブートが有効になっている場合、すべての OS ブート コンポーネント (ブート ローダー、カーネル、カーネル ドライバー) は、信頼された発行元によって署名されている必要があります。 Defender for Cloud によって、お客様が所有する 1 台以上の Linux マシンで信頼されていない OS ブート コンポーネントが特定されました。 悪意のある可能性のあるコンポーネントからコンピューターを保護するには、それらを許可リストに追加するか、特定されたコンポーネントを削除します。 (関連ポリシーはありません)

重大度: 低

Linux 仮想マシンではセキュア ブートを使用する必要がある

説明: マルウェアベースのルートキットとブート キットのインストールから保護するには、サポートされている Linux 仮想マシンでセキュア ブートを有効にします。 セキュア ブートにより、署名されたオペレーティング システムとドライバーのみを確実に実行できるようになります。 この評価は、Azure Monitor エージェントがインストールされている Linux 仮想マシンにのみ適用されます。 (関連ポリシーはありません)

重大度: 低

Linux ベースの Azure Arc 対応マシンに Log Analytics エージェントをインストールする必要がある

説明: Defender for Cloud では、Log Analytics エージェント (OMS とも呼ばれます) を使用して、Azure Arc マシンからセキュリティ イベントを収集します。 すべての Azure Arc マシンにエージェントをデプロイするには、修復手順に従います。 (関連ポリシーはありません)

重大度: 高

Defender for Servers では AMA と MMA の使用が段階的に廃止されるため、このようなエージェントに依存する推奨事項は削除されます。 代わりに、Defender for Servers の機能では、MMA または AMA に依存せずに、Microsoft Defender for Endpoint エージェントまたはエージェントレス スキャンが使用されます。

非推奨予定: 2024 年 7 月

Virtual Machine Scale Sets に Log Analytics エージェントをインストールする必要がある

説明: Defender for Cloud は、セキュリティの脆弱性と脅威を監視するために、Azure 仮想マシン (VM) からデータを収集します。 データは、Log Analytics エージェント (旧称 Microsoft Monitoring Agent (MMA)) を使用して収集されます。エージェントがセキュリティ関連のさまざまな構成とイベント ログをマシンから読み取り、分析のためにデータをワークスペースにコピーします。 Azure Kubernetes Service や Azure Service Fabric などの Azure 管理サービスによって VM が使用されている場合は、その手順に従う必要もあります。 Azure 仮想マシン スケール セットのためにエージェントの自動プロビジョニングを構成することはできません。 エージェントを仮想マシン スケール セット (Azure Kubernetes Service や Azure Service Fabric など、Azure 管理サービスで使用されるものを含む) にデプロイするには、修復手順の方法に従ってください。 (関連ポリシー: Log Analytics エージェントは、Azure Security Center の監視) のために仮想マシン スケール セットにインストールする必要があります。

Defender for Servers では AMA と MMA の使用が段階的に廃止されるため、このようなエージェントに依存する推奨事項は削除されます。 代わりに、Defender for Servers の機能では、MMA または AMA に依存せずに、Microsoft Defender for Endpoint エージェントまたはエージェントレス スキャンが使用されます。

非推奨予定: 2024 年 7 月

重大度: 高

仮想マシンに Log Analytics エージェントをインストールする必要がある

説明: Defender for Cloud は、セキュリティの脆弱性と脅威を監視するために、Azure 仮想マシン (VM) からデータを収集します。 データは、Log Analytics エージェント (旧称 Microsoft Monitoring Agent (MMA)) を使用して収集されます。エージェントがセキュリティ関連のさまざまな構成とイベント ログをマシンから読み取り、分析のためにデータを Log Analytics ワークスペースにコピーします。 Azure Kubernetes Service や Azure Service Fabric などの Azure 管理サービスによって VM が使用されている場合にも、このエージェントが必要になります。 自動プロビジョニングを構成して、エージェントを自動的にデプロイすることをお勧めします。 自動プロビジョニングを使用しないことを選択する場合は、修復手順の指示に従って手動でエージェントを VM にデプロイします。 (関連ポリシー: Azure Security Center の監視) のために、Log Analytics エージェントを仮想マシンにインストールする必要があります。

Defender for Servers では AMA と MMA の使用が段階的に廃止されるため、このようなエージェントに依存する推奨事項は削除されます。 代わりに、Defender for Servers の機能では、MMA または AMA に依存せずに、Microsoft Defender for Endpoint エージェントまたはエージェントレス スキャンが使用されます。

非推奨予定: 2024 年 7 月

重大度: 高

Windows ベースの Azure Arc 対応マシンに Log Analytics エージェントをインストールする必要がある

説明: Defender for Cloud では、Log Analytics エージェント (MMA とも呼ばれます) を使用して、Azure Arc マシンからセキュリティ イベントを収集します。 すべての Azure Arc マシンにエージェントをデプロイするには、修復手順に従います。 (関連ポリシーはありません)

重大度: 高

Defender for Servers では AMA と MMA の使用が段階的に廃止されるため、このようなエージェントに依存する推奨事項は削除されます。 代わりに、Defender for Servers の機能では、MMA または AMA に依存せずに、Microsoft Defender for Endpoint エージェントまたはエージェントレス スキャンが使用されます。

非推奨予定: 2024 年 7 月

マシンを安全に構成する必要がある

説明: コンピューターのセキュリティ構成の脆弱性を修復して、攻撃から保護します。 (関連ポリシー: コンピューターのセキュリティ構成の脆弱性を修復する必要があります)。

この推奨事項は、サーバーのセキュリティ体制を改善するのに役立ちます。 Defender for Cloud では、Microsoft Defender 脆弱性の管理を利用したセキュリティ ベースラインを提供することで、Center for Internet Security (CIS) ベンチマークが強化されます。 詳細情報。

重大度: 低

セキュリティ構成の更新を適用するにはマシンを再起動する必要がある

説明: セキュリティ構成の更新プログラムを適用し、脆弱性から保護するには、コンピューターを再起動します。 この評価は、Azure Monitor エージェントがインストールされている Linux 仮想マシンにのみ適用されます。 (関連ポリシーはありません)

重大度: 低

マシンに脆弱性評価ソリューションを導入する必要がある

説明: Defender for Cloud は、接続されているマシンが脆弱性評価ツールを実行していることを定期的に確認します。 脆弱性評価ソリューションをデプロイするには、この推奨事項を使用します。 (関連ポリシー: 仮想マシンで脆弱性評価ソリューションを有効にする必要があります)。

重大度: 中

マシンでは、脆弱性の検出結果が解決されている必要がある

説明: 仮想マシン上の脆弱性評価ソリューションからの結果を解決します。 (関連ポリシー: 仮想マシンで脆弱性評価ソリューションを有効にする必要があります)。

重大度: 低

仮想マシンの管理ポートは、Just-In-Time のネットワーク アクセス制御で保護する必要がある

説明: Defender for Cloud は、ネットワーク セキュリティ グループ内の管理ポートに対して、過度に制限の緩い受信規則をいくつか特定しました。 Just-In-Time のアクセス制御を有効にして、インターネットベースのブルートフォース攻撃から VM を保護します。 詳細については、「Just-In-Time (JIT) VM アクセスについて」を参照してください。 (関連ポリシー: 仮想マシンの管理ポートは、Just-In-Time ネットワーク アクセス制御) で保護する必要があります。

重大度: 高

Microsoft Defender for Servers を有効にする必要がある

説明: Microsoft Defender for servers は、サーバー ワークロードに対してリアルタイムの脅威保護を提供し、セキュリティ強化に関する推奨事項と、疑わしいアクティビティに関するアラートを生成します。 この情報を使用して、セキュリティの問題を迅速に修復し、サーバーのセキュリティを強化できます。

この推奨事項の修復によって、サーバーを保護するための料金が発生します。 このサブスクリプションにサーバーがない場合、料金は発生しません。 今後、このサブスクリプションにサーバーを作成すると、それらは自動的に保護され、その時点で料金が発生します。 詳細については、「Microsoft Defender for servers の概要」を参照してください。 (関連ポリシー: Azure Defender for servers を有効にする必要があります)。

重大度: 高

Microsoft Defender for Servers をワークスペース上で有効にする必要がある

説明: Microsoft Defender for servers は、Windows および Linux マシンの脅威検出と高度な防御を実現します。 ワークスペースではなくサブスクリプションでこの Defender プランを有効にすると、Microsoft Defender for servers の全機能に対する料金がかかりますが、一部のメリットが得られません。 ワークスペースで Microsoft Defender for servers を有効にすると、そのワークスペースに対して報告を行うすべてのマシンに対して Microsoft Defender for servers の料金が発生します (Defender プランを有効にしていないサブスクリプションであっても同様です)。 サブスクリプションで Microsoft Defender for servers も有効にしない限り、それらのマシンでは、Just-In-Time VM アクセス、適応型アプリケーション制御、Azure リソースのネットワーク検出を利用することができません。 詳細については、「Microsoft Defender for servers の概要」を参照してください。 (関連ポリシーはありません)

重大度: 中

セキュア ブートを、サポートしている Windows 仮想マシンで有効にする必要があります

説明: サポートされている Windows 仮想マシンでセキュア ブートを有効にして、ブート チェーンに対する悪意のある未承認の変更を軽減します。 有効にすると、信頼されたブートローダー、カーネル、およびカーネル ドライバーの実行のみが許可されます。 この評価が適用されるのは、トラステッド起動が有効な Windows 仮想マシンのみです。

  • トラステッド起動を使用するには、新しい仮想マシンを作成する必要があります。
  • 最初に作成されたときにトラステッド起動が有効にされていない既存の仮想マシンで、トラステッド起動を有効にすることはできません。

詳細については、「Azure Virtual Machines のトラステッド起動」を参照してください。 (関連ポリシーはありません)

重大度: 低

Service Fabric クラスターでは、ClusterProtectionLevel プロパティを EncryptAndSign に設定する必要がある

説明: Service Fabric には、プライマリ クラスター証明書を使用したノード間通信用の 3 つのレベルの保護 (None、Sign、EncryptAndSign) が用意されています。 すべてのノード間メッセージが暗号化され、デジタル署名されるように保護レベルを設定します。 (関連ポリシー: Service Fabric クラスターでは、ClusterProtectionLevel プロパティが EncryptAndSign) に設定されている必要があります。

重大度: 高

Service Fabric クラスターでは、クライアント認証に Azure Active Directory のみを使用する必要がある

説明: Service Fabric で Azure Active Directory 経由でのみクライアント認証を実行します (関連ポリシー: Service Fabric クラスターでは、クライアント認証にのみ Azure Active Directory を使用する必要があります)。

重大度: 高

仮想マシン スケール セットにシステムの更新プログラムをインストールする必要がある

説明: 不足しているシステム セキュリティと重要な更新プログラムをインストールして、Windows および Linux 仮想マシン スケール セットをセキュリティで保護します。 (関連ポリシー: 仮想マシン スケール セットのシステム更新プログラムをインストールする必要があります)。

Azure Monitor エージェント (AMA) と Log Analytics エージェント (Microsoft Monitoring Agent (MMA) とも呼ばれます) の使用が Defender for Servers で段階的に廃止されると、このようなエージェントに依存する推奨事項は削除されます。 代わりに、Defender for Servers の機能では、MMA または AMA に依存せずに、Microsoft Defender for Endpoint エージェントまたはエージェントレス スキャンが使用されます。

非推奨予定: 2024 年 7 月。 これらの推奨事項は 新しい推奨事項によって置き換。

重大度: 高

システム更新プログラムをマシンにインストールする必要がある

説明: 不足しているシステム セキュリティと重要な更新プログラムをインストールして、Windows および Linux の仮想マシンとコンピューターをセキュリティで保護します (関連ポリシー: システム更新プログラムをコンピューターにインストールする必要があります)。

Azure Monitor エージェント (AMA) と Log Analytics エージェント (Microsoft Monitoring Agent (MMA) とも呼ばれます) の使用が Defender for Servers で段階的に廃止されると、このようなエージェントに依存する推奨事項は削除されます。 代わりに、Defender for Servers の機能では、MMA または AMA に依存せずに、Microsoft Defender for Endpoint エージェントまたはエージェントレス スキャンが使用されます。

非推奨予定: 2024 年 7 月。 これらの推奨事項は 新しい推奨事項によって置き換。

重大度: 高

システム更新プログラムをマシンにインストールする必要がある (更新センターを利用)

説明: コンピューターにシステム、セキュリティ、および重要な更新プログラムがありません。 多くの場合、ソフトウェア更新プログラムには、セキュリティ ホールに対する重要なパッチが含まれています。 このようなホールはマルウェア攻撃で頻繁に悪用されるため、ソフトウェアを最新の状態に保つことが不可欠です。 未処理のパッチをすべてインストールし、マシンをセキュリティで保護するには、修復手順に従います。 (関連ポリシーはありません)

重大度: 高

仮想マシンおよび仮想マシン スケール セットでは、ホストでの暗号化が有効になっている必要がある

説明: ホストでの暗号化を使用して、仮想マシンと仮想マシン スケール セット データのエンドツーエンドの暗号化を取得します。 ホストでの暗号化を使用すると、一時ディスクと OS およびデータ ディスクのキャッシュの保存時の暗号化が有効になります。 ホストでの暗号化が有効になっている場合、一時およびエフェメラル OS ディスクはプラットフォーム マネージド キーを使用して暗号化されます。 OS とデータ ディスクのキャッシュは、ディスクで選択された暗号化の種類に応じて、カスタマー マネージドまたはプラットフォーム マネージド キーのいずれかを使用して保存時に暗号化されます。 詳細については、「 Azure portal を使用して、ホストでの暗号化を使用してエンドツーエンドの暗号化を有効にするを参照してください。 (関連ポリシー: 仮想マシンおよび仮想マシン スケール セットでは、ホストでの暗号化が有効になっている必要がある)。

重大度: 中

仮想マシンを新しい Azure Resource Manager リソースに移行する必要がある

説明: 仮想マシン (クラシック) は非推奨となり、これらの VM は Azure Resource Manager に移行する必要があります。 Azure Resource Manager には現在、完全な IaaS 機能とその他の強化機能が含まれるため、2020 年 2 月 28 日に Azure Service Manager (ASM) を介した IaaS 仮想マシン (VM) の管理を非推奨にしました。 この機能は、2023 年 3 月 1 日に完全に廃止される予定です。

影響を受けるすべてのクラシック VM を表示するには、[ディレクトリ + サブスクリプション] タブですべての Azure サブスクリプションを選択してください。

このツールに関する利用可能なリソースと情報と移行: 仮想マシン (クラシック) の廃止の概要、移行のステップ バイ ステップ プロセス、利用可能な Microsoft リソース。Azure Resource Manager 移行ツールへの移行の詳細.PowerShell. を使用して Azure Resource Manager 移行ツールに移行する(関連ポリシー: 仮想マシンは、新しい Azure Resource Manager リソース) に移行する必要があります。

重大度: 高

仮想マシンのゲスト構成証明の状態は正常である必要がある

説明: ゲスト構成証明は、信頼されたログ (TCGLog) を構成証明サーバーに送信することによって実行されます。 このサーバーでこれらのログが使用されて、ブート コンポーネントが信頼できるかどうかが判断されます。 この評価は、ブート チェーンの侵害を検出することを目的としています。これは、 bootkit または rootkit 感染の結果である可能性があります。 この評価は、ゲスト構成証明の拡張機能がインストールされている、トラステッド起動が有効な仮想マシンのみに適用されます。 (関連ポリシーはありません)

重大度: 中

仮想マシンのゲスト構成拡張機能はシステム割り当てマネージド ID を使用してデプロイする必要がある

説明: ゲスト構成拡張機能には、システム割り当てマネージド ID が必要です。 このポリシーのスコープ内の Azure 仮想マシンは、ゲスト構成拡張機能がインストールされていても、システム割り当てマネージド ID がなければ非準拠になります。 詳細情報 (関連ポリシー: Guest Configuration 拡張機能は、システム割り当てマネージド ID を使用して Azure 仮想マシンにデプロイする必要があります)。

重大度: 中

Virtual Machine Scale Sets を安全に構成する必要がある

説明: 仮想マシン スケール セットでは、脆弱性を修復して攻撃から保護します。 (関連ポリシー: 仮想マシン スケール セットのセキュリティ構成の脆弱性を修復する必要があります)。

重大度: 高

コンピューティングとストレージのリソース間で一時ディスク、キャッシュ、データ フローを仮想マシンによって暗号化する必要がある

説明: 既定では、仮想マシンの OS ディスクとデータ ディスクは、プラットフォームマネージド キーを使用して保存時に暗号化されます。一時ディスクとデータ キャッシュは暗号化されず、コンピューティング リソースとストレージ リソースの間を流れるときはデータは暗号化されません。 Azure でのさまざまなディスク暗号化テクノロジの比較については、「マネージド ディスク暗号化オプションの概要」を参照してください。 Azure Disk Encryption を使用してこのデータをすべて暗号化します。 次のような場合は、この推奨事項を無視してください。

ホスト側暗号化機能を使用しているか、Managed Disks のサーバー側暗号化がセキュリティ要件を満たしています。 詳細については、Azure Disk Storage の サーバー側の暗号化に関するページを参照してください。

(関連ポリシー:仮想マシンにディスク暗号化を適用する必要がある)

重大度: 高

vTPM を、サポートしている仮想マシンで有効にする必要があります

説明: サポートされている仮想マシンで仮想 TPM デバイスを有効にして、TPM を必要とするメジャー ブートやその他の OS セキュリティ機能を容易にします。 有効にすると、vTPM を使用してブート整合性の構成証明を行うことができます。 この評価が適用されるのは、トラステッド起動が有効な仮想マシンのみです。

  • トラステッド起動を使用するには、新しい仮想マシンを作成する必要があります。
  • 最初に作成されたときにトラステッド起動が有効にされていない既存の仮想マシンで、トラステッド起動を有効にすることはできません。

詳細については、「Azure Virtual Machines のトラステッド起動」を参照してください。 (関連ポリシーはありません)

重大度: 低

Linux マシンのセキュリティ構成の脆弱性を修復する必要がある (Powered by ゲスト構成)

説明: Linux マシンのセキュリティ構成の脆弱性を修復して、攻撃から保護します。 (関連ポリシー: Linux マシンは、Azure セキュリティ ベースライン) の要件を満たしている必要があります。

重大度: 低

Windows マシンのセキュリティ構成の脆弱性を修復する必要がある (Powered by ゲスト構成)

説明: Windows マシンのセキュリティ構成の脆弱性を修復して、攻撃から保護します。 (関連ポリシーはありません)

重大度: 低

マシンで Windows Defender Exploit Guard を有効にする必要がある

説明: Windows Defender Exploit Guard は、Azure Policy ゲスト構成エージェントを使用します。 Exploit Guard には、さまざまな攻撃ベクトルに対してデバイスをロックダウンし、マルウェア攻撃でよく使用される動作をブロックするよう設計された 4 つのコンポーネントがありますが、企業がセキュリティ リスクと生産性の要件のバランスをとれるようになっています (Windows のみ)。 (関連ポリシー: Windows Defender Exploit Guard が有効になっていない Windows マシンを監査する)。

重大度: 中

Windows 仮想マシンでは、Azure Disk Encryption か EncryptionAtHost を有効にする必要があります

説明: 既定では、仮想マシンの OS ディスクとデータ ディスクは、プラットフォームマネージド キーを使用して保存時に暗号化されます。一時ディスクとデータ キャッシュは暗号化されず、コンピューティング リソースとストレージ リソースの間を流れるときはデータは暗号化されません。 Azure Disk Encryption または EncryptionAtHost を使用してこのデータをすべて暗号化します。 マネージド ディスク暗号化オプションの概要で暗号化オファリングを比較してください。 このポリシーは、そのポリシー割り当てスコープに 2 つの前提条件がデプロイされている必要があります。 詳細については、「 Azure Machine Configuration の概要を参照してください。 (関連ポリシー: [プレビュー]: Windows 仮想マシンで Azure Disk Encryption または EncryptionAtHost) を有効にする必要があります。

古い推奨事項を置き換えます。仮想マシンは、コンピューティング リソースとストレージ リソース間の一時ディスク、キャッシュ、データ フローを暗号化する必要があります。 推奨事項を使用すると、VM 暗号化コンプライアンスを監査できます。

重大度: 高

Windows Web サーバーはセキュリティで保護された通信プロトコルを使用するように構成される必要がある

説明: インターネット経由で通信される情報のプライバシーを保護するには、Web サーバーで業界標準の暗号化プロトコルであるトランスポート層セキュリティ (TLS) の最新バージョンを使用する必要があります。 TLS によって、セキュリティ証明書を使用してマシン間の接続が暗号化されることにより、ネットワーク経由の通信がセキュリティで保護されます。 (関連ポリシー: セキュリティで保護された通信プロトコルを使用していない Windows Web サーバーを監査する)。

重大度: 高

AWS コンピューティングの推奨事項

Systems Manager によって管理されている Amazon EC2 インスタンスでは、パッチのインストール後のパッチ コンプライアンス状態が COMPLIANT である必要がある

説明: このコントロールは、Amazon EC2 Systems Manager パッチコンプライアンスのコンプライアンスステータスが、インスタンスへのパッチのインストール後に準拠しているかNON_COMPLIANTかをチェックします。 AWS Systems Manager Patch Manager によって管理されているインスタンスのみがチェックされます。 PCI DSS 要件 '6.2' で規定されている 30 日間の制限内でパッチが適用されたかどうかは確認されません。 また、適用されたパッチがセキュリティ パッチとして分類されたかどうかも検証されません。 適切なベースライン設定に従いパッチ グループを作成し、Systems Manager で、スコープ内システムがそれらのパッチ グループによって管理されていることを確認する必要があります。 パッチ グループの詳細については、「 AWS Systems Manager ユーザー ガイドを参照してください。

重大度: 中

AWS KMS を使用して保存時にファイル データを暗号化するように Amazon EFS を構成する必要がある

説明: このコントロールは、Amazon Elastic File System が AWS KMS を使用してファイル データを暗号化するように構成されているかどうかを確認します。 このチェックは、DescribeFileSystems 応答で *"Encrypted" が "false" に設定されている場合に失敗します。 DescribeFileSystems 応答の "KmsKeyId" キーが、efs-encrypted-check の KmsKeyId パラメーターと一致しません。 このコントロールでは、 efs-encrypted-check に "KmsKeyId" パラメーターは使用されません。 "Encrypted" の値のみがチェックされます。 Amazon EFS 内の機密データに追加されたセキュリティ層に対しては、暗号化されたファイル システムを作成する必要があります。 Amazon EFS は、ファイル システム保存時の暗号化をサポートしています。 Amazon EFS ファイル システムを作成するときに、保存データの暗号化を有効にすることができます。 Amazon EFS の暗号化の詳細については、Amazon Elastic File System ユーザー ガイドの「Data encryption in Amazon EFS」 (Amazon EFS でのデータ暗号化) を参照してください。

重大度: 中

Amazon EFS ボリュームは、バックアップ プランに含まれている必要がある

説明: このコントロールは、Amazon Elastic File System (Amazon EFS) ファイルシステムが AWS Backup のバックアップ計画に追加されるかどうかを確認します。 Amazon EFS ファイルシステムがバックアッププランに含まれていない場合、コントロールは失敗します。 EFS ファイル システムをバックアップ プランに含めておくと、データが削除されたり、データ損失したりしないよう、データが保護されます。

重大度: 中

Application Load Balancer の削除の防止は、有効にする必要がある

説明: このコントロールは、Application Load Balancer で削除保護が有効になっているかどうかを確認します。 削除保護が構成されていない場合、コントロールは失敗します。 Application Load Balancer が削除されないように保護するには、削除の防止を有効にしてください。

重大度: 中

ロード バランサーに関連付けられている Auto Scaling グループでは、正常性チェックを使用する必要がある

説明: ロード バランサーに関連付けられている自動スケーリング グループは、エラスティック負荷分散の正常性チェックを使用しています。 PCI DSS では、負荷分散や高可用性の構成は必要ありません。 これは、AWS のベスト プラクティスで推奨されています。

重大度: 低

AWS アカウントでは、Azure Arc 自動プロビジョニングを有効にする必要がある

説明: Microsoft Defender for servers からのセキュリティ コンテンツを完全に可視化するには、EC2 インスタンスを Azure Arc に接続する必要があります。対象となるすべての EC2 インスタンスが Azure Arc を自動的に受信できるようにするには、AWS アカウント レベルで Defender for Cloud からの自動プロビジョニングを有効にします。 詳細については、Azure Arc と Microsoft Defender for server に関する各ページを参照してください。

重大度: 高

CloudFront ディストリビューションでは、オリジン フェールオーバーを構成する必要がある

説明: このコントロールは、Amazon CloudFront ディストリビューションが 2 つ以上の配信元を持つ配信元グループで構成されているかどうかを確認します。 CloudFront オリジン フェールオーバーを使用すると、可用性が向上します。 プライマリ オリジンが使用できないか、特定の HTTP 応答状態コードを返す場合、オリジン フェールオーバーによって、トラフィックがセカンダリ オリジンに自動的にリダイレクトされます。

重大度: 中

CodeBuild GitHub または Bitbucket ソース リポジトリの URL には、OAuth を使用する必要がある

説明: このコントロールは、GitHub または Bitbucket ソース リポジトリの URL に個人用アクセス トークンまたはユーザー名とパスワードが含まれているかどうかを確認します。 認証資格情報は、クリア テキストで保存または送信したり、リポジトリの URL で表示したりしないてください。 個人用アクセス トークンまたはユーザー名とパスワードの代わりに OAuth を使用して、GitHub または Bitbucket のリポジトリにアクセスするための承認を付与する必要があります。 個人用アクセス トークンまたはユーザー名とパスワードを使用すると、資格情報が意図せず公開されたり、不正アクセスを受けたりする可能性があります。

重大度: 高

CodeBuild プロジェクト環境変数には、資格情報を含めることができない

説明: このコントロールは、プロジェクトに環境変数 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEYが含まれているかどうかを確認します。 データが意図せず公開されたり、不正アクセスを受けたりする原因となる可能性があるため、認証資格情報 AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY は、クリア テキストで保存しないでください。

重大度: 高

DynamoDB Accelerator (DAX) クラスターは、保存時に暗号化する必要がある

説明: このコントロールは、DAX クラスターが保存時に暗号化されているかどうかを確認します。 保存データを暗号化すると、AWS で認証されていないユーザーがアクセスしているディスクにデータが格納されるリスクが軽減されます。 暗号化により、アクセス制御が強化され、未承認ユーザーによるデータへのアクセスが制限されます。 たとえば、データの暗号化を解除して読み取り可能にするには、API のアクセス許可が必要となります。

重大度: 中

DynamoDB テーブルでは、必要に応じて自動的に容量をスケーリングする必要がある

説明: このコントロールは、Amazon DynamoDB テーブルが必要に応じて読み取りと書き込みの容量をスケーリングできるかどうかを確認します。 このコントロールは、テーブルに、オンデマンド容量モードまたはプロビジョニング済みモードのいずれかが使用されており、自動スケーリングが構成されている場合に合格します。 必要に応じて容量をスケーリングすることで、スロットリングの例外が回避され、アプリケーションの可用性を維持しやすくなります。

重大度: 中

EC2 インスタンスは、Azure Arc に接続する必要がある

説明: Microsoft Defender for Servers のセキュリティ コンテンツを完全に可視化するために、EC2 インスタンスを Azure Arc に接続します。 詳細については、ハイブリッドクラウド環境の Azure Arc と Microsoft Defender for Servers に関する各記事を参照してください。

重大度: 高

EC2 インスタンスは、AWS Systems Manager で管理する必要がある

説明: Amazon EC2 Systems Manager パッチコンプライアンスの状態は、インスタンスへのパッチのインストール後に 'COMPLIANT' または 'NON_COMPLIANT' になります。 AWS Systems Manager Patch Manager によって管理されているインスタンスのみがチェックされます。 PCI DSS 要件 '6' で規定されている 30 日間の制限内で適用されたパッチはチェックされません。

重大度: 中

EDR 構成の問題を EC2 上で解決する必要がある

説明: 最新の脅威と脆弱性から仮想マシンを保護するには、インストールされているエンドポイント検出と応答 (EDR) ソリューションで特定されたすべての構成の問題を解決します。 現時点では、この推奨事項は、Microsoft Defender for Endpoint が有効になっているリソースにのみ適用されます。

このエージェントレス エンドポイントの推奨事項は、Defender for Servers プラン 2 または Defender CSPM プランがある場合に使用できます。 詳細については エージェントレス エンドポイント保護の推奨事項に関するページを参照してください。

重大度: 高

EDR ソリューションを EC2 にインストールする必要がある

説明: EC2 を保護するには、エンドポイント検出と応答 (EDR) ソリューションをインストールします。 EDR は、高度な脅威の防止、検出、調査、対応に役立ちます。 Microsoft Defender for Servers を使用して、Microsoft Defender for Endpoint をデプロイします。 リソースが "異常" として分類されている場合、サポートされている EDR ソリューションはインストールされていません。 この推奨事項では検出できない EDR ソリューションがインストールされている場合は、除外することができます。

このエージェントレス エンドポイントの推奨事項は、Defender for Servers プラン 2 または Defender CSPM プランがある場合に使用できます。 詳細については エージェントレス エンドポイント保護の推奨事項に関するページを参照してください。

重大度: 高

Systems Manager によって管理されているインスタンスの関連付けコンプライアンス状態は、COMPLIANT である必要がある

説明: このコントロールは、インスタンスで関連付けが実行された後に、AWS Systems Manager の関連付けコンプライアンスの状態が準拠しているか、NON_COMPLIANTであるかをチェックします。 関連付けコンプライアンス状態が COMPLIANT の場合、コントロールは合格です。 State Manager の関連付けは、マネージド インスタンスに割り当てられた構成です。 この構成によって、インスタンス上で維持する必要がある状態が定義されます。 たとえば、関連付けを使用すると、ウイルス対策ソフトウェアをインストールしてインスタンス上で実行するように指定したり、特定のポートを閉じるように指定したりすることができます。 State Manager の関連付けを 1 つ以上作成すると、コンソール内や AWS CLI コマンドへの応答内で、または Systems Manager API 操作に対応して、コンプライアンス状態情報が即座に使用可能となります。 関連付けの場合、"構成" コンプライアンスには、準拠または非準拠の状態と、関連付けに割り当てられた重大度レベル ( Critical Mediumなど) が表示されます。 State Manager の関連付けのコンプライアンスの詳細については、「AWS Systems Manager ユーザー ガイド」の「 ステートマネージャーの関連付けのコンプライアンス について」を参照してください。 Systems Manager の関連付けに対して、スコープ内 EC2 インスタンスを構成する必要があります。 また、パッチのベンダーのセキュリティ評価のパッチ ベースラインを構成し、PCI DSS 3.2.1 要件を満たすように自動適用日 6.2を設定する必要があります。 関連付けを作成 方法の詳細については AWS Systems Manager ユーザー ガイドの「関連付けを作成する」を参照してください。 Systems Manager でのパッチ適用の操作の詳細については、AWS Systems Manager ユーザー ガイドの「 AWS Systems Manager Patch Manager を参照してください。

重大度: 低

Lambda 関数には、配信不能キューが構成されている必要がある

説明: このコントロールは、Lambda 関数が配信不能キューで構成されているかどうかを確認します。 このコントロールは、Lambda 関数に配信不能キューが構成されていない場合に失敗します。 失敗した場合の代替の宛先には、配信不能キューを含む関数を構成して、破棄されたイベントを保存して、さらに処理を行います。 配信不能キューは、失敗した場合の宛先での役割と同じ役割を果たします。 これは、イベントがすべての処理試行に失敗した場合、または処理されることなく期限切れになった場合に使用されます。 配信不能キューを使用すると、Lambda 関数のエラーまたは失敗した要求を振り返り、異常な動作をデバッグまたは特定することができます。 セキュリティの観点からは、関数が失敗した理由を把握することや、関数によってデータが削除されたり、データ セキュリティの侵害が発生したりする結果とならないようにすることが重要です。 たとえば、関数で、基になるリソースと通信できない場合は、ネットワークのどこかでサービス拒否 (DoS) 攻撃が発生している兆候を示している可能性があります。

重大度: 中

Lambda 関数では、サポートされているランタイムを使用する必要がある

説明: このコントロールは、ランタイムの Lambda 関数の設定が、各言語でサポートされているランタイムに対して設定された予期される値と一致することを確認します。 このコントロールは、 nodejs14.x、 nodejs12.x、 nodejs10.x、 python3.8、 python3.7、 python3.6、 ruby2.7、 ruby2.5、 java11、 java8、 java8.al2、 go1.x、 dotnetcore3.1、 dotnetcore2.1Lambda ランタイム は、メンテナンスとセキュリティ更新プログラムの対象となるオペレーティング システム、プログラミング言語、およびソフトウェア ライブラリの組み合わせを中心に構築されています。 ランタイム コンポーネントがセキュリティ更新プログラムでサポートされなくなった場合、ランタイムは、Lambda によって非推奨になります。 非推奨のランタイムを使用する関数を作成することはできませんが、関数は呼び出しイベントを処理するために引き続き使用できます。 Lambda 関数が最新であり、古いランタイム環境を使用していないことを確認します。 このコントロールを使用してサポートされている言語があるかどうかをチェックする対象となる、サポートされているランタイムの詳細については、AWS Lambda 開発者ガイドで AWS Lambda ランタイムに関するページを参照してください。

重大度: 中

Just-In-Time ネットワーク アクセス制御を使用して、EC2 インスタンスの管理ポートを保護する必要がある

説明: Microsoft Defender for Cloud では、ネットワーク内の管理ポートの受信規則が過度に制限されていることを確認しました。 Just-In-Time アクセス制御を有効にして、インターネットベースのブルートフォース攻撃からインスタンスを保護します。 詳細情報。

重大度: 高

使用されていない EC2 セキュリティ グループは、削除する必要がある

説明: セキュリティ グループは、Amazon EC2 インスタンスまたは ENI にアタッチする必要があります。 正常な結果は、未使用の Amazon EC2 セキュリティグループがあることを示している可能性があります。

重大度: 低

GCP コンピューティングに関する推奨事項

コンピューティング エンジン VM では Container-Optimized OS を使用する必要があります

説明: この推奨事項は、キーと値のペア 'imageType': 'COS' のノード プールの構成プロパティを評価します。

重大度: 低

EDR 構成の問題を GCP 仮想マシン上で解決する必要がある

説明: 最新の脅威と脆弱性から仮想マシンを保護するには、インストールされているエンドポイント検出と応答 (EDR) ソリューションで特定されたすべての構成の問題を解決します。 現時点では、この推奨事項は、Microsoft Defender for Endpoint が有効になっているリソースにのみ適用されます。

このエージェントレス エンドポイントの推奨事項は、Defender for Servers プラン 2 または Defender CSPM プランがある場合に使用できます。 詳細については エージェントレス エンドポイント保護の推奨事項に関するページを参照してください。

重大度: 高

EDR ソリューションを GCP Virtual Machines にインストールする必要がある

説明: 仮想マシンを保護するには、エンドポイント検出と応答 (EDR) ソリューションをインストールします。 EDR は、高度な脅威の防止、検出、調査、対応に役立ちます。 Microsoft Defender for Servers を使用して、Microsoft Defender for Endpoint をデプロイします。 リソースが "異常" として分類されている場合、サポートされている EDR ソリューションはインストールされていません。 この推奨事項では検出できない EDR ソリューションがインストールされている場合は、除外することができます。

このエージェントレス エンドポイントの推奨事項は、Defender for Servers プラン 2 または Defender CSPM プランがある場合に使用できます。 詳細については エージェントレス エンドポイント保護の推奨事項に関するページを参照してください。

重大度: 高

VM インスタンスで [プロジェクト全体の SSH 認証鍵をブロック] が有効になっていることを確認する

説明: 共通または共有のプロジェクト全体の SSH キーを使用してインスタンスにアクセスするのではなく、インスタンス固有の SSH キーを使用することをお勧めします。 プロジェクト全体の SSH キーは、Compute/Project-meta-data に格納されます。 プロジェクト全体の SSH キーを使用して、プロジェクト内のすべてのインスタンスにログインできます。 プロジェクト全体の SSH キーを使用すると、SSH キーの管理が容易になりますが、侵害された場合は、プロジェクト内のすべてのインスタンスに影響を与える可能性のあるセキュリティ リスクが生じます。 SSH キーが侵害された場合に攻撃対象領域を制限できるインスタンス固有の SSH キーを使用することをお勧めします。

重大度: 中

シールドされた VM が有効な状態でコンピューティング インスタンスが起動されていることを確認する

説明: 高度な脅威から保護し、VM 上のブート ローダーとファームウェアが署名され、アンアンペアされていることを確認するには、シールドされた VM を有効にしてコンピューティング インスタンスを起動することをお勧めします。 シールドされた VM は、 rootkits や bootkitsに対する防御に役立つ一連のセキュリティ 制御によって強化された Google Cloud Platform 上の VM です。 シールドされた VM によって、コンピューティング エンジン VM インスタンスの検証可能な整合性が提供されるため、ユーザーはブート レベルまたはカーネル レベルのマルウェアやルートキットによってインスタンスが侵害されていないことを確信することができます。 シールドされた VM の検証可能な整合性は、セキュア ブート、仮想トラステッド プラットフォーム モジュール (vTPM) 対応のメジャー ブート、および整合性の監視を使用して実現されます。 シールドされた VM インスタンスは、Google の証明機関を使用して署名および検証されたファームウェアを実行し、インスタンスのファームウェアが変更されていないことを確認し、セキュア ブートの信頼のルートを確立します。 整合性の監視は、VM インスタンスの状態を理解して決定するのに役立ち、シールドされた VM の vTPM では、整合性ポリシー ベースラインと呼ばれる既知の適切なブート ベースラインを作成するために必要な測定を実行することによって、メジャー ブートが有効になります。 整合性ポリシー ベースラインは、後続の VM ブートからの測定値と比較して、何かが変更されたかどうかを判断するために使用されます。 セキュア ブートは、すべてのブート コンポーネントのデジタル署名を確認し、署名の検証が失敗した場合にブート プロセスを停止することで、本物のソフトウェアのみがシステムで実行されることを保証するのに役立ちます。

重大度: 高

[シリアル ポート接続を有効化] が VM インスタンスで有効になっていないことを確認する

説明: シリアル ポートとの対話は、多くの場合、シリアル コンソールと呼ばれます。これはターミナル ウィンドウの使用と似ていますが、入力と出力は完全にテキスト モードであり、グラフィカル インターフェイスやマウスサポートはありません。 あるインスタンスの対話型シリアル コンソールを有効にした場合、クライアントは任意の IP アドレスからそのインスタンスへの接続を試みることができます。 そのため、対話型シリアル コンソールのサポートを無効にする必要があります。 仮想マシン インスタンスには、4 つの仮想シリアル ポートがあります。 シリアル ポートとの対話はターミナル ウィンドウの使用と似ていますが、入力と出力は完全にテキスト モードであり、グラフィカル インターフェイスやマウスのサポートはありません。 インスタンスのオペレーティング システム、BIOS、およびその他のシステム レベルのエンティティでは、多くの場合、シリアル ポートに出力を書き込み、コマンドやプロンプトへの応答などの入力を受け付けることができます。 通常、これらのシステム レベルのエンティティは最初のシリアル ポート (ポート 1) を使用し、シリアル ポート 1 はシリアル コンソールと呼ばれることがよくあります。 対話型シリアル コンソールでは、IP 許可リストなどの IP ベースのアクセス制限はサポートされていません。 あるインスタンスの対話型シリアル コンソールを有効にした場合、クライアントは任意の IP アドレスからそのインスタンスへの接続を試みることができます。 これにより、正しい SSH キー、ユーザー名、プロジェクト ID、ゾーン、インスタンス名がわかっている場合は、誰でもそのインスタンスに接続できます。 そのため、対話型シリアル コンソールのサポートを無効にする必要があります。

重大度: 中

Cloud SQL PostgreSQL インスタンスの 'log_duration' データベース フラグが 'on' に設定されていることを確認する

説明: log_hostname設定を有効にすると、完了した各ステートメントの期間がログに記録されます。 これにより、クエリのテキストはログに記録されないため、log_min_duration_statement フラグとは異なる動作になります。 このパラメーターは、セッションの開始後に変更することはできません。 クエリの実行に要する時間を監視することは、リソース占有クエリを特定し、サーバーのパフォーマンスを評価する上で重要な場合があります。 サーバーのパフォーマンスと安定性を確保するために、負荷分散や最適化されたクエリの使用などの追加の手順を実行できます。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

Cloud SQL PostgreSQL インスタンスの 'log_executor_stats' データベース フラグが 'off' に設定されていることを確認する

説明: PostgreSQL Executor は、PostgreSQL Planner によって引き継がれたプランを実行する役割を担います。 Executor は、プランを再帰的に処理して、必要な一連の行を抽出します。 "log_executor_stats" フラグは、各クエリの PostgreSQL ログに PostgreSQL Executor パフォーマンス統計を含めることを制御します。 "log_executor_stats" フラグを使用すると、PostgreSQL Executor のパフォーマンス統計をログに記録するための粗いプロファイリング方法が可能になります。トラブルシューティングに役立つ場合でも、ログの数が大幅に増加し、パフォーマンスのオーバーヘッドが発生する可能性があります。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

Cloud SQL PostgreSQL インスタンスの 'log_min_error_statement' データベース フラグが 'Error' 以上の厳格さに設定されていることを確認する

説明: "log_min_error_statement" フラグは、エラー ステートメントと見なされる最小メッセージ重大度レベルを定義します。 エラー ステートメントのメッセージは、SQL ステートメントと共にログに記録されます。 有効な値には、"DEBUG5"、"DEBUG4"、"DEBUG3"、"DEBUG2"、"DEBUG1"、"INFO"、"NOTICE"、"WARNING"、"ERROR"、"LOG"、"FATAL"、"PANIC" などがあります。各重大度レベルには、上記の後続のレベルが含まれます。 ERROR 以上の値が設定されていることを確認します。 監査は、運用上の問題のトラブルシューティングに役立ち、フォレンジック分析も可能です。 "log_min_error_statement" が正しい値に設定されていない場合、メッセージがエラー メッセージとして適切に分類されない可能性があります。 一般的なログ メッセージをエラー メッセージとして考慮することは、実際のエラーを見つけるのが難しく、エラー メッセージが実際のエラーをスキップして SQL ステートメントをログに記録する可能性があるため、重大度レベルを厳しくすることを検討することは困難です。 "log_min_error_statement" フラグは、"ERROR" 以上に設定する必要があります。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

Cloud SQL PostgreSQL インスタンスの 'log_parser_stats' データベース フラグが 'off' に設定されていることを確認する

説明: PostgreSQL Planner/オプティマイザーは、サーバーが受信した各クエリの構文を解析して検証する役割を担います。 構文が正しい場合は "解析ツリー" が構築され、それ以外の場合はエラーが生成されます。 "log_parser_stats" フラグは、各クエリの PostgreSQL ログにパーサー パフォーマンス統計を含めることを制御します。 "log_parser_stats" フラグを使用すると、パーサーのパフォーマンス統計をログに記録するための粗いプロファイリング方法が可能になります。これはトラブルシューティングに役立ちますが、ログの数が大幅に増加し、パフォーマンスのオーバーヘッドが発生する可能性があります。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

Cloud SQL PostgreSQL インスタンスの 'log_planner_stats' データベース フラグが 'off' に設定されていることを確認する

説明: 同じ SQL クエリを複数の方法で実行しても、異なる結果を生成できます。 PostgreSQL プランナー/オプティマイザーは、各クエリの最適な実行プランを作成する役割を担います。 "log_planner_stats" フラグは、各クエリの PostgreSQL ログに PostgreSQL プランナー パフォーマンス統計を含めることを制御します。 "log_planner_stats" フラグを使用すると、PostgreSQL Planner のパフォーマンス統計をログに記録するための粗いプロファイリング方法が可能になります。トラブルシューティングには役立ちますが、ログの数が大幅に増加し、パフォーマンスのオーバーヘッドが発生する可能性があります。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

Cloud SQL PostgreSQL インスタンスの 'log_statement_stats' データベース フラグが 'off' に設定されていることを確認する

説明: "log_statement_stats" フラグは、各クエリの PostgreSQL ログに SQL クエリのエンド ツー エンドのパフォーマンス統計を含めることを制御します。 これは、他のモジュール統計 (log_parser_stats、 log_planner_stats、 log_executor_stats) では有効にできません。 "log_statement_stats" フラグを使用すると、SQL クエリのエンド ツー エンドのパフォーマンス統計をログに記録するための粗いプロファイリング方法が可能になります。 これはトラブルシューティングに役立ちますが、ログの数が大幅に増え、パフォーマンスのオーバーヘッドが発生する可能性があります。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

コンピューティング インスタンスにパブリック IP アドレスが含まれていないことを確認する

説明: コンピューティング インスタンスは、外部 IP アドレスを持つよう構成しないでください。 攻撃対象領域を減らすには、コンピューティング インスタンスにパブリック IP アドレスを含めることはできません。 代わりに、インスタンスのインターネットへの露出を最小限とするために、ロード バランサーの背後でインスタンスを構成する必要があります。 GKE によって作成されたインスタンスの一部は外部 IP アドレスを持ち、インスタンス設定を編集して変更できないため、除外する必要があります。 これらの VM には、 gke- で始まる名前があり、 goog-gke-nodeラベルが付けられます。

重大度: 高

インスタンスが既定のサービス アカウントを使用するように構成されていないことを確認する

説明: プロジェクトにエディター ロールがあるため、既定のコンピューティング エンジン サービス アカウントを使用しないようにインスタンスを構成することをお勧めします。 既定のコンピューティング エンジン サービス アカウントにはプロジェクトの編集者ロールがあり、ほとんどの Google Cloud Services の読み取りおよび書き込みアクセスが許可されます。 VM が侵害された場合に特権エスカレーションから保護し、攻撃者がすべてのプロジェクトにアクセスできないようにするには、既定のコンピューティング エンジン サービス アカウントを使用しないことをお勧めします。 代わりに、新しいサービス アカウントを作成し、インスタンスに必要なアクセス許可のみを割り当てる必要があります。 既定のコンピューティング エンジン サービス アカウントには、 [PROJECT_NUMBER]- compute@developer.gserviceaccount.comという名前が付けられます。 GKE によって作成された VM は除外する必要があります。 これらの VM には、 gke- で始まる名前があり、 goog-gke-nodeラベルが付けられます。

重大度: 高

インスタンスが、すべてのクラウド API へのフル アクセスを持つ既定のサービス アカウントを使用するよう構成されていないことを確認します

説明: 最小限の特権の原則をサポートし、潜在的な特権エスカレーションを防ぐために、インスタンスが既定のサービス アカウント "コンピューティング エンジンの既定のサービス アカウント" に割り当てられないようにし、スコープ "すべてのクラウド API へのフル アクセスを許可する" ことをお勧めします。必要に応じて、ユーザーが管理するカスタム サービス アカウントを作成、管理、使用する機能に加えて、Google コンピューティング エンジンは、インスタンスが必要なクラウド サービスにアクセスするための既定のサービス アカウント "コンピューティング エンジンの既定のサービス アカウント" を提供します。

"プロジェクト エディター" ロールは "コンピューティング エンジンの既定のサービス アカウント" に割り当てられるため、このサービス アカウントには、課金を除くすべてのクラウド サービスに対するほぼすべての機能があります。 ただし、インスタンスに割り当てられた "コンピューティング エンジンの既定のサービス アカウント" は、3 つのスコープで動作できます。

  • 既定のアクセスを許可する: インスタンスの実行に必要な最小限のアクセスのみを許可します (最小特権)。
  • すべてのクラウド API へのフル アクセスを許可する: すべてのクラウド API/サービスへのフル アクセスを許可します (アクセスが多すぎます)。
  • 各 API のアクセスを設定する: インスタンス管理者は、インスタンスで期待される特定のビジネス機能を実行するために必要な API のみを選択できます。

インスタンスにアクセスするユーザーに割り当てられた IAM ロールに基づいて、スコープ "すべてのクラウド API へのフル アクセスを許可する" を持つ "コンピューティング エンジンの既定のサービス アカウント" でインスタンスが構成されている場合、ユーザーが実行しないクラウド操作/API 呼び出しを実行でき、特権エスカレーションが成功する可能性があります。

GKE によって作成された VM は除外する必要があります。 これらの VM には、 gke- で始まる名前があり、 goog-gke-nodeラベルが付けられます。

重大度: 中

インスタンスで IP 転送が有効になっていないことを確認する

説明: パケットの送信元 IP アドレスがインスタンスの IP アドレスと一致しない限り、コンピューティング エンジン インスタンスはパケットを転送できません。 同様に、GCP では、パケットを受信するインスタンスの IP アドレスとは異なる宛先 IP アドレスを持つパケットは配信されません。 ただし、パケットのルーティングにインスタンスを使用する場合は、両方の機能が必要です。 データ損失や情報漏えいを防ぐために、データ パケットの転送を無効にする必要があります。 コンピューティング エンジン インスタンスは、パケットの送信元 IP アドレスがインスタンスの IP アドレスと一致しない限り、パケットを転送できません。 同様に、GCP では、パケットを受信するインスタンスの IP アドレスとは異なる宛先 IP アドレスを持つパケットは配信されません。 ただし、パケットのルーティングにインスタンスを使用する場合は、両方の機能が必要です。 この送信元と宛先の IP チェックを有効にするには、canIpForward フィールドを無効にします。これにより、インスタンスは、一致しない宛先 IP または送信元 IP を持つパケットを送受信できます。

重大度: 中

Cloud SQL PostgreSQL インスタンスの 'log_checkpoints' データベース フラグが 'on' に設定されていることを確認する

説明: Cloud SQL PostgreSQL インスタンスのlog_checkpoints データベース フラグがオンに設定されていることを確認します。 log_checkpoints を有効にすると、チェックポイントと再開ポイントがサーバー ログに記録されます。 ログ メッセージには、書き込まれたバッファーの数や書き込みに費やされた時間など、一部の統計が含まれます。 このパラメーターは、postgresql.conf ファイルまたはサーバーのコマンド ラインでのみ設定できます。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

Cloud SQL PostgreSQL インスタンスの 'log_lock_waits' データベース フラグが 'on' に設定されていることを確認する

説明: PostgreSQL インスタンスに対して "log_lock_waits" フラグを有効にすると、割り当てられた "deadlock_timeout" 時間よりも長い時間がかかるセッション待機のログが作成されます。 デッドロック タイムアウトは、条件をチェックする前にロックを待機する時間を定義します。 デッドロック タイムアウトが頻繁に発生することは、基になる問題があることを示している可能性があります。 log_lock_waits フラグを有効にしてこのような待機をログに記録すると、ロックの遅延や、特別に細工された SQL が過剰な時間ロックを保持してリソースを不足させようとしている場合に、パフォーマンスの低下を特定できます。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

Cloud SQL PostgreSQL インスタンスの 'log_min_duration_statement' データベース フラグが '-1' に設定されていることを確認する

説明: "log_min_duration_statement" フラグは、ステートメントの合計期間が記録されるステートメントの最小実行時間をミリ秒単位で定義します。 "log_min_duration_statement" が無効になっていることを確認します。つまり、値 -1 が設定されています。 SQL ステートメントのログ記録には、ログに記録すべきではない機密情報が含まれている場合があります。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

Cloud SQL PostgreSQL インスタンスの 'log_min_messages' データベース フラグが適切に設定されていることを確認する

説明: "log_min_error_statement" フラグは、エラー ステートメントと見なされる最小メッセージ重大度レベルを定義します。 エラー ステートメントのメッセージは、SQL ステートメントと共にログに記録されます。 有効な値には、"DEBUG5"、"DEBUG4"、"DEBUG3"、"DEBUG2"、"DEBUG1"、"INFO"、"NOTICE"、"WARNING"、"ERROR"、"LOG"、"FATAL"、"PANIC" などがあります。各重大度レベルには、上記の後続のレベルが含まれます。 失敗したステートメントのログ記録を効果的にオフにするには、このパラメーターを PANIC に設定します。 ベスト プラクティス設定と見なされるのは ERROR です。 変更は、あくまでも組織のログ ポリシーに従って行ってください。 監査は、運用上の問題のトラブルシューティングに役立ち、フォレンジック分析も可能です。 "log_min_error_statement" が正しい値に設定されていない場合、メッセージがエラー メッセージとして適切に分類されない可能性があります。 一般的なログ メッセージをエラー メッセージとして考慮すると、実際のエラーを見つけにくくなる一方で、エラー メッセージの重大度レベルが厳しい場合にのみ、実際のエラーをスキップして SQL ステートメントをログに記録する可能性があります。 "log_min_error_statement" フラグは、組織のログ ポリシーに従って設定する必要があります。 この推奨事項は、PostgreSQL データベース インスタンスに適用されます。

重大度: 低

Cloud SQL PostgreSQL インスタンスの 'log_temp_files' データベース フラグが '0' に設定されていることを確認します

説明: PostgreSQL では、これらの操作が "work_mem" を超えた場合に、並べ替え、ハッシュ、一時クエリ結果などのアクション用の一時ファイルを作成できます。"log_temp_files" フラグは、ログ名と削除時のファイル サイズを制御します。 "log_temp_files" を 0 に構成すると、すべての一時ファイル情報がログに記録されますが、正の値を指定すると、サイズが指定したキロバイト数以上のファイルのみがログに記録されます。 値 "-1" を指定すると、一時ファイル情報のログ記録が無効になります。 すべての一時ファイルがログに記録されない場合は、アプリケーションのコーディングが不十分であるか、意図的なリソース不足の試行が原因である可能性のある潜在的なパフォーマンスの問題を特定することが困難になる可能性があります。

重大度: 低

重要な VM の VM ディスクが顧客指定の暗号化キーを使用して暗号化されていることを確認する

説明: 顧客が提供する暗号化キー (CSEK) は、Google Cloud Storage と Google コンピューティング エンジンの機能です。 独自の暗号化キーを指定した場合、Google ではそのキーを使用して、データの暗号化と暗号化解除に使用される Google によって生成されたキーを保護します。 既定では、Google Compute Engine ではすべての保存データが暗号化されます。 この暗号化は Compute Engine によって自動で処理および管理されるため、追加の操作を行う必要はありません。 ただし、この暗号化を自分で制御および管理する場合は、独自の暗号化キーを指定できます。 既定では、Google Compute Engine ではすべての保存データが暗号化されます。 この暗号化は Compute Engine によって自動で処理および管理されるため、追加の操作を行う必要はありません。 ただし、この暗号化を自分で制御および管理する場合は、独自の暗号化キーを指定できます。 独自の暗号化キーを指定した場合、Compute Engine ではそのキーを使用して、データの暗号化と暗号化解除に使用される Google によって生成されたキーを保護します。 正しいキーを提供できるユーザーのみが、顧客指定の暗号化キーによって保護されたリソースを使用できます。 Google は、キーをサーバーに保存せず、キーを指定しない限り、保護されたデータにアクセスできません。 これはまた、キーを忘れた場合や紛失した場合、Googleがキーを回復したり、紛失したキーで暗号化されたデータを回復したりする方法がないことを意味します。 少なくともビジネス クリティカルな VM は、VM ディスクを CSEK で暗号化しておいてください。

重大度: 中

GCP プロジェクトでは、Azure Arc 自動プロビジョニングを有効にする必要がある

説明: Microsoft Defender for servers のセキュリティ コンテンツを完全に可視化するには、GCP VM インスタンスを Azure Arc に接続する必要があります。対象となるすべての VM インスタンスが Azure Arc を自動的に受信できるようにするには、GCP プロジェクト レベルで Defender for Cloud からの自動プロビジョニングを有効にします。 詳細については、Azure Arc と Microsoft Defender for server に関する各ページを参照してください。

重大度: 高

GCP VM インスタンスを Azure Arc に接続する必要がある

説明: Microsoft Defender for Servers のセキュリティ コンテンツを完全に可視化するために、GCP Virtual Machines を Azure Arc に接続します。 詳細については、ハイブリッドクラウド環境の Azure Arc と Microsoft Defender for Servers に関する各記事を参照してください。

重大度: 高

GCP VM インスタンスに OS 構成エージェントがインストールされている必要がある

説明: Azure Arc 自動プロビジョニングを使用して Defender for Servers のすべての機能を受信するには、GCP VM で OS 構成エージェントが有効になっている必要があります。

重大度: 高

GKE クラスターの自動修復機能を有効にする必要がある

説明: この推奨事項では、キーと値のペア 'key': 'autoRepair,' 'value': true のノード プールの管理プロパティを評価します。

重大度: 中

GKE クラスターの自動アップグレード機能を有効にする必要がある

説明: この推奨事項は、キーと値のペア 'key': 'autoUpgrade,' 'value': true のノード プールの管理プロパティを評価します。

重大度: 高

GKE クラスターの監視を有効にする必要がある

説明: この推奨事項では、クラスターの monitoringService プロパティに、メトリックの書き込みに Cloud Monitoring が使用する必要がある場所が含まれているかどうかを評価します。

重大度: 中

関連するコンテンツ