次の方法で共有


Azure Key Vault の信頼性

この記事では、Azure Key Vault での信頼性のサポートについて説明します。可用性 ゾーン複数リージョンのデプロイによるリージョン内の回復性について説明します。

Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。

Key Vault は、キー、パスワード、証明書、その他の機密情報などのシークレットのセキュリティで保護されたストアを提供するクラウド サービスです。 Key Vault には、シークレットが利用可能な状態を維持できるように、複数の組み込みの信頼性機能が用意されています。 これらの機能には、リージョンの自動レプリケーション、データの冗長性、シークレットをバックアップおよび復元する機能が含まれます。

運用環境のデプロイに関する推奨事項

Key Vault の運用環境のデプロイでは、次の手順を実行することをお勧めします。

  • Standard または Premium レベルのキーボールトを使用します。

  • 論理的な削除と消去保護を有効にして、誤削除や意図的な消去を防止します。

  • 重要なワークロードの場合は、このガイドで説明されている複数リージョン戦略の実装を検討してください。

信頼性アーキテクチャの概要

ハードウェア障害やネットワーク障害が発生した場合にキー、シークレット、証明書の高い持続性と可用性を確保するために、Key Vault では、次のイベント中に可用性を維持するために複数の冗長性が提供されます。

  • ハードウェア障害
  • ネットワークの停止
  • ローカライズされた災害
  • メンテナンス アクティビティ

既定では、Key Vault はリージョン内でキー コンテナーとその内容をレプリケートすることで冗長性を実現します。

リージョンに ペアになっているリージョン があり、そのペアになっているリージョンがプライマリ リージョンと同じ地域にある場合、コンテンツもペアになっているリージョンにレプリケートされます。 この方法により、キーとシークレットの高い持続性が確保され、ハードウェア障害、ネットワーク障害、またはローカライズされた災害から保護されます。

一時的な障害

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションが一時的な障害に対処できることが重要です。これは通常、影響を受けた要求を再試行することで対処します。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

発生する可能性のある一時的なエラーを処理するには、クライアント アプリケーションが Key Vault と対話するときに再試行ロジックを実装する必要があります。 次のベスト プラクティスを検討してください。

  • 通常は組み込みの再試行メカニズムを含む Azure SDK を使用します。

  • クライアントが Key Vault に直接接続する場合は、指数バックオフ再試行ポリシーを実装します。

  • 可能な限りシークレットをメモリにキャッシュして、Key Vault への直接要求を減らします。

  • Key Vault サービスの制限を超えるとスロットリングが発生するため、スロットリングエラーを監視します。

高スループットのシナリオで Key Vault を使用する場合は、スロットリング制限を回避するために、操作を複数のキーボルトに分散することを検討してください。 次のシナリオでは、Key Vault 固有のガイダンスを検討してください。

  • 高スループットのシナリオは、Key Vault 操作の サービス制限 に近づくか超えるシナリオです (ソフトウェアで保護されたキーの場合は 1 秒あたり 200 操作など)。

  • 高スループットのワークロードの場合は、Key Vault トラフィックを複数のコンテナーと異なるリージョンに分割します。

  • すべてのトランザクションの種類に対するサブスクリプション全体の制限は、個々のキー コンテナーの制限の 5 倍です。

  • セキュリティドメインまたは可用性ドメインごとに個別のコンテナーを使用します。 たとえば、2 つのリージョンに 5 つのアプリがある場合は、10 個のコンテナーを使用することを検討してください。

  • 暗号化、ラップ、検証などの公開キー操作の場合は、公開キーマテリアルをキャッシュしてローカルでこれらの操作を実行します。

詳細については、 Key Vault の調整に関するガイダンスを参照してください。

可用性ゾーンのサポート

可用性ゾーン は、各 Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

Key Vault は、可用性ゾーンを サポートするリージョンでゾーンの冗長性を自動的に提供します。 この冗長性により、特定の構成を必要とせずに、リージョン内で高可用性を実現できます。

可用性ゾーンが使用できなくなった場合、Key Vault は、高可用性を確保するために、要求を他の正常な可用性ゾーンに自動的にリダイレクトします。

リージョンのサポート

Key Vault では、可用性ゾーンを サポートするすべての Azure リージョンで、既定でゾーンの冗長性が有効になります

要求事項

すべての Key Vault SKU (Standard および Premium) では、同じレベルの可用性と回復性がサポートされます。 ゾーンの回復性を実現するための階層固有の要件はありません。

費用

Key Vault のゾーン冗長性に関連する追加コストはありません。 価格は、SKU 、Standard または Premium、および実行された操作の数に基づいています。

通常の運用

このセクションでは、キー コンテナーが存在するリージョンに可用性ゾーンがあり、すべての可用性ゾーンが動作可能な場合に期待されることを説明します。

  • ゾーン間のトラフィック ルーティング: Key Vault は、可用性ゾーン間のトラフィック ルーティングを自動的に管理します。 通常の操作中、要求はゾーン間で透過的に分散されます。

  • ゾーン間のデータ レプリケーション: Key Vault データは、ゾーンをサポートするリージョンの可用性ゾーン間で同期的にレプリケートされます。 このレプリケーションにより、ゾーンが使用できなくなった場合でも、キー、シークレット、証明書の一貫性と使用が保証されます。

