Activation, Configuration et Lecture de l'Audit Standard et Fin

  • Imprimer

Cet article a pour but d’expliquer ce qu’est l’audit sous notre SGBD préféré. Il s’applique donc aux bases Oracle de la version 10g à 11gR2 et à la 12cR1 dans le cas de la non activation de la nouveauté : audit unifié.

Il est important de comprendre comment l’audit s’active, et surtout comment on peut le configurer pour obtenir ce que l’on souhaite auditer. Bien souvent la mise en place de l’audit est un prérequis demandé par un client, par un projet mais bien souvent personne ne sait vraiment ce que l’on peut obtenir et ce que l’on veut obtenir. L’erreur serait d’ouvrir toute les vannes, d’activer l’audit tout azimut, cela génèrerait un flux important d’audit qui noierait l’information pertinente, générerait aussi peut être des problèmes de volumétrie d’audit, voire de performance. Il faut donc définir une stratégie d’audit avant le mettre en place et pour cela comprendre comment s’articule l’audit.

Remarque : Cet article ne traite que de l’audit dit Standard et Fin, c’est-à-dire celui fournit de base dans Oracle et expliqué dans la documentation Oracle Security. Il ne traite pas de l’audit provenant d’option Oracle : Oracle Database Vault, Oracle Label Security…

 

 

Audit  SYS et rôles administratifs

Par défaut en 11g et version antérieure, le compte SYS est audité mais uniquement sur l’action LOGON. Ce compte est le super utilisateur d’Oracle, il peut faire tout ce qu’il veut… sauf si Vault Database est installé et configuré. C’est donc un compte à auditer, il n’y a pas de question à se poser. Il est donc conseillé de mettre en place son audit en activant l’audit des comptes administratifs.

Mais en réalité cet audit n’audite pas particulièrement SYS comme souvent on le pense, il audite en fait les connexions sous rôle administratif c’est à dire en SYSDBA et SYSOPER pour les versions d’Oracle 11gR2 et précédentes, et aussi SYSBACKUP, SYSDG et SYSKM en 12c.

Sa mise en place est simple il suffit de passer le paramètre audit_sys_operations à TRUE. Les fichiers d’audit alors se trouverons obligatoirement en dehors de la base de données dans le répertoire correspondant au paramètre audit_file_dest. En fait ils se trouvent en dehors car cela permet de tracer les actions de SYSDBA par exemple même quand la base n’est pas OPEN et quand il est impossible d’écrire dans la base.

Cet audit n’est pas customisable. C’est du ON/OFF. Dès qu’il est activé toutes les actions des connexions SYS* sont auditées.

Pour l’activer il faut mettre audit_sys_operation à TRUE (remarque : En 12c elle est à TRUE par défaut). Cette variable n’est pas modifiable à chaud, il faut prévoir un redémarrage de la base.

SQL> show parameter audit
NAME                                      TYPE          VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest                      string      /oracle/oraBase/admin/TESTORA/adump
audit_sys_operations                 boolean     FALSE
audit_syslog_level                   string
audit_trail                          string      DB

SQL> alter system set audit_sys_operations=TRUE scope=spfile;

SQL> shutdown immediate

SQL> startup

Maintenant toutes les connexions et opérations en SYSDBA par exemple, sont loggés dans audit_file_dest (ici  /oracle/oraBase/admin/TESTORA/adump) :

[oracle@oradbm1 adump]$ tail -f TESTORA_ora_3180_1.aud
Mon Apr 25 17:08:27 2016 +02:00
LENGTH : '157'
ACTION :[6] 'COMMIT'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/1'
STATUS:[1] '0'
DBID:[9] '630020041'

Mon Apr 25 17:08:43 2016 +02:00
LENGTH : '170'
ACTION :[18] 'select * from dual'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'                                                                 
CLIENT TERMINAL:[5] 'pts/1'
STATUS:[1] '0'
DBID:[9] '630020041'

