1. 管理者ガイド
  2. Oracle Audit Vault and Database Firewallの開始
  3. 一般的なセキュリティ・ガイドライン

3 一般的なセキュリティ・ガイドライン

一般的なセキュリティのガイドラインについて学習します。

3.1データを保護するためのOracle Audit Vault and Database Firewallの安全なインストール

データを保護するためにOracle AVDFを安全にインストールする方法を学習します。

3.1.1 Oracle Audit Vault and Database Firewallの安全なインストール

Oracle Audit Vault and Database Firewallの安全なインストールを学習します。

Oracle Audit Vault Serverは、デフォルトで安全な状態でインストールされます。このため、デフォルト設定を変更する場合は注意して行うことが重要です。その変更によって設定のセキュリティが侵害される可能性があるためです。

関連項目:

インストールの詳細は、『Oracle Audit Vault and Database Firewallインストレーション・ガイド』を参照してください。

3.1.2 データの保護

Oracle AVDFを使用したデータの保護を強化するには、アカウントの命名、パスワードの使用およびその他のガイドラインを考慮してください。

データを保護するために次のガイドラインに従うことを検討してください。

  • アカウント名とパスワード: Oracle Audit Vault ServerコンソールUI、およびroot、support、sysアカウントにセキュアなパスワードを使用し、これらのパスワードを安全に保持します。

  • 管理者アカウント: Oracle Audit Vault and Database Firewallの管理者アカウントを共有しないでください。

  • 強力なパスワード・ポリシー: 強力なパスワードを採用するようにユーザーに促します。

  • インストール済のアカウント: Oracle Audit Vault and Database Firewallには、オペレーティング・システム・アカウントおよびデータベース・アカウントが組み込まれています。このタイプの新規アカウントを追加しないでください。既存のアカウントはロック解除しないでください。それを行うと、Oracle Audit Vault and Database Firewallシステムのセキュリティが損なわれる場合があります。

  • セキュアなアーカイブ: Oracle Audit Vault and Database Firewallは、ネットワーク経由でアーカイブ・データを送信します。アーカイブ先と中間のネットワーク・インフラストラクチャの両方を保護します。

  • リモート・アクセス: Oracle Audit Vault Serverコンソールのサービス・ページの「設定」タブでは、次のものへのアクセスを制御します。
    • Webコンソール
    • シェル(ssh)
    • SNMP

    リモート・アクセスを付与するときは、次のガイドラインに従います。

    • 特定のタスクに必要である場合にのみアクセス権を付与し、その後、そのタスクが完了したらアクセス権を取り消します。

    • IPアドレスによりアクセスを制限します。これはシステムのインストール後すぐに実行します。

    • ターミナル(シェル)アクセス権は、パッチ更新の実行時、またはマニュアルもしくはOracleサポートによって求められた場合にのみ付与します。

3.2 セキュリティに関する一般的な推奨事項

次に示す、Oracle Audit Vault Server and Database Firewall (Oracle AVDF)の全般的なセキュリティの推奨事項に従ってください。

  • Oracle Database Firewallを使用して不要なトラフィックをブロックしている場合は、データベース・クライアントとデータベースの間のすべてのデータ・フローがDatabase Firewallを経由するようにします。これには、リクエストとレスポンスの両方が含まれます。
  • 対象のサイトにとって適切なセキュリティ対策を使用して、Oracle AVDFが収容されているコンピュータへのアクセスを制御します。インストールしたシステムのセキュリティは、インストール中に物理的または仮想的にコンソールにアクセスする人物によって侵害される可能性があるため、特定の信頼できるユーザーのみにアクセス権を付与します。
  • パスワードがベスト・プラクティスに準拠していることを確認します。
  • 管理者と監査者のロールをそれぞれ別のユーザーに割り当て、管理者と監査者の業務を分離します。
  • Audit Vault Serverユーザーに、適切な管理者ロール、スーパー管理者ロール、監査者ロールおよびスーパー監査者ロールを割り当てます。
  • デフォルトでは、Oracle AVDFに関連するアカウント(Oracle OSユーザー・アカウント、Oracle Gridアカウント、任意のOracle Database Vaultアカウント(たとえば、DV_OWNERロールとDV_ACCTMGRロールが付与されたユーザー)がロックされます。)これらのアカウントがロックされたままになっていることを確認します。
  • ユーザー間およびログイン・セッション間でパスワードを共有しないようにします。異なるユーザーによるアクセスを区別できるように、新しいオペレーティング・システム・ユーザーを追加します。
  • システム・ログの転送を構成する場合は、適切な暗号化を使用して、ネットワーク・アクセス権がある関係者(ネットワーク管理者など)が機密性の高いデータにアクセスできないようにします。「TLSによるリモートsyslogの構成」を参照してください。

3.3 外部ネットワークの依存関係

外部ネットワークの重要な依存関係を考慮して、Oracle AVDF構成のセキュリティを確保します。

Audit Vault ServerまたはDatabase Firewallに外部ネットワーク・サービスを追加する場合は、それらのサービスをデプロイメントの信頼モデルに含めます。

たとえば、DNSサーバーをアプライアンスに追加する場合は、DNSサーバーを信頼して、検索するホスト名に関する正しい情報を提供します。何者かがDNSサーバーを侵害している場合、そのホスト名を使用してAudit Vault ServerまたはDatabase Firewallがアクセスするネットワーク・エンドポイントを制御できます。

NFSやNTPなどの他のサービスにも類似する信頼関係があります。

このため、次のものが適切に保護されている場合にのみ、Audit Vault ServerまたはDatabase Firewallにネットワーク・サービスを追加します。

  • サービス
  • ホスト・サーバー
  • 中間ネットワーク

3.4 ネットワークベース・ソリューションのデプロイに関する考慮事項

ネットワークベース・ソリューションをデプロイする場合の考慮事項について学習します。

3.4.1 Database Firewallを使用した暗号化トラフィックのモニター

Database Firewallでは、データベース・クライアントとOracle Database間で構成されている場合、ネイティブ・ネットワーク暗号化(NNE)トラフィックのモニターがサポートされています。

Oracle Audit Vault and Database Firewall (Oracle AVDF)リリース20.7以降、Database Firewallでは、Database Firewallがプロキシ・モードでデプロイされている場合、データベース・クライアントとOracle Database間のTLS暗号化SQLトラフィックのモニターがサポートされています。Database Firewallは、データベース・クライアントからのセッションを終了し、データベース・サーバーへの新しいTLSアウトバウンド・セッションを作成するTLSプロキシとして機能します。

Oracle AVDFリリース20.8以降、Database Firewallでは、データベース・クライアントとOracle Real Application Clusters (Oracle RAC)間のTLS暗号化SQLトラフィックのモニターがサポートされています。

Oracle以外のデータベースのTLSトラフィックをモニターするには、TLS終了ソリューションを使用して、Database Firewallに到達する直前にTLSトラフィックを終了します。

3.4.2 Database Firewall Server側のSQLおよびコンテキスト構成の管理

Database Firewall SQLおよびコンテキスト構成を管理する方法を学習します。

