Présentation de la sécurité sur l'infrastructure de Google

Le contenu du présent document est correct et représente le statu quo au mois de janvier 2017. Les stratégies et les systèmes de sécurité Google peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.

Résumé à l'intention des responsables informatiques

  • Google dispose d'une infrastructure technique à l'échelle mondiale, conçue pour assurer la sécurité tout au long du cycle de traitement des informations chez Google. Cette infrastructure garantit la sécurité de nos services à tous les niveaux : déploiement, stockage des données avec mesures de confidentialité pour l'utilisateur final, communications entre les services, communication en privé avec les clients via Internet, et opérations effectuées par les administrateurs.
  • Google utilise cette infrastructure pour développer ses services Internet, y compris les services grand public tels que la recherche Google, Gmail et Photos, et les services d'entreprise tels que G Suite et Google Cloud Platform.
  • La sécurité de l'infrastructure est mise en œuvre par niveaux successifs : d'abord la sécurité physique des centres de données, puis la sécurité du matériel et des logiciels sous-jacents à l'infrastructure, et enfin les contraintes et les processus techniques mis en place pour assurer la sécurité opérationnelle.
  • Google investit massivement dans la sécurisation de son infrastructure, avec plusieurs centaines d'ingénieurs dédiés à la sécurité et à la confidentialité répartis sur l'ensemble des sites de Google, dont beaucoup sont des professionnels d'autorités reconnues dans le secteur.

Présentation

Ce document donne un aperçu de la conception de la sécurité dans l'infrastructure technique de Google. Cette infrastructure à l'échelle mondiale vise à assurer la sécurité tout au long du cycle de traitement des informations chez Google. Elle garantit la sécurité de nos services à tous les niveaux : déploiement, stockage des données avec mesures de confidentialité pour l'utilisateur final, communications entre les services, communication en privé avec les clients via Internet, et opérations effectuées par les administrateurs.

Google utilise cette infrastructure pour développer ses services Internet, y compris les services grand public tels que la recherche Google, Gmail et Photos, et les services d'entreprise tels que G Suite et Google Cloud Platform.

Cet article décrit la sécurité de cette infrastructure, constituée de niveaux successifs : d'abord la sécurité physique des centres de données puis la sécurité du matériel et des logiciels sous-jacents à l'infrastructure, et enfin les contraintes et les processus techniques mis en place pour assurer la sécurité opérationnelle.

Niveaux de sécurité de l'infrastructure de Google : les différents niveaux de sécurité vont de l'infrastructure matérielle (niveau inférieur) à la sécurité opérationnelle (niveau supérieur). Le contenu de chaque niveau est décrit en détail dans ce document.

Infrastructure de bas niveau sécurisée

Cette section décrit comment les niveaux les plus bas de notre infrastructure sont sécurisés, que ce soit pour les locaux physiques, le matériel spécifique des centres de données ou la pile logicielle de bas niveau qui s'exécute sur chaque machine.

Sécurité des locaux physiques

Google conçoit et construit ses propres centres de données qui intègrent plusieurs niveaux de protection de sécurité physique. L'accès à ces centres de données est limité à seulement quelques employés Google. Nous utilisons plusieurs niveaux de sécurité physique pour protéger nos centres de données et mettons en œuvre des technologies telles que l'identification biométrique, la détection de métaux, les caméras, les barrières de sécurité pour véhicules et les systèmes de détection d'intrusion à laser. En outre, Google héberge des serveurs dans des centres de données tiers où nous nous assurons que des mesures de sécurité physique contrôlées par Google s'ajoutent aux niveaux de sécurité fournis par l'opérateur du centre de données. Par exemple, dans de tels sites, nous pouvons utiliser des systèmes d'identification biométrique, des caméras et des détecteurs de métaux indépendants.

Conception et provenance du matériel

Un centre de données Google comprend des milliers de serveurs connectés à un réseau local. Les cartes serveur et l'équipement réseau sont conçus par Google. Nous évaluons les fournisseurs de composants avec lesquels nous travaillons et choisissons les composants avec soin, tout en collaborant avec ces prestataires pour contrôler et valider les propriétés de sécurité fournies par les composants. Nous concevons également des puces personnalisées, y compris une puce de sécurité matérielle actuellement déployée sur les serveurs et les périphériques. Ces puces nous permettent d'identifier et d'authentifier de manière sécurisée les appareils Google légitimes au niveau matériel.

