リリース・ノートには、このリリースのOracle Key Vaultの新機能、最新の製品ソフトウェアおよびドキュメントのダウンロード方法、およびOracle Key Vaultの既知の問題の対処方法が記載されています。

1.1 Oracle Key Vaultのこのリリースの変更点

Oracle Key Vaultのこのリリースでは、大規模な企業でOracle Key Vaultの使用を強化する新機能が導入されています。

1.1.1 リリース18.7に新機能はありません

Oracle Key Vaultリリース18.7で導入された新機能はありません。

1.2 Oracle Key Vaultのソフトウェアおよびドキュメントのダウンロード

最新バージョンのOracle Key Vaultのソフトウェアおよびドキュメントはいつでもダウンロードできます。

1.2.1 Oracle Key Vaultインストール・ソフトウェアのダウンロード

新規インストールの場合は、Software Delivery CloudからOracle Key Vaultソフトウェアをダウンロードできます。このパッケージは、Oracle Key Vaultのアップグレードには使用できません。既存のOracle Key Vaultデプロイメントからのアップグレードの場合、アップグレード手順を記載したreadmeファイルを含んだMy Oracle Support WebサイトからOracle Key Vaultのアップグレード・ソフトウェアをダウンロードできます。

  1. WebブラウザでOracle Software Delivery Cloudポータルにアクセスします。
  2. 「Sign In」をクリックし、入力を求められたら、「User ID」および「Password」に入力します。
  3. 「All Categories」メニューで、「Release」を選択します。次のフィールドで、「Oracle Key Vault」と入力して、「Search」をクリックします。
  4. 表示されたリストから「Oracle Key Vault 18.7.0.0.0」を選択するか、「Oracle Key Vault 18.7.0.0.0」の横にある「+Add to Cart」ボタンをクリックします。
    ダウンロードがカートに追加されます。(カートの中身を確認するには、画面の右上にある「View Cart」をクリックします。)
  5. 「Checkout」をクリックします。
  6. 次のページでインストール・パッケージの詳細を確認して、「Continue」をクリックします。
  7. 「Oracle Standard Terms and Restrictions」ページで、契約条件を読み、同意した後、「I have reviewed and accept the terms of the Commercial License, Special Programs License, and/or Trial License」を選択して「Continue」をクリックします。

    ダウンロード・ページが表示され、次のOracle Key Vault ISOファイルがリストされます。

    • Vpart_number.iso (Oracle Key Vault 18.7.0.0.0 - ディスク1)

    • Vpart_number.iso (Oracle Key Vault 18.7.0.0.0 - ディスク2)

    • Vpart_number.iso (Oracle Key Vault 18.7.0.0.0 - ディスク3)

  8. 「Print」ボタンの右側にある「View Digest Details」をクリックします。

    3つのISOファイルのリストを展開すると、各ISOファイルのSHA-1およびSHA-256のチェックサム参照番号が表示されます。

  9. SHA-256チェックサム参照番号をコピーし、後で参照するために保存します。
  10. 「Download」をクリックして、ISOファイルを保存する場所を選択します。
    各ファイルを個別に保存するには、名前をクリックしてダウンロードする場所を指定します。
  11. 「Save」をクリックします。

    両方のISOファイルのサイズの合計は4 GBを超えるため、ネットワーク速度によってはダウンロードに時間がかかることがあります。ダウンロードの推定時間と推定速度が「File Download」ダイアログ・ボックスに表示されます。

  12. ISOファイルが指定した場所にダウンロードされたら、ダウンロードされたファイルのSHA-256チェックサムを確認します。
    1. LinuxまたはUnixマシンから、最初のVpart_number.isoのSHA256チェックサムを生成します。
      $ sha256sum Vpart_number.iso

      チェックサムが、ステップ9で「File Download」ダイアログ・ボックスからコピーした値と一致することを確認します。

    2. 2番目のVpart_number.isoのSHA-256チェックサムを生成します。
      $ sha256sum Vpart_number.iso

      チェックサムが、ステップ9で「File Download」ダイアログ・ボックスからコピーした値と一致することを確認します。

  13. 必要に応じて、3つのVpart_number.isoファイルをそれぞれDVD-ROMディスクに書き込み、ディスクにラベルを付けます。
    • OKV 18.7 Disc 1

    • OKV 18.7 Disc 2

    • OKV 18.7 Disc 3

