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

27 b. Chiffrement du côté client i. Principe Après l approche serveur, il a été mis en exergue que les principaux problèmes étaient dû au fait que les données (/clés) circulaient en clair. De plus, le fait de protéger la base de données de la sorte, diminue beaucoup ses performances. Il faut donc que le client gère les transmissions pour que les clés, ainsi que les données soient chiffrées entre le client et le serveur, le traitement s effectuant sur le client (ce qui n est pas du tout recommandé). Bien entendu, il est relativement évident de voir que cette seule approche comporte beaucoup de problèmes : par exemple, le client devra gérer les droits d'accès (ce qui n est pas ce qu il se fait de mieux), les données et les clés seront forcement en clair sur le client. On se pose dans un cadre de confiance, si les clients et le réseau ne sont pas considérés comme sûrs, il ne faut pas déployer cela. Tout cela doit être pris en compte dans le but de finalement déporter la majeure partie du traitement sur le client sans pour autant empiéter sur la sécurité du serveur. ii. Solutions Il semblait donc nécessaire de faire quelque chose pour palier ces gros problèmes. Pour ce faire (l indexation des données chiffrées et le traitement direct des données chiffrées s étant avéré être inutile ou irréalisable) il faut regarder du côté des chiffrements à propriétés particulières, nous allons en lister 3 types : Chiffrement préservant l'égalité : Oracle Database 11g (en 2007) Chiffrement préservant l ordre : Algorithme AKS (Agrawal-Kayal-Saxena publié en 2004) Chiffrement homomorphique : Les données sont envoyées chiffrées par le client vers le cloud. Les données sont ensuite l'objet d'un traitement (un calcul par exemple) qui va être effectué sur les données chiffrées, ce traitement générant un résultat. Ce résultat est luimême chiffré, donc incompréhensible pour le prestataire du cloud. Enfin le prestataire du cloud va retourner le résultat au client qui le déchiffrera pour obtenir le résultat final. On peut donc dire qu'avec le chiffrement homomorphique, le résultat du traitement est le même que si les données n'avaient pas été chiffrées. Avec le chiffrement homomorphique, les données ne sont jamais en clair lors de leur transmission ni lors de leur traitement. Par exemple : Chiffrement à comparaisons rapides (Tingjian Ge, Stan Zdonik 2007) Il permet de décider rapidement si deux données sont différentes. La comparaison de deux chiffrés part de l octet de poids fort, procède octet par octet de gauche à droite et s arrête dès qu une différence est rencontrée ; c est l «Early Stopping». Il reste de nombreux problèmes du point de vue cryptographique pour le chiffrement des bases de données. Par exemple, comment utiliser correctement un chiffrement à flots? Ou encore, comment chiffrer en gardant une structure permettant une recherche efficace? Et finalement, comment protéger l intégrité des données (CRSP/COMPUSTAT MERGED DATABASE)? Page 24

28 2. Intégrité a. Définitions Propriété assurant que des données n ont pas été modifiées ou détruites de façon non autorisée Garantie que le système et l information traitée ne sont modifiés que par une action volontaire et légitime L intégrité du système et de l information traitée garantit que ceux-ci ne sont modifiés que par une action volontaire et légitime. Lorsque l information est échangée, l intégrité s étend à l authentification du message, c est à dire à la garantie de son origine et de sa destination Le contrôle d intégrité consiste à s assurer que celle-ci est préservée afin de détecter et limiter les risques d erreur et de malveillance. b. Journalisation La journalisation de base de donnée est une partie importante pour la haute disponibilité d'une base de donnée, elle rend possible la restauration de la base de donnée en cas de défaillance de cette dernière. Les fichiers de journalisation enregistrent les modifications successives apportées à la base de données. Il existe deux types de journalisation qui fournissent un niveau de récupération différente : la journalisation circulaire et la journalisation d'archivage. La journalisation circulaire Les plus anciens enregistrements sont écrasés pour en stocker de nouveaux, au besoin. Cela évite de perdre les plus récentes informations dans un journal dont on limite le volume. Fonctionnement Page 25