Database Firewallポリシー強制は、データベース・クライアントとサーバー間のSQLトラフィックを取得して理解することに依存しています。Database Firewallでは、アプリケーション層とデータベース・サーバー間のネットワーク・トラフィックのみを分析するため、データベース・サーバーから直接送信されるSQLを調べることはできません。Database Firewallで調べることができないSQL文のタイプの中には、ストアド・プロシージャおよびコールアウトから実行する、システム提供のSQLとユーザー定義のSQLがあります。また、バックグラウンド・ジョブ(DBMS_JOBまたはDBMS_SCHEDULER PL/SQLパッケージによってOracleデータベース内で作成されたものなど)から実行されたSQLと、DDLやその他のSQL文から間接的に実行されたSQLも調べることができません。Oracle AVDFの監査機能を使用すると、これらのタイプのSQL文を取得できます。

Database Firewallは、その実行コンテキスト全体をネットワーク・トラフィックから取得した情報を使用して作成します。ただし、強制は、サーバー上のコンテキスト情報に基づています。コンテキストが欠落していると、データベース・オブジェクトで使用する識別子の解決に影響します。

3.4.3 様々なデータベース・アクセス・パスでのOracle AVDFの動作

データベース・アクセス・パスでOracle AVDFがどのように動作するかについて学習します。

Oracle AVDFは、次のタイプのデータベース・アクセス・パスで動作します。

  • SQL以外のプロトコルのアクセス: データベース・プラットフォームは、データベースSQLベース・プロトコル以外の様々なネットワーク・プロトコルをサポートしています。たとえば、Oracle Databaseは、データベース内のデータに対してHTTP、FTP、アドバンスト・キューイング、ダイレクト・パスおよびNFSアクセスをサポートしています。Database Firewallでポリシー強制が適用されるのは、データベースへのSQLベースのアクセスに対してのみです。Database Firewallで理解可能なプロトコルは、Oracle TTC/Net、Microsoft SQL ServerやSybase ASEに使用されるTabular Data Stream (TDS)、およびIBM Distributed Relational Database Architecture (DRDA)です。

  • IPv6接続: Oracle AVDFは、IPv6デプロイメントをサポートしていません。

  • TCPベース以外の接続: Database Firewallでは、データベース・サーバーへのTCPベースのネットワーク接続のみがサポートされます。Systems Network Architecture (SNA)、Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX)など、TCP以外のプロトコルを使用したデータベース・サーバーへの接続は監視できません。

3.4.4 共有サーバー・モードで構成されたOracle DatabaseターゲットのDatabase Firewall構成

Database Firewallの共有サーバー構成の管理について学習します。

共有サーバー・アーキテクチャにより、ユーザー・プロセスがサーバー・プロセスを共有することをデータベースで許可できます。ディスパッチャ・プロセスは、受信した複数のネットワーク・セッション・リクエストを共通キューに送信し、次に、これらのセッション・リクエストを共有サーバーで使用可能な次のプロセスにリダイレクトします。デフォルトでは、Oracle DatabaseでTCPプロトコルに対するディスパッチャ・サービスが1つ作成されます。init.oraファイルでは、この設定は次のようにDISPATCHERSパラメータによって制御されます。

dispatchers="(PROTOCOL=tcp)"

デフォルトの構成では、動的ポートは、TCPプロトコルを使用して受信接続をリスニングします。共有サーバー構成では、多数のユーザー・プロセスがこの動的ポートでディスパッチャに接続します。このポートでの接続を監視するようにDatabase Firewallが構成されていない場合は、これらの接続にポリシーを強制することはできません。Database Firewallの接続を簡単に構成するには、DISPATCHERSパラメータにポート番号を明示的に指定してください。たとえば:

dispatchers="(PROTOCOL=tcp)(PORT=nnnn)"

nnnnの値を選択し、そのアドレスを通常のリスナー・アドレスとともに保護するようにDatabase Firewallを構成します。

関連項目:

3.4.5 クライアントおよびリスナーの動作に関するその他の考慮事項

クライアントおよび共有リスナーを理解するためのその他の問題について学習します。

  • クライアント側のコンテキスト: クライアント・プログラム名やクライアント・オペレーティング・システム・ユーザー名など、クライアント側のコンテキスト情報を使用するようにOracle Database Firewallポリシーを構成できます。クライアントがこの情報をデータベースに送信すると、Oracle Database Firewallはそれをネットワークから取得します。Oracle Database Firewallでは、クライアント側またはネットワークの整合性を制御することも強制することもありません。セキュリティ・ポリシーの定義にこの情報を使用する前に、この情報の整合性を考慮してください。

  • 共有リスナー上の複数のデータベースおよびサービス: Oracle Database Firewallは、Oracle Databaseサービス名に基づいてポリシーをサポートしています。Oracle以外のデータベースの場合は、IPアドレスとポート番号に基づいたポリシーが強制されます。単一のリスナー・エンドポイント(IP_address:port)が複数のデータベースで共有されている構成では、個々の各データベースに対するトラフィックをOracle Database Firewallで区別できません。

3.5 特別な構成に関するセキュリティ上の考慮事項

特別な構成でのセキュリティに関する考慮事項について学習します。

3.5.1 カスタム・コレクタの開発

カスタム・コレクタの開発について学習します。

カスタム・コレクタを開発する場合は、次のことに注意してください。

  • リソースのリークを防止します。JDBCリソースが適切にクローズされることを確認します。これらのリソースには接続、結果セットおよび文が含まれます。
  • データの損失を回避します。カスタム・コレクタによって正常に収集された後にのみ、監査データがターゲット・システムからパージされるようにします。
  • ターゲット・システムに対して頻繁に問合せを行わないようにします。
  • カスタム・コレクタが、ターゲット・ホストのCPU、メモリーなどシステム・リソースを消費しすぎないようにします。
  • 監査レコードには機密情報が含まれているため、監査データをロギングしないようにします。
  • ターゲット・システムで必要な権限のみを、エージェントへのアクセス権を持つユーザーに付与します。
  • 必要なファイルのみをカスタム・コレクタの.jarファイルに追加します。
  • カスタム・コレクタのコードが、ターゲット・システムから安全に監査データを収集するようにします。

    ノート:

    収集フレームワークにより、監査データがコレクタからOracle Audit Vault Serverに安全に転送されます。

3.6 Transport Layer Securityレベルの設定について

Oracle AVDFでのTransport Layer Security (TLS)レベルの設定について学習します。

このトピックでは、Oracle Audit Vault and Database Firewallアプライアンスにデプロイされる様々なレベルの接続暗号化について説明します。Oracle AVDFでは、コンポーネント間通信にTLSを使用します。

次の接続などに関して、TLSレベルおよび暗号化スイートを変更できます。

  • Audit Vault Serverとエージェントまたはホスト・モニター・エージェントとの接続

  • ホスト・モニター・エージェントとDatabase Firewallとの接続

  • Audit Vault ServerとDatabase Firewallとの接続

  • Audit Vault Serverコンソールおよびエンド・ユーザー・ブラウザ

ノート:

Oracle AVDFアプライアンスで使用される接続暗号化強度

TLSレベル TLSのバージョン 説明

レベル4

(新規インストール時のデフォルト)

 
TLSv1.2

このレベルは最も強力であり、Oracle Audit Vault and Database Firewall内のすべてのコンポーネント間の通信に対してTLSをバージョン1.2に制限します。

ノート:

サポートされているサービスが明示的に低いレベルのTLSを必要としていないかぎり、すべてのサービスにレベル4を使用することをお薦めします。

レベル3

 
TLSv1.2

このレベルでは、Level-4で実行されるすべての処理がサポートされます。

Oracle AVDFリリース20.1から20.3の場合:

  • Audit Vault AgentをIBM AIXにデプロイする必要がある場合は、TLSレベルをレベル3以下に設定してください(次の表の5行目を参照してください)。
  • レベル3では、Audit Vault AgentとAudit Vault Server間の通信にTLS 1.2またはTLS 1.1を使用します。ホスト監視エージェントとDatabase Firewall間の通信も同様です。

