Qu'est-ce que la confiance zéro ?

Le modèle « Zero Trust » remplace la confiance fondée sur la localisation par une vérification continue. Alors qu’un modèle périmétrique considérait par défaut tout ce qui se trouvait à l’intérieur du réseau comme fiable, le modèle « Zero Trust » évalue chaque requête comme si elle provenait d’une source non fiable, indépendamment de son origine réelle ou des autorisations accordées à ce même utilisateur une heure auparavant.

Trois concepts caractérisent ce modèle dans la pratique :

• Pas de confiance implicite. La position au sein du réseau ne garantit rien en soi, et le fait de se trouver à l'intérieur du pare-feu ne constitue pas une preuve de la légitimité d'une requête.
• Vérification continue. La fiabilité est évaluée à chaque requête, et non pas établie une seule fois lors de la connexion puis maintenue pendant toute la durée de la session.
• Principe du privilège minimal. L'accès est limité à ce qu'exige une requête spécifique et ne va pas au-delà.

Le « Zero Trust » n'est pas un produit que les entreprises peuvent acheter. Il s'agit d'une stratégie qui englobe l'identité, les appareils, les réseaux, les applications et les données, plutôt que d'une technologie propre à l'une de ces couches en particulier. Les fournisseurs qui la présentent comme un produit ne décrivent généralement qu'un seul composant de l'architecture.

Le terme lui-même remonte à 1994, lorsque Stephen Paul Marsh l’a utilisé dans une thèse de doctorat sur la confiance informatique à l’université de Stirling. Il s'est imposé dans le domaine de la sécurité en 2010, lorsque John Kindervag, analyste chez Forrester, a publié “ No More Chewy Centers : Introducing the Zero Trust Model of Information Security ” (Finis les « cœurs mous » : présentation du modèle « zéro confiance » en matière de sécurité de l'information) et a démontré que la confiance constituait en soi une vulnérabilité. Le projet BeyondCorp de Google, lancé en 2009, a été l'une des premières mises en œuvre à grande échelle.

La norme NIST SP 800-207 définit sept principes fondamentaux auxquels toute architecture « zero-trust » doit se conformer.

1. Toutes les sources de données et tous les services informatiques constituent des ressources. Les bases de données, les applications, les services SaaS, les appareils IoT et les postes de travail des utilisateurs doivent tous être protégés, sans aucune exception liée à leur emplacement ou à leur importance supposée.
2. Toutes les communications sont sécurisées, quel que soit l'emplacement du réseau.. Le trafic transitant par le réseau interne est authentifié et chiffré selon les mêmes normes que le trafic provenant de l'Internet public.
3. L'accès est accordé pour chaque session.. La confiance est évaluée pour la session en cours et ne se prolonge pas au-delà ; ainsi, l'accès à une ressource ne garantit en rien l'accès à une autre.
4. L'accès est déterminé par une politique dynamique. Les décisions tiennent compte de l'identité du client, de l'état de l'application, de la posture des ressources, ainsi que des caractéristiques comportementales et environnementales, plutôt que de se fonder sur un ensemble de règles statiques.
5. L'entreprise surveille l'état de sécurité de tous ses actifs. Aucun élément n'est considéré comme fiable par défaut, et l'intégrité des appareils est évaluée en continu afin qu'elle puisse être prise en compte dans les décisions d'accès.
6. L'authentification et l'autorisation sont des processus dynamiques et sont strictement appliquées avant tout accès.. La vérification s'inscrit dans un cycle continu d'autorisation, d'analyse, d'adaptation et de réévaluation, plutôt que sous la forme d'un contrôle unique effectué au début d'une session.
7. L'entreprise recueille autant d'informations que possible et les utilise pour améliorer sa posture de sécurité.. Les données de télémétrie recueillies auprès des ressources, de l'infrastructure et des systèmes de communication sont prises en compte dans les politiques qui régissent l'accès.

Une formulation plus concise en trois points est également largement répandue : vérifier explicitement, partir du principe d’une violation, appliquer le principe du privilège minimal. Cette formulation, qui trouve son origine dans le modèle Microsoft, constitue un résumé assez pertinent, mais elle ne correspond pas à ce que spécifie réellement la norme SP 800-207 ; les organisations qui s’appuient sur les recommandations du NIST doivent donc se conformer aux sept principes énoncés ci-dessus.

Chaque demande d'accès est interceptée et traitée en temps réel, selon une séquence qui reste la même, quel que soit le développeur de la pile sous-jacente :

