L'autorisation binaire pour Borg : comment Google vérifie la provenance du code et implémente son identité

Google a rédigé plusieurs livres blancs qui détaillent les projets que notre équipe spécialisée a développés en interne pour améliorer la sécurité, parmi lesquels BeyondCorp et BeyondProd. Pour en savoir plus sur la sécurité de Google, consultez le livre blanc Présentation de la sécurité sur l'infrastructure de Google.

Dans ce livre blanc, nous décrivons le processus d'examen du code, sa provenance 1 et la nécessité de mettre en place des mécanismes d'application. Nous nous concentrons sur le développement d'un contrôle d'application spécifique : l'autorisation binaire pour Borg. L'objectif de l'autorisation binaire pour Borg est de réduire les risques internes en s'assurant que les logiciels de production déployés chez Google sont dûment examinés et autorisés, en particulier s'ils ont accès aux informations sur les utilisateurs. Pour tous les produits Google, nous attachons une grande importance à la protection des informations sur les utilisateurs. Nous nous efforçons d'être aussi transparents que possible en termes de sécurité.

Le contenu du présent livre blanc est réputé correct et représente l'état des connaissances à sa date de rédaction, soit décembre 2019. Les règles et les systèmes de sécurité de Google Cloud peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.

Résumé à l'intention des responsables informatiques

  • Le risque lié aux initiés représente une menace pour la sécurité des informations sur les utilisateurs. Chez Google, nous faisons tout notre possible pour minimiser le risque que le personnel de Google utilise frauduleusement sa connaissance de l'entreprise ou accède sans autorisation aux informations sur les utilisateurs. Ceci comprend l'exécution d'une tâche non autorisée.
  • L'autorisation binaire pour Borg est une vérification interne d'exécution de déploiement qui minimise les risques internes en s'assurant que les logiciels de production et la configuration déployés par Google sont correctement examinés et autorisés.
  • L'autorisation binaire pour Borg s'assure que les déploiements de code et de configuration respectent au minimum certaines normes.
  • En dehors du contrôle des applications, l'autorisation binaire pour Borg peut également être utilisée lors d'un audit consultatif pour signaler que certaines conditions ne sont pas remplies.
  • L'adoption de l'autorisation binaire pour Borg permet à Google de réduire les risques internes, de prévenir d'éventuelles attaques et d'assurer l'uniformité des systèmes de production de Google.

La réduction des risques internes chez Google

