次の方法で共有


マネージド HSM のセキュリティ ドメインの概要

マネージド HSM は、シングル テナントの FIPS (連邦情報処理標準) 140-2 の検証を受けた高可用性ハードウェア セキュリティ モジュール (HSM) であり、顧客が管理するセキュリティ ドメインがあります。

マネージド HSM が動作するには、セキュリティ ドメインが必要です。 セキュリティ ドメインは暗号化された BLOB ファイルであり、HSM のバックアップ、ユーザー資格情報、署名キー、データ暗号化キーなど、マネージド HSM に固有の成果物が含まれています。

マネージド HSM セキュリティ ドメインは次の目的を果たします。

  • 各マネージド HSM を、お客様が独自に管理する信頼キーのルートに暗号的に結びつけることで、"所有権" を確立します。 こうすることで、Microsoft はマネージド HSM 上にあるお客様の暗号キー マテリアルにアクセスできなくなります。

  • マネージド HSM インスタンスのキーの暗号境界を設定します。

  • 障害の発生時にマネージド HSM インスタンスを完全に復旧できます。 次の障害シナリオに対応できます。

    • マネージド HSM インスタンスのすべてのメンバー HSM インスタンスが破棄されるような壊滅的な障害。
    • マネージド HSM インスタンスが顧客によって論理的に削除され、必須の保持期間の満了後にリソースが消去された。
    • 顧客が、マネージド HSM インスタンスとすべてのデータを含むバックアップを実行してプロジェクトをアーカイブし、その後、そのプロジェクトに関連付けられたすべての Azure リソースを削除しました。

セキュリティ ドメインがないと、ディザスター リカバリーは不可能です。 Microsoft 側でセキュリティ ドメインを復旧することはできません。また、セキュリティ ドメインなしでキーにアクセスすることもできません。 そのため、ビジネス継続性と、暗号的にロックアウトされないようにするためには、セキュリティ ドメインの保護が最も重要です。

セキュリティ ドメイン保護のベスト プラクティス

セキュリティ ドメインを確実に保護するには、次のベスト プラクティスを実装します。

暗号化されたセキュリティ ドメインのダウンロード

セキュリティ ドメインは、初期化時にマネージド HSM ハードウェアとサービス ソフトウェア エンクレーブの両方に生成されます。 マネージド HSM をプロビジョニングした後、少なくとも 3 つの RSA キー ペアを作成し、セキュリティ ドメインのダウンロードを要求するときに、これらの公開キーをサービスに送信する必要があります。 また、後でセキュリティ ドメインの暗号化を解除するために必要なキーの最小数 (クォーラム) を指定する必要があります。

マネージド HSM は、セキュリティ ドメインを初期化し、Shamir のシークレット共有アルゴリズムを使用して、指定した公開キーで暗号化します。 セキュリティ ドメインがダウンロードされた後、マネージド HSM はアクティブ化された状態に移行し、使用できるようになります。

セキュリティ ドメイン キーの格納

セキュリティ ドメイン キーは、オフライン ストレージ (暗号化された USB ドライブなど) に保管し、クォーラムの各分割を別のストレージ デバイスに格納する必要があります。 ストレージ デバイスは、地理的に離れた場所にある物理的な金庫またはロック ボックス内に保管する必要があります。 非常に機密性が高く保証度の高いユース ケースの場合は、セキュリティ ドメインの秘密キーをオンプレミスのオフライン HSM に格納することもできます。

マネージド HSM クォーラムのセキュリティ ポリシーを定期的に見直すことも特に重要です。 セキュリティ ポリシーは正確にする必要があります。セキュリティ ドメインとその秘密キーの格納場所について最新の記録を保持する必要があります。また、セキュリティ ドメインの管理者を把握している必要があります。

セキュリティ ドメイン キーの取り扱いに関する禁止事項は次のとおりです。

  • すべてのクォーラム キーに物理的にアクセスする許可を 1 人の担当者に与えないでください。 つまり、m は 1 より大きくする必要があります (理想的には > 3 以上をお勧めします)。
  • セキュリティ ドメイン キーは、インターネットに接続されたコンピューターに格納しないでください。 インターネットに接続されたコンピューターは、ウイルスや悪意のあるハッカーなど、さまざまな脅威にさらされています。 セキュリティ ドメイン キーをオフラインで格納することで、リスクを大幅に軽減できます。

セキュリティ ドメイン クォーラムの確立

