Embed Size (px)
Citation preview
La sécurité dans les Bases de Données
Année Universitaire 2014 – 2015
Réalisé par : ABBAD Zakariae
HIRCHOUA Badr
Master :SIRM1
LA GESTION DES PRIVILÈGES
LES TRANSACTIONS
DUPLICATION
REPRISE EN CAS D’INCIDENT
L'AUDIT
LE CRYPTAGE D’INFORMATIONS
CONCLUSION
PLAN
8
INTRODUCTION1
234567
2
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 .
la gestion des privilèges
4
Processus de contrôle
5
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 certainecaté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
Octroi ou révocation de privilèges
SQL offre deux commandes pour octroyer ou révoquer des privilèges :
GRANT
REVOKE
7
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
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.
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
Révocation avec restriction : exemple
ADIL zakariae saidSELECT 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
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 ;
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
les transactions
14
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)
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
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
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
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
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 T20
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
REPRISE EN CAS D’INCIDENT
22
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
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
DUPLICATION
25
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
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
L'AUDIT
28
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
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
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
03types d’actionseffectué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
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
Le cryptage
d’informations
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.
Algorithmes de cryptographie symétrique
35
Quelques algorithmes de
chiffrement symétrique très
utilisés :
Chiffre de Vernam DES
3DES
AES
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é)
Le cryptage dans oracle
• description du paquet DBMS_CRYPTO :
37
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;
beginl_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;
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
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 :
REFERENCES
41
N. Boudjlida : « Eléments de base de la sécurité des bases de données ».http://psoug.org/reference/dbms_crypto.htmlhttp://www.oracle.com/technetwork/issue-archive/2005/05-jan/o15security-097078.htmlJacques Le Maitre : « Sécurité des bases de données »
