Bda CM Securite BD

Bases de données
avancées
Jean-Yves Antoine
LI - Université François Rabelais de Tours
Jean-Yves.Antoine AT univ-tours.fr
UFR Sciences et Techniques

Master IUP SIR Blois – M1
Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 1

Bases de données
avancées
Administration de bases de données :

Protection et sécurité des données par les
SGBD transactionnels
UFR Sciences et Techniques

IUP GMI Blois – IUP3

Sécurité de données
1. Reprise après panne
Transaction
2. Gestion des accès concurrents Séquences
3. Contrôle d’accès : privilèges

1. Panne
Type de panne
– panne d’action et de transaction : locale à la base de données ✪
– globale au système
• Panne système (soft crash) : panne système sans atteinte à la mémoire physique
• Panne mémoire (hard crash) : problème sur les supports mémoire secondaire
Exemple : gros systèmes
Panne
Défaillance Fréquence
Fréquence Tps reprise
Locale ~ 10 / minute instantané
Soft crash 2 à 3 / semaine qques minutes
Hard crash 1 à 2 / an qques heures
[Gray 81, Härder, Reuter 83]
Résistance aux pannes : mémoire sûre
Reprise sur panne
– SGBD restreint (non partagés, mono-utilisateur,…) : pas de support à la reprise
– SGBD complet (Oracle) : reprise basée sur la notion de transaction
1. Panne locale et transaction
• Problème
Plusieurs clauses SQL pour une seule action logique
Problème de cohérence si panne lors d’une de ces instructions
Exemple - Suppression manuelle d’un enregistrement en cascade
table2
DELETE FROM table2 WHERE…
table1
INSERT INTO table2 VALUES…
• Transaction
- Unité logique de traitement correspondant à un ensemble d’actions sur la BD
- Trois actions atomiques : validation, annulation et ré-exécution d’une transaction
- Unité de base pour la gestion des pannes et celle des accès concurrents

Transaction : principes généraux
Transaction — Unité logique de traitement formée d’une
suite d’actions :
session d’utilisation: suite de transactions
….
fin de transaction: validation ou invalidation des
actions OK
Validation — publication définitive des modifications INSERT INTO…

UPDATE …
(enregistrement physique): pas de retour arrière SELECT …
OK
Annulation / Invalidation — retour de la base à son
état en début de transaction SELECT…
INSERT INTO…
En cours de transaction : mémorisation des actions
NO OK
réalisées dans un journal (fichier de log ou de redo-
log) avant et après ALTER TABLE
….
Administration Oracle 9i : outil Log Miner
Accès concurrents : verrous en cours de transaction
Transaction : principes ACID
[Bjork, 1973]
Atomicité transactions atomiques (tout ou rien)
Cohérence transactions maintiennent la cohérence de la base
Isolation transactions, mêmes concurrentes, isolées les unes des autres
Durabilité après validation, mise à jour pérennes même si panne

Transaction : SQL
Mise en œuvre pratique
– SQL — Oracle : segments d’annulation ROLLBACK / UNDO Segments
– Gestion de transaction non supportée par les SGBD restreints
Début de transaction implicite

– Début de toute commande SQL en début de session,
– Fin de la transaction précédente ensuite.
Fin de transaction explicite

– Commandes de validation (COMMIT) ou annulation (ROLLBACK),
Fin de transaction implicite

– Commande de définition de données (CREATE, ALTER, DROP etc.)
– Fin de session, détection de problème par le SGBD ou arrêt anormal du SGBD.

(In)validation de transaction
• COMMIT COMMIT ;
– Termine une transaction par la validation des actions effectuées
– Annulation des verrous éventuels et publication définitive des modifications
effectuées aux autres utilisateurs
• ROLLBACK ROLLBACK ;
– Termine une transaction en annulant toutes les actions effectuées.
• Sous-transaction : SAVEPOINT
– positionnement d’un point intermédiaire dans la transaction
SAVEPOINT <point_repere> ;
– annulation des actions depuis ce point de repère (et non depuis le début)
ROLLBACK TO <point_repere> ;

Transaction : exemple
DELETE FROM personne WHERE .... ;
INSERT INTO TABLE personne VALUES ... ;
COMMIT ;
ALTER TABLE societe ADD …. ;
UPDATE personne ... SET ;
SAVEPOINT a ;
? ?
DELETE FROM personne WHERE .... ;
UPDATE personne SET .... ;
ROLLBACK TO a ; ROLLBACK ;

