Sécurité des bases de données

Transcription

1 Sécurité des bases de données samedi Jean-Eric Djenderedjian Pierre-Antoine Failly Christophe Mollet Stanley Hammer Seraphin Serillon Fabrice Boissier

2 I. Executive summary... 1 II. Introduction... 2 III. Pourquoi ce sujet? Rappel Historique Attaques sur les bases de données... 4 IV. Les scénarios d'attaques classiques Exemple basique : Le formulaire d'authentification non protégé... 5 V. Les scénarios d'attaques évolués Ampleur d une attaque Exemple récents et célèbres... 8 VI. La sécurisation des bases de données en entreprises Situation actuelle a. Normes et bonnes pratiques b. Points organisationnel et architecture Audit a. Définition b. Pourquoi auditer? c. Quoi auditer? VII. Cryptographie appliquée aux bases de données Confidentialité a. Chiffrement du côté serveur b. Chiffrement du côté client Intégrité a. Définitions b. Journalisation c. Stockage d. Sauvegarde Authenticité a. Journalisation... 29

3 b. Droits et Structure de la BDD Limites et Améliorations du Matériel a. Améliorations du Matériel b. Limites du Matériel VIII. Analyse de cette situation IX. Solutions disponibles sur le marché IBM Oracle Microsoft SQL Server Magic Quadrant X. Conclusion XI. Bibliographie/Webographie & remerciement... 39

4 I. Executive summary Today Security Database is a major challenge. Many organizations keep all of their data in the IT. In this report we will present you several databases aspects to a better understanding of their securities. To keep databases safe we have to respect at least, these following points: Standards and Best Practices respect Understand Databases issues Softwares update Professional security management Audit cycle (PDCA) Security prevention Of course, depending on data importance, more security system can be done. Every organization has to correlate their risks with their costs. Another point really important in the database security is the cryptography and the different aspects resulting of this. In fact, we cannot speak about Cryptography without speaking about these three following points: Integrity: Fact to access to information by unauthorized recipients and intentional but unauthorized destruction or alteration of that information Confidentiality: Fact to nondisclosure of information except to another authorized person Authenticity: Fact to undisputed origin or authorship Please keep in mind there is no database system 100% safe. Moreover a new technology called Big Data is coming. For this reason, we always have to keep watching over new technologies to make databases as safe as possible. Page 1

5 II. Introduction Depuis leur apparition, les bases de données sont devenues indispensables dans le monde de l informatique. Les systèmes d exploitation, les logiciels de gestions, les réseaux sociaux ne sont que quelques exemples utilisant les bases de données. Comme nous venons de le voir au travers de trois exemples, leur implantation est telle que la sécurité de ces bases de données est primordiale surtout en prenant en considération le caractère sensibles des informations (numéro de carte bancaire, de sécurité sociale, etc.) stockées. Dans ce rapport nous vous présenterons les enjeux de la sécurisation des bases de données. Il est toujours important d assimiler la théorie, voici pourquoi ce rapport commence par une partie rappel (sur l historique des bases de données et des différentes attaques sur ces dernières) avant de présenter la sécurité des bases de données en entreprise pour finir par les solutions techniques des éditeurs en matière d intégrité et de confidentialité. Page 2

6 III. Pourquoi ce sujet? 1. Rappel Historique Jusqu'en 1960 les informations étaient enregistrées dans des fichiers manipulés par les logiciels applicatifs. L'idée des bases de données a été lancée dans le cadre du programme Apollo. Les premières bases de données sont donc apparues au début des années Afin de pouvoir manipuler ces données IBM, conjointement avec Rockwell met sur le marché le logiciel Information Management System (IMS). Ce SGBD était de type hiérarchique : un niveau contenait les informations qui sont identiques sur plusieurs enregistrements de la base de données. Le découpage a ensuite été étendu pour prendre la forme d'un en arbre. A la même époque General Electric, avec l'aide de Charles Bachman, met sur le marché le logiciel Integrated Data Store. Avec ce SGBD les informations sont enregistrées dans des bases de données organisées selon un modèle réseau (topologie en étoile), ce qui permet d'enregistrer des informations ayant une organisation plus complexe que le modèle hiérarchique. En 1965, Charles Bachman conçoit l'architecture Ansi/Sparc encore utilisée de nos jours. Cette innovation eut pour but de faire la distinction claire entre la représentation interne des données au niveau physique (structure de données) et la représentation logique de celles-ci. La deuxième grande innovation de ce modèle est la possibilité de créer des schémas externes qui sont en fait des portions de la base de données (sous-bases virtuelles) destinées à différents utilisateurs. Un utilisateur particulier ne peut que manipuler les données appartenant à son propre schéma externe. En 1968 Dick Pick crée Pick, un système d'exploitation contenant un système de gestion de base de données «multivaluée», ce système fonctionnait grâce à une décomposition hiérarchique en comptes, avec des fichiers, des enregistrements, des champs, des sous-champs et des sous-souschamps. En 1970, Edgar F. Codd note dans sa thèse mathématique sur l'algèbre relationnelle qu'un ensemble d'entités est comparable à une famille définissant une relation en mathématique et que les jointures sont des produits cartésiens. Cette thèse est à l'origine des bases de données relationnelles. Apparues dans les années 1990, les bases de données objet-relationnel utilisent un modèle de données relationnel tout en permettant le stockage des objets. Depuis ces années, les bases de données n ont pas réellement évolué. En revanche, un problème commence à se faire ressentir. En effet, les bases données deviennent de plus en plus Page 3

