Sécurité

Ce document présente les concepts de base, les couches et les rôles opérationnels permettant de maintenir la sécurité dans Google Distributed Cloud (GDC) air gap. GDC est conçu pour les environnements déconnectés hautement sécurisés et pour respecter des exigences strictes en matière de souveraineté des données.

Ce document s'adresse aux audiences du groupe d'opérateurs d'infrastructure, du groupe d'administrateurs de plate-forme et du groupe d'opérateurs d'applications qui gèrent la sécurité de leur organisation. Pour en savoir plus, consultez la documentation sur les audiences pour GDC sous air gap.

Ce document vous aide à comprendre les principaux attributs de sécurité dans les catégories suivantes :

• Conformité
• Opérations de sécurité
• Opérations de fiabilité
• Cryptographie
• Identity and Access Management (IAM)
• Sécurité réseau
• Sécurité des applications
• Sécurité des hôtes et des nœuds
• Sécurité matérielle
• Sécurité des installations

Stratégie de sécurité

GDC adopte une approche axée sur la sécurité avec plusieurs couches de sécurité pour offrir un contrôle maximal, rester conforme aux réglementations légales et protéger les données confidentielles. Il est conçu pour s'exécuter sur du matériel dédié et sécurisé dans un centre de données local afin de fournir une isolation stricte des locataires.

Les couches de sécurité fournies par GDC incluent la sécurité matérielle, la sécurité des hôtes et des nœuds, la sécurité des applications, la sécurité réseau, la cryptographie, Identity and Access Management (IAM), les opérations de sécurité et de fiabilité, la conformité et les offres de sécurité.

GDC dispose d'un modèle de sécurité partagée pour sécuriser l'ensemble de la pile d'applications. GDC fournit des services IaaS (Infrastructure as a Service), PaaS (Platform as a Service) et SaaS (Software as a Service). Dans toutes les configurations de GDC, Google et l'opérateur sont responsables de la sécurisation des couches de l'infrastructure. Le client est responsable de la sécurisation de la configuration du projet et de la couche d'application, y compris des conteneurs d'application, des images de base et des dépendances.

Du point de vue de la sécurité, les groupes d'audience suivants exploitent GDC :

• Groupe d'opérateurs d'infrastructure : gère les opérations quotidiennes de l'infrastructure du système et n'a pas accès aux données client. Ce persona est l'administrateur de plus haut niveau du système. Il peut s'agir de Google, d'un tiers sous contrat ou du client, selon la nature des restrictions de souveraineté.

• Groupe d'administrateurs de plate-forme : persona client qui gère les ressources et les autorisations des projets. Il s'agit du niveau de droits d'administrateur le plus élevé accordé au client et du seul niveau d'administration pouvant accorder l'accès aux données client.

• Groupe d'opérateurs d'application : développe des applications à déployer et à exécuter, et configure des ressources et des autorisations précises sur GDC. Ce persona travaille dans le cadre des règles établies par l'administrateur de la plate-forme (PA) pour s'assurer que ses systèmes sont conformes aux exigences de sécurité et de conformité du client.

Pour en savoir plus, consultez Audiences de la documentation.

Sécurité des installations

Vous pouvez déployer GDC dans des centres de données sous air gap désignés par le client. La sécurité physique spécifique à l'emplacement varie en fonction des exigences de chaque client. Pour se conformer aux réglementations locales, les centres de données peuvent avoir besoin d'une accréditation, par exemple ISO 27001. Le centre de données doit disposer de plusieurs mesures de sécurité, telles que des systèmes de défense sécurisés pour empêcher tout accès non autorisé au centre de données, une couverture complète par caméra pour surveiller toutes les activités dans le centre de données, une authentification physique pour s'assurer que seul le personnel autorisé peut accéder au centre de données, un personnel de sécurité pour patrouiller dans le centre de données 24h/24 et 7j/7 et répondre à tout incident de sécurité, ainsi que des règles d'accès et de sécurité strictes pour réglementer la manière dont le personnel accède au centre de données et l'utilise. Ces mesures de sécurité constituent une première couche de protection importante pour protéger les données stockées dans le centre de données contre tout accès, utilisation, divulgation, perturbation, modification ou destruction non autorisés.

Sécurité matérielle

