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

Ce contenu a été mis à jour pour la dernière fois en juin 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.

Présentation

Ce document donne un aperçu de la conception de la sécurité dans l'infrastructure technique de Google. Il est destiné aux cadres, architectes et auditeurs de sécurité.

Ce document décrit les éléments suivants:

  • L'infrastructure technique mondiale de Google, conçue pour assurer la sécurité tout au long du cycle de traitement des informations chez Google. Cette infrastructure permet de fournir les éléments suivants :
    • Déploiement sécurisé de services
    • Stockage sécurisé des données avec mesures de confidentialité pour l'utilisateur final
    • Communication sécurisée entre les services
    • Communication sécurisée et privée avec les clients via Internet
    • Fonctionnement sécurisé par les ingénieurs de Google
  • Comment nous utilisons cette infrastructure pour créer des services Internet, y compris des services grand public tels que la recherche Google, Gmail et Google Photos, et des services d'entreprise tels que Google Workspace et Google Cloud.
  • Nous investissons dans la sécurisation de notre infrastructure et de nos opérations. De nombreux ingénieurs sont dédiés à la sécurité et à la confidentialité dans tous les services Google, dont beaucoup sont des professionnels d'autorités reconnues dans le secteur.
  • Les produits et services de sécurité résultant d'innovations que nous avons mises en œuvre en interne pour répondre à nos besoins de sécurité. Par exemple, BeyondCorp est le résultat direct de notre mise en œuvre interne du modèle de sécurité "zéro confiance".

  • La conception de la sécurité de l'infrastructure par couches progressives. Ces couches incluent les éléments suivants:

Les sections suivantes de ce document décrivent les couches de sécurité.

Infrastructure de bas niveau sécurisée

Cette section décrit comment les locaux physiques de nos centres de données, le matériel de nos centres de données et la pile logicielle exécutée sur le matériel sont sécurisés.

Sécurité des locaux physiques

Nous concevons et construisons nos propres centres de données qui intègrent plusieurs niveaux de sécurité physique. L'accès à ces centres de données est étroitement contrôlé. Nous utilisons plusieurs niveaux de sécurité physique pour protéger nos centres de données. Nous utilisons 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. Pour en savoir plus, consultez la section Sécurité des centres de données.

Nous hébergeons également certains serveurs dans des centres de données tiers. Dans ces centres de données, nous nous assurons que des mesures de sécurité physique contrôlées par Google s'ajoutent aux couches de sécurité fournies par l'opérateur du centre de données. Par exemple, nous exploitons des systèmes d'identification biométrique, des caméras et des détecteurs de métaux indépendants des couches de sécurité fournies par l'opérateur du centre de données.

Conception et provenance du matériel

Un centre de données Google comprend des milliers de serveurs connectés à un réseau local. Nous concevons les cartes de serveur et l'équipement réseau. Nous évaluons les fournisseurs de composants avec lesquels nous travaillons et choisissons les composants avec soin. Nous aidons les fournisseurs à 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 (appelée Titan) que nous déployons sur des serveurs, des appareils et des périphériques. Ces puces nous permettent d'identifier et d'authentifier les appareils Google légitimes au niveau matériel, et de servir de racines de confiance matérielles.

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

Les serveurs Google utilisent diverses technologies pour s'assurer qu'ils démarrent la bonne pile logicielle. Nous utilisons des signatures de chiffrement pour des composants de bas niveau tels que le contrôleur de gestion de carte de base (BMC), le BIOS, le bootloader, le noyau et l'image du système d'exploitation de base. Ces signatures peuvent être validées pendant chaque cycle de démarrage ou de mise à jour. La première vérification de l'intégrité des serveurs Google utilise une racine de confiance matérielle. Les composants sont contrôlés, conçus et renforcés par Google avec une attestation d'intégrité. Avec chaque nouvelle génération de matériel, nous nous efforçons d'améliorer continuellement la sécurité. Par exemple, selon la génération de la conception du serveur, la racine de confiance de la chaîne de démarrage est l'une des suivantes:

  • La puce matérielle Titan
  • Une puce de micrologiciel verrouillable
  • Un microcontrôleur exécutant notre propre code de sécurité

