Sécurité de l'infrastructure, du réseau et des charges de travail

Google Distributed Cloud (GDC) avec isolation physique permet de protéger les racks matériels, les systèmes d'exploitation hôtes, les limites de l'architecture mutualisée, les chaînes d'approvisionnement logicielles et le trafic réseau déployé dans des centres de données accrédités.

Sécurité des installations

Le matériel GDC est déployé dans des centres de données accrédités que vous contrôlez ou qui sont contrôlés par l'opérateur de votre choix. Votre organisation et l'opérateur d'infrastructure sont responsables de l'application des contrôles d'accès physique, des protections environnementales et des procédures de gestion des supports pour l'installation hébergeant les racks GDC.

Voici quelques-uns des contrôles de sécurité physique recommandés :

• Contrôles d'accès au périmètre et aux racks : restreignez l'accès physique au centre de données et aux racks GDC à l'aide de lecteurs de badges, de l'authentification biométrique, de journaux d'accompagnement des visiteurs, de patrouilles de sécurité 24h/24, 7j/7 et de portes de rack verrouillées.
• Surveillance et détection des accès non autorisés : surveillance des allées de racks avec un système de télévision en circuit fermé (CCTV) continu et des alarmes d'intrusion physique.
• Isolation de l'alimentation, du refroidissement et du câblage : fournissez des alimentations redondantes, une surveillance environnementale et des chemins de câblage protégés qui répondent à vos exigences réglementaires et d'accréditation (telles que ISO/IEC 27001 ou ICD 705).

Sécurité matérielle

GDC s'exécute sur des racks matériels modulaires pré-intégrés fabriqués avec des composants commerciaux prêts à l'emploi (COTS) provenant de fabricants d'équipement d'origine (OEM) approuvés. Des installations régionales certifiées, dotées d'un personnel ayant fait l'objet d'une vérification d'antécédents, intègrent les racks matériels. Les composants matériels et micrologiciels à haut risque font également l'objet d'examens de sécurité dédiés contre les menaces de falsification physique et de la chaîne d'approvisionnement.

Les principaux contrôles de sécurité matérielle sont les suivants :

• Serveurs de calcul : les serveurs Bare Metal utilisent des racines de confiance matérielles, des modules de plate-forme de confiance (TPM 2.0) et un micrologiciel de contrôleur de gestion de la carte mère (BMC) signé pour vérifier l'intégrité du matériel et du démarrage avant de charger le système d'exploitation.
• Commutateurs réseau et pare-feu de périmètre : les commutateurs de gestion et de haut de rack appliquent des contrôles d'accès au niveau des ports et le chiffrement MACsec. Les pare-feu de périmètre redondants fournissent une inspection avec état au débit de ligne et une prévention des intrusions à la limite de la zone.
• Dispositifs de stockage : les dispositifs de stockage d'objets, de fichiers et de blocs d'entreprise appliquent le chiffrement AES-256 au repos avec accélération matérielle sur les disques à chiffrement automatique (SED) et l'isolation logique des locataires via des machines virtuelles de stockage (SVM) dédiées.
• Modules de sécurité matériels (HSM) : des appliances HSM dédiées connectées au réseau (validées FIPS 140-2 de niveau 3 et FIPS 140-3) génèrent, stockent et protègent les clés cryptographiques racine dans du matériel inviolable.

Pour en savoir plus, consultez la documentation suivante :

Sujet	Documentation et guides de configuration
Gestion du matériel et des HSM	Clés HSM de contrôle et Machines de nœud de cluster

Sécurité des hôtes et des nœuds

Chaque hôte Bare Metal et chaque nœud de cluster Kubernetes dans GDC exécute une image de système d'exploitation renforcée, configurée pour minimiser la surface d'attaque et empêcher l'élévation non autorisée des privilèges.

