5 - Securité Des BD

Sécurité des bases de données
Plan
 Introduction
 Contrôle d’accès
 Contrôle de canaux cachés
 Contrôle d’inférence
 Contrôle d’accès en SQL
 Contrôle d’intégrité
 La fonction d’administrateur de BD
2
EST Fès Sécurité des Bases de données
Sécurisation d’une BD : objectifs
Assurer la sécurité d’une BD c’est maintenir :
 la confidentialité,
 l’intégrité,
 et la disponibilité
des données.
3
Maintien de la confidentialité
 Il s’agit de détecter ou d’empêcher des accès non autorisés.
 C’est crucial :
– dans des environnements critiques ou stratégiques
> militaires ou commerciaux, par exemple.
– pour respecter le droit des individus à décider comment
et dans quel but les informations les concernant
peuvent être extraites, mémorisées ou transmises à
d’autres individus.
4
Maintien de l’intégrité
 Il s’agit de détecter ou d’empêcher des mises à jour
incorrectes des données quelles soient dues à :
– des pannes de système,
– des manipulations erronées,
– des sabotages.
5
Maintien de la disponibilité
 Il s’agit de détecter ou d’empêcher des dénis de service.
 Il y a déni de service lorsqu’un utilisateur ne parvient pas à
accéder dans un délai raisonnable, à une information ou à
une ressource pour laquelle il a une autorisation d’accès :
– par exemple, un déni de service peut être provoqué par
une attaque consistant à saturer un serveur de fausses
requêtes empêchant les requêtes valides d’être
exécutées.
6
Menaces sur la sécurité des BD
 Les violations de la sécurité d’une BD consistent en des
lectures ou des mises à jour incorrectes.
 Les événements qui portent ces violations sont appelées
des menaces.
7
Types de menaces
On distingue :
 les menaces non frauduleuses :
– catastrophes naturelles,
– pannes de logiciel ou de matériel,
– erreurs humaines…
 les menaces frauduleuses :
– utilisation abusive de leurs droits par les utilisateurs, agents
hostiles exécutant des actions de destruction du logiciel ou du
matériel, ou lisant ou mettant à jour des données protégées,
– ces agents peuvent être cachés dans des actions légales : chevaux
de Troie. 8
Besoins en sécurité d’une BD
 Authentification des utilisateurs
 Protection contre les accès non autorisés
– Contrôle d’accès
 Protection contre les inférences
– Contrôle d’inférence
 Confinement (protection lors des transferts d’information
entre processeurs)
– Contrôle des canaux cachés
 Intégrité de la base de données
– Contrôle de l’intégrité sémantique
– Contrôle de concurrence
– Reprise après panne
9
Politique de sécurité
 La politique de sécurité peut être définie comme
l’ensemble des lois règles ou pratiques qui régissent la
façon dont l’information sensible et les autres ressources
sont gérées, protégées et distribuées à l’intérieur d’un
système d’information.
10
Les 3 axes d’une politique de
sécurité
 Physique
– Environnement physique du système à protéger
• éléments critiques
• mesures vis-à-vis du vol et des catastrophes
 Administratif
– Procédures organisationnelles
• répartition des tâches
• séparation des pouvoirs
 Logique
– Contrôles d’accès logiques (qui, quoi, quand, pourquoi,comment)
• fonctions d’identification, d’authentification et d’autorisation mises
en oeuvre par le système informatique.
11
Contrôle d’accès
Un système de contrôle d’accès comprend :
 des sujets : utilisateurs, processus… qui peuvent être classés par groupes,
 des objets : données, programmes…
 des opérations : lecture, ajout, modification, suppression…, déclenchées
par les sujets sur les objets
 un règlement de sécurité constitué d’un ensemble de règles d’accès
traduisant la politique de sécurité du système d’information.
 un processeur de sécurité qui vérifie que les requêtes adressées au
système ne violent pas les règles d’accès et selon le cas autorise, modifie
ou interdit la requête.
12
Processeur de sécurité
13
Principe du moindre privilège
 Ce principe stipule qu’un sujet ne doit disposer que des
droits d’accès minimum pour assurer l’exécution des
tâches qui lui sont assignées, pas un de plus.
 Par exemple :
Ne pas donner les droits de l’administrateur à tout

utilisateur d’un système (système d’exploitation, SGBD).
14
Autorisation, interdiction et
obligation
 Les règlements les plus simples ne contiennent que des