ゾーンダウン エクスペリエンス

次のセクションでは、キー ボールトが可用性ゾーンがあるが、1 つ以上が使用できないリージョンにある場合に想定される内容について説明します。

  • 検出と応答: Key Vault サービスは、ゾーンの障害を検出し、それらに自動的に応答する役割を担います。 ゾーン障害時にアクションを実行する必要はありません。

  • 通知: Azure Resource Health と Azure Service Health を使用して、キー コンテナーの状態を監視できます。 これらのサービスは、サービスの低下に関する通知を提供します。

  • アクティブな要求: ゾーン障害時に、影響を受けるゾーンが処理中の要求の処理に失敗する可能性があり、クライアント アプリケーションは要求を再試行する必要があります。 クライアント アプリケーションは、ゾーン障害が発生した場合に要求を再試行できるように、 一時的な障害処理プラクティス に従う必要があります。

  • 予想されるデータ損失: ゾーン間の同期レプリケーションにより、ゾーン障害時にデータ損失は発生しません。

  • 予想されるダウンタイム: 読み取り操作では、ゾーン障害時のダウンタイムを最小限に抑える必要があります。 書き込み操作では、サービスがゾーン障害に合わせて調整されている間、一時的に使用できなくなる可能性があります。 読み取り操作は、ゾーン障害時に引き続き使用できる状態が続くと予想されます。

  • トラフィックの再ルーティング: Key Vault は、影響を受けるゾーンから正常なゾーンにトラフィックを自動的に再ルーティングします。顧客の介入は必要ありません。

ゾーンの回復

影響を受ける可用性ゾーンが復旧すると、Key Vault はそのゾーンに操作を自動的に復元します。 Azure プラットフォームは、このプロセスを完全に管理し、顧客の介入を必要としません。

マルチリージョン サポート

Key Vault リソースは、1 つの Azure リージョンにデプロイされます。 リージョンが使用できなくなった場合、キー ボールトも使用できなくなります。 ただし、リージョンの停止に対する回復性を確保するために使用できる方法があります。 これらの方法は、キー コンテナーが存在するリージョンがペアになっているかペアになっていないか、および特定の要件と構成に依存します。

Microsoft が管理するペア リージョンへのフェールオーバー

Key Vault では、ほとんどのペアになっているリージョンのキー コンテナーに対して、Microsoft が管理するレプリケーションとフェールオーバーがサポートされています。 キー コンテナーの内容は、リージョン内で、およびペアになっているリージョンに非同期で、自動的にレプリケートされます。 この方法では、キーとシークレットの高い持続性が保証されます。 万一リージョンの障害が長引いた場合、Microsoft はキー コンテナーのリージョン フェールオーバーを開始する可能性があります。

次のリージョンでは、リージョン間での Microsoft マネージド レプリケーションまたはフェールオーバーはサポートされていません。

  • ブラジル南部
  • ブラジル南東部
  • 米国西部 3
  • ペアになったリージョンがないリージョン

Von Bedeutung

Microsoft は、Microsoft が管理するフェールオーバーをトリガーします。 これは、大幅な遅延の後に発生する可能性が高く、ベスト エフォートベースで実行されます。 このプロセスにはいくつかの例外もあります。 キー コンテナーのフェールオーバーは、他の Azure サービスのフェールオーバーの時点とは異なるタイミングで発生する可能性があります。

リージョンの停止に対する回復性が必要な場合は、代替の マルチリージョン アプローチの 1 つを使用することを検討してください。

また、バックアップと復元機能を使って、コンテナーの内容を任意の別のリージョンにレプリケートすることもできます。

考慮事項

  • ダウンタイム: フェールオーバーが実行されている間、キー コンテナーが数分間使用できなくなる可能性があります。

  • フェールオーバー後の読み取り専用: フェールオーバー後、キー コンテナーは読み取り専用になり、限定された操作のみが実行可能です。 セカンダリ リージョンでの操作中にキー コンテナーのプロパティを変更することはできません。また、セカンダリ リージョンでの操作中にアクセス ポリシーとファイアウォールの構成を変更することはできません。

    キー コンテナーが読み取り専用モードの場合、次の操作のみが実行可能です。

    • 証明書の一覧の取得
    • 証明書を取得する
    • シークレットのリスト
    • シークレットの取得
    • キーのリスト
    • キー (のプロパティ) の取得
    • Encrypt
    • 復号化
    • ラップ
    • ラップ解除
    • Verify
    • Sign
    • Backup

費用

Key Vault の組み込みのマルチリージョン レプリケーション機能に対する追加コストは発生しません。

通常の運用

