Décider de la sécurité de votre zone de destination Google Cloud

Last reviewed 2023-08-31 UTC

Ce document présente les décisions de sécurité importantes et les options recommandées à prendre en compte lors de la conception d'une zone de destination Google Cloud. Il fait partie d'une série sur les zones de destination et s'adresse aux spécialistes de la sécurité, aux RSSI et aux architectes qui souhaitent comprendre les décisions à prendre lors de la conception d'un zone de destination dans Google Cloud.

Dans ce document, il est supposé qu'une équipe centrale, telle que l'équipe chargée de la sécurité ou l'équipe chargée de la plate-forme, applique ces contrôles de sécurité de zone de destination. Cet article se concentre sur la conception d'environnements d'entreprise. Par conséquent, certaines stratégies qu'il décrit peuvent être moins pertinentes pour les petites équipes.

Points de décision pour sécuriser votre zone de destination Google Cloud

Pour choisir la meilleure conception de sécurité pour votre organisation, vous devez prendre les décisions suivantes :

Schéma de l'architecture

L'exemple d'architecture décrit dans ce document s'appuie sur des modèles de conception de sécurité courants. Les contrôles spécifiques peuvent varier en fonction de facteurs tels que le secteur de votre entreprise, vos charges de travail cibles ou des exigences de conformité supplémentaires. Le schéma suivant illustre l'architecture des contrôles de sécurité que vous appliquez dans votre zone de destination lorsque vous suivez les recommandations de ce document.

Exemple d'architecture des contrôles de sécurité

Le schéma précédent montre les éléments suivants :

  • La gestion des clés de compte de service permet de limiter le risque lié aux identifiants de longue durée des comptes de service.
  • VPC Service Controls définit un périmètre autour de ressources sensibles qui permet de restreindre les accès depuis l'extérieur du périmètre.
  • Security Command Center surveille l'environnement pour détecter les configurations et les menaces non sécurisées.
  • Un récepteur de journaux centralisé collecte les journaux d'audit pour tous les projets.
  • Le chiffrement au repos par défaut de Google chiffre toutes les données persistantes sur le disque.
  • Le chiffrement en transit par défaut de Google s'applique aux chemins réseau de couche 3 et 4.
  • Access Transparency vous permet de visualiser et de contrôler l'accès de Google à votre environnement.

Comment limiter les identifiants persistants pour les comptes de service

Les comptes de service sont des identités de machines que vous utilisez pour accorder des rôles IAM aux charges de travail et leur permettre d'accéder aux API Google Cloud. Une clé de compte de service est un identifiant persistant, et tous les identifiants persistants présentent un risque potentiellement élevé. Nous vous déconseillons de laisser les développeurs créer des clés de compte de service librement.

Par exemple, si un développeur valide accidentellement la clé de compte de service dans un dépôt Git public, un pirate informatique externe peut s'authentifier à l'aide de ces identifiants. Autre exemple : si la clé de compte de service est stockée dans un dépôt interne, un initié malveillant capable de lire la clé peut utiliser les identifiants pour élever ses propres droits Google Cloud.

Pour définir une stratégie permettant de gérer ces identifiants persistants, vous devez fournir des alternatives viables, limiter la prolifération de ces identifiants persistants et gérer leur utilisation. Pour en savoir plus sur les alternatives aux clés de compte de service, consultez la section Choisir la méthode d'authentification adaptée à votre cas d'utilisation.

Les sections suivantes décrivent les options permettant de limiter les identifiants persistants. Nous recommandons l'option 1 pour la plupart des cas d'utilisation. Les autres options décrites dans les sections suivantes sont des alternatives que vous pouvez envisager si l'option 1 ne s'applique pas à votre organisation spécifique.

Option 1 : Restreindre l'utilisation des clés de compte de service persistantes

Nous vous recommandons de ne pas autoriser les utilisateurs à télécharger des clés de compte de service, car les clés exposées sont un vecteur d'attaque courant. Restreindre l'utilisation des clés de compte de service persistantes permet de réduire les risques et les frais liés à la gestion manuelle des clés de compte de service.

