Ce document fournit des informations sur le chiffrement en transit de Google Distributed Cloud (GDC) air-gapped.
Résumé à l'intention des responsables informatiques
- GDC met en œuvre plusieurs mesures de sécurité pour assurer l'authenticité, l'intégrité et la confidentialité des données en transit.
- Selon la connexion établie, 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 Cloud Service Mesh de GDC à l'aide de TLS.
Introduction
La sécurité est souvent un facteur décisif dans le choix d'un fournisseur de services cloud. Chez Google, il s'agit d'un facteur de la plus haute importance. Nous mettons tout en œuvre pour protéger vos données, qu'elles transitent sur votre réseau, qu'elles circulent au sein de l'infrastructure de Google ou qu'elles soient stockées sur nos serveurs.
La stratégie de sécurité de Google repose sur l'authentification, l'intégrité et le chiffrement, tant pour les données au repos que pour les données en transit. Ce document décrit notre approche du chiffrement en transit pour Google Distributed Cloud sous air gap (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 de gérer les 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é pour assurer 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 les modifications non autorisées.
- 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 utilise souvent l'échange de clés asymétriques, tel que l'échange de clés Diffie-Hellman basé sur une courbe elliptique, pour établir une clé symétrique partagée utilisée pour le chiffrement des données. Pour en savoir plus sur le chiffrement, consultez l'article Introduction à la cryptographie moderne.
Le chiffrement peut être utilisé pour protéger les données dans plusieurs états :
- Le chiffrement au repos chiffre les données stockées pour les protéger contre tout éventuel piratage du système ou exfiltration de données. La norme AES (Advanced Encryption Standard) est souvent utilisée pour le chiffrement des 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 de services 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. Le chiffrement en transit protège vos données contre les pirates informatiques potentiels, une fois la connexion établie et authentifiée, en :
- Éliminer la nécessité de faire confiance aux 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 une authentification, une intégrité et un chiffrement adéquats, les données qui transitent entre les utilisateurs, les appareils ou les 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 les cas où il est appliqué.
Infrastructure réseau GDC
Limites physiques
Une limite physique est une barrière qui ceint un espace physique contrôlé par Google 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 personnes autorisées 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 ou sortent de la limite physique de GDC, nous utilisons une authentification et un chiffrement forts 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 via GDC. Cette section décrit comment les requêtes sont transmises d'un utilisateur final au service GDC ou à l'application client appropriés, et comment le trafic est acheminé entre les services intersites.
Un service géré par GDC est un service 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 présente différents types de requêtes de routage. La figure 1 illustre les interactions entre les différents composants réseau et la sécurité en place pour chaque connexion.
Figure 1 : Infrastructure de connectivité intersites
Utilisateur final (réseau client) vers l'API GDC et le service géré
Les services gérés hébergés sur des passerelles d'entrée Cloud Service Mesh acceptent les requêtes provenant du réseau du client à l'aide de la passerelle d'entrée Cloud Service Mesh. La passerelle d'entrée Cloud Service Mesh gère le proxy du trafic HTTP(S) entrant, et gère le routage et l'équilibrage de charge du trafic vers les services gérés par GDC eux-mêmes. 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 de la passerelle d'entrée Cloud Service Mesh au frontend 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. Cependant, 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 d'application à l'aide du protocole 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. Cette manière dépend de votre configuration.
Exposer les applications client via API Gateway client
GDC permet d'exposer les applications client via l'API Gateway du client. Le service API Gateway du 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 un équilibreur de charge externe 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 au personnel concerné de configurer des règles d'entrée et de sortie. La figure 1 illustre cette interaction (connexion E).
Exposer des charges de travail de machine virtuelle
GDC permet d'exposer les machines virtuelles créées par le client aux utilisateurs finaux. GDC permet de configurer des règles d'entrée et de sortie pour le personnel correspondant. 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 de GDC. Dans certains cas, comme la sauvegarde intersites, les données sont acheminées en dehors de la limite physique de GDC. Dans ce cas, les données sont chiffrées à la fois au niveau de la couche d'application (par exemple, TLS) et 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 dans 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 utilise différentes 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 utilisées par Google pour protéger les données en transit.
Le reste de cette section décrit les protections par défaut utilisées par Google pour protéger les données en transit.
Chiffrement de l'utilisateur vers la passerelle d'entrée Cloud Service Mesh
À l'heure actuelle, de nombreux systèmes exploitent le protocole HTTPS pour communiquer sur Internet. HTTPS assure la sécurité en utilisant une connexion TLS, qui garantit l'authenticité, l'intégrité et la confidentialité des requêtes et des réponses. Pour accepter les requêtes HTTPS, le récepteur nécessite une paire de clés publique/privée et un certificat X.509 pour l'authentification du serveur auprès d'une autorité de certification (CA). La paire de clés et le certificat permettent d'authentifier les requêtes d'un utilisateur au niveau de la couche d'application (couche 7) en prouvant que le destinataire est propriétaire du nom de domaine auquel les requêtes sont destinées. Les sous-sections suivantes décrivent les composants du chiffrement entre l'utilisateur et la passerelle d'entrée Cloud Service Mesh, à savoir : TLS, BoringSSL et l'autorité de certification configurable GDC.
TLS (Transport Layer Security)
Lorsque vous envoyez une requête à un service GDC, nous sécurisons les données en transit en assurant l'authentification, l'intégrité et le chiffrement, à l'aide du protocole HTTPS avec un certificat d'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 particulier avec le client en fonction de ce que le client peut accepter. La passerelle d'entrée GDC Cloud Service Mesh n'applique que les algorithmes approuvés par la norme FIPS pour offrir une sécurité renforcée.
BoringSSL
BoringSSL est une implémentation Open Source du protocole TLS gérée par Google, dérivée d'OpenSSL, qui est principalement compatible avec l'interface OpenSSL. Google a créé BoringSSL à partir d'OpenSSL pour simplifier OpenSSL, à la fois pour un usage interne et pour mieux prendre en charge les projets Open Source Chromium et Android. BoringCrypto, le cœur de BoringSSL, a été validé au niveau 1 de la norme FIPS 140-2.
Le protocole TLS dans la passerelle d'entrée Cloud Service Mesh est mis en œuvre 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 ainsi que dans la bibliothèque de cryptographie BoringSSL
Autorité de certification configurable de GDC
Dans le cadre du protocole TLS, un serveur doit prouver son identité à l'utilisateur lorsqu'il reçoit une demande de connexion. Cette validation de l'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 le serveur souhaite être accessible partout, l'autorité de certification racine doit être connue de tout appareil client potentiel. Les navigateurs et les appareils clients sont configurés avec un ensemble d'autorités de certification racines auxquelles ils font confiance, en fonction de l'environnement dans lequel le client opère.
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 interfaces 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 à l'interface de l'application side-car Istio
- La passerelle d'entrée Cloud Service Mesh met fin au protocole TLS et rechiffre le protocole TLS vers un autre serveur, avec l'autorité de certification configurée.
Chiffrement réseau du trafic de stockage
Dans le système de stockage de fichiers et de blocs GDC, le trafic est acheminé entre l'application qui utilise 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 de transport IPSec est utilisé entre le trafic de fichiers et de blocs vers l'hôte qui doit accéder au stockage. L'authentification est effectuée par 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 associations de sécurité IPSec établies, les informations sont échangées via le 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
Dans l'infrastructure GDC, au niveau de la couche d'application (couche 7), nous utilisons mTLS ou TLS pour l'authentification, l'intégrité et le chiffrement des appels RPC de 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 s'exécute en tant qu'identité de compte de service avec des identifiants cryptographiques associés. Lorsqu'ils communiquent via mTLS via Cloud Service Mesh, les services GDC utilisent des certificats clients pour s'authentifier auprès d'autres services. Cloud Service Mesh vérifie ces certificats à l'aide d'une autorité de certification interne. Lors de la communication via TLS, par exemple vers 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.