Google applique un processus rigoureux pour assurer la sécurité de son matériel. Tout le matériel GDC est acheté et assemblé par des partenaires approuvés et certifiés pour répondre aux exigences de souveraineté et de chaîne d'approvisionnement spécifiques au client. Le matériel est testé et approuvé pour répondre aux normes internes strictes de Google et aux besoins des clients les plus soucieux de la sécurité. Tous les sous-composants du matériel GDC proviennent de fournisseurs de confiance, qui ont été vérifiés et sont connus pour leur fiabilité. L'intégration du matériel dans les racks GDC est effectuée dans des centres régionaux certifiés, qui sont des installations approuvées par Google pour gérer le matériel sensible. Tous les membres du personnel qui manipulent le matériel GDC font l'objet d'une vérification des antécédents, ce qui garantit que seul le personnel autorisé a accès au matériel. De plus, l'implémentation réelle de certains composants matériels et micrologiciels à haut risque est examinée par une équipe dédiée à la sécurité. Ces examens prennent en compte des menaces telles que les attaques de la chaîne d'approvisionnement, les attaques physiques et les attaques d'exécution locale sur les composants matériels et micrologiciels, y compris les menaces persistantes. Ces examens permettent d'acquérir des connaissances qui influencent directement nos exigences de sécurité matérielle, y compris les micrologiciels sécurisés et les mises à jour du micrologiciel, l'intégrité des micrologiciels, le démarrage sécurisé, la gestion sécurisée et la maintenance. Google entretient des relations étroites avec tous les fournisseurs et toutes les équipes qui utilisent le matériel afin de s'assurer que des fonctionnalités de sécurité de premier ordre sont fournies. Cela signifie que Google collabore constamment avec ses partenaires pour s'assurer que le matériel est aussi sécurisé que possible. Google va encore plus loin en améliorant les exigences matérielles et de sécurité, en effectuant des examens de sécurité interactifs et en collaborant avec les équipes produit pour mettre en œuvre de nouvelles fonctionnalités de sécurité spécialement conçues pour GDC et profondément intégrées non seulement au matériel et au micrologiciel, mais aussi à d'autres fonctionnalités du produit.

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

GDC garantit que seul notre système d'exploitation (OS) de nœud sécurisé et personnalisé peut être chargé sur les systèmes par défaut. Les images et configurations renforcées réduisent considérablement les surfaces d'attaque. Les modules cryptographiques qui protègent les données au repos et en transit sont certifiés FIPS 140-2/3, ce qui signifie qu'ils ont été rigoureusement testés pour la sécurité et validés par un laboratoire indépendant accrédité. GDC fournit un logiciel anti-logiciels malveillants pour le système d'exploitation exécuté sur les nœuds bare metal et une solution pour analyser les systèmes de stockage. Google empaquette les mises à jour de ces scanners, qui sont incluses dans les mises à jour système régulières que l'IO applique à l'aide du processus de mise à niveau de GDC. Les alertes de détection sont envoyées à l'OI. GDC fournit également des outils de surveillance de l'intégrité et de détection des violations pour protéger le système contre les modifications involontaires. Globalement, ces mesures de sécurité permettent de protéger le système contre diverses attaques. Les mesures de sécurité empêchent les pirates d'accéder au système, d'exploiter les failles et d'installer des logiciels malveillants.

Tenancy

GDC est une plate-forme cloud gérée mutualisée semblable à la plate-formeGoogle Cloud . L'architecture est conçue pour assurer une isolation forte entre les locataires, en fournissant une couche de protection solide entre les utilisateurs du cloud et en permettant aux utilisateurs de respecter des normes d'accréditation strictes pour les charges de travail. GDC propose deux niveaux d'isolation des locataires. Le premier niveau, appelé "Organisations", fournit une isolation physique forte du calcul, et le second niveau, "Projets", offre des options d'allocation de ressources plus précises grâce à une séparation logique.

Aucun serveur de calcul physique n'est partagé entre les organisations, et les couches d'opérateurs conservent également la location. Les IO ne sont pas autorisés à accéder aux couches PA. De même, les AO ne peuvent pas accéder aux couches PA.

Sécurité des applications

Pour se protéger contre les attaques de la chaîne d'approvisionnement logicielle, tous les logiciels GDC sont développés conformément au framework SLSA (Supply chain Levels for Software Artifacts), un framework de sécurité de la chaîne d'approvisionnement que Google a développé en partenariat avec des organisations telles que la CNCF et la Linux Foundation.