Pour mettre en œuvre cette option, tenez compte des éléments suivants :

Évitez cette option lorsque vous disposez déjà d'outils permettant de générer des identifiants d'API de courte durée pour les comptes de service.

Pour en savoir plus, consultez les ressources suivantes :

Option 2 : Utiliser des outils de gestion des accès supplémentaires pour générer des identifiants éphémères

Au lieu de restreindre l'utilisation des clés de compte de service persistantes, vous pouvez générer des identifiants éphémères pour les comptes de service. Les identifiants éphémères présentent moins de risques que les identifiants persistants, tels que les clés de compte de service. Vous pouvez développer vos propres outils ou utiliser des solutions tierces comme Hashicorp Vault pour générer des identifiants d'accès éphémères.

Utilisez cette option lorsque vous avez déjà investi dans un outil tiers pour générer des identifiants éphémères pour le contrôle des accès, ou que vous disposez d'un budget et d'une capacité suffisants pour développer votre propre solution.

Évitez d'utiliser cette option lorsque vous n'avez pas d'outils existants permettant d'accorder des identifiants éphémères, ou si vous ne disposez pas de la capacité nécessaire pour créer votre propre solution.

Pour plus d'informations, consultez la page Créer des identifiants de compte de service éphémères.

Comment limiter l'exfiltration de données via les API Google

Les API Google disposent de points de terminaison publics, accessibles à tous les clients. Bien que chaque ressource d'API de votre environnement Google Cloud soit soumise à des contrôles d'accès IAM, il est possible que des données soient accessibles à l'aide d'identifiants volés, exfiltrés par des initiés malveillants ou du code compromis, ou exposés via une stratégie IAM mal configurée.

VPC Service Controls est une solution qui résout ces risques. Toutefois, VPC Service Controls apporte également de la complexité à votre modèle d'accès. Vous devez donc concevoir VPC Service Controls de façon à répondre aux besoins de votre environnement et de votre cas d'utilisation uniques.

Les sections suivantes décrivent les options permettant de limiter l'exfiltration de données via les API Google. Nous recommandons l'option 1 pour la plupart des cas d'utilisation. Les autres options décrites dans les sections suivantes sont des alternatives que vous pouvez envisager si l'option 1 ne s'applique pas à votre cas d'utilisation spécifique.

Option 1 : Configurer VPC Service Controls à grande échelle dans votre environnement

Nous vous recommandons de concevoir votre environnement dans un ou plusieurs périmètres VPC Service Controls qui limitent toutes les API compatibles. Configurez des exceptions au périmètre avec des niveaux d'accès ou des règles d'entrée afin que les développeurs puissent accéder aux services dont ils ont besoin, y compris les accès à la console si nécessaire.

Utilisez cette option lorsque les conditions suivantes sont remplies :

  • Les services que vous souhaitez utiliser sont compatibles avec VPC Service Controls et vos charges de travail ne nécessitent pas d'accès Internet non restreint.
  • Vous stockez sur Google Cloud des données sensibles pouvant entraîner une perte importante en cas d'exfiltration.
  • Vous disposez d'attributs cohérents pour l'accès des développeurs, qui peuvent être configurés en tant qu'exceptions au périmètre, permettant aux utilisateurs d'accéder aux données dont ils ont besoin.

Évitez cette option lorsque vos charges de travail nécessitent un accès Internet non restreint ou des services non compatibles avec VPC Service Controls.

Pour en savoir plus, consultez les ressources suivantes :

Option 2 : Configurer VPC Service Controls pour un sous-ensemble de votre environnement

Au lieu de configurer VPC Service Controls à grande échelle dans votre environnement, vous pouvez limiter sa configuration au sous-ensemble de projets contenant des données sensibles et des charges de travail internes uniquement. Cette option vous permet d'utiliser une conception et une opération simplifiées pour la plupart des projets, tout en privilégiant la protection des données pour les projets contenant des données sensibles.

