Frédéric Cuppens Protection des systèmes d’informations :

Présentation au sujet: "Frédéric Cuppens Protection des systèmes d’informations :"— Transcription de la présentation:

1 Frédéric Cuppens Protection des systèmes d’informations :
Menaces et solutions actuelles Frédéric Cuppens Maître de recherches ONERA Toulouse (et IRIT Toulouse à partir de Novembre 2002)

2 Plan A. Contexte 1. Introduction 2. Exemples d’attaques B. Démarche pour la sécurité des systèmes d’information 3. Politique de sécurité 4. Détection d’intrusions 5. Authentification 6. Sécurité des communications 7. Politiques de contrôle d’accès C. Différents types de politiques de contrôle d’accès 8. Approche discrétionnaire 9. Approche basée sur les rôles 10. Base de données privée virtuelle D. Conclusion / perspectives

3 Evolution du contexte 1. Introduction Technologie Internet future
BlueTooth UMTS Infrastructure hétérogène Active Network Client/Serveur Réseaux avec connections multiples Hiperlan WLAN Infrastructure hétérogène Mainframe Gestion de données et d’applications Systèmes ouverts WAP I-mode Système de gestion indépendant Systèmes interropérants Niveau de complexité Gestion centralisée Gestion centralisée Chemins d’accès multiples Chemin d’accès unique Oracle2 Oracle6 Oracle7 Oracle8i Oracle9i 1980 1990 2000

4 Quelques statistiques
1. Introduction Quelques statistiques 1,2 Milliard $US Pertes d’eBay, Yahoo! and Amazon.com dues aux attaques contre leurs sites en 2000 Attaque contre la disponibilité (DDOS: Distributed Denial of Service) Source : Yankee Group 85 % Pourcentage des companies américaines et Canadiennes ayant trouvé un virus dans leur système Source : CSI/FBI 80 % Pourcentage estimé des attaques correspondant aux intrusions internes Source : FBI

5 Objectifs de l’intrusion
1. Introduction Objectifs de l’intrusion Confidentialité Accès illégal à certaines informations Exemples : sniffing, cracking, ... Objectifs de l’intrusion Intégrité Disponibilité Création, modification ou suppression illégale de l’information Empêche les utilisateurs d’avoir un accès autorisé au système Exemples : altering, spoofing, hijacking, ... Exemples : flooding, smurfing, ...

6 Nouvelles vulnérabilités Mécanismes de sécurité
1. Introduction Contexte actuel Nouvelles vulnérabilités Nouvelles menaces Hacker amateur E-crime Infowarrior menaces internes sabotage d’information critique Au moins 800 vulnérabilités nouvelles découvertes chaque année dans les environements Internet Nouveaux risques Nouveaux outils d’intrusion permettant d’exploiter automatiquement les vulnérabilités Firewall VPN Transactions électroniques sécurisées Secure mail Détection d’intrusion Mécanismes de sécurité

7 Principales “classes” d’attaque
2. Exemples d’attaques Principales “classes” d’attaque Sniffing Ecoute Spoofing Mascarade Flooding Deni de service Scanning Balayage des services Hijacking Interception / détournement de communication Virus et Chevaux de Troie

8 Packet sniffing (R-a-Probe)
2. Exemples d’attaques Packet sniffing (R-a-Probe) Destinataire Intercepter des paquets transmis via Internet (login, numéro de carte de crédit, autres données sensibles) Voler des nom de machines, Nom d’utilisateurs, mots de passe (même chiffrés), … Internet ou DMZ M M M Attaquant Emetteur

9 Flooding 2. Exemples d’attaques Principe : Flooding les plus fréquents
Envoyer un grand nombre de messages de sorte que le récepteur ne peut plus les gérer Conduit à un déni de service Ce déni de service peut provenir de plusieurs sources (DDOS pour Déni de service distribué) Flooding les plus fréquents Flooding TCP (ou Syn flooding) Flooding UDP Smurfing (exemple de flooding ICMP avec des paquets “Echo Request”)

10 SYN flooding (R-a-deny(temporary ou administrative))
2. Exemples d’attaques SYN flooding (R-a-deny(temporary ou administrative)) Attaque DoS sur les réseaux IP Connexion à moitié ouverte : le serveur insère les informations d’ouverture dans sa pile Trop de connexions à moitié ouverte peuvent conduire à un déni de service Serveur Client SYN Toto SYN - ACK Nerd SYN SYN SYN SYN Le client n’envoie pas de ack pour ouvrir la connexion Le serveur attend la réponse (ack) du client et conserve dans sa pile des connexions à moitié ouvertes

11 Smurfing (R-a-deny(temporary))
2. Exemples d’attaques Smurfing (R-a-deny(temporary)) Existence d ’une adresse « broadcast » en xxx.xxx.xxx.255 Si une machine du sous réseau envoie un message « echo request » à cette adresse,toutes les machines du sous-réseau vont répondre par un « echo reply » Internet ECHO REPLY de vers la victime ECHO REPLY de vers la victime ECHO REQUEST de la victime vers ECHO REPLY de vers la victime ECHO REPLY de vers la victime ECHO REPLY de vers la victime ECHO REPLY de vers la victime Envoi d ’un message « echo request » forgé avec l ’adress de la victime (spoofing) Des centaines de messages « echo reply » envoyés à la victime Attaquant Victime Principe du smurfing : amplification du flooding Jusqu ’à 255 messages reçus par la victime pour un message envoyé par l ’attaquant

12 Spoofing 2. Exemples d’attaques Principe :
Masquerade : forger des paquets avec de fausses adresses pour pour se faire passer pour une autre machine Spoofing les plus fréquents : Spoofing ARP (appelé également ARP poison) Spoofing ICMP Spoofing UDP Spoofing TCP

13 ARP Poison 2. Exemples d’attaques
Principle du protocole ARP (protocole non connecté): Dans le protocole ARP, chaque “requête” est diffusée aux autres machines d’un réseau local Chaque machine conserve dans son cache la correspondance Le cache est mis à jour lorsque la machine reçoit un “ARP reply” (même s’il n’a pas envoyé un “ARP request”) Principe de l’attaque : L’attaquant envoie des messages “ARP reply” avec qui ne correspond pas à Applications: Deni de service Hijacking

