Pourquoi Zero Trust est trop souvent simplifié à l’excès

De nombreux fournisseurs parlent du durcissement et de Zero Trust comme s’ils étaient interchangeables. Ils ne le sont pas. Le durcissement est un composant de Zero Trust, axé sur le renforcement des défenses et le contrôle de qui peut entrer. Le Zero Trust va plus loin en obligeant les équipes à partir du principe d’une compromission et à se demander ce qui se passe lorsque des attaquants entrent. 

Les attaques modernes contournent régulièrement les contrôles de durcissement via l’escalade de privilèges, le vol d’identifiants et des vulnérabilités non corrigées. Une fois qu’un attaquant atteint un niveau de privilèges élevé dans un système, la différence entre le durcissement et Zero Trust devient déterminante pour évaluer le risque et garantir la capacité de restauration. 

Le problème n’est pas que le durcissement soit sans importance ou qu’il ne fasse pas partie de Zero Trust — il en fait partie. Le problème, c’est que de nombreux fournisseurs incitent les organisations à s’arrêter au durcissement.  Ils présentent le durcissement comme Zero Trust, ce qui laisse l’organisation avec un faux sentiment de protection. 

« Les attaquants ne se contentent pas d’entrer et de s’arrêter. Ils progressent couche par couche jusqu’à atteindre les systèmes qui ont le plus de valeur. » 

Durcissement : ce que c’est et où cela aide 

Le durcissement est la réduction disciplinée du risque à l’échelle de l’environnement. Il inclut l’accès au moindre privilège, la MFA, la segmentation et la supervision — des contrôles destinés à empêcher la compromission. Ces mesures ralentissent la progression d’un attaquant et limitent le rayon d’impact lors d’une attaque par rançongiciel. 

Cependant, le durcissement repose sur un postulat : que les contrôles empêcheront la compromission. Les systèmes, équipes et infrastructures du quotidien se comportent rarement de manière aussi « propre ». Les fenêtres de maintenance introduisent des exceptions, les correctifs prennent du retard et les configurations dérivent. De plus, les attaquants ne s’appuient pas sur un point d’entrée unique. Ils enchaînent vulnérabilités, identifiants et mauvaises configurations jusqu’à atteindre un système doté d’une autorité significative. 

Les hyperviseurs, les fournisseurs d’identité et les plateformes de bases de données partagent tous la même limitation structurelle : ils nécessitent un contrôle privilégié pour fonctionner. Une fois que les attaquants compromettent ces couches, l’environnement se comporte exactement comme l’attaquant le souhaite. Cette limitation n’est propre à aucune catégorie de produit — elle est inhérente aux systèmes conçus pour une autorité opérationnelle étendue. 

Par exemple, un hyperviseur doit pouvoir créer, modifier et supprimer des charges de travail ; un système de base de données doit pouvoir modifier les schémas, les données et les autorisations. Cette puissance opérationnelle est nécessaire, mais elle signifie aussi que, dès qu’un attaquant atteint le serveur avec des privilèges élevés, cette infrastructure peut être accessible ou démantelée. La même dynamique s’applique à tous les plans de contrôle à privilèges élevés. Ces couches sont conçues pour le contrôle opérationnel, et ce même contrôle devient un passif en cas de compromission. 

Le durcissement conduit souvent à une conclusion erronée – que la compromission n’aura pas lieu. La réalité est que des compromissions surviendront, et qu’une fois qu’un attaquant atteint un système conçu pour exercer un contrôle étendu, il peut perturber ou modifier les opérations. 

Zero Trust : ce que c’est et comment cela fonctionne 

Zero Trust est souvent réduit à un ensemble de techniques de durcissement. Pourtant, Zero Trust n’est pas une liste de contrôle de mesures — c’est un état d’esprit fondé sur « Assume Breach ». « Assume Breach » signifie accepter que des attaquants entreront dans l’environnement, escaladeront les privilèges, obtiendront des identifiants et atteindront des systèmes à forte valeur.   L’essentiel est de concevoir des plans pour se rétablir après la compromission. 

C’est là que l’industrie hésite. De nombreux fournisseurs évitent la discussion « Assume Breach » parce que leurs systèmes ne peuvent pas y survivre. Le durcissement est une affirmation de sécurité confortable. « Assume Breach » ne l’est pas. Ils mettent donc en avant la MFA, la segmentation, et la détection, en évitant la question de ce qui se passe lorsque ces contrôles échouent. Le résultat est une interprétation étroite de Zero Trust qui s’arrête au moment où l’attaquant réussit. 

Zero Trust chez Object First est défini différemment : un système de stockage avec Zero Access pour exécuter des actions destructrices, de sorte qu’aucun administrateur, aucun attaquant et aucun processus ne puisse modifier ou supprimer les données de sauvegarde, même avec des identifiants complets. 

Cela est appliqué via l’immutabilité native S3, une appliance de stockage dédiée, et des contrôles Sécurisé‑by‑Design qui suppriment entièrement les chemins privilégiés. Cela empêche l’accès root, l’accès shell et les actions d’administration, y compris la suppression et la modification. 

Zero Trust doit tenir à la couche où les contrôles de durcissement ont échoué. 

Les couches de protection dans le stockage des données de sauvegarde 

La protection moderne des données ne repose pas sur un seul plan. Elle s’étend sur plusieurs couches de contrôle, chacune avec ses propres responsabilités et ses propres modes de défaillance. La superposition de sécurité de Object First est modélisée d’après le modèle de maturité Zero Trust de la CISA, qui est une manière utile de comprendre où le durcissement et Zero Trust fixent les règles. 

