La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Centre de Toulouse BDA02 21 Octobre 2002 Protection des systèmes dinformations : Menaces et solutions actuelles Frédéric Cuppens Maître de recherches ONERA.

Présentations similaires


Présentation au sujet: "Centre de Toulouse BDA02 21 Octobre 2002 Protection des systèmes dinformations : Menaces et solutions actuelles Frédéric Cuppens Maître de recherches ONERA."— Transcription de la présentation:

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

2 Centre de Toulouse BDA02 21 Octobre 2002 Plan A. Contexte 1. Introduction 2. Exemples dattaques B. Démarche pour la sécurité des systèmes dinformation 3. Politique de sécurité 4. Détection dintrusions 5. Authentification 6. Sécurité des communications 7. Politiques de contrôle daccès C. Différents types de politiques de contrôle daccè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 Centre de Toulouse BDA02 21 Octobre 2002 Evolution du contexte Mainframe Système de gestion indépendant Gestion centralisée Chemin daccès unique Client/Serveur Infrastructure hétérogène Gestion de données et dapplications Gestion centralisée Chemins daccès multiples Technologie Internet Infrastructure hétérogène Réseaux avec connections multiples Systèmes ouverts Systèmes interropérants Niveau de complexité 1. Introduction Technologie Internet future BlueTooth UMTS Active Network WLANHiperlan WAPI-mode Oracle2Oracle6Oracle7 Oracle8iOracle9i

4 Centre de Toulouse BDA02 21 Octobre 2002 Quelques statistiques 1,2 Milliard $US Pertes deBay, 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 1. Introduction

5 Centre de Toulouse BDA02 21 Octobre 2002 Objectifs de lintrusion 1. Introduction Objectifs de lintrusion Confidentialité Intégrité Disponibilité Accès illégal à certaines informations Création, modification ou suppression illégale de linformation Empêche les utilisateurs davoir un accès autorisé au système Exemples : sniffing, cracking,... Exemples : altering, spoofing, hijacking,... Exemples : flooding, smurfing,...

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

7 Centre de Toulouse BDA02 21 Octobre 2002 Principales classes dattaque Sniffing Ecoute Spoofing Mascarade Flooding Deni de service Scanning Balayage des services Hijacking Interception / détournement de communication Virus et Chevaux de Troie 2. Exemples dattaques

8 Centre de Toulouse BDA02 21 Octobre 2002 Internet ou DMZ Packet sniffing (R-a-Probe) M M M Emetteur Attaquant 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 dutilisateurs, mots de passe (même chiffrés), … 2. Exemples dattaques

9 Centre de Toulouse BDA02 21 Octobre 2002 Flooding Principe : 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) 2. Exemples dattaques

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

11 Centre de Toulouse BDA02 21 Octobre 2002 Smurfing (R-a-deny(temporary)) Attaquant Victime Internet 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 ECHO REPLY de vers la victime ECHO REPLY de vers la victime 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 » Envoi d un message « echo request » forgé avec l adress de la victime (spoofing) Des centaines de messages « echo reply » envoyés à la victime Principe du smurfing : amplification du flooding Jusqu à 255 messages reçus par la victime pour un message envoyé par l attaquant 2. Exemples dattaques

12 Centre de Toulouse BDA02 21 Octobre 2002 Spoofing 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 2. Exemples dattaques

13 Centre de Toulouse BDA02 21 Octobre 2002 ARP Poison Principle du protocole ARP (protocole non connecté): Dans le protocole ARP, chaque requête est diffusée aux autres machines dun 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 sil na pas envoyé un ARP request) Principe de lattaque : Lattaquant envoie des messages ARP reply avec qui ne correspond pas à Applications: Deni de service Hijacking 2. Exemples dattaques

14 Centre de Toulouse BDA02 21 Octobre 2002 Hijacking ARP (R-m-Intercept) Cache ARP 00:00:00:02 (1) Communication Cache ARP 00:00:00:02 Cache ARP 00:00:00:03 (2) ARP Poison Cache ARP 00:00:00:03 ARP Reply : :00:00:03 ARP Reply : :00:00:03 Man In the Middle 00:00:00:03 Cache ARP 00:00:00:03 Cache ARP 00:00:00:03 (3) Hijacking 2. Exemples dattaques

