Un environnement de recette est presque toujours moins surveillé, moins à jour et plus permissif que la production. Et il contient très souvent les mêmes données.
C’est une combinaison que les attaquants connaissent.
Pourquoi la frontière disparaît
Elle ne disparaît jamais par décision. Elle s’efface par accumulation de raccourcis :
- Une copie de la base de production « pour tester dans des conditions réelles ».
- Un flux ouvert entre les deux zones « le temps de la migration ».
- Un compte de service commun, parce que le recréer en recette prenait trop de temps.
- Un serveur de recette exposé sur Internet pour qu’un prestataire y accède.
Chacun de ces raccourcis est justifié isolément. Ensemble, ils font de la recette un chemin d’accès direct à la production.
Les trois risques concrets
La fuite de données. Une base de production copiée en recette hérite des données personnelles sans hériter des protections. C’est un manquement direct à l’article 32 du RGPD, et l’un des constats les plus fréquents en contrôle.
Le rebond. Un attaquant compromet un serveur de recette peu durci, puis utilise un flux ouvert ou un compte partagé pour atteindre la production. C’est un cas classique d’élévation par les comptes de service.
La contamination. Un test lancé par erreur sur la production : suppression de données, envoi de courriels à de vrais clients, appel à une interface de paiement réelle. Ce n’est pas de la sécurité au sens strict, mais c’est le scénario qui se produit le plus souvent.
Ce qu’il faut séparer
Les réseaux. Zones distinctes, flux entre elles explicitement autorisés et journalisés — application directe de la segmentation. Par défaut, aucun flux de la recette vers la production.
Les identités. Comptes distincts, y compris pour les administrateurs. Un administrateur qui utilise le même compte des deux côtés annule la séparation réseau.
Les secrets. Clés, certificats, chaînes de connexion, jetons d’interface. Un secret de production présent dans un dépôt de code de test est une fuite en attente.
Les données. C’est le point le plus difficile, et le plus important.
Le problème des données de test
Tester sur des données synthétiques est plus lent et détecte moins de cas limites. C’est pourquoi les équipes copient la production. La réponse « c’est interdit » ne tient pas si aucune alternative n’est fournie.
Deux approches praticables :
L’anonymisation, qui rend la ré-identification impossible. Solide juridiquement, mais dégrade souvent la cohérence fonctionnelle des jeux de données.
La pseudonymisation ou le masquage, qui remplacent les données identifiantes en conservant format et cohérence. La mesure 8.11 d’ISO/IEC 27002:2022 — masquage des données — traite précisément ce sujet, et c’est l’une des nouveautés de la révision 2022.
Attention : des données pseudonymisées restent des données personnelles au sens du RGPD. Elles doivent rester protégées, mais le risque est considérablement réduit.
La mesure 8.33 encadre plus largement les informations de test.
Le cas des environnements éphémères
Les environnements créés à la demande puis détruits sont une bonne pratique — à condition qu’ils soient réellement détruits. Nous trouvons régulièrement des environnements « temporaires » de plusieurs années, oubliés, non mis à jour, parfois exposés.
Un inventaire et une date d’expiration obligatoire à la création évitent cette accumulation.
Les cinq vérifications
- Existe-t-il un flux réseau direct de la recette vers la production ?
- Un compte permet-il d’accéder aux deux environnements ?
- Les bases de recette contiennent-elles des données personnelles réelles ?
- Des secrets de production figurent-ils dans un dépôt ou une configuration de test ?
- Combien d’environnements temporaires existent, et depuis quand ?
La troisième question est celle qui met le plus souvent en difficulté lors d’un contrôle.
Sources
- ISO/IEC 27002:2022, mesures 8.11 (masquage), 8.31 (séparation des environnements) et 8.33 (informations de test)
- Règlement (UE) 2016/679 (RGPD), article 32
- CNIL — anonymisation et pseudonymisation
Aller plus loin
Ces points sont systématiquement examinés lors de nos tests d’intrusion internes et de l’audit 360.