Apps – VEEAM Backup & Réplication

Sauvegarde, nom fénimin (de sauf et garde) : Garantie, protection accordée par une autorité : Se mettre sous la sauvegarde de la justice ou au sens informatique du terme, Procédure de protection des informations contenues dans un système informatique, par copie de ces informations sur disque ou bande magnétique.

Vous l’avez compris, je vais parler de sauvegarde et mon autorité à moi, c’est VEEAM. (Je vous rassure je n’ai pas de part, ni d’action dans cette société).

Déjà pourquoi VEEAM et pas un autre ? Je n’ai absolument rien contre les autres solutions. J’ai juste commencé avec cette solution et j’ai continué avec cette dernière ainsi que toutes la suite de produits qui gravite autour 🙂 Alors pourquoi changer une équipe qui gagne ?

Avant de rentrer dans le vif du sujet, la question que nous devons nous poser, c’est pourquoi la sauvegarder un système informatique d’un simple poste utilisateur à la totalité d’un système d’information.

Jusqu’à présent, les données étaient stockées sur des supports physiques (papier, photo, etc). Aujourd’hui la majorité de nos données sont stockées sur des supports logiques numériques dans des supports physiques (téléphone, disque dur, USB, Serveurs etc) à un endroit, voir plusieurs. Or, comment s’assurer que ces données non physiques à base de 0 et de 1 soient protégées de toutes suppressions accidentelles ? Nous allons faire une copie de ces données et les stockées autre part. Ainsi en cas de suppression ou d’avarie nous serons en capacité de les « retrouver ».

La solution VEEAM Backup et Réplication répond à ce besoin pour les systèmes d’informations. C’est pourquoi je vous propose dans ce billet de déployer un serveur de sauvegarde. (Attention et comme d’habitude, je vais suivre le guide officiel fournit par le fournisseur. Je ne compte pas réinventer la roue, mais m’attarder sur des points importants qui sont bien malheureusement négligés par certains SysAdmin).

Prérequis

SE : Windows 2016 à 2022
Apps : VEEAM B&R 12.1, 12.2
Autres :
- Média externe
- Stockage Object
- Stockage Hardened

Théorie

Architecture & Best Pratices

Il est compliqué de donner un mode empirique d’une infrastructure VEEAM pour la bonne et simple raison qu’en fonction des autres produits et solution VEEAM qui peuvent graviter autour (VEEAMOne, VSPC, VCC etc). Toutefois, nous retrouvons sur l’infrastructure plusieurs rôles majeurs :

Backup Server
Proxy Backup
WAN Accelerator (Optionnel)
Mount Server
Backup Repository

Le rôle qui nous intéresse le plus est Backup Server. Ce dernier est le cœur de l’ensemble de la solution et va venir piloter les autres différents rôles selon les tâches qui seront exécutées. Si nous devons décomposer le rôle, nous aurions le schéma suivant :

Attardons nous rapidement sur chacun des 5 rôles présents pour bien comprendre comment fonctionne un Ordonnanceur VEEAM.

Naturellement et pour chacun des rôles la liste des ports à autoriser sont disponible avec la description sur la page de l’éditeur.

Ce rôle va permettre de traiter les instructions de sauvegarde définis par l’ordonnanceur. Il se situe entre le stockage, l’ordonnanceur et les ressources à sauvegarder. Que ce soit pour une infrastructure de sauvegarde composé que d’un ordonnanceur ou une structure avancée, le rôle proxy est d’office déployé sur le serveur d’ordonnancement.

Ce qui nous donne en théorie la topologie suivante :

Ce rôle comme son nom l’indique, va servir a stocker les données sauvegardées par notre ordonnanceur VEEAM.

Au vu du nombre de solution existante, j’ai décidé de ne traiter uniquement que la partie NFS, SMB, Windows et Linux. Il serait facile de faire un billet par technologie de repo. Nous allons rester simple, basique.

Ce qui nous donne en théorie la topologie suivante :

Bien, bien nous avançons. Le rôle du serveur de sauvegarde a déjà été présenté. Ce dernier vous l’avez compris à pour objectif de définir et de piloter les jobs de protection (sauvegarde, externalisation, réplication etc).

Je passe volontairement le schéma. Pourquoi ? Parce que ce dernier va être imbuvable. Le serveur de backup et la tête pensante de l’infrastructure et interagie avec l’ensemble des composants VEEAM pour commencer et secundo il faut rajouter les dépendances externes (SMTP, Licence VEEAM etc). Je n’ai donc pas envie et je ne suis pas venu ici pour souffrir ok 🙂

Ce rôle est super important. Pourtant le nom au premier abord n’est pas bien parlant, même si nous pouvons facilement deviner.

Il permet d’assurer la restauration des éléments protégés. Soit réaliser l’ensemble des types de restauration proposés par VEEAM (objet, fichiers, éléments virtuels, VM, etc).

Ce qui nous donne en théorie la topologie suivante :

Attention, car d’autres éléments gravitent autour de ce rôle mais ne sont pas liés directement à ce dernier. Je m’explique. Lorsqu’une demande de restauration est initié, d’autres composants rentrent jeu tel que l’Helper Appliance Connection, l’Helper Host Connection et le Guest OS Connection.

Nos 4 éléments sont liés au processus de restauration, Guest OS File Recovery.

Naturellement, il existe différent type de restauration selon le média de destination. Les ports changeront donc selon si une restauration vPowerNFS, Microsoft Azure, AWS etc.

Ce rôle vient se positionner entre les ressources à sauvegarder (VMs) et le serveur de sauvegarde. Ce dernier va sur les ressources déployer des ressources consistantes ou non pour réaliser les protections à chaud des données.

Le cycle de vie, c’est par ici.

Ainsi, il est possible de définir plusieurs Guest Interaction Proxy dans un job pour améliorer les performances ou pour forcer un proxy spécifique pour un job de protection (subnet différent par exemple).

Ce qui nous donne en théorie la topologie suivante :

Je ne traiterai pas de la partie consistance pour ne pas surcharger le schéma. Néanmoins, vous retrouver le détail sur le site de VEEAM.

Dans tous les cas, les différentes machines (pour ne pas dire serveurs de préférence) doivent être hors domaine et isolé dans une bulle réseau à part ou dans le pire des cas uniquement dans la réseau d’administration.

VEEAM pour le coup assure une nouvelle fois en facilitant la mise en place et la sécurisation de son architecture auprès des SysAdmin en fournissant la matrice des flux réseau à implémenter (différent subnet ou micro segmentation).

Avant de définir l’infrastructure cible, il convient de se poser les questions :

Qu’elle est la taille de l’infrastructure à sauvegarder ? Si l’infrastructure est conséquentes, l’ajout d’un Proxy Backup n’est pas du luxe.
Qu’elle est la nature de mon infrastructure virtuelle ? Cas d’une infrastructure virtuelle, architecture HA (Baie de stockage et N Hyperviseurs) ou un seul hyperviseur, que choisir ? Nous étudierons les deux scénarios.
Qu’elle va être la nature du stockage de destination qui va accueillir les sauvegardes ? NAS, Tape, Serveur, Média amovible ?
Dans le cas d’externalisation, ai-je besoin d’un WAN Accelerator ?
Plutôt du stockage block ou objet ?

Ca nous fait déjà un petit paquet de question. Mais pas de quoi s’affoler. Le plus difficile n’est pas l’implémentation mais la construction et sécurisation de notre infrastructure de sauvegarde.

La première vrai question est comment assurer la règle des 3-2-1-1-0.

	Objectifs	Réponses/Observations
