Ne négligeons pas la non-production

Tous les référentiels de bonnes pratiques s’accordent : les différents environnements d’une application (les classiques développement, test, qualification/intégration, pré-production et production, ou autres comme Sandbox, Formations, User Acceptance Test…) doivent être segmentés, pour assurer une correcte allocation des droits (ex: pas de développeurs en production) et protection des données (pas de données de production dans les chaînes en amont).

La conséquence habituelle observée est une protection maximale des environnements contenant des données sensibles, et un certain laxisme sur les autres (privilèges élevés attribués à de nombreux comptes, absences de revues, mots de passe par défaut, durcissements non appliqués, filtrage réseau plus ouvert…) pour faciliter les travaux des développeurs et intégrateurs. Pas de données métier, pas de risques, me direz-vous.

Rien n’est moins sûr. En cas d’attaque et d’accès aux environnements secondaires, des chemins auxquels on ne pense pas toujours peuvent permettre de faciliter ou de réaliser une latéralisation vers la production :

• La réutilisation de secrets : comptes techniques ou utilisateurs administrateurs dont le mot de passe est identique sur tous les environnements ou construit sur un pattern permettant de deviner celui de la production,
• Les flux de mise en production : vulnérabilité classique dans les écosystèmes SAP,
• L’accès réseau si les environnements sont dans le même segment,
• Le passage en boite blanche : plus facile d’attaquer la production quand vous avez déja une connaissance des chemins d’accès, du fonctionnement, des versions déployées…
• Les données de test non ou mal anonymisées : un backup de la production est parfois le jeu de données le plus intéressant pour votre formation utilisateurs…

Maintenir la même exigence sur un environnement de développement et sur une production reste compliqué à imposer, mais certaines pratiques peuvent réduire les risques :

• Zéro flux transverses, les mises en productions repassent par un orchestrateur ou une chaîne de CI,
• Avoir un annuaire de qualification avec une interface permettant aux développeurs/intégrateurs de créer des comptes à durée limitée à la volée et avec un mot de passe aléatoire,
• Des processus d’anonymisation validés pour créer les données de test (sûrement le plus complexe),
• Des audits/contrôles qui couvrent tout l’écosystème.