Le rôle de la segmentation dans Zero Trust

Zero Trust est souvent associé à la vérification d’identité, à l’accès au moindre privilège et à l’authentification continue. Chez Object First, nous partons d’un état d’esprit « Assume Breach », en reconnaissant que des attaquants peuvent déjà se trouver à l’intérieur de l’environnement. Sous ces principes se cache une autre exigence qui reçoit beaucoup moins d’attention : la segmentation. 

À mesure que les organisations consolident leur infrastructure pour réduire la complexité opérationnelle, comprendre ce qui doit rester séparé devient de plus en plus important. Dans une architecture Zero Trust, la segmentation ne se limite pas à la séparation physique. Elle peut aussi être définie via des zones de sécurité et de résilience, des frontières de confiance, des contrôles administratifs et des chemins de communication strictement restreints. L’objectif est de garantir que, même si des attaquants compromettent des identifiants, des comptes à privilèges ou d’autres secrets de sécurité, ils ne puissent pas exploiter ces compromissions pour modifier ou détruire des données de sauvegarde protégées. 

Cette approche permet aux logiciels de sauvegarde et aux systèmes de stockage de fonctionner ensemble sans violer les frontières de sécurité requises. Une architecture de sauvegarde Zero Trust exige donc des frontières de confiance claires, des chemins de communication bien définis et un stockage qui reste immuable et protégé même lorsque d’autres couches de l’environnement ont été compromises.  

Segmentation, immutabilité et air gap logique répondent à des objectifs différents 

La segmentation, l’immutabilité et l’air gap sont souvent abordés ensemble, mais ils résolvent des problèmes différents. La segmentation établit des frontières de confiance. Son objectif est de contenir une compromission et de restreindre les mouvements latéraux entre systèmes. Immuabilité protège les données de sauvegarde contre la modification ou la suppression. L’air gap logique crée une séparation entre environnements afin de limiter l’exposition. 

Une solution de stockage de sauvegarde peut être immuable sans être correctement segmentée, et elle peut être segmentée sans être isolée par air gap. Une cyber-résilience solide dépend de la compréhension du rôle joué par chaque contrôle. 

Dans un cadre Zero Trust, la segmentation répond à une question fondamentale : si un composant est compromis, qu’est-ce qui reste protégé ? Pour les environnements de sauvegarde, cette question est particulièrement importante, car l’infrastructure de sauvegarde est de plus en plus interconnectée avec les systèmes de production. 

L’environnement de sauvegarde contient plusieurs zones de confiance 

De nombreuses organisations traitent l’infrastructure de sauvegarde comme un système unique. Du point de vue de la sécurité, plusieurs zones de confiance distinctes existent au sein d’une architecture de sauvegarde moderne. 

Les applications de production occupent une couche. Le logiciel Sauvegarde en occupe une autre. Le stockage de sauvegarde immuable constitue la couche la plus interne, car il sert de fondation à la restauration. 

Le modèle en oignon des zones de confiance 

Un modèle en couches, façon oignon, aide à illustrer ces relations. 

Au centre se trouvent les données sauvegarde immuable. Autour d’elles se trouvent les applications de sauvegarde, les charges de travail de production, les hyperviseurs, les plateformes de stockage, les outils d’administration et les systèmes de gestion. Chaque couche fonctionne selon des hypothèses de sécurité différentes. 

Les environnements de production exigent que des administrateurs provisionnent des systèmes, suppriment des charges de travail, modifient des configurations et réalisent des tâches opérationnelles. Ces privilèges sont nécessaires au quotidien, mais ils créent aussi du risque. Zero Trust reconnaît cette réalité et part du principe que des identifiants finiront par être compromis. 

Certains modèles de sécurité se concentrent sur la prévention de la compromission. Une stratégie de restauration Zero Trust suppose que la compromission a déjà eu lieu et pose une autre question : qu’est-ce qui survit ensuite ? 

La réponse doit toujours inclure les données de sauvegarde. 

Le logiciel Sauvegarde nécessite un accès à la production, mais une frontière de confiance distincte 

L’un des concepts les plus importants en sécurité des sauvegardes est de comprendre le rôle du logiciel de sauvegarde. 

