3 データの回復

障害回復とは、自然災害または人災のあとに組織の業務にとって重要な情報を回復または継続するための準備に関連する、プロセス、ポリシー、および手順です。これには、次が含まれます。

回復時点目標 (RPO、Recovery Point Objective): 業務継続計画の定義に従ってデータを回復させる時点。これは一般に、その業務で決定することを障害時に「どこまで喪失することが許されるか」を定義することです。これは、時、日、または週単位で指定できます。
回復時間目標 (RTO、Recovery Time Objective): 業務継続の中断に関連する許容できない結果を回避するために、障害 (または中断) のあとに業務プロセスを「復元」する必要のある期間。結合されたサービスネットワークを使用しているときは、これは分単位になる可能性があります。図 3-2 を参照してください。

OKM は、地理的に分離された複数のサイトにまたがることができます。これにより、クラスタ全体が破壊される障害のリスクが大幅に小さくなります。KMA のクラスタ化により、データベースエントリのレプリケーションと作業負荷の分散が可能になります。万一、クラスタ全体を再作成する必要がある場合でも、最近のデータベースバックアップから OKM 環境を再作成することで、ほとんどの鍵データを回復できます。

暗号化およびアーカイブ戦略を設計するときの非常に重要な設計要素は、どこかのサイトで生成された重要データは、回復サイトにレプリケートして保管することです。

サイトが失われた場合は、このバックアップデータを別の稼働サイトへ移すことができます。テープボリュームに関連付けられたデータユニットおよび鍵は、姉妹サイトの KMA に通知され、業務継続に必要な暗号化されたデータを利用できるようになります。

クラスタの損害を受けた部分は、サイトの運用が再開すると同じ場所または異なる場所に簡単に復元できます。

多くの会社は、サードパーティーの障害回復 (DR) サイトのサービスを採用することで、できるだけ早く業務を再開できるようにしています。定期的に予告なしの DR テストを実施することで、障害、自然災害、または人的災害から企業が回復する準備がどの程度できているのかをデモします。考えられるシナリオは数多くありますが、ここではその一部を取り上げます。

共有リソース	障害回復に費用対効果の高い要素を提供
レプリケーション	損失がない KMA からのレプリケーションによる復元
シナリオ 1	KMA の事前配置
シナリオ 2	KMA の共有
シナリオ 3	鍵転送
シナリオ 4	バックアップからの復元
バックアップ手法	役に立つガイドライン

バックアップおよび鍵共有に関する考慮事項

OKM のバックアップおよび鍵共有 (インポート/エクスポート) は、データベースに負荷がかかり、バックアップまたは鍵転送操作を実行中の KMA では応答時間が低下します。

可能な場合は、OKM バックアップおよび転送期間中は、テープドライブの作業負荷を減少してください。

可能でない場合は、次のオプションを検討してください。

OKM バックアップおよび鍵転送は、どの KMA でも実行することができますが、ベストプラクティスは毎回同じ KMA を使用することです。たいていの場合、OKM バックアップユーティリティーを呼び出す cron ジョブが何らかの方法で設定されることになります。
クラスタが十分大きい場合は、1 つの KMA を管理 KMA 専用にできます。
- この KMA は、どのようなときでも (特にバックアップまたは鍵転送期間中に) テープドライブ鍵リクエストに煩わされることがないように、サービスネットワーク接続を設定しないでください。
- この KMA は、OKM GUI セッションでも使用することができるため、その他の KMA を管理関連のリクエスト処理からオフロードします。
バックアップおよび鍵転送 KMA の管理ネットワーク接続が高速になるほど、バックアップおよび鍵転送期間中の負荷増大への対応が向上します。

これはすべての KMA に該当しますが、特にバックアップを実行する KMA に当てはまります (バックアップ期間中のレプリケーションリクエストへの対処が遅れるため)。高速なネットワーク接続を使用すると、レプリケーションのバックログ (ラグなど) を最小化できます。
バックアップおよび鍵転送 KMA は、テープドライブによって使用されないサイトに配置します。これにより、テープドライブは、割り当てられているサイト内のほかの KMA を優先し、バックアップおよび鍵転送 KMA を使用しなくなります。
テープドライブが含まれるサイトに多くの KMA を追加して、鍵リクエストの負荷分散が多くの KMA 間で行われるようにします。これにより、バックアップおよび鍵転送 KMA が処理する必要のある鍵リクエストの数が減少します。

鍵プールサイズの決定

OKM 管理者は、時間単位あたり、および OKM バックアップ期間または鍵転送期間中に作成が想定される鍵の数について最悪のケースを知っておく必要があります。