7 grosses et brassent des quantités astronomiques d informations. Des spécialistes sont donc en train de plancher sur de nouveaux types de bases de données afin de résoudre ce problème. Voici une frise chronologique représentant l'évolution des bases de données de 1960 à nos jours: 2. Attaques sur les bases de données De nos jours, l importance des informations contenues dans les bases de données est une cible de choix pour les hackers, ce n est donc pas les exemples et les types d attaques possibles qui manquent. Nous avons choisi de vous présenter deux attaques bien connues des experts informatiques. L une d elle est très utilisée de nos jours. Étant assez simple à mettre en place elle ne nécessite pas une grande maîtrise afin de la mener à bien. L autre, diamétralement opposée, est très connu pour avoir été de très grande ampleur et avoir touché de nombreux pays. La première attaque est l injection SQL c est à dire l'exploitation d'une faille touchant une application interagissant avec une base de données qui permet de compromettre la sécurité de la base en injectant une requête non prévue par le système. Nous en parlerons plus longuement dans la suite de notre rapport. L autre attaque nommée Stuxnet a été commise en C est un ver informatique spécifique au système Microsoft Windows. Le virus s attaque aux systèmes Microsoft Windows par le biais d une faille des logiciels SCADA WinCC/PCS 7 de Siemens (basés sur des bases de données SQL serveur). Le ver a affecté systèmes informatiques, dont situés en Iran, y compris des PC appartenant à des employés de la centrale nucléaire de Bouchehr. Il a également touché, dans une moindre mesure, des ordinateurs et des centrales situés en Allemagne, en France, en Inde et en Indonésie également utilisateurs de technologies Siemens. A travers ces deux exemples, on s'aperçoit que l attaque des bases de données peut aussi bien toucher les sites internet les plus basiques, que les applications utilisées dans les centrales nucléaires. Bien entendu, leurs complexités diffèrent suivant leurs importances mais la finalité reste la même, l extraction et/ou la manipulation d informations dans le but de nuire à une organisation ou un état. Page 4

8 IV. Les scénarios d'attaques classiques Quand on pense aux scénarios typiques d'attaques sur une base de données on pense spontanément aux attaques ciblant les bases de données sur lesquelles s appuient les applications web. Il est tout à fait normal de penser à ce type d'attaque car c'est à la fois le plus courant et le plus simple à mettre en place (tout du moins quand le site web n'est pas bien protégé). Cette partie va donc exposer la technique du SQLi (SQL Injection) en prenant l'exemple des applications web. 1. Exemple basique : Le formulaire d'authentification non protégé Disclaimer Le but de cette section n'est pas d'apprendre à plus de gens comment attaquer un site web, c'est en gardant ça en tête qu au lieu de présenter ici la technique du blind SQLi time based nous présentons l'exemple le plus basique et donc celui qui a le plus de chance d'être inefficace et détecté. Quel est le but des hackers Dans l'exemple présent, bypasser le processus d'authentification (et donc atteindre à la confidentialité des informations). Comment le mettre en place Comme dans tout bon formulaire d'authentification celui de notre exemple comporte au moins deux champs (un pour l'identifiant et un pour le mot de passe), afin de bypasser le formulaire il va donc falloir user de l'un de ces deux champs afin de fausser le test d'authentification. Toute la complexité de cette technique réside en fait dans la compréhension de la forme qu'a la requête SQL employée pour l'authentification. Une fois que nous avons une idée approximative de la forme de la requête SQL alors on peut commencer à bypasser les tests. Page 5

9 Dans l'exemple présent il suffit de rentrer "User' --" en identifiant et n'importe quel mot de passe pour être authentifié comme User (si tant est que cet utilisateur existe et qu'il a les droits nécessaires pour passer ce formulaire). Comment ça marche Imaginons par exemple que la requête ressemble à "SELECT uid WHERE name = '(nom)' AND password = '(mot de passe hashé)';" (ce qui semble crédible étant donné notre exemple encore une fois simplifié à l'extrême) on se rend alors compte qu'il y a deux parties dans notre test : Celle portant sur l'identifiant Celle portant sur le mot de passe En insérant "User' --" dans le champ identifiant la requête devient: "SELECT uid WHERE name = 'User' --' AND password = '(mot de passe hashé)';" ce qui nous permet de nous authentifier. Pourquoi? Tout simplement car les "--" ont en SQL la signification de commentaire, ce qui écrase donc le second test sur les mots de passes. Une seconde techniques consisterait à attaquer le second champ (celui du mot de passe donc) en insérant "' OR 1=1 --", la requête devenant donc : "SELECT uid WHERE name = 'User' AND password = ' OR 1=1 --';" On peut donc voir qu'ici au lieu d'annuler directement le test sur le mot de passe on le contourne à l'aide d'une opération logique (AND, OR, NOT, etc.) triviale. La technique du SQL injection est très loin de se limiter à ça, on pourrait d'ailleurs considérer dans le cas présent que le but réel du hacker soit la compromission de l'intégrité de la base de données, pour se faire il lui aurait suffit d'intégrer un payload (qui se serait chargé de changer les valeurs de la base) ou plus simplement la compromission du serveur (il suffit pour cela que ce formulaire soit en fait un formulaire d'authentification pour accéder à la plateforme d'administration du site). Page 6