これで、サーバー・マシンにOracle Key Vaultをインストールできます。

1.2.2 Oracle Key Vaultのドキュメントのダウンロード

  1. Oracleドキュメント・サイトにアクセスします。
  2. 「Oracle Database Related Products」を選択します。
  3. 「Database Security」セクションで、リリース・ノートを含む最新バージョンのOracle Key Vault 18.7ドキュメントを検索してダウンロードします。

1.3 既知の問題

このリリースの時点で、Oracle Key Vaultにはまれな状況で発生する可能性がある問題があります。各問題の回避策が提供されます。

1.3.1.1 HP-UXシステムで、SELECT FROM V$ENCRYPTION_KEYSを実行するとORA-28407が返されることがある

問題: HP-UXオペレーティング・システムで、長時間実行されているデータベース・プロセスまたはセッションで実行された次のような透過的データ暗号化(TDE)問合せで、ORA-28407 ハードウェア・セキュリティ・モジュール・エラーが検出されましたというエラーが発生することがあります。

SELECT * FROM V$ENCRYPTION_KEYS;

これは、PTHREAD_KEYS_MAX設定によって制御されるプロセスごとのキーの合計数に関するシステムによる制限にプロセスが達したか、超過したため、システムがそれ以上スレッド固有のデータ・キーを作成できなかったためです。通常、PTHREAD_KEYS_MAX128に設定されています。

回避策: データベース・セッションを切り替えて、TDE問合せを再実行します。セッションを切り替えることができない場合は、データベースおよびリスナーを開始する前に、PTHREAD_USER_KEYS_MAX16384を設定します。

バグ番号: 28270280

1.3.1.2 複数回ログインに失敗すると、ユーザーがロックされ、ログイン不能になる

問題: 現在のパスワード・ポリシーでは、ユーザーがパスワードを連続して3回間違って入力した場合、ユーザー・アカウントが1日間ロックされます。このため、そのユーザーは24時間のロックアウト期間が経過した後にのみログインできます。

回避策: パスワードをノートにとって、安全に保管して参照できるようにします。

バグ番号: 23300720

1.3.1.3 問題の修正後もリストにOKVアラートが表示される

問題: ユーザーがパスワードを変更した後でも、ユーザー・パスワードの期限切れのアラートが引き続き表示されます。

回避策: Oracle Key Vault管理コンソールで、「Reports」「Configure Reports」の順に選択します。「User Password Expiration」オプションの選択を解除します。または、アラートを無視します。

バグ番号: 27620622

1.3.1.4 Java Keystoreがokvutilユーティリティの-oオプションを使用してアップロードされた場合、秘密キーが上書きされない

問題: okvutil uploadコマンドの-oオプションを使用して、Java keystore (JKS)またはJava Cryptography Extension keystore (JCEKS)をOracle Key Vaultサーバーにアップロードした場合、ユーザー定義のキーは上書きされません。

回避策: ウォレットから秘密キーを削除し、そのキーを再度アップロードします。

バグ番号: 26887060

1.3.1.5 FIPSモードのOracle Key Vaultの起動時の警告

問題: FIPSモードで動作するOracle Key Vaultサーバーを起動すると、次のような警告がコンソールに表示されることがあります。
Warning : Error inserting
    serpent_avx2(/lib/modules/4.1.12-124.34.1.1.el6uek.x86_64/kernerl/arch/x86/crypto/serpent_avx2):
    No such device

これらは、FIPSモードで使用できない、またはサポートされていない暗号の命令セットがロードされていないことを示す、画面にスローされる情報メッセージです。これらの警告は無視しても支障ありません。

回避策: なし。

バグ番号: 30844891

1.3.2.1 アップグレードしたプライマリ/スタンバイOracle Key Vault 18.xサーバーのペア解除が権限の問題で失敗することがある

