Google Distributed Cloud (GDC) sous air gap utilise une architecture Zero Trust pour protéger votre infrastructure, vos services de plate-forme et vos charges de travail d'application dans des environnements déconnectés, sans nécessiter de connectivité à Google Cloudou à Internet.
La documentation de sécurité de GDC est organisée dans cette présentation et dans deux documents dédiés :
- Présentation de la sécurité : couvre la stratégie de sécurité (piliers Zero Trust et responsabilité partagée), la cryptographie, Identity and Access Management (IAM) et la conformité.
- Sécurité de l'infrastructure, du réseau et des charges de travail : couvre la sécurité des installations, la sécurité matérielle, la sécurité des hôtes et des nœuds, l'isolation de l'architecture mutualisée, la sécurité de la chaîne d'approvisionnement des applications et la segmentation réseau.
- Opérations de sécurité : couvre la surveillance de la sécurité de l'infrastructure et des locataires, la gestion des failles, la réponse aux incidents, l'exportation des journaux de gestion des informations et des événements de sécurité (SIEM) externes, la journalisation d'audit, l'accès d'urgence, la reprise après sinistre et les mises à niveau progressives.
Stratégie de sécurité
GDC repose sur une architecture zéro confiance qui n'accorde aucune confiance implicite basée sur l'emplacement réseau, la propriété de l'appareil ou l'identité de l'utilisateur. Chaque requête sur les couches de matériel, de plan de contrôle et de charge de travail doit être authentifiée, autorisée et chiffrée. Pour en savoir plus sur l'architecture et l'application des principes zéro confiance aux déploiements déconnectés, consultez le livre blanc sur la stratégie zéro confiance de GDC et L'approche zéro confiance de Google Distributed Cloud pour les environnements air gap.
Le modèle de sécurité GDC s'aligne sur les sept piliers Zero Trust suivants :
- Identité et utilisateurs : authentifie les identités humaines et de service via votre fournisseur d'identité d'entreprise (IdP) et applique l'accès avec privilèges minimum dans les organisations et les projets.
- Appareils et points de terminaison : vérifie l'intégrité du matériel et du démarrage, renforce les systèmes d'exploitation hôtes et de nœuds par rapport aux benchmarks de défense, et surveille en permanence les hôtes pour détecter les modifications non autorisées.
- Applications et charges de travail : protège l'intégrité des logiciels, de la compilation à l'exécution, à l'aide de chaînes d'approvisionnement logicielles vérifiées, de registres de conteneurs locaux avec analyse des failles et de règles d'admission de cluster.
- Données et cryptographie : protège les données au repos et en transit par défaut à l'aide de clés cryptographiques intégrées au matériel, de clés de chiffrement gérées par le client (CMEK) et d'une infrastructure à clé publique (PKI) automatisée.
- Réseau et environnement : isole les plans de gestion, les organisations de locataires et les charges de travail de projet à l'aide de la segmentation réseau multicouche, de l'inspection du périmètre et des règles de réseau de refus par défaut.
- Automatisation et orchestration : applique une configuration cohérente, des mises à niveau progressives sans interruption et un accès d'urgence audité via une gestion déclarative des modifications.
- Visibilité et analyse : collecte et met en corrélation la télémétrie d'audit, opérationnelle et de sécurité sur l'ensemble de la plate-forme, et permet d'exporter les journaux des locataires vers des systèmes de surveillance de la sécurité externes.
Modèle de responsabilité partagée
La sécurité dans GDC est une responsabilité partagée entre les couches d'infrastructure, de plate-forme et de charge de travail. Selon que vous utilisez un modèle IaaS (Infrastructure as a Service), PaaS (Platform as a Service) ou SaaS (Software as a Service), les responsabilités opérationnelles sont réparties comme indiqué dans le schéma suivant :
- Couche d'infrastructure : couvre l'infrastructure système sous-jacente, y compris les dispositifs matériels, les commutateurs, les baies de stockage, le cluster root-admin et la surveillance de la sécurité de l'infrastructure. Les mises à niveau du système, la gestion du cycle de vie du matériel et les opérations de sécurité de l'infrastructure sont effectuées sans accéder aux données sensibles des charges de travail des clients.
- Couche d'organisation et de plate-forme : couvre l'administration de l'organisation du locataire, y compris les connexions IdP au niveau de l'organisation, les liaisons de rôles, les clés KMS (Key Management System), les certificats PKI, les règles de réseau de projet, les clusters Kubernetes partagés, ainsi que l'observabilité et l'exportation des journaux de l'organisation.
- Couche de charge de travail et couche application : couvre le développement, le déploiement et la surveillance des charges de travail conteneurisées et de machines virtuelles (VM) dans des espaces de noms de projet isolés, conformément aux règles de sécurité de l'organisation.
Pour en savoir plus, consultez la documentation suivante :
| Sujet | Documentation et guides de configuration |
|---|---|
| Architecture et audiences | Audiences de la documentation et Hiérarchie des ressources |
| Isolation et responsabilité partagée | Concevoir des limites d'accès, Concevoir la séparation de la charge de travail et Modèle de responsabilité partagée de Marketplace |
Cryptographie
GDC fournit un système de gestion des clés (KMS), Certificate Authority Service (CAS) et une infrastructure à clé publique (PKI) intégrés, soutenus par des modules de sécurité matériels (HSM) validés FIPS pour protéger les données au repos et en transit :
- PKI et CAS : automatise l'émission, le renouvellement et la distribution des bundles de confiance des certificats sur les plans de contrôle et les points de terminaison d'entrée, avec la prise en charge des autorités de certification racines internes, des CA intermédiaires externes, des certificats TLS Web personnalisés et des CA de charge de travail.
- KMS et HSM : utilise une hiérarchie de chiffrement encapsulé basée sur HSM par organisation, qui vous permet de gérer les clés de chiffrement symétriques et les clés de signature asymétriques, et d'utiliser des clés de chiffrement gérées par le client (CMEK) pour l'effacement cryptographique.
- Chiffrement par défaut au repos et en transit : chiffre par défaut tous les blocs, fichiers, objets et disques de stockage de serveur au repos à l'aide du chiffrement AES-256 multicouche validé par la norme FIPS, et sécurise tout le trafic en transit à l'aide de TLS, de TLS mutuel (mTLS), d'IPsec ou de MACsec.
Pour en savoir plus, consultez la documentation suivante :
| Sujet | Documentation et guides de configuration |
|---|---|
| PKI et certificats | Récupérer des bundles de confiance, Configurations de certificats TLS Web, Modes de transition PKI et Certificate Authority Service |
| Gestion des clés (KMS, CMEK et HSM) | Système de gestion des clés, Clés de chiffrement gérées par le client et Contrôler les clés HSM |
| Chiffrement des données et du stockage | Chiffrement au repos, Chiffrement en transit, Gérer les buckets de stockage chiffrés et Chiffrer les métriques |
Identity and Access Management
Identity and Access Management (IAM) dans GDC authentifie les utilisateurs humains et les identités de service des charges de travail (ProjectServiceAccount), et applique le principe du moindre privilège et la séparation des tâches pour les ressources globales et zonales. Vous connectez GDC à votre fournisseur d'identité (IdP) d'entreprise à l'aide d'OpenID Connect (OIDC) ou de SAML 2.0 avec l'authentification multifacteur (MFA). Vous accordez ensuite l'accès en associant des utilisateurs ou des groupes à des rôles prédéfinis ou personnalisés limités à votre organisation, à votre projet ou à votre cluster Kubernetes.
Pour en savoir plus, consultez la documentation suivante :
| Sujet | Documentation et guides de configuration |
|---|---|
| Fournisseurs d'identité et authentification | Autorisation et contrôle des accès, Se connecter à un fournisseur d'identité et Identités de service |
| Liaisons de rôles et contrôle des accès | Accorder et révoquer l'accès, Gérer l'accès aux clusters standards et Autorisations des rôles prédéfinis |
Conformité
GDC est conçu pour aider les clients souverains à répondre à des exigences de conformité strictes grâce à un suivi continu de l'inventaire, à l'analyse des failles, à des tests d'intrusion et à la validation de la reprise après sinistre. Étant donné que GDC fonctionne dans votre établissement accrédité, l'obtention de l'accréditation finale du système (comme une autorisation d'exploitation) suit le modèle de responsabilité partagée.
Conformité avec le guide d'implémentation technique de sécurité (STIG)
En vertu de la règle STIG RHEL-08-040320, le package xorg-x11-server-common est une dépendance système approuvée requise pour les pilotes de GPU NVIDIA et les bibliothèques d'accélération matérielle (telles que Vulkan et Mesa). Le service de gestionnaire d'affichage graphique est désactivé et inactif sur les images de système d'exploitation des nœuds.
Pour en savoir plus, consultez la documentation suivante :
| Sujet | Documentation et guides de configuration |
|---|---|
| Benchmarks et règles | Benchmark CIS de Kubernetes et Configurer des règles d'administration |
| Journaux d'audit et conservation | Présentation des journaux d'audit, Sécuriser et restaurer les journaux d'audit et Créer des buckets WORM |