Faisant de la sécurité une de nos priorités, nous avons mis en place des mesures pour limiter les risques internes, en particulier la possibilité pour le personnel de Google (ou toute autre personne de l'entreprise) d'utiliser ses connaissances ou ses accès pour commettre des actes malveillants. Les risques internes incluent également le scénario selon lequel un pirate informatique a compromis les identifiants d'un employé de Google pour faciliter son attaque. Nous avons consacré d'importantes ressources à l'innovation dans le domaine de la protection contre les risques internes. Chez Google, la protection des informations sur les utilisateurs est primordiale. Nous nous efforçons de les protéger de manière globale. Notre objectif est d'empêcher un employé de Google d'accéder aux informations sur les utilisateurs sans autorisation.

Autorisation d'accès aux informations sur les utilisateurs

Chez Google, les services et le personnel peuvent parfois avoir accès aux informations sur les utilisateurs. Nous interagissons avec les informations sur les utilisateurs de différentes manières :

  1. En tant qu'utilisateur final : un employé qui utilise un service s'authentifie directement auprès du service qui lui affiche ensuite ses données personnelles. Par exemple, un employé qui se connecte à son compte Gmail pourra consulter ses propres e-mails.
  2. Dans le cadre de sa mission : le personnel de Google n'a besoin le plus souvent que des données anonymisées de l'utilisateur pour remplir sa mission. Cependant, à de rares occasions et dans le cadre de sa mission, notre personnel a besoin d'accéder aux informations sur les utilisateurs (assistance ou débogage, par exemple). Notre objectif est d'assurer un maximum de transparence concernant l'accès aux informations sur les utilisateurs. Parmi les moyens que nous utilisons se trouve Access Transparency. Cette fonctionnalité permet aux clients Google Cloud de consulter les accès à leurs données éligibles via des journaux en temps réel.
  3. Dans le cadre d'un service, via un programme : pour accomplir une tâche, un service peut avoir besoin d'accéder à grande échelle aux informations sur les utilisateurs, via un programme. Par exemple, un pipeline de données interroge simultanément des milliers d'informations sur les utilisateurs afin de générer des statistiques d'utilisation cumulées. Lorsque ce besoin se présente, l'accès est accordé à un ensemble de données plutôt qu'aux informations sur un utilisateur donné. L'accès aux informations sur chaque utilisateur n'est pas journalisé.

Ce livre blanc se concentre sur le type de menace présenté dans le troisième scénario. Nous voulons nous assurer que les administrateurs qui gèrent les systèmes qui accèdent aux informations sur les utilisateurs ne puissent pas commettre d'abus.

Type de menace

Les contrôles évoqués dans le présent document ont été mis en place pour protéger les informations sur les utilisateurs en empêchant tout accès unilatéral. Nous voulons empêcher le personnel de Google, qui intervient de façon autonome, d'accéder directement ou indirectement aux informations sur les utilisateurs ou de les modifier sans autorisation ni justification. Nos contrôles préviennent ces agissements, que leur auteur ait une intention malveillante, que son compte ait été compromis ou qu'il ait reçu une autorisation involontaire.

L'infrastructure conteneurisée de Google

Notre infrastructure est conteneurisée grâce à un système de gestion de clusters appelé Borg. Nous exécutons des centaines de milliers de tâches à partir de nombreuses applications différentes, sur de multiples clusters, chacun d'entre eux comportant jusqu'à plusieurs dizaines de milliers de machines. Malgré cette envergure, notre environnement de production est assez homogène. Ainsi, les points de contact permettant l'accès aux informations sur les utilisateurs peuvent être plus facilement contrôlés et audités.

De plus, l'utilisation de conteneurs nous permet de bénéficier d'avantages considérables en termes de sécurité. Les conteneurs sont conçus pour être exploités de manière immuable, moyennant des redéploiements fréquents à partir de la restauration complète d'une image. Cette caractéristique nous permet d'examiner un changement de code dans son contexte et constitue un passage obligé unique pour toutes les modifications déployées dans notre infrastructure.

Pour comprendre comment nous avons développé une solution qui limite l'accès automatisé aux informations sur les utilisateurs par un service, il faut d'abord comprendre comment un service est mis en production chez Google.

Étape 1 : Examen du code

Notre code source est stocké dans un dépôt central monolithique qui permet à des milliers d'employés de le contrôler à partir d'un seul emplacement. L'utilisation d'un code base unique simplifie la gestion du code source, en particulier de nos dépendances vis-à-vis d'un code tiers. Un code base monolithique permet également de mettre en place un passage obligé unique pour les examens de code. Chez Google, l'examen du code implique l'inspection et l'approbation d'au moins un ingénieur autre que l'auteur. Notre processus d'examen du code obéit à la règle selon laquelle les modifications au code de tout système doivent au minimum être validées par les propriétaires de ce système. Une fois le code validé, il est compilé.

Lors de l'importation de modifications provenant d'un tiers ou d'un code source ouvert, nous en vérifions la pertinence (par exemple, la dernière version). Cependant, nous n'examinons pas toujours de la même façon les modifications apportées par des développeurs externes au code tiers ou au code Open Source que nous utilisons.

Étape 2 : Compilations vérifiables

Nous utilisons un système de compilation très semblable à Bazel, qui compile le code source et crée un binaire de déploiement. Notre système de compilation fonctionne dans un environnement isolé et verrouillé, séparé des employés qui exécutent les compilations. Pour chaque compilation, le système produit un fichier manifeste de compilation vérifiable, un certificat signé décrivant entièrement les sources qui ont été utilisées pour la compilation, les hachages cryptographiques de tous les binaires ou autres artefacts de compilation, et les paramètres de compilation complets. Ce fichier manifeste nous permet de tracer un binaire jusqu'au code source qui a été utilisé lors de sa création, et par extension, jusqu'au processus de création et de soumission du code source qu'il décrit. De plus, le fichier manifeste nous permet de vérifier que le binaire n'a pas été modifié. Toute modification du fichier invalide automatiquement sa signature.

Comme une compilation peut en théorie comporter du code arbitraire, notre système de compilation a été renforcé de manière à permettre la multilocation. En d'autres termes, notre système de compilation est conçu pour empêcher toute compilation d'affecter les autres. Le système empêche les compilations d'apporter des modifications qui pourraient compromettre l'intégrité des fichiers manifestes de compilation vérifiables ou du système lui-même. Une fois la compilation terminée, la modification est déployée à l'aide de Borg.

Étape 3 : Tâches de déploiement

Une fois compilé, un binaire peut être déployé sur notre infrastructure conteneurisée sous forme de tâche Borg. Ces tâches font appel à des paquets qui peuvent contenir des binaires ou des données, dont l'installation est gérée par Borg. Une configuration Borg précise les conditions requises par la tâche à déployer : les packages, les paramètres d'exécution, les arguments et les options. Borg planifie la tâche en tenant compte de ses impératifs, de sa priorité, de son quota et de toute autre condition indiquée dans sa configuration. Une fois déployée, la tâche Borg peut interagir avec d'autres tâches en production.

Étape 4 : Identité de la tâche

Une tâche Borg est exécutée par une identité. C'est cette identité qui est utilisée pour accéder aux entrepôts de données ou aux méthodes d'appel de procédure à distance (RPC) d'autres services. Une identité peut être soit un compte de rôle (comme un service), soit un compte utilisateur (comme le compte personnel d'un salarié). Plusieurs tâches peuvent être exécutées sous la même identité. Nous limitons la possibilité de déployer ou de modifier des tâches possédant une identité particulière aux personnes responsables de l'exécution du service, généralement nos ingénieurs en fiabilité des sites.

