Votre base de données est-elle sécurisée ?
par mail
l'article
Longtemps la base de données est restée parfaitement à l'abri des regards au cœur de l'entreprise. Seuls quelques applications métier et les administrateurs y accédaient, avec parcimonie. Elle n'avait alors guère besoin d'être fortement sécurisée. Mais l'autarcie a vécu : l'avènement d'internet, des applications web, des portails et des serveurs d'applications a exposé du jour au lendemain les bases des entreprises au monde entier. “ Le client d'une banque en ligne accède en fait au mainframe et à la base de données de sa banque. Et tout ce qui se dresse entre lui et ces systèmes critiques, c'est une interface web. Développée par qui ? quand ? comment ? ” observe Shlomo Kramer, fondateur d'Imperva, un éditeur de solutions de sécurité pour les bases de données.
Ces bases doivent désormais être protégées contre les menaces extérieures (intrusion, altération ou déni de service depuis le frontal web ou le serveur d'applications) aussi bien qu'internes (vol ou destruction des données par des utilisateurs accrédités). Et, face à des contraintes réglementaires toujours plus présentes, elle doit également permettre l'audit de son activité de bout en bout. Pour ajouter à la difficulté, cet impératif de traçabilité est compromis par l'ouverture des bases. Ainsi, lorsqu'un collaborateur authentifié sur le portail web exploite une application métier, c'est souvent un serveur d'application mandataire qui exécute ses requêtes et qui apparaît donc dans les logs de la base de données. Il est alors difficile de lier une requête à un utilisateur particulier.
La sécurisation implique une approche à plusieurs niveaux : une bonne configuration du produit, une définition claire des tables afin d'identifier les données à protéger, et enfin une attribution des droits aux utilisateurs bien conçue. Ce n'est qu'ensuite que des mesures telles que le chiffrement ou le recours à des produits spécialisés seront envisagés. Sans omettre, bien entendu, les principes habituels d'application régulière des correctifs et de cloisonnement du réseau.
Une configuration la plus simple possible
“ Ce sont souvent à des développeurs que l'on demande d'installer la base de données ”, constate Robin Schumacher, responsable du développement produit de MySQL. Or on ne s'improvise pas administrateur lorsqu'il s'agit d'installer un logiciel aussi complexe. “ Une base se déploie avec le moins de voilure possible ”, rappelle Lionel Billon, chef de produit SQL chez Microsoft.
Mais il n'est pas toujours possible de réaliser une installation minimale. Ainsi, de nombreuses bases Oracle de production fonctionnent encore avec leurs schémas et comptes par défaut : avant la version 10g, Oracle installait automatiquement plusieurs centaines de ces comptes, certains avec des droits systèmes et des mots de passe connus par tous (dont le célèbre “ change_on_install ”), sans intervention possible de l'administrateur. Pour les bases en production, des scanners de vulnérabilités spécifiques aident à rechercher de tels comptes installés par défaut. Attention cependant aux dépendances existant sur ces comptes avant de les désactiver ou de changer le mot de passe !
L'authentification à la base de données peut être soit prise en charge par cette dernière, en stockant les empreintes des mots de passe dans une table d'utilisateurs, soit laissée à la charge du système d'exploitation sous-jacent. Microsoft SQL Server exploite ainsi l'authentification de Windows. Oracle, lui, utilise les comptes “ OPS$ ” avec la commande “ sqlplus ” pour transférer à la base l'authentification réalisée sur le système d'exploitation. Bien que très pratique, cette approche fait dépendre plus encore la sécurité de la base de celle de l'OS hôte. Elle peut également être source d'erreur lorsque la base devra migrer sur un nouveau système. Elle implique aussi probablement de désactiver l'authentification distante au système d'exploitation si aucun mécanisme d'authentification forte n'est en place. Il convient enfin de supprimer les codes d'exemple (binaires ou procédures stockées) installés par défaut et pour certains vulnérables : ils peuvent servir à un attaquant pour prendre le contrôle de la base de données ou du serveur hôte.
La clé d'une base plus sûre est une attribution fine des droits à ses utilisateurs. On peut distinguer cinq profils d'utilisateurs : le consommateur, qui consulte seulement les données ; l'utilisateur applicatif, qui met à jour les structures existantes ; le responsable, ayant la possibilité d'ajouter d'autres utilisateurs, par exemple ; le développeur, autorisé à créer des procédures stockées, des séquences, des tables, de nouvelles structures, etc. ; et l'administrateur de la base, doté de tous les droits.
L'attribution différenciée des droits d'accès
Parallèlement à ces profils peuvent être définis des groupes, soit hiérarchiques, soit métiers. Une étude des données stockées détermine quelles colonnes doivent être en accès restreint et quels groupes d'utilisateurs peuvent les consulter – le champ “ salaire ”, par exemple, peut être masqué à tous sauf au groupe “ managers ”. Ces deux approches (groupes et profils) sont gérées différemment par les SGBD du marché. Parfois même, pas du tout ! Pourtant, le principe de séparation des rôles et de droits minimums devrait être mis en œuvre systématiquement, dans les limites fonctionnelles de la base. Heureusement, en l'absence de support granulaire des autorisations, il est toujours possible d'utiliser des procédures stockées pour obtenir un résultat équivalent : “ Dans ce cas, les utilisateurs ne voient que les procédures stockées définies par l'administrateur et les résultats correspondants. Ils ne peuvent exécuter des commandes SQL directes ”, explique Robin Schumacher.
Protéger les données par chiffrement
L'utilisation du chiffrement est à double tranchant. La sécurité est certes largement accrue, notamment face au vol du disque dur, mais la gestion des clés de chiffrement rend l'approche complexe. Une solution intermédiaire est l'utilisation du chiffrement transparent des colonnes sensibles, lorsque la base de données le permet (c'est le cas d'Oracle et de MS-SQL Server dans sa version 2008). Les données seront protégées en cas de vol du disque, mais demeurent en clair pour tous les utilisateurs autorisés à accéder à la base. Avantage : c'est la base qui se charge de gérer la clé de chiffrement. La procédure est de fait simplifiée et il suffit d'une commande pour activer le chiffrement sur une colonne.
Renforcer le dispositif avec des solutions tierces
On trouve deux catégories d'outils dédiés à la sécurité des bases de données. Les scanners de vulnérabilité auditent la base pour détecter les comptes par défaut, les mots de passe faibles, la présence de binaires vulnérables, etc. Les outils de sécurité active protègent, eux, la base en temps réel : soit sous la forme d'une appliance qui intercepte le trafic destiné à la base, soit sous la forme d'un agent installé sur le serveur. Ces outils permettent également de journaliser les accès et l'utilisation de la base dans le cadre du respect des obligations légales. Les pare-feu applicatifs, bien que généralistes, peuvent aussi protéger les bases contre des attaques de type injection SQL (pollution des entrées utilisateurs afin de manipuler la requête SQL passée à la base depuis le frontal web). Tous ces outils doivent cependant être évalués en termes d'impact sur les performances (de la base elle-même dans le cas d'une solution à base d'agent, de latence du trafic dans le cas d'une appliance).
Les 7 vulnérabilités à prendre en compte
Attaque externe par excellence, l'injection SQL est perpétuée en modifiant la requête attendue par le système, voire en y greffant une autre de son choix.
Ces comptes sont créés à l'installation de la base. Ils peuvent permettre à un intrus de prendre pied sur le système avant de tenter d'exploiter d'autres vulnérabilités locales.
Si les utilisateurs disposent de plus de droits que nécessaire, ils peuvent accéder à des informations sensibles ou modifier la base de données de manière illégitime.
Le DBA (administrateur de bases de données) dispose de tous les droits et peut accéder à des informations confidentielles qui n'ont rien à voir avec ses tâches.
Les utilisateurs ne devraient interagir avec la base qu'à travers une application métier. Le non respect de ce principe augmente les risques d'exploitation de certaines vulnérabilités.
Les procédures stockées ou d'autres binaires de démonstration livrés avec la base peuvent souffrir de vulnérabilités et permettre de prendre la main sur le serveur.
Si le système d'exploitation hôte n'est pas sécurisé, un attaquant pourra s'en prendre aux fichiers de l'application du SGBD, contournant ainsi toutes les mesures de sécurité applicatives.
Un datawarehouse est aussi vulnérable
“ Une base de données classique est associée à un processus vertical, avec des utilisateurs connus, explique Jean-Marc Bonnet, architecte solutions chez Teradata France. Alors qu'un entrepôt de données est orienté multimétiers et multi-utilisateurs. ” Il est donc primordial de contingenter et de contrôler l'accès à cette base de données particulière. Par exemple, un opérateur téléphonique conservera des données dont ses équipes techniques ont besoin, mais que ses équipes marketing n'ont le droit de traiter qu'avec l'accord des clients. Cette démarche de contingentement repose sur une gestion de rôles et de profils, auxquels sont associés des droits d'accès sur les objets.
Une authentification forte des utilisateurs est possible, mais elle est rarement implémentée par défaut. La solution Teradata Warehouse 8.0 autorise, par exemple, le recours à des jetons et à des certificats, mais par le biais de développement d'interfaces spécifiques. Le chiffrement des sessions entre les applications clientes de l'entrepôt de données et le serveur est, lui, une fonction de base de ces produits.
5 solutions de sécurisation active
Le marché privilégie l'approche des suites intégrées d'outils. Les produits prennent en charge la traçabilité des accès, la protection des bases contre les attaques connues, la détection des vulnérabilités et parfois le renforcement du contrôle d'accès à la base. Certains associent un agent à une appliance, tandis que d'autres privilégient l'installation sur un serveur dédié avec des sondes logicielles sur les différentes bases de données à contrôler.
Vrai ou faux
Faux. Le pare-feu applicatif est en mesure de bloquer des attaques connues, telle une injection SQL. Mais il ne saura pas déterminer si une requête d'effacement est illégitime parce qu'issue d'un utilisateur censé uniquement consulter les informations de la base. Seule une bonne distribution des droits utilisateurs permet de se protéger d'un tel risque.
Faux. Les bases de données disposent de fonctions d'audit complexes, mais pas assez souvent activées, car leur impact sur la charge du serveur peut s'avérer important. L'audit propriétaire est plus complet : il permet de déceler les tentatives d'accès ratées, les accès à des tables ou colonnes protégées, etc. La fonction d'audit fin d'Oracle permet, par exemple, de consigner à la fois la requête, son résultat, ainsi que le terminal et le login de l'utilisateur qui l'a initiée. SQL Server dispose de fonctions équivalentes avec le “ profiler ”.
Faux. Le trafic entre le serveur d'applications ou le frontal web et la base de données peut être chiffré pour le protéger des interceptions. Les sauvegardes doivent aussi être gérées de manière sécurisée.
Vrai. En créant des vues correspondant à des besoins métiers spécifiques, l'administrateur isole les utilisateurs de la base de données. Le procédé est aussi applicable avec des procédures stockées.
