Les Bases de données sont des depôts d’informations importantes et secretes de l’entreprise. Dans plusieurs organizations les bases de données sont mal protegées ,il faut qu’il soivent les plus securisées que les autres systemes existant dans l’oragnisation ,c’est à dire il faut assurer l’integrité et la confidentialité de nos données .

1. La sécurité dans les Bases de
Données
Année Universitaire 2014 – 2015
Réalisé par : ABBAD Zakariae
HIRCHOUA Badr
Master :SIRM1

2. LA GESTION DES PRIVILÈGES
LES TRANSACTIONS
DUPLICATION
REPRISE EN CAS D’INCIDENT
L'AUDIT
LE CRYPTAGE D’INFORMATIONS
CONCLUSION
PLAN
8
INTRODUCTION1
2
3
4
5
6
7
2

3. INTRODUCTION
3
Les Bases de données sont des depôts d’informations importantes et
secretes de l’entreprise.
Dans plusieurs organizations les bases de données sont mal protegées ,il
faut qu’il soivent les plus securisées que les autres systemes existant
dans l’oragnisation ,c’est à dire il faut assurer l’integrité et la
confidentialité de nos données .

4. la gestion des
privilèges
4

5. Processus de contrôle
5

6. Privilèges
 On distingue :
les privilèges objets qui concernent des opérations précises sur des tables, des vues …
les privilèges systèmes qui concernent des opérations sur tous les objets d’un certaine
catégorie.
6
Ces privilèges varient sensiblement d’un SGBD à l’autre.
Privilèges système
 Par exemple :
 INSERT ANY TABLE
 DELETE ANY INDEX
Privilèges objets
 SELECT
 INSERT
 UPDATE
 DELETE
 TRIGGER
 USAGE
 EXECUTE

7. Octroi ou révocation de privilèges
 SQL offre deux commandes pour octroyer ou révoquer des privilèges :
 GRANT
 REVOKE
7

8. Règles des privilèges
 Règle d’octroi des privilèges
 Un utilisateur ne peut octroyer que les privilèges qu’il possède.
 Règles de révocation des privilèges
 Un utilisateur ne peut révoquer que les privilèges qui lui ont été transmis.
 Si l’option CASCADE est spécifiée, la révocation d’un privilège est récursive.
 Si l’option RESTRICT est spécifiée, la révocation d’un privilège à un utilisateur n’est
possible que si celui-ci n’a pas transmis ce privilège à un autre utilisateur.
 Si un utilisateur a reçu un privilège de plusieurs utilisateurs, il ne perd ce privilège que
si tous ces utilisateurs le lui retirent.
8

9. Octroi de privilèges : exemple
9
Adil : GRANT SELECT ON departement TO ossama WITH GRANT OPTION;
Adil : GRANT SELECT ON departement TO badr WITH GRANT OPTION;
Ossama : GRANT SELECT ON departement TO zakariae WITH GRANT OPTION;
badr : GRANT SELECT ON departement TO zakariae WITH GRANT OPTION;
zakariae : GRANT SELECT ON departement TO said;
ADIL
SELECT
ON departement*
Ossama
badr
SELECT
ON departement*
zakariae said
SELECT
ON departement*
SELECT
ON departement*
SELECT
ON departement*
* indique que le privilège a été accordé WITH GRANT OPTION.

10. Révocation en cascade : exemple
ADIL
SELECT
ON departement*
Ossama
badr
SELECT
ON departement*
zakariae said
SELECT
ON departement*
SELECT
ON departement*
SELECT
ON departement*
ADIL
Ossama
badr
SELECT
ON departement*
zakariae said
SELECT
ON departement*
Adil : REVOKE SELECT ON département FROM oussama CASCADE
10

11. Révocation avec restriction : exemple
ADIL zakariae said
SELECT
ON departement*
SELECT
ON departement*
ADIL : REVOKE SELECT ON département FROM zakariae RESTRICT
ADIL zakariae saidSELECT
ON departement*
ZAKARIAE : REVOKE SELECT ON département FROM SAID RESTRICT
11

