Zero Trust : comment Google est devenu une « entreprise modèle » avec BeyondCorp

Google, champion du zero trust ? La société est, en tout cas, souvent présentée comme une référence en la matière.

Il faut dire qu’elle communique ouvertement sur ses démarches depuis bientôt une dizaine d’années. Sous une marque ombrelle : BeyondCorp, dévoilée fin 2014 avec la promesse d’une « nouvelle approche de la sécurité d’entreprise ».

Le postulat : le périmètre informatique de l’entreprise s’agrandit… et ce qui se trouve dedans n’est plus forcément sûr.

Dans ce contexte, l’accès doit dépendre uniquement de l’appareil et de l’utilisateur, peu importe sa localisation réseau. Et tout accès doit être authentifié, autorisé et chiffré.

Inventaire, VLAN, proxy : les premiers jalons de BeyondCorp

Au moment où Google présentait BeyondCorp, l’essentiel des bases était posé. À commencer par un inventaire permettant de suivre les appareils sur l’ensemble de leur cycle de vie. Le principe : ceux présents dans la base et considérés comme sécurisés peuvent recevoir un certificat spécifique.

Celui-ci est stocké dans un TPM (matériel ou logiciel) ou dans un magasin. Renouvelé périodiquement, il est employé pour toute connexion à une ressource. Les utilisateurs – et les groupes – sont eux aussi stockés dans des bases, intégrées avec les processus RH (arrivées, départs, mobilités internes). L’authentification (à deux facteurs) se fait par l’intermédiaire d’un portail SSO externalisé qui génère des jetons éphémères.

Côté réseau, l’objectif était de prendre ses distances avec l’intranet « de confiance », au profit d’une segmentation en VLAN dépourvus de privilèges. Le principal pour les terminaux authentifiés. Un second, de type « invité », pour ceux non gérés ou non reconnus. L’assignation, dynamique, s’appuie sur un serveur RADIUS. Elle découle de la décision d’un moteur de contrôle d’accès embarqué dans un proxy placé devant toutes les applications.

Avant que Google lance sa démarche zero trust, l’accès à ses apps se faisait soit directement via le réseau privilégié, soit par VPN pour les connexions externes.

L’ère BeyondCorp est synonyme de migration en deux étapes.
D’abord, substituer le proxy aux accès VPN. Ensuite, le généraliser pour l’accès depuis tout réseau.

Pour l’extinction du VPN, trois grandes règles.

Premièrement, restreindre son usage aux utilisateurs capables de prouver qu’ils en ont besoin. Deuxièmement, sur cette population, supprimer les droits d’accès passé une période d’inactivité. Troisièmement, encourager les utilisateurs effectivement actifs à migrer dès lors qu’on est (quasi) certain que tous leurs workflows sont disponibles au travers du proxy.

Pour s’assurer que c’est le cas, on examine le trafic à deux niveaux. D’une part, en analysant un échantillon de données issues des switchs. De l’autre, sur les terminaux, avec une sonde logicielle qui simule le réseau sans privilèges. À partir du moment où on dépasse une proportion de trafic « compatible » (pouvant être acheminé vers le reste du réseau de l’entreprise), on peut envisager d’amorcer le basculement.

Le seuil est à 99,99 % sur 30 jours consécutifs. Une fois atteint, on passe la sonde logicielle en mode « actif » : en plus de journaliser, elle bloque le trafic incompatible. Après 30 jours supplémentaires, si le seuil est maintenu, on le consigne dans l’inventaire. Ce qui fournit un signal fort pour assigner l’appareil au réseau sans privilèges lors de sa prochaine authentification RADIUS.

Les défis de l’évaluation continue

Début 2016, BeyondCorp faisait l’objet d’une deuxième publication. Google y détaillait, entre autres, le processus de mise à l’échelle de son inventaire. Avec notamment des précisions sur les sources de données.

Côté interne, il listait Active Directory, Puppet et Simian. En externe, des scans de vulnérabilités, des autorités de certification ou encore des éléments d’infrastructure réseau de type tables ARP. Le tout accompagné d’un ordre de grandeur : en moins de deux ans, sur un périmètre de 15 sources, plus de 80 To de données ingérées.

Observées pour certaines (version de l’OS, logiciels installés, date de la dernière analyse de sécurité…). Fournies pour d’autres (propriétaires d’appareils, listes d’autorisations, attributions DNS et DHCP…), autant dans l’optique de commencer à constituer l’inventaire que de s’adapter aux clients non personnalisables à l’image d’une partie des imprimantes. Google revenait également sur les défis liés à la qualité de ces données (gestion des doublons, restauration d’un état précédent de l’inventaire), à leur propagation (disponibilité vs latence)… ainsi qu’à leur corrélation.

Par exemple, le fait que différents identifiants peuvent se rattacher à un même appareil (numéro de série dans un système de gestion d’actifs, numéro de disque dans un gestionnaire de chiffrement, adresse MAC dans une base ARP). Et l’amplification potentielle du phénomène à l’échelle du cycle de vie des appareils, étant donné qu’il arrive de remplacer des composants, voire d’en échanger.

Un proxy à toute épreuve ?

Toujours en 2016, Google consacrait une publication au proxy. On en découvrait le substrat. À avoir la flotte de proxys HTTP(S) inversés formant le front-end des applications web du groupe américain. Un socle sur lequel avaient été greffées des briques d’authentification, d’autorisation et de journalisation automatisée spécifiques à BeyondCorp.