14 Hijacking ARP (R-m-Intercept)
2. Exemples d’attaques Hijacking ARP (R-m-Intercept) @IP @MAC 00:00:00:02 @IP @MAC 00:00:00:01 (1) Communication Cache ARP : @IP  @MAC 00:00:00:02 Cache ARP : @IP  @MAC 00:00:00:01 (2) ARP Poison ARP Reply : is-at @MAC 00:00:00:03 ARP Reply : is-at @MAC 00:00:00:03 Cache ARP : @IP  @MAC 00:00:00:03 Cache ARP : @IP  @MAC 00:00:00:03 Man In the Middle (MiM) @MAC 00:00:00:03 (3) Hijacking Cache ARP : @IP  @MAC 00:00:00:03 Cache ARP : @IP  @MAC 00:00:00:03

15 Scanning: exemples 2. Exemples d’attaques Objectif général :
Obtenir la liste des ports ouverts d’un système TCP SYN scanning (half-open scanning) Envoyer un message SYN, attendre un SYN-ACK et ensuite envoyer un RESET TCP FIN scanning Envoyer un message FIN et attendre un RESET (port fermé) sinon le port est ouvert UDP ICMP port unreachable scanning Pour scanner les services UDP Envoyer un paquet et attendre ensuite un message “ICMP_PORT_UNREACH” (port ouvert) sinon le port est fermé

16 Virus et Chevaux de Troie
2. Exemples d’attaques Virus et Chevaux de Troie Il y a des milliers de virus et de Chevaux de Troie Exemple : Back Orifice 2000 (bo2k) Création d’une porte dérobée (back door) Pour prendre le contrôle d’un système

17 Back Orifice 2000 2. Exemples d’attaques Etape 1: Etape 2: Etape 3:
Encapsuler bo2k dans un fichier « attractif » pour que la victime installe bo2k sur son système Etape 2: Connexion entre l’attaquant et bo2k via un port particulier (par exemple: 8080) Etape 3: Prendre le contrôle de la victime Lancer ou arrêter des services Modifier ou télécharger des fichiers Etc.

18 Exemple d’attaque pour obtenir les droits d’accès root
2. Exemples d’attaques Exemple d’attaque pour obtenir les droits d’accès root ShellCode (R-b-S) Effectue un Buffer Overflow Exemple: Red Code Principe : Mauvaise gestion de la mémoire dynamique Pas de séparation entre le code du programme et les données stockées dans la pile Le volume des données insérées est plus volumineux que l’espace mémoire alloué Pendant l’exécution, une sous-routine écrase l’adresse de retour Ce qui permet l’exécution d’un shellcode Vulnérabilité classique exploitée : Fonctions sur les chaînes de caractères (sprintf)

19 ShellCode 2. Exemples d’attaques Gestion de la pile Problème :
Appel fonction Début : Sauvegarde du contexte Création statique du domaine Exécution du programme Fin : Restoration du contexte Problème : L’adresse de retour peut être écrasée

20 Schéma d’un ShellCode 2. Exemples d’attaques Trois parties :
NOP Padding Car l’attaquant ne connait pas précisément la position du ShellCode Problème pour positionner exactement l’adresse de retour au début du ShellCode Instructions principales exécutées par le ShellCode Adresse du Shellcode Commentaires : La partie NOP est facilement détectée Mais existence de ShellCodes Polymorphiques Utilisation de biblothèques d’instructions équivalente adresse du shellcode … shellcode Début du shellcode NOP …

21 Attaque par injection de code SQL
2. Exemples d’attaques Attaque par injection de code SQL Attaque due au pirate Rain Forest Puppy Attaque contre une base données via une application proxy Page ASP Active Server Page Script Visual Basic Username: Base de données Réponse du SGBD Password:

22 Attaque par injection de code SQL (suite)
2. Exemples d’attaques Attaque par injection de code SQL (suite) Exemple de Script Visual Basic exécuté par le serveur : Dim sql Sql = "SELECT * FROM Users WHERE username = ' "& username &" ' AND password = ' "& password &" ' ; " Set rs = Comm.OpenRecordset(sql) If not rs.eof() then ' user connected successfully ' end if Si un utilisateur fournit Eric comme Username et duratrouver comme mot de passe, la requête suivante est envoyée au SGBD : SELECT * FROM Users WHERE username = 'Eric' AND password = 'duratrouver' ; Si la base retourne un n-uplet Connection ok

23 Attaque par injection de code SQL (suite)
2. Exemples d’attaques Attaque par injection de code SQL (suite) Réalisation de l’attaque : L’attaquant fournit le mot de passe suivant : Toto ' OR TRUE OR ' Dans ce cas, la requête suivante est envoyée à la base : SELECT * FROM Users WHERE username = 'Eric' AND password = 'Toto' OR TRUE OR ' ' ; Dans ce cas, le SGBD retourne l’ensemble des n-uplets de la relation Users L’attaquant va se retrouver connecté en tant que premier utilisateur de la base En général, il s’agira de l’administrateur de la base

24 Attaque par injection de code SQL (suite)
2. Exemples d’attaques Attaque par injection de code SQL (suite) Autre possibilité d’attaque Script Visual Basic Numero dossier : 1234 Base de données Résultat analyse : Réponse du SGBD

25 Attaque par injection de code SQL (suite)
2. Exemples d’attaques Attaque par injection de code SQL (suite) Script Visual Basic exécuté par le serveur : Dim sql Sql = "SELECT resultat FROM Dossier_analyse WHERE username = ' " & username & " ' AND numero_dossier = " & numero-dossier & " ; " Set rs = Comm.OpenRecordset(sql) Si Eric demande à connaître les résultats de ses analyses correspondant au numéro de dossier 1234, la requête suivante est envoyée au SGBD : SELECT resultat FROM Dossier_analyse WHERE username = 'Eric' AND numero_dossier = 1234 ;

26 Attaque par injection de code SQL (suite)
2. Exemples d’attaques Attaque par injection de code SQL (suite) Réalisation de l’attaque : L’attaquant fournit le numéro de dossier suivant : 1234 OR TRUE La requête suivante est envoyée à la base : SELECT resultat FROM Dossier_analyse WHERE username = 'Eric' AND numero_dossier = 1234 OR TRUE ; Le SGBD retourne l’ensemble des n-uplets de la relation Dossier_analyse L’attaquant connaît les résultats d’analyse de tous les utilisateurs de la base

27 Attaque contre les bases de données statistiques
2. Exemples d’attaques Attaque contre les bases de données statistiques Exemple : Relation Analyse(Patient,H/F,Age,Mutuelle,Leucocyte) Patient H/F Age Mutuelle Leucocyte Dupont H 30 MMA 6000 Durand F 25 LMDE 3000 Dulac 35 7000 Duval 45 IPECA 5500 Dubois 55 MGEN 3500 Dumont 38 7500 Dupré 32 7200 Dupuis 50 6800 Dufour MAAF 4000 Dumas 40 Rempart 3800

