همانطور که می دانید، ثبت وقایع برای نسخه های قبل از اوراکل 12c، از طریق standard auditing امکان پذیر است. با کمک این شیوه از auditing، می توان تمامی عملیات کاربران حاضر در بانک اطلاعاتی را مانیتور نمود (البته به غیر از کاربرانی که با مجوز sysdba به بانک لاگین کرده اند.) این شیوه از auditing در کنار مزیتهای فراوانی که به همراه دارد، با محدودیتهایی هم روبروست، محدودیتهایی نظیر:

1.امکان دستکاری راحت audit record توسط کاربر sys

2.عدم ثبت وقایع کاربر sys در جدولی از بانک

3.عدم امکان auditing بر اساس role کاربران

4.عدم پارتیشن بندی پیش فرض جدول $aud و مشقتهای حذف بازه ای اطلاعات آن(delete + HWM)

5.عدم امکان auditing بر اساس مولفه هایی چون rman، datapump، sqlldr و …

6.عدم امکان auditing بر مبنای host name، ip address و …

و …

نکته: در محیطی که چند نفر مسئولیت پشتیبانی بانک را بر عهده دارند و بعضی از آنها از تسلط کافی برخوردار نیستند، ثبت وقایع برای کاربر sys می تواند مفید باشد البته دور زدن auditing برای فردی که از دانش کافی در این زمینه برخوردار است، به سادگی قابل انجام خواهد بود و برای کنترل چنین فردی، ناگزیر باید از ابزاری چون database vault استفاده کرد.

مثال زیر یکی دیگر از محدودیتهای standard auditing را نشان می دهد:

مثال: ثبت وقایع برای کاربران usef، ali، reza بر اساس سه مجوز drop any table، create any table، delete any table انجام شود:

SQL> audit delete any table,drop any table,create any table by usef;

Audit succeeded.

SQL> audit delete any table,drop any table,create any table by ali;

Audit succeeded.

SQL> audit delete any table,drop any table,create any table by reza;

Audit succeeded.

همانطور که می بینید، به تعداد هر کاربر، باید اسامی مجوزها تکرار شوند و امکان ایجاد یک گروه برای این سه مجوز وجود ندارد این شیوه از auditing، در یک محیط بزرگ و با تعداد بالای کاربر، با دشواریهایی همراه خواهد بود.

با آمدن اوراکل 12c، در زمینه auditing بهبودهایی حاصل شد و با ارائه قابلیتunified auditing ، بسیاری از محدودیتهای standard auditing برطرف شد. در این متن به بررسی این قابلیت جدید اوراکل، خواهیم پرداخت.

همانطور که از نام این ویژگی برمی اید، قرار است با کمک unified auditing، سطوح مختلف auditing از قبیل sys auditing، FGA auditing، standard auditing و … تنها در یک جدول ذخیره شوند.

با ارائه unified auditing، در دو زمینه performance و security ترمیمهایی صورت پذیرفت برای مثال، به جهت کارایی بیشتر، برخلاف standard auditing، وقایع ثبت شده بلافاصله بعد از اجرای دستور، به دیسک منتقل نخواهند شد و برای مدتی در SGA queue باقی خواهند ماند و در مدت زمان معین(حداقل هر سه ثانیه یکبار)، به دیسک منتقل می شوند البته با قبول این ریسک، که کرش کردن instance قبل از انتقال audit record به دیسک، سبب از دست رفتن این اطلاعات خواهد شد(برای این جنس اطلاعات از redo استفاده نمی شود).

مقدار و اندازه sga برای نگهداری audit recordها، با پارامتر unified_audit_sga_queue_size مشخص می شود که مقدار پیش فرض ان برابر با 1MB می باشد و حداکثر مقدار ان می تواند به 30MB برسد.

نکته 1:برای نوشتن اجباری اطلاعات از sga به دیسک، می توان از دستور زیر استفاده کرد:

SQL> execute dbms_audit_mgmt.flush_unified_audit_trail;

PL/SQL procedure successfully completed.

نکته 2: با اجرای بلاک زیر، unified auditing به حالت Immediate-write سوییچ خواهد کرد:

BEGIN

 DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(

  DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,

  DBMS_AUDIT_MGMT.AUDIT_TRAIL_WRITE_MODE,

  DBMS_AUDIT_MGMT.AUDIT_TRAIL_IMMEDIATE_WRITE);