12. Importance des vues
par exemple, si la BD est formée de la table : EMPLOYE(NOM, DEPARTEMENT, SALAIRE)
on pourra restreindre l’accès à l’affectation ou au salaire d’un employé en
définissant les deux vues suivantes :
• CREATE VIEW AFFECTATION_EMPLOYE(NOM, DEPARTEMENT) AS SELECT NOM,
DEPARTEMENT FROM EMPLOYE
• CREATE VIEW SALAIRE_EMPLOYE(NOM, SALAIRE) AS SELECT NOM, SALAIRE
FROM EMPLOYE
12
 Les vues jouent un rôle important car elles permettent de définir de façon précise
les portions d’une BD sur lesquelles des privilèges sont accordés.
• et en accordant des privilèges sur chacune de ces deux vues, par exemple :
 GRANT UPDATE ON SALAIRE_EMPLOYE TO Badr ;

13. Rôles
 Un rôle est un ensemble de privilèges.
 Les rôles sont assignés aux utilisateurs qui peuvent avoir plusieurs rôles.
 Les rôles sont organisés hiérarchiquement.
 Il ne faut pas confondre rôle et utilisateur :
 un utilisateur peut être propriétaire d’un objet, un rôle ne le peut pas.
13

14. les transactions
14

15. Les Transactions
Définitions
15
 Nous appellerons transaction tout programme qui accède à la base ou qui en
modifie le contenu, c’est-à-dire qui réalise une suite d’opérations de lecture et
d’écriture dans la base.
 Une transaction est soit validée par un commit, soit annulée par un rollback, soit
interrompue par un abort,
 Une transaction a une marque de début (Begin Of Transaction BOT), et une
marque de fin (End Of Transaction EOT)

16. Gestion des transactions
 Un gérant de transactions a pour rôle de
contrôler l’exécution de transactions et
il doit assurer les propriétés dites :
1
2
3
4
16
Début Transaction
Action1; Action 2 ; Action3 ; …
Si toutes les Actions sont correctement exécutées
Alors Valider la transaction (commit)
Sinon Annuler ses effets (rollback)
Finsi
Fin Transaction

17. Les Techniques de contrôle de la concurrence
17
VERROUILLAGE
 On peut considérer un verrou comme une variable associée à un granule et dont la valeur
spécifie les opérations autorisées sur le granule, le granule étant l’unité de verrouillage et
pouvant concrètement être la base de données, une relation ou une partie de relation, un tuple, un
attribut, etc
 Un verrou binaire est un verrou à deux états : quand il est apposé sur un granule, celui-ci est
accessible ou inaccessible
 Autres type de verrou

18. PROBLEMES DE VERROUILLAGE.
 l’INTERBLOCAGE est causé par des attentes mutuelles. Il se produit lorsqu’une transaction T1 détient un
granule G1 et attend qu’une transaction T2 libère un granule G2, et qu’en même temps, T2 détient G2 et
attend la libération de G1. La solution à ce type de situation est soit de l’empêcher de se produire soit de
le détecter et d’y remédier .
 La détection consiste à tester périodiquement si une situation d’interblocage s’est produite .
 LA SITUATION DE FAMINE se produit lorsqu’une transaction est perpétuellement en attente alors que
d’autres continuent à s’exécuter . C’est le cas, par exemple, lorsqu’un granule est verrouillé en mode
partagé par une première transaction T1 : une transaction T2 désirant modifier ce granule est mise en
attente tandis que de nouvelles transactions de lecture pourront elles acquérir un verrou partagé sur le
granule et donc s’exécuter, augmentant ainsi le temps d’attente de T2.
18

19. Journalisation de transactions et reprises
 la reprise en cas d’incident va au-delà du simple échec des transactions. Elle est également requise
dans le cas d’incidents “logiques” (panne du serveur de données ou du système d’exploitation
hôte) ou “physiques” (défaillance du matériel, détérioration d’un support de stockage, etc.). Dans
nombre de cas d’échec ou d’incident, le système pourra remettre la base en état s’il dispose de
suffisamment d’informations sur les activités qui ont précédé le moment de l’incident :
 ces informations sont disponibles dans le journal (ou log) des transactions sous la forme d’une
