Architecture Zero Trust: ce que c’est et ce que j’en pense

Je lis depuis un bon moment la publication du NIST sur l’architecture Zero Trust (ZTA). Vous trouverez le document ici: https://csrc.nist.gov/publications/detail/sp/800-207/final. Ce document de 41 pages est dense et rempli de patrons d’architecture avancés. Il m’a fallu un certain temps pour le lire et le comprendre.

La version originale de cet article a été publiée sur www.tristandostaler.com le 11 janvier 2021.

Qu’est-ce qu’une architecture Zero Trust

Une architecture Zero Trust (ZTA) est une architecture de sécurité de l’information fondée sur l’idée qu’un réseau ne devrait accorder aucune confiance implicite à l’intérieur de son périmètre. Beaucoup de réseaux d’entreprise sont conçus comme un œuf: une coquille externe plutôt solide et robuste, mais un intérieur où tout est permissif. Il suffit d’une petite aiguille capable de percer la coquille pour semer le désordre à l’intérieur.

En concevant un réseau selon la ZTA, vous vous assurez que si un attaquant parvient à prendre pied dans le réseau interne, il n’a accès à rien. Bien sûr, s’il a volé des identifiants, il conserve l’accès dont dispose l’utilisateur dont il usurpe l’identité. Mais avec une ZTA, le risque global et l’état courant de l’ensemble des actifs de l’entreprise sont évalués de façon dynamique et continue: un accès accordé à un utilisateur peut donc être retiré à tout moment, selon de nombreux critères.

Par exemple, si le risque global de l’entreprise atteint un point critique parce qu’une nouvelle CVE au score CVSS de 9,9 sur 10 apparaît dans ses actifs, l’algorithme pourrait bloquer l’accès à l’information sensible jusqu’à ce que la CVE soit corrigée, ou exiger une vérification par authentification multifacteur là où un seul facteur suffirait normalement.