Mon Apr 25 17:09:08 2016 +02:00
LENGTH : '172'
ACTION :[17] 'grant dba to toto'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'                                                                                                                            
CLIENT TERMINAL:[5] 'pts/1'
STATUS:[4] '1917'
DBID:[9] '630020041'

Mais aussi les connexions en  SYSOPER :

Mon Apr 25 17:13:49 2016 +02:00
LENGTH : '162'
ACTION :[7] 'CONNECT'
DATABASE USER:[4] 'toto'
PRIVILEGE :[7] 'SYSOPER'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/1'
STATUS:[1] '0'
DBID:[9] '630020041'

Et aussi SYSBACKUP, SYSDG et SYSKM.

Il est possible de générer l’audit au format XML, il faut pour cela que le paramètre audit_trail soit égal à XML ou XML, EXTENDED. Mais ce paramètre influe aussi sur l’audit trail standard comme nous allons le voir ci-après.       

 

Audit Standard

 

Activation

L’audit standard permet d’auditer toutes les sessions hormis les sessions avec le privilège SYSDBA et SYSOPER en 11g et SYSBACKUP, SYSDG et SYSKM en plus en 12c.

Pour que cet audit soit activé il suffit que le paramètre audit_trail ne soit pas à NONE. Ce paramètre peut prendre comme valeur :

NONE : l’audit standard est désactivé

DB : L’audit standard est activé et il s’écrit dans la base de données dans la table SYS.AUD$. DB est la valeur par défaut. Aucun utilisateur ne peut lire SYS.AUD$ hormis ceux qui ont le privilège SELECT ANY DICTIONARY. Le privilège SELECT ANY TABLE ne permet pas de lire SYS.AUD$, ni aucune table SYS.*$ mais cela est vrai uniquement si la paramètre 07_DICTIONARY_ACCESSIBILITY est à FALSE (défaut).

DB, EXTENDED : Exactement comme DB, mais ce paramètre rajoute dans l’audit, donc dans la table SYS.AUD$, la requête , qui a déclenché l’audit, en entier (tout le DML pas juste le type de requête) et la valeur des binds variables s’il y en a.

OS : L’audit standard est activé et il s’écrit dans des fichiers texte (*.aud) sur l’operating systeme. Les informations stockées sont alors du même niveau que DB, EXTENDED c’est-à-dire toute la requête. Oracle recommande cette activation pour les bases les plus sensibles au niveau sécurité. Les fichiers alors générés iront dans le répertoire définit par la variable audit_file_dest vu dans la paragraphe précédent «Audit SYS et rôle administratif », à moins que vous n’activiez l’écriture dans la SYSLOG du système (UNIX/Linux environement seulement) avec la variable audit_syslog_level qui prend alors le dessus sur audit_file_dest.

XML : L’audit standard est activé et il s’écrit sur dans des fichiers au format XML sur l’operating systeme. Hormis le fait que les fichiers soient aux formats XML, la différence avec OS est qu’en plus l’audit standard reste consultable à partir de la base par requêtage sql, en effet les fichiers sont vus comme des tables externe et consultable entre autre par la vue SYS.V$XML_AUDIT_TRAIL, mais  aussi DBA_COMMON_AUDIT_TRAIL (qui agrège AUD$, les XML et l’audit fine grain) . Comme pour OS, audit_file_dest détermine l’emplacement des fichiers XML.

XML, EXTENDED : Comme XML mais rajoute la requête, qui a déclenché l’audit, en entier et la valeur des bind variables s’il y en a.

Remarque :
Si audit_trail est égal à OS alors un autre paramètre d’initialisation peut être activé : audit_syslog_level. Ce paramètre permet de rediriger l’audit vers une SYSLOG et donc par la même occasion rendre encore moins accessible l’audit car à priori seul root y a accès.

 

Configuration