Oracle AVDF 20.4以降、レベル3はAudit Vault AgentとAudit Vault Server間の通信にTLS 1.2を使用します。ホスト監視エージェントとDatabase Firewall間の通信も同様です。

レベル2

 
TLSv1.2
TLSv1.1

このレベルでは、レガシーの暗号化および非推奨の暗号化に対するサポートが追加されます。

ノート:

  • Oracle AVDFリリース20.1から20.3へのアップグレード時に、アップグレード・プロセスが、マルチアプライアンス・デプロイメントのアップグレード中に接続を維持するために自動的にレベル4に設定されることはありません。アップグレードが完了したら、レガシー・システムとの相互運用性が必要でないかぎり、レベル4に設定してください。
  • Oracle AVDFリリース20.4 (以降)へのアップグレード時に、アップグレード・プロセスが、すべての場合において自動的にレベル4に設定されることはありません。アップグレード・プロセス(エージェントを含む)が完了したら、レベル4に設定することをお薦めします。

レベル1

(カスタム)

 
TLSv1.2

これは、デフォルトではレベル4の強度で構成された、カスタマイズ可能な暗号セットです。

TLSレベルおよびその他のタスクを変更する方法

行番号 タスク コマンド 詳細情報

1

Audit Vault ServerおよびDatabase Firewallの既存のTLSレベルを確認する

 
grep CIPHER_LEVEL /usr/local/dbfw/etc/dbfw.conf

supportユーザーとしてログインし、このコマンドを実行します。Audit Vault ServerとDatabase Firewallの実際の構成を確認するには、このコマンドを使用します。

2

TLSレベルを設定し、オプションをさらに見つける

 
/usr/local/dbfw/bin/priv/configure-networking --help

rootユーザーとしてログインし、このコマンドを実行します。新規インストール時には、デフォルトではTLSレベルはレベル4に設定されます。

アップグレード時には、デフォルトではレベル2に設定されます。これは、ほとんどの状況に適しています。

設定されたレベルは変更可能です。使用可能なオプションを見つけるには、このコマンドを使用します。

3

Audit Vault ServerコンソールのTLSレベルを設定します。

 
/usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level [LEVEL]

rootユーザーとしてログインし、このコマンドを実行します。このコマンドは、AVS GUIへのWebブラウザ接続のTLSレベルを設定します。このレベルは1、2、3または4に設定できます。

4

Audit Vault ServerとDatabase Firewallとの通信のTLSレベルを設定する

 
/usr/local/dbfw/bin/priv/configure-networking --internal-tls-cipher-level [LEVEL]

rootユーザーとしてログインし、このコマンドを実行します。このコマンドは、目的のTLSレベルを設定し、内部サービスを再起動します。このレベルは1、2、3または4に設定できます。

5

Audit Vault AgentとAudit Vault Serverとの通信、およびホスト・モニター・エージェントとDatabase Firewallとの通信のTLSレベルを設定します。

 
/usr/local/dbfw/bin/priv/configure-networking --agent-tls-cipher-level [LEVEL]

rootユーザーとしてログインし、このコマンドを実行します。このコマンドは、Audit Vault AgentとAudit Vault Serverとの通信、およびホスト・モニター・エージェントとDatabase Firewallとの通信のためのTLSレベルを設定します。このレベルは1、2、3または4に設定できます。

ノート:

configure-networkingコマンドを実行した後に、すべてのエージェントを指定のTLSレベルにアップグレードするには、次のステップを実行します。

1. Audit Vault Serverコンソールにrootユーザーとしてログインします。

2. 次のコマンドを使用してディレクトリを変更します。

cd /usr/local/dbfw/bin/priv

3. 次のコマンドを使用してスクリプトを実行します。

./send_agent_update_signal.sh

このコマンドは、1時間以内に複数回実行できません。

6

カスタマイズした暗号セットを適用する

Audit Vault Serverコンソールの場合:

  • 編集: /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group.xml

    実行: 
    /usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level 1

Audit Vault Agentまたはホスト監視エージェントの場合:

  • 編集: /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_agent.xml

  • 実行: 
    /usr/local/dbfw/bin/priv/configure-networking --agent-tls-cipher-level 1

アプライアンス間通信の場合:

  • 編集: /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_services.xml

  • 実行: 
    /usr/local/dbfw/bin/priv/configure-networking --internal-tls-cipher-level 1

新規インストール時には、デフォルトでは製品はレベル4に設定されます。アップグレード時には、レベル2に設定されます。これは、ほとんどの状況に適しています。これはカスタマイズできます。アップグレード・プロセス中に、暗号レベルが最大のセキュリティに設定されていないことを示すプロンプトと警告メッセージが表示されます。暗号レベルがアップグレード中に自動的に変更されることはありません。

作成したファイルからカスタム定義レベルを適用するには、このコマンドを使用します。これらのコマンドは、Webブラウザ接続のTLSレベルを設定し、内部サービスおよびAudit Vault Serverを再起動します。

ノート:

カスタマイズされた暗号セットを適用するコマンドを実行した後、/var/log/messagesにあるシステム・ログ・ファイルのエラー出力を確認して、ファイルにエラーがないことを確認してください。

rootユーザーとしてログインし、コマンドを実行してカスタム・レベルの構成ファイルを編集します。カスタマイズ可能な暗号スイート・セットは、このファイルで定義されます。新規インストール時には、デフォルトでは製品はレベル4に設定されます。このファイルを、暗号スイートをさらに制限して、製品で使用可能な暗号を含むように変更できます。

7

使用可能な暗号スイートをすべて示すリストを表示する

 
openssl ciphers -v

supportユーザーとしてログインして、このコマンドを実行します。現在使用可能な一連の暗号スイートを表示するには、このコマンドを使用します。

8

インバウンド接続のTLSレベルをデータベース・クライアントからDatabase Firewallモニタリング・ポイントに変更する。

詳細は、Database Firewallモニタリング・ポイントの変更を参照してください。

Oracle AVDFリリース20.7以降、Database Firewallでは、TLS暗号化SQLトラフィックがサポートされています。TLSレベルは、Audit Vault Serverコンソールを使用して、Database Firewallモニタリング・ポイントの「詳細」設定で変更できます。

9

アウトバウンド接続のTLSレベルをDatabase Firewallモニタリング・ポイントからOracle Databaseに変更する。

詳細は、Database Firewallモニタリング・ポイントの変更を参照してください。

Oracle AVDFリリース20.7以降、Database Firewallでは、TLS暗号化SQLトラフィックがサポートされています。TLSレベルは、Audit Vault Serverコンソールを使用して、Database Firewallモニタリング・ポイントの「詳細」設定で変更できます。

TLSレベルの変更が必要な状況

内部TLSレベルはレベル4のままにすることをお薦めします。TLSレベルの変更が必要な状況について、詳細を次に示します。

コンポーネント 状況

内部通信

セキュリティを強化するには、レベル4に設定することをお薦めします。

Audit Vault Serverコンソール(GUI)

古いブラウザをサポートするには、ブラウザと一致するようにTLSレベルを設定します。

Audit Vault Agent / ホスト・モニター・エージェント / Audit Vault Server

セキュリティを強化するには、レベル4に設定することをお薦めします。

IBM AIXでデプロイされたAudit Vault Agent

