Contrôle Accès Bases de Données DAM

Contrôle des accès aux bases de données

Les bonnes pratiques de contrôle des accès aux bases de données incluent : comptes dédiés par application (pas de compte partagé entre plusieurs applications), comptes applicatifs avec droits minimaux (SELECT uniquement pour les applications en lecture, INSERT/UPDATE sur les tables concernées uniquement pour les applications en écriture — jamais DROP, CREATE, ALTER en production), comptes DBA séparés des comptes applicatifs (les DBA s'authentifient avec leurs comptes personnels pour toutes les opérations d'administration — piste d'audit individuelle), interdiction des comptes SA (System Administrator) ou root pour les connexions applicatives, et rotation régulière des mots de passe des comptes de service de base de données (via PAM ou secrets manager).

La gestion des connexions en base de données doit également couvrir : le chiffrement des connexions client-serveur (TLS pour les connexions réseau, même sur un réseau interne), la restriction des adresses IP autorisées à se connecter (filtrage au niveau du pare-feu DB), et le contrôle du nombre de connexions simultanées (pour éviter les abus ou les attaques DoS via exhaustion des connexions).

Database Activity Monitoring et détection des anomalies

Un DAM surveille les activités de base de données en temps réel pour détecter : l'accès massif aux données (SELECT * sur des tables contenant des données personnelles sans contexte légitime), les modifications non planifiées (UPDATE ou DELETE massifs hors des fenêtres de maintenance), les accès depuis des comptes ou des adresses IP inhabituels (un compte applicatif accédant directement depuis le réseau de management plutôt que depuis le serveur applicatif), les requêtes hors des heures ouvrées pour des comptes non-DBA, et les tentatives d'accès aux tables d'authentification (tables contenant des hashes de mots de passe).

Le DAM peut fonctionner en mode monitoring (alerte uniquement — log et notifie les équipes SOC) ou en mode blocking (bloque la requête en temps réel si elle correspond à une règle de blocage). Le mode blocking nécessite une intégration plus profonde et peut introduire une latence sur les requêtes — à utiliser avec précaution sur les bases de production à haute performance. Le mode monitoring est plus courant en production, complété par un processus d'investigation et réponse aux alertes DAM.

Protection contre l'injection SQL

La protection contre l'injection SQL (SQLi) est une responsabilité partagée entre les développeurs et les équipes de sécurité : côté développement — utilisation obligatoire des prepared statements et des ORMs sécurisés (Django ORM, Hibernate, Entity Framework), validation et échappement de toutes les entrées utilisateur, principe du moindre privilège pour les comptes applicatifs (même si une SQLi est réussie, l'attaquant ne peut que lire/modifier les données accessibles au compte applicatif) ; côté sécurité — WAF (Web Application Firewall) avec règles de détection SQLi (ModSecurity avec règles OWASP CRS, AWS WAF, Azure WAF, Cloudflare WAF), tests d'injection SQL réguliers lors des pentests et des scans de vulnérabilités (SQLMap, Burp Suite Pro).

Les revues de code sécurisées (SAST — Static Application Security Testing) dans le pipeline CI/CD détectent les patterns de code vulnérables à l'injection SQL avant le déploiement en production (outils SAST : Checkmarx, SonarQube Security Rules, Semgrep avec règles OWASP). Les tests dynamiques (DAST — Dynamic Application Security Testing) vérifient l'application en cours d'exécution pour détecter les vulnérabilités SQLi résiduelles.