Best Practices für die Sicherheit von Cloud Service Mesh

In diesem Dokument werden Best Practices zum Einrichten und Steuern einer sicheren Cloud Service Mesh-Konfiguration beschrieben, die in Google Kubernetes Engine (GKE) ausgeführt wird. Die Anleitungen in der Das Dokument geht über die für die Konfiguration und Installation verwendeten Einstellungen hinaus. Cloud-Service-Mesh und beschreibt, wie Sie Cloud Service Mesh mit anderen Google Cloud-Produkten Produkte und Funktionen zum Schutz vor Sicherheitsbedrohungen, in einem Mesh-Netzwerk gegenüberliegen.

Die Zielgruppe für dieses Dokument umfasst Administratoren, die Richtlinien in einem Cloud Service Mesh verwalten, und Nutzer, die Dienste in einem Cloud Service Mesh ausführen. Die hier beschriebenen Sicherheitsmaßnahmen sind auch für Organisationen nützlich, die die Sicherheit ihrer Service Meshes erhöhen müssen, um Compliance-Anforderungen zu erfüllen.

Das Dokument ist so aufgebaut:

Einleitung

Cloud Service Mesh bietet Features und Tools, mit denen Sie Dienste auf einheitliche Weise beobachten, verwalten und schützen können. Es verfolgt einen anwendungsorientierten Ansatz und verwendet vertrauenswürdige Anwendungsidentitäten anstelle eines auf Netzwerk-IP ausgerichteten Ansatzes. Sie können ein Service Mesh transparent bereitstellen, ohne vorhandenen Anwendungscode ändern zu müssen. Cloud Service Mesh bietet deklarative Kontrolle über das Netzwerkverhalten, wodurch die Arbeit von Teams entkoppelt wird, d. h. die Bereitstellung und Freigabe von Anwendungsfeatures ist getrennt von den Verantwortlichkeiten der Administratoren, die für Sicherheit und Netzwerk verantwortlich sind.

Cloud Service Mesh basiert auf Open Source Istio Service Mesh, das komplexe Konfigurationen und Topologien ermöglicht. Je nach Struktur Ihrer Organisation sind möglicherweise mehrere Teams oder Rollen für die Installation und Konfiguration eines Mesh-Netzwerks verantwortlich. Die Standardeinstellungen von Cloud Service Mesh werden zum Schutz der Anwendungen ausgewählt. In einigen Fällen müssen Sie jedoch benutzerdefinierte Konfigurationen verwenden oder Ausnahmen gewähren, indem Sie bestimmte Anwendungen, Ports oder IP-Adressen von der Teilnahme an einem Mesh-Netzwerk ausschließen. Kontrollen zur Steuerung von Mesh-Konfigurationen und Sicherheitsausnahmen sind wichtig.

Angriffsvektoren und Sicherheitsrisiken

Angriffsvektoren

Die Sicherheit von Cloud Service Mesh folgt dem Zero-Trust-Sicherheitsmodell, gehen davon aus, dass Sicherheitsbedrohungen innerhalb und außerhalb eines Sicherheitsbereich des Unternehmens. Beispiele für Sicherheitsangriffe, die Anwendungen in einem Service Mesh gefährden können:

  • Daten-Exfiltration-Angriffe. Beispielsweise Angriffe, die sensible Daten oder Anmeldedaten aus Dienst-zu-Dienst-Traffic abhören.
  • Man-in-the-Middle-Angriffe. Beispiel: Ein schädlicher Dienst, der sich als legitimer Dienst maskiert, um die Kommunikation zwischen Diensten zu abzurufen oder zu ändern.
  • Angriffe auf Rechteausweitung. Beispielsweise Angriffe, die unberechtigten Zugriff auf erweiterte Berechtigungen zum Ausführen von Vorgängen in einem Netzwerk nutzen.
  • DoS-Angriffe (Denial of Service).
  • Botnet-Angriffe, die versuchen, Dienste zu manipulieren und zu bearbeiten, um Angriffe auf andere Dienste zu starten.