autorisations. Ce qui n'est pas autorisé est interdit
 Certains règlements incluent des interdictions afin de
spécifier des exceptions à des permissions générales:
– Exemple: Les patients ont droit de consulter leur dossier médical
sauf Jean Dupont.
 D'autres enfin, plus sophistiqués, incluent des obligations

– Difficiles à implanter dans les systèmes informatiques
15
Modèles de contrôle d’accès
 On distingue deux grandes catégories de modèles de
contrôle d’accès :
– modèles discrétionnaires,
– modèles obligatoires.
16
Modèles discrétionnaires
 Chaque objet a un propriétaire (en général, le créateur) qui
décide quels sont les autres sujets qui ont accès à cet
objet :
– d’où le nom de « discrétionnaire »
 Il y a donc décentralisation du contrôle d’accès.

 Ce contrôle peut malgré tout être centralisé en confiant
tous les droits à l’administrateur du système.
17
Exemple : modèle à matrice
d’accès
18
Modèles discrétionnaires :
avantages et inconvénients
 Ils sont simples à mettre en oeuvre.
 Ce sont les plus implantés : UNIX, SQL…
 Le contrôle de la propagation des droits et celui de la
révocation des droits propagés posent des problèmes
difficiles.
 Ils sont vulnérables aux chevaux de Troie.
19
Vulnérabilité aux chevaux de
Troie
Soit :
 2 fichiers F1 et F2
 1 utilisateur U1 ayant :
– le droit de modifier F1
– aucun droit sur F2
 1 utilisateur U2 ayant :
– aucun droit sur F1
– le droit de modifier F2
20
Vulnérabilité aux chevaux de
Troie
21
Modèles à base de rôles
 On peut améliorer les modèles discrétionnaires en
regroupant les autorisations par rôles organisés
hiérarchiquement.
 Les modèles à base de rôles :
– sont bien adaptés aux applications de gestion :
• un rôle pour chaque fonction dans l’entreprise.
– permettent une administration souple des droits

d’accès.
22
Hiérarchie de rôles : exemple
23
Modèles obligatoires
 Ils ont été développés pour des systèmes d’information
pour lesquels la préservation du secret est primordiale :
• militaires, par exemple.
 Ce sont des modèles multi-niveaux.
24
Niveaux d’accès
 On définit un ensemble de niveaux d’accès muni d’une
relation d’ordre :
– Top secret ≥ Secret ≥ Confidentiel ≥Non classifié
 Chaque sujet reçoit un niveau d’accès :
– son niveau d’habilitation.
 Chaque objet reçoit un niveau d’accès :
– son niveau de classification.
25
Modèle de Bell et La Padula
Il est basé sur deux règles :
 No Read Up : Un sujet peut seulement lire les objets dont
le niveau de classification est inférieur ou égal au niveau
d’habilitation de ce sujet.
 No Write Down : Un sujet peut seulement écrire les objets
dont le niveau de classification est supérieur ou égal au
niveau d’habilitation de ce sujet.
26
Nécessité du No Write Down
 Supposons l’absence de la règle du No Write Down.
 Soit un programme P habilité Secret :
– P peut lire un fichier F classifié Secret puis écrire dans
un fichier F’ non classifié l’information secrète qu’il a
lue dans F (sans la règle du No Write Down, il en a le
droit).
– Un utilisateur non classifié pourra alors accéder à cette
information secrète en lisant F’ auquel il a le droit
d’accès.
27
Leurres
 Un leurre est une information fausse introduite dans une
BD multi-niveaux (en général) pour protéger l’existence
d’une information sensible.
28
Exemple de leurre
 Supposons que les 2 informations suivantes soit classée
Secret :
– « Le salaire mensuel de Jean est de 600 € »,
– « Le salaire de Jean est classé secret ».
 A la question:
– « Quel est le salaire de Jean ? »
on ne peut donc pas répondre :
– « Le salaire de Jean est secret ou inconnu. »
 On affecte donc à Jean un faux salaire (200 €, par exemple)
mais publique.
– Ce faux salaire est un leurre.
29
Modèles obligatoires :
avantages et inconvénients
 Il sont bien adaptés aux applications ou la protection du
secret est primordiale.
 Mais ils sont trop rigides et trop centralisés.
 La confidentialité est assurée au détriment de la
disponibilité.
30
Contrôle de canaux cachés
 Un canal est un support de communication de l’information :
bus, ligne téléphonique, réseau…
 Un canal caché est un canal qui peut être exploité par un