15 Centre de Toulouse BDA02 21 Octobre 2002 Scanning: exemples Objectif général : Obtenir la liste des ports ouverts dun 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é 2. Exemples dattaques

16 Centre de Toulouse BDA02 21 Octobre 2002 Virus et Chevaux de Troie Il y a des milliers de virus et de Chevaux de Troie Exemple : Back Orifice 2000 (bo2k) Création dune porte dérobée (back door) Pour prendre le contrôle dun système 2. Exemples dattaques

17 Centre de Toulouse BDA02 21 Octobre 2002 Back Orifice 2000 Etape 1: Encapsuler bo2k dans un fichier « attractif » pour que la victime installe bo2k sur son système Etape 2: Connexion entre lattaquant 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. 2. Exemples dattaques

18 Centre de Toulouse BDA02 21 Octobre 2002 Exemple dattaque pour obtenir les droits daccè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 lespace mémoire alloué Pendant lexécution, une sous-routine écrase ladresse de retour Ce qui permet lexécution dun shellcode Vulnérabilité classique exploitée : Fonctions sur les chaînes de caractères (sprintf) 2. Exemples dattaques

19 Centre de Toulouse BDA02 21 Octobre 2002 ShellCode Gestion de la pile Appel fonction Début : –Sauvegarde du contexte –Création statique du domaine Exécution du programme Fin : –Restoration du contexte Problème : Ladresse de retour peut être écrasée 2. Exemples dattaques

20 Centre de Toulouse BDA02 21 Octobre 2002 Schéma dun ShellCode Trois parties : NOP Padding Car lattaquant ne connait pas précisément la position du ShellCode Problème pour positionner exactement ladresse 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 dinstructions équivalente NOP … NOP shellcode adresse du shellcode … adresse du shellcode … adresse du shellcode … adresse du shellcode Début du shellcode 2. Exemples dattaques

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

22 Centre de Toulouse BDA02 21 Octobre 2002 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 2. Exemples dattaques

23 Centre de Toulouse BDA02 21 Octobre 2002 Attaque par injection de code SQL (suite) Réalisation de lattaque : Lattaquant 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 lensemble des n-uplets de la relation Users Lattaquant va se retrouver connecté en tant que premier utilisateur de la base En général, il sagira de ladministrateur de la base 2. Exemples dattaques

24 Centre de Toulouse BDA02 21 Octobre 2002 Attaque par injection de code SQL (suite) Autre possibilité dattaque Numero dossier : 1234 Base de données Script Visual Basic Réponse du SGBD Résultat analyse : 2. Exemples dattaques

25 Centre de Toulouse BDA02 21 Octobre 2002 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 & " ' ANDnumero_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 ; 2. Exemples dattaques

26 Centre de Toulouse BDA02 21 Octobre 2002 Attaque par injection de code SQL (suite) Réalisation de lattaque : Lattaquant 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 lensemble des n-uplets de la relation Dossier_analyse Lattaquant connaît les résultats danalyse de tous les utilisateurs de la base 2. Exemples dattaques

27 Centre de Toulouse BDA02 21 Octobre 2002 Attaque contre les bases de données statistiques PatientH/FAgeMutuelleLeucocyte DupontH30MMA6000 DurandF25LMDE3000 DulacF35MMA7000 DuvalH45IPECA5500 DuboisH55MGEN3500 DumontH38MMA7500 DupréF32IPECA7200 DupuisF50MGEN6800 DufourH45MAAF4000 DumasH40Rempart3800 Exemple : Relation Analyse(Patient,H/F,Age,Mutuelle,Leucocyte) 2. Exemples dattaques

28 Centre de Toulouse BDA02 21 Octobre 2002 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 2. Exemples dattaques

29 Centre de Toulouse BDA02 21 Octobre 2002 Attaque contre les bases de données statistiques (suite) Exemple dattaque 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 : Exemples dattaques