29 La journalisation d'archivage Les logs d'archivage sont des fichiers qui ont été copiés depuis le répertoire contenant les active logs dans un autre endroit à des fins d archivage. Ce type de journalisation permet d effectuer une restauration en ligne, tout en enregistrant les activités de la base durant l opération. A l issue de la restauration, le fichier active log courant est fermé et archivé. Après redémarrage d une base de données suite à une panne, l utilisation des logs permet de rétablir la base de données à un état cohérent. Pour déterminer quels fichiers de log doivent être utilisés pour rétablir la base, on utilise les fichiers de contrôle qui contiennent les informations suivantes: Nom de la base de données Date et heure de création de la base L'emplacement des fichiers journaux Des informations de synchronisation c. Stockage Pour protéger une base de données, il faut définir son lieu de stockage et les règles de sécurité. La base de données est stockée sur des serveurs de l organisation. De leurs postes de travail, les utilisateurs consultent, mettent à jour le contenu de la base de données. De nombreux risques menacent les bases de données : Virus, panne de disque dur sur le serveur, mauvaise manipulation, vol, incendie peuvent entraîner la destruction des données. Il existe des méthodes (sauvegardes régulières), des matériels (Bandes Magnétiques, DVD ), des logiciels (antivirus) pour assurer leur sécurité et leur intégrité. L'application de l'intégrité des données garantit la qualité des données stockées dans la base. Par exemple, si un employé est défini avec un ID d'employé égal à 123, la base de données ne doit pas autoriser qu'un autre employé ait la même valeur d'id. Si une colonne employee_rating est destinée à accueillir des valeurs comprises entre 1 et 5, la base de données ne doit pas accepter de valeur en dehors de cette plage. Si la table contient une colonne dept_id qui stocke le numéro de service de l'employé, la base de données ne doit accepter que des valeurs correspondant bien aux identifiants de service de la société. Lors de la planification des tables, deux étapes importantes consistent d'une part à identifier les valeurs valides pour une colonne et d'autre part à décider de la façon d'appliquer l'intégrité des données dans cette colonne. L'intégrité des données se répartit entre les catégories suivantes : Intégrité d'entité Intégrité de domaine Intégrité référentielle Intégrité définie par l'utilisateur. Page 26

30 Intégrité d'entité L'intégrité d'entité définit un tuple comme étant une entité unique pour une table particulière. Elle garantit l'intégrité des colonnes d'identification ou de la clé primaire d'une table, par le biais d'index UNIQUE, de contraintes UNIQUE ou de contraintes PRIMARY KEY. Intégrité de domaine L'intégrité de domaine fait référence à la fourchette (au domaine) des entrées valides pour une colonne spécifique. Vous pouvez mettre en application l'intégrité de domaine pour restreindre le type à l'aide des types de données, le format, des contraintes CHECK et des règles, ou la fourchette des valeurs possibles, à l'aide des contraintes FOREIGN KEY et CHECK, des définitions DEFAULT et NOT NULL, et des règles. Intégrité référentielle L'intégrité référentielle préserve les relations définies entre les tables lors de l'insertion ou de la suppression tuples. C est une situation dans laquelle pour chaque information d'une table A qui fait référence à une information d'une table B, l'information référencée existe dans la table B. L'intégrité référentielle est un vecteur de cohérence du contenu de la base de données. Les systèmes de gestion de base de données (SGBD) permettent de déclarer des règles de maintien de l'intégrité référentielle (contrainte). Une fois la contrainte déclarée, le SGBD refusera toute modification du contenu de la base de données qui violerait la règle en question et casserait l'intégrité référentielle. Par exemple : on définira qu'un livre a un ou plusieurs auteurs. Une contrainte d'intégrité référentielle interdira l'effacement d'un auteur, tant que dans la base de données il existera au moins un livre se référant à cet auteur. Cette contrainte interdira également d'ajouter un livre si l'auteur n'est pas préalablement inscrit dans la base de données. Intégrité définie par l'utilisateur L'intégrité définie par l'utilisateur vous permet de définir des règles propres à l'entreprise, qui n'appartiennent à aucune des autres catégories d'intégrité. Toutes les catégories d'intégrité acceptent l'intégrité définie par l'utilisateur. Cela englobe toutes les contraintes au niveau de la colonne ou de la table dans CREATE TABLE, les procédures stockées et les déclencheurs. d. Sauvegarde Les sauvegardes complètes peuvent être stockées sur un support de sauvegarde, et ainsi être mises à l abri en cas de problème physique sur la base de donnée (incendie, inondation) préservant ainsi l intégrité des données. Ces sauvegardes peuvent être effectuées sans mettre la base de données hors ligne, seulement elles consomment une grande quantité de ressource du système et peuvent augmenter le temps de réponse de la base de données. Pour compenser ce problème, il existe les sauvegardes différentielles. Elles utilisent le même mécanisme que les sauvegardes complètes à la différence qu elles ne copient que les données modifiées depuis la dernière sauvegarde complète. Ce système de sauvegarde consomme moins de ressource et a donc un impact moindre sur les performances de la base de données. Page 27