問題: Oracle Key Vaultの現在のリリースへのアップグレードを完了した後、プライマリ/スタンバイ構成からペア解除しようとすると、次のメッセージが/var/log/debugファイルに書き込まれて失敗することがあります。
ORA-48141: error creating directory during ADR initialization: [/var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv]
ORA-48189: OS command to create directory failed
回避策: Oracle Key Vault 18.1にアップグレードされたプライマリ-スタンバイ構成でペア解除する前に、次のステップを使用して/var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pvディレクトリに正しい権限が設定されていることを確認してください。
  1. sshを使用してユーザーsupportとしてプライマリOracle Key Vaultシステムにログインします。
    $ ssh support@okv_instance_ip_address
  2. rootユーザーに切り替えます。
    support$ su - root
  3. /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pvディレクトリの権限を確認します。
    root# ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
    出力は次のようになります。
    drwxr-xr-x 2 root   oinstall  4096 Apr 24 22:01 metadata_pv
  4. 前述の例のようにディレクトリの所有者がユーザーrootの場合は、次のコマンドを実行します。
    root# chown oracle:oinstall /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
    ファイルをリストして、所有者がoracleになったことを確認します。
    root# ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
    出力は次のようになります。
    drwxr-xr-x 2 oracle oinstall 4096 Apr 24 22:01 metadata_pv

バグ番号: 29693700

1.3.2.2 アップグレードする前にペア解除されたOKVシステムでは、DB_UNIQUE_NAMEをリセットする必要がある

問題: ペア解除される前はOracle Key Vault 12.2高可用性(現在はプライマリ-スタンバイ)構成の一部で、その後アップグレードされたOracle Key Vaultシステムでは、DB_UNIQUE_NAMEパラメータにDBFWDB_HA1またはDBFWDB_HA2が設定されています。このパラメータは、システムをクラスタ・モードに変換する前に、DBFWDBにリセットする必要があります。そうしないと、クラスタへのノードの追加に失敗します。

回避策: Oracle Key Vault 12.2高可用性構成のプライマリ・サーバーであり、現在のリリースのOracle Key Vaultにアップグレードされる前にペア解除されたシステムの場合、アップグレードが正常に完了した後、クラスタ・ノードに変換する前に、次のコマンドをシステムで実行する必要があります。
  1. sshを使用してユーザーsupportとしてプライマリOracle Key Vaultシステムにログインします。
    $ ssh support@okv_instance_ip_address
  2. rootユーザーに切り替えます。
    support$ su - root
  3. /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pvディレクトリの所有者およびグループを確認します。
    root# ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
    出力は次のようになります。
    drwxr-xr-x 2 root   oinstall  4096 Apr 24 22:01 metadata_pv
  4. 前述の例のようにディレクトリの所有者がユーザーrootの場合は、次のコマンドを実行します。
    root# chown oracle:oinstall /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb/metadata_pv
    ファイルをリストして、所有者がoracleになったことを確認します。
    root# ls -l /var/lib/oracle/diag/rdbms/dbfwdb/dbfwdb
    出力は次のようになります。
    drwxr-xr-x 2 oracle oinstall 4096 Apr 24 22:01 metadata_pv
  5. ユーザーoracleに切り替えます。
    root# su oracle
  6. SQL*Plusを開始します。
    oracle$ sqlplus / as sysdba
  7. 次の文を実行します。
    show parameter db_unique_name;
  8. DB_UNIQUE_NAMEDBFWDB以外である場合は、次のコマンドを実行します。
    alter system set db_unique_name='DBFWDB' scope=spfile;
    exit
  9. rootユーザーとして、次のコマンドを実行します。
    oracle$ service dbfwdb stop
    oracle$ service dbfwdb start
  10. DB_UNIQUE_NAMEパラメータが変更されたことを確認します。
    SQL*Plusを開始します。
    oracle$ sqlplus / as sysdba
  11. 次の文を実行します。
    show parameter db_unique_name
    返される出力は次の出力と一致するはずです。
    NAME                  TYPE        VALUE
    --------------------- ----------- -----------
    db_unique_name        string      DBFWDB

バグ番号: 29696058

1.3.2.3 OKV 12.2.0.5以前からOKV 18にアップグレードされたシステムでは、FIPSモードになっていると誤解を招くような表示になっている場合がある

Oracle Key Vault 12.2.0.5以前からOKV 18.1 - 18.7にアップグレードされたシステムでは、Oracle Key Vault管理コンソールでシステムがFIPSモードになっていると誤解を招くように報告される場合があります。

これに該当するか確認するには:
  1. システム管理者権限を持っているユーザーとしてOracle Key Vault管理コンソールにログインします。

  2. 「System」タブからStatusページに移動し、「FIPS Mode」フィールドを確認します。これで、FIPSモードが有効になっていると表示される場合があります。

  3. 「System」タブからSystem Settingsページに移動し、「FIPS Mode」セクションまで下にスクロールします。これで、確認済と表示される場合があります。

    アップグレードの完了後にシステムが明示的にFIPSモードにされなかった場合、このバグが発生しています。

