Ce document fournit des informations détaillées sur le chiffrement en transit de Google Distributed Cloud (GDC) sous air gap.
Résumé à l'intention des responsables informatiques
- GDC met en œuvre plusieurs mesures de sécurité afin de garantir l'authenticité, l'intégrité et la confidentialité des données en transit.
- Selon le type de connexion, GDC applique des protections par défaut aux données en transit pour les composants GDC. Par exemple, nous sécurisons les communications entre l'utilisateur et la passerelle d'entrée GDC Cloud Service Mesh à l'aide de TLS.
Introduction
La sécurité est souvent un facteur déterminant lors du choix d'un fournisseur de services cloud. Chez Google, il s'agit d'un facteur de la plus haute importance. Nous travaillons sans relâche pour protéger vos données, qu'elles passent sur votre réseau, circulent au sein de l'infrastructure de Google ou soient stockées sur nos serveurs.
L'authentification, l'intégrité et le chiffrement sont des éléments centraux de la stratégie de sécurité de Google, tant pour les données au repos que pour celles en transit. Ce document décrit notre approche du chiffrement en transit pour Google Distributed Cloud air-gapped (GDC).
Pour les données au repos, consultez Chiffrement au repos. Pour obtenir une vision globale de la sécurité chez Google, consultez la page Présentation de la sécurité sur l'infrastructure de Google.
Audience : ce document est destiné aux RSSI et aux équipes chargées des opérations de sécurité qui utilisent ou envisagent d'utiliser GDC.
Conditions préalables : en plus de cette présentation, nous partons du principe que vous possédez des connaissances de base en chiffrement et en primitives cryptographiques.
Authentification, intégrité et chiffrement
GDC met en œuvre plusieurs mesures de sécurité afin de garantir l'authenticité, l'intégrité et la confidentialité des données en transit.
- Authentification : nous authentifions la destination des données au niveau de la couche réseau. La source est authentifiée par l'AIS géré par GDC.
- Intégrité : nous nous assurons que les données que vous envoyez parviennent à destination sans subir la moindre altération, c'est-à-dire qu'elles sont protégées contre toute modification non autorisée.
- Chiffrement : nous rendons vos données illisibles pendant leur transit, afin qu'elles restent confidentielles. Le chiffrement est le processus qui permet de transformer des données lisibles (texte brut) en données illisibles (texte chiffré). Ainsi, le texte brut n'est accessible qu'aux parties autorisées par le propriétaire des données. Les algorithmes utilisés dans le processus de chiffrement sont publics, mais la clé requise pour déchiffrer le texte chiffré est privée. Le chiffrement en transit exploite souvent l'échange de clés asymétriques (tel que l'échange de clés Diffie-Hellman basé sur les courbes elliptiques) pour établir une clé symétrique partagée servant à chiffrer des données. Pour en savoir plus sur le chiffrement, consultez l'article Introduction to Modern Cryptography.
Le chiffrement permet de protéger les données dans plusieurs états :
- Le chiffrement au repos chiffre les données stockées pour les protéger contre tout piratage du système ou exfiltration de données. La norme AES (Advanced Encryption Standard) est souvent utilisée pour chiffrer les données au repos.
- Le chiffrement en transit permet de protéger vos données si les communications sont interceptées au moment où ces données se déplacent entre votre site et le fournisseur cloud, ou entre deux services. Cette protection est obtenue en chiffrant les données avant la transmission, en authentifiant des points de terminaison et, à l'arrivée, en déchiffrant et vérifiant que les données n'ont pas été modifiées. Par exemple, le protocole TLS (Transport Layer Security) est souvent employé pour chiffrer des données en transit afin d'assurer la sécurité des échanges, tandis que la norme S/MIME (Secure/Multipurpose Internet Mail Extensions) est généralement utilisée pour chiffrer des e-mails.
Le chiffrement s'inscrit dans une stratégie de sécurité plus large. Une fois une connexion établie et authentifiée, le chiffrement en transit protège vos données contre des pirates potentiels en :
- supprimant la nécessité d'approuver les couches inférieures du réseau, qui sont généralement fournies par des tiers ;
- réduisant la surface d'attaque potentielle ;
- empêchant les pirates d'accéder aux données lorsque des communications sont interceptées.
Avec un niveau adéquat d'authentification, d'intégrité et de chiffrement, les données qui transitent entre plusieurs utilisateurs, appareils ou processus peuvent être protégées dans un environnement hostile. Le reste de ce document explique l'approche de GDC concernant le chiffrement des données en transit et décrit dans quels cas il est appliqué.
Infrastructure réseau GDC
Limites physiques
Une limite physique est une barrière qui ceint un espace physique contrôlé par ou en coordination avec Google, dans lequel nous pouvons vérifier que des mesures de sécurité rigoureuses sont en place. L'accès physique à ces emplacements est restreint, fortement surveillé et audité. Seul un petit groupe de personnel autorisé a accès au matériel. Les données en transit dans ce périmètre physique sont généralement authentifiées et chiffrées.
Pour les communications qui entrent dans les limites physiques du GDC ou en sortent, nous utilisons une authentification et un chiffrement renforcés pour protéger les données en transit.
Routage du trafic
Pour comprendre le fonctionnement du chiffrement en transit dans GDC, il est nécessaire d'expliquer comment le trafic est acheminé vers et dans GDC. Cette section décrit la manière dont les requêtes parviennent d'un utilisateur final à l'application du client ou au service GDC concerné, et la façon dont le trafic est acheminé entre plusieurs services multisites.
Un service géré par GDC est un service de cloud privé modulaire. Ces services incluent le calcul, le stockage et le machine learning. Par exemple, le stockage d'objets GDC est un service géré par GDC. Une application de client est une application hébergée sur GDC que vous pouvez, en tant que client GDC, créer et déployer à l'aide des services GDC. Les applications de clients ou les solutions partenaires hébergées sur GDC ne sont pas considérées comme des services gérés par GDC. Par exemple, une application que vous créez à l'aide de VM GDC, du service de base de données et de Vertex AI est une application client.
La figure 1 montre différents types de requêtes de routage. La figure 1 montre les interactions entre les différents composants réseau et la sécurité appliquée pour chaque connexion.
Figure 1 : Infrastructure de connectivité multisite
Routage du trafic entre un utilisateur final (réseau client) et l'API GDC et le service géré
Pour les services gérés hébergés sur les passerelles d'entrée Cloud Service Mesh, ils acceptent les requêtes du réseau client à l'aide de la passerelle d'entrée Cloud Service Mesh. La passerelle d'entrée Cloud Service Mesh sert de proxy pour le trafic HTTP(S) entrant, et achemine et équilibre la charge du trafic vers les services gérés par GDC. Une autre couche de pare-feu fournit des contre-mesures contre les attaques DDoS avec détection et prévention des intrusions. Cette connexion est authentifiée et chiffrée depuis la passerelle d'entrée Cloud Service Mesh jusqu'à l'interface du service géré par GDC. La figure 1 illustre cette interaction (connexion A).
La plupart des API et des services gérés GDC sont hébergés sur des passerelles d'entrée Cloud Service Mesh. Toutefois, certains services sont hébergés directement sur l'équilibreur de charge de couche 4 géré par GDC. Par exemple, les bases de données DBS sont hébergées sur un équilibreur de charge externe GDC. Ces services sont configurés pour authentifier et chiffrer les connexions au niveau de la couche application à l'aide de TLS. La figure 1 illustre cette interaction (connexion B).
Routage du trafic entre un utilisateur final (réseau client) et une application client hébergée sur GDC
Il existe plusieurs façons d'acheminer le trafic du réseau client vers une application client hébergée sur GDC. La manière dont votre trafic est acheminé dépend de votre configuration.
Exposer les applications client via la passerelle d'API client
GDC permet d'exposer les applications client via la passerelle d'API client. Le service API Gateway client permet aux utilisateurs de développer, déployer, sécuriser, gérer et faire évoluer l'API selon leurs besoins. La figure 1 illustre cette interaction (connexion C).
Exposer les charges de travail client conteneurisées via l'équilibreur de charge externe du client
GDC permet d'exposer les charges de travail conteneurisées gérées par le client via un équilibreur de charge externe. GDC permet de configurer des règles d'entrée et de sortie pour le personnel concerné. La figure 1 illustre cette interaction (connexion E).
Exposer les charges de travail des machines virtuelles
GDC permet d'exposer les machines virtuelles créées par les clients aux utilisateurs finaux. GDC permet de configurer des règles d'entrée et de sortie pour le personnel concerné. La figure 1 illustre cette interaction (connexion F).
Service d'interconnexion intersites GDC
Le routage d'un service géré à un autre s'effectue généralement entièrement dans les limites physiques du GDC. Dans certains cas, comme la sauvegarde multisite, les données sont acheminées en dehors des limites physiques du GDC. Dans ce cas, les données sont chiffrées au niveau de la couche application (par exemple, TLS) et peuvent également l'être au niveau de la couche réseau. La figure 1 illustre cette interaction (connexion G).
Routage du trafic entre plusieurs machines virtuelles
Les connexions de VM à VM au sein de GDC ne sont pas chiffrées au niveau du réseau. Les clients sont responsables du chiffrement des données à l'aide de protocoles chiffrés appropriés ou de technologies spécifiques telles que les tunnels IPsec.
Chiffrement en transit par défaut
GDC emploie diverses méthodes de chiffrement par défaut et configurables par l'utilisateur pour les données en transit. Le type de chiffrement utilisé dépend de la couche OSI, du type de service et du composant physique de l'infrastructure. Cette section décrit les protections par défaut que Google utilise pour protéger les données en transit.
Le reste de cette section décrit les protections par défaut qui permettent à Google de protéger les données en transit.
Chiffrement du trafic entre les utilisateurs et la passerelle d'entrée Cloud Service Mesh
À l'heure actuelle, de nombreux systèmes exploitent le protocole HTTPS pour communiquer sur Internet. Il offre un haut niveau de sécurité grâce à l'utilisation d'une connexion TLS, qui garantit l'authenticité, l'intégrité et la confidentialité des requêtes et des réponses. Avant d'accepter des requêtes HTTPS, le destinataire demande une paire de clés publiques/privées et un certificat X.509 pour authentifier le serveur auprès d'une autorité de certification (CA). La paire de clés et le certificat aident à authentifier les requêtes d'un utilisateur au niveau de la couche d'application (couche 7) en prouvant que le destinataire possède bien le nom de domaine auquel les requêtes sont adressées. Les sous-sections suivantes abordent les composants du chiffrement entre les utilisateurs et la passerelle d'entrée Cloud Service Mesh : TLS, BoringSSL et l'autorité de certification configurable GDC.
Transport Layer Security (TLS)
Lorsque vous envoyez une requête à un service GDC, nous sécurisons les données en transit en fournissant l'authentification, l'intégrité et le chiffrement grâce au protocole HTTPS, à l'aide d'un certificat émis par une autorité de certification de confiance. Toutes les données que l'utilisateur envoie à la passerelle d'entrée Cloud Service Mesh pour le service géré par GDC sont chiffrées en transit avec le protocole TLS (Transport Layer Security). La passerelle d'entrée Cloud Service Mesh négocie un protocole de chiffrement spécifique avec le client en fonction des protocoles qu'il accepte. La passerelle d'entrée GDC Cloud Service Mesh n'applique que les algorithmes approuvés par la norme FIPS pour renforcer la sécurité.
BoringSSL
Gérée par Google et dérivée d'OpenSSL, BoringSSL est une mise en œuvre Open Source du protocole TLS qui est principalement compatible avec l'interface OpenSSL. Google a créé BoringSSL à partir d'OpenSSL afin de simplifier l'utilisation d'OpenSSL en interne et d'offrir une meilleure compatibilité avec les projets Open Source Chromium et Android. BoringCrypto, le module au cœur de BoringSSL, a obtenu le niveau 1 de la certification FIPS 140-2.
TLS dans la passerelle d'entrée Cloud Service Mesh est implémenté avec BoringSSL. Le tableau 1 présente les protocoles de chiffrement compatibles avec GDC lors de la communication avec les clients.
| Protocoles | Authentification | Échange de clés | Chiffrement | Fonction de hachage |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
Tableau 1 : Chiffrement mis en œuvre dans la passerelle d'entrée Cloud Service Mesh pour les services GDC et dans la bibliothèque de cryptographie BoringSSL
Autorité de certification configurable GDC
Le protocole TLS exige qu'un serveur prouve son identité à l'utilisateur lorsqu'il reçoit une requête de connexion. Cette validation d'identité est effectuée par le protocole TLS, qui demande au serveur de présenter un certificat contenant son identité déclarée. Le certificat comporte à la fois le nom d'hôte DNS du serveur et sa clé publique. Une fois présenté, il est signé par une autorité de certification (CA) émettrice, approuvée par l'utilisateur qui demande à se connecter. Ainsi, les utilisateurs qui demandent à se connecter au serveur ont seulement besoin d'approuver l'autorité de certification racine. Si un serveur doit être accessible par des utilisateurs où qu'ils se trouvent, l'autorité de certification racine doit être connue de tout appareil client potentiel. Les navigateurs et appareils clients sont configurés avec un ensemble d'AC racines auxquelles ils font confiance, en fonction de l'environnement dans lequel le client fonctionne.
L'autorité de certification racine pour GDC dépend de l'environnement dans lequel elle est déployée et des exigences des clients dans cet environnement.
Passerelle d'entrée Cloud Service Mesh vers les frontaux d'application
Deux cas de figure :
- La passerelle d'entrée Cloud Service Mesh met fin au protocole TLS et rechiffre le protocole mTLS à l'aide des certificats Istio Cloud Service Mesh.
- mTLS de la passerelle d'entrée au frontend de l'application side-car Istio
- La passerelle d'entrée Cloud Service Mesh interrompt le protocole TLS, puis le chiffre à nouveau pour un autre serveur, avec l'autorité de certification configurée.
Chiffrement du trafic de stockage sur le réseau
Dans le système de stockage de fichiers et de blocs GDC, le trafic est acheminé entre l'application utilisant le stockage et le service de stockage. Ces données sont authentifiées et chiffrées en transit à l'aide d'IPSec. Le chiffrement côté client pour le trafic de stockage sera bientôt disponible. Le mode Transport IPSec est utilisé entre le trafic de fichiers et de blocs vers l'hôte qui doit accéder au stockage. L'authentification s'effectue à l'aide d'une clé pré-partagée générée à la volée et stockée de manière sécurisée dans GDC. Une fois les SA IPSec établies, les informations sont échangées à l'aide du tunnel IPSec. Les paquets sont chiffrés et déchiffrés à l'aide du chiffrement conforme à la norme FIPS spécifié dans l'association de sécurité IPsec.
Authentification, intégrité et chiffrement entre plusieurs services
Au niveau de la couche d'application (couche 7) de l'infrastructure GDC, nous utilisons mTLS ou TLS pour l'authentification, l'intégrité et le chiffrement des appels RPC depuis la passerelle d'entrée Cloud Service Mesh vers un service et d'un service GDC vers un autre service GDC. Chaque service exécuté dans GDC agit en tant qu'identité de compte de service dotée d'identifiants cryptographiques associés. Lorsqu'ils communiquent via mTLS avec Cloud Service Mesh, les services GDC utilisent des certificats client pour s'authentifier auprès d'autres services. Cloud Service Mesh vérifie ces certificats à l'aide d'une autorité de certification interne. Lorsqu'ils communiquent via TLS, par exemple avec un serveur d'API Kubernetes GDC, les services GDC utilisent des jetons de compte de service Kubernetes pour s'authentifier auprès des services. Les jetons de compte de service Kubernetes sont validés à l'aide des clés publiques de l'émetteur de jetons du serveur d'API Kubernetes.