tadata
← Retour à l'accueil

Sécurité des Bases de Données : Défense en Profondeur pour Votre Actif le Plus Précieux

#security#databases#encryption#compliance#governance

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é

tadata
  • Couche réseau
    • Sous-réseaux privés (pas d'IP publique)
    • Groupes de sécurité / règles de pare-feu
    • VPC peering / PrivateLink
    • TLS pour toutes les connexions
    • Liste d'IP autorisées pour l'accès administrateur
  • Couche authentification
    • Authentification IAM (AWS RDS IAM, GCP IAM)
    • Par certificats (mTLS)
    • Intégration LDAP / Active Directory
    • Identifiants éphémères (secrets dynamiques Vault)
    • Multi-facteur pour l'accès administrateur
  • Couche autorisation
    • Contrôle d'accès basé sur les rôles (RBAC)
    • Sécurité au niveau des lignes (RLS)
    • Permissions au niveau des colonnes
    • Isolation par schéma
    • Masquage de données via des vues
  • Couche chiffrement
    • Au repos (TDE, chiffrement de volume)
    • En transit (TLS 1.3)
    • Chiffrement au niveau du champ / de la colonne
    • Chiffrement côté client
    • Gestion des clés (KMS, Vault Transit)
  • Couche audit
    • Journalisation des requêtes (pgaudit, plugin d'audit MySQL)
    • Journalisation des connexions
    • Suivi des changements de schéma
    • Surveillance des accès aux données (DAM)
    • Alertes sur les requêtes anormales
  • Couche sauvegarde et restauration
    • Sauvegardes chiffrées
    • Réplication inter-régions
    • Restauration à un instant donné (PITR)
    • Contrôle d'accès aux sauvegardes
    • Tests de restauration réguliers
Couches de sécurité d'une base de données
tadata
Network private endpoint deny public access server/DB firewall VNet rules MI subnet NSG outbound restriction Identity Entra-only auth MFA / Conditional Access managed identities Azure RBAC for management Authorisation database roles GRANT / DENY on schemas RLS DDM + UNMASK Data protection TDE (+ CMK) TLS 1.2+ Always Encrypted ledger Detection and audit auditing Defender for SQL vulnerability assessment classification 1 2 3 4 1 Port scan from Internet — stopped at Network 2 Password spray on SQL logins — stopped at Identity 3 Support user reads card numbers — stopped at Data protection 4 Stolen backup file — stopped at Data protection
Network private endpoint deny public access server/DB firewall VNet rules MI subnet NSG outbound restriction Identity Entra-only auth MFA / Conditional Access managed identities Azure RBAC for management Authorisation database roles GRANT / DENY on schemas RLS DDM + UNMASK Data protection TDE (+ CMK) TLS 1.2+ Always Encrypted ledger Detection and audit auditing Defender for SQL vulnerability assessment classification 1 2 3 4 1 Port scan from Internet — stopped at Network 2 Password spray on SQL logins — stopped at Identity 3 Support user reads card numbers — stopped at Data protection 4 Stolen backup file — stopped at Data protection

Extrait de la fiche « DP-300 Domain 2: Secure the Azure SQL Environment » · Demander la fiche complète

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

ModèleDescriptionGranularitéComplexitéIdéal Pour
RBACPermissions assignées à des rôlesTable / schémaBasseLa plupart des applications
ABACPolitiques évaluant des attributsChamp / ligneHauteMulti-tenant complexe
RLSVisibilité par ligne imposée par la BDDLigneMoyenneSaaS multi-tenant
Niveau ColonnePermissions sur des colonnes spécifiquesColonneMoyenneProtection des PII
Masquage par VuesVues exposant des données masquéesFlexibleBasseReporting, accès analytique

Correspondance Conformité

Domaine de ContrôleSOC 2HIPAAPCI DSS 4.0RGPD
Chiffrement au reposCC6.1164.312(a)(2)(iv)Req 3.5Art. 32
Chiffrement en transitCC6.1164.312(e)(1)Req 4.2Art. 32
Contrôle d'accèsCC6.1, CC6.3164.312(a)(1)Req 7, 8Art. 25, 32
Journalisation d'auditCC7.1, CC7.2164.312(b)Req 10Art. 30
Sauvegarde/restaurationA1.2164.308(a)(7)Req 12.10Art. 32

Modèle de Maturité

NiveauNomCaractéristiques
1BasiqueCredentials par défaut changés, TLS activé, sauvegardes existantes.
2StandardRBAC implémenté, journalisation d'audit activée, chiffrement au repos.
3RenforcéRLS/ABAC, chiffrement au niveau des champs pour les PII, credentials dynamiques.
4ProactifScan de vulnérabilités continu, détection d'anomalies de requêtes, rotation automatisée.
5Avancé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

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.