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

  • [アーティクル]

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

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

CIS Controls v8 ID NNIST 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を使用して、Cloud Data Loss Prevention (DLP) スキャンの結果を利用して、タグ テンプレートが定義された機密データを識別します。

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

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

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

CIS Controls v8 ID NNIST 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、SQL 用のMicrosoft Defender、オープンソース リレーショナル データベースのMicrosoft Defender、および Cosmos DB のMicrosoft Defenderを使用して、機密データの不正な転送を示す可能性のある異常な情報の転送に関するアラートを生成します情報。

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

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

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

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

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

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

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

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

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

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

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

CIS Controls v8 ID NNIST 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 以降を使用するようにします。

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

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

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

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

CIS Controls v8 ID NNIST 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 サービス、またはストレージ レベル、ファイル レベル、またはデータベース レベルで、保存データの暗号化を有効にすることができます。

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

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

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

注: 詳細については、ドキュメント「Google Cloud Services の暗号化の粒度」を参照してください。

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

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

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

CIS Controls v8 ID NNIST 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 サービスとネイティブに統合されています。 Azure Key Vaultを使用してキーを生成したり、独自のキーを持ち込んだりできます。

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

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

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

AWS Key Management Service (KMS) は、カスタマー マネージドカスタマー マスター キーのユース ケースのために、多くの AWS サービスとネイティブに統合されています。 AWS Key Management Service (KMS) を使用してマスター キーを生成するか、独自のキーを持ち込みます。

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

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

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

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

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

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

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

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

CIS Controls v8 ID NNIST 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 から Azure Key Vault に HSM で保護されたキーをインポートします)。 推奨されるガイドラインに従って、キーの生成とキー転送を実行します。

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

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

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

重要な素材の有効期間と移植性を最大化するには、独自のキー (BYOK) をサービスに持ち込みます (つまり、オンプレミスの HSM から KMS またはクラウド HSM に 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 Key Management Service (Cloud KMS) を使用して、互換性のある Google クラウド サービスとワークロード アプリケーションで暗号化キーのライフサイクルを作成および管理します。 定義されたスケジュールと、キーの廃止または侵害が発生した場合に基づいて、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 NNIST 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 NNIST 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 Key Management Service (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 の実装と追加のコンテキスト:

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