3	Avoir 3 copies différentes des données de production	Il faut prendre en compte 1 pour les données de production, 1 pour les données sauvegardées et 1 pour les données externalisées et optionnellement 1 pour les données déconnectées ou immuables. Soit un total minimum de 3 copies, 4 en incluant les données de production.
2	Avoir 2 médias/supports différents pour le stockage des sauvegardes	Dissocier le stockage de la sauvegarde sur 1 média et 1 média différent pour la copie de cette sauvegarde et optionnellement 1 média supplémentaire pour les données déconnectées ou immuables. Soit un total minimum de 2 médias, 3 en incluant les médias déconnectées ou immuable.
1	Avoir 1 copie hors site de production	Il est indispensable de réaliser la copie de la sauvegarde sur un autre site que le site de production. Il est possible de passer par un fournisseur pour stocker une copie de sa sauvegarde ou de réaliser un copie dans un Cloud Public (avec les avantages et inconvénients que cela peut entrainer).
1	Avoir 1 copie déconnecté ou immuable	Cette mesure vise à se prémunir des attaques visant à corrompre ou altérer les données sauvegardées. Si ces dernières sont sur un médias déconnectés, il est peu probable sauf s’il n’est pas déconnecté du SI d’être altéré… Quant à l’immuable qu’il soit hardened ou objet, le nom parle de lui-même. Les TAPES ou Bandes sont également une alternatives avec le Cloud.
0	Avoir 0 erreur dans les chaines de sauvegarde	Le dernier point consiste à vérifier la cohérence des chaines de sauvegardes et des différents points et d’affirmer que l’intégrité des ces derniers ne comportent pas d’erreur.

Personnellement, j’arrive toujours à 3-2-1-1. Le 0 je n’ai jamais pu l’atteindre, par manque de temps. Cependant, grâce à ce billet, je vais enfin faire un grand pas en avant pour sortir du gouffre intellectuel dans lequel je commençais à me complaire.

Ensuite, il serait hypocrite de ma part de réinventer la roue. Puisqu’il suffit de RTFM¹ le site de l’éditeur et de s’inspirer des différentes architectures (et des exemples mis en avant). Comme je l’ai dit plus haut il n’y a pas d’architecture empirique et cela dépend, fortement des équipements et ressources qui seront utilisés, des locaux, des contraintes de l’organisation et du PAS² défini par la direction.

Alors pourquoi parler/écrire pour ne rien dire ? Tout simplement pour avertir sur le fait qu’on installe pas un composant VEEAM comme nous installerions NotePad++. Et qu’il faut bien penser à tout. Ce n’est pas quand la partie de Dungeon Keeper et lancée qu’on change les pièges, fallait y penser avant.

En gros pour moi avec une infrastructure classique, j’opterai pour l’architecture suivante à moindre cout.

Ainsi en respectant les bonnes pratiques VEEAM, j’ai considérablement restreint le risque de mon système d’information. Certes, je considéré que sur un seul site, j’ai trois bâtiments interconnecté et que les bâtiments B et C sont suffisamment loin du bâtiment A. Avec les recommandations, nous constatons avec les deux schémas ci-dessous qu’il est possible de continuer ou de reprendre les données en cas de sinistre.

Quelque chose m’embête. Imaginons le cas où le sinistre concerne l’ensemble du site et donc les trois bâtiments ? Une externalisation de la sauvegarde (ou copie de la sauvegarde) sur un autre site ou un cloud privé, public assurerai une reprise d’activité MAIS nécessiterai un cout mensuel récurrent (entre nous largement acceptable).

Niveau sécurité, il convient de suivre les recommandations de l’éditeur et de durcir au préalable les environnements Windows. J’enfonce une porte ouverte, mais chaque mot de passe doit être unique et ne doit pas être réutilisé et TOUTES les sauvegardes doivent être chiffrées. Pour mieux comprendre la criticité de la chose j’oserai même à dire cryptées !

Vous avez tiré une carte lynchage. Les gars de la branche sécurité des systèmes d’informations vous jettent des clés FIDO et des dictionnaires Gros Larousse et Petit Robert pour votre hérésie !

Rien ne justifie de ne pas chiffrer ces sauvegardes, surtout quand ces dernières sont sur des médias qui peuvent être facilement perdu. D’ailleurs, un point et cas qui m’a marqué dans mes études lors d’un partiel portait justement sur le stockage des données amovibles. Le coffre fort. Ce dernier doit être assez robuste en terme de sécurité, mais doit être ignifuge et réfractaire.

Access & Less Privileged

Je traiterai et completerai au fur et à mesure cette partie car cela va dépendre des systèmes à lequel VEEAM va s’interconnecter (VMWare (vCSA, ESXi) ou Microsoft (HyperV)).

Cette partie (peut importe la solution à mettre en place) est un véritable casse tête. La simplicité voudrait que nous attribuons les permissions root ou system pour avoir la paix. L’objectif est de définir un compte dédié à VEEAMBR sur les plateformes de gestion de socle de virtualisation avec uniquement les permissions nécessaires.

Là, c’est plutôt simple, il suffit d’utiliser directement le compte root de notre VCSA.

NO WWWWAAAAYYYYY !

RTFM une nouvelle fois mon gars ! VEEAM explique ce qu’il faut faire (ici). Je ne vais donc pas m’attarder là dessus encore une fois (oui car c’est déjà abordé dans un article pas encore publié) :p .

Pour cette partie, c’est un peu plus compliqué. Pourquoi ? Il faut tâtonner et créer ça propre politique (rôle). Si dans un sens nous pouvons nous appuyer sur la première étape de notre accordéon (partie précédente).

Je n’ai pas trouvé à ce jour de KB ou guide officiel uniquement pour la partie ESXi. Mais cela va t-il nous retenir pour autant d’innover ? Au pire ça ne fonctionne pas et nous aurons appris certaines choses. Au mieux ça fonctionne et nous aurons appris des choses. Dans les deux cas c’est win-win.

Bien que je ne l’ai pas encore testé, je dirai qu’une des bases serait du type :

Je pense avoir fait le tour. Pour le reste, je vous invite à vous perdre dans le guide de VEEAM. C’est difficile de tout aborder et de ne pas tomber dans la paraphrase.

Pratiques

Nous considérons que le serveur Windows a été durci au préalable et que nous possédons un serveur à jour.

Nous avons également télécharger en amont les sources (iso) de Veeam Backup et Réplication.

Installation

Nous partons donc du principe que notre serveur Windows est déjà configuré et non joint à un domaine.

Les prérequis en termes de ressources doivent être les suivantes:

OS : WIN10, WIN11, WS 2012 à WS 2022
CPU : 4 cores (minimum)
RAM : 4 Go + 500 Mo pour chaque job tournant en parallèle
Disk : 10Go pour l’installation + 10 Go / 100 VMs pour le Guest Catalogue + 10 Go pour les logs
Network : 1 Gbps minimum

Bon, dans mon cas, je vais être un peu short en CPU, mais on va tenter quand même.

Il est important et c’est ce que je recommande, de dissocier le Guest Catalog et le Cache du disque système et de dédier une troisième partition pour les Logs.

/!\ Attention : Nous installerons VEEAM en tant qu’Administrateur local

Avant de lancer le setup, nous allons configurer quelques options sur notre SE qui sont de mon point de vu important.

Afin de ne pas saturer notre système de lettre lors du montage des disques des VMs que nous allons sauvegarder nous allons désactiver l’automount.

