Bonnes pratiques de sécurité pour Cloud Service Mesh

Ce document décrit les bonnes pratiques pour établir et régir une configuration Cloud Service Mesh sécurisée exécutée sur Google Kubernetes Engine (GKE). Les instructions de ce document vont au-delà des paramètres utilisés pour configurer et installer Cloud Service Mesh et expliquent comment vous pouvez utiliser Cloud Service Mesh avec d'autres produits et fonctionnalités Google Cloud pour vous protéger contre les menaces de sécurité auxquelles les applications dans un réseau maillé peuvent faire face.

Ce document est destiné aux administrateurs qui gèrent les règles dans un maillage de services cloud et les utilisateurs qui exécutent des services dans Cloud Service Mesh. Les mesures de sécurité décrites ici sont également utiles pour les organisations qui doivent renforcer la sécurité de leurs maillages de services afin de répondre aux exigences de conformité.

Le document est organisé comme suit :

Présentation

Cloud Service Mesh fournit des fonctionnalités et des outils qui vous aident à observer, gérer des services sécurisés de manière unifiée. Il adopte une approche centrée sur les applications et utilise des identités d'application approuvées plutôt qu'une approche basée sur l'adresse IP du réseau. Vous pouvez déployer un maillage de services de manière transparente, sans avoir à modifier le code d'application existant. Cloud Service Mesh fournit un contrôle déclaratif sur le réseau ce qui permet de dissocier le travail des équipes chargées la livraison et la publication de fonctionnalités d'application qui relèvent de la responsabilité administrateurs responsables de la sécurité et de la mise en réseau.

Cloud Service Mesh est basé sur le modèle Open Source Maillage de services Istio, qui : permet des configurations et des topologies sophistiquées. Selon la structure de votre organisation, une ou plusieurs équipes ou rôles peuvent être chargés d'installer et de configurer un réseau maillé. Les paramètres par défaut de Cloud Service Mesh sont sélectionnés pour protéger les applications, mais dans certains cas, vous devrez peut-être des configurations personnalisées ou d'accorder des exceptions en excluant certaines applications, certains ports ou IP d'un réseau maillé. Il est important de mettre en place des contrôles pour régir les configurations des réseaux maillés et les exceptions de sécurité.

Vecteurs d'attaque et risques de sécurité

Vecteurs d'attaque

La sécurité de Cloud Service Mesh suit le modèle de sécurité zéro confiance, suppose que les menaces de sécurité proviennent de l'intérieur et de l'extérieur périmètre de sécurité de votre entreprise. Exemples de types d'attaques de sécurité pouvant menacer les applications dans un maillage de services incluent:

  • Les attaques par exfiltration de données Il peut s'agir, par exemple, d'attaques espionnant les données sensibles ou les identifiants émis par le trafic de service à service.
  • Les attaques MITM ("man in the middle"). Par exemple, un service malveillant qui se fait passer pour un service légitime pour obtenir ou modifier la communication entre les services.
  • Les attaques par élévation des privilèges. Il peut s'agir, par exemple, d'attaques utilisant un accès non autorisé à des privilèges élevés pour effectuer des opérations sur un réseau.
  • Les attaques par déni de service (DoS).
  • Les attaques Botnet, qui tentent de compromettre et de manipuler des services pour lancer des attaques sur d'autres services.