Lorsque Borg démarre une tâche, il la dote d'identifiants chiffrés. La tâche utilise ces identifiants pour prouver son identité lors de demandes à d'autres services (au moyen d'Application Layer Transport Security). Pour qu'un service puisse accéder à certaines données ou à un autre service, son identité doit posséder les autorisations nécessaires. Prenons l'exemple d'un service tel que l'API Cloud Data Loss Prevention (Cloud DLP) de Google Cloud. Pour que l'API DLP puisse accéder aux données à analyser, elle a besoin de deux choses. Tout d'abord, l'API DLP doit être configurée de façon à s'exécuter avec une identité distincte, dans ce cas un compte de rôle. Ensuite, les autorisations d'accès aux données analysées par l'API DLP doivent inclure ce compte de rôle. Sans une identité valide et les autorisations adéquates, le service serait incapable d'effectuer l'analyse.

Nos politiques exigent que tout compte de rôle ayant accès aux informations sur les utilisateurs (ou toute autre information sensible) soit étroitement contrôlé par l'autorisation binaire pour Borg et d'autres systèmes de sécurité. Les tâches d'assurance qualité et de développement qui n'ont pas accès à des données ou à des ressources sensibles sont autorisées à s'exécuter avec un nombre réduit de contrôles.

Synthèse : Cycle de vie d'une tâche

Voici un résumé des étapes à suivre pour exécuter une tâche sur notre infrastructure :

  1. Un développeur Google apporte une modification au code. Ce code est ensuite envoyé à un ou plusieurs autres ingénieurs Google pour examen. L'examen implique la vérification d'une autorisation valable et de la journalisation. Une fois validé, le code est enregistré.
  2. Déclenché par le développeur, le système de compilation crée et empaquette de façon vérifiable les binaires dans un environnement de type "bac à sable". Cette opération produit un paquet que le système de compilation signe ensuite à titre de validation.
  3. La tâche est déployée sur Borg par un ingénieur spécialement autorisé à gérer les tâches qui s'exécutent sous l'identité sécurisée correspondante.
  4. Lorsqu'une tâche Borg tente d'accéder à des ressources confidentielles comme les informations sur les utilisateurs, l'identité de la tâche est soumise à validation.

Maintenant que vous savez comment les tâches sont exécutées au sein de notre environnement de production, examinons le type de menace dont l'autorisation binaire pour Borg se charge, en empêchant un éventuel initié malveillant d'exécuter une tâche non autorisée. Pour ce faire, l'autorisation binaire pour Borg vérifie que tous les contrôles de sécurité nécessaires ont eu lieu avant le déploiement d'un binaire.

Cette section vous a donné un aperçu de notre infrastructure conteneurisée. Une connaissance de base de notre environnement de production est une condition préalable à la compréhension des contrôles que nous avons mis en place concernant l'accès automatisé aux informations par les utilisateurs. Ces contrôles sont détaillés dans la section suivante.

L'autorisation binaire pour Borg

Depuis plusieurs années, nous nous efforçons de protéger les informations sur les utilisateurs contre tout accès manuel. Ceci consiste entre autres à limiter l'accès aux informations et à la gestion des tâches au personnel de Google qui en a besoin pour remplir sa mission.

L'autorisation binaire pour Borg s'assure que tous les logiciels et configurations de production déployés chez Google sont correctement examinés et autorisés, en particulier si le code peut accéder aux informations sur les utilisateurs. Pour ce faire, l'autorisation binaire pour Borg assure un service de contrôle de déploiement pour empêcher le démarrage de tâches non autorisées, ainsi qu'un traçage d'audit du code et de la configuration utilisés dans les tâches où elle intervient.

Validation

L'autorisation binaire pour Borg vérifie que les binaires répondent à certaines exigences lors de leur déploiement. Par exemple, le propriétaire d'un service peut exiger que le binaire de son service soit compilé à partir d'un code qui a été examiné, vérifié, testé et autorisé. Ce type de contrôle est appelé contrôle de déploiement. L'autorisation binaire pour Borg peut également effectuer des contrôles une fois qu'un binaire a été déployé. On parle alors de contrôles post-déploiement. Pour en savoir plus sur ces contrôles post-déploiement, consultez notre section Modes d'exécution.

Une modification du code génère un nouveau binaire. Ce nouveau binaire doit être déployé pour que les modifications soient prises en compte. L'autorisation binaire pour Borg propose de nombreux types de contrôles de déploiement. Voici quelques exemples de contrôles :

  • Le binaire est-il compilé à partir d'un code enregistré ?

    Le code est-il déposé et vérifié dans le dépôt de code source de Google ? Pour que le code soit déposé, il doit en principe avoir été examiné par un deuxième ingénieur de Google.

  • Le binaire est-il compilé de manière vérifiable ?

    Ce binaire peut-il être tracé jusqu'à des sources vérifiables et a-t-il été compilé par un système de compilation approuvé ?

  • Le binaire est-il compilé à partir d'un code testé ?

    Le binaire répond-il aux exigences du test ?

  • Le binaire compilé à partir du code est-il destiné à être utilisé lors du déploiement ?

    Le code a-t-il été déposé dans la section appropriée du dépôt de code source qui correspond au projet ou à l'équipe concernés par cette tâche Borg spécifique ?

Bien que ces conditions soient spécifiques à notre environnement de production, des conditions similaires peuvent s'appliquer à vos environnements CI/CD (intégration continue/déploiement continu) en fonction de vos propres exigences en termes de sécurité, de conformité ou de fiabilité.

Règles spécifiques au service

Les tâches qui accèdent à des informations sensibles nécessitent généralement le dépôt du code, à quelques exceptions près pour des raisons fonctionnelles justifiées. Les données sensibles comprennent les informations sur les utilisateurs, sur l'emploi et les finances, ainsi que toute autre information propriétaire ou d'entreprise qu'il est nécessaire de connaître. Toutes les tâches de Google sont soumises à une stratégie. Une tâche Borg ne nécessitant pas d'accès aux informations sur les utilisateurs est elle aussi soumise à une stratégie, mais sans conditions spécifiques.

Lorsque les propriétaires d'un service intègrent l'autorisation binaire pour Borg, ils définissent une stratégie comportant les conditions de sécurité requises par leur service. Tous les comptes de rôle utilisés pour mettre en place ce service doivent spécifier une stratégie d'autorisation binaire pour Borg. Pour chaque compte de rôle, la politique d'autorisation binaire pour Borg définit les tâches qui doivent être lancées, ainsi que les conditions en termes de code et de configuration de la tâche. La définition ou la modification d'une stratégie constituent une modification du code qui doit être examinée.

Les conditions applicables à une stratégie d'autorisation binaire pour Borg sont les suivantes :

  • Le code est compilé de façon vérifiable : le code qui est compilé de façon vérifiable est susceptible d'être audité. Cela ne signifie pas nécessairement que le code a été soumis à examen. Dans certains cas, le code n'est même pas déposé. Le code utilisé lors d'une compilation vérifiable est susceptible d'être audité pendant au moins 18 mois, même s'il n'est pas déposé.

  • Le code est déposé : le code est compilé à partir d'un emplacement spécifique et déterminé sur notre dépôt de code source. Ceci implique généralement un examen du code.

  • Les configurations sont déposées : toutes les configurations déposées lors du déploiement subissent le même processus d'examen et de dépôt que le code ordinaire. Ainsi, la valeur des options de la ligne de commande, les arguments et les paramètres ne peuvent être modifiés sans examen.

Les systèmes et les composants qui appliquent l'autorisation binaire pour Borg doivent être étroitement contrôlés. Pour ce faire, les conditions les plus strictes possibles sont mises en œuvre, ainsi que des contrôles manuels supplémentaires.

Les modes d'exécution

L'autorisation binaire pour Borg effectue différentes actions en fonction de la stratégie spécifiée par la tâche Borg. Ces mesures, que l'on appelle "modes d'exécution", sont au nombre de trois : l'application forcée, l'audit et la validation continue. Lors de la définition d'une stratégie, le propriétaire du service doit choisir entre application forcée ou audit au moment du déploiement. Le mode validation continue est activé par défaut. Les sections suivantes détaillent chaque mode.

Le mode application forcée lors du déploiement

Lorsqu'une nouvelle tâche est déposée, Borgmaster 2 consulte l'autorisation binaire pour Borg pour s'assurer que la tâche répond aux conditions nécessaires, telles que définies par la stratégie d'autorisation binaire pour Borg. Cette vérification agit comme un contrôleur d'admission. Si les conditions sont remplies, Borgmaster exécute la tâche. Sinon, Borgmaster rejette la demande même si l'utilisateur qui la soumet est autorisé à le faire.

En mode application forcée, l'autorisation binaire pour Borg bloque le déploiement d'une tâche Borg si elle ne satisfait pas aux conditions définies par la stratégie d'autorisation binaire pour Borg de cette tâche. Les services inconnus de l'autorisation binaire pour Borg démarrent généralement en mode audit (décrit dans la section suivante), puis passent en mode application forcée.

Procédures d'urgence

En cas d'incident ou de panne, la priorité est de rétablir le service affecté le plus rapidement possible. Dans une situation d'urgence, il peut être nécessaire d'exécuter du code qui n'a pas été examiné ou vérifié. Ainsi, il est possible de contourner le mode application forcée à l'aide d'une option d'urgence. Les procédures d'urgence servent également de solution de secours en cas d'un dysfonctionnement de l'autorisation binaire pour Borg susceptible de bloquer un déploiement. Un développeur qui déploie une tâche en suivant la procédure d'urgence doit motiver sa demande.

Dans les secondes qui suivent l'utilisation de la procédure d'urgence, l'autorisation binaire pour Borg journalise les détails de la tâche Borg correspondante. Le journal contient le code qui a été utilisé et le motif invoqué par l'utilisateur. Quelques secondes plus tard, une trace d'audit est envoyée à l'équipe de sécurité centralisée. Au bout de quelques heures, la trace d'audit est envoyée à l'équipe qui possède le compte du rôle. Les procédures d'urgence ne doivent être utilisées qu'en dernier recours.

Le mode audit lors du déploiement

En mode audit, l'autorisation binaire pour Borg signale dans le journal qu'une tâche Borg ne répond pas aux conditions de la stratégie, mais ne bloque pas son déploiement. Cette violation de la stratégie déclenche une alerte transmise à l'équipe qui possède le compte du rôle.

Chez Google, certains services, comme ceux qui accèdent aux informations sur les utilisateurs, doivent utiliser le mode application forcée. Les propriétaires de services sont priés d'utiliser le mode application forcée et de n'utiliser le mode audit que pour l'intégration d'un nouveau service. Pour utiliser le mode audit, les propriétaires de services doivent motiver leur demande de dérogation. Par exemple, un service devrait appliquer le mode audit si sa fiabilité SLO (objectif de niveau de service) est sensiblement plus élevée que ce que l'autorisation binaire pour Borg prévoit.

Bien que le mode audit soit utile pour affiner une stratégie initiale, il ne constitue pas en pratique un état stable pour la plupart des services. Lorsque vous utilisez le mode audit, le propriétaire du service n'est pas informé des violations de stratégie avant plusieurs heures. Ceci peut engendrer un flux de notifications intempestives qui masquent les véritables problèmes de sécurité derrière des erreurs ou des configurations incorrectes de stratégies mises en place par le propriétaire du service. En mode application forcée, le propriétaire du service reçoit une alerte immédiate s'il tente de lancer une tâche qui ne répond pas à la stratégie. Le flux de notifications est ainsi beaucoup plus clair. De plus, le mode application forcée de l'autorisation binaire pour Borg permet de détecter les erreurs involontaires, comme le lancement accidentel d'une tâche dans un rôle différent de celui dans lequel il devrait être exécuté.

La validation continue

Quel que soit son mode d'exécution au moment du déploiement, une tâche est validée en continu pendant toute sa durée de vie. Un processus d'autorisation binaire pour Borg s'exécute au moins une fois par jour pour vérifier que tous les travaux qui ont été lancés (ou sont toujours en cours d'exécution ) sont conformes aux mises à jour de leurs stratégies. Ainsi, le mode validation continue permet de contrôler en permanence les tâches exécutées selon des stratégies obsolètes ou avec une identité déployée au moyen de procédures d'urgence. Si une tâche ne respecte pas la stratégie mise à jour, l'autorisation binaire pour Borg le signalera aux propriétaires du service pour leur permettre de limiter les risques.