10 V. Les scénarios d'attaques évolués 1. Ampleur d une attaque Très peu des attaques sur les bases de données sont réalisées pour le plaisir ou par défi. Chaque intrusion dans une base est un risque pour le propriétaire des données. L ampleur de ce risque peut varier, cela peut aller du vol de données à leur vente sur le marché noir en passant par la compromission de serveur ou de l intégrité des données. Vol de données Les vols de données n'entraînent pas nécessairement la destruction ou l'altération des données. Si les données sont copiées, transférées ou imprimées, les originaux restent inchangés. C'est d'ailleurs une des raisons pour lesquelles il est difficile de détecter ces vols tout particulièrement quand les accès à la base de données manque de traçabilité ou que les logs sont mal gérés voire non-exploités. L'impact d'un vol de données confidentielles (par exemple des brevets, des clefs privées, etc.) peut être nettement supérieur à la simple perte de données. On parle aussi de perte de confidentialité des données. Compromission de serveur L intrusion d une personne non-autorisée sur un serveur contenant une base de données, compromet la machine. L attaquant peut créer une backdoor (un compte possédant des privilèges administrateur ou root) et y installer un botnet permettant le vol de données sur une échelle de temps plus longue ou pire détourner la machine pour lui faire effectuer des actions non souhaitées et non maîtrisées par la société hébergeant la base. Le danger d une telle attaque provient du fait que l on ne sait pas depuis combien de temps l intrusion et le vol de données ont eu lieu. Outre le vol des données, l attaquant peut également utiliser ces failles pour y déposer un ver ou un virus qui pourra se répandre d une base de données à une autre sans avoir besoin de trouver de faille. Une fois la machine infectée, le ver peut y voler des données, les modifier, y installer une backdoor, etc. Remise en question de l intégrité des données Lors d une intrusion, le vol de données n est pas la seule option. L attaquant peut également modifier le contenu des données et ainsi remettre en doute leur intégrité. Encore plus difficile à détecter que le vol de données, leur modification est une attaque qui a de lourdes conséquences. A moins de trouver exactement les fichiers corrompus (ce qui, dans une grande base de données, est très difficile), la solution est d écraser toute la base et de la remplacer par un backup (copie intégrale des données) sauvegardé sur un autre serveur. Ces sauvegardes n étant réalisées que périodiquement, la remise à niveau d une base de données signifie la perte définitive d une partie de ces données. Page 7

11 Vente d accès ou de données sur le marché noir Sécurité des bases de données Le vol et la modification de données sont des attaques très dangereuses mais qui ne peuvent être réalisées que par peu d attaquants. Pour ces personnes les données récupérées lors de l intrusion n ont pas une grande utilité. Cependant, la revente sur le marché noir de ces données ou des accès récupérés est la pire conséquence d une attaque visant les bases de données. La plupart des projets des entreprises restent internes à l entreprise principalement pour des raisons de concurrence. La revente d informations cruciales peut faire perdre à une entreprise des années de travail et d argent investis. Lors d une intrusion, il n est jamais à exclure qu un recèle de données sera effectué. Pour éviter cela, il faut mettre en place un chiffrement des données sensibles de l entreprise pour que leur utilisation devienne impossible par des personnes non autorisées. 2. Exemple récents et célèbres Voici quelques exemples d attaques célèbres et récentes. Sony L'attaque est survenue entre le 17 et le 19 avril Durant l'attaque, des millions de données personnelles et bancaires ont été subtilisées. Le 20 avril 2011, Sony ferme le PlayStation Network quelques jours après l'intrusion malgré les fortes contraintes de production associées à cette plateforme. Avec un total de plus de 77 millions d'utilisateurs, le nombre de données et d identifiants volés font de cette attaque la plus grande qu a subit le réseau depuis son lancement en De lourdes pertes financières se comptant en milliards de dollars ont été recensées et un bon nombre d'actions en justice ont été engagées contre la firme. SQL_Slammer Le ver SQLSlammer exploite une faille de type buffer overflow déjà ancienne pour infecter les serveurs SQL Server non à jour dans leurs correctifs via une requête malformée. Il est présent uniquement en mémoire, n'est pas destructif et ne peut pas infecter le poste de travail d'un simple utilisateur. Dans la journée du samedi 25 janvier 2003, l'activité maximale du ver a entraîné un peu partout dans le monde une consommation anormalement élevée de bande passante, rendant difficile voire impossible l'accès à certains sites web ou l'utilisation de certains services utilisant internet. Ces perturbations sont également à l'origine d'une rumeur faisant état d'une attaque DDoS par plusieurs groupes de pirates. Pour plus de renseignements sur ce qui s'est réellement passé, voir la revue de presse. La majorité des serveurs, pas à jour dans leurs correctifs lors de l'apparition du virus, ayant été patchée, même si des variantes ou de nouveaux vers utilisant la même faille apparaissent, leurs effets sur le trafic resteront limités. L'activité du ver durera cependant jusqu'à ce que tous les serveurs vulnérables soient mis à jour, ce qui pourra prendre potentiellement très longtemps en fonction de la diligence des administrateurs concernés. Page 8