Chaque serveur du centre de données a sa propre identité unique. Cette identité peut être liée à la racine de confiance matérielle et au logiciel avec lequel la machine démarre. Cette identité permet d'authentifier les appels d'API vers et depuis les services de gestion de bas niveau sur la machine. Cette identité est également utilisée pour l'authentification mutuelle des serveurs et le chiffrement des données en transit. Nous avons développé le système Application Layer Transport Security (ALTS) pour sécuriser les communications d'appel de procédure à distance (RPC) au sein de notre infrastructure. Ces identités de machine peuvent être révoquées de manière centralisée pour répondre à un incident de sécurité. En outre, leurs certificats et leurs clés sont régulièrement alternés, et les anciens sont révoqués.

Nous avons développé des systèmes automatisés pour effectuer les opérations suivantes:

  • Assurez-vous que les serveurs exécutent les versions à jour de leurs piles logicielles (y compris les correctifs de sécurité).
  • Détectez et diagnostiquez les problèmes matériels et logiciels.
  • Garantissez l'intégrité des machines et des périphériques à l'aide du démarrage validé et de l'attestation implicite.
  • Assurez-vous que seules les machines exécutant le logiciel et le micrologiciel souhaités peuvent accéder aux identifiants leur permettant de communiquer sur le réseau de production.
  • Supprimez ou réallouez les machines du service lorsqu'elles ne sont plus nécessaires.

Déploiement sécurisé d'un service

Les services Google sont les fichiers binaires d'application que nos développeurs écrivent et exécutent sur notre infrastructure. Exemples de services Google : serveurs Gmail, bases de données Spanner, serveurs Cloud Storage, transcodeurs vidéo YouTube et VM Compute Engine exécutant des applications clientes. Pour gérer l'ampleur de la charge de travail requise, des milliers de machines peuvent exécuter des binaires du même service. Un service d'orchestration de clusters, appelé Borg, contrôle les services exécutés directement sur l'infrastructure.

L'infrastructure ne présume aucune confiance préalable entre les services exécutés sur l'infrastructure. Ce modèle de confiance est appelé modèle de sécurité "zéro confiance". Un modèle de sécurité zéro confiance signifie qu'aucun appareil ni utilisateur n'est approuvé par défaut, qu'il se trouve à l'intérieur ou à l'extérieur du réseau.

L'infrastructure étant conçue pour être mutualisée, les données de nos clients (consommateurs, entreprises et même nos propres données) sont réparties sur une infrastructure partagée. Cette infrastructure est composée de dizaines de milliers de machines homogènes. L'infrastructure ne sépare pas les données client sur une seule machine ou un seul ensemble de machines, sauf dans des circonstances spécifiques, par exemple lorsque vous utilisez Google Cloud pour provisionner des VMNœuds à locataire unique pour Compute Engine.

Google Cloud et Google Workspace sont conformes aux exigences réglementaires concernant la résidence des données. Pour en savoir plus sur la résidence des données et Google Cloud, consultez la page Mettre en œuvre les exigences de résidence des données et de souveraineté. Pour en savoir plus sur la résidence des données et Google Workspace, consultez l'article Emplacements des données: Choisir un emplacement géographique pour vos données.

Identité, intégrité et isolement du service

Pour activer la communication inter-service, les applications utilisent l'authentification et l'autorisation par chiffrement. L'authentification et l'autorisation offrent un contrôle d'accès renforcé au niveau de l'abstraction et une précision que les administrateurs et les services peuvent comprendre.

Les services ne reposent pas sur la segmentation du réseau interne ni sur le pare-feu en tant que mécanisme de sécurité principal. Le filtrage des entrées et des sorties à différents points de notre réseau permet d'éviter le spoofing d'adresses IP. Cette approche nous aide également à optimiser les performances et la disponibilité de notre réseau. Pour Google Cloud, vous pouvez ajouter des mécanismes de sécurité supplémentaires tels que VPC Service Controls et Cloud Interconnect.

