Cours-Gratuit
  • Accueil
  • Blog
  • Cours informatique
home icon Cours gratuits » Cours informatique » Cours bases de données

Cours Sécurité des bases de données

Cours Sécurité des bases de données
Participez au vote ☆☆☆☆☆★★★★★

Sécurité des bases de données

Jacques Le Maitre

Université du Sud Toulon-Var

Ce cours est mis à disposition selon les termes  de la licence CreativeCommons

Paternité-Pas d'Utilisation Commerciale-Pas de Modification 2.0 France


Introduction


Maintien de la confidentialité

p  Il s’agit de détecter ou d’empêcher des accès non autorisés.

p  C’est crucial :

n  dans des environnements critiques ou stratégiques : militaires ou commerciaux, par exemple.

n  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.


Maintien de la disponibilité

p  Il s’agit de détecter ou d’empêcher des dénis de service.

p  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.

p  Par exemple, une attaque consistant à saturer un serveur de fausses requêtes empêchant les requêtes valides d’être exécutées.


Contrôle d’accès

p Un système de contrôle d’accès comprend :

n  des sujets : utilisateurs, processus… qui peuvent être classés par groupes,

n  des objets : données, programmes…

n  des opérations : lecture, ajout, modification, suppression…, déclenchées par les sujets sur les objets

n  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.

n  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.

Politique de sécurité

p Les ITSEC définissent la politique de sécurité 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.


Principe du moindre privilège

p  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.

p  Ex : ne pas donner les droits de l’administrateur à tout utilisateur d’un système (système d’exploitation, SGBD). 

Autorisation, interdiction et obligation

p  Les règlements les plus simples ne contiennent que des autorisations :

Ø  ce qui n’est pas autorisé est interdit.

p  Certains règlements incluent des interdictions afin de spécifier des exceptions à des permissions générales.

n Ex : les patients ont droit de consulter leur dossier médical sauf Jean Dupont.

p  D’autres enfin, plus sophistiqués, incluent des obligations :

Ø  difficiles à implanter dans les systèmes informatiques.

Modèles de contrôle d’accès

p  On distingue deux grandes catégories de modèles de contrôle d’accès :

n les modèles discrétionnaires :

p  Le créateur d’un objet en est son propriétaire et le transfert des privilèges sur ces objets est à sa discrétion.

n les modèles obligatoires :

p Il s’agit de protéger le secret et l’intégrité.

p Les sujets (ou utilisateurs) et objets sont classés par niveaux (ex: Top secret, Secret, Confidentiel, Public).

Contrôle d’inférence

p  L’objectif du contrôle d’inférence est protéger une BD des attaques consistant  à déduire des données non autorisées à partir de données autorisées.

p  Ex : interdire l’accès à des données individuelles dans une BD statistiques à partir de requêtes agrégatives (comptage, somme, moyenne...).

Sécurisation des applications

p Les attaques à une BD peuvent exploiter les failles des applications opérant sur cette BD :

n  stockage des mots de passe dans les fichiers de configuration de l’application, 

n  scripts de connexion à la BD accessibles dans le code source de l’application,

n  attaques par injection SQL,

n  attaques exploitant les débordements de tampons

...

Injection SQL (1)

p On suppose qu’une application récupère le nom username et le mot de passe password saisi, dans un formulaire, par un utilisateur et se connecte à la BD en exécutant la requête affectée à la variable $requete composée par concaténation :

n $requete =

 "SELECT * 

  FROM users 

  WHERE username = '" & username & "' 

  AND password = '" & password & "' ;" 

Audit

p Un outil indispensable pour assurer la sécurité d’une BD est l’audit basé sur un journal des différents types d’accès à la BD :

n  audit des entrées dans la base,

n  audit des utilisations de la BD en dehors des heures ouvrables,

n  audit de la manipulation du schéma,

n  audit des erreurs,

n  audit des modifications des sources des procédures stockées et des triggers,

n  audit des modifications des attributs de sécurité (login, privilèges...) ...


Modèles de contrôle d'accès

Principaux modèles

p  Modèles discrétionnaires  à base de matrice d’accès

p  Modèle à base de rôles

p  Modèles obligatoires

n  Modèle de Bell et LaPadula

Ø  protection du secret

n  Modèle de Biba

Ø  protection de l’intégrité

p  Les modèles à base de rôle et les modèles obligatoires s’appuient aussi sur une matrice d’accès.

Modèles discrétionnaires

p  Chaque objet a un propriétaire (en général, son créateur) qui décide quels sont les autres sujets qui ont accès à cet objet :

Ø d’où le nom de « discrétionnaire »

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

p  Ce contrôle peut malgré tout être centralisé en confiant tous les droits à l’administrateur du système.


Modèle HRU

p  Le modèle HRU est basé sur l’utilisation d’une matrice d’accès indiquant les modes d’accès à un objet autorisés pour un sujet.

