Présentation de la sécurité dans Cloud Service Mesh

La sécurité de Cloud Service Mesh vous aide à limiter les menaces internes et à réduire le nombre risque de violation des données en s'assurant que toutes les communications entre les charges de travail sont chiffrés, s'authentifient et sont autorisés.

Traditionnellement, la microsegmentation utilisant des règles basées sur l'adresse IP permet d'atténuer les risques internes. Toutefois, l'adoption de conteneurs, de services partagés et d'environnements de production distribués répartis sur plusieurs clouds rend cette approche plus difficile à configurer et même plus difficile à gérer.

Avec Cloud Service Mesh, vous pouvez configurer une couche de service contextuel et demander une sécurité réseau contextuelle indépendante de la sécurité du réseau sous-jacent. C'est pourquoi Cloud Service Mesh vous permet d'adopter une stratégie de défense en profondeur cohérente avec le modèle de sécurité zéro confiance ces principes. Il vous permet d'atteindre cet objectif via des stratégies déclaratives et sans modifier le code d'application.

TLS mutuel

Cloud Service Mesh utilise l'authentification TLS mutuelle (mTLS) pour l'authentification des pairs. L'authentification fait référence à l'identité : qui est le service ? Qui est cet utilisateur final ? Et puis-je me fier à leur identité ?

mTLS permet aux charges de travail de valider leurs identités et de s'authentifier entre elles. Vous connaissez peut-être déjà le protocole TLS simple utilisé dans HTTPS pour permettre aux navigateurs d'approuver des serveurs Web et de chiffrer les données échangées. Lorsque le protocole TLS simple est utilisé, le client établit que le serveur est digne de confiance en validant son certificat. mTLS est une mise en œuvre de TLS dans laquelle le client et le serveur se présentent des certificats et vérifient leurs identités respectives.

mTLS est le moyen par lequel Cloud Service Mesh met en œuvre à la fois l'authentification et chiffrement entre les services.

Dans Cloud Service Mesh 1.6 et versions ultérieures, l'authentification mTLS automatique est activée par défaut. L'authentification mTLS permet à un proxy side-car client de détecter automatiquement si le serveur possède un side-car. Le side-car client envoie l'authentification mTLS aux charges de travail avec des side-cars, et envoie du texte brut aux charges de travail sans side-car. Notez toutefois que les services acceptent à la fois le trafic en texte brut et le trafic mTLS. Pour sécuriser votre maillage de services, nous vous recommandons de migrer vos services pour n'accepter que le trafic mTLS.

Pour en savoir plus sur l'application exclusive de mTLS, consultez Cloud Service Mesh, par exemple: mTLS.

Configuration de la suite de chiffrement

La liste suivante inclut l'algorithme de chiffrement par défaut conforme à la norme FIPS de Cloud Service Mesh suites:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

Pour renforcer la sécurité, la version TLS minimale côté serveur compatible avec Les charges de travail Cloud Service Mesh sont en version 1.2, qui prend en charge la personnalisation des suites de chiffrement. Notez que Cloud Service Mesh est également compatible avec TLS v1.3, qui code en dur les suites de chiffrement et ne permet pas de les modifier.

Pour plus d’informations sur les suites de chiffrement, consultez la configuration TLS commune d'Envoy et Authentification TLS mutuelle d'Istio.

Avantages de sécurité