Packages globalement autorisés

Certains packages sont couramment utilisés par plusieurs services de Google. Au lieu de forcer chaque service à maintenir sa propre version, ces packages sont autorisés de manière centralisée : on parle de packages gérés globalement. Lors de la création d'une stratégie d'autorisation binaire pour Borg, un propriétaire de service peut définir un package global autorisé pour une tâche donnée. Un mécanisme global par défaut existe aussi pour les packages couramment utilisés. Il n'est donc pas nécessaire de les lister individuellement dans le cadre de la stratégie de chaque service. Ceci permet à Google de maintenir un contrôle explicite sur les composants système communs utilisés par l'entreprise, et de s'assurer que ceux-ci sont correctement examinés et mis à jour sans impliquer les différentes équipes. Bien qu'un propriétaire de service puisse autoriser ces packages explicitement dans le cadre de la stratégie d'autorisation binaire pour Borg de son service, la démarche recommandée et approuvée s'en trouve facilitée pour les propriétaires.

Cas extrêmes

Google met en œuvre des contrôles de sécurité rigoureux du code déployé en production, y compris des examens de code et des compilations vérifiables. L'autorisation binaire pour Borg agit comme un point de contrôle et d'application forcée supplémentaire pour garantir que ces contrôles de sécurité sont correctement mis en œuvre.

