鍵ストアのベスト・プラクティス

鍵ストアとマスター鍵のセキュリティーを保持するためにセキュリティーのベスト・プラクティスを使用します。

鍵ストア資格情報

ほとんどの鍵ストア構成では、保管されている鍵にアクセスするためには、鍵ストアに資格情報を渡す必要があります。 Db2® は鍵ストアにアクセスできる必要があるため、 Db2 も鍵ストア資格情報にアクセスできる必要があります。 この情報は、 db2start コマンドの実行時に必要です。 Db2 に keystone 資格情報を安全に提供する方法はいくつかあります。
  • 資格情報のオペレーター入力を求めるプロンプト
  • 指定のファイル引数を使用したアクセス
  • 「stash」ファイルの使用
stash ファイルは、鍵ストアへのアクセスに必要な資格情報が入っている難読化ファイルです。 このファイルは、 Db2 インスタンス所有者のみが読み取ることができるように設定します。 stash ファイルの作成方法の詳細については、詳細な 鍵ストア構成 情報を参照してください。
注: stash ファイルを使用するほかに、必ずパスワードをバックアップしてください。 これは特に、ローカル鍵ストア・ファイルに使用されるパスワードが該当します。 万一 stash ファイルが破損した場合は、手動でパスワードを指定する必要があります。 パスワードを忘れた場合、バックアップを作成していなければ、鍵とデータへのアクセス権限は失われます。

ローカル keystone ファイルのパスワードを作成または変更する場合は、 gsk8capicmd_64 コマンドの –strong パラメーターを使用して、パスワードが強力であることを確認してください。 gsk8capicmd_64 コマンドの完全な構文について詳しくは、「 GSKCapiCmd ユーザー・ガイド」を参照してください。

鍵ストアのバックアップ

鍵ストアの内容は重要なので、鍵ストアを定期的な間隔でバックアップすることが大切です。 鍵または証明書が追加されたときや、マスター鍵 (MK) の循環が行われたとき、パスワードが変更されたときなど、鍵ストアの内容が変わるたびに、バックアップを行う必要があります。
注: パスワード変更がある場合のバックアップは、すべての鍵ストアではなく、stash ファイルにのみ適用されます。 ローカル鍵ストア・ファイルにも適用されます。

鍵ストア構成ファイルは Db2 データベース・バックアップの一部として組み込まれていないため、手動でバックアップする必要があります。 鍵ストア資格情報がディスクに保管されている場合でも、手動でバックアップする必要があります。

ローカル鍵ストア・ファイルの場合、構成ファイルは Db2 データベース・バックアップの一部として組み込まれていないため、手動でバックアップする必要があります。

セントラル鍵ストアの場合は、鍵ストアのバックアップに関する推奨事項について理解するために、ご使用の鍵ストア製品の資料を参照してください。

MK ラベルの固有性

Db2 は、MK ラベルを使用して各 MK を一意的に識別し、暗号化された各オブジェクト (データベース、トランザクション・ログ、またはバックアップ・ファイル) にラベル値を保管します。 この保管ラベル値は、オブジェクト内のデータの暗号化に使用されるデータ暗号鍵 (DEK) の復号に使用される MK を識別するためのものです。 重複を避けるために固有の MK ラベルを使用することが重要です。 固有のラベルが使用されないと、暗号化データへのアクセス権限が失われる可能性があります。 ラベルの鍵ストアから取得された MK がオブジェクト内の DEK の暗号化に使用される MK と異なる場合、暗号化データへのアクセス権限は失われます。

マスター鍵の保持

暗号化データベース、トランザクション・ログ、およびバックアップ・イメージに保管されている DEK にアクセスするには、MK が必要です。 これらのオブジェクトの存続時間中に複数の MK が存在することがあるため、暗号化データが保持されている間はそれらの MK を保持する必要があります。 そのため、鍵ストアから MK を削除しないでください。

鍵ストアの構成変更

すべての変更をオンラインで完了できるわけではないため、 Db2 データベース管理対象鍵ストア構成パラメーターまたは鍵ストア構成の内容を変更する前に、慎重に計画する必要があります。 新しい鍵要求が行われるたびに、その要求が鍵ストアにアクセスするときにこれらの値が読み取られます。 いくつかの例外を除き、これらの構成値に対する変更は、次のキー要求で Db2 処理に反映されます。 Db2 データベース・マネージャー構成パラメーター keystore_type および keystore_location はオンラインで構成可能ですが、これらは単一の db2 update dbm cfg コマンドで設定する必要があります。 そうしないと、 Db2 は更新と更新の間に鍵ストアにアクセスしようとして、アクセス・エラーを報告する可能性があります。

SSL_KEYDB、SSL_KEYDB_STASH、および SSL_KMIP_CLIENT_CERTIFICATE_LABEL の各鍵ストア構成値を変更した場合は、インスタンスを再始動して変更を有効にする必要があります。 LIBRARY 鍵ストア構成値への変更は、 Db2 が再始動されるまで有効になりません。 同様に、構成値が変更されない場合、ライブラリーの物理コピーに対する変更は、 Db2 が再始動されるまで有効になりません。 Db2 は定期的に鍵ストアにアクセスできるため、潜在的なエラーを回避するために、構成変更時に Db2 を停止することを強くお勧めします。 暗号化されたデータベースと暗号化されていないデータベースが同じインスタンスのもとに混在する場合は、暗号化されたデータベースを静止するだけで十分です。

鍵の循環

鍵の循環とは暗号鍵を変更するプロセスのことであり、しばしばコンプライアンスの目的で必要となります。 鍵の循環を行うのは、鍵が存在しているときに公開されてリスクが発生する可能性を軽減するためです。 暗号化のために Db2 によって使用される DEK は、暗号化されたデータベース、バックアップ、またはトランザクション・ログの外部ではないため、機密漏れのリスクはほとんどありません。 このことは、データベース外に存在する MK には当てはまりません。 Db2 は、 SYSPROC.ADMIN_ROTATE_MASTER_KEY プロシージャー このプロシージャーは、古い MK を使用して組み込み DEK を復号してから、新しい MK で再暗号化します。 MK の循環は、既存のバックアップやアーカイブ・トランザクション・ログの範囲内の DEK の暗号化には影響を及ぼしませんが、その後に生成される DEK 項目に影響を与えます。 HADR 環境内の 1 次データベース上で鍵の循環が行われると、スタンバイ・データベース上で自動的に鍵の循環が行われます。 ただし、この変更は、他のログ・レコードがスタンバイ・データベースに送られるまで行われません。 循環された鍵をスタンバイ・データベースに強制的に適用するには、ARCHIVE LOG コマンドを使用して、スタンバイ・データベース上で循環を適用するために必要なログ・レコードを生成します。 MK が循環すると、データベースはすぐに新しい鍵を使い始めますが、以下のシナリオでは古い MK 値へのアクセスがまだ必要です。
  • 鍵の循環が行われてから再使用されていないトランザクション・ログ・ファイル
  • 前の MK 値を使用したアーカイブ暗号化トランザクション・ログ・ファイル
  • 前の MK 値を使用した暗号化バックアップ・イメージ
暗号化されたオブジェクトによって参照されなくなったことが確実な場合を除き、鍵ストアから MK を削除しないでください。