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 の主権、可用性、パフォーマンス、スケーラビリティ」を参照してください。
セキュリティ ドメイン
セキュリティ ドメインは、ディザスター リカバリーの重要なコンポーネントです。 これは、パーティション所有者キー、パーティション資格情報、データ ラッピング キー、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 可用性メトリックを監視して、サービスの正常性を把握します。
大量のデータの暗号化をスケーリングするには、キー暗号化キー (KEK) のみが Managed HSM に格納され、別のセキュリティで保護されたキーの保存場所に格納されている下位レベルのキーをラップするために使用されるキー階層を使用します。
パフォーマンス ベンチマークと容量計画のガイダンスの詳細については、 Azure Managed HSM のスケーリング ガイダンスに関するページを参照してください。
パーティションの障害に対する回復性
Managed HSM は、トリプル冗長アーキテクチャを通じて高可用性を実現します。各 HSM プールは、データセンター内の個別のサーバー ラックに分散された 3 つの HSM パーティションで構成されます。 このラック レベルの分散により、ローカライズされたハードウェア障害に対する冗長性が提供されます。
Managed HSM プールの 3 つのパーティションを示す図。各パーティションは、個別の物理サーバーと異なるサーバー ラックにあります。
ハードウェア障害またはローカライズされた停止が発生すると、Managed HSM によって要求が正常なパーティションに自動的にリダイレクトされ、 機密サービス復旧と呼ばれるプロセスによって影響を受けるパーティションが再構築されます。 障害が発生したパーティションは、回復中にシークレットを保護するために、構成証明済みの TLS と Intel SGX エンクレーブを使用して正常なハードウェアに自動的に再構築されます。
Cost
Managed HSM の組み込みの高可用性に関連する追加コストはありません。 価格は、HSM プールの数と実行された操作の数に基づいています。 詳細については、「Azure Managed HSM の価格」を参照してください。
すべてのパーティションが正常な場合の動作
このセクションでは、Managed HSM プールが操作可能であり、パーティションが使用できない場合に想定される内容について説明します。
トラフィック ルーティング: Managed HSM は、3 つのパーティション間のトラフィック ルーティングを自動的に管理します。 通常の操作では、要求はパーティション間で透過的に分散されます。
データ レプリケーション: キー、ロールの割り当て、アクセス制御ポリシーを含むすべてのデータが、3 つのパーティションすべてに同期的にレプリケートされます。 これにより、パーティションが使用できなくなった場合でも、一貫性と可用性が確保されます。
パーティション障害時の動作
このセクションでは、1 つ以上のパーティションが使用できなくなった場合に想定される内容について説明します。
検出と応答: Managed HSM サービスは、パーティションの障害を検出し、それらに自動的に応答します。 パーティション障害時にアクションを実行する必要はありません。
アクティブな要求: パーティション障害時に、影響を受けるパーティションへの処理中の要求が失敗し、クライアント アプリケーションで再試行が必要になる場合があります。 パーティションの停止の影響を最小限に抑えるために、クライアント アプリケーションは 一時的な障害処理プラクティスに従う必要があります。
予期されるデータ損失: パーティション間の同期レプリケーションにより、パーティション障害時にデータ損失は発生しません。
予想されるダウンタイム: 読み取り操作とほとんどの暗号化操作では、パーティションの障害時にダウンタイムを最小限に抑える必要があります。 残りの正常なパーティションは引き続き要求を処理します。
トラフィックの再ルーティング: マネージド HSM は、影響を受けるパーティションから正常なパーティションにトラフィックを自動的に再ルーティングします。お客様の介入は必要ありません。
パーティションの回復
影響を受けるパーティションが復旧すると、Managed HSM は機密サービス復旧によって操作を自動的に復元します。 このプロセス:
- 正常なハードウェアに新しいサービス インスタンスを作成します。
- プライマリ パーティションとの認証済み TLS 接続を確立します。
- 資格情報と暗号化マテリアルを安全に交換します。
- サービス データを新しい CPU にシールします。
Azure プラットフォームは、このプロセスを完全に管理し、顧客の介入を必要としません。
可用性ゾーンの障害に対する回復性
マネージド HSM の高可用性は、明示的な可用性ゾーンのデプロイではなく、データセンター内のラックレベルの分散に基づいています。 各パーティションは、異なるラック内の個別のサーバー上で実行され、電源やネットワーク スイッチの問題などのラック レベルの障害から保護されます。
データセンター全体または可用性ゾーン全体の障害に対する回復性が必要な場合は、 リージョン全体の障害に対する回復性の方法の 1 つを使用することを検討してください。
リージョン全体の障害に対する回復性
Managed HSM リソースは、単一の Azure リージョンにデプロイされます。 リージョンが使用できなくなった場合、Managed HSM も使用できなくなります。 ただし、リージョンの障害に対する回復性を確保するために使用できる方法があります。
複数リージョンのレプリケーション
Managed HSM では、オプション のマルチリージョン レプリケーションがサポートされています。これにより、Managed HSM プールを 1 つの Azure リージョン ( プライマリ リージョン) から 2 番目の Azure リージョン ( 拡張リージョン) に拡張できます。 構成が完了したら、次の手順を実行します
- どちらのリージョンもアクティブであり、要求を処理できます。
- キー マテリアル、ロール、およびアクセス許可は、リージョン間で自動的にレプリケートされます。
- 要求は、Azure Traffic Manager を使用して、使用可能な最も近いリージョンにルーティングされます。
- 組み合わされた SLA が向上します。
Requirements
リージョンのサポート: すべての Azure Managed HSM リージョンがプライマリ リージョンとしてサポートされます。 Azure リージョンのペアリングには依存関係がありません。
Managed HSM では、すべてのリージョンが拡張リージョンとしてサポートされているわけではありません。 詳細については、Azure リージョンのサポートに関する ページを参照してください。
リージョンの最大数: 合計で最大 2 つのリージョンに対して、1 つの拡張リージョンを追加できます。
Cost
複数リージョンレプリケーションでは、拡張リージョンで 2 つ目の HSM プールが使用されるため、追加の課金が発生します。 詳細については、「Azure Managed HSM の価格」を参照してください。
複数リージョンのレプリケーションを構成する
拡張リージョンを追加します。 拡張リージョンを既存のプライマリ リージョンに追加する方法の詳細については、「 拡張リージョンへのプライマリ HSM の拡張」を参照してください。
Managed HSM を別のリージョンに拡張するには、最大で 30 分かかる場合があります。
拡張リージョンを削除します。 既存のプライマリ リージョンから拡張リージョンを削除する方法の詳細については、「 プライマリ HSM からの拡張リージョンの削除」を参照してください。
すべてのリージョンが正常な場合の動作
マルチリージョン レプリケーションが有効で、両方のリージョンが動作している場合:
トラフィック ルーティング: すべてのリージョンで要求を処理できます。 Azure Traffic Manager は、最も近い地理的または最も短い待機時間でリージョンに要求をルーティングします。
Private Link を使用する場合は、フェールオーバー中に最適なルーティングを実現するために、両方のリージョンでプライベート エンドポイントを構成します。 詳細については、 マルチリージョン レプリケーションでのプライベート リンクの動作に関するページを参照してください。
データ レプリケーション: キー、ロール定義、ロールの割り当てに対するすべての変更は、6 分以内に拡張リージョンに非同期的にレプリケートされます。 キーを作成または更新してから 6 分間待ってから、拡張リージョンでキーを使用します。
リージョン障害時の動作
複数リージョンのレプリケーションが有効になっていて、1 つのリージョンで障害が発生した場合:
- 検出と応答: 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 によって操作が自動的に再開されます。 Traffic Manager は、近接性に基づいて、両方のリージョンへの要求のルーティングを再度開始します。
リージョン障害のテスト
Managed HSM は、リージョンの障害に対するトラフィック ルーティング、フェールオーバー、フェールバックを完全に管理するため、リージョンの障害プロセスを検証したり、それ以上入力したりする必要はありません。
回復性のためのカスタム マルチリージョン ソリューション
複数リージョンのレプリケーションがニーズに適していない場合は、手動ディザスター リカバリーを実装できます。 これには、次のことが必要です。
- ソース HSM のセキュリティ ドメイン。
- セキュリティ ドメインを暗号化する秘密キー (少なくともクォーラム番号)。
- ソース HSM からの最近の完全な HSM バックアップ。
ディザスター リカバリーを実行するには:
- 別のリージョンに新しい Managed HSM インスタンスを作成します。
- セキュリティ ドメイン回復モードをアクティブ化し、セキュリティ ドメインをアップロードします。
- 新しい HSM のバックアップを作成します (復元前に必要)。
- ソース HSM からバックアップを復元します。
Important
新しい HSM の名前とサービス エンドポイント URI は異なります。 新しい場所を使用するには、アプリケーション構成を更新する必要があります。
ディザスター リカバリーの詳細な手順については、 Managed HSM のディザスター リカバリーに関する記事を参照してください。
バックアップと復元
Managed HSM では、すべてのキー、バージョン、属性、タグ、ロールの割り当ての完全バックアップと復元がサポートされます。 バックアップは Azure Storage アカウントに格納されます。 リージョンでサポートされている場合は、geo 冗長ストレージ (GRS) が有効になっている Azure Storage アカウントに Managed 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 を提供します。 複数リージョンのレプリケーションを有効にすると、両方のリージョンの SLA の組み合わせが増加します。