この説明では、1 時間当たりの鍵消費率を計算済みであることを前提とします。

注:

KMA は鍵を事前に生成しておくため、鍵プールのメンテナンスプログラムがサーバー内で実行されるまで、エージェントからの鍵作成リクエストによって実際に KMA で鍵が作成されるわけではありません。サーバーがビジーの場合、鍵プールメンテナンスプログラムの動作が遅れることがあります。

合計の鍵プールサイズは、KMA がバックアップ期間中に鍵プールから事前生成された鍵を渡すことができる程度に大きい必要があります。

鍵プールサイズが小さすぎると、KMA は事前に生成された鍵を使い果たしてしまい、準備の完了した鍵がないというエラーを返し始めることがあります。これが発生すると、テープドライブはほかの KMA にフェイルオーバーし、バックアップ/鍵転送期間のパフォーマンスの課題がさらに混乱してしまいます。

デフォルトの鍵プールサイズである 1000 の鍵は、バックアップ期間の鍵作成率について見積もられた最悪ケースがこれを超えないかぎり、ほとんどの顧客にとって十分です。

OKM バックアップ期間は、データベースが大きくなるにつれて徐々に拡大するため、定期的に観察してください。バックアップ期間がしきい値を超えると、鍵プールサイズの調整が必要になることがあります。また、全体的なテープの作業負荷が変化したために鍵消費率が上がる場合も、鍵プールサイズを調整してください。

共有リソース

共有リソースは、障害回復に費用対効果の高い要素を提供できます。

レコード管理、データ破棄、データの継続性および回復に特化した企業では、複数の顧客がバックアップおよびアーカイブを始めとしたさまざまな理由で使用できる機器を購入します。

障害回復では、顧客は共有リソースサイトからのテープドライブ、ライブラリ、およびその他のリソースを障害回復テストのために、または実際に障害から回復するために、短期間使用できます。

障害回復および鍵管理には 2 つのアプローチがあります。

顧客は KMA を DR サイトに配置し、WAN 接続を使用して本番クラスタへと構成できます。これらの KMA は、特定の顧客に専用のものであり、その顧客の鍵は常に DR サイトにあって使用できる状態にできます。

このアプローチでは、顧客がテープドライブを共有リソースサイトの KMA に登録して OKM クラスタに参加すると、回復を開始できます。

これは、OKM GUI を DR サイトの DMA に接続することで行うことができます。実際の障害回復シナリオでは、これらが顧客のクラスタの残りの KMA だけであることがあります。

ドライブの登録は、数分以内に完了できます。登録が完了すると、ドライブが構成されていれば、テープの本番を開始できます。
別の方法は、顧客の本番 OKM のバックアップを共有リソースサイトで提供される KMA に復元することです。これにより、広域ネットワーク (WAN) およびオンサイトの専用 KMA は不要になりますが、データベースを復元するための追加時間が必要です。

このアプローチでは、復元操作に通常の OKM バックアップファイルとコアセキュリティーバックアップの両方が必要です。この復元アプローチでは、コアセキュリティーバックアップの鍵分割資格メンバーの定足数が必要です。

復元操作には、100,000 鍵あたり約 20 分かかります。

復元が完了したら、ドライブを登録および構成する必要があります。

3 つのファイルを DR サイトに移す必要があります。
- コアセキュリティーバックアップファイル
- .xml バックアップファイル
- .dat バックアップファイル
これらのファイルは、バックアップ責任者によって作成されます。

ほかのサイトからのレプリケーション

図 3-1 および図 3-2 は、2 つの地理的に離れたサイトの例を示しています。1 つの OKM クラスタがあり、クラスタには 4 つの KMA (各サイトに 2 つの KMA) があります。

初期インストール時に、1 つめの KMA が構成されたあとで、追加の KMA (新規または交換) はクラスタ内のほかの KMA から自己レプリケートします。

1 つ以上の KMA が動作し続けているかぎり、クラスタの残りに影響を与えることなく 1 つの KMA を回復させることができます。

図 3-1 は、回復時点目標の例です。この例で、業務継続性をサイト全体に回復させる時点には、数か月かかることがあります。

サイト 1 は破壊されたが、サイト 2 は損失がない場合:

顧客は、クラスタの KMA およびテープドライブを含む、破壊されたインフラストラクチャー機器を交換する必要があります。