この問題を解決するには:
  1. SSHを介してsupportユーザーとしてOracle Key Vaultリリース18.7システムにログインし、suを使用してrootに切り替えます。

  2. okv_security.confファイルのバックアップを作成します。
    # /bin/cp -p /usr/local/okv/etc/okv_security.conf /usr/local/okv/etc/okv_security.conf.bkp

    ノート:

    次の手順でokv_security.confファイルが変更され、システム全体の機能に意図しない影響を与える可能性があります。PROCEED WITH CAUTION。
  3. okv_security.confファイルの内容を表示し、次の2つのパラメータを探します。
    • HSM_FIPS_ENABLED
    • FIPS_ENABLED
  4. 次の条件のすべてが満たされている場合にのみ続行します:
    1. /usr/local/okv/etc/okv_security.confHSM_FIPS_ENABLED="1"が含まれている
    2. /usr/local/okv/etc/okv_security.confFIPS_ENABLED="0"が含まれている
    3. HSM_FIPS_ENABLED="1"行が、FIPS_ENABLED="0"行のに表示されている

    これらの条件のいずれかが満たされない場合は、Oracleサポートに連絡してください。

    3つの条件のすべてが満たされた場合、/usr/local/okv/etc/okv_security.confを次のように編集します。
    /bin/echo "FIPS_ENABLED=\"0\"" >> /usr/local/okv/etc/okv_security.conf
    /bin/echo "HSM_FIPS_ENABLED=\"1\"" >> /usr/local/okv/etc/okv_security.conf

    /usr/local/okv/etc/okv_security.confファイルを編集し、HSM_FIPS_ENABLEDおよびFIPS_ENABLEDパラメータの最初の出現箇所のみを削除します。

    /usr/local/okv/etc/okv_security.confを再度確認します。今回は、次を含んでいる必要があります。
    1. FIPS_ENABLEDパラメータの正確に1回の出現
    2. HSM_FIPS_ENABLEDパラメータの正確に1回の出現
    3. FIPS_ENABLED="0"
    4. HSM_FIPS_ENABLED="1"
    5. FIPS_ENABLED="0"およびHSM_FIPS_ENABLED="1"は、前述の順序で(最初にFIPS_ENABLED、続けてHSM_FIPS_ENABLED)ファイルに表示されます。

Oracle Key Vault管理コンソールが選択されている場合、「System」タブの下にあるStatusページとSettingsページの両方に、正しいFIPSステータスが反映されている必要があります。これで、Oracle Key Vaultのドキュメントのガイドラインに従ってFIPSモードを有効にできるようになります。

バグ番号: 32734169

1.3.3.1 プライマリ/スタンバイ・ペアでのスイッチオーバー時に、監査証跡がリモートのsyslogに送信されない

説明: プライマリにsyslogが構成されている場合は、監査ログもsyslogに書き込まれます。スイッチオーバー時に、監査ログがsyslogに書き込まれないことがあります。これはスタンバイにsyslogが構成されていないためです。syslogはプライマリとスタンバイで別個に構成する必要があります。

回避策: スイッチオーバー後にスタンバイにsyslogを構成し、監査ログがsyslogに書き込まれるようにします。

バグ番号: 28790364

1.3.3.2 プライマリ/スタンバイでのフェイルオーバーでSSHトンネル・ステータスが無効として表示される

問題: フェイルオーバー操作の後、新しいOracle Key Vaultプライマリ・サーバーでSSHトンネルの正しいステータスが表示されません。SSHトンネルが使用可能になったときに、SSHトンネルが無効として表示されます。ダッシュボードにもSSHトンネルの設定が失敗したことを警告するアラートが表示されます。これは、フェイルオーバー操作の後、同じサービス・エンドポイントとしてのデータベースに対してOracle Key Vaultが2つのSSHトンネルを確立しようとするためであり、間違ったステータスとなり、ダッシュボードにアラートが表示されます。サービス・エンドポイントとしてのデータベースへの2番目のSSHトンネルは、Oracle Key Vaultサーバーとサービス・エンドポイントとしてのデータベースの間の接続性に影響しません。サービス・エンドポイントとしてのデータベースへの最初のSSHトンネルは、フェイルオーバー後に機能して使用可能です。