OK, mais une fois activée, tout est loggé ?  Non et heureusement, surtout pour une base avec beaucoup de sessions actives. En général quand un client demande l’audit sur une base, il ne sait pas ce qu’il veut, alors il demande tout mais cela ne sert à rien de générer un audit pour chaque action. Est-ce important de tracer les un million de SELECT d’un compte utilisé uniquement par une application ? Non, il vaut mieux logger les connexions avec ce compte et s’assurer que toutes les connexions proviennent de serveur clairement identifié avec la couche applicative attendue. En fait le plus important est de savoir analyser le résultat. Mais ce n’est pas l’objet de ce paragraphe. Ici nous allons voir les différents niveaux de l’audit standard.

L’audit standard permet de logger des actions/instructions que l’on peut définir à plusieurs niveaux :

-          Audit système :

  • Au niveau de l’utilisation de privilège système (connect, select any table…)
  • Au niveau d’une instruction spécifique (alter table…)
  • Au niveau d’un compte utilisateur.

-          Audit objet :

  • Au niveau d’instructions accédant à un objet spécifique.

Mais il ne permet pas de logger des accès sur des colonnes particulières, c’est l’audit fin (Fine Grain Audit) qui le permet et on le verra plus loin.

Quand on active l’audit standard c’est-à-dire en mettant autre chose que NONE à la variable d’initialisation audit_trail, une configuration par défaut s’active. Cette configuration par défaut n’audite pas tous les actions produites sur la base de données et heureusement, on va dire que c’est le minimum au niveau sécurité qui s’active.

 

Audit système 

Pour visualiser ce qui est actuellement audité par l’audit standard au niveau audit système, cela peut se faire en interrogeant les vues dba_priv_audit_opts et dba_stmt_audit_opts.

Ci-dessous le résultat sur une base 11g avec l’audit standard par défaut sans modification :

SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from dba_priv_audit_opts order by 1,2 ;

USER_NAME               PRIVILEGE                SUCCESS    FAILURE
------------------------------ ---------------------------------------- ---------- ----------
                   ALTER ANY PROCEDURE          BY ACCESS  BY ACCESS
                   ALTER ANY TABLE              BY ACCESS  BY ACCESS
                   ALTER DATABASE               BY ACCESS  BY ACCESS
                   ALTER PROFILE                BY ACCESS  BY ACCESS
                   ALTER SYSTEM                 BY ACCESS  BY ACCESS
                   ALTER USER                   BY ACCESS  BY ACCESS
                   AUDIT SYSTEM                 BY ACCESS  BY ACCESS
                   CREATE ANY JOB               BY ACCESS  BY ACCESS
                   CREATE ANY LIBRARY           BY ACCESS  BY ACCESS
                   CREATE ANY PROCEDURE         BY ACCESS  BY ACCESS
                   CREATE ANY TABLE             BY ACCESS  BY ACCESS
                   CREATE EXTERNAL JOB          BY ACCESS  BY ACCESS
                   CREATE PUBLIC DATABASE LINK  BY ACCESS  BY ACCESS
                   CREATE SESSION               BY ACCESS  BY ACCESS
                   CREATE USER                  BY ACCESS  BY ACCESS
                   DROP ANY PROCEDURE           BY ACCESS  BY ACCESS
                   DROP ANY TABLE               BY ACCESS  BY ACCESS
                   DROP PROFILE                 BY ACCESS  BY ACCESS
                   DROP USER                    BY ACCESS  BY ACCESS
                   EXEMPT ACCESS POLICY         BY ACCESS  BY ACCESS
                   GRANT ANY OBJECT PRIVILEGE   BY ACCESS  BY ACCESS
                   GRANT ANY PRIVILEGE          BY ACCESS  BY ACCESS
                   GRANT ANY ROLE               BY ACCESS  BY ACCESS

23 rows selected.

SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE  from dba_stmt_audit_opts order by 1,2 ;