31 Les sauvegardes différentielles seules sont inutiles en cas de panne de la base de données. Le mécanisme de restauration consiste donc à utiliser la dernière sauvegarde complète, puis à appliquer les modifications des sauvegardes différentielles pour revenir à l état sauvegardé le plus récent. Le support de sauvegarde utilisé par 90% des entreprises est la bande magnétique. Les formats modernes offrent une capacité pouvant atteindre 3 téraoctets, ce qui en fait des solutions économiquement concurrentielles sur le marché du stockage portable. Quelle que soit leur capacité ou leur vitesse de traitement, les sauvegardes sur bandes permettent avant tout de sortir les sauvegardes des bureaux de la société et donc de pouvoir récupérer les Données suite à un sinistre. Leur mode de fonctionnement intègre une gestion des erreurs et elles sont en ce sens nettement plus fiables que les disques durs. Leur durée de vie est par contre plus limitée et le lecteur nécessite un nettoyage régulier. Un nettoyage mensuel est idéal, un nettoyage trimestriel peut faire l affaire. Au-delà, le nombre d erreurs de lecture/écriture ne peut qu aller en augmentant. Le problème lié aux bandes est que la rotation de celles-ci nécessite une certaine rigueur de façon à ce que la sauvegarde soit efficace. Il est important de noter les points suivants concernant la capacité et la vitesse des bandes: Deux valeurs sont annoncées : capacité native et capacité après compression. La seconde n est qu une estimation, souvent très optimiste. Si le débit des données est insuffisant, le lecteur doit régulièrement recaler la bande et inscrire des marqueurs. La conséquence est une perte d espace disponible sur la bande. On peut donc potentiellement se retrouver avec une bande d une capacité finalement inférieure à sa capacité native. Quel que soit le format, la sauvegarde est beaucoup plus rapide avec de gros fichiers qu avec de petits. Ces lecteurs, au format SCSI ou Fiber Channel, se branchent comme un disque dur. Tous les lecteurs d une même gamme sont compatibles de manière ascendante sur 3 générations, au moins pour ce qui concerne la relecture des bandes, et 2 pour l écriture. Le format LTO est le leader du marché des bandes. Ce média a une durée de vie estimée à 30 ans et chargements/déchargements, et un temps de positionnement moyen de 75 secondes. Ce format propose également un mode WORM (Write Once Read Many) depuis quelques années, ainsi que le chiffrement physique de la bande. Les entreprises doivent se prémunir contre tout ce qui peut nuire à leurs données, qu il s agisse de la perte d un bagage, de la vengeance d un employé mécontent ou simplement d une tasse de café à l équilibre instable. A cet égard, la bande magnétique offre une grande capacité de survie. En combinant ses atouts avec un stockage professionnel, les entreprises ont l assurance que les informations qu elle renferme restent exploitables pour longtemps. Page 28

