Oracle
 sql >> Base de données >  >> RDS >> Oracle

Sécurité de la base de données Oracle :audit de la base de données

Dans cet article, je continuerai avec Oracle Database Security et je présenterai quelques faits importants sur l'audit de base de données standard, les déclencheurs d'audit et les politiques d'audit dans Oracle. L'audit de base de données comporte deux composants :la surveillance et l'enregistrement persistant des ensembles d'activités et des événements de base de données établis. Les objectifs de l'audit de base de données sont la non-répudiation, l'investigation des activités suspectes, la détection des problèmes générés par les configurations concernant l'autorisation (accès aux ressources), le respect de la législation en vigueur et le contrôle.

Audit standard

Quelles activités auditons-nous ? Le démarrage et l'arrêt de la base de données ainsi que les connexions établies par l'administrateur de la base de données sont implicitement audités par Oracle et les données sont automatiquement stockées dans le système d'exploitation. Le tableau ci-dessous montre d'autres activités qui peuvent être surveillées :

Où conservons-nous les activités auditées ?

  • dans la base de données , en utilisant la piste d'audit de la base de données, où nous avons deux possibilités :
    • audit_trail =DB
      ce qui peut être fait avec le code suivant :

      alter system set audit_trail=db scope=spfile;
    • audit_trail =DB,EXTENDED
      en utilisant le code suivant :

      alter system set audit_trail= db, extended scope=spfile;

    La différence entre DB et DB,EXTENDED est que la seconde remplit les colonnes SQLBIND et SQLTEXT CLOB de la table SYS.AUD$.

  • externe , en utilisant la piste d'audit du système d'exploitation, avec les possibilités suivantes :
    • audit_trail =OS
      et le code utilisé est :

      alter system set audit_trail=os scope=spfile;
    • audit_trail =XML et AUDIT_FILE_DEST =chemin du fichier (implicitement est $ORACLE_BASE/admin/$ORACLE_SID/adump)
      avec le code :

      alter system set audit_trail=xml scope=spfile;

Afin de trouver la configuration actuelle des activités auditées stockées, on peut lancer la requête suivante, écrite en minuscule :

select value from v$parameter where name='audit_trail';

Commandes plus utiles :

[identifiant de table=43 /]

Voyons maintenant quelques exemples d'audit de base de données.

Voici un exemple d'audit standard avec des informations auditées stockées dans la base de données :

Les informations auditées sont constituées des instructions SELECT exécutées sur les tables de la base de données.

Dans SQL Developer, exécutez le script suivant :

alter system set audit_trail= db, extended scope=spfile;
AUDIT SELECT TABLE;

Ensuite, la base de données doit être redémarrée. Pour ce faire, dans le terminal SQLPlus, connectez-vous avec le nom d'utilisateur sys en tant que sysdba / password et exécutez les instructions suivantes :

SHUTDOWN IMMEDIATE
STARTUP

Notez que les tailles ci-dessus diffèrent d'un système à l'autre.

Pour vérifier si la piste d'audit est correctement définie, exécutez la requête suivante :

select value from v$parameter where name='audit_trail';

ou :

show parameter audit_trail;

Lorsque vous souhaitez arrêter l'audit, exécutez :

NOAUDIT SELECT TABLE;

Pour voir quelles déclarations ont été enregistrées par l'audit, vous pouvez utiliser :

select dbms_lob.substr( sqltext, 4000, 1 )
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS');

ou

select count(*), OBJ$NAME, USERID
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS')
group by rollup (OBJ$NAME, USERID);

Un autre exemple concerne l'audit standard avec des données auditées stockées dans un fichier XML, dans le chemin standard.

alter system set audit_trail=xml scope=spfile;
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees WHENEVER NOT
SUCCESSFUL;

Encore une fois, redémarrez la base de données :connectez-vous au terminal SQLPlus avec le nom d'utilisateur sys en tant que sysdba / mot de passe et exécutez les commandes SHUTDOWN IMMEDIATE et STARTUP.

Ensuite, chaque fois qu'une requête de sélection, d'insertion, de mise à jour et de suppression échoue sur la table des employés, elle doit être enregistrée dans le fichier XML.

Lorsque nous voulons arrêter l'audit, nous exécutons les commandes suivantes dans l'environnement de développement de la base :

NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

Et restaurez la piste d'audit par défaut :

alter system set audit_trail=db scope=spfile;

Vous trouverez ci-dessous un exemple d'une partie d'un fichier d'audit XML :

Comment supprimons-nous les informations auditées ?

Le volume des données auditées peut devenir très important en raison du nombre d'activités auditées et de leur fréquence. C'est pourquoi il est recommandé d'archiver périodiquement les données auditées et de les supprimer du système de production.