Pour se faire, ouvrir une invite de commande en tant qu’administrateur et dans l’utilitaire diskpart réaliser la commande automount disable, puis quitter l’utilitaire.

Par mesure de sécurité et afin de ne pas utiliser le compte .\Administrateur pour réaliser les sauvegardes, nous allons rétablir la visibilité des partages administratifs pour les utilisateurs de notre serveur.

Ouvrez l’éditeur de registre et ajoutez la valeur LocalAccountTokenFilterPolicy en définissant la valeur à 1.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Monter les deux disques de 10 Go chacun.

Sur le premier disque VEEAM, créez les répertoires :

VBRCatalog : Qui contiendra le Guest Catalogue. Ce dernier a pour but d’assurer l’indexation, des différents SE invités des VMs que nous allons protéger.
NFSDatastore : Qui va contenir le cache en écriture lors des opérations de restauration ou lors des action de vérification lors de la sauvegarde des VMs.

Sur le second disque Logs, créez le répertoire :

VBRLogs : Qui contiendra l’ensemble des logs de notre serveur VEEAM (jobs, installation, journaux d’upgrade, etc).

Nous sommes pas mal. Je pense que nous pouvons nous lancer sous les feux des projecteurs

Sélectionnez la première option

Charger une licence si vous en possédez une, dans le cas contraire vous partirez comme moi avec la version CE³.

C’est parti pour un petit check des prérequis nécessaires au bon fonctionnement de VEEAM. Si des dépendances sont manquantes, de mémoire VEEAM vous invitera à les installer ou les installera pour vous. Il se peut que vous soyez inviter à reboot votre serveur.

Dans le cas d’un reboot, une fois authentifié, le wizard se lancera de nouveau. Inutile de spamer le launcher.

VEEAM vous le dira dans une warningbox qu’une instance est déjà en cours 🙂

Cette étape va vous demandez une grande concentration.

Deux choix s’offre à vous, réaliser une installation par défaut ou custom.

Dans notre cas, c’est une CUSTOM, il faudra cliquer en bas à gauche près du « Gear Icon » (un expression et reste d’une formation NUTANIX… 🙂 )

Laissez le compte LOCAL SYSTEL par défaut (recommended).

Depuis la version 12 de VEEAM, il est possible d’utiliser comme SGBD PostgreSQL en lieu et place de MSSQL Express.

Le pourquoi du comment de cette proposition est simple. Il y a malheureusement trop de contrainte à utiliser MSSQL dans ça version EXPRESS, surtout pour des bases de données dépassant les 10Go. Afin de s’affranchir des contraintes, PostgreSQL a été implémenté.

Je vous encourage fortement de passer sur PostgreSQL en lieu et place de MSSQL.

Ici, nous retrouvons la partie dédiée à nos répertoires créés plus tôt pour le cache (NFSDatastores) et le guest file catalog (VBRCatalog).

Nous ne touchons pas au chemin relatif à l’installation.

Laissons les ports par défauts pour les différents services.

C’est le moment d’aller chercher un café ou un cognac (XO de préférence).

Ta dam !

L’installation est terminée. On est pas bien là ? Paisible, à la fraîche, décontractés du guest… Et on backupera quand on aura envie de backuper.

Nous pouvons lancer le raccourcie sur le bureau et nous atteler à la configuration de notre VEEAM.

Configuration

La première chose que j’aime à faire sur un VEEAM qui sent le neuf, c’est de configurer les options ainsi que la sauvegarde de la configuration de ce dernier.

Dans le menu Options, deux onglets nous intéressent fortement, celui intitulé Security et E-mails Settings. Pour le reste, je laisse par défaut.

Pourquoi ? Premièrement parce que je n’ai pas de licence pour réaliser d’I/O Control, deuxièmement parce que les paramètres par défaut me vont et que je n’ai pas suffisamment de ressource pour l’instant pour transférer les logs vers un serveur SNMP ou SYSLOG.

Je n’ai pas de certificat à ajouter, j’ai toujours préférer laisser celui de VEEAM (autosigné) quand à la sécurité.

Afin de garantir la sécurité de notre serveur, il est vivement recommandé dans le cas de la sauvegarde de système GNU Linux ou de présente de Linux sur le réseau de ne pas faire confiance aux équipements qui viendraient contacter le serveur de sauvegarde. Ces derniers seront mis automatiquement en « DMZ » et devront être approuvé manuellement par l’administrateur.

Nous pouvons choisir d’activer ou non la validation FIPS⁴. Dans notre cas, nous n’avons pas de données critiques pour activer cette fonctionnalités et mes ressources sont restreintes dans mon LAB. Néanmoins, il est intéressant de savoir, qu’il est possible d’activer le contrôle en temps réel de la validation cryptographique des transactions et donc certifier que la sauvegarde est conforme.

Afin de ne pas saturer le disque système, je redirige sur une partition dédiée les logs VEEAM B&R et j’active la compression de ces derniers.

Le second onglet le plus important. Sans lui pas de notification et donc pas de visibilité sur la santé de nos sauvegardes ainsi que de la santé de notre serveur de sauvegarde.

La configuration est facilement compréhensible. Sachez toutefois que l’adresse mentionné ici recevra l’intégralité des rapports envoyés.

La sauvegarde de la configuration est un enjeu majeur car en cas de perte de notre serveur VEEAM il suffira de recharger la configuration pour retrouver notre VEEAM de nouveau opérationnel.

Par défaut, la configuration est sauvegardée sur le serveur lui-même. Mauvais idée si nous perdons le serveur. C’est pour ça cette trace de pneu couleur prune ? Toutefois notre serveur n’ayant pas encore de repo de monté, il faut mieux avoir une sauvegarde sur le serveur lui-même que rien. Il faudra toutefois penser à changer ce dernier une fois le repo ajouté.

Personnellement, je garde autant de configuration qu’il y a de jour dans le mois. J’aime également recevoir un petit rapport à 10h00 tous les jours m’indiquant que la configuration a été sauvegardé.

Point important, je chiffre ma sauvegarde. La configuration est sensible est donc en cas de fuite, je ne vous fait pas de dessin… Le mot de passe doit être différent des autres clés de chiffrements et doit être stocké dans un lieu sure. VEEAM recommande de le changer régulièrement. Personnellement l’aide d’un générateur de mot de passe est apprécié.

Sécurisation

Bien, nous avons notre serveur VEEAM fonctionnel et configuré. Toutefois, l’éditeur nous fournit un ensemble de bonne pratique de sécurité. Nous avons donc la possibilité de passer outre ou de nous attarder sur la sécurité de l’application.

Pour rappel et pour l’avoir dit précédemment (ou quitte à être gâteux avant l’âge), la sauvegarde représente un enjeu majeur et stratégique des organisations. Les chaines de sauvegarde et le respect des bonnes pratiques relatives à l’infrastructure de backup constituent le dernier bastion, rempart en cas de sinistre naturel ou criminel.

Networking

Les recommandations sont explicites, il nous suffit de n’autoriser que les flux sortant pour les protocoles et ports vers les destinations précises.

Ainsi, VEEAM recommande de n’autoriser que les ports tcp:80 et tcp:443 à destination :

Serveur de mise à jour : dev.veeam.com
Serveur de licence : authlok.veeam.com & vbr.butler.veeam.com

Il en est de même avec les serveurs de mise à jour Windows.

Là de nouveau se pose une question de sécurité. Dois je configurer le firewall du SE ou en amont sur mon Firewall ?