Oracle : transaction et contraintes
Contraintes différées
Il est possible de différer la vérification d’une contraintes en fin de transaction logique
– Deux statuts : contrainte différable (DEFERRABLE) ou non
– Deux états pour une contrainte reportable : immédiate ou différée (DEFERRED)
Utilisation d’une contrainte différable

Attribution une fois pour toute du caractère différable lors de la création + état initial
CREATE TABLE piece
(id NUMBER,
elt NUMBER,
CONSTRAINT fk_piece_elt FOREIGN KEY(elt) REFERENCES elt(id)
DEFERRABLE INITIALLY DEFERRED );
INITIALLY IMMEDIATE
Changement d’état dans une transaction ou toute une session

SET { CONSTRAINT | CONSTRAINTS} { ctr1 [, ctr2…] | ALL}
{ IMMEDIATE | DEFERRED }
ALTER SESSION SET CONSTRAINTS = { IMMEDIATE | DEFERRED }

SQL : propriétés de transaction
Définir les caractéristiques de la transaction à venir
valable uniquement si aucune autre transaction en cours
SET TRANSACTION [mode_acces] [niveau_isolation]
Niveau d’isolation cf. partie verrouillage

SERIALIZABLE | REPEATABLE READ | READ COMMITED | READ UNCOMMITED
Mode d’accès
READ ONLY | READ WRITE
– READ WRITE incompatible avec READ UNCOMMITED

Pannes et transactions: journalisation
• Journalisation Journal
- Performance : modifications mémorisées en cache (mémoire Id_transaction
volatile) et recopie sur disque à intervalles prédéfinis. Time
- Sécurité des données : cache perdu lors des pannes systèmes Fichier / Page
- Journalisation : mémorisation des informations qui ont été Valeur avant
modifiées en cache mais pas encore reportées sur disque Valeur après
• Journal des images avant

- Valeurs des données mises à jour et pas encore sur écrites sur disque, avant modification
- Protection des données : utilisation pour défaire une transaction (undo log)
• Journal des images après

- Valeurs des données mises à jour et pas encore sur écrites sur disque, après modification
- Protection des données : utilisation pour rejouer une transaction (redo log)

Pannes et transactions: journalisation
Protection des données : journalisation avant action
log log
avant 2 4 après
journal
3 Cache
donnée donnée
lue 1 5 modifiée
BD persistante
Performance : journal également en mémoire volatile (cache)

Protection des données : validation ≠ sauvegarde automatique sur DD
validation après écriture

Journalisation : Oracle 10g
Fichiers de redo-log
- Remplissage circulaire d’un ensemble de fichiers de redo-log
- Restauration : suppression ou archivage (ARCHIVELOG MODE) du fichier une
fois utilisé pour rejouer les transactions
Fichier Log1
Fichier Log2 Tablespace UNDO
Fichier LogN

Journalisation : Oracle 10g
Accès aux fichiers redo-log
- Dictionnaire de données : V$LOGHIST ; V$LOGFILE, V$LOG
- Outil Log Miner
Gestion des tablespaces UNDO

- Dimensionnement de la taille mémoire accordée au journal
- Dictionnaire de données
Vue Rôle
Liste des TABLESPACES. Le champ CONTENT
DBA_TABLESPACES
donne leur type (UNDO,…)
DBA_UNDO_EXTENTS Caractéristiques des UNDO segments
V$UNDOSTATS % d’utilisation du TABLESPACE
- Outil Undo Advisor

Reprise après panne
Panne locale (problème de cohérence de la base)
Gestion immédiate : ROLLBACK explicite ou implicite
Reprise à froid : hard crash

– support mémoire physique endommagé
– recopie d’une sauvegarde antérieure (dump)
– si copie physique du journal non atteinte : on rejoue les actions du journal
Reprise à chaud : soft crash

1. Recherche dans le journal du dernier point de reprise système (copie physique)
2. Ré-exécution des transactions mémorisées après le point de reprise (redo log)
3. Annulation des transactions journalisées mais non encore validées (undo log)
– Oracle : gestion automatique à l’aide des segments d’annulation (ROLLBACK

segments / UNDO segments)
Reprise à chaud : soft crash
Validation logique et sauvegarde physique
point de contrôle crash
(copie physique)
temps
MIT
T1 CO
M
M MIT
T2 CO
M MIT
T3 CO
T4 ?
T5 ?
Action de restauration Transaction