Chaque service exécuté sur l'infrastructure possède une identité de compte de service. Des identifiants chiffrés sont fournis à chaque service, qui peut les utiliser pour prouver son identité à d'autres services lors de la création ou de la réception de RPC. Ces identités sont utilisées dans les stratégies de sécurité. Les stratégies de sécurité garantissent que les clients communiquent avec le serveur prévu et que les serveurs limitent les méthodes et les données auxquelles certains clients peuvent accéder.

Nous utilisons diverses techniques d'isolation et de bac à sable pour protéger un service d'autres services exécutés sur la même machine. Ces techniques incluent la séparation des utilisateurs Linux, des bacs à sable basés sur le langage (tels que l'API Sandboxed) et des bacs à sable basés sur un noyau, un noyau d'application pour les conteneurs (par exemple, gVisor) 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. Les charges de travail plus risquées incluent des éléments fournis par l'utilisateur qui nécessitent un traitement supplémentaire. Par exemple, les charges de travail plus risquées incluent l'exécution de convertisseurs de fichiers complexes sur des données fournies par l'utilisateur ou l'exécution de code fourni par l'utilisateur pour des produits tels qu'App Engine ou Compute Engine.

Pour plus de sécurité, les services sensibles, tels que le service d'orchestration de clusters et certains services de gestion de clés, s'exécutent exclusivement sur des machines dédiées.

Dans Google Cloud, pour renforcer l'isolation cryptographique de vos charges de travail et protéger les données utilisées, nous acceptons les services d'informatique confidentielle pour les nœuds Google Kubernetes Engine (GKE) et VM Compute Engine.

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 limiter les RPC entrants uniquement à une liste autorisée d'autres services. Ce service peut être configuré avec la liste des identités de service autorisées, et l'infrastructure applique automatiquement cette restriction d'accès. L'application forcée inclut la journalisation d'audit, les justifications et la restriction d'accès unilatéral (pour les demandes d'ingénierie, par exemple).

Les ingénieurs Google qui ont besoin d'accéder aux services reçoivent également des identités individuelles. Les services peuvent être configurés pour autoriser ou refuser leur accès en fonction de leurs identités. Toutes ces identités (machine, service et employé) se trouvent dans un espace de noms global géré par l'infrastructure.

Pour gérer ces identités, l'infrastructure fournit un système de workflow incluant des chaînes d'approbation, une journalisation et des notifications. Par exemple, la stratégie de sécurité peut appliquer une autorisation multipartie. Ce système utilise la règle à deux personnes pour s'assurer qu'un ingénieur agissant seul ne peut pas effectuer d'opérations sensibles sans l'approbation préalable d'un autre ingénieur autorisé. Ce système permet aux processus de gestion des accès sécurisés de s'adapter à des milliers de services fonctionnant sur l'infrastructure.

L'infrastructure fournit également des services avec le service canonique pour la gestion des utilisateurs, des groupes et des adhésions afin qu'ils puissent mettre en œuvre un contrôle d'accès personnalisé et précis si nécessaire.

Les identités des utilisateurs finaux sont gérées séparément, comme décrit dans la section Gestion des accès aux données des utilisateurs finaux dans Google Workspace.

Chiffrement de la communication inter-service

L'infrastructure assure la confidentialité et l'intégrité des données RPC sur le réseau. Tout le trafic des réseaux virtuels Google Cloud est chiffré. Toutes les communications entre les services d'infrastructure sont authentifiées et la plupart des communications interservices sont chiffrées, ce qui ajoute une couche de sécurité supplémentaire pour protéger la communication même si le réseau est piraté ou si un appareil réseau est compromis. Les exceptions à l'exigence de chiffrement pour la communication inter-service ne sont accordées que pour le trafic présentant des exigences de faible latence et qui ne quitte pas une même structure de mise en réseau au sein des multiples couches de sécurité physique de notre centre de données.

L'infrastructure fournit automatiquement et efficacement (à l'aide du déchargement matériel) un chiffrement de bout en bout pour le trafic RPC de l'infrastructure qui passe par le réseau entre les centres de données.

Gérer l'accès aux données de l'utilisateur final dans Google Workspace

Un service Google Workspace 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 peut couvrir d'autres services de l'infrastructure. Par exemple, Gmail peut appeler une API People pour accéder au carnet d'adresses de l'utilisateur final.

La section Chiffrement de la communication inter-service décrit comment un service (tel que Google Contacts) est conçu pour protéger les requêtes RPC d'un autre service (tel que Gmail). Ce niveau de contrôle d'accès reste un large ensemble d'autorisations, car Gmail peut demander les contacts de n'importe quel utilisateur à tout moment.

Lorsque Gmail envoie une requête RPC à Google Contacts pour le compte d'un utilisateur final, l'infrastructure permet à Gmail de présenter une demande d'autorisation de l'utilisateur final dans la requête RPC. Ce ticket prouve que Gmail envoie la requête RPC au nom de cet utilisateur final. Le ticket permet à Google Contacts d'appliquer une mesure de sécurité de sorte qu'il ne renvoie que des données pour l'utilisateur final nommé dans le ticket.

L'infrastructure fournit un service d'identité d'utilisateur central qui émet ces demandes de contexte de l'utilisateur final. Le service de gestion des identités vérifie la connexion de l'utilisateur final et envoie ensuite les identifiants de l'utilisateur, comme un cookie ou un jeton OAuth, à l'appareil de l'utilisateur. Chaque requête ultérieure de l'appareil à notre infrastructure doit présenter ces identifiants d'utilisateur final.

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

Le schéma suivant montre comment le service A et le service B communiquent. 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. Chaque service possède une configuration de service que le propriétaire du service crée. Pour la communication inter-service chiffrée, l'authentification mutuelle automatique utilise des identités appelantes et appelées. La communication n'est possible que lorsqu'une configuration de règle d'accès le permet.

Schéma montrant comment les services A et B communiquent.

Pour en savoir plus sur la gestion des accès dans Google Cloud, consultez la page Présentation d'IAM.

Gérer l'accès aux données de l'utilisateur final dans Google Cloud

À l'instar de la gestion des accès aux données des utilisateurs finaux dans Google Workspace, l'infrastructure fournit un service d'identité d'utilisateur final qui authentifie les comptes de service et émet des demandes de contexte d'utilisateur final après l'authentification d'un compte de service. La gestion des accès entre les services Google Cloud s'effectue généralement avec des agents de service plutôt que avec des demandes de contexte d'utilisateur final.

Google Cloud utilise Identity and Access Management (IAM) et des produits contextuels tels qu'Identity-Aware Proxy pour vous permettre de gérer l'accès aux ressources dans votre organisation Google Cloud. Toutes les requêtes adressées aux services Google Cloud passent par IAM pour vérifier les autorisations.

Le processus de gestion des accès est le suivant :

  1. Une requête est transmise via le service Google Front End ou le service Cloud Front End pour les VM clientes.
  2. La requête est acheminée vers le service d'identité d'utilisateur final qui termine la vérification d'authentification et émet les tickets de contexte d'utilisateur final.
  3. La requête est également acheminée pour vérifier des éléments tels que :
  4. Une fois toutes ces vérifications effectuées, les services de backend Google Cloud sont appelés.

Pour en savoir plus sur la gestion des accès dans Google Cloud, consultez la page Présentation d'IAM.

Stockage sécurisé des données

Cette section décrit comment nous mettons en œuvre la sécurité des données stockées sur l'infrastructure.

Chiffrement au repos

L'infrastructure de Google fournit divers services de stockage et systèmes de fichiers distribués (par exemple, Spanner et Colossus) ainsi qu'un service de gestion de clés central. Les applications Google accèdent à l'espace de stockage physique via une infrastructure de stockage. Nous utilisons plusieurs niveaux de chiffrement pour protéger les données au repos. Par défaut, l'infrastructure de stockage chiffre toutes les données utilisateur avant que celles-ci ne soient écrites sur l'espace de stockage physique.

L'infrastructure effectue le chiffrement au niveau de la couche d'infrastructure de l'application ou du stockage. Le chiffrement permet à l'infrastructure de s'isoler des menaces potentielles aux niveaux inférieurs de stockage, telles que les micrologiciels de disques malveillants. Le cas échéant, nous activons également la compatibilité du chiffrement matériel sur nos disques durs et nos SSD, et nous suivons méticuleusement chaque disque 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 ce processus de nettoyage sont physiquement détruits (c'est-à-dire, broyés) sur site.

