Protéger ses bases de données MySQL avec GreenSQL

Les données sont devenues la cible de toutes les convoitises. L'une des grandes tendances de ces dernières années porte sur le "glissement" de la sécurité depuis les couches bases (réseau/OS) vers les couches applicatives (développements en PHP, Java, ...).

Sécuriser ses applications web contre les attaques est un réel challenge pour de très nombreuses entreprises. On pourrait dire que ce problème commence uniquement à montrer le bout de son nez et encore. Une écrasante majorité des directions métiers en charge du développement des applications ne sont même pas conscientes de la signification de base d'expression comme "SQL Injection", "Cross-Site Scripting" ou encore "Cross-Site Requests Forgeries". Les plus pessimistes diront que ça sent le sapin : Quelque part ils ont raison car tôt ou tard ca pétera au nez de quelqu'un : les plus habiles sauront s'écarter au bon moment. :-)

Au même titre que des firewalls permettent de contrôler les flux réseaux et de bloquer les flux non-autorisés ; les serveurs de base de données peuvent être protégés contre des requêtes malicieuses visant à voler leurs précieuses données. Bienvenue dans le monde des "database firewall" ou "firewall applicatifs pour bases de données".

Pour des moteurs de base de données commerciaux comme Microsoft SQL Server ou Oracle, il existe sur le marché des logiciels comme ceux proposés par Imperva et Guardium (pour n'en citer que quelques-uns).

Si au contraire votre choix s'est porté sur des moteurs OpenSource comme MySQL ou PostgreSQL, hormis des solutions "intrusives" nécessitant une mise à jour du code applicatif, c'était un peu la traversée du désert sans gourde ni chameau... Mais depuis environ un an, les choses ont changé : La solution GreenSQL compatible avec MySQL (avec PostgreSQL dans la roadmap) semble particulièrement intéressante comme solution de "database firewall"
GreenSQL s'intercale entre le site web et le moteur de base de donnée à protéger.

greensql-architecture.preview.jpg
L'application va donc envoyer ses requêtes SQL non plus directement vers le serveur MySQL mais va les soumettre pour analyse à GreenSQL : Ce dernier va procéder à une analyse des requêtes et si celles-ci sont identifiées comme non-malicieuses, va les renvoyer de façon transparente au moteur de base de données : C'est le fonctionnement classique d'un serveur de type proxy ou "mandataire".

Il est possible de configurer GreenSQL en 4 différents modes
  1. En mode IDS (détection d'attaques uniquement)
  2. En mode IPS (détection et blocage des attaques identifiées)
  3. En mode apprentissage
  4. En mode de protection de type "deny default policy".
Les deux premiers modes sont assez explicites : GreenSQL embarque un ensemble de "signatures d'attaques" caractéristiques d'injections SQL via identification de signatures. Le premier mode de type IDS ne faisant que reporter d'éventuelles attaques mais ne les bloque pas. Le mode IPS va lui bloquer les requêtes dès que celles-ci contiennent l'empreinte caractéristique d'une attaque.

A chaque requête, un niveau de risque est calculé et en fonction de celui-ci, il est possible de décider si la requête doit être bloquée ou non. Ce niveau de risque peut être pondéré en fonction de différents facteurs, comme par exemple le nom de la table ("paiements", "passwords", "type abonnement" pour donner quelques exemples). Cela semble particulièrement pertinent comme approche.

Ce qui est particulièrement intéressant c'est le mode de réaction sur attaque : Dans le cas d'une réaction de type blocage d'une requête, l'application ne voit rien se passer en tant que tel : Seul son résultat est "nul" (cad qu'aucun enregistrements n'est renvoyé). Cela permet de conserver "tel que" les applications sans avoir à modifier leur code.

Les deux derniers modes sont complémentaires et devraient donner les meilleurs résultats

Le mode "apprentissage" permet de configurer GreenSQL dans un mode ou il "apprends" ou "identifie" les requêtes légitimes/correctes. Pendant cette phase d'apprentissage, il est bien sûr important que seules des requêtes "légitimes" soient captées.

Le dernier mode "deny default policy" s'appuie sur les résultats du mode "apprentissage" et reste très similaire à un firewall réseau classique : Seules les requêtes préalablement identifiées comme "legitimes" sont autorisées, les autres seront rejetées... Très similaire à un firewall réseau implémentant une politique "Tout ce qui n'est pas explicitement autorisé et refusé".

Le mot de la fin
Je n'ai pas personnellement testé GreenSQL mais à ce que j'ai pu lire cela me semble un outil de très bonne facture. Coté performances, le surcout affiché reste assez modéré. Pour ceux qui souhaiteraient plus de détails avant de se lancer dans une première maquette, je vous conseille les slides PPT présentés à l'OWASP.
J'encourage les personnes ayant un retour d'expérience "terrain" sur GreenSQL à partager avec nous leurs impressions.
Jean-François Audenard

Au sein de la direction sécurité du Groupe Orange, je suis en charge de la veille sécurité et de la sensibilisation à la sécurité. Franchise, optimisme et bonne-humeur sont mes moteurs quotidiens