Oracle AVDFリリース20.1から20.3へのフレッシュ・インストールでは、レベル4に設定されます。Audit Vault AgentのいずれかがIBM AIXにデプロイされている場合は、TLSレベルをレベル3に変更してください。

Oracle AVDF 20.4以降のフレッシュ・インストールでは、レベル4に設定され、変更は必要ありません。

カスタムの暗号セットの設定

rootユーザーとしてログインし、この手順を実行してカスタム暗号セットを設定します。これを行うには、TLSレベルを定義するカスタム・ファイルを作成してから、そのファイルを適用します。

  1. カスタマイズ可能な一連のTLSレベルは、次のファイルで定義されています。

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group.xml

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_agent.xml

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_ssl_services.xml

  2. tls_configuration_custom_group.xmlファイルは、製品で使用可能な暗号を含むように、必要に応じて変更できます。
  3. 次のコマンドを実行して、使用可能な暗号の完全なリストを表示します。
    openssl ciphers –v
  4. tls_configuration_custom_group.xmlファイルを開いて、ファイルの形式を確認します。形式は次のようになる必要があります。
    <?xml version="1.0" encoding='UTF-8' standalone='yes'?>
    <tls_configuration_groups xmlns='http://www.oracle.com/avdf'>
    <tls_configuration level="1">
    <ssl_protocols>
    <ssl_protocol>...</ssl_protocol>
    </ssl_protocols>
    <ssl_cipher_suite>
    <ssl_cipher>...</ssl_cipher>
    </ssl_cipher_suite>
    </tls_configuration>
    </tls_configuration_groups>
  5. カスタマイズ可能なtls_configuration_custom_group.xmlファイルでは、必要に応じて次のタグのみを追加または削除できます。
    <ssl_protocol>...</ssl_protocol>
  6. 複数のタグは、次のように順序どおりに適用できます。
    <ssl_cipher>...</ssl_cipher>
  7. 値は、次のApacheプロトコル値のいずれかにする必要があります。
    1. TLSv1.2
    2. TLSv1.1
    3. TLSv1 (Deprecated)
  8. 次のコマンドを実行してカスタム・セットを適用します。
    /usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level 1 --internal-tls-cipher-level 1 --agent-tls-cipher-level 1

    関連項目:

    TLS暗号化SQLトラフィックの監視

3.7 証明書

Oracle AVDFの様々な証明書について学習します。

3.7.1 プラットフォーム証明書

Oracle AVDFプラットフォーム証明書について学習します。

Oracle AVDFでは、様々なサービスによる内部通信にプラットフォーム証明書を使用します。

Oracle AVDFリリース20.6.0.0.0以降では、期限切れになる前に、Audit Vault ServerおよびDatabase Firewallアプライアンスのプラットフォーム証明書を更新できます。有効期限が90日未満の場合、/var/log/messagesファイルに警告メッセージ(ODF 10729)が表示されます。証明書を手動で更新するための詳細な手順は、Database Firewallのメッセージの項のODF 10729に対するアクション列を参照してください。

証明書が手動で更新されず、30日未満でまもなく期限切れとなる場合、プラットフォーム証明書は自動的に更新され、関連するすべてのサービスが再起動されます。

3.7.2 Audit Vault Agent証明書について

Audit Vault Agent証明書について説明します。

Audit Vault Agent証明書は、AgentとAudit Vault Serverの間の通信に使用されます。こうしたAudit Vault Agent証明書は、Oracle AVDFサービスが中断されないように、ローテーションまたは更新する必要があります。

Oracle AVDFリリース20.7以降では、証明書は手動で更新できます。Oracle AVDFリリース20.6以前では、証明書の更新前にパッチを適用する必要があります。

Audit Vault Agentの証明書がローテーションまたは更新されると、その証明書は、すべてのリリースで27か月間有効になります。

ノート:

証明書のローテーションまたは更新は、Audit Vault AgentとHost Monitor Agentに適用されます。

3.7.3 Audit Vault Agent証明書のローテーション

Audit Vault Agent証明書のローテーション方法について説明します。

Audit Vault Agentは、各種コンポーネントおよびサービスとの内部通信に証明書を使用します。こうした証明書は、次の表に示すとおりに特定の期間有効です。

表3-1 Audit Vault Agent証明書の有効期間

Audit Vault Serverリリース Audit Vault Agent証明書の有効期間
Oracle AVDF 12.2 10年
Oracle AVDF 20.1以降 27か月
次のステップを実行して、Audit Vault Agent証明書をローテーションします。

ヒント:

Oracle AVDF 20.9以降では、Audit Vault Agentの証明書がまもなく期限切れになるというシステム・アラートを受信した場合は、「ステップ4: Audit Vault Agent証明書のローテーション」までスキップできます。
3.7.3.1 ステップ1: Audit Vault Agent証明書の検証用パッチのダウンロード

このパッチをダウンロードして、Audit Vault Agent証明書の有効性を確認し、有効期限を調べます。

  1. My Oracle Supportにログインします。
  2. パッチ番号34412167を検索します。
  3. ダウンロード
    • Oracle AVDF 20.1-20.7の場合: p34412167_201000_Linux-x86-64.zip
    • Oracle AVDF 20.8-20.9の場合: p34412167_208000_Linux-x86-64.zip
  4. zipファイルの内容を抽出します。
  5. 抽出した場所からAudit Vault Serverの/tmpディレクトリにshow-agent-certificate.pyをコピーします。
3.7.3.2 ステップ2: Audit Vault Agent証明書の有効性の確認

Audit Vault Agent証明書の有効性を確認し、有効期限を調べます。

  1. rootユーザーとしてSSHを通じてAudit Vault Serverに接続します。
  2. oracleユーザーに切り替えます。
    su - oracle
  3. $ORACLE_HOME/binディレクトリに/tmp/show-agent-certificate.pyをコピーします。
  4. 次のコマンドを実行して、Audit Vault Agent証明書の有効性を確認します。
    ./show-agent-certificate.py
  5. 有効期限をメモします。
3.7.3.3 ステップ3: Audit Vault Agentへのパッチ適用による証明書ローテーションの有効化(Oracle AVDF 20.1から20.6のみ)

ステップ2の結果が、エージェントの証明書がすでに期限切れになっていることや、今後3か月以内に期限切れになることを示している場合は、エージェントの証明書をローテーションする必要があります。Oracle AVDFリリース20.1から20.6の場合は、最初にAudit Vault Agentにパッチを適用することで、証明書のローテーションを有効にする必要があります。

ノート:

高可用性環境では、このパッチをプライマリとスタンバイの両方のAudit Vault Serverに適用します。

  1. 拡張リクエスト(ER) 33869404のバンドル・パッチをリクエストします。
  2. パッチに付属するREADMEの指示に従い、Audit Vault Serverを通じてAudit Vault Agentにパッチを適用します。

    ノート:

    このパッチは、Audit Vault Server証明書のローテーションを実行する前に適用してください。「Audit Vault Server証明書のローテーション」を参照してください。
  3. パッチ適用の完了後に、Audit Vault Agentの状態を確認します。
    • すでに証明書が期限切れになっている場合、エージェントはSTOPPED状態になります。
    • まだ証明書が期限切れになっていない場合、エージェントはRUNNING状態になっています。エージェントが「STOPPED」状態の場合は、Oracle Supportに連絡してください。
3.7.3.4 ステップ4: Audit Vault Agent証明書のローテーション

ステップ2の結果が、エージェントの証明書がすでに期限切れになっていることや、今後30日以内に期限切れになることを示している場合は、エージェントの証明書をローテーションする必要があります。

