Google Cloud Platform : la sécurité du modèle de responsabilités partagées

La technologie digitale a permis l’accélération de l’adoption du cloud par les organisations. Même si cette tendance se confirme, se mettre au cloud ne vient pas sans challenge. Vous êtes (ou songer à être) utilisateur de Google Cloud Platform ? Voici ce que vous devez savoir sur la sécurité du modèle de responsabilité partagée.

Choisir son cloud : la sécurité avant tout

Analyse de données, stockage, backup, hébergement des applications web ou encore virtualisation, on a tous une bonne raison d’utiliser le cloud. Le choix de ce dernier est souvent le résultat d’un processus multi-critères mais la question de la sécurité est centrale :

• L’exfiltration de données privées et sensibles
• Les attaques informatiques de plus en plus sophistiquées
• L’impact des erreurs de configurations
• La gestion d’identités

Lorsque l’on évoque la sécurité du cloud, l’approche est différente que lorsqu’il s’agit d’infrastructures On-Premise (sur site). Le modèle de responsabilités partagées de Google Cloud Platform est alors un bon moyen de différencier la limite entre ce qu’incombe au client consommateur et au fournisseur cloud.

Le cas de Google Cloud Platform

Google Cloud Platform est composé d’une pléthore de services qui peuvent être catégorisés selon les modèles (Iaas, Paas, Saas). Les responsabilités varient en fonction du modèle choisi et le catalogue des services, évolue en permanence. C’est en faisant évoluer les fonctionnalités que Google s’assure de répondre aux besoins et aux exigences de sécurité de chaque client.

De plus, les services Cloud Google bénéficient d’un niveau de protection similaire aux autres services Google (Gmail, Maps…). En optant pour Google Cloud Platform, vous optez donc déjà pour un service avec un haut niveau de sécurité.

Pour convaincre les entreprises d’héberger des workloads sensibles, Google Cloud va au-delà de du modèle de responsabilité partagée. Dans le modèle de destinée partagée (Shared Faith) par exemple, Google est partenaire actif à côté des clients pour assurer leur sécurité.

La responsabilité de Google

Comment Google assure-t-il la sécurité de l’infrastructure technique ?

1 – Sécurité physique :

Sécurité des Premises physiques : l’accès aux datacenter Google est réglementé et hautement contrôlé. Parmi les méthodes de sécurité physique on retrouve : l’identification biométrique, détection des métaux, la vidéo surveillance ou encore la détection d’intrusion.

Conception matérielle et la vérification de la provenance : Google conçoit ses datacenter et les puces personnalisées (y compris les puces de sécurité comme Titan) déployées sur leurs serveurs. Cela permet d’assurer l’authenticité matérielle et d’identifier les périphériques légitimes.

Secure boot et l’identité machine : des signatures cryptographiques sont utilisées au niveau des composantes de bas niveau comme BIOS, bootloader, kernel et les images des systèmes d’exploitation. Ces signatures peuvent être validées à chaque démarrage ou à chaque mise à jour. Chaque machine possède également sa propre identité. Celle-ci est utilisée pour l’authentification des appels APIs entrants et sortants de management. Ces identités peuvent être révoquées suite à des incidents de sécurité. 

2 – Sécurité des services : 

Les services Google sont des applications binaires produites par des développeurs. Un seul service peut tourner sur des milliers de machines à l’aide d’un système d’orchestration Borg multi-tenants mais la confiance n’y est pas présente par défaut (modèle Zero Trust Security)  

Identité Service, intégrité et isolation : Les applications utilisent l’authentification, l’autorisation et une identité cryptographique. Celles-ci permettent un contrôle d’accès plus strict qu’une segmentation réseau classique ou pare-feu vulnérable au spoofing IP. Une isolation et des techniques de sandboxing permettent la protection des services qui tournent sur la même machine, en utilisant des sandboxes basées sur le kernel ou l’isolation des conteneurs avec gVisor.

Gestion d’accès Inter-service : par défaut; la communication n’est autorisée qu’explicitement via un contrôle d’accès configurable au niveau du service. L’infrastructure renforce automatiquement les polices d’accès avec une traçabilité via la journalisation.

Cryptage de communication inter-service : la sécurité de la communication est assurée par un cryptage du trafic RPC ou autre protocole comme HTTP via encapsulation. Ces communications restent confidentielles même en cas de compromis du réseau et assure une isolation de la couche applicative indépendamment de la couche réseau. 

3 – Stockage sécurisé des données

Cryptage des données au repos : une approche multicouche de cryptage est utilisée pour protéger les données au repos avant que celles-ci ne soient écrites sur des supports physiques ( SSD, HDD ..). Après décommission, ces mêmes supports physiques sont nettoyés en suivant un processus multi-étapes avec deux vérifications indépendantes. Les supports qui échouent ces vérifications sont physiquement détruits.