12 Ces derniers doivent donc impérativement appliquer le correctif de sécurité, d'autant qu'une variante destructive du ver pourrait entraîner des pertes de données en plus d'une perturbation localisée du trafic réseau. Cette attaque est celle qui a révélé à la face du monde l importance à la fois de la sécurité mais aussi de l application des mises à jour. Page 9

13 VI. La sécurisation des bases de données en entreprises La Sécurité du système d'informations est de facto un sujet d'expert il est donc naturellement un sujet plutôt technique. Dans l'esprit des décideurs des entreprises modernes l'adjonction de la sécurité à la technique donne le plus souvent la cryptographie. Or c'est une vision extrêmement limitative de ce qu'est la Sécurité du système d'informations en effet la cryptographie peut proposer des solutions assurant l'intégrité et la confidentialité des données. Néanmoins, dans le monde sur-connecté dans lequel nous vivons, une composante de la Sécurité du système d'informations prend une place de plus en plus importante : la disponibilité. En marge des solutions organisationnelles à mettre en place pour s'assurer une meilleure administration des bases, nous vous présenterons donc des solutions - notamment architecturales - améliorant la disponibilité des données avant de décrire les solutions cryptographiques disponibles sur le marché. 1. Situation actuelle a. Normes et bonnes pratiques L implantation actuelle des bases de données dans le monde de l entreprise étant ce qu elle est, de nombreuses normes et best practices ont vu le jour afin d aider les sociétés à déployer, administrer et sécuriser au mieux leurs données. Notre but ici n est pas d être exhaustifs - le format de ce document ne le permettant de toute façon pas - en lieu et place de décrire en détails toutes les normes et bonnes pratiques régissant l utilisation en entreprise (ou tout autre contexte - type laboratoire de recherches informatiques - nécessitant à la fois de l optimisation et de la sécurité) des bases de données, ce rapport comportera plutôt une liste des principales normes, best practices et autre obligations légales pouvant impacter la gestion des bases de données ainsi qu un recueil détaillant les dix bonnes pratiques considérées comme étant les plus importantes. Quand il s agit de normes, le premier organisme qui vient en tête d une personne ayant une sensibilisation (à la sécurité informatique, à la qualité, etc.) est probablement ISO. Cet organisme mondialement reconnu a en effet rédigé une quantité impressionnante de normes et autres recueils de bonnes pratiques. Ici les deux numéros qui vont nous intéresser sont les normes ISO et la première est une norme décrivant les exigences pour la mise en place d un Système de Management de la Sécurité de l Information (SMSI). - la seconde en revanche est un recueil de bonnes pratiques destiné à aider les responsables que ça soit de la mise en place, de l exploitation ou de l amélioration du SMSI. CobiT en tant que référentiel principal de la gouvernance des SI (basé lui aussi sur des bonnes pratiques collectées auprès d experts) fait également partis des référentiels qui peuvent être important d intégrés dans son SMSI. En marge de ces grands noms des normes et bonnes pratiques de nombreux autres noms peuvent être évoqués ici bien que beaucoup plus restrictifs (certains s appliquant uniquement sur Page 10

14 une certaines zones géographiques et sur un secteur d activités restreint) il n en reste pas moins important (notamment car certains sont des obligations légales), dans cette secondes listes on retrouve par exemple PCI-DDS, les accords de Bâle, les obligations issues de l ARJEL, SSAE 16 (successeur de SAS 70), COSO, HPST, etc.) b. Points organisationnel et architecture i. Checklist Cette section de ce rapport va vous détailler certaines des recommandations qui nous ont semblé être à la fois les plus importantes et potentiellement les plus simples à mettre en place. 1) Changer le mot de passe par défaut Lors du déploiement d une base de données il est extrêmement rare que cette dernière vous propose instinctivement de changer les identifiants (mot de passe et - certains penseront que cette démarche doit être réservée pour les plus paranoïaque d entre nous néanmoins et même si le temps de la sécurité par l obscurité est révolu il ne fait jamais de mal d être imprévisible sur certains point - login) du ou des comptes - notamment administrateurs - installés par défaut et c est un problème majeur. En effet de nombreux sites internet référençant les différents couples login/mot de passe pour les différentes versions des différents systèmes de gestion de bases de données existent, il est possible que vous l ignoriez, les hackers en revanche se servent fréquemment de ce genre d informations. Changer ce mot de passe (voire le login) pourrait être l occasion de réfléchir à la nécessité d instaurer une politique de gestion des mots de passe en gardant en tête que ce qui importe vraiment est l entropie des mots de passe choisis 2) Refuser les connexions distantes La seconde condition extrêmement dangereuse pour un système de gestion de base de données est son exposition directe sur Internet. Cela peut sembler être une évidence mais autant que faire ce peu (et les cas où cette exposition est obligatoire sont vraiment rares voire même inexistants à condition de se donner les moyens nécessaire à la sécurisation des données [archi 3-tiers et/ou DMZ]) il serait bon de faire passer tous les accès à la base de données par un serveur local. 3) Décommissionner votre base Par défaut la majorité des bases de données disponibles sur le marché s installe des utilisateurs, des tables voire même des bases entières en vu de tester la base de données. Nous ne sommes pas ici pour discuter de leur intérêt ou non lors d une phase de test, toujours est-il qu au moment de passer la base de données en production il serait bon de faire disparaître ces utilisateurs/tables/bases qui, une nouvelle fois, sont répertoriés sur Internet et sont donc à même de faciliter une intrusion. 4) Activer les logs Il est également très important d adopter une politique de gestion des logs (ne serait-ce que les activer est un bon début, certains SGBD n activent pas cette option par défaut). Page 11