32 3. Authenticité L authenticité, soit la non-répudiation, est très importante dans des cadres juridiques/postmortem afin de pouvoir entamer des procédures, mais également dans la détection d anomalies (trop de requêtes d un utilisateur vers une ressource qui lui est interdite par exemple). L authenticité ne peut être validée que si un processus d IAM/Gestion des Identités et des Accès est en place. Les certificats permettent la non-répudiation, mais dans le cadre des bases de données, nous nous concentrerons sur les solutions de journalisation/enregistrement des journaux, puisque les droits et la structure des BDD apportent une séparation des rôles et des données accédées, via un cloisonnement, et permettent aux journaux d être plus légers. Sur le marché, nous pouvons voir quelques exemples de solutions logicielles complètes, voici l exemple d Oracle : Oracle Audit Vault consolide les données d'audit en provenance de plusieurs serveurs afin d'assurer un suivi de l'activité des utilisateurs, et génère des rapports et des alertes en cas d'activité suspecte Oracle Total Recall établit un historique des modifications apportées aux données sensibles Oracle Database Vault permet de contrôler les accès des administrateurs et autres utilisateurs disposant de privilèges, tout en contrôlant en temps réel l'activité de la base de données Oracle Label Security offre un contrôle d'accès basé sur la classification des données a. Journalisation La journalisation est utilisée de deux façons, la première à été décrite précédemment, et c est sa fonction principale : permettre de rejouer les actions en cas de problème sur le SGBD ou la machine. La deuxième fonction, beaucoup moins utilisée avant l apparition du besoin de sécurité, consiste à enregistrer la requête ET un identifiant unique. Bien que cela soit la même opération dans les deux cas, la deuxième fonction interprète la forme de la requête, et non son fond (on regarde simplement qui accède à quoi sans effectuer le traitement demandé). La journalisation ne fait qu enregistrer mais, une fois associée aux processus d authentification, il devient possible de détecter des anomalies et remonter des alertes lorsqu elles sont trop fréquentes. Dans les SGBD dédiés à des fortes charges/utilisations, les journaux (logs) ne sont pas immédiatement inscrits sur les supports de stockage. Ceux-ci sont conservés en mémoire vive afin d être plus rapide d accès en cas d annulation d une transaction ou de modification d une donnée précédemment écrite. Les journaux contiennent donc un numéro de transaction et l opération effectuée. Stocker l identité qui a effectué la requête peut facilement consommer beaucoup plus de mémoire, il faut donc prévoir en amont du projet quels seront les besoins de sécurité afin de prévoir une configuration correcte, et éviter de devoir refaire une phase d optimisation après ajout des logiciels de traitement de l authenticité. Page 29

33 L utilisation de la journalisation dans le cadre de l authenticité est à la fois facile à mettre en place et lourde à utiliser. En effet, il suffit d utiliser les API disponibles pour retrouver les transactions anormales ou de certains utilisateurs, mais ce processus peut être très coûteux en temps CPU et attente I/O, ce qui ne convient pas au type de facturation effectué sur la plupart des SGBD commerciaux. C est pour cela que des solutions sont proposées en plus des SGBD : dédier des logiciels au monitoring et à l analyse de journaux, ceci permettant d'analyser les logs et donc de faire remonter les alertes de notre choix sans pour autant toucher son workflow et donc en optimisant les couts des licences du SGBD. La journalisation ne doit pas non plus s effectuer qu au niveau du SGBD. Bien que le SGBD enregistre toutes les requêtes et les identifiants uniques, ces identifiants peuvent n appartenir qu à des applicatifs, et non aux utilisateurs ayant fait une action entraînant la requête (de façon similaire à un proxy). La journalisation doit s effectuer sur toute la chaîne d applicatifs et être très détaillée (ce qui implique la nécessité de préparer en amont les stockages dynamique et statique nécessaires sur toute la chaîne, ce qui peut entraîner une augmentation de coûts). b. Droits et Structure de la BDD Pour bien séparer les bases de données à buts différents (paye interne, portefeuilles clients, transactions financières, ventes, etc.), il est évident qu il faut séparer les accès à chacune d entre elle. L IAM intervient également à ce moment : lors du design de l ensemble des BDD, il est important de bien séparer les rôles de chaque entité, et petit à petit décrire combien de BDD seront nécessaires, et qui aura accès à quoi. Une bonne structuration en amont facilite grandement la gestion de la sécurité notamment en forçant les utilisateurs, développeurs et administrateurs à respecter ce design. Lorsqu il n y a aucune solution en place, et que l on souhaite construire plusieurs BDD à usages multiples, ce design sécurisé est très facile à concevoir puis à mettre en place. Les difficultés apparaissent lorsqu une petite solution existe déjà, ou que de multiples solutions existent et doivent cohabiter. Cette structuration permet la séparation des données d un point de vue base de données, cependant, sans exploiter les droits d accès, le cloisonnement n existera pas. Cette notion est assez évidente de nos jours, mais selon les besoins et machines sur lesquelles des solutions ont été déployées, il n est pas impossible de voir que tous les applicatifs utilisent la même identité pour s authentifier. Il est impératif de donner à chaque applicatif des droits très précis et restreints aux seuls usages pour lesquels il a été conçu. Si plusieurs applicatifs sont utilisés pour une même tâche, une organisation dans les identifiants uniques, ou simplement sur les logins, est très conseillée. Une IAM bien réfléchie et déployée est nécessaire pour effectuer cela. 4. Limites et Améliorations du Matériel a. Améliorations du Matériel Il existe de plus en plus de matériel permettant de faciliter les calculs de cryptographie. Plusieurs normes et certifications existent et sont nécessaires pour que le matériel soit utilisable dans des milieux sensibles. Le matériel classique est la carte à puce, ce dispositif est suffisamment sécurisé physiquement pour que personne ne puisse en extraire les données stockées. Si la puce venait à être ouverte, des dispositifs matériels sont prévus pour que les données s autodétruisent ou deviennent Page 30