Sécurité de la pile de démarrage et de l'identité de la machine

Les serveurs Google utilisent différentes technologies afin de s'assurer qu'ils démarrent la bonne pile logicielle. Nous utilisons des signatures de chiffrement sur des composants de bas niveau tels que le BIOS, le bootloader, le noyau et l'image du système d'exploitation de base. Ces signatures peuvent être validées à chaque démarrage ou mise à jour. Les composants sont tous contrôlés, conçus et renforcés par Google. Avec chaque nouvelle génération de matériel, nous nous efforçons d'améliorer continuellement la sécurité : par exemple, en fonction de la génération du serveur, la racine de confiance de la chaîne de démarrage est établie grâce à une puce de micrologiciel verrouillable, un microcontrôleur exécutant le code de sécurité Google ou une puce de sécurité conçue par Google comme indiqué ci-dessus.

Chaque serveur du centre de données a sa propre identité spécifique qui peut être associée à la racine matérielle de confiance et au logiciel avec lequel la machine a démarré. Cette identité permet d'authentifier les appels d'API vers et depuis les services de gestion de bas niveau sur la machine.

Google a créé des systèmes automatisés pour s'assurer que les serveurs exécutent des versions à jour de leurs piles logicielles (y compris les correctifs de sécurité), pour détecter et diagnostiquer les problèmes matériels et logiciels, et pour retirer les machines du service si nécessaire.

Déploiement sécurisé d'un service

Dans cette section, nous abordons à présent la façon dont le matériel et les logiciels de base permettent d'assurer le déploiement sécurisé d'un service sur notre infrastructure. Par "service", nous entendons un binaire d'application qu'un développeur a écrit et veut utiliser sur notre infrastructure, par exemple un serveur SMTP Gmail, un serveur de stockage Bigtable, un transcodeur vidéo YouTube ou un bac à sable App Engine exécutant une application client. Des milliers de machines peuvent faire fonctionner des copies du même service pour gérer la capacité requise en terme de charge de travail. Les services exécutés sur l'infrastructure sont contrôlés par un service d'orchestration de clusters appelé Borg.

Comme nous le verrons dans la suite de cette section, l'infrastructure ne présume aucune confiance préalable entre les services s'exécutant sur l'infrastructure. En d'autres termes, l'infrastructure est fondamentalement conçue pour être mutualisée.

Identité, intégrité et isolement du service

Nous utilisons l'authentification et l'autorisation par chiffrement au niveau de l'application pour la communication inter-service. Cela permet un contrôle d'accès renforcé au niveau de l'abstraction et une granularité que les administrateurs et les services peuvent comprendre naturellement.

Nous ne nous servons pas de la segmentation interne du réseau ni du pare-feu comme principaux mécanismes de sécurité, bien que nous utilisions le filtrage d'entrée et de sortie comme niveau de sécurité supplémentaire à divers points de notre réseau afin d'empêcher le spoofing d'adresses IP. Cette approche nous aide également à optimiser les performances et la disponibilité de notre réseau.

Chaque service exécuté sur l'infrastructure possède une identité de compte de service associée. Des identifiants chiffrés sont fournis à chaque service, qui peut les utiliser pour prouver son identité lors de la réalisation ou de la réception d'appels de procédure à distance (RPC) à d'autres services. Ces identités permettent aux clients de s'assurer qu'ils communiquent avec le serveur approprié, et aux serveurs de limiter l'accès aux méthodes et aux données à des clients particuliers.

Le code source de Google est stocké dans un dépôt central dans lequel les versions actuelles et antérieures du service peuvent être contrôlées. L'infrastructure peut en outre être configurée pour exiger que les binaires d'un service soient créés à partir d'un code source spécifique examiné, vérifié et testé. De telles vérifications de code nécessitent l'inspection et l'approbation d'au moins un ingénieur autre que l'auteur. Le système impose également que les modifications de code apportées à n'importe quel système soient approuvées par les propriétaires de ce système. Non seulement ces exigences limitent la capacité d'un initié ou d'une personne mal intentionnée à apporter des modifications malveillantes au code source, mais elles fournissent également un outil permettant de tracer un service jusqu'à sa source.