30 Centre de Toulouse BDA02 21 Octobre 2002 Attaque contre les bases de données statistiques (suite) Requête 3 SELECT COUNT ( Patient ) FROM Analyse Résultat : 10 Requête 4 SELECT COUNT ( Patient ) FROM Analyse 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 : Requête 6 SELECT SUM ( Leucocyte ) FROM Analyse WHERE NOT ( H/F = 'H' AND Mutuelle = MGEN) ; Résultat : ; – = Exemples dattaques

31 Centre de Toulouse BDA02 21 Octobre 2002 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 sagit 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 2. Exemples dattaques

32 Centre de Toulouse BDA02 21 Octobre 2002 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 : Traqueur individuel pour Dubois L'expression booléenne H/F = 'H' AND Mutuelle = MGEN permet à l'utilisateur d'obtenir des informations concernant Dubois Cest un traqueur individuel pour Dubois Requête 10 SELECT SUM ( Leucocyte ) FROM Analyse WHERE H/F = 'H' AND NOT (Mutuelle = MGEN) ; Résultat : ; = Exemples dattaques

33 Centre de Toulouse BDA02 21 Octobre 2002 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 quun traqueur global existe « presque toujours » Et il est habituellement facile à trouver 2. Exemples dattaques

34 Centre de Toulouse BDA02 21 Octobre 2002 B. Démarche pour la sécurité des systèmes dinformation Modèles de sécurité Mécanismes de sécurité Détection d intrusion Approche protection Approche détection Politique de sécurité Propriété (ou objectif) de sécurité Règlement particulier appliqué à un système d information Garantit que le système ne viole pas la politique de sécurité 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 Centre de Toulouse BDA02 21 Octobre 2002 Comment construire une politique de sécurité Méthodologie informelle Périmètre de sécurité Analyse de risques Politique de sécurité interne Politique de sécurité système Politique de sécurité technique Architecture de sécurité Fonctions et Mécanismes de sécurité Politique de sécuritéConception du système sécurisé 3. Politique de sécurité

36 Centre de Toulouse BDA02 21 Octobre 2002 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 3. Politique de sécurité

37 Centre de Toulouse BDA02 21 Octobre 2002 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 3. Politique de sécurité

38 Centre de Toulouse BDA02 21 Octobre 2002 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 danti-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 3. Politique de sécurité

39 Centre de Toulouse BDA02 21 Octobre 2002 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é interne Politique de sécurité système Politique de sécurité technique Politique de sécurité Etape 3.1 Etape 3.2 Etape Politique de sécurité

40 Centre de Toulouse BDA02 21 Octobre 2002 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. 3. Politique de sécurité

41 Centre de Toulouse BDA02 21 Octobre 2002 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. 3. Politique de sécurité

42 Centre de Toulouse BDA02 21 Octobre 2002 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 3. Politique de sécurité

43 Centre de Toulouse BDA02 21 Octobre 2002 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. 3. Politique de sécurité

44 Centre de Toulouse BDA02 21 Octobre 2002 Détection dintrusions 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 dattaque Détection danomalies: 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 » 4. Détection dintrusions

45 Centre de Toulouse BDA02 21 Octobre 2002 Détection de scénarios d attaques Fichiers d audit Système cible Analyseur d audit IHM BD de signatures d attaques AlarmesCommandes Journalisation Insertion/Mise a jour Attaques détectées

46 Centre de Toulouse BDA02 21 Octobre 2002 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 4. Détection dintrusions

47 Centre de Toulouse BDA02 21 Octobre 2002 Fichiers d audit Détection de comportements anormaux Système cible Analyseur d audit IHM BD de comportements normaux Mise à jour des comportements Alarmes Journalisation Anomalies détectées

48 Centre de Toulouse BDA02 21 Octobre 2002 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 Détection de comportements anormaux (suite) 4. Détection dintrusions

49 Centre de Toulouse BDA02 21 Octobre 2002 Détection dintrusion Les limites actuelles de la détection dintrusion 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é dune alerte est trop faible Pas de vision globale Difficile de détecter une attaque distribuée Difficile de détecter les attaques nouvelles Cest un avantage des approches comportementales 4. Détection dintrusions

