BeyondCorp : Google détaille son approche de la sécurité sans périmètre

Une approche basée sur la confiance

De fait, il semble bien décidé à partager son expérience. Dans un rapport d’étape, quatre de ses ingénieurs s’attachent à détailler la mise en œuvre concrète de cette initiative, en incluant « les défis et les leçons apprises » en cours de route.

L’ensemble repose sur des niveaux de confiance « représentant les niveaux croissants de sensibilité » des ressources. Celle-ci sont les applications, les services et les infrastructures « sujet au contrôle d’accès » : « cela peut inclure n’importe quoi depuis les bases de connaissance en ligne jusqu’aux bases de données financières ». Un niveau de confiance minimum requis est associé à chacune de ces ressources.

Le niveau de confiance associé à un appareil tentant d’accéder à une ressource est déterminé par un système dédié, le Trust Inferer, qui « analyse et annote l’état de l’appareil en continu ». C’est lui qui affecte donc à un appareil le niveau de confiance maximal auquel il est susceptible d’accéder en fonction de son état et, en conséquence, « le VLAN qu’il pourra utiliser sur le réseau interne ». Ces informations sont enregistrées dans un registre dédié et actualisées à chaque changement d’état de l’appareil.

Un dispositif de contrôle d’accès se charge alors de faire respecter les règles définies par les administrateurs, en fonction des informations contenues dans le registre d’inventaire des appareils. Ce contrôle d’accès s’étend à tous les composants de l’infrastructure susceptible de jouer un rôle de passerelle vers les ressources : commutateurs réseau, serveurs SSH, proxies Web, etc.

Tout est suspect

L’un des points clés de cette approche est la suspicion généralisée. Le terme appareil recouvre ainsi un ensemble assez vaste : « un appareil est une collection de composants physiques et virtuels qui agit comme un ordinateur, alors qu’un hôte est une photographie de l’état d’un appareil à un instant donné ».

Ainsi, le service d’inventaire « contient des informations sur les appareils, leurs hôtes correspondants, et sur les décisions de confiance appliquées aux deux ». Ce service se nourrit de nombreuses sources, à commencer par l’annuaire Active Directory, ainsi que les outils d’administration Puppet et Simian (développé en interne par Google, sur la base du projet Munki, et reversé à la communauté du libre), mais également par « agents sur les appareils, les systèmes de gestion des configuration et les systèmes de gestion des actifs corporate ». Il s’alimente également auprès de scanners de vulnérabilités, d’autorités de certification et d’éléments d’infrastructure réseau « comme les tables ARP ».

Au total, Google indique avoir ingéré un total de plus de 80 To de données sur les appareils connectés à son infrastructure. Et pas question là de droit à l’oubli : « conserver les données historiques est essentiel pour nous permettre de comprendre le cycle de vie de bout en bout d’un appareil donné, suivre et analyser les tendances à l’échelle de la flotte complète, et réaliser des audits de sécurité ainsi que des enquêtes ».

Un déploiement progressif

Sans surprise, Google s’est donc engagé dans une mise en œuvre graduelle de son initiative BeyondCorp, en commençant par un « sous-ensemble de passerelles avec un service de méta-inventaire intérimaire », et « une petite poignée de sources contenant majoritairement des données prescrites » - des données gérées manuellement, comme la propriété d’un appareil, par opposition aux données observées et remontée par l’infrastructure.

Mais parallèlement, le géant du Web a travaillé au développement d’une solution de méta-inventaire capable de fonctionner à plus grande échelle sans introduire de latence susceptible de pénaliser les utilisateurs : « le service d’inventaire d’appareils agrège des données de plus de 15 sources, ingérant 30 à 100 changements par seconde en fonction du nombre d’appareils générant activement des données ».

La corrélation de ces données, nécessaire à l’établissement des niveaux de confiance, s’est avérée particulièrement « complexe », poussant les ingénieurs de Google à « utiliser un certificat X.509 comme identifiant persistent d’appareil ». De quoi leur permettre de disposer de deux fonctionnalités clés : « si le certificat change, l’appareil est considéré comme un nouvel appareil, même si tous les autres éléments d’identification restent les mêmes ». Et s’il est installé sur un autre appareil, les algorithmes de corrélation détectent une anomalie et « dégradent le niveau de confiance en réponse ».

Ne pas affecter les utilisateurs

Un tel projet est éminemment susceptible de perturber les utilisateurs dans leur quotidien. Pour éviter cela, les équipes de Google ont réalisé un inventaire complet des workflows en s’appuyant sur l’examen du trafic réseau. L’occasion de découvrir des services qui auraient dû avoir été arrêtés « mais qui continuaient de fonctionner sans raison claire ».

Cette collecte a conduit les ingénieurs à se rapprocher des propriétaires des services identifiés pour les migrer vers des passerelles prêtes pour l’initiative BeyondCorp. Une migration aisée pour certains, mais plus difficile pour d’autres « qui ont nécessité des exceptions aux règles » de sécurité : « mais nous nous sommes assurés que tous les propriétaires de services soient tenus responsables des exceptions ». Des exceptions à la durée de vie limitée : « la pression s’applique sur les fournisseurs de services et les développeurs d’applications pour qu’ils configurent leurs services correctement ».

Mais ces exceptions ont accru « la complexité au sein de l’écosystème BeyondCorp » jusqu’à rendre difficile la gestion de certaines demandes de support des utilisateurs. Un service spécifique d’analyse des décisions du système d’attribution des niveaux de confiance a dû être développé.