En plus du chiffrement effectué par l'infrastructure, Google Cloud et Google Workspace fournissent des services de gestion des clés. Pour Google Cloud, Cloud KMS est un service cloud qui permet aux clients de gérer les clés cryptographiques. Pour Google Workspace, vous pouvez utiliser le chiffrement côté client. Pour en savoir plus, consultez la section Chiffrement côté client et collaboration renforcée dans Google Workspace.

Suppression de données

La suppression de données commence généralement par la programmation de suppression de données spécifiques plutôt que par la suppression effective des données. Cette approche nous permet d'éviter des suppressions involontaires, qu'elles soient initiées par le client, qu'elles soient dues à un bug ou qu'elles résultent d'une erreur de processus interne. Lorsque les données sont marquées pour suppression, elles sont supprimées conformément aux stratégies spécifiques du service.

Lorsqu'un utilisateur final supprime son compte, l'infrastructure informe les services qui gèrent 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 à un utilisateur final de contrôler ses propres données.

Pour plus d'informations, consultez la section Suppression des données sur Google Cloud.

Communication Internet sécurisée

Cette section décrit comment nous sécurisons la communication entre Internet et les services qui s'exécutent sur l'infrastructure de Google.

Comme indiqué dans la section Conception et provenance du matériel, l'infrastructure se compose de nombreuses machines physiques qui sont interconnectées sur le LAN et le WAN. 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'adressage IP privé. Nous n'exposons qu'un sous-ensemble des machines directement au trafic Internet externe, afin de pouvoir mettre en œuvre des protections supplémentaires telles que les défenses contre les attaques par déni de service (DoS).