USER_NAME               AUDIT_OPTION                SUCCESS    FAILURE
------------------------------ ---------------------------------------- ---------- ----------
                   ALTER ANY PROCEDURE          BY ACCESS  BY ACCESS
                   ALTER ANY TABLE              BY ACCESS  BY ACCESS
                   ALTER DATABASE               BY ACCESS  BY ACCESS
                   ALTER PROFILE                BY ACCESS  BY ACCESS
                   ALTER SYSTEM                 BY ACCESS  BY ACCESS
                   ALTER USER                   BY ACCESS  BY ACCESS
                   CREATE ANY JOB               BY ACCESS  BY ACCESS
                   CREATE ANY LIBRARY           BY ACCESS  BY ACCESS
                   CREATE ANY PROCEDURE         BY ACCESS  BY ACCESS
                   CREATE ANY TABLE             BY ACCESS  BY ACCESS
                   CREATE EXTERNAL JOB          BY ACCESS  BY ACCESS
                   CREATE PUBLIC DATABASE LINK  BY ACCESS  BY ACCESS
                   CREATE SESSION               BY ACCESS  BY ACCESS
                   CREATE USER                  BY ACCESS  BY ACCESS
                   DATABASE LINK                BY ACCESS  BY ACCESS
                   DROP ANY PROCEDURE           BY ACCESS  BY ACCESS
                   DROP ANY TABLE               BY ACCESS  BY ACCESS
                   DROP PROFILE                 BY ACCESS  BY ACCESS
                   DROP USER                    BY ACCESS  BY ACCESS
                   EXEMPT ACCESS POLICY         BY ACCESS  BY ACCESS
                   GRANT ANY OBJECT PRIVILEGE   BY ACCESS  BY ACCESS
                   GRANT ANY PRIVILEGE          BY ACCESS  BY ACCESS
                   GRANT ANY ROLE               BY ACCESS  BY ACCESS
                   PROFILE                      BY ACCESS  BY ACCESS
                   PUBLIC SYNONYM               BY ACCESS  BY ACCESS
                   ROLE                         BY ACCESS  BY ACCESS
                   SYSTEM AUDIT                 BY ACCESS  BY ACCESS
                   SYSTEM GRANT                 BY ACCESS  BY ACCESS
28 rows selected.

Ci-dessous le résultat sur une base 12c avec l’audit standard par défaut sans modification :

SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from dba_priv_audit_opts;

no rows selected

SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE  from dba_stmt_audit_opts;

no rows selected

En 12c, il n’y a pas de configuration par défaut d’activer. En fait ce n’est pas entièrement vrai. Si on fait un select dans AUD$ il n’y aura aucune ligne d’audit mais en revanche dans UNIFIED_AUDIT_TRAIL il y aura des lignes :

SQL> select count(*) from dba_audit_trail;

  COUNT(*)
----------
     0

SQL> select count(*) from UNIFIED_AUDIT_TRAIL;

  COUNT(*)
----------
    10

Oracle a introduit avec la 12c la notion d’audit unifié que l’on verra dans un prochain article. Mais juste pour explication notre base 12c n’est pas en audit unifié pur (pure unified audit mode) mais en mode audit unifié mixte (mixted unified audit mode) :

SQL> select * from v$option where parameter like '%Unif%';

PARAMETER
----------------------------------------------------------------
VALUE                                     CON_ID
---------------------------------------------------------------- ----------
Unified Auditing
FALSE                                      0

Et quand la base n’est pas en audit unifié pur (comme dans le cas ci-dessus), alors quand on active l’audit standard, par défaut l’audit Standard et Fin n’audite rien, et l’audit unifié (le nouveau) audite quelque action. Dans la documentation 12c cet ancien audit est nommé : Traditional Auditing.

