مراقبة قواعد البيانات هي جزء من أمن قواعد البيانات ومن خلال عملية المراقبة نستطيع أن نجد العديد من الإجابات لبعض الأمور التي قد تبقى غامضة بدون عملية المراقبة.

يمكن تقسيم عملية المراقبة إلى ثلاثة أنواع:-

1-  Standard Database Auditing:

وهو متابعة وحفظ المعلومات عن عمليات الاتصال والفصل بقاعدة البيانات، وأيضا متابعة استخدام (Object Privileges and System Privileges)

داخل قاعدة البيانات، مثل إنشاء وحذف واستعلام وتعديل وغيرها من العمليات. 

2 - Value-based auditing: في النوع الأول نتابع عمليات الاتصال وكذلك نتابع العمليات داخل قاعدة البيانات ولكن قد نحتاج إلى حفظ القيم التي يتم تغييرها في قاعدة البيانات.

3 - Fine-grained auditing: هذا النوع لحفظ جمل SQL التي تم تنفيذها في قاعدة البيانات.

ولكن قبل الدخول في تفاصيل أنواع المراقبة يجب ملاحظة أنه يجب تهيئة قاعدة بيانات Oracle 10g قبل البدء في عمليات المراقبة باستخدام متغير AUDIT_TRAIL والذي يأخذ إحدى القيم التالية: 

1- NONE: هذا يعني أن قاعدة البيانات غير جاهزة لعملية المراقبة.

2- DB: هذا يعني أن معلومات المراقبة محفوظة في قاعدة البيانات في جداول تابعة للمستخدم SYS.

3- OS: هذا يعني أن معلومات المراقبة محفوظة على مستوى نظام التشغيل. إذا كنا نعمل على بيئة Windows، يتم حفظ البيانات في سجل الأحداث. إذا كنا نعمل على UNIX أو LINUX، يتم تخزين المعلومات كملفات في المسار المحدد في متغير AUDIT_FILE_DEST.

يدعم Oracle 10g أنواعًا مختلفة من المراقبة، حتى يتمكن مسؤول قاعدة البيانات من مراقبة كل ما يحدث في قاعدة البيانات. تخيل معي حجم البيانات المخزنة إذا قمنا بمراقبة كل ما يحدث في قاعدة البيانات. لا شك أن هذا سيؤثر سلبًا على أداء قاعدة البيانات، لذلك من الضروري أن يركز مسؤول قاعدة البيانات على المراقبة حتى نراقب ما نحتاجه دون مراقبة زائدة. على سبيل المثال، إذا أردنا مراقبة بعض الجداول، فمن الأفضل التركيز على نوع العمليات التي يجب مراقبتها، مثل الحذف فقط. ولكن إذا قمت بمراقبة كل ما يحدث للجداول، فسيؤثر ذلك على أداء قاعدة البيانات.

سيتم مراقبة الاستعلامات والتعديلات والحذف وما إلى ذلك. لذلك، فإن التركيز مهم في عملية المراقبة.

أول شيء يجب علينا فعله هو تهيئة قاعدة البيانات عن طريق تغيير قيمة المتغير AUDIT_TRAIL من القيمة NONE إلى إحدى القيم التالية (OS أو DB)

لنفترض هنا أننا نريد تخزين معلومات المراقبة داخل قاعدة البيانات، لذلك نختار القيمة DB.

ولكن قبل ذلك، نتأكد من المتغير AUDIT_TRAIL

SHOW PARAMETER AUDIT_TRAIL; 

نقوم بتحويل قيمة المتغير AUDIT_TRAIL إلى القيمة DB، مع الأخذ بعين الاعتبار أن هذا المتغير ليس تلقائي، أي أنه يتطلب إغلاق وفتح قاعدة البيانات حتى تتأثر قيمة المتغير.

ALTER SYSTEM SET AUDIT_TRAIL=DB SCOPE=SPFILE; 

ثم نقوم بإغلاق وفتح قاعدة البيانات والتحقق من قيمة المتغير.

Standard Database Auditing -1:

كما ذكرنا سابقا يركز هذا النوع من المراقبة على مراقبة عملية اتصال قاعدة البيانات وكذلك (System Privileges and Object Privileges).

كما يجب ملاحظة وجود خيارين أثناء عملية المراقبة (BY ACCESS & BY SESSION).

BY SESSION: يعني تخزين حقل واحد من المعلومات أثناء عمليات المراقبة لنوع معين من العمليات لكل SESSION. ولتوضيح الرؤية بشكل أكبر، لنفترض أننا راقبنا عملية التعديل

على جداول مستخدم معين، لنفترض أنه X. فتح أحد المستخدمين SESSION واستخدم هذه SESSION لتعديل 5 جداول تابعة للمستخدم X.

ستقوم عملية المراقبة بتخزين حقل واحد فقط لعملية التعديل طالما أنه قام بالتعديل بنفس SESSION، بمعنى آخر فهو يعادل عبارة GROUP BY SESSIION.

BY ACCESS : يمكن أخذ نفس المثال السابق ولكن هنا سيتم تخزين 5 حقول كل حقل هو عملية التعديل التي حدثت لكل جدول.

لا شك أن خيار BY SESSION قد لا يكون كافيا في بعض الأحيان لمعرفة تفاصيل معلومات المراقبة لذا قد نلجأ لخيار BY ACCESS والذي يوفر تفاصيل أكثر ولكنه بالطبع يزيد من عمليات تخزين المعلومات وفي هذا النوع من المراقبة كما ذكرنا فإن أفضل شيء هو عملية التركيز والتركيز يكون بتحديد المستخدم وكذلك بتحديد نجاح أو فشل العملية (SUCCESSFUL OR NOT SUCCESSFUL). يحتوي هذا النوع من المراقبة Standard Database Auditing

 على أقسام فرعية:-

• SESSION AUDITING:

وهو جزء من النوع الأول من المراقبة Standard Database Auditing، حيث يتم مراقبة عمليات الاتصال والانقطاع بقاعدة البيانات، ومن الممكن التركيز على تحديد المستخدم الذي نريد مراقبة عمليات اتصاله، ومن الممكن أيضًا متابعة جميع المستخدمين باستخدام أمر AUDIT SESSION، ومن الممكن أيضًا التركيز على تحديد عملية نجاح أو فشل عملية الاتصال.

على افتراض أننا نريد مراقبة جميع عمليات الاتصال والانقطاع الناجحة للمستخدم TEST ولأننا نريد معرفة وقت الاتصال والانقطاع، فمن الأفضل استخدام خيار ACCESS.

AUDIT SESSION BY TEST BY ACCESS WHENEVER SUCCESSFUL; 

ماذا لو قام المستخدم TEST بالاتصال بقاعدة البيانات؟

الآن يمكن لمسؤول قاعدة البيانات رؤية معلومات حول الاتصال المذكور أعلاه

SELECT SERNAME,TERMINAL,ACTION_NAME,EXTENDED_TIMESTAMP FROM DBA_AUDIT_SESSION; 

ستجد أنه يظهر لمسؤول قاعدة البيانات أن المستخدم TEST قد اتصل بقاعدة البيانات في التاريخ والوقت المحددين بواسطة جهاز NBS. يمكنك أيضًا عرض معلومات أخرى حول اسم مستخدم الجهاز ومعلومات أخرى.

ماذا لو انقطع اتصال المستخدم TEST؟ بالطبع، ستظهر معلومات إضافية لمسؤول قاعدة البيانات.

SELECT USERNAME,TERMINAL,ACTION_NAME,TO_CHAR(EXTENDED_TIM ESTAMP,'DD-MM-YYYY:HH-MI- SS'),TO_CHAR(LOGOFF_TIME,'DD-MM-YYYY:HH-MI-SS') FROM DBA_AUDIT_SESSION; 

الآن يظهر لمسؤول قاعدة البيانات أن المستخدم TEST قد انقطع اتصاله بقاعدة البيانات في الوقت المحدد.

