Présentation du renforcement de MySQL

Il n'existe pas de solution miracle : certains pirates informatiques peuvent facilement analyser l'intégralité d'Internet en quelques minutes et déchiffrer les mots de passe en quelques secondes. Bien qu'il soit parfois nécessaire de laisser une base de données accessible via un réseau IP public, votre base de données est alors extrêmement vulnérable. Pour atténuer les risques liés aux adresses IP publiques, vous pouvez restreindre l'accès à la base de données à un ensemble limité d'adresses IP.

Cela étant, la meilleure solution consiste à n'autoriser l'accès qu'à l'intérieur d'un cloud privé virtuel (VPC) et à n'autoriser que les connexions d'opérateurs dans un hôte bastion. Dans Google Cloud, cette solution s'appelle une adresse IP privée. Si votre instance MySQL n'est accessible que dans un VPC, un pirate informatique devra d'abord pirater le VPC avant de tenter de forcer l'instance.

Chaque version mineure de MySQL contient des notes de version et comporte presque toujours une section sur les mises à jour de sécurité. Si votre instance est obsolète de plusieurs versions, il manque à votre base de données plusieurs versions de correctifs de sécurité.

En plus de corriger les problèmes de sécurité au fil du temps, MySQL introduit régulièrement plusieurs nouvelles fonctionnalités de sécurité. Par exemple, MySQL 8.0 a introduit de nombreuses façons de renforcer les schémas et les utilisateurs MySQL, tels que les rôles, le suivi des échecs de connexion et la génération de mots de passe aléatoires.

