Les architectures 3-tiers, majoritairement employées pour les services en ligne, s’articulent autour de trois composants : le navigateur du client, le serveur applicatif (serveurs web + moteur applicatif) et enfin la base de données. Une grande partie de la sécurité est assurée par des moteurs d’application mais les vulnérabilités de ces derniers, couplées aux failles issues parfois du développement, peuvent entrainer des attaques de type « Injection SQL ».
Voici donc quelques conseils de première nécessité pour sécuriser votre base de données. Ceux-ci doivent néanmoins être accompagnés de mesures de sécurisation de votre système d’exploitation et de votre moteur d’application.
1. Changer le mot de passe par défaut
Avant de passer à table, Scott et Tiger se lavent les mains. Même chose lorsque nous avons terminé l’installation de notre base de données : il faut systématiquement modifier les mots de passe par défaut.
Astuce : le site CIRT recense les mots de passe par défaut de nombreux équipements et logiciels.
2. Refuser les connexions distantes
Pour ne pas tenter le diable, nous allons également nous assurer que le service de base de données n’est pas exposé sur une adresse IP publique. Par défaut, nous devrons nous assurer qu’il est en écoute sur l’interface loopback (127.0.0.1) ou une socket système.
Astuce : si votre interface d’administration (où est installé PhpMyAdmin ou SQL Entreprise Manager par exemple) n’est pas sur le même serveur, faites communiquer les composants via des adresses IP privées sans NAT vers l’extérieur de votre réseau.
3. Supprimer les comptes inutiles
Nous allons ensuite supprimer les accès aux données qui nous paraissant inutiles : c’est assez simple, nous supprimons tous les comptes d’accès configurés après l’installation, à l’exception bien entendu du compte d’administration principal (root, sa, …).
Astuce : les plus paranoïaques d’entre nous pousseront même le vice jusqu’à renommer le compte d’administration principal. Technique ayant néanmoins que peu d’impacts sur la sécurité si par exemple nous nous dédouanons d’un mot de passe robuste.
4. Supprimer la base de données d’exemple
Suivant la règle « tout ce qui ne nous sert pas doit être supprimé », nous allons faire de même avec les bases ou tables de données livrées à l’installation pour servir d’exemples. Attention, tous les moteurs ne sont pas livrés avec ce type de données.
Soyons particulièrement attentifs aux bases ou tables dites « système », elles contiennent par exemple les identifiants des comptes d’accès et les droits associés. Une lecture de la documentation de votre éditeur (Oracle, Microsoft, Mysql, Postgres, …) est un pré-requis avant de trancher dans le vif.
Astuce : une fois les étapes de nettoyage réalisées, nous sommes en possession d’une configuration « propre » qu’il est parfois intéressant de sauvegarder. La réalisation d’un paquetage logiciel est un plus non négligeable (paquetage Debian, RPM pour Redhat, NullSoft Installer, …).
5. Activer les logs et les externaliser
L’activation des fichiers de logs doit être un réflexe de la première heure. En cas d’interruption du service, d’incidents logiciels ou matériels, ou d’intrusion sur le système, les journaux d’activités permettront de mieux analyser la situation et de prendre les mesures nécessaires.
L’externalisation des fichiers logs en temps-réel (via utilisation de syslog par exemple) est parfois nécessaire pour répondre à des obligations légales ou règlementaires. Les données externalisées doivent être stockées en lecture seule et archivées sur support non-réinscriptible si besoin.
Astuce : si votre serveur base de données ne produit pas des fichiers logs compatibles avec syslog, copiez-les à intervalles réguliers sur un serveur distant qui n’autorisera le compte de copie qu’en écriture et non en lecture et suppression.
6. Exécuter le service avec un compte de service
Les moteurs de bases de données sont généralement conçus pour n’utiliser que des droits limités sur le système d’exploitation. Les répertoires et les ports d’écoute utilisés en standard sont en effet au sein d’un contexte utilisateur et non celui du noyau.
Si nous sommes victimes d’une attaque de type « dépassement de tampon », le code susceptible d’être exécuté le sera avec des droit limités et les dégâts seront moins importants.
Astuce : pour plus de sécurité, il est recommandé, lorsque ceci est possible, d’isoler l’exécution du moteur de base de données dans un environnement clos, technique dite du « chroot »..
7. Restreindre les privilèges des utilisateurs
Dans une démarche toujours pragmatique, nous allons nous assurer que les privilèges fournis aux utilisateurs de la base de données sont en adéquation avec le besoin fonctionnel. Le compte utilisé pour se connecter à la base et y consulter des données au travers d’un script PHP, n’aura nullement besoin de droits d’écriture ou de suppression.
Nous devons donc identifier les bases et leurs tables de données auxquelles un utilisateur devra avoir accès (exemple : base « web », tables « clients » et « articles »). Dans un second temps, il nous est nécessaire de déterminer les droits d’accès associés : l’utilisateur doit-il pouvoir lire, créer, modifier ou supprimer des enregistrements ?
Astuce : nous pouvons agir dans le respect de deux règles simples, « tout ce qui n’est pas expressément nécessaire est interdit » et « si nous ne savons pas à quoi correspond un droit d’accès, c’est que nous n’en avons pas besoin ».
8. Chiffrer les données stockées
Les moteurs les plus récents proposent tous en standard ou via un module additionnel, des options de chiffrement des données. Ne nous gênons pas pour activer l’option si nos bases de données sont constituées de données sensibles.
Les étapes de chiffrement et déchiffrement pourront alors être réalisés par la couche d’accès aux données. Ainsi, une attaque de type « Injection SQL » ne donnera accès qu’à des données chiffrées à l’attaquant. Dans le cadre de la certification PCI-DSS, les biens susceptibles d’être chiffrés sont spécifiquement définis (obligation pour les numéros de carte de crédit lors de leur phase de conservation).
Astuce : une solution hybride consiste à ne chiffrer les données que lors de phases particulières d’écriture (stockage de données sensibles de l’utilisateur comme son numéro de sécurité sociale). N’oublions pas non plus de sécuriser les clés de chiffrement en les stockant hors du serveur de base de données.
9. Appliquer les patchs de l’éditeur
Cela semble relever de l'évidence même, mais une fois les phases d'installation, de configuration et de recette terminées, beaucoup d’entre nous oublient que nos logiciels s’inscrivent dans un cycle de vie parfois mouvementé.
Outre les correctifs de sécurité applicables à notre système d’exploitation, nous devons veiller à la parution de correctifs pour notre moteur de bases de données. Nul besoin ici d’engager un détective privé, chaque éditeur (libre ou commercial) met à la disposition du public, une page web dédiée aux nouveaux paquets logiciels de sécurité (exemple : la page consacrée à PostgreSQL) ou bien une liste de diffusion.
Astuce : nous suivrons de près l’ensemble des correctifs proposés par l’éditeur de notre base de données, qu’il s’agissent des correctifs de sécurité, ou qu’il s’agissent des correctifs en terme d’évolutions. En effet, certains éditeurs s’imposent un rythme de correctifs soutenus et intègrent les correctifs de sécurité dans les paliers évolutifs.
10. Votre conseil
Cette liste ne serait bien évidemment pas complète sans votre conseil de sécurisation. Dans votre environnement, vous avez sans doute mis en place une action de sécurisation qui n'est pas listée ici.
Je vous invite donc à nous présenter vos conseils, recommandations, astuces, leurs avantages et particularités... à vos commentaires !
crédit photo : © Maxim_Kazmin - Fotolia.com