| Oracle® Audit Vault and Database Firewall管理者ガイド リリース12.2 E70392-19 |
|
 前 |
 次 |
ここでのトピック
Database FirewallのペアまたはAudit Vault Serverのペア、あるいはその両方を構成して、高可用性システム・アーキテクチャを提供できます。これらは、回復可能なペアと呼ばれます。Database Firewallの場合、この章で説明する回復可能なペアの構成は、データベース・アクティビティ監視(DAM)モードにのみ適用されます。
Audit Vault Serverの回復可能なペアでは、プライマリAudit Vault Serverがすべてのサーバー機能を実行します。監査および構成データは、プライマリAudit Vault ServerからセカンダリAudit Vault Serverにコピーされます。セカンダリAudit Vault ServerではAudit Vault Serverコンソールを使用できないため、セカンダリ・サーバーのコンソールにアクセスしようとすると、プライマリ・サーバーのAudit Vault Serverコンソールにリダイレクトされます。
Audit Vault Serverの高可用性ペアでは、フェイルオーバーが有効になっている場合は、フェイルオーバーの発生時にセカンダリ・サーバーがプライマリになります。
Database Firewallの回復可能なペアでは、プライマリとセカンダリの両方のDatabase Firewallが次の処理を実行します。
同じ期間のトラフィックの受信
同じ構成を持ち、Audit Vault Serverによって同期される。これは、セキュア・ターゲット、強制ポイント、ポリシーおよびその他の監視設定の構成です。Database Firewallコンソールのシステム・ページのIPアドレス、ネットワーク・マスク、プライマリおよびセカンダリDatabase FirewallインスタンスのDNSなどのシステム構成は除きます。これらの設定は同期されません。
適用されたポリシーに基づいたログ・ファイルの作成
Audit Vault Serverへのアラートの送信。その後、Audit Vault ServerはプライマリDatabase Firewallからアラートのみを送信します。
Audit Vault Serverは、Database Firewallのプライマリ・インスタンスとセカンダリ・インスタンスからトラフィック・ログを収集します。Audit Vault Serverは、回復可能なペアの状態を制御します。Database Firewallのプライマリ・インスタンスとセカンダリ・インスタンスの間では通信は行われません。Audit Vault ServerがプライマリDatabase Firewallと長時間通信できない場合、または特定のDatabase Firewallインスタンスを使用できないためにプライマリDatabase Firewallから収集されたトラフィック・ログに時間ギャップがある場合、Audit Vault ServerはセカンダリDatabase Firewallから収集されたトラフィック・ログ・ファイルを使用します。Audit Vault Serverは、指定された時間範囲のデータがAudit Vault Serverデータベースに保存された後に、Database Firewallの両方のインスタンスからトラフィック・ログ・ファイルを削除します。
図8-1に、高可用性モードのAudit Vault ServerのペアとDatabase Firewallのペアを示します。
図8-1 高可用性モードのAudit Vault ServerのペアとDatabase Firewallのペア
ノート:
高可用性のペアリングまたはペアリング解除は、1時間以内に1回のみ実行する必要があります。
関連項目:
DAMモードとDPE (データベース・ポリシー強制)モードの詳細は、『Oracle Audit Vault and Database Firewall概要ガイド』を参照してください。
次のトピックでは、Audit Vault Serverのペアリングの概要について説明します。
具体的には、次の各トピックでは、プライマリおよびセカンダリAudit Vault Serverの構成、Audit Vault Serverの高可用性ステータスのチェック、Audit Vault Serverをペアリングにした後のAudit Vault Agentの更新、プライマリおよびセカンダリAudit Vault Server間でのロールの入替え、およびAudit Vault Serverのペアのフェイルオーバーの処理について説明します。
2つのAudit Vault Serをペアにする場合、1つをプライマリとして指定し、もう1つをセカンダリ・サーバーとして指定すると、プライマリ・サーバーのすべてのデータおよび構成(ネットワーク設定を除く)が自動的にセカンダリ・サーバーにコピーされ、それ以降はセカンダリ・サーバーと同期されます。
Audit Vault Serverの回復可能なペアを構成した後、プライマリ・サーバーに対してのみすべての構成タスクを実行します。これには、Audit Vault Agentのデプロイ、セキュア・ターゲットおよびホストの設定、Database Firewallおよび強制ポイントの追加などのタスクがあります。
Database Firewallをデプロイし、Audit Vault Serverの回復可能なペアを構成する場合、プライマリとセカンダリの両方のAudit Vault Serverのサーバー証明書およびIPアドレスを各Database Firewallに指定する必要があります。
Audit Vault Serverのペアを作成する前にセカンダリ・サーバーのAudit Vault Agentをデプロイした場合は、ペアの作成が完了したら、以前にデプロイしたセカンダリ・サーバーのAudit Vault Agentを手動で更新する必要があります。
これは、Audit Vault Serverの高可用性ペアリングを実行する前にプライマリ・サーバーのAudit Vault Agentをデプロイした場合は不要です。
このトピックでは、Audit Vault Serverのペアを構成するための前提条件について説明します。
プライマリとセカンダリ両方のAudit Vault Serverが同じ仕様であることを確認します。仕様の内容は、次のとおりです。
Create New Filesystemを選択して、プライマリおよびセカンダリ監査Vaultサーバーに追加されるすべての場所に異なるファイルシステムが存在するようにします。これらの場所は、高可用性のペアリング中にマップされます。これらの場所のマッピングは、高可用性のペアリングが成功するとプライマリAudit Vault Serverのコンソールに表示されます。host:exportおよびdirectory:destinationのパスの組合せは、一意である必要があります。関連トピック
Server2を構成するには、セカンダリ・サーバーで次のようにします。
Server1 (プライマリ)からサーバー証明書をコピーします。
Server1に管理者としてログインします。
Server1の「設定」タブで、「セキュリティ」メニューから、「サーバー証明書」をクリックします。
証明書をコピーします。
別のブラウザ・ウィンドウで、Server2にスーパー管理者としてログインします。
Server2のコンソールで、「設定」タブをクリックします。
「システム」メニューから、「高可用性」を選択します。
「このサーバーの構成」フィールドで、「セカンダリ・サーバー」を選択します。
表示されるフィールドに「プライマリ・サーバーIPアドレス」を入力します。
「プライマリ・サーバー証明書」フィールドに、Server1からコピーした証明書を貼り付けます。
「保存」をクリックします。
検証後にプライマリ・サーバーのIPアドレスおよび証明書が保存されます。この時点でペアリングを開始する場合は、ページの上部にあるプライマリ・サーバーのURLをクリックします。
「リセット」ボタンが表示され、これにより、この手順で構成した設定を取り消してシステムを元の状態にリセットできます。
この手順では、プライマリ・サーバーをServer1、セカンダリ(スタンバイ)・サーバーをServer2と呼びます。
Server1を構成するには、プライマリ・サーバーで次のようにします。
Server2 (セカンダリ)からサーバー証明書をコピーします。
Server2に管理者としてログインします。
Server1の「設定」タブで、「セキュリティ」メニューから、「サーバー証明書」をクリックします。
証明書をコピーします。
別のブラウザ・ウィンドウで、Server1にスーパー管理者としてログインします。
Server1のコンソールで、「設定」タブをクリックします。
「システム」メニューから、「高可用性」を選択します。
「このサーバーの構成」フィールドで、「プライマリ・サーバー」を選択します。
「ペアリングの開始」ボタンが表示されます。
表示されるフィールドに「セカンダリ・サーバーIPアドレス」を入力します。
「セカンダリ・サーバー証明書」フィールドに、Server2からコピーした証明書を貼り付けます。
Server1とServer2のペアを起動する準備ができたら、次のステップに進みます。
プライマリ・サーバー(Server1)で高可用性ペアを起動します。これには数分かかりますが、完了すると、セカンダリ・サーバーではコンソールUIを使用できなくなります。
ノート:
ユーザーは、ILMのアーカイブ前に必ず高可用性ペアリングの手順を実行する必要があります。そうしないと、エラーが発生することがあります。
この手順を完了した後、プライマリ・サーバーでのみすべての構成タスクを実行します。これには、Audit Vault Agentのデプロイ、セキュア・ターゲットおよびホストの設定、Database Firewallおよび強制ポイントの追加などのタスクがあります。Server2 (スタンバイ)のコンソールUIは使用できなくなるため、Server1にリダイレクトされます。
「ペアリングの開始」をクリックします。
高可用性構成の進行状況を示すメッセージが表示されます。この処理には少なくとも10分かかり、その間はコンソールが使用できない可能性があります。
ブラウザを定期的にリフレッシュします。
構成が完了すると、「高可用性ステータス」が表示されます。
このトピックでは、Audit Vault Serverのペアリング後にAudit Vault Agentを更新する方法について説明します。
Audit Vault Serverの高可用性ペアでは、フェイルオーバーの発生時にセカンダリ・サーバーがプライマリになります。Audit Vault Serverの高可用性ペアリングを実行する前にセカンダリ・サーバーのAudit Vault Agentをデプロイした場合は、フェイルオーバーの発生後に、新しいプライマリ・サーバーのAgentのステータスがUNREACHABLEになります。このシナリオを回避するには、ペアの作成が完了したら、以前にデプロイしたセカンダリ・サーバーのAudit Vault Agentを手動で更新します。
これは、Audit Vault Serverの高可用性ペアリングを実行する前にプライマリ・サーバーのAudit Vault Agentをデプロイした場合は不要です。
ノート:
Audit Vault Agentおよびホスト監視エージェントは、Audit Vault Serverのペアリングまたはペアリング解除後に自動的に更新されます。これはリリース12.2.0.5.0以降に適用可能です。
Oracle Audit Vault and Database Firewallのバージョンが12.2.0.4.0を下回っている場合、この手順を使用してAudit Vault Agentまたはホスト監視エージェントを手動で更新します。
Audit Vault Serverのペア作成後にAudit Vault Agentを手動で更新するには:
ノート:
Windowsの場合は、Agent_Homeフォルダを完全に削除する前に、Agent_Homeフォルダから次のコマンドを実行します。
agentctl.bat unregistersvc
プライマリAudit Vault Serverが使用不可になると、10分遅延の後にセカンダリAudit Vault Serverに自動的にフェイルオーバーされます。遅延により、プライマリ・サーバーの再起動によるフェイルオーバーを防止します。
データベースが正常に停止した場合、フェイルオーバーは発生しません。プライマリAudit Vault Serverが停止され(電源オフなど)、10分以内に起動しない場合、フェイルオーバーが発生します。
プライマリAudit Vault Serverが手動で停止され、再インストールまたは別のサーバーに置き換えられた場合は、次の手順を実行する必要があります。
oracleユーザーとして次のコマンドを発行し、現在のスタンバイ・サーバーを手動でフェイルオーバーします。
/usr/local/dbfw/bin/setup_ha.rb --failover
その後、スーパー管理者ユーザーとしてAudit Vaultコンソールにログインして、2つのサーバーをアンペアできます。
「設定」を選択し、「高可用性」を選択します。
「高可用性ステータス」ページで、「アンペア」ボタンをクリックします。
2つのAudit Vault Server間で新しい証明書をコピーします。
「ペアリングの開始」ボタンをクリックして、再び高可用性設定を開始します。
フェイルオーバー発生時には、セカンダリ・サーバーがプライマリAudit Vault Serverになります。このプライマリ・サーバーを構成するには、次の手順を行ったうえで、高可用性のペアリングを繰り返す必要があります。
Audit Vault Serverコンソールにスーパー管理者としてログインします。
「設定」タブをクリックします。
「設定」を選択し、「高可用性」を選択します。
「高可用性ステータス」ページで、「アンペア」ボタンをクリックして、スタンドアロン・サーバーに変換する新しいプライマリ・サーバーをアンペアします。
スタンドアロン・サーバーで、ネットワーク設定およびサービス設定(DNS設定など)を構成します。
次のAVCLIコマンドを使用して、アーカイブ場所として定義されているリモート・ファイルシステム(NFS共有)をスタンドアロン・サーバーに手動でマウントします。
ALTER REMOTE FILESYSTEM filesystem_name MOUNT
障害が発生したサーバーの接続を解除してサーバーを置換します。これで、置換されたサーバーを新しいセカンダリ・サーバーとして構成できます。
2つのAudit Vault Serverをペアにするには、構成ステップを再び実行します。
次のトピックでは、Database Firewallの回復可能なペアの管理、構成、ロールの切替えおよび解除を行う方法について説明します。
ここで説明する手順は、DAMモードのDatabase Firewallにのみ適用されます。
前提条件
2つのDatabase Firewallを回復可能なペアとして指定する前に、それぞれに対して初期構成タスクを実行します。詳細は、「Database Firewallの構成」を参照してください。
ペアにするDatabase Firewallのいずれにも強制ポイントが構成されていないことを確認してください。回復可能なペアを作成する前に、両方のDatabase Firewallからすべての強制ポイントを削除してください。
Audit Vault Serverの回復可能なペアを構成する場合
Audit Vault Serverの回復可能なペアも構成した場合は、各Audit Vault ServerのIPアドレスおよび証明書をシステム内の各Database Firewallに指定する必要があります。
Database Firewallの回復可能なペアでプライマリとセカンダリのロールを入れ替える場合は、この手順に従います。
通常、Database Firewallインスタンスの回復可能なペアの高可用性構成は、監視のみモードで設定されます。Oracle Audit Vault and Database Firewallには、モニタリング/ブロック(プロキシ)モードでデプロイしたDatabase Firewallに高可用性構成を設定するオプションがあります。
プロキシ・モードでデプロイされた2つ以上の個別のDatabase Firewallインスタンスは、高可用性を実現するように構成できます。
このトピックには、プロキシ・モードの2つ以上の個別のDatabase Firewallインスタンスに高可用性を構成するために必要な情報が含まれています。これはクライアント構成に変更を加えることで実現できます。
Oracle SQL OCI (Oracle Call Interface)ベースのクライアントは、tnsnames.oraファイルを使用してデータベースに接続します。このファイル内のパラメータは、この構成の一部として変更する必要があります。
ノート:
この機能は、Oracle Audit Vault and Database Firewallリリース12.2.0.11.0以降で使用できます。前提条件
構成手順を実行する前に、必要な基本設定を完了します。
クライアントは、次のパラメータを使用して構成できます。
ADDRESS_LIST
CONNECT_TIMEOUT
LOAD_BALANCE
データベース・ターゲットに接続するためのDatabase Firewallの複数のIPアドレスをADDRESS_LISTに含めます。
ノート:
Audit Vault ServerまたはDatabase Firewall用に構成したポート番号は、内部で使用しないでください。次に例を示します。
dbfw1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.0.2.1)(PORT=1111))(ADDRESS=(PROTOCOL=TCP)(HOST=192.0.2.2)(PORT=2222)))(CONNECT_DATA=(SERVICE_NAME=dbfwdb)))
クライアント・アプリケーションを使用してデータベースに接続します。
たとえば、SQL*Plusクライアントを使用する場合は、次のコマンドを使用します。
sqlplus <username>/<password>@<net_service_name>
クライアントは、最初のDatabase Firewallインスタンスへの接続を試みます。最初のインスタンスが停止しているかアクセスできない場合、クライアントは2番目のインスタンスへの接続を試みます。これは、アクティブおよびパッシブのデプロイメントと同様に機能します。
ノート:
adminユーザーは、十分に注意してこのパラメータを設定する必要があります。ノードが停止しているかどうかを迅速に検出するには、CONNECT_TIMEOUTパラメータを使用します。また、フェイルオーバー時の接続時間も短縮されます。
次に例を示します。
dbfw1=(DESCRIPTION=(CONNECT_TIMEOUT=10)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.0.2.1)(PORT=1111))(ADDRESS=(PROTOCOL=TCP)(HOST=192.0.2.2)(PORT=2222)))(CONNECT_DATA=(SERVICE_NAME=dbfwdb)))
クライアントは、最初のDatabase Firewallインスタンスへの接続を試みます。最初のインスタンスが停止しているか、アクセスできない場合、クライアントはCONNECT_TIMEOUTパラメータに指定された期間(秒)待機します。前述の例では10秒です。その後、クライアントは2番目のインスタンスへの接続を試みます。この動作は要件に応じて変更できます。
ノート:
デフォルトでは、待機時間は60秒です。Database Firewallのデプロイ済インスタンス間でクライアント接続をロード・バランシングするには、LOAD_BALANCEパラメータを使用します。
次に例を示します。
dbfw1=(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=192.0.2.1)(PORT=1111))(ADDRESS=(PROTOCOL=TCP)(HOST=192.0.2.2)(PORT=2222)))(CONNECT_DATA=(SERVICE_NAME=dbfwdb)))
このパラメータを定義すると、クライアントはランダムな順序でアドレスのリストに接続し、多くのDatabase Firewallインスタンスに負荷を分散します。ロード・バランシング・デプロイメントと同様に機能します。
関連トピック
関連項目:
Database Firewallポリシーの作成このトピックには、モニタリング・ポイントがプロキシ・モードである2つ以上の個別のDatabase Firewallインスタンスに高可用性を構成するために必要な情報が含まれています。これは、ローカルDNSの構成を変更することで実現できます。
ノート:
この機能は、Oracle Audit Vault and Database Firewallリリース12.2.0.11.0以降で使用できます。前提条件
構成手順を実行する前に、必要な基本設定を完了します。
DNSが構成されているサーバーで、複数のDatabase FirewallインスタンスのIPアドレスを表すドメイン名を作成します。これは、クライアントがDNSまたはホスト名解決に使用するローカルのDNSです。
ターゲット・データベースへの接続に使用されるクライアントで、この変更を行います。DNSサーバーを既存のドメインのネーム・サーバーとして定義します。この構成は、クライアント・ホストで行う必要があります。
クライアントは、Database Firewallを介してデータベースに接続する際に、ドメイン名をホスト名として使用する必要があります。
ポート番号、サービス名などのその他の詳細を指定します。
SQL*Plusクライアントを使用する場合は、次の文字列を使用して接続します。
sqlplus username/password@<domain name>:port/servicename
この設定では、ドメイン・ネーム・サーバーは次のいずれかの方法で構成できます。
DBFW1、DBFW2など)に常に接続するようにDNSを構成します。この場合、クライアントが最初のインスタンス(DBFW1)に接続できないとき、2番目のインスタンス(DBFW2)への接続が試みられます。関連トピック
関連項目:
Database Firewallポリシーの作成