p  Le système est défini par le quadruplet  (S, O, R, M) :

n    S est l’ensemble des sujets,

n    O est l’ensemble des objets, n R est l’ensemble des mode d’accès, n M est la matrice d’accès.


Administration des autorisations

p  Le créateur d’un objet reçoit automatiquement own sur cet objet :

Ø il en est le propriétaire.

p  Le propriétaire d’un objet peut octroyer/révoquer à un autre sujet n’importe quel autre privilège sur cet objet excepté le privilège own.

p  Un sujet ayant un privilège sur un objet sans en être le propriétaire peut transmettre ce privilège.

p  Si m est un privilège r, w, a ou x et   m* ? M[s, o] est autorisé à octroyer à s le privilège m sur l’objet o.

Modèles discrétionnaires : avantages et inconvénients

p  Ils sont simples à mettre en œuvre.

p  Ce sont les plus implantés : UNIX, SQL…

p  Le contrôle de la propagation des droits et celui de la révocation des droits propagés posent des problèmes difficiles.

p  Ils sont vulnérables aux chevaux de Troie.


Modèles à base de rôles

p  On peut améliorer les modèles discrétionnaires en créant des rôles qui sont des ensembles d’autorisation.

p  Les autorisations sont octroyés aux rôles et les rôles aux utilisateurs.

p  Pour pouvoir réaliser une action sur un objet un utilisateur doit ouvrir une session et activer celui de ses rôles qui contient l’autorisation de réaliser cette action.

p  Un rôle peut hériter des privilèges d’un autre rôle.

p  Les modèles à base de rôles :

n  sont bien adaptés aux applications de gestion : un rôle pour chaque fonction dans l’entreprise.

n  permettent une administration souple des privilèges.


Modèle de Bell et LaPadula (BLP)

p  Le modèle de Bell et LaPadula a pour objectif la protection du secret des informations.

p  Il est basé sur la classification des objets et des sujets par niveaux de secret.

p  L’ensemble des niveaux de secret est muni d’un ordre partiel (?). Par exemple :

n Top secret (TS) > Secret (S) > Confidentiel (C) > Non classifié (NC).

Définition du système

p  Le système est défini par le 7-uplet  (S, O, R, b, M, f, H) :

n  S, O, R, M comme dans le modèle HRU,

n  b est l’ensemble des accès courants, il est composé de triplets (s, o, m) spécifiant que le sujet s a un accès courant à l’objet o en mode m,

n  f est la fonction de niveau qui associe à chaque sujet ou à chaque objet un niveau de sécurité :

p  fo(o) est le niveau de sécurité de l’objet o,

p  fs(s) est le niveau de sécurité affecté à un sujet lorsqu’il est créé dans le système,

p  fc(s) est le niveau de sécurité courant du sujet s, celui avec lequel il entre dans une session (fc(s) ? fs(s)).

n H une classification hiérarchique des objets.

Objets

p  Les objets sont des éléments passifs du système qui contiennent des informations.

p  Chaque objet reçoit un niveau de secret.

p  Ce niveau reflète la sensibilité de l’information stockée dans cet objet et donc le problème que poserait la transmission de cette information à un utilisateur non autorisé à la consulter.

p  Le niveau de secret d’un objet doit dominer celui de ses parents dans la hiérarchie de classification H.

Utilisateurs et sujets

p  Chaque utilisateur reçoit un niveau de secret.

p  Ce niveau traduit la confiance faite à un utilisateur de ne pas transmettre une information à un utilisateur ayant un niveau de secret inférieur au niveau de secret de cette information.

p  Un utilisateur peut entrer dans le système à tout niveau ? à son niveau de secret.

p  Les sujets sont des processus activés par les utiisateurs.

p  Les sujets activés par un utilisateur reçoivent le même niveau de secret que celui-ci.


Propriété de sécurité discrétionnaire sd

p  Règles. Chaque accès courant doit être présent dans la matrice d’accès : un sujet ne peut effectuer que les accès pour lesquels il a les autorisations nécessaires.

p  Un état (b, M, f, H) satisfait la propriété sd si, et seulement si, pour chaque  (s, o, m) ? b on a m ? M[s, o].

Propriété de simple sécurité (ss)

p  Règle. Un sujet s peut lire ou écrire une information dans un objet o seulement si le niveau de secret de s est ? au niveau de secret de o.

p  Un état (b, M, f, H) satisfait la propriété ss si, et seulement si, pour chaque 

(s, o, m) ? b tel que m = r ou m = w on a fS(s) ? fO(o).

p  La satisfaction de cette propriété assure qu’un sujet n’accédera pas à une information classée à un niveau plus haut que lui. 


Propriété *

p  Règles. Un sujet s qui n’est pas de confiance peut :