Le logiciel Sauvegarde est souvent perçu comme faisant partie de l’environnement de restauration. Sur le plan opérationnel, toutefois, il partage de nombreuses caractéristiques des systèmes de production. Il nécessite un accès à privilèges, interagit avec plusieurs plateformes et peut exécuter des actions administratives puissantes. 

Si des attaquants prennent le contrôle du logiciel de sauvegarde, ils peuvent désactiver des tâches, modifier des politiques, supprimer des paramètres de rétention et perturber les processus de restauration. 

Pour cette raison, le logiciel de sauvegarde doit être considéré, du point de vue de la confiance, comme faisant partie de la couche de production au sens large. 

Cette hypothèse influence la conception des architectures Zero Trust. La restauration ne peut pas dépendre du fait que le logiciel de sauvegarde reste non compromis. La restauration doit dépendre du fait que le stockage de sauvegarde reste inchangé même si le logiciel de sauvegarde est compromis. 

Lorsque chaque identifiant est supposé exposé et que chaque compte administrateur est supposé vulnérable au phishing, stockage immuable devient la dernière couche protégeant la capacité de restauration. 

Pourquoi le logiciel et le stockage doivent rester séparés 

Une erreur fréquente consiste à traiter le logiciel de sauvegarde et le stockage de sauvegarde comme un seul domaine de sécurité. 

Lorsque les serveurs de sauvegarde ont un contrôle direct sur le stockage, un attaquant qui compromet l’application de sauvegarde peut obtenir un chemin d’accès vers les données de sauvegarde elles-mêmes. Le même risque apparaît lorsque des identités partagées, des plans de gestion ou un accès administratif non restreint s’étendent aux deux environnements. 

Une segmentation forte crée une frontière entre le logiciel de sauvegarde et le stockage de sauvegarde. La communication doit se faire via des interfaces bien définies, avec des autorisations strictement limitées. 

Ce principe devient particulièrement important à mesure que les organisations poursuivent des modèles d’infrastructure plus intégrés et plus consolidés. 

La séparation physique est une approche. La séparation logique en est une autre. Le facteur critique est de préserver des frontières de confiance indépendantes entre les composants. 

Il est également important de distinguer les domaines réseau et les domaines de sécurité. Ce n’est pas la même chose. Le logiciel Sauvegarde a souvent besoin d’une connectivité réseau étendue vers le stockage de sauvegarde afin d’écrire, lire et restaurer les données efficacement. Cette connectivité nécessaire ne signifie pas que les deux systèmes appartiennent au même périmètre de sécurité. Même lorsque l’infrastructure de sauvegarde peut communiquer directement avec le stockage au niveau réseau, leurs frontières de sécurité doivent rester distinctes. 

Un système peut résider dans la même appliance, le même cluster ou la même plateforme tout en maintenant une séparation architecturale. La communication via des protocoles définis et des modèles de privilèges limités contribue à garantir qu’une compromission dans un domaine ne se propage pas automatiquement à un autre. 

Pour les clients Object First, le protocole S3 sert de frontière clé. Le logiciel Sauvegarde interagit avec le stockage via une interface contrôlée plutôt que via un accès illimité au système d’exploitation. Cette séparation aide à préserver l’intégrité des données sauvegarde immuable même lorsque des systèmes en dehors de la couche de stockage sont compromis. 

Le défi de sécurité derrière la consolidation de l’infrastructure 

Les équipes informatiques subissent une pression croissante pour simplifier les opérations. La consolidation réduit la charge administrative, diminue la prolifération des fournisseurs et rationalise la gestion de l’infrastructure. 

La virtualisation a transformé la consolidation des serveurs. Les plateformes de stockage partagées ont consolidé l’infrastructure de données. Les appliances intégrées poursuivent aujourd’hui cette tendance. 

Chaque effort de consolidation apporte des bénéfices opérationnels, comme une infrastructure partagée. Chaque effort de consolidation peut aussi supprimer des couches de séparation. Par exemple, si vous exécutez un service de stockage virtualisé sur un hyperviseur, toute personne disposant de privilèges au niveau de l’hyperviseur peut le modifier ou le supprimer. 

Les équipes Sécurité doivent donc évaluer soigneusement les décisions de consolidation. Consolider les mauvais composants peut faire s’effondrer des frontières de confiance qui protégeaient auparavant des actifs critiques. 