Die Angriffe können auch anhand der Angriffsziele kategorisiert werden:

  • Angriffe auf das interne Mesh-Netzwerk. Angriffe, mit denen die interne Kommunikation zwischen Diensten oder Diensten und der Steuerungsebene manipuliert, abgehört oder gespooft werden soll.
  • Angriffe auf die Steuerungsebene. Angriffe, die darauf abzielen, die Steuerungsebene zu beeinträchtigen (z. B. ein DoS-Angriff) oder sensible Daten aus der Steuerungsebene exfiltrieren.
  • Angriffe auf das Mesh-Netzwerk am Edge. Angriffe, die auf das Manipulieren, Abhören oder Spoofing der Kommunikation für ein- oder ausgehenden Traffic im Mesh-Netzwerk abzielen.
  • Angriffe auf Vorgänge im Mesh-Netzwerk. Angriffe auf die Vorgänge im Mesh-Netzwerk. Angreifer versuchen möglicherweise, erweiterte Berechtigungen zu erhalten, um böswillige Vorgänge in einem Mesh-Netzwerk auszuführen, wie z. B. Ändern der Sicherheitsrichtlinien und Arbeitslast-Images.

Sicherheitsrisiken

Neben Sicherheitsangriffen hat ein Mesh-Netzwerk auch andere Sicherheitsrisiken. In der folgenden Liste werden einige mögliche Sicherheitsrisiken beschrieben:

  • Unvollständiger Schutzmaßnahmen für die Sicherheit. Ein Service Mesh wurde nicht mit Authentifizierungs- und Autorisierungsrichtlinien zum Schutz der Sicherheit konfiguriert. Beispielsweise wurden für Dienste in einem Mesh keine Authentifizierungs- oder Autorisierungsrichtlinien definiert.
  • Ausnahmen von Sicherheitsrichtlinien. Um ihren spezifischen Anwendungsfällen gerecht zu werden, erstellen möglicherweise Ausnahmen von Sicherheitsrichtlinien für bestimmten Traffic (interne oder extern) von Cloud Service Mesh-Sicherheitsrichtlinien ausgeschlossen werden. Informationen zur sicheren Handhabung solcher Fälle finden Sie im Abschnitt Ausnahmen von Richtlinien sicher einrichten.
  • Vernachlässigung der Image-Upgrades. Für die in einem Mesh-Netzwerk verwendeten Images können Sicherheitslücken erkannt werden. Sie müssen die Mesh-Komponenten- und Arbeitslast-Images mit den neuesten Fehlerkorrekturen auf dem neuesten Stand halten.
  • Mangelnde Wartung (keine Fachkenntnisse oder Ressourcen). Die Mesh-Software und Richtlinienkonfigurationen erfordern eine regelmäßige Wartung, um die neuesten Sicherheitsmechanismen zu nutzen.
  • Mangelnde Sichtbarkeit. Fehlkonfigurationen oder unsichere Konfigurationen von Mesh-Richtlinien und abnormaler Traffic bzw. abnormale Vorgänge im Mesh-Netzwerk werden von Mesh-Administratoren nicht erkannt.
  • Konfigurationsabweichung. Die Konfiguration von Richtlinien in einem Mesh-Netzwerk weicht von der "Source of Truth" ab.

Maßnahmen zum Schutz eines Service Mesh

In diesem Abschnitt wird ein Betriebshandbuch zum Sichern von Service Mesh vorgestellt.

Sicherheitsarchitektur

Die Sicherheit eines Service Mesh hängt von der Sicherheit der Komponenten auf verschiedenen Ebenen des Mesh-Systems und seiner Anwendungen ab. Das übergeordnete Ziel der vorgeschlagenen Sicherheitlage für das Cloud Service Mesh ist es, ein Service Mesh durch Einbindung mehrerer Sicherheitsmechanismen auf verschiedenen Ebenen abzusichern, die gemeinsam die Gesamtsystemsicherheit unter dem Zero-Trust-Sicherheitsmodell erreichen. Das folgende Diagramm zeigt das vorgeschlagene Cloud Service Mesh Sicherheitsstatus.

Sicherheitsstatus des Cloud Service Mesh