Revenons donc à l’audit tradicitonnel. La vue dba_priv_audit_opts donne la liste des privilèges systèmes qui sont audités, et la vue dba_stmt_audit_opts donne la liste des instructions qui sont audités. Il y a des recoupements comme par exemple le privilège CREATE SESSION et l’instruction CREATE SESSION. La subtilité est que l’audit d’un privilège système se déclenche si on passe par ce privilège, l’audit d’une instruction se déclenche quand on exécute cette instruction. 

Comme on peut le voir dans le résultat précédent des requêtes portant sur dba_priv_audit_opts et dba_stmt_audit_opts, la colonne user_name est vide, cela signifie que quel que soit la session qui exécute ou utilise un privilège de la liste, la session déclenchera un évènement dans l’audit standard.

Pour rajouter des nouvelles options d’audit ou en enlever, cela se fait avec la commande AUDIT/NOAUDIT. Et avec la commande AUDIT on peut aussi spécifier un compte particulier pour lequel on voudrait rajouter des audits.

Exemple : On veut auditer tous les updates du compte USERTEST :

SQL> AUDIT UPDATE TABLE BY USERTEST;

Audit succeeded.

SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE  from dba_stmt_audit_opts order by 1,2 ;

USER_NAME               AUDIT_OPTION                SUCCESS    FAILURE
------------------------------ ---------------------------------------- ---------- ----------
USERTEST               UPDATE TABLE                BY SESSION BY SESSION
                       ALTER ANY PROCEDURE         BY ACCESS  BY ACCESS
                       ALTER ANY TABLE             BY ACCESS  BY ACCESS
[...]
                       SYSTEM AUDIT                BY ACCESS  BY ACCESS
                       SYSTEM GRANT                BY ACCESS  BY ACCESS

29 rows selected.

La syntaxe de la commande audit en simplifé pour les cas les plus courant :

AUDIT privilege/statement [ ,privilege/statement ]
[ BY username [ , username] ]
[ BY < SESSION|ACCESS> ]
[ WHENEVER [NOT] SUCCESSFUL ]

BY SESSION : il n’y aura qu’un enregistrement dans l’audit pour les requêtes ou opérations identiques dans une même session, sauf pour les instructions DDL qui généreront autant de lignes que des fois que celles-ci seront exécutées.

BY ACCESS : il y aura un enregistrement à chaque déclenchement.

WHENEVER SUCCESSFUL : le déclenchement aura lieu uniquement si la requête ou l’opération se finit avec succès

WHENEVER NOT SUCCESSFUL : le déclenchement aura lieu uniquement si la requête ou l’opération se termine en erreur ou échec.

Mais alors si je veux l’écriture d’un audit que la requête soit en succès ou en échec ? Je mets quoi ? Et bien je ne mets rien, je ne mets pas [ WHENEVER [NOT] SUCCESSFUL ].

Pour la syntaxe de la commande AUDIT en détail voici les liens pour la 11gR2 et la 12c : syntaxe_audit_11g et syntaxe_audit_12c.

 

Audit objet

Pour l’audit des objets c’est la vue dba_obj_audit_opts  qui donne la liste des objets qui sont audités et sur quelles instructions ils le sont.

SQL> select * from dba_obj_audit_opts ;

no rows selected

…rien dans cette base 11g fraîchement installée.

Pour mettre en place l’audit d’un objet, c’est aussi la commande AUDIT comme pour l’audit système mais avec une syntaxe un peu différente.

Ci-dessous la syntaxe résumé/simplifié :

AUDIT statement [ ,statement ]
ON < [schema.]object | DEFAULT>
[ BY < SESSION|ACCESS> ]
[ WHENEVER [NOT] SUCCESSFUL ]

Comme précédemment pour la syntaxe complète : syntaxe_audit_11g et syntaxe_audit_12c.

Un exemple : mise en place de l’audit sur la table MATABLE pour toutes les opérations UPDATE, INSERT et DELETE.

SQL> audit update, insert, delete on USERTEST.MATABLE by ACCESS ;