Nous avons à disposition une variété de techniques d'isolement et de bac à sable pour protéger un service contre d'autres services fonctionnant sur la même machine. Ces techniques incluent la séparation des utilisateurs Linux standards, des bacs à sable basés sur le langage et le noyau, et la virtualisation matérielle. En général, nous utilisons un nombre plus élevé de niveaux d'isolement pour les charges de travail plus risquées. C'est notamment le cas pour l'exécution de convertisseurs de formats de fichiers complexes sur des données fournies par l'utilisateur, ou pour l'exécution de code fourni par l'utilisateur pour des produits tels que Google App Engine ou Google Compute Engine. Pour ajouter une barrière de sécurité, nous permettons à des services très sensibles, tels que le service d'orchestration de clusters et certains services de gestion de clés, de s'exécuter exclusivement sur des machines dédiées.

Gestion de l'accès inter-service

Le propriétaire d'un service a la possibilité de spécifier exactement quels autres services peuvent communiquer avec lui grâce aux fonctionnalités de gestion des accès fournies par l'infrastructure. Par exemple, un service peut souhaiter offrir certaines API uniquement à une liste blanche spécifique d'autres services. Ce service peut être configuré avec la liste blanche des identités de compte de service autorisées, et cette restriction d'accès est ensuite automatiquement appliquée par l'infrastructure.

Les ingénieurs Google qui accèdent aux services reçoivent également des identités individuelles, de sorte que les services peuvent être configurés de manière similaire pour autoriser ou refuser leurs accès. Tous ces types d'identités (machine, service et employé) se trouvent dans un espace de noms global géré par l'infrastructure. Comme expliqué dans la suite de ce document, les identités des utilisateurs finaux sont traitées séparément.

L'infrastructure fournit un système de processus de gestion des identités complet pour les identités internes, y compris les chaînes d'approbation, la journalisation et la notification. Par exemple, ces identités peuvent être attribuées à des groupes de contrôle d'accès via un système permettant un contrôle à deux parties où un ingénieur peut proposer une modification à un groupe qu'un autre ingénieur (qui est également administrateur du groupe) doit approuver. Ce système permet aux processus de gestion des accès sécurisés de s'adapter aux milliers de services fonctionnant sur l'infrastructure.

En plus du mécanisme automatique de contrôle d'accès au niveau de l'API, l'infrastructure fournit également aux services la possibilité de lire des LCA et des bases de données de groupe pour leur permettre d'appliquer leur propre contrôle d'accès personnalisé.

Chiffrement de la communication inter-service

Parallèlement aux fonctionnalités d'authentification et d'autorisation RPC décrites dans les sections précédentes, l'infrastructure fournit également une confidentialité et une intégrité par chiffrement pour les données RPC sur le réseau. Pour offrir ces avantages de sécurité à d'autres protocoles de couche d'application tels que HTTP, nous les encapsulons dans nos mécanismes RPC d'infrastructure. Cela permet essentiellement d'isoler la couche d'application et de supprimer toute dépendance à la sécurité du chemin réseau. La communication inter-service chiffrée peut rester sécurisée même si le réseau est piraté ou si un appareil réseau est compromis.