Cloud Service Mesh bietet Sicherheit auf mehreren Ebenen, darunter:

  • Sicherheit am Edge des Mesh-Netzwerks
    • Die Cloud Service Mesh-Sicherheit für eingehenden Traffic bietet Zugriffssteuerung für externen Traffic und schützt den externen Zugriff auf die APIs, die von den Diensten im Mesh-Netzwerk verfügbar gemacht werden.
    • Die Sicherheit des ausgehenden Cloud Service Mesh-Traffics reguliert den ausgehenden Traffic von internen Arbeitslasten entfernt.
    • Cloud Service Mesh-Nutzerauthentifizierung kann in die Google-Infrastruktur eingebunden werden, um externe Aufrufe von Webbrowsern bei den Diensten zu authentifizieren, die Webanwendungen ausführen.
    • Zertifikatsverwaltung für Cloud Service Mesh-Gateway die privaten Schlüssel und X.509-Zertifikate schützt und rotiert, Cloud Service Mesh-Gateways für eingehenden und ausgehenden Traffic mit Certificate Authority Service.
    • Cloud Armor kann sich vor externe Distributed-Denial-of-Service- (DDoS)- und Layer-7-Angriffe. Es dient als Web Application Firewall (WAF), um das Mesh-Netzwerk vor Netzwerkangriffen zu schützen. Zum Beispiel Angriffe durch Injektion und Remote-Codeausführung.
    • VPC und VPC Service Controls schützen das Edge des Mesh-Netzwerks durch die private Netzwerkzugriffssteuerung.
  • Clustersicherheit
    • Gegenseitiges TLS (mTLS) von Cloud Service Mesh erzwingt Arbeitslast-zu-Arbeitslast Traffic-Verschlüsselung und -Authentifizierung.
    • Verwaltete Zertifizierungsstelle, z. B. die Cloud Service Mesh-Zertifizierungsstelle und Certificate Authority Service, stellt die verwendeten Zertifikate sicher bereit und verwaltet sie. durch die Arbeitslasten.
    • Cloud Service Mesh-Autorisierung erzwingt Zugriffssteuerung für das Mesh basierend auf ihrer Identität und anderen Attributen.
    • GKE Enterprise-Sicherheitsdashboard die Konfigurationen von Sicherheitsrichtlinien und Kubernetes-Netzwerkrichtlinien für die Arbeitslasten.
    • Die Kubernetes-Netzwerkrichtlinie erzwingt die Zugriffssteuerung für Pods anhand von IP-Adressen, Pod-Labels, Namespaces und mehr.
    • Die Sicherheit der Steuerungsebene schützt vor Angriffen auf der Steuerungsebene. Dieser Schutz verhindert, dass Angreifer Dienst- und Mesh-Konfigurationsdaten ändern, ausnutzen oder umgehen.
  • Arbeitslastsicherheit
    • Bleiben Sie mit den Sicherheitsupdates von Cloud Service Mesh auf dem neuesten Stand, um zu gewährleisten, dass die in Ihrem Mesh-Netzwerk ausgeführten Cloud Service Mesh-Binärdateien frei von öffentlich bekannten Sicherheitslücken sind.
    • Identitätsföderation von Arbeitslasten für GKE Ermöglicht es Arbeitslasten, Anmeldedaten für den sicheren Aufruf von Google-Diensten abzurufen.
    • Kubernetes CNI (Container Network Interface) verhindert Berechtigungen Eskalationsangriffe, da keine privilegierten Initialisierungscontainer für Cloud Service Mesh
  • Operatorsicherheit
    • Die rollenbasierte Zugriffssteuerung von Kubernetes (RBAC) beschränkt den Zugriff auf Kubernetes-Ressourcen und die Operatorberechtigungen, um Angriffe durch böswillige Operatoren oder Operator-Identitätsdiebstahl zu minimieren.
    • GKE Enterprise Policy Controller validiert und prüft Richtlinienkonfigurationen im Mesh-Netzwerk, um Fehlkonfigurationen zu verhindern.
    • Die Google Cloud-Binärautorisierung sorgt dafür, dass die im Mesh-Netzwerk enthaltenen Arbeitslast-Images mit den Images identisch sind, die von den Administratoren autorisiert werden.
    • Google Cloud-Audit-Logging prüft Mesh-Vorgänge.