processus pour transmettre de l’information en violation de la
politique de sécurité.
 Les canaux cachés résultent très souvent de particularités
liées à l’implantation
– Difficile d’en tenir compte dans un modèle théorique représentant un
certain niveau d ’abstraction.
31
Exemple de canaux cachés
 Canal caché de stockage
– Deux programmes qui partagent une ressource commune (un espace
disque, par exemple) peuvent échanger des informations sensibles en
utilisant les changements d’état de cette ressource.
– Par exemple, en créant un fichier, le programme émetteur peut
transmettre au programme récepteur une information contenue dans
le nom de ce fichier (par exemple, un code alphanumérique).
 Canal caché temporel
– Un programme peut transmettre une information sensible en
modulant temporellement l’utilisation d’une ressource (par exemple,
le temps d’exécution). Le programme récepteur récupérera cette
information en décodant cette modulation.
32
Contrôle d’inférence
 L’inférence dans le cadre de la sécurité d’une BD est la
possibilité d’obtenir des informations confidentielles à partir
d’informations non confidentielles.
 On appelle canal d’inférence un canal par lequel un

utilisateur peut atteindre un ensemble X de données
(autorisées) et en déduire un ensemble Y de données (non
autorisées) par application d’une fonction f à X : Y = f(X)
33
Contrôle d’inférence dans les BD
statistiques
 Une BD statistique est une BD dans laquelle :
– les données ne sont accessibles que par des fonctions
statistiques : somme, moyenne, variance…
– l’accès aux données individuelles n’est pas autorisé,
 Il faut empêcher un utilisateur d’obtenir des informations
individuelles à partir d’informations statistiques.
34
Protection des BD statistiques
Deux types de techniques sont utilisées pour protéger
les BD statistiques contre les attaques par inférence :
 Techniques de restriction :
– elles consistent à poser des contraintes sur les tailles d’échantillons
qui peuvent être interrogés.
 Techniques de perturbation :
– elles consistent à introduire des modifications soit dans les
enregistrements de la base de données, soit dans les réponses aux
requêtes pour cacher la valeur exacte des informations individuelles.
35
Techniques de restriction (1)
 On peut interdire les requêtes sur les données
individuelles.
 Ce n’est pas suffisant :
– Soit un ensemble de personnes décrites par la relation
personne(nom, salaire).
– Dupont veut connaître le salaire de Durand. Il demande :
s := SELECT sum(salaire) FROM personne
WHERE nom in ('Dupont', 'Durand')
– Il en déduit :
salaire(Durand) = s - salaire(Dupont)
36
 On peut imposer qu’un échantillon et son complément ait
une cardinalité supérieure à un seuil donné.
 Ce n’est pas non plus suffisant :
– Dupont construit un ensemble P de personnes ne contenant pas
Durand, tel que card(P) et card(Personnes – P) soient supérieures
au seuil fixé.
– Il demande :
s1 := SELECT sum(salaire) FROM P
s2 := SELECT sum(salaire) FROM P UNION {Durand}
– Il en déduit alors le salaire de Durand :
salaire(Durand) = s2 – s1
37
 On peut en plus limiter la taille des intersections entre les
échantillons interrogés ne dépasse un certain seuil.
 Si l’on interdit les intersections de taille supérieures à 3,
le salaire de Durand ne pourra pas être retrouvée par les
requêtes précédentes :
– s1 = {p1, p2, p3, p4, p5}
– s2 = {p1, p2, p3, p4, p5, Durand}
– card(s2 – s1) = 5 > 3
 Cette solution impose la mémorisation des résultats des

requêtes.
38
Contrôle d’accès en SQL
 Gestion des utilisateurs
 Gestion des privilèges
 Gestion des rôles
 Implantation d’un modèle obligatoire
39
Sujets, objets, privilèges et rôles
 Sujets
– utilisateurs, groupe d’utilisateurs, tous les utilisateurs
 Objets
– BD, tables, vues, index, procédures…
 Privilèges (ou autorisations)
– sur les tables,
– sur le schéma,
– sur la base de données…
 Rôles
– groupes de privilèges
40
Modèle de contrôle d’accès
Le modèle de contrôle d’accès SQL est un modèle
discrétionnaire :
 Le créateur d’un objet possède tous les privilèges sur cet
objet.
 Pour pouvoir accéder à un objet qu’il n’a pas créé, un
