Cloud Service Mesh-Sicherheit – Übersicht

Das Cloud Service Mesh mit der Sicherheit von Istio-APIs unterstützt Sie beim Abwehren von Insiderbedrohungen und dem Reduzieren des Risikos von Datenpannen, da die gesamte Kommunikation zwischen Arbeitslasten verschlüsselt, beidseitig authentifiziert und autorisiert ist.

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 und anfragekontextsensitive Netzwerksicherheitsebene konfigurieren, die von der Sicherheit des zugrunde liegenden Netzwerks unabhängig ist. Aus diesem Grund bietet Ihnen Cloud Service Mesh die Möglichkeit, eine gestaffelte Sicherheitsebene einzuführen, die den Zero-Trust-Sicherheitsprinzipien entspricht. Sie können diesen Status über deklarative Richtlinien erreichen, ohne Anwendungscode ändern zu müssen.

Gegenseitiges TLS

Cloud Service Mesh verwendet gegenseitiges TLS (mTLS) für die Peer-Authentifizierung. Die Authentifizierung bezieht sich auf die Identität: Wer ist dieser Dienst? wer ist dieser Endnutzer? Kann ich darauf vertrauen, dass er tatsächlich der ist, der er vorgibt zu sein?

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 das Mittel, mit dem Cloud Service Mesh sowohl die Authentifizierung als auch die Verschlüsselung zwischen Diensten implementiert.

In Cloud Service Mesh ist automatisches mTLS standardmäßig aktiviert. Mit automatischem mTLS erkennt ein Client-Sidecar-Proxy automatisch, ob der Server eine Sidecar-Datei hat. Der Client-Sidecar sendet mTLS an Arbeitslasten mit Sidecars und Nur-Text an Arbeitslasten ohne Sidecars. 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 zum Erzwingen nur mTLS finden Sie unter Cloud Service Mesh am Beispiel: mTLS.

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 von Peers mTLS-Zertifikate anstelle von Inhabertokens wie JSON-Webtokens (JWT). Da mTLS-Zertifikate an den TLS-Kanal gebunden sind, kann eine Entität in Ihrer Produktionsumgebung nicht die Identität einer anderen Entität übernehmen, indem das Authentifizierungstoken ohne Zugriff auf die privaten Schlüssel noch einmal wiedergegeben wird.

  • 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 verwenden, um Clients, die außerhalb der Clients außerhalb des Mesh-Netzwerks bereitgestellt werden, Zugriff zu gewähren.

  • 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. So verringern Sie das Risiko, dass die Manipulation der Anmeldedaten eines einzelnen Clients einem Angreifer Zugriff auf alle Nutzerdaten gewährt.

  • Identifikation von Clients, die auf einen Dienst mit vertraulichen Daten zugegriffen haben. Das Zugriffs-Logging von Cloud Service Mesh erfasst zusätzlich zur IP-Adresse die mTLS-Identität des Clients. Auf diese Weise können Sie nachvollziehen, 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 die Sicherheitsvorteile zu nutzen.

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 Verwendung von mTLS in großem Maßstab ist die Verwaltung der Schlüssel und Zertifikate für alle Zielarbeitslasten. Cloud Service Mesh kümmert sich um das Rotieren von mTLS-Schlüsseln und -Zertifikaten für Mesh-Arbeitslasten, ohne die Kommunikation zu unterbrechen. Die Konfiguration kleinerer Aktualisierungsintervalle für das Zertifikat kann das Risiko reduzieren.

Anthos Service Mesh-Zertifizierungsstelle (Mesh CA)

Cloud Service Mesh enthält eine verwaltete multiregionale private Zertifizierungsstelle (Mesh CA) zum Ausstellen von Zertifikaten für mTLS. Mesh CA ist ein äußerst zuverlässiger und skalierbarer Dienst, der für dynamisch skalierte Arbeitslasten auf einer Cloud-Plattform optimiert ist. Mit Mesh CA verwaltet Google die Sicherheit und Verfügbarkeit des CA-Back-Ends. Mesh CA ermöglicht es Ihnen, sich clusterübergreifend auf eine einzige Root of Trust zu verlassen. Wenn Sie Mesh CA verwenden, können Sie sich auf Identitätspools von Arbeitslasten verlassen, um eine grobe Isolation zu ermöglichen. Standardmäßig schlägt die Authentifizierung fehl, wenn sich Client und Server nicht im selben Workload Identity-Pool befinden.

