En novembre 2019 (avant le confinement lié à la pandémie), j’étais RSSI d’une entreprise internationale de services professionnels. Mon projet stratégique le plus important à l’époque consistait à créer le « VPN permanent ». Quel était cet objectif primordial ? Une tentative de modernisation de notre accès à distance sécurisé mondial. Pour quelles raisons ? Avec nos anciens systèmes, accéder aux ressources de l’entreprise depuis l’extérieur du périmètre de sécurité représentait trop d’efforts, et nous prévoyions de croître à mesure que davantage de personnes travaillaient en dehors du bureau. (Nous étions loin de nous douter que…)

Mon DSI et moi-même avons identifié quatre problèmes importants que le VPN permanent devait permettre de résoudre :

Manque de confort : réduire la complexité de la connexion à un simple service d’authentification unique (SSO) pour n’importe quel appareil, n’importe où, afin d’améliorer l’expérience utilisateur
Risque de menace : réduire la surface d’attaque à mesure qu’augmentait le nombre de personnes se trouvant à l’extérieur du périmètre de sécurité
Mauvaises performances : réduire le trafic soumis au backhauling vers nos data centers via des connexions MPLS afin d’améliorer l’expérience utilisateur
Frais généraux élevés : réduire les dépenses liées au backhauling MPLS en utilisant des connexions directes à Internet

Nous avions des idées différentes sur ce qui était le plus important et sur ce qu’il fallait faire en premier. Mais nous étions tous les deux d’accord sur le fait que notre architecture actuelle n’allait pas nous permettre d’évoluer vers un environnement distant basé sur le cloud.

Le dilemme récurrent : expérience utilisateur ou sécurité de l’entreprise

Mon DSI a remis en question notre approche de l’accès à distance : « Pourquoi dois-je m’authentifier sur un ordinateur portable de la société, lancer un client VPN, fournir à nouveau mon mot de passe réseau, activer mon jeton d’authentification multifacteur (MFA) et saisir manuellement un authentifiant rotatif à 8 chiffres simplement pour me connecter au réseau de l’entreprise ? »

Notre fastidieux processus de connexion sécurisée au réseau contribuait à une expérience utilisateur désastreuse et était si onéreux qu’il incitait les employés à éviter la sécurité. Le problème a été encore aggravé par le fait que d’autres services que les employés utilisent régulièrement (banque, réseaux sociaux et commerce électronique, par exemple) nécessitent des notifications push d’authentification multifacteur (MFA) supplémentaires sur les appareils enregistrés ou autorisés.

Je partageais ses préoccupations en matière d’expérience utilisateur. Je souhaitais également réduire le nombre de services d’écoute VPN entrants (trois) et de passerelles VDI (deux) fonctionnant dans trois DMZ continentales différentes. À la même époque, plusieurs exploits de concentrateurs VPN ont fait couler beaucoup d’encre et ont exigé des correctifs ou des mises à jour en urgence. Les mises à jour de ce type devaient être testées et examinées pour déterminer leur impact opérationnel, ce qui impliquait un délai de mise en œuvre plus long et une plus forte exposition aux risques du réseau.

Il s’avère que ces deux problèmes étaient liés.

O365 nous a brisé

Nous avons soumis au backhauling tout notre trafic distant des États-Unis vers un concentrateur VPN situé dans un data center de colocation à Phoenix, en Arizona. (Les data centers de Londres et de Pékin disposaient respectivement de configurations similaires en Europe et en Asie). Notre plan stratégique 2019 consistait à adopter Office 365 via une entité Azure. Une évaluation de l’impact sur l’entreprise a suggéré que notre trafic nomade (déjà en hausse) augmenterait de façon exponentielle avec une utilisation accrue des applications Office 365 telles que SharePoint, OneDrive, Teams et Skype.

Si tous les télétravailleurs éligibles des États-Unis se connectaient simultanément, tout le trafic Internet et Office 365 serait soumis au backhauling vers Phoenix, puis envoyé vers l’instance de Service Edge de Los Angeles avant de se diriger vers sa véritable destination : le cloud. Nos données O365 ont emprunté un chemin détourné à travers plusieurs réseaux, ce qui a ralenti les performances de l’application.

Nous devions trouver un moyen d’améliorer les performances d’Office 365. Une option consistait à déployer une solution de tunnel fractionné, mais le manque de visibilité sur les appareils, le trafic et le réseau augmentait les risques bien au-delà de ce qui était acceptable. Il nous fallait un moyen de séparer le trafic lié à Internet du trafic lié aux applications internes.

Zero Trust nous montre la voie à suivre