1. Une personne demande à y avoir accès à une ressource, ce sujet pouvant être une personne, un compte de service, une charge de travail ou un agent IA.
2. Les signaux sont collectés, notamment l'identité, l'état de l'appareil, la localisation, l'heure, le comportement antérieur et les informations sur les menaces.
3. Un moteur de règles évalue la requête en contradiction avec la politique de l'entreprise et un score de risque calculé.
4. Une décision est rendue et exécutée, en accordant l'accès, en le refusant ou en le renforçant par un facteur d'authentification supplémentaire.
5. La session fait l'objet d'une surveillance, de sorte que toute évolution du niveau de risque entraîne une réévaluation et que l'accès puisse être révoqué alors que la session est encore ouverte.

C'est cette dernière étape qui distingue le modèle « Zero Trust » des modèles qui l'ont précédé, car la sécurité périmétrique prend une seule décision à la frontière et en assume ensuite les conséquences, tandis que le modèle « Zero Trust » poursuit son évaluation tant que la session dure.

La meilleure façon de comprendre la différence est de considérer qu’un VPN étend le périmètre, tandis que le modèle « Zero Trust » supprime purement et simplement ce périmètre.

Lorsqu'un utilisateur se connecte via un VPN classique, il est intégré au réseau de l'entreprise et bénéficie d'un accès étendu au niveau du réseau sur la base d'une seule vérification effectuée au moment de la connexion. Tout ce qui est accessible depuis cette position sur le réseau est accessible à cet utilisateur, ainsi qu'à toute personne qui parviendrait à dérober ses identifiants.

Le modèle « Zero Trust » accorde l'accès à des ressources individuelles plutôt qu'à des réseaux ; ainsi, l'autorisation d'accéder à une application ne s'étend pas à d'autres ressources. Chaque requête est réévaluée en fonction des conditions de risque du moment.

La publication spéciale 800-207 du NIST, parue en août 2020, constitue l'architecture de référence sur laquelle s'appuient la plupart des organisations. Elle établit une distinction claire entre les composants qui prennent et appliquent les décisions d'accès et les sources de données qui les sous-tendent.

Les trois composantes logiques fondamentales

Moteur de règles (PE). Il prend la décision d'accès en évaluant la politique d'entreprise à la lumière des données décrites ci-dessous, en appliquant un algorithme de confiance, puis en accordant, refusant ou révoquant l'accès.

Administrateur de police (PA). Il met en œuvre cette décision en ouvrant ou en fermant le canal de communication et en délivrant l'identifiant ou le jeton que le sujet utilise pour accéder à la ressource. Ensemble, le PE et le PA constituent ce que le NIST appelle le « point de décision de politique ».

Point d'application des politiques (PEP). Permet d'établir, de surveiller et de mettre fin à la connexion entre le sujet et la ressource, en s'insérant dans le chemin de la requête et en appliquant ce que le point de décision de politique détermine.

Sources de données alimentant le moteur de règles

Les éléments suivants fournissent les signaux que le moteur de règles évalue, sans prendre de décisions eux-mêmes :

• Système de gestion des identités. Comptes, fiches d'identité, rôles, attributs et droits d'accès.
• Politiques d'accès aux données. Les règles définissant qui peut accéder à quelles ressources et dans quelles conditions.
• Diagnostic et atténuation en continu. Inventaire des actifs et état de sécurité des appareils.
• Informations sur les menaces. Indicateurs internes et externes relatifs aux attaques et aux vulnérabilités récemment découvertes.
• Journaux d'activité et SIEM. Les données télémétriques agrégées servent à affiner la stratégie au fil du temps.
• Systèmes de conformité sectoriels. Les exigences réglementaires que l'entreprise est tenue de respecter.
• PKI. Émission et validation de certificats pour les entités et les ressources.

Les équipes ont souvent tendance à brouiller cette distinction lors de la mise en œuvre, en considérant un système d'identité ou un flux d'informations sur les menaces comme s'il prenait les décisions d'accès, alors que, dans le modèle du NIST, ces systèmes ne fournissent que des données au moteur de règles qui prend réellement les décisions. Cette distinction revêt une importance capitale lorsqu'il s'agit d'évaluer quelles parties de l'architecture sont réellement prises en charge par un fournisseur.

En tant que concept, le « Zero Trust » est assez simple : ne faire confiance à personne et n’approuver aucune action tant que l’on n’a pas validé l’identité de la personne et autorisé sa demande. C'est au niveau de la mise en œuvre que la plupart des organisations butent, car le « Zero Trust » touche simultanément l'identité, le réseau, les terminaux, les applications et les données, et rares sont les équipes de sécurité qui disposent du budget ou du capital politique nécessaire pour traiter ces cinq aspects à la fois. Cela soulève la question pratique de savoir par où commencer, et la réponse est presque toujours : par l'identité.

