次の方法で共有

セキュリティ制御: データ保護

  • [アーティクル]

データ保護は、保存時、転送中、およびアクセス制御、およびアクセス制御、暗号化、キー管理、証明書管理を使用して機密データ資産の検出、分類、保護、監視などの承認されたアクセス メカニズムを介して制御します。

DP-1:機密データを検出、分類、ラベル付けする

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
3.2、3.7、3.13 RA-2、SC-28 A3.2

セキュリティ原則: 定義された機密データ スコープに基づいて、機密データのインベントリを確立して維持します。 ツールを使用して、機密データの範囲に入るデータを検出、分類し、ラベルを付けます。

Azure ガイダンス: 以前の Azure Purview と Microsoft 365 コンプライアンス ソリューションを組み合わせた Microsoft Purview などのツールと、Azure SQL データの検出と分類を組み合わせて、Azure、オンプレミス、Microsoft 365、およびその他の場所に存在する機密データを一元的にスキャン、分類、ラベル付けするツールを使用します。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: さまざまなソースから S3 ストレージ バケットにデータをレプリケートし、AWS Macie を使用して、バケットに格納されている機密データをスキャン、分類、ラベル付けします。 AWS Macie は、カスタムデータ識別子ルールに基づいて、セキュリティ認証情報、財務情報、PHI および PII データ、その他のデータパターンなどの機密データを検出できます。

また、Azure Purview マルチクラウド スキャン コネクタを使用して、S3 ストレージ バケットに存在する機密データをスキャン、分類、ラベル付けすることもできます。

注: データ検出の分類とラベル付けの目的で、AWS Marketplace のサードパーティ製エンタープライズ ソリューションを使用することもできます。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: Google Cloud データ損失防止などのツールを使用して、GCP およびオンプレミス環境に存在する機密データを一元的にスキャン、分類、ラベル付けします。

さらに、Google Cloud Data Catalog を使用して、クラウド データ損失防止 (DLP) スキャンの結果を利用して、タグ テンプレートが定義された機密データを識別します。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

DP-2: 機密データをターゲットにした異常と脅威を監視する

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
3.13 AC-4、SI-4 A3.2

セキュリティ原則: 企業の可視性と制御の範囲外の場所へのデータの不正な転送など、機密データに関する異常を監視します。 これには通常、不正なデータ流出を示す可能性のある異常な活動 (大規模または異常な転送) の監視が含まれます。

Azure ガイダンス: Azure Information Protection (AIP) を使用して、分類およびラベル付けされたデータを監視します。

Microsoft Defender for Storage、Microsoft Defender for SQL、Microsoft Defender for オープンソース リレーショナル データベース、および Microsoft Defender for Cosmos DB を使用して、機密データ情報の不正な転送を示す可能性のある異常な情報転送に関するアラートを生成します。

注: データ損失防止 (DLP) のコンプライアンスに必要な場合は、Azure Marketplace のホストベースの DLP ソリューションまたは Microsoft 365 DLP ソリューションを使用して、データ流出を防ぐために検出や予防の制御を適用できます。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: AWS Macie を使用して分類およびラベル付けされたデータを監視し、GuardDuty を使用して一部のリソース (S3、EC2、または Kubernetes または IAM リソース) の異常なアクティビティを検出します。 結果とアラートは、EventBridge を使用してトリアージ、分析、追跡を行い、インシデントの集計と追跡のために Microsoft Sentinel または Security Hub に転送できます。

また、コンプライアンスチェック、コンテナーセキュリティ、エンドポイントセキュリティ機能のために、AWS アカウントを Microsoft Defender for Cloud に接続することもできます。

注: データ損失防止 (DLP) のコンプライアンスに必要な場合は、AWS Marketplace のホストベースの DLP ソリューションを使用できます。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: Google Cloud Security Command Center/Event Threat Detection/Anomaly Detection を使用して、機密情報の不正な転送を示す可能性がある情報の異常な転送に関するアラートを生成します。

また、コンプライアンス チェック、コンテナー セキュリティ、エンドポイント セキュリティ機能のために、GCP アカウントを Microsoft Defender for Cloud に接続することもできます。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