Audit succeeded.

Maintenant si sur cette base de données nous interrogeons dba_obj_audit_opts :

select * from dba_obj_audit_opts ;

OWNER       OBJECT_NAME    OBJECT_TYPE  ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE CRE REA WRI FBK
---------- --------------- ------------ --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
USERTEST    MATABLE        TABLE        -/- -/- -/- A/A -/- -/- A/A -/- -/- -/- A/A -/- -/- -/- -/- -/- -/-

Il y a bien un enregistrement maintenant et les colonnes DEL pour DELETE, INS pour INSERT et UPD pour UPDATE contiennent A/A. Et cela se lit comme cela :
Audit_sur_succès / Audit_sur_échec
avec
- pour absence de d’audit
A pour audit sur ACCESS
S pour audit sur SESSION

Donc ici A/A dans la colonne DEL signifie que la table MATABLE du schéma USERTEST déclenche un audit à chaque tentative de DELETE sur elle et ce quel que soit le résultat de la commande DELETE : échec ou succès.
Et s’il y avait -/S dans la colonne DEL cela aurait signifié alors qu’il n’y aurait pas d’audit sur les DELETE qui réussiraient mais en revanche un audit pour ceux qui échoueraient. Et si dans une même session plusieurs DELETE échouaient, il n’y aurait qu’une ligne de générée dans l’audit car S de SESSION.

Remarque :
On peut définir un défaut d’audit d’objet pour que tout nouvel objet crée soit audité sur certaines opérations sans à avoir à exécuter la commande AUDIT après sa création. La vue all_def_audit_opts permet de visualiser ce "par défaut".

SQL> select * from all_def_audit_opts;

ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE FBK REA
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
-/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-

SQL> AUDIT ALTER ON DEFAULT BY ACCESS ;

Audit succeeded.

SQL> select * from all_def_audit_opts;

ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE FBK REA
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
A/A -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-

Maintenant tout nouvel objet créé déclenchera un enregistrement dans l’audit standard si un ALTER est fait dessus qu’il réussisse ou échoue.

 

Audit Fin

Audit Fin ou Fine Grained Audit en Anglais, pour une fois c’est plus court en Français  Wink. Plus sérieusement, l’audit fin permet de définir des conditions d’audit en fonction des données accédées, ce que ne permet pas l’audit standard. On peut même rajouter des conditions à son déclenchement qui n’ont rien à voir avec les données accédées comme par exemple l’horaire, la plage d’adresse IP, l’OS username… Et on peut aussi déclencher des actions comme par exemple l’envoi de mails. En revanche l’audit fin n’est disponible que dans la version Entreprise mais ne demande pas d’ "Extra Cost Option".

Le fine grained audit est un peu plus complexe à mettre en œuvre par rapport au standard audit. Il faut utiliser le package DBMS_FGA qui permet de créer/gérer des POLICY (politique de management).

Comme pour l’audit standard, le stockage de l’audit fin peut se faire en base ou sur fichier XML, mais en revanche pas dans les fichiers texte : *.aud. Ce paramétrage n’est pas dépendant du fichier d’initialisation de la base comme pour l’audit standard, il se fait dans la déclaration de la POLICY.

Un exemple vaut plus qu’un grand discourt, alors voici un bien concret :

Une table contenant des informations sur des clients :

create table crm.clients (id number, nom varchar2(50), prenom varchar2(50), ville varchar2(50), telephone  varchar2(50), adresse  varchar2(50)) tablespace users;