L'autorisation binaire pour Borg ne convient toutefois pas à tous les cas. L'autorisation binaire pour Borg ne prend pas en charge les cas limites suivants : le code compilé à l'aide de systèmes de compilation non standards, le code déployé dans des environnements autres que Borg, et le code destiné à l'analyse de données et au machine learning, qui ne se prête pas à un examen humain avant le choix des paramètres de production définitifs. Dans ces cas, diverses autres mesures de sécurité sont prévues, y compris d'autres systèmes de traçage de l'origine du code. Néanmoins, ce code demeure soumis aux contrôles de sécurité généraux de Google.

Mise en œuvre de l'autorisation binaire pour Borg

Pour mettre en œuvre l'autorisation binaire pour Borg, l'équipe responsable a développé plusieurs nouvelles fonctionnalités, dont les procédures d'urgence et le mode audit. Ces outils ont grandement facilité l'essai de l'autorisation binaire pour Borg par les propriétaires de services. Si vous envisagez de déployer un système analogue à l'autorisation binaire pour Borg dans votre entreprise, vous devrez peut-être fournir une charge de travail supplémentaire pour faciliter cette transition. Cette section décrit le travail d'organisation et de gestion du changement que nous avons effectué dans le cadre de notre plan de mise en œuvre.

Avantages

