Cloud sans internet : ce que signifie opérer Google Distributed Cloud air-gapped

Un cloud qui ne se connecte pas à internet change les règles de tout ce que nous tenons pour acquis. Les correctifs ne descendent pas par le réseau : ils arrivent sur un support physique après un passage par l'antimalware. Les ingénieurs de Google ne se connectent pas pour regarder l'environnement du client, parce qu'ils n'ont même pas accès à son organisation. Le matériel arrive avec des certificats d'origine et du personnel habilité. Google Distributed Cloud air-gapped est le cloud privé clé en main de Google pour les environnements classifiés et déconnectés, et le cours L300 de Google Skills le parcourt de bout en bout. Ce post suit ce parcours en se demandant, à chaque couche, ce qui change quand il n'y a pas d'internet.

Le matériel arrive fermé

Hardware 3.0 repose sur trois principes : infrastructure de pointe, flexibilité de croissance et chaîne d'approvisionnement sécurisée avec des OEM comme HPE, Nvidia, Cisco, NetApp et Palo Alto, personnel habilité, certificats d'origine et traçage GPS. La configuration minimale est trois racks de base, un pour le stockage objet, un pour le fichier et le bloc et un pour le calcul, plus le rack OIR, exclusivement dédié aux opérations et qui ne charge aucune charge client. L'intégration se fait en trois centres : les Amériques, APAC à Singapour et EMEA en République tchèque.

Sur le réseau physique, le fabric est spine-leaf à deux tiers, non bloquant, avec 51,2 Tb/s de bande passante totale, double commutateur ToR par rack et jusqu'à 31 racks. L'environnement opérant sans internet, la connectivité externe est fournie par l'organisation ou son partenaire, avec GDC Interconnect comme service géré : réservations de capacité par incréments de 10, 100 ou 400 Gbps, avec deux patrons. Dans le partagé, plusieurs organisations se connectent à un réseau externe partagé, avec des IP externes uniques et un BGP géré par l'Infrastructure Operator ; dans le dédié, chaque organisation a son propre réseau externe, les IP peuvent se chevaucher et le BGP est mené par le Platform Administrator.

Partager le câble sans partager rien

Plusieurs organisations partagent le même réseau physique, et l'isolation se fait en couches : VRF avec tables de routage et de transfert isolées par organisation ; chaque organisation avec son propre IDPS que tout le trafic traverse ; overlays GENEVE pour le trafic entre charges de travail d'un VPC et VXLAN entre nœuds d'une même organisation ; et IPsec en option entre nœuds contre les attaques man-in-the-middle nées dans l'infrastructure réseau. À cela s'ajoute DNSSEC recommandé sur toute la hiérarchie.

Le réseau virtuel suit la hiérarchie organisation → VPC par défaut → projets, et son comportement par défaut en dit long sur la conception : les projets d'une organisation ne communiquent pas entre eux, les ressources d'un même projet oui, tout le trafic sortant est autorisé et tout le trafic entrant est refusé. Pour que deux projets parlent bidirectionnellement, les deux propriétaires doivent configurer leur côté, une « handshake » qui exige une configuration dans les deux sens. Il y a aussi les load balancers L3/L4, les règles de pare-feu par projet, le VPN IPSec par organisation, la protection contre l'exfiltration qui met le trafic sortant en pause s'il est désactivé, et les VPC Flow Logs basés sur Hubble.

Par-dessus cela se montent les conteneurs et les projets. GKE Enterprise apporte la gestion du cycle de vie multi-cluster, les node pools, le node fencing pour l'auto-réparation et les sauvegardes programmées, avec le CNI Cilium et MetalLB. Et le point de conception qui mérite d'être souligné : projets et clusters entretiennent une relation many-to-many. Un projet s'étend sur plusieurs clusters et un cluster reçoit plusieurs projets, ce qui évite le cluster sprawl, parce que donner un cluster à chaque développeur lui offre l'accès cluster-admin et la liberté d'installer des logiciels non approuvés. Les projets GDC sont des conteneurs de ressources et de politiques comme dans Google Cloud, mais moins rigides : ils représentent des choses qui vont ensemble et obéissent au même ensemble de politiques, pas des équipes. Supprimer le projet supprime ses VM, sauvegardes, pods et politiques IAM.