• Système d'exploitation renforcé par STIG : les nœuds exécutent Linux renforcé par rapport aux guides d'implémentation technique de sécurité (STIG) de la Defense Information Systems Agency (DISA) et aux benchmarks du Center for Internet Security (CIS). Les packages, compilateurs et services réseau inutiles sont supprimés de l'image de base.
• Démarrage sécurisé UEFI : les hôtes Bare Metal et les machines virtuelles (VM) utilisateur sont compatibles avec le démarrage sécurisé UEFI pour vérifier que seuls les bootloaders et les images de kernel signés de manière cryptographique s'exécutent au démarrage.
• Contrôles d'accès obligatoires et du noyau : les nœuds appliquent SELinux en mode d'application, le filtrage des appels système seccomp, les espaces de noms Linux et les limites de ressources cgroups pour isoler les conteneurs du noyau hôte sous-jacent.
• Intégrité de l'hôte et protection des points de terminaison : la surveillance de l'intégrité des fichiers (FIM) vérifie les fichiers système critiques pour détecter les modifications non autorisées, et les contrôles de détection et de réponse au niveau des points de terminaison (EDR) et de protection contre les logiciels malveillants surveillent l'exécution des processus et la télémétrie de l'hôte.

Pour en savoir plus, consultez la documentation suivante :

Sujet	Documentation et guides de configuration
Isolation des nœuds et benchmarks	Présentation de l'isolation des nœuds et Benchmark CIS de Kubernetes
Démarrage sécurisé et gestion de l'OS des VM	Démarrer une VM de manière sécurisée et Gérer les packages d'OS

Tenancy

GDC fournit une architecture mutualisée hiérarchique avec une isolation physique et réseau stricte entre les organisations, et une isolation logique des espaces de noms entre les projets d'une organisation.

Isolation logique entre les organisations, les clusters et les projets

Le schéma suivant montre comment le cluster root-admin, les clusters d'infrastructure d'organisation et les clusters de charge de travail sont isolés au niveau des limites de gestion et de locataire :

• Cluster root-admin : dédié au démarrage des organisations, à la gestion de l'inventaire matériel et à l'exécution des services de sécurité et d'observabilité de l'infrastructure.
• Organisation : limite du locataire de premier niveau. Chaque organisation dispose de son propre cluster d'infrastructure d'organisation dédié, de sa propre configuration de fournisseur d'identité, de sa propre hiérarchie de système de gestion des clés (KMS) et de sa propre instance de routage et de transfert virtuels (VRF).
• Clusters Kubernetes : vous pouvez provisionner des clusters partagés au niveau de l'organisation (qui hébergent plusieurs projets) ou des clusters standards au niveau du projet (dédiés à un seul projet pour une meilleure séparation des charges de travail).
• Projet : unité de location logique au sein d'une organisation dans laquelle vous déployez des VM, des conteneurs, des bases de données et des ressources de stockage. Les projets appliquent l'homogénéité des espaces de noms Kubernetes, les limites du contrôle des accès basé sur les rôles (RBAC) et les règles de réseau de projet sur l'ensemble des clusters.

Isolation physique et VRF entre les racks

Sur les racks physiques 42U, GDC isole les organisations sur des serveurs de calcul, des machines virtuelles de stockage (SVM) et des VRF réseau distincts, de sorte qu'aucun serveur de calcul physique n'est partagé entre les organisations :

Pour en savoir plus, consultez la documentation suivante :

Sujet	Documentation et guides de configuration
Hiérarchie des ressources et projets	Hiérarchie des ressources et Gérer les projets
Clusters Kubernetes	Clusters Kubernetes dans GDC et Configurations de cluster
Conception des limites et des charges de travail	Concevoir des limites d'accès et Concevoir la séparation de la charge de travail

Sécurité des applications

GDC sécurise à la fois les logiciels de la plate-forme fournis via l'air gap et les applications client déployées au sein de votre organisation.

Chaîne d'approvisionnement logicielle et validation SLSA