Chaque décision relevant du modèle « Zero Trust » revient à une seule et même question : ce sujet est-il bien celui qu’il prétend être, et devrait-il disposer de cet accès à l’instant présent ? La segmentation et le chiffrement ne permettent pas de répondre à cette question, et l’état de sécurité des appareils permet de la cerner sans toutefois la trancher, ce qui fait de l’identité le seul contrôle capable d’y apporter une réponse. Lorsque l’identité est fragile, tous les contrôles en aval appliquent fidèlement une décision fondée sur une prémisse non vérifiée.

L'identité joue un rôle déterminant à trois niveaux :

• Authentification. Vérification du sujet via méthodes de protection contre le phishing plutôt que des secrets partagés qui peuvent être volés, réutilisés ou faire l'objet d'une manipulation psychologique.
• Autorisation. Déterminer ce à quoi un sujet vérifié a le droit d'accéder, sur la base de rôles réglementés plutôt qu’un accès acquis au fil des années, au gré des changements de poste.
• Évaluation continue. Réévaluer ces deux éléments à mesure que les indicateurs de risque évoluent, et révoquer l'accès lorsque ces indicateurs le justifient.

Il y a là un corollaire dérangeant : on ne peut pas appliquer un principe de « privilège minimal » que l'on n'a jamais défini, et on ne peut pas définir ce principe sans savoir qui a accès à quoi aujourd'hui. La plupart des organisations ne peuvent pas répondre à cette question avec certitude, c'est pourquoi gouvernance de l'identité doit être mis en place dès le début d'un programme « Zero Trust », plutôt que lors d'une phase ultérieure.

Gestion des identités et des accès fournit les composants indispensables à une architecture « Zero Trust ».

Deux exigences ont tendance à être sous-estimées plus que toute autre.

L'authentification doit être à l'épreuve du phishing. Authentification multifactorielle (MFA) basée sur des codes d'accès à usage unique La transmission par SMS ou par e-mail renforce la sécurité sans pour autant combler les failles, car les attaques de type « man-in-the-middle » et les campagnes visant à susciter une lassitude vis-à-vis de l'authentification multifactorielle (MFA) parviennent assez régulièrement à contourner les méthodes de notification push et de mot de passe à usage unique (OTP). FIDO2 et clés d'accès liées à un appareil associer les identifiants à la fois à l'appareil et à l'origine ; c'est ce mécanisme qui permet de mettre fin à l'attaque, plutôt que de simplement la ralentir. RSA défend cet argument depuis bien avant qu'il ne fasse l'objet d'un consensus, en tant que membre du conseil d'administration de l'Alliance FIDO et coprésident du groupe de travail « Enterprise ».

Access doit continuer à fonctionner même lorsque le cloud ne fonctionne pas. Une architecture qui achemine chaque décision d’accès via un moteur de politiques cloud introduit, de par sa conception, un point de défaillance unique ; or, lorsque ce service devient inaccessible, plus personne ne peut travailler. Pour les organisations évoluant dans des environnements sur site, hybrides, isolés physiquement ou à disponibilité constante, où une panne entraîne des conséquences opérationnelles plutôt qu’un simple désagrément, le rapport qualité-prix est médiocre. Le modèle « Zero Trust » devrait réduire le nombre d’éléments susceptibles de mettre une organisation hors ligne plutôt que de les concentrer ; c’est pourquoi les voies d’application hors ligne et sur site sont ce qui rend ce modèle viable dans ces environnements.

Une fois qu'une entreprise s'engage dans une démarche « Zero Trust », le véritable travail commence. Il s'agit d'un programme s'étalant sur plusieurs années, et les entreprises qui parviennent à obtenir des résultats ont tendance à organiser les différentes étapes de manière séquentielle plutôt que de tout mettre en œuvre simultanément.

1. Identités, ressources et accès actuels. Le principe du « privilège minimal » ne peut pas être appliqué sans référence de base connue ; commencez donc par déterminer qui et quoi a accès à quelles ressources à l'heure actuelle, y compris les comptes de service, les prestataires et les identités des machines.

2. Renforcer d'abord l'authentification. Le déploiement d'une authentification multifactorielle (MFA) résistante au phishing sur les voies d'accès les plus critiques permet d'obtenir la plus forte réduction des risques par unité d'effort, et constitue une condition préalable à la plupart des mesures qui suivent.

3. Définir et appliquer des politiques d'accès. Traduire les rôles et les besoins métier en règles explicites, puis supprimer les accès généraux permanents et les remplacer par des droits d'accès bien délimités et pouvant faire l'objet d'un réexamen.

4. Prendre en compte le contexte dans les décisions d'accès. La mise en place d'une authentification basée sur le risque permet aux requêtes à faible risque d'être acceptées sans encombre, tandis que celles qui présentent des anomalies sont soumises à une vérification supplémentaire ou bloquées ; c'est également ainsi que l'on empêche les utilisateurs de contourner le système.