50 Centre de Toulouse BDA02 21 Octobre 2002 Outils de protection dun système dinformation Authentification Confidentialité et intégrité des données transmises Contrôle des accès Bases de données virtuelles Audit

51 Centre de Toulouse BDA02 21 Octobre 2002 Authentification Authentification par le SGBD ou par le système dexploitation Authentification par le SGBD SGBD BD Authentification par lOS Profil des utilisateur s 5. Authentification

52 Centre de Toulouse BDA02 21 Octobre 2002 Création dun profil dutilisateur Permet dassocier différents paramètres au protocole dauthentification et à la gestion des mots de passe Par exemple, sous ORACLE 8 : REMOTE_OS_AUTHENT = True : lauthentification aura lieu par lOS FAILED_LOGIN_ATTEMPTS : nombre déchecs de tentative daccès avant que le compte ne soit verrouillé PASSWORD_LIFE_TIME : durée de vie en jours dun mot de passe 5. Authentification

53 Centre de Toulouse BDA02 21 Octobre 2002 Risques liés à lauthentification Existence dutilisateurs par défaut Possibilité dattaques contre ces comptes sils nont 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é dutiliser SSL sous ORACLE Secure Sockets Layer Gestion de certificats via un tiers de confiance Authentification mutuelle via le protocole Kerberos 5. Authentification

54 Centre de Toulouse BDA02 21 Octobre 2002 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 6. Sécurité des communications

55 Centre de Toulouse BDA02 21 Octobre 2002 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 6. Sécurité des communications

56 Centre de Toulouse BDA02 21 Octobre 2002 Politique de contrôle daccès = ensemble de règles Format des règles Sujet Permission Interdiction Obligation Action Objet Ensemble d objets avoir réaliser agir sur agir sur 7. Politique de contrôle daccès

57 Centre de Toulouse BDA02 21 Octobre 2002 Concept de base dune politique de contrôle d accès 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 SujetActionObjet Réaliser Agir sur 7. Politique de contrôle daccès

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

59 Centre de Toulouse BDA02 21 Octobre 2002 Exemple (suite) Objets (plus détaillés) Dossier_Patient Dossier_Admin Dossier_Médical Dossier_Soins_Infirmiers Partie_Admin Partie_Secu_Sociale 7. Politique de contrôle daccès

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

61 Centre de Toulouse BDA02 21 Octobre 2002 Exemple de règles Règles indépendantes du contenu Les plus simples Règle qui permet daccé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 7. Politique de contrôle daccès

62 Centre de Toulouse BDA02 21 Octobre 2002 Exemple de règles (suite) Règles dépendant du contenu La permission daccé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 quil 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 » dun de ses patients 7. Politique de contrôle daccès

63 Centre de Toulouse BDA02 21 Octobre 2002 Exemple de règles (suite) Règles dépendant du contexte La permission daccéder à un objet dépend dune 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 7. Politique de contrôle daccès

64 Centre de Toulouse BDA02 21 Octobre 2002 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 7. Politique de contrôle daccès

65 Centre de Toulouse BDA02 21 Octobre 2002 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 8. DAC

66 Centre de Toulouse BDA02 21 Octobre 2002 Exemple typique de DAC Gestion des droits dans UNIX Répertoire F Contenu du fichier F UserGroupOther RWERW-R-- Owner Jean 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 8. DAC

67 Centre de Toulouse BDA02 21 Octobre 2002 Principe du modèle DAC proposé par SQL U Utilisateur P Permission V Vue A Action O Objet = N-uplet 8. DAC

68 Centre de Toulouse BDA02 21 Octobre 2002 Notion de vue Vue = relation dérivée 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 8. DAC

69 Centre de Toulouse BDA02 21 Octobre 2002 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 dexécuter Instruction REVOKE Permet d enlever un privilège que possède un utilisateu 8. DAC

70 Centre de Toulouse BDA02 21 Octobre 2002 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 dun 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 8. DAC