n  ajouter une information dans un objet o seulement si le niveau de sécurité courant de s est ? au niveau de secret de o,

n  écrire une information dans un objet o seulement si le niveau de secret courant de s est = au niveau de secret de o,

n  lire une information dans un objet o seulement si le niveau de secret courant de s est ? au niveau de secret de o.

p  Un état (b, M, f, H) satisfait la propriété * si, et seulement si, pour chaque (s, o, m) ? b tel que s n’est pas un sujet de confiance on a :

n  m = a ? fc(s) ? fo(o)

n  m = w ? fc(s) = fo(o)

n  m = r ? fc(s) ? fo(o)


Exemple d’état sécuritaire

niveaux de secret = 1 < 2 < 3 < 4 < 5 < 6 < 7 < 8  sujets : Alice et Odile (de confiance),  Pierre (non de  confiance)

M

F1

P

F2

F3

Alice

r, w

r

Pierre

r

r

w

Odile

x

a

r

F1

P

F2

F3

fO

4

8

3

1

fS

fC

Alice

7

4

Pierre

5

1

Odile

6

2

b = {(Alice, F1, r), (Pierre, F3, w), (Odile, P, x)}

Exemple d’état non sécuritaire

niveaux de secret = 1 < 2 < 3 < 4 < 5 < 6 < 7 < 8 sujets : Alice et Odile (de confiance),  Pierre (non de  confiance) 

M

F1

P

F2

F3

Alice

r, w

r

r

Pierre

r

r

w

Odile

x

r

F1

P

F2

F3

fO

4

8

3

1

fS

fC

Alice

7

4

Pierre

5

3

Odile

6

2

b = {(Alice, P, r), (Pierre, F3, w), (Odile, F2, a)}

•  l’accès d’Alice à P contrevient à ss

•  l’accès de Pierre à F3 contrevient à *

•  l’accès d’Odile à F2 contrevient à sd


Modèle de Biba

p  Le modèle de Biba (K. J. Biba, 1977) a pour objectif la protection de l’intégrité des informations.

p  Il applique à la protection de l’intégrité une stratégie similaire à celle de la protection du secret par le modèle BLP : les sujets et les objets sont classés par niveaux d’intégrité.

p  L’ensemble des niveaux d’intégrité est muni d’un ordre partiel (?). Par exemple :

n Crucial (TS) > Très important (TI) > Important (I) > Non classifié (NC)


Classification des utilisateurs

p  Chaque utilisateur reçoit un niveau d’intégrité.

p  Ce niveau traduit la confiance faite à un utilisateur pour insérer, modifier ou supprimer de l’information.

p  Les sujets activés par un utilisateur reçoivent le même niveau de secret que celui-ci.



Contrôle d’accès en SQL


Création des utilisateurs

p  La création des utilisateurs est du ressort de l’administrateur de la base de données qui peut créer :

n  des utilisateurs,

n  des groupes d’utilisateurs.

p  SQL2 ne spécifie pas de commande pour la création des utilisateurs :

Ø cette commande est donc spécifique à chaque SGBD.


Privilèges objets (1)

pSELECT SELECT(c1, …, cn) 

n pour pouvoir lire le contenu de toutes ou de certaines colonnes d’une table.

pINSERT INSERT(c1, …, cn) 

n pour pouvoir insérer une valeur dans toutes ou certaines colonnes d’une table.

pUPDATE UPDATE(c1, …, cn)  

n pour pouvoir modifier le contenu de toutes ou de certaines colonnes d’une table.

pDELETE

n pour pouvoir supprimer des lignes d’une table.


Règles de révocation des privilèges

p    Un utilisateur ne peut révoquer que les privilèges qui lui ont été transmis.

p    Si l’option CASCADE est spécifiée, la révocation d’un privilège est récursive.

p    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.

p    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.


Pierre

Alice : REVOKE SELECT ON département FROM odile CASCADE

Odile

                                                         Alice                                  Alain                    Isabelle

SELECT 

SELECT 

ON departement*

ON departement*

Pierre


Importance des vues

p  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.

p  Par exemple, si la BD est formée de la table :

n  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 :

n  create view affectation_employe(nom, departement) as   select nom, departement from employe n 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 :

n  grant update on salaire_employe to pierre

Exemple de mise en place des contrôles d’accès sur une base de données

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

n La BD décrit :

p  les employés : nom, salaire, nom du département, p les départements : nom, nom du responsable. 

n Les utilisateurs de la BD sont ses employés :

p Alice est l’administratrice de la BD,

p Odile est la directrice du personnel,

p Pierre est l’agent comptable,

p Alain est responsable du département Informatique,

p Isabelle est une employé du département Informatique.


Exemple : création des vues

p  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;

p  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); 

Exemple : octroi des privilèges  