サイトが復元され、機能した場合:
- 新しい KMA をインストールおよび作成します (セキュリティー責任者および定足数が必要です)。
- 新しい KMA について 1 回に 1 つずつ既存のクラスタに参加します。
- 新しいテープドライブをインストールおよびアクティブ化します。
- 新しいテープドライブを登録します (これでエージェントと呼ばれます)。
これでサイト 1 は、損失がないサイト 2 で残っている KMA から自己レプリケートします。

図 3-2 は、回復時間目標の例です。この例で、業務継続性を回復させるための時間は、数分程度です。

サイト 1 の KMA は破壊されたが、サイト 2 のインフラストラクチャーは損失がない場合:

2 つのサイト間でテープドライブを接続する広域「サービス」ネットワークでは、サイト 2 からの損失がない KMA は、両方のサイト間のテープ操作を続行できます。

サイト 1 で KMA が交換されると、前述の説明と同様に、これらは損失がないサイト 2 で残っている KMA から自己レプリケートします。

QuickStart プログラム中に、顧客は次を選択します。

(2) Join Existing Cluster

新しい KMA ごとに 1 回に 1 つずつ行います。

図 3-1 ほかのサイトからのレプリケーション - 回復時点目標

図 3-2 サービスネットワークの継続 - 回復時間目標

シナリオ 1: KMA の事前配置

このシナリオでは、顧客には複数サイトの大環境があります。各サイトは次を使用します。

KMA のペア、および自動テープ暗号化をサポートするインフラストラクチャー
すべての KMA が鍵を共有する単一クラスタ。

複数のサイト間で、この顧客は、顧客の OKM クラスタの一部である障害回復 (DR) サイトで機器の保守および使用も行います。

このシナリオについては、図 3-3 を参照してください。

この顧客は、次で構成される単純なバックアップスキームを使用します。

日次の増分バックアップ
週次の差分バックアップ
月次のフルバックアップ。

月次バックアップは、DR サイトで複製され、オフサイトのストレージ施設に送信され、90 日間保管されます。90 日の保持期間後、テープはリサイクルされます。

顧客が DR サイトに機器を保有しているため、このサイトはバックアップおよびアーカイブプロセスを厳密に処理する顧客の拡張にすぎません。

図 3-3 事前配置された機器

シナリオ 2: 共有された KMA

このシナリオは、「シナリオ 1: KMA の事前配置」とよく似ていますが、障害回復サイトに機器があり、その他の複数の顧客とリソースを共有しています。

このシナリオについては、図 3-4 を参照してください。

この障害回復サイトはその他の DR クライアントをサポートするため、サイトが暗号化対応プロセス用に常に構成されていることを前提にできません。

注:

KMA は、別の顧客用の構成を作成する前に、出荷時の設定にリセットする必要があります。

DR サイトで、

顧客は DR サイトのインベントリから適切な機器を選択します。
DR サイトは、それに従って、機器およびインフラストラクチャーを構成します。

重要:

顧客は、3 つの OKM バックアップファイルを DR サイトに提供する必要があります。

コアセキュリティーバックアップファイル
.xml バックアップファイル
.dat バックアップファイル

DR サイトで、顧客は

QuickStart ウィザードを使用して初期 KMA を構成します
KMA を OKM バックアップファイルから復元します
ドライブを暗号化対応としてアクティブ化、有効化、または切り替えします (DR 担当者)
テープドライブを DR サイトの KMA クラスタに登録します。

ジョブが完了したら、障害回復サイトは次を行う必要があります。

エージェントから暗号化をオフに切り替えます
テープドライブをクラスタから削除するか、ドライブのパスフレーズをリセットします
KMA を出荷時のデフォルトにリセットします。

インフラストラクチャーおよびネットワークを切断します。

図 3-4 共有された KMA

シナリオ 3: 鍵転送パートナー

鍵転送は、鍵共有とも呼ばれます。転送は、鍵と関連データユニットをパートナー間または独立したクラスタ間でセキュアに交換することを可能にします。また、暗号化された媒体を交換する場合には必要です。

注:

DR サイトは、鍵転送パートナーとして構成することもできます。

このプロセスでは、転送の各当事者で公開/非公開鍵ペアを確立する必要があります。初期構成が完了した場合:

送信側は、鍵のエクスポートを使用してファイル転送を生成します。
次に、受信側が鍵のインポートを使用して、鍵とそれに関連付けられたデータを受信します

実際には、障害回復に鍵転送パートナーを使用することは非推奨です。ただし、DR サイトがバックアッププロセス中に鍵を作成する場合、またはそのときは、鍵転送を実行すると、すでに存在するデータベースに DR サイト鍵が徐々に追加されることがあります。