34 illisibles. Seul un des ingénieurs ayant conçus ce dispositif, avec des moyens techniques coûtant plusieurs millions, a réussi à extraire une clé privée d une ancienne version des cartes à puces. Aujourd hui, il est admis que les moyens nécessaires pour refaire cette action avec les nouvelles normes sont à la limite de ce que la technologie humaine permet. Aucun système de sécurité n égale la carte à puce. Seuls 5 fondeurs sont autorisés et capables de fondre des puces dans le monde. Le principal défaut des cartes à puce, dans le cadre des Bases de Données, et que celles-ci sont beaucoup plus lentes pour effectuer les opérations de chiffrement. En effet, ce matériel a été conçu pour stocker de façon sécurisée les clés, mais pas pour les utiliser de façon continue. Des périphériques physiquement moins sécurisés, mais beaucoup plus performants existent. Il est même à noter que plusieurs gammes de produits sont disponibles, et ceux-ci respectent le même rapport : peu de sécurité ou résistance, avec chiffrement des données extrêmement rapide, ou opérations plus complexes possibles, mais ralentissement du temps de chiffrement. Chez IBM, il existe par exemple pour System i (AS/400) la 2058 Cryptographic Accelerator ou le 4758 Cryptographic Coprocessor. La 2058 est une carte permettant d alléger les calculs faits dans les processeurs classiques, en effectuant les opérations cryptographiques sur son propre système. Cependant, contrairement au 4758, celle-ci ne stocke pas les clés en interne, et est limitée à des opérations de hachage ou de cryptographie faible. Le matériel est également très bien préparé : on peut aligner jusqu à 32 de ces cartes afin de paralléliser plusieurs opérations cryptographiques. Les opérations étant généralement longues, les paralléliser est donc un réel bénéfice dans certains cas. De plus, dans la littérature IBM, les Coprocessors sont des cartes contenant un CPU et de la mémoire, le tout effectuant des calculs de façon classique (opération par opération en faisant cheminer les résultats intermédiaires en mémoire) mais légèrement optimisée, à l inverse, le matériel dit Accelerator est en réalité une fonction de chiffrement gravée dans une puce prenant sur ses bus directement les flots de données à traiter. Les systèmes IBM étant surtout dans le monde bancaire, soumis aux plus fortes restrictions avec les militaires, il est intéressant de noter que ces cartes restent compatibles même si obsolètes (l obsolescence des Accelerators se comprend tout à fait, mais moins celui des Coprocessors. Cette raison fait que les Accelerators seuls ne sont plus fabriquées, et on leur préfère des cartes à double usage). De plus, des extensions sont ajoutées afin que les nouvelles applications Java puissent également tirer profit de ces cartes d extension. En pratique, les cartes proposent différents services : générateurs de nombres aléatoires, hachage (SHA1,...), MAC, chiffrement symétrique (DES, Triple-DES,...), chiffrement asymétrique (RSA, ), génération de clés par courbes elliptiques, etc... Toujours chez IBM, la RAIM (Redundant Array of Independent Memory) a été introduite en juin Cette technologie n est autre que l application du RAID des Disques sur la Mémoire vive. Des algorithmes similaires sont utilisés et permettent ainsi que des modules physiques soient détériorés SANS altérer la donnée. Cela permet de dépasser les protections proposées par la parité de mémoire ou l ECC, qui ne protègent pas de toutes les erreurs mémoire. Grâce à la RAIM, on peut monter jusqu à la perte de quelques barrettes complètes, sans que la donnée soit altérée! Page 31