28 Attaque contre les bases de données statistiques (suite)
2. Exemples d’attaques Attaque contre les bases de données statistiques (suite) Base de données statistique Base de données qui permet d'évaluer des requêtes qui dérivent des informations d'agrégation Par exemple : des totaux, des moyennes Mais pas des requêtes qui dérivent des informations particulières Exemple : La requête « quelle est la moyenne du taux de leucocytes des patients ayant plus de 30 ans ? » est permise La requête « quel est le taux de leucocytes de Dupont ? » est interdite

29 Attaque contre les bases de données statistiques (suite)
2. Exemples d’attaques Attaque contre les bases de données statistiques (suite) Exemple d’attaque simple : U veut découvrir le taux de Leucocyte de Dubois U sait par ailleurs que Dubois est un adhérent masculin de la MGEN. Requête 1 SELECT COUNT ( Patient ) FROM Analyse WHERE H/F = 'H' AND Mutuelle = 'MGEN' ; Résultat : 1 Conséquence : Le système doit refuser de répondre à une requête pour laquelle la cardinalité du résultat est inférieure à une certaine borne b Par exemple 2 Requête 2 SELECT SUM ( Leucocyte ) FROM Analyse WHERE H/F = 'H' AND Mutuelle = 'MGEN' ; Résultat : 3500

30 Attaque contre les bases de données statistiques (suite)
2. Exemples d’attaques Attaque contre les bases de données statistiques (suite) Requête 3 SELECT COUNT ( Patient ) FROM Analyse Résultat : 10 Requête 4 WHERE NOT ( H/F = 'H' AND Mutuelle = ‘MGEN’ ) ; Résultat: 9 ; = 1 Conséquence : Le système doit aussi refuser de répondre à une requête pour laquelle la cardinalité du résultat est inférieure à N - b N est la cardinalité de la relation initiale Requête 5 SELECT SUM ( Leucocyte ) FROM Analyse Résultat : 54300 Requête 6 WHERE NOT ( H/F = 'H' AND Mutuelle = ‘MGEN’) ; Résultat : ; – = 3500

31 Attaque contre les bases de données statistiques (suite)
2. Exemples d’attaques Attaque contre les bases de données statistiques (suite) Problème : On peut montrer que limiter les requêtes à celles pour lesquelles le résultat a une cardinalité c telle que b  c  N - b n'est pas suffisant pour éviter la compromission Exemple : si b = 2, les requêtes auront une réponse si c est telle que 2  c  8 Requête 7 SELECT COUNT ( Patient ) FROM Analyse WHERE H/F = 'H' ; Résultat : 6 Conséquence U peut déduire qu'il existe exactement un patient masculin qui a la MGEN comme mutuelle, Il s’agit de Dubois, puisque U sait que cette description correspond à Dubois Requête 8 SELECT COUNT ( Patient ) FROM Analyse WHERE H/F = 'H' AND NOT (Mutuelle = ‘MGEN’) ; Résultat : 5

32 Attaque contre les bases de données statistiques (suite)
2. Exemples d’attaques Attaque contre les bases de données statistiques (suite) Conséquence (suite) Le taux de Leucocyte de Dubois est facilement découvert de la façon suivante : Requête 9 SELECT SUM ( Leucocyte ) FROM Analyse WHERE H/F = 'H' ; Résultat : 30300 Traqueur individuel pour Dubois L'expression booléenne H/F = 'H' AND Mutuelle = ‘MGEN’ permet à l'utilisateur d'obtenir des informations concernant Dubois C’est un traqueur individuel pour Dubois Requête 10 SELECT SUM ( Leucocyte ) FROM Analyse WHERE H/F = 'H' AND NOT (Mutuelle = ‘MGEN’) ; Résultat : ; = 3500

33 Attaque contre les bases de données statistiques (suite)
2. Exemples d’attaques Attaque contre les bases de données statistiques (suite) Remarque Un traqueur individuel ne fonctionne que pour des requêtes faisant intervenir une certaine expression inadmissible particulière Traqueur global Expression booléenne qui peut être utilisée pour trouver la réponse à toute requête inadmissible Résultat de D. Denning et P. Denning Data Security. ACM Computer Survey, 11(3), 1979 Toute expression ayant un ensemble résultat de cardinalité c telle que 2b  c  N - 2b est un traqueur global b doit être inférieur à N/4, ce qui sera en général le cas quand N est grand [DD79] suggère qu’un traqueur global existe « presque toujours » Et il est habituellement facile à trouver

34 B. Démarche pour la sécurité des systèmes d’information
Politique de sécurité Règlement particulier appliqué à un système d ’information Modèles de sécurité Propriété (ou objectif) de sécurité Garantit que le système ne viole pas la politique de sécurité Approche protection Approche détection Mécanismes de sécurité Détection d ’intrusion Mécanismes logiciels ou matériels qui implantent la politique de sécurité dans le système conformément aux propriétés de sécurité Techniques pour détecter toute tentative de violation de la politique de sécurité

35 Comment construire une politique de sécurité
Méthodologie informelle Périmètre de sécurité Politique de sécurité Conception du système sécurisé Politique de sécurité interne Architecture de sécurité Analyse de risques Politique de sécurité système Fonctions et Mécanismes de sécurité Politique de sécurité technique

36 Comment construire une politique de sécurité
Etape 1 : Définition du périmètre de sécurité Périmètre du système à protéger Fonctions du système Utilisateurs du système Recensement des biens à protéger Biens matériel, logiciel et humain

37 Comment construire une politique de sécurité
Etape 2 : Analyse de risque Recenser les vulnérabilités du système Recenser les menaces du système Risque = Vulnérabilité  Menace Un risque existe s ’il existe une vulnérabilité et une menace potentielle qui cherche à exploiter la vulnérabilité Recenser les éléments de confiance

38 Comment construire une politique de sécurité
Exemples de vulnérabilités Matériel non protégé Chiffrement des données médicales par le médecin sans séquestre de clé Manque de protection des communications Pas d ’utilisation d’anti-virus Exemples de menaces Feu, inondation, détérioration intentionnelle ou non Indisponibilité ou décès du médecin rendant inaccessible les données Possibilité d ’écoute dans le but de récupérer des données confidentielles Virus venant modifier les données médicales

39 Comment construire une politique de sécurité
Etape 3 : Définition de la politique de sécurité Idée de base : la politique de sécurité doit être globale Politique de sécurité Politique de sécurité interne Etape 3.1 Politique de sécurité système Etape 3.2 Politique de sécurité technique Etape 3.3