回避策: フェイルオーバー後、新しいOracle Key Vaultプライマリ・サーバーでは、使用可能という正しいSSHステータスが表示され、サービス・エンドポイントとしてのデータベースに接続されます。サービス・エンドポイントとしてのデータベースでokvutil listを使用して、SSHトンネルのステータスを確認することもできます。

バグ番号: 24679516

1.3.3.3 HA 12.2 BP5からペア解除し、新しいOKVサーバーに再度ペアリングしてもスタンドアロンと表示される

問題: Oracle Key Vault 12.2.0.5.0以降を実行しているペア解除されたOracle Key Vaultプライマリ・サーバーを新しくインストールされたOracle Key Vaultサーバーとペアリングした場合、「Primary-Standby」ページの「Current status」でサーバーがスタンドアロン・モードであると表示されます。スタンドアロン・ステータスは、プライマリ-スタンバイ構成が失敗したことを示します。プライマリ-スタンバイ設定が失敗するのは、プライマリ・サーバーのSSH構成が再度有効にされないためです。

回避策: Oracle Key Vaultが実行されているペア解除されたOracle Key Vaultプライマリ・サーバーをペアリングする前に、SSH構成を無効にして再度有効にします。プライマリ・サーバーをスタンバイ・サーバーとペア解除して、プライマリ・サーバーでプライマリ-スタンバイ構成を実行した後に、SSH構成を無効にして再度有効にする必要があります。

ノート:

Oracle Key Vaultが実行されているペア解除されたOracle Key Vaultプライマリ・サーバーをペアリングする前に、他のすべてのブラウザ・インスタンスを閉じたことを確認します。

バグ番号: 26617880

1.3.3.4 管理された停止がプライマリOKVで行われたときに、フェイルオーバーの問題が発生する

問題: プライマリ/スタンバイ・ペアのプライマリOracle Key Vaultノードでは、管理された停止が定期的に実行されます。たとえば、ユーザーが、管理コンソールの電源オフ・ボタンを押すか、端末から停止コマンドを実行して、停止を実行します。これが発生すると、フェイルオーバー操作は行われず、スタンバイOracle Key Vaultノードはプライマリ・サーバーとして引き継ぎません。これはプライマリOracle Key Vaultサーバーの/var/lock/subsys/dbfwdbファイルの存在によって予想できます。管理された停止時にプライマリにこのファイルが存在する場合、フェイルオーバーは行われません。存在しない場合は、フェイルオーバーが行われます。

プライマリでの電源喪失、データベースの障害などの他の状況では、このファイルが存在しているかどうかにかかわらず、フェイルオーバーは引き続き行われます。

回避策: スタンバイ・ノードが新しいプライマリ・ノードとして引き継がれるように管理された停止を実行する場合は、かわりにスイッチオーバーを実行します。

バグ番号: 29666606

1.3.3.5 プライマリおよびスタンバイが異なるRO制限モード構成の場合にHA設定が成功する

問題: プライマリ/スタンバイ構成を行うとき、ペアリング前に一方のOracle Key Vaultサーバーでは読取り専用制限モードが有効にされ、他方のOracle Key Vaultサーバーでは無効にされている場合に、構成が成功します。プライマリ-スタンバイ・デプロイメントでは、この不一致は問題と混乱に繋がる場合があります。

回避策: Oracle Key Vault管理コンソールを使用して、両方のサーバーに同じ読取り専用制限モード状態が適用されていることを確認します。これを行うには、「System」タブを選択して、「Primary-Standby」を選択します。「Allow Read-Only Restricted Mode」オプションを選択します。その後、各サーバーにプライマリ-スタンバイ構成を適用します。

バグ番号: 26536033

1.3.4 マルチマスター・クラスタの問題

この項では、マルチマスター・クラスタ構成に固有のOracle Key Vaultの問題について説明します。

1.3.4.1 OKVクラスタで複数のシステム障害が発生した後に、レプリケーションの再開が失敗することがある

問題: GoldenGateのバグ29624366が原因で、Oracle Key Vaultクラスタで複数のシステム障害が発生した後に、一部のノードからのレプリケーションの再開に失敗することがあります。特に、これが発生すると、GoldenGateのReplicatが終了し、GoldenGate証跡ファイルの新しい変更ログを処理できません。

