La checklist RGPD du DBA pour le clonage de bases (gratuite, 12 points) | DataTamed
La checklist RGPD du DBA pour le clonage de bases
Douze vérifications que toute équipe SQL Server devrait pouvoir passer avant qu'un seul octet de données de production n'atteigne un environnement non-prod. À copier, coller, exécuter.
Pourquoi cela compte
Voici la vérité gênante sur le RGPD pour les équipes d'ingénierie : la production est rarement l'endroit qui vous fait mal. La production a les journaux, le contrôle d'accès, le chiffrement au repos, la piste d'audit — toute la machinerie pour adultes. Les problèmes vivent partout où les données de production se diffusent en silence : dev, QA, UAT, staging, le bac à sable d'intégration que quelqu'un a monté pour un partenaire, et oui, le portable sur lequel un prestataire a restauré une sauvegarde mardi dernier et a oublié. Cette dispersion, c'est là que la plupart des fuites se produisent, et c'est là que la plupart des audits trébuchent vraiment.
Alors nous avons écrit la checklist que nous aurions aimé que quelqu'un nous tende il y a des années. Douze questions simples. Si vous pouvez répondre « oui » à toutes, vous avez effectivement fermé la porte à la classe dominante de risque RGPD dans votre parc SQL Server. Si vous ne pouvez pas encore, voici à peu près l'ordre dans lequel nous les corrigerions.
Les douze vérifications
1. Nous avons un inventaire à jour des colonnes PII
Chaque base, chaque table, chaque colonne contenant des données personnelles — écrit quelque part qui ne se perd pas quand le DBA principal part en vacances.
2. Les PII sont masquées avant que le fichier de base ne soit stocké
Pas « après la restauration ». Pas « lors de la prochaine fenêtre de maintenance ». Avant que le fichier n'atterrisse sur un disque non-prod. Masquez à l'import pour que des PII de qualité production n'atteignent jamais un environnement non-prod en premier lieu.
3. La stratégie de masquage par colonne est documentée
Pour chaque colonne PII : quelle stratégie (partielle / rédaction / nullification) et pourquoi. Les auditeurs adorent ça, parce que cela montre que les choix étaient délibérés.
4. Le masquage est imposé par la plateforme, pas par les humains
Si votre masquage vit dans un script que quelqu'un doit penser à exécuter, tôt ou tard — généralement un vendredi après-midi, généralement quand quelqu'un remplace quelqu'un d'autre — il sera oublié. Intégrez-le au flux pour qu'un clone non masqué ne puisse tout simplement pas exister.
5. Chaque événement de clonage est consigné
Qui, quand, image source, serveur cible, masquage appliqué. Une ligne par clone. Exportable.
6. Le libre-service est contrôlé par rôle
Le libre-service est une fonctionnalité, pas une valeur par défaut pour tout le monde. Restreignez qui peut créer des clones aux personnes qui en ont besoin.
7. Les identifiants non-prod sont différents de la production
Mots de passe SA distincts par environnement. Comptes de service distincts. Les secrets de production restent en production.
8. Il existe un rapport de masquage en un clic
Quand le régulateur demande « montrez-moi votre preuve de masquage », vous devriez pouvoir produire un CSV / Excel / PDF en moins de cinq minutes — pas en lançant une requête SQL contre la table masking_log.
9. Le clonage inter-versions est validé
Cloner une base SQL Server 2022 sur une instance 2017 casse silencieusement les niveaux de compatibilité. Validez explicitement la compatibilité de version pendant le clonage — et refusez de continuer si cela casserait quelque chose.
10. Il existe une politique de rétention pour les clones non-prod
Même un clone masqué reste de la donnée. Faites-le expirer. Trois mois. Six mois. Choisissez un nombre, écrivez-le, imposez-le.
11. Nous avons répété l'audit
Essayez en exercice théorique : « Un régulateur vient de nous demander la preuve de masquage du dernier trimestre. » Si votre équipe peut la produire en cinq minutes — calmement, depuis un endroit connu — vous passez. Si le premier réflexe est « laisse-moi fouiller dans l'historique SSMS et pinger le DBA qui est en vacances », non.
12. Nous savons exactement où voyagent les fichiers de base
Si un outil de clonage envoie des sauvegardes, des schémas ou des métadonnées dans le cloud, vous devriez pouvoir pointer le contrat qui le dit. Sinon, votre outil de choix devrait être auto-hébergé par défaut — comme DataTamed.
Douze vérifications que toute équipe SQL Server devrait passer avant que les données de production n'atteignent le non-prod.Cliquez pour partager
Si vous voulez la visite complète, la page de cas d'usage Conformité & RGPD parcourt chacun des douze en détail, captures d'écran du produit réel à l'appui. Ou laissez tomber la brochure et passez directement à un essai gratuit de 14 jours — parcourez la checklist sur vos propres sauvegardes et voyez combien de points passent au vert sans écrire la moindre ligne de script.