15 En fonction du secteur de votre entreprise il se peut même que cela soit une obligation légale (notamment pour vous fournir les moyens d expliquer aux autorités ce qui s est passé en cas d intrusions voire même de compromission). 5) Exécuter le service avec un compte de service La plupart des SGBD modernes sont conçu pour pouvoir fonctionner en userland (par opposition au kernelland) ce qui implique qu en cas de compromission du système les actions que pourra effectuer l attaquant auront un impact minimisé. Dans la même optique il peut-être intéressant de chrooter le service de façon à rendre plus difficilement accessible les fichiers du système et donc à complexifier la compromission totale du serveur. 6) Chiffrer les données stockées Un tiers de ce rapport est consacré aux solutions de cryptographie adaptées aux bases de données mais malgré l évidence que cela représente, il semble pertinent de relever ici que si les données stockés sont sensibles, il est primordiale de les chiffrer et de ne pas stocker les clefs sur le serveur hébergeant le SGBD de façon à assurer leur confidentialité même si ces dernières se trouver être compromises. 7) Appliquer les patchs de l éditeur Les SGBD sont en réalité un logiciel comme un autre, il serait donc dangereux de les laisser devenir obsolètes. En effet de très nombreuses failles étant découvertes sur ces systèmes critiques, les patchs sont donc tout autant nombreux. Il est donc intéressant de mettre en place, en collaboration avec l équipe de production, une politique de management des mises à jour. 8) Restreindre les privilèges des utilisateurs Une best practice importante est également l analyse du besoin fonctionnelle. En effet tous les utilisateurs n ont pas besoin d avoir accès à toutes les données. Une fois cette analyse effectuée il peut également être intéressant de donner des droits différents aux utilisateurs en fonction de leurs besoins propres (par exemple un compte utilisé pour lister les articles d un site web commerçant via n importe quelle technologie web n a d une part nullement besoin d accéder à la liste des utilisateurs (par exemple) et d autre part son action étant uniquement de lister les entrées de la table article il serait superflu (et donc potentiellement dangereux en cas de compromission du compte) de doter ce compte des droits de modifications ou de création d entrées). 9) Sauvegarder votre configuration Il est enfin extrêmement important de conserver précieusement votre configuration de base de façon à pouvoir mettre une instance de spare rapidement en production que cela soit simplement pour faire grossir votre capacité à supporter la charge (nous reviendrons sur ce point plus tard) ou en cas de défaillance de la première (ces deux remarques sont d autant plus vraies dans le cas d une architecture virtualisée). Page 12

16 10) Porter une attention particulière au développement des clients En effet ces derniers ont le rôle de front-end et sont donc la première cible des attaques. Le moindre défaut de conception dans un client peut compromettre l intégralité d une base, d un SGBD, d un serveur voire même d un système d information entier! De nombreux guides d audit et d aides au développement existent afin d orienter les développeurs vers une façon de coder plus sécurisée (un exemple serait d utiliser systématique des procédures stockées et de filtrer les entrées des utilisateurs). ii. Architecture sécurisée Les SGBD sont le plus souvent représentés sous la forme de serveurs dédiés ces mêmes serveurs se trouvant dans des datacenters lorsque la société en a les moyens. Nous allons faire un rapide rappel des différents éléments nécessaires à la compréhension d une architecture puis détailler certaines bonnes pratiques à adopter afin d ajuster la disponibilité des données aux besoins métiers. Serveurs 1U 2U En dehors de la puissance (CPU et RAM) du serveur, ce qui va nous intéresser ici c est sa connectique. En effet une grande partie des problèmes de continuité d activités provenant de l architecture physique (par opposition aux problèmes logiques et donc logiciels) viennent en fait soit de la connexion réseau soit de l alimentation électrique. Baies 4U 14U 22U 42U Dans le cas présent la taille importe peu en soit (sauf le cadre d'un contrat d'hébergement, auquel cas les baies sont soit directement fournies soit la taille des baies est normalisée - le plus souvent à 42U) il est cependant important de bien prévoir son besoin - tout en prenant en considération qu'il est extrêmement rare qu'une baie soit exclusive aux serveurs (comme le révèle l image ci-dessus), il Page 13