L'autorisation binaire pour Borg présente trois avantages qui ont contribué à l'élaboration de l'analyse de rentabilisation préalable à son développement et à son adoption par Google : la réduction des risques internes, une identité de code solide et une conformité simplifiée.

Réduction des risques internes

L'autorisation binaire pour Borg a été principalement développée pour empêcher toute personne d'obtenir un accès automatisé non autorisé aux informations sur les utilisateurs. L'autorisation binaire pour Borg empêche un ingénieur seul, ou un pirate informatique qui obtient les identifiants d'un ingénieur, d'accéder frauduleusement et de façon inaperçue aux données sensibles.

Fiabilité de l'identité du code

Comme décrit dans la section Infrastructure conteneurisée, les tâches Borg s'exécutent sous une identité, généralement un compte de rôle. Cette identité est utilisée par d'autres services pour valider l'autorisation appropriée avant d'accorder l'accès aux données. Il est cependant impossible pour les autres services d'imposer l'utilisation de ces données. Ils doivent donc s'assurer que l'identité de la tâche ne fait pas un usage abusif des données qu'elle a reçues. L'autorisation binaire pour Borg lie l'identité de la tâche à un code spécifique et garantit que seul ce code peut être utilisé pour obtenir les privilèges de l'identité de la tâche. Ceci permet la transition d'une identité de tâche, basée sur la confiance en une identité et en tout utilisateur humain provisoirement autorisé, vers une identité de code, basée sur un morceau de code donné dont la sémantique spécifique été examinée et peut être modifiée sans processus d'approbation.

Simplification de la conformité

L'autorisation binaire pour Borg a simplifié les tâches de conformité qui étaient auparavant manuelles. Certains processus de Google nécessitent des contrôles plus stricts de la façon dont ils traitent les informations. Par exemple, nos systèmes de rapports financiers doivent être conformes à la loi Sarbanes-Oxley (SOX). Le système qui a précédé l'autorisation binaire pour Borg permettait d'effectuer manuellement des vérifications pour assurer la conformité. Depuis la mise en place de l'autorisation binaire pour Borg, la plupart de ces contrôles ont été automatisés en fonction des stratégies adoptées par les services. L'automatisation de ces contrôles a permis à l'équipe de conformité d'accroître à la fois l'étendue des services couverts et l'adoption de contrôles adaptés à ces services.

Intégration d'un service

L'équipe responsable de l'autorisation binaire pour Borg s'est assurée que le processus d'intégration était simple et direct. Au départ, les propriétaires de services de Google étaient préoccupés par l'adoption de l'autorisation binaire pour Borg pour deux raisons :

  • Si l'autorisation binaire pour Borg n'était pas suffisamment fiable, sa mise en œuvre pouvait bloquer les modifications en situation critique.
  • Elle pouvait ralentir le développement d'un service en raison de fréquents contrôles de code et de traitements itératifs.

Pour répondre à ces préoccupations, l'équipe responsable de l'autorisation binaire pour Borg a mis au point le mode audit. Grâce à ce mode, elle a pu prouver à certains des premiers utilisateurs clés que l'autorisation binaire pour Borg fonctionnait. Pour renforcer sa fiabilité, l'équipe a mis au point un SLO de disponibilité et a introduit des procédures d'urgence en mode application forcée.