Si les données auditées sont stockées dans la base de données (piste d'audit de la base de données), nous pouvons utiliser des instructions de suppression (mais seulement après avoir archivé les données !) :

DELETE FROM SYS.AUD$;

Vous pouvez choisir de supprimer les informations auditées pour un objet de base de données spécifique, par exemple, une table appelée produits :

DELETE FROM SYS.AUD$ WHERE OBJ$NAME='PRODUCTS';

Déclencheurs d'audit

Un déclencheur est un bloc PL/SQL ou l'instruction CALL d'une procédure PL/SQL qui est automatiquement exécutée chaque fois qu'un événement se produit. Il existe deux types de déclencheurs :au niveau de la base de données (instructions de base de données) et au niveau de l'application (par exemple, appuyer sur un bouton d'un formulaire Oracle). Les déclencheurs utilisés pour l'audit sont les déclencheurs au niveau de la base de données. Ils se classent dans les catégories suivantes :

  • Déclencheurs DML :lorsqu'une instruction DML est déclenchée sur une table. Ces déclencheurs peuvent être exécutés une fois au niveau de la commande quel que soit le nombre d'enregistrements (déclencheurs au niveau de l'instruction) ou ils peuvent être exécutés POUR CHAQUE LIGNE (déclencheurs au niveau de l'enregistrement). Types de déclencheurs au niveau de l'enregistrement :AVANT LA DÉCLARATION, APRÈS LA DÉCLARATION, AVANT CHAQUE LIGNE, APRÈS CHAQUE LIGNE ;
  • Déclencheurs INSTEAD OF :lorsqu'une instruction DML est déclenchée sur une vue ;
  • Déclencheurs SYSTEM - déclenchés par des événements tels que le démarrage/l'arrêt de la base de données, les instructions DDL, la connexion/déconnexion de l'utilisateur. Types de déclencheurs système :APRÈS L'ÉVÉNEMENT, AVANT L'ÉVÉNEMENT.

Interroger le SYS.TRIGGER$ table ou le ALL_TRIGGERS view offre des informations sur tous les déclencheurs au niveau de la base de données. Par exemple, le type de déclencheur distinct de la base de données peut être trouvé comme suit :

SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;

La vue DBA_TRIGGERS offre des informations sur les déclencheurs créés automatiquement par les produits Oracle lors de l'installation. Si nous voulons trouver des informations sur les déclencheurs SYSTEM ("BEFORE EVENT" et "AFTER EVENT"), nous pouvons exécuter l'instruction suivante :

SELECT SUBSTR(OWNER,1,20) OWNER ,SUBSTR(TRIGGER_NAME,1,30),
TRIGGER_NAME, SUBSTR(TRIGGERING_EVENT,1,30) TRIGGERING_EVENT,
TRIGGER_TYPE
FROM DBA_TRIGGERS
WHERE TRIGGER_TYPE='BEFORE EVENT' OR TRIGGER_TYPE='AFTER EVENT'
ORDER BY TRIGGER_TYPE DESC;

De plus, lors de l'installation, des déclencheurs DML sont automatiquement créés sur le schéma utilisateur HR :

SELECT SUBSTR(TABLE_NAME,1,20) TABLE_NAME,
SUBSTR(TRIGGER_TYPE,1,30) TRIGGER_TYPE,TRIGGER_BODY
FROM DBA_TRIGGERS
WHERE OWNER='HR';

Pour l'audit, nous pouvons créer des déclencheurs personnalisés pour enregistrer les informations souhaitées, mais il convient de créer une table spéciale pour stocker les informations auditées.

Il est important de s'assurer que les déclencheurs développés n'influencent pas l'activité normale de la base de données. Le but de l'audit est de surveiller passivement l'activité normale de la base de données au jour le jour et de la stocker pour une analyse ultérieure. Par conséquent, il n'est pas recommandé de créer des déclencheurs INSTEAD OF pour renvoyer les résultats des tables cibles vers la table d'audit.

Les déclencheurs DML au niveau de l'instruction peuvent coexister avec les déclencheurs DML au niveau de l'enregistrement. L'ordre d'appel est :

  • déclencher l'instruction AVANT
  • pour chaque enregistrement affecté
    • déclencher AVANT l'enregistrement
    • action DML en cours
    • déclencher APRÈS l'enregistrement
  • déclencher l'instruction AFTER

Les déclencheurs définis par l'utilisateur ne seront exécutés que si, selon Oracle, l'instruction est correcte et peut se produire. Pour une instruction DML erronée ou qui viole une contrainte, une erreur sera renvoyée et le déclencheur ne sera pas exécuté. Par conséquent, pour l'audit, il est recommandé d'utiliser en particulier les déclencheurs LMD au niveau de l'instruction.

Exemple de déclencheur d'audit :

Supposons que nous voulions créer un déclencheur pour enregistrer dans une table d'audit (appelée TAB_AUDIT_EMP) des informations sur les déclarations DML qui établissent des salaires supérieurs à 20000 (la devise n'est pas importante ici) pour les employés de l'entreprise. Nous voulons stocker dans TAB_AUDIT_EMP le numéro de séquence de la requête, le nom d'utilisateur, la session, l'hôte et la date.

Cela peut être fait avec ce qui suit :

CREATE TABLE TAB_AUDIT_EMP

(secv_id NUMBER(3) PRIMARY KEY,
username VARCHAR2(20),
session_nr NUMBER(10),
hostname VARCHAR2(100),
query_date DATE
);

CREATE SEQUENCE secv_aud_emp START WITH 1 INCREMENT BY 1;
CREATE OR REPLACE TRIGGER huge_salary
AFTER INSERT OR UPDATE OR DELETE OF SALARY ON EMPLOYEES
FOR EACH ROW WHEN (NEW.salary>20000)
BEGIN
INSERT INTO TAB_AUDIT_EMP
VALUES(secv_aud_emp.NEXTVAL , sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'), sys_context('userenv', 'host'), sysdate);
END;

Supposons que nous procédions à une modification de salaire pour les employés d'un service spécifique :

UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

Et puis nous vérifions le suivi :

select secv_id, substr(username,1,20) username, session_nr, substr(hostname,1,30) hostname, query_date
from TAB_AUDIT_EMP;

Règles d'audit

La troisième méthode d'audit fait référence aux politiques d'audit. La définition d'une stratégie d'audit contient les éléments suivants :

  • spécification de l'objet (schéma, nom de l'objet, colonnes) soumis à la surveillance
  • spécification des actions auditées pour un objet (SELECT, INSERT, UPDATE, DELETE) :implicitement c'est SELECT
  • spécification des conditions qui doivent être remplies pour enregistrer les informations auditées, cela se fait dans la clause WHEN du déclencheur et est facultatif
  • un gestionnaire d'événements qui gère en plus l'événement, ce qui est facultatif.

Une stratégie d'audit peut être active (état ENABLED) ou inactive (état DISABLED). La liste des politiques d'audit peut être obtenue en interrogeant la vue ALL_AUDIT_POLICIES :

SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

Pour l'administration de la stratégie d'audit, nous avons le package DBMS_FGA. Pour utiliser ce package, il est nécessaire d'accorder des privilèges aux utilisateurs qui écriront du code PL/SQL :

grant execute on dbms_fga to username;

Exemple de stratégie d'audit :

Nous souhaitons créer une stratégie d'audit pour enregistrer les instructions DML qui modifient les responsables (MANAGER_ID) dans la table DEPARTMENTS. Nous pouvons choisir de créer un gestionnaire pour la politique, appelé proc_audit_alert, qui nous informe d'une modification concernant le gestionnaire :

CREATE OR REPLACE PROCEDURE proc_audit_alert ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Alert! Manager Changed !');
END;

Et la politique peut être :

CREATE OR REPLACE PROCEDURE proc_audit_manager AS
BEGIN
DBMS_FGA.ADD_POLICY
(
object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager',
audit_column=>'ID_MANAGER',
enable=>false,
statement_types=>'UPDATE',
handler_module=>'proc_audit_alert'
);
DBMS_FGA.ENABLE_POLICY
( object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager');
END;

Notez que object_schema, object_name, policy_name, audit_column, statement_types et handler_module doivent être adaptés à la stratégie que vous souhaitez écrire.

Ensuite, on exécute la procédure :

EXECUTE proc_audit_manager;

Nous pouvons vérifier si la règle est activée :

SELECT ENABLED, POLICY_NAME
FROM ALL_AUDIT_POLICIES
WHERE OBJECT_NAME='DEPARTMENTS';

Ensuite, vérifiez si la procédure et la politique fonctionnent correctement, en exécutant une mise à jour :

UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;

En conclusion, l'audit est nécessaire pour chaque base de données et les méthodes fournies ci-dessus vous aident à trouver une activité suspecte qui pourrait affecter la sécurité de votre base de données. Pour plus de détails sur l'audit de la base de données Oracle, consultez la bibliographie ci-dessous.

Bibliographie :

  • http://www.datadisk.co.uk/html_docs/oracle/auditing.htm
  • http://docs.oracle.com/cd/B10501_01/server.920/a96521/audit.htm
  • https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000