71 Centre de Toulouse BDA02 21 Octobre 2002 Instruction GRANT Format de l instruction : GRANT ON TO [ 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 8. DAC

72 Centre de Toulouse BDA02 21 Octobre 2002 Instruction REVOKE Format de l instruction : REVOKE [ GRANT OPTION FOR ] ON FROM ; GRANT OPTION FOR est optionnel signifie que seul le droit de transfert est révoqué = 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 8. DAC

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

74 Centre de Toulouse BDA02 21 Octobre 2002 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 8. DAC

75 Centre de Toulouse BDA02 21 Octobre 2002 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 ; 8. DAC

76 Centre de Toulouse BDA02 21 Octobre 2002 Expression des règles (suite) R2 : Le médecin a la permission de consulter l intégralité du dossier dun 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 ; 8. DAC

77 Centre de Toulouse BDA02 21 Octobre 2002 Expression des règles (suite) R3 : Le médecin a la permission de mettre à jour les parties « Dossier_Medical » et « Dossier_Soins_Infirmiers » dun 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 » 8. DAC

78 Centre de Toulouse BDA02 21 Octobre 2002 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 ; 8. DAC

79 Centre de Toulouse BDA02 21 Octobre 2002 Règle de délégation 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 8. DAC

80 Centre de Toulouse BDA02 21 Octobre 2002 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 8. DAC

81 Centre de Toulouse BDA02 21 Octobre 2002 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 8. DAC

82 Centre de Toulouse BDA02 21 Octobre 2002 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 daccès basé sur lidentité des sujets Pas de structuration des sujets 8. DAC

83 Centre de Toulouse BDA02 21 Octobre 2002 Modèle RBAC Présentation du modèle de base RBAC96 Proposé par Ravi Sandhu Gestion des rôles dans SQL3 9. RBAC

84 Centre de Toulouse BDA02 21 Octobre 2002 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 9. RBAC

85 Centre de Toulouse BDA02 21 Octobre 2002 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 9. RBAC

86 Centre de Toulouse BDA02 21 Octobre 2002 Modèle consolidé : Contraintes + Hiérarchie La famille des modèles de RBAC96 RBAC 0 Modèle de base (le plus simple) RBAC 1 RBAC 2 RBAC 3 ContraintesHiérarchie de rôles 9. RBAC

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

88 Centre de Toulouse BDA02 21 Octobre 2002 Moindre privilège dans RBAC 0 Dans une session, lutilisateur peut choisir les rôles quil 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, lorsquun rôle est activé, toutes les permissions de ce rôle sont systématiquement activées 9. RBAC

89 Centre de Toulouse BDA02 21 Octobre 2002 Hiérarchie de rôles : RBAC 1 U Utilisateurs R Rôles P Permissions S Sessions AUAP HR Hiérarchie de rôles 9. RBAC

90 Centre de Toulouse BDA02 21 Octobre 2002 Hiérarchie de rôles 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 9. RBAC

91 Centre de Toulouse BDA02 21 Octobre 2002 Hiérarchie de rôles (suite) Spécialisation/Généralisation R1 est un senior rôle de R2 si chaque fois quun utilisateur joue le rôle R1, cet utilisateur joue aussi le rôle R2 Personnel médical Médecin GénéralisteSpécialiste CardiologueRhumatologue RBAC

92 Centre de Toulouse BDA02 21 Octobre 2002 Hiérarchie de rôles (suite) 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 Médecin Chef de service Directeur d un département Directeur d un hôpital RBAC

93 Centre de Toulouse BDA02 21 Octobre 2002 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 dhéritage est acceptable dans le cas dune hiérarchie de type Spécialisation/Généralisation Il est parfois discutable dans le cas dune hiérarchie organisationnelle Le directeur de l hôpital n hérite pas de toutes les permissions du Médecin 9. RBAC

94 Centre de Toulouse BDA02 21 Octobre 2002 Contraintes : RBAC 2 U Utilisateurs R Rôles P Permissions S Sessions AUAP Contraintes 9. RBAC

95 Centre de Toulouse BDA02 21 Octobre 2002 Contraintes Expression logique qui permet de contraindre les différentes affectations : AU : Utilisateur Rôle AP : Rôle Permission AS : Session Rôle 9. RBAC

96 Centre de Toulouse BDA02 21 Octobre 2002 Contraintes (suite) 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 9. RBAC

97 Centre de Toulouse BDA02 21 Octobre 2002 Contraintes (suite) 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 quau 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 » 9. RBAC

98 Centre de Toulouse BDA02 21 Octobre 2002 Contraintes (suite) Contrainte sur AS : Session Rôle Similaire aux contraintes sur AU : Utilisateur Rôle Mais contrainte dynamique lorsquun 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 9. RBAC

99 Centre de Toulouse BDA02 21 Octobre 2002 Modèle consolidé : RBAC 3 U Utilisateurs R Rôles P Permissions S Sessions AUAP HR Hiérarchie de rôles Contraintes 9. RBAC

100 Centre de Toulouse BDA02 21 Octobre 2002 Modèle consolidé : RBAC 3 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 9. RBAC

101 Centre de Toulouse BDA02 21 Octobre 2002 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 ; Création d un nouveau rôle nom_role DROP ROLE ; Suppression du rôle nom_role SET ROLE ; Permet à un utilisateur d activer un ensemble de rôle pendant la durée d une session SQL 9. RBAC

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

103 Centre de Toulouse BDA02 21 Octobre 2002 Adaptation de l instruction GRANT Affectation des privilèges aux rôles GRANT ON TO [ WITH GRANT OPTION ] ; Affectation des utilisateurs aux rôles GRANT TO Rôle junior et rôle senior GRANT TO Le rôle role2 reçoit tous les privilèges du rôle role1 9. RBAC

104 Centre de Toulouse BDA02 21 Octobre 2002 Adaptation de l instruction REVOKE Revocation de privilèges aux rôles REVOKE [ GRANT OPTION FOR ] ON FROM ; Révocation des utilisateurs aux rôles REVOKE FROM Mise à jour de la hiérarchie de rôle REVOKE role1 FROM role2 ; 9. RBAC

105 Centre de Toulouse BDA02 21 Octobre 2002 Application du modèle 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 ; 9. RBAC

106 Centre de Toulouse BDA02 21 Octobre 2002 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 9. RBAC

107 Centre de Toulouse BDA02 21 Octobre 2002 Sécurité des applications Limite des contrôles daccè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. lattaque par injection de code SQL Il est possible dassocier un rôle à lapplication Mais dans ce cas, tous les utilisateurs de lapplication disposeront des mêmes droits daccès à la base Solution insuffisante 10. Sécurité des applications

108 Centre de Toulouse BDA02 21 Octobre 2002 Base de données privée virtuelle (VPD) Mécanisme fourni par Oracle 8i pour assurer la sécurité des applications Principe Possibilité dassocier 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 dune application Permet daccéder aux attributs spécifiques de lattribut connecté via lapplication La clause WHERE de la requête modifiée est construite en utilisant ce contexte 10. Sécurité des applications

109 Centre de Toulouse BDA02 21 Octobre 2002 Contexte dapplication 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 dy associer des attributs Exemple : 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 10. Sécurité des applications

110 Centre de Toulouse BDA02 21 Octobre 2002 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 ; 10. Sécurité des applications

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

112 Centre de Toulouse BDA02 21 Octobre 2002 Limites des modèles DAC et RBAC Hypothèse de DAC Lapplication 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 Conclusion/Perspectives

113 Centre de Toulouse BDA02 21 Octobre 2002 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. Conclusion/Perspectives

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

115 Centre de Toulouse BDA02 21 Octobre 2002 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,... Conclusion/Perspectives

116 Centre de Toulouse BDA02 21 Octobre 2002 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 Conclusion/Perspectives

117 Centre de Toulouse BDA02 21 Octobre 2002 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 lorsquil 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 Conclusion/Perspectives


Télécharger ppt "Centre de Toulouse BDA02 21 Octobre 2002 Protection des systèmes dinformations : Menaces et solutions actuelles Frédéric Cuppens Maître de recherches ONERA."

Présentations similaires


Annonces Google