DP-3: 転送中の機密データの暗号化

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
3.10 SC-8 3.5、3.6、4.1

セキュリティの原則: 暗号化を使用して、転送中のデータを "帯域外" 攻撃 (トラフィック キャプチャなど) から保護し、攻撃者がデータを簡単に読み取ったり変更したりできないようにします。

転送中データの暗号化がネットワーク内外で必須となる network の境界とサービス範囲を設定します。 これはプライベート ネットワーク上のトラフィックでは省略できますが、外部ネットワークとパブリック ネットワーク上のトラフィックには重要です。

Azure ガイダンス: 転送中のネイティブ データ暗号化機能が組み込まれている Azure Storage などのサービスでセキュリティで保護された転送を適用します。

Azure リソースに接続するすべてのクライアントがトランスポート層セキュリティ (TLS) v1.2 以降を使用するようにして、Web アプリケーションのワークロードとサービスに HTTPS を適用します。 VM のリモート管理については、非暗号化プロトコルではなく、SSH (Linux の場合) または RDP/TLS (Windows の場合) を使用します。

Azure 仮想マシンのリモート管理には、暗号化されていないプロトコルではなく、SSH (Linux の場合) または RDP/TLS (Windows の場合) を使用します。 安全なファイル転送を行うには、通常の FTP サービスを使用する代わりに、Azure Storage BLOB、App Service アプリ、関数アプリで SFTP/FTPS サービスを使用します。

注意: 転送中データの暗号化は、Azure データセンター間を移動するすべての Azure トラフィックについて有効になっています。 TLS v1.2 以降は、ほとんどの Azure サービスで既定で有効になっています。 また、Azure Storage や Application Gateway などの一部のサービスでは、サーバー側で TLS v1.2 以降を適用できます。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: 転送中のネイティブ データ暗号化機能が組み込まれている Amazon S3、RDS、CloudFront などのサービスで安全な転送を適用します。

AWS リソースに接続するすべてのクライアントで TLS v1.2 以降が使用されるようにすることで、ワークロード Web アプリケーションとサービス (サーバー側またはクライアント側、またはその両方) に HTTPS (AWS Elastic Load Balancer など) を適用します。

EC2 インスタンスのリモート管理には、暗号化されていないプロトコルの代わりに SSH (Linux の場合) または RDP/TLS (Windows の場合) を使用します。 安全なファイル転送には、通常の FTP サービスではなく、AWS Transfer SFTP または FTPS サービスを使用します。

注: AWS データセンター間のすべてのネットワーク トラフィックは、物理層で透過的に暗号化されます。 サポートされている Amazon EC2 インスタンスタイプを使用する場合、VPC 内およびリージョン間のピアリングされた VPC 間のすべてのトラフィックは、ネットワークレイヤーで透過的に暗号化されます。 TLS v1.2 以降は、ほとんどの AWS サービスで既定で有効になっています。 また、AWS Load Balancer などの一部のサービスでは、サーバー側で TLS v1.2 以降を適用できます。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: 転送中のネイティブ データ暗号化機能が組み込まれている Google Cloud Storage などのサービスで安全な転送を強制します。

Web アプリケーションのワークロードとサービスに HTTPS を適用して、GCP リソースに接続するすべてのクライアントがトランスポート層セキュリティ (TLS) v1.2 以降を使用するようにします。

リモート管理の場合、Google Cloud Compute Engine では、暗号化されていないプロトコルではなく SSH (Linux の場合) または RDP/TLS (Windows の場合) を使用します。 安全なファイル転送を行うには、通常の FTP サービスではなく、Google Cloud Big Query や Cloud App Engine などのサービスで SFTP/FTPS サービスを使用します。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

DP-4: 保存データ暗号化を既定で有効にする

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
3.11 SC-28 3.4、3.5

セキュリティ原則: アクセス制御を補完するために、保存データは、暗号化を使用した "帯域外" 攻撃 (基になるストレージへのアクセスなど) から保護する必要があります。 これにより、攻撃者がデータを簡単に読み取ったり変更したりすることが確実にできなくなります。