Par exemple, vous pouvez envisager cette alternative lorsqu'un nombre limité de projets contient des ensembles de données BigQuery contenant des données sensibles. Vous pouvez définir un périmètre de service autour de ces projets uniquement, et définir des règles d'entrée et de sortie afin d'autoriser des exceptions étroites pour les analystes ayant besoin d'utiliser ces ensembles de données.

Autre exemple, dans une application avec une architecture à trois niveaux, certains composants peuvent se trouver en dehors du périmètre. Le niveau de présentation qui autorise l'entrée du trafic utilisateur peut être un projet situé en dehors du périmètre, et les niveaux d'application et de données contenant des données sensibles peuvent être des projets distincts à l'intérieur du périmètre de service. Vous définissez des règles d'entrée et de sortie vers le périmètre afin que les niveaux puissent communiquer sur le périmètre avec un accès précis.

Utilisez cette option lorsque les conditions suivantes sont remplies :

  • Seuls les projets limités et bien définis contiennent des données sensibles. D'autres projets contiennent des données à faible risque.
  • Certaines charges de travail sont internes uniquement, mais d'autres nécessitent des accès à l'Internet public ou dépendent de services non compatibles avec VPC Service Controls.
  • La configuration de VPC Service Controls pour tous les projets entraîne une surcharge trop importante ou nécessite trop de solutions de contournement.

Évitez cette option lorsque de nombreux projets peuvent contenir des données sensibles.

Pour en savoir plus, consultez la page Bonnes pratiques pour activer VPC Service Controls.

Option 3 : Ne pas configurer VPC Service Controls

Au lieu de configurer VPC Service Controls à l'échelle de votre environnement, vous pouvez choisir de ne pas l'utiliser, en particulier si les coûts opérationnels dépassent sa valeur.

Par exemple, votre organisation peut ne pas disposer d'un modèle cohérent d'accès des développeurs pouvant constituer la base d'une règle d'entrée. Vos opérations informatiques sont peut-être sous-traitées à plusieurs tiers. Par conséquent, les développeurs ne disposent pas d'appareils gérés ni d'un accès à partir d'adresses IP cohérentes. Dans ce scénario, il est possible que vous ne puissiez pas définir de règles d'entrée pour autoriser les exceptions au périmètre dont les développeurs ont besoin pour effectuer leurs opérations quotidiennes.

Utilisez cette option lorsque :

  • vous utilisez des services non compatibles avec VPC Service Controls ;
  • les charges de travail sont Web et ne contiennent pas de données sensibles ;
  • vous ne disposez pas d'attributs cohérents pour l'accès des développeurs, tels que des appareils gérés ou des plages d'adresses IP connues.

Évitez cette option lorsque vous avez des données sensibles dans votre environnement Google Cloud.

Comment surveiller en permanence les configurations et les menaces non sécurisées

L'adoption de services cloud présente de nouveaux défis et menaces par rapport à l'utilisation de services sur site. Vos outils existants qui surveillent les serveurs de longue durée peuvent ne pas convenir à l'autoscaling ou aux services éphémères, et risquent de ne pas surveiller les ressources sans serveur. Par conséquent, vous devez évaluer les outils de sécurité qui fonctionnent par rapport à la gamme complète de services cloud que vous pouvez adopter. Vous devez également surveiller en permanence les normes cloud sécurisées, telles que les benchmarks CIS pour Google Cloud.

Les sections suivantes décrivent les options de surveillance continue. Nous recommandons l'option 1 pour la plupart des cas d'utilisation. Les autres options décrites dans les sections suivantes sont des alternatives que vous pouvez envisager si l'option 1 ne s'applique pas à votre cas d'utilisation spécifique.

Option 1 : Utiliser Security Command Center Premium

Nous vous recommandons d'activer le niveau Premium de Security Command Center au niveau de l'organisation, ce qui vous permet de renforcer votre stratégie de sécurité en procédant comme suit :

  • Analyse votre niveau de sécurité et déterminer à quel point vos données sont exposées aux attaques
  • Fournit l'inventaire et la découverte des éléments
  • Identifie les erreurs de configuration, les failles et les menaces
  • Aide à limiter les risques et à les corriger