35 b. Limites du Matériel Bien que le matériel soit une source efficace et sûre de chiffrement, celui-ci est limité. Dans le cadre de la carte à puce pour un SGBD, la véritable barrière est la vitesse de chiffrement. Dans le cadre des cartes accélératrices, nous avons déjà vu que les cartes de type Accelerators deviennent automatiquement et immédiatement obsolètes, des qu un avis de changement d algorithme est imposé par les normes, ce qui oblige un changement de matériel, entraînant un arrêt des machines et applicatifs (dans notre cas du SGBD, qui peut mettre jusqu à plusieurs heures à redémarrer). Un matériel ne fonctionne pas tout seul, il ne fait qu apporter un service très optimisé aux applications. Pour s en servir, l application a besoin d une couche d abstraction. On identifie donc 2 sources softwares de possibles problèmes. Et en effet, l université de Cambridge a réussi à détourner l utilisation de la carte 4758 : les cartes ne proposant que des services très simples (lire un choix d algorithme, puis lire un flot de bits à traiter, et sortir le résultat), celles-ci ne sont pas complexes, cependant, les API associées peuvent subir un défaut de conception, et les applications encore plus! C est ce que l université a exploité en démontrant qu il était possible de demander d effectuer des calculs entraînant l extraction de la clé privée depuis l API. De plus, il ne faut pas oublier que le matériel est sensible à sa condition physique. Ne pas le protéger ne fera qu augmenter les risques de détérioration, vol, etc... Il faut à la fois l encadrer correctement par le haut et par le bas car il est la première brique du traitement de la donnée. Un design correct d OS/pilote, puis d application, associée à un bon entretien et une protection adéquate des cartes, permettra un usage plus long dans le temps. Les SGBD étant les applications utilisant tout le matériel classique disponible (CPU, mémoire, réseau, stockage physique), lui ajouter un composant plutôt lent au niveau du réseau ou du stockage physique ne fera que réduire ses performances, ce qui est contraire à leur usage. La cryptographie matérielle est une chance de réduire le temps de calcul software, mais elle est limitée par l usage et l entretien qu on lui porte. Page 32