回避策: そのようなReplicatの位置を手動で変更して、証跡ファイル内のエラーのあるレコードをスキップするか、障害の発生したOracle Key Vaultノードをクラスタから強制的に削除し、新しいノードを追加してそれに置き換えます。

バグ番号: 29700647

1.3.4.2 候補ノードに変換された後にOKVノードで変更されたシステム設定がコントローラ・ノードに反映されない

問題: Oracle Key Vaultノードが候補ノードに変換された後にシステム設定が変更され、コントローラ・ノードがその候補ノードの設定を最初に検証しようとして失敗した場合、更新された設定はコントローラ・ノードに反映されません。ペアリング・プロセスは、コントローラおよび候補ノードの両方で中断する必要があります。

回避策: なし。候補ノードに変換してクラスタに追加する前に、Oracle Key Vaultノードのシステム設定がクラスタの設定と一致していることを確認します。

バグ番号: 29430349

1.3.4.3 再起動後の読取り専用制限モードでの読取り/書込みノード

問題: 読取り/書込みノードを再起動すると、ノードまたはその読取り/書込みピアが読取り専用制限モードでスタックすることがあります。

回避策: ノードを再起動する際、ノードの読取り/書込みピア・ノードが一時的に読取り専用制限モードで稼働するのは正常です。ただし、ノードの起動が完了するとすぐに、読取り/書込みピアは数分以内に読取り/書込みモードに戻ります。再起動されたノードは読取り専用制限モードで起動することがありますが、同様に数分以内に読取り/書込みモードに戻ります。ただし、ノードまたはその読取り/書込みピアが読取り専用制限モードのままになっていない場合、REDO送信がスタックしている可能性があります。読取り専用制限モードのままでノードを再起動すると修正できます。

バグ番号: 30589921

1.3.4.4 OGGに引き続き必要なアーカイブ・ログのRMANによる自動クリーン・アップ

問題: RMANは、高速リカバリ領域のアーカイブ・ログを自動的に管理します。通常の状況では、Oracle GoldenGateで引き続き必要とされているアーカイブ・ログはRMANによって削除されません。ただし、領域が不足すると、RMANは必要なアーカイブ・ログをクリーン・アップすることがあります。このようなアーカイブ・ログがクリーン・アップされると、現在のノードからノードの読取り/書込みピア・ノードを除いた他のすべてのノードへのレプリケーションが中断されます。Oracle Key Vaultでは、高速リカバリ領域の定期的なクリーン・アップを実行してこの問題を緩和しようとしますが、まれに、高速リカバリ領域が一杯になり、この問題が発生することがあります。

回避策: 高速リカバリ領域での領域不足の原因を特定し、問題を修正します。ディスク領域にタブを保持することで、高速リカバリ領域での領域不足を特定できます。高速リカバリ領域は、/var/lib/oracle/fast_recovery_area/下にあります。

バグ番号: 30558372

1.3.4.5 MDNDよりも時間がかかる場合、Oracle Key Vaultでは有効化が終了しないようにする必要がある

問題: 「Maximum Disable Node Duration」時間制限より前にOracle Key Vaultノードを有効または無効にしたが、「Maximum Disable Node Duration」時間制限が失効する前に有効化が終了しない場合、クラスタ内の不一致の原因となるアーカイブ・ログおよび証跡ファイルのクリーン・アップが行われる可能性があります。この場合、有効化プロセスを終了させないでください。

回避策: 有効化を終了するのに「Maximum Disable Node Duration」期間より長くかかる場合、クラスタからノードを削除または強制削除します。

バグ番号: 30533066

1.3.4.6 12.2 BP4以前からのアップグレードの場合、クラスタに変換する前に証明書をローテーションする必要がある

問題: Oracle Key Vault 12.2 BP4から18.2までをOracle Key Vault 18.4にアップグレードしようとして、アップグレード前に新しい証明書を生成しない場合は、次のエラー・メッセージを受信します。

Failed to convert server to cluster node, detected use of weak signature
algorithms in OKV server credentials. Please perform a certificate rotation
operation before converting this server to a cluster node.
回避策: 次の2つのステップで、Oracle Key Vaultリリース18.4にアップグレードします。
  1. Oracle Key Vault 12.2 BP4から12.2 BP11にアップグレードして、証明書ローテーション操作を実行します。
  2. Oracle Key Vault 12.2 BP11からOracle Key Vaultリリース18.4にアップグレードします。