Lorsque vous activez Security Command Center au début de la création de votre zone de destination, l'équipe de sécurité de votre organisation dispose d'une visibilité en quasi-temps réel des configurations, des menaces et des options de résolution non sécurisées. Cette visibilité permet à votre équipe de sécurité de déterminer si la zone de destination répond à ses exigences et est prête à permettre aux développeurs de commencer à déployer des applications.

Utilisez cette option lorsque les conditions suivantes sont remplies :

  • Vous souhaitez disposer d'un outil de gestion de la stratégie de sécurité et de détection des menaces qui est intégré à tous les services Google Cloud sans effort d'intégration supplémentaire.
  • Vous souhaitez utiliser les mêmes fonctionnalités de détection des menaces, de machine learning et d'autres méthodes avancées que Google utilise pour protéger ses propres services.
  • Votre centre d'opérations de sécurité (SOC) existant ne dispose pas des compétences ou de la capacité nécessaires pour générer des insights sur les menaces à partir d'un grand volume de journaux cloud.

Évitez cette option lorsque vos outils de sécurité existants peuvent gérer entièrement les ressources cloud éphémères ou sans serveur, surveiller les configurations non sécurisées et identifier les menaces à grande échelle dans un environnement cloud.

Option 2 : Utiliser vos outils de sécurité existants pour gérer la stratégie de sécurité et la détection des menaces dans le cloud

Comme alternative à l'utilisation de Security Command Center Premium, vous pouvez envisager d'autres outils de gestion pour la stratégie de sécurité cloud. Divers outils tiers existent dont les fonctions sont semblables à celles de Security Command Center, et vous avez peut-être déjà investi dans des outils cloud natifs axés sur les environnements multicloud.

Vous pouvez également utiliser Security Command Center avec des outils tiers. Par exemple, vous pouvez ingérer les notifications de résultats de Security Command Center dans un autre outil, ou ajouter un service de sécurité tiers au tableau de bord Security Command Center. Autre exemple : vous devez peut-être stocker les journaux sur un système SIEM existant afin que l'équipe SOC l'analyse pour détecter les menaces. Vous pouvez configurer votre solution SIEM existante pour n'ingérer que les notifications de résultats générées par Security Command Center, au lieu d'ingérer un grand volume de journaux et d'attendre qu'une équipe SOC analyse les données brutes pour en obtenir des insights.

Utilisez cette option lorsque vos outils de sécurité existants peuvent gérer entièrement les ressources cloud éphémères ou sans serveur, surveiller les configurations non sécurisées et identifier les menaces à grande échelle dans un environnement cloud.

Évitez cette conception lorsque les conditions suivantes sont remplies :

  • Votre SOC existant ne dispose pas des compétences ou de la capacité nécessaires pour générer des insights sur les menaces à partir du vaste volume de journaux cloud.
  • L'intégration de plusieurs outils tiers à plusieurs services Google Cloud apporte plus de complexité que de valeur.

Pour en savoir plus, consultez les ressources suivantes :

Comment agréger de manière centralisée les journaux nécessaires

La plupart des journaux d'audit sont stockés dans le projet Google Cloud qui les a générés. À mesure que votre environnement se développe, il peut être impossible pour un auditeur de vérifier les journaux de chaque projet. Par conséquent, vous devez décider de la façon dont les journaux seront centralisés et agrégés afin de faciliter vos opérations internes d'audit et de sécurité.

Les sections suivantes décrivent les options d'agrégation de journaux. Nous recommandons l'option 1 pour la plupart des cas d'utilisation. Les autres options décrites dans les sections suivantes sont des alternatives que vous pouvez envisager si l'option 1 ne s'applique pas à votre cas d'utilisation spécifique.

Option 1 : Conserver les journaux dans Google Cloud à l'aide de récepteurs de journaux agrégés