p  Alice transmet à tous les utilisateurs le privilège de consulter les affectations :

 GRANT SELECT ON affectation TO PUBLIC;

p  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;

Exemple : octroi des privilèges  

p  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;

p  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;


Exemple : effets sur les requêtes

SELECT *

FROM affectation

UPDATE employe

SET salaire = 2000

WHERE nom = 

'isabelle'

UPDATE departement SET responsable = 

'isabelle' 

WHERE nom = 

'informatique'

alain

acceptée

refusée

refusée

alice

acceptée

acceptée

acceptée

isabelle

acceptée

refusée

refusée

odile

acceptée

acceptée

acceptée

pierre

acceptée

acceptée

refusée


Privilèges en PostgreSQL

p   Les privilèges sur une table ne peuvent pas être restreints à certaines des colonnes de cette table.

p   Pour placer un privilège INSERT ou UPDATE sur certaines colonnes d’une table T, il faut :

1. construire une vue de cette table restreinte :

p   aux colonnes à mettre à jour,

p   aux colonnes permettant de sélectionner les lignes à mettre à jour ;

2. créer une règle ON INSERT ou ON UPDATE, déclenchant les mises à jour sur la table T.

Utilisateurs et rôles  en PostgreSQL version 8

p  Le concept d’utilisateur est subsumé par celui de rôle. 

p  Un rôle est une entité qui peut posséder des objets ou bien des privilèges sur des objets. 

p  On distingue :

n  les rôles de connexion, qui possèdent un login et peuvent se connecter à la BD,

n  les rôles de groupe, qui ne possèdent pas de login.


Exercice : gestion du M2 (3)

p  L’administrateur de la base de données a l’autorisation de  créer les tables et de transmettre les privilèges sur ces tables.

p  Le secrétaire a l’autorisation de créer et de modifier les informations concernant :

n  les étudiants et les enseignants : nom, e-mail, adresse, téléphone, personne à prévenir en cas d’accident…

n  les UE : code, responsable, intervenants, intitulé, ECTS…

p  Le responsable d’une UE a l’autorisation d’ajouter ou de modifier la note réelle d’un étudiant dans cette UE.

p  Le responsable du M2 a l’autorisation de créer ou modifier la note finale d’un étudiant à une UE et au M2. Il dispose de points de jury accordés par les membres du jury (les enseignants) qu’il répartit entre les différentes UE.

Exercice : gestion du M2 (3)

p  Tous les utilisateurs ont l’autorisation de consulter :

n  les informations qui les concernent,

n  les noms, prénoms et e-mails des étudiants et des enseignants,

n  les informations concernant les UE : code, intitulé, enseignants, ECTS, … n les notes finales.

p  Le secrétaire a l’autorisation de consulter les informations personnelles des étudiants et des enseignants (adresse, téléphone, personne à prévenir en cas d’accident…).

p  Les étudiants ont l’autorisation de consulter leurs propres notes réelles et leurs points de jury.

p  Les enseignants ont l’autorisation de consulter les notes réelles et les points de jury.

p  Tout ce qui n’est pas autorisé est interdit !

Decouvrir ces documents

  • Cours complet sur les Bases de données

    Cours complet sur les Bases de données

  • Introduction aux bases de données SQL

    Introduction aux bases de données SQL

  • Cours VB.Net et les Bases de Données

    Cours VB.Net et les Bases de Données

  • Bases de Données document

    Bases de Données document

  • Cours systèmes de Gestion de Bases de Données

    Cours systèmes de Gestion de Bases de Données

  • Débuter la programmation Visual Basic avec les Bases de Données

    Débuter la programmation Visual Basic avec les Bases de Données

  • Cours Bases de données relationnelle SQL Server

    Cours Bases de données relationnelle SQL Server

  • Cours informatique la sécurité des réseaux Internet

    Cours informatique la sécurité des réseaux Internet

Articles connexes

  • UE Bases de Données
  • Examen de Bases de Données 2006
  • TD 8 : Introduction aux bases de données Le langage SQL
  • Exercices gestion de bases de données relationnelles avec SQL
  • Sécurité en ligne pour les étudiants : protégez vos données et prémunissez-vous des cyberattaques
  • Cours de soutien scolaire bénévole - Informations et conseils
  • Rédiger une lettre de motivation master marketing au Canada
  • Cours particuliers : une nouvelle école informelle ?
  • Contactez-nous
  • A propos de nous
  • On recrute
  • Rechercher dans le site
  • Politique de confidentialité
  • Droit d'auteur/Copyright
  • Conditions générales d'utilisation
  • Plan du site
  • Accueil
  • Blog
  • Finance et compta.
  • Formations Pro.
  • Logiciels & Apps
  • Organisation
  • Cours informatique
  • Aide à la rédaction
  • Etudes et Metiers
  • Science et Tech
  • Titans de la Tech
id 11354 02