鍵転送プロセスでは、各ユーザーが OKM クラスタごとに転送パートナーを構成する必要があります。

一方の転送パートナーが鍵を OKM クラスタからエクスポートします。
他方の転送パートナーが鍵を OKM クラスタにインポートします。

鍵転送パートナーを構成するときは、管理者は次のような複数の役割が必要なタスクを特定の順序で実行する必要があります。

セキュリティー責任者役割
コンプライアンス責任者役割
オペレータ役割。

鍵転送パートナーを構成するには、『OKM 管理ガイド』を参照し、次を行います。

鍵の交換に関与する両方の OKM クラスタに鍵転送パートナーを構成します。
公開/非公開鍵の交換を確立して、OKM クラスターと通信します。たとえば、電子メールを送信する場合、2 つのサイトで確立された通信方法を使用すると、電子メール交換をセキュアにし、送信者および受信者を認証できます。

情報が送信中に改ざんされることを防ぐために、フィンガープリントなどのメカニズムがあります。
定足数を収集して、新しい転送パートナーの作成を承認します。
転送パートナーを 1 つまたは複数の鍵グループに割り当てます。
鍵を一方の OKM クラスタからエクスポートし、他方にインポートします。これは、何回でも実行できます。

図 3-5 転送鍵パートナー

シナリオ 4: バックアップからの復元

バックアップとは、データのコピーを作成し、データが失われた障害やその他の事象後にオリジナルを復元するために使用できるようにすることを指します。

これらのコピーは通常「バックアップ」と呼ばれ、次を行うためのものです。

障害のあとで、サイトを復元する (障害回復)
ファイルを意図せず削除または破損したあとで、ファイルを復元する

部門、グループ、組織、または企業ごとに、機能するバックアップスキームを認識および使用することが重要です。また、バックアッププロセスが想定どおりに動作していることに確信を持つことも重要です。

OKM の場合、OKM を作成し、必要に応じて復元するために次のものを利用できます。

バックアップ

バックアップ処理中に作成されるファイルで、KMA の復元に必要なすべての情報が含まれています。このファイルは、バックアップ専用に生成された「鍵」を使用して暗号化されます。この鍵は、対応するバックアップ鍵ファイルに格納されます。
バックアップ鍵ファイル

バックアップ処理中に生成されるファイルで、バックアップファイルの暗号化に使用される鍵が格納されます。このファイルは、システムの「マスター鍵」を使用して暗号化されます。マスター鍵は、鍵分割資格の定足数を使用して、コアセキュリティーバックアップファイルから抽出されます。
バックアップオペレータ

データと鍵のセキュリティー保護と格納の責任を負うユーザーの役割。

注:

詳細については、"バックアップ手法"を参照してください。

バックアップの場所:

OKM バックアップの場所は、適度な距離 (たとえば、1 回のビル火災ですべてのデータが破壊されない) で安全な場所にあるサイトに置いてください。自然災害の場合は、距離も考慮してください。

たとえば、すべてのバックアップサイトがニューオーリンズ内の複数のビルにある場合、カトリーナのような災害があるとデータの破壊は免れません。

復元:

バックアップからの復元は、サイトが火災で破壊された場合のようにクラスタ内のすべての KMA で障害が発生した場合のみ必要です。

注:

バックアップから OKM を復元するには、定足数が必要です。バックアップオペレータがバックアップを作成および保守し、セキュリティー責任者がそれらを復元します。必要な数の定足数ユーザーが利用できることを確認してください。

システムをバックアップから復元するには、『OKM 管理ガイド』を参照し、次を行います。

「Secure Information Management」 > 「Backup List」を選択します。バックアップファイルの履歴および詳細を確認できます。
「Backup List」画面で、復元するバックアップを強調表示してバックアップエントリをダブルクリックします。「Backup Details」ダイアログボックスが表示されます。
「Restore」ボタンをクリックします。「Restore Backup」ダイアログボックスが表示されます。

図 3-6 バックアップからの復元
「Start」ボタンをクリックします。

アップロードが完了すると、「Key Split Quorum Authentication」ダイアログボックスが表示されます。

コアセキュリティーバックアップ定足数は、操作を認証するために、ユーザーの名前およびパスフレーズを入力する必要があります。
「OK」ボタンをクリックします。復元の進捗表示が示されます。

バックアップ手法

顧客も状況もそれぞれ異なるものです。ここでは役立つ可能性のあるガイドラインをいくつか示します。

バックアップの頻度。処理の異なる 2 種類のバックアップがあります。