SLSA est une checklist de normes et de contrôles permettant d'éviter les accès non autorisés, d'améliorer l'intégrité et de sécuriser les packages dans la chaîne d'approvisionnement logicielle. Cette checklist est conçue pour empêcher les exploits qui attaquent les dépôts de code source, les systèmes de compilation et les packages de dépendances tierces.

Tous les codes sources et dépendances GDC sont stockés dans un système de contrôle des versions Google isolé et chiffré dans des centres de données Google sécurisés. Tout le code dispose d'un historique validé et nécessite qu'une deuxième personne examine les modifications du code avant qu'elles ne soient acceptées dans le système de contrôle des versions.

Les builds sont livrés à l'aide d'un système d'orchestration des versions de Google qui exploiteGoogle Cloud Build et les outils de test automatisés de Google pour une compilation, un test et une publication entièrement automatisés des images de conteneurs et des binaires. Toutes les compilations sont isolées, hermétiques et définies à l'aide du principe de compilation en tant que code. Aucun individu ne dispose d'un accès unilatéral au processus de livraison de logiciels.

Toutes les images sont analysées pour détecter les failles à l'aide de plusieurs scanners de sécurité des applications et sont validées à plusieurs points à l'aide d'une combinaison de signatures cryptographiques et de sommes de contrôle SHA256. Chaque version contient une nomenclature logicielle (SBOM) qui inclut des détails sur les composants logiciels, les dépendances et les bibliothèques, ainsi que les données fournies.

Sécurité réseau

Cette section présente la sécurité réseau de GDC.

Réseau physique

Bien que GDC soit conçu pour être utilisé dans des environnements déconnectés, en pratique, les systèmes GDC sont susceptibles d'être connectés à un environnement protégé plus vaste, connecté au réseau privé interne d'un client, tout en restant déconnectés de l'Internet public.

Tout le trafic réseau entre le réseau privé du client et les systèmes GDC passe par des pare-feu et des systèmes de détection et de prévention des intrusions (IDS/IPS). Le pare-feu constitue la première ligne de défense pour contrôler l'accès au système. Le pare-feu et l'IDS/IPS contrôlent le trafic entrant et sortant en fonction de règles de sécurité configurables, et utilisent le machine learning pour analyser automatiquement le trafic et bloquer les accès non autorisés. Le système IDS/IPS inspecte par défaut toutes les communications entrantes et sortantes de l'infrastructure. Les administrateurs de projet peuvent également utiliser le système IDS/IPS pour inspecter le trafic de leurs propres charges de travail. Les pare-feu et les IDS/IPS sont également intégrés à la pile d'observabilité de l'organisation pour les charges de travail des clients et à la pile SIEM de l'IO pour l'infrastructure afin de permettre une analyse de sécurité et une investigation supplémentaires.

Les pare-feu appliquent des règles de refus par défaut comme stratégie de sécurité initiale pour empêcher les accès involontaires et les fuites de données. L'OI et le PA disposent de méthodes permettant de définir d'autres règles d'accès si nécessaire. Dans GDC, deux réseaux physiquement distincts permettent d'isoler les fonctions d'administration et de contrôle des données de charge de travail des clients.

Le réseau de gestion hors bande (OOB) est utilisé uniquement pour les fonctions d'administration, telles que les modifications de configuration des périphériques réseau, des dispositifs de stockage et d'autres composants matériels. Seul l'IO a accès au réseau OOB, et uniquement dans des cas exceptionnels. Les LCA réseau sont configurées de sorte que seuls les serveurs du cluster root-admin contrôlé par l'IO sont autorisés à accéder à ce réseau. Le réseau du plan de données connecte les serveurs de charge de travail entre eux et est accessible par l'AP et les OA.

Réseau défini par logiciel

Le réseau du plan de données est un réseau de superposition basé sur le routage et le transfert virtuels (VRF) pour l'isolation du trafic des locataires. Chaque organisation locataire dispose d'un réseau VRF externe et interne. Les services externes, par exemple l'équilibreur de charge externe et le NAT de sortie, se trouvent dans le domaine externe. Les charges de travail client résident dans le VRF interne.