Suppression des données : Toute suppression est d’abord faite par un marquage pour suppression. Cette approche permet la restauration des données en cas de suppression accidentelle humaine ou à cause de bug. Éventuellement, les données sont supprimées après un délai suivant les stratégies qui sont spécifiques à chaque service.

4 – Communication internet sécurisée

L’infrastructure est isolée d’internet dans des zones avec adressage IP privé. Seule une petite partie des machines est directement exposée au trafic extérieur. Une implémentation supplémentaire des moyens de protection comme DoS est aussi ajoutée. 

Service Google Front End (GFE) : un reverse proxy intelligent frontal à tout service Google qui assure la terminaison de la communication TLS avec les certificats correspondants. GFE applique aussi une protection contre les DoS

Protection contre le Déni de Service DoS : le trafic passe par des répartiteurs de charge, ces derniers communiquent les informations sur volume sur le trafic à un service central de DoS. Si une attaque est détectée, le service DoS repousse une configuration au répartiteur de charge pour ignorer ou faire baisser le trafic.

Authentification Utilisateur : une couche de défense supplémentaire peut être mise en place grâce à des challenges additionnels. Il s’agit d’éviter le vol de credentials comme les clés de sécurité Titan ou autre forme d’authentification multi facteurs.

5 – Sécurité opérationnelle 

Développement logiciel : Google renforce l’utilisation de librairies logicielles internes pour éliminer certaines classes de vulnérabilités comme XSS dans les applications Web. Cela vient s’ajouter à des scanners ZEB pour détecter les bugs de sécurité ou des outils d’analyse statique du code.

Protection de code source : les versions courantes et passées de chaque service sont stockées pour audit. Un système Binary Autorisation est renforcé à chaque déploiement pour vérifier l’authenticité des binaires et éviter la modification malicieuse de code.

Réduire le risque d’initié : une approbation multi-partie est nécessaire pour quelques actions privilégiées. Tout accès aux données clients est tracé et les patterns d’accès sont également analysés.

La responsabilité du client

(Liste non exhaustive)

1 – Ressource Manager

Il permet une organisation des ressources de façon hiérarchique. Le but étant de segmenter les ressources et par conséquent définir différents niveaux d’ownership. Il est également possible d’y attacher différents types de politiques et différents niveaux de contrôle d’accès.

La hiérarchie des ressources est constituée comme suit : organisation, dossiers, projets et ressources.

La structure des dossiers dépend de la nature de l’organisation et les types de services déployés. 

• Les dossiers sont utilisés pour regrouper les projets en relation et pour séparer les projets en unités logiques. Ceci permet d’appliquer des politiques communes à l’ensemble de ces projets.
• Les projets sont des conteneurs de ressources : chaque projet hérite des politiques définies au niveau du dossier parent, les APIs sont activées à ce niveau de même que chaque projet est rattaché à un seul Billing Account.

2 – Politiques d’organisation

Ce sont des contraintes à renforcer à tout niveau de la hiérarchie. Les politiques d’organisation peuvent être définies au niveau de l’organisation, des dossiers ou des projets. Une politique d’organisation est automatiquement héritée par les sous ressources de la hiérarchie. Parmi les exemples de politique, on peut citer :

• compute.vmExternalIpAccess : interdit le déploiement des machines virtuelles avec des IP publiques. Cela limite le risque d’exposition involontaire aux tiers non autorisés.

• compute.skipDefaultNetworkCreation : si la valeur de cette contrainte est vraie, la création d’un VPC par défaut peut être ignoré à la création d’un nouveau projet.

3 – Identity and Access management (IAM)

Google Cloud utilise Cloud Identity pour la gestion d’authentification et les accès. La gestion manuelle des différentes identités d’Active Directory de tous les employés peut représenter un challenge considérable. C’est pour cette raison que la fédération des identités entre les différents systèmes d’identité est nécessaire. En effet, cela permet l’automatisation de l’approvisionnement et le maintien d’une synchronisation de cycle de vie de chaque utilisateur sur ces différents systèmes hétérogènes.

• l’outil Google Cloud Directory Sync GCDS permet la synchronisation de la création, suppression, suspension et mise à jour des identités définies dans l’Active Directory. Cette synchronisation est unidirectionnelle vers Cloud Identity. Active Directory reste la source de vérité.

• Single Sign-On (SSO) permet l’authentification des utilisateurs grâce à leurs credentials Active Directory. Google Cloud peut déléguer l’authentification à Active Directory Federation Service parmi d’autres en utilisant le protocole Security Assertion Markup Language (SAML). Ainsi, il est possible d’ajouter plus de politiques définies au niveau Active Directory comme le Multi Factor Authentication (MFA). 