يمكنك أيضًا الاستعلام عن معلومات الاتصال والانقطاع بقاعدة البيانات عبر (DBA_AUDIT_TRAIL).

إذا كانت معلومات الاتصال والانقطاع بقاعدة البيانات متوفرة في كل من (DBA_AUDIT_TRAIL & DBA_AUDIT_SESSION).

يمكن لمسؤول قاعدة البيانات الاستعلام عن خيارات المراقبة التي قام بتكوينها في قاعدة البيانات من خلال:

DBA_OBJ_AUDIT_OPTS

DBA_STMT_AUDIT_OPTS

DBA_PRIV_AUDIT_OPTS

SELECT USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE FROM DBA_STMT_AUDIT_OPTS; 

بالطبع يمكن إلغاء عملية المراقبة، فإذا أردنا إلغاء عملية مراقبة اتصال المستخدم TEST التي قمنا بمراقبتها مسبقًا.

NOAUDIT SESSION BY TEST;

الآن إذا قمنا بإجراء استعلام لعرض خيارات المراقبة التي قمنا بتكوينها، فلن نجد خيار مراقبة اتصال المستخدم TEST.

• SQL STATEMENT AUDITING:

تخيل معي أن مسؤول قاعدة البيانات يريد مراقبة عمليات DDL مثل إنشاء أو حذف جدول. في هذا النوع من المراقبة يمكن أن يكون التركيز على تحديد المستخدم وأيضا على نجاح أو فشل العملية.

ولكن هذا في إطار ما يملكه المستخدم. على سبيل المثال، إذا قام مستخدم بإنشاء جدول في SCHEMA لمستخدم آخر، فإن هذا النوع من المراقبة يندرج تحت ما يسمى بـ AUDITING PRIVILEGE SYSTEM، والذي سنناقشه لاحقًا، ولكن هنا فقط في إطار ما يملكه المستخدم. لنفترض أننا نريد مراقبة عملية إنشاء الجداول بواسطة المستخدم TEST داخل مساحته، أي في نفس SCHEMA.

AUDIT CREATE TABLE BY TEST BY ACCESS; 

ماذا لو قام المستخدم TEST الآن بإنشاء جدول؟

CREATE TABLE USER_MASTER (USER_NO NUMBER(٥),USER_NAME VARCHAR٢(٠٤),CONSTRAINT PK_USER_NO PRIMARY KEY(USER_NO)); 

سيتم عرض المعلومات لمسؤول قاعدة البيانات.

SELECT USERNAME,OWNER,TO_CHAR(TIMESTAMP,'DD-MM- YYYY:HH-MI-SS'),OBJ_NAME,ACTION_NAME FROM DBA_AUDIT_TRAIL WHERE OWNER='TEST'; 

على سبيل المثال، إذا قام المستخدم TEST بإنشاء جدول في SCHEMA آخر، فلن توفر خيارات المراقبة أعلاه أي معلومات ما لم نراقب إذن TABLE ANY CREATE، والذي سنناقشه في الخطوة التالية.

يمكن الاستعلام عن الخيارات التي قمنا بتكوينها لمراقبة SQL STATEMENT من خلال:

DBA_STMT_AUDIT_OPTS

DBA_PRIV_AUDIT_OPTS

يمكن إلغاء المراقبة من خلال:

NOAUDIT CREATE TABLE BY TEST; 

• SYSTEM PRIVILEGE AUDITING:

هذا لمراقبة عمليات استخدام امتيازات SYSTEM PRIVILEGES داخل قاعدة البيانات، على سبيل المثال امتياز CREATE ANY TABLE. بالطبع، يمكن التركيز على عملية مراقبة الامتيازات من خلال مستخدم معين، وكذلك من خلال نجاح أو فشل العملية. في الأصل، يتم تخزين عمليات مراقبة امتيازات SYSTEM PRIVILEGES كحقل لكل عملية، من أجل استخدام خيار BY ACCESS كوضع. بشكل افتراضي، ولكن بالطبع يمكن استخدام خيار SESSION BY لتقليل كمية البيانات المخزنة، بحيث يتم تخزين حقل واحد لكل SESSION استخدمت الإذن المتحكم فيه. لنفترض أننا نريد مراقبة إذن TABLE ANY CREATE للمستخدم TEST، بمعنى آخر، نريد مراقبة جميع الجداول التي ينشئها المستخدم TEST في SCHEMA آخر باستخدام إذن CREATE ANY TABLE، مما يعني إنشاء جدول في SCHEMA آخر.