Zertifikate der Mesh CA enthalten die folgenden Daten zu den Diensten Ihrer Anwendung:

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

Certificate Authority Service

Als Alternative zu Mesh CA können Sie Cloud Service Mesh für die Verwendung des Certificate Authority Service konfigurieren. Dieser eignet sich für die folgenden Anwendungsfälle:

  • Wenn Sie unterschiedliche CAs benötigen, um Arbeitslastzertifikate auf unterschiedlichen Clustern zu signieren.
  • 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 mit einem benutzerdefinierten Unternehmens-Root-Zertifikat verknüpfen möchten, um Arbeitslastzertifikate zu signieren.

Die Kosten von Mesh CA sind in den Cloud Service Mesh-Preisen enthalten. Die Kosten für CA Service sind nicht im Cloud Service Mesh-Basispreis enthalten und werden separat abgerechnet. Darüber hinaus umfasst CA Service ein explizites SLA, Mesh CA jedoch nicht.

Für diese Integration werden allen Arbeitslasten in Cloud Service Mesh zwei IAM-Rollen zugewiesen:

Richtlinien für identitätssensitive Zugriffssteuerung (Firewall)

Mit Cloud Service Mesh können Sie Netzwerksicherheitsrichtlinien konfigurieren, die auf der mTLS-Identität im Vergleich zur IP-Adresse des Peers basieren. Auf diese Weise können Sie Richtlinien erstellen, die unabhängig vom Netzwerkstandort der Arbeitslast sind. Es 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 bestätigen, dass ein JWT von einer vertrauenswürdigen Entität signiert ist. Das bedeutet, dass Sie Richtlinien konfigurieren können, die den Zugriff von bestimmten Clients nur dann zulassen, wenn eine Anforderung für eine Anfrage besteht oder mit einem bestimmten Wert übereinstimmt.

Nutzerauthentifizierung mit Identity-Aware Proxy

Sie authentifizieren Nutzer, die auf einen Dienst zugreifen, der auf einem Cloud Service Mesh-Ingress-Gateway verfügbar ist, mit Identity-Aware Proxy (IAP). IAP kann Nutzer authentifizieren, die sich über einen Browser anmelden, in benutzerdefinierte Identitätsanbieter einbinden und ein kurzlebiges JWT-Token oder ein RCToken ausgeben, mit dem dann Zugriff auf dem Ingress-Gateway oder einem nachgelagerten Dienst (mithilfe eines Nebenautos) gewährt werden kann. Weitere Informationen finden Sie unter IAP in Cloud Service Mesh integrieren.

Nutzerauthentifizierung mit Ihrem vorhandenen Identitätsanbieter:

Sie können Ihren vorhandenen Identitätsanbieter in Cloud Service Mesh einbinden, um eine browserbasierte Endnutzerauthentifizierung und Zugriffssteuerung für Ihre bereitgestellten Arbeitslasten zu ermöglichen. Weitere Informationen finden Sie unter Cloud Service Mesh-Nutzerauthentifizierung konfigurieren.

Zugriffs-Logging und -Monitoring:

Cloud Service Mesh stellt sicher, dass Zugriffslogs und -messwerte in der Google Cloud-Beobachtbarkeit verfügbar sind, und bietet ein integriertes Dashboard, um Zugriffsmuster für einen Dienst oder eine Arbeitslast anhand dieser Daten zu verstehen.

FIPS-konform

Die Komponente der Datenebene verwendet gemäß FIPS 140-2 validierte Verschlüsselungmodule.

Beschränkungen

Für die Sicherheit von Cloud Service Mesh gilt die folgende 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 können. Wenn Sie den Dienst nur für Clients im selben Netzwerk verfügbar machen möchten, müssen Sie eine benutzerdefinierte Richtlinien-Engine für die Nutzerauthentifizierung und die Tokenausgabe konfigurieren.

Nächste Schritte