Azure ガイダンス: 多くの Azure サービスでは、サービスマネージド キーを使用して、インフラストラクチャ レイヤーで保存データの暗号化が既定で有効になっています。 これらのサービス管理キーは、顧客の代わりに生成され、2 年ごとに自動的にローテーションされます。

技術的に実行可能であり、既定では有効になっていない場合は、Azure サービスまたは VM の保存時の暗号化をストレージ レベル、ファイル レベル、またはデータベース レベルで有効にすることができます。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: 多くの AWS サービスでは、AWS が管理するカスタマー マスター キーを使用して、インフラストラクチャ/プラットフォーム レイヤーで既定で保存データの暗号化が有効になっています。 これらの AWS で管理されるカスタマー マスター キーは、顧客の代わりに生成され、3 年ごとに自動的にローテーションされます。

技術的に実行可能であり、既定では有効になっていない場合は、AWS サービス、またはストレージ レベル、ファイル レベル、またはデータベース レベルで VM で保存データの暗号化を有効にすることができます。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: 多くの Google Cloud 製品およびサービスでは、サービスマネージド キーを使用して、インフラストラクチャ レイヤーで保存データの暗号化が既定で有効になっています。 これらのサービス マネージド キーは、顧客の代わりに生成され、自動的にローテーションされます。

技術的に実行可能であり、既定では有効になっていない場合は、保存データの暗号化を GCP サービス、またはストレージ レベル、ファイル レベル、またはデータベース レベルで VM で有効にすることができます。

注: 詳細については、「Google クラウド サービスの暗号化の粒度」のドキュメントを参照してください。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

DP-5: 必要に応じて保存データ暗号化でカスタマー マネージド キー オプションを使用する

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
3.11 SC-12、SC-28 3.4、3.5、3.6

セキュリティ原則: 規制コンプライアンスに必要な場合は、カスタマー マネージド キー オプションが必要なユース ケースとサービス スコープを定義します。 サービスでカスタマー マネージド キーを使用して保存時のデータ暗号化を有効にして実装します。

Azure ガイダンス: Azure には、ほとんどのサービスで自分で管理されるキー (カスタマー マネージド キー) を使用した暗号化オプションも用意されています。

Azure Key Vault Standard、Premium、および Managed HSM は、カスタマー マネージド キーのユース ケースのために、多くの Azure Services とネイティブに統合されています。 Azure Key Vault を使用してキーを生成したり、独自のキーを持ち込んだりすることができます。

ただし、カスタマー マネージド キー オプションを使用するには、キーのライフサイクルを管理するための追加の運用作業が必要です。 これには、暗号化キーの生成、ローテーション、取り消し、アクセス制御などが含まれます。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: AWS には、特定のサービスに対して自分で管理されるキー (AWS キー管理サービス に格納されているカスタマー マネージドカスタマー マスター キー) を使用した暗号化オプションも用意されています。

AWS キー管理サービス (KMS) は、カスタマー マネージドカスタマー マスター キーのユース ケース向けに、多くの AWS サービスとネイティブに統合されています。 AWS キー管理サービス (KMS) を使用してマスター キーを生成するか、独自のキーを持ち込んでもかまいません。

ただし、カスタマー マネージド キー オプションを使用するには、キーのライフサイクルを管理するための追加の運用作業が必要です。 これには、暗号化キーの生成、ローテーション、取り消し、アクセス制御などが含まれます。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: Google Cloud では、ほとんどのサービスで自分で管理されるキー (カスタマー マネージド キー) を使用した暗号化オプションが提供されています。

Google Cloud キー管理サービス (Cloud KMS) は、カスタマー マネージド暗号化キー用の多くの GCP サービスとネイティブに統合されています。 これらのキーはクラウド KMS を使用して作成および管理でき、キーはソフトウェア キーとして、HSM クラスターに格納するか、外部に格納します。 Cloud KMS を使用してキーを生成したり、独自のキー (顧客が指定した暗号化キー) を指定したりできます。

ただし、カスタマー マネージド キー オプションを使用するには、キーのライフサイクルを管理するための追加の運用作業が必要です。 これには、暗号化キーの生成、ローテーション、取り消し、アクセス制御などが含まれます。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