Aucune T1
Annulation (Rollback) T4, T5
Rejouer le transaction T2, T3
BD réparties : validation en deux étapes
Double COMMIT : BD réparties ou multi-processus
machine coordinateur machine
distante 1 distante 2
demande COMMIT distant demande COMMIT distant
prêt prêt
ordre COMMIT distant ordre COMMIT distant
COMMIT OK Commit OK
COMMIT global OK COMMIT global OK

Double COMMIT
Panne sur demande de préparation

panne
prêt
timeout reprise
ordre ROLLBACK distant ordre ROLLBACK distant
ROLLBACK OK ROLLBACK OK
ROLLBACK global OK ROLLBACK global OK

Double COMMIT
Panne sur validation distante
prêt prêt
ordre COMMIT distant ordre COMMIT distant
panne
COMMIT OK
timeout
reprise
COMMIT OK

Concurrence : problèmes
Accès concurrents
– Plusieurs utilisateurs ou applications accèdent/modifient aux mêmes données.
– Problèmes sur les valeurs lues et surtout de maintien de la cohérence de la BD.
Perte d’opération
UPDATE O1
O1
UPDATE O1
Lecture O1
Lecture O1
UPDATE
tampon
UPDATE
tampon Écriture O1
T1
Ecriture O1 T2
Perte T2

Concurrence: problèmes
Incohérence de la base
Lectures fantômes laissant croire au non respect des contraintes d’intégrité
CHECK 01 = 02
UPDATE O2
01 02 UPDATE O1 (idem)
SELECT O1
SELECT O2 Lecture O2
Écriture O2
T1 Lecture O1
T2
Lecture O2 Lecture O1
Écriture O1
01 ≠ 02 !!

Concurrence: problèmes
Incohérence de la base
Lectures fantômes pouvant conduire à des inconsistances permanentes
CHECK 01 = 02 UPDATE O2
UPDATE O1 (idem)
UPDATE O1
UPDATE O2 (idem) 01 02
Lecture O1 Lecture O2
Ecriture O1
Écriture O2
T1 Lecture O2 Lecture O1
T2
01 ≠ 02 ?? Ecriture O2
Écriture O1

Sécurisation des accès concurrents
Principes
– Contrôler les accès concurrents sur les données en cours de modification
– Transaction : grain temporel minimal de gestion des accès concurrents (ACID)
– Granularité : définition de l’unité de base dont l’accès peut-être contrôlé. Peut
être variable suivant la transaction : champ, tuple, relation…
– Objectif : sérialisation de l’exécution des transactions.
Sérialisation
– Schéma sériel: schéma d’exécution dans lequel les transactions sont
exécutées à la suite les unes des autres: pas de problème de concurrence.
– Schéma sérialisable : un schéma de N transactions T1, …, Tn concurrentes est
sérialisable si il existe un schéma sériel des transactions qui produit le même
résultat quelque soit l’état initial de la base
– Schéma sérialisable par permutation : cas particulier (plus restrictif) de
schéma sérialisable ou on peut permuter les actions deux à deux pour obtenir un
schéma sériel
Opérations - Compatibles : exécutables en parallèle sans problème
- Permutables : ordre d’exécution sans influence sur le résultat final
Opérations de T1 et T2 compatible permutable
Lecture/Ecriture A et Lecture/Ecriture B oui oui
Lecture A et Ecriture A non non
Ecriture A et Ecriture A non non
Graphe de précédence d’un schéma d’exécution

– Définition: on dit qu’il y a précédence d’une transaction T1 par rapport à une
transaction T2 si il existe au moins une opération O1 de T1 non permutable
avec une opération O2 de T2 et qui est avant O2 dans le schéma d’exécution
T1 T2 T3 T1 T2 T3
– Condition suffisante : le schéma d’exécution de transactions concurrentes est

sérialisable si le graphe de précédence qui lui est associé est sans circuit.
Sérialisation contrôle d’accès pour n’autoriser que des schémas sérialisables
- approche optimiste : contrôle par estampillage ou validation
- approche prudente : verrouillage
Estampillage
. – Numéro d’ordre attribué aux transactions
– Traces sur les éléments de la BD lors des opérations de lecture / écriture :
• LL(E) numéro de la dernière transaction à avoir lu l’élément E
• LE(E) numéro de la dernière transaction à avoir écrit / modifié E
– Algorithme d’ordonnancement: Ti veut opérer sur une donnée E
• si i ≥ LL(E) (resp. LE(E) ) alors on peut exécuter i (transaction bien postérieure)
• sinon, on annule et reprend la transaction d’estampille LL(E) ( resp. LE(E) ).
– Approche optimiste : on suppose que tout se passe bien a priori. Si
ordonnancement non sérialisable, il faut alors différer ou défaire les transactions