40 Comment construire une politique de sécurité
Etape 3.1 : Définition de la politique de sécurité interne Règlement de sécurité utilisé dans l ’organisation dans laquelle le système va fonctionner Exemples d ’exigences de la politique de sécurité interne Règles définissant le secret médical Règles de déontologie du médecin Conditions à remplir pour faire partie du personnel du groupe médical Règles à respecter pour accéder au groupe médical Accueil des patients, accès à la salle d ’attente, etc. Règles à respecter lorsque le groupe médical est fermé Fermeture et protection des locaux Procédure pour contacter un médecin en cas d ’urgence etc.

41 Comment construire une politique de sécurité
Etape 3.2 : Définition de la politique de sécurité système Plus large que le système informatique Doit être compatible avec la politique de sécurité interne Prévoir une sensibilisation du personnel aux risques informatiques Exemple d ’exigences de la politique de sécurité système Règles pour contrôler l ’accès physique au serveur d ’informations du groupe médical Choix du local, protection du local, contrôle d ’accès au local Règles à respecter pour choisir et gérer son mot de passe Règles pour gérer les sauvegardes du système d ’information médical etc.

42 Comment construire une politique de sécurité
Etape 3.3 : Définition de la politique de sécurité technique Spécifique aux systèmes informatiques Fait partie de la politique de sécurité système Inclut une politique de contrôle d ’accès au système d ’informations Voir l ’ensemble des règles R1-R17 données comme exemple

43 Comment construire une politique de sécurité
Etape 4 : Définition de l ’architecture de sécurité Choix des composants de sécurité Exemple : router, firewall, SGBD, etc Définition d ’une architecture intégrant ces composants Etape 5 : Définition des mécanismes et fonctions de sécurité Choix des mécanismes d ’authentification Exemple : mot de passe, carte à puce, biométrie, etc Définition des besoins de chiffrement et choix des fonctions de chiffrement Définition et mise en œuvre des mécanismes de contrôle d ’accès Etc.

44 Détection d’intrusions
Plusieurs IDS (Intrusion Detection System) sont disponibles prototypes de recherche produits commerciaux Plusieurs approches Détection basée sur les signatures Détection de scénario d’attaque Détection d’anomalies: approche comportementale Détection de comportement anormal Approche politique de sécurité Détection de la violation de la politique de sécurité Plusieurs moyens « Host based » « Network Based »

45 Détection de scénarios d ’attaques
Système cible Journalisation Fichiers d ’audit BD de signatures d ’attaques Analyseur d ’audit Attaques détectées IHM Insertion/Mise a jour Alarmes Commandes

46 Détection de scénarios d ’attaques (suite)
4. Détection d’intrusions Détection de scénarios d ’attaques (suite) Avantages Possibilité d ’expliquer le raisonnement Causes de l ’incident Conséquences Remèdes possibles Possibilité de réactions (contre-mesures) Inconvénients Difficulté d ’acquisition et d ’actualisation de la connaissance Base de signatures incomplètes et signatures « faibles » Seules les attaques décrites dans la base de signatures peuvent être détectées Puissance de calcul nécessaire Limitation en capacité de traitement Nécessite des audits de sécurité détaillés

47 Détection de comportements anormaux
Système cible Journalisation Fichiers d ’audit BD de comportements normaux Analyseur d ’audit Anomalies détectées IHM Mise à jour des comportements Alarmes

48 Détection de comportements anormaux (suite)
4. Détection d’intrusions Détection de comportements anormaux (suite) Avantages Outil générique Ces outils s ’adaptent facilement aux données d ’audit Ils demandent moins de précision que les approches par reconnaissance de scénarios Possibilité de détecter de nouvelles attaques Inconvénients Nécessite un comportement stable du système modélisé Apprentissage éventuel de mauvais comportements ou de comportements intrusifs Taux de fausses alarmes élevé Temps d ’apprentissage élevé De 1 semaine à un mois est nécessaire pour construire le modèle de référence Il est nécessaire que le système soit protégé pendant cette période En général, pas de diagnostic précis en cas d ’alarme

49 Détection d’intrusion
4. Détection d’intrusions Détection d’intrusion Les limites actuelles de la détection d’intrusion Faible taux de détection Faux négatifs Trop de fausses alertes Faux positifs Plus de alertes générées en une semaine (source IBM USA) Le niveau de granularité d’une alerte est trop faible Pas de vision globale Difficile de détecter une attaque distribuée Difficile de détecter les attaques nouvelles C’est un avantage des approches comportementales

50 Outils de protection d’un système d’information
Authentification Confidentialité et intégrité des données transmises Contrôle des accès Bases de données virtuelles Audit

51 Profil des utilisateurs
5. Authentification Authentification Authentification par le SGBD ou par le système d’exploitation Profil des utilisateurs Authentification par le SGBD SGBD BD Authentification par l’OS

52 Création d’un profil d’utilisateur
5. Authentification Création d’un profil d’utilisateur Permet d’associer différents paramètres au protocole d’authentification et à la gestion des mots de passe Par exemple, sous ORACLE 8 : REMOTE_OS_AUTHENT = True : l’authentification aura lieu par l’OS FAILED_LOGIN_ATTEMPTS : nombre d’échecs de tentative d’accès avant que le compte ne soit verrouillé PASSWORD_LIFE_TIME : durée de vie en jours d’un mot de passe

53 Risques liés à l’authentification
Existence d’utilisateurs par défaut Possibilité d’attaques contre ces comptes s’ils n’ont pas été reconfigurés Exemple : utilisateur SCOTT (mot de passe TIGER) sous ORACLE Gestion des mots de passe Distribution du mot de passe lors de la création du compte Transmission du mot de passe entre le client et le serveur Administrateur malveillant Pour limiter ces risques, possibilité d’utiliser SSL sous ORACLE Secure Sockets Layer Gestion de certificats via un tiers de confiance Authentification mutuelle via le protocole Kerberos

54 Confidentialité et intégrité des données transmises
6. Sécurité des communications Confidentialité et intégrité des données transmises Risques lors de la transmission des requêtes et des résultats entre le client et le serveur SGBD BD Ecoute Interception Altération Mascarade Rejeu

55 Chiffrement et signature
6. Sécurité des communications Chiffrement et signature Exemple : Sous Oracle, utilisation de Oracle Advanced Security Chiffrement avec OAS Chiffrement de bout en bout Pas de chiffrement des données stockées Chiffrement symétrique Supporte le triple DES avec clés de 168 bits Signature Pour éviter des manipulations des données lors de la transmission Message Digest Value