Service Google Front End

Lorsqu'un service doit 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. Le GFE applique également des protections contre les attaques DoS. Le serveur GFE transmet ensuite les requêtes pour le service via le protocole de sécurité RPC décrit dans la section Gérer les accès aux données de l'utilisateur final dans Google Workspace.

En effet, tout service interne qui doit se publier de manière externe utilise le serveur GFE comme interface intelligente de proxy inverse. Le GFE fournit l'hébergement IP public de son nom DNS public, la protection DoS et la terminaison TLS. Les GFE s'exécutent sur l'infrastructure comme n'importe quel autre service et peuvent évoluer en fonction des volumes de requêtes entrantes.

Les VM clientes sur Google Cloud ne s'enregistrent pas auprès de GFE. À la place, elles s'enregistrent auprès de Cloud Front End, une configuration spéciale de GFE qui utilise la pile réseau de Compute Engine. Cloud Front End permet aux VM clientes d'accéder directement à un service Google à l'aide de leur adresse IP publique ou privée. (Les adresses IP privées ne sont disponibles que lorsque l'accès privé à Google est activé.)

Protection DoS

L'échelle de notre infrastructure nous permet d'absorber de nombreuses attaques DoS. Pour réduire davantage le risque d'impact DoS sur les services, nous avons mis en place des protections DoS à plusieurs niveaux et plusieurs couches.

Lorsque notre réseau backbone par fibre optique fournit une connexion externe à l'un de nos centres de données, la connexion passe par plusieurs couches d'équilibreurs de charge matériels et logiciels. 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 une attaque DoS, il peut configurer les équilibreurs de charge pour supprimer ou limiter le trafic associé à l'attaque.

Les instances GFE signalent également des informations sur les requêtes qu'elles reçoivent au service DoS central, y compris les informations sur la couche d'application auxquelles les équilibreurs de charge n'ont pas accès. Ensuite, le service DoS central peut configurer les instances GFE pour supprimer ou limiter le trafic associé à l'attaque.

Authentification des utilisateurs

Après la protection DoS, le niveau de défense suivant pour la communication sécurisée provient du service d'identité central. Les utilisateurs finaux interagissent avec ce service via la page de connexion Google. Le service demande un nom d'utilisateur et un mot de passe, et peut également inviter les utilisateurs à saisir des informations supplémentaires en fonction de facteurs de risque. Les facteurs de risque incluent, par exemple, si les utilisateurs se sont connectés depuis le même appareil ou depuis 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.

Lorsque les utilisateurs se connectent, ils peuvent utiliser des seconds facteurs comme les OTP ou les clés de sécurité avec protection contre l'hameçonnage, comme la clé de sécurité Titan. La clé de sécurité Titan est un jeton physique compatible avec le facteur U2F (FIDO Universal 2nd Factor). Nous avons participé au développement de la norme ouverte U2F avec l'alliance FIDO. La plupart des plates-formes et navigateurs Web ont adopté cette norme d'authentification ouverte.

Sécurité opérationnelle

Cette section décrit le développement de nos logiciels d'infrastructure, la protection des machines et des identifiants de nos employés, et la protection contre les menaces internes et externes contre l'infrastructure.

Développement de logiciel sécurisé

Outre les protections du contrôle du code source et le processus d'examen à deux parties décrits précédemment, nous utilisons des bibliothèques qui empêchent 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 utilisons é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. L'équipe qui effectue ces examens comprend des experts en matière de sécurité Web, de chiffrement et de sécurité du système d'exploitation. Ces examens peuvent entraîner le développement de nouvelles fonctionnalités de bibliothèque de sécurité et de fuzzers que nous pouvons utiliser pour de futurs produits.

En outre, un programme Vulnerability Rewards est mis en place pour récompenser quiconque découvre et signale les bugs dans notre infrastructure ou dans nos applications. Pour en savoir plus sur ce programme, y compris sur les récompenses que nous vous avons attribuées, consultez la page Statistiques essentielles de Bug Hunters.

Nous investissons également dans la recherche d'attaques du jour zéro et d'autres problèmes de sécurité dans les logiciels Open Source que nous utilisons. Nous gérons le projet zéro, qui est une équipe de chercheurs de Google spécialisés dans la recherche de failles du jour zéro, telles que Spectre et Meltdown De plus, nous sommes le plus grand émetteur de CVE et de corrections de bugs de sécurité pour l'hyperviseur KVM de Linux.

Protections du code source

Notre code source est stocké dans des dépôts dotés d'une intégrité de la source et d'une gouvernance intégrées, où les versions actuelles et antérieures du service peuvent être auditées. L'infrastructure nécessite que les binaires d'un service soient créés à partir d'un code source spécifique, après examen, évaluation et test. L'autorisation binaire pour Borg (BAB) est une vérification d'application interne qui se produit lorsqu'un service est déployé. L'autorisation binaire pour Borg effectue les opérations suivantes:

  • Elle s'assure que les logiciels de production et la configuration déployés chez Google sont examinés et autorisés, en particulier lorsque le code peut accéder aux informations sur les utilisateurs.
  • L'autorisation binaire pour Borg s'assure que les déploiements de code et de configuration respectent au minimum certaines normes.
  • Limite la capacité d'un initié ou d'une personne mal intentionnée à apporter des modifications malveillantes au code source, et fournit également un outil permettant de tracer un service jusqu'à sa source.

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

Nous mettons en œuvre des mesures de sauvegardes pour protéger les appareils et les identifiants de nos employés contre les menaces. Pour protéger nos employés contre les tentatives d'hameçonnage sophistiquées, nous avons remplacé l'authentification à deux facteurs OTP par l'utilisation obligatoire de clés de sécurité compatibles U2F.

Nous surveillons les appareils clients que nos employés utilisent pour faire fonctionner notre infrastructure. Nous nous assurons que les images du système d'exploitation de ces appareils sont à jour avec les correctifs de sécurité, et nous contrôlons les applications que les employés peuvent installer sur leurs appareils. Nous disposons également de systèmes qui analysent les applications, les téléchargements, les extensions et le contenu des navigateurs Web installés par les utilisateurs pour déterminer s'ils sont adaptés aux appareils de l'entreprise.

La connexion au LAN de l'entreprise ne représente pas notre mécanisme principal pour accorder des privilèges d'accès. À la place, nous utilisons la sécurité zéro confiance pour protéger les accès des employés à nos ressources. Les contrôles de gestion des accès au niveau de l'application exposent les applications internes aux employés uniquement lorsque ceux-ci utilisent un appareil géré et qu'ils se connectent à partir de réseaux et d'emplacements géographiques attendus. Un appareil client est approuvé en fonction d'un certificat émis à l'ordinateur individuel et basé sur des assertions concernant sa configuration (telles qu'un logiciel à jour). Pour plus d'informations, consultez BeyondCorp.

