Ce document fournit des informations sur le chiffrement en transit dans Google Distributed Cloud (GDC) sous air gap.
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.
- En fonction de 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éterminant lors du 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 soient transférées au sein de l'infrastructure de Google ou qu'elles 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 sous air gap (GDC).
Pour les données au repos, consultez la page 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 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 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 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 leur transmission, en authentifiant les points de terminaison, puis en déchiffrant et en vérifiant que les données n'ont pas été modifiées à leur arrivée. 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 la barrière d'un espace physique contrôlé par Google ou en coordination avec Google, où nous pouvons nous assurer que des mesures de sécurité rigoureuses sont en place. L'accès physique à ces emplacements est limité, fortement surveillé et audité. Seul un petit nombre de personnes autorisées ont accès au matériel. Les données en transit dans ces limites physiques 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 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.
Un service géré par GDC est un service cloud privé modulaire. Nous offrons par exemple des services de calcul, de stockage et de machine learning. Ainsi, 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. Ainsi, une application que vous créez à l'aide de VM GDC, de Database Service et de Vertex AI est une application de client.
La figure 1 présente différents types de requêtes de routage. Elle illustre les interactions entre les différents composants réseau et la sécurité en place pour chaque connexion.
Figure 1 : Infrastructure de connectivité intersite
Routage du trafic entre un utilisateur final (réseau client) et une API GDC et un service géré
Pour les services gérés hébergés sur des 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 proxy le trafic entrant HTTP(S), 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'au frontend du service géré par GDC. La figure 1 illustre cette interaction en tant que connexion A.
La plupart des API et des services gérés par GDC sont hébergés sur des passerelles d'entrée Cloud Service Mesh. Cependant, certains services sont hébergés directement sur un é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 de TLS. La figure 1 illustre cette interaction en tant que connexion B.
Routage du trafic entre un utilisateur final (réseau client) et une application de client hébergée sur GDC
Le trafic du réseau client peut être acheminé de plusieurs manières vers une application de client hébergée sur GDC. Le routage de votre trafic dépend de votre configuration.
Exposer les applications de client via la passerelle d'API du client
GDC permet d'exposer les applications client via l'API Gateway client. Le service API Gateway du client permet aux utilisateurs de développer, déployer, sécuriser, gérer et mettre à l'échelle l'API selon leurs besoins. La figure 1 illustre cette interaction en tant que connexion C.
Exposer les charges de travail de 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 en tant que connexion E.
Exposer les charges de travail des machines virtuelles
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 concerné. La figure 1 illustre cette interaction en tant que connexion F.
Service d'interconnexion intersite GDC
Le routage entre plusieurs services gérés s'effectue généralement entièrement dans la limite physique de GDC. Dans certains cas, comme la sauvegarde intersite, 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 peuvent également être chiffrées au niveau de la couche réseau. La figure 1 illustre cette interaction en tant que connexion G.
Machine virtuelle à machine virtuelle
Les connexions entre plusieurs 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 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 entre un utilisateur et une 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 des utilisateurs et une passerelle d'entrée Cloud Service Mesh : TLS, BoringSSL et l'autorité de certification configurable de GDC.
TLS (Transport Layer Security)
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 approuvée. 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 à l'aide du 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 Cloud Service Mesh de GDC n'applique que les algorithmes approuvés par la norme FIPS pour renforcer la sécurité.
BoringSSL
BoringSSL, gérée par Google et dérivée d'OpenSSL, 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 ce dernier à la fois pour un usage interne et pour 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.
Le protocole TLS est mis en œuvre dans la passerelle d'entrée Cloud Service Mesh à l'aide de 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
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'autorités de certification racines qu'ils approuvent, en fonction de l'environnement dans lequel le client fonctionne.
L'autorité de certification racine de 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 frontends d'application
Deux cas de figure :
- La passerelle d'entrée Cloud Service Mesh met fin à TLS et rechiffre mTLS à l'aide des certificats Istio de Cloud Service Mesh.
- mTLS de la passerelle d'entrée vers le frontend d'application Istio Sidecar
- La passerelle d'entrée Cloud Service Mesh met fin à TLS et rechiffre 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 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 la SA IPSec.
Authentification, intégrité et chiffrement entre plusieurs services
Au sein de 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 entre la passerelle d'entrée Cloud Service Mesh et un service, et entre un service GDC et 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 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 vérifiés à l'aide des clés publiques de l'émetteur de jetons du serveur d'API Kubernetes.