Das folgende Diagramm zeigt die Kommunikations- und Konfigurationsabläufe mit den integrierten Sicherheitslösungen in Cloud Service Mesh.

Grafik: Trafficfluss des Sicherheitsdiagramms

Clustersicherheit

Strikte mTLS-Authentifizierung aktivieren

Bei MitM-Angriffen (Man-in-the-Middle) wird versucht, eine schädliche Entität zwischen zwei kommunizierenden Parteien einzufügen, um die Kommunikation abzuhören oder zu manipulieren. Cloud Service Mesh schützt vor MitM- und Daten-Exfiltration-Angriffen, indem die mTLS-Authentifizierung und -Verschlüsselung für alle kommunizierenden Parteien erzwungen wird. Der Modus "Moderat" verwendet mTLS, wenn von beiden Seiten unterstützt, lässt jedoch Verbindungen ohne mTLS zu. Im Gegensatz dazu erfordert die strikte mTLS-Authentifizierung, dass der Traffic mit mTLS verschlüsselt und authentifiziert wird, und es wird kein Traffic im Nur-Text-Format zugelassen.

Mit Cloud Service Mesh können Sie Mindestversion für TLS konfigurieren für die TLS-Verbindungen zwischen Ihren Arbeitslasten. Compliance-Anforderungen.

Weitere Informationen finden Sie unter Cloud Service Mesh am Beispiel: mTLS | Mesh-weites mTLS erzwingen.

Zugriffssteuerungen aktivieren

Sicherheitsrichtlinien von Cloud Service Mesh (z. B. Authentifizierungs- und Autorisierungsrichtlinien) sollten für den gesamten Traffic in und aus dem Mesh erzwungen werden, es sei denn, es gibt starke Begründungen, um einen Dienst oder Pod von den Cloud Service Mesh-Sicherheitsrichtlinien auszuschließen. In einigen Fällen können Nutzer berechtigt sein, Cloud Service Mesh-Sicherheitsrichtlinien für einige Ports und IP-Bereiche zu umgehen. Für um native Verbindungen zu Diensten herzustellen, Cloud Service Mesh. Informationen zum Schutz von Cloud Service Mesh bei solchen Anwendungsfällen finden Sie unter Ausnahmen von Cloud Service Mesh-Richtlinien sicher einrichten.

Die Dienstzugriffskontrolle ist wichtig, um unbefugten Zugriff auf Dienstleistungen. Mit der mTLS-Erzwingung wird eine Anfrage verschlüsselt und authentifiziert, aber ein Mesh-Netzwerk ist weiterhin vorhanden. braucht Cloud Service Mesh-Autorisierungsrichtlinien um die Zugriffssteuerung für Dienste zu erzwingen. Beispielsweise werden nicht autorisierte Anfragen von authentifizierten Clients abgelehnt.

Cloud Service Mesh-Autorisierungsrichtlinien bieten eine flexible Möglichkeit, Zugriffskontrollen, um Ihre Dienste vor unbefugtem Zugriff zu schützen. Cloud Service Mesh-Autorisierungsrichtlinien sollten basierend auf den Authentifizierte Identitäten, die aus den Authentifizierungsergebnissen abgeleitet wurden – mTLS oder JSON JWT-basierte Authentifizierungen sollten zusammen als Teil der Cloud Service Mesh-Autorisierungsrichtlinien.

Cloud Service Mesh-Authentifizierungsrichtlinien erzwingen

JSON-Webtoken (JWT)

Zusätzlich zur mTLS-Authentifizierung können Mesh-Administratoren von einem Dienst erfordern, dass Anfragen über JWT authentifiziert und autorisiert werden. Cloud Service Mesh agiert nicht als JWT-Anbieter, authentifiziert JWTs jedoch basierend auf den konfigurierten JWKS-Endpunkten (JSON Web Key Set) JWT-Authentifizierung können auf Ingress-Gateways für externen Traffic oder auf interne Dienste angewendet werden für In-Mesh-Traffic. Die JWT-Authentifizierung kann mit der mTLS-Authentifizierung kombiniert werden. Ein JWT wird als Anmeldedaten verwendet, um den Endaufrufer und den angeforderten Aufruf zu repräsentieren. Der Dienst erfordert einen Nachweis, dass er im Namen des Endanrufers aufgerufen wird. Das Erzwingen der JWT-Authentifizierung schützt vor Angriffen, die auf einen Dienst zugreifen ohne gültige Anmeldedaten und im Namen eines echten Endnutzers zu veröffentlichen.