Le réseau interne est utilisé pour la communication au sein du locataire, par exemple pour le trafic de charge de travail entre les nœuds et vers le stockage de fichiers et de blocs au sein de l'organisation. Le réseau externe est utilisé pour communiquer en dehors d'une organisation. Le trafic de gestion des locataires pour accéder aux fonctions de contrôle des accès ou le trafic client pour accéder aux projets doit passer par le réseau externe. Chaque charge de travail client dispose d'équilibreurs de charge et de passerelles NAT à configurer pour le trafic entrant et sortant.

Réseau virtuel

La mise en réseau virtuelle GDC est une couche de mise en réseau au niveau de l'organisation, basée sur le réseau de superposition. Il est optimisé par le pilote CNI (Container Network Interface) géré par GDC : le plan de données de mise en réseau Anthos.

La couche réseau virtuelle de GDC fournit une isolation logicielle au sein de l'organisation, appelée "projet". Cette couche fournit les fonctionnalités de sécurité réseau suivantes :

• Règle de réseau de projet : pour la protection des limites du projet.
• Règle de réseau d'organisation : pour la protection des limites de l'organisation.

Les règles de réseau du projet et de l'organisation ont une configuration de refus par défaut comme point de départ pour se protéger contre les accès non intentionnels et les fuites de données.

Protection contre le déni de service

Tout le trafic entrant dans GDC passe par l'IDS/IPS et un ensemble d'équilibreurs de charge. Les systèmes IDS/IPS détectent et suppriment le trafic non autorisé, et protègent les ressources contre les attaques par inondation de session. Les équilibreurs de charge peuvent limiter le trafic de manière appropriée pour éviter toute perte de service. Comme toute connectivité externe est gérée via le réseau privé du client, celui-ci peut fournir une couche supplémentaire de protection contre les attaques par déni de service distribué.

Cryptographie

Cette section présente la cryptographie GDC.

PKI

GDC fournit une infrastructure à clé publique (PKI) pour la gestion centralisée des autorités de certification X.509 pour les services d'infrastructure. Par défaut, GDC dispose d'autorités de certification racine privées par installation, ainsi que d'autorités de certification intermédiaires et de certificats serveur distribués à partir de celles-ci. De plus, GDC peut prendre en charge l'installation de certificats émis par le client sur les points de terminaison destinés aux clients, ce qui augmente la flexibilité d'utilisation des certificats. GDC coordonne de manière centralisée la distribution des magasins de confiance, ce qui permet aux charges de travail et aux services système d'authentifier et de chiffrer plus facilement le trafic des applications. En résumé, GDC fournit une solution PKI puissante pour sécuriser divers services d'infrastructure, ce qui permet une gestion de la confiance pratique, mais étroitement contrôlée.

Service de gestion des clés

GDC fournit un service de gestion des clés (KMS) reposant sur des modules de sécurité matériels (HSM). Le KMS est un service propriétaire. Le matériel de clé reste dans le KMS, qui est lui-même sauvegardé par des HSM. Les définitions de ressources personnalisées (CRD) contiennent des données de clé chiffrées. Seul le KMS a accès aux données de clé brutes en mémoire. Il existe un KMS par organisation. Toutes les données au repos sont chiffrées par défaut à l'aide de clés basées sur un HSM. Les clients peuvent également choisir de gérer leurs propres clés cryptographiques. KMS est compatible avec les algorithmes approuvés par la norme FIPS et les modules validés par la norme FIPS. Le KMS permet d'importer et d'exporter des clés de manière sécurisée pour les cas d'utilisation d'autorité de séquestre, de suppression ou de reprise après sinistre. Ces fonctionnalités font de KMS un moyen sûr et fiable de gérer les clés cryptographiques.

GDC propose également des clés de chiffrement gérées par le client (CMEK). Les CMEK permettent aux clients de contrôler les clés qui protègent leurs données au repos dans GDC. L'une des principales motivations de l'adoption des CMEK est l'effacement cryptographique, une méthode de destruction des données à haute assurance pour la correction des fuites de données et le déprovisionnement. Les clés peuvent être supprimées hors bande des données qu'elles protègent. Toutes les données de votre organisation sont protégées par un ensemble de CMEK que vos opérateurs de plate-forme peuvent surveiller, auditer et supprimer si nécessaire. Les clés CMEK sont des clés de chiffrement que vous pouvez gérer à l'aide des API HSM. Les CMEK peuvent être utilisées pour chiffrer les données des charges de travail de stockage de blocs, de disques de machines virtuelles, de services de base de données et de conteneurs utilisateur.

