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
La partie la plus difficile du RGPD pour les équipes d'ingénierie n'est pas la production. La production a des journaux, du contrôle d'accès, du chiffrement au repos, des pistes d'audit. La partie difficile, c'est partout où les données de production se diffusent : dev, QA, UAT, staging, le portable sur lequel un prestataire a restauré une sauvegarde mardi dernier. C'est là que la plupart des fuites se produisent, et c'est là que la plupart des audits échouent réellement.
Si vous pouvez répondre « oui » aux douze, vous avez effectivement éliminé la classe dominante de risque RGPD dans votre parc SQL Server. Si vous ne pouvez pas, voici l'ordre dans lequel les corriger.
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, il sera oublié. Le flux ne devrait pas permettre l'existence d'un clone non masqué.
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
Théorique : « Le régulateur vient de demander la preuve de masquage du dernier trimestre ». Si votre équipe peut la produire en cinq minutes, vous passez. Si elle doit fouiller dans l'historique SSMS, 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
Comment DataTamed met en œuvre les douze d'office
Nous n'avons pas écrit cette checklist comme un document de vente — c'est vraiment le manuel de terrain que nous aurions aimé avoir des années plus tôt. Mais soyons honnêtes : DataTamed a été conçu pour que chacun de ces douze points passe par défaut, sans configuration :
- Détection automatique de six catégories de PII à l'import (n°1, n°2)
- Choix de stratégie de masquage par colonne (n°3)
- Masquage imposé au niveau de la plateforme — il n'y a pas de bascule « ignorer le masquage » (n°4)
- Chaque événement de clonage, masquage et sauvegarde consigné dans des rapports exportables (n°5, n°8, n°11)
- Contrôle d'accès par rôle, clés API distinctes par agent (n°6, n°7)
- Validation automatique de compatibilité de version SQL Server dans l'assistant de clonage (n°9)
- Auto-hébergé par défaut — le serveur tourne dans votre réseau, point final (n°12)
Si vous voulez une visite complète, la page de cas d'usage Conformité & RGPD couvre chacun des douze en détail, avec des captures d'écran du produit réel. Ou allez directement à un essai gratuit de 14 jours et parcourez la checklist sur vos propres données.