END;

نکته 3: با کمک دو پارامتر مخفی unified_audit_flush_interval_ و unified_audit_flush_threshold_ می توان در مورد بازه زمانی انتقال audit recordها از sga به دیسک اعمال نظر کرد.

به عنوان مزیت دوم، به لحاظ امنیتی، برخلاف standard auditing، که در ان کاربر sys می توانست به راحتی اطلاعات جدول aud$ را دستکاری کند، امکان هرگونه تصرف در جدول مربوط به unified auditing که AUD$UNIFIED نام دارد(اوراکل 12cR2)، به راحتی شدنی نخواهد بود و به صورت رسمی و بر اساس مستندات، صرفا باید اطلاعات auditing را با کمک بسته dbms_audit_mgmt پاک کرد و هرگونه تلاش برای حذف دستی این جدول و یا پارتیشنهای ان، با خطا مواجه خواهد شد:

SQL>  truncate table audsys.AUD$UNIFIED;

ORA-46385: DML and DDL operations are not allowed on table “AUDSYS”.”AUD$UNIFIED”.

SQL> drop table audsys.aud$unified;

ORA-46385: DML and DDL operations are not allowed on table “AUDSYS”.”AUD$UNIFIED”.

SQL> delete audsys.aud$unified;

ORA-46385: DML and DDL operations are not allowed on table “AUDSYS”.”AUD$UNIFIED”.

SQL>  ALTER TABLE AUDSYS.AUD$UNIFIED DROP PARTITION SYS_P924;

ORA-46385: DML and DDL operations are not allowed on table “AUDSYS”.”AUD$UNIFIED”.

همچنین مالک جدول AUD$UNIFIED کاربری به نام AUDSYS می باشد که به صورت پیش فرض در وضیعت lock قرار دارد و امکان لاگین به ان و یا حذف ان، به روشهای متداول، وجود ندارد:

 SQL> alter user audsys account unlock;

User altered.

SQL> alter user audsys identified by a;

User altered.

SQL> conn audsys/a

ORA-46370: cannot connect as AUDSYS user

SQL> drop user audsys cascade;

ORA-28050: specified user or role cannot be dropped

نکته:بصورت پیش فرض، جدول aud$unified در sysaux ذخیره خواهد شد و با اجرای بلاک زیر، می توان tablespace دیگری را برای پارتیشنهای جدید این جدول، تعیین کرد(پارتیشنهای قبلی به tablespace جدید منتقل نخواهند شد):

begin

  DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(

   audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,

   audit_trail_location_value => tablespace_name);

end;

با همه مزیتهایی که unified auditing به همراه دارد، با ایجاد بانک اطلاعاتی در نسخه 12c، باز هم standard auditing فعال خواهد ماند و به لحاظ auditing، بانک در حالت Mixed auditing قرار می گیرد به این معنی که در کنار فعال بودن standard auditing (پارامتر audit_trail برابر با db خواهد بود)، unified auditing هم دو audit policy فعال به نامهای ORA_SECURECONFIG و ORA_LOGON_FAILURES خواهد داشت(تاکید می شود در صورتی که audit_trail<>none باشد).

این قاعده برای بانکهایی که به نسخه 12c ارتقا یافته اند، صادق نخواهد بود و unified auditing در این سیستمها، به صورت کلی غیرفعال می باشد ولی می توان audit policy مورد نظر را به صورت دستی ایجاد و یا فعال کرد.

برای مشاهده اسامی و مشخصات audit policyها می توان از ویوی DBA_AUDIT_POLICIES استفاده کرد و ویوی AUDIT_UNIFIED_ENABLED_POLICIES هم تنها audit policyهای فعال را نمایش خواهد داد:

SQL>  select distinct policy_name from AUDIT_UNIFIED_ENABLED_POLICIES;

ORA_LOGON_FAILURES

ORA_SECURECONFIG

***با کمک پارامتر مخفی unified_audit_policy_disabled_ می توان Defualt audit policyها را غیرفعال کرد.

در حالت Mixed auditing، unified auditing کماکان به مقدار پارامتر audit_trail وابسته خواهد بود و با تنظیم این پارامتر به مقدار none، این ویژگی هم عملا از کار خواهد افتاد.