Si nous partons du postulat que nous avons une architecture 3 tiers avec un subnet dédié pour notre environnement de sauvegarde, les règles doivent être configurées sur le UTM⁵. Avec cette configuration, il n’est donc pas nécessaire de configurer le firewall windows de notre serveur de backup.

Dans le cas contraire ou n’avons pas de pare-feu, cela devient tout de suite plus complexe. Il sera nécessaire d’ajouter les policies directement sur notre SE. Sauf que, car sinon ça serait trop facile, le firewall Windows ne prend pas en charge la résolution des enregistrement DNS de type CNAME, mais uniquement des subnets, adresses IP…

Comment autorisons nous alors les *.windowsupdate.com et autres windowsupdate.com ?

A savoir que l’avantage d’un enregistrement de type CNAME est de répondre au changement des enregistrements de type A…

Oh p’tain t’es en train de nous dire qu’il faut se palucher toutes les ips et subnets à la main ? T’es un grand malade !

Malheureusement pour les enregistrements wildcard, pas d’autres solutions pour les enregistrement CNAME, nous pouvons toujours passer par nslookup ou Resolve-DNSName.

Ce qui nous donnerai

Toutefois, cela ne répond pas à la problématique d’un potentiel changement d’adresse IP lié à un enregistrement de type A ou CNAME. C’est pourquoi j’ai fait un nouvelle fois appel à ma feignantise, j’ai fait un script qui vient mettre à jour automatiquement les règles de firewall.

Mais pour le coup, je ne vais pas être totalement transparent et je vais garder certaines modifications pour moi 🙂 Peut-être que je partagerai ces points selon mon humeur. J’entends déjà les « Merci co****d », je répondrai, « Merci MONSIEUR co****d 🙂 »

Si dans le point précédent nous étions vigilant sur les flux sortants pour éviter une potentiel évasion de datas. Il convient d’être vigilant sur une potentiel intrusion.

Dans le cas du management de VEEAM par les produits VSPC ou VCC, il sera nécessaire d’autoriser les connexions entrantes et sortante sur les ports tcp:6179-6180 par défaut. Sans quoi, il sera difficile de manager le serveur VEEAM.

La question de l’autorisation du service TermService se pose. Il doit être désactivé mais est nécessaire pour la VCC. Il est donc nécessaire de penser en bon père de famille et de mesurer le rapport bénéfices/risques.

Il convient d’activer le chiffrement réseau sur notre réseau privé. Oui mais pourquoi faire donc dirait l’autre ?

Par défaut, le chiffrement réseau est actif pour les réseaux publiques. Toutefois, pour se prémunir d’une potentiel écoute sur notre bulle de sauvegarde (et autre subnet), activer le chiffrement des flux réseaux va permettre de chiffrer les connexions lors du transfert de données vers le service VEEAM Data Mover.

Ainsi lors de l’exécution d’un job de sauvegarde, les données seront chiffrés avant d’être envoyé transférées.

Là où ça devient intéressant c’est que nous pouvons activer ou non du Throttling :p Il est également possible de définir directement un subnet.

Attention néanmoins car cela peut engendrer une latence considérable sur le réseau. VEEAM recommande de désactiver l’option dans le cas de nombreux jobs ou d’équipements qui pourraient être vite « surchargés ».

Ce point est logique, mais pas utilisable pour tout le monde… Ah bon ? Oui, cette fonctionnalité n’est pas disponible dans la Community Edition. Toutefois il suffira de suivre le guide pour implémenter cette bonne pratique.

Il en sera de même pour la fonctionnalité 4-yeux (non je ne vise pas les personnes ayant des problèmes de vue… ou de JANNUS). La fonctionnalités Four Eyes Authorization (disponible uniquement en Entreprise Plus) permet de demander un double validation lors d’action de suppression. Ce qui en cas d’acte malveillant ou de compromission du server de backup de protéger les datas. A condition d’avoir au minima deux comptes de contrôles avec le profil Administrateur.

Par défaut, VEEAM utilise un certificat autosigné pour garantir le chiffrement des connections entre les composants de l’infrastructures de sauvegarde.

Il est possible d’installer un certificat tiers si besoin. Etant pour un usage interne sans publication, il n’est donc pas « gênant » d’utiliser le certificat autosigné.

Le classique des classiques, et je ne parle pas d’un burger signature de chez X ou Y ! Rare sont ceux qui ferment leurs sessions de travail, alors imaginer les sessions de la console VEEAM ?

Personnellement, lorsque j’interviens pour un dysfonctionnement de sauvegarde et que je me retrouve en direct sur un ordo, j’ai comme des envies de meurtres. Promis, je lance une résurrection après, puis je récidive 🙂

Nous pouvons donc et je recommande d’activer la déconnexion en cas d’inactivité pour assurer la sécurité sur la console d’administration.

Ici, deux cas de figure.

Le premier, vous n’avez pas fait d’installation personnalisée. Dans ce cas, vous allez directement Aux Six Roses vous en jeter un petit derrière la cravate. Dans le cas contraire, il va falloir revoir les ACLs⁶ des répertoires créés précédemment pour le VBRCatalog et le NfsDatastore.

Dans la logique, nous avons par défaut :

Si nous voulons éviter un potentiel escalade de privilège et d’exécutions de code malveillant, VEEAM recommande d’appliquer les droits suivants :

Compte	ACL	Scope
Administrators	Full control	This folder, subfolders and files
SYSTEM	Full control	This folder, subfolders and files
CREATOR OWNER	Full control	Subfolders and files only
Users	Read & Execute	This folder, subfolders and files

Lien

Ce qui nous donnerai par exemple :

Il convient de ne faire confiance à personne. C’est pourquoi dans le cas des machines LINUX (postes ou serveurs), il est important de ne pas faire confiance à ces équipements d’approuver manuellement ces derniers.

Ainsi il sera plus facile d’identifier un loup au milieu du troupeau.

Databases

Attention, ouverture d’une porte ouverte à grand coup de deltoide dans 3, 2, 1… BAM ! Naturellement tout le monde doit avoir accès à la base de données MSSQL Express ou PostreSQL avec ALL GRANT PERMISSIONS !

#ironie #seconddegres #commedisentlesjeunes

Bien sûr que non. L’accès au serveur de sauvegarde ou qui héberge le ou les bases de données doit être réglementé, sur le principe 3Tiers, avec compte nominatif. Les éléments contenu dans l’application autant que dans le SGBD sont sensibles et hautement critique.

Les questions que nous devons nous poser sont, qui doit avoir accès aux serveurs ? Avec quel niveau de permission ? Sur quelle période ?

Comme abordé précédemment, il est d’une importance cruciale de réaliser une sauvegarde de la configuration de notre serveur. Toutefois les informations contenus dans cette dernière sont critiques et doivent être chiffrées.

Toutes sans exceptions.

Backup Repository

Pour ce point, je pense avoir été suffisamment claire précédemment. Je vous invite à vous référer à l’article du site ou plus haut.

En somme, il suffit de suivre les bonnes pratiques de l’application de la sauvegarde.

On parle de sécurité et des bonnes pratiques logiques et logicielles, mais QUID de la sécurité physique des équipements ?

Bien souvent minimiser, c’est le drame quand on découvre que trois disques ont été arrachés du serveur de stockage, qu’un disque externe ou bande a été volé ou qu’un NAS a été victime du dernier spectacle d’HOUDINI…

Je passe volontairement sur les serveurs car ces derniers doivent être dans un local dont l’accès et strictement réglementé.