17 est en effet fréquent de trouver des équipements réseaux (switch, firewall, VPNbox, IDS/IPS, routeurs, etc.) ainsi que des éléments annexes (des onduleurs par exemple) au milieux des serveurs d'une baie - en effet une baie standard (de 42U) toute équipée coûte la bagatelle d'un million d'euro actuellement. Bonnes pratiques Le moyen le plus simple de palier un problème d alimentation (électrique ou réseau) est de redonder cette dernière. Cette solution n en est pas réellement une dans le sens où elle se contente de contourner le problème au lieu de lui trouver un palliatif. Il n empêche que dans les faits, cette solution de résilience est celle permettant d améliorer sensiblement la qualité de service si tant est qu elle est mise en place correctement. Ici le but recherché en doublant les alimentations et les prises réseaux n est pas de palier un dysfonctionnement des câbles d alimentation ou des câbles réseaux mais bien de palier au dysfonctionnement éventuel du fournisseur de service. Il est donc important de s assurer que ces deux câbles d alimentations ne soient pas reliés à la même source de courant (il en va de même pour les câbles réseaux qui doivent, eux, être reliés aux réseaux de deux opérateurs de télécommunications différents ce qui dans les faits est relativement complexe à obtenir étant donné la facilité avec laquelle les opérateurs se louent leur réseaux). Ce système monolithique dans lequel on espère survivre aux problèmes en surprotégeant les petits éléments de l architecture est certes efficace mais coûtent relativement cher (ce n est certes pas spécialement le cas pour les serveurs mais si on prend en compte toute l architecture de production - et donc les équipements réseaux type firewall et routeurs - les prix s envolent extrêmement rapidement). Pire encore, plus les besoins de l entreprise grandissent et plus ce modèle de serveurs dédiés montre ses limites, il était donc crucial de trouver une alternative. La seule vraie solution pour supporter les montées en charges est de passer sur une architecture distribuée. Ce qui signifie donc d avoir des load-balancer dont l unique tâche est de distribuer les actions à effectuer (vraisemblablement des requêtes SQL dans le cadre des bases de données) vers les serveurs de travail. Il est évident que dans ce genre d architecture ce ne sont plus les serveurs mais bien les load-balancer qui deviennent les éléments cruciaux (on peut même parler dans certains cas de SPOF), leur plus faible nombre nous permet de leur fournir une résilience maximum sans pour autant voir le budget exploser. En utilisant une architecture de ce type il devient possible de supporter beaucoup plus de charges tout en pouvant passer sur des pools de serveurs / équipements réseaux moins résilients (et donc moins cher) sans pour autant réduire la qualité de service (ou SLA). La seconde alternative (reposant également sur le modèle d architecture distribuée) est la virtualisation. Il est en effet aisé de nos jours de virtualiser des pools de serveurs load-balancés sur une architecture virtualisée. Cette solution offre une plus grande flexibilité que son homologue physique, en effet les hyperviseurs modernes (par exemple ESX de VMWare) permettent de déplacer une instance de serveur d un serveur physique vers un autre ce qui peut permettre d optimiser au maximum son parc informatique. On peut alors se demander quel est l intérêt économique de cette solution - en effet les serveurs contribuant à l architecture virtualisée font souvent partie de catégorie haute, et de plus, la mise en place d une plateforme virtualisée ajoute aux coûts d exploitation des coûts de licences logiciels. Cet intérêt est très simple : la mutualisation des ressources. Page 14

18 Il est en effet très rare (sous-dimensionnement mis à part) qu une architecture soit à 100% de ses capacités en permanence, la virtualisation offre une solution simple pour permettre aux entreprises de dimensionner leur infrastructure au juste niveau (niveau déterminable via une étude fonctionnelle du besoin moyen) tout en lui permettant de s auto-booster un court laps de temps (pour supporter les montées en charge). 2. Audit a. Définition De manière générale, un audit est un processus systématique, indépendant et documenté recueillant des informations objectives. Celles-ci serviront à déterminer le niveau de conformité des éléments du système audité par rapport aux exigences des référentiels du domaine concerné, déterminer l aptitude du système à atteindre des objectifs spécifiés et à donner à l audité la possibilité d améliorer son système. Il s'attache notamment à détecter les anomalies et les risques dans les organismes et secteurs d'activités qu'il examine. Dans le milieu informatique, un audit est une évaluation des risques et performances liés aux activités informatiques. Son but d'apporter une diminution de ces risques, une amélioration de ces performances et globalement de mieux maîtriser le système. b. Pourquoi auditer? i. La sécurité est un domaine d expert Un administrateur de base de données a toujours besoin de savoir ce qu il se passe dans la base de données qu il administre. Il doit s assurer de la disponibilité, de la confidentialité et de l intégrité des données stockées dans la base. Les audits de sécurité vont être généralement demandés pour vérifier la conformité de la base de données aux politiques de sécurité de l entreprise, ainsi que leur sécurité (droits des comptes, les connexions qui échouent, les changements de mots de passes, etc.). Les audits sont aussi demandés pour surveiller l intégrité d une base. Les installations où sont hébergés les serveurs contenant les bases de données sont également soumis à des audits de conformité. Page 15

