protection des systèmes d’informations : mena ces et solutions actuelles frédéric cuppens
DESCRIPTION
Protection des systèmes d’informations : Mena ces et solutions actuelles Frédéric Cuppens Maître de recherches ONERA Toulouse (et IRIT Toulouse à partir de Novembre 2002). Plan. A. Contexte 1. Introduction 2. Exemples d’attaques B. Démarche pour la sécurité des systèmes d’information - PowerPoint PPT PresentationTRANSCRIPT
Centre de Toulouse
BDA’02
21 Octobre 2002
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)
Centre de Toulouse
BDA’02
21 Octobre 2002Plan
A. Contexte1. Introduction
2. Exemples d’attaques
B. Démarche pour la sécurité des systèmes d’information3. 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ès8. Approche discrétionnaire
9. Approche basée sur les rôles
10. Base de données privée virtuelle
D. Conclusion / perspectives
Centre de Toulouse
BDA’02
21 Octobre 2002
Evolution du contexte
1980 1990 2000
MainframeSystème de gestion indépendant
Gestion centralisée
Chemin d’accès unique
Client/ServeurInfrastructure hétérogène
Gestion de données et d’applications
Gestion centralisée
Chemins d’accès multiples
TechnologieInternet
Infrastructure hétérogène
Réseaux avec connections multiples
Systèmes ouverts
Systèmes interropérants
Niv
eau
de
co
mp
lex
ité
1. Introduction
TechnologieInternet future
BlueToothUMTS
Active Network
WLANHiperlan
WAP I-mode
Oracle2Oracle6
Oracle7Oracle8i
Oracle9i
Centre de Toulouse
BDA’02
21 Octobre 2002
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
1. Introduction
Centre de Toulouse
BDA’02
21 Octobre 2002
Objectifs de l’intrusion
1. Introduction
Objectifs de l’intrusion
Confidentialité
IntégritéDisponibilité
Accès illégal à certaines informations
Création, modification ou suppression illégale de l’information
Empêche les utilisateurs d’avoir un accès autorisé au système
Exemples : sniffing, cracking, ...
Exemples : altering, spoofing, hijacking, ...Exemples : flooding, smurfing, ...
Centre de Toulouse
BDA’02
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 d’information critique
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
Centre de Toulouse
BDA’02
21 Octobre 2002
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
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
Internet ou DMZ
Packet sniffing (R-a-Probe)
MM
MM
MM
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 d’utilisateurs, mots de passe (même chiffrés), …
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 d’attaques
Centre de Toulouse
BDA’02
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 d’ouverture dans sa pile
•Trop de connexions à moitié ouverte peuvent conduire à un déni de service
Nerd
Toto
SYN
SYN - ACK
ClientServeur
•Le serveur attend la réponse (ack) du client et conserve dans sa pile des connexions à moitié ouvertes
SYNSYN
SYNSYN
•Le client n’envoie pas de ack pour ouvrir la connexion
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
Smurfing (R-a-deny(temporary))
Attaquant Victime
Internet
ECHO REQUESTde la victime
vers 192.168.0.255
ECHO REPLYde 192.168.0.20vers la victime
ECHO REPLYde 192.168.0.20vers la victime
ECHO REPLYde 192.168.0.20vers la victime
ECHO REPLYde 192.168.0.20vers la victime
ECHO REPLYde 192.168.0.20vers la victime
ECHO REPLYde 192.168.0.20vers 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 floodingJusqu ’à 255 messages reçus par la victime pour un message envoyé par l ’attaquant
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 d’attaques
Centre de Toulouse
BDA’02
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 d’un réseau
local Chaque machine conserve dans son cache la correspondance @IP/@MAC 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 une @IP qui ne correspond pas à une
@MAC Applications:
• Deni de service • Hijacking
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
Hijacking ARP (R-m-Intercept)
Cache ARP :@IP 192.16.1.2@MAC 00:00:00:02
(1)Communication
Cache ARP :@IP 192.16.1.1@MAC 00:00:00:01
@IP 192.16.1.1@MAC 00:00:00:01
@IP 192.16.1.2@MAC 00:00:00:02
Cache ARP :@IP 192.16.1.2@MAC 00:00:00:03
(2)ARP Poison
Cache ARP :@IP 192.16.1.1@MAC 00:00:00:03
ARP Reply :192.16.1.2 is-at
@MAC 00:00:00:03
ARP Reply :192.16.1.1 is-at
@MAC 00:00:00:03
Man In the Middle (MiM)@MAC
00:00:00:03Cache ARP :@IP 192.16.1.2@MAC 00:00:00:03
Cache ARP :@IP 192.16.1.1@MAC 00:00:00:03
(3)Hijacking
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
Scanning: exemples
• 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é
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 d’une porte dérobée (back door) Pour prendre le contrôle d’un système
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 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.
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
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)
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 : L’adresse de retour peut être écrasée
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
Schéma d’un ShellCode
• 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
NOPNOP
…NOPNOP
shellcode
adresse du shellcode…
adresse du shellcode…
adresse du shellcode…
adresse du shellcode
Début du shellcode
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
Attaque par injection de code SQL (suite)
• Exemple de Script Visual Basic exécuté par le serveur :Dim sqlSql = "SELECT * FROM Users WHERE username = ' "& username &" ' ANDpassword = ' "& 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 d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
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
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
Attaque par injection de code SQL (suite)
• Autre possibilité d’attaque
Numero dossier : 1234
Base de
données
Script Visual Basic
Réponse du SGBDRésultat analyse :
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 & " '
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 ;
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
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
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
Attaque contre les bases de données statistiques
Patient H/F Age Mutuelle Leucocyte
Dupont H 30 MMA 6000
Durand F 25 LMDE 3000
Dulac F 35 MMA 7000
Duval H 45 IPECA 5500
Dubois H 55 MGEN 3500
Dumont H 38 MMA 7500
Dupré F 32 IPECA 7200
Dupuis F 50 MGEN 6800
Dufour H 45 MAAF 4000
Dumas H 40 Rempart 3800
• Exemple : Relation Analyse(Patient,H/F,Age,Mutuelle,Leucocyte)
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
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 1SELECT 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
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
Attaque contre les bases de données statistiques (suite)
• Requête 3SELECT COUNT ( Patient )
FROM Analyse
Résultat : 10
• Requête 4SELECT COUNT ( Patient )
FROM Analyse
WHERE NOT ( H/F = 'H'
AND Mutuelle = ‘MGEN’ ) ;
Résultat: 9 ; 10 - 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 5SELECT SUM ( Leucocyte )
FROM Analyse
Résultat : 54300
• Requête 6SELECT SUM ( Leucocyte )
FROM Analyse
WHERE NOT ( H/F = 'H'
AND Mutuelle = ‘MGEN’) ;
Résultat : 50800 ; 54300 – 50800 = 3500
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 7SELECT 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 8SELECT COUNT ( Patient )
FROM Analyse
WHERE H/F = 'H'
AND NOT (Mutuelle = ‘MGEN’) ;
Résultat : 5
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 9SELECT 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 10SELECT SUM ( Leucocyte )
FROM Analyse
WHERE H/F = 'H'
AND NOT (Mutuelle = ‘MGEN’) ;
Résultat : 26800 ; 30300 - 26800 = 3500
2. Exemples d’attaques
Centre de Toulouse
BDA’02
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 qu’un traqueur global existe « presque toujours » Et il est habituellement facile à trouver
2. Exemples d’attaques
Centre de Toulouse
BDA’02
21 Octobre 2002
B. Démarche pour la sécurité des systèmes d’information
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 particulierappliqué à un système d ’information
Garantit que le système ne violepas la politique de sécurité
Mécanismes logiciels ou matérielsqui implantent la politique de sécuritédans le système conformément auxpropriétés de sécurité
Techniques pour détectertoute tentative de violationde la politique de sécurité
Centre de Toulouse
BDA’02
21 Octobre 2002
Comment construire une politique de sécurité
• Méthodologie informelle
Périmètrede sécurité
Analysede risques
Politique desécurité interne
Politique desécurité système
Politique desécurité technique
Architecture desécurité
Fonctions etMécanismesde sécurité
Politique de sécurité Conception du système sécurisé
3. Politique de sécurité
Centre de Toulouse
BDA’02
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é
Centre de Toulouse
BDA’02
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é
Centre de Toulouse
BDA’02
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 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
3. Politique de sécurité
Centre de Toulouse
BDA’02
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 desécurité interne
Politique desécurité système
Politique desécurité technique
Politique de sécurité
Etape 3.1
Etape 3.2
Etape 3.3
3. Politique de sécurité
Centre de Toulouse
BDA’02
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é
Centre de Toulouse
BDA’02
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é
Centre de Toulouse
BDA’02
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é
Centre de Toulouse
BDA’02
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é
Centre de Toulouse
BDA’02
21 Octobre 2002
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 »
4. Détection d’intrusions
Centre de Toulouse
BDA’02
21 Octobre 2002Détection de scénarios d ’attaques
Fichiersd ’audit
Systèmecible
Analyseurd ’audit
IHM
BD designaturesd ’attaques
Alarmes Commandes
Journalisation
Insertion/Mise a jour
Attaquesdétectées
Centre de Toulouse
BDA’02
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 d’intrusions
Centre de Toulouse
BDA’02
21 Octobre 2002
Fichiersd ’audit
Détection de comportements anormaux
Systèmecible
Analyseurd ’audit
IHM
BD decomportements
normaux
Mise à jour descomportements
Alarmes
Journalisation
Anomaliesdétectées
Centre de Toulouse
BDA’02
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 d’intrusions
Centre de Toulouse
BDA’02
21 Octobre 2002
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 100 000 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
4. Détection d’intrusions
Centre de Toulouse
BDA’02
21 Octobre 2002
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
Centre de Toulouse
BDA’02
21 Octobre 2002
Authentification
• Authentification par le SGBD ou par le système d’exploitation
Authentification par le SGBDSGBD
BD
Authentification par l’OS
Profil des utilisateur
s
5. Authentification
Centre de Toulouse
BDA’02
21 Octobre 2002
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
5. Authentification
Centre de Toulouse
BDA’02
21 Octobre 2002
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
5. Authentification
Centre de Toulouse
BDA’02
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
SGBDBD
EcouteInterceptionAltérationMascaradeRejeu
6. Sécurité des communications
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
21 Octobre 2002
Politique de contrôle d’accès = ensemble de règles
• Format des règles
Sujet
Permission
Interdiction
Obligation
Action
Objet
Ensembled ’objets
avoir
avoir
avoir
réaliser
réaliser
réaliser
agirsur
agirsur
7. Politique de contrôle d’accès
Centre de Toulouse
BDA’02
21 Octobre 2002
Concept de base d’une 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
Sujet Action ObjetRéaliser Agir sur
7. Politique de contrôle d’accès
Centre de Toulouse
BDA’02
21 Octobre 2002
Exemple : Système d ’information d ’un groupe médical
• Sujets = personnels du groupe médical
JeanJeanne
Médecin
Nadine
Secrétairemédical
• Objets : Dossiers des patients
7. Politique de contrôle d’accès
Centre de Toulouse
BDA’02
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 d’accès
Centre de Toulouse
BDA’02
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 d’accès
Centre de Toulouse
BDA’02
21 Octobre 2002
Exemple de règles
• 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
7. Politique de contrôle d’accès
Centre de Toulouse
BDA’02
21 Octobre 2002
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
7. Politique de contrôle d’accès
Centre de Toulouse
BDA’02
21 Octobre 2002
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
7. Politique de contrôle d’accès
Centre de Toulouse
BDA’02
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 d’accès
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
21 Octobre 2002
Exemple typique de DAC
• Gestion des droits dans UNIX
Répertoire
F
Contenudu fichier F
User Group Other
R W E R W - 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
Centre de Toulouse
BDA’02
21 Octobre 2002
Principe du modèle DAC proposé par SQL
UUtilisateur
PPermission
VVue
AAction
OObjet
= N-uplet
8. DAC
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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 d’exécuter
• Instruction REVOKE Permet d ’enlever un privilège que possède un utilisateu
8. DAC
Centre de Toulouse
BDA’02
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 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
8. DAC
Centre de Toulouse
BDA’02
21 Octobre 2002
Instruction GRANT
• 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
8. DAC
Centre de Toulouse
BDA’02
21 Octobre 2002
Instruction REVOKE
• 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
8. DAC
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
21 Octobre 2002
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 ;
8. DAC
Centre de Toulouse
BDA’02
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 » 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 »
8. DAC
Centre de Toulouse
BDA’02
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 vueCREATE 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 INSERTON dossier_admin_medecin TO Jean, Jeanne ;
8. DAC
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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_medecinWHERE 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_PaulTO Nadine ;
Possible car le médecin a le privilège « WITH GRANT OPTION » sur la table prescription_du_medecin
8. DAC
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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 d’accès basé sur l’identité des sujets Pas de structuration des sujets
8. DAC
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
21 Octobre 2002
Modèle consolidé :Contraintes + Hiérarchie
La famille des modèles de RBAC96
RBAC0
Modèle de base(le plus simple)
RBAC1 RBAC2
RBAC3
ContraintesHiérarchie de rôles
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
Modèle de base : RBAC0
UUtilisateurs
RRôles
PPermissions
.
.
. SSessions
AUAffectation
desUtilisateurs
APAffectation
desPermissions
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 parun seul utilisateur
• Un utilisateur peut activerplusieurs rôles dans une session
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
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
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
Hiérarchie de rôles : RBAC1
UUtilisateurs
RRôles
PPermissions
.
.
. SSessions
AU AP
HRHiérarchiede rôles
9. RBAC
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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 qu’un utilisateur joue le rôle R1, cet utilisateur joue aussi le rôle R2
Personnel médical
Médecin
Généraliste Spécialiste
Cardiologue Rhumatologue . . .
9. RBAC
Centre de Toulouse
BDA’02
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
. . .
9. RBAC
Centre de Toulouse
BDA’02
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 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
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
Contraintes : RBAC2
UUtilisateurs
RRôles
PPermissions
.
.
. SSessions
AU AP
Contraintes
9. RBAC
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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 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 »
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
Contraintes (suite)
• 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
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
Modèle consolidé : RBAC3
UUtilisateurs
RRôles
PPermissions
.
.
. SSessions
AU AP
HRHiérarchiede rôles
Contraintes
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
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
9. RBAC
Centre de Toulouse
BDA’02
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 <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
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
Principe de la gestion des rôles dans SQL3
RRôle
PPermission
VVue
AAction
OObjet
=N-uplet
UUtilisateur
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
Adaptation de l ’instruction GRANT
• Affectation des privilèges aux rôlesGRANT <liste privileges>
ON <table ou vue>
TO <liste roles>
[ WITH GRANT OPTION ] ;
• Affectation des utilisateurs aux rôlesGRANT <liste roles>
TO <liste utilisateurs>
• Rôle junior et rôle seniorGRANT <role1> TO <role2> Le rôle role2 reçoit tous les privilèges du rôle role1
9. RBAC
Centre de Toulouse
BDA’02
21 Octobre 2002
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ôlesREVOKE <liste roles>
FROM <liste utilisateurs>
• Mise à jour de la hiérarchie de rôleREVOKE role1 FROM role2 ;
9. RBAC
Centre de Toulouse
BDA’02
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 PRIVILEGESON dossier_adminTO secretaire_medicale ;
• Puis affectation de Nadine au rôle secretaire_medicale
GRANT secretaire_medicale to Nadine ;
9. RBAC
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
21 Octobre 2002
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
10. Sécurité des applications
Centre de Toulouse
BDA’02
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é 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
10. Sécurité des applications
Centre de Toulouse
BDA’02
21 Octobre 2002
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 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
Centre de Toulouse
BDA’02
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 isMY_PREDICATE varchar2(2000) ;beginMY_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
Centre de Toulouse
BDA’02
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'
• L’application 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 qu’aux dossiers médicaux de ses patients
10. Sécurité des applications
Centre de Toulouse
BDA’02
21 Octobre 2002
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
Conclusion/Perspectives
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
21 Octobre 2002
Limites des modèles DAC et RBAC (suite)
• Exemple de Cheval de Troie Attaque contre la confidentialité
Dossiersdes
patients
Bénéficiairedu Chevalde Troie
Application piégée
Médecin
L ’application piégée a les droits de lectureet d ’écriture sur les dossiers des patients
Transmission des dossiers des patientsà l ’insu du médecin
Conclusion/Perspectives
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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
Centre de Toulouse
BDA’02
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 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
Conclusion/Perspectives