La sécurité des composants est relativement large. Elle commence par la redondance énergétique pour parer à toutes coupures d’alimentation éventuelles (onduleur), d’une température et hydrométrie contrôlé (climatisation). Les équipements doivent être inaccessible (baie fermée à clef). Les disques doivent être si possible en position verrouillé dans les slots (serveur ou NAS). Les serveurs ou NAS attachés à la baie ou mobilier.

Les médias amovibles ou bandes doivent être stockés en lieu sure. Les données doivent être chiffrées dans tous les cas pour ce prémunir de vol ou de perte éventuelle.

« Jean-Mi, t’as encore laissé une VHS à la machine à café. Ah non c’est ma bande… »

L’accès au média de stockage (SAN, NAS, Serveur, CLOUD…) doivent être sous contrôle et revu périodiquement. Même si le contenu des données sauvegardées sont chiffrées (cf point plus haut).

Il convient d’autoriser uniquement l’authentification Homme et machines. Le cloisonnement et une part essentielle de la sécurité. Elle s’applique de la plus basse couche du modèle OSI (physique) jusqu’à son plus haut niveau (application).

Ainsi, l’accès aux repositories de sauvegardes doivent être restreint à l’essentiel depuis le serveur de sauvegarde comme sur le reste du SI, jusque sur les partages.

Comme pour la sauvegarde de la configuration, il convient de chiffrer l’ensemble des chaines de sauvegarde. L’objectif étant de se prémunir d’un vol physique ou logique des données.

De nouveau, les mots de passes servant au chiffrement doivent être différent et changer au minimum une fois par an.

J’ai par exemple, pris l’habitude de dédié une passphrase complexe par type de jobs. Ainsi, ma sauvegarde et chiffré avec un mot de passe différent de ma copie (externalisation), un mot de passe différent de mon hardened et de ma configuration.

Le chiffrement des flux réseaux SMB doit être actif et l’authentification doit être requis et ce pour éviter l’utilisation du protocole d’authentification NTLMv2⁷. Bien que celui ci soit déprécié depuis 2010 par Microsoft, il est rare que celui-ci soit désactivé sur les SI.

L’immuabilité est maintenant devenu un standard pour se prémunir des attaques de type rançonlogiciel et de la suppression des chaines de sauvegarde. C’est pourquoi il devient nécessaire de configurer les repositories soient avec les technologies :

Hardened (immuabilité native)
Stockage S3 (stockage objet, mais peut on vraiment parler de vrai immuabilité ?)

Bref, comme toutes choses évoluent avec le temps, l’immuabilité va devenir le standard de demain.

Néanmoins cela ne protège pas d’une suppression physiques des LUNs⁸ et autres volumes ou « d’arrachage physique » des disques sur les médias.

La sauvegarde offline ou hors-ligne si nous souhaitons appliquer la loi AllGood consiste à se prémunir de la corruption logique ou physique des supports contenant les sauvegardes du SI de production et de garder une sauvegarde inaccessible puisque déconnectée.

Plusieurs possibilités dans ce cas, soit le bon vieux jeu de rotation sur média externe (HDD) incluant le chiffrement des chaines de sauvegarde. Ce qui est je pense le meilleur compromis pour les PMEs et MEs. Où dans le cas d’hébergement une sauvegarde sur bande (Tape) avec serveur rotatif.

Je note un bémol sur le Tape storage. L’un des points bloquant restent la durée de vie des robots et la capacité de stockage des bandes. Dans le cas d’un Cloud Provider (comprendre fournisseur d’hébergement privé), le stockage peut vite évoluer à la hausse et donc cela peut devenir contraignant concernant le capacité de stockage et son évolutivité. Néanmoins, le Tape storage reste l’un des moyens les plus fiables et sécurisés pour une sauvegarde hors-ligne (point de vu personnel, à vous de me triquiter).

Pour se point, je renvoie au guide général de la sécurité (ici). Normalement et dans la logique, une grande partie est traitée dans le cadre du durcissement d’une SE Windows et dans les points de recommandations VEEAM qui sont abordés dans la partie suivante.

En règle générale, je dirai qu’il ne faut pas prendre pour argent comptant les acquis et de se remettre en question en permanence pour garantir un niveau de sécurité le plus élevé possible sans pour autant être trop restrictif. Il faut tout de même pouvoir bosser de temps en temps. 🙂

Security & Compliance Analyser

Comme j’ai du déjà le dire précédemment, depuis la version 12, VEEAM à mis à disposition un petit outil dans la console qui permet de vérifier si les bonnes pratiques et recommandations sont appliqués à l’environnement ainsi qu’à l’application. C’est une nouvelle fois super en terme de MCO⁹. Naturellement, un guide existe et une nouvelle fois, je ne compte pas paraphraser toute la section qui aborde le sujet. Mais il convient de s’y attarder un petit peu. 🙂 Pour le reste => Lien.

L’outil aborde deux sections de sécurité. La première concerne l’environnement de sauvegarde et la seconde la configuration du produit. Pour plus de simplicité nous distinguerons les deux sections dans un module « accordéon« .

Une fois la console VEEAM démarré et que nous sommes authentifiés, dans le bandeau, sélectionnez l’application Security & Compliance Analyser

Ce qui nous donne une jolie petite windows avec le résultat de l’analyse de sécurité de notre système. Si le système n’a pas été durci vous devriez avoir l’affichage suivant.

C’est dans la version 12.2 que le point N°12 et N°13 font leurs apparitions. Toujours plus de sécurité, encore plus !

Bon, on s’y met ? 😀

Backup Infrastructure Security

Pour des raisons de sécurité il convient de ne pas activer le service de Connexion du bureau à distance. De cette façon, nous nous assurons que sur notre infrastructure, PERSONNE ne pourra accéder au serveur de sauvegarde en dehors de l’accès physique ou local.

Toutefois (car il y a un toutefois), le service doit ou peux rester actif dans le cas où le serveur de sauvegarde est connecté à une VCC¹⁰. Dans ce cas de figure, il est possible à l’équipe de gestion des sauvegardes ou SysAdmin de se connecter au serveur via RDP¹¹ de manière sécurisé depuis le serveur VCC vers le serveur de sauvegarde (port tcp:[6179:6180]).

Nous ferons abstraction du cas de la VCC et désactivons le service.

> Set-Service -Name TermService -StartupType Disabled

Le nom est équivoque. Ce service permet lorsqu’il est actif, de permettre aux utilisateurs de modifier la base de registre à distance sur les machines (ordinateurs ou serveurs).

Le risque ainsi que l’impact sont assez conséquent pour ignorer ce service et ne pas l’activer.

> Set-Service -Name RemoteRegistry -StartupType Disabled

Le service WinRM¹² est également aussi sensible que les deux services précédent. Puis qu’il permet d’administrer à distance les machines sur lequel il est actif. Donc un accès au serveur de sauvegarde…

On coupe !

> Set-Service -Name WinRM -StartupType Disabled

Ca parait évident, mais sachez que beaucoup pour ne pas dire TROP de SysAdmin désactive ce dernier sur l’ensemble de tous les profils. Oui car il est plus facile de désactiver le parefeu que de faire une régle InBound ou OutBound…

Personnellement, j’ai constaté à maintes et maintes reprises ce cas de figure sur des serveurs applicatifs. D’ailleurs, si nous ouvrons une parenthèse, je pose la question qui est responsable de la vulnérabilité d’un serveur applicatif ?

L’éditeur qui a installé et qui fait assure le MCO du logiciel ?
Le prestataire ou l’équipe informatique ?