Lors de l'intégration de l'autorisation binaire pour Borg à un service existant, le propriétaire du service active généralement le mode audit. Ceci permet d'identifier et de résoudre les problèmes avant de passer en mode application forcée. Le mode application forcée est la stratégie par défaut de toute tâche impliquant l'utilisation de l'autorisation binaire pour Borg en production. Pour déployer une tâche, le propriétaire du service doit proposer une stratégie qui exige que le code soit au minimum déposé et compilé de manière vérifiable. Un propriétaire de service peut déployer une tâche sans respecter cette condition minimale, mais il doit obtenir une dérogation. Si le service a besoin d'accéder à des données ou à des services plus sensibles, le propriétaire peut adopter des conditions plus strictes. La définition d'une stratégie initiale est parfois délicate, c'est pourquoi l'équipe responsable de l'autorisation binaire pour Borg a créé un outil automatisé pour aider les propriétaires de services à élaborer leurs stratégies. Ces outils vérifient quelles parties du dépôt source sont utilisées par une tâche existante et suggèrent une stratégie appropriée.

Lors de l'intégration de l'autorisation binaire pour Borg à un nouveau service, le propriétaire du service active le mode application forcée dès le début. Le propriétaire du service élabore une première stratégie et la révise régulièrement pour y ajouter des conditions supplémentaires. Les stratégies sont elles-mêmes gérées comme des modifications de code et nécessitent donc l'intervention d'un second ingénieur Google pour examiner les mises à jour.

Impact

L'adoption de l'autorisation binaire pour Borg et d'un modèle de déploiement conteneurisé offre de nombreux avantages à Google en termes de sécurité et d'assistance :

  • L'autorisation binaire pour Borg permet de réduire globalement les risques internes : en exigeant que le code réponde à certaines normes et pratiques de gestion du changement avant d'accéder aux informations sur les utilisateurs, elle réduit le risque qu'un Googleur agissant seul (ou dont le compte a été compromis) accède aux informations sur les utilisateurs de manière automatisée.
  • L'autorisation binaire pour Borg garantit l'uniformité des systèmes de production : en utilisant des systèmes conteneurisés et en validant leurs conditions avant déploiement, nos systèmes sont plus faciles à déboguer, plus fiables et disposent d'une gestion du changement plus claire. Ces conditions constituent un langage commun aux exigences des systèmes de production.
  • L'autorisation binaire pour Borg est un langage commun de protection des données qui assure la conformité de nos systèmes. Les informations relatives à cette conformité sont publiées en interne et peuvent être consultées par d'autres équipes. Cette publication des informations permet aux équipes de communiquer entre elles sur la protection des données en utilisant des termes communs. Ce langage commun réduit le va-et-vient nécessaire entre les équipes lors du traitement des informations.
  • L'autorisation binaire pour Borg permet un suivi automatisé des exigences de conformité : certains processus, comme ceux qui concernent les rapports financiers, doivent répondre à certaines exigences de gestion du changement à des fins de conformité. Grâce à elle, ces contrôles sont automatisés, permettant de gagner du temps et d'augmenter l'étendue de la couverture.

C'est l'une des nombreuses technologies utilisées par Google pour réduire les risques internes.

Adoption de mesures similaires dans votre entreprise

Nous avons tiré de nombreux enseignements majeurs lors de la mise en œuvre de l'autorisation binaire pour Borg. Un changement d'une telle ampleur peut paraître intimidant. Dans cette section, nous partageons les enseignements que nous avons tirés en cours de route en espérant que vous puissiez appliquer les principes de l'autorisation binaire pour Borg à votre entreprise.

Mettez en place un pipeline CI/CD conteneurisé plus homogène.

L'adoption de l'autorisation binaire pour Borg par Google a été rendue possible par la cohérence et l'intégration des outils que nous utilisons pour développer notre code. Ces tâches comprenaient l'examen du code, les compilations vérifiables, les déploiements conteneurisés et l'identité basée sur les services pour le contrôle d'accès. La compilation vérifiable permet de vérifier la façon dont les binaires sont compilés. Les conteneurs vous permettent de séparer les binaires des données et sont une étape nécessaire pour garantir qu'ils répondent aux conditions d'utilisation. Cette approche a simplifié l'adoption de l'autorisation binaire pour Borg et a renforcé les garanties qu'une telle solution peut offrir.

L'introduction de microservices a permis d'adopter une authentification basée sur le service (compte de service) plutôt que sur l'hôte (adresse IP). Le passage à une identité basée sur les services permet de modifier la gestion de l'authentification et de l'autorisation entre les services. Par exemple, si vous utilisez un jeton d'identité imbriqué dans une image de conteneur pour attester une identité, les garanties fournies par la provenance du code ne seront pas aussi fortes. Si vous ne pouvez pas adopter directement une identité de service, vous pouvez tenter de protéger plus efficacement les jetons d'identité en guise de mesure provisoire.