trace des opérations effectuées sur la base. Ce journal sert tant pour l’annulation des transactions
en cas d’échec que pour la remise en état d’une base en cas d’incident d’une autre nature.
19

20. Journalisation et point de contrôle
 Le journal d’une base est un (ou plusieurs) espace physique non volatile (disque, bande)
associé à une base de données. Il doit être archivé périodiquement en synchronisation avec
des sauvegardes de l’espace des données.
 Pour chaque transaction T , il comporte des informations du type :
– < identification de T , début >;
– <identification de T , écriture, donnée concernée, ancienne valeur, nouvelle valeur >;
– < identification de T , lecture, donnée concernée> ;
– <identification de T , commit >
 L ’information <identification de T , commit > est inscrite dans le log au point de
validation de la transaction T
20

21. Les points de contrôle sont d’autres types d’information du journal. Ils y sont inscrits
périodiquement. À l’issue de chaque période, le système suspend les transactions en
cours, inscrit leurs opérations de modification dans la base et inscrit un point de
contrôle dans le journal. Concrètement, les points de contrôle sont les instants où un
système réalise des écritures physiques de pages de sa mémoire cache vers l’espace
disque.
Journalisation et point de contrôle
21

22. REPRISE EN CAS
D’INCIDENT
22

23. Reprise en cas d’incident
La stratégie de reprise dépend de la gravité de l’incident qui la provoque :
le processus de « reprise à froid » consiste à considérer une sauvegarde de la base, à la
recharger puis à automatiquement exécuter les transactions marquées valides dans le journal,
depuis la date de la sauvegarde jusqu’à la date de l’incident.
Si les dégâts sont importants
Si les dégâts sont importants
la « reprise à chaud » consiste à défaire (UNDO) certaines actions et à en refaire (REDO)
d’autres, si nécessaire. Deux techniques sont principalement utilisées : la mise à jour
différée et la mise à jour immédiate.
Si les dégâts ne sont pas catastrophiques
23

24. Reprise en cas d’incident
Exemple :cette figure schématise un processus de sauvegarde des données et des
journaux pendant une période d’activité. La sauvegarde du journal le vide de son
contenu, ce qui n’est pas le cas de celui de la base, évidemment
24

25. DUPLICATION
25

26. Sécurité par réplication
 Ce dispositif permet de synchroniser le contenu d’un espace quelconque de
stockage (données, journal, métadonnées) avec un réplica de cet espace. Il a pour
effet d’opérer les modifications « en double », c’est-à-dire sur l’espace ou l’unité
primaire et sur sa copie (que nous appellerons également espace ou unité
secondaire).
 De ce fait, en cas de panne ou de détérioration de l’unité primaire, on pourra
(presque) assurer une continuité de service en “basculant” sur l’unité secondaire.
 Il est plus sécurisant de localiser les unités primaires et secondaires sur des
disques physiques différents.
26

27. Le multiplexage
Le multiplexage doit concerner principalement le fichier de contrôle d’une base
(control file) et le journal (redo log), chaque base devant comporter, au minimum,
deux fichiers de contrôle et deux fichiers redo log. Pour ce qui concerne le
multiplexage des fichiers redo log actifs, Oracle définit la notion de groupe et de
membre : un membre est un fichier d’un groupe et les membres d’un même groupe
sont des copies les uns des autres. Une base doit avoir au minimum deux groupes
d’au moins un membre chacun.
27

28. L'AUDIT
28

29. La surveillance (audit)
 La surveillance, ou audit, permet d’enregistrer des événements liés à des
utilisateurs, à des bases de données, ou encore au serveur lui-même.
 La liste des événements devant faire l’objet d’une surveillance est appelée
options de l’audit et l’ensemble des enregistrements décrivant la surveillance
effective est généralement appelé audit trail.
son installation ou sa
configuration préalable
la spécification des options
de l’audit
la gestion de l’audit trail
La mise en œuvre de ce mécanisme nécessite
29

30. La surveillance sous Oracle
 Les événements à surveiller sont spécifiés à l’aide de l’instruction audit et les
enregistrements de la surveillance (audit trail) sont contenus dans la table
sys.aud$ qui fait partie du dictionnaire de chaque base.
 Ces enregistrements comprennent, entre autres informations, le nom de