Les services peuvent configurer le niveau de protection par chiffrement qu'ils souhaitent pour chaque RPC d'infrastructure (par exemple, configurer uniquement la protection de niveau d'intégrité pour les données de faible valeur dans les centres de données). Pour se protéger de personnes mal intentionnées aux méthodes complexes qui tentent d'exploiter les liens WAN privés, l'infrastructure chiffre automatiquement tout le trafic RPC de l'infrastructure qui passe par le WAN entre les centres de données, sans nécessiter de configuration explicite du service. Nous avons commencé à déployer des accélérateurs de chiffrement matériels qui nous permettront d'étendre ce chiffrement par défaut à tout le trafic RPC de l'infrastructure dans nos centres de données.

Gestion de l'accès aux données de l'utilisateur final

Un service Google type est mis en place dans le but d'effectuer une action pour un utilisateur final. Par exemple, un utilisateur final peut stocker ses e-mails dans Gmail. L'interaction de l'utilisateur final avec une application telle que Gmail s'étend aux autres services de l'infrastructure. Par exemple, le service Gmail peut appeler une API fournie par le service Contacts pour accéder au carnet d'adresses de l'utilisateur final.

Comme indiqué dans la section précédente, le service Contacts peut être configuré de sorte que les seules requêtes RPC autorisées proviennent du service Gmail (ou de tout autre service particulier autorisé par le service Contacts).

Cependant, ceci représente toujours un très large ensemble d'autorisations. Dans le cadre de cette autorisation, le service Gmail serait en mesure de demander les contacts de n'importe quel utilisateur à tout moment.

Étant donné que le service Gmail envoie une requête RPC au service Contacts au nom d'un utilisateur final particulier, l'infrastructure offre au service Gmail la possibilité de présenter un "ticket d'autorisation d'utilisateur final" dans le cadre du RPC. Ce ticket prouve que le service Gmail traite actuellement une requête au nom de cet utilisateur final. Cela permet au service Contacts d'appliquer une mesure de sécurité grâce à laquelle il renvoie uniquement des données pour l'utilisateur final nommé dans le ticket.

L'infrastructure fournit un service d'identité d'utilisateur central qui émet ces "tickets d'autorisation d'utilisateur final". La connexion d'un utilisateur final est validée par le service d'identité central qui envoie ensuite les identifiants de l'utilisateur, comme un cookie ou un jeton OAuth, à l'appareil client de l'utilisateur. Chaque requête ultérieure de l'appareil client dans Google doit présenter ces identifiants d'utilisateur.

Lorsqu'un service reçoit les identifiants d'un utilisateur final, il les transmet au service d'identité central pour validation. Si les identifiants de l'utilisateur final sont validés, le service d'identité central renvoie un "ticket d'autorisation d'utilisateur final" de courte durée pouvant être utilisé pour les appels RPC liés à la requête. Dans notre exemple, ce service qui obtient le "ticket d'autorisation d'utilisateur final" serait le service Gmail qui le ferait parvenir au service Contacts. À partir de ce moment, le "ticket d'autorisation d'utilisateur final" peut être transmis par le service appelant à l'appelé dans le cadre de l'appel RPC pour tout appel en cascade.

Gestion de l'authentification et des accès des services : l'infrastructure fournit l'identité de service, l'authentification mutuelle automatique, la communication inter-service chiffrée et l'application des stratégies d'accès définies par le propriétaire du service.

Stockage sécurisé des données

Dans les sections précédentes, nous nous sommes intéressés au déploiement sécurisé des services. Découvrons à présent comment stocker des données de façon sécurisée sur l'infrastructure.

Chiffrement au repos

L'infrastructure de Google fournit une variété de services de stockage, tels que Bigtable et Spanner, ainsi qu'un service de gestion de clés central. La plupart des applications Google accèdent indirectement aux espaces de stockage physiques via ces services de stockage. Les services de stockage peuvent être configurés pour utiliser les clés du service de gestion de clés central afin de chiffrer les données avant qu'elles soient écrites sur l'espace de stockage physique. Ce service de gestion de clés est compatible avec la rotation automatique des clés, fournit des journaux d'audit complets et s'intègre aux tickets d'autorisation d'utilisateur final mentionnés précédemment pour associer des clés à des utilisateurs finaux particuliers.

L'exécution du chiffrement au niveau de la couche d'application permet à l'infrastructure de s'isoler des menaces potentielles aux niveaux inférieurs de stockage, telles que les micrologiciels de disques malveillants. Cela dit, l'infrastructure met également en place des niveaux de protection supplémentaires. Le chiffrement matériel est disponible sur nos disques durs et nos SSD, et chaque disque est suivi méticuleusement tout au long de son cycle de vie. Avant qu'un périphérique de stockage chiffré hors service puisse quitter nos locaux, il est nettoyé à l'aide d'un processus en plusieurs étapes comprenant deux vérifications indépendantes. Les périphériques qui ne réussissent pas cette procédure d'effacement sont physiquement détruits (c'est-à-dire, broyés) sur site.