Un compte d’administration de l’audit fin (dba n'est pas obligatoire, il faut alors affiner les droits):

grant create session, dba to sysadmin_fga identified by oracle;
grant select on crm.clients to sysadmin_fga;
grant execute on dbms_fga to sysadmin_fga;
grant select on sys.fga_log$ to sysadmin_fga;

Et une POLICY sur la table CLIENTS :

connect sysadmin_fga/oracle
BEGIN
dbms_fga.add_policy(
object_schema => 'CRM',
object_name => 'CLIENTS',
policy_name => 'AUDIT_CLIENTS',
audit_condition => ' SYS_CONTEXT(''USERENV'',''OS_USER'') = ''oracle'' OR SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') != ''10.10.0.61'' ',
audit_column => 'NOM, TELEPHONE',
enable => TRUE,
statement_types => 'SELECT, DELETE',
audit_trail => dbms_fga.db + dbms_fga.extended,
audit_column_opts => dbms_fga.all_columns
);
END;
/

Cette POCLIY nommé AUDIT_CIENTS (policy_name => 'AUDIT_CLIENTS') permet de déclencher un enregistrement d’audit fin quand :

-          Une requête de SELECT ou de DELETE (statement_types => 'SELECT, DELETE') est faite

-          Sur la table CLIENTS (object_name => 'CLIENTS') du schéma CRM (object_schema => 'CRM')

-          A la condition que l’OS user soit oracle ou bien que l’adresse IP soit différente de 10.10.0.61 (audit_condition => ‘la condition)

-          Et que la requête utilise toutes les colonnes (audit_column_opts => dbms_fga.all_columns) suivante: NOM et TELEPHONE (audit_column => 'NOM, TELEPHONE').

-          Alors cet enregistrement sera stocké dans la base (audit_trail => dbms_fga.db + dbms_fga.extended) dans la table SYS.FGA_LOG$.

-          Et en plus cet enregistrement contiendra la requête en entier et pas juste le type de requête (audit_trail => dbms_fga.db + dbms_fga.extended)

 

Pour visualiser les POLICY de fine grained audit configurées sur la base de données, les vues dba_audit_policies  et dba_audit_policy_columns peuvent être interrogées :

SQL>  Select * from dba_audit_policy_columns

OBJECT_SCHEMA         OBJECT_NAME              POLICY_NAME             POLICY_COLUMN
------------------------------ ------------------------------ --------------------------
CRM                   CLIENTS                  AUDIT_CLIENTS           NOM
CRM                   CLIENTS                  AUDIT_CLIENTS           TELEPHONE

SQL>  select OBJECT_SCHEMA,OBJECT_NAME,POLICY_OWNER,POLICY_NAME,ENABLED,SEL,INS,UPD,DEL,AUDIT_TRAIL,POLICY_COLUMN_OPTIONS,POLICY_COLUMN,POLICY_TEXT from dba_audit_policies;

OBJEC OBJECT_NAM POLICY_OWNER     POLICY_NAME          ENA SEL INS UPD DEL AUDIT_TRAIL  POLICY_COLU POLICY_COLUMN
----- ---------- --------------- -------------------- --- --- --- --- --- ------------ ----------- ------------------------------
POLICY_TEXT
----------------------------------------------------------------------------------------------------
CRM   CLIENTS     SYSADMIN_FGA     AUDIT_CLIENTS          YES YES NO  NO  YES DB+EXTENDED  ALL_COLUMNS NOM
 SYS_CONTEXT('USERENV','OS_USER') = 'oracle' OR SYS_CONTEXT('USERENV','IP_ADDRESS') != '10.10.0.61'

 

Pour supprimer cette POLICY :

BEGIN
dbms_fga.drop_policy(
object_schema => 'CRM',
object_name => 'CLIENTS',
policy_name => 'AUDIT_CLIENTS');
END;
/

 

 

Lecture des audits

C’est bien beau de configurer les audits standard et fin mais faut-il aussi savoir les visualiser, sinon cela ne sert à rien. Le dessin ci-dessous, fait la synthèse des différentes sources.

 

 

Les différents audits se trouvent donc dans des tables ou bien des fichiers (voir une SYSLOG, non représenté dans le schéma) suivant le paramétrage expliqué dans le paragraphe activation pour l’audit.