Cloud Service Mesh offre les avantages de sécurité suivants:

  • Atténue le risque de nouvelle lecture ou d'usurpation d'identité qui utilisent des identifiants volés. Cloud Service Mesh s'authentifie sur des certificats mTLS des jetons d'appairage, et non des jetons de support Jetons Web JSON (JWT). Les certificats mTLS étant liés au canal TLS, il n'est pas possible qu'une entité de votre environnement de production procède à une usurpation d'identité en renouvelant le jeton d'authentification sans accéder aux clés privées.

  • Assure le chiffrement en transit. L'utilisation de mTLS pour l'authentification garantit également que toutes les communications TCP sont chiffrées en transit.

  • Garantit que seuls les clients autorisés peuvent accéder à un service contenant des données sensibles. Seuls les clients autorisés peuvent accéder à un service contenant des données sensibles, indépendamment de l'emplacement réseau du client et des identifiants au niveau de l'application. Vous pouvez spécifier que seuls les clients disposant d'identités de service autorisés ou dans les espaces de noms Kubernetes autorisés peuvent accéder à un service. Vous pouvez utilisent également des stratégies d'accès basées sur les adresses IP pour accorder l'accès aux clients déployés hors de dans l'environnement GKE Enterprise.

  • Atténue le risque de violation des données utilisateur sur votre réseau de production. Vous pouvez vous assurer que les initiés ne peuvent accéder aux données sensibles que via des clients autorisés. De plus, vous pouvez faire en sorte que certains clients ne puissent accéder aux informations sur l'utilisateur que s'ils peuvent présenter un jeton utilisateur valide et de courte durée. Cela réduit le risque que les identifiants d'un client accordent à un pirate informatique l'accès à toutes les informations sur l'utilisateur.

  • Identifie les clients ayant accédé à un service avec des données sensibles. La journalisation des accès à Cloud Service Mesh capture l'identité mTLS du client dans en plus de l'adresse IP. Ainsi, vous pouvez facilement déterminer quelle charge de travail a accédé à un service, même si elle est éphémère et déployée de manière dynamique, et dans un autre cluster ou sur un réseau VPC (cloud privé virtuel).

Fonctionnalités

Cette section décrit les fonctionnalités fournies par Cloud Service Mesh pour réaliser et ses avantages en termes de sécurité.

Certificat automatique et rotation des clés

L'utilisation de mTLS basée sur les identités de service permet de chiffrer toutes les communications TCP et fournit des identifiants plus sécurisés et ne pouvant être relus pour le contrôle des accès. L'un des principaux défis de l'utilisation de mTLS à grande échelle est la gestion des clés et des certificats pour toutes les charges de travail cibles. Cloud Service Mesh s'occupe de la rotation Clés et certificats mTLS pour les charges de travail GKE Enterprise sans interruption les communications. Vous pouvez configurer des intervalles d'actualisation plus restreints réduire les risques.

Autorité de certification Cloud Service Mesh

Cloud Service Mesh inclut un certificat privé multirégional géré l'autorité de certification Cloud Service Mesh, qui permet d'émettre des certificats pour mTLS. L'autorité de certification Cloud Service Mesh est un service hautement fiable et évolutif optimisé pour les charges de travail à scaling dynamique sur une plate-forme cloud. Avec l'autorité de certification Cloud Service Mesh, Google gère la sécurité et la disponibilité backend de l'autorité de certification. L'autorité de certification Cloud Service Mesh vous permet de vous fier à une seule racine de confiance sur les clusters GKE Enterprise. Lorsque vous utilisez l'autorité de certification Cloud Service Mesh, vous pouvez s'appuient sur des pools d'identités de charge de travail pour fournir une isolation sommaire. Par par défaut, l'authentification échoue si le client et le serveur ne font pas partie du même pool d'identités de charge de travail.

Les certificats de l'autorité de certification Cloud Service Mesh incluent les données suivantes sur les services de votre application:

  • L'ID de projet Google Cloud
  • L'espace de noms GKE
  • Le nom du compte de service GKE

Certificate Authority Service

Au lieu de l'autorité de certification Cloud Service Mesh, vous pouvez configurer Cloud Service Mesh peut utiliser Certificate Authority Service, qui convient les cas d'utilisation suivants:

  • Vous avez besoin de plusieurs autorités de certification différentes pour signer des certificats de charge de travail sur différents clusters.
  • Vous souhaitez utiliser des certificats de plug-in d'autorités de certification personnalisées Istiod.
  • Vous devez sauvegarder vos clés de signature dans un HSM géré.
  • Vous travaillez dans un secteur hautement réglementé et vous êtes soumis à des exigences de conformité.
  • Si vous souhaitez associer votre CA Cloud Service Mesh à une autorité de certification d'entreprise personnalisée certificat racine pour signer les certificats de charge de travail.