Chiffrement

Cette section présente le chiffrement GDC.

Données au repos

Toutes les données GDC stockées dans un espace de stockage de fichiers, de blocs et d'objets sont chiffrées au repos à l'aide de plusieurs niveaux de chiffrement. Dans les environnements mutualisés, les données de chaque locataire sont chiffrées avec une clé spécifique au locataire avant d'être écrites dans un espace de stockage de fichiers, de blocs et d'objets :

• Le stockage de blocs (volumes d'application, disques de VM, stockage de base de données) est chiffré à trois niveaux :
  • Couche logicielle : chiffrement LUKS (Linux Unified Key Setup) effectué dans un matériel de calcul dédié au locataire avec des clés par volume, sauvegardées par HSM et gérées par le client.
  • Couche de l'appareil : chiffrement au niveau de l'agrégat de volumes (NVE/NAE) effectué dans l'appareil de stockage avec des clés par locataire, sauvegardées par HSM et gérées par le client.
  • Couche de disque : disques à chiffrement automatique (SED) avec des clés par disque, basées sur un HSM et gérées par l'IO.
• Le stockage d'objets est chiffré à deux niveaux
  • Couche de bucket : chiffrement des données d'objet coordonné au sein d'un matériel de calcul dédié au locataire, avec des clés par bucket, gérées par le client et sauvegardées par HSM.
  • Couche de disque : disques SED avec des clés par disque, basées sur HSM, gérées par l'IO.
• Le stockage sur disque du serveur, qui contient les données de configuration du système pour un seul locataire, est chiffré à un niveau :
  • Couche de disque : disques SED avec des clés par disque, sauvegardées par HSM et gérées par le client.

Données en transit

Par défaut, tout le trafic GDC est chiffré à l'aide de modules cryptographiques certifiés FIPS 140-2 et de protocoles standards dans l'industrie tels que TLS 1.2+, HTTPS et les tunnels IPSec. Les clients doivent également utiliser des algorithmes de chiffrement sur la couche application, en fonction du modèle de responsabilité partagée, afin de s'assurer que les exigences de chiffrement sont respectées pour toutes les applications déployées sur GDC.

Identity and Access Management (IAM)

L'accès au système est basé sur le principe du moindre privilège. Les utilisateurs n'ont accès qu'aux ressources dont ils ont besoin. Ce processus protège le système contre les accès non autorisés et les utilisations abusives. De plus, le système applique la séparation des tâches, par exemple en n'autorisant pas l'accès unilatéral. Aucune personne ne dispose d'un contrôle total sur un système ou un processus. Ce processus permet d'éviter les fraudes et les erreurs. GDC peut s'intégrer au fournisseur d'identité existant des clients. Le système est compatible avec SAML 2.0 et OIDC pour la fédération des fournisseurs d'identité. Cette compatibilité permet aux utilisateurs d'authentifier les utilisateurs du système à l'aide de leur fournisseur d'identité existant afin de gérer les utilisateurs de manière centralisée. Tous les utilisateurs et toutes les charges de travail sont authentifiés avant d'accéder au système. Le RBAC et l'ABAC sont utilisés pour autoriser l'accès à l'ensemble du plan de contrôle et des données. Les utilisateurs ne sont autorisés à accéder aux ressources et à effectuer des actions que s'ils sont authentifiés et autorisés. Tous les accès sont consignés dans un journal d'audit, ce qui permet aux administrateurs de savoir qui a accédé à une ressource et quand. Ce processus permet d'identifier les accès non autorisés et les utilisations abusives.

Opérations de sécurité

GDC Security Operations (SecOps) fournit une assurance de l'information aux entités soumises à des exigences strictes en matière de sécurité, de conformité et de souveraineté, afin de garantir une confidentialité, une intégrité et une disponibilité opérationnelles maximales des charges de travail réglementées des clients sous air gap. Cette architecture de sécurité est destinée à répondre aux objectifs suivants :

• Corrélez la journalisation de la plate-forme GDC pour l'analyse de la sécurité et la réponse aux incidents.
• Identifiez, signalez et suivez rapidement les failles de sécurité.
• Protégez tous les éléments OIC et GDC grâce à la détection et à la réponse au niveau des points de terminaison (EDR).
• Fournissez des outils, des processus et des runbooks pour permettre au centre d'opérations SecOps de surveiller en continu l'identification, le confinement, l'éradication et la récupération des incidents de cybersécurité.

Fonctionnalité	Description
Gestion des informations et des événements de sécurité	Elastic Security est une plate-forme de gestion des informations et des événements de sécurité (SIEM) qui collecte, indexe et analyse les données de sécurité provenant de diverses sources pour aider les organisations à détecter les menaces et à y répondre.
Gestion des failles	Tenable Security Center est une plate-forme de gestion des failles qui aide les organisations à identifier et à corriger les failles de sécurité.
Détection et réponse pour les points de terminaison	Elastic Security, Windows Defender et ClamAV. Les plates-formes de sécurité unifiées, qui offrent aux entreprises une vue complète de leur stratégie de sécurité pour détecter les menaces et y répondre plus efficacement.
Gestion sécurisée des demandes d'assistance	Solution logicielle qui permet aux organisations de gérer le cycle de vie des incidents de sécurité.

GDC SecOps permet aux IO de fournir des fonctions d'opérations de sécurité. L'équipe GDC SecOps fournit des processus axés sur les personnes, y compris la réponse aux incidents, la gestion des failles, l'ingénierie de la sécurité et la gestion des risques liés à la chaîne d'approvisionnement. GDC SecOps permet à un centre des opérations de sécurité (SOC) d'effectuer les opérations suivantes :

Capacité	Description
Détection	Notre infrastructure de sécurité surveille en permanence les menaces et les failles potentielles. Lorsqu'une menace ou une faille est détectée, l'équipe chargée des opérations de sécurité reçoit immédiatement un rapport.
Tri	L'équipe chargée des opérations de sécurité trie chaque incident pour déterminer la gravité de la menace et la réponse appropriée.
Confinement	L'équipe chargée des opérations de sécurité prend des mesures pour contenir la menace et l'empêcher de se propager.
Enquête	L'équipe des opérations de sécurité enquête sur l'incident pour en déterminer la cause principale et identifier les faiblesses de notre stratégie de sécurité.
Réponse	L'équipe chargée des opérations de sécurité prend des mesures pour répondre à l'incident et limiter les dommages causés.
Récupération	L'équipe chargée des opérations de sécurité prend des mesures pour se remettre de l'incident et rétablir l'état normal de nos systèmes et réseaux.

Gestion des failles

GDC exécute plusieurs processus d'identification des failles dans l'environnement de préproduction avant chaque version afin de rester informé des éventuelles failles et expositions courantes (CVE). GDC fournit également une analyse des failles dans l'environnement de production à des fins de surveillance et de reporting de routine. Tous les résultats de l'environnement de production sont intégrés aux processus des opérations de sécurité pour suivre et atténuer les menaces.

Réponse aux incidents de sécurité

Lorsque des failles sont détectées dans le code déployé sur GDC ou qu'un incident se produit dans le système, un ensemble de processus de réponse aux incidents sont disponibles et exécutés par l'IO et l'équipe de sécurité GDC pour atténuer, créer et appliquer des correctifs de sécurité, et communiquer avec les parties concernées. Ce processus de gestion des incidents est similaire au processus de gestion des incidents standard de Google, avec des modifications pour la nature déconnectée de GDC.

Pour chaque CVE ou incident découvert, un chargé d'incident est désigné pour exécuter le processus de réponse. L'IC est chargé de gérer le processus, ce qui inclut la vérification et la validation de l'incident, l'attribution d'un score CVSS (Common Vulnerability Scoring System) à la faille, la gestion du processus de création d'un correctif et de sa mise à disposition, ainsi que la création des communications appropriées.

Opérations de fiabilité

Cette section présente les opérations de fiabilité de GDC.

Journaliser et surveiller

GDC est fourni avec une plate-forme d'observabilité qui offre des fonctionnalités de surveillance, de journalisation, de traçage et de reporting pour la plate-forme, les services et les charges de travail GDC.

Le sous-système de journalisation ingère et agrège les journaux de toutes les plates-formes et services GDC de base, ainsi que les charges de travail des clients, dans une base de données de séries temporelles. Il met ces données à disposition via une interface utilisateur interactive et des API.

Les événements critiques des journaux d'audit incluent les domaines suivants :

• Demandes d'authentification et d'autorisation des utilisateurs.
• Génération et révocation des jetons d'authentification.
• Tous les accès administrateur et modifications.
• Toutes les actions de l'API du plan de contrôle.
• Tous les événements liés à la sécurité, y compris les IDS, les IPS, les pare-feu et les antivirus.

Accès en mode "bris de glace"

L'OI n'a pas accès aux données client. Toutefois, dans les situations d'urgence, il peut arriver que l'opérateur d'infrastructure ait besoin d'accéder aux données client. Dans ce cas, GDC dispose d'un ensemble de procédures d'accès d'urgence qu'un administrateur de plate-forme utilise pour accorder explicitement l'accès à l'opérateur d'infrastructure pour le dépannage.

Tous les identifiants d'accès d'urgence sont stockés hors connexion dans un coffre-fort ou chiffrés avec des clés ancrées dans le HSM. L'accès à ces identifiants est un événement auditable qui peut déclencher des alertes.

Par exemple, si la configuration IAM a été corrompue et empêche l'accès des utilisateurs, l'OI utilise une authentification basée sur les certificats SSH via des postes de travail sécurisés et nécessite une approbation multipartite pour établir l'accès. Toutes les actions effectuées sont suivies et peuvent être auditées. Les clés SSH changent après un incident d'accès d'urgence.

Reprise après sinistre

GDC est fourni avec un système de sauvegarde qui permet aux administrateurs de plate-forme de créer et de gérer des règles de sauvegarde pour les clusters, les espaces de noms ou les VM. Le système de sauvegarde contient les systèmes classiques de planification, d'exécution des sauvegardes, de restauration des données et de reporting.

Mettre à niveau et mettre à jour le système

Étant donné que GDC est un environnement sous air gap, l'opérateur d'infrastructure traite toutes les mises à jour des systèmes client. Google signe et publie les mises à jour binaires dans un emplacement sécurisé pour que l'OI puisse les télécharger. L'IO valide les binaires et les déplace vers GDC pour distribution et déploiement.

Ce système inclut toutes les mises à jour logicielles et de micrologiciel, y compris les mises à jour du logiciel GDC, de l'OS au niveau du nœud, des définitions et signatures d'antivirus et de logiciels malveillants, des appareils de stockage et de réseau, des mises à jour d'appareils et de toutes les autres mises à jour binaires.

Gestion des modifications : Infrastructure as Code

GDC utilise l'Infrastructure as Code (IaC) pour automatiser le provisionnement et le déploiement des configurations GDC. L'IaC sépare les responsabilités au sein de l'équipe chargée des opérations d'infrastructure. Par exemple, proposer une modification de configuration plutôt que d'autoriser la modification, afin de sécuriser l'ensemble du processus. Avec GDC IAC, toutes les modifications de configuration sont validées par des processus d'examen et d'approbation multipartites afin de s'assurer que seules les configurations autorisées sont déployées. Ces examens créent un processus transparent et vérifiable, améliorent la cohérence des modifications et réduisent la dérive de configuration.

Processus de conformité

GDC est prêt à se conformer aux régimes courants tels que NIST 800-53 et SOC 2, et à obtenir des certifications telles que FIPS 140-2 et 3. GDC passe également par différents processus de certification et répond aux normes de sécurité de Google. La conformité est un processus continu. Pour aider les clients et les opérateurs dans cette démarche, GDC fournit une surveillance et des tests continus. Dans le cadre des pratiques de sécurité du processus de surveillance continue, GDC suit les modifications d'inventaire, telles que les logiciels et matériels inconnus, ou l'ajout de nouveaux logiciels ou matériels. GDC effectue régulièrement des tests d'intrusion en simulant des attaques d'acteurs malveillants. GDC analyse régulièrement les systèmes à la recherche de logiciels malveillants et l'alerte en cas d'infection. Le processus de test de reprise après sinistre teste la capacité de GDC à se remettre d'une situation impliquant un sinistre. Ces processus garantissent la sécurité des données et des systèmes GDC.

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 du système d'exploitation du nœud.