19 ii. Roue de Deming Ayant pour but de mettre en place un plan d amélioration afin de traiter les écarts et nonconformités, un audit doit être planifié et déroulé très rigoureusement. Afin d obtenir les meilleurs résultats, les audits se déroulent selon la méthode de PDCA (Plan Do Check Act), aussi représentée par la roue de Deming. La première étape du cycle, Plan (en français «Planifier»), consiste à préparer et planifier ce que l on va réaliser. Définir le cahier des charges (tâches à réaliser et leur coût), établir un planning (déterminer les dates de début et fin de réalisation). On en ressort l identification des vrais problèmes. Il reste à rechercher les causes racines et planifier la mise en œuvre des actions correctives. La seconde étape du cycle, Do (en français «Faire») est la construction, la réalisation de l'œuvre. Elle commence toujours par une phase de test. Exécuter le plan d action, déployer les ressources nécessaires et mettre en œuvre toutes les opérations correctives mentionnées dans le plan, toutes les solutions retenues. La troisième étape, Check (en français «Vérifier») consiste à contrôler que les ressources mises en œuvre dans l étape précédente (Do) et les résultats obtenus correspondent bien à ce qui a été prévu (Plan). Divers moyens de contrôle sont alors déployés (Tableau de bord : indicateurs de performance, etc.). Contrôler que les ressources mises en œuvre dans l étape précédente (Do) et les résultats obtenus correspondent bien à ce qui a été prévu (Plan). Enfin la dernière étape du cycle, Act (en français «Agir»), consiste à ajuster les écarts, rechercher des points d'améliorations. Ce qui amènera un nouveau projet à réaliser, donc une nouvelle planification à établir. Et ce sera le début d un nouveau cycle. Ajuster les écarts, vérifier que les solutions mises en place sont efficaces dans le temps, rechercher des points d'améliorations tant que le niveau attendu n'est pas atteint. c. Quoi auditer? Audit de structure : Montrer si la structure de la base est en adéquation avec les exigences fonctionnelles et particulièrement adaptée à l'usage qui en est fait (requêtes). On vérifiera en particulier que le modèle de données a été respectueux des règles de l'art : modélisation relationnelle (MCD, MLD), respect des formes normales, contraintes de domaine, schéma externe... et correspond à la nécessité de service. Page 16

20 Audit de la qualité des données : Vérifier que la base n'est pas polluée par de nombreuses données inutiles ou erronées. En particulier on vérifiera l'existence de contraintes telles que celles de domaine, intégrité référentielles, unicité, validation, format (notamment les formats normalisés de données)... Dans le cas d'absence de telles contraintes, des mesures par sondage devront être entreprises afin de remonter les anomalies. Audit de configuration et de performances : Vérifier si la configuration du serveur logique (SGBDR) et du serveur physique (hardware) est conforme aux exigences du service des données : en particulier RAM, disques, processeurs, paramétrages à tous niveau. Cela nécessite de tracer l'activité du serveur sur divers plans techniques puis d'analyser les données recueillies à l'aide de différentes méthodes et moyens qui peuvent faire l'objet de plusieurs passes successives pour affinement. Audit des requêtes clientes : Vérifier le style de développement adopté (requêtes adhoc, emploi de procédures stockées, mapping relationnel objet...), la qualité de l'écriture des requêtes et l'indexation des tables. On procède à l'aide de différentes techniques en fonction de la façon dont est écrit le programme applicatif, techniques qui peuvent être combinées (analyse d'échantillon, traçage de l'activité du moteur SQL, revue de code...). Cela nécessite une bonne connaissance de l'optimisation et du fonctionnement du moteur de requête et du moteur de stockage. Par exemple, on débusquera par "écrémage" les 20% de requêtes qui consomment 80% des ressources (loi de Pareto) et on s'appliquera à en diminuer drastiquement le coût, par exemple par récriture, indexation, voir refactoring du modèle. A ce stade, on pourra aussi rechercher les problèmes potentiels liés à la sécurité : configuration des comptes d'accès, mise en place des privilèges sur les objets, utilisation de procédure accédant à des ressources externes, injection de code... et en donner les remèdes. Audit d'infrastructure réseau : Vérifier ce qui se passe entre les serveurs et les "clients". Ces clients pouvant être d'autres serveurs (Web, objet...) ou des clients applicatifs finaux. Il faut mesurer les temps de réponse effectifs (trames) et ressentis (utilisateur). La technique, pour ce faire, consiste à analyser les trames réseau pour en connaître la volumétrie et chronométrer les allers-retours des IHM. Pour une volumétrie anormale de trames, on en déduira quelles sont les commandes à l'origine et comment on peut agir dessus. Pour un temps de réponse IHM trop important, il faudra déterminer quel élément dans la boucle est à l'origine de la consommation anormale des temps de réponse. L'inconvénient de cet audit, somme toute assez rare, est qu'il nécessite des moyens matériels et logiciels coûteux et une analyse qui, compte tenu de la volumétrie et de la complexité des données recueillies, peut s'avérer assez chère. De nombreuses normes existent assistant la mise en place d un SMSI, cependant en fonction de la taille de votre société il est possible que vous n ayez pas le budget pour les mettre en place, néanmoins certains conseils simples peuvent sensiblement complexifier la tâche des attaquant et donc la sécurité de vos données. C est en gardant ceci en tête que nous vous avons décrit les solutions adaptées aux petites (checklist) et moyennes entreprises (checklist et audit) tout en abordant les solutions adaptées aux grandes et très grandes entreprises (datacenter avec architecture sécurisée et audit). Page 17

21 La suite de ce rapport sera consacré aux solutions techniques des éditeurs de SGBD basées sur de la cryptographie et assurant donc l intégrité et la confidentialité des données. Page 18

22 VII. Cryptographie appliquée aux bases de données 1. Confidentialité La confidentialité sert à prévenir les fuites d information. Or, celle-ci ne doit surtout pas «trop nuire» à la rapidité de fonctionnement de la base de données. Pour cela, la méthode la plus sûre reste le chiffrement. Mais cette technique regroupe un nombre d'algorithmes élevé, et parfois susceptible de contenir des vulnérabilités. De plus, chiffrer garanti une bonne sécurité, mais faut-il encore savoir à quel niveau il faut le faire et comment. Il est possible de chiffrer les données sur 3 niveaux : Couche stockage Avantage : Transparent pour le SGBD et l'applicatif, ainsi que sécurisé pour les données aux repos. Inconvénient : ce n'est pas lié aux droits d'accès, et il y a des baisses de performances énormes. Couche SGBD Avantage : Transparent pour le SGBD et l'applicatif, possibilité de faire chiffrer selon les privilèges utilisateurs, ou en fonction de la sensibilité des données. Inconvénient : problèmes de mécanismes internes au SGBD comme l'authenticité, impossibilité d'indexer les données, et donc probables problèmes de performance. Page 19