در صورتی که قصد داریم به صورت کامل standard auditing را کنار گذاشته و صرفا از unified auditing استفاده کنیم، باید با اجرای اسکریپتی، unified auditing را فعال کنیم.

برای مشاهده وضیعت فعلی این ویژگی، میتوانیم از دستور زیر استفاده کنیم:

SELECT VALUE FROM V$OPTION WHERE PARAMETER = ‘Unified Auditing’;

FALSE

همانطور که می بینید، به طور پیش فرض، Unified Auditing غیرفعال می باشد برای فعال کردن این ویژگی، ابتدا بهتر است بانک را از کار انداخت:

[oracle@dbhost ~]$ ps –eaf|grep pmon

oracle    8337     1  0 11:36 ?        00:00:01 ora_pmon_noncdb

oracle   16273     1  0 Jun23 ?        00:03:34 ora_pmon_stb

oracle   23219     1  0 Jul19 ?        00:00:15 ora_pmon_cdb18c2

[oracle@dbhost ~]$ kill -9 8337 23219 16273

و سپس اسکریپت زیر را اجرا نمود:

[oracle@dbhost ~]$ cd $ORACLE_HOME/rdbms/lib

[oracle@dbhost lib]$ make –f ins_rdbms.mk uniaud_on ioracle

با اجرای این اسکریپت، قابلیت Unified Auditing فعال خواهد شد:

SELECT VALUE FROM V$OPTION WHERE PARAMETER = ‘Unified Auditing’;

TRUE

با فعال کردن unified auditing، عملا امکان استفاده از standard auditing از بین خواهد رفت و تنظیم پارامترهای زیر، دیگر اثر سابق را نخواهد داشت:

audit_trail – audit_file_dest – audit_sys_operations – audit_syslog_level

به اصطلاح بانک از حالت Mixed auditing به Pure auditing منتقل خواهد شد.

***ساختار auditing در حالت Mixed auditing:

***ساختار auditing در حالت Pure auditing:

***ساختار unified auditing در اوراکل 12c:

همچنین در جدول زیر،  اثرگذاری پارامترهای auditing را در دو حالت Mixed و Pure مرور می کنیم:

نکته: برای غیرفعال کردن unified Auditing باید از دستور زیر استفاده کرد:

[oracle@dbhost ~]$ cd $ORACLE_HOME/rdbms/lib

[oracle@dbhost lib]$ make -f ins_rdbms.mk uniaud_off ioracle ORACLE_HOME=$ORACLE_HOME

با کمک unified auditing می توان audit policyهای متنوعی را در چهار سطح Privilege، Role، Action و Component ایجاد نمود که در ادامه به بررسی هر کدام از انها، خواهیم پرداخت.

Privilege Audit Policy

در این سطح می توان auditing را برای system privilegeهای مشخصی فعال کرد.

نکته: برای مشاهده لیست system privilageها، می توان از جدول system_privilege_map استفاده کرد.

برای مثال، با ایجاد و فعال کردن audit policy زیر، هر دستوری که برای اجرا شدن، نیاز به استفاده یکی از مجوزهای create any table و یا drop any table را داشته باشد، audit خواهد شد:

SQL> CREATE AUDIT POLICY audit_privs PRIVILEGES create any table,drop any table;

Audit policy created.

نکته: کاربری که نقش AUDIT_ADMIN را دارد، امکان ساخت audit policy را هم خواهد داشت همچنین برای دسترسی به ویوهای مربوط به unified auditing، نقش AUDIT_VIEWER مکفی خواهد بود.

بعد از ایجاد audit policy، با دستور زیر، آن را فعال می کنیم:

SQL> AUDIT POLICY audit_privs;

Audit succeeded.

با این دستور، هر کاربری که از این دو مجوز استفاده کرده باشد، اطلاعات ان ثبت خواهد شد:

SQL> create user usef identified by a;

User created.

SQL> grant create any table,connect to usef;

Grant succeeded.

SQL> conn usef/a

Connected.

SQL> create table vahid.tbl1(id number);

Table created.

اطلاعات این وقایع، با کمک ویوی unified_audit_trail قابل رویت می باشد:

SQL> select dbusername,client_program_name,action_name,unified_audit_policies from unified_audit_trail where unified_audit_policies like ‘%AUDIT_PRIVS%’;