Oracle Key Vault 12.2 BP11で証明書のローテーションを実行する方法の詳細は、リリース12.2のOracle Key Vault管理者ガイドを参照してください。

バグ番号: 30673249

1.3.4.7 18.1クラスタで読取り/書込みノードを強制削除してからアップグレードすると、上位バージョンで、強制削除されたノードを置換できないことがある

問題: 読取り/書込みノードを強制削除するときは、まず、停止する必要があります。しかし、GoldenGateのバグ30413969が原因で、強制削除されたノードを停止すると、削除されたノードの読取り/書込みピア・ノードでのダウンストリーム抽出が完全にはクリーンアップされません。このバグの回避策は、Oracle Key Vaultバージョン18.2以上では存在します。ただし、読取り/書込みノードが強制削除されたOracle Key Vault 18.1マルチマスター・クラスタからアップグレードする場合、アップグレード後にノードを置換しようとすると、バージョン18.1で強制削除が発生したときにクリーンアップが実行されなかったため、依然として成功しません。

回避策: 次のステップは慎重に実行する必要があります。これらのステップを誤ったOracle Key Vaultサーバーで実行するとレプリケーションが中断され、ステップを実行されたノードを強制削除する必要があります。

シナリオ例: ノードAおよびBは読取り/書込みピアです。ノードBをクラスタから強制削除しました。ノードAは、GoldenGateのバグ30413969が原因で、完全にはクリーンアップされていない可能性があります。アップグレードの前後で、別のノードをノードAの読取り/書込みピアとして追加しようとする前に、ノードAで次のステップを実行してクリーンアップを終了します。
ssh support@Oracle_Key_Vault_IP_address
su - root
su - oracle
/var/lib/oracle/dbfw/bin/sqlplus / as sysdba
exec sys.dbms_xstream_adm.drop_outbound('OGG$OKV_DEXT');
exec sys.dbms_streams_adm.remove_queue('OGG$Q_OKV_DEXT', TRUE, TRUE);

前述のステップがノードAで正常に実行されたら、それをコントローラ・ノードとして使用し、別のノードをノードAの読取り/書込みピアとしてクラスタに追加できます。

バグ番号: 31216736

1.3.4.8 Oracle Key Vault 18.1、18.2または18.3のクラスタ・ノードからのバックアップ(その後アップグレードされ、別のクラスタの作成に使用)で、読取り/書込みピアを追加できないことがある

問題: クラスタ・ノードで作成されたバックアップをスタンドアロンOracle Key Vaultサーバーにリストアする場合、Oracle Key Vault上のデータベースのglobal_nameは、バックアップが作成されたクラスタ・ノードのglobal_nameに応じて、DBFWDB.DBFWDBまたはDBFWDB_HA2.DBFWDBのいずれかになります。global_nameがDBFWDB_HA2.DBFWDBで、スタンドアロンOracle Key Vaultサーバーがクラスタ・ノードに変換される場合、global_nameの不一致が原因で、読取り/書込みピア・ノードを正常に追加できません。グローバル名は、バージョン18.4以上では、バックアップのリストア時に修正されますが、バックアップが下位バージョンで作成およびリストアされた場合、18.4以上にアップグレードした後でも問題は解消されません。

回避策: バックアップをスタンドアロンOracle Key Vaultサーバーにリストアした後で、次のステップを実行してからサーバーをクラスタ・ノードに変換します。最初のselect文は、global_nameDBFWDB_HA2.DBFWDBであることを確認するためのものです。このselect文で返されたglobal_nameDBFWDB_HA2.DBFWDBでない場合、またはサーバーがすでにクラスタ・ノードに変換されている場合は、global_nameの更新を続行しないでください。
ssh support@Oracle_Key_Vault_IP_address
su - root
su - oracle
/var/lib/oracle/dbfw/bin/sqlplus / as sysdba
select global_name from global_name;
alter database rename global_name to DBFWDB.DBFWDB;

バグ番号: 31241245

1.3.4.9 サーバー証明書のローテーション後にクラスタ・サービス・ステータスが停止になる

問題: サーバー証明書をローテーションすると、証明書を置換するために複数のプロセスが停止します。ただし、通常の状況では、停止後すぐに再起動されます。証明書のローテーション中またはその後、「Monitoring」ページの「Cluster」タブで、1つ以上のクラスタ・サービスが稼働していないことを示す下向き矢印が「Cluster Services Status」に表示されることがあります。これにより、このノードとの間でのレプリケーションが中断します。数分を超えて解消されない場合、このバグが発生した可能性があります。