DP-6: セキュア キー管理プロセスの使用

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
該当なし IA-5、SC-12、SC-28 3.6

セキュリティ原則: エンタープライズ暗号化キー管理の標準、プロセス、および手順を文書化して実装し、キーのライフサイクルを制御します。 サービスでカスタマー マネージド キーを使用する必要がある場合は、セキュリティで保護されたキー コンテナーをキーの生成、配布、ストレージに使用します。 キーは定義済みのスケジュールに基づいてローテーションし、また、キーの償却や改ざんがあった場合は取り消します。

Azure ガイダンス: Azure Key Vault を使用して、キーの生成、配布、ストレージなど、暗号化キーのライフ サイクルを作成および制御します。 定義されたスケジュールに基づいて、Azure Key Vault にあるキーをローテーションし、また、キーの償却や改ざんがあった場合は取り消します。 キーを生成するときに、特定の暗号化の種類と最小キー サイズが必要です。

ワークロード サービスやアプリケーションでカスタマー マネージド キー (CMK) を使用する必要がある場合は、ベスト プラクティスに従ってください。

  • キー階層を使用して、自分のキー暗号化キー (KEK) と共に別のデータ暗号化キー (DEK) をキー コンテナーに生成します。
  • キーが Azure Key Vault に登録され、各サービスまたはアプリケーションのキー ID を介して実装されていることを確認します。

キー マテリアルの有効期間と移植性を最大化するには、独自のキー (BYOK) をサービスに取り込みます (つまり、HSM で保護されたキーをオンプレミスの HSM から Azure Key Vault にインポートする)。 推奨されるガイドラインに従って、キーの生成とキー転送を実行します。

注: Azure Key Vault の種類と FIPS コンプライアンス/検証レベルの FIPS 140-2 レベルについては、以下を参照してください。

  • コンテナー内のソフトウェアで保護されたキー (Premium および Standard SKU): FIPS 140-2 レベル 1
  • コンテナー内の HSM で保護されたキー (Premium SKU): FIPS 140-2 Level 2
  • マネージド HSM 内の HSM で保護されたキー: FIPS 140-2 Level 3

Azure Key Vault Premium では、バックエンドで共有 HSM インフラストラクチャが使用されます。 Azure Key Vault Managed HSM では、より高いレベルのキー セキュリティが必要な場合のために、専用の機密サービス エンドポイントと専用 HSM を使用します。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: AWS キー管理サービス (KMS) を使用して、キーの生成、配布、ストレージなど、暗号化キーのライフ サイクルを作成および制御します。 定義されたスケジュールに基づいて、およびキーの廃止または侵害が発生した場合に、KMS とサービスのキーをローテーションして取り消します。

ワークロード サービスまたはアプリケーションでカスタマー マネージドカスタマー マスター キーを使用する必要がある場合は、ベスト プラクティスに従ってください。

  • キー階層を使用して、KMS でキー暗号化キー (KEK) を使用して個別のデータ暗号化キー (DEK) を生成します。
  • キーが KMS に登録されていることを確認し、各サービスまたはアプリケーションの IAM ポリシーを使用して実装します。

キー マテリアルの有効期間と移植性を最大化するには、独自のキー (BYOK) をサービスに取り込みます (つまり、HSM で保護されたキーをオンプレミスの HSM から KMS または Cloud HSM にインポートする)。 推奨されるガイドラインに従って、キーの生成とキー転送を実行します。

注: AWS KMS では、バックエンドで共有 HSM インフラストラクチャが使用されます。 独自のキー ストアと専用 HSM (高レベルのキー セキュリティに関する規制コンプライアンス要件など) を管理して暗号化キーを生成および格納する必要がある場合は、AWS CloudHSM によってサポートされる AWS KMS カスタム キー ストアを使用します。

注: AWS KMS および CloudHSM の FIPS コンプライアンス レベルの FIPS 140-2 レベルについては、以下を参照してください。

  • AWS KMS の既定値: FIPS 140-2 レベル 2 が検証済み
  • CloudHSM を使用する AWS KMS: FIPS 140-2 レベル 3 (特定のサービスの場合) が検証済み
  • AWS CloudHSM: FIPS 140-2 レベル 3 が検証済み

