Pourquoi les serveurs de sauvegarde ne devraient jamais faire partie du même domaine

Les sauvegardes sont souvent considérées comme le dernier recours après une cyber-attaque, un défaut matériel ou une erreur humaine. Pourtant, une erreur de sécurité centrale est encore ignorée aujourd'hui dans de nombreuses entreprises : Le serveur de sauvegarde se trouve dans le même domaine Active Directory que les systèmes de production.

C'est précisément ce qui peut conduire, en cas d'urgence, à ce que les sauvegardes soient également compromises ou supprimées.

Le problème de base : l'administrateur du domaine contrôle tout

Dans un environnement Windows classique, un administrateur de domaine dispose de droits étendus. Si ce compte est compromis - par exemple par un hameçonnage, un logiciel malveillant ou un ransomware - l'attaquant obtient souvent l'accès à tous les systèmes au sein du domaine.

Si le serveur de sauvegarde se trouve également dans ce domaine, les conséquences sont graves :

• Les sauvegardes peuvent être supprimées
• Les tâches de sauvegarde peuvent être manipulées
• Les points de restauration disparaissent
• Le logiciel de sauvegarde peut être désactivé
• Les chevaux de Troie de chiffrement atteignent aussi les sauvegardes

La sauvegarde perd ainsi son objectif premier : la restauration indépendante en cas de catastrophe.

Le principe le plus important : séparer l'infrastructure de sauvegarde

Une stratégie de sauvegarde sûre repose sur l'isolation. Le serveur de sauvegarde ne devrait donc jamais dépendre entièrement du même domaine dont il doit protéger les systèmes.

Les approches qui ont fait leurs preuves sont

• propre domaine séparé
• Workgroup au lieu de l'adhésion au domaine
• des réseaux de gestion dédiés
• comptes d'administrateur séparés
• des règles de pare-feu limitées
• Stockage immuable ou sauvegardes hors ligne

L'objectif est clair : même si le domaine de production est compromis, l'environnement de sauvegarde doit continuer à fonctionner de manière indépendante.

Utilisateur de service au lieu de l'administrateur de domaine

Une autre erreur fréquente est l'utilisation d'un compte d'administrateur de domaine pour les tâches de sauvegarde.

De nombreuses solutions de sauvegarde nécessitent certes un accès aux serveurs, aux bases de données ou aux machines virtuelles, mais elles ne requièrent pas les droits d'administration complets du domaine.

Il convient plutôt d'utiliser des comptes de service dédiés :

• avec les autorisations minimales nécessaires
• uniquement pour les systèmes définis
• sans inscription interactive
• avec un mot de passe fort et une rotation
• séparément par service de sauvegarde ou zone système

Cela réduit considérablement la surface d'attaque.

Principe des droits minimaux

Le principe dit du «moindre privilège» fait partie des principes de sécurité les plus importants des infrastructures informatiques modernes.

Un service de sauvegarde nécessite par exemple

• Accès à certains partages
• Droits de snapshot sur les hyperviseurs
• Droits de lecture de la base de données
• Droits de sécurisation de certains systèmes

Toutefois, il n'a généralement pas besoin d'un contrôle total sur l'ensemble du domaine.

Moins un compte compromis possède de droits, moins les dommages potentiels sont importants.

Aujourd'hui, les ransomwares pensent d'abord aux sauvegardes

Depuis longtemps, les attaques modernes ne visent plus seulement les données productives. Les groupes professionnels de ransomware recherchent activement

• Serveurs de sauvegarde
• Logiciel de sauvegarde
• Systèmes NAS
• Instances Veeam
• Accès à l'hyperviseur
• Systèmes de stockage

Car les pirates le savent : Sans sauvegardes fonctionnelles, la probabilité de paiement d'une rançon augmente massivement.

C'est pourquoi il ne suffit plus d'avoir «une sauvegarde quelque part». L'environnement de sauvegarde lui-même doit être particulièrement protégé.

Meilleures pratiques pour des environnements de sauvegarde sécurisés

Les mesures suivantes ont fait leurs preuves :

1. isoler le serveur de sauvegarde
Pas d'adhésion directe au domaine productif ou séparation claire via des positions de confiance distinctes.

2. utiliser ses propres comptes de service
Ne pas utiliser les comptes d'administrateur de domaine pour les logiciels de sauvegarde.

3. utiliser des sauvegardes immuables
Les sauvegardes ne doivent pas pouvoir être supprimées ou modifiées pendant des périodes définies.

4. tester la restauration des sauvegardes
Une sauvegarde n'a de valeur que si la restauration est fiable.

5. faire des copies hors ligne ou des copies air gap
Au moins une copie de sauvegarde doit être séparée physiquement ou logiquement.

Une sauvegarde dans la même zone de sécurité que les systèmes de production n'offre souvent qu'une sécurité illusoire. Si le domaine est compromis, les sauvegardes le sont souvent aussi.

C'est pourquoi les serveurs de sauvegarde devraient si possible être exploités en dehors du domaine à protéger - combiné avec des comptes de service séparés et des autorisations minimales.

Car une sauvegarde ne protège vraiment que si elle reste inviolable en cas d'urgence.