L’éditeur vous dira, que ce n’est pas lui qui gère le réseau et le système et le prestataire ou l’équipe informatique vous diront que c’est applicatif et qu’ils ne touchent pas au système pour ne pas créer de dysfonctionnements quant aux dépendances systèmes et les applications en place. A méditer… Je clôture cette parenthèse après avoir semer le doute. (Pour ceux qui commence à flipper, je répondrai « De rien »).

> Set-NetFirewallProfile -Name Public -Enabled $true
> Set-NetFirewallProfile -Name Private -Enabled $true
> Set-NetFirewallProfile -Name Domain -Enabled $true

C’est une fonctionnalité super pratique sur nos postes utilisateurs car il permet de répondre à notre fénéantise. Cette fonctionnalité permet de garder en cache les mots de passe.

Pratique ne veux pas dire sécurisé comme le disait un collègue.

Donc le risque de retrouver un mot de passe en clair ou juste masqué sur un serveur de sauvegarde revient à aller aux p***s sans capote(s) et pleurer d’avoir attrapé une chaude p***e des familles. Alors, qu’est ce qu’on fait ? On désactive naturellement.

The value of the HKLM\System\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential registry key is set to 0.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Le WPAD¹³… Il permet à toutes machines de localiser de manière automatique le fichier de configuration d’un serveur mandataire. Ce fichier de configuration est critique car en cas d’altération de celui-ci par un individu malveillant, ce dernier se placerai entre les ressources et le serveur mandataire (MitM¹⁴).

L’utilité d’une telle fonctionnalité sur notre serveur de sauvegarde n’est pas utile. Ca dégage.

> Set-Service -Name WinHttpAutoProxySvc -StartupType Disabled

The value of the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\DisableWpad registry key is set to 1.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Ce point est assez logique. Il convient désactiver les protocoles de chiffrements obsolètes.

Toutefois, suivant les SEs (récent) certains de ces protocoles ne sont pas présents. Logique, pourquoi installer des protocoles qui sont obsolètes ? Sauf si nous les avons déployés manuellement pour un usage spécifique. De mon point de vu, il est difficilement justifiable sur un serveur de sauvegarde jugé hautement critique.

Ce point est donc difficilement atteignable sans « tricher ».

Par exemple sur un serveur WS 2016, les protocoles TLS 1.0, TLS 1.1, SSL 3.0 n’ont pas d’entrée dans la base de registre tout comme les clés de registre Server et Client.

De ce fait, le status Unable to detect apparaitra en Warning. C’est dommage.

Pour obtenir le statut en Success, il conviendrait donc de créer les clés de registre ainsi que les valeurs attendu.

WSH¹⁵ est un ancien système d’exécution de code. Il est normalement plus ou peu utilisé car remplacé par Powershell ou le framework .NET. Néanmoins, laissé ce dernier actif permettrai d’exécuter du code et d’altérer le système en accédant à des composants COM/ActiveX. Il n’est donc pas nécessaire de garde ce dernier actif.

The value of the HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings\Enabled registry key is set to 0.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Le protocole de partage de ressource (SMB¹⁶) dans sa version 1.0 est faillible car il n’inclus les mécanismes de sécurité que nous connaissons maintenant et donc il est facilement sujet au MitM.

La seule explication plausible pour voir ce dernier actif resterait l’usage d’une vieille application ne supportant pas le protocole dans sa version 3. Comme toujours il n’a rien à faire sur un serveur de sauvegarde et combien même ça serait le cas pour un très très vieux équipements jouant le rôle de repository, il y aurait un trou dans la raquette. Les calculs sont pas bon Kévin !

> Set-SmbServerConfiguration -EnableSMB1Protocol $Status

LLMNR¹⁷ pour les intimes, protocoles de résolution de noms. Ce dernier offre la possibilité d’effectuer localement la résolution de noms. Dans le cas d’un échec de résolution DNS, ce dernier peut être amené à être utilisé. Soit, il est facilement exposé au MitM et aux poisoning.

Il est préférable de le désactiver.

The HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\EnableMultiCast registry key exists. The value of the key is set to 0.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Si nous reprenons le point numéro 9, il convient d’activer et de forcer l’usage du protocole SMBv3 si et seulement si nous sommes amenés à utiliser ce dernier. Néanmoins, il vaut mieux prévenir que guérir. Surtout si nous sommes plusieurs à intervenir sur l’infrastructure de sauvegarde. Et un oublie et vite arrivé malheureusement…

La configuration de celui-ci se fait par l’activation du chiffrement des Data, l’activation de la signature de sécurité et nécessitant une signature de sécurité.

> Set-SmbServerConfiguration -RequireSecuritySignature $true
> Set-SmbServerConfiguration -EncryptData $true
> Set-SmbServerConfiguration -EnableSecuritySignature $true

Si nous nous basons sur la page technet, Microsoft recommande de protéger le service LSASS¹⁸ afin d’offrir « une protection renforcée pour le processus de l’autorité de sécurité locale (LSA) afin d’empêcher toute injection de code qui pourrait compromettre les informations d’identification« .

VEEAM se basant sur cette recommandation (présente depuis WIN 8.1 et WINDOWs Server 2012) d’activer le Lock UEFI ainsi que le secure BOOT. C’est pas déconnant et il fallait y penser. <3

The value of the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL registry key is set to 1 or 2.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Afin de réduire encore davantage l’exposition de notre serveur de sauvegarde, il est recommandé de désactiver NetBios sur l’ensemble des interfaces. L’objectif est d’éviter une possible fuite de données depuis un répertoire partagé.

Par défaut et pour l’avoir vérifier, ce dernier est à 0 (soit actif). Comme nous l’avons fait pour LLMNR au point N°10, il convient de désactiver ce dernier est définissant la valeur à 2.

The value of HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID}\NetbiosOptions registry keys is set to 2.
Veeam Backup & Replication 12
User Guide for VMware vSphere

Normalement, si nous avons bien suivit toutes les étapes, nous devrions avoir le résultat suivant.

Sauf que voila, ça fait tâche de voir un Warning quant aux points de contrôles des protocoles SSL/TLS obsolètes. Il faudrait dans ce cas, que le contrôle ne se porte pas uniquement sur les valeurs de clés de registres mais également sur les clés de registres elles mêmes.

Ainsi, si nous trichons en créant les clés de registres manquantes et ajoutons les valeurs attendus, nous obtenons un 100%.

Est ce pourtant bien de la triche ? Je répondrai que non car aucun point n’a été supprimé ou masqué et que l’ensemble des recommandations de sécurité propres à l’infrastructure de sauvegarde a été implémenté.

De nature feignante et devant dans le cadre de mon activité professionnel déployer fréquemment des environnements VEEAM, j’ai décidé de scripter cette partie. Cette dernière sera disponible plus bas.

Product Configuration

Ce point de controle vient vérifier si oui ou non la recommandation du 1 média hors-ligne ou immuable est implémenté. Pour rappel rien n’est imposé mais recommandé. A défaut de configurer et d’administrer un repo hardened (ce qui peut représenter un investissement) selon la taille du SI, une simple sauvegarde sur disque externe avec rotation suffit.

Je ne rentrerai pas dans le détail de la configuration ici. Un billet sera dédié à l’implémentation d’un stockage hardened (immuable).

Ouai parce que même par gourmandise, je comprends parfaitement que vous lecteurs commencez à avoir des remontés quant à la longueur de cet article…