Suppression de données

La suppression de données chez Google commence le plus souvent par le marquage de données spécifiques comme étant "programmées pour suppression" plutôt que par la suppression complète de données. Cela nous permet de récupérer des suppressions involontaires, qu'elles soient initiées par le client ou générées suite à un bug ou à une erreur de processus interne. Après avoir été marquées comme étant "programmées pour suppression", les données sont supprimées conformément aux stratégies spécifiques du service.

Lorsqu'un utilisateur final supprime l'ensemble de son compte, l'infrastructure informe les services gérant les données de l'utilisateur final que le compte a été supprimé. Les services peuvent ensuite programmer la suppression des données associées au compte d'utilisateur final supprimé. Cette fonctionnalité permet au développeur d'un service de facilement mettre en œuvre des paramètres de contrôle par l'utilisateur final.

Communication Internet sécurisée

Dans les sections précédentes de ce document, nous avons décrit la façon dont les services sont sécurisés sur notre infrastructure. Nous allons à présent vous expliquer comment nous sécurisons la communication entre Internet et ces services.

Comme nous l'avons expliqué précédemment, l'infrastructure se compose d'un grand ensemble de machines physiques qui sont interconnectées sur le LAN et le WAN. Nous avons également précisé que la sécurité de la communication inter-service ne dépend pas de la sécurité du réseau. Cependant, notre infrastructure est isolée du réseau Internet grâce à un espace d'adresses IP privé afin que des protections supplémentaires puissent être plus facilement mises en place, comme la protection contre les attaques par déni de service (DoS), en exposant uniquement un sous-ensemble des machines directement au trafic Internet externe.

Service Google Front End

Lorsqu'un service souhaite se rendre disponible sur Internet, il peut s'enregistrer auprès d'un service d'infrastructure appelé Google Front End (GFE). Le serveur GFE s'assure que toutes les connexions TLS sont effectuées en utilisant des certificats corrects et en suivant les bonnes pratiques, telles que la disponibilité de la confidentialité persistante parfaite. Il applique également des protections contre les attaques par déni de service (sujet abordé en détail ci-après). Le serveur GFE transmet ensuite les requêtes pour le service via le protocole de sécurité RPC décrit précédemment.

En effet, tout service interne qui choisit de se publier de manière externe utilise le serveur GFE comme interface intelligente de proxy inverse. Cette interface fournit l'hébergement IP public de son nom DNS public, la protection contre les attaques par déni de service (DoS) et la terminaison TLS. Sachez que les services passant par GFE s'exécutent sur l'infrastructure comme n'importe quel autre service et ont donc la possibilité d'évoluer pour s'adapter aux volumes de requêtes entrantes.

Protection relative au déni de service (DoS)

L'ampleur de notre infrastructure nous permet d'absorber facilement de nombreuses attaques DoS. Cela dit, des protections DoS à plusieurs niveaux et plusieurs couches sont présentes et permettent de réduire davantage le risque de tout impact DoS sur un service s'exécutant derrière un serveur GFE.

Une fois que notre réseau backbone fournit une connexion externe à l'un de nos centres de données, la connexion traverse plusieurs couches d'équilibrage de charge matérielle et logicielle. Ces équilibreurs de charge transmettent des informations sur le trafic entrant à un service DoS central s'exécutant sur l'infrastructure. Lorsque le service DoS central détecte la présence d'une attaque DoS, il peut configurer les équilibreurs de charge pour supprimer ou ralentir le trafic associé à l'attaque.

Au niveau de la couche suivante, les instances GFE signalent également les requêtes qu'elles reçoivent au service DoS central, y compris les informations sur la couche d'application que les équilibreurs de charge n'ont pas. Ensuite, le service DoS central peut également configurer les instances GFE pour supprimer ou ralentir le trafic associé à l'attaque.

Authentification de l'utilisateur