ノート:

高可用性環境では、プライマリAudit Vault Serverにのみ次のステップを実行します。

  1. rootユーザーとしてSSHを通じてAudit Vault Serverに接続します。
  2. ディレクトリを変更します: 
    cd /opt/avdf/lib/ruby/avdf
  3. 次のコマンドを実行して、Audit Vault Agent証明書をローテーションします。 
    ruby update_agent_cert_task.rb
  4. 証明書がすでに期限切れの場合:

    1. administratorとしてAudit Vault Serverコンソールにログインします。

    2. 「エージェント」タブをクリックします。
    3. 停止しているすべてのエージェントのチェック・ボックスを選択して、「非アクティブ化」をクリックします。
    4. 非アクティブ化されたすべてのエージェントのチェック・ボックスを選択して、「アクティブ化」をクリックします。
    5. すべてのエージェントのエージェント・アクティブ化キーをコピーするか、メモします。
    6. 左側のナビゲーション・メニューで「ダウンロード」をクリックします。
    7. agent.jarをダウンロードします
    8. すべてのエージェント・マシンにagent.jarファイルを転送します。
    9. 次のコマンドを実行して、すべてのAudit Vault Agentを起動します: 
      1. agentctl start -k
      2. エージェント・アクティブ化キーを次の形式で貼り付けるか、入力します。

        <Agent Name>::XXXX-XXXX-XXXX-XXXX-XXXX

        入力してもアクティブ化キーは表示されません。

    Oracle AVDF 20.9でエージェントレス収集を使用しているときに、すでに証明書が失効している場合は、次のステップを実行します

    1. SSHを使用して宛先Audit Vault Serverにログインし、rootユーザーに切り替えます。

      「SSHを使用したOracle AVDFアプライアンスへのログイン」を参照してください。

    2. 次のコマンドを実行して、エージェントレス収集サービスを再デプロイします
      /usr/local/dbfw/bin/deploy_default_agent.py
  5. 証明書がまだ期限切れになっていない場合:
    1. ローテーション後に、Audit Vault Agent証明書を検証します。「ステップ2: Audit Vault Agent証明書の有効性の確認」を参照してください。

      Audit Vault Agentによる新しい証明書の更新には、最長で12時間かかります。この時間は、Audit Vault Serverに登録されているエージェントの数に応じて異なります。

    2. 12時間後に、Audit Vault AgentがRUNNING状態になっていることを確認します。STOPPED状態になっている場合は、Oracle Supportに連絡してください。

ノート:

高可用性環境では、プライマリAudit Vault Serverにのみ次のステップを実行します。

  1. SSHを使用してAudit Vault Serverにログインし、rootユーザーに切り替えます。

    「SSHを使用したOracle AVDFアプライアンスへのログイン」を参照してください。

  2. ディレクトリを変更します:
    cd /opt/avdf/lib/ruby/avdf
  3. 次のコマンドを実行して、Audit Vault Agent証明書をローテーションします。
    ruby update_agent_cert_task.rb
  4. すでに証明書が期限切れになっていて、エージェントレス収集を使用している場合:

    1. SSHを使用して宛先Audit Vault Serverにログインし、rootユーザーに切り替えます。

      「SSHを使用したOracle AVDFアプライアンスへのログイン」を参照してください。

    2. 次のコマンドを実行して、エージェントレス収集サービスを再デプロイします
      /usr/local/dbfw/bin/deploy_default_agent.py

3.7.4 Audit Vault Server証明書のローテーション

Audit Vault Server証明書のローテーション方法について説明します。

