FINE GRAINED AUDITING (FGA)

Gliederung zu AUDITING
1; Übersicht (Versionen)
Seite 2
2; Audit-Kategorien
a; Standard-Audit
b; Datenbank-Audit
c; Wertorientierter Audit
d; Anwendungs-Audit
3; SETUP
a; Datenbank-Audit aktivieren (und deaktivieren)
Beispiel
b; Installation AUDITING
c; Privileg für den User
d; Audit-Optionen festlegen
1; Administrative Verbindungen
2; Auditing auf Objekt-Ebene
3; Auditing auf Privilegien-Ebene
4; Anweisungs-Audit
Seite 3
Seite 4
Seite 6
Seite 6
Seite 7
Seite 7
Seite 7
Seite 8
4; Fein abgestimmtes Auditing (FGA)
a; Interfaces von DBMS_FGA
b; Neu in Version 10g
c; Erstellen einer Policy auf Spalten-Ebene (nur 10g)
inkl. Spalten Masking (Beispiel)
d; Implementierung der Audit Policy
e; Triggering
f; Beispiele zu 9i
g; Beispiele zu 10g
g.1. STATIC
g.2. Context Sensitive
h; Audit Column (+ Beispiel)
i; Audit Event Handler (+ Beispiel)
Seite 9
Seite 9
Seite 9
Seite 11
Seite 12
Seite 12
Seite 13
Seite 14
Seite 14
Seite 14
Seite 15
Seite 16
5; Syntax zu ADD_POLICY
Seite 17
6; VIEWS
Seite 19
1
AUDITING
1; Übersicht (Versionen)
In den DB-Versionen vor 9i erfolgte das Auditing mit „before“ und „after“ Triggern
für INSERT,UPDATE und DELETE. Ab Version 9i lassen sich auch SELECTs auditieren.
In Version 10, supportet FGA-DML-Statements + MERGE.
In Version 10g ist für den AUDIT_TRAIL – Parameter die Option „DB_EXTENDED“
hinzugekommen. Siehe dort.
Ab Version 9i ist es möglich nur die „Success“ oder nur die „Unsuccess“-Operationen zu
auditieren.Mit anderen Worten: AUDITING kann nur die Versuche auditieren, auch wenn
keine Information abgerufen werden konnte.
2; Audit-Kategorien:
a; Standard-Audit
Standardmäßig wird geprüft:
- STARTUP/SHUTDOWN der Instanzen
- Administratorprivilegien
(Die Audit-Informationen enthalten den Betriebssystem-User, der sich mit
Administrator-Privilegien bei ORACLE anmeldet.
b; Datenbank-Audit
Beim Datenbank-Audit werden bestimmte Benutzer-DB-Aktionen überwacht
und aufgezeichnet. Informationen über das Ereignis werden im Audit-Trail gespeichert.
Neben der Überwachung verdächtiger Aktivitäten auf der DB können auch Daten zu
speziellen DB-Aktivitäten z.B. in Form von Statistikdaten zu den aktualisierten Tabellen,
der Anzahl durchgeführter I/O-Operationen sowie die Anzahl der Benutzer erfasst
werden die sich zu Spitzenbelastungszeiten gleichzeitig anmelden.
c; Wertorientierter Audit
Ein DB-Audit kann keine Spaltenwerte aufzeichnen. Wenn Änderungen von
Datenbankspalten überwacht und die Spaltenwerte für jede Änderung aufgezeichnet
werden müssen, soll der Anwendungs-Audit verwendet werden.
d; Anwendungs-Audit
erfolgt über Client-Code, Stored-Procedures oder DB-Trigger.
2
3; SETUP
a; Datenbank-Audit aktivieren und deaktivieren
Erfolgt mittels AUDIT_TRAIL =
„wert“
wert
=
-
DB oder TRUE
(Ermöglicht das systemweite Auditing, wobei die auditierten Records in den
Audit Trail (= SYS.AUD$ Table) geschrieben werden.
-
OS
(systemweites Auditing, bei dem die auditierten Records in das Audit Trail des
Systems geschrieben werden)
-
DB_EXTENDED
(identisch mit der Option „DB/TRUE“;
zusätzlich werden die Spalten „SQLBIND“ und „SQLTEXT CLOB“ in der
Tabelle SYS.AUD$ gefüllt.)
-
NONE oder FALSE
(Default. Schaltet Auditing aus)
Besonderheit zur Option „OS“:
Es muß hier der Ort spezifiziert werden:
z.B. AUDIT_FILE_DEST = $ORACLE_HOME/rdbms/audit
Abfrage mit:
SQL> select spid, program, username from v$process;
Für weitere Parameter siehe “FGA” auf den Folgeseiten
3
Beispiel:
In der init.ora wurde
AUDIT_TRAIL auf DB_EXTENDED gesetzt.
Damit wurde das automatische Schreiben von Audits ermöglicht. Alle Sätze werden
in die SYS.AUD$ Tabelle geschrieben. Zusätzlich werden die CLOB-Spalten der
SYS.AUD$ Tabelle, SQLBIND und SQLTEXT gefüllt.
Online wäre die gleiche Wirkung erzielt mit:
SQL> ALTER SYSTEM SET audit_trail=db_extended SCOPE=SPFILE;
SQL> SHOW PARAMETER AUDIT_TRAIL
Nachstehendes Beispiel dient zur Erläuterung welche Inhalte in den Spalten „sqlbind“ und
„sqltext“ der Tabelle SYS.SYSAUD$ stehen:
SQL> AUDIT INSERT INTO piet.dept;
-siehe “Audit-Optionen festlegen”
SQL> CREATE OR REPLACE PROCEDURE dbms_example
(deptnum IN piet.dept.deptno%TYPE,
deptname IN piet.dept.dname%TYPE,
location IN piet.dept.loc%TYPE) IS
stmt_str varchar2(100);
rows_processed NUMBER;
cur_hdl NUMBER;
BEGIN
stmt_str := 'INSERT INTO piet.dept VALUES( :deptno,
:dname, :loc)';
cur_hdl := DBMS_SQL.OPEN_CURSOR;
DBMS_SQL.PARSE(cur_hdl,stmt_str,DBMS_SQL.NATIVE);
DBMS_SQL.BIND_VARIABLE(cur_hdl,´:deptno´, deptnum);
DBMS_SQL.BIND_VARIABLE(cur_hdl, ´:dname´,deptname);
DBMS_SQL.BIND_VARIABLE(cur_hdl,´:loc´, location);
rows_processed := dbms_sql.execute(cur_hdl);
DBMS_SQL.CLOSE_CURSOR(cur_hdl);
END;
/
SQL> select
Oder:
SQL> select
Oder:
SQL> select
sqlbind, sqltext from sys.aud$;
sqlbind, sqltext from user_audit_trail;
sqlbind, sqltext from dba_audit_trail;
In den Spalten “sqlbind” stehen nach Aufruf obiger Prozedur die entsprechenden Werte für
die Bindevariablen “:deptno“,“:deptname“ und “:loc“.
4
Der Inhalt von “sqltext“ enthält die SQL-Statements der Prozedur “dbms_example“.
Anstatt der Tabelle “SYS.AUD$“ kann auch der View “USER_AUDIT_TRAIL“ /
“DBA_AUDIT_TRAIL“ abgefragt werden. Diese Views setzt auf der Tabelle “SYS.AUD$“
auf. Die Verwendung der Views ist die gebräuchlichere Form.
„USER_AUDIT_TRAIL“ listet nur die Einträge des Users.
5
b;
Installation AUDITING
Falls Auditing nicht existiert kann das Auditing nun installiert werden:
SVRMGR> connect internal (oder als SYS)
SVRMGR> @cataudit.sql
Siehe auch “Feinabgestimmtes Auditing mittels DBMS_FGA” auf den Folgeseiten.
c;
Privileg “audit xxxx“ für den User
(“audit system“ / “audit any“)
Für das Auditing muß der User das Audit-Priv besitzen.
SQL>
SQL>
SQL>
SQL>
connect system/manager
grant audit system to scott;
connect scott/tiger
audit session;
Mit dem Privileg “audit system” kann der User
SCOTT auf Session-Ebene auditieren.
User mit dem Audit-Priv werden abgefragt über:
SQL> select *
2 from dba_sys_privs
3 where privilege like '%AUDIT%';
d;
Audit-Optionen festlegen
Erfolgt über das Kommando: AUDIT
Legt fest, welche Befehle,Benutzer,Objekte oder Privilegien geprüft werden sollen..
Außerdem lässt sich festlegen, ob Audit-Informationen für jedes Vorkommen oder nur
einmal pro Session generiert werden sollen.
Allgemeines Format:
audit {statement_option|privilege_option} [by user] [by
{session|access}] [ whenever {successful|unsuccessful}]
Nur “statement_option und privilege option sind pflicht.
6
Eine Statement-Option kann z.B. sein:
ALTER, GRANT, RENAME sowie die "klassischen" Datenmanipulationen INSERT,
UPDATE usw. Man kann entweder einzelne Objekte, z.B. eine bestimmte Datenbanktabelle,
angeben oder DEFAULT. Bei letzterem gilt der Befehl systemweit, also nicht nur für einzelne
Objekte. SESSION oder ACCESS steuert, ob die Protokollierung nur beim ersten Mal einer
"Sitzung" am Terminal oder bei jedem Zugriff erfolgt. Man kann die Protokollierung dann
noch auf erfolgreiche Aktionen oder Misserfolge begrenzen.
Auditing kann sich richten auf:
1;
2;
3;
4;
Administrative Verbindungen
Auditing auf Objekt-Ebene
Auditing auf Privilegien Ebene
Auditing von Anweisungen
Zu 1; Administrative Verbindungen
z.B. AUDIT SYS Operations:
Hier muß in der init.ora der Parameter gesetzt werden:
AUDIT_SYS_OPERATIONS = TRUE
Die Operationen von SYS, SYSDBA und SYSOPER werden überwacht.
Zu 2; Auditing auf Objekt-Ebene
Objekte sind: Tabellen, Views, Sequenzen, Packages, Stored Procedures/ Funktions
Welche Optionen sind möglich ?
alter, audit, comment, delete, grant, index, insert, lock, rename,
select, update, reference and execute
“reference“ and “execute“ können nicht auf Tabellen angewendet
werden.
z.B. AUDIT SELECT ON emi.orders;
AUDIT SELECT ON scott.emp by access;
In letzterem Fall wird auch jeder versuchte Zugriff auf EMP protokolliert.
zu 3; Auditing auf Privilegien-Ebene
Es können alle Privs auditiert werden
Gültige Privs können nachgesehen werden in: system_privilege_map
z.B. AUDIT CREATE ANY TRIGGER;
:
SQL> select username, priv_used, ses_actions from dba_audit_object;
Ergebnis:
USERNAME
-------SCOTT
SCOTT
SYSTEM
PRIV_USED
SES_ACTIONS
---------------------------------------- ------------------CREATE ANY TRIGGER
CREATE ANY TRIGGER
CREATE ANY TRIGGER
Bei z.B. AUDIT TABLE
werden Statements zu: CREATE,ALTER und DROP table
auditiert.
7
zu 4; Anweisungs-Audit:
Ist ähnlich wie bei „Auditing auf Privilegien-Ebene“. Nur wird hier das System Privileg
auditiert.
z.B. AUDIT CREATE TABLE auditiert nur das CREATE TABLE und nicht irgendeine
Anweisung zu ALTER oder DROP
Alle diese Optionen können ergänzt werden durch:
- WHENEVER SUCCESSFUL
/
- BY SESSION / BY ACCESS
WHENEVER NOT SUCCESSFUL
Die vereinbarten Optionen kann man nachsehen in der View:
SYS.DBA_SYS_AUDIT_OPTS
Session-Auditing beenden mit:
SQL> noaudit session;
8
4; Feinabgestimmtes Auditing (FGA)
- FGA ermöglicht die Überwachung des Datenzugriffs auf der Basis des Inhalts
- Implementierung über das Package DBMS_FGA
FGA wurde in der Version 9i nur von SELECT supported. Neu in Version 10g ist der
Support von FGA für DML-Statements + MERGE
Definition: „Virtual Private Database (VPD)“
Die Kombination von “feinkörnige Zugangskontrolle” mit sicherem
Anwendungszusammenhang wird VPD genannt
a;
Interfaces von DBMS_FGA
- ADD_POLICY
(Syntax siehe Seite 17))
- ENABLE_POLICY
- DISABLE_POLICY
- DROP_POLICY
ORACLE auditiert immer ein DELETE, auch wenn keine Spalten spezifiziert worden sind,
da hier sämtliche Spalten betroffen sind.
b; Neu in Version 10g:
-
Es ist der View DBA_COMMON_AUDIT_TRAIL hinzugekommen
Dieser View enthält nun zusätzliche Informationen zu
SCN sowie „sqlbind“ und „sql_text“ (siehe SYS.AUD$).
Voraussetzung für diesen View ist, dass in der init.ora
AUDIT_TRAIL = DB_EXTENDED gesetzt wurde
Zusätzliche Informationen sind:
 die SerienNummer der Audit Datensätze
 Nummern zu den Statements, die helfen welche Audit-Einträge zu