Nous vous recommandons de configurer un récepteur de journaux centralisé à l'échelle de l'entreprise pour les journaux d'audit et les autres journaux requis par votre équipe de sécurité. Vous pouvez référencer l'outil champ d'application des journaux pour identifier les journaux requis par votre équipe de sécurité et déterminer si ces types de journaux nécessitent une activation explicite.

Par exemple, l'équipe de sécurité attend un enregistrement central de toutes les ressources créées par vos utilisateurs afin de pouvoir surveiller et examiner les modifications suspectes. L'équipe de sécurité requiert également un enregistrement immuable des accès aux données pour certaines charges de travail très sensibles. Elle configure donc un récepteur de journaux pour agréger les journaux d'audit des activités d'administration de tous les projets dans un bucket d'analyse de journaux d'un projet central qu'elle peut afficher pour les enquêtes impromptues. Elles configurent ensuite un deuxième récepteur de journaux pour les journaux d'audit d'accès aux données des projets contenant des charges de travail sensibles dans un bucket Cloud Storage afin de les conserver à long terme.

Utilisez cette option lorsque les conditions suivantes sont remplies :

  • Votre équipe de sécurité attend un enregistrement central de tous les journaux d'audit ou d'autres types de journaux spécifiques.
  • Elle doit stocker les journaux dans un environnement dont l'accès est limité, en dehors du contrôle de la charge de travail ou des équipes qui les ont générés.

Évitez cette option lorsque les conditions suivantes sont remplies : - Votre organisation n'a pas d'exigence centrale pour les journaux d'audit cohérents entre les charges de travail. - Les propriétaires de projet individuels sont entièrement responsables de la gestion de leurs propres journaux d'audit.

Pour en savoir plus, consultez les ressources suivantes :

Option 2 : Exporter les journaux d'audit requis vers un espace de stockage en dehors de Google Cloud

Au lieu de stocker les journaux dans Google Cloud, envisagez d'exporter les journaux d'audit en dehors de Google Cloud. Une fois que vous avez centralisé les types de journaux nécessaires dans un récepteur de journaux agrégés dans Google Cloud, intégrez le contenu de ce récepteur sur une autre plate-forme en dehors de Google Cloud pour le stockage et l'analyse des journaux.

Par exemple, vous pouvez utiliser une solution SIEM tierce pour agréger et analyser les journaux d'audit de plusieurs fournisseurs cloud. Cet outil dispose de capacités suffisantes pour travailler avec des ressources cloud sans serveur, et votre équipe SOC dispose des compétences et de la capacité nécessaires pour générer des insights à partir de ce grand volume de journaux.

Cette option peut être très coûteuse en raison des coûts de sortie réseau dans Google Cloud, ainsi que des coûts de stockage et de capacité dans l'autre environnement. Plutôt que d'exporter chaque journal disponible, nous vous recommandons de sélectionner les journaux requis dans l'environnement externe.

Utilisez cette option lorsque vous devez stocker les journaux de tous les environnements et fournisseurs cloud dans un emplacement central unique.

Évitez cette conception lorsque les conditions suivantes sont remplies :

  • Vos systèmes existants ne disposent pas de la capacité ou du budget nécessaire pour ingérer un volume important de journaux cloud supplémentaires.
  • Vos systèmes existants nécessitent des efforts d'intégration pour chaque type et format de journal.
  • Vous collectez des journaux sans objectif clair sur la manière dont ils seront utilisés.

Pour en savoir plus, consultez les ressources suivantes :

Comment satisfaire les exigences de conformité de chiffrement au repos

Google Cloud chiffre automatiquement tous vos contenus stockés au repos à l'aide d'un ou de plusieurs mécanismes. En fonction de vos exigences de conformité, vous devrez peut-être gérer vous-même les clés de chiffrement.

Les sections suivantes décrivent les options de chiffrement au repos. Nous recommandons l'option 1 pour la plupart des cas d'utilisation. Les autres options décrites dans les sections suivantes sont des alternatives que vous pouvez envisager si l'option 1 ne s'applique pas à votre cas d'utilisation spécifique.

Option 1 : Autoriser l'utilisation du chiffrement au repos par défaut