utilisateur doit avoir reçus les privilèges nécessaires.
41
Processus de contrôle
42
Gestion des utilisateurs
 La création des utilisateurs est du ressort de l’administrateur
de la base de données qui peut créer :
– des utilisateurs,
– des groupes d’utilisateurs.
 SQL2 ne spécifie pas de commande pour la création des

utilisateurs :
– cette commande est donc spécifique à chaque SGBD.
43
Gestion des privilèges
On distingue :
 les privilèges objets qui concernent des opérations précises
sur des tables, des vues, des procédures stockées…, dont le
nom est spécifié ;
 les privilèges systèmes qui concernent des opérations sur
tous les objets d’un certaine catégorie.
Ces privilèges varient sensiblement d’un SGBD à l’autre.
44
Privilèges objets (1)
 SELECT SELECT(c1, …, cn)
– pour pouvoir lire le contenu de toutes ou de certaines colonnes d’une
table.
 INSERT INSERT(c1, …, cn)
– pour pouvoir insérer une valeur dans toutes ou certaines colonnes
d’une table.
 UPDATE UPDATE(c1, …, cn)
– pour pouvoir modifier le contenu de toutes ou de certaines colonnes
d’une table.
 DELETE
– pour pouvoir supprimer des lignes d’une table.
45
Privilèges objets (2)
 REFERENCES REFERENCES(c1, …, cn)
– pour pouvoir faire référence à une table ou à certaines colonnes
d’une table dans une contrainte d’intégrité.
 TRIGGER
– pour pouvoir placer un trigger sur une table.
 USAGE
– pour pouvoir manipuler les domaines.
 EXECUTE
– pour pouvoir exécuter une procédure stockée.
46
Privilèges système
 ORACLE, par exemple, propose un jeu très complet de
privilèges systèmes (plus d’une centaine) qui permettent
de réaliser des opérations sur tous les objets d’une
certaine catégorie :
 Par exemple :
– INSERT ANY TABLE
– DELETE ANY INDEX
47
Octroi ou révocation de
privilèges
 SQL offre deux commandes pour octroyer ou révoquer des
privilèges :
• GRANT
• REVOKE
48
GRANT
 Syntaxe
GRANT (liste de privilèges | ALL)
ON liste d’objets
TO liste d’utilisateurs | PUBLIC
[WITH GRANT OPTION]
avec :
 ALL
• tous les privilèges que le donneur peut accorder
 PUBLIC
• tous les utilisateurs connus du système
 WITH GRANT OPTION

• indique que le receveur pourra transmettre les privilèges qui
lui sont octroyés 49
REVOKE
 Syntaxe
REVOKE [GRANT OPTION FOR] (privilèges | ALL)
ON liste d’objets
FROM liste d’utilisateurs
[{RESTRICT | CASCADE}]
avec :
 CASCADE : la révocation concerne les utilisateurs cités dans la clause
FROM ainsi que ceux à qui ces privilèges ont été récursivement
transmis.
 RESTRICT : la révocation ne concerne que les utilisateurs cités dans

la clause FROM.
 GRANT OPTION FOR : ce n’est pas les privilèges qui sont révoqués,
mais le droit de le transmettre. 50
Règle d’octroi des privilèges
 Un utilisateur ne peut octroyer que les privilèges qu’il
possède.
51
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.
52
Graphe d’octroi des privilèges
C’est un outil pratique pour gérer la propagation
des privilèges et leur révocation.
 chaque nœud représente un utilisateur, il est étiqueté par le
nom de cet utilisateur,
 chaque arc représente un octroi de privilège, il est étiqueté
par ce privilège.
53
Octroi de privilèges : exemple
 Alice : GRANT SELECT ON departement TO odile WITH GRANT OPTION;
 Alice : GRANT SELECT ON departement TO pierre WITH GRANT OPTION;
 Odile : GRANT SELECT ON departement TO alain WITH GRANT OPTION;
 Pierre : GRANT SELECT ON departement TO alain WITH GRANT OPTION;
 Alain : GRANT SELECT ON departement TO isabelle;
 * indique que le privilège a été accordé WITH GRANT OPTION.
54
Révocation en cascade : exemple
Alice : REVOKE SELECT ON département FROM odile CASCADE
55
Révocation avec restriction :
exemple
 Alice : REVOKE SELECT ON département FROM odile RESTRICT

Interdit !
 Alain : REVOKE SELECT ON departement FROM isabelle RESTRICT
56
Importance des vues
 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.
 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
 et en accordant des privilèges sur chacune de ces deux vues, par