Réduction des risques internes

Les risques internes désignent la possibilité pour un employé, un prestataire ou un partenaire actuel ou ancien qui dispose ou a disposé d'un accès à notre réseau, à notre système ou à nos données, d'utiliser cet accès afin de compromettre la confidentialité, l'intégrité ou la disponibilité de nos données ou de nos systèmes d'information.

Pour réduire les risques internes, nous limitons et surveillons activement les activités des employés qui bénéficient d'un accès administrateur à l'infrastructure. Nous nous efforçons continuellement d'éliminer le besoin d'accès privilégié pour des tâches particulières en utilisant l'automatisation afin d'accomplir les mêmes tâches de manière sûre et contrôlée. Nous exposons des API limitées qui permettent le débogage sans exposer les données sensibles, et nous exigeons des approbations à deux parties pour certaines actions sensibles effectuées par des opérateurs humains.

L'accès des employés Google aux informations sur les utilisateurs finaux peut être enregistré via des crochets d'infrastructure de bas niveau. Notre équipe de sécurité surveille les modèles d'accès et examine les événements inhabituels. Pour en savoir plus, consultez la page Gestion des accès privilégiés dans Google Cloud (PDF).

Nous utilisons l'autorisation binaire pour Borg afin de protéger notre chaîne d'approvisionnement contre les risques internes. De plus, notre investissement dans BeyondProd permet de protéger les données utilisateur dans l'infrastructure Google et d'établir une relation de confiance avec nos services.