AUDIT CREATE ANY TABLE BY TEST WHENEVER SUCCESSFUL;

الآن ماذا لو قام المستخدم TEST بإنشاء جدول في EMP SCHEMA، أي في مساحة مستخدم EMP؟

CREATE TABLE EMP.EMPLOYEE (EMP_NO NUMBER(٤),EMP NAME VARCHAR(40)); 

وبطبيعة الحال، يمكن لمدير قاعدة البيانات اتباع هذه الخطوة.

SELECT USERNAME,OWNER,OBJ_NAME,ACTION_NAME,TO_CHAR(TIMEST AMP,'DD-MM-YYYY:HH-MI-SS') FROM DBA_AUDIT_OBJECT WHERE USERNAME='TEST'; 

ستلاحظ أن المستخدم TEST قام بالفعل بإنشاء جدول EMPLOYEE في المستخدم EMP في الوقت المحدد.

يمكنك أيضًا متابعة بقية الأذونات، على سبيل المثال (DROP ANY TABLE) وأذونات أخرى SYSTEM PRIVILEGES.

للاستعلام عن تهيئة خيارات مراقبة SYSTEM .

SELECT * FROM DBA_PRIV_AUDIT_OPTS WHERE PRIVILEGE='CREATE ANY TABLE'; 

يمكن أيضًا إلغاء المراقبة.

NOAUDIT CRATE ANY TABLE BY TEST WHENEVER SECCESSFUL;

• OBJECT PRIVILEGE AUDITING:

هذا النوع مخصص لمراقبة العمليات التي تتم على كائنات مثل الجداولTABLES  والعروض VIEWS  والكائنات الأخرى.

من الممكن التركيز من خلال تحديد المستخدم وأيضًا من خلال نجاح أو فشل العملية. أصل هذا النوع من المراقبة هو BY SESSION، ولكن يمكن تحديد الخيار BY ACCESS.

لنفترض أننا نريد مراقبة الإضافات في جدول USER_MASTER في SCHEMA المسمى TEST.

AUDIT INSERT ON TEST.USER_MASTER BY ACCESS; 

الآن إذا قام المستخدم TEST بإضافة بيانات إلى جدول USER_MASTER، يمكن لمسؤول قاعدة البيانات متابعة ذلك.

SELECT USERNAME,TO_CHAR(TIMESTAMP,'DD-MM-YY:HH- MI-SS'),OBJ_NAME,ACTION_NAME FROM DBA_AUDIT_TRAIL WHERE USERNAME='TEST' AND OBJ_NAME='USER_MASTER' AND ACTION_NAME='INSERT'; 

للاستعلام عن خيارات تهيئة مراقبة ﺍلOBJECT PRIVILEGES.

SELECT * FROM DBA_OBJ_AUDIT_OPTS WHERE OWNER='TEST' AND OBJECT_NAME='USER_MASTER'; 

هناك ثلاث قيم:

-: تعني عدم وجود مراقبة.

A: تعني أن معلومات المراقبة مخزنة بواسطة  BY ACCESS.

S: تعني أن معلومات المراقبة مخزنة بواسطة BY SESSION .

لاحظ أنه مقابل حقل INS، توجد القيمة A/A، مما يعني أن عملية INSERT تتم مراقبتها باستخدام خيار BY ACCESS، سواء نجحت العملية أم فشلت.

ومع ذلك، إذا كان الخيار WHENEVER SUCCESSFUL، فستكون القيمة A/-

يمكن إلغاء عملية المراقبة باستخدام.

NOAUDIT INSERT ON TEST.USER_MASTER; 

وبذلك نكون قد ناقشنا الخيارات المتاحة للمراقبة والتي تنتمي إلى الجزء الأول،  Standard Database Auditing، وهي:

.SESSION AUDITING

SQL STATEMENT AUDITING

SYSTEM PRIVILEGE AUDITING

OBJECT PRIVILEGE AUDITING

2- Value-Based Auditing:

 في النوع الأول من المراقبة وهو Standard Database Auditing نستطيع مراقبة وحفظ المعلومات عن العمليات التي تحدث في قاعدة البيانات ولكن في بعض الأحيان قد نحتاج إلى حفظ القيم التي يتم تعديلها أو حذفها من قاعدة البيانات وهذه القيم لا يتم حفظها في ﺍلStandard Database Auditing هذا النوع من المراقبة وهو Value-Based Auditing يعتمد على إنشاء Trigger بحيث يتم تنفيذه بعد إجراء العملية تعديل أو حذف لحفظ المعلومات والقيم التي نريدها وحفظها في جدول نقوم بإنشائه خصيصا لتخزين هذه المعلومات.

بالطبع هذا النوع من Auditing Value-Based  يقلل من أداء قاعدة البيانات أكثر من نوع Standard Database Auditing  وذلك لأن Trigger يتم تنفيذه بعد كل عملية تعديل أو حذف.

الآن لنفترض أننا نريد مراقبة وحفظ القيم التي تم تعديلها في حقل BOOK_NAME في جدول BOOK الذي يملكه المستخدم TEST.

يجب على مدير قاعدة البيانات أولاً تحديد المعلومات التي يريد حفظها، ولنفترض أنها:-

1- IP Address للجهاز الذي تم استخدامه للاتصال بقاعدة البيانات.

2- اسم مستخدم نظام التشغيل الذي اتصل بقاعدة البيانات.

3- التاريخ والوقت.

4- قيمة الحقل قبل وبعد التعديل.

ثانياً: يجب على مدير قاعدة البيانات إنشاء الجدول لتخزين المعلومات حول عمليات التعديل.

CREATE TABLE BOOK_AUDIT(

OS_USER VARCHAR2(70),

UPDATE_DATE DATE,

IP_ADDRESS VARCHAR2(60),

OLD_NEW_NAME VARCHAR2(100)); 

ثالثًا، يقوم مدير قاعدة البيانات بإنشاء ﺍلTrigger.

CREATE OR REPLACE TRIGGER BOOK_NAME_AUDIT AFTER UPDATE OF BOOK_NAME

ON TEST.BOOK

REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW

BEGIN

IF :OLD.BOOK_NAME != :NEW.BOOK_NAME THEN INSERT INTO BOOK_AUDIT

VALUES (SYS_CONTEXT('USERENV','OS_USER'), SYSDATE, SYS_CONTEXT('USERENV','IP_ADDRESS'),

:NEW.BOOK_NO ||' BOOK_NO) CHANGED FROM '||:OLD.BOOK_NAME||

' TO '||:NEW.BOOK_NAME); END IF;

END; 

هذه هي الطريقة التي يتم بها إنشاء ﺍلTrigger ولنفترض أن المستخدم TEST قام بإجراء تعديل في جدول BOOK.

يمكن لمسؤول قاعدة البيانات تتبع هذا التعديل عبر جدول BOOK_AUDIT.

SELECT OS_USER,TO_CHAR(UPDATE_DATE,'DD-MM-YY:HH- MI-SS'),IP ADDRESS,OLD NEW NAME FROM BOOK_AUDIT; 

لإيقاف هذا النوع من المراقبة، يمكنك تعطيل أو حذف هذا ﺍلTrigger.