Accès concurrents : verrouillage
Verrouillage : principes
– Une transaction peut poser et libérer des verrous sur les données sur lesquelles elle
travaille (lecture, mise à jour, écriture…).
– Une transaction ne peut réaliser une opération sur une donnée que s’il n’y a pas de
verrou posé dessus, où si la transaction possède le verrou en question. Sinon, elle
est mise en attente au niveau de l’opération en cours
– Approche prudente : pas d’annulation de transaction en cours, sauf si verrou mortel
Stratégies de verrouillage
– Verrous uniques stricts : verrou sur une donnée dès qu’on l’utilise
– Verrous distincts non nécessairement exclusifs : verrous différents suivant l’action
• lecture (verrou partagé) / écriture (exclusif)
• lecture, mise à jour protégés ou non, exclusive ou non , etc…
Niveaux d’isolation des transactions C= 1 0
Matrice de compatibilité des opérations 0 0
lecture / écriture
Algorithme de verrouillage (cas général : verrous distincts)
– Avant chaque opération, la transaction vérifie si elle peut poser le verrou (exclusif ou
non) qui correspond à cette dernière. Si non, attente.
– En pratique :
⇒ Vecteur O(i,e) des opérations de la transaction Ti en cours sur l’élément e
⇒ Demande LOCK : vecteur booléen Mj(e) des modes de verrouillage demandés
⇒Demande UNLOCK: remise à zéro du mode correspondant dans O(i,e)
⇒ Verrouillage autorisé si : M (e) ⊂  ( C * Σ O(i,e) ) j Boole
i≠j
Protocole de verrouillage en deux phases (2PL)

– 2PL : dans la transaction, tous les verrouillages précèdent les libérations de verrou.
– Intérêt : condition suffisante pour assure des schémas d’exécution sérialisables.

Problèmes de verrouillage : verrou mortel
INSERT O2
INSERT O1 SELECT O1
UPDATE O2
01 02
A LOCK : Écriture dans O1 B

LOCK : Écriture dans O2
WAIT LOCK : Écriture dans O2

LOCK : Lecture dans O1
WAIT

Détection des interblocages: graphe des attentes
• Graphe des attentes: une transaction Ti attend une transaction Tj si Ti attend de
pouvoir verrouiller une donnée d alors que le verrou correspondant appartient à Tj.
• Interblocage (verrou mortel) ssi le graphe des attentes possède un circuit
T1 T2 T3 T4
Résolution des interblocages

• Prévention: pré-ordonnancement des transactions Trop lourd
• Correction: algorithme de déblocage implicite
☺
– Stratégie DIE_WAIT : Ti attend Tj uniquement si Ti est plus vieille que Tj . Sinon, Ti est
annulée (reprise).
– Stratégie WOUND_WAIT : Ti attend Tj uniquement si Ti est plus jeune que Tj . Sinon, Ti
tue Tj (reprise provoquée).
– Stratégies plus souples : on blesse (ultimatum d’une certaine durée) avant de tuer

Accès concurrents: verrouillage
Problèmes de verrouillage : blocage permanent
• Problème: ensemble de transactions effectuant des actions compatibles (pas de
verrou mortel) mais bloquant de facto les autres transactions.
• Solutions - file d’attente des demandes de verrouillage
- stratégies DIE_WAIT / WOUND_WAIT: pas de blocage permanent
Problèmes de verrouillage : lecture fantôme

• Toujours possible : difficulté de définir des granules logiques communs
T1 01 ⊂ 02 UPDATE O2
SELECT O1
SELECT O2 01 02
Lecture O1 LOCK : Lecture O2

LOCK : Écriture O2
01 ⊂ 02 ?? Lecture O2 UNLOCK : Commit

T2
• Niveaux d’isolations variables
2PL : assure la sériabilité mais restreint les exécutions concurrentes
Protocoles plus permissifs … plus de concurrence mais dangers associés
Mode d’opérations autorisés et durée des verrous :
• verrou court libéré après l’exécution de l’opération concernée
• verrou long libéré en fin de transaction (2PL maximal)
• SQL2 : Niveaux d’isolation normalisés

