Cloud Service Mesh-Sicherheit – Übersicht

Mit der Cloud Service Mesh-Sicherheit können Sie Insiderbedrohungen abschwächen und die Risiko einer Datenpanne, da die gesamte Kommunikation zwischen den Arbeitslasten verschlüsselt, gegenseitig authentifiziert und autorisiert.

Bisher wurde die Mikrosegmentierung mit IP-basierten Regeln genutzt, um das Risiko der Datenweitergabe durch Insider zu verringern. Durch die Einführung von Containern, gemeinsam genutzten Diensten und verteilten Produktionsumgebungen über mehrere Clouds hinweg ist dieser Ansatz jedoch schwieriger zu konfigurieren und noch schwieriger zu pflegen.

Mit Cloud Service Mesh können Sie eine dienstkontextsensitive Ebene konfigurieren. und kontextsensitive Netzwerksicherheit anfordern, die unabhängig von der des zugrunde liegenden Netzwerks. Aus diesem Grund können Sie mit Cloud Service Mesh eine gestaffelte Sicherheitsebene anwenden, die den Zero-Trust-Sicherheitsgrundsätzen entspricht. Auf diese Weise können Sie diesen Sicherheitsstatus durch deklarative Richtlinien erreichen, ohne den Anwendungscode zu ändern.

Gegenseitiges TLS

Cloud Service Mesh verwendet gegenseitige TLS (mTLS) für die Peer-Authentifizierung. Authentifizierung bezieht sich auf die Identität: Wer ist ein Dienst? Wer ist dieser Endnutzer? und ich kann darauf vertrauen, dass sie das sind, wofür sie sich ausgeben?

Mit mTLS können Arbeitslasten die Identitäten des jeweils anderen prüfen und sich authentifizieren. Möglicherweise sind Sie mit einfachem TLS vertraut. Dies wird in HTTPS genutzt, um es Browsern zu ermöglichen, Webservern zu vertrauen und die ausgetauschten Daten zu verschlüsseln. Wenn einfaches TLS verwendet wird, stellt der Client fest, dass der Server als vertrauenswürdig eingestuft werden kann, indem er sein Zertifikat validiert. mTLS ist eine Implementierung von TLS, in der sowohl der Client als auch der Server Zertifikate bereitstellen und die Identität des jeweils anderen überprüft wird.

mTLS ist die Methode, mit der Cloud Service Mesh sowohl die Authentifizierung als auch die Verschlüsselung zwischen Diensten implementiert.

In Cloud Service Mesh 1.6 und höher ist automatisches mTLS standardmäßig aktiviert. Bei „automTLS“ erkennt ein Client-Sidecar-Proxy automatisch, ob der Server einen Sidecar hat. An Arbeitslasten mit Sidecars sendet der Client-Sidecar-Proxy mTLS und an Arbeitslasten ohne Sidecars sendet er Nur-Text-Traffic. Dienste akzeptieren sowohl Nur-Text- als auch mTLS-Traffic. Um Ihr Service Mesh zu sichern, empfehlen wir Ihnen, Ihre Dienste so zu migrieren, dass nur mTLS-Traffic akzeptiert wird.

Weitere Informationen zur Erzwingung nur von mTLS finden Sie unter Cloud Service Mesh am Beispiel: mTLS.

Cipher Suite-Konfiguration

Die folgende Liste enthält die standardmäßigen, FIPS-konformen Chiffren-Suiten von Cloud Service Mesh:

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

Für eine bessere Sicherheit ist die serverseitige TLS-Mindestversion, die von Cloud Service Mesh-Arbeitslasten unterstützt wird, 1.2. Diese Version unterstützt die Anpassung von Chiffrensammlungen. Cloud Service Mesh unterstützt auch TLS v1.3, bei dem die Chiffren-Suites hartcodiert sind und nicht geändert werden können.

Weitere Informationen zu Chiffrensätzen finden Sie unter Gängige TLS-Konfiguration von Envoy und Gegenseitige TLS-Authentifizierung von Istio.

Sicherheitsvorteile