l’utilisateur concerné, les identifications de la session et du terminal, le nom de
l’objet schéma accédé, la date de l’action, le privilège système utilisé, l’opération
exécutée ou tentée, etc.
30

31. Les options de surveillance
 Les événements ou les actions qui peuvent être
l’objet des mécanisme d’audit peuvent être classés
en trois catégories :
01
02
03 types d’actions
effectuées sur des
objets
types d’instructions
SQL utilisés
 la surveillance peut être imposée pour une session
(by session) ou chaque accès (by access).
31
types de commandes
autorisées par des
privilèges système

32. La gestion des enregistrements de surveillance
 La table sys.aud$, qui contient les enregistrements d’audit, est créée par un script
(catalog.sql).
 La taille de sys.aud$ est déterminée lors de la création de la base.
 On peut en contrôler le remplissage en en archivant périodiquement le contenu
 la table sys.aud$ et les diverses vues sont interrogeables comme toute autre table ou
vue du dictionnaire de la base.
32

33. 33
Le cryptage
d’informations

34. Le cryptage d’informations.
34
 La protection directe des données est devenu une nécessité en agissant sur ces
données, par le biais de cryptage de l’information qui garantie la
confidentialité de ces données.
 La cryptographie est une des disciplines de la cryptologie s'attachant à
protéger des messages (assurant confidentialité, authenticité et intégrité) en
s'aidant souvent de secrets ou clés.

35. Algorithmes de cryptographie symétrique
35
Quelques algorithmes de
chiffrement symétrique très
utilisés :
 Chiffre de Vernam DES
 3DES
 AES

36. Algorithmes de cryptographie asymétrique
36
Quelques algorithmes de
cryptographie asymétrique très
utilisés :
 RSA (chiffrement et signature)
 DSA (signature)
 Diffie-Hellman (échange de clé)

37. Le cryptage dans oracle
• description du paquet DBMS_CRYPTO :
37

38. 38
create or replace function get_enc_val
( p_in in varchar2 ,p_key in raw)
return raw is
l_enc_val raw (2000);
l_mod number :=
dbms_crypto.ENCRYPT_AES128
+ dbms_crypto.CHAIN_CBC
+ dbms_crypto.PAD_PKCS5;
begin
l_enc_val := dbms_crypto.encrypt(
UTL_I18N.STRING_TO_RAW(p_in ,
'AL32UTF8'),
l_mod,
p_key
);
return l_enc_val;
end;
Le cryptage dans oracle
create or replace function get_dec_val
( p_in in raw, p_key in raw )
return varchar2
is
l_ret varchar2 (2000);
l_dec_val raw (2000);
l_mod number := dbms_crypto.ENCRYPT_AES128
+ dbms_crypto.CHAIN_CBC
+ dbms_crypto.PAD_PKCS5;
begin
l_dec_val := dbms_crypto.decrypt ( p_in, l_mod, p_key );
l_ret:= UTL_I18N.RAW_TO_CHAR
(l_dec_val, 'AL32UTF8');
return l_ret;
end;

39. La gestion de la clé
 On dispose de deux options pour la gestion des clés:
Utiliser la même clé pour tous les enregistrements
Utilisez une clé différente pour chaque enregistrement
 il ya plusieurs options pour stocker la clé:
Dans la base de données
Dans le système de fichiers
Avec l'utilisateur
39

40. CONCLUSION
40
1. Changer le mot de passe par défaut
2. Refuser les connexions distantes
3. Supprimer les comptes inutiles
4. Supprimer la base de données d’exemple
5. Activer les logs et les externaliser
6. Exécuter le service avec un compte de service
7. Restreindre les privilèges des utilisateurs
8. Chiffrer les données stockées
9. Appliquer les patchs de l’éditeur
Voici donc quelques conseils de première nécessité pour sécuriser votre base de données :

41. REFERENCES
41
N. Boudjlida : « Eléments de base de la sécurité des bases de données ».
http://psoug.org/reference/dbms_crypto.html
http://www.oracle.com/technetwork/issue-archive/2005/05-jan/o15security-097078.html
Jacques Le Maitre : « Sécurité des bases de données »