Joshua Resnick - Fotolia

Introduction aux outils de sécurité pour bases de données

L’expert Adrian Lane explique pourquoi les outils de sécurité des bases de données jouent un rôle important, sinon crucial, dans la protection des données.

On peut penser que la sécurité des bases de données relève du domaine des éditeurs de systèmes de gestion de bases de données relationnelles (SGBDR). Ils sont experts dans leurs plateformes et devraient, théoriquement, être la source vers laquelle se tourner pour trouver des produits de protection des bases de données. Mais en fait, ces éditeurs ne fournissent qu’une partie de la réponse au sujet.

Certaines capacités de sécurité critiques sont intégrées aux plateformes de SGBDR : gestion d’identités, contrôle d’accès, ou encore chiffrement des communications réseau. Mais cela laisse de côté de nombreux services de sécurité tout aussi critiques, comme la surveillance des activités des utilisateurs, la protection contre les injections SQL, ou encore la recherche de vulnérabilités. Et dans certains cas, les fonctionnalités fournies nativement ne sont tout simplement pas appropriées. Par exemple, les traces d’audit générées par les bases de données pèchent souvent par l’absence d’informations nécessaires aux rapports de conformité. Sans compter avec des fonctions de chiffrement souvent trop lentes et trop difficiles à intégrer.

Et les manques s’avèrent encore plus importants lorsque l’on prend en compte les besoins spécifiques de l’entreprise : celle-ci a souvent besoin de protection pour plus d’un seul type de base de données. Les produits mono-plateforme ne s’avèrent généralement pas adaptés aux besoins d’entreprises stockant des informations sensibles dans plusieurs types de bases de données. De fait, la plupart des entreprises utilisent des bases de données Oracle aux côtés de bases Postgres et MySQL, DB2, Sybase ou encore SQL Server, chacune servant des fonctions métiers spécifiques et critiques.

Surtout, les exigences réglementaires se concentrent généralement sur la protection des données, pas de l’infrastructure. Et la sécurité des données va au-delà de la protection de leur contenant. La manière dont les données sont utilisées et dans quelles circonstances est une question qui n’est pas traitée par les systèmes de contrôle des accès des bases de données.

Pour toutes ces raisons, les outils de sécurité des bases de données jouent un rôle important, sinon essentiel, dans la protection des données de l’entreprise au sein de son centre de calcul.

Surveiller les activités

Le composant le plus important est là celui qui assure la surveillance des activités. On parle de plateforme de database activity monitoring (DAM). Ces DAM capturent toutes les activités SQL de la base de données, jusqu’aux actions d’administration, et analysent les requêtes à la recherche de comportements, de contextes, susceptibles de trahir des usages inappropriés. Ces outils peuvent détecter et alerter d’un vaste éventail de menaces. Ils peuvent même bloquer certaines requêtes – même si peu d’organisations utilisent ces capacités.

La plupart des organisations déploient des DAM non seulement pour leurs capacités de détection, mais également parce que ces plateformes collectent la trace d’événements précise nécessaire au reporting de conformité, avec des données et des fonctions de filtrage absentes des logs natifs des bases de données. En résumé, les DAM sont aux bases de données ce que les SIEM et systèmes de gestion de journaux sont à la sécurité de l’infrastructure.

Mais les DAM nécessitent de déployer des agents locaux et peuvent être onéreuses. Elles requièrent une actualisation régulière des règles pour assurer que les alertes sont générées pour des activités réellement inappropriées. En outre, le blocage de requêtes peut conduire à des effets collatéraux malvenus dans la cohérence des données et l’état des applications.

A noter l’existence d’un sous-segment du DAM se concentrant sur des plateformes couramment appelées pare-feu de bases de données. Comparables à des pare-feu applicatifs (WAF), ces passerelles s’interposent entre application et base de données pour bloquer le trafic malicieux. Elles peuvent bloquer les attaques par injection SQL et filtrer les requêtes inappropriées, ou encore masquer les résultats de requêtes en fonction des droits des utilisateurs.

Recherche de vulnérabilités

Les outils de recherche de vulnérabilité vérifient la configuration des bases de données et les correctifs installés. Contrairement aux outils d’évaluation génériques pour terminaux et serveurs, ces outils vérifient les réglages du système d’exploitation de l’hôte du SGBDR, mais également les détails de configuration spécifiques à ce dernier, invisibles aux outils génériques.

Les systèmes d’analyse dédiés aux SGBDR contiennent des milliers de vérifications préconfigurées et relatives à des erreurs de réglage fréquentes, ou encore des vecteurs d’attaques courants. Et cela au-delà des recommandations des éditeurs, en tant compte des pratiques de référence de l’industrie.

