| Oracle® Audit Vault and Database Firewall管理者ガイド リリース12.2 E70392-19 |
|
 前 |
 次 |
この項では、初期構成の完了後における毎日のAudit Vault ServerおよびDatabase Firewallの操作の管理について説明します。
ここでのトピック
ここでのトピック
必要なファイルが存在するかどうか、HTTPサーバーが実行されているかどうか、Oracleリスナーおよび他のプロセスが実行されているかどうかなど、Audit Vault Serverのアクティビティを追跡するための診断チェックを実行できます。
Audit Vault Serverの診断を実行するには:
関連項目:
個々のDatabase Firewallの診断情報を表示する必要がある場合は、「Database Firewallのステータスおよび診断レポートの表示」を参照してください。
Audit Vault Serverのアプライアンスをデバッグする必要がある場合は、構成全体で使用されるポート、構成設定などの広範な情報を取得する詳細な診断レポートを生成してダウンロードできます。
AVCLI ALTER SYSTEM SETコマンドを使用して各種サーバー・コンポーネントのLOGLEVELを設定することによって、収集する診断情報の量を調整できます。ダウンロード操作を実行すると、その時点で利用可能な構成情報とともに、ログおよびトレース・ファイルの情報が取得されます。ログ・レベルの変更は、変更された後に生成されるトレースまたはログ・ファイルにのみ、その影響が及ぶことに注意してください。たとえば、ログ・レベルをDEBUGに設定した後に問題が発生した場合は、この項の手順を実行して診断レポートをダウンロードする前に、問題を再現する必要があります。そうしないと、レポートにはデバッグまたはトレースが取得されません。
ただし、DEBUG設定によって多くのファイルが生成され、システムのパフォーマンスに影響する可能性があることに注意してください。このため、この設定は一時的な使用を原則とし、問題を診断するときにのみ使用します。問題を発見して修正した後は、DEBUG設定をERRORなどの元の設定に戻します。
Audit Vault Server診断のzipファイルをダウンロードするには:
次のシステム・コンポーネントに対し、異なるログ・レベルを設定できます。
表14-1 様々なログ・レベルを持つコンポーネント
| エージェント | アラート |
|---|---|
アーカイブおよび取得 |
バックグラウンド・サーバー・プロセス |
データ・リポジトリ |
Database Firewall |
通知 |
プラグイン管理 |
ポリシー管理 |
レポートの生成 |
SANストレージ |
トランザクション・ログの証跡 |
WebコンソールUI (3つのログ・レベルのみ) |
該当なし |
ログ・レベルが異なることで、異なる量の情報がシステム・ログに提供され、ログのサイズに影響します。次に、ログ・ファイルに書き込まれる情報量の順にロギング・レベルを示します。debugが最も多い情報量を提供します。
error: 重要な情報のみがレポートされます。これは、最小限のログ・メッセージが生成されます。
warning: (デフォルト)警告およびエラー・メッセージがレポートされます(WebコンソールUIではサポートされません)。
info: 情報メッセージ、警告メッセージ、エラー・メッセージを書き込みます。このレベルは、本番環境ではなく、テスト環境に適しています。
debug: デバッグのために詳細なメッセージを書き込みます。これは、最も多くのログ・メッセージが生成されます。デバッグ・ログには、システムの状態に関する機密情報が含まれる可能性があります。必要な場合にのみdebugログ・レベルを追加し、デバッグが完了したら、それを削除します。
ログ・レベルの設定または変更
ログ・レベルを設定するには:
Audit Vault Serverコンソールにスーパー管理者としてログインします。
「設定」タブをクリックし、システム・メニューで「診断」をクリックします。
リストされるコンポーネントのいずれかで、ドロップダウン・リストからログ・レベルを選択します。
「保存」をクリックします。
診断ログのクリア
Audit Vault Serverから診断ログをクリアするには:
Audit Vault Serverコンソールにスーパー管理者としてログインします。
「設定」タブをクリックし、システム・メニューで「ログ管理」をクリックします。
「診断ログのクリア」をクリックし、「適用」をクリックして確認します。
ログがクリアされたときに、確認メッセージが表示されます。
コネクタ情報を設定または変更するには、関連する次の手順に従います。
ノート:
Micro Focus Security ArcSight SIEM (旧称はHP ArcSight SIEM)は、12.2.0.8.0で非推奨となり、12.2.0.9.0でサポートされなくなります。かわりにsyslog統合機能を使用してください。
アーカイブ・ジョブを開始するには、アーカイブ場所を少なくとも1つ構成する必要があります。
アーカイブの場所へのデータの転送にはNFSを使用することをお薦めします。セキュア・コピー(SCP)またはWindows File Sharing (SMB)を使用してアーカイブの場所にデータを転送する場合、データ・ファイルは、最初にAudit Vault Serverのステージング領域にコピーされます。したがって、ファイル・システムに追加の領域があることを確認する必要があります。そうしないと、データ・ファイルのコピーが失敗する可能性があります。SCPまたはSMBで大きいファイルを転送すると時間がかかることに注意してください。
ノート:
ここでファイルシステムを選択できるように、AVCLIユーティリティを使用してリモート・ファイルシステムを登録できます。詳細は、REGISTER REMOTE FILESYSTEMを参照してください。
アーカイブ・ジョブを開始するには:
ノート:
「ジョブ」ページ→「システム」メニュー→「設定」タブからアーカイブ・ジョブの進捗を確認するには、「ジョブの監視」を参照してください。
アーカイブ場所を作成するには、「アーカイブ場所の定義」を参照してください。
「Oracle Audit Vault And Database Firewallでのデータのアーカイブおよび取得について」
ここでのトピック
リポジトリ暗号化について学習します。
Oracle Audit Vault Serverのイベント・リポジトリの暗号化は、Oracle Audit Vault and Database Firewall 12.2の新規インストールで有効です。この機能では、Oracle Databaseの透過的データ暗号化(TDE)を使用して、Audit Vault Serverに格納されているデータ、外付けのSANストレージに格納されているデータ、およびアーカイブの場所に格納されているデータのすべての監査イベントが暗号化されます。
暗号化キーのローテーションにより、暗号化されたデータにセキュリティのレイヤーが追加されます。
組織のガイドラインに従って、定期的にAudit Vault Serverのイベント・リポジトリのマスター暗号化キーをローテーションする必要があります。また、たとえば、マスター・キーへのアクセス権限を持っていた人が退職した場合など、必要に応じて暗号化キーをローテーションすることをお薦めします。
ノート:
Audit Vault Serverをバックアップからリストアすると、リストア操作によりシステムがある時点に復元されます。したがって、システムのリストアにより、古い暗号化キーが回復されます。
Oracle Audit Vault Serverでアップグレードされたインスタンスのデータ暗号化について学習します。
データ暗号化のフェーズ
このトピックでは、データ暗号化プロセスを開始するために使用できる手順の詳細を示します。
警告:
新しくインストールされたOracle Audit Vault Server、またはOracle Databaseリリース12.2.x以上のフレッシュ・インストールからアップグレードされたシステムでは、データ暗号化プロセスを実行しないでください。Oracle Database 12.2.0以上のバージョンでは、すべての新規インストールで暗号化が自動的に有効になります。したがって、すべての表領域がデフォルトで暗号化されます。
データ暗号化プロセスは2つのフェーズに分かれています。
データ暗号化の有効化:
このフェーズは自動的に行われ、Audit Vault Serverのアップグレードの実行中にデータ暗号化が有効になります。アップグレード・プロセスでは、スタンドアロンおよびプライマリ・システム上のキーストアのパスワードが要求されます。アップグレードが成功すると、データ暗号化が自動的に有効になります。それ以降、新しく作成された表領域は自動的に暗号化されます。ただし、アップグレード前に作成された表領域はクリア・テキストのままです。
既存のクリア・テキスト表領域の暗号化:
このフェーズはユーザーによってトリガーされます。既存のクリア・テキスト表領域を暗号化するには、ユーザーがデータ暗号化プロセスを開始する必要があります。このプロセスをトリガーするには、/usr/local/dbfw/bin/avdf_data_encryption.shスクリプトを実行します。ユーザーによってトリガーされる既存のクリア・テキスト表領域の暗号化ステップの詳細は、このトピックを参照してください。
始める前に
暗号化の速度は、システムのハードウェア・プロファイルにもよりますが、1GBのデータを暗号化するのに20-50秒程度です。
表領域の暗号化プロセスを開始するには、rootとして/usr/local/dbfw/bin/avdf_data_encryption.shスクリプトを実行します。
暗号化プロセスの前に、必ずAVDFのバックアップを取ってください。
ユーザーがこの手順を実行するには、オペレーティング・システムのrootユーザー権限を持っている必要があります。適切な権限を取得していることを確認してください。
暗号化プロセス・スクリプトは、スタンドアロン・システムまたはHA設定のプライマリで実行する必要があります。暗号化スクリプトを実行する前に、スタンバイ・システムも稼働中していることを確認してください。スタンバイ・システムが停止していると、スクリプトでエラーが発生する可能性があります。スクリプトはプライマリ・システムとスタンバイ・システムの両方の表領域を暗号化します。
暗号化プロセスを実行する前に、データベースが稼働していることを確認してください。データベースのステータスを確認するには、rootユーザーとしてログインし、/etc/init.d/dbfwdb statusコマンドを実行します。
暗号化プロセス・スクリプトは、バックグラウンドで実行されているすべてのジョブを停止します。影響を受ける可能性がある重要なプロセスが実行されていないことを確認してください。
ノート:
HAシステムでは、プライマリが正常にアップグレードされるまで、データ暗号化は完全に有効になりません。アップグレードが正常に完了すると、すべてのクリア・テキスト表領域は次のいずれかの状態になります。
オンライン
オフライン・ローカル(オフラインだが、AVS上にデータ・ファイルが存在する)
オフライン・リモート(オフラインだが、アーカイブの場所にデータ・ファイルが存在する)
オンライン(ユーザーが取得)
オンライン(証跡によって取得)
データ暗号化プロセスを開始するには:
ここでのトピック
Oracle Audit Vault Serverのバックアップ・ユーティリティでは、構成設定を含め、すべてのOracle Audit Vault Serverのデータがバックアップされます。
全体バックアップに加え、前回のホット・バックアップからの新しいデータおよび構成の変更のみが含まれる増分バックアップを実行できます。たとえば、日曜日に全体バックアップを行い、月曜日、水曜日および金曜日に増分バックアップを行います。
バックアップ・ユーティリティでは、ホット・バックアップまたはコールド・バックアップを実行できます。ホット・バックアップは、Oracle Audit Vault Serverが実行されている間に実行されます。コールド・バックアップは、実行する前にOracle Audit Vault Serverが停止されます。
バックアップ・ファイルはAudit Vault Serverに格納できますが、Audit Vault Serverのコンピュータが故障した場合に備え、NFSファイルシステムなどのリモートの場所に格納することをお薦めします。バックアップ・ファイルの場所は、Audit Vault Serverからアクセス可能である必要があります。
リストア・ユーティリティでは、バックアップ・ファイルからデータおよび構成を新しいAudit Vault Serverにリストアできます。リストアを実行するコンピュータには、バックアップを取得したコンピュータと同じバージョンのOracle Audit Vault and Database Firewallが存在する必要があります。
ノート:
ユーザーは、リストア操作の実行中は、同じパスのバックアップを指定することに注意する必要があります。たとえば、バックアップ・ディレクトリが/usr/local/backupの場合は、リストア操作の実行中は/usr/local/backupをバックアップ・ディレクトリとして指定します。
Database Firewallをバックアップする必要はありません。Audit Vault Serverは、既存のすべての強制ポイント構成をDatabase Firewallに再適用できます。詳細は、「強制ポイントのリストア」を参照してください。
バックアップ機能では、アーカイブ・ファイルはバックアップされません。アーカイブの場所にあるデータ・ファイルは、リモート・ファイル・システムに配置される可能性があるため、avbackupによってバックアップされません。これらのファイルは、NFSマウント・ポイントにある場合は、以前と同じマウント・ポイント設定を使用して新しいシステムでリストアした後にアクセスできます。
NFSは、Audit Vault Serverのマウント・ポイントです。NFSサーバーを置き換える場合は、Audit Vault Serverがマウント・ポイントにアクセスしていないことを確認してください。
リストア操作の完了には時間がかかります。これは、リストアされるデータの量によって異なります。SSHまたはTerminusを使用してリストア操作を実行する場合、ユーザーの介入がないと接続が削除される場合があります。SSHまたはTerminusを確実に維持してください。
高可用性構成でのバックアップ操作およびリストア操作の動作
高可用性構成を使用している場合は、Oracle Audit Vault and Database Firewallにより、セカンダリ・サーバーではなく、プライマリ・サーバーのバックアップのみが実行されることに注意してください。高可用性のプライマリ・バックアップからリストア操作を実行すると、最後にリストアされたシステムがスタンドアロン・サーバーになり、それは高可用性構成ではありません。
リポジトリ暗号化およびバックアップ暗号化
Oracle Audit Vault and Database Firewallの完全なインストール(アップグレードではなく)を行った場合、Audit Vault Serverに格納されるデータは、自動的にOracle Databaseの透過的データ暗号化(TDE)を使用して暗号化されます。この機能はアップグレードしたシステムでは使用できません。
バックアップでTDEが有効になっていたシステムのバックアップ・ファイルからリストアする場合、リストア中にTDEキーストアのパスワードが要求されます。バックアップが行われたときに使用されていたTDEキーストアのパスワードを使用する必要があります。TDEキーストアのパスワードはバックアップ後に変更される可能性があるため、各バックアップを行うときに、そのとき使用されているキーストア・パスワードを把握しておくことが重要です。
さらに、TDEの機能が使用可能であるかどうかに関係なく、バックアップ・ファイルの暗号化を設定できます。この場合は、バックアップ暗号化パスワードが必要になり、リストアを行うときにそれが要求されます。
したがって、リストアを行うときに2つのパスワードを指定する必要があります。
関連項目:
TDEの詳細は、「リポジトリ暗号化の管理」を参照してください。
Oracle Audit Vault and Database Firewallの高可用性の構成の詳細は、「高可用性の構成」を参照してください。
バックアップ・ファイルに必要な領域の容量を決定します。
バックアップ・ファイルに必要な領域の容量は、Oracle Audit Vault Serverデータベースのサイズによって決まります。Audit Vault Serverで次のSQL問合せを実行して、データベースのバックアップ・ファイルのサイズの上限推定値を取得できます。
sqlplus system
Enter password: password
SELECT SUM (BYTES)/1024/1024/1024||' GB' FROM DBA_DATA_FILESFoot 1
ノート:
新しいシステムのRAMサイズおよびディスク・サイズが元のシステムと同じかそれ以上であることを確認してください。これにより、バックアップおよびリストア・タスクの実行中にout of memoryエラーが発生しなくなります。
バックアップ・プロセスにSAN構成は含まれません。リストアを実行する前に、新しいシステムに十分なディスク領域があることを確認してください。必要なディスク領域の詳細は、バックアップ・ディレクトリにあるinfo.txtファイルを参照してください。
リストア・システムには、少なくともバックアップ・システムと同じ量のメモリーとディスク領域が必要です。足りない場合、リストア操作は失敗します。
高可用性構成を使用している場合にコールド・バックアップを実行するには、次の手順を実行します。
Audit Vault Serverコンソールにログインします。
「設定」を選択します。
「システム」で、「高可用性」を選択します。
「フェイルオーバーの無効化」ボタンを選択します。
「確認」ダイアログで、「OK」をクリックします。
Audit Vault Serverにrootとしてログインします。
次のコマンドを実行し、入力を要求されたら情報を入力します。
/var/lib/oracle/dbfw/bin/avbackup config
システムから、次のように入力を要求されます。
BACKUP_DIR
このプロンプトは、バックアップ・ファイルの格納先ディレクトリを示しています。ディレクトリ名は、200文字以内にする必要があります。Oracle Recovery Manager (RMAN)により、このディレクトリ内のバックアップ・ファイルが追跡されるため、ディレクトリを指定した後でディレクトリのパスを変更しないでください。ファイルは、Oracleユーザーとしてこのディレクトリに書き込まれます。このディレクトリへのすべてのアクセスは、ユーザーoracleで処理されます。(oracleユーザーはoinstallグループに属します。)Oracleは、自動的にリストア操作中にこのディレクトリ・パスを使用します。
このディレクトリはAudit Vault Serverからアクセスでき、oracle:oinstallが所有している必要があります。この値は、一度設定したら変更してはならず、全体バックアップまたは増分バックアップのいずれを行うかにかかわらず、同じである必要があります。
クローズ状態のバックアップとオンライン・バックアップを同じBACKUP_DIRの場所に置かないでください。次のガイドラインに従ってください。
同じBACKUP_DIRディレクトリで、オンラインの全体(増分0)バックアップの上位にオンラインの増分1バックアップを配置します。または、同じBACKUP_DIRディレクトリで、クローズ状態の増分0バックアップの上位にクローズ状態の増分1バックアップを配置できます。
同じBACKUP_DIRディレクトリで、オンラインの増分0バックアップの上位にクローズ状態の増分1バックアップを置いたり、同じBACKUP_DIRディレクトリで、クローズ状態の増分0バックアップの上位にオンラインの増分1バックアップを置かないでください。そのようにすると、これらのバックアップ・ファイルのリストア操作が失敗する原因となります。
リストア操作中、同じディレクトリ・パスが自動的に使用されます。このバックアップ先は、バックアップ・ファイルを格納するための十分な空き領域のある、マウントされているファイルシステムである必要があります。これは、NFSファイルシステム(マウントする方法は、「リモート・ファイルシステムのAVCLIコマンド」を参照)でもかまいませんが、SANストレージは使用できません。
次に例を示します。
BACKUP_DIR[/backup]:/AVBACKUP
TMP_DIR
このディレクトリは、作業ディレクトリが作成される一時的な(親)作業ディレクトリです。このディレクトリには、少なくとも100MBの空き領域が必要です。oracleユーザーには、TMP_DIRの読取り/書込みのアクセス権限が必要です。
次に例を示します。
TMP_DIR[/tmp]:/usr/local/dbfw/tmp/BCKTMP
KEEP_LOGS
この設定により、バックアップ操作が成功した後、ログ・ファイルを保存するかどうかが決定されます。ログ・ファイルは、失敗した後は常に保存されます。バックアップまたはリストアが成功したときにログを保存するには、YESを入力します。バックアップまたはリストアが成功した後にログを自動的に削除するには、NOを入力します。
次に例を示します。
KEEP_LOGS[NO]:yes
INCREMENTAL_STRATEGY
この設定では、RMANの増分バックアップのレベルを選択します。全体バックアップを実行するには、0を入力します。増分バックアップを実行するには、1を入力します。増分バックアップでは、前回のバックアップ以降の変更がバックアップされます。
次に例を示します。
INCREMENTAL[0]:0
BACKUP_TYPE
この設定では、実行するバックアップのタイプを指定します。HOTまたはCOLDを入力します。ホット・バックアップは、Audit Vault Serverデータベースの実行中に実行されます。ただし、ホット・バックアップ処理中は、アーカイブ・ログ・モードが有効になっている必要があります。アーカイブ・ログ・モードが有効でない場合は、アーカイブ・ログ・モードを有効にするためにデータベースを停止して、データベースを再起動する必要があります。アーカイブ・ログ・モードを有効にする操作に時間はかかりませんが、停止および再起動を行う必要があります。コールド・バックアップでは、バックアップ処理中にAudit Vault serverデータベースが停止されます。コールド・バックアップを実行する前に、メンテナンスの停止をスケジュールする必要があります。
次に例を示します。
BACKUP_TYPE[HOT]:COLD
PASSWD
(オプション)この設定では、バックアップ・ファイルの暗号化パスワードを設定します。バックアップ・ファイルからリストアするときに、このパスワードが必要になります。他のパラメータとは異なり、パスワード・パラメータはバックアップから自動的に取得できません。この設定を省略すると、バックアップ・ファイルは暗号化されません。
次に例を示します。
PASSWD[-- not set --]: password Confirm password: password
MAXPIECESIZE
この設定では、バックアップ・ファイルの最大サイズを指定します。有効なファイルの最大サイズは、実際のファイルシステムによって異なります。これを設定するのは、CHANNEL_PARALLELISMが1に設定されている場合のみです。
次に例を示します。
MAXPIECESIZE[2G]:
CHANNEL_PARALLELISM
この設定では、コマンドの実行に使用されるチャネル(プロセス)の数を指定します。これは、アクセスするデバイスの数と一致する必要があります。
並列性が1より大きい場合、ユーザーは場所およびセクション・サイズを要求されます。並列性が1の場合、ユーザーはMAXPIECESIZEを要求されます。
例: 物理ディスクごとに1つ。
チャネルの数が1より大きい場合、各チャネルの場所およびセクション・サイズを指定します。
CHANNEL_PARALLELISM[1]:4
ベスト・プラクティス:
複数の物理ディスクがある場合は、物理ディスクの数に応じてCHANNEL_PARALLELISMを適切な値に設定することをお薦めします。大規模なデータベースをバックアップするには、システムのバックアップに必要な時間を短縮するために、実際の物理ディスク設定に従ってCHANNEL_PARALLELISMおよびSECTION_SIZEを設定します。CHANNEL_LOCATION
チャネルの場所を指定します。ユーザーは、各チャネルに複数の場所を設定できます。すべてのチャネルに対してすべての場所を同じにすることができます。この場所は、バックアップ・ファイルのフルパスです。パフォーマンスを向上させるために、異なる物理ハード・ディスク上の異なる場所を指定する必要があります。すべての場所を同じパスに指定できます。
次に例を示します。
CHANNEL_LOCATION_1[]:/disk_1 CHANNEL_LOCATION_2[]:/disk_2 CHANNEL_LOCATION_3[]:/disk_3 CHANNEL_LOCATION_4[]:/disk_4
SECTION_SIZE
セクション・サイズは最大のデータ・ファイルまたは並列性より小さく、物理ディスクが処理可能なサイズより小さくなります。
次に例を示します。
SECTION_SIZE[]:32G
USE_NEW_IP
リストア操作に対して、バックアップ・システムからの古いIPアドレスではなく、リストア・システムの新しい(現行) IPアドレスを指定します。使用できる値はYまたはNです。
USE_NEW_IP[N]:Y
REDUNDANCY
この設定では、保持する全体バックアップの数を指定します。backupコマンドを実行すると、この数よりも古いバックアップ(および、それに関連する増分バックアップ)が削除されます。冗長性を高めるには、バックアップ用により多くのディスク領域(BACKUP_DIRパラメータで指定されるもの)が必要になります。
次に例を示します。
REDUNDANCY[1]:
これらの設定を完了すると、次のような選択内容の概要が表示されます。
BACKUP_DIR=/long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars TMP_DIR=/tmp KEEP_LOGS=NO INCREMENTAL=0 BACKUP_TYPE=HOT PASSWD=-- not set -- CHANNEL_PARALLELISM=3 CHANNEL_LOCATION=/long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars /long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars /long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars SECTION_SIZE=500M REDUNDANCY=1 USE_NEW_IP=Y
バックアップの構成処理中にアーカイブ・ログ・モードを変更した場合は、データベースが再起動した後で、Audit Vault Server上でJava Framework内部ツールが実行されていることを確認します。
次に例を示します。
/usr/local/dbfw/bin/javafwk status
Java framework process is stoppedと出力される場合は、次のように再起動します。
/usr/local/dbfw/bin/javafwk start
このステップでは、バックアップを検証します。avbackup configファイルの設定に関係なく、最後に作成したバックアップの検証操作が実行されます。
ノート:
バックアップ構成ファイルはリリースに固有のものです。同じリリースでのみ機能します。各アップグレードの後、バックアップ操作を実行する前に、avbackup configコマンドを実行し、新しい構成ファイルを作成することをお薦めします。
クローズ状態のバックアップとオンライン・バックアップの場所は同じにしないでください。同じBACKUP_DIRの場所を使用しないでください。この場所を指定した後は、Oracle Recovery Manager (RMAN)でこのディレクトリ内のバックアップ・ファイルが追跡されるため、ディレクトリ・パスを変更しないようにすることをお薦めします。
ノート:
avbackupを使用して定期的なバックアップを実行する場合、全体バックアップと増分バックアップのcronジョブを設定する場合、または独自のスクリプトを使用してバックアップ操作を実行する場合は、次のことに留意してください。
avbackupツールでは、データベースとOracle Audit Vault and Database Firewallの構成のバックアップが実行されます。
RMANバックアップでは、Oracle Audit Vault and Database Firewallデータベースのみがバックアップされます。RMANは、アーカイブ、バックアップおよびアップグレードのプロセスで重要な役割を果たします。Audit Vault ServerのデフォルトのRMAN設定は変更しないでください。
RMANのみのバックアップでは、システムがクラッシュした場合に新しいシステムでリストアできません。元の構成がないため、このバックアップは機能しません。
RMANによるバックアップ計画は、データベースがクラッシュし、システムがまだ実行中である場合にのみ機能します。
avbackup構成のこの問題を解決するには、次のマンドを実行します。これらのコマンドは例として示すものであり、cronジョブ設定に役立ちます。ただし、これが原因で生じる問題は、Oracleではサポート範囲外となります。
| タスク | プロシージャ |
|---|---|
全体バックアップ用にavbackup構成を1回実行する |
|
全体増分バックアップ用にavbackup構成を1回実行する |
|
全体バックアップ用にcronジョブを1つ設定する |
|
増分バックアップ用にcronジョブを1つ設定する |
|
ここでのトピック
Audit Vault Serverの内容をリストアした後で、次のアクションが発生します。
すべてのデータベース・アカウントは、以前のシステムからのアカウントに置き換えられます。リストア処理の後で、必要に応じてこれらのアカウントを変更できます。
キーストアのパスワードは、以前のシステムで使用されていたキーストアのパスワードに置き換えられます。リストア処理が完了した後で、必要に応じてキーストアのパスワードを変更できます。
オペレーティング・システムのアカウントは、リストア処理の影響を受けません。したがって、rootおよびsupportのアカウントに設定したパスワードは、リストア前と同じままです。
Oracle Audit Vault Serverをリストアするための前提条件を確認します。
新しいOracle Audit Vault Serverにバックアップ・ファイルをリストアする前に、次のことを実行します。
ノート:
avbackup configコマンドを実行する際に、USE_NEW_IPパラメータをNに設定します。この場合、元のシステムがまだ稼働していると、使用中のIPアドレスは切り替えられないのでリストアが失敗します。avbackup configコマンドを実行する際に、USE_NEW_IPパラメータがYに設定されていることを確認します。この場合は、バックアップ・システムと同じサブネットでリストアする必要はありません。この構成は、異なるサブネット上にある別のデータ・センターでリストアする場合や、バックアップ・システムが稼働中に新しいIPでバックアップをリストアする場合に使用できます。バックアップ・ファイルから新しいAudit Vault Serverをリストアするには、まず、新しいAudit Vault Serverにバックアップ・ユーティリティを設定します。
「ステップ1: バックアップ・ユーティリティの構成」と同じ手順に従って、BACKUP_DIRおよびPASSWDにシステムをバックアップしたときと同じ値を指定します。
新規または異なるIPアドレスを持つ新しいシステムにバックアップをリストアする方法を学習します。
リストア操作を実行した後、同じIPアドレスが使用されます。システムのサービスおよび機能を中断せずに新しいIPアドレスを維持するオプションがあります。新しいIPアドレスが使用されている場合、システムによってデータベースがリストアされ、新しいIPアドレスが維持されます。この項では、システムまたはAudit Vault Serverがデフォルトで元のIPアドレスを保持しないように、リストア操作の後に実行する必要があるステップについて説明します。
システムに新しいIPアドレスがある場合、リストア操作の後に次のステップを実行します。
ノート:
新しいIPでのリストア・プロセスが完了すると、バックアップ・システムのコンソール証明書が無効になるか、使用中になります。新しい証明書を生成してアップロードする必要があります。
リストア操作の完了には時間がかかります。これは、リストアされるデータの量によって異なります。SSHまたはTerminusを使用してリストア操作を実行する場合、ユーザーの介入がないと接続が削除される場合があります。SSHまたはTerminusを確実に維持してください。
ここでのトピック
Audit Vault ServerでOracle Database In-Memoryを有効にすると、Oracle Audit Vault and Database Firewallのレポートおよびダッシュボードのパフォーマンスが向上します。この機能では、指定した期間に特定の容量のシステム・メモリーを監査データに割り当てることができます。インメモリーに存在する監査データは、より迅速にダッシュボードおよびレポートで使用可能になります。
Oracle Database In-Memoryに割り当てるシステム・メモリーの容量、およびその環境で1日当たりに収集されるデータの平均量に基づいて、Oracle Audit Vault and Database Firewallによって、割り当てられたメモリーに収まる監査データの日数が計算されます。この計算に基づいてインメモリーの日付範囲がOracle Audit Vault and Database Firewall監査者に表示され、迅速なレポートを取得できる期間がわかります。たとえば、1GBが2日分のデータに対応できる場合、1GBのメモリーをOracle Database In-Memoryに提供すると、2日分の最新データがOracle Database In-Memoryに格納されます。2GBのメモリーをOracle Database In-Memoryに提供すると、4日分のデータがOracle Database In-Memoryに送られます。
Oracle Database In-Memoryを有効にする前に必ず、現在および将来、セキュア・ターゲットと強制ポイントのために必要となるメモリー容量を見積ります。『Oracle Audit Vault and Database Firewallのサイズ設定アドバイス』(MOSドキュメントID 2223771.1)で、RAM要件を計算するためのガイドラインを参照できます。このドキュメントは、Oracle Supportから入手できます。通常のRAM要件を見積った後、Oracle Database In-Memory機能を使用する場合は、インメモリー・データベースにどのくらいのRAMを使用するかを見積り、それをRAM要件に追加します。機能を有効にする場合は、Oracle Database In-Memory用に少なくとも1GBを割り当てる必要があります。
Oracle Database In-Memoryを有効にした後で、日付範囲に基づいて実行するか、最新データを保存するように実行するかを選択できます。この手順ではデータベースの再起動は行いません。またエージェント・コレクタなどのコンポーネントに対する影響はありません。
Oracle Audit Vault Serverでサーバーの表領域使用量を監視できます。
Oracle Audit Vault Serverには、SYSAUX表領域があり、デフォルトでは1つのデータ・ファイルが保持されています。SYSAUX表領域は、自動セグメント領域管理が指定されたローカル管理表領域です。
管理者は、SYSAUX表領域の領域使用量を監視し、必要に応じて保存用の追加のデータファイルを作成する必要があります。
関連項目:
保存用データ・ファイルを追加する場合に使用できるALTER TABLESPACE SQL文の詳細は、『Oracle Database管理者ガイド』を参照してください。
表領域の最適化の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。
システムを管理するためのアーカイブ・ログ・ディスク領域使用量を監視できます。
Oracle Audit Vault Serverデータベースでは、デフォルトでARCHIVELOGモードが無効です。ARCHIVELOGモードが有効になると、一杯になったオンラインREDOログがディスクにコピーされます。これにより、データベースをオープンしてユーザーからのアクセスに対応しながらそのデータベースをバックアップすることや、データベースを任意の時点にリカバリすることができます。管理者は、REDOログのディスク領域使用量を監視する必要があります。
関連項目:
アーカイブ・ログ・モードの設定の詳細およびアーカイブ・ログに関するその他の一般情報は、『Oracle Database管理者ガイド』を参照してください。
LOG_ARCHIVE_DEST_nの場所を変更して、これらのアーカイブ・ログ・ファイルの場所をより大きなディスクに変更する方法の詳細は、方法1: LOG_ARCHIVE_DEST_nパラメータの使用に関する項を参照してください。
アーカイブ・ログのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
バックアップのために十分な領域があることを確認するためにサーバーのフラッシュ・リカバリ領域を監視することをお薦めします。
Oracle Audit Vault Serverには、デフォルトで次の初期化パラメータ設定が含まれます。
DB_RECOVERY_FILE_DEST_SIZE初期化パラメータは、2GBに設定されています。
DB_RECOVERY_FILE_DEST初期化パラメータは、デフォルトのフラッシュ・リカバリ領域(通常はORACLE_HOME/flash_recovery_areaディレクトリ)に設定されています。
フラッシュ・リカバリ領域のサイズが、すべてのデータファイルのコピー、すべての増分バックアップ、オンラインREDOログ、テープにバックアップされていないアーカイブREDOログ、制御ファイル、および制御ファイルの自動バックアップの保持に十分な大きさであることを確認してください。この領域は、構成されている監査証跡の数、監査レコードの収集を管理する範囲、実施するバックアップおよびアーカイブ計画によっては、すぐに一杯になる可能性があります。
管理者は、Oracle Enterprise Manager Database Controlを使用して、フラッシュ・リカバリ領域の空き容量を監視できます。「ホーム」ページの「高可用性」セクションの「使用可能なフラッシュ・リカバリ領域」フィールドで、使用可能な領域の割合を監視します。データベース・コンソールのアラート・ログのメッセージを確認します。フラッシュ・リカバリ領域の使用済の領域の割合が85%になると、警告メッセージがアラート・ログに送信されます。フラッシュ・リカバリ領域の使用済の領域の割合が97%になると、クリティカル警告メッセージがアラート・ログに送信されます。
DB_RECOVERY_FILE_DEST_SIZE初期化パラメータの値をこれらのファイルに対応できるように増やし、DB_RECOVERY_FILE_DEST初期化パラメータの値をより多くのディスク領域を使用できるところに設定することにより、フラッシュ・リカバリ領域の空き領域を管理できます。
関連項目:
『Oracle Database管理者ガイド』
『Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド』
ここでのトピック
Audit Vault Serverコンソール(Web) UIを使用するかわりに、AVCLIコマンドライン・インタフェースを使用して、セキュア・ターゲットの登録および構成、Audit Vault Serverへの接続など、Oracle Audit Vault and Database Firewallを管理できます。
Audit Vault ServerからAVCLIを実行することも、Audit Vault ServerからAVCLIユーティリティをダウンロードし、別のコンピュータにユーティリティをインストールして実行することもできます。
AVCLIで使用される構文は、SQL*Plusに似ています。たとえば、AVCLI内から、CONNECTコマンドを使用して別のユーザーとしてログインできます。また、AVCLIコマンドでは、大/小文字を区別しません。このマニュアルでは、コマンドは大文字で入力しています。
ノート:
JDKのインストール・ディレクトリを指すようにJAVA_HOME環境変数を設定してください。Windowsで、%JAVA_HOME%\binをPATH環境変数に追加します。
関連項目:
使用可能なAVCLIコマンドの詳細は、「AVCLIコマンド・リファレンス」を参照してください。
ユーザー名を指定してもしなくても、AVCLIを対話モードで起動できます(つまり、パスワードを指定する必要があります)。格納されている資格証明を使用してAVCLIを起動することもできます。この項では、AVCLIを起動する2つの方法について説明します。
ここでのトピック
AVCLIを対話モードで起動するには、次の方法のいずれかを使用します。オプションであるいくつかのコマンドを除いて、AVCLIコマンドはすべてセミコロン(;)で終了する必要があります。簡単にするために、このガイドではすべてのAVCLIコマンドにセミコロンを使用します。
ユーザー名を指定した対話型モードの使用
ユーザー名を指定してAVCLIを起動する場合のコマンド構文は、次のとおりです。
avcli -u username Enter password: password
次に例を示します。
avcli -u psmith AVCLI : Release 12.2.0.0.0 - Production on timestamp Copyright (c) 1996, 2015 Oracle. All Rights Reserved. Enter password for 'psmith': password Connected to: Oracle Audit Vault Server 12.2.0.0.0 AVCLI>
ユーザー名を指定しない対話型モードの使用
ユーザー名を指定せずにAVCLIを起動する場合は、AV_ADMINロールを付与された有効なユーザーとしてAudit Vault Serverに接続する必要があります。ユーザー名を指定してAVCLIを起動する場合のコマンド構文は、次のとおりです。
avcli AVCLI> CONNECT [username];
次に例を示します。
avcli AVCLI : Release 12.2.0.0.0 - Production on timestamp Copyright (c) 1996, 2015 Oracle. All Rights Reserved. AVCLI> CONNECT psmith Enter password: password; Connected.
ユーザー名を入力していない場合は、要求されます。
Oracle AVDF管理者の資格証明の格納は、ユーザーの介入なしに、またスクリプト内に資格証明を置かずにAVCLIスクリプトを実行する必要がある場合に役立ちます。
AVCLIの所有者である場合(つまり、AVCLIユーティリティをインストールした場合)は、AVCLIウォレットに1人のOracle AVDF管理者の資格証明を格納できます。その後、管理者は資格証明を提供せずにAVCLIを呼び出すことができ、介入しなくてもスクリプトを実行できます。
管理者の資格証明の格納または上書き
管理者が資格証明なしに(非対話的に)AVCLIを呼び出すことができるための前提条件として、AVCLIの所有者が管理者の資格証明を格納する必要があります。AVCLIの所有者として、1人の管理者の資格証明のみを格納できます。
指定された管理者の資格証明を格納するには:
AVCLIの所有者として、Audit Vault Serverと接続せずにavcliを実行します。次に例を示します。
avcli
AVCLI : Release Release 12.2.0.0.0 - Production on timestamp
Copyright (c) 1996, 2015 Oracle. All Rights Reserved.
AVCLI>
STORE CREDENTIALSコマンドを実行し、入力を要求されたら管理者の資格証明を入力します。次に例を示します。
AVCLI> STORE CREDENTIALS; Enter user name: username Enter password:password Re-enter password:password
前に格納されている資格証明は上書きされます。
ノート:
この管理者のパスワードを変更した場合は、再びこの手順に従って新しい資格証明を格納します。
格納されている資格証明を使用したAVCLIの起動(非対話的に)
資格証明を入力せずにAVCLIを起動するには、前の手順で詳しく説明したように、資格証明が格納されている必要があります。
格納されている資格証明を使用してAVCLIを起動する2つの方法があります。
シェルから
Audit Vault Serverで、次のように入力します。
avcli /@
このコマンドは、AVCLIにログインし、Audit Vault Serverに接続します。
AVCLI内から
資格証明なしにシェルからAVCLIを起動した(avcliと入力して)場合は、次のように入力してAudit Vault Serverに接続します。
AVCLI> CONNECT /@;
次に例を示します。
avcli
AVCLI : Release 12.2.0.0.0 - Production on timestamp
Copyright (c) 1996, 2015 Oracle. All Rights Reserved.
AVCLI> CONNECT /@;
Connected.
関連項目:
ユーザーの介入なしに、またスクリプト内に資格証明を置かずに、AVCLIスクリプトを実行できます。
.av拡張子が付いています。 AVCLIスクリプトの例を次に示します。
#Here is an AVCLI command start collection for secured target sample_target1 using host sample_host1 from table SYS.AUD$; #More AVCLI commands #Quit command quit;
AVCLIを起動するときに、次のログ・レベルを指定できます。Oracle Audit Vault and Database Firewallにより、Audit Vault Serverの$ORACLE_HOME/av/logディレクトリにログが書き込まれます。
info: 情報およびエラー・メッセージが記録されます。
warning: 警告およびエラー・メッセージが記録されます。
error: エラー・メッセージのみが記録されます(デフォルト)。
debug: デバッグ、エラー、警告および情報メッセージが記録されます。
ログ・レベルを指定するには、Lオプションを入力します。たとえば、ユーザーpsmithとしてAVCLIを起動し、ログ・レベルをwarningに設定するには、次のようにします。
avcli -l warning -u psmith AVCLI : Release 12.2.0.0.0 - Production on timestamp Copyright (c) 1996, 2015 Oracle. All Rights Reserved. Enter password for 'psmith': password Connected to: Oracle Audit Vault Server 12.2.0.0.0 AVCLI>
スクリプトを使用してAVCLIを起動し、debug警告レベルを指定するには:
avcli -l debug -f myscript.av AVCLI : Release 12.2.0.0.0 - Production on timestamp Copyright (c) 1996, 2015 Oracle. All Rights Reserved. AVCLI> Connected. AVCLI> the script myscript.av executes
ノート: AV_ADMINロールを付与された有効なユーザーとして接続する必要があります。そのためには、CONNECT username/passwordディレクティブを使用します。
ここでのトピック
Database Firewallのネットワーク、トラフィック・ソースまたはサービス構成を変更する必要がある場合、次の項のいずれかを参照してください。
デバッグを目的としてネットワーク・トラフィックを表示できます。ファイアウォールを通過するライブ・ネットワーク・トラフィックを表示できます。
Database Firewallでライブ・ネットワーク・トラフィックを表示するには:
Oracle Database Firewallでネットワーク・トラフィックを取得する方法を学習します。
トラフィックをファイル(.pcapファイル・タイプ)に取得でき、これをダウンロードして分析できます。
ネットワーク・トラフィックをファイルに取得するには:
この手順を使用して、Oracle Database Firewallの再起動または電源オフを行います。
Database Firewallを再起動または電源オフするには:
Oracle Audit Vault ServerからOracle Database Firewallを削除できます。
Oracle Audit Vault ServerからOracle Database Firewallを削除するには:
Oracle Database Firewallから更新された証明書を取得する方法を学習します。
Audit Vault ServerコンソールUIを使用して、Audit Vault Serverに格納されているDatabase Firewall証明書を更新できます。ファイアウォールとAudit Vault Server間の通信を保守するためにDatabase Firewallをアップグレードする場合は、この証明書を更新する必要があります。
Audit Vault Serverに保存されているDatabase Firewall証明書を更新するには:
ファイアウォールのリストが表示されます。
関連項目:
Database Firewallの診断を表示するには、「Database Firewallのステータスおよび診断レポートの表示」を参照してください。
Oracle Database Firewallのリセット方法を学習します。
この項には、Oracle Database Firewall設定の情報およびFirewall IDのリセットの詳細が含まれています。「Database Firewall IDのリセット」タブの「リセットID」ボタンは、Firewall IDのリセットを実行します。Firewall IDは、ファイアウォールの一意の識別番号です。これは管理ネットワーク・インタフェース・カードから導出されます。リセットが実行されると、既存の強制ポイントが削除され、Audit Vault Serverに格納されている構成情報を使用して新しい強制ポイントが作成されます。Audit Vault Serverにリストされていない強制ポイントは、リセットが実行されると削除されます。未処理の取得済データも削除されます。Firewallのネットワーク設定は変更されません。このアクションにより、Firewall IDもリセットされます。
ノート:
ネットワーク・インタフェース・カードを交換するときは、Firewall IDをリセットする必要があります。
Firewallのネットワーク設定は変更されません。Firewall IDをリセットする前に、ファイアウォール・ネットワークが適切に構成されていることを確認してください。
ユーザーは、次のシナリオでFirewall IDをリセットする必要があります。
Database Firewallで管理ネットワーク・インタフェース・カードを交換した後。
既存の構成済ファイアウォールを、新しくインストールしたファイアウォールと置換した後。
Audit Vault Serverをバックアップからリストアするとき、Database Firewallに登録された強制ポイントのステータスをリストアする必要があります。
関連項目:
詳細は、「Oracle Database Firewallのリセット」を参照してください。
脚注
脚注1:このガイドでは、1GBは2の30乗バイトまたは10進表記の1,073,741,824バイトを表します。