– Niveau 0 verrou exclusif court en écriture uniquement
Garantie : mises à jour assurées uniquement
– Niveau 1 verrou exclusif long en écriture uniquement
Garantie : non perte et cohérence des mises à jour
– Niveau 2 Niveau 1 + verrous courts partagés en lecture
Garantie : niveau 1 + cohérence des lectures
– Niveau 3 2PL : verrous longs écriture exclusive / lecture partagée
Niveau 2 + lecture renouvelable
• Niveaux d’isolations variables problèmes éventuels
• Problème 1 : lecture salissante
UPDATE O2
01 02
ROLLBACK
SELECT O2
Écriture O2
Lecture O2
T1 ROLLBACK
O2?? T2
Verrou court : UNLOCK avant COMMIT

Problème 2 : lecture non renouvelable
UPDATE O2
01 02
SELECT O2
Lecture O2
Lecture O2 UPDATE
tampon
Écriture O2
SELECT O2
T1
Lecture O2 T2
COMMIT
O2??
Verrou court : UNLOCK avant COMMIT

Problème 3 : lecture fantôme Rappel : au mieux, on ne peut que limiter
les situations de lectures fantômes
01 02
UPDATE O2
SELECT O1
UPDATE O1
SELECT O2
Écriture O2
Lecture O1
T1 Écriture O1
Lecture O2 T2
O1 ?? COMMIT
Verrou court lecture / écriture

Accès concurrents : Oracle
Verrouillage implicite des données
– Gestion transparente: automatique, suivant le niveau d’isolation choisi
– Plusieurs niveaux d’isolation : contrôle plus ou moins strict de la concurrence
– Protocole 2PL : déverrouillage final sur COMMIT (si niveau SERIALIZABLE)
– Granularité fine : on peut ne verrouiller qu’un tuple, un attribut
– Dictionnaire Oracle : V$LOCK
Mise à jour des données (INSERT, UPDATE et DELETE )

– Niveau SERIALIZABLE: verrou sur le tuple (ROW) de la table concernée.
– Création d’un ROLLBACK segment : modifications visibles du seul utilisateur
responsable de la transaction jusqu’à la fin de transaction.
Consultation de données (SELECT)
– Niveau SERIALIZABLE : verrou lecture protégée.
– Ne peut pas voir les mises à jour non encore publiées par les autres transactions.
Nom Age Age = 5
Léo 4
A : Début SELECT Age FROM Nom ; C
C : Début UPDATE .. SET Age=5;
A: Fin SELECT Age FROM Nom ; Age

5 UNDO segment
B : Début SELECT Age FROM Nom ; C : Fin UPDATE .. SET Age=5;
C : Fin transaction
Age =4 Age = 5
B : Fin SELECT Age FROM Nom ;
A B
Niveaux d’isolation
Niveau d’isolation Lecture Lecture non Fantôme
salissante renouvelable
Lecture non validée
Lecture validée
Lecture renouvelable
Sérialisable
SQL : Définir un niveau d’isolation

• SERIALIZABLE par défaut
• Définition par transaction SET TRANSACTION [niveau_isolation]
Accès Concurrents : Oracle
Verrouillage explicite sur table ou enregistrements
• Verrouillage de table
LOCK TABLE <nom_table> IN {EXCLUSIVE | SHARED } MODE
– Mode exclusif (X) : table totalement verrouillée sauf en consultation (SELECT).

– Mode partagé (S) : d’autres transactions peuvent mettre un verrou partagé sur
la table. Si plusieurs verrous S, impossibilité de modifier les données par aucune
des transactions.
• Verrouillage de tuple (ROW)
LOCK TABLE <nom_table> IN {ROW EXCLUSIVE | ROW

SHARED | SHARE ROW EXCLUSIVE} MODE
– Si verrou partagé uniquement sur les enregistrements (RS), modifications

parallèles possible sur enregistrements différents.
Séquences
Principe: définition de valeurs unique et accès concurrents
– Objet nommé dans la base de données qui sert à générer des valeurs (entiers)
uniques dans un environnement d ’utilisation multi-utilisateurs, sans conflit et sans
risque de verrous mortels
– Une séquence est un objet spécifique qui peut être utilisé dans plusieurs tables et par
plusieurs utilisateurs.
– Un pas d’incrément permet de définir le calcul de la valeur courante à partir de la
valeur précédente. Les valeurs sont comprises entre des valeurs maximales et
minimales (-1026 et 1027 par défaut).
– Une fois l’ensemble des valeurs parcouru, on peut autoriser le retour à la valeur initiale
pour poursuivre la génération à l’aide de l’option CYCLE
Exemple d’utilisation : clé primaire

