Azure Key Vault Managed HSM は、FIPS 140-3 レベル 3 に検証されたハードウェア セキュリティ モジュール (HSM) を使用して、クラウド アプリケーションの暗号化キーを保護できるようにする、フル マネージドの高可用性シングルテナントの標準準拠クラウド サービスです。 Managed HSM には、キーの可用性を確保するためのさまざまな組み込み機能が備わっています。
Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、パーティションの障害、リージョンの停止など、さまざまな障害や問題に対する Managed HSM の回復性について説明します。 また、ディザスター リカバリーにバックアップとセキュリティ ドメインを使用する方法、回復機能が誤って削除されないように保護する方法、Managed HSM サービス レベル アグリーメント (SLA) に関する重要な情報についても説明します。
運用環境のデプロイに関する推奨事項
本番環境のワークロードに対しては、次のことをお勧めします。
- マネージド HSM をプロビジョニングした直後に 、セキュリティ ドメイン をダウンロードして安全に格納します。 ディザスター リカバリー用のセキュリティ ドメインが必要です。
- 少なくとも 3 つのキー所有者を持つセキュリティ ドメインのマルチユーザー クォーラムを確立します。
- 消去保護を有効にして、偶発的または悪意のある削除を防ぎます。
- Azure Storage アカウントに定期的な バックアップ を実装し、サポートされているリージョンで geo 冗長ストレージを使用します。
- より高い SLA を必要とするミッション クリティカルなワークロードの マルチリージョン レプリケーション を有効にします。
信頼性アーキテクチャの概要
Managed HSM を使用する場合は、プールと呼ばれるインスタンスをデプロイします。
Managed HSM のアーキテクチャは、高可用性と持続性を実現するように設計されています。
シングルテナントの分離: 各 Managed HSM インスタンスは、1 人の顧客専用であり、暗号化によって分離された複数の HSM パーティションのクラスターで構成されます。
トリプル冗長パーティション: マネージド HSM プールは、データセンター内の個別のラックに分散された 3 つの負荷分散 HSM パーティションで構成されます。 このディストリビューションは、ハードウェア障害に対する冗長性を提供し、ラックの電源やネットワーク スイッチなどの 1 つのコンポーネントの損失がすべてのパーティションに影響を与えることはありません。
コンフィデンシャル コンピューティング: 各サービス インスタンスは、Intel SGX エンクレーブを使用する信頼された実行環境 (TEE) で実行されます。 サーバーへの物理的なアクセス権を持つ個人を含むMicrosoft担当者は、暗号化キー マテリアルにアクセスできません。
自動復旧: ハードウェア障害またはその他の問題が 3 つのパーティションのいずれかに影響する場合、サービスは、影響を受けるパーティションを正常なハードウェア上で自動的に再構築します。ユーザーの介入やシークレットの公開は行いません。
Managed HSM でこれらの機能を実装する方法については、 Managed HSM の主権、可用性、パフォーマンス、スケーラビリティに関するページを参照してください。
セキュリティ ドメイン
セキュリティ ドメインは、ディザスター リカバリーを目的とした Managed HSM の重要なコンポーネントです。 これは、パーティション所有者キー、パーティション資格情報、データ ラッピング キー、HSM の初期バックアップなど、Managed HSM インスタンスを最初から再構築するために必要なすべての資格情報を含む暗号化された BLOB です。
Important
セキュリティ ドメインがないと、ディザスター リカバリーは実行できません。 Microsoft はセキュリティ ドメインを回復する方法がなく、それなしではキーにアクセスできません。
セキュリティ ドメインは、Managed HSM のセキュリティと信頼性の重要な部分です。 次のベスト プラクティスに従うことをお勧めします。
キーを安全に生成する: 運用環境では、オンプレミスの HSM や分離ワークステーションなどのエアギャップ環境でセキュリティ ドメインを保護する RSA キー ペアを生成します。
オフラインで保存する: 暗号化された USB ドライブまたはその他のオフライン ストレージにセキュリティ ドメイン キーを格納し、各キー共有は別の地理的な場所にある別のデバイスに保存します。
マルチユーザー クォーラムを確立します。 1 人のユーザーがすべてのクォーラム キーにアクセスできないようにし、1 人のユーザーへの依存関係を回避するには、少なくとも 3 人のキー所有者を使用します。
詳細については、「 Managed HSM のセキュリティ ドメインの概要」を参照してください。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Managed HSM と統合する Azure サービスを使用する場合、これらのサービスは一時的な障害を自動的に処理します。
Managed HSM と統合するカスタム アプリケーションを構築する場合は、発生する可能性のある一時的な障害を処理するための次のベスト プラクティスを検討してください。
組み込みの再試行メカニズムを含む、Azure Key Vault 用の Microsoft 提供の SDK を使用します。 SDK は、 .NET、 Python、 および JavaScript で使用できます。
Managed HSM と直接対話するすべてのコードに対して、指数バックオフを含む再試行ロジックを実装します。
Managed HSM に対する直接の依存関係の数を減らします。 可能な限り暗号化操作の結果をキャッシュして、Managed HSM への直接要求を減らします。 公開キーマテリアルをキャッシュして、暗号化、ラップ、検証などの公開キー操作をローカルで実行します。 操作をローカルで実行すると、Managed HSM への依存関係が減少し、一時的な障害によってこれらの操作が中断される可能性が低くなります。
高スループットのシナリオで Managed HSM を使用する場合、Managed HSM は暗号化操作を調整しません。 HSM ハードウェアを使用して容量を最大限に活用します。 各 Managed HSM インスタンスには、3 つのパーティションがあります。 メンテナンスまたは復旧操作中に、1 つのパーティションが使用できない可能性があります。 容量計画では、2 つのパーティションを使用できるものとします。 保証されたスループットが必要な場合は、使用可能な 1 つのパーティションに基づいて計画します。 Managed HSM 可用性メトリックを監視して、サービスの正常性を把握します。
大規模なデータ ボリュームの暗号化をスケーリングするには、キー階層を使用します。 マネージド HSM にキー暗号化キー (KEK) のみを格納し、それを使用して、セキュリティで保護されたキー ストレージの他の場所に格納されている下位レベルのデータ暗号化キーをラップします。
パフォーマンス ベンチマークと容量計画の詳細については、「Azure Managed HSM のスケーリング ガイダンス」を参照してください。
パーティションの障害に対する回復性
Managed HSM は、トリプル冗長アーキテクチャを通じて高可用性を実現します。各 HSM プールは、データセンター内の個別のサーバー ラックに分散された 3 つの HSM パーティションで構成されます。 このラック レベルの分散により、ローカライズされたハードウェア障害に対する冗長性が提供されます。
ハードウェア障害またはローカライズされた停止が発生すると、Managed HSM によって要求が正常なパーティションに自動的にリダイレクトされ、 機密サービス復旧と呼ばれるプロセスによって影響を受けるパーティションが再構築されます。 障害が発生したパーティションは、回復中にシークレットを保護するために、構成証明済みの TLS と Intel SGX エンクレーブを使用して正常なハードウェア上に自動的に再構築されます。
Cost
Managed HSM の組み込みの高可用性では、追加コストは発生しません。 価格は、HSM プールの数と実行する操作の数に基づいています。 詳細については、「Azure Managed HSM の価格」を参照してください。
すべてのパーティションが正常な場合の動作
このセクションでは、Managed HSM プールが操作可能であり、パーティションが使用できない場合に想定される内容について説明します。
トラフィック ルーティング: Managed HSM は、3 つのパーティション間のトラフィック ルーティングを自動的に管理します。 通常の操作では、パーティション間で要求が透過的に分散されます。
データ レプリケーション: Managed HSM は、キー、ロールの割り当て、アクセス制御ポリシーなど、すべてのデータを 3 つのパーティションすべてに同期的にレプリケートします。 この方法では、パーティションが使用できなくなった場合でも、一貫性と可用性が確保されます。
パーティション障害時の動作
このセクションでは、1 つ以上のパーティションが使用できなくなった場合に想定される内容について説明します。
検出と応答: Managed HSM サービスは、パーティションの障害を検出し、それらに自動的に応答します。 パーティション障害時にアクションを実行する必要はありません。
アクティブな要求: パーティション障害時に、影響を受けるパーティションへの処理中の要求が失敗し、クライアント アプリケーションで再試行が必要になる場合があります。 パーティションの停止の影響を最小限に抑えるために、クライアント アプリケーションは 一時的な障害処理プラクティスに従う必要があります。
予想されるデータ損失: パーティション間の同期レプリケーションにより、パーティションの障害時にデータ損失は発生しません。
予想されるダウンタイム: 読み取り操作とほとんどの暗号化操作では、パーティションの障害時にダウンタイムを最小限に抑えるか、ダウンタイムを発生させてはなりません。 残りの正常なパーティションは引き続き要求を処理します。
トラフィックの再ルーティング: Managed HSM は、影響を受けるパーティションから正常なパーティションにトラフィックを自動的に再ルーティングします。お客様の介入は必要ありません。
パーティションの回復
影響を受けるパーティションが復旧すると、Managed HSM は機密サービス復旧によって操作を自動的に復元します。 このプロセス:
- 正常なハードウェアに新しいサービス インスタンスを作成します。
- プライマリ パーティションとの認証済み TLS 接続を確立します。
- 資格情報と暗号化マテリアルを安全に交換します。
- サービス データを新しい CPU にシールします。
Azure プラットフォームは、このプロセスを完全に管理し、顧客の介入を必要としません。
可用性ゾーンの障害に対する回復性
Managed HSM の高可用性は、明示的な可用性ゾーンのデプロイではなく、データセンター内のラックレベルの分散に基づいています。 各パーティションは、異なるラック内の個別のサーバー上で実行されます。これにより、電源やネットワーク スイッチの問題などのラック レベルの障害から保護されます。
データセンター全体または可用性ゾーン全体の障害から保護するには、「 リージョン全体の障害に対する回復性」で説明されているいずれかの方法を使用します。
リージョン全体の障害に対する回復性
Managed HSM リソースは、単一の Azure リージョンにデプロイされます。 リージョンが使用できなくなった場合、Managed HSM も使用できなくなります。 ただし、リージョンの障害に対する回復性を確保するために使用できる方法があります。
複数リージョンのレプリケーション
Managed HSM では、オプションのマルチリージョン レプリケーションがサポートされています。これは、Managed HSM プールを 1 つのAzure リージョン (プライマリ リージョン) から 2 つ目のAzure リージョン (拡張リージョン) に拡張するために使用できます。 この機能を構成する場合:
- どちらのリージョンもアクティブであり、要求を処理できます。
- キー マテリアル、ロール、およびアクセス許可は、リージョン間で自動的にレプリケートされます。
- Azure Traffic Managerは、使用可能な最も近いリージョンに要求をルーティングします。
- 組み合わされた SLA が向上します。
Requirements
リージョンのサポート: Managed HSM をサポートするすべてのリージョンをプライマリ リージョンとして使用できます。 Azure リージョンのペアリングには依存関係がありません。
Managed HSM では、すべてのリージョンが拡張リージョンとしてサポートされているわけではありません。 詳細については、Azure リージョンのサポートに関する ページを参照してください。
リージョンの最大数: 合計で最大 2 つのリージョンに対して、1 つの拡張リージョンを追加できます。
Cost
複数リージョンレプリケーションでは、拡張リージョンが 2 つ目の HSM プールを使用するため、追加の課金が発生します。 詳細については、「Azure Managed HSM の価格」を参照してください。
複数リージョンのレプリケーションを構成する
拡張リージョンを追加します。 拡張リージョンを既存のプライマリ リージョンに追加する方法の詳細については、「 拡張リージョンへのプライマリ HSM の拡張」を参照してください。
Managed HSM を別のリージョンに拡張するには、最大で 30 分かかる場合があります。
拡張リージョンを削除します。 既存のプライマリ リージョンから拡張リージョンを削除する方法の詳細については、「 プライマリ HSM からの拡張リージョンの削除」を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、マルチリージョン レプリケーションを構成し、両方のリージョンが動作する場合に想定される内容について説明します。
トラフィック ルーティング: すべてのリージョンで要求を処理できます。 Azure Traffic Manager は、最も近い地理的または最も短い待機時間でリージョンに要求をルーティングします。
Azure Private Linkを使用して Managed HSM にアクセスする場合は、フェールオーバー中に最適なルーティングを行うために、両方のリージョンでプライベート エンドポイントを構成します。 詳細については、 マルチリージョン レプリケーションでのプライベート リンクの動作に関するページを参照してください。
データ レプリケーション: キー、ロール定義、ロールの割り当てに対するすべての変更は、6 分以内に拡張リージョンに非同期的にレプリケートされます。 キーを作成または更新してから 6 分間待ってから、拡張リージョンでキーを使用します。
リージョン障害時の動作
このセクションでは、マルチリージョン レプリケーションを構成し、いずれかのレプリカ リージョンで障害が発生した場合に想定される内容について説明します。
- 検出と応答: Azure Traffic Managerは異常なリージョンを検出し、将来の要求を正常なリージョンにルーティングします。 DNS レコードの有効期間は 5 秒 (TTL) ですが、DNS 参照をキャッシュしているクライアントではフェールオーバー時間が若干長くなる可能性があります。
- Notification: Microsoft は、リージョンがダウンしたときに自動的にあなたに通知しません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: 影響を受けるリージョンへの送信中の要求は失敗し、再試行が必要になる場合があります。
予想されるデータ損失: リージョンの障害が発生する 6 分以内に行われた変更は、拡張リージョンにレプリケートされない可能性があります。 プライマリ リージョンが回復不能な場合、これらの変更は失われる可能性があります。
予想されるダウンタイム: 読み取りと書き込みの両方の操作は、フェールオーバー中に正常なリージョンで引き続き使用できます。
異常なリージョンに近いクライアント アプリケーションは、DNS レコードが更新されるまで引き続きそのリージョンに送信される可能性がありますが、この更新は約 5 秒以内に行われます。 フェールオーバー時間を最小限に抑えるために、クライアントは DNS レコードの TTL よりも長い間 DNS 参照をキャッシュしないようにする必要があります。
ルーティング： Azure Traffic Manager は、正常なリージョンに要求を自動的に再ルーティングします。
リージョンの復旧
影響を受けるリージョンが復旧すると、Managed HSM によって操作が自動的に再開されます。 Azure Traffic Managerは、近接性に基づいて、両方のリージョンへの要求のルーティングを再度開始します。
リージョン障害のテスト
Managed HSM は、リージョンの障害に対するトラフィック ルーティング、フェールオーバー、フェールバックを完全に管理するため、リージョンの障害プロセスを検証したり、それ以上入力したりする必要はありません。
回復性のためのカスタム マルチリージョン ソリューション
複数リージョンのレプリケーションがニーズに適していない場合は、手動ディザスター リカバリーを実装できます。 この方法では、次のものが必要です。
- ソース HSM のセキュリティ ドメイン。
- セキュリティ ドメインを暗号化する秘密キー (少なくともクォーラム番号)。
- ソース HSM からの最近の完全な HSM バックアップ。
ディザスター リカバリーを実行するには:
- 別のリージョンに新しい Managed HSM インスタンスを作成します。
- セキュリティ ドメイン回復モードをアクティブ化し、セキュリティ ドメインをアップロードします。
- 新しい HSM のバックアップを作成します (復元前に必要)。
- ソース HSM からバックアップを復元します。
Important
新しい HSM の名前とサービス エンドポイント URI は異なります。 新しい場所を使用するには、アプリケーション構成を更新する必要があります。
ディザスター リカバリーの詳細な手順については、 Managed HSM のディザスター リカバリーに関する記事を参照してください。
バックアップと復元
Managed HSM では、すべてのキー、バージョン、属性、タグ、ロールの割り当ての完全バックアップと復元がサポートされます。 バックアップは Azure Storage アカウントに格納されます。 リージョンでサポートされている場合は、geo 冗長ストレージ (GRS) が有効になっているAzure Storage アカウントにマネージド HSM をバックアップすることをお勧めします。
HSM は、HSM のセキュリティ ドメインに関連付けられている暗号化キーを使用してバックアップを暗号化します。 バックアップは、同じセキュリティ ドメインを持つ HSM にのみ復元できます。
Managed HSM ではバックアップのスケジュール設定はサポートされていませんが、Azure Functions や Azure Automation などのサービスを使用して独自のスケジューラを構築できます。
バックアップの進行中は、一部のパーティションがバックアップ操作の実行をビジー状態にしているため、HSM が完全なスループットで動作しない可能性があります。
バックアップと復元の手順の詳細については、 完全バックアップと復元に関する記事を参照してください。
誤削除に対する回復性
Managed HSM には、偶発的または悪意のある削除を防ぐための 2 つの主要な回復機能が用意されています。
論理的な削除: 削除された HSM とキーは直ちに消去されません。 これらは、7 ~ 90 日 (既定: 90 日間) の構成可能なリテンション期間の間、回復可能なままになります。 論理的な削除は常に有効になっており、無効にすることはできません。
Note
論理的に削除された Managed HSM リソースは、消去されるまで引き続き課金されます。
消去保護: 有効にすると、保持期間が経過するまで、Managed HSM とそのキーが完全に削除されません。 消去保護は、Microsoft を含むだれでも無効にしたりオーバーライドしたりすることはできません。
運用環境で消去保護を有効にすることを強くお勧めします。 詳細については、 Managed HSM の論理的な削除と消去の保護に関する記事を参照してください。
サービス メンテナンスに対する回復性
Managed HSM は、お客様の介入なしに、ファームウェアの更新、修正プログラムの適用、ハードウェア復旧などのサービス メンテナンスを処理します。 メンテナンス中:
- 更新プログラムの適用中に、サービスによってパーティションが一時的に使用できなくなる場合があります。
- 定期的なメンテナンス中は、3 つのパーティションのうち少なくとも 2 つを使用できます。
- クライアント アプリケーションでは、短い中断を処理するための再試行ロジックを実装する必要があります。
機密サービスの復旧プロセスにより、メンテナンス操作中にサービスがシークレットを公開することは決してありません。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。
Managed HSM は、単一リージョンのデプロイに対する標準の可用性 SLA を提供します。 複数リージョンのレプリケーションを有効にすると、要求が使用できなくなった場合に、いずれかのリージョンから要求を処理できるため、全体的に予想されるアップタイムが上がります。