回避策: この問題が発生した場合は、「Monitoring」ページの「Restart Cluster Services」ボタンをクリックして、クラスタ・サービスの再起動を試行します。数分後、ページをリフレッシュします。「Cluster Services Status」に赤い下向き矢印がまだ表示される場合は、Oracleサポートに問い合せてください。

バグ番号: 31371440

1.3.4.10 バックアップの実行中にクラスタの最初のノードを作成しようとすると、再起動するまでUIが使用できなくなる

問題: スタンドアロンのOracle Key Vaultサーバーをマルチマスター・クラスタの最初のノードに変換するとき、現在進行中のバックアップがある場合、2つの操作間の相互作用によってユーザー・インタフェースが正しく動作しなくなり、両方の操作が失敗することがあります。その後、ユーザー・インタフェースに移動するとログイン・ページが表示されますが、ログインしようとすると失敗し、最終的に「Server Error 500」メッセージが表示されます。

回避策: この問題が発生した場合は、Oracle Key Vaultサーバーを再起動する必要があります。これにより、再度ログインできるようになります。必要に応じて、バックアップおよびクラスタ・ノードへの変換を再試行できます。

バグ番号: 31891079

1.4.1 Oracle TDEとOracle Key Vaultの統合

使用しているOracle DatabaseのバージョンおよびTDEの機能によっては、スムーズな運用のためにOracleデータベースにパッチ適用する必要がある場合があります。

MOS-NOTEのドキュメントID 2535751.1を参照して、使用しているデプロイメントにデータベース・パッチが必要かどうかを確認します。

MOS-NOTEには、Oracle Key Vaultをキーストアとして使用するように構成されたOracle Database Transparent Data Encryption (TDE)機能の既知の問題がリストされています。このドキュメントには問題を解決するための修正もリストされており、Oracle Database TDEとOracle Key Vaultをよりスムーズに統合できます。問題は、不具合、簡略化された操作によるユーザーの負荷の軽減、またはTDEとOKVの統合の改善です。このドキュメントは、データベース管理者、およびOracle Key Vaultを使用してTDEマスター・キーを管理する担当のユーザーを対象としています。

1.4.2 レポートがマルチマスター・クラスタの監査レプリケーションの影響を受ける

ホームページのOracle Key Vaultのレポートおよび詳細は、Oracle Key Vault監査レコードから生成されます。監査レプリケーションがオフにされている場合、各ノードにはそのノードで行われた操作のレポートが表示されます。監査レプリケーションがオンにされている場合、各ノードにはクラスタのすべてのノードで行われた操作のレポートが表示されます。

監査レプリケーションをオフにして、Oracle Audit Vault and Database Firewall (AVDF)などのセキュリティ情報およびイベント管理(SIEM)ソリューションを使用して、すべてのノードから監査レコードを収集することをお薦めします。

1.4.3 マルチマスター・クラスタでの更新は単一インスタンスでの更新より遅い

マルチマスター・クラスタの更新ではオブジェクトの存在がチェックされることがあり、クラスタ内のすべてのノードがスキャンされて更新操作が遅くなります。時間はクラスタ内のノード数に比例して増加します。更新は完了までに数分かかることがあります。

TDEマスター暗号化キーの設定およびローテーションが、更新操作の例です。

1.5 サポートされるデータベースのバージョン

次のバージョンのOracle Databaseは、Oracle Key Vault 18.7でサポートされます。

  • 互換性パラメータを11.2に設定したOracle DB 11.2
  • 互換性パラメータを11.2に設定したOracle DB 12.1
  • Oracle DB 12.2
  • Oracle DB 18c
  • Oracle DB 19c

1.6 リリース18.7に含まれているクリティカル・パッチ更新

Oracle Key Vaultリリース18.7では、Oracle Database 18 (18.13 DB RU)の2021年1月のリリース・アップデート - 1月のリリース・アップデートを組み込むために、基盤となっているインフラストラクチャが更新されました。詳細についてはサインインしてください。

https://www.oracle.com/security-alerts/cpujan2021.html

Oracle Key Vaultリリース18.7には、JavaおよびOracle Linux (OL)オペレーティング・システムのセキュリティおよび安定性に関する修正も含まれています。

1.7 ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracleサポートへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。