Dans Google Cloud, vous pouvez surveiller l'accès à vos données à l'aide d'Access Transparency. Les journaux Access Transparency vous permettent de vérifier que le personnel de Google n'accède à votre contenu que pour des raisons professionnelles valables, telles que la résolution d'une panne ou le traitement de vos demandes d'assistance. Access Approval vous garantit que Cloud Customer Care et les services d'ingénierie ne puissent accéder à vos données qu'avec votre approbation explicite. L'approbation est validée de manière cryptographique afin d'en garantir l'intégrité.

Surveillance des menaces

Le groupe Threat Analysis de Google surveille les acteurs des menaces et l'évolution de leurs tactiques et techniques. Les objectifs de ce groupe sont d'améliorer la sécurité des produits Google et de partager ces informations au profit de la communauté en ligne.

Pour Google Cloud, vous pouvez utiliser Google Cloud Threat Intelligence pour Chronicle et VirusTotal pour surveiller de nombreux types de logiciels malveillants et y répondre. Google Cloud Threat Intelligence for Chronicle est une équipe de chercheurs de menaces qui exploitent les renseignements sur les menaces pour les utiliser avec Chronicle. VirusTotal est une solution de base de données et de visualisation de logiciels malveillants qui vous permet de mieux comprendre le fonctionnement des logiciels malveillants au sein de votre entreprise.

Pour en savoir plus sur nos activités de surveillance des menaces, consultez le rapport Threat Horizons.

Détection des intrusions

Nous utilisons des pipelines de traitement de données sophistiqués pour intégrer 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.

Étape suivante