Le Zero Trust n’était pas nouveau pour moi : nous utilisions depuis des années une passerelle Web sécurisée (SWG) dans le cloud pour répondre aux menaces et réaliser nos objectifs de sécurité. Le SWG a excellé dans l’inspection du trafic sortant à la recherche de menaces et de fuites de données, et a sécurisé de manière homogène toutes nos entités SaaS professionnelles. Il offrait également la meilleure visibilité sur le comportement du trafic sortant et les mesures d’utilisation que j’aie jamais connue. Je me suis donc demandé : « Pouvons-nous utiliser ce modèle pour le trafic entrant d’un cloud privé en utilisant le modèle Zero Trust ? » (Attention spoiler : oui. Oui, c’est possible).

Zero Trust est un nouveau paradigme, et il exige un changement fondamental de l’état d’esprit relatif à la connectivité. Les adeptes de la sécurité traditionnelle du périmètre se demandent : « Comment connecter en toute sécurité cet appareil à ce réseau ? » Zero Trust est plus direct (à plus d’un titre) et demande « Comment connecter en toute sécurité cet utilisateur à cette application ? »

En 2019, Gartner a défini la mise en œuvre pratique du Zero Trust en tant qu’accès réseau Zero Trust ou ZTNA :

ZTNA (également connu sous le nom de périmètre défini par logiciel, ou SDP) désigne un ensemble de technologies qui fonctionne sur un modèle de confiance adaptatif où la confiance n’est jamais implicite, et où l’accès est accordé selon le principe du « besoin de savoir » et du moindre privilège, défini par des politiques granulaires.*

Nous avons déployé un connecteur réseau et mis en place une configuration de droits simple pour le provisionnement des utilisateurs. En d’autres termes : pas de déploiement ni d’installation de nouveaux logiciels de terminal. Nous pouvions désormais remplacer notre solution VPN par une solution Zero Trust et réduire notre surface d’attaque pour tous les utilisateurs. Avantage supplémentaire : nous avons immédiatement découvert une demi-douzaine de serveurs « d’informatique fantôme » dissimulés. Heureusement, ils étaient correctement entretenus et corrigés automatiquement, mais jusqu’à ZTNA, personne ne savait qui les utilisait ni à quoi ils servaient.

Le grand changement : la COVID-19

En février 2020, nous étions prêts à déployer le Zero Trust dans l’ensemble de l’entreprise. C’est alors que la COVID-19 a mis le monde à l’arrêt.

Nous avons été confrontés à plusieurs obstacles à notre transition vers le télétravail. Environ 20 % de nos effectifs n’avaient jamais travaillé à distance : pas d’ordinateur portable professionnel, pas de jeton MFA, aucune connaissance des pratiques de gestion des applications BYOD. Toutes les ressources informatiques ont été consacrées à l’ajout de licences et d’infrastructures à notre environnement VDI. Alors que nous stabilisions notre personnel distant, notre évaluation de l’impact commercial de 2019 est devenue une réalité. L’explosion des conférences Web Zoom, Teams et Bluejeans a saturé la bande passante de notre passerelle VPN américaine.

Le déploiement du modèle Zero Trust a atténué ce problème et a permis d’aborder l’expérience utilisateur et la sécurité dans une solution unique.

La note de bas de page du Zero Trust : pourquoi la qualité de ma réunion est-elle mauvaise ?

Après avoir géré la sécurité des employés pendant la crise de la COVID-19, j’étais enthousiaste à l’idée d’aller de l’avant avec une infrastructure Zero Trust pour l’ensemble de la société. Mais notre DSI et moi avions des opinions divergentes sur l’orientation à donner au Zero Trust. Je voulais aller plus loin et l’utiliser pour permettre des connexions Internet directes à nos applications et ressources cloud, alors qu’il pensait que cela pourrait introduire trop de changements pour les employés pendant la pandémie.

Curieusement, en avril 2020, notre PDG a convoqué une réunion. Le PDG et son épouse ont participé à des appels Zoom simultanés, chacun avec un nombre similaire de participants. La réunion en ligne du PDG a souffert de baisses continuelles d’audio et de vidéo. En revanche, l’appel de sa femme s’est déroulé avec un son et une vidéo de qualité. Pourquoi cela se produisait-il ? Quel est le problème ?

Le problème était exactement ce dont le DSI et moi avions discuté une semaine plus tôt : le backhauling. Le trafic de conférence Web de notre PDG passait par son réseau domestique à Washington, D.C., puis par notre data center de Phoenix, et enfin par l’instance de Service Edge de Zscaler à Los Angeles, tout cela avant de se connecter à l’infrastructure Zoom. Quant à l’appel de sa femme, nous pouvons supposer simplement que le trafic de son appareil passait directement par leur passerelle locale. Comme je l’ai dit au DSI : « Vous pouvez résoudre ce problème avec des connexions Internet directes, en utilisant le principe Zero Trust ».

Cette réunion avec le PDG a déclenché notre déploiement mondial d’utilisateurs Zero Trust, un dénouement heureux !