Le coût de l'autorité de certification de Cloud Service Mesh est inclus dans le Cloud Service Mesh pricing. Le service CA n'est pas inclus dans le package de base Cloud Service Mesh, facturé séparément. En outre, CA fait l'objet d'un SLA explicite, mais Ce n'est pas le cas de l'autorité de certification de Cloud Service Mesh.

Pour cette intégration, toutes les charges de travail dans Cloud Service Mesh se voient accorder deux Rôles IAM:

Stratégies de contrôle de l'accès selon l'identité (pare-feu)

Avec Cloud Service Mesh, vous pouvez configurer des règles de sécurité réseau en fonction de l'identité mTLS par rapport à l'adresse IP du pair. Cela vous permet de créer des règles indépendantes de l'emplacement réseau de la charge de travail. Seules les communications entre les clusters d'un même projet Google Cloud sont actuellement compatibles.

Demander des stratégies de contrôle d'accès compatibles avec les revendications (pare-feu)

En plus de l'identité mTLS, vous pouvez accorder un accès basé sur les revendications de requête dans l'en-tête JWT des requêtes HTTP ou gRPC. Cloud Service Mesh vous permet d'affirmer qu'un jeton JWT est signé par une entité de confiance. Cela signifie que vous ne pouvez configurer des règles qui autorisent l'accès de certains clients que si une revendication de requête existe ou correspond à une valeur spécifiée.

Authentification des utilisateurs avec Identity-Aware Proxy

Vous authentifiez les utilisateurs qui accèdent à n'importe quel service exposé sur une la passerelle d'entrée Cloud Service Mesh à l'aide de Identity-Aware Proxy (IAP) : IAP peut authentifier les utilisateurs qui se connectent à partir d'un navigateur, s'intègrent à des fournisseurs d'identité personnalisés, et émettre un jeton JWT de courte durée ou un jeton RCToken qui peuvent ensuite être utilisés pour accorder l'accès à la passerelle d'entrée ou un service en aval (en utilisant un side-car). Pour en savoir plus, consultez Intégrer IAP à Cloud Service Mesh

Authentification des utilisateurs avec votre fournisseur d'identité existant

Vous pouvez intégrer votre fournisseur d'identité existant à Cloud Service Mesh pour fournir l'authentification des utilisateurs finaux sur navigateur et le contrôle des accès charges de travail. Pour en savoir plus, consultez Configurer l'authentification des utilisateurs dans Cloud Service Mesh

Journalisation et surveillance des accès

Cloud Service Mesh s'assure que les journaux et les métriques d'accès sont disponibles Google Cloud Observability et offre un tableau de bord intégré pour comprendre les modèles d'accès à un service ou à une charge de travail basés sur ces données. Vous pouvez également choisir de configurer une destination privée. Cloud Service Mesh permet vous réduisez le bruit dans les journaux d'accès en n'enregistrant que les accès réussis une seule fois par période configurable. Les requêtes refusées par une règle de sécurité ou qui génèrent une erreur sont toujours consignées. Vous pouvez ainsi réduire considérablement les coûts associés à l'ingestion, au stockage et au traitement des journaux, sans perte des signaux de sécurité clés.

Conformité avec la norme FIPS

Tous les composants du plan de contrôle et proxys du cluster sur l'architecture x86 utilisent Chiffrement validé FIPS 140-2 modules.

Limites

La sécurité de Cloud Service Mesh présente actuellement les limites suivantes:

  • L'authentification de l'utilisateur qui utilise IAP nécessite la publication d'un service sur Internet. IAP et Cloud Service Mesh vous permettent configurer des stratégies pouvant limiter l'accès aux utilisateurs et aux clients autorisés dans une la plage d'adresses IP autorisée. Si vous choisissez de n'exposer le service qu'aux clients du même réseau, vous devez configurer un moteur de règles personnalisées pour l'authentification des utilisateurs et l'émission des jetons.

Étape suivante