chapitre 4 dba

Un système sécurisé garantit…

La confidentialité des données qu'il contient

Aspects de la sécurité d'une BD (4)

Authentifier les utilisateurs ; gérer les utilisateurs et les profils ; limiter l'accès aux données et aux services (principe du moindre privilège) ; surveiller les activités suspectes (audit)

Pourquoi auditer ?

Même autorisés, les utilisateurs authentifiés peuvent parfois compromettre le système : il faut surveiller les activités suspectes

Principe du moindre privilège

N'accorder à un utilisateur que les privilèges dont il a réellement besoin pour effectuer une tâche de manière efficace

Les 4 mesures liées au moindre privilège

Protéger le dictionnaire de données ; révoquer les privilèges non nécessaires du rôle PUBLIC ; limiter les utilisateurs dotés de privilèges d'administration ; limiter/désactiver l'authentification à distance

Comment protéger le dictionnaire de données ?

Mettre le paramètre O7_DICTIONARY_ACCESSIBILITY à FALSE

O7_DICTIONARY_ACCESSIBILITY = FALSE : effet n°1

Empêche les utilisateurs dotés d'un privilège système "ANY TABLE" d'accéder aux tables de base du dictionnaire de données

O7_DICTIONARY_ACCESSIBILITY = FALSE : effet n°2

Empêche l'utilisateur SYS de se connecter sous un autre compte que SYSDBA

Pourquoi révoquer des privilèges du rôle PUBLIC ?

N'importe quel utilisateur de la BD peut utiliser les privilèges accordés à PUBLIC : il faut révoquer ceux qui ne sont pas indispensables

Packages dont EXECUTE doit toujours être révoqué de PUBLIC

UTL_SMTP, UTL_HTTP, UTL_FILE

Danger de UTL_SMTP accordé à PUBLIC

Permet l'envoi de messages électroniques arbitraires (la BD sert de serveur SMTP) : échange non autorisé d'e-mails

Danger de UTL_HTTP accordé à PUBLIC

Permet au serveur de BD de demander/extraire des données via HTTP : possibilité d'envoyer des données à un site web malveillant via HTML

Danger de UTL_FILE accordé à PUBLIC

Mal configuré : accès texte à n'importe quel fichier de l'OS. Même bien configuré : ne distingue pas les applications appelantes (une appli peut écrire au même endroit qu'une autre)

Commande pour révoquer UTL_FILE, UTL_HTTP, UTL_SMTP de PUBLIC

REVOKE EXECUTE ON utl_file, utl_http, utl_smtp FROM PUBLIC;

Types de privilèges à limiter (administrateurs)

L'octroi des privilèges système et objet ; les connexions avec les privilèges SYS (SYSDBA et SYSOPER) ; les privilèges de type DBA (ex : DROP ANY TABLE)

Lister tous les utilisateurs ayant le rôle DBA

SELECT grantee FROM dba_role_privs WHERE granted_role = 'DBA';

Lister les utilisateurs ayant SYSDBA ou SYSOPER

SELECT * FROM V$PWFILE_USERS; (colonnes USERNAME, SYSDBA, SYSOPER)

Quelle vue pour les utilisateurs SYSDBA/SYSOPER ?

V$PWFILE_USERS

Quelle vue pour lister les bénéficiaires d'un rôle (ex : DBA) ?

DBA_ROLE_PRIVS

Quand utiliser l'authentification à distance par l'OS ?

Seulement quand on fait confiance à tous les clients pour authentifier correctement les utilisateurs

Processus d'authentification à distance (3 étapes)

1) L'utilisateur de BD est authentifié en externe ; 2) Le système distant authentifie l'utilisateur ; 3) L'utilisateur se connecte à la BD sans authentification complémentaire

Comment désactiver l'authentification à distance ?

Vérifier que REMOTE_OS_AUTHENT = FALSE (valeur par défaut)