Après la protection DoS, le niveau de défense suivant provient du service d'identité central. Ce service se manifeste généralement par l'affichage de la page de connexion Google pour les utilisateurs finaux. Au-delà de la simple demande d'un nom d'utilisateur et d'un mot de passe, le service invite également les utilisateurs à fournir des informations supplémentaires basées sur des facteurs de risque tels que la connexion à partir du même appareil ou à un emplacement similaire. Après l'authentification de l'utilisateur, le service d'identité émet des identifiants, tels que des cookies et des jetons OAuth, qui peuvent être utilisés pour les appels suivants.

Les utilisateurs ont également la possibilité de se servir de seconds facteurs comme les OTP ou les clés de sécurité de protection contre l'hameçonnage lors de la connexion. Pour s'assurer que les avantages vont au-delà de Google, nous avons rejoint l'alliance FIDO aux côtés de plusieurs fournisseurs d'appareils pour développer la norme ouverte U2F (Universal 2nd Factor). Ces appareils sont désormais disponibles sur le marché, et d'autres services Web majeurs nous ont également suivis dans la mise en place de cette norme.

Sécurité opérationnelle

Dans les sections précédentes, nous avons décrit la conception de la sécurité dans notre infrastructure, ainsi que certains des mécanismes de fonctionnement sécurisé comme les contrôles d'accès sur les RPC.

Nous allons à présent nous intéresser à la façon dont nous gérons la sécurité de l'infrastructure : les logiciels d'infrastructure sont créés de manière sécurisée, les machines et les identifiants de nos employés sont protégés, et les menaces des initiés ainsi que des acteurs externes sont traitées de façon appropriée.

Développement de logiciel sécurisé

Parallèlement au contrôle de source central et aux fonctionnalités de vérification à deux parties décrites précédemment, des bibliothèques sont également mises à disposition et permettent d'empêcher les développeurs d'introduire certaines classes de bugs de sécurité. Par exemple, nous utilisons des bibliothèques et des frameworks grâce auxquels il est possible d'éliminer les failles XSS dans les applications Web. Nous proposons également des outils automatisés tels que des fuzzers, des outils d'analyse statique et des analyseurs de sécurité Web pour détecter automatiquement les bugs de sécurité.

En guise de validation finale, des vérifications de sécurité manuelles sont effectuées, qu'il s'agisse de triages rapides pour les fonctionnalités moins risquées ou de contrôles approfondis de la conception et de la mise en œuvre pour les fonctionnalités les plus risquées. Ces vérifications sont réalisées par une équipe composée d'experts en matière de sécurité Web, de chiffrement et de sécurité du système d'exploitation. Elles peuvent également aboutir à la création de fonctionnalités de bibliothèque de sécurité et de fuzzers qui peuvent ensuite être appliqués à d'autres futurs produits.

En outre, un programme de récompenses pour la découverte de failles, Vulnerability Rewards Program, a été mis en place et permet de récompenser financièrement toute personne étant capable de découvrir et de signaler des bugs dans notre infrastructure ou dans nos applications. Plusieurs millions de dollars ont été versés en guise de récompense dans le cadre de ce programme.

Nous déployons également beaucoup d'efforts pour trouver des vulnérabilités zero-day et d'autres problèmes de sécurité dans tous les logiciels Open Source que nous utilisons, et pour faire remonter ces problèmes. Par exemple, le bug OpenSSL Heartbleed a été trouvé chez Google, désormais le plus grand émetteur de CVE et de corrections de bugs de sécurité pour l'hyperviseur KVM de Linux.

Sécuriser les appareils et les identifiants des employés

Nous investissons de manière importante dans la protection des appareils et des identifiants de nos employés, ainsi que dans la surveillance des activités afin de découvrir des menaces potentielles ou des activités d'initiés illicites. Il s'agit d'un élément essentiel de notre investissement visant à assurer le fonctionnement sécurisé de notre infrastructure.

Nos employés sont constamment la cible de tentatives d'hameçonnage sophistiquées. Pour se protéger contre cette menace, nous avons remplacé les seconds facteurs OTP vulnérables par l'utilisation obligatoire de clés de sécurité compatibles U2F pour les comptes d'employés.

