La plupart des scénarios d’attaque par ransomware incluent désormais une étape qui cible les sauvegardes avant le début du chiffrement. Une fois que l’attaquant détient des identifiants d’administration, un dépôt de sauvegarde en ligne qui peut être supprimé ou écrasé n’est qu’un jeu de données de plus à détruire. Deux contrôles sont couramment proposés en réponse : un air gap qui sépare la copie de sauvegarde du réseau de production, et l’immutabilité qui empêche toute modification de la copie, même par un administrateur. Ils sont souvent présentés comme des alternatives. Ils résolvent des problèmes différents.
La vraie question est de savoir à quels modes de défaillance l’organisation doit survivre, à quelle vitesse elle doit se rétablir et quelle charge opérationnelle elle peut supporter. Cet article définit les air gaps physiques, les air gaps logiques et l’immutabilité au niveau du stockage, expose ce que chacun bloque et ne bloque pas, et décrit l’architecture en couches vers laquelle convergent la plupart des environnements matures.
Un air gap est une séparation entre la copie de sauvegarde et tout système qu’un attaquant pourrait atteindre depuis l’environnement de production. En pratique, il recouvre deux approches.
Un air gap physique place la copie sur un support qui n’est connecté à rien : cartouches de bande retirées de la librairie et conservées dans un coffre, disques amovibles expédiés hors site, ou système mis hors tension entre les fenêtres de sauvegarde. Tant que le support reste sur une étagère, rien ne peut le supprimer ou le chiffrer sans qu’une personne le manipule physiquement.
Un air gap logique garde la copie en ligne mais l’isole sur le plan administratif et réseau : un segment réseau ou un site distinct avec un routage restreint, un domaine d’identité séparé de sorte que les identifiants de production ne donnent aucun droit côté sauvegarde, une réplication tirée par le système isolé plutôt que poussée depuis la production, et une connectivité ouverte uniquement pendant les fenêtres de réplication planifiées.
L’immutabilité signifie qu’une fois un objet de sauvegarde écrit, il ne peut être ni modifié ni supprimé avant l’expiration d’une période de rétention. Sur un stockage objet compatible S3, elle est mise en œuvre avec S3 Object Lock, un mécanisme WORM (write-once-read-many) appliqué par le système de stockage lui-même. En mode compliance, le verrou ne peut être ni raccourci ni retiré par aucun utilisateur, y compris l’administrateur du stockage, pendant toute la durée de la rétention.
La propriété essentielle est l’emplacement du contrôle. Un paramètre de rétention dans l’application de sauvegarde protège contre les erreurs commises dans cette application. L’object lock au niveau du stockage protège contre quiconque atteint le stockage avec des identifiants valides, car le stockage refuse la suppression quel que soit le demandeur. Des applications de sauvegarde comme Veeam et Commvault écrivent nativement vers des dépôts object lock.
Un attaquant disposant des identifiants du serveur de sauvegarde peut émettre des commandes de suppression vers tout dépôt accessible avec ces identifiants. L’immutabilité empêche la suppression d’aboutir. Un air gap logique avec des identifiants séparés empêche les commandes d’atteindre la copie isolée. Un air gap physique rend la copie inaccessible, mais uniquement pour les supports déjà hors ligne ; les sauvegardes les plus récentes encore dans la librairie ou sur le disque de transit restent exposées.
L’administrateur malveillant ou contraint est le cas qui distingue l’immutabilité au niveau du stockage de la plupart des autres contrôles. Un air gap logique exploité par la même personne offre peu de protection. L’object lock en mode compliance en offre une, car aucun privilège sur le système ne peut le contourner avant l’expiration de la rétention. Un air gap physique protège également ici, à condition que l’accès au coffre exige une seconde personne.
Un malware qui se propage via les partages réseau ne peut pas atteindre un support sur une étagère, et un air gap logique correctement configuré le contient. L’immutabilité n’empêche pas un malware d’être écrit dans de nouvelles sauvegardes ; elle garantit que les points de restauration sains écrits plus tôt restent intacts. La perte de site est le cas inverse : l’immutabilité sur un seul site ne protège en rien contre un incendie, une inondation ou une panne régionale, tandis qu’une copie physique hors site ou un second site isolé logiquement le fait.
Aucune forme d’air gap ne détecte la dégradation des bits ; une bande dans un coffre peut se dégrader pendant des années sans que personne s’en aperçoive. Un stockage objet avec vérification d’intégrité continue répond à ce problème, et toute architecture doit inclure des tests de restauration périodiques quel que soit le contrôle retenu.
| Contrôle | Protège contre | Ne protège pas contre | Vitesse de restauration | Charge opérationnelle |
|---|---|---|---|---|
| Air gap physique (bande, support amovible, coffre hors tension) | Vol d’identifiants, propagation de malware, suppression par un initié avec double contrôle, perte de site en cas de stockage hors site | Sauvegardes récentes pas encore hors ligne, dégradation silencieuse des supports | De plusieurs heures à plusieurs jours pour la récupération, restauration séquentielle | Élevée : manipulation, transport, coffre, renouvellement des supports |
| Air gap logique (réseau isolé, identifiants séparés, réplication en mode pull) | Vol d’identifiants de production, propagation de malware, perte de site en cas de second site | Initié ayant accès au domaine isolé, mauvaise configuration, corruption des données répliquées | Rapide, en ligne | Moyenne à élevée : second environnement permanent, maintenance des identités et du pare-feu |
| Immutabilité au niveau du stockage (S3 Object Lock, mode compliance) | Vol d’identifiants, suppression par un initié, chiffrement des points de restauration existants, suppression accidentelle | Perte de site à elle seule, malware écrit dans de nouvelles sauvegardes | Rapide, en ligne, directement vers l’application de sauvegarde | Faible à moyenne : planification de capacité tenant compte de la rétention, synchronisation horaire |
Le schéma courant est hiérarchisé. La cible de sauvegarde principale est un dépôt de stockage objet immuable en ligne, sur site, souvent configuré comme dépôt durci ou niveau de capacité directement dans l’application de sauvegarde. Il reçoit chaque travail de sauvegarde, conserve les points de restauration sous object lock et sert la grande majorité des restaurations à la vitesse du disque.
Derrière lui se trouve une copie isolée de dernier recours : un second système de stockage objet immuable sur un autre site derrière un air gap logique, un export sur bande vers un coffre, ou les deux. Cette copie est rarement utilisée, une récupération plus lente est donc acceptable. Supposons qu’une organisation doive restaurer un serveur de fichiers de 40 To après un incident : elle restaure depuis le niveau immuable local le jour même, tandis que la copie isolée est gardée en réserve au cas où la plateforme principale elle-même aurait été compromise.
Ce qui suit est une orientation générale ; les exigences réglementaires et les objectifs de reprise doivent guider la décision.
Scality ARTESCA est un stockage objet S3 conçu pour la sauvegarde, avec S3 Object Lock pour assurer l’immutabilité au niveau du stockage. Dans l’architecture hiérarchisée décrite ci-dessus, il joue le rôle de niveau immuable en ligne, traitant les restaurations quotidiennes sans attendre la récupération d’un support. Son implémentation d’object lock et ses mesures de durcissement sont décrites sur la page sécurité et cyber-résilience.
ARTESCA est validé avec les principales applications de sauvegarde, dont Veeam, Commvault, Cohesity, Rubrik, HYCU et Veritas, de sorte que le dépôt immuable se configure depuis la console de sauvegarde. La liste à jour est maintenue sur la page compatibilité sauvegarde.
ARTESCA étant disponible sous forme de logiciel ou d’appliance matérielle à partir de quelques dizaines de téraoctets, une seconde instance peut être déployée sur un autre site comme copie isolée, répliquée via un chemin contrôlé avec des identifiants séparés. Cela donne l’immutabilité sur les deux niveaux et un air gap logique entre eux, avec la bande comme troisième couche optionnelle.
Commencez par rendre le dépôt de sauvegarde principal immuable au niveau du stockage, puis décidez du degré d’isolement nécessaire pour la seconde copie en fonction des scénarios de perte de site et d’initié auxquels l’organisation doit survivre.