Man-in-the-Middle-Angriffe: Netzwerkangriffe auf Mobilgeräte Verhindern
Wir werden Ihre persönlichen Daten immer sicher aufbewahren.
Wir bitten Sie um Ihre Daten im Austausch für eine wertvolle Ressource, um (a) Ihr Surferlebnis zu verbessern, indem wir die Website Lookout auf Ihre Bedürfnisse abstimmen; (b) Ihnen Informationen per E-Mail oder auf anderem Wege zukommen zu lassen, von denen wir glauben, dass sie für Sie von Interesse sein könnten; (c) Ihnen Marketingmitteilungen zukommen zu lassen, von denen wir glauben, dass sie für Sie von Nutzen sein könnten. Sie können mehr über unsere Datenschutzpolitik lesen hier.
Erfolgsformel gegenüber Cyberangriffen: das regelmäßige Updaten und Patchen von Software
Software-Updates sind über sämtliche Betriebssysteme hinweg allgegenwärtig. Sie stellen nicht nur neue Funktionen bereit, sondern können zudem große Cyberangriffe verhindern. Schließlich werden im Rahmen der Aktualisierungen oft auch Systemschwachstellen behoben. Die Priorisierung und Durchführung dieser notwendigen Maßnahme ist für viele Nutzer jedoch teilweise lästig und unbequem, da Computer, Server, Tablets, Smartphones und weitere Geräte im Zuge der Installation neu gestartet werden müssen. Das sorgt während der regulären Bürozeiten regelmäßig für teilweise längere Arbeitsunterbrechungen. Daher werden Aktualisierungen oft aufgeschoben und empfohlene Patches, die häufige Sicherheitsprobleme wie Datendiebstahl und Identitätsverlust verhindern könnten, ignoriert.
Nach einer Erhebung von ZD Net-Medien lassen sich 61 Prozent der bestehenden Schwachstellen in Unternehmensnetzwerken auf das Jahr 2016 oder noch früher zurückdatieren, obwohl Patches dafür bereits seit fünf Jahren oder länger verfügbar sind. Einige der Schwachstellen, die nach wie vor beispielsweise für den Zugang zu Netzwerken ausgenutzt werden, sind sogar mehr als ein Jahrzehnt alt.
Wie besorgniserregend sind Software-Schwachstellen?
Wer das Einspielen von Updates länger vermieden hat und damit bislang ungeschoren davonkam, hat vielleicht ein falsches Sicherheitsgefühl entwickelt und denkt, dass diese generell nicht notwendig sind. Das ist ein Trugschluss. Der Cyberangriff auf das Internationale Komitee vom Roten Kreuz (IKRK) im November 2021 beweist, dass solche Zuversicht oftmals fehl am Platze ist. Bei dem Vorfall verschafften sich Hacker Zugang zu den Systemen des IKRK, indem sie eine bekannte, aber nicht gepatchte kritische Schwachstelle in einem Single-Sign-On-Tool ausnutzten, das von Zoho entwickelt wurde – einer Firma, die webbasierte Lösungen für die Unternehmensverwaltung anbietet. Während des Angriffs wurden die Daten von mehr als 515.000 „hochgradig gefährdeten“ Personen kompromittiert.
Diesbezüglich zeigen die von IBM im Jahresbericht X-Force Threat Intelligence Index 2022 vorgelegten Daten, dass 34 Prozent der gemeldeten Cyberangriffe im Jahr 2021 auf die Ausnutzung von Schwachstellen zurückzuführen sind. Das bedeutet im Vergleich zu 2020 einen Anstieg der Vorfälle jener Art um 33 Prozent. Die Zahlen verdeutlichen die enorme Bedeutung dieses Angriffsvektors als Einfallstor für Hacker. Ebenso wird in dem Bericht die Zunahme der Zahl der Schwachstellen an sich hervorgehoben. Jene haben mit 19.649 nach fünf Jahren des konsequenten Wachstums einen neuen Rekordwert erreicht. Noch besorgniserregender ist jedoch, dass auch die Zahl der Exploits, d. h. der Tools, die von Cyberkriminellen zur Ausnutzung einer Schwachstelle verwendet werden, stetig zunimmt. Der Internet Security Report von WatchGuard, in dem das WatchGuard Threat Lab regelmäßig neuen Malware-Varianten und Angriffsmustern auf den Grund geht, gibt an, dass das Volumen der Netzwerkangriffe mit rund 5,7 Millionen Netzwerk-Exploits im vierten Quartal 2021 ein Vierjahreshoch erreicht hat. Das bedeutet, dass den Cyberkriminellen immer mehr Möglichkeiten zur Verfügung stehen, um ihre Pläne zu verwirklichen.
Software-Updates: der erste Schritt zur Cybersicherheit
Neue Schwachstellen tauchen ständig auf und laut der U.S. Cybersecurity and Infrastructure Security Agency (CISA) besteht die beste Verteidigung dagegen darin, sämtliche Software auf dem neuesten Stand zu halten. Sie empfiehlt außerdem eine Reihe von Maßnahmen, um sicherzustellen, dass die Systeme stets auf Höhe der Zeit sind:
Aktivieren Sie, wann immer möglich, automatische Software-Updates. Dadurch wird sichergestellt, dass Aktualisierungen so schnell wie möglich installiert werden. Vermeiden Sie die Verwendung veralteter (End-of-Life, EOL) und nicht unterstützter Software. Besuchen Sie die Websites der Anbieter direkt und klicken Sie nicht auf Werbebanner oder E-Mail-Links. Führen Sie keine Software-Updates außerhalb vertrauenswürdiger Netzwerke durch.
Sicherheitslücken am Endpunkt schließen
Es liegt auf der Hand, dass Software-Patches und -Updates im Rahmen der Cybersicherheitsstrategie eines Unternehmens von entscheidender Bedeutung sind. Zusätzlich zu den von der CISA empfohlenen Praktiken stehen Unternehmen geradezu in der Pflicht, bekannte Schwachstellen zu überwachen und sie zu entschärfen. Denn diese werden immer wieder ausgenutzt, um sich Zugang zu internen Netzwerken zu verschaffen. Folglich stellen Software-Schwachstellen ein größeres und greifbareres Risiko dar als andere Bedrohungsarten.
Es gibt eine Reihe von Tools, die dabei helfen, Systeme auf dem neuesten Stand zu halten und durch verfügbare Patches zu schützen. Das stellt einen großen Vorteil im Kampf gegen Cyberkriminelle dar. Mithilfe von Datenbanken, die den Abgleich der auf den Endpunkten eines Netzwerks installierten Patches ermöglichen, lassen sich Systeme besser absichern und Malware-Angriffe auf anfällige Workstations und Server verhindern.
Anthos Service Mesh – Best Practices für die Sicherheit
Anthos Service Mesh – Best Practices für die Sicherheit
In diesem Dokument werden Best Practices zum Einrichten und Steuern einer sicheren Anthos Service Mesh-Konfiguration beschrieben, die in Google Kubernetes Engine (GKE) ausgeführt wird. Die Anleitung in diesem Dokument geht über die Einstellungen hinaus, die zum Konfigurieren und Installieren von Anthos Service Mesh verwendet werden. Es wird beschrieben, wie Sie Anthos Service Mesh mit anderen Google Cloud-Produkten und -Features verwenden können, um Ihre Anwendungen gegen Sicherheitsbedrohungen in einem Mesh-Netzwerk zu schützen.
Die Zielgruppe für dieses Dokument umfasst Administratoren, die Richtlinien in einem Anthos Service Mesh verwalten, und Nutzer, die Dienste in einem Anthos 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:
Einführung
Anthos 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. Anthos 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.
Anthos Service Mesh basiert auf dem 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 Anthos 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.
Hinweis: Dieser Leitfaden ergänzt die Dokumentation zu den Best Practices für die Sicherheit von Istio , die detaillierte Konfigurationsempfehlungen für gegenseitige TLS (mTLS), Autorisierungsrichtlinien, Gateways und andere Sicherheitskonfigurationen umfasst. Sie sollten diese Empfehlungen als Grundlage behandeln und zusammen mit den in diesem Leitfaden beschriebenen Best Practices verwenden. In diesem Leitfaden werden zusätzliche Best Practices für Anthos Service Mesh beschrieben und wie Technologien in Google Cloud alle Ebenen, Komponenten und Informationsflüsse in einem Mesh-Netzwerk schützen können.
Angriffsvektoren und Sicherheitsrisiken
Angriffsvektoren
Die Sicherheit von Anthos Service Mesh folgt dem Zero-Trust-Sicherheitsmodell, das davon ausgeht, dass Sicherheitsbedrohungen von innerhalb und außerhalb des Sicherheitsperimeters einer Organisation stammen. 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 jeweiligen Anwendungsfällen gerecht zu werden, können Nutzer Ausnahmen von Sicherheitsrichtlinien für bestimmten (internen oder externen) Traffic festlegen, der von Anthos Service Mesh-Sicherheitsrichtlinien ausgeschlossen werden soll. 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 Anthos 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 die vorgeschlagene Sicherheitslage des Anthos Service Mesh.
Anthos Service Mesh bietet Sicherheit auf mehreren Ebenen, darunter:
Sicherheit am Edge des Mesh-Netzwerks Anthos 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. Anthos Service Mesh-Sicherheit für ausgehenden Traffic reguliert den ausgehenden Traffic von internen Arbeitslasten. Anthos Service Mesh-Nutzerauthentifizierung kann in die Google-Infrastruktur eingebunden werden, um externe Aufrufe von Webbrowsern bei den Diensten zu authentifizieren, die Webanwendungen ausführen. Die Gateway-Zertifikatsverwaltung von Anthos Service Mesh schützt und rotiert die privaten Schlüssel und X.509-Zertifikate, die von Anthos Service Mesh für eingehende und ausgehende Gateways mit Certificate Authority Service verwendet werden. Cloud Armor kann vor externen DDoS-Angriffen (Distributed Denial of Service) und Layer-7-Angriffen schützen. 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 Anthos Service Mesh – Gegenseitiges TLS (mTLS) erzwingt die Verschlüsselung und Authentifizierung von Traffic zwischen Arbeitslasten. Verwaltete CAs, z. B. die Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) und Certificate Authority Service, stellen von den Arbeitslasten verwendete Zertifikate sicher bereit und verwalten sie. Die Anthos Service Mesh-Autorisierung erzwingt die Zugriffssteuerung für Mesh-Dienste anhand ihrer Identitäten und anderer Attribute. Das Anthos-Sicherheitsdashboard ermöglicht das Monitoring der 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 Anthos Service Mesh auf dem neuesten Stand, um zu gewährleisten, dass die in Ihrem Mesh-Netzwerk ausgeführten Anthos Service Mesh-Binärdateien frei von öffentlich bekannten Sicherheitslücken sind. Mit Workload Identity können Arbeitslasten Anmeldedaten erhalten, um Google-Dienste sicher aufzurufen. Der Cloud Key Management Service (Cloud KMS) schützt sensible Daten oder Anmeldedaten über Hardwaresicherheitsmodule (HSM). Arbeitslasten können beispielsweise mit Cloud KMS Anmeldedaten oder andere sensible Daten speichern. CA Service wird zum Ausstellen von Zertifikaten für Mesh-Arbeitslasten verwendet und unterstützt Kunden- und HSM-basierte Signaturschlüssel, die von Cloud KMS verwaltet werden. Kubernetes CNI (Container Network Interface) verhindert Angriffe auf die Eskalation von Berechtigungen, da kein privilegierter Anthos Service Mesh-Init-Container benötigt wird.
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. Anthos 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 Anthos Service Mesh.
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. Anthos 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 Anthos Service Mesh können Sie die Mindestversion von TLS für die TLS-Verbindungen zwischen Ihren Arbeitslasten konfigurieren, um Ihre Sicherheits- und Complianceanforderungen zu erfüllen.
Weitere Informationen finden Sie unter Anthos Service Mesh nach Beispiel: mTLS | Mesh-weites mTLS erzwingen.
Zugriffssteuerungen aktivieren
Sicherheitsrichtlinien von Anthos 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 der Anthos Service Mesh-Sicherheitsrichtlinien auszuschließen. In einigen Fällen können Nutzer berechtigt sein, Anthos Service Mesh-Sicherheitsrichtlinien für einige Ports und IP-Bereiche zu umgehen. So können Sie beispielsweise native Verbindungen zu Diensten herstellen, die nicht von Anthos Service Mesh verwaltet werden. Informationen zum Schutz von Anthos Service Mesh bei solchen Anwendungsfällen finden Sie unter Ausnahmen von Anthos Service Mesh-Richtlinien sicher einrichten.
Die Dienstzugriffssteuerung ist wichtig, um nicht autorisierten Zugriff auf Dienste zu verhindern. Die mTLS-Erzwingung verschlüsselt und authentifiziert eine Anfrage, aber ein Mesh-Netzwerk benötigt weiterhin Anthos Service Mesh-Autorisierungsrichtlinien, um die Zugriffssteuerung für Dienste zu erzwingen. Beispielsweise werden nicht autorisierte Anfragen von authentifizierten Clients abgelehnt.
Mit Anthos Service Mesh-Autorisierungsrichtlinien können Sie Zugriffssteuerungen flexibel konfigurieren, um Ihre Dienste vor unbefugtem Zugriff zu schützen. Anthos Service Mesh-Autorisierungsrichtlinien sollten anhand der authentifizierten Identitäten erzwungen werden, die aus den Authentifizierungsergebnissen abgeleitet wurden. mTLS- oder JWT-Authentifizierungen (JSON Web Token) sollten zusammen im Rahmen der Anthos Service Mesh-Autorisierungsrichtlinien verwendet werden.
Anthos 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. Anthos Service Mesh fungiert nicht als JWT-Anbieter, sondern authentifiziert JWTs basierend auf den konfigurierten JSON-JWKS-Endpunkten (JSON Web Key Set). Die JWT-Authentifizierung kann auf Eingangsgateways für externen Traffic oder auf interne Dienste innerhalb des Mesh-Netzwerks angewendet werden. Die JWT-Authentifizierung kann mit der mTLS-Authentifizierung kombiniert werden, wenn ein JWT als Anmeldedaten zur Darstellung des Endnutzers verwendet wird. Der angeforderte Dienst erfordert einen Nachweis, dass er im Namen des Endnutzers aufgerufen wird. Die JWT-Authentifizierung schützt vor Angriffen, die ohne gültige Anmeldedaten und im Namen eines tatsächlichen Endnutzers auf einen Dienst zugreifen.
Anthos Service Mesh-Nutzerauthentifizierung
Die Anthos Service Mesh-Nutzerauthentifizierung ist eine integrierte Lösung zur browserbasierten Endnutzerauthentifizierung und Zugriffssteuerung für Ihre Arbeitslasten. Sie bindet ein Service Mesh in vorhandene Identitätsanbieter (Identity Provider, IdP) ein, um einen standardmäßigen OIDC-Anmeldevorgang und Einwilligungsablauf (OpenID Connect) zu implementieren, und verwendet Anthos Service Mesh-Autorisierungsrichtlinien für die Zugriffssteuerung.
Autorisierungsrichtlinien erzwingen
Steuerung von Anthos Service Mesh-Autorisierungsrichtlinien:
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.
Anthos Service Mesh-Autorisierungsrichtlinien sollten anhand von authentifizierten Identitäten erzwungen werden, die aus den Authentifizierungsergebnissen abgeleitet werden, um Schutz vor nicht autorisiertem Zugriff auf Dienste oder Daten zu bieten.
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.
Hinweis: Anthos Service Mesh verarbeitet keinen Nicht-TCP-Traffic (z. B. UDP). Er kann daher nicht durch Autorisierungsrichtlinien gesteuert werden. Mesh-Administratoren können Kubernetes-Netzwerkrichtlinien verwenden, um Richtlinien für UDP-Traffic zu definieren. Wenn Mesh-Dienste beispielsweise nicht UDP verwenden, können Mesh-Administratoren eine Kubernetes-Netzwerkrichtlinie definieren, um UDP-Traffic zu blockieren.
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.
Anthos Service Mesh unterstützt die Einbindung in Identity-Aware Proxy (IAP), die ein RequestContextToken (ein kurzlebiges Mesh-internes Token, eingetauscht gegen ein externes Token) generiert, das in Anthos Service Mesh für die Autorisierung verwendet wird. Mit dem Austausch von Tokens wird erreicht, dass Angreifer im Mesh-Netzwerk keine gestohlenen Tokens für den Zugriff auf Dienste verwenden können. Der begrenzte Umfang und die Lebensdauer des ausgetauschten Tokens verringern die Wahrscheinlichkeit eines Angriffs durch Tokenwiederholung.
Hinweis: Der IAP-Tokenaustausch unterscheidet sich von der Anthos Service Mesh-Nutzerauthentifizierung darin, dass IAP externe Tokens gegen kurzlebige interne Tokens austauscht, um vor Tokenwiederholungsangriffen zu schützen. Die Anthos Service Mesh-Nutzerauthentifizierung hingegen authentifiziert in einem Webbrowser ausgeführte externe Aufrufe von Webanwendungsdiensten.
Ausnahmen von Anthos Service Mesh-Richtlinien sicher einrichten
Möglicherweise haben Sie spezielle Anwendungsfälle für Ihr Service Mesh. Es kann beispielsweise erforderlich sein, einen bestimmten Netzwerkport verfügbar zu machen, um den Texttraffic zu verarbeiten. Um bestimmte Nutzungsszenarien zu berücksichtigen, müssen Sie manchmal Ausnahmen erstellen, damit bestimmte interne oder externe Zugriffe von Anthos Service Mesh-Sicherheitsrichtlinien ausgeschlossen werden. Dies führt zu Sicherheitsproblemen.
Es kann berechtigt sein, Anthos Service Mesh-Sicherheitsrichtlinien für einige Ports und IP-Bereiche zu umgehen. Sie können Annotationen (z. B. excludeInboundPorts , excludeOutboundPorts , excludeOutboundIPRanges ) zu Pods hinzufügen, um Traffic von der Verarbeitung durch den Envoy-Sidecar auszuschließen. Neben Annotationen zum Ausschließen des Traffics können Sie das Mesh-Netzwerk komplett umgehen. Dazu stellen Sie eine Anwendung mit deaktivierter Sidecar-Injektion bereit. Fügen Sie beispielsweise dem Anwendungs-Pod das Label sidecar.istio.io/inject="false" hinzu:
Das Umgehen von Anthos Service Mesh-Sicherheitsrichtlinien wirkt sich negativ auf die Gesamtsystemsicherheit aus. Wenn beispielsweise Anthos Service Mesh-mTLS und -Autorisierungsrichtlinien für einen Netzwerkport mithilfe von Annotationen umgangen werden, gibt es keine Zugriffssteuerung für den Traffic am Port und Abhören oder Trafficänderungen werden möglich. Darüber hinaus wirkt sich die Umgehung von Anthos Service Mesh-Richtlinien auch auf Richtlinien aus, die nicht sicherheitsrelevant sind, z. B. Netzwerkrichtlinien.
Wenn die Anthos Service Mesh-Sicherheitsrichtlinie für einen Port oder eine IP-Adresse (absichtlich oder unbeabsichtigt) umgangen wird, sollten andere Sicherheitsmaßnahmen vorhanden sein, um das Mesh-Netzwerk zu sichern sowie Sicherheitsausnahmen, potenzielle Sicherheitslücken und den Status der allgemeinen Sicherheitserzwingung zu überwachen. So sichern Sie das Mesh-Netzwerk in solchen Szenarien:
Der Traffic, der die Sidecars umgeht, muss nativ verschlüsselt und authentifiziert werden, um MitM-Angriffe zu verhindern.
Erzwingen Sie Kubernetes-Netzwerkrichtlinien, um die Konnektivität von Ports mit Richtlinienausnahmen zu begrenzen. Beschränken Sie beispielsweise einen Port mit Richtlinienausnahmen, um nur Traffic von einem anderen Dienst im selben Namespace oder nur Traffic über Ports mit erzwungener Anthos Service Mesh-Sicherheitsrichtlinie zuzulassen.
Erzwingen Sie Anthos Policy Controller, um Anthos Service Mesh-Richtlinien automatisch zu validieren. Erzwingen Sie beispielsweise, dass die Anthos Service Mesh-Sidecars immer in Arbeitslasten eingefügt werden.
Kubernetes-Netzwerkrichtlinien erzwingen
Anthos Service Mesh baut auf der zugrunde liegenden Plattform auf (z. B. Kubernetes). Daher hängt die Sicherheit von Anthos Service Mesh von der Sicherheit der zugrunde liegenden Plattform ab. Beispiel: Ohne Kontrolle darüber, wer Kubernetes-Ressourcen aktualisieren kann, kann ein Nutzer das Kubernetes-Deployment eines Dienstes ändern, um die Sidecar-Datei des Dienstes zu umgehen.
Um eine robuste Sicherheitslage für ein Service Mesh zu schaffen, sollten die Sicherheitsmechanismen der zugrunde liegenden Plattform zur gemeinsamen Verwendung mit den Sicherheitsrichtlinien von Anthos Service Mesh erzwungen werden.
Kubernetes-Netzwerkrichtlinien arbeiten auf Netzwerkebene (L3 und L4) für IP-Adressen und Ports auf Kubernetes-Pods und -Namespaces. Kubernetes-Netzwerkrichtlinien können in Verbindung mit Anthos Service Mesh-Richtlinien erzwungen werden, um die Sicherheit des Mesh-Netzwerks zu erhöhen.
Der Mesh-Administrator kann beispielsweise Kubernetes-Netzwerkrichtlinien so konfigurieren, dass Traffic nur Ports mit erzwungener Anthos Service Mesh-Sicherheitsrichtlinie verwenden kann. Wenn der gesamte Traffic mit Anthos Service Mesh mTLS erzwungen werden muss, kann der Administrator eine Kubernetes-Netzwerkrichtlinie konfigurieren, um nur Traffic an Ports zuzulassen, die mit der Anthos Service Mesh-mTLS-Richtlinie konfiguriert sind. Der Mesh-Administrator kann auch Kubernetes-Netzwerkrichtlinien konfigurieren, um die Konnektivität von Ports mit Richtlinienausnahmen zu beschränken. Beispielsweise können Sie die Konnektivität solcher Ports innerhalb eines Namespace beschränken.
Hinweis: Einschränkungen für Kubernetes-Netzwerkrichtlinien. Sie können zwar eine Kubernetes-Netzwerkrichtlinie verwenden, um unerwünschte Konnektivität zu verhindern und Sicherheitslücken von Ports mit umgangenen Sicherheitsrichtlinien zu begrenzen, sie ist jedoch kein Ersatz für Anthos Service Mesh-Sicherheitsrichtlinien, da sie keine Zugriffssteuerungen basierend auf der Anwendungsidentität oder anderen Layer-7-Attributen bietet. Darüber hinaus ist es nur möglich, Pod- und Namespace-Selektoren für Kubernetes-Netzwerkrichtlinien in einem einzelnen Cluster zu verwenden. Pod-IP-Bereiche können mit Multi-Cluster-Mesh verwendet werden, die Richtlinien sind jedoch grob und ihre Verwaltung ist fehleranfällig.
Sicherer Zugriff auf die Steuerungsebene
Die Anthos Service Mesh-Steuerungsebene authentifiziert alle Clients, die eine Verbindung herstellen. Daher können nur Aufrufer mit gültigen Anmeldedaten (Kubernetes-JWT- oder X.509-Zertifikate, die von zulässigen Zertifizierungsstellen ausgestellt werden) auf die Anthos Service Mesh-Steuerungsebene zugreifen. TLS verschlüsselt die Verbindungen zwischen Arbeitslasten und der Anthos Service Mesh-Steuerungsebene.
Neben dem Authentifizierungsmechanismus für Anthos Service Mesh im Cluster können Kubernetes-Netzwerkrichtlinien bereitgestellt werden, um den Anthos Service Mesh-System-Namespace (standardmäßig istio-system) von nicht verwalteten Namespaces und Clients außerhalb des Mesh-Netzwerks zu isolieren, während Datenebenen auf die Steuerungsebene zugreifen können. VPC-Firewallregeln können verhindern, dass Traffic außerhalb eines Clusters Istiod erreicht. Mit solchen Netzwerkisolationsmaßnahmen kann ein Angreifer von außerhalb des Mesh-Netzwerks nicht auf die Steuerungsebene zugreifen, selbst wenn er gültige Anmeldedaten hat. Für verwaltete Steuerungsebenen übernimmt Google die Sicherheit für die Steuerungsebenen und solche Richtlinien zur Netzwerkisolation für Steuerungsebenen sind nicht erforderlich.
Namespace-Grenzen erzwingen
So verhindern Sie, dass der Nutzer eines Namespace auf Ressourcen in einem nicht autorisierten Namespace zugreift bzw. diese aktualisiert:
Erzwingen Sie Zugriffssteuerungen.
Erzwingen Sie Kubernetes-Netzwerkrichtlinien. Wenn Dienste in einem Namespace keinen Traffic außerhalb des Namespace haben, sollte der Mesh-Administrator eine Kubernetes-Netzwerkrichtlinie bereitstellen, die nur Traffic innerhalb des Namespace zulässt: kein eingehender oder ausgehender Traffic in den bzw. aus dem Namespace.
Erzwingen Sie Kubernetes-RBAC-Netzwerkrichtlinien. Die Rollen von Anwendungsadministratoren sollten an einen Namespace gebunden sein. Gewähren Sie nur Mesh-Administratoren die ClusterRole.
Kubernetes-RBAC-Netzwerkrichtlinien erzwingen
Die Mesh-Administratoren sollten Kubernetes RBAC-Richtlinien erzwingen, um zu steuern, wer auf Kubernetes-Ressourcen zugreifen und sie aktualisieren darf. Die Kubernetes-Zugriffssteuerung kann die Sicherheitsrisiken im Mesh-Netzwerk minimieren. Beispielsweise sollten nicht autorisierte Nutzer keine Kubernetes-Deployments ändern und die Erzwingung von Anthos Service Mesh-Richtlinien umgehen können. Die Rollen eines Nutzers sollten an einen Namespace gebunden sein, damit der Nutzer nicht auf mehr Namespaces zugreifen kann, als er benötigt. Ausführliche Anleitungen und Beispiele für die Konfiguration von RBAC finden Sie unter Rollenbasierte Zugriffssteuerung konfigurieren. Nachdem Sie Workload Identity aktiviert haben, können Sie auch ein Kubernetes-Dienstkonto als IAM-Dienstkonto zulassen.
Sicherheit am Edge des Mesh-Netzwerks
Da die meisten Angriffe auch von außerhalb eines Clusters stammen können, ist die Sicherheit am Edge des Mesh-Netzwerks entscheidend.
Zugriffssteuerung für eingehenden Cluster-Traffic
Anthos Service Mesh empfängt eingehenden externen Traffic über das Eingangsgateway. Über das Eingangsgateway bereitgestellte Dienste sind möglicherweise Angriffe von externen Quellen ausgesetzt. Sicherheitsadministratoren sollten Dienste, die externem Traffic über Eingangsgateways ausgesetzt sind, immer ausreichend sichern, um sie vor Angriffen zu schützen.
Bei eingehendem Traffic sollten Authentifizierung und Autorisierung für Dienste erzwungen werden, die externen Aufrufern zur Verfügung gestellt werden.
Sicherheitsrichtlinien für eingehenden Cluster-Traffic erzwingen Wenn der Cluster externen Traffic empfangen muss, sollte der Mesh-Administrator Richtlinien für eingehenden Traffic erzwingen, einschließlich Anthos Service Mesh-Gateway-TLS sowie Authentifizierungs- und Autorisierungsrichtlinien, um externe Anfragen zu authentifizieren und zu prüfen, ob sie auf Dienste zugreifen dürfen, die über das Eingangsgateway zur Verfügung gestellt werden. Die Erzwingung von Sicherheitsrichtlinien für eingehenden Traffic schützt vor Angriffen von außerhalb des Mesh-Netzwerks, die versuchen, ohne gültige Anmeldedaten oder Berechtigungen auf einen Dienst zuzugreifen.
Verwenden Sie Cloud Armor als Web Application Firewall (WAF) zum Schutz vor webbasierten Angriffen wie Injektionsangriffen und Remote-Ausführungsangriffen. Weitere Informationen finden Sie unter Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Ingress verfügbar machen.
Ausgehenden Cluster-Traffic regulieren
Die Sicherheit des ausgehenden Cluster-Traffics ist für die Sicherheit des Mesh-Netzwerks entscheidend, da Sicherheitsrichtlinien für ausgehenden Traffic vor Daten-Exfiltration-Angriffen schützen, die Filterung von ausgehendem Traffic erzwingen und den TLS-Ursprung für ausgehenden Traffic erzwingen können. Sicherheitsadministratoren sollten den ausgehenden Cluster-Traffic regulieren und prüfen.
Zusätzlich zur Verwendung von VPC-Firewalls, um ausgehenden Traffic zu beschränken, sollten die Administratoren des Mesh-Netzwerks auch Sicherheitsrichtlinien für ausgehenden Cluster-Traffic erzwingen und ausgehenden Traffic so konfigurieren, dass er Ausgangsgateways durchläuft.
Richtlinien für ausgehenden Traffic können die folgenden Angriffe minimieren:
Daten-Exfiltration-Angriffe.
Dienst-Pods können von Angreifern ausgenutzt werden, wenn ihre CVEs nicht gepatcht wurden. Manipulierte Pods können zu einem von Angreifern kontrollierten Botnet werden, das Spam sendet oder DoS-Angriffe startet.
Mit Autorisierungsrichtlinien für Eingangsgateways kann sichergestellt werden, dass nur autorisierte Dienste Traffic an bestimmte Hosts außerhalb des Mesh-Netzwerks senden dürfen. Für Traffic, der das Mesh-Netzwerk verlässt, kann der TLS-Ursprung an Ausgangsgateways erfolgen, anstatt an einzelnen Sidecars. So kann der TLS-Ursprung für Traffic einheitlich und sicher erfolgen, da die Clientzertifikate für mTLS von den Namespaces isoliert werden können, in denen Anwendungen ausgeführt werden.
Mit privatem Cluster oder VPC Service Control externe Zugriffe sperren
Sie erzwingen Richtlinien für eingehenden und ausgehenden Traffic und sperren externen Zugriff mit einem privaten Cluster oder VPC Service Controls, sofern möglich. Sicherheitsrichtlinien werden von Sicherheitsadministratoren für das Mesh-Netzwerk gesteuert. Die Konfiguration eines privaten Clusters oder von VPC Service Controls hingegen kann von Sicherheitsadministratoren der Organisation erzwungen werden.
VPC Service Controls kann erzwungen werden, um einen Sicherheitsbereich für die Dienste zu definieren. Damit können Sie Folgendes erreichen:
Verhindern, dass Dienste auf externe Ressourcen zugreifen.
Verhindern, dass externe Nutzer auf die Dienste in einem Sicherheitsperimeter zugreifen.
VPC Service Controls trägt zum Schutz vor Daten-Exfiltration-Angriffen bei und verhindert, dass externe Angreifer auf Dienste innerhalb eines Mesh-Netzwerks zugreifen.
Schutz vor externen DDoS-Angriffen
Externe DDoS-Angriffe können Eingangsgateways und Back-End-Dienste überlasten, sodass legitime Anfragen nicht verarbeitet werden. Cloud Armor kann zum Schutz vor DDoS-Angriffen verwendet werden. Cloud Armor schützt nicht nur vor DDoS-Angriffen auf Netzwerkebene (L3 und L4), sondern auch vor DDoS-Angriffen auf Anwendungsebene (L7).
Sicherheit bei der Verwaltung und Automatisierung von Mesh-Netzwerken
Es ist wichtig, die Sicherheit für administrative Vorgänge und Automatisierungen zu berücksichtigen, die Sie für Ihr Mesh-Netzwerk einrichten, z. B. CI/CD. Mit den folgenden Vorgehensweisen können Sie für einen sicheren Betrieb des Mesh-Netzwerks sorgen, ohne das Risiko, Dienste zusätzlichen Angriffen auszusetzen.
Rollen für Vorgänge im Mesh-Netzwerk segmentieren
Nach dem Prinzip der rollenbasierten Zugriffssteuerung sollten Nutzer eines Mesh-Netzwerks nach ihren Rollen klassifiziert werden. Jeder Rolle sollte nur der Mindestsatz an Berechtigungen gewährt werden, der für die Rolle benötigt wird.
Beispielsweise sollte die Gruppe von Nutzern, die Dienstbereitstellungen durchführen, keine Berechtigungen zum Aktualisieren von Authentifizierungs- und Autorisierungsrichtlinien haben.
Es gibt verschiedene Operatorkategorien. Beispiel: Clusteroperatoren und Namespace-Operatoren. Es ist wichtig, die Rechteausweitung bei einem Operator zu verhindern, was zu einem unberechtigten Zugriff auf nicht autorisierte Ressourcen führen kann.
Mit Kubernetes-RBAC-Richtlinien können Mesh-Administratoren den Ressourcenzugriff nur auf autorisierte Nutzer beschränken.
Wenn Operatoren Anthos Service Mesh-Richtlinien versehentlich falsch konfigurieren, kann dies zu schwerwiegenden Sicherheitsvorfällen führen. Mesh-Administratoren können Policy Controller verwenden, um Einschränkungen bei Richtlinienkonfigurationen zu erzwingen und damit Fehlkonfigurationen zu vermeiden und Anthos Service Mesh-Richtlinien automatisch zu validieren.
Mesh-Administratoren sollten Einschränkungen für Anthos Service Mesh-Richtlinien mit Policy Controller implementieren, um Nutzern mit Berechtigungen zum Aktualisieren von Anthos Service Mesh-Sicherheitsrichtlinien und Validieren von Anthos Service Mesh-Richtlinien nicht zu viel Vertrauen entgegenzubringen.
Policy Controller basiert auf dem Open-Source-Projekt Gatekeeper und kann entweder als Kubernetes-Admission-Controller ausgeführt werden, um die Anwendung ungültiger Ressourcen zu verhindern, oder im Prüfmodus, damit Administratoren über Richtlinienverstöße informiert werden. Policy Controller kann die Bereitstellung von Ressourcen im Mesh-Netzwerk automatisch validieren, beispielsweise indem geprüft wird, dass die Annotationen in einer Bereitstellung keine Anthos Service Mesh-Richtlinien umgehen, die Anthos Service Mesh-Richtlinien wie erwartet funktionieren und Deployments keine Root-Funktionen wie NET_ADMIN und NET_RAW enthalten.
Policy Controller kann auch vorhandene Anthos Service Mesh-Ressourcen auf Einschränkungen prüfen, um Fehlkonfigurationen bei Richtlinien zu erkennen.
Hier sind einige Beispiele dafür, wie Anthos Policy Controller zu Erzwingung von Sicherheitsrichtlinien verwendet werden kann:
Die mit Policy Controller bereitgestellte Einschränkungsvorlagenbibliothek enthält eine Reihe von Einschränkungsvorlagen, die mit den vorkonfigurierten Bundle von Anthos Service Mesh-Sicherheitseinschränkungen verwendet werden können, um bestimmte Best Practices für Anthos Service Mesh-Sicherheit zu erzwingen, z. B. Authentifizierungs-, Autorisierungs- und Trafficrichtlinien. Im Folgenden sind einige Beispieleinschränkungen aufgeführt, die im Bundle enthalten sind:
PeerAuthentication mit strikter mTLS auf Mesh-Ebene erzwingen.
Erzwingen, dass PeerAuthentications keine strikte mTLS-Authentifizierung überschreiben können.
AuthorizationPolicy für standardmäßige Ablehnung auf Mesh-Ebene erzwingen.
Sichere Muster der AuthorizationPolicy erzwingen.
Erzwingen, dass Anthos Service Mesh-Sidecars immer in Arbeitslasten eingeschleust werden.
Zum Umgang mit Ausnahmen und Break-Glass-Situationen kann der Mesh-Administrator Folgendes tun:
Mit GitOps-Ansatz und Config Sync Konfigurationsabweichungen verhindern
Konfigurationsabweichungen treten auf, wenn die Konfiguration von Richtlinien in einem Mesh von ihrer "Source of Truth" abweicht. Mit Config Sync können Sie Konfigurationsabweichungen verhindern.
Audit-Logging und Monitoring erzwingen
Mesh-Administratoren sollten Folgendes überwachen:
Diese Beobachtbarkeitsressourcen können verwendet werden, um zu prüfen, ob die Sicherheitskonfiguration wie erwartet funktioniert, und um Ausnahmen von der Erzwingung von Sicherheitsrichtlinien zu überwachen. Beispiel: Zugriff, der nicht über Sidecars geleitet wurde, Zugriff, der keine gültigen Anmeldedaten hatte, aber einen Dienst erreicht hat.
Open-Source-Beobachtbarkeitssoftware (z. B. Prometheus) kann zwar mit Anthos Service Mesh verwendet werden, doch wird dringend empfohlen, die Operations Suite von Google Cloud (ehemals Stackdriver) zu verwenden.. Die integrierte Beobachtbarkeitslösung für Google Cloud bietet vollständig verwaltete und nutzerfreundliche Funktionen für Logging, Messwerterfassung, Monitoring und Benachrichtigungen.
Zertifizierungsstelle für clusterinterne Zertifikate schützen
Standardmäßig verwendet Anthos Service Mesh eine von Google verwaltete Zertifizierungsstelle namens Anthos Service Mesh (Mesh CA).
Wenn Sie die nicht verwaltete Istio-Zertifizierungsstelle (CA) verwenden, die als Teil von Istiod gehostet wird, wird der Signaturschlüssel der Zertifizierungsstelle in einem Kubernetes-Secret gespeichert und kann von Operatoren mit Zugriff auf die Secret-Ressource im Namespace istio-system aufgerufen werden. Dies ist ein Risiko, da ein Operator den CA-Schlüssel möglicherweise unabhängig von der CA von Istiod verwenden und möglicherweise Arbeitslastzertifikate unabhängig signieren kann. Es besteht auch die Gefahr, dass ein selbstverwalteter CA-Signaturschlüssel aufgrund eines Betriebsfehlers versehentlich gestohlen wird.
Zum Schutz des CA-Signaturschlüssels kann der Mesh-Administrator das Mesh-Netzwerk für die Verwendung von Mesh CA oder Certificate Authority Service (CA Service) aktualisieren, die von Google gesichert und verwaltet werden (z. B. CA-Schlüsselrotation). Im Vergleich zu Mesh CA unterstützt CA Service kundenspezifische, HSM-gesicherte Signaturschlüssel über Cloud KMS, gestützt durch Cloud HSM.
Arbeitslastsicherheit
Die Arbeitslastsicherheit schützt vor Angriffen, bei denen Arbeitslast-Pods manipuliert und diese manipulierten Pods dann für Angriffe auf den Cluster (z. B. Botnet-Angriffe) genutzt werden.
Pod-Berechtigungen einschränken
Ein Kubernetes-Pod kann Berechtigungen haben, die sich auf andere Pods auf dem Knoten oder dem Cluster auswirken. Es ist wichtig, Sicherheitseinschränkungen für Arbeitslast-Pods zu erzwingen, um zu verhindern, dass ein manipulierter Pod Angriffe auf den Cluster startet.
So erzwingen Sie das Prinzip der geringsten Berechtigung für die Arbeitslasten auf einem Pod:
Die in einem Mesh-Netzwerk bereitgestellten Dienste sollten mit möglichst wenigen Berechtigungen ausgeführt werden.
Kubernetes-Pods, die im privilegierten Modus ausgeführt werden, können Netzwerkstacks und andere Kernelfunktionen auf dem Host bearbeiten. Mit Anthos Policy Controller können Sie verhindern, dass Pods privilegierte Container ausführen.
Anthos Service Mesh kann so konfiguriert werden, dass es einen init-Container verwendet, um die iptables-Trafficweiterleitung an die Sidecar-Datei einzurichten. Dadurch muss der Nutzer, der Arbeitslasten-Deployments erstellt, Berechtigungen zum Bereitstellen von Containern mit den Funktionen NET_ADMIN und NET_RAW haben. Damit keine Container mit erhöhten Berechtigungen ausgeführt werden, können Mesh-Administratoren stattdessen das Istio CNI-Plug-in aktivieren, um die Traffic-Weiterleitung an die Sidecar-Dateien zu konfigurieren.
Container-Images sichern
Angreifer können Angriffe starten, indem sie anfällige Container-Images ausnutzen. Administratoren sollten die Binärautorisierung erzwingen, um die Integrität von Container-Images zu prüfen und sicherzustellen, dass nur vertrauenswürdige Container-Images im Mesh bereitgestellt werden.
Sicherheitslücken in Mesh-Netzwerken minimieren
Container Analysis. Container Analysis kann Sicherheitslücken in GKE-Arbeitslasten scannen und erkennen.
Umgang mit CVEs (Common Vulnerabilities and Exposures). In einem Container-Image erkannte Sicherheitslücken sollten von den Mesh-Administratoren so schnell wie möglich behoben werden. Für verwaltetes Anthos Service Mesh mit verwalteter Datenebene wendet Google automatisch Patching auf das Mesh-Netzwerk betreffende CVEs an.
Workload Identity für einen sicheren Zugriff auf Google-Dienste verwenden
Workload Identity ist die empfohlene Methode für Mesh-Arbeitslasten, um sicher auf Google-Dienste zuzugreifen. Die Alternative zum Speichern eines Dienstkontoschlüssels in einem Kubernetes-Secret und zur Verwendung des Dienstkontoschlüssels für den Zugriff auf Google-Dienste ist aufgrund der Risiken von Datenlecks, Rechteausweitung, Offenlegung von Informationen und Nachweisbarkeit nicht so sicher.
Sicherheitsstatus über Sicherheitsdashboard und Telemetrie überwachen
Ein Service Mesh kann Sicherheitsausnahmen und potenzielle Sicherheitsücken haben. Es ist wichtig, den Sicherheitsstatus eines Mesh-Netzwerks aufzuzeigen und zu überwachen. Dazu gehören die erzwungenen Sicherheitsrichtlinien, Sicherheitsausnahmen und potenzielle Sicherheitslücken im Mesh-Netzwerk. Mit dem Anthos-Sicherheitsdashboard und Telemetrie kann der Mesh-Sicherheitsstatus aufgezeigt und überwacht werden.
Telemetrie überwacht den Zustand und die Leistung von Diensten in einem Mesh-Netzwerk, sodass Mesh-Administratoren das Verhalten von Diensten (z. B. SLOs, abnormaler Traffic, Dienstausfall, Topologie) beobachten können.
Das Anthos-Sicherheitsdashboard analysiert und visualisiert die Sicherheitsrichtlinien, die auf eine Arbeitslast in einem Service Mesh angewendet werden, einschließlich Zugriffssteuerungsrichtlinien (Kubernetes-Netzwerkrichtlinien, Richtlinien für die Binärautorisierung und Richtlinien für die Dienstzugriffssteuerung) und Authentifizierungsrichtlinien (mTLS).
Sicherheit für vertrauliche Nutzerdaten und Anmeldedaten
Vertrauliche Nutzerdaten oder Anmeldedaten können anfällig für Angriffe durch Pods oder schädliche Vorgänge sein, die im nichtflüchtigen Clusterspeicher gespeichert sind, z. B. mithilfe von Kubernetes-Secrets oder direkt in Pods. Sie sind auch anfällig für Netzwerkangriffe, wenn sie zur Authentifizierung bei Diensten über das Netzwerk übertragen werden.
Speichern Sie vertrauliche Nutzerdaten und Anmeldedaten nach Möglichkeit in einem geschützten Speicher wie Secret Manager und Cloud KMS.
Legen Sie separate Namespaces für Kubernetes-Pods fest, die auf vertrauliche Daten zugreifen, und definieren Sie Kubernetes-Richtlinien, damit die Namespaces nicht von anderen Namespaces aus zugänglich sind. Segmentieren Sie die Rollen, die für Vorgänge verwendet werden, und erzwingen Sie Namespace-Grenzen.
Erzwingen Sie den Tokenaustausch, um die Exfiltration von langlebigen Tokens mit hohen Berechtigungen zu verhindern.
Nächste Schritte