Une fonctionnalité intéressante mais non par réellement importante à mon sens. Je m’explique. La fonctionnalité de protection contre la perte des mots de passe stockés sur notre serveur de sauvegarde peuvent être perdu en cas de dysfonctionnement de ce même serveur et donc d’accès aux données.

Nos chaines de sauvegardes étant chiffrées, difficile de déchiffrer ces dernières si le mot de passe est perdu… C’est pourquoi pour des raisons de sécurité et de faciliter de gestion il est recommandé d’implémenter un VEEAM Backup Manager.

Il permet de manager plusieurs serveur VEEAM
Il stocke une copie des mots de passes et donc protège d’une perte ou suppression des éléments secrets

Il convient toutefois de ne pas mutualisé le serveur manager avec le serveur de sauvegarde (cela n’a pas de sens et nous tombons vite dans le cas du serpent qui se mord la queue) et de déployer le rôle et les fonctionnalités sur un serveur dédié.

Dans mon cas et je n’ai qu’un seul serveur de sauvegarde (et surtout pas de licence), je n’ai pas d’intérêt à déployer ce rôle. Les éléments secret sont comme vous vous en doutez sont stockés dans un bloc-note nommé MOTDEPASSE_SAUVEGARDE.txt sur mon bureau utilisateur. :p

Mais c’est qu’il pense être comique le garçon ! (Oui mais Comic san MS)

Les éléments de confiance sont stockées dans un gestionnaire de mots de passe (type LastPass, KeyPass, Keeper, Dashlane etc…). Ainsi je ne mets pas tous mes oeufs dans le même panier.

Néanmoins, l’outil de contrôle lui ne sait pas tout ça. Et comme je n’ai pas les ressources nécessaire pour implémenter un VEEAM Backup Manager, j’accepte le point de non compliance, mais répond toutefois à ce dernier.

Le serveur de sauvegarde ainsi que l’ensemble des éléments propres à la sauvegarde ne doit pas être au domaine. Cette recommandation vise à garantir un niveau de sécurité plus important dans le cas où une compromission ou intrusion sur la bulle d’administration, management venait à avoir lieu.

Quitte à être sénile encore une fois, la sauvegarde doit être le dernier bastion et doit être imprenable.

Les notifications doivent être configurées. Pourquoi ? Je reçois déjà suffisamment de mail tous les jours.

Je dirais plusieurs raisons :

S’assurer que la sauvegarde de la configuration se fait bien sur la période indiquée et que cette dernière est valide
S’assurer que l’ensemble des tâches de sauvegardes (et de vérification) se déroulent sur la période indiquée et en succès
S’assurer que l’infrastructure de sauvegarde est saine

Les notifications permettent de garder et d’être garant du bon déroulement de la sécurité de son SI.

Merci Captain Obivious

Toutes les éléments protégés doivent répondre au minima à la règle des 3-2-1. Je passe mon tour sur le détail de ces points et vous laisse remonter plus dans dans ce billet sur la description de chaque point.

Un point qui me chagrine beaucoup… La Reverse Incremental (nous l’appellerons RI¹⁹) est déprécié au détriment de la Forward Incremental (nous l’appellerons FI²⁰) ou de la Forward Forever Incremental (nous l’appellerons FFI²¹).

Il est déjà je pense important de comprendre les deux types de fonctionnement.

La RI garde en dernier point de sauvegarde (le plus récent) une full dans laquelle le dernier point d’incrément est ajouté. Le point d’incrément de la veille est donc relayé comme maillon précédent de la chaine et les blocks modifiées sont ajoutés dans la full.

Ce type de sauvegarde permet une restauration plus rapide et un gain de place sur le repository de stockage au détriment d’I/O plus élevés. Ce qui rend donc le processus de sauvegarde plus lent. Donc une baisse des performances possible.

A l’inverse, la FFI garde en premier point de sauvegarde (le plus ancien) une full dans laquelle va venir se déverser l’incrément de la veille. Ainsi le dernier point de sauvegarde est donc toujours un incrément.

Cela permet donc de limiter les I/O sur le repository est donc un gain de performance. Toutefois si l’un des incréments est corrompu, l’ensemble de la chaine peut être corrompu. Le seul moyen de prévention serait donc le SureBackup ou d’implémenter la sauvegarde FI avec du GFS²².

L’inconvénient, c’est que nous nous retrouvons avec 3 fulls. Soit une consommation supplémentaire des ressources de stockage.

Personnellement j’ai une préférence pour la RI. Car le risque de corruption de chaîne est plus faible au détriment des performances (I/O) liés au repository tout en garantissant une optimisation de l’espace de stockage.

Je dirai que pour cette recommandation, il faut s’adapter au contexte dans lequel nous travaillons au quotidien. VEEAM recommande, mais tout dépendra de notre infrastructure ainsi que de l’activité de notre organisation et des ressources à notre disposition.

Je prendrai le temps dans un prochain article de faire un benchmark pour un même job de comparer les performances de chaque type de sauvegarde.

Cette recommandation part du postulat que nous ne devons faire confiance à aucun device linux. Dans le cas contraire, les équipements linux peuvent contacter en SSH le serveur de sauvegarde. Si la fonctionnalité d’approbation est activée, il sera nécessaire d’approuver les équipements afin que ces derniers puissent se connecter une fois leurs empreintes ajoutées.

Comme pour le point numéro 3 concernant la protection des mots de passe et des éléments sensible, il revient de sauvegarder la configuration de notre serveur de sauvegarde sur un emplacement autre que le serveur de sauvegarde.

Point logique, mais souvent négligé. Ainsi en cas de perte de notre serveur de sauvegarde (maj windows foireuse par exemple), il nous suffira de créer un nouveau serveur de sauvegarde puis de recharger la configuration précédente.

Et hop, le tour est joué.

L’ensemble des flux entre le serveur de sauvegarde et les proxys VEEAM doivent être chiffrés et ce même si nous sommes dans le même subnet.

Pourquoi ? Nous ne sommes pas à l’abris d’écoute ou d’interception des données lors de l’exécution des jobs de protection.

Retour à notre sauvegarde hardened ou immuable. Le repository qui va contenir, stocker nos données sauvegardées doit être un média physique et non pas une VM ou autres environnements conteneurisés.

La raison me semble évidente, nous n’allons pas sauvegarder des données et rendre ces dernières immuables sur une ressource virtuelle qui pourraient être supprimée en un clic ou une ligne de commande.

Oui mais toi c’est bien ce que t’as fait non ? Oui car je n’ai pas de repo. Toutefois, si on m’offre le repo physique, je vous promet que je valide ce point de recommandation #coeuraveclesmains

Par défaut, le traffic sortant vers internet est chiffré (TLS). Néanmoins, il est recommandé de chiffrer également le trafic sur le LAN entre la bulle de sauvegarde est les autres bulles (subnets). Ainsi, les données sensibles sont chiffrées lors des échanges de data.

Cela peut entrainer une baisse des performances et générer un goulot d’étranglement au niveau du réseau en gérant de la latence.

Nous retrouvons une nouvelle fois l’un des classiques des environnements GNU Linux concernant l’authentification. Il est préférable de ne pas utiliser l’authentification de base mais l’authentification par clé.

Toujours pour les mêmes raisons d’une potentielle attaque de MiTM le risque est donc plus faible.

Il est possible de faire démarrer et tourner les services VEEAM avec un compte local différent. Toutefois, il relève de la bonne pratique de laisser le compte System Local gérer ces derniers. Restons Simple, Standard et Sécurisé et évitons les Shit In, Shit Out et Shit Stay ! La règle des 3S 🙂

