Backup Trust Plane Shared With Production Domain

L’infrastructure de sauvegarde — console, serveurs, stockage, comptes d’administration — s’authentifie via le même annuaire que la production qu’elle protège. Un administrateur du domaine de production est donc, de fait, administrateur des sauvegardes : il peut s’y connecter, réduire la rétention, supprimer des jeux.

C’est structurel : la sauvegarde est déployée comme un service de l’environnement au lieu d’un plan de contrôle indépendant. L’intégration à l’annuaire est le chemin par défaut de la plupart des solutions — authentification unifiée, gestion simplifiée — et personne ne formule jamais la décision inverse. La conséquence architecturale est que la sauvegarde partage le sort de ce qu’elle protège : la compromission des identités de production est la compromission des sauvegardes. Le dernier filet de sécurité est suspendu au même clou que tout le reste.

Le scénario dominant de rançongiciel opéré par un humain inclut la destruction des sauvegardes avant le chiffrement — c’est une étape planifiée, pas un dommage collatéral. Avec un plan de confiance partagé, l’attaquant qui a obtenu les privilèges d’annuaire n’a rien à « compromettre » côté sauvegarde : il s’y connecte, légitimement du point de vue du système.

Le déroulé observable : suppression des jeux de sauvegarde, des instantanés et des tâches planifiées, puis chiffrement de la production. La question « peut-on restaurer ? » reçoit sa réponse au pire moment possible.

L’enjeu est binaire : c’est très souvent cette seule frontière de confiance qui sépare un incident de quelques jours (restauration) d’une reconstruction de plusieurs semaines — avec, entre les deux, la question du paiement qui ne se poserait pas autrement.

Le test tient en une question : avec un compte d’administrateur du domaine de production (ou un compte capable d’en réinitialiser le mot de passe), peut-on ouvrir la console de sauvegarde et supprimer un jeu ? Si oui, le pattern est présent, quelle que soit la qualité de la solution.

Vérifications complémentaires :

• le serveur de sauvegarde est-il joint au domaine de production ?
• les comptes de service de la sauvegarde sont-ils des comptes de cet annuaire ?
• le stockage de sauvegarde expose-t-il un protocole permettant l’écriture ou la suppression depuis le réseau de production ?
• qui peut réduire la rétention, et cette opération peut-elle se faire seul, sans seconde validation ?
• les administrateurs de la sauvegarde utilisent-ils leur poste de travail habituel pour l’administrer ?

Chaque « oui » élargit le chemin entre les privilèges de production et la destruction des sauvegardes.

Séparer le plan de confiance, pas seulement le réseau :

• comptes d’administration de la sauvegarde hors de l’annuaire de production : comptes locaux dédiés ou annuaire distinct, avec MFA propre ;
• serveur de sauvegarde non joint au domaine de production ;
• segmentation : la console n’est pas joignable depuis les postes de travail ; le stockage n’expose à la production que le flux d’écriture des sauvegardes, pas d’interface d’administration ;
• suppression retardée ou à double validation quand la solution le permet : une suppression demandée aujourd’hui ne devient effective que dans plusieurs jours ;
• compléter par une copie immuable (voir MFL-010) : la séparation du plan de confiance réduit la probabilité de destruction, l’immuabilité en borne l’impact. Les deux ensemble se justifient ; l’un sans l’autre laisse un scénario ouvert.

Si les identités de production sont compromises, considérer l’infrastructure de sauvegarde comme compromise jusqu’à preuve du contraire — c’est le même plan de confiance.

Dans l’ordre :

• couper les chemins de destruction : isoler l’interface d’administration du stockage, suspendre les comptes exposés, déclencher un instantané côté baie de stockage si disponible ;
• exporter une copie hors d’atteinte de l’état actuel des sauvegardes avant toute autre action — même partielle, même lente ;
• auditer ce que l’attaquant a déjà pu faire : réduction de rétention, suppressions récentes, modifications de tâches — la corruption silencieuse des semaines précédentes est un scénario documenté ;
• vérifier l’intégrité et la date des jeux restants avant de s’engager sur un plan de restauration ;
• restaurer vers un environnement propre, avec des identités reconstruites — pas dans le domaine suspect qui a permis l’accès aux sauvegardes.