5. Ressources par segment. En limitant l'accès d'une session compromise, on réduit l'ampleur des dégâts lorsque — et non pas « si » — un mécanisme de contrôle vient à échouer.

6. Surveiller, examiner et révoquer. Les réévaluations des droits doivent être effectuées selon un calendrier précis, car les droits qui s’accumulent sans faire l’objet d’une réévaluation finissent par entraîner cette prolifération des privilèges que le programme était censé empêcher.

Dans ce contexte, l'ordre prime sur le rythme, car une segmentation appliquée sans s'appuyer sur une identité bien définie produit des réseaux bien compartimentés qui continuent toutefois de protéger des comptes dotés de privilèges excessifs.

Les organisations n'atteignent jamais le niveau « Zero Trust ». Elles doivent évaluer en permanence leur posture de sécurité et réexaminer chaque décision d'accès.

Friction utilisateur. Une vérification trop stricte favorise les solutions de contournement, l'informatique parallèle et l'augmentation du volume des demandes adressées au service d'assistance, alors que l'accessibilité et la sécurité ne doivent pas nécessairement s'opposer. L'authentification basée sur les risques adapte le niveau de contrôle au risque que présente chaque demande individuelle, plutôt que d'imposer des contraintes uniformes à tous les utilisateurs.

Systèmes hérités. Les applications antérieures aux normes d'authentification modernes ne peuvent souvent pas être intégrées sans passer par une passerelle, un proxy ou un remplacement pur et simple, ce qui en fait l'élément le plus contraignant dans la plupart des programmes et celui qui est le plus souvent sous-estimé lors de la phase de planification.

Dépendance à la disponibilité. Le fait de centraliser les décisions d'accès au sein d'un seul service cloud crée une nouvelle dépendance critique : si le moteur de règles devient inaccessible, tout le monde se retrouve privé d'accès à l'ensemble des ressources. Il est judicieux de demander directement à n'importe quel fournisseur ce qu'il advient de l'authentification en cas de panne de son service.

Périmètre organisationnel. Étant donné que l'approche « Zero Trust » concerne à la fois les équipes chargées de l'identité, du réseau, des terminaux, des applications et des données, les programmes gérés exclusivement par une seule fonction ont tendance à s'enliser aux limites de cette fonction.

Confusion entre fournisseurs. Aucun produit ne permet à lui seul de mettre en œuvre le modèle “ Zero Trust ” ; il convient donc d'évaluer les fournisseurs en fonction des composants architecturaux qu'ils fournissent réellement, et il vaut mieux considérer la « plateforme Zero Trust » comme un argument à vérifier plutôt que comme une catégorie de produits à acheter.

Prolifération des données d'identité. La gestion des identités constitue un problème croissant en matière de données plutôt qu'un problème statique, et les droits d'accès s'accumulent plus rapidement que la plupart des équipes ne peuvent les examiner manuellement ; c'est à ce stade que l'automatisation et l'analyse des données cessent d'être facultatives.

Le modèle « Zero Trust » est passé du statut de « bonne pratique » à celui d'« exigence » dans plusieurs environnements réglementés.

• Décret 14028 dirige Agences civiles fédérales américaines vers une architecture « Zero Trust ».
• Modèle de maturité « Zero Trust » de la CISA fournit le cadre de référence à l'aune duquel les agences fédérales évaluent leur niveau de maturité, articulé autour de cinq piliers : l'identité, les appareils, les réseaux, les applications et les charges de travail, ainsi que les données.
• Stratégie « Zero Trust » du ministère américain de la Défense présente les actions menées dans le cadre du modèle « Zero Trust » pour les composants de défense.
• CMMC 2.0 impose des exigences en matière de contrôle d'accès et d'authentification multifactorielle (MFA) à l'ensemble de la base industrielle de défense.
• DORA et NIS2 imposer des exigences en matière de contrôle d'accès, de résilience et de continuité opérationnelle à Services financiers de l'UE et les infrastructures critiques qui s'inscrivent dans les principes du « Zero Trust », que ce terme apparaisse ou non dans le texte.

L'identité apparaît comme un pilier ou un domaine de contrôle dans chacun de ces cas, et c'est également le domaine pour lequel les auditeurs ont tendance à demander en premier lieu des éléments probants et celui pour lequel les organisations sont le moins souvent prêtes à les fournir.

Les exigences en matière de résilience et les architectures exclusivement basées sur le cloud s'opposent également d'une manière qui mérite d'être examinée dès le début. Les attentes en matière de continuité opérationnelle prévues par la loi DORA, ainsi que les exigences de disponibilité permanente dans les secteurs de la défense et des infrastructures critiques, sont difficiles à satisfaire avec un modèle d'accès qui cesse de fonctionner dès que le service d'un fournisseur devient inaccessible.