Alphabet a publié un document donnant un aperçu de la façon dont la sécurité est conçue dans l'infrastructure technique de Google. « Cette infrastructure à l'échelle mondiale est conçue pour assurer la sécurité tout au long du cycle de vie du traitement de l'information chez Google. Cette infrastructure assure le déploiement sécurisé des services, le stockage sécurisé des données avec des garanties de confidentialité pour les utilisateurs finaux, des communications sécurisées entre les services, une communication sécurisée et privée avec les clients via Internet et un fonctionnement sécurisé par les administrateurs », a expliqué Alphabet. L’entreprise a précisé qu’elle se sert de cette infrastructure « pour créer ses services Internet, y compris les services grand public tels que Search, Gmail et Photos, ainsi que les services d'entreprise tels que G Suite et Google Cloud Platform ».
Le document révèle que Google s’appuie sur 6 couches de sécurité que sont :
- la sécurité opérationnelle : qui couvre la détection d’intrusion, la réduction de risques internes, la sûreté du développement logiciel ;
- la communication internet : notamment une protection contre les attaques par déni de service et la protection apportée par le service Google Front End ;
- les services de stockage : l’entreprise procède ici au chiffrement lorsque les données sont au repos, mais aussi à l’effacement des données ;
- identité des utilisateurs : Google met à la disposition des utilisateurs une protection contre les abus d’authentification, mais aussi un service d’authentification ;
- le déploiement de service : l’entreprise propose entre autres la gestion de l'accès aux données des utilisateurs finaux, le chiffrement des communications inter service, la gestion d’accès aux communications inter service ;
- les infrastructures matérielles : ici il est question de la sécurité des piles d’amorçage et de l’identité de la machine, mais aussi des locaux physiques.
Infrastructures matérielles
Sécurisation des locaux physiques
Google conçoit et construit ses propres centres de données, qui intègrent plusieurs couches de protections de sécurité physique (utilisation de technologies telles que l'identification biométrique, la détection de métaux, les caméras, les barrières de véhicules et les systèmes de détection d'intrusion au laser). L'accès à ces centres de données est limité à une très faible fraction des employés de Google.
Sécurisation des piles d’amorçage et l'identité de la machine
Les serveurs de Google utilisent une variété de technologies pour s'assurer qu'ils démarrent la pile logicielle correcte. « Nous utilisons des signatures cryptographiques sur des composants de bas niveau comme le BIOS, le bootloader, le noyau et l'image du système d'exploitation de base. Ces signatures peuvent être validées lors de chaque démarrage ou mise à jour » . Concernant chaque nouvelle génération de matériel, Google assure qu’il s’efforce d'améliorer continuellement la sécurité : « par exemple, en fonction de la génération de la conception du serveur, nous renforçons la confiance de la chaîne de démarrage soit dans une puce de microprogramme verrouillable, soit dans un microcontrôleur exécutant un code de sécurité écrit par Google ».
Sécurisation du déploiement de service
Par « service », Google entend un binaire d'application qu'un développeur a écrit et veut exécuter sur son infrastructure, par exemple un serveur SMTP Gmail, un serveur de stockage BigTable, un transcodeur vidéo YouTube ou un sandbox Application Engine exécutant une application client. Ici, l’infrastructure ne suppose pas une quelconque confiance entre les services qui s’exécutent sur elle.
Identité, intégrité et isolement des services
Google se sert de l'authentification cryptographique et l'autorisation au niveau de la couche application pour la communication interservices afin de « fournir un contrôle d'accès solide à un niveau d'abstraction et une granularité que les administrateurs et les services peuvent naturellement comprendre » .
Chaque service qui s'exécute sur l'infrastructure possède une identité de compte de service associé. À chaque service sont attribuées des informations d'identification cryptographiques dont il peut se servir pour prouver son identité lorsqu’il émet ou reçoit des appels de procédure distante (RPC) d'autres services. Ces identités sont utilisées par les clients pour s'assurer qu'ils parlent au bon serveur et par les serveurs pour limiter l'accès aux méthodes et données à des clients particuliers.
Le code source de Google est stocké dans un référentiel central où les versions actuelles et passées du service sont vérifiables. L'infrastructure peut en outre être configurée pour exiger que les binaires d'un service soient construits à partir de code source passé en revu, vérifié et testé, des examens qui nécessitent l'inspection et l'approbation d'au moins un ingénieur autre que l'auteur. Toutefois, le système veille à ce que les modifications de code apportées à tout système soient approuvées par les propriétaires de ce système. Des exigences qui permettent de limiter la capacité d’une entité à apporter des modifications malveillantes au code source.
Gestion des accès interservices
Le propriétaire d'un service peut utiliser les fonctions de gestion d'accès fournies par l'infrastructure pour spécifier exactement quels autres services peuvent communiquer avec le sien. Par exemple, un service peut souhaiter ouvrir 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.
Service et gestion des accès : l'infrastructure fournit l'identité du service, l'authentification mutuelle automatique, la communication interservices chiffrée et l'application des politiques d'accès telles que définies par le propriétaire du service.
Stockage sécurisé de données
Chiffrement au repos
L'infrastructure de Google fournit une variété de services de stockage, tels que BigTable et Spanner, et un service central de gestion de clés. La plupart des applications chez Google accèdent au stockage physique indirectement via ces services de stockage. Les services de stockage peuvent être configurés pour utiliser des clés du service central de gestion des clés pour chiffrer les données avant d'être écrits dans le stockage physique. Ce service de gestion de clés prend en charge la rotation automatique des clés, fournit des journaux d'audit étendus et s'intègre avec les tickets d'autorisation des utilisateurs finaux pour lier les clés à des utilisateurs finaux particuliers.
Suppression des données
Chez Google, la suppression des données commence le plus souvent par le marquage de données spécifiques comme étant "planifiées pour la suppression" plutôt que par la suppression des données proprement dite. Le but est de permettre à ses ingénieurs de récupérer des suppressions non intentionnelles, qu’elles soient initiées par un client ou résultantes d’un bogue ou d’une erreur de processus en interne. Après avoir été marquées comme «programmé pour la suppression», les données sont supprimées conformément aux politiques spécifiques au service.
Communication sécurisée sur Internet
Google Front End Service (GFE)
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) qui veille à ce que toutes les connexions TLS soient terminées en utilisant des certificats corrects et en suivant les meilleures pratiques. Le GFE applique en outre des protections contre les attaques par déni de service et transmet les requêtes du service en utilisant le protocole de sécurité RPC.
Authentification d'utilisateur
Ce service se manifeste généralement aux utilisateurs finaux en tant que page de connexion Google. Au-delà de la simple demande d’un nom d'utilisateur et d'un mot de passe, le service interroge également intelligemment les utilisateurs sur des informations supplémentaires basées sur des facteurs de risque comme savoir s’ils se sont connectés depuis le même périphérique ou depuis un emplacement similaire dans le passé. Après l'authentification de l'utilisateur, le service émet des informations d'identification telles que les cookies et les jetons OAuth qui peuvent être utilisés pour les appels ultérieurs.
Sécurité opérationnelle
Développement logiciel sécurisé
En plus des fonctionnalités de contrôle central et de révision en deux parties, Google fournit des bibliothèques qui empêchent les développeurs d'introduire certaines classes de bogues de sécurité. « Par exemple, nous avons des bibliothèques et des frameworks qui éliminent les vulnérabilités XSS dans les applications Web. Nous avons également des outils automatisés pour détecter automatiquement les bogues de sécurité, y compris les fuzzers, les outils d'analyse statique et les scanners de sécurité Web ».
Réduction des risques d'initiés
Google explique qu’il limite et surveille activement les activités des employés qui ont un accès administratif à l'infrastructure. L’entreprise travaille continuellement à éliminer le besoin d'accès privilégié pour des tâches particulières en fournissant l'automatisation qui peut accomplir les mêmes tâches d'une manière sûre et contrôlée. Ceci inclut l'exigence d'approbations bipartites pour certaines actions et l'introduction d'API limitées qui permettent le débogage sans exposer les informations sensibles.
L'accès des employés Google aux informations de l'utilisateur final peut être enregistré grâce à des crochets d'infrastructure de bas niveau. L'équipe de sécurité de Google surveille activement les modèles d'accès et enquête sur les événements inhabituels.
Source : Google