Valeur par défaut de REMOTE_OS_AUTHENT

FALSE

Paramètre O7_DICTIONARY_ACCESSIBILITY vs REMOTE_OS_AUTHENT

O7_DICTIONARY_ACCESSIBILITY = FALSE protège le dictionnaire. REMOTE_OS_AUTHENT = FALSE désactive l'authentification à distance par l'OS

Les 3 outils d'audit intégrés d'Oracle

1) Audit standard (audit de la BD) ; 2) Audit par trigger (audit basé sur les valeurs/données) ; 3) Fine Grained Auditing, FGA (audit détaillé, à partir de 8i, pas dispo sur toutes les versions)

Audit standard : événements audités et contenu de la trace

Événements : utilisation des privilèges, notamment l'accès aux objets. Trace : ensemble fixe de données

Audit basé sur les données : événements audités et contenu de la trace

Événements : données modifiées par les instructions LMD. Trace : définie par l'administrateur

Audit détaillé (FGA) : événements audités et contenu de la trace

Événements : instructions SQL (INSERT, UPDATE, DELETE, SELECT) en fonction du contenu. Trace : ensemble fixe de données, incluant l'instruction SQL

Tableau comparatif des 3 audits : "contenu de la trace"

Standard = ensemble fixe de données. Basé sur les données = défini par l'administrateur. Détaillé (FGA) = ensemble fixe incluant l'instruction SQL

Audit standard : fonctionnement (schéma)