Cloud Service Mesh bietet die folgenden Sicherheitsvorteile:

  • Verminderung des Risikos von Replay- oder Imitationsangriffen, bei denen gestohlene Anmeldedaten verwendet werden. Cloud Service Mesh benötigt zur Authentifizierung mTLS-Zertifikate Peers statt Inhabertokens wie JSON-Webtokens (JWT): Da mTLS-Zertifikate an den TLS-Kanal gebunden sind, kann eine Entität in Ihrer Produktionsumgebung nicht als eine andere Identität ausgegeben werden. Dazu wird einfach das Authentifizierungstoken ohne Zugriff auf die privaten Schlüssel ausgegeben.

  • Sicherstellen der Verschlüsselung während der Übertragung. Durch die Verwendung von mTLS für die Authentifizierung wird außerdem sichergestellt, dass alle TCP-Kommunikationen bei der Übertragung verschlüsselt werden.

  • Zugriff auf einen Dienst mit vertraulichen Daten nur durch autorisierte Clients. Nur autorisierte Clients können auf einen Dienst mit vertraulichen Daten zugreifen, unabhängig vom Netzwerkstandort des Clients und den Anmeldedaten auf Anwendungsebene. Sie können angeben, dass nur Clients mit autorisierten Dienstidentitäten oder in autorisierten Kubernetes-Namespaces auf einen Dienst zugreifen können. Sie können auch IP-basierte Zugriffsrichtlinien, um Clients, die außerhalb bereitgestellt werden, Zugriff zu gewähren in der GKE Enterprise-Umgebung.

  • Verminderung des Risikos von Verstößen gegen Nutzerdaten in Ihrem Produktionsnetzwerk. Sie können gewährleisten, dass Insider nur über autorisierte Clients auf vertrauliche Daten zugreifen können. Darüber hinaus können Sie dafür sorgen, dass bestimmte Clients nur dann Zugriff auf Nutzerdaten erhalten, wenn der Client ein gültiges und vorübergehendes Nutzer-Token vorweisen kann. Dadurch wird das Risiko minimiert, dass der Zugriff auf die Anmeldedaten eines einzigen Clients einem Angreifer Zugriff auf alle Nutzerdaten ermöglicht.

  • Identifikation von Clients, die auf einen Dienst mit vertraulichen Daten zugegriffen haben. Das Cloud Service Mesh-Zugriffs-Logging erfasst die mTLS-Identität des Clients in zusätzlich zur IP-Adresse. Dadurch können Sie problemlos erkennen, welche Arbeitslast auf einen Dienst zugegriffen hat, auch wenn die Arbeitslast sitzungsspezifisch und dynamisch und in einem anderen Cluster oder VPC-Netzwerk (Virtual Private Cloud) bereitgestellt wird.

Features

In diesem Abschnitt werden die Features von Cloud Service Mesh beschrieben, um das Problem zu beheben. ihre Sicherheitsvorteile.

Automatische Zertifikate und Schlüsselrotation

Die Verwendung von mTLS auf Basis von Dienstidentitäten ermöglicht die Verschlüsselung der gesamten TCP-Kommunikation und bietet sicherere, nicht wiederholbare Anmeldedaten für die Zugriffssteuerung. Eine der größten Herausforderungen bei der umfangreichen Nutzung von mTLS ist die Verwaltung der Schlüssel. und Zertifikate für alle Zielarbeitslasten. Cloud Service Mesh kümmert sich um die Rotation von mTLS-Schlüsseln und ‑Zertifikaten für GKE Enterprise-Arbeitslasten, ohne die Kommunikation zu unterbrechen. Es ist möglich, kürzere Intervalle für die Aktualisierung von Zertifikaten zu konfigurieren, um das Risiko zu verringern.

Cloud Service Mesh-Zertifizierungsstelle

Cloud Service Mesh enthält ein verwaltetes multiregionales privates Zertifikat Cloud Service Mesh-Zertifizierungsstelle, für die Ausstellung von Zertifikaten für mTLS. Die Cloud Service Mesh-Zertifizierungsstelle ist ein zuverlässiger und skalierbarer Dienst, der für dynamisch skalierte Arbeitslasten in einer Cloud-Plattform optimiert ist. Mit Cloud Service Mesh-Zertifizierungsstelle verwaltet Google die Sicherheit und Verfügbarkeit der CA-Back-End. Mit der Cloud Service Mesh-Zertifizierungsstelle können Sie sich auf eine einzige Root of Trust verlassen in allen GKE Enterprise-Clustern. Wenn Sie die Cloud Service Mesh-Zertifizierungsstelle verwenden, können Sie sind Workload Identity-Pools für eine grobe Isolation erforderlich. Die Authentifizierung schlägt standardmäßig fehl, wenn sich Client und Server nicht im selben Workload Identity-Pool befinden.

Zertifikate der Cloud Service Mesh-Zertifizierungsstelle enthalten die folgenden Daten über die Dienste Ihrer Anwendung:

  • Die Google Cloud-Projekt-ID
  • Der GKE-Namespace
  • Der Name des GKE-Dienstkontos

Certificate Authority Service

Als Alternative zur Cloud Service Mesh-Zertifizierungsstelle können Sie Cloud Service Mesh zur Nutzung von Certificate Authority Service, der für die folgende Anwendungsfälle:

  • Wenn Sie unterschiedliche CAs benötigen, um Arbeitslastzertifikate auf unterschiedlichen Clustern zu signieren.
  • Wenn Sie Zertifikate von benutzerdefinierten Istio-CA-Plug-ins verwenden möchten.
  • Wenn Sie Ihre Signaturschlüssel in einem verwalteten HSM sichern müssen.
  • Wenn Sie in einer stark regulierten Branche tätig sind und der Compliance unterliegen.
  • Wenn Sie Ihre Cloud Service Mesh-Zertifizierungsstelle an ein benutzerdefiniertes Unternehmen verketten möchten Root-Zertifikat, um Arbeitslastzertifikate zu signieren.