Pour les tables AUD$ (audit standard) et FGA_LOG$ (audit fin) il est plus simple et convivial d’interroger leur vue respective DBA_AUDIT_TRAIL et DBA_FGA_AUDIT_TRAIL car elles font des jointures avec des tables de références, il est plus agréable d’avoir l’action (ex : UPDATE, ALTER SYSTEM) que le code action ( ex 6, 49…).

Si l’audit standard et/ou l’audit fin sont stockés dans des fichiers XML ils sont consultables dans la vue V$XML_AUDIT_TRAIL. Attention les performances de consultation peuvent être pauvre s’il y a de nombreux fichier XML.

Pour l’audit standard en mode OS, c’est-à-dire dans des fichiers textes *.aud, ainsi que pour l’audit SYS, la consultation n’est pas aisée, il est conseillé d’avoir un collecteur pour pouvoir browser dans les logs d’audit comme SPLUNK, LogLogic, Oracle Audit Vault (à ne pas confondre avec Vault Database)….

La vue DBA_COMMON_AUDIT_TRAIL permet, elle, d’ "unifié" en une seule vue les audits standard et fin sauf si le standard est de type OS ( fichier *.aud).

Et maintenant un exemple de ce que l’on peut trouver en lisant l’audit standard et audit fin et se servant de la vue DBA_COMMON_AUDIT_TRAIL.

SQL> select AUDIT_TYPE,SESSION_ID,to_char(EXTENDED_TIMESTAMP,'DD-MON-YY HH24:MI:SS'),DB_USER, OS_USER, USERHOST, COMMENT_TEXT,STATEMENT_TYPE, OBJECT_SCHEMA, OBJECT_NAME,RETURNCODE,SQL_TEXT from dba_common_audit_trail where EXTENDED_TIMESTAMP > trunc(sysdate)  order by EXTENDED_TIMESTAMP ;

Standard Audit           330120 13-MAY-16 22:14:33 SYSTEM         winroc    client.localdomain
Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.0.100)(PORT=54311))   LOGON                                         0


Fine Grained Audit       330120 13-MAY-16 22:23:17 SYSTEM         winroc    client.localdomain
                                                     SELECT              CRM          CLIENTS
select NOM,TELEPHONE from crm.clients where VILLE='PANAMA'


Standard Audit           330120 13-MAY-16 22:36:24 SYSTEM         winroc    client.localdomain
                                                     DELETE              SYS          AUD$                     0


Standard Audit           330120 13-MAY-16 22:37:41 SYSTEM         winroc    client.localdomain
                                                     LOGOFF                                         0


Standard Audit           330121 13-MAY-16 22:37:57 USERTEST         winroc    client.localdomain
Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.0.100)(PORT=54312))   LOGON                                         0


Standard Audit           330121 13-MAY-16 22:38:32 USERTEST         winroc    client.localdomain
                                                     DELETE              SYS          AUD$                  2004

 

Dans cet extrait on peut voir 2 choses intéressantes

-          que la session 330121 a tenté de faire un delete dans AUD$ et a eu en retour l’erreur ORA-2004, cela a été logé grâce à l’audit standard. Et on peut voir aussi que cette session provient de l’OS user winroc du serveur client.localdomain avec l’adresse IP 10.10.0.100 et il s’est connecté avec le compte oracle USERTEST.

-          que la session 330120 s’est intéressée au nom et numéro de téléphone de la ville Panama, voulait-il faire un listing pour le publier et en faire un LEAKS ? Wink. Toujours est-il que la session venait de l’OS user winroc du serveur client.localdomain avec l’adresse IP 10.10.0.100 et il s’est connecté avec le compte oracle SYSTEM.

 

Voilà nous avons fait le tour de de l’audit traditionnel (standard et fi) : activation, configuration et lecture. Il resterait à voir la purge mais cela sera peut-être dans un prochain article.