Audit Vault Serverは、各種コンポーネントおよびサービスとの内部通信に証明書を使用します。Oracle AVDFを使用すると、Audit Vault Server証明書を失効前にローテーションできます。

  1. My Oracle Supportにログインします。
  2. パッチ番号34378212を検索します。
  3. p34378212_191000_Linux-x86-64.zipをダウンロードします。
  4. zipファイルの内容を抽出します。
  5. 抽出した場所からAudit Vault Serverの/tmpディレクトリにgensslcert.avs.tar.gzをコピーします。
  6. Audit Vault Serverへのインストールを完了します。

    1. supportユーザーとしてSSHを使用してAudit Vault Serverにログインします。

      ノート:

      Oracle Cloud Infrastructure (OCI)マーケットプレイス・イメージを使用している場合は、OPCユーザーとしてSSHを介して接続します。 
      ssh support@<audit_vault_server_ip_address>

    2. rootユーザーに切り替えます。

      su - root

      ノート:

      OCIマーケットプレイス・イメージを使用している場合は、sudo su -コマンドを使用します。

    3. 新規ディレクトリを作成:

      mkdir /root/gensslcert

    4. 新しいディレクトリにgensslcert.avs.tar.gzをコピーします。 

      cp /tmp/gensslcert.avs.tar.gz /root/gensslcert

    5. 新しいディレクトリに変更します。

      cd /root/gensslcert

    6. ファイルを抽出します。

      tar xvfz gensslcert.avs.tar.gz
  7. 次のコマンドをrootユーザーとして実行して、Audit Vault Serverで新しい認証局(CA)証明書を生成します。このプロセスでは、Audit Vault Serverの一元的な自己署名CA証明書を更新します。
    /root/gensslcert/gensslcert destroy-certs create-ca
  8. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  9. CA証明書バンドルとサービスを更新および再生成します。

    1. Audit Vault Serverアプライアンスで、rootユーザーとして次のコマンドを実行します: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    2. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
      systemctl reload httpd
      systemctl restart controller
  10. プライマリ・サーバーで、rootユーザーとして次のコマンドを実行します: 
    systemctl start monitor
  11. 新しいCA証明書をコピーして、Audit Vault Serverからリンクされている各Database Firewallインスタンスに転送します:
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/primary.ca
    Database Firewallで、次のコマンドをrootユーザーとして実行します: 
    cp /tmp/primary.ca /usr/local/dbfw/etc/controller.crt
    cp /tmp/standby.ca /usr/local/dbfw/etc/controller_second.crt
  12. Database FirewallとAudit Vault Serverのコントローラを更新します。
    Database Firewallで、次のコマンドをrootユーザーとして実行します: 
    cat /tmp/primary.ca | /opt/avdf/config-utils/bin/config-avs set avs=primary address=<primary-ip> certificate=-
    cat /tmp/standby.ca | /opt/avdf/config-utils/bin/config-avs set avs=secondary address=<standby-ip> certificate=-
  13. Database Firewallアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart stund
  14. ローカル証明書およびピア証明書が有効であることを検証します。

    次のローカル証明書を検証します。

    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt
    • /usr/local/dbfw/etc/avs/avs_apex_client.crt
    • /usr/local/dbfw/etc/avs/avswallet
    • /etc/pki/tls/certs/localhost.crt

    次のピア認証を検証します:

    • /usr/local/dbfw/etc/avs/fwcerts/fw-[ip].cert
    • /usr/local/dbfw/etc/ha_partner.crt
    • /var/lib/oracle/dbfw/av/conf/ava.cer
    • /var/lib/oracle/dbfw/av/conf/avs.cer

    証明書の有効性は、config-diagnostics、sappdiagまたはopenssl x509コマンドを使用して検証します。 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  1. My Oracle Supportにログインします。
  2. パッチ番号34378212を検索します。
  3. p34378212_191000_Linux-x86-64.zipをダウンロードします。
  4. zipファイルの内容を抽出します。
  5. 抽出した場所からAudit Vault Serverの/tmpディレクトリにgensslcert.avs.tar.gzをコピーします。
  6. Audit Vault Serverへのインストールを完了します。

    1. supportユーザーとしてSSHを使用してAudit Vault Serverにログインします。

      ノート:

      Oracle Cloud Infrastructure (OCI)マーケットプレイス・イメージを使用している場合は、OPCユーザーとしてSSHを介して接続します。 
      ssh support@<audit_vault_server_ip_address>

    2. rootユーザーに切り替えます。

      su - root

      ノート:

      OCIマーケットプレイス・イメージを使用している場合は、sudo su -コマンドを使用します。

    3. 新規ディレクトリを作成:

      mkdir /root/gensslcert

    4. 新しいディレクトリにgensslcert.avs.tar.gzをコピーします。 

      cp /tmp/gensslcert.avs.tar.gz /root/gensslcert

    5. 新しいディレクトリに変更します。

      cd /root/gensslcert

    6. ファイルを抽出します。

      tar xvfz gensslcert.avs.tar.gz
  7. 次のコマンドをrootユーザーとして実行して、プライマリAudit Vault Serverで新しい認証局(CA)証明書を生成します。このプロセスでは、Audit Vault Serverの一元的な自己署名CA証明書を更新します。
    /root/gensslcert/gensslcert destroy-certs create-ca
  8. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  9. プライマリAudit Vault ServerからスタンバイAudit Vault ServerにCA証明書を転送します:
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    scp /usr/local/dbfw/etc/ca.crt support@<standby-ip>:/tmp/ha_partner.crt
    スタンバイ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    cp /tmp/ha_partner.crt /usr/local/dbfw/etc/ha_partner.crt
  10. スタンバイAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  11. 次のコマンドをrootユーザーとして実行して、スタンバイAudit Vault ServerインスタンスでCA証明書とすべての証明書を再生成します。
    /root/gensslcert/gensslcert destroy-certs create-ca
  12. スタンバイAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  13. プライマリ・インスタンスにスタンバイCA証明書を転送します:
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    cp /tmp/ha_partner.crt /usr/local/dbfw/etc/ha_partner.crt
    スタンバイ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    scp /usr/local/dbfw/etc/ca.crt support@<primary-ip>:/tmp/ha_partner.crt
  14. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  15. CA証明書バンドルとサービスを更新および再生成します。プライマリおよびスタンバイのAudit Vault Serverインスタンスで、次のステップを1つずつ実行します。

    1. プライマリAudit Vault Serverアプライアンスで、rootユーザーとして次のコマンドを実行します: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    2. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
      systemctl reload httpd
      systemctl restart controller

    3. スタンバイAudit Vault Serverアプライアンスで、rootユーザーとして次のコマンドを実行します: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    4. スタンバイAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
      systemctl reload httpd
      systemctl restart controller
  16. プライマリAudit Vault Serverアプライアンスで、オブザーバを再起動します。
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    systemctl stop monitor

    oracleユーザーに切り替えます。

    su - oracle
    プライマリ・サーバーで、次のコマンドをoracleユーザーとして実行します: 
    /usr/local/dbfw/bin/observerctl --stop
    /usr/local/dbfw/bin/observerctl --start
  17. オブザーバ・プロセスが稼働するまで2分間待機します。

    オブザーバ・ステータスを確認するには:

    1. supportユーザーとしてSSHを使用してAudit Vault Serverにログインします。

      ノート:

      Oracle Cloud Infrastructure (OCI)マーケットプレイス・イメージを使用している場合は、OPCユーザーとしてSSHを介して接続します。 
      ssh support@<audit_vault_server_ip_address>

    2. rootユーザーに切り替えます。

      su - root

      ノート:

      OCIマーケットプレイス・イメージを使用している場合は、sudo su -コマンドを使用します。

    3. oracleユーザーに切り替えます。

      su - oracle

    4. 次のコマンドを実行します。

      /usr/local/dbfw/bin/setup_ha.rb –status

      これにより、Data Guardオブザーバ・ステータスを含むすべてのステータスが表示されます。オブザーバが稼働しているときには、Data Guard Observer = yesと表示されます。

  18. プライマリ・サーバーで、rootユーザーとして次のコマンドを実行します: 
    systemctl start monitor
  19. 新しいCA証明書をコピーして、プライマリとスタンバイのインスタンスからリンクされている各Database Firewallインスタンスに転送します:
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/primary.ca
    スタンバイ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/standby.ca
    Database Firewallで、次のコマンドをrootユーザーとして実行します: 
    cp /tmp/primary.ca /usr/local/dbfw/etc/controller.crt
    cp /tmp/standby.ca /usr/local/dbfw/etc/controller_second.crt
  20. Database FirewallとAudit Vault Serverのコントローラを更新します。
    Database Firewallで、次のコマンドをrootユーザーとして実行します: 
    cat /tmp/primary.ca | /opt/avdf/config-utils/bin/config-avs set avs=primary address=<primary-ip> certificate=-
    cat /tmp/standby.ca | /opt/avdf/config-utils/bin/config-avs set avs=secondary address=<standby-ip> certificate=-
  21. Database Firewallアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart stund
  22. ローカル証明書およびピア証明書が有効であることを検証します。

    次のローカル証明書を検証します。

    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt
    • /usr/local/dbfw/etc/avs/avs_apex_client.crt
    • /usr/local/dbfw/etc/avs/avswallet
    • /etc/pki/tls/certs/localhost.crt

    次のピア認証を検証します:

    • /usr/local/dbfw/etc/avs/fwcerts/fw-[ip].cert
    • /usr/local/dbfw/etc/ha_partner.crt
    • /var/lib/oracle/dbfw/av/conf/ava.cer
    • /var/lib/oracle/dbfw/av/conf/avs.cer

    証明書の有効性は、config-diagnostics、sappdiagまたはopenssl x509コマンドを使用して検証します。 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  1. rootユーザーとして次のコマンドを実行して、Audit Vault Serverで新しい認証局(CA)証明書を生成します。このプロセスでは、Audit Vault Serverの一元的な自己署名CA証明書を更新します。 
    /usr/local/bin/gensslcert destroy-certs create-ca
  2. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  3. CA証明書バンドルとサービスを更新および再生成します。

    1. プライマリAudit Vault Serverアプライアンスで、rootユーザーとして次のコマンドを実行します: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    2. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
      systemctl reload httpd
      systemctl restart controller
  4. プライマリ・サーバーで、rootユーザーとして次のコマンドを実行します: 
    systemctl start monitor
  5. 新しいCA証明書をコピーして、Audit Vault Serverからリンクされている各Database Firewallインスタンスに転送します:
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します:
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/primary.ca
    Database Firewallで、次のコマンドをrootユーザーとして実行します:
    cp /tmp/primary.ca /usr/local/dbfw/etc/controller.crt
    cp /tmp/standby.ca /usr/local/dbfw/etc/controller_second.crt
  6. Database FirewallとAudit Vault Serverのコントローラを更新します。

    Database Firewallで、次のコマンドをrootユーザーとして実行します: 

    cat /tmp/primary.ca | /opt/avdf/config-utils/bin/config-avs set avs=primary address=<primary-ip> certificate=-
    cat /tmp/standby.ca | /opt/avdf/config-utils/bin/config-avs set avs=secondary address=<standby-ip> certificate=-
  7. Database Firewallアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart stund
  8. ローカル証明書およびピア証明書が有効であることを検証します。

    次のローカル証明書を検証します。

    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt
    • /usr/local/dbfw/etc/avs/avs_apex_client.crt
    • /usr/local/dbfw/etc/avs/avswallet
    • /etc/pki/tls/certs/localhost.crt

    次のピア認証を検証します:

    • /usr/local/dbfw/etc/avs/fwcerts/fw-[ip].cert
    • /usr/local/dbfw/etc/ha_partner.crt
    • /var/lib/oracle/dbfw/av/conf/ava.cer
    • /var/lib/oracle/dbfw/av/conf/avs.cer

    証明書の有効性は、config-diagnostics、sappdiagまたはopenssl x509コマンドを使用して検証します。 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  1. rootユーザーとして次のコマンドを実行して、プライマリAudit Vault Serverで新しい認証局(CA)証明書を生成します。このプロセスでは、Audit Vault Serverの一元的な自己署名CA証明書を更新します。 
    /usr/local/bin/gensslcert destroy-certs create-ca
  2. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  3. プライマリAudit Vault ServerからスタンバイAudit Vault ServerにCA証明書を転送します:
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    scp /usr/local/dbfw/etc/ca.crt support@<standby-ip>:/tmp/ha_partner.crt
    スタンバイ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    cp /tmp/ha_partner.crt /usr/local/dbfw/etc/ha_partner.crt
  4. スタンバイAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  5. CA証明書とすべての証明書をスタンバイAudit Vault Serverインスタンスで再生成します。

    スタンバイ・サーバーで、次のコマンドをrootユーザーとして実行します: 

    /usr/local/bin/gensslcert destroy-certs create-ca
  6. スタンバイAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  7. プライマリ・インスタンスにスタンバイCA証明書を転送します:
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    cp /tmp/ha_partner.crt /usr/local/dbfw/etc/ha_partner.crt
    スタンバイ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    scp /usr/local/dbfw/etc/ca.crt support@<primary-ip>:/tmp/ha_partner.crt
  8. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart controller
  9. CA証明書バンドルとサービスを更新および再生成します。プライマリおよびスタンバイのAudit Vault Serverインスタンスで、次のステップを1つずつ実行します。

    1. プライマリAudit Vault Serverアプライアンスで、rootユーザーとして次のコマンドを実行します: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    2. プライマリAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
      systemctl reload httpd
      systemctl restart controller

    3. スタンバイAudit Vault Serverアプライアンスで、rootユーザーとして次のコマンドを実行します: 

      cat /usr/local/dbfw/etc/ha_partner.crt /usr/local/dbfw/etc/ca.crt > /etc/pki/tls/certs/dbfw-ca.crt
    4. スタンバイAudit Vault Serverアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
      systemctl reload httpd
      systemctl restart controller
  10. プライマリAudit Vault Serverアプライアンスで、オブザーバを再起動します。
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します: 
    systemctl stop monitor

    oracleユーザーに切り替えます。

    su - oracle
    プライマリ・サーバーで、次のコマンドをoracleユーザーとして実行します:
    /usr/local/dbfw/bin/observerctl --stop
    /usr/local/dbfw/bin/observerctl --start
  11. オブザーバ・プロセスが稼働するまで2分間待機します。

    オブザーバ・ステータスを確認するには:

    1. supportユーザーとしてSSHを使用してAudit Vault Serverにログインします。

      ノート:

      Oracle Cloud Infrastructure (OCI)マーケットプレイス・イメージを使用している場合は、OPCユーザーとしてSSHを介して接続します。 
      ssh support@<audit_vault_server_ip_address>

    2. rootユーザーに切り替えます。

      su - root

      ノート:

      OCIマーケットプレイス・イメージを使用している場合は、sudo su -コマンドを使用します。

    3. oracleユーザーに切り替えます。

      su - oracle

    4. 次のコマンドを実行します。

      /usr/local/dbfw/bin/setup_ha.rb –status

      これにより、Data Guardオブザーバ・ステータスを含むすべてのステータスが表示されます。オブザーバが稼働しているときには、Data Guard Observer = yesと表示されます。

  12. プライマリ・サーバーで、rootユーザーとして次のコマンドを実行します: 
    systemctl start monitor
  13. 新しいCA証明書をコピーして、プライマリとスタンバイのインスタンスからリンクされている各Database Firewallインスタンスに転送します:
    プライマリ・サーバーで、次のコマンドをrootユーザーとして実行します:
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/primary.ca
    スタンバイ・サーバーで、次のコマンドをrootユーザーとして実行します:
    scp /usr/local/dbfw/etc/ca.crt support@<dbfw-ip>:/tmp/standby.ca
    Database Firewallで、次のコマンドをrootユーザーとして実行します:
    cp /tmp/primary.ca /usr/local/dbfw/etc/controller.crt
    cp /tmp/standby.ca /usr/local/dbfw/etc/controller_second.crt
  14. Database FirewallとAudit Vault Serverのコントローラを更新します。

    Database Firewallで、次のコマンドをrootユーザーとして実行します: 

    cat /tmp/primary.ca | /opt/avdf/config-utils/bin/config-avs set avs=primary address=<primary-ip> certificate=-
    cat /tmp/standby.ca | /opt/avdf/config-utils/bin/config-avs set avs=secondary address=<standby-ip> certificate=-
  15. Database Firewallアプライアンスを再起動します。rootユーザーとして、次のコマンドを実行します:
    systemctl reload httpd
    systemctl restart stund
  16. ローカル証明書およびピア証明書が有効であることを検証します。

    次のローカル証明書を検証します。

    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt
    • /usr/local/dbfw/etc/avs/avs_apex_client.crt
    • /usr/local/dbfw/etc/avs/avswallet
    • /etc/pki/tls/certs/localhost.crt

    次のピア認証を検証します:

    • /usr/local/dbfw/etc/avs/fwcerts/fw-[ip].cert
    • /usr/local/dbfw/etc/ha_partner.crt
    • /var/lib/oracle/dbfw/av/conf/ava.cer
    • /var/lib/oracle/dbfw/av/conf/avs.cer

    証明書の有効性は、config-diagnostics、sappdiagまたはopenssl x509コマンドを使用して検証します。 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt

3.7.5 Database Firewall証明書のローテーション

Database Firewall証明書のローテーション方法について説明します。

Database Firewallは、各種コンポーネントおよびサービスとの内部通信に証明書を使用します。Oracle AVDFを使用すると、Database Firewall証明書を失効前にローテーションできます。

ノート:

高可用性のためにペアにされたものを含め、各Database Firewallインスタンスの証明書をローテーションします。
  1. My Oracle Supportにログインします。
  2. パッチ番号34378217を検索します。
  3. p34378217_191000_Linux-x86-64.zipをダウンロードします。
  4. zipファイルの内容を抽出します。
  5. 抽出した場所からDatabase Firewallサーバーの/tmpディレクトリにgensslcert.dbfw.tar.gzをコピーします。
  6. 次のステップを実行して、Database Firewallサーバーへのインストールを完了します。

    1. supportユーザーとしてSSHを通じてDatabase Firewallアプライアンスに接続します。

    2. rootユーザーに切り替えます。 

      su - root

    3. 新規ディレクトリを作成:

      mkdir /root/gensslcert

    4. 新しいディレクトリにgensslcert.dbfw.tar.gzをコピーします。 

      cp /tmp/gensslcert.dbfw.tar.gz /root/gensslcert

    5. 新しいディレクトリに変更します。

      cd /root/gensslcert

    6. 次のコマンドを実行します。

      tar xvfz gensslcert.dbfw.tar.gz
  7. Database Firewallアプライアンスで、新しい認証局(CA)証明書を生成します。最初に、次のいずれかのコマンドを実行して、Database FirewallアプライアンスでローカルCA証明書を再生成します。
    dbfw(root)$ /root/gensslcert/gensslcert destroy-certs create-ca
  8. 次のコマンドを実行して、Database Firewallサービスを再起動します。 
    dbfw(root) $ systemctl reload httpd
    dbfw(root) $ systemctl restart stund
  9. Audit Vault ServerのDatabase Firewall証明書を更新して、Database Firewallの制御を取り戻します。「Database Firewallからの更新済証明書のフェッチ」を参照してください。
  10. 次のローカル証明書が有効であることを検証します。
    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt

    証明書の有効性は、config-diagnostics、sappdiagまたはopenssl x509コマンドを使用して検証します。 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  11. 次のピア証明書が有効であることを検証します。
    • /usr/local/dbfw/etc/controller.crt
    • /usr/local/dbfw/etc/controller_second.crt
    • /usr/local/dbfw/etc/fw_ca.crt
  1. Database Firewallアプライアンスで、新しい認証局(CA)証明書を生成します。最初に、次のいずれかのコマンドを実行して、Database FirewallアプライアンスでローカルCA証明書を再生成します。
    dbfw(root)$ /usr/local/bin/gensslcert destroy-certs create-ca
  2. 次のコマンドを実行して、Database Firewallサービスを再起動します。 
    dbfw(root) $ systemctl reload httpd
    dbfw(root) $ systemctl restart stund
  3. Audit Vault ServerのDatabase Firewall証明書を更新して、Database Firewallの制御を取り戻します。「Database Firewallからの更新済証明書のフェッチ」を参照してください。
  4. 次のローカル証明書が有効であることを検証します。
    • /usr/local/dbfw/etc/ca.crt
    • /etc/pki/tls/certs/localhost_internal.crt
    • /usr/local/dbfw/etc/cert.crt

    証明書の有効性は、config-diagnostics、sappdiagまたはopenssl x509コマンドを使用して検証します。 

    /usr/local/dbfw/bin/sappdiag
    openssl x509 -enddate -startdate -noout -in /usr/local/dbfw/etc/ca.crt
  5. 次のピア証明書が有効であることを検証します。
    • /usr/local/dbfw/etc/controller.crt
    • /usr/local/dbfw/etc/controller_second.crt
    • /usr/local/dbfw/etc/fw_ca.crt