exemple :
– GRANT UPDATE ON salaire_employe TO pierre 57
Exemple de mise en place des contrôles
d’accès sur une base de données
On considère une BD décrivant une petite entreprise :

 La BD décrit :
– les employés : nom, salaire, nom du département,
– les départements : nom, nom du responsable.
 Les utilisateurs de la BD sont ses employés :
– Alice est l’administratrice de la BD,
– Odile est la directrice du personnel,
– Pierre est l’agent comptable,
– Alain est responsable du département Informatique,
– Isabelle est une employé du département Informatique.
58
Exemple : création des
utilisateurs
 Alice, l’administratrice, crée la BD :
CREATEDB ma_petite_entreprise
 Alice se connecte à la BD :
CONNECT TO ma_petite_entreprise USER DBA;
 Alice crée les utilisateurs de cette BD:

CREATE USER alain;
CREATE USER isabelle;
CREATE USER odile;
CREATE USER pierre;
59
Exemple : création des tables
 Alice crée deux tables décrivant les employés et les
départements:
CREATE TABLE employe (nom VARCHAR(20) PRIMARY
KEY, nom_dept VARCHAR(20), salaire FLOAT);
CREATE TABLE departement (nom VARCHAR(20)
PRIMARY KEY,responsable VARCHAR(20)REFERENCES
employe(nom));
ALTER TABLE employe ADD FOREIGN KEY (nom_dept)
REFERENCES departement(nom);
60
Exemple : création des vues
 Alice crée une vue qui cache les salaires des employés :
CREATE VIEW affectation(nom, nom_dept) AS

SELECT e.nom, e.nom_dept FROM employe e;
 Alice crée une vue qui donne le nom et le salaire de chaque employé
du département dont l’utilisateur de cette vue est le responsable :
CREATE VIEW mon_employe(nom, salaire) AS
SELECT e.nom, e.salaire
FROM employe as e
WHERE e.nom_dept IN
(SELECT nom
FROM departement
WHERE responsable = USER);
61
Exemple : octroi des privilèges
 Alice transmet à tous les utilisateurs le privilège de
consulter les affectations :
GRANT SELECT ON affectation TO PUBLIC;
 Alice transmet à Alain, responsable du département
Informatique, le privilège de consulter le salaire des
employés de ce département.
GRANT SELECT ON mon_employe TO alain;
62
Exemple : octroi des privilèges
 Alice transmet à Odile, la directrice du personnel, les privilèges de
consulter et de modifier le département dans lequel travaille un employé
et le responsable d’un département.
GRANT SELECT, UPDATE(nom_dept)
ON employe TO odile;
GRANT SELECT, UPDATE(responsable)
ON departement TO odile;
 Alice transmet à Pierre, l’agent comptable, les privilèges de consulter et
de modifier le salaire des employés.
GRANT SELECT, UPDATE(salaire)
ON employe TO pierre;
63
Exemple : matrice d’accès
64
Exemple : effets sur les requêtes
65
Exemple : révocation de
privilèges
 Alice révoque le privilège de Pierre de modifier le salaire
d’un employé :
REVOKE UPDATE(salaire)
ON employé
FROM pierre;
Pierre possède encore le privilège de consulter les
affectations.
66
Gestion des 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.
67
Gestion des rôles en SQL Oracle
 Création d’un rôle
CREATE ROLE nom de rôle
 Octroi d’un privilège à un rôle
GRANT liste de privilèges
ON liste d’objets
TO liste de rôles ou d’utilisateurs
 Octroi d’un rôle à un rôle ou à un utilisateur
GRANT liste de rôles
TO liste de rôles ou d’utilisateurs
 Activation d’un rôle
SET ROLE liste de rôles
68
Exemple : les rôles
Les 5 rôles de la BD ma_petite_entreprise:
 employé :
– privilège de consulter les affectations
 responsable (de département) :
– privilège employé
– privilège de consulter les salaires de ses employés
 srh (service des ressources humaines) :
– privilège employé,
– privilège de modifier le département dans lequel travaille un employé et le
responsable d’un département.
 agent_comptable :
– privilège employé
– privilège de mettre à jour le salaire des employés
 administrateur
– tous les privilèges
69
Exemple : graphe des rôles
70
Exemple : création du rôle
employé
 CREATE ROLE employe;
 GRANT SELECT
ON affectation
TO employe;
 GRANT employe
