• Aug 18, 2025

Objectif 100%, sécurité Veeam Backup & Replication v12

Détails les recommandations du Veeam Analyzer et propose des améliorations complémentaires. De l'architecture simple vers une posture de sécurité renforcée, explorez les bonnes pratiques pour atteindre une sécurité optimale.

En tant qu'administrateur et utilisateur de Veeam Backup & Replication depuis 2011, j'ai développé une expertise approfondie des meilleures pratiques en matière de protection des données. La sécurisation de Veeam Backup & Replication v12 (version 12.3.1.3617) constitue une recommandation forte de l'éditeur, qui propose un outil intégré de sécurité et de conformité.

Cette approche de sécurisation s'articule autour de deux axes principaux :

Sécurisation de l'infrastructure

Les mesures de sécurité de l'infrastructure suivent les pratiques standards de durcissement des systèmes Windows, incluant :

  • Configuration sécurisée du système d'exploitation

  • Gestion des accès

Configuration sécurisée du produit

Les mesures de configuration se concentrent spécifiquement sur la protection de l'application Veeam B&R elle-même, couvrant :

  • Paramétrage sécurisé des composants Veeam

  • Chiffrement des données et communications

  • Gestion des identités et authentification

Prérequis fondamentaux

Avant ma mise en œuvre, il a été essentiel de m'assurer que :

  • L'accès au serveur est verrouillé pour empêcher l'accès physique non autorisé

  • Le serveur bénéficie encore du support Microsoft (cette condition garantit l'accès aux correctifs de sécurité)

  • Le serveur dispose de suffisamment de ressources

  • Le serveur dispose d'une bande passante dédiée pour les transferts de données (sauvegarde et restauration)

  • Le serveur soit dans un domaine de management dédié OU alors en workgroup (standalone).

  • Le serveur est protégé par une solution de sécurité (idéalement de type XDR)

  • Le serveur est dédié aux logiciels Veeam (désinstaller les outils tiers ou plugin Veeam inutiles)

  • Le serveur est dans un domaine de diffusion distinct (physique ou virtuel)

  • Le serveur est filtré par un pare-feu physique et n'autorise que le strict nécessaire

  • Le serveur est accessible uniquement via la console de management du serveur ET par une solution tiers (hors RDP) de type bastion (avec journalisation)

  • Le serveur est supervisé en cas de connexion (console Veeam), via syslog (pour le SIEM).

  • La gestion des secrets (clé de chiffrement) est dans un KMS dédié et externalisé

Une partie de ces principes fait partie du modèle Zero Trust, Veeam l'illustre parfaitement au lien suivant. Dans le cas de l'installation sous Windows, l'outil Security Compliance Toolkit (SCT) peut vous aider afin de respecter plus rapidement les recommandations de Veeam.

A partir de ce moment j'ai mis en place les mesures ci-dessous, pour obtenir notre score de 100% :

Le récapitulatif des bonnes pratiques de l'Analyzer

Voici les étapes des 35 remédiations que j'ai donc déployées par GPO :

🔐 Sécurité de l'infrastructure de sauvegarde

  • Le service Remote Desktop Service (TermService) est désactivé.

  • Le service Remote Registry (RemoteRegistry) est désactivé.

  • Le service Windows Remote Management (WinRM) est désactivé.

  • Le pare-feu Windows est activé.

  • La signature et le chiffrement SMBv3 sont activés.

  • Le caching des identifiants WDigest est désactivé.

  • Le service Web Proxy Auto-Discovery (WinHttpAutoProxySvc) est désactivé.

  • Les versions obsolètes de SSL et TLS sont désactivées.

  • Windows Script Host est désactivé.

  • Le protocole SMBv1 est désactivé.

  • Le protocole LLMNR est désactivé.

  • Le service LSASS est activé/configuré pour s’exécuter en tant que processus protégé.

  • Le protocole NetBIOS est désactivésur toutes les interfaces réseau.


⚙️ Configuration du produit

  • MFA est activée pour la console de sauvegarde.

  • Des supports immutables ou hors ligne (air gapped) sont utilisés.

  • La protection contre la perte de mot de passe est activée.

  • Les notifications par e-mail sont activées.

  • La sauvegarde de configuration est activée et chiffrée.

  • Toutes les sauvegardes respectent la règle 3-2-1.

  • Le mode de sauvegarde reverse incremental est évité.

  • Les sauvegardes vers des référentiels cloud sont chiffrées.

  • Les serveurs Linux inconnus ne sont pas automatiquement approuvés.

  • La sauvegarde de configuration n’est pas stockée sur le serveur de sauvegarde.

  • Le chiffrement du trafic hôte vers proxy est activé en mode transport réseau.

  • Les référentiels renforcés ne sont pas hébergés dans des machines virtuelles.

  • Le chiffrement du trafic réseau est activé dans le réseau de sauvegarde.

  • L’authentification par mot de passe est désactivée sur les serveurs Linux.

  • Les services de sauvegarde s’exécutent sous le compte LocalSystem.

  • Les identifiants et mots de passe de chiffrement sont renouvelés au moins une fois par an.

  • Le serveur SSH est désactivé sur les référentiels renforcés.

  • Le mode Governance de S3 Object Lock ne garantit pas une véritable immutabilité.

  • Les dernières mises à jour du produit sont installées.

  • Le serveur PostgreSQL est configuré selon les recommandations.

  • Les référentiels renforcés ne sont pas utilisés comme serveurs proxy de sauvegarde.

  • Les recommandations sur la longueur et complexité des mots de passe de chiffrement sont suivies.


🚫 Recommandation non appliquée

  • Le serveur de sauvegarde ne devrait pas faire partie du domaine de production.
    Supprimé (justification) : Utilisation d’un domaine de gestion.

L'ensemble des explications sont disponibles au lien suivant.
Veeam One peut également vous aider, ainsi que le site best practice.

Conclusion

L'adoption des recommandations Veeam s'aligne avec une architecture simple mais maîtrisée. La criticité du serveur de sauvegarde justifie une attention particulière car il est essentiel en cas d'incident. Nous pourrions aussi évoquer des recommandations non énoncées par le Veeam Analyzer :

  • Externalisation de la base de données : Migration vers un serveur PostgreSQL dédié

  • Durcissement de la base de données : Changer les identifiants par défaut et limiter les accès

  • Isolation du proxy : Déploiement sur une machine distincte (environnement non-Windows)

  • Durcissement réseau : Renforcement du filtrage avec accès restreint aux ressources critiques via le proxy uniquement

  • Chiffrement renforcé à froid : Mise en place du chiffrement de l'ensemble des volumes (pas uniquement des fichiers Veeam).

  • Stratégie de sauvegarde avancée : Implémentation de la règle 3-2-1-1-0 complétée par SureBackup (tester les sauvegardes systématiquement et manuellement, si SureBackup n'est pas envisageable)

  • Sauvegarde air-gap : Stockage déconnecté physiquement du réseau (bandes, stockage offline rotatif)

  • Authentification avec une carte à puce : Renforcer l'authentification des comptes (Yubikey)

  • Documentation et procédures : Plan de reprise d'activité (PRA) détaillé avec procédures de restauration documentées (failover Veeam).

L'architecture en deviendrait plus complexe mais renforcerait significativement la posture de sécurité et la résilience du système de sauvegarde. C'est peut être après avoir adapté cette architecture que mon score serait vraiment de 100%...

Et vous, comment respectez-vous les bonnes pratiques de sauvegarde de vos données ?