注: シークレット管理 (資格情報、パスワード、API キーなど) の場合は、AWS Secrets Manager を使用します。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: Cloud キー管理サービス (Cloud KMS) を使用して、互換性のある Google Cloud サービスとワークロード アプリケーションで暗号化キーのライフサイクルを作成および管理します。 定義されたスケジュールと、キーの提供終了または侵害が発生した場合に基づいて、Cloud KMS とサービスのキーをローテーションして取り消します。

Google の Cloud HSM サービスを使用して、クラウド KMS (キー管理サービス) にハードウェアベースのキーを提供します。このサービスを使用すると、フル マネージドハードウェア セキュリティ モジュール (HSM) によって保護されている間、独自の暗号化キーを管理および使用できます。

Cloud HSM サービスでは、FIPS 140-2 レベル 3 で検証され、FIPS モードで常に実行されている HSM が使用されます。 FIPS 140-2 レベル 3 検証済みで、常に FIPS モードで実行されています。 FIPS 標準では、HSM で使用される暗号アルゴリズムと乱数の生成を指定します。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

DP-7: セキュリティで保護された証明書管理プロセスを使用する

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
該当なし IA-5、SC-12、SC-17 3.6

セキュリティ原則: エンタープライズ証明書管理標準、証明書ライフサイクル制御を含むプロセスと手順、および証明書ポリシー (公開キー インフラストラクチャが必要な場合) を文書化して実装します。

組織の基幹サービスで使用されている証明書が、自動化メカニズムを使用してインベントリに入れられ、追跡され、監視され、タイムリーに更新されることで、サービス中断を回避できるように確保します。

Azure ガイダンス: Azure Key Vault を使用して、証明書の作成/インポート、ローテーション、失効、ストレージ、消去など、証明書のライフサイクルを作成および制御します。 証明書が、キーサイズ不足、長すぎる有効期間、セキュリティにより保護されていない暗号化などのセキュアではない特性を使用することなく、定義済みの基準に従って生成されることを確認します。 定義されたスケジュールと証明書の有効期限に基づいて、Azure Key Vault とサポートされている Azure サービスで証明書の自動ローテーションを設定します。 フロントエンド アプリケーションで自動ローテーションがサポートされていない場合は、Azure Key Vault で手動ローテーションを使用します。

セキュリティ保証が制限されているため、重要なサービスでは自己署名証明書とワイルドカード証明書を使用しないでください。 代わりに、Azure Key Vault で公開署名付き証明書を作成できます。 次の証明機関 (CA) は、現在 Azure Key Vault と統合されているパートナー プロバイダーです。

  • DigiCert: Azure Key Vault は DigiCert による OV TLS/SSL 証明書を提供します。
  • GlobalSign: Azure Key Vault は GlobalSighn による OV TLS/SSL 証明書を提供します。

注: 承認済みの CA のみを使用し、これらの CA によって発行された既知の不良ルート/中間証明書が無効になっていることを確認します。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: AWS Certificate Manager (ACM) を使用して、証明書の作成/インポート、ローテーション、失効、ストレージ、消去など、証明書のライフサイクルを作成および制御します。 証明書が、キーサイズ不足、長すぎる有効期間、セキュリティにより保護されていない暗号化などのセキュアではない特性を使用することなく、定義済みの基準に従って生成されることを確認します。 定義されたスケジュールと証明書の有効期限に基づいて、ACM およびサポートされている AWS サービスで証明書の自動ローテーションを設定します。 フロントエンド アプリケーションで自動ローテーションがサポートされていない場合は、ACM で手動ローテーションを使用します。 それまでの間は、証明書の更新状態を常に追跡して、証明書の有効性を確認する必要があります。

セキュリティ保証が制限されているため、重要なサービスでは自己署名証明書とワイルドカード証明書を使用しないでください。 代わりに、ACM で (Amazon 証明機関によって署名された) パブリック署名付き証明書を作成し、CloudFront、Load Balancer、API Gateway などのサービスにプログラムでデプロイします。また、ACM を使用してプライベート証明機関 (CA) を確立し、プライベート証明書に署名することもできます。