Certes, certaines bases de données intègrent des systèmes de vérification de base, au sein de leurs fonctionnalités d’administration. Mais la vérité est que les outils tiers vont bien au-delà, prenant en compte des détails que nombre d’éditeurs de bases de données choisissent d’omettre. L’éditeur peut alerter ses clients sur des vulnérabilités spécifiques et proposer des correctifs. Mais l’éditeur tiers peut suggérer des mesures supplémentaires, des reconfigurations ou encore des analyses différentes. Un tiers recommandera par exemple de désactiver des options connues pour les vulnérabilités qu’elles induisent.

Enfin, la plupart des outils tiers sont conçus dans la perspective de personnes au profil non technique. Ils fournissent la séparation de tâches nécessaire entre équipes de sécurité et administrateurs de bases de données, mais des personnes peu versées dans les détails techniques peuvent vérifier que les règles appropriées sont en place et appliquées.

Chiffrement

La plupart des bases de données intègrent des capacités de chiffrement, généralement pour verrouiller des champs ou des colonnes spécifiques. Ces capacités natives sont essentiellement pilotées par l’application. C’est l’application qui doit être adaptée pour appeler les librairies de chiffrement de la base de données afin de chiffrer ou déchiffrer les données. Ce chiffrement, au niveau de la couche applicative, est généralement laissé de côté pour des questions de performances et d’intégration.

Désormais, la plupart des éditeurs de SGBDR utilisent un chiffrement transparent (TDE). Celui-ci concerne toutes les données, en les chiffrant à l’écriture, puis en les déchiffrant à la lecture. Cela peut paraître contre-intuitif, mais ce chiffrement est plus rapide que le chiffrement au niveau de la couche applicative. Surtout, il est invisible pour l’utilisateur et même pour la base de données. Dès lors, le chiffrement peut être ajouté sans apporter de changement au code des applications ou des requêtes sur la base de données.

Mais voilà, le TDE nécessite un système robuste de gestion des clés de chiffrement pour assurer la sécurité des données. Et n’importe quelle application, tout utilisateur dûment authentifié, peut accéder aux données en clair. Ainsi, le TDE répond aux questions de protection des données au repos, mais pas de contrôle des accès et des utilisations.

Masquage et tokenisation

Lorsqu’une organisation ne fait pas confiance à une base de données, ou ne peut pas garantir qu’elle restera sûre dans le temps, comme peut-elle s’assurer que les données resteront en sécurité ? Les deux technologies de tokenisation et de masquage sont là pour répondre à cette question.

La première remplace les données sensibles par une copie qui ressemble à l’original et se comporte de manière identique. Tout comme un jeton d’auto-tamponneuse remplit l’office d’une véritable pièce de monnaie. Cela signifie que les applications continuent de fonctionner normalement, mais sans menace de vol ou de perte de données. Les jetons n’ont pour valeur qu’une référence à la valeur réelle, stockée elle dans une autre base de données, hautement sécurisée, et accessible uniquement à une poignée d’utilisateurs triés sur le volet, le coffre-fort à jetons (token vault).

Les jetons sont parfaits pour remplacer des éléments de données unitaires, comme un numéro de carte bancaire. Mais que faire des cas où les organisations doivent analyser d’importants volumes de données complexes et sensibles ?

C’est là qu’entre en jeu le masquage – parfois appelé masquage statique : les jeux de données sensibles sont remplacés par des copies ; mais ces dernières préservent la valeur agrégée de la base de données. Un masque permet de dissimuler des données, par exemple en réorganisant aléatoirement une colonne contenant dans salaires, ou en substituant à des noms tirés d’un annuaire à des noms réels. Ainsi, les véritables données sont cachées, mais leurs substituts conservent suffisamment de similarités avec l’original pour que les analyses continuent de fournir des résultats pertinents.

Formation et support

Les outils de sécurité pour bases de données intègrent généralement des règles préconfigurées, pour simplifier la tâche des équipes de sécurité et d’exploitation. Mais chaque outil est suffisamment complexe – tant pour son déploiement que pour son administration – pour justifier une formation.

Les éditeurs de plateformes de DAM proposent ces formations, parfois même sans surcoût à l’acquisition de la licence. Dans la plupart des cas, deux à cinq jours de formation sont suffisants. Et l’administration courante de la plateforme peut alors être opérée en interne, sans recourir à une équipe de support dédiée.

Adapté de l’anglais

Pour approfondir sur Backup et protection de données

Close