در مثال قبلی، ثبت وقایع برای همه کاربران انجام می شد علاوه بر این حالت، می توان یک audit policy را  صرفا برای یک یا چند کاربر مشخص، فعال کرد:

SQL> AUDIT POLICY audit_privs by usef,vahid;

Audit succeeded.

همچنین می توان یک یا چند کاربر را از این policy مستثنی نمود:

SQL> AUDIT POLICY audit_privs EXCEPT usef;

Audit succeeded.

در audit policy، همانند standard auditing، می توان ثبت وقایع را به موفقیت(successful) و یا عدم موفقیت(not successful) عمل انجام شده، منوط کرد که در حالت پیش فرض، هر دوی انها با کمک audit policy پوشش داده خواهند شد و همچنین امکان تعیین هر کدام از انها، در زمان اجرای دستور audit policy، وجود دارد برای مثال، در دستور زیر، تنها در صورتی که کاربر usef موفق به انجام کاری نشود، لاگ مربوط به ان، ثبت خواهد شد:

SQL> audit policy aud_pol by usef WHENEVER NOT SUCCESSFUL;

Audit succeeded.

در زمان ساخت audit policy می توان با کمک خصیصه هایِ application context از پیش ساخته اوراکل، که USERENV نام دارد، شرطهایی را در انتهای دستور اضافه کرد و محدودیتهایی را به این audit policy اعمال کرد. برای مثال، با ایجاد policy زیر، استفاده از دو مجوز drop any table و create any table توسط هر کاربری غیر از usef، در aud$unified ثبت خواهد شد:

SQL> CREATE AUDIT POLICY audit_privs

PRIVILEGES create any table,drop any table

WHEN ‘SYS_CONTEXT(”USERENV”,”SESSION_USER”)!=”USEF”’

EVALUATE PER STATEMENT;

Audit policy created.

در زمان استفاده از standard auditing، منها کردن applicationها از auditing، کار اسانی نبود. انجام این کار با کمک unified auditing به سادگی قابل انجام است:

CREATE AUDIT POLICY audit_privs_machine

PRIVILEGES create any table,drop any table

WHEN ‘SYS_CONTEXT (”USERENV”, ”HOST”) NOT IN (”5908003”)’

EVALUATE PER STATEMENT;

قبلا اشاره شد که همراه با ایجاد بانک اطلاعاتی در نسخه 12c، چند privilege audit policy هم ایجاد خواهند شد که یکی از آنها ORA_SECURECONFIG نام دارد که بطور پیش فرض، قوانین ان برای همه کاربران فعال است بطوریکه با استفاده از این audit policy، بسیاری از کارهای کاربر sys هم ردگیری خواهد شد.مثال زیر را ببینید:

مثال: کاربر sys قصد دارد تا دستور begin backup را اجرا کند:

SQL> conn /as sysdba

Connected.

SQL> alter database begin backup;

ORA-01123: cannot start online backup; media recovery not enabled

با اجرای ناموفق دستور alter database begin backup توسط کاربر sys، عمل انجام شده ثبت خواهد شد و با مراجعه به ویوی unified_audit_policies رکورد مربوطه، قابل رویت می باشد:

برای حذف یک audit policy در حال استفاده، ابتدا باید ان را noaudit کرد:

SQL> noaudit policy audit_privs;

Noaudit succeeded.

و سپس با کمک دستور زیر، اقدام به حذف ان نمود:

SQL> drop audit policy audit_privs;

Audit Policy dropped.

Role Audit Policy

برای فعال کردن مانیتورینگ در سطح system privilegeهای یک role، می توان از role audit policy استفاده کرد. همچنین می توان تمامی افرادی که یک role مشخصی دارند، را نظارت کرد.

برای مثال، در دستور زیر، با ایجاد یک audit policy، قصد داریم تا تمامی system privilegeهایی که نقش dba به همراه دارد را مانیتور کنیم:

SQL> CREATE AUDIT POLICY audit_role ROLE DBA;

Audit policy created.

نکته: برای مشاهده لیست مجوزهای سیستمی مرتبط با نقش dba، می توان از دستور زیر استفاده کرد:

select * from dba_sys_privs where grantee=’DBA’;

audit policy ایجاد شده را برای کاربر usef فعال می کنیم:

SQL> create user usef identified by a ;

User created.

SQL> audit policy audit_role by usef;

Audit succeeded.