56 Politique de contrôle d’accès = ensemble de règles
Format des règles Permission avoir agir sur réaliser Objet avoir Sujet Interdiction Action réaliser Ensemble d ’objets agir sur avoir réaliser Obligation

57 Concept de base d’une politique de contrôle d ’accès
Sujet Réaliser Action Agir sur Objet Sujets = Entités actives du SI Inclut toujours les utilisateurs Inclut souvent les processus travaillant pour le compte des utilisateurs Objets = Entités passives du SI Contiennent les informations à protéger Exemple : les relations dans une base de données relationnelle Actions = permettent aux sujets de manipuler les objets Exemple Requête SQL dans une base de données relationnelle

58 Exemple : Système d ’information d ’un groupe médical
7. Politique de contrôle d’accès Exemple : Système d ’information d ’un groupe médical Sujets = personnels du groupe médical Médecin Secrétaire médical Jean Jeanne Nadine Objets : Dossiers des patients

59 Dossier_Soins_Infirmiers
7. Politique de contrôle d’accès Exemple (suite) Objets (plus détaillés) Partie_Admin Dossier_Admin Partie_Secu_Sociale Dossier_Patient Dossier_Médical Dossier_Soins_Infirmiers

60 Exemple (suite) 7. Politique de contrôle d’accès Actions (exemples)
Consulter le dossier Ausculter un patient Mettre à jour les parties « Dossier_médical » et « Dossier_soins_Infirmiers » Créer le dossier d ’un nouveau patient Renseigner « Dossier_Admin »

61 Exemple de règles 7. Politique de contrôle d’accès
Règles indépendantes du contenu Les plus simples Règle qui permet d’accéder à un objet indépendamment du contenu de cet objet Exemple : R1 : La secrétaire médicale a la permission de gérer le « Dossier_Admin » d ’un patient du groupe médical Permet de consulter et de mettre à jour n ’importe quelle information du « Dossier_Admin » d ’un patient

62 Exemple de règles (suite)
7. Politique de contrôle d’accès Exemple de règles (suite) Règles dépendant du contenu La permission d’accéder à un objet dépend du contenu de cet objet Exemple : R2 : Le médecin a la permission de consulter l ’intégralité du dossier d ’un de ses patients Permet de consulter un dossier médical à condition qu’il s ’agisse d ’un patient de ce médecin R3 : Le médecin a la permission de mettre à jour les parties « Dossier_Medical » et « Dossier_Soins_Infirmiers » d’un de ses patients

63 Exemple de règles (suite)
7. Politique de contrôle d’accès Exemple de règles (suite) Règles dépendant du contexte La permission d’accéder à un objet dépend d’une condition indépendante du contenu de cet objet Exemples : R4 : En l ’absence de la secrétaire médical, le médecin a le droit de gérer le carnet de Rendez-Vous

64 Exemple de règles (suite)
7. Politique de contrôle d’accès Exemple de règles (suite) Délégation et transfert de droit Exemple : R5 : Un médecin du groupe médical a la permission d ’autoriser la secrétaire médicale de mettre à jour la prescription contenue dans le « Dossier_médical » du patient Contrepartie de la délégation R6 : La secrétaire médicale ayant reçu autorisation a la permission de mettre à jour la prescription du « Dossier_médical » du patient

65 Modèle discrétionnaire (DAC)
DAC = Discretionary Access Control Contrôle d ’accès discrétionnaire Objectif de DAC Garantir que tous les accès directs aux objets correspondent à des accès permis par la politique de sécurité Principes de DAC Les sujets ont des permissions de réaliser des actions sur les objets Typiquement, consultation (lecture) ou modification (écriture) de l ’objet Les sujets ont l ’autorisation de transférer certaines permissions à d ’autres sujets Droits discrétionnaires de donner des permissions à d ’autres sujets

66 Exemple typique de DAC 8. DAC Gestion des droits dans UNIX Owner User
Répertoire Owner User Group Other F Jean R W E R W - R - - Concept de propriétaire Dans UNIX, chaque objet a un propriétaire C ’est le propriétaire qui a les droits discrétionnaires sur l ’objet Le propriétaire décide des droits des autres sujets Contenu du fichier F

67 Principe du modèle DAC proposé par SQL
Utilisateur P Permission V Vue O Objet = N-uplet A Action

68 Notion de vue 8. DAC Vue = relation dérivée Exemple
Toute expression relationnelle à laquelle on a donné un nom Exemple Soit la relation dossier_patient Relation qui contient les dossiers de tous les patients du cabinet médical Soit la vue : CREATE VIEW dossier_patient_de_Jean AS SELECT * FROM dossier_patient WHERE dossier_patient.medecin_traitant = ”Jean” ; La vue   dossier_patient_de_Jean contient tous les dossiers des patients de Jean

69 Définition d ’une politique de sécurité dans DAC-SQL
Basée sur le concept de « Vue » Permet de diviser la base de données en plusieurs parties Instruction GRANT Permet de spécifier les privilèges que certains utilisateurs ont la permission d’exécuter Instruction REVOKE Permet d ’enlever un privilège que possède un utilisateu

70 Définition d ’une politique de sécurité dans DAC-SQL
Principaux privilèges possibles SELECT : permet la consultation de la table INSERT : permet l ’insertion de nouvelles données dans la table UPDATE : permet la mise à jour de n ’importe quelle colonne de la table UPDATE(nom_colonne) : permet la mise à jour d ’une colonne spécifique de la table DELETE : permet de supprimer n ’importe quelle donnée de la table ALTER : Modifier la définition d’un objet EXECUTE : Compiler et exécuter une procédure utilisée dans un programme REFERENCE : Créer une contrainte sur une relation INDEX : Créer un index sur une relation

71 Instruction GRANT 8. DAC Format de l ’instruction :
GRANT <liste privileges> ON <table ou vue> TO <liste utilisateurs> [ WITH GRANT OPTION ] ; WITH GRANT OPTION est optionnel signifie que l ’utilisateur qui obtient le privilège peut ensuite accorder ce privilège à un autre utilisateur

72 Instruction REVOKE 8. DAC Format de l ’instruction :
REVOKE [ GRANT OPTION FOR ] <liste privileges> ON <table ou vue> FROM <liste utilisateurs> <option> ; GRANT OPTION FOR est optionnel signifie que seul le droit de transfert est révoqué <option> = RESTRICT ou CASCADE Supposons que A accorde le privilège p à B et B accorde ensuite p à C CASCADE : si A révoque p à B alors C perd aussi le privilège RESTRICT : si A révoque p à B alors la révocation échoue

