Ce contenu a été mis à jour pour la dernière fois en septembre 2023, 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.
Ce document explique comment nous utilisons les révisions de code, l'infrastructure de sécurité et un contrôle d'application appelé autorisation binaire pour Borg (BAB), afin de protéger la chaîne d'approvisionnement logicielle de Google contre les risques internes. L'autorisation binaire pour Borg réduit les risques internes, car elle garantit que les logiciels de production sont examinés et approuvés avant d'être déployés, en particulier lorsque notre code peut accéder à des données sensibles. Depuis la publication initiale de ce document, nous avons inclus les principaux concepts de BAB dans une spécification ouverte appelée Niveaux de la chaîne d'approvisionnement pour les artefacts logiciels (SLSA).
Ce document fait partie d'une série de documents techniques décrivant certains projets développés par l'équipe de sécurité de Google pour améliorer la sécurité, y compris BeyondCorp et BeyondProd. Pour en savoir plus sur la sécurité de notre infrastructure, consultez la Présentation de la sécurité sur l'infrastructure de Google.
Présentation
Les risques internes représentent une menace pour la sécurité des informations sur les utilisateurs, qui peuvent comprendre des données concernant leurs emplois et leurs finances, ou d'autres données propriétaires ou commerciales. Les risques internes sont la possibilité pour un employé d'utiliser ses connaissances ou ses accès à l'organisation pour réaliser des actes malveillants, ou la possibilité pour un pirate informatique externe d'utiliser les identifiants compromis d'un employé pour faire de même.
Afin de réduire les risques internes au sein de notre chaîne d'approvisionnement logicielle, nous utilisons l'autorisation binaire pour Borg. L'autorisation binaire pour Borg est une vérification interne d'exécution qui se produit lors du déploiement du logiciel. L'autorisation binaire pour Borg s'assure que les déploiements de code et de configuration respectent certaines normes minimales et assurent l'uniformité dans nos systèmes de production.
Nous aidons à protéger les données utilisateur dans nos systèmes de production en empêchant tout accès unilatéral par nos employés. L'autorisation binaire pour Borg permet de s'assurer que les employés, lorsqu'ils agissent seuls, ne peuvent pas accéder directement ou indirectement aux informations sur les utilisateurs ou les modifier sans autorisation ni justification appropriée. L'autorisation binaire pour Borg et les contrôles associés nous permettent d'appliquer le principe du moindre privilège, ce qui améliore notre stratégie de sécurité indépendamment de l'acteur à l'origine de la menace. En d'autres termes, l'autorisation binaire pour Borg empêche tout accès unilatéral, que l'acteur ait une intention malveillante, que son compte ait été compromis, ou qu'il ait reçu une autorisation involontairement.
Avantages de l'autorisation binaire pour Borg
L'adoption de l'autorisation binaire pour Borg et d'un modèle de déploiement conteneurisé offre de nombreux avantages en termes de sécurité pour l'infrastructure de Google. Les avantages sont les suivants :
- L'autorisation binaire pour Borg permet de réduire les risques internes : l'autorisation binaire pour Borg nécessite que le code réponde à certaines normes et pratiques de gestion du changement pour pouvoir accéder aux informations sur les utilisateurs. Cette exigence réduit le risque qu'un employé agissant seul (ou dont la sécurité du compte est compromise) accède à des informations sur les utilisateurs par programmation.
- L'autorisation binaire pour Borg assure 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 deviennent plus faciles à déboguer, plus fiables et disposent de processus de gestion du changement bien définis. 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 : BAB permet d'assurer la conformité des systèmes Google. Les informations relatives à cette conformité sont publiées en interne et sont disponibles pour les autres équipes. Cette publication des informations permet aux équipes de communiquer entre elles sur la protection des accès aux 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é : l'autorisation binaire pour Borg simplifie 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 nous traitons 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é. Avec l'introduction 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.
L'autorisation binaire pour Borg fait partie d'un framework plus vaste, BeyondProd, que nous utilisons pour limiter les risques internes.
Notre processus de développement et de production
Le processus de développement et de production de Google comprend quatre étapes obligatoires : l'examen du code, les compilations vérifiables, le déploiement conteneurisé et l'identité basée sur les services. Les sections suivantes décrivent ces étapes plus en détail.
Étape 1 : Examen du code
Une grande partie de notre code source est stockée dans un dépôt central monolithique, , qui permet à des milliers d'employés d'examiner le code à partir d'un seul emplacement. Le codebase Google simplifie la gestion du code source, en particulier la gestion de nos dépendances vis-à-vis d'un code tiers. Un codebase monolithique permet également de mettre en place un passage obligé unique pour les révisions de code.
Nos révisions du code incluent l'inspection et l'approbation d'au moins un ingénieur autre que l'auteur. Notre processus de révision du code exige au minimum que les propriétaires d'un système approuvent les modifications apportées au code de ce système. Une fois le code validé, il est compilé.
Lors de l'importation de modifications provenant de code tiers ou de code Open Source, 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
Notre système de compilation est semblable à Bazel, qui crée et compile le code source pour créer un binaire de déploiement. Notre système de compilation s'exécute dans un environnement isolé et verrouillé , séparé des employés qui effectuent les compilations. Pour chaque compilation, le système crée une provenance générée par des compilations vérifiables . Cette provenance est un certificat signé qui décrit les sources et les dépendances incluses dans la compilation, les hachages cryptographiques de tous les binaires ou autres artefacts de compilation, et les paramètres de compilation complets. Cette provenance permet les opérations suivantes :
- La possibilité de tracer un binaire jusqu'au code source utilisé lors de sa création. Par extension, la provenance peut également tracer le processus autour de la création et de l'envoi du code source qu'il décrit.
- La possibilité de vérifier que le binaire n'a pas été modifié, car toute modification du fichier invaliderait automatiquement sa signature.
Comme une compilation peut comporter du code arbitraire, notre système de compilation a été renforcé pour l'architecture mutualisée. 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é de la provenance de la compilation 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 : Déploiement conteneurisé
Une fois que le système de compilation a créé le binaire, il est empaqueté dans une image de conteneur et déployé en tant que tâche Borg sur notre système d'orchestration de clusters, Borg. Nous exécutons des centaines de milliers de jobs à 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.
Les conteneurs offrent des avantages notables en termes de sécurité. Les conteneurs sont conçus pour être immuables, moyennant des redéploiements fréquents à partir de la restauration complète d'une image. La conteneurisation 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.
La configuration d'une tâche Borg précise les conditions requises par la tâche à déployer : les images de conteneurs, 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 le job déployé, le job Borg peut interagir avec d'autres jobs en production.
Étape 4 : Identité basée sur les services
Une tâche Borg s'exécute en tant qu'identité de service. Cette identité permet d'accéder aux datastores ou aux méthodes d'appel de procédure à distance (RPC) ou d'autres services. Plusieurs jobs peuvent être exécutés sous la même identité. Seuls les employés chargés d'exécuter le service (généralement, les ingénieurs en fiabilité des sites ou SRE) peuvent déployer ou modifier des jobs avec une identité particulière.
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 de l'Application Layer Transport Security (ALTS). Pour qu'un service puisse accéder à certaines données ou à un autre service, son identité doit posséder les autorisations nécessaires.
Nos stratégies nécessitent la protection BAB pour les identités de service ayant accès aux informations sur les utilisateurs et à toute autre information sensible. Les jobs d'assurance qualité et de développement qui n'ont pas accès aux données sensibles sont autorisées à s'exécuter avec un nombre réduit de contrôles.
Fonctionnement de l'autorisation binaire pour Borg
L'autorisation binaire pour Borg s'intègre à Borg pour garantir que seuls les jobs autorisés peuvent s'exécuter avec l'identité de chaque service. L'autorisation binaire pour Borg crée également une piste d'audit du code et de la configuration utilisés dans les jobs où BAB intervient pour permettre une surveillance et la gestion des incidents.
L'autorisation binaire pour Borg est conçue pour garantir que tous les logiciels et configurations de production sont correctement examinés, validés, compilés de façon vérifiable et autorisés, en particulier lorsque le code peut accéder aux informations sur les utilisateurs.
Règles spécifiques au service
Lorsque les propriétaires d'un service intègrent leur service à l'autorisation binaire pour Borg, , ils créent une règle qui définit les exigences de sécurité pour leur service. Cette règle est appelée règle spécifique au service. La définition ou la modification d'une règle constituent une modification du code qui doit être examinée.
La règle spécifique au service définit le code et la configuration autorisés à s'exécuter en tant qu'identité du service, ainsi que les propriétés requises de ce code et cette configuration. Tous les jobs exécutés en tant qu'identité du service doivent respecter la règle spécifique au service.
Tous les services Google sont soumis à une règle spécifique. Les services qui accèdent aux données sensibles doivent disposer de règles suffisamment fortes, tandis que les services sans accès aux données sensibles peuvent disposer d'une règle permissive de type "autoriser tout".
Les règles spécifiques au service peuvent appliquer les exigences suivantes :
- Le code doit être auditable : Nous pouvons tracer l'image du conteneur jusqu'à ses sources lisibles via la provenance générée par les compilations vérifiables. Une règle de conservation conserve les sources lisibles du code pendant au moins 18 mois, même si le code n'est pas envoyé.
- Le code doit être envoyé : Le code est compilé à partir d'un emplacement spécifié et défini dans notre dépôt source. L'envoi implique généralement un examen du code.
- Les configurations doivent être envoyées : Toutes les configurations fournies lors du déploiement sont soumises au même processus d'examen et d'envoi que le code ordinaire. Par conséquent, les valeurs, arguments et paramètres des options de ligne de commande ne peuvent pas être modifiés sans examen.
Les systèmes et les composants qui appliquent l'autorisation binaire pour Borg sont étroitement contrôlés à l'aide des exigences automatiques les plus strictes et de contrôles manuels supplémentaires.
Les modes d'exécution
L'autorisation binaire pour Borg utilise deux modes d'exécution pour garantir que tous les jobs respectent la règle spécifique au service :
- Le mode application forcée lors du déploiement, qui empêche le déploiement de jobs non conformes.
- Le mode validation continue, qui surveille et vous alerte si des jobs non conformes ont été déployés.
En outre, en cas d'urgence, les procédures d'urgence peuvent contourner l'application forcée lors du déploiement.
Le mode application forcée lors du déploiement
Borg Prime est le contrôleur centralisé de Borg, qui sert d'autorité de certification pour ALTS. Lorsqu'une nouvelle tâche est envoyée, Borg Prime consulte l'autorisation binaire pour Borg afin de s'assurer que la tâche répond aux conditions des règles spécifiques au service avant que Borg Prime lui accorde le certificat ALTS. Cette vérification agit comme un contrôleur d'admission : Borg ne démarre la tâche que si elle répond aux règles spécifiques au service. Cette vérification se produit même lorsque l'employé ou le service qui effectue la requête de déploiement est autorisé.
Dans de rares cas, les services peuvent désactiver l'application forcée lors du déploiement à condition de fournir une justification adéquate.
Le mode validation continue
Une fois une tâche déployée, elle est validée en continu pendant toute sa durée de vie, quel que soit le mode d'application forcée lors du déploiement. Un processus d'autorisation binaire pour Borg s'exécute au moins une fois par jour pour vérifier que les travaux qui ont été lancés (ou sont toujours en cours d'exécution ) sont conformes aux mises à jour de leurs stratégies. Par exemple, le mode validation continue recherche en permanence des jobs exécutés selon des stratégies obsolètes ou qui ont été déployés à l'aide de procédures d'urgence. Si une tâche ne respecte pas la dernière stratégie, l'autorisation binaire pour Borg le signale aux propriétaires du service pour leur permettre de limiter les risques.
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 compilé de façon vérifiable. 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. Lorsqu'un développeur déploie une tâche en suivant la procédure d'urgence, il 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 inclut le code utilisé et la justification fournie par l'utilisateur. Quelques secondes plus tard, une trace d'audit est envoyée à l'équipe de sécurité centralisée de Google. En quelques heures, la piste d'audit est envoyée à l'équipe propriétaire de l'identité de la tâche. Les procédures d'urgence ne doivent être utilisées qu'en dernier recours.
Étendre l'autorisation binaire pour Borg à d'autres environnements
Au départ, l'autorisation binaire pour Borg ne prenait en charge que la protection des jobs Borg et exigeait que le logiciel soit développé à l'aide du système traditionnel de contrôle des sources, de compilation et de packaging de Google. L'autorisation binaire pour Borg prend désormais en charge la protection d'autres environnements de livraison et de déploiement de logiciels, ainsi que d'autres systèmes de contrôle des sources, de compilation et de packaging. Les détails de mise en œuvre diffèrent selon les environnements, mais les avantages de l'autorisation binaire pour Borg restent les mêmes.
Certains cas ne se prêtent pas bien à un examen manuel du code avant le déploiement, notamment pour un développement itératif du code de machine learning et l'analyse de données à haute fréquence. Dans ces cas de figure, certaines commandes permettent de compenser l'examen manuel.
Adoption de mesures similaires dans votre entreprise
Cette section décrit les bonnes pratiques apprises lors de la mise en œuvre de l'autorisation binaire pour Borg de façon à pouvoir adopter des contrôles similaires dans votre organisation.
Créer un pipeline CI/CD homogène et conteneurisé
L'adoption de l'autorisation binaire pour Borg a été simplifiée car la plupart des équipes utilisaient un système de contrôle de source, un processus de révision de code, un système de compilation et un système de déploiement. Les révisions de code faisaient déjà partie de notre culture. Nous avons donc pu apporter des modifications sans trop de changements significatifs pour les utilisateurs. Pour adopter l'autorisation binaire pour Borg, nous nous sommes concentrés sur les révisions de code, les compilations vérifiables, les déploiements conteneurisés et les identités basées sur les services pour le contrôle d'accès. Cette approche a simplifié l'adoption de l'autorisation binaire pour Borg et a renforcé les garanties qu'une telle solution peut offrir.
L'utilisation généralisée de microservices et d'identités basées sur les services (comme les comptes de service), plutôt que sur les identités basées sur l'hôte (comme les adresses IP), nous permet de créer un contrôle ultraprécis sur le logiciel autorisé à exécuter chacun de ces services.
Si votre organisation ne peut pas adopter directement une identité de service, vous pouvez tenter de protéger les jetons d'identité en utilisant d'autres mesures en guise de mesure provisoire.
Définir 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 révisions formelles du code avant de pouvoir les appliquer lors du déploiement.
La conformité est la principale raison d'être d'un processus de déploiement axé sur des stratégies. Si vous parvenez à encoder 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.
Appliquer 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 des règles spécifiques au service a lieu lorsque le code est déployé et qu'il accède aux informations, et non lorsqu'il est compilé. Une stratégie 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. 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.
Intégrer 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. Nous avons identifié quelques propriétaires de services qui ont constaté des avantages immédiats en matière d'application et étaient prêts à faire part de leurs commentaires. Nous avons demandé à ces propriétaires de se porter volontaires avant de rendre toute modification obligatoire. 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
Si vous devez gérer du code tiers, réfléchissez à la manière dont vous allez introduire vos règles dans votre codebase tiers. 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é. Nous vous recommandons de contrôler régulièrement ce code en fonction de vos exigences de sécurité.
Pour en savoir plus sur la gestion du code tiers, consultez la page Parvenir ensemble à développer une communauté Open Source plus sûre.
Étapes suivantes
- Découvrez BeyondProd, que nous utilisons pour créer un périmètre sécurisé autour de nos microservices.
- Pour adopter un pipeline CI/CD sécurisé, consultez la section Niveaux de la chaîne d'approvisionnement pour les artefacts logiciels (SLSA).