L'option de chiffrement au repos par défaut est suffisante dans de nombreux cas d'utilisation qui ne présentent pas d'exigences de conformité particulières concernant la gestion des clés de chiffrement.

Par exemple, l'équipe de sécurité d'une entreprise de jeux en ligne exige que toutes les données client soient chiffrées au repos. Ils n'ont pas d'exigences réglementaires concernant la gestion des clés. Après avoir examiné le chiffrement au repos par défaut de Google, ils considèrent qu'il s'agit d'un contrôle suffisant pour leurs besoins.

Utilisez cette option lorsque les conditions suivantes sont remplies :

  • Vous n'avez pas d'exigences particulières concernant le chiffrement des données ou la gestion des clés de chiffrement.
  • Vous préférez un service géré plutôt que d'encourir des coûts et des frais opérationnels supplémentaires liés à gestion de vos propres clés de chiffrement.

Évitez cette option lorsque vous devez gérer vos propres clés de chiffrement en raison d'exigences de conformité.

Pour plus d'informations, consultez la section Chiffrement au repos dans Google Cloud.

Option 2 : Gérer les clés de chiffrement à l'aide de Cloud KMS

En plus du chiffrement au repos par défaut, vous avez peut-être besoin de davantage de contrôle sur les clés utilisées pour chiffrer les données au repos dans un projet Google Cloud. Cloud Key Management Service (Cloud KMS) permet de protéger vos données à l'aide de clés de chiffrement gérées par le client (CMEK). Par exemple, dans le secteur des services financiers, vous devez peut-être préciser à vos auditeurs externes comment vous gérez vos propres clés de chiffrement pour les données sensibles.

Pour obtenir des couches de contrôle supplémentaires, vous pouvez configurer des modules de sécurité matériels (HSM) ou une gestion des clés externes (EKM) avec CMEK. Les clés de chiffrement fournies par le client (CSEK) ne sont pas recommandées. Les scénarios qui étaient traditionnellement traités par CSEK sont désormais mieux pris en charge par Cloud External Key Manager (Cloud EKM). En effet, Cloud EKM est compatible avec davantage de services et avec une plus grande disponibilité.

Cette option confère aux développeurs d'applications la responsabilité de suivre la gestion des clés requise par votre équipe de sécurité. L'équipe de sécurité peut appliquer l'exigence en bloquant la création de ressources non conformes avec les règles d'administration CMEK.

Utilisez cette option lorsqu'une ou plusieurs des conditions suivantes sont remplies :

  • Vous devez gérer le cycle de vie de vos propres clés.
  • Vous devez générer du matériel de clé cryptographique avec un HSM certifié FIPS 140-2 de niveau 3.
  • Vous devez stocker le matériel de clé cryptographique en dehors de Google Cloud à l'aide de Cloud EKM.

Évitez cette conception lorsque les conditions suivantes sont remplies :

  • Vous n'avez pas d'exigences spécifiques concernant le chiffrement des données ou la gestion des clés de chiffrement.
  • Vous préférez un service géré plutôt que d'encourir des coûts et des frais opérationnels supplémentaires liés à gestion de vos propres clés de chiffrement.

Pour en savoir plus, consultez les ressources suivantes :

Option 3 : Tokeniser les données au niveau de la couche d'application avant de les conserver dans l'espace de stockage

En plus du chiffrement par défaut fourni par Google, vous pouvez également développer votre propre solution pour tokeniser les données avant de les stocker dans Google Cloud.

Par exemple, un data scientist doit analyser un ensemble de données contenant des informations permettant d'identifier l'utilisateur, mais il ne doit pas avoir accès aux données brutes de certains champs sensibles. Pour limiter l'accès de contrôle aux données brutes, vous pouvez développer un pipeline d'ingestion avec la protection des données sensibles afin d'ingérer et de tokeniser les données sensibles, puis conserver les données tokenisées dans BigQuery.