Qui dit configuration dit informations sensibles. Pour se prémunir d’une fuite du fichier de configuration, il convient une nouvelle fois de chiffrer cette dernière.

Un de mes anciens collègues criait toujours haut et fort (et je pense qu’il perpétue toujours cette transmission orale) que les mots de passes c’est comme les slips/culottes (pour la parité de la gente féminine dans l’IT) ça se changent !

Dans certains cas d’infrastructures complexes, il est difficile de changer un mot de passe sans générer un minimum d’impact. C’est pourquoi, le changement de mot de passe doit être pris comme un changement important.

VEEAM recommande un changement au minimum annuel, personnellement j’aime le faire semestriellement quand il me reste une once de temps.

Pour plus de sécurité de notre sauvegarde immuable et donc s’assurer que l’ensemble des données stockées sur ce dernier soient limitées en terme d’exposition. Il convient de désactiver le daemon SSH est d’activer ce dernier que lors de tâche de MCO.

Après si le repo immuable est dans un subnet différent avec des règles de par feu interlan strict, la désactivation du service n’est pas obligatoire. Personnellement, je dirai qu’il vaut mieux prévenir que guérir.

Chacun voit midi à sa porte.

Sur ce point là, je ne vais pas vous mentir, je suis Candide. Le guide recommande d’activer l’option de rétention pour les stockages objets.

Je n’utilise pas encore de stockage objets, mais cela ne serait tardé dans un prochain billet 🙂

Toujours dans la logique et la même dynamique. Ce n’est pas parce que c’est dans le cloud que c’est super secure, bien au contraire. Donc une nouvelle fois, nous nous devons de chiffrer les données sauvegardées et protégés sur les repos dans le « nuage ».

Une évidence, mais pas pour tous les SysAdmins… Si j’étais patron, je demanderai à mon responsable IT de me montrer la preuve que tout mon parc est à jour. S’il y a des gérants qui parcours cet article, vous pourriez être étonné du résultat quant à votre SI.

Personnellement, je n’aime pas implémenter la dernière mise à jour d’une solution dans l’immédiat et préfère soit garder une version d’écart ou attendre 3 à 4 semaines avant d’appliquer la dernière version/patch.

Ainsi, si une mise à jour vient à générer un dysfonctionnement, je ne suis pas impacté et laisse donc « les autres essuyer les plâtres ».

C’est très courageux comme démarchent, bravo.

Oui, je reconnais c’est pas super, mais quitte à sortir une excuse… Etant en permanence en flux tendu sur divers projets, il est compliqué en cas de dysfonctionnement de la sauvegarde d’être sur plusieurs front à la fois. Et comme la sauvegarde c’est priorité 0 si ce n’est -1. Je préfère qu’il n’y est pas de bug. J’ai une mention particulière et remercie chaudement les SysAdmins qui implémentent les dernières MAJs et vont remonter les bugs à ma place.

Github

/!\ Attention /!\ : Le script dans sa version 1.0.2 contient deux dysfonctionnements et restent en statu béta, alpha. Il manque les blocks de descriptions des fonctions, et l’optimisation des points 7 et 10. D’autres fonctionnalités viendrons s’ajouter. Comme indiqué, le travail de R&D reste sur mon temps perso et donc ne me permet pas de « livrer »/ »mettre à disposition » une solution propre clé en main. Avant d’appliquer le script, je vous recommande un snapshot à froid de votre serveur VEEAM.

Miaou

Conclusion

C’est encore un gros billet que tu nous sors là Père GUILLEMARD ! Hé, oui mon gars ! Félicitation si t’as pas décroché entre temps. Je penserai à te donner un succès Gold ou Platinium sur le PlayStation Store 🙂

Plus sérieusement, je n’avais JAMAIS poussé aussi loin la configuration et la sécurisation d’une infrastructure VEEAM B&R. Et encore, par manque de ressource sur ma petite machine, je n’ai pas poussé le vice à déployer un WAN Accelerator et un Proxy VEEAM (m’enfin dans la logique c’est pas super compliqué il faut juste de la rigueur et du bon sens). Comme nous sommes dans la confidence, je dirai même que j’ai le sentiments d’être un imposteur quant aux infrastructures VEEAM que j’ai pu déployer. C’est un peu le fameux « Nan, mais je sais » alors qu’en réalité je ne savais pas.

VEEAM nous offre dans ces versions de nouvelles fonctionnalités toujours plus poussées et orientées sécurité. Il est difficile (par manque de temps peut-être ?) de suivre toutes ces nouvelles fonctionnalités d’une version à une autre et donc de se remettre en question et de modifier en bien nos infrastructures. Pour autant, cela fait il de moi un charlot ? Egalement ce qui doit être souligné, c’est que VEEAM en plus de prodiguer les bonnes pratiques met à disposition des outils pour suivre l’état de santé des services dans ces solutions pour rester le plus performant possible.

La sauvegarde et l’ensemble de son écosystème représente le dernier bastion des systèmes d’informations. La bonne gestion de cet écosystème permet de se prémunir de sinistre matériel, infrastructure ou d’attaques informatiques et de pouvoir repartir dans des délais acceptable selon le RTO établi. Dans le cas contraire, des mots durs et difficiles à entendre peuvent apparaitre « dépôt de bilan », « licenciement », « perte financière », « cessation d’activité »… Welcome to Amish Paradise

Il ne faut pas négliger la sauvegarde.

Et j’inviterai chaque dirigeant ou directeur des systèmes d’informations à demander un rapport d’audit de leur infrastructure de sauvegarde de manière ponctuelle. De plus les KPIs²³ de l’ensemble des jobs de sauvegardes devraient être présenté dans des rapports et revues hebdomadaires, mensuelles et annuelles.

Dans les perspectives d’évolutions et le pourquoi de cette article, VEEAM DR (ou Backup & Réplication) va me permettre de poursuivre avec d’autres articles, notamment la VCC, VSPC, Repo Hardened, Repo Stockage S3 ainsi qu’une passerelle entre VEEAM et ITOP concernant le MCO des sauvegardes journalières.

Le mot de la fin :

C’est un coup des russes ? Alerte Générale !!! Ah pardon, mais vous étiez en case mandoline. Vous reculez de 3 GFS et vous restaurez chez LAMELOISE. Pensez à la NDF.
Erwan GUILLEMARD

Sources

RTFM : Read The Fucking Manuel ↩︎
PAS : Plan d’Assurance Qualité ↩︎
CE : Community Edition ↩︎
FIPS : Federal Information Processing Standard ↩︎
UTM : Unified threat management ↩︎
ACLs : Access Control List ↩︎
NTLMv2 : Network Lan Manager Version 2 ↩︎
LUNs : Logical Unit Number ↩︎
MCO : Maintient en Condition Opérationnelle ↩︎
VCC : VEEAM CLOUD CONNECT ↩︎
RDP : Remote Desktop Protocol ↩︎
WinRM : Windows Remote Management ↩︎
WPAD : Web Proxy Auto-Discovery ↩︎
MiTM : Man In The Middle ↩︎
WSH : Windows Script Host ↩︎
SMB : Server Message Block ↩︎
LLMNR : Link-Local Multicast Name Resolution ↩︎
LSASS : Local Security Authority Subsystem Service ↩︎
RI : Reverse Incremental ↩︎
FI : Forward Incremental ↩︎
FFI : Forward Forever Incremental ↩︎
GFS : GrandFather – Father – Son ↩︎
KPIs : Keys Performances Indicators ↩︎

Sinistre Site principal	Sinistre Sites Secondaires