با اهدای مجوز create session و drop any table به کاربر usef، جدولی را حذف می کنیم:

SQL> create user usef identified by a ;

User created.

SQL> grant create session,drop any table to usef;

Grant succeeded.

SQL> conn usef/a

Connected.

SQL> drop table vahid.tbl1;

Table dropped.

در این صورت، اطلاعات زیر در ویوی unified_audit_trail قابل مشاهده می باشند:

select dbusername,client_program_name,action_name,unified_audit_policies from unified_audit_trail where unified_audit_policies like ‘%AUDIT_ROL%’;

این اطلاعات نشان می دهد که کاربر usef، با استفاده از مجوز drop any table، که یکی از مجوزهای سیستمی نقش dba می باشد، توانسته است جدولی را حذف کند.

حال اگر بخواهیم تمامی وقایع مربوط به کاربرانی که نقش dba دارند، ثبت شود، می توانیم از دستور زیر استفاده کنیم:

SQL> audit policy audit_role by users with granted roles DBA;

Audit succeeded.

با این کار، استفاده از مجوز drop any table توسط کاربر usef، از طریق این audit policy، ثبت نخواهد شد:

-قبل از انجام تست، لاگهای موجود را حذف می کنیم:

SQL> exec dbms_audit_mgmt.clean_audit_trail(audit_trail_type=>dbms_audit_mgmt.audit_trail_unified,use_last_arch_timestamp=>false);

 PL/SQL procedure successfully completed

همچنین audit policy قبلی که audit_role نام داشت را غیرفعال می کنیم:

SQL> NOAUDIT POLICY audit_role by usef;

Noaudit succeeded.

کاربر usef جدولی که مالک ان کاربر دیگری می باشد را حذف می کند:

SQL> conn usef/a

Connected.

SQL> drop table vahid.tbl2;

Table dropped.

هیچ رکوردی به این جهت ثبت نشده است:

SQL> conn /as sysdba

Connected.

SQL> select dbusername,client_program_name,action_name,unified_audit_policies from unified_audit_trail where unified_audit_policies like ‘%AUDIT_ROL%’;

no rows selected

در همین حال، اگر کاربر usef تنها نقش dba را دارا باشد و با کمک مجوزهای سیستمی این نقش، جدولی را حذف کند، اطلاعات مربوط به ان، ثبت خواهد شد:

SQL>  revoke drop any table from usef;

Revoke succeeded.

SQL> grant dba to usef;

Grant succeeded.

SQL> conn usef/a

Connected.

SQL> drop table vahid.tbl3;

Table dropped.

select dbusername,client_program_name,action_name,unified_audit_policies from unified_audit_trail where unified_audit_policies like ‘%AUDIT_ROL%’;

برای حذف کردن roleای از این audit policy و یا اضافه کردن یک role به ان، می توان از دستور زیر استفاده کرد:

SQL>  alter audit policy audit_role add role connect;

Audit policy altered.

SQL>  alter audit policy audit_role drop role dba;

Audit policy altered.

همچنین برای حذف کامل audit policy ایجاد شده، ابتدا باید ان را غیرفعال کرد:

SQL> noaudit  policy audit_role by users with granted roles DBA;

Noaudit succeeded.

و سپس با دستور زیر، این audit policy را حذف نمود:

SQL> drop audit  policy audit_role ;

Audit Policy dropped.

Action Audit Policy

در دو مورد قبلی، audit policyها صرفا به system privilege و roleها مربوط می شدند حال با کمک action audit policy امکان auditing کاربران در سطح object هم مهیا خواهد شد بعبارتی؛ در این سطح می توان قوانینی را وضع کرد تا انجام عملیات مشخص بر روی یک یا چند object، ثبت و audit شوند.

برای مشاهده لیست دستورهای قابل audit در این قسمت، می توان از ویوی auditable_system_actions، کمک گرفت.

در ادامه با دو مثال، AUDIT POLICYای را در این زمینه ایجاد خواهیم کرد.

مثال 1: با ایجاد audit policy زیر، قصد داریم حذف اطلاعات جدول tbl1 را مانیتور کنیم:

SQL> create audit policy action_pol actions delete on vahid.tbl1;

Audit policy created.

SQL> audit policy action_pol by usef;

Audit succeeded.

برای تست، جدول tbl1 را یکبار بروزرسانی می کنیم:

SQL> conn usef/a

SQL> update vahid.tbl1 set name=’ali’ where name is not null;

5 rows updated.

با بروزرسانی این جدول توسط کاربر usef، اطلاعاتی در aud$unified ثبت نخواهد شد:

select dbusername,client_program_name,action_name,unified_audit_policies from unified_audit_trail where unified_audit_policies like ‘%ACTION_POL%’;

no rows selected

اما با اجرای دستور delete توسط کاربر usef، اطلاعات مربوط به ان ثبت خواهد شد:

SQL> conn usef/a

Connected.

SQL> delete vahid.tbl1;

5 rows deleted.

SQL> select dbusername,client_program_name,action_name,unified_audit_policies from unified_audit_trail where unified_audit_policies like ‘%ACTION_POL%’;

مثال 2: با ایجاد audit policy زیر، تمامی دستورات selectای که توسط کاربر usef اجرا می شوند، audit خواهند شد:

SQL> CREATE AUDIT POLICY ALL_SELECT_ACTION

ACTIONS SELECT

WHEN ‘SYS_CONTEXT(”USERENV”,”SESSION_USER”)=”USEF”’

EVALUATE PER SESSION;

Audit policy created.

Component Audit Policy

یکی دیگر از قابلیتهای audit policy، ثبت وقایع بر مبنای componentها می باشد با کمکAudit policy component می توان componentهای زیر را audit نمود:

Data Pump

SQL*Loader Direct Path

Label Security

Real Application Security

Database Vault

برای مثال، با ایجاد audit policy زیر، هر بار اجرای دستور impdp، ثبت خواهد شد:

SQL> create audit policy comp_policy ACTIONS  COMPONENT=datapump import;

Audit policy created.

SQL> audit policy comp_policy;

Audit succeeded.

با فعال شدن این audit policy، هر کاربری دستور impdp را اجرا کند، رکوردی به این جهت در aud$unified اضافه خواهد شد:

[oracle@dbhost ~]$ impdp usef/a directory=drm tables=usef.tbl

Import: Release 18.0.0.0.0 – Production on Wed Aug 8 18:30:02 2018 Version 18.1.0.0.0

Copyright © 1982, 2018, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 – Production

Master table “USEF”.”SYS_IMPORT_TABLE_01” successfully loaded/unloaded