Les personnes du déploiement

flowchart LR
    D0[Jour 0 : conception<br/>6–9 mois avant<br/>Google + retours du client] --> D1[Jour 1 : livraison<br/>validation du matériel,<br/>installation, formation]
    D1 --> D2[Jour 2 : opérations<br/>client ou partenaire opérateur]
    D2 --> IO[Infrastructure Operator<br/>personne unique, sans accès<br/>à l'environnement du client]

Le cycle de vie a trois phases. Le jour 0 est la conception, entre 6 et 9 mois avant la livraison, avec l'architecture cible approuvée et les plans d'opérations et de staffing en place. Le jour 1 est la livraison : la commande de matériel arrive au centre de données, elle est validée, le logiciel est installé, avec quatre semaines de formation et environ dix semaines de déploiement initial où le personnel du client fait du shadowing. Le jour 2 sont les opérations, et là le client ou son partenaire opérateur prend le volant avec les manuels et runbooks que livre Google.

Au centre de ce modèle il y a une figure qui n'existe pas dans les clouds publics : l'Infrastructure Operator, la personne unique de GDC. Il gère toute l'infrastructure et fait des tâches qui vont au-delà des permissions du Platform Administrator et de l'Application Operator, mais il n'a pas accès à l'organisation du client : il maintient la segmentation et la séparation de l'environnement du client tout en offrant une ligne de support. Qui l'incarne dépend du modèle de livraison, Google-managed ou partner-managed, et le second devrait être le prédominant.

La Operations Suite est son espace de travail : ServiceNow pour les tickets et workflows configurés pour NIST 800-53, GitLab comme infrastructure as code avec approbation multiparte obligatoire, où les privilèges par défaut de l'opérateur sont en lecture seule et toute escalade passe par une revue de seconde partie, plus Grafana et Prometheus, et un rack core avec la stack de Microsoft en bring-your-own-license du partenaire. Le support tourne à trois niveaux : frontline, la backline du partenaire et le niveau 3 via Google Cloud Support.

Multi-zone : trois pour qu'un témoin soit nécessaire

Multi-zone améliore la résilience des charges critiques sans augmenter le débit intrinsèque par zone. La zone est la plus petite unité, avec au moins 10 km de séparation pour qualifier comme disaster domain dans la plupart des normes ; la région regroupe des zones avec jusqu'à 100 km de fibre sur le chemin le plus long pour admettre la réplication synchrone ; l'univers est l'ensemble de zones qui partagent un contrôle plane, de une à six. La règle opérationnelle est la plus mémorable : avec trois zones ou plus il y a récupération automatique, parce qu'il y a un témoin qui permet d'identifier où est le problème ; avec deux ou moins, l'opérateur doit la déclencher à la main. Et la configuration idéale recommandée est de six zones sur deux régions de trois, parce que la connexion inter-région est la plus vulnérable.

La sécurité comme couche, pas comme patch

Le modèle de menaces a trois fronts : chaîne d'approvisionnement, avec du matériel malveillant en fabrication ou du code injecté dans des bibliothèques et des mises à jour ; menace interne, avec employés, sous-traitants et opérateurs ayant accès root ; et accès non autorisé, y compris le « client du client ». Les deux philosophies de conception sont defense in depth et zero trust, et les couvertures vont de l'installation au matériel, à l'hôte, au réseau, aux données et aux fonctions de support.

Côté logiciel, le SDLC sécurisé suit le cadre SLSA : contrôle de version sécurisé, revue et approbation par seconde personne sur tout changement, builds automatisés et hermétiques, images scannées et signées, et SBOM avec changelog par release. Les vérifications S3C ont trois catégories : source, build et runtime. En cryptographie, tout le chiffrement au repos admet des clés gérées par le client via KMS avec crypto shredding, avec des clés soutenues par des HSM et des disques auto-chiffrés qui ajoutent une seconde couche ; en transit, TLS 1.2 et IPsec conformes à FIPS 140-2. Et chaque organisation a ses clés dans son propre namespace HSM, sans chemin vers celui d'une autre.

Les opérations de sécurité travaillent sur le plan administratif avec Splunk comme SIEM, Trellix HX comme EDR, Tenable pour les vulnérabilités et ServiceNow comme SOAR, avec Grafana comme source autoritative des logs immuables et le SOC de Mandiant opérant 24/7. Le modèle de responsabilité partagée a un bord clair : SecOps ne voit pas les charges du client ; le client défend ses données, ses charges et ses applications.

Des données et des mises à jour qui voyagent en physique

Database Service apporte PostgreSQL, Oracle en bring-your-own-license et AlloyDB Omni sur la même plateforme, avec une haute disponibilité self-healing (une sonde de santé toutes les quelques secondes relève une nouvelle instance si quelque chose tombe), des snapshots vers l'object store et une récupération ponctuelle. L'argument contre l'auto-gestion des bases sur VM est économique : le calcul du TCO omet généralement les coûts les plus élevés de l'auto-gestion. Le stockage se répartit en cinq piliers (bloc, objet, fichier, transfert de données et protection des données), avec le bloc qui démarre à 768 TiB par incréments de 256 TiB et l'objet à 879 TiB, chiffrement en couches, et snapshots locaux, une fonction qui n'existe pas dans le cloud public.

Les upgrades sont là où l'air-gapped se voit le plus distinct. Un release se construit avec les vérifications S3C et des compatibility checks, se téléverse vers un bucket, puis l'Operating Entity le télécharge avec une machine connectée à internet, exécute l'antimalware et le checksum, et le transfère avec un dispositif physique sécurisé vers le domaine secure, où le artifact management system et l'upgrade controller le déploient.

flowchart TD
    U1[1. Infrastructure<br/>déclenchée par l'IO] --> U2[2. Organisation<br/>fenêtre fixée par le PA]
    U2 --> U3[3. Clusters et services utilisateur<br/>self-service, sans fenêtre]
    U3 -->|Sans sauter de niveau| V[Version appliquée]

L'ordre des trois niveaux est obligatoire : d'abord l'infrastructure, déclenchée par l'Infrastructure Operator sur des plages horaires pré-annoncées ; ensuite l'organisation, dans la fenêtre de maintenance fixée par le Platform Administrator ; et enfin les clusters et instances de service utilisateur, en self-service. L'utilisateur final ne saute pas de niveaux. Le versionnement est sémantique, avec des correctifs mensuels de sécurité et des hotfixes hors bande, et les sauts de version ne sont permis qu'entre correctifs. Si un échoue, la récupération ne se déclenche jamais toute seule : il faut l'initier explicitement et elle restaure la version précédente ou le dernier point de contrôle qualifié. Et Google n'impose jamais de upgrades ; il envoie des avis jusqu'à la fin du support.

Ce que le design enseigne et ce qui est daté

Au-delà du catalogue, la conception air-gapped enseigne une répartition de la confiance assez explicite : la plateforme suppose que le réseau est compromis (segmentation en couches, default deny), que la chaîne d'approvisionnement est une cible (SLSA, signatures, transfert physique) et que l'opération sera faite par des personnes concrètes (personne unique, approbation multiparte, two-person rule). Chaque mécanisme répond à une menace nommée, pas à une checklist générique.

Ce qui doit se prendre avec une date : le cours est daté 2024 et plusieurs capacités arrivent en roadmap avec un horizon 2025, comme le GA de multi-zona au premier semestre 2025, File Storage dans ce même semestre, la réplication synchrone ou les auto-upgrades des clusters utilisateur ; il vaut revalider les délais contre la documentation officielle. Et les quinze comprobations de connaissances ne se sont pas ouvertes, donc aucune affirmation sur leurs réponses.

*Source : « L300 Google Distributed Cloud air-gapped », de Google Skills.*