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

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