次のセクションでは、キー ボルトが Microsoft が管理するレプリケーションとフェールオーバーをサポートするリージョンにあり、かつプライマリリージョンが運用中である場合に想定される内容について説明します。

  • リージョン間のトラフィック ルーティング: 通常の運用中、すべての要求は、キー ボールトがデプロイされているプライマリ リージョンにルーティングされます。

  • リージョン間のデータ レプリケーション: Key Vault は、ペアのリージョンに非同期的にデータをレプリケートします。 キー コンテナーの内容を変更すると、それらの変更は最初にプライマリ リージョンにコミットされ、次にセカンダリ リージョンにレプリケートされます。

リージョン ダウン エクスペリエンス

次のセクションでは、Microsoft が管理するレプリケーションとフェールオーバーをサポートするリージョンにキー コンテナーがあり、プライマリ リージョンで障害が発生した場合に想定される内容について説明します。

  • 検出と応答: Microsoft は、プライマリ リージョンが失われた場合にフェールオーバーを実行することを決定できます。 このプロセスは、プライマリ リージョンが失われた後に数時間かかる場合もあれば、一部のシナリオでは長くなる場合があります。 キー ボールトのフェイルオーバーは、他の Azure サービスと同時に行われない可能性があります。

  • 通知: Azure Resource Health と Azure Service Health の通知を使用して、キー コンテナーの状態を監視できます。

  • アクティブな要求: リージョンのフェールオーバー中にアクティブな要求が失敗する可能性があり、クライアント アプリケーションはフェールオーバーの完了後に再試行する必要があります。

  • 予想されるデータ損失: プライマリ リージョンが失敗する前に変更がセカンダリ リージョンにレプリケートされない場合、データ損失が発生する可能性があります。

  • 予想されるダウンタイム: プライマリ リージョンの大規模な停止中には、キー ボールトが数時間、または Microsoft がセカンダリ リージョンへのフェールオーバーを開始するまで使用できない可能性があります。

    Private Link を使用してキー コンテナーに接続している場合、リージョンのフェールオーバー後に接続が再確立されるまでに最大 20 分ほどかかることがあります。

  • トラフィックの再ルーティング: リージョンのフェールオーバーが完了すると、顧客の介入を必要とせずに、ペアになっているリージョンに要求が自動的にルーティングされます。

代替のマルチリージョン アプローチ

Key Vault の Microsoft が管理するリージョン間フェールオーバー機能が適していないシナリオがあります。

  • キー コンテナーがペアになっていないリージョン内にあります。

  • キー コンテナーが存在するペアになったリージョンが、ブラジル南部、ブラジル南東部、米国西部 3 での Microsoft が管理するリージョン間レプリケーションとフェールオーバーをサポートしていません。

  • ビジネスアップタイムの目標は、Microsoft が管理するリージョン間フェールオーバーによって提供される復旧時間やデータ損失によって満たされません。

  • プライマリ リージョンのペアではないリージョンにフェールオーバーする必要があります。

次の手順を実行して、カスタムのリージョン間フェールオーバー ソリューションを設計できます。

  1. 異なるリージョンに個別のキーボールトを作成します。

  2. バックアップと復元の機能を使用して、リージョン間で一貫したシークレットを維持します。

  3. キー ボールト間でフェールオーバーするためのアプリケーション レベルのロジックを実装します。

バックアップ

Key Vault では、個々のシークレット、キー、証明書をバックアップおよび復元できます。 バックアップは、キー コンテナーへのアクセスが失われる可能性が低い場合に、シークレットのオフライン コピーを提供することを目的としています。

バックアップ機能に関する次の重要な要因を考慮してください。

  • バックアップでは、暗号化された BLOB が作成され、Azure の外部では暗号化を解除できません。

  • バックアップは、同じ Azure サブスクリプションと Azure 地域内のキー コンテナーにのみ復元できます。

  • キー、シークレット、または証明書オブジェクトの過去 500 バージョン以下のバックアップには制限があります。

  • バックアップは特定の時点のスナップショットであり、シークレットが変更されたときに自動的に更新されることはありません。

ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、特定のシークレットの誤削除など、他の方法では行わないリスクから保護されます。 詳細については、「 Key Vault のバックアップ」を参照してください。

回復機能

Key Vault には、偶発的または悪意のある削除を防ぐための 2 つのキー回復機能が用意されています。

  • ソフト削除: ソフト削除を有効にすると、構成可能な保持期間中に削除されたボールトおよびオブジェクトを回復できます。 この期間の既定値は 90 日です。 論理的な削除は、キー コンテナー リソース用のごみ箱のようなものと考えてください。

  • 消去保護: 消去保護を有効にすると、保持期間が経過するまで、キー コンテナーとそのオブジェクトが完全に削除されるのを防ぐことができます。 このセーフガードは、悪意のあるアクターがあなたの秘密を永久に破壊するのを防ぎます。

運用環境では、両方の機能を強くお勧めします。 詳細については、Key Vault 回復管理ドキュメントの 論理的な削除と消去の保護 を参照してください。

サービス水準合意書

Key Vault のサービス レベル アグリーメント (SLA) には、サービスの予想される可用性と、その可用性の期待を達成するために満たす必要がある条件が記述されています。 詳細については、 オンライン サービスの SLA を参照してください。