こんにちは。DB技術部のN.Hです。

コロナ禍で在宅勤務が普及しだし、セキュリティへの関心が更に高まっていますね。
本日はそれに絡めて、Oracleのセキュリティ機能についてお話したいと思います。

Oracle 11gまでは、必須監査、DBA監査、標準監査、FGA監査といった複数の監査機能が混在していましたが、Oracle 12cより、機能統合とパフォーマンス向上を目的とした統合監査が導入されました。Oracle 19cまでのデフォルトは、「従来型監査」と「統合監査」の両方を利用できる混合モードとなっており、（従来型監査を利用しない）完全な統合監査モードを利用する場合は明示的に有効化する必要があります。

そしてとうとう、Oracle 20cからは「統合監査以外は非推奨」となります。こうした流れからこの「統合監査」の必要性が更に高まることが予想されますので、今日はその統合監査の機能をご紹介しようと思います。

本稿のデモは、12cと19cの環境で動作確認をしています。
なお、前述の通り、デフォルトの混合モードでも統合監査機能は利用可能です。もし混合モードで下記の操作を試される場合は、パラメータaudit_trailがdbになっていることを事前に確認下さい。

ログオンを監査してみる（入門編）

 
さて、この統合監査は、重要なデータへのアクセスの監視を行うための機能です。
一見、難しそうに見えますが、簡単に設定できるように作られています。以下の2ステップだけです。

1．監査ポリシー（ルール）を作成する
2．監査ポリシーを有効にする

では、早速、ステップ1からやっていきましょう。

1．監査ポリシー（ルール）を作成する

ログオンを記録する監査ポリシーを作ってみます。ここでは、LOGON_POLという名前で作成してみます。

SQL> create audit policy LOGON_POL actions logon;

Audit policy created.

2．監査ポリシーを有効にする

監査ポリシーを作っただけでは、監査は有効になりませんので、SYSTEMユーザのログオンを監査してみます。BY句を指定しないと、全てのユーザが監査対象になります。

SQL> audit policy LOGON_POL by system;

Audit succeeded.

これで準備完了です。

では、きちんと監査情報が取得されるかを確認してみましょう。

2.で監査ポリシーを有効化した後のセッションから監査情報が取得されるため、まずSYSTEMユーザでログインを試行します。誤ったパスワードと、正しいパスワードの両方を実行しておきます。

SQL> conn system/password
ERROR:
ORA-01017: ユーザー名/パスワードが無効です。ログオンは拒否されました。

Warning: You are no longer connected to ORACLE.