73 Application du modèle 8. DAC Politique de sécurité du groupe médical
Sujets = Utilisateurs Objets 3 relations : dossier_admin dossier_medical dossier_soins_infirmiers

74 Application du modèle (suite)
8. DAC Application du modèle (suite) Définition du dossier du patient CREATE VIEW dossier_patient AS SELECT * FROM dossier_admin, dossier_medical, dossier_soins_infirmiers WHERE dossier_admin.id_patient = dossier_medical.id_patient AND dossier_admin.id_patient = dossier_soins_infirmiers.id_patient

75 Exemples d ’expression de règles
8. DAC Exemples d ’expression de règles R1 : La secrétaire médicale a la permission de gérer le « Dossier_Admin » d ’un patient du groupe médical GRANT ALL PRIVILEGES ON dossier_admin TO Nadine ;

76 Expression des règles (suite)
8. DAC Expression des règles (suite) R2 : Le médecin a la permission de consulter l ’intégralité du dossier d’un de ses patients Définition d ’une vue CREATE VIEW dossier_patient_du_medecin AS SELECT * FROM dossier_patient WHERE dossier_patient.medecin_traitant = CURRENT_USER ; CURRENT_USER : opérateur prédéfini géré par SQL GRANT SELECT ON dossier_patient_du_medecin TO Jean, Jeanne ;

77 Expression des règles (suite)
8. DAC Expression des règles (suite) R3 : Le médecin a la permission de mettre à jour les parties « Dossier_Medical » et « Dossier_Soins_Infirmiers » d’un de ses patients Définition d ’une vue CREATE VIEW dossier_medical_du_medecin AS SELECT * FROM dossier_medical WHERE dossier_medical.medecin_traitant = CURRENT_USER ; GRANT INSERT, UPDATE, DELETE ON dossier_medical_du_medecin TO Jean, Jeanne ; Règle similaire pour « dossier_soins_infirmier »

78 Expression des règles (suite)
8. DAC Expression des règles (suite) R4 : En l ’absence de la secrétaire médicale, le médecin a la permission de créer le « dossier_admin » d ’un nouveau patient Hypothèse : existence de deux tables utilisateur : cette table à un attribut « nom » et un attribut « etat » utilisateur_role(nom,role) Définition d ’une vue CREATE VIEW dossier_admin_medecin AS SELECT * FROM dossier_admin WHERE NOT EXISTS (SELECT * FROM utilisateur, utilisateur_role WHERE utilisateur.nom = utilisateur_role.nom AND utilisateur_role.role = ”secretaire_medical” AND utilisateur.etat = ”present” ) ; GRANT INSERT ON dossier_admin_medecin TO Jean, Jeanne ;

79 Règle de délégation 8. DAC Il s ’agit d ’un « à peu prêt »
R5 : Un médecin a la permission d ’autoriser la secrétaire médicale de mettre à jour la prescription contenue dans le « Dossier_médical » du patient Création d ’une vue CREATE VIEW prescription_du_medecin AS SELECT dossier_medical.nom_patient, dossier_medical.prescription FROM dossier_medical, WHERE dossier_medical.medecin_traitant = CURRENT_USER ; GRANT SELECT, UPDATE(prescription) ON prescription_du_medecin TO Jean, Jeanne WITH GRANT OPTION TO Nadine ; Il s ’agit d ’un « à peu prêt » Avec SQL, On ne peut pas préciser que « GRANT OPTION » ne concerne que la secrétaire médicale

80 Règle de délégation (suite)
8. DAC Règle de délégation (suite) R6 : La secrétaire médicale ayant reçu autorisation a la permission de mettre à jour la prescription du « Dossier_médical » du patient Pour donner effectivement l ’autorisation de mettre à jour la prescription d ’un patient particulier (par exemple Paul), le médecin doit : 1 : Créer une vue : CREATE VIEW prescription_de_Paul AS SELECT * FROM prescription_du_medecin WHERE prescription_du_medecin.nom_patient = ”Paul” ; 2 : Donner les privilèges sur la vue à la secrétaire médicale : CREATE PERMISSION R6 GRANT SELECT, UPDATE(prescription) ON prescription_de_Paul TO Nadine ; Possible car le médecin a le privilège « WITH GRANT OPTION » sur la table prescription_du_medecin

81 Privilèges système dans DAC-SQL
Les instructions GRANT et REVOKE s ’appliquent aussi aux fonctions d ’administration, par exemple : CREATE TABLE ALTER TABLE DROP TABLE CREATE USER DROP USER Dans notre exemple médical, il faudrait compléter la définition de la politique de sécurité pour définir quels sont les utilisateurs qui ont des privilèges système

82 Conclusion sur DAC-SQL
Intérêt du concept de vue Permet d ’exprimer des règles dépendant du contenu Permet d ’exprimer certaines règles dépendant du contexte Règle de délégation Incomplet et complexe à gérer « WITH GRANT OPTION » n ’est pas suffisant Structuration des objets Grâce au concept de vue Contrôle d’accès basé sur l’identité des sujets Pas de structuration des sujets

83 Modèle RBAC 9. RBAC Présentation du modèle de base
Proposé par Ravi Sandhu Gestion des rôles dans SQL3

84 Concepts de base de RBAC
Concept de rôle Permet de représenter la structure d ’une organisation Recouvre plus aspects Rôle fonctionnel Permet la réalisation de certaines tâches spécifiques Exemple : médecin, infirmier, secrétaire médical Rôle organisationnel Autorité et responsabilité Exemple : infirmier chef, responsable du service d ’urgence, directeur de l ’hôpital Mais aussi, dans certains cas, participation à un projet

85 Concepts de base de RBAC (suite)
Sujet Dans RBAC, Sujet = Utilisateur Permission Concept primitif de RBAC Doit ensuite être interprété dans le contexte applicatif considéré Exemples : Permission sur des vues dans un SGBD relationnel Permission sur des fichiers dans un système d ’exploitation Conséquences : Pas de concept d ’objet dans RBAC96 Pas de concept d ’action dans RBAC96 Session Les utilisateurs doivent toujours commencer par activer une session

86 La famille des modèles de RBAC96
Modèle consolidé : Contraintes + Hiérarchie RBAC1 RBAC2 Hiérarchie de rôles Contraintes RBAC0 Modèle de base (le plus simple)

87 . Modèle de base : RBAC0 AU AP U R P S 9. RBAC AU : Un rôle peut être
affecté à plusieurs utilisateurs Plusieurs rôles peuvent être affectés à un utilisateur Modèle de base : RBAC0 AU Affectation des Utilisateurs AP Affectation des Permissions U Utilisateurs R Rôles P Permissions AP : Une permission peut être affectée à plusieurs rôles Plusieurs permissions peuvent être affectées à un rôle . Une session est activée par un seul utilisateur Un utilisateur peut activer plusieurs rôles dans une session S Sessions