コアセキュリティーバックアップ。特別な戦略を使用してセキュリティー保護する必要があります。
鍵データのデータベースバックアップ。保護する必要があります。

コアセキュリティーバックアップ

コアバックアップには、OKM のプライマリコンポーネントであるルート鍵データが含まれます。ルート鍵データとは、クラスタの初期化時に生成されるこの鍵データです。ルート鍵データは、マスター鍵を保護します。マスター鍵は、KMA に格納されるデータユニット鍵を保護する対称鍵です。

コアセキュリティーバックアップは、鍵分割資格で定義された定足数のユーザーを必要とする鍵分割スキームによって保護されます。この定足数のユーザーは、ルート鍵データのラップを解除するために、ユーザー名とパスフレーズを提供する必要があります。

手法:

コアバックアップは、最初のデータベースバックアップよりも先に行う必要があり、その後は鍵分割メンバー (定足数) が変更されたときのみ繰り返す必要があります。これは、特別な対処および保護が必要なセキュリティー項目です。これは、OKM のあらゆるバックアップを復元するために必要です。

ベストプラクティスとして、このバックアップの 2 つのコピーを 2 つのセキュアな場所に顧客が選択したポータブルメディア (CD、USB メモリースティック、外付けハードドライブなど) で保持してください。

新しいコアバックアップが作成およびセキュリティー保護されたら、古いものは破棄してください。

データベースのバックアップ

注:

バックアップオペレータは、データおよびその鍵のセキュリティー保護および格納を担当します。

データベースのバックアップは、バックアップファイルとバックアップ鍵ファイルの 2 つのファイルで構成されます。これらのファイル名は自動的に生成されますが、名前を編集できます。

各 KMA は作成時に 1000 個の鍵をデフォルトで作成します。これは、インストール中に変化することがあります。各 KMA はそれぞれの鍵を制御および割り当てます。10 個の鍵を発行すると、KMA は 10 個の鍵を作成して補充します。

その後、鍵は OKM 内のすべての KMA にレプリケートされます。

データベースのバックアップは AES-256 で暗号化されるため、セキュアです。

手法:

例 1: データベースのバックアップ — OKM クラスタ内の複数のサイト

鍵は、破損に備えて鍵を保護しています。
鍵は、レプリケーションによって保護されています。

地理的に配置されたデータセンターであるため、顧客はクラスタの総合的な障害回復を必要とすることはありません。この顧客のバックアップを作成することは、例 2 ほど重要ではありませんが、コアセキュリティーバックアップを作成し、単一 KMA から生成されたすべての鍵がデータユニットに発行される前に、データベースバックアップを作成します。

例 2: データベースのバックアップ — OKM クラスタ内の 1 つの物理サイト

局地的な障害が OKM 全体を破壊する可能性があります。
データベースのバックアップは、鍵の唯一の保護です。

コアセキュリティーとデータベースのバックアップのオフサイトコピーを保守してください。必要最小限の保護の場合:

表 3-1 データベースのバックアップの計算

1.	テープごとに 1 つの鍵を使用する場合に、当初暗号化するテープの本数を計算します。
2.	当初作成された鍵を発行するのに何時間、何日、または何週間かかりますか。注: 各 KMA は作成時に 1000 個の鍵をデフォルトで作成します
3.	鍵暗号化期間の有効期限が切れるマウント済みテープの本数を計算します。
4.	これら 2 つの計算を加算します
5.	1 つの KMA のみがすべての鍵を発行し、当初の鍵がすべて発行される前にデータベースをバックアップすると想定します。これにより、計算の 50% の安全率が得られます。
6.	新しいテープの合流に基づいてこの計算を繰り返します (暗号化期間の期限切れは再利用してください)。

考慮事項:

コピーはアーカイブするかアーカイブしないでください。
古いバックアップには、保持しておきたくないユーザー、パスワード、およびその他の機密データが含まれています。
バックアップメディアの障害に備えて、現在のデータベースのバックアップを 2 つ作成し、アーカイブしてください。
1 つの KMA のみが鍵を発行することを想定して 50 % の安全率を計算したため、いずれかのバックアップにはすべてのアクティブな鍵が含まれます。
データベースの古いコピーはアーカイブしないでください。
ポリシーまたはコンプライアンスの理由で鍵を定期的に削除する場合、削除された鍵は以前のバックアップから回復できます。
冗長コピーを保持してください。2 つのバックアップを作成しないでください。
2 つの同一コピーを作成し、バックアップメディアの障害から保護してください。このスキームにより、バックアップ中に別の鍵が発行されないことも保証され、2 つのコピーが異なることはありません。