Générer les valeurs de la clé sur une importation si aucun champ de données ne joue ce
rôle (équivalent à NumeroAuto en ACCESS ou Auto Increment en MySQL)
Séquences
Création
CREATE SEQUENCE [<schema>.]<nom_seq>
[ INCREMENT BY <entier> ]
[START WITH <entier>]
[ MAXVALUE entier ] [ MINVALUE entier ]
[ {CYCLE | NOCYCLE}]
[{CACHE <entier> | NOCACHE}] ;
Modification
Généralement pour changer l’amplitude de variation ou le pas d’incrément
ALTER SEQUENCE [<schema>.]<nom_seq> + un des éléments de création
Suppression
DROP SEQUENCE <nom_sequence> ;

Séquences
• Utilisation
• Utilisation dans toute commande SQL de manipulation des données (SELECT,
INSERT, UPDATE) avec quelques restrictions
• <nom_sequence>.NEXTVAL : directive (pseudo-attribut) générant la première ou la
prochaine valeur de la séquence et retourne la valeur de celle-ci (lecture et écriture)
• <nom_sequence>.CURVAL : valeur courante de la séquence (lecture seule)
• Exemple
CREATE SEQUENCE seq_exple NOCYCLE ;
SELECT seq_exple.NEXTVAL FROM seq_exple ; /* 1ère utilisation */
...
SELECT seq_exple.CURVAL FROM seq_exple ; /* lecture 1ère valeur */
...
SELECT seq_exple.CURVAL FROM seq_exple ;

Séquences : Oracle
Visualisation de l’état d’une séquence
Lecture (SELECT) du pseudo-attribut <nom_seq>.CURVAL dans la
pseudo-table DUAL
Dictionnaire Oracle : vue ALL_SEQUENCES

Nom NULL ? Type
-------------------------------------- -------- ---------------
SEQUENCE_OWNER NOT NULL VARCHAR2(30)
SEQUENCE_NAME NOT NULL VARCHAR2(30)
MIN_VALUE NUMBER
MAX_VALUE NUMBER
INCREMENT_BY NOT NULL NUMBER
CYCLE_FLAG VARCHAR2(1)
ORDER_FLAG VARCHAR2(1)
CACHE_SIZE NOT NULL NUMBER
LAST_NUMBER NOT NULL NUMBER

Séquences
Utilisation explicite de séquences avec SQL Loader
1. Créer une séquence
CREATE SEQUENCE seq_exple START WITH 1 INCREMENT 1 BY NOCYCLE ;
2. Utiliser la séquence dans le fichier de contrôle
LOAD DATA INFILE 'donnees.don'