Starting “USEF”.”SYS_IMPORT_TABLE_01”:  usef/******** directory=drm tables=usef.tbl

Processing object type TABLE_EXPORT/TABLE/TABLE

Processing object type TABLE_EXPORT/TABLE/TABLE_DATA

. . imported “USEF”.”TBL”                                19.99 KB       4 rows

Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER

Job “USEF”.”SYS_IMPORT_TABLE_01” successfully completed at Wed Aug 8 18:30:23 2018 elapsed 0 00:00:20

با مشاهده اطلاعات ویوی unified_audit_trail، رکورد مورد نظر را ملاحظه خواهیم کرد:

select p.audit_type,p.action_name,unified_audit_policies from unified_audit_trail p where p.unified_audit_policies=’COMP_POLICY’;

نکته 1: برای audit کردن هر دو عمل export و import، می توان از عبارت ALL استفاده کرد.

نکته 2: لیست componentها به همراه مولفه های مورد استفاده انها را می توان در ویوی auditable_system_actions مشاهده کرد.

ایجاد audit policy به صورت ترکیبی

ملاحظه کردید که ایجاد یک audit policy درچهار سطح role، privilege، action و component امکان پذیر می باشد. علاوه بر ایجاد audit policy در این چهار سطح، امکان ایجاد یک audit policy از ترکیب این چهار سطح هم وجود دارد. قبل از مشاهده یک مثال در این زمینه، syntax ایجاد audit policy را مرور می کنیم:

CREATE AUDIT POLICY policy_name

{ {privilege_audit_clause [action_audit_clause ] [role_audit_clause ]}

| { action_audit_clause [role_audit_clause ] }

| { role_audit_clause }

}

[WHEN audit_condition EVALUATE PER {STATEMENT|SESSION|INSTANCE}]

[CONTAINER = {CURRENT | ALL}];

مثال:

CREATE AUDIT POLICY ALL_POLICY

  Privileges  drop any table

  Actions   CREATE TABLESPACE, CREATE USER

  Actions   Component = DataPump  EXPORT, IMPORT

  ROLE connect;

حذف اطلاعات قدیمی unified audtinig

برای خالی کردن و یا اصطلاحا purge کردن رکوردهای unified audit trail، باید از بسته DBMS_AUDIT_MGMT استفاده کرد. برای این کار، ابتدا باید با دستور زیر مشخص کرد که تا چه بازه زمانی ای از اطلاعات قبلی جدول aud$unified، در هر بار اجرای دستور CLEAN_AUDIT_TRAIL(به شکلی که در دستور بعدی خواهد امد)، پاک شوند:

exec DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP (AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, LAST_ARCHIVE_TIME => sysdate-30);

 ***برای مشاهده تنظیمات جاری، می توان از ویوی dba_audit_mgmt_last_arch_ts کمک گرفت.

با اجرای دستور زیر، پالیسی بالا اعمال خواهد شد:

exec DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, USE_LAST_ARCH_TIMESTAMP => TRUE);

با ایجاد یک جاب، اجرای این بسته، به صورت اتوماتیک و در بازه های زمانی معین انجام خواهد شد. بلاک زیر، این job را ایجاد خواهد کرد(هر ده ساعت یکبار، جاب اجرا خواهد شد):

begin

DBMS_AUDIT_MGMT.CREATE_PURGE_JOB(

   audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,

   audit_trail_purge_interval => 10,

   audit_trail_purge_name =>’Trail_PurgeJob’

   );

end;

برای مشاهده لیست جابهای ایجاد شده با کمک بسته DBMS_AUDIT_MGMT، می توان از ویوی dba_audit_mgmt_cleanup_jobs استفاده کرد.

select * from dba_audit_mgmt_cleanup_jobs;

همچنین برای حذف کامل اطلاعات جاری جدول aud$unified می توان از دستور زیر استفاده کرد:

SQL> exec dbms_audit_mgmt.clean_audit_trail(audit_trail_type=>dbms_audit_mgmt.audit_trail_unified,use_last_arch_timestamp=>false);

PL/SQL procedure successfully completed

با فعال کردن تریس در این session، عملیات صورت گرفته در پس زمینه اجرای این دستور را مشاهده خواهیم کرد:

 PARSING IN CURSOR #139958736371168 len=60 dep=2 uid=0 oct=26 lid=0 tim=4849776214695 hv=3994280521 ad=’6a69f238′ sqlid=’405ckmbr17sk9′

LOCK TABLE “AUDSYS”.”AUD$UNIFIED” IN EXCLUSIVE MODE  NOWAIT

PARSING IN CURSOR #139958718667408 len=33 dep=1 uid=0 oct=85 lid=0 tim=4849776216583 hv=2585660027 ad=’6a6a7058′ sqlid=’3k0xk3ud1w2mv’

TRUNCATE TABLE AUDSYS.AUD$UNIFIED

PARSING IN CURSOR #139958718667408 len=129 dep=1 uid=0 oct=3 lid=0 tim=4849776524816 hv=1106348162 ad=’6a6a5900′ sqlid=’88rbjp50z3242′

select partition_name from dba_tab_partitions where table_owner=’AUDSYS’ and table_name=’AUD$UNIFIED’ order by partition_position

PARSING IN CURSOR #139958717620960 len=80 dep=1 uid=0 oct=170 lid=0 tim=4849776528727 hv=3195453465 ad=’6a616900′ sqlid=’6cfytdqz7dh0t’

CALL DBMS_PDB_EXEC_SQL(‘ALTER TABLE AUDSYS.AUD$UNIFIED DROP PARTITION SYS_P917’)

PARSING IN CURSOR #139958715953664 len=54 dep=2 uid=0 oct=15 lid=0 tim=4849776531753 hv=4209168174 ad=’6a611420′ sqlid=’29atv2zxf5mtf’

ALTER TABLE AUDSYS.AUD$UNIFIED DROP PARTITION SYS_P917

PARSING IN CURSOR #139958715953664 len=80 dep=1 uid=0 oct=170 lid=0 tim=4849776637216 hv=1874954663 ad=’6aa4b7a8′ sqlid=’fxc3169rw32d7′

CALL DBMS_PDB_EXEC_SQL(‘ALTER TABLE AUDSYS.AUD$UNIFIED DROP PARTITION SYS_P924’)