La tokenisation des données n'est pas un contrôle que vous pouvez appliquer de manière centralisée dans la zone de destination. Au lieu de cela, cette option transfère la responsabilité aux développeurs d'applications de configurer leur propre chiffrement, ou à une équipe de la plate-forme qui développe un pipeline de chiffrement en tant que service partagé que les développeurs d'applications peuvent utiliser.

Utilisez cette option lorsque certaines charges de travail contiennent des données très sensibles qui ne doivent pas être utilisées sous leur forme brute.

Évitez cette option lorsque Cloud KMS est suffisant pour répondre à vos exigences, comme décrit dans la section Gérer les clés de chiffrement à l'aide de Cloud KMS. Le transfert des données via des pipelines de chiffrement et de déchiffrement supplémentaires augmente les coûts, la latence et la complexité des applications.

Pour en savoir plus, consultez les ressources suivantes :

Comment satisfaire les exigences de conformité de chiffrement en transit

Google Cloud met en œuvre plusieurs mesures de sécurité pour assurer l'authenticité, l'intégrité et la confidentialité des données en transit. En fonction de vos exigences en termes de sécurité et de conformité, vous pouvez également configurer le chiffrement de la couche d'application.

Les sections suivantes décrivent les options de chiffrement en transit. Nous recommandons l'option 1 pour la plupart des cas d'utilisation. L'autre option décrite dans les sections suivantes est une fonctionnalité supplémentaire que vous pouvez envisager si l'option 1 est insuffisante pour votre cas d'utilisation spécifique.

Option 1 : Déterminer si le chiffrement en transit par défaut est suffisant

De nombreux modèles de trafic bénéficient du chiffrement en transit par défaut de Google sans nécessiter de configuration supplémentaire. Tout le trafic de VM à VM dans un réseau VPC et des réseaux VPC connectés est chiffré au niveau de la couche 3 ou de la couche 4. Le trafic provenant d'Internet vers les services Google s'arrête au niveau de Google Front End (GFE). GFE effectue également les opérations suivantes :

  • Interrompt le trafic de proxy HTTP(S), TCP et TLS entrant
  • Applique des contre-mesures contre les attaques DDoS
  • Gère le routage et l'équilibrage de charge du trafic vers les services Google Cloud

Par exemple, si vous concevez une application interne sans serveur à l'aide des API Google, tous les chemins réseau des services utiliseront automatiquement le chiffrement en transit par défaut. Il n'est pas nécessaire de configurer un chiffrement supplémentaire dans les contrôles de transit pour que le trafic soit chiffré.

Utilisez cette option lorsque le chiffrement en transit par défaut de Google est suffisant pour vos charges de travail internes.

Évitez cette conception lorsque les conditions suivantes sont remplies :

  • Vous avez besoin de chiffrement pour tout le trafic sur Cloud Interconnect.
  • Vous autorisez le trafic Internet entrant dans votre réseau VPC.
  • Vous avez besoin d'un chiffrement de couche 7 en transit entre toutes les ressources de calcul internes.

Dans ces cas, vous devez configurer des contrôles supplémentaires, comme indiqué dans Option 2 : Exiger la configuration du chiffrement de couche 7 en transit pour les applications. Pour en savoir plus, consultez la page Chiffrement en transit dans Google Cloud.

Option 2 : Exiger la configuration du chiffrement de couche 7 en transit pour les applications

En plus du chiffrement en transit par défaut, vous pouvez configurer le chiffrement de couche 7 pour le trafic des applications. Google Cloud fournit des services gérés pour les applications nécessitant le chiffrement en transit de la couche d'application, y compris les certificats gérés, Anthos Service Mesh et Traffic Director.

Par exemple, un développeur crée une application qui accepte le trafic entrant provenant d'Internet. Il utilise un équilibreur de charge d'application avec des certificats SSL gérés par Google pour exécuter et faire évoluer les services derrière une seule adresse IP.

Le chiffrement de la couche d'application n'est pas un contrôle que vous pouvez appliquer de manière centralisée dans la zone de destination. À la place, cette option transfère aux développeurs d'applications la responsabilité de configurer le chiffrement en transit.

Utilisez cette option lorsque les applications nécessitent du trafic HTTPS ou SSL entre les composants.