Le proxy est capable de gérer les requêtes faites sans identifiants utilisateur, comme celles d’un gestionnaire de logiciels qui tenterait de télécharger des mises à jour. Il est « transparent » pour les back-end, qui peuvent implémenter leurs propres flux d’authentification, potentiellement plus granulaires. Le chiffrement des communications repose sur le framework LOAS (Low Overhead Authentication System).

Avec lui, on peut transmettre des métadonnées qui permettront par exemple d’activer des fonctionnalités au vol en fonction du niveau de confiance des appareils. Le proxy répond à deux types de règles : globales ou spécifiques à un service. Il embarque un mécanisme de provisionnement en libre-service permettant aux propriétaires d’applications de modifier eux-mêmes la configuration.

Et surtout plusieurs « parades ». On peut en citer trois.

Tout d’abord, la création de tunnels point à point pour gérer les logiciels tiers incapables de présenter des certificats TLS ou qui supposent une connectivité directe. Ensuite, le serveur d’autorisation HTTP inclus dans le flux d’ouverture de connexion pour limiter l’effet de latence induit sur Chrome Remote Desktop, principale solution de bureau à distance des employés du groupe. Enfin, les bacs à sable, sous forme d’instances séparées du proxy que le répartiteur de charge ignore, mais que les développeurs peuvent exploiter.

À ce stade de la démarche BeyondCorp, les ordinateurs utilisaient, en guise d’identifiants « persistants », des certificats X.509. Leur rotation impliquant de relancer le navigateur pour s’assurer de la fermeture des sockets, Google envisageait de passer à un identifiant tel que ceux exploités sur mobile (sur iOS, ForVendor, codé « en dur » ; sur Android, celui de l’EMM).

Des systèmes et des utilisateurs

Début 2017, on franchissait une première étape vers la commercialisation de BeyondCorp : Google ouvrait l’accès à une version expérimentale de son proxy. Au cours de l’été, il en annonçait la disponibilité globale pour ses environnements App Engine, Compute Engine et GKE.

En parallèle, il publiait un nouveau document, axé sur l’équilibre productivité-sécurité. Au programme, l’approfondissement de la réflexion sur les fameux certificats. Et sur l’édifice mis en place pour les acheminer vers les appareils (développement d’une autorité de certification, création d’API, déploiement de la couche 802.1x sur les switchs, etc.).

Au menu également, d’autres cas particuliers traités avec la solution « tunnel chiffré ». Par exemple, les applications liées à des serveurs de licence non HTTP ou celles invoquant des méthodes à distance. Et côté infrastructure, les serveurs NFS/CIFS ne respectant pas les propriétés minimales requises en matière de chiffrement et d’authentification.

Deux solutions substitutives : stockage local + backup cloud ou remplacement par Google Drive. Esquissée dans ce document, l’expérience utilisateur allait véritablement être abordée à l’automne, avec une publication dédiée. Google y explique insister, dès l’intégration des employés, sur leur principal point de contact avec BeyondCorp : l’extension Chrome. Et évoque quelques-unes de ses capacités, dont la détection de portails captifs (hôtels,

BeyondCorp rallie les EDR

À la Cloud Next’18, Google affichait un premier « gros » cas client, en l’objet de Veolia, avec un déploiement zero trust couvrant 169 000 employés à l’échelle mondiale. L’édition suivante allait mettre en lumière le cas Airbnb. Et être le théâtre du lancement d’une alliance avec un groupement de fournisseurs d’EDR.

Initialement, Check Point, Lookout, Palo Alto Networks, Symantec et VMware. Tous s’engageaient à partager des données de posture de sécurité pour alimenter le moteur décisionnel de BeyondCorp.

Entre-temps (automne 2018), Google avait apporté des précisions à propos de ses mécanismes d’évaluation continue. Et des outils qui le soutenaient. OS Query de Facebook en faisait partie, pour la télémétrie. Defender Credential Guard (de Microsoft) aussi, au sein d’une liste de conseils pour orchestrer le déploiement des stratégies de sécurité. Limiter l’éventail des configurations hardware en est une. Utiliser des listes blanches plutôt que des listes noires (plus complexes à maintenir, car potentiellement infinies) en est une autre.

Dans la pratique, l’hétérogénéité des plates-formes et des menaces qui les ciblent complique l’application uniforme des stratégies. Aussi Google a-t-il normalisé ses méthodes de contrôle. Et défini, autant que possible, des seuils de conformité plutôt que des valeurs absolues. Tout en adoptant une démarche progressive de déploiement, fonction des populations et des niveaux de criticité.

Vers la sécurisation du cloud

Fin 2019 émergeait une nouvelle marque : BeyondProd. Ou BeyondCorp appliqué aux microservices.

Dans ce cadre, Google met en œuvre des concepts tels que les points de terminaison de service mutuellement authentifiés, la sécurité des données en transit, la provenance de code de bout en bout et le maillage de services.

En 2020, Citrix, Crowdstrike, Jamf et Tanium rejoignaient l’alliance BeyondCorp. L’offre commerciale s’enrichissait quant à elle d’une solution d’accès à distance… qui allait devenir, début 2021, BeyondCorp Enterprise. Sans agent (via Chrome) et exploitant les points de présence du réseau Google.

Une version Essentials a été lancée cette année. Elle associe contrôle d’accès contextuel, DLP, filtrage d’URL et protection contre les malwares.

Illustration : © Google