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の構成」を参照してください。
- データベース・アカウント
AGENTUSR#
およびAVSRCUSR#
は、Oracle AVDF 20.9より前のAVS_NONINTERACTIVE
プロファイル、およびOracle AVDF 20.9以降のAVS_AGENT_NONINTERACTIVE
プロファイルに属しています。これらのアカウントは、新しいエージェントまたはターゲットが追加されるたびに作成されます。これらのアカウントのパスワードは内部で生成され、Oracle AVDF 20.9以降では、そのパスワードは定期的なローテーションも行われます。AGENTUSR#
およびAVSRCUSR#
アカウントに関する変更(パスワード存続期間、ログイン試行の失敗回数またはパスワードの変更など)は実行しないでください。詳細は、「AGENTUSR#アカウントとAVSRCUSR#アカウントのパスワードの更新」を参照してください。 - データベース・アカウント
AVREPORTUSER
は、AVS_NONINTERACTIVE
プロファイルに属しています。AVREPORTUSER
アカウントに関する変更(パスワード存続期間、ログイン試行の失敗回数など)は実行しないでください。
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を構成します。
関連項目:
-
共有サーバーの管理の詳細は、『Oracle Database管理者ガイド』を参照してください
-
DISPATCHERS
パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください
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コンソールおよびエンド・ユーザー・ブラウザ
ノート:
-
「ホスト・モニター・エージェントの要件」に準拠します。
-
エージェントで
Java 1.6
が使用されている場合は、Java
バージョンを1.8
にアップグレードしてください。
Oracle AVDFアプライアンスで使用される接続暗号化強度
TLSレベル | TLSのバージョン | 説明 |
---|---|---|
レベル4 (新規インストール時のデフォルト) |
|
このレベルは最も強力であり、Oracle Audit Vault and Database Firewall内のすべてのコンポーネント間の通信に対してTLSをバージョン1.2に制限します。 ノート: サポートされているサービスが明示的に低いレベルのTLSを必要としていないかぎり、すべてのサービスにレベル4を使用することをお薦めします。 |
レベル3 |
|
このレベルでは、Level-4で実行されるすべての処理がサポートされます。 Oracle AVDFリリース20.1から20.3の場合:
Oracle AVDF 20.4以降、レベル3はAudit Vault AgentとAudit Vault Server間の通信にTLS 1.2を使用します。ホスト監視エージェントとDatabase Firewall間の通信も同様です。 |
レベル2 |
|
このレベルでは、レガシーの暗号化および非推奨の暗号化に対するサポートが追加されます。 ノート:
|
レベル1 (カスタム) |
|
これは、デフォルトではレベル4の強度で構成された、カスタマイズ可能な暗号セットです。 |
TLSレベルおよびその他のタスクを変更する方法
行番号 | タスク | コマンド | 詳細情報 |
---|---|---|---|
1 |
Audit Vault ServerおよびDatabase Firewallの既存のTLSレベルを確認する |
|
supportユーザーとしてログインし、このコマンドを実行します。Audit Vault ServerとDatabase Firewallの実際の構成を確認するには、このコマンドを使用します。 |
2 |
TLSレベルを設定し、オプションをさらに見つける |
|
rootユーザーとしてログインし、このコマンドを実行します。新規インストール時には、デフォルトではTLSレベルはレベル4に設定されます。 アップグレード時には、デフォルトではレベル2に設定されます。これは、ほとんどの状況に適しています。 設定されたレベルは変更可能です。使用可能なオプションを見つけるには、このコマンドを使用します。 |
3 |
Audit Vault ServerコンソールのTLSレベルを設定します。 |
|
rootユーザーとしてログインし、このコマンドを実行します。このコマンドは、AVS GUIへのWebブラウザ接続のTLSレベルを設定します。このレベルは |
4 |
Audit Vault ServerとDatabase Firewallとの通信のTLSレベルを設定する |
|
rootユーザーとしてログインし、このコマンドを実行します。このコマンドは、目的のTLSレベルを設定し、内部サービスを再起動します。このレベルは |
5 |
Audit Vault AgentとAudit Vault Serverとの通信、およびホスト・モニター・エージェントとDatabase Firewallとの通信のTLSレベルを設定します。 |
|
rootユーザーとしてログインし、このコマンドを実行します。このコマンドは、Audit Vault AgentとAudit Vault Serverとの通信、およびホスト・モニター・エージェントとDatabase Firewallとの通信のためのTLSレベルを設定します。このレベルは ノート:
1. Audit Vault Serverコンソールにrootユーザーとしてログインします。 2. 次のコマンドを使用してディレクトリを変更します。
3. 次のコマンドを使用してスクリプトを実行します。
このコマンドは、1時間以内に複数回実行できません。 |
6 |
カスタマイズした暗号セットを適用する |
Audit Vault Serverコンソールの場合:
Audit Vault Agentまたはホスト監視エージェントの場合:
アプライアンス間通信の場合:
|
新規インストール時には、デフォルトでは製品はレベル4に設定されます。アップグレード時には、レベル2に設定されます。これは、ほとんどの状況に適しています。これはカスタマイズできます。アップグレード・プロセス中に、暗号レベルが最大のセキュリティに設定されていないことを示すプロンプトと警告メッセージが表示されます。暗号レベルがアップグレード中に自動的に変更されることはありません。 作成したファイルからカスタム定義レベルを適用するには、このコマンドを使用します。これらのコマンドは、Webブラウザ接続のTLSレベルを設定し、内部サービスおよびAudit Vault Serverを再起動します。 ノート: カスタマイズされた暗号セットを適用するコマンドを実行した後、 rootユーザーとしてログインし、コマンドを実行してカスタム・レベルの構成ファイルを編集します。カスタマイズ可能な暗号スイート・セットは、このファイルで定義されます。新規インストール時には、デフォルトでは製品はレベル4に設定されます。このファイルを、暗号スイートをさらに制限して、製品で使用可能な暗号を含むように変更できます。 |
7 |
使用可能な暗号スイートをすべて示すリストを表示する |
|
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レベルを定義するカスタム・ファイルを作成してから、そのファイルを適用します。
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は、各種コンポーネントおよびサービスとの内部通信に証明書を使用します。こうした証明書は、次の表に示すとおりに特定の期間有効です。
表3-1 Audit Vault Agent証明書の有効期間
Audit Vault Serverリリース | Audit Vault Agent証明書の有効期間 |
---|---|
Oracle AVDF 12.2 | 10年 |
Oracle AVDF 20.1以降 | 27か月 |
ヒント:
Oracle AVDF 20.9以降では、Audit Vault Agentの証明書がまもなく期限切れになるというシステム・アラートを受信した場合は、「ステップ4: Audit Vault Agent証明書のローテーション」までスキップできます。3.7.2.1 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.2.2 ステップ1: Audit Vault Agent証明書の検証用パッチのダウンロード (Oracle AVDF 20.1から20.9)
このパッチをダウンロードして、Audit Vault Agent証明書の有効性を確認し、有効期限を調べます。
- My Oracle Supportにログインします。
- パッチ番号34412167を検索します。
- ダウンロード
- Oracle AVDF 20.1-20.7の場合:
p34412167_201000_Linux-x86-64.zip
- Oracle AVDF 20.8-20.9の場合:
p34412167_208000_Linux-x86-64.zip
- Oracle AVDF 20.1-20.7の場合:
- zipファイルの内容を抽出します。
- 抽出した場所からAudit Vault Serverの
/tmp
ディレクトリにshow-agent-certificate.py
をコピーします。
3.7.2.3 ステップ2: Audit Vault Agent証明書の有効性の確認(Oracle AVDF 20.1から20.9)
Audit Vault Agent証明書の有効性を確認し、有効期限を調べます。
3.7.2.4 ステップ3: Audit Vault Agentへのパッチ適用による証明書ローテーションの有効化(Oracle AVDF 20.1から20.6のみ)
ステップ2の結果が、エージェントの証明書がすでに期限切れになっていることや、今後3か月以内に期限切れになることを示している場合は、エージェントの証明書をローテーションする必要があります。Oracle AVDFリリース20.1から20.6の場合は、最初にAudit Vault Agentにパッチを適用することで、証明書のローテーションを有効にする必要があります。
ノート:
高可用性環境では、このパッチをプライマリとスタンバイの両方のAudit Vault Serverに適用します。
3.7.2.5 ステップ4: Audit Vault Agent証明書のローテーション
ステップ2の結果が、エージェントの証明書がすでに期限切れになっていることや、今後30日以内に期限切れになることを示している場合は、エージェントの証明書をローテーションする必要があります。
証明書が期限切れになった場合、Oracle AVDF 20.10では、このステップによって手動で証明書をローテーションする必要があります。
証明書のローテーションを実行する前に、AVDFシステム、Audit Vault Server、Audit Vault AgentおよびDatabase Firewallのすべてのコンポーネントが稼働していることを確認します。コンポーネントが停止している間に証明書がローテーションされると、そのコンポーネントは次回起動時に機能しなくなります。
-
super administrator
としてAudit Vault Serverコンソールにログインします。 - 「設定」タブをクリックします。
- 「セキュリティ」セクションで、「証明書」タブをクリックします。
- 「証明書のローテーション」タブをクリックします。
- 「CA証明書のローテーション」をクリックしてすべての認証局(CA)およびサービス証明書をローテーションするか、「サービス証明書のローテーション」をクリックして次のサービス証明書のみをローテーションします。
- プライマリAudit Vault Server。UI証明書を含む(それが外部で署名されていない場合)。
SSO証明書はローテーションされません(これは手動で実行する必要があるため)。詳細は、「Audit Vault ServerのSSO証明書のローテーション」を参照してください。
- セカンダリAudit Vault Server(高可用性環境で設定されている場合)
- 登録されている任意のAudit Vault Agent
- 登録されている任意のDatabase Firewall
ノート:
認証局がローテーションされた場合は、それにより、Database Firewall認証局によって署名された証明書が無効になります。そのため、TLSプロキシ証明書は、適切な認証局によって外部で署名されている必要があります。詳細は、「Database FirewallのTLSプロキシ証明書の作成」を参照してください。
- プライマリAudit Vault Server。UI証明書を含む(それが外部で署名されていない場合)。
- 「OK」をクリックして証明書のローテーションを確定します。
証明書のローテーション中は、UIをしばらく使用できない場合があります。
ノート:
高可用性環境では、プライマリAudit Vault Serverにのみ次のステップを実行します。
-
SSHを使用してAudit Vault Serverにログインし、
root
ユーザーに切り替えます。「SSHを使用したOracle AVDFアプライアンスへのログイン」を参照してください。
- ディレクトリを変更します:
cd /opt/avdf/lib/ruby/avdf
- 次のコマンドを実行して、Audit Vault Agent証明書をローテーションします。
ruby update_agent_cert_task.rb
- すでに証明書が期限切れになっていて、エージェントレス収集を使用している場合:
-
SSHを使用して宛先Audit Vault Serverにログインし、
root
ユーザーに切り替えます。「SSHを使用したOracle AVDFアプライアンスへのログイン」を参照してください。
- 次のコマンドを実行して、エージェントレス収集サービスを再デプロイします
/usr/local/dbfw/bin/deploy_default_agent.py
-
ノート:
高可用性環境では、プライマリAudit Vault Serverにのみ次のステップを実行します。
- rootユーザーとしてSSHを通じてAudit Vault Serverに接続します。
- ディレクトリを変更します:
cd /opt/avdf/lib/ruby/avdf
- 次のコマンドを実行して、Audit Vault Agent証明書をローテーションします。
ruby update_agent_cert_task.rb
- 証明書がすでに期限切れの場合:
-
administrator
としてAudit Vault Serverコンソールにログインします。 - 「エージェント」タブをクリックします。
- 停止しているすべてのエージェントのチェック・ボックスを選択して、「非アクティブ化」をクリックします。
- 非アクティブ化されたすべてのエージェントのチェック・ボックスを選択して、「アクティブ化」をクリックします。
- すべてのエージェントのエージェント・アクティブ化キーをコピーするか、メモします。
- 左側のナビゲーション・メニューで「ダウンロード」をクリックします。
agent.jar
をダウンロードします- すべてのエージェント・マシンに
agent.jar
ファイルを転送します。 - 次のコマンドを実行して、すべてのAudit Vault Agentを起動します:
-
agentctl start -k
- エージェント・アクティブ化キーを次の形式で貼り付けるか、入力します。
<Agent Name>::XXXX-XXXX-XXXX-XXXX-XXXX
入力してもアクティブ化キーは表示されません。
-
Oracle AVDF 20.9でエージェントレス収集を使用しているときに、すでに証明書が失効している場合は、次のステップを実行します
-
SSHを使用して宛先Audit Vault Serverにログインし、
root
ユーザーに切り替えます。「SSHを使用したOracle AVDFアプライアンスへのログイン」を参照してください。
- 次のコマンドを実行して、エージェントレス収集サービスを再デプロイします
/usr/local/dbfw/bin/deploy_default_agent.py
-
- 証明書がまだ期限切れになっていない場合:
- ローテーション後に、Audit Vault Agent証明書を検証します。「ステップ2: Audit Vault Agent証明書の有効性の確認(Oracle AVDF 20.1から20.9)」を参照してください。
Audit Vault Agentによる新しい証明書の更新には、最長で12時間かかります。この時間は、Audit Vault Serverに登録されているエージェントの数に応じて異なります。
- 12時間後に、Audit Vault AgentがRUNNING状態になっていることを確認します。STOPPED状態になっている場合は、Oracle Supportに連絡してください。
- ローテーション後に、Audit Vault Agent証明書を検証します。「ステップ2: Audit Vault Agent証明書の有効性の確認(Oracle AVDF 20.1から20.9)」を参照してください。
- パッチ34412167を適用する前にAudit Vault Agentの自動起動機能を無効にした場合は、それを再度有効にします。詳細は、「Windowsホスト上のエージェントの自動起動」を参照してください。
3.7.3 Audit Vault Server証明書のローテーション
Audit Vault Server証明書のローテーション方法について説明します。
Audit Vault Serverは、各種コンポーネントおよびサービスとの内部通信に証明書を使用します。Oracle AVDFを使用すると、Audit Vault Server証明書を失効前にローテーションできます。
証明書が期限切れになった場合、Oracle AVDF 20.10では、このステップによって手動で証明書をローテーションする必要があります。
証明書のローテーションを実行する前に、AVDFシステム、Audit Vault Server、Audit Vault AgentおよびDatabase Firewallのすべてのコンポーネントが稼働していることを確認します。コンポーネントが停止している間に証明書がローテーションされると、そのコンポーネントは次回起動時に機能しなくなります。
-
super administrator
としてAudit Vault Serverコンソールにログインします。 - 「設定」タブをクリックします。
- 「セキュリティ」セクションで、「証明書」タブをクリックします。
- 「証明書のローテーション」タブをクリックします。
- 「CA証明書のローテーション」をクリックしてすべての認証局(CA)およびサービス証明書をローテーションするか、「サービス証明書のローテーション」をクリックして次のサービス証明書のみをローテーションします。
- プライマリAudit Vault Server。UI証明書を含む(それが外部で署名されていない場合)。
SSO証明書はローテーションされません(これは手動で実行する必要があるため)。詳細は、「Audit Vault ServerのSSO証明書のローテーション」を参照してください。
- セカンダリAudit Vault Server(高可用性環境で設定されている場合)
- 登録されている任意のAudit Vault Agent
- 登録されている任意のDatabase Firewall
ノート:
認証局がローテーションされた場合は、それにより、Database Firewall認証局によって署名された証明書が無効になります。そのため、TLSプロキシ証明書は、適切な認証局によって外部で署名されている必要があります。詳細は、「Database FirewallのTLSプロキシ証明書の作成」を参照してください。
- プライマリAudit Vault Server。UI証明書を含む(それが外部で署名されていない場合)。
- 「OK」をクリックして証明書のローテーションを確定します。
証明書のローテーション中は、UIをしばらく使用できない場合があります。
root
ユーザーとして次のコマンドを実行して、Audit Vault Serverで新しい認証局(CA)証明書を生成します。このプロセスでは、Audit Vault Serverの一元的な自己署名CA証明書を更新します。/usr/local/bin/gensslcert destroy-certs create-ca
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- CA証明書バンドルとサービスを更新および再生成します。
-
プライマリ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
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
-
- プライマリ・サーバーで、
root
ユーザーとして次のコマンドを実行します:systemctl start monitor
- 新しい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
- 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=-
- Database Firewallアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart stund
- ローカル証明書およびピア証明書が有効であることを検証します。
次のローカル証明書を検証します。
/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
root
ユーザーとして次のコマンドを実行して、プライマリAudit Vault Serverで新しい認証局(CA)証明書を生成します。このプロセスでは、Audit Vault Serverの一元的な自己署名CA証明書を更新します。/usr/local/bin/gensslcert destroy-certs create-ca
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- プライマリ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
- スタンバイAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- CA証明書とすべての証明書をスタンバイAudit Vault Serverインスタンスで再生成します。
スタンバイ・サーバーで、次のコマンドを
root
ユーザーとして実行します:/usr/local/bin/gensslcert destroy-certs create-ca
- スタンバイAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- プライマリ・インスタンスにスタンバイ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
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- CA証明書バンドルとサービスを更新および再生成します。プライマリおよびスタンバイのAudit Vault Serverインスタンスで、次のステップを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
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
-
スタンバイ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
- スタンバイAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
-
- プライマリAudit Vault Serverアプライアンスで、オブザーバを再起動します。
プライマリ・サーバーで、次のコマンドを
root
ユーザーとして実行します:systemctl stop monitor
oracle
ユーザーに切り替えます。su - oracle
プライマリ・サーバーで、次のコマンドをoracle
ユーザーとして実行します:/usr/local/dbfw/bin/observerctl --stop
/usr/local/dbfw/bin/observerctl --start
- オブザーバ・プロセスが稼働するまで2分間待機します。
オブザーバ・ステータスを確認するには:
-
support
ユーザーとしてSSHを使用してAudit Vault Serverにログインします。ノート:
Oracle Cloud Infrastructure (OCI)マーケットプレイス・イメージを使用している場合は、OPC
ユーザーとしてSSHを介して接続します。ssh support@<audit_vault_server_ip_address>
-
root
ユーザーに切り替えます。su - root
ノート:
OCIマーケットプレイス・イメージを使用している場合は、sudo su -
コマンドを使用します。 -
oracle
ユーザーに切り替えます。su - oracle
-
次のコマンドを実行します。
/usr/local/dbfw/bin/setup_ha.rb –status
これにより、Data Guardオブザーバ・ステータスを含むすべてのステータスが表示されます。オブザーバが稼働しているときには、Data Guard Observer = yesと表示されます。
-
- プライマリ・サーバーで、
root
ユーザーとして次のコマンドを実行します:systemctl start monitor
- 新しい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
- 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=-
- Database Firewallアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart stund
- ローカル証明書およびピア証明書が有効であることを検証します。
次のローカル証明書を検証します。
/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
- My Oracle Supportにログインします。
- パッチ番号34378212を検索します。
p34378212_191000_Linux-x86-64.zip
をダウンロードします。- zipファイルの内容を抽出します。
- 抽出した場所からAudit Vault Serverの
/tmp
ディレクトリにgensslcert.avs.tar.gz
をコピーします。 - Audit Vault Serverへのインストールを完了します。
-
support
ユーザーとしてSSHを使用してAudit Vault Serverにログインします。ノート:
Oracle Cloud Infrastructure (OCI)マーケットプレイス・イメージを使用している場合は、OPC
ユーザーとしてSSHを介して接続します。ssh support@<audit_vault_server_ip_address>
-
root
ユーザーに切り替えます。su - root
ノート:
OCIマーケットプレイス・イメージを使用している場合は、sudo su -
コマンドを使用します。 -
新規ディレクトリを作成:
mkdir /root/gensslcert
-
新しいディレクトリに
gensslcert.avs.tar.gz
をコピーします。cp /tmp/gensslcert.avs.tar.gz /root/gensslcert
-
新しいディレクトリに変更します。
cd /root/gensslcert
-
ファイルを抽出します。
tar xvfz gensslcert.avs.tar.gz
-
- 次のコマンドを
root
ユーザーとして実行して、Audit Vault Serverで新しい認証局(CA)証明書を生成します。このプロセスでは、Audit Vault Serverの一元的な自己署名CA証明書を更新します。/root/gensslcert/gensslcert destroy-certs create-ca
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- CA証明書バンドルとサービスを更新および再生成します。
-
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
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
-
- プライマリ・サーバーで、
root
ユーザーとして次のコマンドを実行します:systemctl start monitor
- 新しい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
- 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=-
- Database Firewallアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart stund
- ローカル証明書およびピア証明書が有効であることを検証します。
次のローカル証明書を検証します。
/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
- My Oracle Supportにログインします。
- パッチ番号34378212を検索します。
p34378212_191000_Linux-x86-64.zip
をダウンロードします。- zipファイルの内容を抽出します。
- 抽出した場所からAudit Vault Serverの
/tmp
ディレクトリにgensslcert.avs.tar.gz
をコピーします。 - Audit Vault Serverへのインストールを完了します。
-
support
ユーザーとしてSSHを使用してAudit Vault Serverにログインします。ノート:
Oracle Cloud Infrastructure (OCI)マーケットプレイス・イメージを使用している場合は、OPC
ユーザーとしてSSHを介して接続します。ssh support@<audit_vault_server_ip_address>
-
root
ユーザーに切り替えます。su - root
ノート:
OCIマーケットプレイス・イメージを使用している場合は、sudo su -
コマンドを使用します。 -
新規ディレクトリを作成:
mkdir /root/gensslcert
-
新しいディレクトリに
gensslcert.avs.tar.gz
をコピーします。cp /tmp/gensslcert.avs.tar.gz /root/gensslcert
-
新しいディレクトリに変更します。
cd /root/gensslcert
-
ファイルを抽出します。
tar xvfz gensslcert.avs.tar.gz
-
- 次のコマンドを
root
ユーザーとして実行して、プライマリAudit Vault Serverで新しい認証局(CA)証明書を生成します。このプロセスでは、Audit Vault Serverの一元的な自己署名CA証明書を更新します。/root/gensslcert/gensslcert destroy-certs create-ca
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- プライマリ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
- スタンバイAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- 次のコマンドを
root
ユーザーとして実行して、スタンバイAudit Vault ServerインスタンスでCA証明書とすべての証明書を再生成します。/root/gensslcert/gensslcert destroy-certs create-ca
- スタンバイAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- プライマリ・インスタンスにスタンバイ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
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
- CA証明書バンドルとサービスを更新および再生成します。プライマリおよびスタンバイのAudit Vault Serverインスタンスで、次のステップを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
- プライマリAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
-
スタンバイ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
- スタンバイAudit Vault Serverアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart controller
-
- プライマリAudit Vault Serverアプライアンスで、オブザーバを再起動します。
プライマリ・サーバーで、次のコマンドを
root
ユーザーとして実行します:systemctl stop monitor
oracle
ユーザーに切り替えます。su - oracle
プライマリ・サーバーで、次のコマンドをoracle
ユーザーとして実行します:/usr/local/dbfw/bin/observerctl --stop
/usr/local/dbfw/bin/observerctl --start
- オブザーバ・プロセスが稼働するまで2分間待機します。
オブザーバ・ステータスを確認するには:
-
support
ユーザーとしてSSHを使用してAudit Vault Serverにログインします。ノート:
Oracle Cloud Infrastructure (OCI)マーケットプレイス・イメージを使用している場合は、OPC
ユーザーとしてSSHを介して接続します。ssh support@<audit_vault_server_ip_address>
-
root
ユーザーに切り替えます。su - root
ノート:
OCIマーケットプレイス・イメージを使用している場合は、sudo su -
コマンドを使用します。 -
oracle
ユーザーに切り替えます。su - oracle
-
次のコマンドを実行します。
/usr/local/dbfw/bin/setup_ha.rb –status
これにより、Data Guardオブザーバ・ステータスを含むすべてのステータスが表示されます。オブザーバが稼働しているときには、Data Guard Observer = yesと表示されます。
-
- プライマリ・サーバーで、
root
ユーザーとして次のコマンドを実行します:systemctl start monitor
- 新しい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
- 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=-
- Database Firewallアプライアンスを再起動します。
root
ユーザーとして、次のコマンドを実行します:systemctl reload httpd
systemctl restart stund
- ローカル証明書およびピア証明書が有効であることを検証します。
次のローカル証明書を検証します。
/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.4 Database Firewall証明書のローテーション
Database Firewall証明書のローテーション方法について説明します。
Database Firewallは、各種コンポーネントおよびサービスとの内部通信に証明書を使用します。Oracle AVDFを使用すると、Database Firewall証明書を失効前にローテーションできます。
ノート:
高可用性のためにペアにされたものを含め、各Database Firewallインスタンスの証明書をローテーションします。証明書が期限切れになった場合、Oracle AVDF 20.10では、このステップによって手動で証明書をローテーションする必要があります。
証明書のローテーションを実行する前に、AVDFシステム、Audit Vault Server、Audit Vault AgentおよびDatabase Firewallのすべてのコンポーネントが稼働していることを確認します。コンポーネントが停止している間に証明書がローテーションされると、そのコンポーネントは次回起動時に機能しなくなります。
-
super administrator
としてAudit Vault Serverコンソールにログインします。 - 「設定」タブをクリックします。
- 「セキュリティ」セクションで、「証明書」タブをクリックします。
- 「証明書のローテーション」タブをクリックします。
- 「CA証明書のローテーション」をクリックしてすべての認証局(CA)およびサービス証明書をローテーションするか、「サービス証明書のローテーション」をクリックして次のサービス証明書のみをローテーションします。
- プライマリAudit Vault Server。UI証明書を含む(それが外部で署名されていない場合)。
SSO証明書はローテーションされません(これは手動で実行する必要があるため)。詳細は、「Audit Vault ServerのSSO証明書のローテーション」を参照してください。
- セカンダリAudit Vault Server(高可用性環境で設定されている場合)
- 登録されている任意のAudit Vault Agent
- 登録されている任意のDatabase Firewall
ノート:
認証局がローテーションされた場合は、それにより、Database Firewall認証局によって署名された証明書が無効になります。そのため、TLSプロキシ証明書は、適切な認証局によって外部で署名されている必要があります。詳細は、「Database FirewallのTLSプロキシ証明書の作成」を参照してください。
- プライマリAudit Vault Server。UI証明書を含む(それが外部で署名されていない場合)。
- 「OK」をクリックして証明書のローテーションを確定します。
証明書のローテーション中は、UIをしばらく使用できない場合があります。
- Database Firewallアプライアンスで、新しい認証局(CA)証明書を生成します。最初に、次のいずれかのコマンドを実行して、Database FirewallアプライアンスでローカルCA証明書を再生成します。
dbfw(root)$ /usr/local/bin/gensslcert destroy-certs create-ca
- 次のコマンドを実行して、Database Firewallサービスを再起動します。
dbfw(root) $ systemctl reload httpd
dbfw(root) $ systemctl restart stund
- Audit Vault ServerのDatabase Firewall証明書を更新して、Database Firewallの制御を取り戻します。「Database Firewallからの更新済証明書のフェッチ」を参照してください。
- 次のローカル証明書が有効であることを検証します。
/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
- 次のピア証明書が有効であることを検証します。
/usr/local/dbfw/etc/controller.crt
/usr/local/dbfw/etc/controller_second.crt
/usr/local/dbfw/etc/fw_ca.crt
- My Oracle Supportにログインします。
- パッチ番号34378217を検索します。
p34378217_191000_Linux-x86-64.zip
をダウンロードします。- zipファイルの内容を抽出します。
- 抽出した場所からDatabase Firewallサーバーの
/tmp
ディレクトリにgensslcert.dbfw.tar.gz
をコピーします。 - 次のステップを実行して、Database Firewallサーバーへのインストールを完了します。
-
supportユーザーとしてSSHを通じてDatabase Firewallアプライアンスに接続します。
-
rootユーザーに切り替えます。
su - root
-
新規ディレクトリを作成:
mkdir /root/gensslcert
-
新しいディレクトリに
gensslcert.dbfw.tar.gz
をコピーします。cp /tmp/gensslcert.dbfw.tar.gz /root/gensslcert
-
新しいディレクトリに変更します。
cd /root/gensslcert
-
次のコマンドを実行します。
tar xvfz gensslcert.dbfw.tar.gz
-
- Database Firewallアプライアンスで、新しい認証局(CA)証明書を生成します。最初に、次のいずれかのコマンドを実行して、Database FirewallアプライアンスでローカルCA証明書を再生成します。
dbfw(root)$ /root/gensslcert/gensslcert destroy-certs create-ca
- 次のコマンドを実行して、Database Firewallサービスを再起動します。
dbfw(root) $ systemctl reload httpd
dbfw(root) $ systemctl restart stund
- Audit Vault ServerのDatabase Firewall証明書を更新して、Database Firewallの制御を取り戻します。「Database Firewallからの更新済証明書のフェッチ」を参照してください。
- 次のローカル証明書が有効であることを検証します。
/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
- 次のピア証明書が有効であることを検証します。
/usr/local/dbfw/etc/controller.crt
/usr/local/dbfw/etc/controller_second.crt
/usr/local/dbfw/etc/fw_ca.crt
3.7.5 Audit Vault ServerのSSO証明書のローテーション
Oracle AVDF 20.11以降では、Audit Vault Serverコンソールのユーザーに対してシングル・サインオン(SSO)を構成できます。SSOキーおよび証明書をローテーションする方法を説明します。
SSO証明書のローテーションは、手動で実行する必要があります。これは、Audit Vault Serverの「証明書のローテーション」タブで使用可能な機能ではローテーションされないためです。
-
SSHを使用してAudit Vault Serverにログインし、
root
ユーザーに切り替えます。「SSHを使用したOracle AVDFアプライアンスへのログイン」を参照してください。
- 次のように、
/usr/local/dbfw/etc
ディレクトリに移動します。cd /usr/local/dbfw/etc
- バックアップ・ディレクトリを作成し、現在のApex SAMLキーおよび証明書ファイルをそこに移動します。
mkdir apexsaml_backup mv apexsaml.key ./apexsaml_backup mv apexsaml.crt ./apexsaml_backup
- Apex SAMLキーおよび証明書を生成します。
/usr/local/dbfw/etc/privileged-migrations/gen_saml_apex_cert.sh
- それらをAudit Vault Serverに登録します。
/usr/local/dbfw/etc/privileged-migrations/register_apex_key_cert.py
- Audit Vault ServerコンソールにログインすることでそのSSO構成をテストします。
詳細は、SSOによるOracle AVDFアプライアンスへのログインを参照してください。
- SSO接続テストに合格した場合は、Apex SAMLキーおよび証明書のバックアップ・ディレクトリを削除します。
rm -r /usr/local/dbfw/etc/apexsmal_backup
- アイデンティティ・プロバイダでAudit Vault ServerのSSO証明書が必要な場合は、アイデンティティ・プロバイダ構成をその新しいSSO証明書で更新します。
- 高可用性で構成されている場合は、
/usr/local/dbfw/etc/apexsaml.key
および/usr/local/dbfw/etc/apexsaml.crt
をスタンバイAudit Vault Serverにコピーします。
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にアップロードします。