3- (Fine-Grained Auditing (FGA:

تستطيع أنواع المراقبة السابقة حفظ معلومات عن العمليات التي تحدث في قاعدة البيانات، كما يمكن حفظ القيم التي تتغير، أما هذا النوع من المراقبة فهو لحفظ جمل SQL التي يتم تنفيذها في قاعدة البيانات ويشمل كل الجمل التالية (DELETE & UPDATE & INSERT & SELECT)، ويتم ذلك باستخدام حزمة DBMS_FGA، تحتوي هذه الحزمة على أربعة من  ﺍلProcedure:-

1- ADD_POLICY: لإضافة POLICY جديدة لمراقبة جمل SQL في قاعدة البيانات وفقًا للقيم التي سنحددها في الإجراء.

2- DROP_POLICY: لحذف AUDIT POLICY موجودة.

3- ENABLE_POLICY: لتشغيل  AUDIT POLICY

DISABLE POLICY - 4: لتعطيل AUDIT POLICY.

الآن لنفترض أننا نريد حفظ جمل SELECT التي تحدث لجدول BOOK الذي يملكه المستخدم TEST، ولكي لا نحفظ كل جمل SELECT التي تحدث لجدول BOOK، فمن الممكن التركيز

على بعض الحقول باستخدام بعض الشروط.

.WHERE BOOK_NO=1 على سبيل المثال

وهذا لتركيز عملية المراقبة.

يجب على مسؤول قاعدة البيانات أن يحرص دائمًا على عدم المبالغة في عملية المراقبة، بل التركيز دائمًا على ما هو مطلوب. الآن نقوم بتنفيذ إجراء ADD_POLICY لإضافة AUDIT POLICY لحفظ جمل SELECT التي يتم تنفيذها على جدول BOOK وفقًا للشروط التي نحددها. بالطبع، يحتوي هذا الإجراء على مجموعة من المتغيرات التي يجب أن نحدد قيمها. سنتحدث عن هذه Procedures بشيء من التفصيل لاحقًا. هذه الإجراءات موجودة في قاعدة البيانات ضمن حزمة DBMG_FGA، أي أن مسؤول قاعدة البيانات لا يحتاج إلى إنشائها. يحتاج فقط إلى تنفيذها بعد تحديد قيم المتغيرات.

DECLARE

OBJECT_SCHEMA VARCHAR2(200);

OBJECT_NAME VARCHAR2(200);

POLICY_NAME VARCHAR2(200);

AUDIT_CONDITION VARCHAR2(200);

AUDIT_COLUMN VARCHAR2(200);

HANDLER_SCHEMA VARCHAR2(200);

HANDLER_MODULE VARCHAR2(200);

ENABLE BOOLEAN;

STATEMENT_TYPES VARCHAR2(200);

AUDIT_TRAIL BINARY_INTEGER;

AUDIT_COLUMN_OPTS BINARY_INTEGER;

BEGIN

OBJECT_SCHEMA := 'TEST';

OBJECT_NAME := 'BOOK';

POLICY_NAME := 'BOOK_SELECT';

AUDIT_CONDITION := 'BOO_NO=1';

AUDIT_COLUMN := 'BOOK_NAME';

HANDLER_SCHEMA := NULL;

HANDLER_MODULE := NULL;

ENABLE := TRUE;

STATEMENT_TYPES := 'SELECT';

AUDIT_TRAIL := 1;

AUDIT_COLUMN_OPTS := 0;

SYS.DBMS_FGA.ADD_POLICY ( OBJECT_SCHEMA, OBJECT_NAME, POLICY_NAME, AUDIT_CONDITION, AUDIT_COLUMN, HANDLER_SCHEMA, HANDLER_MODULE, ENABLE, STATEMENT_TYPES, AUDIT_TRAIL, AUDIT_COLUMN_OPTS );

COMMIT;

END;

/ 

 OBJECT_SCHEMA: تعني المستخدم الذي يحتوي على الجدول أو الكائن الذي نريد مراقبة عبارات SELECT عليه.

OBJECT_NAME: هو الكائن الذي نريد مراقبة عبارات SELECT عليه.

POLICY_NAME: هو اسم POLICY AUDIT الذي نريد إنشاءه.

AUDIT_CONDITION: هو لتحديد الشروط لتركيز عملية المراقبة.

AUDIT_COLUMN: هذا هو العمود الذي نريد تركيز عملية المراقبة عليه.

HANDLER_SCHEMA: قد نحتاج أحيانًا إلى تحديد إجراء لأداء بعض الأحداث الإضافية أثناء عملية المراقبة، لذلك نحدد هنا المستخدم الذي يحتوي على هذا الإجراء.

ENABLE: لتنشيط عملية POLICY AUDIT، ويأخذ هذا المتغير القيمة TRUE في الوضع الافتراضي.

STATEMENT_TYPES: لتحديد نوع عبارات SQL التي نريد مراقبتها، يكون الوضع الافتراضي هو SELECT.

AUDIT_TRAIL: لتخزين عبارات SQL التي تمت مراقبتها في AUDIT_TRAIL.

AUDIT_COLUMN_OPTS: ماذا لو قمت بتحديد عدد من الأعمدة في المتغير AUDIT_COLUMN، هنا لتحديد ما إذا كان (الكل أو أي).

والآن ماذا لو قام مستخدم EMP بإجراء استعلام على جدول BOOK الذي ينتمي إلى مستخدم TEST بنفس الشروط المذكورة أعلاه؟

SELECT * FROM TEST.BOOK WHERE BOOK_NO=1; 

يمكن لمسؤول قاعدة البيانات الآن متابعة هذا الاستعلام.

SELECT USERHOST,OS_USER,DB_USER,TO_CHAR(TIMESTAMP,'DD-MM- YY:HH-MI-SS'),SQL_TEXT FROM DBA_FGA_AUDIT_TRAIL WHERE DB_USER='EMP;

إ

ذا قام مستخدم EMP بإجراء استعلام آخر لا يفي بالشروط المحددة في إجراء ADD_POLICY، فلن يتم عرض المعلومات من هذا الاستعلام إلى مسؤول قاعدة البيانات.

بالطبع، يمكن لمسؤول قاعدة البيانات الاستعلام عن AUDIT_POLICIES التي تعمل في قاعدة بيانات DBA_AUDIT_POLICIES.

SELECT POLICY_NAME,OBJECT_SCHEMA,OBJECT_NAME,POLICY_COLUM N,SEL FROM DBA_AUDIT_POLICIES; 

يمكن تعطيل ﺍلPOLICY AUDIT  هذه من خلال إجراء DISABLE_POLICY.

DECLARE

OBJECT_SCHEMA VARCHAR2(200);

OBJECT_NAME VARCHAR2(200);

POLICY_NAME VARCHAR2(200);

BEGIN

OBJECT_SCHEMA := 'TEST'; OBJECT_NAME := 'BOOK'; POLICY_NAME := 'BOOK_SELECT';

SYS.DBMS_FGA.DISABLE_POLICY ( OBJECT_SCHEMA, OBJECT_NAME, POLICY_NAME );

COMMIT;

END;

/

  

يمكن أيضًا تمكينه مرة أخرى باستخدام الإجراء ENABLE_POLICY.

DECLARE

OBJECT_SCHEMA VARCHAR2(200);

OBJECT_NAME VARCHAR2(200);

POLICY_NAME VARCHAR2(200);

BEGIN

OBJECT_SCHEMA := 'TEST';

OBJECT_NAME := 'BOOK';

POLICY_NAME := 'BOOK_SELECT';

SYS.DBMS_FGA.ENABLE_POLICY ( OBJECT_SCHEMA, OBJECT_NAME, POLICY_NAME );

COMMIT;

END;

/ 

أ

خيرًا، يمكن حذف POLICY AUDIT باستخدام إجراء DROP_POLICY.

DECLARE

OBJECT_SCHEMA VARCHAR2(200);

OBJECT_NAME VARCHAR2(200);

POLICY_NAME VARCHAR2(200);

BEGIN

OBJECT_SCHEMA := 'TEST';

OBJECT_NAME := 'BOOK';

POLICY_NAME := 'BOOK_SELECT';

 
SYS.DBMS_FGA.DROP_POLICY ( OBJECT_SCHEMA, OBJECT_NAME, POLICY_NAME );

COMMIT;

END;

/ 

الآن إذا قمت بإجراء استعلام عن AUDIT_POLICIES فلن تجد هذه ﺍلPOLICY في قاعدة البيانات.