Envisagez d'attribuer une exception limitée à cette option lorsque vous migrez des charges de travail de calcul vers le cloud qui n'exigeaient pas le chiffrement en transit précédemment pour le trafic interne lorsque les applications résidaient sur site. Lors d'une migration à grande échelle, le fait de forcer la modernisation des anciennes applications avant la migration peut entraîner un retard inacceptable pour le programme.

Pour en savoir plus, consultez les ressources suivantes :

Choisir les contrôles supplémentaires nécessaires pour gérer les accès du fournisseur de services cloud

La nécessité de vérifier les accès du fournisseur de services cloud peut poser problème lors de l'adoption du cloud. Google Cloud fournit plusieurs couches de contrôle qui permettent de vérifier les accès du fournisseur cloud.

Les sections suivantes décrivent les options de gestion des accès du FSC. Nous recommandons l'option 1 pour la plupart des cas d'utilisation. L'autre option décrite dans les sections suivantes est une fonctionnalité supplémentaire que vous pouvez envisager si l'option 1 est insuffisante pour votre cas d'utilisation spécifique.

Option 1 : Activer les journaux Access Transparency

Les journaux Access Transparency enregistrent les actions effectuées par le personnel de Google Cloud dans votre environnement, par exemple en cas de dépannage pendant une demande d'assistance.

Par exemple, votre développeur soumet une demande à Cloud Customer Care et l'assistance d'un agent pour l'aider à résoudre son problème. Un journal Access Transparency est généré pour consigner les actions entreprises par le personnel d'assistance, y compris le numéro de la demande d'assistance qui les justifie.

Utilisez cette option lorsque les conditions suivantes sont remplies :

  • Vous devez vérifier que le personnel de Google Cloud n'accède à votre contenu que pour des raisons professionnelles valables, telles que la résolution d'une panne ou le traitement de vos demandes d'assistance.
  • Vous avez des exigences de conformité pour suivre l'accès aux données sensibles.

Option 2 : Activer les journaux Access Transparency et la gestion des accès des fournisseurs

Si votre entreprise a des exigences de conformité visant à accorder une approbation explicite avant qu'un fournisseur de services cloud puisse accéder à votre environnement, vous pouvez, en plus de l'option 1, utiliser Access Transparency avec d'autres contrôles qui vous permettent d'approuver ou de refuser l'accès à vos données de manière explicite.

Access Approval est une solution manuelle qui garantit que le service client et les ingénieurs Google doivent demander votre approbation explicite préalable (par e-mail ou via un webhook) chaque fois qu'ils doivent accéder à votre contenu.

Key Access Justifications est une solution programmatique qui ajoute un champ de justification à toutes les requêtes de clés de chiffrement configurées avec Cloud EKM.

Utilisez cette option lorsque les conditions suivantes sont remplies :

  • Vous souhaitez qu'une équipe centrale gère directement les accès du personnel de Google à votre contenu.
  • Pour Access Approval, vous pouvez accepter le risque que la fonctionnalité centralisée d'approbation ou de refus de chaque demande d'accès soit plus importante que le compromis opérationnel, ce qui peut ralentir la résolution des demandes d'assistance.
  • Pour Key Access Justifications, votre entreprise utilise déjà Cloud External Key Manager dans le cadre de sa stratégie de chiffrement, et souhaite contrôler de manière automatisée tous les types d'accès aux données chiffrées, et pas seulement l'accès aux données du personnel de Google.

Évitez cette conception lorsque les conditions suivantes sont remplies :

  • Le retard opérationnel pouvant se produire lorsqu'une équipe centrale ayant l'autorité Access Approval doit répondre est un risque inacceptable pour les charges de travail qui nécessitent une haute disponibilité et une réponse rapide du service client.

Pour en savoir plus, consultez les ressources suivantes :

Bonnes pratiques de sécurité pour les zones de destination Google Cloud

Outre les décisions introduites dans ce document, tenez compte des bonnes pratiques de sécurité suivantes :

Étapes suivantes