Autre exemple intéressant: un accès pourrait être refusé si l’on découvre que des identifiants de l’utilisateur qui tente de se connecter ont récemment fait l’objet d’une fuite (par exemple au moyen de https://haveibeenpwned.com/).

Pourquoi c’est important

Une architecture Zero Trust est un élément clé de l’architecture moderne, en nuage ou non. C’est notamment l’un des principaux éléments de la nouvelle recommandation d’architecture de Microsoft: https://docs.microsoft.com/en-us/security/compass/privileged-access-strategy.

Ce modèle réduit significativement le risque qu’un attaquant élève ses privilèges ou conserve un accès pendant une longue période, et il rend plus difficile l’utilisation de privilèges élevés lorsque l’attaquant en dispose, par exemple à la suite d’un hameçonnage.

Comment une architecture Zero Trust est-elle mise en œuvre

Comme je l’ai dit, la documentation officielle est dense et je ne pourrai pas résumer ici comment concevoir et déployer une ZTA. Pour cela, je vous recommande de lire le document officiel. Mais je vais tenter d’exposer clairement l’intention derrière cette architecture, afin que vous puissiez juger si c’est une avenue à emprunter dans votre entreprise.

Tout le principe de l’architecture est résumé à la section 3 du document, page 9: Logical components of Zero Trust Architecture. Sans entrer dans les détails, cette image en donne une assez bonne idée:

On y voit plusieurs composantes:

Subject: le sujet est l’utilisateur qui se sert d’un système (un ordinateur) pour accéder à une ressource de l’entreprise (une information).

System: simplement l’ordinateur, ou un appareil semblable, utilisé par le sujet pour accéder à quelque chose.

Policy Enforcement Point: l’une des composantes centrales d’une ZTA. Son rôle est de recevoir les demandes d’accès des systèmes et de demander au Policy Decision Point si l’accès est accordé. Il importe de noter que l’accès peut être révoqué à tout moment, puisque tout passe par ce point, même une fois l’accès accordé. Un Policy Enforcement Point peut être un système unique, mais il peut aussi être scindé en deux: le client (un ordinateur, par exemple) et la ressource (un site Web donnant accès à l’utilisateur, par exemple).

Policy Decision Point: une composante logique qui englobe les deux autres composantes principales d’une ZTA, le Policy Engine et le Policy Administrator.

Policy Administrator: la composante qui gère toute l’information de session, comme le jeton d’authentification. Elle est aussi responsable d’autoriser ou d’interrompre la communication entre le système et la ressource, selon la décision du Policy Engine.

Policy Engine: la composante qui prend la décision finale d’accès, à partir des politiques définies par l’entreprise. Lorsque le Policy Enforcement Point demande si un système peut communiquer avec une ressource, le Policy Administrator interroge le Policy Engine. Celui-ci prend une décision en s’appuyant sur de multiples points de décision, y compris des sources externes comme le renseignement sur les menaces, et sur la politique applicable à la ressource. Le Policy Administrator exécute ensuite la décision en créant le jeton de session et le reste. Si, à tout moment, le Policy Engine décide que la communication doit cesser, le Policy Administrator révoque la validité du jeton et la communication entre le système et la ressource n’est plus permise.

En résumé, le sujet qui utilise un système tentera de se connecter à une ressource. Pour établir la connexion, le système demandera l’accès au Policy Enforcement Point. Celui-ci demandera comment procéder au Policy Administrator, qui validera auprès du Policy Engine si l’accès doit être accordé ou refusé. Si l’accès est accordé, le Policy Administrator produit toute l’information nécessaire à l’authentification et à l’autorisation de la session, puis retourne les détails au Policy Enforcement Point, qui accorde au système l’accès à la ressource.

Comment mettre en œuvre une ZTA

La section précédente explique, sur le plan conceptuel, comment une ZTA peut être mise en œuvre, mais pas comment l’installer et l’utiliser concrètement. Compte tenu de la complexité de l’architecture, je n’entrerai pas dans ces détails, mais je vous orienterai vers d’excellentes ressources.

En environnement Windows, la meilleure approche est de suivre les lignes directrices et les étapes fournies par Microsoft: https://docs.microsoft.com/en-us/security/compass/privileged-access-strategy

En environnement Linux, certains fournisseurs peuvent aider à mettre en œuvre cette stratégie, dont Okta: https://www.okta.com/resources/datasheet-advanced-server-access-a-zero-trust-approach-to-linux-and-windows-server-access-via-ssh-and-rdp/

Ce que je pense de la ZTA

En raison du contexte actuel de la COVID-19 et du fait que beaucoup d’entreprises doivent maintenant soutenir le télétravail, l’idée d’une ZTA gagne du terrain. Depuis que j’ai commencé à m’y intéresser, je vois de plus en plus de billets de blogue sur le sujet.

Dans un monde idéal, tout le monde mettrait en œuvre une ZTA. La plupart des entreprises deviendraient réellement résilientes aux attaques et le nombre de piratages réussis, semaine après semaine, diminuerait. Mais comme pour tout le monde, les budgets sont limités et les ressources humaines techniques capables de mener ces changements sont rares.

Le principal problème est que, comme la plupart des fonctions de sécurité, elle n’est pas activée par défaut. Il faut donc affecter une ressource qualifiée à temps plein pendant une période considérable, ce qui ralentit tout le reste de ce qu’il y a d’important à faire.

Si vous consultez le lien vers Microsoft Windows, vous constaterez rapidement que cette architecture n’est pas une mince affaire. Et si vous connaissez Microsoft, vous savez que tout ne sera pas parfaitement documenté et que certaines fonctions ne se comporteront pas comme vous le croyez: il faudra donc procéder par essais et erreurs.

Conclusion

Je crois qu’une ZTA devrait être appliquée dans toutes les entreprises, mais en raison de l’effort exigé, elle le sera surtout par des moyennes et grandes entreprises pour qui la sécurité est un besoin d’affaires fondamental.

Sources

Retour aux perspectives