Imaginons que vous travailliez dans un café et que vous souhaitiez exécuter des requêtes. Vous vous connectez donc à MySQL via le réseau Wi-Fi gratuit de la boutique. Si vous n'avez pas utilisé le protocole TLS (Transport Layer Security), vous communiquez votre nom d'utilisateur et votre mot de passe via le protocole TCP (Transmission Control Protocol, l'un des principaux protocoles sur Internet). Appliquez le protocole TLS à votre instance MySQL afin de pouvoir confectionner votre latte sans craindre que des clients espionnent le réseau.

Injection SQL

Souvent, ce n'est pas la base de données, mais l'application qui est la plus vulnérable à une attaque. De nombreuses applications ont été victimes d'attaques par injection SQL, lors de laquelle un pirate informatique insère une entrée malveillante que votre application considère comme une instruction SQL valide. La meilleure protection contre ces attaques consiste à utiliser des instructions préparées lors de la création d'instructions SQL au lieu de concaténer les entrées utilisateur avec des instructions SQL.

Secrets dans votre dépôt

D'innombrables bases de données ont été piratées à cause d'un développeur qui avait transféré par inadvertance son nom d'utilisateur et son mot de passe dans son dépôt de code source. Utilisez plutôt un outil comme Secret Manager de Google Cloud, qui gère tous types de secrets, y compris le mot de passe de votre base de données.

Consigner les mots de passe

Enfin, filtrez les mots de passe de votre base de données des journaux de votre application à l'aide des outils de filtrage de votre framework de journalisation (par exemple, filtres Log4j ou Rails ParameterFilter. Toutefois, la plupart des frameworks de journalisation doivent avoir un équivalent. Si vous ne le faites pas, vous devrez vous assurer que les journaux de votre application sont sécurisés pour que votre base de données soit sécurisée.

Pensez à utiliser la validation des mots de passe pour vous assurer que tous les mots de passe de votre base de données sont suffisamment complexes. Pour les applications, créez des mots de passe longs et complexes, et modifiez-les fréquemment. Les gestionnaires de secrets sont particulièrement utiles pour vous éviter d'avoir à mémoriser des mots de passe complexes et souvent modifiés. 

Si un utilisateur (et non une application) utilise un utilisateur de base de données, respectez les normes NIST et privilégiez la longueur. Les dates d'expiration et les exigences trop complexes liées aux mots de passe obligent souvent les utilisateurs à déléguer leur mémoire à des fichiers en texte brut et des notes, ce qui nuit à l'objectif de ces règles. 

Mieux encore, envisagez d'utiliser l'authentification IAM pour les utilisateurs non liés à l'application. L'authentification IAM permet de déléguer l'établissement d'une connexion à l'offre IAM de Google Cloud. Ainsi, les risques sont atténués uniquement pour l'utilisateur IAM, et non pour l'utilisateur IAM et l'utilisateur de la base de données.

Enfin, MySQL hache (et non sale) par défaut le mot de passe de votre base de données. Cela signifie que les utilisateurs ayant le même mot de passe auront des chaînes d'authentification identiques, facilitant le piratage de mots de passe peu sécurisés à l'aide d'une attaque par rainbow table. Notez que les deux utilisateurs MySQL suivants disposent de la même chaîne d'authentification authentication_string.

Envisagez de définir l'option default_authentication_plugin sur caching_sha2_password. Cela garantit que deux utilisateurs ayant le même mot de passe auront un hachage différent. Notez que les deux utilisateurs ont des valeurs authentication_string différentes dans l'exemple suivant.

Limiter l'accès ne signifie pas seulement sécuriser l'accès depuis l'extérieur. Cela implique également un audit régulier des accès de l'intérieur.

Effectuez un audit de votre application : si elle lit uniquement depuis les tables de facturation, de produit et de client, a-t-elle réellement besoin d'accéder à tout le reste ? Si l'accès racine à la base de données reste disponible, un pirate informatique peut causer des dommages considérables sur votre base de données. Au lieu de cela, pensez à chaque condition requise par votre instance, puis détaillez les droits requis et créez un utilisateur de base de données pour chacun d'eux. Si un pirate informatique viole votre base de données sous l'un de ces utilisateurs, l'ampleur des dommages sera limitée.

Effectuez un audit de vos utilisateurs : combien d'utilisateurs de votre base de données ont vraiment besoin de droits d'administrateur sur vos instances ? Combien d'utilisateurs travaillent encore dans votre organisation, sont associés à des projets inactifs ou sont eux-mêmes inactifs ? Les jetons d'accès peuvent fuiter, et la menace interne est une préoccupation persistante pour la plupart des systèmes. Veillez à avoir le moins d'utilisateurs possible pour aider votre instance à se prémunir contre ce type de problème.

Effectuez un audit de votre "administrateur" : envisagez de supprimer ou de renommer les utilisateurs tels que "racine" ou "admin". Il s'agit de cibles faciles pour les pirates informatiques, et s'ils n'existent pas, votre système sera un peu plus difficile à pirater. C'est ce qu'on appelle la sécurité par l'obscurité. Bien qu'il ne s'agisse pas de la première ligne de défense, elle peut ajouter une petite couche de sécurité à votre base de données MySQL.

Les sauvegardes de données régulières et les plans de récupération de données vérifiables sont essentiels à la gestion saine des bases de données. Cependant, même avec des sauvegardes régulières, vous pouvez perdre toutes les données écrites après la dernière sauvegarde. L'un des avantages de l'écosystème de MySQL est la récupération à un moment précis (PITR), qui vous permet de récupérer des données à tout moment. Pour rendre possible la récupération à un moment précis, activez les journaux binaires sur vos instances Cloud SQL pour MySQL.

Si vous avez suivi toutes les étapes ci-dessus, vous êtes bien préparé et protégé. Cela dit, aucune conception de sécurité ne serait complète sans une vigilance constante : l'audit de base de données. Le plug-in d'audit Cloud SQL pour MySQL vous aide à suivre les comportements inhabituels en cas de violation.

Une fois les mesures ci-dessus en place, la tâche du pirate informatique sera bien plus difficile. Il serait alors obligé de forcer votre application en espérant que l'utilisateur de la base de données de l'application dispose des droits suffisants pour cette attaque. Sinon, il devra pirater votre VPC, trouver un nom d'utilisateur existant et craquer le mot de passe en espérant que l'utilisateur dispose de droits suffisants pour mener à bien son attaque. Vous pouvez consulter les journaux de la base de données ou les journaux d'audit MySQL pour surveiller tout comportement habituel sur la base de données et réagir en conséquence.

Voilà ce que signifie la sécurité dès la conception. Les pirates informatiques continueront à trouver des moyens d'exploiter les machines. C'est pourquoi il est important de concevoir votre système avec le plus de couches de protection possible afin de protéger votre base de données.