3.7.6 Database FirewallのTLSプロキシ証明書の作成

Database FirewallのTLSプロキシ証明書を作成およびアップロードする方法について説明します。

Oracle Audit Vault and Database Firewall (Oracle AVDF)リリース20.8 (以降)では、Database FirewallのTLSプロキシ証明書のAudit Vault Serverコンソールからの管理がサポートされています。

Database Firewallでは、インバウンド(データベース・クライアントからDatabase Firewall)とアウトバウンド(Database Firewallからターゲット・データベース)のTLS接続に証明書を使用します。Audit Vault Serverコンソールから、インバウンドとアウトバウンドの両方のTLS接続の証明書を作成および管理できます。

ノート:

  • この機能は、Oracle AVDFでサポートされるOracle Databaseバージョンで使用できます。これは、Oracle AVDFリリース20.7のOracle Real Application Clusters (Oracle RAC)インスタンスには適用されません。Oracle AVDFリリース20.8以降でサポートされます。
  • この機能は、モニタリング/ブロック(プロキシ)モードでデプロイされたDatabase Firewallインスタンスにのみ適用されます。
  • TLSプロキシとしてDatabase Firewallを使用する場合は、データベースによるパスワードベースのユーザー許可がサポートされています。データベースによる証明書ベースの許可とサードパーティのユーザー許可(RADIUS、Kerberos、LDAPなど)はサポートされていません。

サポートされている証明書の署名方法のタイプは次のとおりです。

  • Database Firewall認証局(CA)によって署名されている証明書

    インバウンドとアウトバウンドのTLS接続には、Database Firewall CAによって署名されている即時利用可能な証明書を使用できます。本番デプロイメントには、サード・パーティの外部署名証明書を使用するようにしてください。

    このオプションは、ターゲット・データベースのモニタリング・ポイントを構成するときに選択できます。

  • 外部CAによって署名されている証明書

    外部CAによって署名された証明書を使用するには、関連情報を添えた証明書署名リクエスト(CSR)を作成し、それをダウンロードし、証明書の署名を取得し、Audit Vault Serverコンソールを使用してアップロードします。

    証明書をアップロードしておくと、その証明書はターゲット・データベースのモニタリング・ポイントを構成する際に使用できます。

次のステップを実行して、CSRを生成し、CSRをダウンロードして、正式に署名された証明書をDatabase Firewallにアップロードします。

  1. Audit Vault Serverコンソールにスーパー管理者としてログインします。
  2. 「設定」タブをクリックします。
  3. 左側のナビゲーション・メニューの「セキュリティ」タブをクリックします。
    スーパー管理者のみが、「セキュリティ」タブのメイン・ページにあるサブタブと設定を表示できます。
  4. メイン・ページで、「証明書」サブタブをクリックします。
  5. 「データベース・ファイアウォール」サブタブをクリックします。
  6. 「CSRの生成」ボタンをクリックします。

    「証明書署名リクエスト(CSR)の生成」ダイアログ・ボックスが表示されます。

  7. ドロップダウン・リストから特定のDatabase Firewallインスタンスを選択します。
  8. 共通名を入力します。
  9. 証明の組織名を入力します。
  10. 国または地域を選択します。
  11. (オプション)次のフィールドを指定します。
    • 組織単位
    • 都道府県
    • 市区町村
    • 電子メール
  12. 「作成」をクリックして、CSRを送信します。
  13. 「CSRのダウンロード」をクリックして、証明書をローカル・マシンに保存します。
  14. CAによって正式に署名された証明書を取得します。
  15. CAが証明書を承認したら、「証明書のアップロード」をクリックします。

    「証明書のアップロード」ダイアログ・ボックスが表示されます。

  16. ローカル・マシンからファイルを選択します。
  17. 「アップロード」をクリックします。
  18. ターゲット・データベースのモニタリング・ポイントを構成するときに、新しくアップロードした証明書を使用します。
    詳細な手順は、「Database Firewallモニタリング・ポイントの変更」を参照してください。
3.7.6.1 証明書の詳細の表示

Audit Vault Serverコンソールでは、各TLSプロキシ証明書の詳細(ステータス、開始日と終了日、有効期限、共通名など)を表示できます。

  1. Audit Vault Serverコンソールにスーパー管理者としてログインします。
  2. 「設定」タブをクリックします。
  3. 左側のナビゲーション・メニューの「セキュリティ」タブをクリックします。
  4. メイン・ページで、「証明書」サブタブをクリックします。
  5. 「データベース・ファイアウォール」サブタブをクリックします。
3.7.6.2 証明書のローテーション

Database FirewallのTLSプロキシ証明書もローテーションできます。

Database Firewall CA署名証明書の場合は、ローテーションによって新しい証明書が作成され、その証明書が同じモニタリング・ポイントに割り当てられます。
外部署名CA証明書の場合は、以前に構成した値を使用した新しいCSRがローテーションによって作成されます。証明書をダウンロードし、前と同じ手順で証明書の作成、署名の取得およびアップロードを実行する必要があります。