Die Kosten für die Cloud Service Mesh-Zertifizierungsstelle sind im Preis für Cloud Service Mesh inbegriffen. Der Zertifizierungsstellendienst ist nicht in der Basisversion enthalten Cloud Service Mesh-Preis und wird separat in Rechnung gestellt. Darüber hinaus enthält CA Service ein explizites SLA, die Cloud Service Mesh-Zertifizierungsstelle jedoch nicht.

Für diese Einbindung erhalten alle Arbeitslasten in Cloud Service Mesh zwei IAM-Rollen:

Richtlinien für identitätssensitive Zugriffssteuerung (Firewall)

Mit Cloud Service Mesh können Sie Netzwerksicherheitsrichtlinien konfigurieren, basierend auf der mTLS-Identität mit der IP-Adresse des Peers. Auf diese Weise können Sie Richtlinien erstellen, die unabhängig vom Netzwerkstandort der Arbeitslast sind. Derzeit wird nur die Kommunikation zwischen Clustern im selben Google Cloud-Projekt unterstützt.

Richtlinien für anforderungssensitive Zugriffssteuerung (Firewall)

Zusätzlich zur mTLS-Identität können Sie den Zugriff auf Basis der Anforderungen im JWT-Header von HTTP- oder gRPC-Anfragen gewähren. Mit Cloud Service Mesh können Sie dass ein JWT von einer vertrauenswürdigen Entität signiert wird. Das bedeutet, dass Sie Richtlinien konfigurieren können, die den Zugriff von bestimmten Clients nur dann zulassen, wenn eine Anforderung vorhanden ist oder einem bestimmten Wert entspricht.

Nutzerauthentifizierung mit Identity-Aware Proxy

Sie authentifizieren Nutzer, die auf Dienste zugreifen, die auf einem Cloud Service Mesh-Ingress-Gateway mithilfe von Identity-Aware Proxy (IAP): IAP kann Nutzer authentifizieren, die sich über einen Browser anmelden, sich in benutzerdefinierte Identitätsanbieter einbinden und ein kurzlebiges JWT-Token oder RCToken ausstellen, das verwendet werden kann, um den Zugriff auf das Ingress-Gateway oder einen nachgelagerten Dienst (mithilfe eines Sidecars) zu gewähren. Weitere Informationen finden Sie unter IAP in Cloud Service Mesh einbinden.

Nutzerauthentifizierung mit Ihrem vorhandenen Identitätsanbieter:

Sie können Ihren bestehenden Identitätsanbieter in das Cloud Service Mesh einbinden, um browserbasierte Endnutzer-Authentifizierung und Zugriffssteuerung für Ihr bereitgestelltes Arbeitsbelastungen. Weitere Informationen finden Sie unter Cloud Service Mesh-Nutzerauthentifizierung konfigurieren.

Zugriffs-Logging und -Monitoring:

Cloud Service Mesh stellt sicher, dass Zugriffslogs und Messwerte in Google Cloud Observability und bietet ein integriertes Dashboard um Zugriffsmuster für einen Dienst oder eine Arbeitslast anhand dieser Daten zu verstehen. Sie können auch ein privates Ziel konfigurieren. Mit Cloud Service Mesh können Sie die Ausgabe falscher positiver Ergebnisse in Zugriffslogs reduzieren, indem Sie erfolgreiche Zugriffe nur einmal in einem konfigurierbaren Zeitfenster protokollieren. Anfragen, die von einer Sicherheitsrichtlinie abgelehnt werden oder zu einem Fehler führen, werden immer protokolliert. Dadurch können Sie die Kosten für die Aufnahme, Speicherung und Verarbeitung von Logs erheblich reduzieren, ohne dass wichtige Sicherheitssignale verloren gehen.

FIPS-konform

Alle Komponenten und Proxys der Steuerungsebene im Cluster in der x86-Architektur verwenden Nach FIPS 140-2 validierte Verschlüsselung Module.

Beschränkungen

Die Sicherheit von Cloud Service Mesh unterliegt derzeit der folgenden Einschränkung:

  • Für die Nutzerauthentifizierung, die IAP verwendet, muss ein Dienst im Internet veröffentlicht werden. Mit IAP und Cloud Service Mesh können Sie Richtlinien konfigurieren, die den Zugriff auf autorisierte Nutzer und Clients in einem zulässigen IP-Bereich einschränken. Wenn Sie den Dienst nur für Clients innerhalb desselben Netzwerks freigeben möchten, müssen Sie eine benutzerdefinierte Richtlinien-Engine für die Nutzerauthentifizierung und die Ausstellung von Tokens konfigurieren.

Nächste Schritte