• Utilisateurs et Groupe : Les rôles sont souvent appliqués au niveau groupe et non pas au niveau utilisateurs. En créant des groupes, on rassemble des utilisateurs avec le même rôle. Cela facilite l’application des politiques communes à un ensemble d’utilisateurs. Les rôles peuvent être :
  • Basique : comme les rôles Owner, Editor et Viewer. 
  • Predefined : un accès granulaire pour des services spécifiques..
  • Custom : des rôles pour fournir un accès granulaire suivant une liste bien déterminée de permission.

4 – Gestion du réseau

Le réseau est fondamental pour toute organisation sur Google Cloud car il permet une implémentation sécurisée. 

• Shared VPC :  réduit la complexité du réseau en adoptant une centralisation des politiques réseau, des sous-réseaux, des routes et des pare-feux au niveau du projet hébergeur ( Host Project ). Les ressources qui y sont déployées peuvent communiquer de façon sécurisée via des IP privés internes. Le trafic reste privé.   
• Pare-feu hiérarchique : assure et renforce les règles de sécurité consistantes à travers l’organisation et les dossiers. Cela permet de définir des règles pour un ensemble de projets et afin qu’elles s’appliquent sur des machines virtuelles existantes ou futures.

5 – Key Management System KMS

Il s’agit d’un service managé pour exécuter les opérations et gérer les clés cryptographiques. Les clés peuvent être basées sur le software, sur des modules hardware (HSM) ou des systems externalisés (EKM). Les différents service Google Cloud Platform chiffrent les données par défaut via des clés managés par Google. Une offre de clés d’encryption managées par utilisateur (Customer Manager Encryption Key CMEK) est également disponible pour donner le contrôle aux utilisateurs sur le chiffrage des données au repos.

Les ressources KMS sont :

• Ring : organise les clés dans une localisation géographique bien spécifique.
• Key : appartient à un seul ring, contient une ou plusieurs versions. 
• Version : contient un contenu utilisé pour effectuer des opérations cryptographiques. 

La gestion des droits KMS est effectuée via IAM. Google recommande les étapes suivantes : 

• Éviter l’utilisation des rôles primitives comme Owner ou Editor
• Séparer les rôles administratifs (cloudkms.admin, cloudkms.importer) et les rôles d’usage
• Limiter l’usage du rôle cloudkms.admin aux comptes privilégiés (équipe sécurité, terraform) 
• Pour les cryptographies asymétriques : séparer les rôles qui ont besoin d’un accès à la clé privée (cloudkms.cryptoKeyDecrypter et cloudkms.signer) des autres utilisateurs qui n’en ont pas besoin (cloudkms.publicKeyViewer et cloudkms.signerVerifier). 

6 – Secret manager

C’est un service de stockage des informations sensibles comme les clés APIs, les mots de passes, les certificats et autres données sensibles. Le stockage est géré et accessible centralement avec une traçabilité et une visibilité sur les différentes actions. On distingue deux termes :

• Secret : une ressource nommée contenant une ou plusieurs versions du même secret. On peut gérer les politiques d’accès à ce niveau et définir les règles de réplication pour plus résilience et de disponibilité.
• Version : on pourra définir plusieurs versions du même secret pour contrôler le cycle de vie de ces données.

7 – Cloud Armor

Il s’agit d’un service managé et scalable pour la protection de trafic public exposé via des répartiteurs de charge. C’est un pare-feu applicatif (Web Application Firewall ou WAF) qui assure une protection contre le déni de service distribué DDoS, SQL Injection et autres attaques du top 10 OWASP. Il détecte, atténue et offre une protection adaptative grâce à l’analyse des patterns de trafic (via des modèles prédictifs basés sur le Machine Learning ML).

8 – Cloud Data Loss Prevention

C’est un service managé serverless qui aide à détecter, classifier, protéger et flaguer les données sensibles hébergées (internes ou externes à Google Cloud). Parmi les fonctionnalités : 

• obscurcissement et anonymisation des données sensibles via des méthodes comme le masquage ou la tokenisation 
• inspection et transformation des données structurées et non structurées
• mesure du risque de la ré-identification grâce à des méthodes statistiques comme k-anonymity et i-diversity.

Le produit supporte plusieurs sources de données comme Bigquery, Google Cloud Storage, Datastore ainsi que la possibilité de développer des sources personnalisées.

9 – VPC Service Control

Un service qui supporte la plupart des services Google Cloud. Il agit comme un pare feu en établissant un périmètre virtuel de sécurité autour des services Google. En autorisant ou en interdisant les appels des différents API Google Cloud, cela permet de :

• Mitiger le risque d’exfiltration en isolant les services multi-tenants
• Restreindre l’accès aux données sensibles uniquement aux réseaux autorisés
• Restreindre l’accès aux ressources uniquement aux adresses IP, identités ou les postes de travail de confiance

Pour découvrir tous nos articles de blog, rendez-vous ici.