Tous les composants de la plate-forme GDC, les services propriétaires et les services tiers gérés sont créés dans des environnements de compilation isolés et hermétiques, et analysés pour détecter d'éventuelles failles. Les artefacts sont signés du côté connecté ("low side") conformément aux exigences des niveaux de la chaîne d'approvisionnement pour les artefacts logiciels (SLSA) avant d'être transférés via l'air gap ("high side").

Chaque version inclut une nomenclature logicielle (SBOM) détaillant les composants logiciels, les dépendances et les bibliothèques. Les artefacts sont vérifiés à l'aide de signatures cryptographiques et de sommes de contrôle SHA-256 avant le déploiement.

Registre d'artefacts et application des règles

GDC applique des contrôles d'image de conteneur et de stratégie avant le déploiement :

• Artifact Registry local (Harbor) : les images de conteneurs et les charts Helm sont stockés dans un registre Harbor local au sein de l'environnement sous air gap, ce qui permet de signer les images et d'analyser les failles sans accès à Internet externe.
• Contrôle d'admission et règles d'administration : Open Policy Agent (OPA) Gatekeeper applique des règles d'administration sur les clusters Kubernetes, empêchant les pods de s'exécuter avec une élévation des privilèges, un accès au réseau hôte ou des images de conteneurs non approuvées.

Pour en savoir plus, consultez la documentation suivante :

Sujet	Documentation et guides de configuration
Règles et Artifact Registry	Configurer des règles d'administration et Créer et gérer des ressources Harbor
Charges de travail et services	Charges de travail de conteneur dans GDC et Déployer des services Marketplace

Sécurité réseau

GDC applique une segmentation réseau multicouche, des ports de commutateur physique aux règles de maillage de services de couche 7.

Segmentation VRF et VXLAN du plan de données

La structure du plan de données utilise le VPN Ethernet (EVPN) Multiprotocol BGP (MP-BGP) avec l'encapsulation VXLAN (Virtual Extensible LAN) pour isoler le trafic entre le cluster root-admin et chaque organisation locataire.

• Réseau de gestion hors bande (OOB) : les interfaces de gestion matérielle fonctionnent sur un réseau de gestion physiquement distinct, isolé du trafic des locataires et accessible uniquement à partir du cluster root-admin.
• Isolation VRF et VXLAN : chaque organisation se voit attribuer des identifiants de réseau virtuel (VNI) de couche 3 dédiés, des VRF externes et internes, et des machines virtuelles de stockage (SVM) isolées, de sorte que le trafic des locataires ne puisse pas franchir les limites de l'organisation sans traverser explicitement le pare-feu.
• Pare-feu de nouvelle génération, IDPS et protection contre les attaques par déni de service (DoS) : les pare-feu de périmètre et les systèmes de détection et de prévention des intrusions (IDPS) appliquent une stratégie de refus par défaut, inspectent le trafic entrant et sortant pour détecter les signatures de menaces et fonctionnent avec des équilibreurs de charge pour limiter les attaques par inondation de sessions. Les journaux du pare-feu et de l'IDPS s'intègrent à la pile d'observabilité et à la surveillance de la sécurité de l'infrastructure de l'organisation.
• Règles de réseau de projet et Kubernetes : au sein d'une organisation, vous pouvez appliquer une microsegmentation de refus par défaut entre les projets et les pods à l'aide des ressources ProjectNetworkPolicy, OrganizationNetworkPolicy et Kubernetes NetworkPolicy basées sur Cilium.

Pour en savoir plus, consultez la documentation suivante :

Sujet	Documentation et guides de configuration
Périmètre et prévention des menaces	Présentation de la mise en réseau, Prévention des menaces liées aux requêtes et Contrôle de sortie
Règles de réseau et journaux de flux	Règles de réseau d'organisation, Règles de réseau de projet, Configurer des règles de réseau Kubernetes et Gérer les journaux de flux
Connectivité externe	Configurer le VPN GDC et Établir la connectivité avec des interconnexions