88 Moindre privilège dans RBAC0
Dans une session, l’utilisateur peut choisir les rôles qu’il souhaite activer Conséquence : Toutes les permissions de l ’utilisateur ne sont pas nécessairement activées Prise en compte partielle du moindre privilège Mais, lorsqu’un rôle est activé, toutes les permissions de ce rôle sont systématiquement activées

89 . Hiérarchie de rôles : RBAC1 HR AU AP U R P S 9. RBAC Hiérarchie
Utilisateurs R Rôles P Permissions . S Sessions

90 Hiérarchie de rôles 9. RBAC
R1 est un rôle junior de R2 si R1 est hiérarchiquement inférieur à R2 R2 est un rôle senior de R1 si R2 est hiérarchiquement supérieur à R2 Notation : R1  R2 : R1 est un rôle junior de R2 R2  R2 : R2 est un rôle senior de R1  et  sont des relations d ’ordre partiel sur l ’ensemble des rôles Plusieurs interprétations possibles de la hiérarchie : Spécialisation/Généralisation Hiérarchie organisationnelle

91 Hiérarchie de rôles (suite)
9. RBAC Hiérarchie de rôles (suite) Cardiologue Rhumatologue . . . Spécialisation/Généralisation R1 est un senior rôle de R2 si chaque fois qu’un utilisateur joue le rôle R1, cet utilisateur joue aussi le rôle R2 Généraliste Spécialiste Médecin Personnel médical

92 Hiérarchie de rôles (suite)
9. RBAC Hiérarchie de rôles (suite) Directeur d ’un hôpital . . . Hiérarchie organisationnelle R1 est un senior rôle de R2 si un utilisateur jouant le rôle R1 est un supérieur hiérarchique d ’un utilisateur jouant le rôle R2 Directeur d ’un département Chef de service Médecin

93 Hiérarchie de rôles (suite)
9. RBAC Hiérarchie de rôles (suite) Héritage des permissions Si R1 est un rôle senior de R2 Alors R1 hérite des permissions affectées à R2 Exemple : Le Cardiologue hérite des permissions du Spécialiste Le principe d’héritage est acceptable dans le cas d’une hiérarchie de type Spécialisation/Généralisation Il est parfois discutable dans le cas d’une hiérarchie organisationnelle Le directeur de l ’hôpital n ’hérite pas de toutes les permissions du Médecin

94 . Contraintes : RBAC2 AU AP U R P S Contraintes 9. RBAC Utilisateurs
Rôles P Permissions . S Sessions Contraintes

95 9. RBAC Contraintes Expression logique qui permet de contraindre les différentes affectations : AU : Utilisateur  Rôle AP : Rôle  Permission AS : Session  Rôle

96 Contraintes (suite) 9. RBAC Contrainte sur AU : Utilisateur  Rôle
Un utilisateur ne peut pas cumuler certains rôles Exemple : rôles anesthésiste et chirurgien  u,  ( AU(u,Anesthésiste)  AU(u,Chirurgien) ) Contrainte de type « Séparation des pouvoirs » Separation of Duty Contrainte de cardinalité Exemple : le rôle de directeur de l ’hôpital ne peut être affecté qu’à un seul utilisateur  u,  u’, ( AU(u,Dir_hopital)  AU(u’,Dir_hopital) )  u = u’

97 Contraintes (suite) 9. RBAC Contrainte sur AP : Rôle  Permission
Certaines permissions ne peuvent pas être affectées à certains rôles Exemple : la permission d ’opérer ne peut être affectée au rôle Infirmier Proche de la notion d ’interdiction Certaines permission de peuvent pas être affectées à plusieurs rôles Exemple : la permission d ’anesthésier ne peut être affectée qu’au rôle Anesthésiste Un rôle de doit pas pouvoir cumuler certaines permissions Exemple : permission d ’anesthésier et d ’opérer Contrainte de type « Séparation des tâches » Plusieurs rôles sont nécessaires pour réaliser une opération Et plusieurs utilisateurs sont aussi nécessaires si l ’on ajoute une contrainte de type « Séparation des pouvoirs »

98 Contraintes (suite) 9. RBAC Contrainte sur AS : Session  Rôle
Similaire aux contraintes sur AU : Utilisateur  Rôle Mais contrainte dynamique lorsqu’un utilisateur active une session Exemple : Role1 : Directeur d ’un service hospitalier Rôle2 : Médecin libéral Un médecin peut cumuler les deux rôles mais pas les activer dans la même session Plusieurs casquettes mais une seule casquette à la fois

99 . Modèle consolidé : RBAC3 HR AU AP U R P S Contraintes 9. RBAC
Hiérarchie de rôles AU AP U Utilisateurs R Rôles P Permissions . S Sessions Contraintes

100 Modèle consolidé : RBAC3
Contrainte sur la hiérarchie de rôle Contrainte sur HR : Rôle  Rôle Exemple : Médecin spécialiste n ’est pas un rôle senior de médecin généraliste

101 Gestion des rôles dans SQL
9. RBAC Gestion des rôles dans SQL Le concept de rôle a été introduit dans SQL3 Par encore pris en compte par tous les SGBD Instructions de SQL3 CREATE ROLE <nom_role> ; Création d ’un nouveau rôle nom_role DROP ROLE <nom_role> ; Suppression du rôle nom_role SET ROLE <liste_roles> ; Permet à un utilisateur d ’activer un ensemble de rôle pendant la durée d ’une session SQL

102 Principe de la gestion des rôles dans SQL3
9. RBAC Principe de la gestion des rôles dans SQL3 R Rôle P Permission V Vue O Objet = N-uplet U Utilisateur A Action

103 Adaptation de l ’instruction GRANT
9. RBAC Adaptation de l ’instruction GRANT Affectation des privilèges aux rôles GRANT <liste privileges> ON <table ou vue> TO <liste roles> [ WITH GRANT OPTION ] ; Affectation des utilisateurs aux rôles GRANT <liste roles> TO <liste utilisateurs> Rôle junior et rôle senior GRANT <role1> TO <role2> Le rôle role2 reçoit tous les privilèges du rôle role1

104 Adaptation de l ’instruction REVOKE
9. RBAC Adaptation de l ’instruction REVOKE Revocation de privilèges aux rôles REVOKE [ GRANT OPTION FOR ] <liste privileges> ON <table ou vue> FROM <liste roles> <CASCADE ou RESTRICT> ; Révocation des utilisateurs aux rôles REVOKE <liste roles> FROM <liste utilisateurs> Mise à jour de la hiérarchie de rôle REVOKE role1 FROM role2 ;

