Il y a quelques années de cela, l'architecture de sécurité de Cloudflare était une architecture VPN classique, de type « château et douves ». Nos employés utilisaient notre VPN d'entreprise pour se connecter à l'ensemble des applications et serveurs internes, afin d'effectuer leur travail. Nous appliquions une authentification à deux facteurs, avec des codes à usage unique basés sur le temps (TOTP), en faisant appel à une application d'authentification telle que Google Authenticator ou Authy lors de la connexion au VPN ; toutefois, seules quelques applications internes comportaient une deuxième couche d'authentification. Cette architecture paraît extérieurement solide, mais son modèle de sécurité est faible. Nous avons récemment analysé dans le détail les mécanismes d'une attaque de phishing que nous avons empêchée, qui explique comment des acteurs malveillants peuvent lancer des attaques par phishing contre des applications « sécurisées » avec des méthodes d'authentification de second facteur, comme TOTP. Heureusement, nous avions depuis longtemps renoncé à TOTP, que nous avions remplacé par des clés de sécurité matérielles et Cloudflare Access. Ce blog explique en détail comment nous avons procédé.
La solution au problème du phishing réside dans un protocole d'authentification multifacteur (MFA) appelé FIDO2/WebAuthn. Aujourd'hui, tous les employés de Cloudflare se connectent en utilisant FIDO2 comme multifacteur sécurisé et s'authentifient sur nos systèmes avec nos produits Zero Trust. Notre nouvelle architecture est à l'épreuve du phishing et nous permet d'appliquer plus facilement le contrôle d'accès basé sur le principe du moindre privilège.
Quelques informations sur la terminologie des clés de sécurité et ce que nous utilisons
En 2018, nous savions que nous voulions migrer vers une authentification multifacteur résistante au phishing. Nous avions observé evilginx2 et avions constaté la maturité des systèmes d'authentification mobiles anti-phishing basés sur les notifications push et de TOTP. Les seuls systèmes d'authentification multifacteur anti-phishing ayant résisté aux attaques par ingénierie sociale et par vol d'informations d'identification étaient les clés de sécurité reposant sur les normes FIDO. L'authentification multifacteur basée sur FIDO introduit une nouvelle terminologie, telle que FIDO2, WebAuthn, les clés physiques ou matérielles, les clés de sécurité, et plus particulièrement, la YubiKey (le nom d'un fabricant réputé de clés matérielles), à laquelle nous ferons référence dans cet article.
WebAuthn désigne la norme d'authentification web, et nous avons écrit une analyse approfondie du fonctionnement de ce protocole lorsque nous avons inauguré la prise en charge des clés de sécurité sur le tableau de bord Cloudflare.
CTAP1(U2F) et CTAP2 font référence au protocole entre le client et le système d'authentification, qui détaille la manière dont les dispositifs logiciels ou appareils matériels interagissent avec la plateforme exécutant le protocole WebAuthn.
FIDO2 désigne l'ensemble formé par ces deux protocoles utilisés pour l'authentification. Les distinctions ne sont pas importantes, mais la nomenclature peut prêter à confusion.
Le plus important à savoir est que tous ces protocoles et normes ont été développés pour créer des protocoles d'authentification ouverts, résistants au phishing, pouvant être mis en œuvre avec un appareil matériel. Dans les logiciels, ils sont mis en œuvre avec Face ID, Touch ID, Windows Assistant ou des applications semblables. Dans le matériel, une YubiKey ou un autre appareil physique distinct est utilisé pour l'authentification via USB, Lightning ou la technologie NFC.
La norme FIDO2 est résistante au phishing, car elle met en œuvre un système de vérification/réponse cryptographiquement sécurisé, et le protocole de vérification incorpore le site web ou le domaine spécifique sur lequel s'authentifie l'utilisateur. Lors de la connexion, la clé de sécurité produit une réponse différente sur le site exemple.net de celle qu'elle produit lorsque l'utilisateur essaie légitimement de s'authentifier sur exemple.com.
Chez Cloudflare, nous avons fourni plusieurs types de clés de sécurité à nos employés au fil des ans, mais nous fournissons actuellement à tous les employés deux clés de sécurité différentes, validées conformément à la norme FIPS. La première clé est une YubiKey 5 Nano ou YubiKey 5C Nano, destinée à rester connectée en permanence à un port USB des ordinateurs portables de nos employés. La seconde est la YubiKey 5 NFC ou la YubiKey 5C NFC, qui se connecte aux ordinateurs de bureau et aux appareils mobiles via la technologie NFC ou par USB-C.
Fin 2018, nous avons distribué des clés de sécurité à l'occasion d'un événement organisé pour l'ensemble de l'entreprise. Nous avons invité tous les employés à enregistrer leurs clés, s'authentifier avec elles et poser des questions sur les appareils lors d'un court atelier. Le programme a été un immense succès, mais nous nous heurtions encore à quelques problèmes, et certaines applications ne fonctionnaient pas avec WebAuthn. Nous n'étions pas prêts à effectuer un déploiement intégral des clés de sécurité, et nous avions besoin d'une solution intermédiaire, le temps de résoudre ces problématiques.
Le commencement : déploiement sélectif des clés de sécurité avec Cloudflare Zero Trust
Nous avons des milliers d'applications et de serveurs dont nous sommes responsables de la maintenance, et qui étaient protégés par notre VPN. Nous avons commencé à effectuer la migration de toutes ces applications vers notre proxy d'accès Zero Trust au moment où nous avons remis un ensemble de clés de sécurité à nos employés.
Cloudflare Access a fourni à nos employés un accès sécurisé à des sites qui étaient auparavant protégés par le VPN. Chaque service interne validait un identifiant signé permettant d'authentifier un utilisateur et de s'assurer que ce dernier s'était connecté avec notre fournisseur d'identité. Cloudflare Access était nécessaire pour notre déploiement des clés de sécurité, car il fournissait un outil permettant de déployer de manière sélective les premières applications internes qui nécessiteraient une authentification avec une clé de sécurité.
Nous avons utilisé Terraform lors de l'intégration de nos applications à nos produits Zero Trust, et c'est la politique Cloudflare Access conformément à laquelle nous avons d'abord déployé les clés de sécurité. Nous avons configuré Cloudflare Access pour utiliser OAuth2 lors de l'intégration avec notre fournisseur d'identité, et le fournisseur d'identité communique à Access le type de second facteur utilisé dans le cadre du flux OAuth.
Dans notre cas, swk est une preuve de possession d'une clé de sécurité. Si une personne se connectait et n'utilisait pas sa clé de sécurité, elle voyait s'afficher un message d'erreur utile lui demandant de se reconnecter et d'appuyer sur le bouton de sa clé de sécurité lorsqu'elle y était invitée.
Le déploiement sélectif a instantanément modifié la trajectoire de notre mise en œuvre de clés de sécurité. Nous avons lancé le déploiement sur un service unique le 29 juillet 2020, et l'authentification avec les clés de sécurité a massivement augmenté au cours des deux mois qui ont suivi. Cette étape était essentielle pour laisser à nos employés le temps de se familiariser avec la nouvelle technologie. Une fenêtre de déploiement sélectif devrait s'étendre sur un mois, afin de tenir compte du personnel en vacances, mais avec le recul, il n'est pas nécessaire qu'elle dure beaucoup plus longtemps que cela.
Quels autres avantages en matière de sécurité nous a apportés la migration de nos applications vers nos produits Zero Trust et hors de notre VPN ? Dans le cas des applications anciennes ou des applications qui n'utilisent pas SAML, cette migration était nécessaire à la mise en œuvre du contrôle d'accès basé sur les rôles et le principe du moindre privilège. Un VPN authentifie votre trafic réseau, mais toutes vos applications n'ont aucune idée de l'identité de l'utilisateur auquel appartient le trafic réseau. Nos applications parvenaient difficilement à appliquer différents niveaux d'autorisation, et chacune devait réinventer son propre système d'authentification.
Lors de l'intégration avec Cloudflare Access, nous avons créé des groupes afin d'appliquer le contrôle d'accès basé sur les rôles (RBAC) et d'indiquer à nos applications le niveau d'autorisation dont devrait disposer chaque personne.
Voici un site auquel seuls les membres du groupe ACL-CFA-CFDATA-argo-config-admin-svc ont accès. Il s'assure que l'employé a utilisé sa clé de sécurité lors de la connexion, et aucune intégration complexe avec OAuth ou SAML n'a été nécessaire pour cela. Nous disposons de plus de 600 sites internes utilisant ce même modèle, et tous ont déployé des clés de sécurité.
La fin de l'utilisation optionnelle : le jour où Cloudflare a complètement renoncé à TOTP
En février 2021, nos employés ont commencé à signaler des tentatives d'ingénierie sociale à notre équipe de sécurité. Ils recevaient des appels téléphoniques d'une personne prétendant faire partie de notre département informatique, et nous nous en sommes inquiétés. Nous avons décidé de commencer à exiger l'utilisation de clés de sécurité pour toutes les authentifications, afin d'éviter que les employés ne soient victimes d'une attaque par ingénierie sociale.
Après avoir désactivé toutes les autres formes d'authentification multifacteur (SMS, TOTP, etc.), à l'exception de WebAuthn, nous utilisions officiellement uniquement FIDO2. Le « jeton logiciel » (TOTP) n'est toutefois pas parfaitement à zéro sur ce graphique. Cela est dû au fait que les personnes qui égarent leur clé de sécurité ou dont le compte est verrouillé doivent suivre un processus de récupération sécurisé hors ligne, pendant lequel la connexion est facilitée par une autre méthode. La bonne pratique consiste à distribuer plusieurs clés de sécurité aux employés afin qu'ils disposent d'une clé de secours, au cas où cette situation se produirait.
Maintenant que tous les employés utilisent leur YubiKey dans le cadre d'une authentification multifacteur résistante au phishing, avons-nous fini ? Qu'en est-il de SSH et des protocoles non-HTTP ? Nous voulions déployer une approche unique et unifiée de la gestion des identités et des accès, et nous avons donc envisagé d'introduire des clés de sécurité dans différents autres protocoles.
Utilisation des clés de sécurité avec SSH
Pour soutenir l'introduction de clés de sécurité pour les connexions SSH, nous avons déployé Cloudflare Tunnel sur l'ensemble de notre infrastructure de production. Cloudflare Tunnel offre une intégration transparente à Cloudflare Access, quel que soit le protocole transitant par le tunnel, et l'exécution d'un tunnel nécessite le client de tunnel cloudflared. Cela signifie que nous pourrions déployer le fichier binaire cloudflared sur l'ensemble de notre infrastructure et créer un tunnel vers chaque machine, créer des politiques Cloudflare Access où les clés de sécurité sont requises et que les connexions ssh commenceraient à nécessiter des clés de sécurité via Cloudflare Access.
En pratique, ces étapes sont moins intimidantes qu'il n'y paraît, et les documents pour développeurs de notre solution Zero Trust proposent un excellent tutoriel décrivant la marche à suivre. Chacun de nos serveurs dispose d'un fichier de configuration indispensable au démarrage du tunnel. Systemd invoque cloudflared, qui utilise ce fichier de configuration (ou un fichier similaire) pour démarrer le tunnel.
tunnel: 37b50fe2-a52a-5611-a9b1-ear382bd12a6
credentials-file: /root/.cloudflared/37b50fe2-a52a-5611-a9b1-ear382bd12a6.json
ingress:
- hostname: <identifier>.ssh.cloudflare.com
service: ssh://localhost:22
- service: http_status:404
Lorsqu'un opérateur doit se connecter à notre infrastructure via SSH, il utilise la directive SSH ProxyCommand pour invoquer cloudflared, s'authentifier avec Cloudflare Access, puis transmettre la connexion SSH via Cloudflare. Les configurations SSH de nos employés comportent une entrée semblable à ceci, pouvant être générée avec une commande d'assistance dans cloudflared :
Host *.ssh.cloudflare.com
ProxyCommand /usr/local/bin/cloudflared access ssh –hostname %h.ssh.cloudflare.com
Il est intéressant de noter qu'OpenSSH prend en charge FIDO2 depuis la version 8.2, mais nous avons constaté qu'il existe des avantages à adopter une approche unifiée du contrôle d'accès, où toutes les listes de contrôle d'accès sont tenues à jour dans un emplacement unique.
Ce que nous avons appris et comment notre expérience peut vous aider
Après ces derniers mois, il ne fait aucun doute que FIDO2 et WebAuthn représentent l'avenir de l'authentification. Au total, il nous aura fallu quelques années, et nous espérons que ces enseignements pourront être utiles à d'autres organisations qui cherchent à se moderniser avec une authentification basée sur FIDO.
Si vous souhaitez déployer des clés de sécurité au sein de votre organisation ou si vous êtes intéressé par les produits Zero Trust de Cloudflare, écrivez-nous à [email protected]. Bien que nous soyons ravis que nos initiatives de prévention nous aient aidés à résister à la dernière vague d'attaques par phishing et par ingénierie sociale, notre équipe de sécurité continue de se développer avec l'objectif de prévenir les prochaines attaques, quelles qu'elles soient.