INTO TABLE Table_exemple
FIELDS TERMINATED BY ';'
(pk_att "seq_exeple.nextval",
NOM ….
Utilisation implicite de séquences avec SQL Loader

LOAD DATA INFILE 'donnees.don' INTO TABLE Table_exemple
FIELDS TERMINATED BY ';'
(pk_att SEQUENCE(Valeur_Max, Increment),
…

Contrôle d’accès
Politique de contrôle discrétionnaire
– Privilèges spécifiques de chaque utilisateur sur chaque objet
Politique de contrôle obligatoire

– Niveaux de classification des objets
– Niveaux d’habilitation des utilisateurs
Exemple
User U peut accéder à objet O si Niveau habilit. U > Niveau classif O
User U peut modifier objet O si Niveau habilit. U = Niveau classif O
SQL
Contrôle discrétionnaire uniquement

Privilèges
Privilèges
– Privilège système : droit d’exécuter un ordre SQL sur n’importe quel type d’objet.
Par défaut, droit réservé uniquement à DBA.
– Privilège objet : droit d ’accès à un objet précis dans un autre schéma que le sien.
Par défaut, un utilisateur qui crée un nouvel objet à tous les droits sur lui, les autres
aucun (sauf DBA)
Gestion des privilèges sous Oracle

• Interface conversationnelle SQL*Plus : clauses SQL GRANT et REVOKE
• Interface Oracle Entreprise Manager

Privilèges système
• Définition de privilège
GRANT { privilège_système | ALL_PRIVILEGES}
TO { utilisateur | PUBLIC } [WITH ADMIN OPTION]
Privilège système :
CREATE, ALTER et DROP. Par défaut, pour les objets « courants » (table,
vue, séquence, synonyme), droit généralement limité à CREATE.
CREATE SESSION : droit de connexion !
ADMIN OPTION : transfert au bénéficiaire du droit d’attribuer les mêmes

privilèges systèmes aux utilisateurs de son choix
remarque : sans ADMIN OPTION, seul DBA peut accorder des privilèges système
• Retrait de privilège système
REVOKE { privilège_système | ALL_PRIVILEGES} FROM { utilisateur | PUBLIC }

Privilèges objet
• Types de privilèges
– ALTER modification de la structure de l’objet

– DELETE suppression de l’objet
– INDEX définition d’un index sur l’objet
– INSERT insertion de tuple dans l’objet
– REFERENCES référence à des contraintes définies sur un objet
– SELECT consultation (droit de lecture)
– UPDATE droit de modification de tuple dans l’objet
(ou certaines colonnes)
– EXECUTE programmes PL/SQL
– …
Privilèges objet : définition
GRANT { privilège_objet [, privilège objet ...] | ALL }
ON objet WHERE
TO { utilisateur [, utilisateur2 …] | PUBLIC }
[WITH GRANT OPTION]
GRANT OPTION
droit au bénéficiaire d’accorder ce privilège à d’autres utilisateurs
Privilège et type d’objet

L "
Table : ALTER, DELETE, INDEX, INSERT, REFERENCES, SELECT, UPDATE L
t "A
Vue : ALTER, DELETE, INSERT, SELECT, UPDATE
r oi
Séquence : ALTER, SELECT d
Privilège sur attributs

Exemple GRANT SELECT ON ma_table(col1, col2) TO PUBLIC;
Privilèges objet : retrait
Syntaxe REVOKE [GRANT OPTION FOR] Priv1 [,Priv2 …]
ON objet
FROM { utilisateur [, utilisateur2…] | PUBLIC }
[ CASCADE CONSTRAINTS]
[ RESTRICT | CASCADE ]
GRANT OPTION FOR droit de transfert seul retiré

RESTRICT / CASCADE
A REVOKE ?
GRANT
B
GRANT
C

Privilèges objet (Oracle)
Dictionnaire Oracle : ALL_TAB_PRIVS
Nom NULL ? Type

----------------------------------------- -------- ----------------
GRANTOR NOT NULL VARCHAR2(30)
GRANTEE NOT NULL VARCHAR2(30)
TABLE_SCHEMA NOT NULL VARCHAR2(30)
TABLE_NAME NOT NULL VARCHAR2(30)
PRIVILEGE NOT NULL VARCHAR2(40)
GRANTABLE VARCHAR2(3)
HIERARCHY VARCHAR2(3)

Vues et sécurité des données
Vues moyen aisé d’avoir un contrôle direct sur les accès
Table1
Att1 : select OK pour PUBLIC
GRANT sur attributs GRANT SELECT ON Table1 (Att1) TO PUBLIC;
GRANT sur vue CREATE VIEW S_ATT1 AS

SELECT Attr1 FROM Table1;
GRANT SELECT ON S_ATT1 TO PUBLIC;

SGBD Oracle : utilisateurs
Création
– Droit de création limité au DBA
- Droit de connexion !
CREATE USER <nom_id> IDENTIFIED BY <password>
Modification (mot de passe)

ALTER USER <nom_id> IDENTIFIED BY <password>
Suppression
DROP USER <nom_id> [CASCADE]

SGBD Oracle : utilisateurs
CREATION D’UN UTILISATEUR
CREATE USER <nom_id>
IDENTIFIED BY { <password> | EXTERNALLY }
[ DEFAULT TABLESPACE <nomTableSp>
[QUOTA { <n> [ K | M ] | UNLIMITED]]
[PROFILE <NomProfile>]
[PASSWORD EXPIRE]
[ACCOUNT { LOCK | UNLOCK } ]
DEFAULT TABLESPACE espace disque de travail

IDENTIFIEDBY EXTERNALLY récupération compte O.S (exemple : OPS$ pour Unix)
UTILISATEURS PREDEFINIS
– SYS propriétaire du dictionnaire de données
– SYSTEM administrateur ORACLE par défaut
SGBD Oracle : rôles
Regroupement d’utilisateurs qui partageront les mêmes privilèges
Rôle prédéfinis ORACLE

– CONNECT connexion, CREATE et SELECT sur les objets courants
– RESOURCE droits en création plus avancés (index, cluster, trigger…)
– DBA
Création / Suppression de rôle
CREATE ROLE <nom_role> [IDENTIFIED BY <passwd> ]
DROP ROLE <nom_role>
Modification de rôle ne concerne que le mot de passe
ALTER ROLE <nom_role> [NOT IDENTIFIED | IDENTIFIED BY <passwd>]

Utilisation
Les rôles s’utilisent indifféremment comme identifiants
d’utilisateur ou de privilège
GRANT { priv_objet | role } ON objet

TO { utilisateur | role | PUBLIC } [WITH ADMIN OPTION]
GRANT priv_system
TO { utilisateur | role | PUBLIC } [WITH ADMIN OPTION]
Groupes d’utilisateurs
GRANT role
TO { utilisateur | PUBLIC } [WITH ADMIN OPTION]

Rôles prédéfinis
CONNECT Utilisateur de base : CREATE SEQUENCE, CREATE
SESSION, CREATE SYNONYM, CREATE TABLE,
CREATE VIEW…
RESOURCE Complément pour utilisateur un peu plus avancé :
CREATE PROCEDURE, CREATE TRIGGER…
DBA Tous les privilèges avec WITH ADMIN OPTION
EXP_FULL_DATABASE Privilèges requis pour l’exportation

IMP_FULL_DATABASE Privilèges requis pour l’importation
SELECT_CATALOG_ROLE SELECT sur les objets du dictionnaire
EXECUTE_CATALOG_ROLE EXECUTE sur les objets du dictionnaire

Bibliographie
Ouvrages de références
– DATE C. J. (2000) Introduction aux bases de données (7° édition), Vuibert, Paris, ISBN
2-7117-8664-1. Partie IV : gestion de la concurrence, pp. 443-496.
– GRAY J., ANDREAS R. (1993) Transaction processing : concepts and techniques.
Morgan Kaufmann, San Mateo, CA.
Travaux cités
– GRAY J.N. et al. (1981) The recovery manager of the system R Database Manager.
ACM Computing Surveys, 13(2).
– HÄRDER T., REUTER A. (1983) Principles of transaction-oriented database recovery.
ACM Comput. Surv. 15(4).
– MOHON C. et al. (1992) A transaction recovery method supporting fine-granularity
locking and partial rollbacks using write-ahead logging. ACM TODS 17(1).

Bda CM Securite BD

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bda CM Securite BD

Uploaded by

Copyright:

Available Formats

Bases de données

UFR Sciences et Techniques

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 1

Administration de bases de données :

UFR Sciences et Techniques

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 2

3. Contrôle d’accès : privilèges

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 3

Exemple - Suppression manuelle d’un enregistrement en cascade

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 5

Validation — publication définitive des modifications INSERT INTO…

Atomicité transactions atomiques (tout ou rien)

Cohérence transactions maintiennent la cohérence de la base

Isolation transactions, mêmes concurrentes, isolées les unes des autres

Durabilité après validation, mise à jour pérennes même si panne

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 7

Début de transaction implicite

Fin de transaction explicite

Fin de transaction implicite

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 8

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 9

INSERT INTO TABLE personne VALUES ... ;

ALTER TABLE societe ADD …. ;

UPDATE personne ... SET ;

UPDATE personne SET .... ;

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 10

Utilisation d’une contrainte différable

Changement d’état dans une transaction ou toute une session

ALTER SESSION SET CONSTRAINTS = { IMMEDIATE | DEFERRED }

valable uniquement si aucune autre transaction en cours

SET TRANSACTION [mode_acces] [niveau_isolation]

Niveau d’isolation cf. partie verrouillage

– READ WRITE incompatible avec READ UNCOMMITED

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 12

• Journal des images avant

• Journal des images après

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 13

Performance : journal également en mémoire volatile (cache)

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 14

Fichier Log2 Tablespace UNDO

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 15

Gestion des tablespaces UNDO

- Outil Undo Advisor

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 16

Reprise à froid : hard crash

Reprise à chaud : soft crash

– Oracle : gestion automatique à l’aide des segments d’annulation (ROLLBACK

Action de restauration Transaction

ordre COMMIT distant ordre COMMIT distant

COMMIT global OK COMMIT global OK

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 19

machine coordinateur machine

ROLLBACK global OK ROLLBACK global OK

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 20

ordre COMMIT distant ordre COMMIT distant

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 21

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 22

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 23

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 24

Graphe de précédence d’un schéma d’exécution

– Condition suffisante : le schéma d’exécution de transactions concurrentes est

Bases de Données avancées — IUP Blois, U. Rabelais Tours — © J.Y. Antoine — 27

Protocole de verrouillage en deux phases (2PL)