Définissez vos objectifs et vos stratégies selon vos besoins.

Élaborez votre processus de publication axé sur les stratégies, élément par élément. Vous devrez peut-être mettre en œuvre certains changements plus tôt que d'autres dans votre pipeline CI/CD. Ainsi, vous devrez peut-être commencer à effectuer des examens formels de code avant de pouvoir les appliquer lors du déploiement.

La conformité est la principale raison d'être d'un processus de publication axé sur des stratégies. Si vous parvenez à définir certaines de vos conditions de conformité au sein d'une stratégie, vous pourrez automatiser vos tests et vous assurer qu'ils sont toujours opérationnels. Commencez par une série de conditions de base et ajoutez des conditions plus poussées au fur et à mesure.

Appliquez les stratégies dès le début du développement.

Il est difficile de définir des stratégies exhaustives pour un logiciel sans savoir au préalable où il s'exécutera et à quelles informations il aura accès. C'est pourquoi l'application de la politique d'autorisation binaire pour Borg a lieu lorsque le code est déployé et qu'il accède aux informations, et non lorsqu'il est compilé. Une stratégie d'autorisation binaire pour Borg est définie en termes d'identité d'exécution, de sorte que le même code peut s'exécuter dans des environnements différents et être soumis à des stratégies différentes.

Nous l'utilisons conjointement à d'autres mécanismes d'accès pour limiter l'accès aux informations sur les utilisateurs. De cette manière, les propriétaires de services peuvent s'assurer que les informations ne sont accessibles qu'à une tâche répondant aux conditions requises par l'autorisation binaire pour Borg, en assimilant le code à une identité.

Déterminez comment impliquer les propriétaires de services existants.

Identifiez quelques propriétaires de services qui verront des avantages immédiats à l'application forcée et sont prêts à faire part de leurs commentaires. Pour ce faire, vous pouvez demander aux propriétaires de se porter volontaires avant de rendre toute modification obligatoire.

Privilégiez le mode application forcée au mode audit, ou limitez strictement la période de sursis du mode audit. Le mode audit permet aux propriétaires de s'intégrer rapidement et de mieux comprendre les risques internes. Le mode audit présente l'inconvénient de nécessiter un certain temps avant de constater une réduction sensible des risques internes. Ce délai peut nuire à la crédibilité du processus et dissuader d'autres personnes d'adopter des mesures d'application. Lorsque l'équipe responsable de l'autorisation binaire pour Borg a proposé des procédures d'urgence de mise en application, les propriétaires de services étaient plus disposés à adopter ces mesures s'ils disposaient d'une porte de sortie.

Intégrez des agents de changement aux équipes.

Lorsque nous avons établi un mandat à l'échelle de Google pour le déploiement de l'autorisation binaire pour Borg, notre taux de réussite a surtout été influencé par le fait que nous avons trouvé des propriétaires pour piloter le changement dans chaque groupe de produits. Une fois leur aide obtenue, nous avons mis sur pied une équipe officielle de gestion du changement pour suivre les modifications en cours. Nous avons ensuite désigné pour chaque équipe produit des responsables chargés de mettre en œuvre ces changements.

Définir la manière de gérer le code tiers

Bon nombre des contrôles de CI/CD que nous décrivons dans ce document sont placés là où votre code est développé, examiné et maintenu par une même entreprise. Si vous êtes dans cette situation, réfléchissez à la façon dont vous intégrerez du code tiers en fonction des conditions de votre stratégie. Vous pouvez par exemple, dans un premier temps, en dispenser ce code, tout en évoluant idéalement vers la maintenance d'un dépôt de l'ensemble du code tiers utilisé, ainsi qu'en contrôlant régulièrement ce code, en fonction de vos conditions de sécurité.

Conclusion

La mise en place d'un contrôle d'application lors du déploiement dans le cadre d'une infrastructure conteneurisée et du processus CI/CD de Google nous a permis de vérifier que le code et la configuration que nous déployons respectent certaines normes minimales de sécurité. Il s'agit d'une mesure de contrôle critique destinée à limiter la capacité d'un individu potentiellement malveillant à exécuter une tâche non autorisée et capable d'accéder aux informations sur les utilisateurs. L'adoption de l'autorisation binaire pour Borg a permis à Google de réduire les risques internes, de prévenir d'éventuelles attaques et de garantir l'uniformité de ses systèmes de production.

Autres références

Pour en savoir plus sur la sécurité globale et l'infrastructure conteneurisée de Google, consultez ces ressources :

Notes

1 La provenance désigne les composants, les modifications apportées aux composants et leur origine. Consultez la page https://csrc.nist.gov/glossary/term/Provenance.

2 Borgmaster est le contrôleur centralisé de Borg. Il gère la planification des tâches et transmet le statut des tâches en cours d'exécution.