注: 承認された CA のみを使用し、これらの CA によって発行された既知の無効な CA ルート/中間証明書が無効になっていることを確認します。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: Google Cloud Certificate Manager を使用して、証明書の作成/インポート、ローテーション、失効、ストレージ、消去など、証明書のライフサイクルを作成および制御します。 証明書が、キーサイズ不足、長すぎる有効期間、セキュリティにより保護されていない暗号化などのセキュアではない特性を使用することなく、定義済みの基準に従って生成されることを確認します。 定義されたスケジュールと証明書の有効期限に基づいて、証明書マネージャーとサポートされている GCP サービスで証明書の自動ローテーションを設定します。 フロントエンド アプリケーションで自動ローテーションがサポートされていない場合は、Certificate Manager で手動ローテーションを使用します。 それまでの間は、証明書の更新状態を常に追跡して、証明書の有効性を確認する必要があります。

セキュリティ保証が制限されているため、重要なサービスでは自己署名証明書とワイルドカード証明書を使用しないでください。 代わりに、証明書マネージャーで署名付きパブリック証明書を作成し、Load Balancer やクラウド DNS などのサービスにプログラムでデプロイできます。また、証明機関サービスを使用して、プライベート証明機関 (CA) を確立してプライベート証明書に署名することもできます。

注: Google Cloud Secret Manager を使用して TLS 証明書を格納することもできます。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):

DP-8: キーおよび証明書リポジトリーのセキュリティを確保する

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
該当なし IA-5、SC-12、SC-17 3.6

セキュリティ原則: 暗号化キーと証明書のライフサイクル管理に使用されるキー コンテナー サービスのセキュリティを確保します。 アクセス制御、ネットワーク セキュリティ、ログ記録と監視、バックアップによって、キー コンテナー サービスを強化し、キーと証明書が最大限のセキュリティによって常に保護されていることを保証します。

Azure ガイダンス: 次のコントロールを使用して Azure Key Vault サービスを強化することで、暗号化キーと証明書をセキュリティで保護します。

  • Azure Key Vault Managed HSM の RBAC ポリシーを使用してキー レベルでアクセス制御を実装し、最小限の特権と職務の分離原則に従っていることを確認します。 たとえば、暗号化キーを管理するユーザーが暗号化データにアクセスできないようにし、その逆も同様に、職務の分離を確保します。 Azure Key Vault Standard と Premium の場合は、さまざまなアプリケーション用に一意のコンテナーを作成して、最小限の特権と職務の分離の原則に従います。
  • Azure Key Vault のログ記録を有効にして、重要な管理プレーンとデータ プレーンのアクティビティがログに記録されるようにします。
  • Private Link と Azure Firewall を使用して Azure Key Vault をセキュリティで保護し、サービスの露出を最小限に抑える
  • マネージド ID を使用して、ワークロード アプリケーションの Azure Key Vault に格納されているキーにアクセスします。
  • データをパージする際には、実際のデータ、バックアップ、アーカイブがパージされる前にキーが削除されないようにしてください。
  • Azure Key Vault を使用してキーと証明書をバックアップします。 論理的な削除と消去の保護を有効にして、キーが誤って削除されないようにします。キーを削除する必要がある場合は、キーを誤って削除したり、データの暗号化を消去したりしないように、キーを削除するのではなく、キーを無効にすることを検討してください。
  • Bring Your Own Key (BYOK) のユース ケースでは、オンプレミス HSM でキーを生成し、キーをインポートして、キーの有効期間と移植性を最大化します。
  • Azure Key Vault の外部でプレーンテキスト形式でキーを格納しないでください。 すべてのキー コンテナー サービスのキーは、既定ではエクスポートできません。
  • ハードウェア保護と最も強力な FIPS レベルには、Azure Key Vault Premium と Azure Managed HSM で HSM ベースのキーの種類 (RSA-HSM) を使用します。

Microsoft Defender for Key Vault を有効にして、Azure Key Vault の Azure ネイティブで高度な脅威の防止を使用することにより、セキュリティ インテリジェンスの層を追加します。

Azure の実装と追加のコンテキスト:

AWS ガイダンス: 暗号化キーのセキュリティについては、次のコントロールを使用して AWS キー管理サービス (KMS) サービスを強化してキーをセキュリティで保護します。

  • IAM ポリシー (ID ベースのアクセス制御) と組み合わせてキー ポリシー (キーレベルのアクセス制御) を使用してアクセス制御を実装し、最小限の特権と職務の分離原則に従います。 たとえば、暗号化キーを管理するユーザーが暗号化データにアクセスできないようにし、その逆も同様に、職務の分離を確保します。
  • CloudTrails などの探偵コントロールを使用して、KMS でのキーの使用状況をログに記録して追跡し、重要なアクションについて警告します。
  • KMS の外部でプレーンテキスト形式でキーを格納しないでください。
  • キーを削除する必要がある場合は、キーの誤削除やデータの暗号化消去を回避するために、キーを削除するのではなく、KMS でキーを無効にすることを検討してください。
  • データをパージする際には、実際のデータ、バックアップ、アーカイブがパージされる前にキーが削除されないようにしてください。
  • Bring Your Own Key (BYOK) のユースケースでは、オンプレミス HSM でキーを生成し、キーをインポートしてキーの有効期間と移植性を最大化します。

証明書のセキュリティを確保するには、次のコントロールを使用して AWS Certificate Manager (ACM) サービスを強化することで、証明書をセキュリティで保護します。

  • IAM ポリシー (ID ベースのアクセス制御) と組み合わせてリソースレベルのポリシーを使用してアクセス制御を実装し、最小限の特権と職務の分離の原則に従います。 たとえば、ユーザー アカウントに対して職務の分離が確実に行われるようにします。証明書を生成するユーザー アカウントは、証明書への読み取り専用アクセスのみを必要とするユーザー アカウントとは別です。
  • CloudTrails などの検出コントロールを使用して、ACM 内の証明書の使用状況をログに記録して追跡し、重要なアクションについてアラートを生成します。
  • KMS セキュリティ ガイダンスに従って、サービス証明書の統合に使用される秘密キー (証明書要求用に生成) をセキュリティで保護します。

AWS の実装と追加のコンテキスト:

GCP ガイダンス: 暗号化キーのセキュリティについては、次のコントロールを使用してキー管理サービスを強化してキーをセキュリティで保護します。

  • IAM ロールを使用してアクセス制御を実装し、最小限の特権と職務の分離の原則に従います。 たとえば、暗号化キーを管理するユーザーが暗号化データにアクセスできないようにし、その逆も同様に、職務の分離を確保します。
  • プロジェクトごとに個別のキー リングを作成します。これにより、最小限の特権のベスト プラクティスに従って、キーへのアクセスを簡単に管理および制御できます。 また、いつどのキーにアクセスできるユーザーを監査することも容易になります。
  • キーの自動ローテーションを有効にして、キーが定期的に更新および更新されるようにします。 これは、ブルート フォース攻撃や機密情報へのアクセスを試みる悪意のあるアクターなどの潜在的なセキュリティ脅威から保護するのに役立ちます。
  • GCP KMS 環境内で発生するすべてのアクティビティを追跡するように監査ログ シンクをセットアップします。

証明書のセキュリティを確保するには、次のコントロールを使用して GCP 証明書マネージャーと証明機関サービスを強化することで、証明書をセキュリティで保護します。

  • IAM ポリシー (ID ベースのアクセス制御) と組み合わせてリソースレベルのポリシーを使用してアクセス制御を実装し、最小限の特権と職務の分離の原則に従います。 たとえば、ユーザー アカウントに対して職務の分離が確実に行われるようにします。証明書を生成するユーザー アカウントは、証明書への読み取り専用アクセスのみを必要とするユーザー アカウントとは別です。
  • クラウド監査ログなどの検出コントロールを使用して、証明書マネージャーで証明書の使用状況をログに記録して追跡し、重要なアクションについて警告します。
  • シークレット マネージャーでは、TLS 証明書のストレージもサポートされています。 シークレット マネージャーでセキュリティ コントロールを実装するには、同様のセキュリティプラクティスに従う必要があります。

GCP の実装と追加のコンテキスト:

顧客のセキュリティ利害関係者 (詳細情報):