Le défi est particulièrement pertinent pour les environnements de sauvegarde, car l’infrastructure de restauration doit fonctionner différemment de l’infrastructure de production. Les systèmes de production sont conçus pour la disponibilité et l’efficacité opérationnelle. Le stockage Sauvegarde est conçu pour survivre à une compromission. 

Ces objectifs exigent des hypothèses de sécurité différentes. 

Les architectures réussies équilibrent l’efficacité et l’isolement en préservant les frontières qui protègent la restauration. 

Défaillances courantes de segmentation 

De nombreuses défaillances de segmentation ne sont pas causées par des erreurs évidentes. Elles résultent de décisions qui semblent efficaces sur le plan opérationnel. 

Exemples : 

• Comptes administrateur partagés entre les environnements de production, de sauvegarde et de stockage 

• Privilèges excessifs accordés aux serveurs de sauvegarde 

• Accès direct au système d’exploitation ou accès de niveau root au stockage de sauvegarde 

• Systèmes d’identité consolidés sans contrôles d’isolement appropriés 

• Plans de gestion partagés couvrant plusieurs zones de confiance 

• Interfaces de gestion matérielle laissées exposées ou insuffisamment sécurisées 

Un domaine souvent négligé concerne les technologies de gestion hors bande telles que IPMI, iDRAC et iLO. 

Ces interfaces offrent un contrôle profond de l’infrastructure au niveau matériel. Si des attaquants accèdent à cette couche, les protections situées au-dessus peuvent devenir sans objet. Les systèmes de stockage, les serveurs et les charges de travail peuvent tous être affectés via le plan de gestion sous-jacent. 

Les frontières Sécurité doivent s’étendre au-delà des applications et des réseaux. Les couches de gestion matérielle méritent le même niveau d’examen que tout autre système à privilèges. 

Vérifier la segmentation en pratique 

Les organisations doivent valider régulièrement que le stockage de sauvegarde reste isolé des identités compromises, des applications et des couches d’infrastructure. 

Les questions clés incluent : 

• Les administrateurs de sauvegarde peuvent-ils modifier les données sauvegarde immuable ? 

• Le logiciel de sauvegarde dispose-t-il d’un accès au système d’exploitation du stockage ? 

• Une identité compromise peut-elle s’étendre à plusieurs zones de confiance ? 

• Les environnements de stockage et de sauvegarde sont-ils administrés via des contrôles de sécurité distincts ? 

• Les interfaces de gestion matérielle sont-elles sécurisées et surveillées ? 

• La compromission d’un serveur de sauvegarde peut-elle modifier directement le stockage de sauvegarde ? 

Si la réponse à l’une de ces questions est oui, une segmentation supplémentaire peut être nécessaire. 

Object First renforce ces protections grâce à une architecture conçue à cet effet, qui élimine les chemins d’attaque courants. Sans exposition à un système d’exploitation généraliste, sans accès root et sans accès shell disponible pour les clients ou les attaquants, les fonctions de stockage critiques restent isolées de nombreux mécanismes couramment utilisés pour compromettre les plateformes de stockage traditionnelles. 

La segmentation protège la dernière ligne de défense 

Dans un Modèle Zero Trust, chaque couche de sécurité doit être évaluée à travers le prisme de la compromission supposée. 

Les administrateurs peuvent être victimes de phishing ; c’est toujours la méthode de cyberattaque la plus courante. Les identifiants peuvent être volés. Les applications peuvent être compromises. L’infrastructure peut tomber en panne. 

La restauration dépend du fait de garantir que la couche de stockage reste protégée lorsque ces événements se produisent. La segmentation fournit les frontières qui rendent cela possible. Elle limite les mouvements latéraux, contient la compromission et préserve l’intégrité des données immuables. À mesure que les organisations continuent de consolider l’infrastructure, la question la plus importante reste inchangée : lorsque tout autour de l’environnement de sauvegarde est attaqué, qu’est-ce qui tient encore ? 

La réponse devrait toujours être le stockage sauvegarde immuable de manière absolue. C’est le fondement de la résilience et l’objectif central de la segmentation dans une architecture Zero Trust.