36 VIII. Analyse de cette situation Comme nous avons essayé de vous le faire sentir tout au long de ce rapport, les bases de données sont de nos jours indispensables pour les systèmes d'informations et indirectement pour les business que ces systèmes supportent. En effet, ayant révolutionné la façon dont les données sont stockées, elles sont de nos jours présentes dans absolument tous les systèmes d'informations (de celui de la petite startup à la très grande entreprise) et ce, sous différentes formes (serveurs applicatifs, serveurs dédiés, instances voire même intégration au sein même d'une application métier, etc...). Ces différentes formes de stockages de données confidentielles offrent d'autant plus de potentielles portes ouvertes aux attaquants, dans le contexte actuel il semble donc nécessaire de sécuriser ces données. Pour ce faire il y a bien évidemment des procédés techniques à mettre en place (notamment des procédés techniques basés sur la cryptographie assurant la confidentialité et l'intégrité des données stockées) mais ces derniers ne couvrent pas pour autant tous les besoins des entreprises modernes (notamment en terme de disponibilité) c'est de l'association entre ce constat et notre envie de vous présenter les différents pendants de la sécurité informatique qu'est né notre envie de présenter dans ce rapport des solutions de sécurisation physique ainsi qu'organisationnelles. Néanmoins l'actualité récente nous a appris que faire confiance aveuglément à des solutions basée sur de la cryptographie pourrait avoir des conséquences désastreuses si une faille est découverte (BEAST). Ceci, ajouté à la complexité de la sécurité informatique (et une nouvelle fois particulièrement la cryptographie), et des différentes normes et bonnes pratiques appliquées dans les très grandes entreprises impliquent la nécessité de commander des audits et des tests d intrusions réguliers sur son système d information (et donc dans notre cas plus spécifiquement sur les bases de données). En effet c'est seulement par le moyen de tests dits "boîte noir" que les responsables de la sécurité des systèmes d'information pourront espérer avoir une vision des faiblesses de leurs infrastructures et ainsi pouvoir travailler à les combler. Il va sans dire que les problématiques de sécurisation (confidentialité, intégrité, disponibilité) des données auront plus de difficultés à recevoir un public dans les petites et moyennes entreprises, notamment dans certains secteurs d'activités, néanmoins il est important de comprendre que de nos jours chaque entreprise a des informations dites "noires" (que ça soit des brevets, des mots de passes, des données bancaires/médicales/clients, des clefs privées ou tout autre type d'informations) devant rester confidentielles que cela soit pour des raisons de survie financière de l'entreprise ou encore pour obligations légales. Nous avons également décidé d octroyer une place relativement importante aux différents scénarios d attaques et surtout à leurs impacts potentiels. Ce choix provient d'un constat simple - il est de notre devoir en tant que professionnels de la sécurité informatique de faire comprendre à nos entreprises ou à nos clients les enjeux et les impacts des risques encourus - dit plus simplement il est important de sentir les enjeux pour pouvoir les communiquer à nos supérieur afin de leur faire comprendre les impacts métiers que peuvent avoir des problèmes informatique (atteintes à la Page 33

37 continuité d'activité, problème d'intégrité ou rupture de la confidentialité des données dues à une attaque). Page 34

38 IX. Solutions disponibles sur le marché Dans cette partie, nous allons vous présenter une liste non exhaustive des solutions apportées par les 3 principaux leaders de ce marché. 1. IBM MainFrame IBM z10 : Crypto Express3, carte d extension PCI-Express : achat de 2 au minimum, jusqu à 16 par machine Crypto-Express3-1P, carte d extension PCI-Express servant de Coprocessor ou d Accelerator Cartes d Extension IBM de chiffrement : IBM PCIe Cryptographic Coprocessor : au format PCI-express, plusieurs dénominations en fonction du système visé (Crypto Express3 pour du system z, IBM 4765 PCIe Cryptographic Coprocessor pour IBM AIX et IBM i (Power6 et 7), pour system x, on obtient un composant fait pour la solution system z) IBM 4764 PCI-X Cryptographic Coprocessor : format unique PCI-X 1.0 compatible PCI 2.2, également disponible pour plusieurs systèmes sous différents formats (des cartes PCI-X ou une solution Crypto Express2 pour system z, les systems i et p (AS/400 et PowerPC) disposent de la carte en option, les system x sont tous compatibles tant que l OS a des pilotes disponibles) Solutions IBM pour DB2 : DB2 Multiplatform Tools, solution proposant plusieurs logiciels à ajouter à DB2 Les produits suivants sont disponibles seuls ou en un pack : DB2 Data Archive Expert : améliore les performances de DB2, compresse/réduit le stockage nécessaire, et facilite l administration DB2 High Performance Unload : meilleures performances, + d options d extraction des sauvegardes DB2, fonctions de répartitions des données, formats de sorties multiples DB2 Performance Expert : meilleur monitoring des performances, + d alertes avec les goulots d étranglement, anticipation de problèmes de performance, simplification de tâches DB2 Recovery Expert : fonctions de sauvegardes rapides, automatisation de certaines tâches de commit/rollback, meilleure reprise d activité, analyse de certains journaux améliorée DB2 Test Database Generator : permet de masquer certaines données tout en permettant de les manipuler via des groupes Produits vendus seuls : DB2 Change Management Expert : fonctions de recherche pour meilleure compréhension des relations pour les DBA DB2 Table Editor : permet d accéder à des données sur d autres plateformes DB2 et Informix Page 35

39 DB2 Web Query Tool : interface pour faciliter la connexion des utilisateurs au DB2 et à Informix IBM Database Encryption Expert : chiffrement des données; disponibles pour Linux, UNIX et Windows DB2 Audit Management Expert : vérification sélective des sélections, mises à jour, suppressions et lectures pour répondre à diverses exigences Toutes les fonctions offertes par les outils DB2 sont également disponibles pour IMS (SGBDH) sur z/os. On trouve également quelques outils similaires pour IBM Informix Dynamic Server, un SGBD Orienté Objet. 2. Oracle Solutions Logicielle Oracle pour le SGBD Oracle 11g de Défense en Profondeur Monitoring : Oracle Configuration Manager : vérifications des paramètres de sécurité de la BDD et du système de fichiers Oracle Audit Vault : consolidation des logs pour générer des rapports d alertes en cas d actions suspectes Oracle Total Recall : historique des modifications des informations sensibles Access Control : Oracle Label Security : contrôle d accès en fonction de la classification des données Oracle Database Vault : contrôle des accès des utilisateurs de privilégiés et contrôle de l activité de la BDD Encryption and Masking : Oracle Advanced Security : chiffrement des données en transit et stockées Oracle Secure Backup : sauvegarde chiffrée de la BDD et du système de fichiers sur bande Oracle Data Masking : transfert des données vers les environnements de test et les partenaires en supprimant les données d identification 3. Microsoft SQL Server Microsoft SQL Server inclut déjà différents services avec des options de sécurité et d intégrité. Leur utilisation se fait en fonction de la licence SQL Server choisie (à négocier lors de l achat). Les nouvelles versions de SQL Server intègrent de base des options très utilisées dans le passé. Microsoft communique peu sur les produits de sécurité, cependant, ils affichent dans leurs messages marketing une composante sécurité très forte : Aucune faille de sécurité entre 2009 et 2010 en envoyant sur le site du NIST (National Institute of Standards and Technology). La documentation de SQL Server explique comment sécuriser chaque élément de la solution. Page 36

40 4. Magic Quadrant Voici un Magic Quadrant de janvier 2011 afin de se faire une idée des entreprises qui composent ce marché. Page 37

41 X. Conclusion Après avoir fait un bref rappel historique sur les bases de données, avoir parlé d authenticité, de confidentialité et d'intégrité, avoir vu les différentes attaques et leurs parades aussi bien d un point de vu technique qu organisationnel, on s'aperçoit que sécuriser les bases de données est une préoccupation majeur dans les DSI. Pour se prémunir de ces attaques, les grandes entreprises respectent de plus en plus les normes et les bonnes pratiques liées à la sécurité informatique. Elles sont aussi amenées à faire appel à des spécialistes (par le biais d audits) pour vérifier leurs pratiques en matière de sécurité informatique. Il est à noter que négliger la sécurité est bien trop souvent dramatique. En effet, l'omniprésence de l informatique dans les entreprises implique que l ensemble des informations sensibles soit contenue dans des bases de données ou tout du moins dans un serveur ou ordinateur relié au réseau et donc qu elles soient potentiellement piratables. Tous les indicateurs tendent à prouver que dans un futur proche les tentatives d attaques seront de plus en plus communes et de ce fait, il faut donc rappeler l importance d effectuer, en plus de toutes les mesures techniques, une prévention auprès des utilisateurs, particulièrement ceux amenés à manipuler des données sensibles. Si on forge une requête on peut détourner la requête initiale afin d'exécuter le code de notre choix. Page 38

42 XI. Bibliographie/Webographie & remerciement Attaque sur carte cryptographique IBM de l université de cambridge Produits du marché : Bibliographie La doc Oracle La doc DB2 La doc Crypto Express3 La doc de l ISACA Webographie % ENUS Page 39

43 Remerciement Monsieur Sébastien BOMBAL (security and infrastructure services lines director chez AREVA) Monsieur Cyrille Barthelemy (Head of Security Services Unit chez INTRINsec) Madame Alexandra CHAMPAVERT (Consultante Indépendante, Expertise SGBDR, anciennement DBA chez Oracle) Madame Cécile BENHAMOU (IBM - Technical Sales DB2 z/os + Tools DB2) Les différents intervenants de Solucom nous ayant fournis un cours sur les datacenters : Monsieur Laurent Ortunio (Consultant Sénior) Monsieur Julien Contal (Responsable de Département) Monsieur Florian Carriere (Responsable de la Business Line PCA) Page 40