TO isabelle;
71
responsable
 CREATE ROLE responsable;
 GRANT employe TO responsable;
 GRANT SELECT
ON mon_employe
TO responsable;
 GRANT responsable TO alain;
72
Exemple : création du rôle srh
 CREATE ROLE srh;
 GRANT employe TO srh;
 GRANT UPDATE(nom_dept)
ON employe
TO srh;
 GRANT UPDATE(responsable)
ON departement
TO srh;
 GRANT srh TO odile;
73
comptabilité
 CREATE ROLE comptabilite;
 GRANT employe TO comptabilite;
 GRANT UPDATE(salaire)
ON employe
TO comptabilite;
 GRANT comptabilite TO pierre;
74
Contrôle d’intégrité
 Réf. cours Intégrité des bases de données
75
Charges d’un administrateur de
BD
Les principales charges d’un administrateur de BD sont :
 l’installation des serveurs de BD et de leurs miroirs,
 la gestion et le contrôle des espaces mémoires et des connexions,
 la gestion des utilisateurs,
 l’allocation et la révocation des privilèges et des rôles,
 la sauvegarde et la restauration des BD et des journaux,
 le diagnostic des problèmes systèmes,
 la configuration du serveur pour de meilleures performances.
76
Installation
 L’installation d’un serveur de BD concerne le serveur lui-
même et son environnement logiciel.
 Ceci implique :
– une bonne connaissance de l’architecture du serveur, de ses
différentes versions (« releases ») et de la documentation
technique,
– une bonne coopération avec l’administrateur système et réseau.
77
Ressources physiques
 Ces ressources sont : les machines, la mémoire centrale,
les espaces disques.
 L’administrateur doit notamment fixer la localisation du
serveur et des bases : sur la même machine ou sur des
machines à part ?
 L’administrateur doit avoir une bonne connaissance du
volume d’activité du serveur de bases de données :
– nombre et volume des bases de données,
– nombre de connexions simultanées…
78
Sauvegardes et restaurations
Des sauvegardes régulières et sûres (dans une mémoire
stable) devront être réalisées :
 de la métabase, cœur du serveur de BD, qui décrit tout ce
qui ce que ce serveur connaît : les BD, les objets de celles-
ci, les utilisateurs et leurs droits, l’utilisation des espaces
mémoire…
 des BD,
 des journaux de transaction (« write-ahead logs »),
 …
79
Exploitation
 Le serveur de BD ou le système d’exploitation peuvent
être arrêtés volontairement ou non. Leur relance doit être
maîtrisée.
 En cours d’exploitation, il faut :
– examiner régulièrement les journaux de compte-rendus maintenus
par le serveur,
– analyser l’activité des bases de données pouraméliorer les
performances : commande VACUUM de PostgreSQL,
– …
80
Carnet de bord
L’administrateur doit tenir un carnet de bord contenant :
 les références des différents contacts (administrateur système et réseau,
fournisseurs…)
 l’identification du matériel sur lesquels sont installés les serveurs et leurs
clients,
 les noms, les localisations et les tailles des espaces créés,
 les paramètres de configuration,
 l’échéancier des sauvegardes et des examens de compte-rendus,
 les scripts de création des BD et de leurs objets,
 les procédures de sauvegarde et de reprise des BD,
 les différents problèmes rencontrés et les solutions apportées,
 …
81

5 - Securité Des BD

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

5 - Securité Des BD

Transféré par

Droits d'auteur :

Formats disponibles

Sécurité des bases de données

Ne pas donner les droits de l’administrateur à tout

 D'autres enfin, plus sophistiqués, incluent des obligations

 Il y a donc décentralisation du contrôle d’accès.

– permettent une administration souple des droits

 Ce sont des modèles multi-niveaux.

 On appelle canal d’inférence un canal par lequel un

 Cette solution impose la mémorisation des résultats des

 SQL2 ne spécifie pas de commande pour la création des

Ces privilèges varient sensiblement d’un SGBD à l’autre.

 WITH GRANT OPTION

 RESTRICT : la révocation ne concerne que les utilisateurs cités dans

 * indique que le privilège a été accordé WITH GRANT OPTION.

Alice : REVOKE SELECT ON département FROM odile CASCADE

 Alice : REVOKE SELECT ON département FROM odile RESTRICT

On considère une BD décrivant une petite entreprise :

 Alice crée les utilisateurs de cette BD:

CREATE VIEW affectation(nom, nom_dept) AS

Vous aimerez peut-être aussi