105 Application du modèle 9. RBAC Création des rôles
CREATE ROLE secretaire_medical ; R1 : La secrétaire médicale a la permission de gérer le « Dossier_Admin » d ’un patient du groupe médical GRANT ALL PRIVILEGES ON dossier_admin TO secretaire_medicale ; Puis affectation de Nadine au rôle secretaire_medicale GRANT secretaire_medicale to Nadine ;

106 Conclusion sur la gestion des rôles dans SQL
9. RBAC Conclusion sur la gestion des rôles dans SQL Conservation des avantages de DAC-SQL Possibilité d ’exprimer des règles dépendant du contenu et du contexte Intérêt des concepts de vue et de rôle Les vues permettent de structurer la gestion des objets Les rôles permettent de structurer la gestion des sujets

107 Sécurité des applications
Limite des contrôles d’accès basés sur les vues et les rôles Ne contrôlent pas les accès via des applications ODBC Application ad-hoc Cf. l’attaque par injection de code SQL Il est possible d’associer un rôle à l’application Mais dans ce cas, tous les utilisateurs de l’application disposeront des mêmes droits d’accès à la base Solution insuffisante

108 Base de données privée virtuelle (VPD)
10. Sécurité des applications Base de données privée virtuelle (VPD) Mécanisme fourni par Oracle 8i pour assurer la sécurité des applications Principe Possibilité d’associer une règle de sécurité à une relation ou une vue Lorsque la fonctionnalité VPD est activée, toute requête qui accède à cette relation ou cette vue est automatiquement modifiée en incluant une clause WHERE Création du contexte d’une application Permet d’accéder aux attributs spécifiques de l’attribut connecté via l’application La clause WHERE de la requête modifiée est construite en utilisant ce contexte

109 Contexte d’application
10. Sécurité des applications Contexte d’application Oracle a prévu un contexte par défaut USERENV : contient des informations système relatives à la session courante Exemple : CURRENT_USER HOST ISDBA Possibilité de créer un nouveau contexte et d’y associer des attributs create context CTX_SEC_MEDICALE using SCHEMA_MED.SEC_MEDICALE CTX_SEC_MEDICALE sera un contexte associé au package PL/SQL nommé SEC_MEDICALE et stocké dans le schéma SCHEMA_MED

110 Définition des règles de sécurité
10. Sécurité des applications Définition des règles de sécurité Les règles de sécurité doivent être écrites en PL/SQL Exemple : create package body SEC_MEDICALE as function DOSSIER_SEC return varchar2 is MY_PREDICATE varchar2(2000) ; begin MY_PREDICATE := 'id_patient in (SELECT id_patient FROM dossier_medical WHERE medecin_traitant = sys_context("USERENV", "CURRENT_USER"))' ; return MY_PREDICATE ; end DOSSIER_SEC ; end SEC_MEDICALE ;

111 Exemple de transformation de requêtes
10. Sécurité des applications Exemple de transformation de requêtes Supposons que Jean formule la requête suivante : SELECT * FROM dossier_medical WHERE id_patient = 'Paul' L’application de la règle DOSSIER_SEC va automatiquement transformer cette requête en la requête suivante : AND id_patient in (SELECT id_patient WHERE medecin_traitant = 'Jean' ) ; Jean ne pourra ainsi accéder qu’aux dossiers médicaux de ses patients

112 Limites des modèles DAC et RBAC
Conclusion/Perspectives Limites des modèles DAC et RBAC Hypothèse de DAC L’application s ’exécutant pour le compte de l ’utilisateur hérite des droits de cet utilisateur Hypothèse de RBAC L ’application s ’exécutant pour le compte de l ’utilisateur hérite des droits de la session Droit de la session = droits de l ’ensemble des rôles activés par l ’utilisateur Dans DAC et RBAC, risque de programmes malveillants Notion de Cheval de Troie

113 Limites des modèles DAC et RBAC (suite)
Conclusion/Perspectives Limites des modèles DAC et RBAC (suite) Cheval de Troie = Programme piégé Un Cheval de Troie est un programme qui a une fonctionnalité apparente mais qui contient des fonctions cachées qui s ’exécutent à l ’insu de l ’utilisateur Objectif du cheval de Troie Transmission illégale d ’information vers de bénéficiaire du piège Modification illégale d ’information par le bénéficiaire du piège Bénéficiaire du piège Utilisateur qui a installé le Cheval de Troie dans le programme Exemple : Concepteur du programme, Utilisateur qui administre le système Utilisateur qui assure la maintenance du système Etc.

114  Limites des modèles DAC et RBAC (suite) Conclusion/Perspectives
Exemple de Cheval de Troie Attaque contre la confidentialité L ’application piégée a les droits de lecture et d ’écriture sur les dossiers des patients Médecin Application piégée  Dossiers des patients Transmission des dossiers des patients à l ’insu du médecin Bénéficiaire du Cheval de Troie

115 Protection contre les Chevaux de Troie
Conclusion/Perspectives Protection contre les Chevaux de Troie Modèle MAC Mandatory Access Control Contrôle d ’accès par Mandat Politique de sécurité multi-niveaux Niveaux hiérarchiques Pour assurer le cloisonnement vertical Exemple : Confidentiel, Secret, Très Secret Compartiments Pour assurer le cloisonnement horizontal Exemple : cardiologie, pédiatrie, rhumatologie, ...

116 Gestion MAC dans un SGBD
Conclusion/Perspectives Gestion MAC dans un SGBD Exemple : Trusted ORACLE 7 Niveau de classification associé aux n-uplets Niveau d ’habilitation associé aux utilisateurs Mise en œuvre du modèle de Bell et LaPadula Echec commercial par manque de souplesse Aujourd ’hui : ORACLE Label Security Inclus dans ORACLE8i Solution VPD pour gérer les niveaux de sécurité Modèle plus souple

117 Perspectives Conclusion/Perspectives
Prise en compte d ’un système d ’informations qui gère les données de plusieurs organisations ayant des politiques de sécurité différentes Limite du modèle R-BAC Proposition du modèle F-BAC : Function-Based Access Control Obligation provisionnelle On accorde une permission à un utilisateur En contrepartie, cet utilisateur a l ’obligation de réaliser une certaine action lorsqu’il utilise cette permission Remettre en cause l ’existence d ’un DBA tout puissant Evaluer des requêtes sur des données chiffrées Sécurité d ’un serveur de documents XML