23 Couche application Avantage : Résiste aux attaques internes Inconvénient : Rien n'est transparent (le client gère le chiffrement/déchiffrement), il peut y avoir des attaques sur les droits d'accès (les données et les clés sont en claires sur le client), il y a une dégradation importante des performances (l'application fait quasiment tout) Parmi toutes ces possibilités, la plus viable en entreprise, bien que lourde, reste le chiffrement au niveau de la couche SGBD. a. Chiffrement du côté serveur i. Principe Le principe fondamental du chiffrement du côté serveur est que celui-ci est responsable du chiffrement, déchiffrement et hachage de toutes les données présentes sur celui-ci. Celles-ci seront chiffrées de manière asymétrique via des clés qui sont hébergées et délivrées par le serveur. Ainsi, en fonction de qui fait la requête, il sera capable de déchiffrer la/les donné(es) lors de l'évaluation de la requête. Bien évidemment, le niveau de protection des données n'excède pas celui des clés stockées sur le serveur. Par contre, pour pousser le vice au plus loin, Oracle propose de chiffrer ces clés via une master key qui est elle-même chiffrée avec un mot de passe. Ici, la principale faiblesse réside donc dans une attaque via le compte Administrateur, qui a, par définition, tous les droits sur la base de données. Il peut donc récupérer ce qu il veut sur la base de données tout en effaçant ses traces. ii. Gestion des clés Le but d'instaurer un gestionnaire de clés est avant tout de réduire au maximum l exposition des clés, tout en atténuant les droits de l administrateur de la base de données. Pour cela, il existe deux possibilités : Ajout d un dispositif sécurisé (Hardware Security Module) Un module matériel de sécurité est un appareil considéré comme inviolable offrant des fonctions cryptographiques. Il s'agit d'un matériel électronique offrant un service de sécurité qui consiste à générer, stocker et protéger des clefs cryptographiques. Page 20

24 L'intérêt de ce type de module est qu il est, par définition considéré comme inviolable. Et même s il devenait faillible, les clés stockées sur ce module sont chiffrées par une clé Master, les rendant inutilisables. Enfin, les clés ne sont donc accessibles que lors de l'exécution d une requête. Bien évidemment, comme tous les algorithmes en cryptologie, il est obligatoire de posséder au moins, à un moment donné, la clé pour procéder à la vérification. La clé sera donc brièvement stockée en clair. (Dans la plupart des cas, elle se situe quelque part dans la mémoire). Il n est pas inutile de noter qu à ce stade, les informations transitent en clair. Ajout d un serveur de sécurité: Dans certain cas, par exemple lors d une attaque en interne (Administrateur et/ou Trojan), il est utile de rajouter un serveur de sécurité. Ce serveur est un simple serveur d approbation fonctionnant avec des clés. Cela implique donc d avoir un 2ème administrateur, ne s'occupant que de la base de données d approbation. De la sorte, même si l'administrateur de la base de données se fait corrompre, il lui est impossible d observer l empreinte de la base de données. Bien entendu, (comme son compatriote expliqué dans le point juste au dessus), ce type de chiffrement étant sur le serveur de base de données, les informations transitent également en clair. Ici, les clés circulent également en clair. Les solutions commerciales : TDE dans la solution Oracle, l authentification nécessaire à la lecture des données non chiffrées est faite par un fichier externe associé à la base, un Wallet Oracle. Page 21

25 TDE dans SQL Server 2008 R2 de Windows, le principe est le même. Le tout repose sur un chiffrement hiérarchique et une infrastructure de gestion des clés. Chaque couche chiffre la couche qui se trouve en dessous d'elle à l'aide d'une combinaison de certificats, de clés asymétriques et de clés symétriques. Ces clés (asymétriques et symétriques) peuvent être stockées hors du serveur dans un module de gestion de clés extensible (EKM, Extensible Key Management). Les données sont chiffrées à l'aide d'une clé symétrique, appelée la clé de chiffrement de base de données (DEK), stockée dans l'enregistrement de démarrage de base de données pour être disponible pendant la récupération. Cette clé est protégée à l'aide d'un certificat (ou une clé asymétrique protégée par un module EKM) qui est lui-même protégé par la clé principale de base de données de la base de données MASTER. Page 22

26 architecture globale du chiffrement TDE Ce chiffrement permet d éviter que des utilisateurs malveillants accèdent aux données Offline, c est à dire aux données stockées physiquement dans les fichiers en court-circuitant SQL. En effet, une simple commande Unix de base ('strings') suffit à voir des données ASCII en clair. (ce qui pour les CHAR et VARCHAR est très pratique.) Le second gros avantage est qu'il est complètement transparent pour la base de données et l'application client. DMBS Obfuscation ToolKit pour Oracle Protegrity Secure.Data IBM DB2 Data Encryption Expert (Similaire à Protegrity Secure.Data) Page 23