A 監査者のためのOracle Audit Vault and Database Firewallのトラブルシューティング

監査者がOracle Audit Vault and Database Firewallを使用しているときに遭遇することがある問題の解決方法について説明します。

A.1 avauditorとしてUIにログインしているときのサーバー・エラー500

このエラーと回避策は、Oracle AVDF 20.1-20.4にのみ適用されます。Oracle AVDF 20.5以降、この修正はOracle AVDFに組み込まれています。

問題

Oracle AVDFのメイン・ダッシュボード・ページがタイム・アウトになっていて、avauditorとしてUIにログインするとサーバー・エラー500が発生します。

回避策

次のリンクを使用して、ダッシュボードにアクセスしないで監査者コンソールにログインします。

https://<your_ip>/console/f?p=7700:170:840803006486::NO:170::&cs=3sUkbsmjyA0l4dG7esmazo5QHpcHUH-VMcnBdG0LMRQzscQZAV-KmBtzF8wnSPJo3uPv-2avAn3YPBBjzBmOVfA。

<your_ip>は、Oracle AVDFインスタンスのIPアドレスに変更してください。

A.2 データベース・ファイアウォール監視対象アクティビティ・レポート - 不正なゲートウェイのエラー

問題

Oracle AVDF 20.4以前では、データベース・ファイアウォール監視対象アクティビティ・レポートを24時間以上フェッチしようとすると、次のエラーが表示されます。

Error: Bad Gateway

エラーを再現するには、Audit Vault Serverコンソールにスーパー監査者(AVAUDITOR)としてログインします。「レポート」タブを選択し、「アクティビティ・レポート」、「データベース・ファイアウォール・レポート」、データベース・ファイアウォール監視対象アクティビティの順にナビゲートします。データベース・ファイアウォール監視対象アクティビティ・レポートを24時間以上フェッチしてください。

解決策

ノート:

この問題は、Oracle AVDF 20.5で修正されました。

Oracle AVDF 20.4以前では、次の回避策を使用します。

  1. Audit Vault Serverコンソールに監査者としてログインします。
  2. 「レポート」タブをクリックします。
  3. 「すべてのアクティビティ」レポートをクリックします。
  4. 場所 = 'ネットワーク'のフィルタを追加します。
  5. レポートを"データベース・ファイアウォール・アクティビティ"として保存します。
  6. 「保存されたレポート」タブをクリックし、保存したレポートを開きます。

A.3 Audit Vault 20.XのEVENT_LOG列RECORD_IDは順次生成かランダム生成か

RECORD_ID列が順序どおりになることは保証されません。RECORD_IDが一意となることは保証されます。

A.4 タイムスタンプ/時刻を使用してすべてのアクティビティ・レポートをフィルタ処理するオプションがない

問題

特定の日時のデータを抽出できるように、タイムスタンプ/時刻を使用してすべてのアクティビティ・レポートをフィルタ処理するオプションはありません。

回避策

対話モード・レポートに行フィルタを追加します。次のステップを実行します。

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

  2. 「レポート」タブをクリックします。
  3. 「すべてのアクティビティ」レポートをクリックします。
  4. 「アクション」メニューで「フィルタ」を選択します。
  5. 「行」タブを選択します。
  6. 次の式を入力します。
     to_timestamp(to_char(BZ,'MM/DD/YYYY HH:MI:SS PM'),'MM/DD/YYYY HH:MI:SS PM') >= to_timestamp('11/17/2021 12:35:55 PM','MM/DD/YYYY HH:MI:SS PM') AND to_timestamp(to_char(BZ,'MM/DD/YYYY HH:MI:SS PM') ,'MM/DD/YYYY HH:MI:SS PM') <= to_timestamp('11/17/2021 1:05:59 PM' ,'MM/DD/YYYY HH:MI:SS PM')

    要件にあわせてフィルタのタイムスタンプを変更します。

  7. 「適用」をクリックします。

A.5 AVDF 20.4インストールにおける「特権ユーザーによるすべてのアクティビティ」レポートのデータ移入の問題

AVDF 20.4が正常にインストールされていても、「特権ユーザーによるすべてのアクティビティ」レポートにデータが表示されません。これは、権限ジョブがまだ実行されていないためです。これは、ジョブを実行してレポートを再フェッチした後に解決されます。