Le DBA active l'audit (fichier de paramètres) et définit les options d'audit ; l'utilisateur exécute une commande ; le processus serveur génère la trace d'audit (dans la BD ou dans l'OS) ; le DBA examine/gère la trace

Paramètre qui active l'audit standard

AUDIT_TRAIL

AUDIT_TRAIL = NONE

Désactive la collecte des enregistrements d'audit

AUDIT_TRAIL = OS

Active l'audit ; enregistrements stockés dans la trace d'audit du système d'exploitation (emplacement défini par AUDIT_FILE_DEST)

AUDIT_TRAIL = DB

Active l'audit ; enregistrements stockés dans la table système de la BD SYS.AUD$

AUDIT_TRAIL = DB, EXTENDED

Comme DB, mais les colonnes SQLBIND et SQLTEXT de SYS.AUD$ sont aussi renseignées

AUDIT_TRAIL = XML

Active l'audit ; enregistrements stockés dans des fichiers au format XML dans la trace d'audit de l'OS

AUDIT_TRAIL = XML, EXTENDED

Comme XML, avec les colonnes SQLBIND et SQLTEXT renseignées

Les 6 valeurs de AUDIT_TRAIL

NONE, OS, DB, DB EXTENDED, XML, XML EXTENDED

Paramètre AUDIT_FILE_DEST

Définit l'emplacement du fichier de trace d'audit quand AUDIT_TRAIL = OS

Table qui stocke l'audit en mode DB

SYS.AUD$ (dans le tablespace SYSTEM)

Afficher la valeur de audit_trail

SHOW PARAMETER audit (affiche audit_file_dest, audit_sys_operations, audit_trail)

Changer audit_trail avec un PFILE

Il suffit d'éditer le contenu du fichier

Changer audit_trail avec un SPFILE

ALTER SYSTEM SET audit_trail=DB SCOPE=SPFILE; (puis redémarrer, car statique)

Audit OS : avantage et limite

Avantage : auditer plusieurs BD vers une même destination (un seul rapport). Limite : pas tous les OS le permettent (Unix)

Audit DB : avantage

Résultats visibles par de simples requêtes sur les vues du dictionnaire relatives à l'audit

Audit DB : limites (2)

SYS.AUD$ (tablespace SYSTEM) doit être archivée et purgée périodiquement (volumineuse) ; elle doit être protégée sinon un utilisateur malveillant peut y effacer ses actions non autorisées

Protéger SYS.AUD$ : solution

Auditer toutes les actions sur cette table : AUDIT ALL ON SYS.AUD$ BY ACCESS;

Les 4 niveaux d'audit standard

Audit de commandes (LDD) ; audit de privilèges (système) ; audit d'objets de schéma (privilèges objet) ; audit de connexion (session)

Syntaxe AUDIT de commandes/privilèges système

AUDIT {commande | privilège système} [, …] [BY user [, user]…] [BY {SESSION | ACCESS}] [WHENEVER [NOT] SUCCESSFUL];

Syntaxe AUDIT d'objets

AUDIT commande [, commande]… ON {[schema.]objet | DEFAULT} [BY {SESSION | ACCESS}] [WHENEVER [NOT] SUCCESSFUL];

BY SESSION

Oracle n'insère qu'UN enregistrement par objet de BD et par session, quel que soit le nombre de commandes SQL du même type

BY ACCESS

Oracle insère un enregistrement dans la trace chaque fois qu'une action est soumise

BY SESSION vs BY ACCESS

SESSION = 1 enregistrement par objet et par session. ACCESS = 1 enregistrement à chaque action

Audit des commandes DDL : SESSION ou ACCESS ?

Oracle audite toujours les commandes DDL BY ACCESS

WHENEVER [NOT] SUCCESSFUL

Audit déclenché seulement selon la réussite (WHENEVER SUCCESSFUL) ou l'échec (WHENEVER NOT SUCCESSFUL) de l'exécution de la commande SQL

Audit de commande NON ciblé (exemple)

AUDIT table; (audite toute instruction LDD qui affecte une table)

Audit de commande CIBLÉ (exemple)

AUDIT TABLE BY hr WHENEVER NOT SUCCESSFUL;

Audit de privilèges système NON ciblé (exemple)

AUDIT select any table, create any trigger;

Audit de privilèges système CIBLÉ (exemple)

AUDIT select any table BY hr BY SESSION;

Audit de privilèges objet NON ciblé (exemple)

AUDIT ALL ON hr.employees;

Audit de privilèges objet CIBLÉ (exemple)

AUDIT UPDATE, DELETE ON hr.employees BY ACCESS;

Audit de session (exemple)

AUDIT session WHENEVER NOT SUCCESSFUL; (audite les connexions échouées)

Désactiver l'audit d'une session

NOAUDIT session; ou NOAUDIT session BY scott, lori;

Désactiver tous les audits de commandes et privilèges

NOAUDIT ALL; ou NOAUDIT ALL PRIVILEGES;

Désactiver l'audit d'un objet

NOAUDIT DELETE ON emp; ou NOAUDIT SELECT, INSERT, DELETE ON jward.dept; ou NOAUDIT ALL ON emp; (toutes les options sur la table)

Privilège nécessaire pour désactiver l'audit de commandes/privilèges

Le privilège système AUDIT SYSTEM

Commande pour arrêter un audit

NOAUDIT (même syntaxe que AUDIT)

Vue DBA_AUDIT_TRAIL

Toutes les entrées de la trace d'audit

Vue DBA_AUDIT_OBJECT

Enregistrements concernant les objets de schémas

Vue DBA_AUDIT_SESSION

Toutes les entrées de connexion et de déconnexion

Vue DBA_AUDIT_STATEMENT

Enregistrements d'audit des instructions

Quelle vue pour les connexions/déconnexions auditées ?

DBA_AUDIT_SESSION

Pourquoi l'audit standard ne suffit pas ?

Il identifie les commandes exécutées sur une table mais ne fournit pas d'informations sur les modifications faites (valeurs). Pour garder trace des modifications : audit basé sur les données avec des triggers

Audit basé sur les données : fonctionnement

Un utilisateur fait une modification -> un déclencheur (trigger) s'exécute -> la modification est effectuée et un enregistrement d'audit est créé par le déclencheur et inséré dans une table de trace d'audit

Les 2 types de triggers pour l'audit

DML trigger et System trigger

DML trigger (audit)

Enregistre les valeurs de toutes les modifications apportées à la BD. Impossible avec l'audit intégré d'Oracle

System trigger (audit)

Audite toute action de création, suppression ou connexion à la base. Inutile car l'audit intégré d'Oracle le fait déjà

Quel trigger est utile pour l'audit et pourquoi ?

Le DML trigger : il enregistre les valeurs modifiées, ce que l'audit intégré ne peut pas faire

Syntaxe CREATE TRIGGER

CREATE [OR REPLACE] TRIGGER nom {BEFORE|AFTER|INSTEAD OF} {INSERT|UPDATE [OF col]|DELETE} [OR …] REFERENCING {OLD [AS] ancien | NEW [AS] nouveau} ON table [FOR EACH ROW] [WHEN (condition)] DECLARE … BEGIN … [EXCEPTION] END;

Audit détaillé (FGA) : définition

Fine Grained Auditing : permet de définir des conditions fines pour l'audit

FGA : 5 caractéristiques

Surveille l'accès aux données en fonction du contenu ; audite SELECT ou INSERT/UPDATE/DELETE ; peut être lié à une table ou une vue ; peut exécuter une procédure PL/SQL ; administré via le package DBMS_FGA

Package qui administre l'audit détaillé

DBMS_FGA (il faut avoir le privilège EXECUTE sur ce package)

Stratégie d'audit détaillé : 2 parties

Les critères d'audit (condition à vérifier pour que l'instruction soit auditée) et l'action d'audit (nom d'une procédure exécutée quand la condition est vérifiée)

Comment créer une stratégie FGA ?

Avec la procédure ADD_POLICY du package DBMS_FGA

DBMS_FGA.ADD_POLICY

Crée une stratégie d'audit à l'aide du prédicat fourni comme condition d'audit

DBMS_FGA.DROP_POLICY

Supprime une stratégie d'audit

DBMS_FGA.ENABLE_POLICY

Active une stratégie d'audit

DBMS_FGA.DISABLE_POLICY

Désactive une stratégie d'audit

Sous-programmes de DBMS_FGA

ADD_POLICY, DROP_POLICY, ENABLE_POLICY, DISABLE_POLICY

Paramètres de ADD_POLICY (exemple du cours)

object_schema, object_name, policy_name, audit_condition, audit_column, handler_schema, handler_module, enable, statement_types

ADD_POLICY : audit_condition

Condition (prédicat) qui doit être vérifiée pour que l'instruction soit auditée (ex : 'dept_id=10')

ADD_POLICY : audit_column

Colonne dont l'accès déclenche l'audit (ex : 'salary')

ADD_POLICY : handler_schema et handler_module

Schéma et nom de la procédure exécutée quand la condition est vérifiée (l'action d'audit)

ADD_POLICY : enable

TRUE/FALSE : active ou non la stratégie dès sa création

ADD_POLICY : statement_types

Types d'instructions auditées (ex : 'select')

Exemple du cours : stratégie audit_emps_salary

SELECT name, salary FROM employees WHERE department_id = 10 est audité (appelle SECURE.LOG_EMPS_SALARY) ; SELECT name, job_id FROM employees n'est PAS audité

Syntaxe enable_policy / disable_policy / drop_policy

dbms_fga.enable_policy (object_schema => 'hr', object_name => 'employees', policy_name => 'audit_emps_salary'); idem pour disable_policy et drop_policy

Vue DBA_FGA_AUDIT_TRAIL

Tous les événements d'audit détaillé

Vue ALL_AUDIT_POLICIES

Toutes les stratégies d'audit détaillé pour les objets auxquels l'utilisateur actuel peut accéder

Vue DBA_AUDIT_POLICIES

Toutes les stratégies d'audit détaillé dans la base de données