SQL> conn system/*******
Connected.

それでは、いざ、監査情報の確認です。統合監査のレコードはUNIFIED_AUDIT_TRAILビューに格納されます。

SQL> select event_timestamp, dbusername, action_name, return_code, unified_audit_policies 
  2  from unified_audit_trail
  3  where unified_audit_policies = 'LOGON_POL'
  4  order by event_timestamp;

EVENT_TIMESTAMP          DBUSERNAME ACTION_NAM RETURN_CODE UNIFIED_AUDIT_POLICI
------------------------ ---------- ---------- ----------- --------------------
2020/06/09_18:14:59.74   SYSTEM     LOGON             1017 LOGON_POL
2020/06/09_18:15:09.35   SYSTEM     LOGON                0 LOGON_POL

UNIFIED_AUDIT_POLICIES列に監査に使用したポリシー名"LOGON_POL"が入っていることから、指定した監査ポリシーの情報が取得されていることがわかります。RETURN_CODE列には、アクションが成功した場合に"0"が格納されますので、1回目のログオン失敗と2回目のログオン成功がきちんと記録されていることが伺えます。

なお、今回は皆さんがイメージしやすいログオンの監査ポリシーを例としてつくってみましたが、データベースの初期構築時にログオンの失敗を監査する事前定義の監査ポリシー ORA_LOGON_FAILURES が作成されます。

どうでしょうか？思ったより簡単に設定できるなと感じられた方もいるのではないでしょうか？

ちなみに、失敗（成功）のみを監査したいといった場合は、ポリシーの有効化時に以下のように指定します。

audit policy 監査ポリシー名 whenever not successful; 
audit policy 監査ポリシー名 whenever successful;

 

機密データへの正規のアクセス以外を監査する（中級編）

 
では次に、機密データの入っているSECURE_DATA表への正規のアクセス以外を監査するポリシーUNAUTHORIZED_ACCESSを作成してみます。

正規のアクセス：
IP：192.168.72.1, ユーザ：OFFICIAL_USER, 操作：SELECT

SQL> create audit policy UNAUTHORIZED_ACCESS
  2    actions select on OFFICIAL_USER.SECURE_DATA
  3    when
  4      'SYS_CONTEXT(''USERENV'',''SESSION_USER'') <> ''OFFICIAL_USER''
  5      or SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') <> ''192.168.72.1'''
  6    evaluate per statement;

Audit policy created.
SQL> audit policy UNAUTHORIZED_ACCESS;

Audit succeeded.

ここで、正規のサーバから非正規のユーザ"TEST_USER"を使用した接続を試みた後の監査情報をみてみましょう。

SQL> select evet_timestamp, dbusername, unified_audit_policies, sql_text, authetication_type
  2  from unified_audit_trail
  3  where unified_audit_policies = 'UNAUTHORIZED_ACCESS';

EVENT_TIMESTAMP          DBUSERNAME UNIFIED_AUDIT_POLICI SQL_TEXT
------------------------ ---------- -------------------- ----------------------------------------
AUTHENTICATION_TYPE
----------------------------------------------------------------------------------------------------
2020/06/09_07:55:50.50   TEST_USER  UNAUTHORIZED_ACCESS  select * from official_user.secure_data
(TYPE=(DATABASE));(CLIENT ADDRESS=((ADDRESS=(PROTOCOL=tcp)(HOST=192.168.72.1)(PORT=51818))));

上記のように、IPアドレスのみ正しくとも、正規のユーザでのSELECTでなければ監査レコードに記録されることが確認できます。

関数を駆使して複雑な監査条件を設定する（上級編）

 
実際のシステムでは、様々な要件から条件が複雑になりがちです。
その複雑な条件を正規表現を使って指定したいところですが、統合監査の条件句では残念ながら正規表現を扱えません。そのようなときは、INSTR関数を用いて正規表現に近いこと実現できます。

以下は、"DEV"が1文字目から始まり、"USER"が5文字目から始まるユーザの監査情報を取得するUNAUTHORIZED_ACCESSを作成してみます。IPアドレスは192.168.72.1、操作はDEV_DATA表へUPDATEです。

SQL> create audit policy REGULAR_EXP_POL
  2    actions update on DEV_USER.DEV_DATA
  3    when
  4      'instr(SYS_CONTEXT(''USERENV'',''SESSION_USER''), ''DEV'') = 1
  5      and instr(SYS_CONTEXT(''USERENV'',''SESSION_USER''), ''USER'') = 5
  6      and SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') = ''192.168.72.1'''
  7    evaluate per statement;

Audit policy created.

SQL> audit policy REGULAR_EXP_POL;

Audit succeeded.
SQL> select EVENT_TIMESTAMP,DBUSERNAME,ACTION_NAME,UNIFIED_AUDIT_POLICIES
  2  from unified_audit_trail
  3  where UNIFIED_AUDIT_POLICIES = 'REGULAR_EXP_POL';

EVENT_TIMESTAMP          DBUSERNAME      ACTION_NAM UNIFIED_AUDIT_POLICI
------------------------ --------------- ---------- --------------------
2020/06/08_17:51:35.44   DEV_USER_TEST   UPDATE     REGULAR_EXP_POL
2020/06/08_17:51:35.52   DEVLUSER        UPDATE     REGULAR_EXP_POL
2020/06/08_17:52:16.65   DEV_USER        UPDATE     REGULAR_EXP_POL

 

設定は簡単だけど、運用には注意が必要

ここまで書いてきたように、
『統合監査では簡単に監査を始められ、複雑なポリシー作成もできる』
ということをご確認いただけたと思います。ただし、19cまでの統合監査では運用に注意が必要です。

例えば、次のような運用を考えます。

『夜間帯は性能への影響などを考えず、日中帯とは異なる監査ポリシーを有効化して監視を強化する』

この場合、統合監査の仕様が重要な懸念事項となります。

それは、統合監査ポリシーの変更は、現行のセッション、現在アクティブなセッションには反映されない[1]という仕様です。

つまり、上記の運用方針を守って統合監査ポリシーの有効化・無効化を正常に動作させたとしても、何者かが日中帯に接続し、そのまま夜間帯で作業を行った場合、夜間帯のみ有効な監査ポリシーでは監査ログを残せません。このような場合には、日中帯の統合監査ポリシーの厳格化、統合監査ポリシーの変更後にデータベースの再起動をするといった運用指針で対処することになります。

[1] Oracle Database 20cでは、統合監査ポリシーの変更は即時反映となるようです。
Oracle® Database 20c Database New Features
~Guide Unified Audit Policy Configuration Changes Effective Immediately~

いかがだったでしょうか。
Oracle DBの統合監査は、それほど難しくない、ということが伝わっていれば幸いです。Oracle DBには、今回紹介した統合監査以外にも様々なセキュリティ機能がありますので、ぜひ、試してみてください。