高可用性とディザスタリカバリを理解する Key Protect

IBM® Key Protect for IBM Cloud® は、高度に使用可能な地域サービスで、アプリケーションを保護して作動させるための自動機能を備えています。

Key Protect の高可用性およびデータの災害復旧は、IBM Cloud と Key Protect によって保証されます。ユーザーの過失による削除から復旧することは「災害復旧」に含まれないので注意してください。

地域をまたいだ災害復旧は、地域をまたいだサポートを含む料金プランのインスタンスでのみ利用可能です。地域災害イベントの前に、インスタンスをクロスリージョナルプランの下に構成していなかった場合、重要なアクションが中断される可能性があります。

場所、テナント、可用性

Key Protect はマルチテナントの地域サービスです。

Key Protect リソースは、サポートされているいずれかの IBM Cloud 地域に作成できます。これらの地域は、Key Protect の要求が扱われて処理される地理上のエリアを表します。 IBM Cloud の各リージョンには複数のアベイラビリティ・ゾーンがあり、ローカル・アクセス、低レイテンシ、セキュリティの各要件を満たしている。

us-south （米国テキサス州ダラス所在）、 jp-tok （日本東京所在）、 eu-de （ドイツ・フランクフルト所在）の3つの地域があり、 Key Protect は、クロスリージョンレジリエンス料金プランを選択した場合に、データがスタンバイインフラストラクチャに複製される別の地域へのフェイルオーバーサポートを提供しています。 us-south リージョンは us-east リージョン（米国ワシントンDC所在）に、 jp-tok リージョンは jp-osa リージョン（日本大阪所在）に、 eu-de リージョンはパリリージョンのデータセンターにデータがレプリケートされる。つまり、 us-south、 jp-tok、 eu-de のサービスが中断した場合、これらのリージョンにある Key Protect へのリクエストは、すでにデータが複製されているリージョンにルーティングされる。

フェールオーバー対応の地域におけるスタンバイインフラストラクチャは、その地域で利用可能な Key Protect サービスとは完全に別物であり、フェールオーバーは一方向のみでアクティブ-パッシブ方式で行われることにご注意ください。つまり、メインの地域がダウンした場合にのみ、クロス地域のサーバーがリクエストを処理します。例えば、 us-east にあるあなたのデータは、現在 us-south にはレプリケートされていません。

Key Protect の目標復旧時点（RPO）と目標復旧時間（RTO）は、それぞれ1時間未満、9時間未満（地域障害の場合）です。

要求は自動的にルーティングされるため、引き続き元のエンドポイントを呼び出すことができます。最初は、読み取り専用の操作しか実行できません。ただし、中断が長期間続くと想定される根拠がある場合には、できる限り早く書き込み操作が有効化されます。それ以外の場合は、書き込み操作が有効になるまでの最大6時間は、読み取り専用操作しかできない。

IBM Cloud を利用して暗号化戦略を計画するときには、通常、最も近いリージョンに Key Protect をプロビジョニングすると、Key Protect API と対話するときの接続の速度と信頼性が高くなることに留意してください。さらに、規制要件によって、使用すべきリージョンが決まる場合もあります。 Key Protect では、複数のリージョンおよび地理的位置をまたいで鍵を使用することが禁止されていないことに注意してください。例えば、us-south にある鍵を使用して、フランクフルトにあるストレージを暗号化することができます。 ユースケース全体にとって最適なリージョンを選択してください。

アプリケーション・レベルの高可用性

ルート鍵を Key Protect にインポートする場合は、ルート鍵が誤って削除され、削除された鍵を復元するための 30 日の猶予期間が経過しても復元できるように、鍵素材のセキュア・バックアップを維持することをお勧めします。言い換えると、30 日以内であれば、バックアップを使用することなく、削除した鍵を Key Protect で復元することができます。

同じ鍵素材を使用して作成された 2 つの鍵は、実質的に同じ鍵であるため (どちらのルート鍵で作成されたデータ暗号鍵 (DEK) であろうと、両方の鍵で DEK をアンラップできます)、インスタンス内にインポートされたすべてのルート鍵について複製鍵を作成することで、ルート鍵をセキュアにバックアップできます。各複製鍵は、元の鍵とは異なる Key Protect リージョンに作成する必要があります。そのため、その鍵の key_id とサービス・インスタンス ID は異なるものになります。したがって、両方の鍵の該当する ID とエンドポイントが既知であれば、アプリケーションではどちらの鍵も使用できます。

ルート鍵がローテートされるたびに新しい鍵素材が鍵に追加され、新しいバージョンの鍵が作成されることに注意してください。そのため、複製鍵をローテーションするときは、必ずその更新された鍵素材を使用してください。

ネットワークを介して通信するアプリケーションは、一時的な障害の影響を受けやすいものです。例えば、要求の実行間隔を指数関数的に長くしながら要求の再試行を行う指数関数的バックオフなど、最新の耐障害手法を使用して Key Protect と対話するように、アプリケーションを設計する必要があります。

アルゴリズムの例

指数バックオフ・ロジックを使用して再試行を実装するには、さまざまなアプローチがあります。使用するアプローチは、具体的なユース・ケースと、ご使用のアプリケーションを取り巻くネットワーク状態によって異なります。インクリメンタル再試行遅延の実装例を以下に示します。

const maxRetries = 3
attempt := 1
delay := time.Second * 1
var ok bool
for !ok && attempt <= maxRetries {
    ok = makeRequest()
    if !ok {
        time.Sleep(delay)
        delay = delay * 2
        attempt += 1
    }
}

再試行の最大回数に達し、アプリケーションで発生しているエラーが Key Protect サポートチケットをサポートチケットをクリックしてください。

ディザスター・リカバリー

Key Protect は、災害イベントの計画と復旧に関する IBM Cloud の要件に従います。

プライベート・エンドポイント設定 (特に Internet Protocol (IP) アドレス) は、災害復旧と事業継続性のアクション中に手動で更新する必要がある場合があります。

鍵とワークロードの保守においてお客様と IBM が分担する責任について詳しくは、Key Protect を使用する際の責任についてを参照してください。