セキュリティ ドメインを保護し、暗号のロックアウトを防ぐ最善の方法は、マネージド HSM の概念 クォーラム を使って、複数人による管理を実装することです。 クォーラムは、セキュリティ ドメインを暗号化するキーを複数人で分割するための分割シークレットしきい値です。 クォーラムは、複数ユーザーの制御を強制します。 こうすることで、セキュリティ ドメインは、組織を離れたり悪意を持っている可能性のある 1 人の担当者に依存しなくなります。

m 人 (m は 3 以上) のクォーラムを実装することをお勧めします。 マネージド HSM のセキュリティ ドメインの最大クォーラム サイズは 10 です。

より大きな (m) サイズにするとセキュリティは強化されますが、セキュリティ ドメインの扱いという点で管理のオーバーヘッドが増えます。 そのため、セキュリティ ドメイン クォーラムは、m>= 3 として慎重に選ぶ必要があります。

また、セキュリティ ドメイン クォーラムのサイズを定期的に見直し、更新するようにします (たとえば、人事異動があった場合など)。 セキュリティ ドメイン所有者の記録を保管することが特に重要です。 記録には、所有権の譲渡または変更をすべて記録する必要があります。 ポリシーでは、クォーラムと文書要件の厳格な順守を強制する必要があります。

このキーを使用すると、マネージド HSM の最も機密性の高い重要な情報にアクセスできるため、セキュリティ ドメインの秘密キーは、組織内の信頼できる主要な従業員が保持する必要があります。 セキュリティ ドメイン保持者には、組織内で個別の役割を持ち、地理的に離れた場所にいる担当者を指定するようにします。

たとえば、セキュリティ ドメイン クォーラムを 4 つのキー ペアに構成し、各秘密キーを異なる担当者に渡すことができます。 セキュリティ ドメインを再構築するには、少なくとも 2 人の担当者が集まる必要があります。 パーツは、次のような主要担当者に渡すことができます。

  • 事業単位の技術リーダー
  • セキュリティ アーキテクト
  • セキュリティ エンジニア
  • アプリケーション開発者

組織はそれぞれ異なり、そのニーズに応じて異なるセキュリティ ポリシーを実施しています。 セキュリティ ポリシーの準拠状況を定期的に見直し、クォーラムとそのサイズについて判断することをお勧めします。 組織はレビューのタイミングを選択できますが、少なくとも四半期に 1 回、次のタイミングでセキュリティ ドメイン レビューを実施することをお勧めします。

  • クォーラムのメンバーが組織から離脱したとき。
  • 新しい脅威または脅威の発生により、クォーラム サイズの増加を決定したとき。
  • クォーラムの実装にプロセスの変更を伴うとき。
  • セキュリティ ドメイン クォーラムのメンバーに属する USB ドライブまたは HSM が紛失した、または侵害されたとき。

セキュリティ ドメインの侵害または紛失

セキュリティ ドメインが侵害された場合、悪意のあるアクターがそれを使って独自のマネージド HSM インスタンスを作成する可能性があります。 悪意のあるアクターは、キーのバックアップへのアクセスを使って、マネージド HSM 上にあるキーで保護されたデータの暗号化を解除し始める可能性があります。

紛失したセキュリティ ドメインは侵害されたものと考えます。

セキュリティ ドメインが侵害された後、現在マネージド HSM で暗号化されたすべてのデータは、現在のキー マテリアルを使って暗号化を解除する必要があります。 新しい Azure Key Vault Managed HSM をプロビジョニングし、新しい URL を指す新しいセキュリティ ドメインを実装する必要があります。

マネージド HSM のあるインスタンスから、異なるセキュリティ ドメインを持つ別のインスタンスにキー マテリアルを移行する方法がないためです。セキュリティ ドメインの実装を十分に検討し、正確で定期的に見直す記録管理方法で保護する必要があります。

まとめ

セキュリティ ドメインとそれに対応する秘密キーには、マネージド HSM の運用に重要な役割があります。 これらの成果物は金庫の解錠番号と似ています。管理が不適切な場合、強固なアルゴリズムとシステムでも容易に侵害される可能性があります。 金庫の解錠番号が敵対者に知られると、最強の金庫でも安全ではありません。 セキュリティ ドメインとその秘密キーの適切な管理は、マネージド HSM を効果的に使うために不可欠です。

組織のセキュリティ目標を達成し、拡張するために必要なポリシー、システム、標準を開発および実装する前に、NIST Special Publication 800-57 のキー管理のベスト プラクティスを確認することを強くお勧めします。

次のステップ