Identité : le premier plan de contrôle que les attaquants tentent de compromettre 

Tout commence par l’identité. Identifiants, jetons, MFA, services d’annuaire — c’est la porte d’entrée de l’environnement. Le durcissement a sa place ici, et il apporte beaucoup. Mais l’identité est aussi la couche que les attaquants ciblent le plus agressivement. Hameçonnage, vol de jetons, détournement de session et escalade de privilèges sont monnaie courante. Une fois qu’un attaquant usurpe l’identité d’un utilisateur légitime, le reste de l’environnement commence à s’ouvrir. 

Terminaux : la couche où la dérive, les exceptions et l’exploitation créent des ouvertures 

Les postes, serveurs, hyperviseurs et appliances entrent tous dans cette catégorie. En théorie, chaque équipement est durci, corrigé et supervisé. En pratique, les équipements sont l’endroit où la réalité opérationnelle s’impose : correctifs retardés, règles de pare-feu temporaires, fenêtres de maintenance et dérive de configuration. Ces écarts s’accumulent au fil du temps, et les attaquants savent les trouver. Un équipement compromis devient un point d’appui qui se fond dans les opérations normales. 

Réseaux : la segmentation ralentit les attaquants, mais ne les arrête pas 

La segmentation, la micro-segmentation et les contrôles de trafic sont conçus pour limiter les attaques par mouvement latéral une fois qu’ils ont obtenu l’accès à un système. Ils aident, mais ils n’éliminent pas le problème. Une fois qu’un attaquant dispose d’identifiants valides ou d’un jeton privilégié, le réseau devient moins une barrière qu’un ralentisseur. L’hypothèse selon laquelle la segmentation contiendra une compromission résiste rarement à un acteur malveillant déterminé. 

Applications & charges de travail : là où les privilèges se concentrent 

C’est ici que l’autorité de l’environnement commence à converger. Hyperviseurs, systèmes d’orchestration et serveurs de sauvegarde vivent tous ici. Ces systèmes doivent pouvoir créer, modifier et supprimer des charges de travail ou des tâches de sauvegarde. Cette puissance opérationnelle est nécessaire, mais elle signifie aussi que, dès qu’un attaquant atteint cette couche avec des privilèges élevés, l’impact devient sévère. Le durcissement réduit le nombre d’erreurs faciles, mais il ne peut pas changer le fait que ces systèmes sont intrinsèquement privilégiés. 

Données Sauvegarde : la seule couche qui doit rester intacte lorsque toutes les autres échouent 

La couche données est celle où Zero Trust doit être absolu. Si les attaquants compromettent l’identité, les terminaux, les réseaux et les applications, les données de sauvegarde et leur chaîne de traçabilité doivent survivre. Cela exige une architecture de stockage qui n’autorise pas les actions destructrices même lorsque l’attaquant dispose d’identifiants complets. 

Veeam et Object First sont conçus pour exactement ce scénario. Les deux partent du principe qu’une compromission a déjà eu lieu, et que la restauration peut devoir démarrer même si Veeam lui-même a été compromis. Dans un scénario du pire — chaque secret exposé, chaque identifiant volé, et chaque plan de contrôle est compromis — les données de sauvegarde dans Ootbi restent immuables et impossibles à supprimer, offrant une base fiable pour se rétablir. 

Cette capacité de survie est ce qui sépare Zero Trust du durcissement. Le durcissement prétend qu’aucune compromission ne surviendra ; Zero Trust exige l’évaluation que des attaquants compromettront la cible, et qu’ils ne pourront malgré tout pas détruire les données nécessaires à la restauration. Veeam documente explicitement comment restaurer Veeam lui-même lors d’une compromission grave, et Object First fournit la couche stockage immuable qui rend cette restauration possible. 

Ce que les organisations doivent rechercher 

Lors de l’évaluation du stockage de sauvegarde, l’indicateur le plus important est de savoir si le système est conçu avec un véritable état d’esprit « Assume Breach ». Les systèmes qui reposent sur l’accès privilégié, la détection ou l’immutabilité au niveau de la couche logicielle restent vulnérables aux mêmes modes de défaillance que les couches au-dessus d’eux. Utiliser une solution qui applique Zero Access garantit que personne — pas même un administrateur — ne peut effectuer d’actions destructrices sur les données de sauvegarde 

Les administrateurs Sauvegarde doivent planifier le scénario du pire : restaurer depuis un environnement compromis où tous les identifiants sont exposés. Si tous les secrets sont connus, les attaquants les connaissent aussi. Le système de stockage doit être conçu pour résister à cette réalité. 

Tout aussi important, les organisations doivent pouvoir prouver cette capacité de survie — et pas seulement se fier à l’affirmation. Une plateforme crédible permet aux organisations de valider l’immutabilité, de tester la restauration dans des scénarios destructeurs et de confirmer que les données restent récupérables même lorsque l’environnement est entièrement compromis. Si un fournisseur restreint ou interdit ce type de tests, cette limitation devient en soi un signal de sécurité. 

La prochaine étape pour l’industrie 

À mesure que Zero Trust devient plus strictement défini, les fournisseurs devront démontrer, et non simplement affirmer, le comportement de leurs systèmes en cas de compromission complète des privilèges. Ils devront documenter les chemins privilégiés, prouver l’immutabilité indépendamment du logiciel de sauvegarde et montrer la capacité de survie lorsque chaque identifiant est exposé.  

Le stockage Sauvegarde doit fonctionner comme la dernière ligne de défense, et non comme un autre système qui s’effondre lorsque les attaquants obtiennent un accès total.