Ce contenu a été mis à jour pour la dernière fois en juin 2024, et correspond à l'état des connaissances à sa date de rédaction. Les règles et les systèmes de sécurité Google peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.
Google exploite une infrastructure de calcul distribuée, multi-locataire et à l'échelle mondiale pour fournir des produits et des services à des milliards de personnes dans le monde entier. Cette infrastructure doit équilibrer les priorités concurrentes de sécurité, de fiabilité, de résilience, d'efficacité, de vitesse de développement, de débogage, etc.
Ce document décrit certains des mécanismes que nous utilisons pour maintenir une stratégie de sécurité de pointe pour les services exécutés dans l'environnement de production de Google. Ces services couvrent tout le spectre de la sensibilité à la sécurité, des tests de développement qui n'ont aucun accès aux données sensibles à l'infrastructure d'identité critique. Ces services effectuent des tâches telles que le traitement des données utilisateur, la gestion des déploiements de logiciels, ainsi que le provisionnement et la gestion du cycle de vie des machines physiques individuelles.
Ce document décrit les contrôles de sécurité qui permettent de protéger les trois couches clés suivantes de notre infrastructure :
- Services de production, qui incluent les services les plus critiques pour la sécurité (également appelés services fondamentaux)
- Machines de production
- Charges de travail de production
Nous appliquons ces contrôles afin que le personnel Google n'ait accès aux services, aux machines et aux charges de travail qu'à des fins professionnelles légitimes (par exemple, pour l'accès à la maintenance) et pour se prémunir contre les risques d'utilisation abusive et la compromission des comptes personnels. Ces contrôles offrent une protection supplémentaire en profondeur qui complète les contrôles de sécurité de l'infrastructure existants qui aident à prévenir la compromission de comptes.
Amélioration continue
Les contrôles décrits dans cet article sont utilisés dans l'environnement de production de Google. De nombreux services, y compris les services fondamentaux, utilisent les niveaux de contrôle les plus résents que nous proposons. Toutefois, en raison de la portée et de la complexité de l'infrastructure de Google, les services de production individuels ont souvent des exigences uniques et peuvent nécessiter un délai supplémentaire pour implémenter les dernières recommandations. Grâce à une culture d'amélioration continue, les équipes d'ingénierie de la fiabilité des sites (SRE) et de sécurité de Google adaptent constamment les contrôles de sécurité pour répondre à l'évolution du paysage des menaces.
Protection des services de production
Google contribue à protéger l'intégrité des services de production afin que le personnel Google n'y ait accès que pour un usage professionnel légitime, comme la maintenance. Il existe deux principales façons d'accéder aux services exécutés dans l'environnement de production : par un accès administrateur et par la chaîne d'approvisionnement logicielle.
La liste suivante décrit les commandes qui permettent de protéger chaque chemin d'accès.
Contrôles des accès administrateur : les services de production nécessitent une maintenance régulière (par exemple, des déploiements de binaires ou de configurations). Chez Google, notre objectif est que ces opérations soient effectuées via l'automatisation, des proxys sécurisés ou un accès d'urgence audité, conformément à la philosophie de production sans contact. La suite de commandes qui supprime l'accès humain aux éléments de production est appelée No Persons (NoPe). NoPe permet à Google de déployer des contrôles d'accès basés sur la sensibilité d'un service de production et sa capacité à atteindre une stratégie encore plus solide grâce à une amélioration continue.
Par exemple, Google n'autorise pas l'accès unilatéral aux services fondamentaux. Même l'accès en cas d'urgence nécessite l'approbation d'autres membres du personnel Google. Un accès est unilatéral si une personne peut effectuer l'accès sans l'approbation d'une autre personne autorisée.
Contrôles de la chaîne d'approvisionnement logicielle : la majorité des charges de travail de production de Google, y compris les services fondamentaux, exécutent des binaires et des configurations de tâches qui sont créés de manière vérifiable à partir d'un code examiné par des pairs et situé dans une source fiable. Nous appliquons ce processus à l'aide de l'autorisation binaire pour Borg (BAB).
Le schéma suivant illustre les commandes qui permettent de protéger un service de production.
Lorsque nous appliquons les niveaux les plus élevés de NoPe et BAB, nous nous assurons qu'aucun membre du personnel n'a un accès unilatéral aux services fondamentaux, même en cas d'urgence, et que tout accès privilégié dont il bénéficie a une portée et une durée bien définies. L'accès privilégié est un niveau d'accès élevé accordé au personnel pour administrer des services de production critiques dans des circonstances particulières qui ne sont pas traitées par l'automatisation. Nous faisons une exception à cette règle pour nous assurer que Google dispose d'un moyen de sortir de situations de blocage.
De nombreux autres services de production, y compris des produits tels que Filestore ou Cloud SQL, et des produits d'infrastructure interne tels que Borg et Spanner, sont configurés pour utiliser les niveaux les plus élevés de NoPe et BAB. Nous nous efforçons constamment de faciliter l'adoption de NoPe et de BAB par les propriétaires de services de production au fil du temps.
Commandes d'accès administrateur
Sur Borg, les membres d'un rôle de production peuvent lire, écrire ou supprimer les données qui leur appartiennent, et exécuter du code en utilisant l'autorité du rôle. Un rôle de production est une identité qui peut exécuter des charges de travail dans l'environnement de production de Google.
L'appartenance permanente à des rôles de production comporte le risque de conséquences involontaires pour la production et le risque que ces privilèges puissent être utilisés à mauvais escient. Toutefois, la mission de la SRE exige que les équipes soient habilitées à gérer les services dont elles sont responsables. Par conséquent, la suppression complète de l'accès peut ne pas être une stratégie viable.
La suite NoPe permet de configurer l'accès de manière à équilibrer les exigences concurrentes d'autonomisation des équipes et de protection des systèmes de production. Avec NoPe, les membres du personnel de Google ont des contraintes sur les droits d'accès de leurs comptes lorsqu'ils tentent d'accéder aux services de production. NoPe permet les contraintes suivantes :
- Les demandes d'accès nécessitent un approbateur et une justification : un contrôle appelé autorisation multipartie (MPA) permet de s'assurer que le personnel Google ne peut pas accéder aux services de production sans justification professionnelle et sans l'approbation d'une autre personne autorisée à vérifier la demande d'accès.
- Aucun accès direct aux rôles de service de production : le personnel ne peut accéder aux services de production qu'à l'aide de proxys sécurisés pour NoPe. Les proxys sécurisés sont conçus de sorte qu'un ensemble bien défini d'instructions puisse être exécuté. Toutes les commandes que les organisations de sécurité et de SRE de Google considèrent comme risquées (par exemple, désactiver un service, accéder à des données ou les supprimer) nécessitent également l'autorisation de modification.
- Aucun rôle de production permanent : un contrôle appelé accès à la demande oblige le personnel à demander un accès temporaire plutôt que d'autoriser les comptes personnels à disposer de droits d'accès permanents. Ce contrôle permet de s'assurer que les droits élevés ne sont accordés que temporairement et pour des raisons spécifiques.
- Surveillance des demandes d'accès du personnel aux services de production : Google exige un audit périodique des schémas d'accès aux rôles de production qui exécutent un service de production. L'objectif de l'audit est d'éliminer la nécessité de telles demandes à l'avenir, grâce à l'amélioration continue des API d'administration. L'accès aux services de production ne doit être réservé qu'aux situations d'urgence. Pour les services fondamentaux, le nombre de situations où l'accès est accordé est si faible qu'une équipe de sécurité effectue un audit de chaque accès accordé pour en confirmer la validité.
Les sections suivantes décrivent chaque commande en détail.
Autorisation multipartite pour NoPe
La MPA nécessite qu'un autre membre du personnel Google autorisé approuve une demande d'accès.
Pour les demandes d'accès à des services suffisamment sensibles, la MPA exige également que le personnel fournisse une justification professionnelle correspondant à une urgence de production en cours pour chaque demande.
Ces deux conditions constituent des obstacles à l'utilisation abusive des accès.
Proxys sécurisés pour NoPe
Les proxys sécurisés sont des outils qui exposent un ensemble de commandes prédéfinies que le proxy sécurisé peut exécuter au nom d'un appelant. Les proxys sécurisés implémentent des stratégies d'autorisation précises et basées sur des règles pour imposer des contraintes d'accès aux services de production. Ces règles peuvent, par exemple, exiger l'approbation d'une autre personne autorisée pour exécuter des commandes susceptibles d'avoir un impact négatif sur la sécurité ou la fiabilité (par exemple, des commandes qui suppriment des fichiers). Les règles peuvent également autoriser l'exécution de certaines commandes sécurisées (par exemple, celles qui listent l'utilisation des ressources) sans nécessiter d'approbation. Cette flexibilité est essentielle pour réduire les tâches opérationnelles.
En cas d'utilisation abusive, les comptes sont toujours limités aux opérations autorisées par le proxy sécurisé. Le compte ne peut exécuter que des commandes sécurisées de manière unilatérale, tandis que les opérations privilégiées nécessitent l'approbation d'une autre personne autorisée. Toutes les opérations laissent une trace d'audit claire.
Pour en savoir plus sur les proxys sécurisés, consultez la présentation SREcon sur la production sans contact. La production sans contact est un ensemble de principes et d'outils qui imposent que chaque modification de production soit effectuée par automatisation (sans intervention humaine), prévalidée par un logiciel ou effectuée à l'aide d'un mécanisme d'urgence audité.
Accès à la demande
L'accès à la demande (AoD) permet à Google de réduire les droits d'accès du personnel en remplaçant l'abonnement permanent par un abonnement éligible.
Les membres éligibles d'un rôle n'ont pas accès à ses droits. Au lieu de cela, si un membre d'un rôle éligible a besoin d'un accès, il peut demander un accès temporaire, appelé attribution AoD. Si elle est approuvée par une autre personne autorisée, l'attribution d'un accès à la demande permet au demandeur de devenir membre du rôle pendant une durée limitée, généralement moins d'une journée.
Le modèle d'abonnement éligible permet au personnel de demander uniquement le sous-ensemble d'accès dont il a besoin pour la durée requise. Concrètement, vous pouvez considérer l'AoD comme un sudo de production limité dans le temps, semblable à la commande sudo -u sous Unix, qui vous permet d'exécuter certaines commandes avec les autorisations élevées associées à un utilisateur spécifique. Toutefois, contrairement au sudo Unix, la réception d'un accès AOD nécessite une justification commerciale et une MPA, et laisse une trace d'audit. Les autorisations AOD sont également limitées dans le temps.
En sécurisant les droits sensibles associés aux abonnements éligibles, vous vous assurez que les comptes ne peuvent accéder à ces droits que s'ils disposent d'une autorisation active, même en cas d'abus d'accès improbable. L'adoption de proxys sécurisés élimine en grande partie le besoin de telles autorisations.
Surveillance des demandes d'accès
Bien que de nombreux domaines de production de Google utilisent NoPe pour réduire l'accès, les autorisations d'accès en lecture seule sont extrêmement rares pour nos rôles de production les plus sensibles et sont réservées aux interventions d'urgence. De plus, chaque événement déclenche un audit manuel a posteriori. L'objectif de l'audit est de réduire la fréquence des attributions de droits d'accès AoD à l'avenir (par exemple, en utilisant ces événements pour motiver les améliorations des API d'administration).
Google surveille en permanence les autorisations AoD et les actions entreprises dans l'ensemble de l'entreprise. Nous utilisons les données de surveillance en temps réel pour détecter les compromissions potentielles et identifier les domaines dans lesquels nous pouvons réduire les accès. En cas d'incident, le journal d'audit permet une réponse rapide.
Autorisation binaire pour Borg
Tout comme NoPe permet de protéger les chemins d'accès privilégiés, l'autorisation binaire pour Borg (BAB) permet de protéger la chaîne d'approvisionnement logicielle de Google. La BAB permet de s'assurer que les logiciels de production et les configurations de tâches sont examinés et approuvés avant d'être déployés, en particulier lorsqu'ils peuvent accéder à des données sensibles. Initialement conçus pour l'infrastructure de production de Google, les principaux concepts de la BAB sont désormais inclus dans une spécification ouverte appelée Supply Chain Levels for Software Artifacts (SLSA).
La BAB permet de s'assurer que le personnel ne peut pas modifier le code source, exécuter des binaires ni configurer des tâches sans examen par les pairs, et que tout artefact binaire ou configuration logicielle est créé de manière vérifiable à partir d'un code source examiné par les pairs et validé.
Pour en savoir plus, consultez la section Autorisation binaire pour Borg.
Protection des machines de production
En plus de renforcer les chemins d'accès privilégiés et de préserver l'intégrité de la chaîne d'approvisionnement logicielle, Google protège les machines sur lesquelles s'exécutent les services de production. En particulier, nous implémentons les éléments suivants :
Contrôles d'accès au shell : la plupart des employés de Google n'ont pas d'accès shell (par exemple, via SSH) aux machines de production ni aux charges de travail exécutées sur Borg, le système de gestion de clusters de Google. Les utilisateurs doivent utiliser des proxys sécurisés qui nécessitent qu'une autre personne autorisée examine et approuve chaque commande avant qu'elle ne soit exécutée.
Seules quelques équipes qui travaillent sur l'infrastructure de bas niveau conservent un accès non unilatéral au shell afin de pouvoir déboguer les problèmes les plus complexes pour lesquels les proxys sécurisés ne sont pas pratiques. Un accès est non unilatéral s'il nécessite l'autorisation d'un ou de plusieurs membres du personnel autorisés supplémentaires. Google fait une exception où l'accès shell unilatéral est autorisé : pour s'assurer que Google dispose d'un moyen de sortir des situations de blocage.
Contrôles des accès physiques : les machines nécessitent une maintenance physique régulière pour fonctionner correctement. Pour s'assurer que les techniciens du centre de données n'accèdent aux machines physiques que pour des raisons professionnelles valides, Google utilise des contrôles physiques vers logiques.
Contrôles du micrologiciel et du logiciel système : Google met en œuvre un flux de sécurité de démarrage sécurisé basé sur une racine de confiance matérielle. La racine de confiance matérielle permet de garantir l'intégrité du micrologiciel de démarrage et du logiciel système de chaque machine.
Le schéma suivant illustre les commandes qui permettent de protéger une machine dans un centre de données.
Contrôles des accès shell
SSH est un outil administratif Open Source très populaire qui permet d'accéder largement aux serveurs Linux. Sans contrôle des accès SSH, les comptes disposant des identifiants appropriés peuvent obtenir un shell qui leur permet d'exécuter du code arbitraire de manière difficile à auditer.
Avec un accès shell à un service de production, le compte peut, par exemple, modifier le comportement d'une tâche en cours d'exécution, exfiltrer des identifiants ou utiliser des identifiants pour s'implanter de manière persistante dans l'environnement.
Pour atténuer ce risque, nous utilisons l'ensemble de commandes suivant, qui remplace l'accès SSH aux machines de production par des méthodes alternatives sécurisées :
- API étroites : pour les équipes dont les workflows sont bien définis et qui nécessitaient auparavant SSH, nous remplaçons SSH par des API étroites et vérifiables.
- Proxys sécurisés pour SSH : pour les équipes qui ont besoin d'un accès plus flexible, les proxys sécurisés permettent d'autoriser et d'auditer les commandes individuellement.
- MPA : lorsque les SRE ont besoin d'un accès SSH d'urgence à une machine, Google exige une justification professionnelle et l'approbation d'une personne autorisée. Les transcriptions complètes des sessions shell sont consignées.
- Scénarios de blocage : seule exception où l'accès SSH unilatéral est autorisé. Les transcriptions complètes des sessions shell sont consignées.
Ces contrôles permettent de trouver un équilibre entre le besoin d'un accès shell légitime et le risque associé à un accès shell trop étendu.
Contexte : SSH chez Google
Par le passé, Google utilisait SSH pour administrer ses machines. Le développement de Borg a permis à la plupart des employés de Google de ne plus avoir besoin d'un accès direct aux machines Linux qui exécutent leurs binaires, mais l'accès shell a persisté pour plusieurs raisons :
- Le personnel a parfois besoin d'un accès direct à une machine à des fins de débogage.
- L'accès SSH est un outil pédagogique précieux pour comprendre les différentes couches d'abstraction.
- Dans les scénarios de reprise après sinistre imprévus, les outils de niveau supérieur peuvent ne pas être disponibles.
Pour trouver un équilibre entre ces raisons et le risque de sécurité qu'elles entraînent, Google a suivi une série d'étapes pour éliminer progressivement le risque et l'utilisation de SSH.
Jalon de contrôle des accès et de surveillance centralisés
Google a investi dans un système central de surveillance et d'autorisation SSH appelé autorisation de surveillance basée sur l'identité de l'hôte (HIBA). HIBA offre une visibilité sur toute utilisation de SSH et permet d'appliquer des règles d'autorisation strictes. Les tentatives SSH sont consignées, non seulement par la machine cible, mais aussi par le proxy BeyondCorp centralisé. Les commandes exécutées par l'interface système sont consignées et transmises aux pipelines de détection des comportements malveillants. Toutefois, la détection est intrinsèquement réactive et vulnérable à l'évasion et à l'obscurcissement.
Élimination du jalon d'accès unilatéral
Pour la plupart des utilisateurs, Google a supprimé l'accès shell (par exemple, via SSH) aux machines de production ou aux charges de travail exécutées sur Borg. Toutefois, il reste accessible aux équipes de développement sur les machines de test (par exemple, les machines utilisées pour qualifier un nouveau matériel ou un nouveau logiciel de bas niveau, mais qui n'exécutent pas de services de production).
API étroites
Certaines équipes Google qui utilisaient historiquement SSH pour exécuter un nombre limité de commandes définies précisément (par exemple, dans un playbook) ou pour obtenir des données dont la structure est prévisible utilisent désormais des API à définition étroite qui répondent au cas d'utilisation spécifique et fournissent des données structurées.
Les API étroites comportent un petit nombre de méthodes alignées sur les parcours utilisateur courants et abstraient les détails d'accès de bas niveau. Par conséquent, elles constituent la solution privilégiée de Google, car elles offrent une sécurité et une auditabilité optimales. En les créant sur l'infrastructure d'appel de procédure distante (RPC) de Google, nous bénéficions de décennies d'investissements dans la sécurité et l'audit.
Proxys sécurisés pour SSH
Certaines équipes Google ne peuvent pas déterminer à l'avance les commandes dont elles pourraient avoir besoin. Dans ce cas, Google utilise un daemon d'exécution de commandes qui n'accepte que les requêtes d'exécution de commandes arbitraires provenant d'un proxy de confiance géré par une équipe de sécurité. Cette technologie est semblable à celle utilisée dans les proxys sécurisés pour NoPe.
Les proxys sécurisés pour SSH sont responsables de l'autorisation précise de l'exécution des commandes et de l'audit. L'autorisation est basée sur l'argument et l'environnement de la commande, les paramètres de limitation de débit, les justifications professionnelles et la MPA. Ce processus d'autorisation permet d'appliquer des restrictions arbitrairement précises sur les commandes pouvant être exécutées en suivant les playbooks et les bonnes pratiques de l'équipe. En cas de défaillance inattendue qui n'est pas capturée dans les playbooks existants, le personnel peut toujours exécuter les commandes de débogage nécessaires après qu'un autre utilisateur autorisé les a approuvées.
MPA pour SSH
Les quelques équipes restantes qui travaillent sur l'infrastructure de bas niveau conservent un accès shell non unilatéral pour déboguer les problèmes les plus complexes.
SSH dans les scénarios de blocage
Google fait une exception lorsque un accès shell unilatéral est autorisé pour s'assurer qu'il peut résoudre les situations de blocage. Les clés SSH utilisées à cette fin sont générées avec un processus vérifiable distinct et stockées hors connexion sur un matériel résistant à la falsification. Lorsque ces clés sont utilisées, les transcriptions complètes de la session shell sont consignées.
Contrôles des accès physiques
Les centres de données Google sont des environnements complexes de serveurs, d'appareils de mise en réseau et de systèmes de contrôle qui nécessitent une large gamme de rôles et de compétences pour les gérer, les maintenir et les exploiter.
Google met en œuvre six couches de contrôles physiques et de nombreux contrôles logiques sur les machines elles-mêmes pour protéger les charges de travail dans le centre de données. Nous protégeons également un espace entre les machines, que nous appelons l'espace physique vers logique.
Les commandes physiques vers logiques fournissent des couches de défense supplémentaires via des commandes appelées renforcement de la machine, contrôle des accès basé sur les tâches et autodéfense du système. Les contrôles physique vers logique protègent contre un adversaire qui cherche à exploiter l'accès physique à une machine et à lancer une attaque logique sur les charges de travail de la machine.
Pour en savoir plus, consultez la page Comment Google protège l'espace physique vers logique dans un centre de données.
Commandes du micrologiciel et du logiciel système
La stratégie de sécurité d'une machine de centre de données est établie au démarrage. Le processus de démarrage de la machine configure le matériel de la machine et initialise son système d'exploitation, tout en garantissant qu'elle peut s'exécuter en toute sécurité dans l'environnement de production de Google.
À chaque étape du processus de démarrage, Google met en œuvre des contrôles de pointe pour garantir l'état de démarrage attendu et garantir la sécurité des données client. Ces contrôles garantissent que nos machines démarrent dans le logiciel prévu, ce qui nous permet de supprimer les failles susceptibles de compromettre la stratégie de sécurité initiale de la machine.
Pour en savoir plus, consultez la page Comment Google applique l'intégrité du démarrage sur les machines de production.
Protection des charges de travail
Conformément à notre philosophie zéro confiance, Google a également introduit des contrôles qui permettent de se prémunir contre les menaces de mouvement latéral entre les charges de travail ayant des exigences de sécurité différentes. L'infrastructure Google utilise une hiérarchie de charges de travail appelée Workload Security Rings (WSR). Le WSR permet de s'assurer que les charges de travail critiques ne sont pas planifiées sur les mêmes machines que les charges de travail moins sécurisées, tout en évitant un impact négatif sur l'utilisation des ressources. Le WSR regroupe les charges de travail en quatre classes de sensibilité (fondamentale, sensible, renforcée et non renforcée) et tente de les planifier dans différents pools de machines.
Le schéma suivant montre comment le WSR regroupe et planifie les charges de travail sur les machines fondamentales, de production et de développement.
Le WSR offrent une couche de défense supplémentaire contre l'élévation des privilèges locaux à l'aide d'attaques de vulnérabilité du noyau ou d'attaques par canal auxiliaire du processeur. Le WSR permet de s'assurer que seules les charges de travail présentant des exigences de sécurité similaires sont planifiées simultanément sur les mêmes machines. Pour implémenter le WSR, nous procédons comme ceci :
- Classification des charges de travail en fonction de leurs exigences de sécurité. Chaque classe est appelée anneau de charge de travail.
- Répartition des machines physiques entre plusieurs pools de machines isolés les uns des autres. En d'autres termes, nous éliminons les chemins de déplacement latéral entre les pools.
- Application de contraintes de planification pour empêcher l'exécution de charges de travail ayant des exigences de sécurité différentes sur la même machine. Ces contraintes de planification permettent d'atténuer le risque de compromission par élévation des privilèges locaux.
Par exemple, le WSR exige que les charges de travail fondamentales s'exécutent sur des machines dédiées et ne soient jamais planifiées en même temps que les charges de travail non fondamentales. Cette contrainte permet d'isoler fortement les charges de travail moins sécurisées.
Méthodes d'isolation des charges de travail
Les logiciels système modernes sont complexes, et les chercheurs en sécurité découvrent régulièrement des failles d'élévation des privilèges locaux, telles que des exploits zero-day du noyau ou de nouvelles attaques par canal auxiliaire du processeur. Le WSR, introduit pour à l'origine dans USENIX ;login:, permet à Google de réduire les risques associés à la colocalisation des charges de travail tout en maintenant une utilisation élevée des ressources.
Par défaut, Borg utilise des limites de processus au niveau de l'OS pour isoler les conteneurs. Ces processus offrent une limite d'isolation plus faible que les machines virtuelles qui utilisent la virtualisation matérielle. Cette isolation plus faible est généralement un bon compromis entre efficacité et sécurité pour les environnements multilocataires qui exécutent des charges de travail fiables. Une charge de travail approuvée est une charge de travail dont le binaire et la configuration ont été créés de manière vérifiable à partir d'un code examiné par des pairs et dont la provenance est attestée. Les charges de travail approuvées ne traitent pas de données non approuvées arbitraires. L'hébergement de code tiers ou l'encodage de vidéos sont des exemples de traitement de données non fiables.
Google s'assure de la fiabilité de ses binaires à l'aide de la BAB. Toutefois, la BAB ne suffit pas à garantir l'intégrité des charges de travail qui traitent des données non fiables. En plus de la BAB, ces charges de travail doivent également s'exécuter dans un bac à sable. Un bac à sable est un environnement contraint, comme gVisor, qui permet à un binaire de s'exécuter en toute sécurité. La BAB et les bacs à sable comportent des limites.
La BAB est un contrôle puissant pour les produits matures, mais elle peut entraîner des ralentissements en début de développement de nouveaux systèmes et lors de l'exécution de tests sans données sensibles (par exemple, optimisation de l'encodage de données déjà publiques). Cette limitation signifie que certains charges de travail doivent toujours s'exécuter sans BAB. Ces charges de travail présentent intrinsèquement un risque plus élevé d'élévation des privilèges locaux (par exemple, en exploitant une faille du noyau pour obtenir un accès racine local sur une machine).
L'exécution en bac à sable des charges de travail non fiables permet également de réduire les risques de sécurité, mais au prix d'une utilisation accrue du calcul et de la mémoire. L'efficacité peut chuter d'un pourcentage à deux chiffres en fonction de la charge de travail et du type de bac à sable. Pour obtenir un exemple d'impact sur les performances d'une charge de travail en bac à sable, consultez les analyses comparatives détaillées dans le guide des performances gVisor. Le WSR nous permet de résoudre les limites d'efficacité liées à l'isolation des charges de travail.
Workload rings
Google définit quatre classes de charges de travail en fonction de leurs exigences de sécurité : fondamentale, sensible, renforcée et non renforcée. Le tableau suivant les décrit plus en détail.
| Workload ring | Description |
|---|---|
| Élémentaire | Les charges de travail essentielles à la sécurité de Google, comme les services de gestion des identités et des accès Les charges de travail fondamentales présentent les exigences de sécurité les plus élevées et sacrifient régulièrement l'efficacité à une sécurité et une fiabilité accrues. |
| Sensible | Charges de travail susceptibles de provoquer des pannes généralisées ou qui ont accès à des données sensibles spécifiques à un produit, telles que des données utilisateur ou client. |
| Service renforcé | Concerne les charges de travail qui ne sont pas critiques pour la sécurité, mais qui ont adopté la BAB ou s'exécutent en bac à sable, de sorte qu'elles présentent peu de risques pour les charges de travail voisines. |
| Non renforcée | Tous les autres charges de travail, y compris celles qui exécutent du code non approuvé. |
Chez Google, nous classons les charges de travail critiques qui concernent des produits spécifiques comme sensibles, tandis que les charges de travail fondamentales sont celles qui peuvent avoir un impact sur tous les produits.
Contrairement aux charges de travail fondamentales et sensibles, nous pouvons classer n'importe quelle charge de travail comme renforcée en nous basant exclusivement sur les contrôles adoptés et le type d'entrée qu'elle traite. Avec les charges de travail renforcées, nous nous intéressons principalement à leur impact sur d'autres charges de travail. Les solutions de renforcement peuvent donc inclure l'exécution en bac à sable.
Pools de machines
Pour éviter de planifier des services sensibles avec des charges de travail moins fiables (par exemple, celles qui traitent des données non fiables sans bac à sable), nous devons les exécuter sur des pools de machines isolés. L'isolation des machines facilite la compréhension des invariants de sécurité, mais chaque pool de machines supplémentaire introduit des compromis en termes d'utilisation des ressources et de facilité de maintenance.
L'isolation des machines entraîne une utilisation moindre des ressources physiques, car il devient plus difficile de s'assurer que les pools de machines sont pleinement utilisés à mesure que nous ajoutons des pools. Le coût de l'efficacité peut devenir important lorsqu'il existe plusieurs pools de machines isolés et volumineux.
Comme l'empreinte de ressources des charges de travail fluctue dans chaque pool, l'isolation stricte ajoute une surcharge de gestion pour rééquilibrer et réutiliser périodiquement les machines entre les pools. Un tel rééquilibrage nécessite de vider toutes les charges de travail d'une machine, de redémarrer la machine et d'effectuer notre processus de nettoyage le plus lourd, qui permet de garantir l'authenticité et l'intégrité du micrologiciel.
Ces considérations signifient que l'implémentation de l'isolation des machines par Google doit permettre d'optimiser l'utilisation des ressources physiques tout en protégeant les charges de travail fondamentales et sensibles contre les adversaires.
Dans Kubernetes, cette approche est appelée isolation des nœuds. Les nœuds Kubernetes peuvent être mappés à des machines physiques ou virtuelles. Dans cet article, nous nous intéressons aux machines physiques. De plus, les produits Google Cloud tels que Compute Engine offrent un bail exclusif pour assurer l'isolation physique des machines.
Contraintes de planification de la charge de travail
Google provisionne les machines dans trois types de pools isolés : machines fondamentales, machines de production et machines de développement. Google gère plusieurs pools isolés qui hébergent des charges de travail fondamentales et sensibles, mais ce document présente chacun d'eux comme un seul pool pour plus de simplicité.
Pour offrir une protection optimale, nous déployons les contraintes de planification suivantes pour le WSR :
- Les charges de travail fondamentales ne peuvent s'exécuter que sur des machines fondamentales.
- Les charges de travail sensibles ne peuvent s'exécuter que sur des machines de production.
- Les charges de travail non renforcées ne peuvent s'exécuter que sur des machines de développement.
- Les charges de travail renforcées peuvent s'exécuter sur des machines de production ou de développement, de préférence sur des machines de production.
Le schéma suivant montre les contraintes de planification.
Dans ce schéma, les limites d'isolation séparent différentes classes de charges de travail, à la fois entre les pools de machines et au sein des pools. Les charges de travail fondamentales sont les seuls locataires des machines fondamentales dédiées. L'autorisation binaire ou l'exécution en bac à sable pour les charges de travail exécutées sur des machines de production permettent d'éviter les attaques par élévation des privilèges locaux. Sur les machines de développement, il existe un risque résiduel qu'une charge de travail non sécurisée puisse compromettre une autre charge de travail. Toutefois, ce risque est limité aux machines de développement, car les charges de travail sécurisées ne peuvent pas créer de jobs.
Les charges de travail renforcées sont planifiées sur des machines de production ou de développement en fonction de la disponibilité. Autoriser la planification dans plusieurs pools peut sembler contre-intuitif, mais il est essentiel d'atténuer la baisse de l'utilisation causée par les contraintes de planification. Les charges de travail renforcées comblent les lacunes introduites par l'isolation des jobs sensibles et non renforcés. De plus, plus l'empreinte des ressources renforcées est importante, plus les fluctuations de l'utilisation des ressources des deux autres classes peuvent être absorbées sans avoir à effectuer des mouvements coûteux entre les rings.
Le schéma suivant illustre les contraintes de planification imposées aux différentes classes de charges de travail. Une charge de travail renforcée peut se trouver sur une machine de production ou de développement.
En isolant les charges de travail fondamentales sur plusieurs pools fondamentaux, Google échange l'efficacité des ressources contre une sécurité accrue. Heureusement, l'empreinte de ressources des charges de travail fondamentales est généralement relativement faible, et les petits pools isolés de machines dédiées ont un impact négligeable sur l'utilisation globale. Toutefois, même avec une automatisation étendue, le maintien de plusieurs pools de machines a un coût. Nous améliorons donc constamment la conception de nos machines pour améliorer l'isolation.
Le WSR garantit que les charges de travail non fondamentales ne sont jamais autorisées à s'exécuter sur des machines fondamentales. Les machines fondamentales sont protégées contre les mouvements latéraux, car seules les charges de travail fondamentales peuvent s'exécuter sur ces machines.
Résumé des contrôles
Google utilise un certain nombre de contrôles dans son infrastructure pour protéger les services de production, les machines de production et les charges de travail. Les contrôles incluent les éléments suivants :
- Contrôles des accès administrateur et BAB pour les services de production
- Contrôles des accès shell, contrôles des accès physiques et contrôles du micrologiciel et du logiciel système pour les machines de production
- WSR pour différentes classes de charges de travail
Ensemble, ces contrôles appliquent des contraintes qui contribuent à protéger les utilisateurs et les clients de Google, ainsi que leurs données. Le schéma suivant illustre la manière dont les contrôles fonctionnent ensemble pour assurer la sécurité de Google.
Étape suivante
- Pour en savoir plus sur les contrôles de sécurité sur l'infrastructure Google, consultez la présentation de la sécurité sur l'infrastructure Google.
- Pour en savoir plus sur la culture de la sécurité de Google, consultez la section Créer des systèmes sécurisés et fiables (livre O'Reilly).
- Pour en savoir plus sur la production sans contact, consultez la présentation SREcon.
Auteurs : Michael Czapiński et Kevin Plybon