症状

仮想マシン(VM)でのAVDF 20.4のインストールが成功し、エージェントおよびホスト・モニターがセキュア・ターゲットに正常にインストールされた後、ディレクトリおよびネットワーク証跡が追加されると、システムは完全に動作します。すべてのモニタリング・ポイントがアクティブで、データベース・ファイアウォールのヘルス・インジケータが緑色です。SYSユーザー・データおよびアプリケーション・ユーザー・データは、「特権ユーザーによるすべてのアクティビティ」レポートを除くすべてのレポートに移入されます。

原因

権限ジョブがデータの移入のために実行されていないため、「特権ユーザーによるすべてのアクティビティ」レポートにはデータが移入されません。

解決策

この問題を解決するには、ユーザー権限ジョブを少なくとも1回実行します。詳細は、Oracle Databaseターゲットのユーザー権限データの取得を参照してください。ジョブが正常に完了した後、レポートのフェッチを再試行します。その後、データは「特権ユーザーによるすべてのアクティビティ」レポートに移入されます。

A.6 アラート・キューおよびアラート・ストアのパージ方法

問題

アラート・キュー表が長い場合、生成されたアラートの電子メール通知は送信されません。

回避策

avsysユーザーとして次を実行します。

  1. 次のように、アラート・キュー表をパージします。
    declare
po dbms_aqadm.aq$_purge_options_t;
begin
po.block := TRUE;
DBMS_AQADM.PURGE_QUEUE_TABLE(
    queue_table=>'avsys.av_alert_qt',
    purge_condition=>NULL,
    purge_options=>po);
END;
  2. 次のように、表alert_store, ALERT_TROUBLETICKET_JOB,ALERT_EMAIL_JOB,ALERT_NOTEを切り捨てます。
    ALTER TABLE ALERT_TROUBLETICKET_JOB DISABLE CONSTRAINT ALRT_TTKT_JOB_ALRT_STORE_FK;
ALTER TABLE ALERT_EMAIL_JOB DISABLE CONSTRAINT ALRT_EMAIL_JOB_ALRT_STORE_FK;
ALTER TABLE ALERT_NOTE DISABLE CONSTRAINT ALERT_NOTE_ALERT_STORE_FK;

truncate table alert_store cascade;
truncate table ALERT_TROUBLETICKET_JOB;
truncate table ALERT_EMAIL_JOB;
truncate table ALERT_NOTE;
  3. 次のように、制約を再度有効にします。
    ALTER TABLE ALERT_NOTE ENABLE CONSTRAINT ALERT_NOTE_ALERT_STORE_FK;
ALTER TABLE ALERT_TROUBLETICKET_JOB ENABLE CONSTRAINT ALRT_TTKT_JOB_ALRT_STORE_FK;
ALTER TABLE ALERT_EMAIL_JOB ENABLE CONSTRAINT ALRT_EMAIL_JOB_ALRT_STORE_FK;

A.7 失敗したログイン・アラート・ポリシー

LOGINコマンド・クラスとLOGONコマンド・クラスの両方を使用して、失敗したログイン・アラート・ポリシーをAVDFで構成する方法について学習します。

問題

失敗したログイン・アラート・ポリシーは有効ですが、アラート条件が正しくトリガーされません。現在の条件は次のとおりです:
:COMMAND_CLASS = 'LOGON'
AND
:EVENT_STATUS = 'FAILURE'

失敗したログイン試行がポリシーで予期したとおりに取得されないことがあります。

回避策

この問題を解決するには、アラート条件を更新して、LOGINコマンド・クラスとLOGONコマンド・クラスの両方を含めて、すべての失敗したログイン試行が取得されるようにします。また、ターゲットでアラートをフィルタするには、:SECURED_TARGET_NAME IN()句を含めます。

改訂された条件:
: COMMAND_CLASS ='LOGON','LOGIN'
AND
:EVENT_STATUS ='FAILURE'
Group By -:SECURED_TARGET_NAME IN()

この改訂された条件により、指定したセキュア・ターゲット全体ですべての失敗したログイン・イベントの包括的なアラートが可能になります。