Nous investissons beaucoup dans la surveillance des appareils clients qui permettent à nos employés de faire fonctionner notre infrastructure. Nous nous assurons que les images du système d'exploitation de ces appareils clients sont à jour avec les correctifs de sécurité, et nous contrôlons les applications qui peuvent être installées. Nous disposons en outre de systèmes permettant d'analyser les applications installées par les utilisateurs, les téléchargements, les extensions de navigateur et les contenus consultés sur le Web afin de déterminer leur pertinence sur les clients d'entreprise.

La présence sur le LAN de l'entreprise ne représente pas notre mécanisme principal pour accorder des privilèges d'accès. Nous utilisons plutôt des contrôles de gestion des accès au niveau de l'application qui nous permettent d'exposer les applications internes uniquement à des utilisateurs spécifiques lorsqu'ils proviennent d'un appareil correctement géré ainsi que de réseaux et d'emplacements géographiques attendus. (Pour en savoir plus, consultez notre article sur BeyondCorp.)

Réduire les risques internes

Nous limitons et surveillons activement les activités des employés qui bénéficient d'un accès administratif à l'infrastructure, et nous travaillons sans relâche afin d'éliminer le besoin d'accès privilégié pour des tâches particulières en fournissant une automatisation pouvant accomplir les mêmes tâches de manière sûre et contrôlée. Ce processus exige des approbations à deux parties pour certaines actions et l'introduction des API limitées permettant le débogage sans exposer les informations sensibles.

L'accès des employés Google aux informations sur les utilisateurs finaux peut être enregistré via des crochets d'infrastructure de bas niveau. L'équipe de sécurité Google surveille activement les modèles d'accès et examine les événements inhabituels.

Détection des intrusions

Google dispose de pipelines de traitement de données sophistiqués qui intègrent des signaux basés sur l'hôte sur des appareils individuels, des signaux basés sur le réseau provenant de différents points de surveillance dans l'infrastructure, ainsi que des signaux émis par les services d'infrastructure. Des règles et des fonctionnalités d'intelligence artificielle articulées autour de ces pipelines avertissent les ingénieurs en sécurité opérationnelle d'incidents possibles. Nos équipes d'investigation et d'intervention en cas d'incident trient ce type d'événements potentiels, les examinent et agissent 24h/24, 7j/7 et 365 jours par an. Des exercices red team sont menés à bien pour mesurer et améliorer l'efficacité de nos mécanismes de détection et d'intervention.

Sécuriser Google Cloud Platform (GCP)

Vous allez à présent découvrir comment notre infrastructure de cloud public, GCP, bénéficie de la sécurité de l'infrastructure sous-jacente. Dans cette section, nous utilisons Google Compute Engine comme exemple de service et nous décrivons en détail les améliorations de sécurité spécifiques au service articulées autour de l'infrastructure.

Compute Engine permet aux clients d'exécuter leurs propres machines virtuelles sur l'infrastructure de Google. La mise en place de Compute Engine repose sur plusieurs composants logiques, notamment le plan de contrôle de gestion et les machines virtuelles elles-mêmes.

Le plan de contrôle de gestion expose la surface de l'API externe et orchestre des tâches telles que la création et la migration de machines virtuelles. Il fonctionne comme une variété de services sur l'infrastructure. Il bénéficie donc automatiquement de fonctionnalités d'intégrité fondamentales telles qu'une chaîne de démarrage sécurisée. Les services individuels s'exécutent sous des comptes de service interne distincts de sorte que chaque service ne puisse bénéficier que des autorisations requises lors des appels de procédure à distance (RPC) sur le reste du plan de contrôle. Comme indiqué précédemment, le code de tous ces services est stocké dans le dépôt de code source central de Google. Il existe une trace de contrôle entre ce code et les fichiers binaires qui seront déployés.

Le plan de contrôle de Compute Engine expose son API via le serveur GFE et profite ainsi des fonctionnalités de sécurité de l'infrastructure telles que la protection par déni de service (DoS) et la compatibilité des protocoles SSL/TLS gérée de manière centralisée. Les clients peuvent obtenir des protections similaires pour les applications exécutées sur leurs machines virtuelles Compute Engine en choisissant d'utiliser le service facultatif Google Cloud Load Balancer, qui est intégré au serveur GFE et peut limiter les risques de nombreux types d'attaques DoS.