Cloud Service Mesh-Nutzerauthentifizierung

Die Cloud Service Mesh-Nutzerauthentifizierung ist eine integrierte Lösung für die browserbasierte Endnutzerauthentifizierung und Zugriffssteuerung für Ihre Arbeitslasten. Ein Service Mesh wird in die vorhandene Identität eingebunden. Anbieter (IdP), die eine standardmäßige webbasierte OpenID Connect-Anmeldung (OIDC) implementieren und dem Einwilligungsvorgang und nutzt Cloud Service Mesh-Autorisierungsrichtlinien für den Zugriff Steuerung.

Autorisierungsrichtlinien erzwingen

Cloud Service Mesh-Autorisierungsrichtlinien steuern:

  • Wer oder was Zugriff auf einen Dienst hat
  • Auf welche Ressourcen zugegriffen werden kann
  • Welche Vorgänge für die zulässigen Ressourcen ausgeführt werden können

Mit Autorisierungsrichtlinien kann die Zugriffssteuerung basierend auf den tatsächlichen Identitäten, als die Dienste ausgeführt werden, auf den Attributen der Anwendungsebene (Ebene 7) (z. B. Anfrageheader) und der Netzwerkebene (Ebene 3 und Ebene 4) wie IP-Bereiche und Ports vielseitig konfiguriert werden.

Cloud Service Mesh-Autorisierungsrichtlinien sollten basierend auf authentifizierten Daten erzwungen werden Identitäten, die aus den Authentifizierungsergebnissen abgeleitet wurden, um sich vor unautorisierten Zugriff auf Dienste oder Daten.

Standardmäßig sollte der Zugriff auf einen Dienst verweigert werden, sofern keine Autorisierungsrichtlinie explizit definiert ist, die den Zugriff auf diesen Dienst zulässt. Beispiele für Autorisierungsrichtlinien, die Zugriffsanfragen verweigern, finden Sie unter Best Practices für Autorisierungsrichtlinien.

Autorisierungsrichtlinien sollten das Vertrauen so weit wie möglich einschränken. Der Zugriff auf einen Dienst kann beispielsweise basierend auf einzelnen URL-Pfaden definiert werden, die von einem Dienst bereitgestellt werden, sodass nur ein Dienst A auf den Pfad /admin eines Dienstes B zugreifen kann.

Autorisierungsrichtlinien können zusammen mit Kubernetes-Netzwerkrichtlinien verwendet werden, die nur auf der Netzwerkebene (Ebene 3 und Ebene 4) funktionieren und den Netzwerkzugriff für IP-Adressen und Ports auf Kubernetes-Pods und Kubernetes-Namespaces steuern.

Tokenaustausch für den Zugriff auf Mesh-Dienste erzwingen

Zum Schutz vor Tokenwiederholungsangriffen, bei denen Tokens gestohlen und die gestohlenen Tokens für den Zugriff auf Mesh-Dienste wiederverwendet werden, sollte ein Token in einer Anfrage von außerhalb des Mesh-Netzwerks gegen ein kurzlebiges Token innerhalb des Mesh-Netzwerks am Edge ausgetauscht werden.

Eine Anfrage von außerhalb des Mesh-Netzwerks für den Zugriff auf einen Mesh-Dienst muss ein Token wie JWT oder Cookie enthalten, um vom Mesh-Dienst authentifiziert und autorisiert zu werden. Ein Token von außerhalb des Mesh-Netzwerks kann langlebig sein. Zum Schutz vor Tokenwiederholungsangriffen sollte ein Token von außerhalb des Mesh-Netzwerks gegen ein kurzlebiges Mesh-internes Token mit einem eingeschränkten Bereich am Ingress des Mesh ausgetauscht werden. Der Mesh-Dienst authentifiziert ein Mesh-internes Token und autorisiert die Zugriffsanfrage anhand des Mesh-internen Tokens.

Nächste Schritte