Les attaques peuvent également être classées en fonction des cibles des attaques :

  • Les attaques internes au réseau maillé. Les attaques visant à altérer, espionner ou usurper la communication service à service ou service à plan de contrôle interne au réseau maillé.
  • Les attaques au plan de contrôle. Les attaques visant à causer un dysfonctionnement du plan de contrôle (tel qu'une attaque DoS) ou à exfiltrer des données sensibles du plan de contrôle.
  • Les attaques en périphérie du réseau maillé. Les attaques visant à altérer, espionner ou usurper la communication au niveau de l'entrée ou de la sortie du réseau maillé.
  • Les attaques aux opérations du réseau maillé Les attaques visant les opérations du réseau maillé. Les pirates informatiques peuvent tenter d'obtenir des privilèges élevés pour effectuer des opérations malveillantes dans un réseau maillé, telles que la modification de ses règles de sécurité et de ses images de charge de travail.

Risques de sécurité

En plus des attaques de sécurité, un réseau maillé est également confronté à d'autres risques de sécurité. La liste suivante décrit quelques risques de sécurité possibles :

  • Protection de sécurité incomplète. Un maillage de services n'a pas été configuré avec des règles d'authentification et d'autorisation pour protéger sa sécurité. Par exemple, aucune règle d'authentification ou d'autorisation n'est définie pour les services d'un réseau maillé.
  • Exceptions aux règles de sécurité. Pour répondre à leurs cas d'utilisation spécifiques, les utilisateurs peuvent créer des exceptions aux règles de sécurité de Cloud Service Mesh afin d'exclure certains trafics (internes ou externes). Pour gérer ces cas de manière sécurisée, consultez la section Gérer les exceptions aux règles de manière sécurisée.
  • Oubli des mises à niveau d'image. Des failles peuvent être détectées au niveau des images utilisées dans un réseau maillé. Vous devez maintenir le composant du réseau maillé et les images de charge de travail à jour avec les derniers correctifs de failles.
  • Faible maintenance (aucune expertise ou ressource). Les configurations du logiciel et des règles du réseau maillé nécessitent une maintenance régulière pour tirer parti des derniers mécanismes de protection de sécurité.
  • Manque de visibilité. Les erreurs de configuration ou des configuration non sécurisée des règles du réseau maillé, ainsi que le trafic ou les opérations de réseau maillé anormal(es) ne sont pas signalés aux administrateurs du réseau maillé.
  • Écarts de configuration. La configuration des règles dans un réseau maillé diffère de la source de vérité.

Mesures pour protéger un maillage de services

Cette section présente un manuel d'exploitation pour sécuriser les maillages de services.

Architecture de sécurité

La sécurité d'un maillage de services dépend de la sécurité des composants au niveau des différentes couches du système du réseau maillé et de ses applications. Le haut niveau de la stratégie de sécurité proposée pour Cloud Service Mesh est de sécuriser le maillage de services via l'intégration de plusieurs mécanismes de sécurité à différents niveaux qui assurent conjointement la sécurité globale du système dans le cadre le modèle de sécurité. Le schéma suivant illustre la stratégie de sécurité proposée pour Cloud Service Mesh.

Stratégie de sécurité de Cloud Service Mesh

Cloud Service Mesh assure la sécurité à plusieurs couches, y compris:

  • Sécurité en périphérie du réseau maillé
    • La sécurité des entrées Cloud Service Mesh permet de contrôle des accès le trafic externe et sécurise l'accès externe aux API exposées par du réseau maillé.
    • La sécurité de sortie Cloud Service Mesh régule le trafic sortant des charges de travail internes.
    • L'authentification des utilisateurs de Cloud Service Mesh s'intègre à l'infrastructure Google pour authentifier les appels externes provenant de navigateurs Web vers les services qui exécutent des applications Web.
    • Gestion des certificats de passerelle Cloud Service Mesh protège et alterne les clés privées et les certificats X.509 utilisés par les passerelles d'entrée et de sortie Cloud Service Mesh utilisant Certificate Authority Service.
    • Cloud Armor peut vous défendre les attaques externes par déni de service distribué (DDoS) et de couche 7. Il sert de pare-feu d'application Web (WAF) pour protéger le réseau maillé contre les attaques de réseau. Il peut s'agir, par exemple, d'attaques par injection ou exécution de code à distance.
    • VPC et VPC Service Controls protègent le réseau périphérique via les contrôles des accès au réseau privé.
  • Sécurité du cluster
    • Le protocole TLS mutuel (mTLS) de Cloud Service Mesh applique le chiffrement et l'authentification du trafic de charge de travail à charge de travail.
    • L'autorité de certification gérée, telle que l'autorité de certification Cloud Service Mesh et Certificate Authority Service, provisionne et gère en toute sécurité les certificats utilisés par les charges de travail.
    • L'autorisation Cloud Service Mesh applique un contrôle d'accès aux services de maillage en fonction de leur identité et d'autres attributs.
    • Le tableau de bord de sécurité GKE Enterprise fournit une surveillance des configurations des règles de sécurité et des règles de réseau Kubernetes pour les charges de travail.
    • La règle de réseau Kubernetes applique un contrôle d'accès aux pods basé sur des adresses IP, des étiquettes de pods, des espaces de noms, etc.
    • La sécurité du plan de contrôle vous protège contre les attaques sur le plan de contrôle. Cette protection empêche les pirates informatiques de modifier, d'exploiter ou de divulguer des données de configuration du service et du réseau maillé.
  • Sécurité des charges de travail
    • Tenez-vous informé des versions de sécurité de Cloud Service Mesh pour vous assurer les binaires Cloud Service Mesh exécutés dans votre réseau maillé sont dépourvus les vulnérabilités connues publiquement.
    • Fédération d'identité de charge de travail pour GKE permet aux charges de travail d'obtenir des identifiants pour appeler en toute sécurité les services Google.
    • L'interface réseau de conteneur (CNI Kubernetes) empêche les privilèges les attaques de niveau supérieur en éliminant la nécessité Conteneur d'initialisation de Cloud Service Mesh.
  • Sécurité des opérateurs
    • Le contrôle des accès basé sur les rôles Kubernetes (RBAC) limite l'accès aux ressources Kubernetes et les autorisations des opérateurs afin de limiter les attaques provenant d'opérateurs malveillants ou de l'usurpation d'identité.
    • GKE Enterprise Policy Controller valide et audite les configurations de règles au sein du réseau maillé afin d'éviter les erreurs de configuration.
    • L'autorisation binaire Google Cloud garantit que les images de charge de travail du réseau maillé sont celles autorisées par les administrateurs.
    • Google Cloud Audit Logging audite les opérations du réseau maillé.

Le schéma ci-dessous illustre les flux de communication et de configuration avec les de sécurité intégrées à Cloud Service Mesh.

Flux de trafic du schéma de sécurité

Sécurité du cluster

Activer le protocole TLS mutuel strict

Une attaque MITM ("man in the middle") tente d'insérer une entité malveillante entre deux parties qui communiquent afin d'intercepter ou de manipuler la communication. Cloud Service Mesh protège contre les attaques MitM et d'exfiltration de données en appliquer Authentification et chiffrement mTLS pour toutes les parties qui communiquent. Le mode permissif utilise le protocole mTLS lorsque les deux côtés le permettent, mais autorise les connexions sans mTLS. En revanche, l'authentification mTLS en mode strict nécessite que le trafic soit chiffré et authentifié avec mTLS et n'autorise pas le trafic en texte brut.

Cloud Service Mesh vous permet de configurer la version TLS minimale pour les connexions TLS entre vos charges de travail afin de répondre à vos exigences de sécurité et de conformité.

Pour en savoir plus, consultez la page Anthos Service Mesh par exemple : mTLS | Appliquer le protocole mTLS au niveau du réseau maillé.

Activer les contrôles des accès

Les règles de sécurité Cloud Service Mesh (telles que l'authentification et l'autorisation règles) doivent être appliquées à tout le trafic entrant et sortant du réseau maillé, qui justifient efficacement l'exclusion d'un service ou d'un pod de Cloud Service Mesh règles de sécurité. Dans certains cas, les utilisateurs peuvent avoir des raisons légitimes de contourner Règles de sécurité Cloud Service Mesh pour certains ports et plages d'adresses IP Par exemple, pour établir des connexions natives avec des services non gérés par Cloud Service Mesh. Pour sécuriser Cloud Service Mesh dans ces cas d'utilisation, consultez la section Gérer les exceptions aux règles de Cloud Service Mesh de manière sécurisée.

Contrôle des accès aux services est essentiel pour empêcher tout accès non autorisé services. L'application mTLS chiffre et authentifie une requête, mais un réseau maillé a besoin Règles d'autorisation Cloud Service Mesh pour appliquer le contrôle des accès aux services. Par exemple, rejeter une requête non autorisée provenant d'un client authentifié.

Les règles d'autorisation Cloud Service Mesh offrent un moyen flexible de configurer des contrôles d’accès pour protéger vos services contre les accès non autorisés. Les règles d'autorisation Cloud Service Mesh doivent être appliquées en fonction identités authentifiées dérivées des résultats d'authentification : mTLS ou JSON Les authentifications basées sur les jetons Web (JWT) doivent être utilisées ensemble Règles d'autorisation Cloud Service Mesh

Appliquer des règles d'authentification Cloud Service Mesh

Jeton Web JSON (JWT)

En plus de l'authentification mTLS, les administrateurs de réseau maillé peuvent demander à un service d'authentifier et d'autoriser les requêtes basées sur JWT. Cloud Service Mesh n'agit pas en tant que fournisseur de jetons JWT, mais authentifie les jetons JWT. en fonction des points de terminaison JWKS configurés. Authentification JWT peuvent être appliquées aux passerelles d'entrée pour le trafic externe ou aux services internes ; pour le trafic des réseaux maillés. L'authentification JWT peut être combinée à l'authentification mTLS lorsqu'un jeton JWT est utilisé en tant qu'identifiant pour représenter l'appelant final, et que le service demandé nécessite de prouver qu'il est appelé pour le compte de l'appelant final. L'application de l'authentification JWT vous protège contre les attaques qui accèdent à un service sans identifiants valides et au nom d'un utilisateur final réel.

Authentification des utilisateurs dans Cloud Service Mesh

L'authentification des utilisateurs avec Cloud Service Mesh est une solution intégrée pour l'authentification des utilisateurs finaux via un navigateur et le contrôle des accès à vos charges de travail. Elle intègre un maillage de services à des fournisseurs d'identité (IdP) existants pour mettre en œuvre un flux de connexion et d'autorisation OpenID Connect (OIDC) standard et utilise les règles d'autorisation Cloud Service Mesh pour le contrôle des accès.

Appliquer des règles d'autorisation

Les règles d'autorisation Cloud Service Mesh contrôlent:

  • Les personnes ou les ressources autorisées à accéder à un service
  • Les ressources qui sont accessibles
  • Les opérations qui peuvent être effectuées sur les ressources autorisées

Les règles d'autorisation sont un moyen polyvalent de configurer le contrôle des accès en fonction des identités réelles exécutées par les services, des propriétés de la couche d'application (couche 7) du trafic (par exemple, des en-têtes de requête) et des propriétés de la couche réseau (couche 3 et couche 4) telles que les plages d'adresses IP et les ports.

Les règles d'autorisation Cloud Service Mesh doivent être appliquées en fonction d'identités authentifiées dérivées des résultats d'authentification pour se protéger contre tout accès non autorisé aux services ou aux données.

Par défaut, l'accès à un service doit être refusé, sauf si une règle d'autorisation est explicitement définie pour autoriser l'accès au service. Consultez la section Bonnes pratiques pour les règles d'autorisation pour obtenir des exemples de règles d'autorisation qui refusent les requêtes d'accès.

Les règles d'autorisation doivent limiter autant que possible la confiance. Par exemple, l'accès à un service peut être défini en fonction des chemins d'URL individuels exposés par un service, de sorte que seul un service A puisse accéder au chemin /admin d'un service B.

Les règles d'autorisation peuvent être utilisées avec les règles de réseau Kubernetes, qui ne fonctionnent qu'au niveau de la couche réseau (couche 3 et couche 4), et contrôlent l'accès au réseau pour les adresses IP et les ports sur les pods Kubernetes et les espaces de noms Kubernetes.

Appliquer l'échange de jetons pour accéder aux services de réseau maillé

Pour empêcher les attaques par répétition de jetons qui volent les jetons et les réutilisent pour accéder aux services de réseau maillé, un jeton d'une requête extérieure au réseau maillé doit être échangé contre un jeton interne au réseau maillé de courte durée en périphérie du réseau maillé.

Une requête extérieure au réseau maillé pour accéder à un service de réseau maillé doit inclure un jeton, tel que JWT ou un cookie, afin d'être authentifiée et autorisée par le service de réseau maillé. Un jeton extérieur au réseau maillé peut être de longue durée. Pour empêcher les attaques par répétition de jetons, un jeton extérieur au réseau maillé doit être échangé contre un jeton interne au réseau maillé et de courte durée avec un niveau d'accès limité en périphérie du réseau maillé. Le service de réseau maillé authentifie un jeton interne au réseau maillé et autorise la requête d'accès en fonction du jeton interne au réseau maillé.

Étape suivante