Database Security: Defense in Depth for Your Most Valuable Asset

Les bases de données sont là où résident les actifs critiques -- données clients, documents financiers, informations de santé, propriété intellectuelle. Une brèche au niveau de la base de données est le pire scénario pour toute organisation. La sécurité des bases de données exige une défense en profondeur : plusieurs couches qui se chevauchent, chacune capable d'arrêter un attaquant ayant contourné la couche supérieure.

Taxonomie des Couches de Sécurité

Couches de Sécurité BDD
├── Couche Réseau
│   ├── Sous-réseaux privés (pas d'IP publique)
│   ├── Groupes de sécurité / règles firewall
│   ├── VPC peering / PrivateLink
│   └── TLS pour toutes les connexions
├── Couche Authentification
│   ├── Authentification IAM (AWS RDS IAM, GCP IAM)
│   ├── Basée sur certificats (mTLS)
│   ├── Intégration LDAP / Active Directory
│   └── Credentials éphémères (Vault dynamic secrets)
├── Couche Autorisation
│   ├── RBAC
│   ├── Sécurité au niveau des lignes (RLS)
│   ├── Permissions au niveau des colonnes
│   └── Masquage de données via vues
├── Couche Chiffrement
│   ├── Au repos (TDE, chiffrement de volume)
│   ├── En transit (TLS 1.3)
│   ├── Au niveau du champ / colonne
│   └── Côté client
├── Couche Audit
│   ├── Journalisation des requêtes (pgaudit)
│   ├── Journalisation des connexions
│   ├── Suivi des changements de schéma
│   └── Alerte sur requêtes anormales
└── Couche Sauvegarde & Restauration
    ├── Sauvegardes chiffrées
    ├── Réplication inter-région
    ├── Restauration point-in-time (PITR)
    └── Tests de restauration réguliers

Comparaison des Modèles de Contrôle d'Accès

Modèle	Description	Granularité	Complexité	Idéal Pour
RBAC	Permissions assignées à des rôles	Table / schéma	Basse	La plupart des applications
ABAC	Politiques évaluant des attributs	Champ / ligne	Haute	Multi-tenant complexe
RLS	Visibilité par ligne imposée par la BDD	Ligne	Moyenne	SaaS multi-tenant
Niveau Colonne	Permissions sur des colonnes spécifiques	Colonne	Moyenne	Protection des PII
Masquage par Vues	Vues exposant des données masquées	Flexible	Basse	Reporting, accès analytique

Correspondance Conformité

Domaine de Contrôle	SOC 2	HIPAA	PCI DSS 4.0	RGPD
Chiffrement au repos	CC6.1	164.312(a)(2)(iv)	Req 3.5	Art. 32
Chiffrement en transit	CC6.1	164.312(e)(1)	Req 4.2	Art. 32
Contrôle d'accès	CC6.1, CC6.3	164.312(a)(1)	Req 7, 8	Art. 25, 32
Journalisation d'audit	CC7.1, CC7.2	164.312(b)	Req 10	Art. 30
Sauvegarde/restauration	A1.2	164.308(a)(7)	Req 12.10	Art. 32

Modèle de Maturité

Niveau	Nom	Caractéristiques
1	Basique	Credentials par défaut changés, TLS activé, sauvegardes existantes.
2	Standard	RBAC implémenté, journalisation d'audit activée, chiffrement au repos.
3	Renforcé	RLS/ABAC, chiffrement au niveau des champs pour les PII, credentials dynamiques.
4	Proactif	Scan de vulnérabilités continu, détection d'anomalies de requêtes, rotation automatisée.
5	Avancé	Chiffrement côté client, classification formelle des données, reporting de conformité automatisé.

Recommandations Stratégiques

L'isolation réseau est non négociable. Les bases de données ne doivent jamais avoir d'IP publiques. Utilisez VPC PrivateLink ou peering.

Éliminez les credentials à longue durée. Utilisez les secrets dynamiques de Vault ou l'authentification IAM. Chaque credential devrait avoir un TTL mesuré en heures, pas en mois.

RLS pour le multi-tenant. Si vous opérez une plateforme SaaS, implémentez le RLS au niveau de la base de données -- pas seulement dans le code applicatif. Les bugs applicatifs ne devraient pas pouvoir exposer les données d'un locataire à un autre.

Auditez tout, alertez sur les anomalies. Activez pgaudit (PostgreSQL) ou le plugin d'audit (MySQL). Alimentez les logs d'audit dans votre SIEM.

Testez vos sauvegardes. Une sauvegarde non testée n'est pas une sauvegarde. Planifiez des tests de restauration mensuels.

Ressources

:::