L'authentification de l'utilisateur final pour l'API du plan de contrôle de Compute Engine est effectuée via le service d'identité centralisé de Google qui fournit des fonctionnalités de sécurité telles que la détection de piratage. L'autorisation est effectuée à l'aide du service Cloud IAM central.

Le trafic réseau pour le plan de contrôle, à la fois des serveurs GFE vers le premier service et entre les autres services du plan de contrôle, est automatiquement authentifié par l'infrastructure et chiffré chaque fois qu'il se déplace d'un centre de données à un autre. En outre, l'infrastructure a été configurée pour chiffrer une partie du trafic du plan de contrôle dans le centre de données lui-même.

Chaque machine virtuelle (VM) s'exécute avec une instance de service de gestionnaire de machine virtuelle (VMM) associée. L'infrastructure fournit à ces services deux identités. Une identité est utilisée par l'instance de service VMM pour ses propres appels, et une autre identité est utilisée pour les appels que le VMM effectue au nom de la VM du client. Cela nous permet de segmenter davantage la confiance placée dans les appels provenant du VMM.

Les disques persistants de Compute Engine sont chiffrés au repos à l'aide de clés protégées par le système de gestion de clés d'infrastructure central. Cela permet une rotation automatisée et un contrôle central de l'accès à ces clés.

Les clients ont aujourd'hui la possibilité d'envoyer le trafic de leurs VM vers d'autres VM ou Internet en clair, ou d'utiliser le chiffrement souhaité pour ce trafic. Nous avons commencé à déployer le chiffrement automatique pour le saut de balayage WAN des VM des clients vers le trafic des VM. Comme décrit précédemment, tout le trafic WAN du plan de contrôle dans l'infrastructure est déjà chiffré. Par la suite, nous prévoyons de tirer parti du chiffrement de réseau avec accélération matérielle dont il a été question plus haut pour chiffrer également le trafic LAN inter-VM dans le centre de données.

L'isolement fourni aux VM est basée sur la virtualisation matérielle à l'aide de la pile KVM Open Source. Nous avons renforcé la mise en place spécifique de KVM en déplaçant une partie de la pile d'émulation de contrôle et de matériel dans un processus non privilégié en dehors du noyau. Nous avons également beaucoup testé le noyau de KVM en utilisant des techniques telles que le fuzzing, l'analyse statique et la vérification manuelle du code. Comme mentionné précédemment, la majorité des failles récemment révélées publiquement dans KVM ont été détectées par Google.

Enfin, nos contrôles de sécurité opérationnels sont un élément clé pour garantir que les accès aux données sont conformes à nos stratégies. Dans le cadre de Google Cloud Platform, l'utilisation des données des clients par Compute Engine est conforme aux stratégies de GCP pour ce type de données, à savoir que Google s'engage à ne pas accéder aux données des clients, ni à les utiliser, sauf dans la mesure nécessaire pour fournir des services aux clients.

Conclusion

Dans cet article, nous avons décrit comment l'infrastructure de Google est conçue pour créer, déployer et faire fonctionner des services de façon sécurisée à l'échelle d'Internet. Cela inclut à la fois les services grand public, tels que Gmail, et nos services d'entreprise. De plus, nos offres Google Cloud sont basées sur cette même infrastructure.

Nous investissons de manière importante dans la sécurisation de notre infrastructure. Nous comptons plusieurs centaines d'ingénieurs dédiés à la sécurité et à la confidentialité répartis sur l'ensemble des sites de Google, dont beaucoup sont des professionnels d'autorités reconnues dans le secteur.

Comme mentionné précédemment, la sécurité de l'infrastructure est mise en œuvre par couches progressives, depuis les composants physiques et les centres de données jusqu'à la provenance du matériel, en passant par le démarrage sécurisé, la communication inter-service sécurisée, les données sécurisées au repos, l'accès protégé aux services Internet et, enfin, les technologies et les processus humains déployés pour la sécurité opérationnelle.

Autres ressources à lire

Consultez les documents suivants pour en savoir plus sur des sujets spécifiques :

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…