einer AnweisungsNummer (STATEMENTID) gehören.
-
Folgende Attribute sind sowohl den Standard Audit Trails sowie FGA Audit-Trails
Gemeinsam: -- globaler-Zeitstempel (GLOBAL_UID)
-- eine eindeutige Instanz-Nummer für die RAC – Instanzen
(INSTANCE_NUMBER)
-- eine Nummer zur Transaktion um einzelne Datensätze einer
Transaktion zuzuordnen (TRANSATIONID)
-
Die Prozedur DBMS_FGA.ADD_POLICY hat einen neuen Parameter:
STATEMENT_TYPES. Dient dazu den Typ der Aktion zu auditieren. Siehe Seite 18.
- Es lassen sich Statements zu DML + MERGE auditieren.
Hinsichtlich MERGE , so wird die darunter liegende INSERT/UPDATE Operation
auditiert.
Man kann mehr als nur eine einzelne Spalte für das FGA auditieren.
-
Man kann auch NULL in den feinkörnigen Aussagen zur Policy verwenden.
Beispiel :
Siehe auch “Syntax zu ADD_POLICY” am Schluß.
begin
DBMS_FGA.ADD_POLICY (
9
object_schema => 'OE',
object_name => 'cust_payment_info',
policy_name => 'fga_cust_payment_info',
audit_condition => 'credit_card_number =
310654305412389',
audit_column => NULL,
handler_schema => NULL,
handler_module => NULL,
enable => TRUE,
statement_types => 'UPDATE, DELETE, SELECT',
audit_trail => DBMS_FGA.DB + DBMS_FGA.EXTENDED);
end;
/
- FGA erzeugt einen signifikant größeren Overhead mit SQL-Informationen.
Der Inhalt der Spalten (siehe Tabelle: SYS.AUD$) „sqltext“ und „sqlbind“ wird nun
nicht mehr in LOBs abgelegt.
-
Einführung von STATIC–POLICIES
Die DB führt eine „statische Policy“ nur einmal aus. Es entfällt das wiederholte
Ausführen der POLICY und legt die Aussagen (Predikate) im Puffer der SGA ab.
Von nun an wendet die DB diese Predikate auf alle folgenden Queries für die
geschützten Objekte an. Dies entlastet ganz erheblich den Server.
In den Versionen zuvor kam ausschließlich die „dynamische Policy“ zur Anwendung.
Hierbei wird jeweils eine unterschiedliche „WHERE“ Klausel verwendet. Bei der
„statischen Policy“ hingegen kommt stets die selbe WHERE-Klausel zur Anwendung.
z..B. DEPTNO=irgendwas. Obwhohl „irgendwas“ für jedes Statement differieren
kann, so hat sich die SQL – Abfrage auf die Tabelle nicht geändert. So etwa in
Analogie zur Binde_Variablen.
z.B. Eine „Function“ fragt einen „UserContext“ ab und generiert unterschiedliche
„WHERE“-Klauseln in Abhängigkeit vom Ergebnis. So erhalten einige User z.B.
„deptno=xxxxx“ und andere wiederum erhalten als Resultat „mgr=xxxx“.
So ergeht beim Ausweis der Policy als „statisch“ die Anweisung an ORACLE dass
diese „Function“ nur einen einzigen Wert zurückliefert, unabhängig wer ausführt.
Wenn ORACLE nun die Anweisung von der Policy erhält , stets den selben Wert
zurückzugeben, so braucht ORACLE diese Policy nicht ständig neu zu generieren.
Für Hosting-Umgebungen, z.B. bei Data Warehouse wo die selbe Aussage auf mehrere
DB-Objekte angewendet werden muß, wird SHARED_STATIC eingesetzt.
Letzterer Parameter unterscheidet sich von SHARED dadurch, dass die Policy über mehrere
Objekte verteilt ist.
-
Einführung von CONTEXT_SENSITIVE und SHARED_CONTEXT_SENSITIVE
Bei CONTEXT_SENSITIVE wird die Policy angewendet zum Zeitpunkt des Parsens der
Anweisung sowie bei der Ausführung der Anweisung wenn der lokale Kontext seit dem letzten
Gebrauch des Cursors sich geändert hat. Wird angewendet bei dreireihiger SessionVereinigung (3-tier session pooling). Ist für Applikationen gedacht, wo mehr als eine Aussage
für unterschiedliche User oder Gruppen getroffen werden. Context-Sensitive Policy
kommt zur Anwendung vor allem bei Applikationen auf WEB-Basis mit
Connection Polling. Hierbei verändert sich die Session in Abhängigkeit
vom „CLIENT_IDENTIFIER“ des Users.
10
Der Unterschied SHARED_CONTEXT_SENSITIVE zu CONTEXT_SENSITIVE besteht
darin, dass hier die Policy auf mehrere Objekte verteilt ist.
c; Erstellen einer Policy auf Spalten-Ebene (nur 10g) (Beispiel)
Erfordert das Privilege „EXECUTE ON DBMS_RLS“
Zuerst wird die Policy-Function erstellt
Dann wird die Policy zu VPD (Virtual Private Database) erstellt mit
DBMS_RLS.ADD_POLICY. Die Spalten-Namen werden spezifiziert über den Parameter:
sec_relevant_cols und evtl. ergänzt durch:
sec_relevant_cols_opt
Erstellen einer Policy-Funktion (Spalten Masking)
Begrenzt den Zugang auf die Spalten “Salary” und “Commission” wenn der
Angestellte nicht zum Department-Nr 5 gehört.
create or replace function test_function
(objowner IN 2, varchar2 objname IN varchar2)
return varchar2 as
con varchar2 (200);
begin
con := 'deptno = 5';
return (con);
end test_function;
/
Nun wird eine VPD erstellt:
begin
dbms_rls.add_policy (
object_schema => 'scott',
object_name => 'emp',
policy_name => 'test_policy',
function_schema => 'scott',
policy_function => 'test_function',
statement_type = 'insert,update'
sec_relevant_cols => 'salary, commission');
end;
SQL> select deptno, empno, ename, job, sal, comm from emp;
Die Spalten “sal” und “comm.” Werden nur für das Department 5 gelistet.
Weiteres Beispiel für Spalten-Masking zu obiger VPD
(mit dem Parameter sec_relevant_cols_opt => DBMS_RLS.ALL_ROWS)
begin
dbms_rls.add_policy (
object_schema => 'scott',
object_name => 'emp',
policy_name => 'sp_job',
function_schema => 'scott',
policy_function => 'pf_job',
11
sec_relevant_cols => 'sal, comm'
sec_relevant_cols_opt => DBMS_RLS.ALL_ROWS
);
end;
/
select deptno, empno, ename, job, sal, comm from emp;
Ergebnis: Es werden Salary und Commision nur für die Mitarbeiter in Department 5
gelistet. Es werden ansonsten alle Mitarbeiter gelistet, jedoch ohne die
Spalten „sal“ und „comm“.
d; Implementierung der Audit Policy
-
erforderliche Angaben (Schema,Objekt, Name der Policy und die Audit-Kondition)
optional (audit Spalte, Schema des Event Handlers, Name des Event Handlers, ob
enabled)
Die Policies sind in der Tabelle „DBA_AUDIT_POLICIES“ gespeichert
Bei einem Drop;Enable/Disable einer Audit-Policy müssen das Schema-Object, sowie die
Bezeichnung der Policy angegeben werden.
e; Triggering
Beim Triggern des Audits, werden die Daten in die Tabelle DBA_FGA_AUDIT_TRAIL
geschrieben.
Diese enthält:
- session id
- user name
- timestamp
- name of policy
- Text der SQL-Query
12
f; Beispiele zu 9i:
DBMS_FGA.ADD_POLICY
(
object_shema
object_name
policy_name
audit_condition
);
=>
=>
=>
=>
'hr ',
'employees ',
'audit_dept100_employees ',
'department_id = ' '100 ' ' '
DBMS_FGA.ENABLE_POLICY
(
object_schema => 'hr',
object_name
'employees',
policy_name
'audit_dept100_employees ',
enable
BOOLEAN := TRUE
);
DBMS_FGA.DISABLE_POLICY
(
object_schema 'hr ',
object_name
'employees ',
policy_name
'department_id = ' '100 ' ' '
);
DBMS_FGA.DROP_POLICY
(
object_schema
'hr ',
object_name
'employees ',
policy_name
'department_id = ' '100 ' ' '
);
13
g; Beispiele zu 10g
g.1. STATIC
begin
dbms_rls.add_policy
(
object_schema
=> 'scott ',
object_name => 'emp ' ,
policy_name => 'test_policy ',
function_schema => 'test_schema ' ,
policy_function => 'test_function ' ,
statement_type = 'select, insert, update ',
policy_type => dbms_rls.static
sec_relevant_cols => 'salary ,
commission');
end;
Wenn die selbe “ statische Policy Funktion” über mehrere Datenbank-Objekte
als „Share“ verteilt werden soll, so muß der Parameter „policy type“ abgeändert
werden auf:
policy_type => dbms_rls.shared_static
g.2.
Context-Sensitive
begin
dbms_rls.add_policy (
object_schema => 'scott ',
object_name => 'emp ' ,
policy_name => 'test_policy ',
function_schema => 'test_schema ' ,
policy_function => 'test_function ' ,
statement_type = 'select, insert, update ',
policy_type => dbms_rls.context_sensitive
sec_relevant_cols => 'salary , commission ');
end;
14
h; Audit Column
Ohne „audit column“ wird die Query auditiert, wenn die Audit-Bedingung zutrifft.
Bei Spezifizierung der „Audit Column“ wird der Audit selbst bei zutreffender
Bedingung nicht getriggert. Getriggert wird erst bei Bezugnahme in der Query.
Allerdings behandelt ORACLE 9i alle Spalten als „Audit Columns“
z.B.
DBMS_FGA.ADD_POLICY
(
object_shema
object_name
policy_name
audit_condition
audit_column
);
=>
=>
=>
=>
'hr ',
'employees ',
'audit_topsecret_employees ',
'security_clearance =
' 'TOPSECRET ' ' ',
=> 'ssn '
SELECT last_name, first_name, phone
FROM employee
WHERE ssn = '123-45-6789 ';
Die Security Freigabe für diese Person lautet TOPSECRET.
Weil die Bedingung zutrifft und die Angabe der ssn Spalte in der Query
angegeben wird so wird diese Abfrage auditiert.
SELECT last_name, first_name, phone
FROM employee
WHERE security_clearance = 'SECRET ';
Diese Query resultiert in Employees mit der Freigabe SECRET.
Die Audit Policy Bedingung erfordert Audit von TOPSECRET.
Die Query wird deshalb nicht ausgeführt.
Folgende Query wird ebenfalls nicht auditiert, da sie „ssn“ nicht referenziert:
SELECT last_name, first_name, phone
FROM employee
WHERE security_clearance != 'SECRET ';
15
i; Audit Event Handler
Es kann auch ein “Audit Event Handler“ als Bestandteil der Audit Policy spezifiziert werden.
Wenn dieser Audit getriggert wird, so ruft ORACLE diesen Event Handler auf.
Definiert wird der Event Handler z.B. mit:
CREATE OR REPLACE PROCEDURE hr.ts_access_alert
(schema varchar2, table_name varchar2, policy_name
varchar2)
AS
BEGIN
/* hier befindet sich der Anwendungscode:
z.B. Senden E-Mail, Tabelle updaten…..
oder aber einen Pager Alert senden.
*/
UTIL_ALERT_PAGER('TS Access Alert '‚ ||SYSDATE|| '
'||table_name);
END;
Der Event-Handler wird in der Audit-Policy folgendermaßen definiert:
DBMS_FGA.ADD_POLICY
(
object_shema
=> 'hr ',
object_name
=> 'employee ',
policy_name
=> 'audit_topsecret_employees ',
audit_condition => 'security_clearance = ' '
TOPSECRET ' ' ',
audit_column
=> 'ssn ',
handler_schema => 'hr ',
handler_module => 'ts_access_alert '
);
16
5; Syntax zu ADD.POLICY
Syntax
DBMS_FGA.ADD_POLICY(
object_schema
VARCHAR2,
object_name
VARCHAR2,
policy_name
VARCHAR2,
audit_condition VARCHAR2,
audit_column
VARCHAR2,
handler_schema VARCHAR2,
handler_module VARCHAR2,
enable
BOOLEAN,
statement_types VARCHAR2,
audit_trail
BINARY_INTEGER IN DEFAULT,
audit_column_opts BINARY_INTEGER IN DEFAULT);
Parameter
ADD_POLICY Procedure Parameters
Parameter
Description
object_schema
Default: NULL
Wenn NULL wird das effective User-Schema angenommen
object_name
Name des zu auditierenden Objektes
policy_name
Einzigartiger Name der Policy
audit_condition
Eine Bedingung in einer Zeile welches die zu überwachende
Bedingung angibt.
Default: NULL
audit_column
Die Spalten, die für den Zugriff überwacht warden sollen.
Schließt auch HIDDEN ein.
NULL bedeudet, Audit, wenn auf eine Spalte zugegriffen wird oder
wenn diese betroffen ist.
Default: NULL
handler_schema
Bezeichnet den Event-Handler. NULL bedeutet, dass das gegenwärtige
Schema verwendet wird.
Default: NULL
handler_module
Der FUNCTION-Name des Event-Handlers; schließt gegebenenfalls
den PACKAGE-Namen mit ein.
Diese Funktion wird nur aufgerufen, wenn die erste Reihe in der Query
aufgerufen wird. Im Falle einer Exception in der Prozedur, so wird das
SQL-Statement nicht ausgeführt.
Default: NULL
17
Parameter
Description
enable
Ermöglicht die Policy.
Default: TRUE
statement_types
SQL-Anweisungen in der Policy: INSERT, UPDATE, DELETE oder
SELECT
Default: SELECT
audit_trail
Um die Spalten LSQLTEXT und LSQLBIND in fga_log$ zu füllen
Default: DB_EXTENDED
audit_column_opts
Entscheidet darüber ob eine Anweisung auditiert wird, wenn die
Abfrage sich auf jede Spalte in dem audit_column Parameter bezieht.
Desgleichen, wenn auf alle Spalten referriert wird.
Default: ANY_COLUMNS
Beispiel:

Example:
DBMS_FGA.ADD_POLICY(
object_schema => 'scott',
object_name=>'emp',
policy_name => 'mypolicy1',
audit_condition => 'sal < 100',
audit_column =>'comm,
credit_card, expirn_date',
handler_schema => NULL,
handler_module => NULL,
enable => TRUE,
statement_types=> 'INSERT, UPDATE');
Eine FGA Policy sollte sich nie auf LOB-Spalten beziehen.
Die Audit-Function in HANDLER_MODE muß folgendes Interface aufweisen:
PROCEDURE <fname> ( object_schema VARCHAR2, object_name VARCHAR2,
policy_name VARCHAR2 ) AS ...
Hierbei ist fname der Name der Prozedur, object_shema ist der Name des Schemas für die zu
auditierende Tabelle, und policy_name ist der Name der Policy.
Jede Audit-Policy wird individuell auf die Abfrage angewendet, unabhängig davon wie viele Policy
konforme Zeilen zurückkommen.
In anderen Worten: Für jede Policy gibt es nur eine einzige Audit-Zeile.
Der View ALL_AUDIT_POLICIES enthät die Spalte audit_column_opts
betreffs der gesetzten Optionen.
18
6; VIEWS
select * from DBA_AUDIT_EXISTS
Datensätze für AUDIT EXISTS/NOT EXISTS
select * from DBA_AUDIT_OBJECT
Datensätze in Bezug auf Schema-Objekte
(DML- und DDL- Audit)
select * from DBA_AUDIT_POLICIES
wenn FGA angewendet wird
Support für mehr als eine relevante Spalte in FGA policy
in Version 9i Funktion für SELECT
in Version 10g zusätzlich Funktion für DML.
select * from DBA_AUDIT_SESSION
Alle Einträge zu An- und Abmeldungen
select * from DBA_AUDIT_STATEMENT
Datensätze für Anweisungs-Audit (GRANT, REVOKE, AUDIT,
NOAUDIT, ALTER SYSTEM)
select * from DBA_AUDIT_TRAIL
Alle Einträge des Audit-Trails
select * from DBA_AUDIT_TRAIL
Alle Einträge des Audit-Trails
select * from DBA_COMMON_AUDIT_TRAIL
zeigt alle XML_Einträge zu AUDIT_TRAIL
Liefert u.a. folgende Spalten:
AUDIT_TYPE,DB_USER,POLICY_NAME,SCN.
select * from DBA_OBJ_AUDIT_OPTS
Optionen für Schema-Objekt_Audit
select * from DBA_PRIV_AUDIT_OPTS
Optionen für Privileg-Audit
select * from DBA_STMT_AUDIT_OPTS
Optionen für Anweisungs-Audit
select * from ALL_DEF_AUDIT_OPTS
Default-Audit-Optionen
19
20