Sechs Möglichkeiten, Kubernetes mit Traffic-Management-Tools abzusichern

Jenn GileLeiter Produktmarketing, NGINX

Redaktion – Dieser Beitrag ist Teil einer zehnteiligen Serie:

1. Komplexität mit produktionsreifem Kubernetes reduzieren
2. So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Traffic-Management
3. So verbessern Sie die Transparenz in Kubernetes
4. Sechs Möglichkeiten, Kubernetes mithilfe von Traffic-Management-Tools abzusichern (dieser Beitrag)
5. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
6. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit
7. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 3: Open Source vs. Standardlösung vs. kommerzielle Lösung
8. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für den NGINX Ingress Controller
9. So wählen Sie ein Service Mesh aus
10. Leistungstests von NGINX Ingress Controllern in einer dynamischen Kubernetes-Cloud-Umgebung

Sie können die vollständige Blogreihe auch als kostenloses E-Book herunterladen: „Kubernetes von der Test- in die Produktionsumgebung überführen“.

Wie in „Cloud-native Anwendungen sicher gestalten, ohne an Geschwindigkeit einzubüßen“ erläutert, haben wir drei Faktoren festgestellt, die dazu führen, dass Cloud-native Anwendungen schwieriger abzusichern sind als herkömmliche Anwendungen:

1. Die Bereitstellung cloudnativer Anwendungen führt zu einer unübersichtlichen Vielzahl von Tools und bietet uneinheitliche Services auf Unternehmensniveau.
2. Die Kosten für die Bereitstellung cloudnativer Anwendungen können unvorhersehbar und hoch sein
3. SecOps-Teams haben Schwierigkeiten, cloudnative Anwendungen zu schützen, und stehen im Konflikt mit DevOps

Obwohl alle drei Faktoren die Sicherheit gleichermaßen beeinträchtigen können, ist der dritte Faktor möglicherweise am schwierigsten zu bewältigen – vielleicht, weil er am stärksten vom „Faktor Mensch“ geprägt ist. Wenn SecOps nicht in der Lage oder nicht befugt ist, Cloud-native-Anwendungen zu schützen, liegen einige der Folgen auf der Hand (Schwachstellen und Sicherheitsverletzungen), während andere verborgen bleiben, darunter eine geringere Agilität und eine ins Stocken geratene digitale Transformation.

Sehen wir uns diese versteckten Kosten genauer an. Unternehmen entscheiden sich für Kubernetes, weil es Agilität und Kosteneinsparungen verspricht. Kommt es jedoch in einer Kubernetes-Umgebung zu Sicherheitsvorfällen, nehmen die meisten Unternehmen ihre Kubernetes-Bereitstellungen aus dem Produktivbetrieb. Das bremst Initiativen zur digitalen Transformation aus, die für die Zukunft des Unternehmens unerlässlich sind – ganz zu schweigen von der vergeudeten Entwicklungsarbeit und den verschwendeten finanziellen Mitteln. Die logische Schlussfolgerung lautet: Wenn Kubernetes vom Test- in den Produktivbetrieb überführt werden soll, muss Sicherheit als strategische Komponente betrachtet werden, für die alle im Unternehmen Verantwortung tragen.

In diesem Beitrag stellen wir sechs Sicherheitsanwendungsfälle vor, die Sie mit Kubernetes-Tools für das Traffic-Management lösen können. So können SecOps, DevOps und NetOps zusammenarbeiten, um Ihre cloudnativen Anwendungen und APIs besser zu schützen. Häufig werden mehrere dieser Techniken kombiniert, um eine umfassende Sicherheitsstrategie zu entwickeln, die Anwendungen und APIs schützt und zugleich die Auswirkungen auf Kunden minimiert.

1. CVEs schnell beheben, um Cyberangriffe zu verhindern
2. OWASP-Top-10- und Denial-of-Service-Angriffe abwehren
3. Authentifizierung und Autorisierung aus Apps auslagern
4. Self-Service mit Leitplanken einrichten
5. Ende-zu-Ende-Verschlüsselung implementieren
6. Stellen Sie sicher, dass die Clients ein starkes Verschlüsselungsverfahren mit einer vertrauenswürdigen Implementierung verwenden.

Terminologie zu Sicherheit und Identität

Bevor wir uns den Anwendungsfällen widmen, geben wir Ihnen einen kurzen Überblick über einige Begriffe aus den Bereichen Sicherheit und Identität, die Ihnen in diesem Beitrag begegnen werden.

• Authentifizierung und Autorisierung – Funktionen, die sicherstellen, dass nur die „richtigen“ Benutzer und Dienste auf Backends oder Anwendungskomponenten zugreifen können:
  • Authentifizierung – Überprüfung der Identität, um sicherzustellen, dass Clients, die Anfragen stellen, tatsächlich die sind, für die sie sich ausgeben. Dies erfolgt mithilfe von Identitätsnachweisen wie Passwörtern oder JSON Web Tokens (JWTs).
  • Autorisierung – Überprüfung der Berechtigung für den Zugriff auf eine Ressource oder Funktion. Dies erfolgt mithilfe von Zugriffstoken, beispielsweise durch Attribute der Schicht 7 wie Sitzungscookies, Sitzungs-IDs, Gruppen-IDs oder Token-Inhalte.
• Critical Vulnerabilities and Exposures (CVEs) – Eine Datenbank öffentlich bekannt gegebener Schwachstellen „in einer Software-, Firmware-, Hardware- oder Dienstkomponente, die auf eine ausnutzbare Schwäche zurückzuführen sind und sich negativ auf die Vertraulichkeit, Integrität oder Verfügbarkeit einer betroffenen Komponente oder mehrerer betroffener Komponenten auswirken können“ (https://www.cve.org/). CVEs können von den Entwicklern entdeckt werden, die das Tool verwalten, von einem Penetrationstester, einem Benutzer oder Kunden oder von jemandem aus der Community (etwa einem „Bug Hunter“). Üblicherweise wird dem Softwareanbieter Zeit gegeben, einen Patch zu entwickeln, bevor die Schwachstelle öffentlich bekannt gegeben wird, damit böswillige Akteure keinen Vorteil daraus ziehen können.
• Denial-of-Service-Angriff (DoS-Angriff) – Ein Angriff, bei dem ein Angreifer eine Website mit Anfragen (TCP/UDP oder HTTP/HTTPS) überflutet, um sie zum Absturz zu bringen. Da DoS-Angriffe die Verfügbarkeit beeinträchtigen, besteht ihre primäre Auswirkung darin, den Ruf des Ziels zu schädigen. Ein verteilter Denial-of-Service-Angriff (DDoS-Angriff), bei dem mehrere Quellen dasselbe Netzwerk oder denselben Dienst angreifen, ist aufgrund des potenziell großen Netzwerks von Angreifern schwieriger abzuwehren. Der Schutz vor DoS-Angriffen erfordert ein Tool, das Angriffe adaptiv erkennt und verhindert. Weitere Informationen finden Sie unter Was ist ein verteilter Denial-of-Service-Angriff (DDoS)?
• Ende-zu-Ende-Verschlüsselung (E2EE) – Die vollständige Verschlüsselung von Daten bei der Übertragung vom Benutzer zur App und zurück. E2EE erfordert SSL-Zertifikate und gegebenenfalls mTLS.
• Mutual TLS (mTLS) – Die Praxis, sowohl für den Client als auch für den Host eine Authentifizierung (mittels SSL/TLS-Zertifikat) zu verlangen. Der Einsatz von mTLS schützt zudem die Vertraulichkeit und Integrität der zwischen Client und Host übertragenen Daten. mTLS kann bis hinunter auf die Ebene der Kubernetes-Pods zwischen zwei Diensten im selben Cluster implementiert werden. Eine hervorragende Einführung in SSL/TLS und mTLS finden Sie unter „Was ist mTLS?“ bei F5 Labs.
• Einmalanmeldung (Single Sign-on, SSO) – SSO-Technologien (einschließlich SAML, OAuth und OIDC) erleichtern die Verwaltung von Authentifizierung und Autorisierung.
  • Vereinfachte Authentifizierung – SSO macht es überflüssig, dass ein Benutzer für jede einzelne Ressource oder Funktion ein eigenes ID-Token benötigt.
  • Standardisierte Autorisierung – SSO erleichtert die Vergabe von Benutzerzugriffsrechten auf Grundlage von Rolle, Abteilung und Hierarchieebene, sodass Berechtigungen nicht für jeden Benutzer einzeln konfiguriert werden müssen.
• SSL (Secure Sockets Layer)/TLS (Transport Layer Security) – Ein Protokoll zum Herstellen authentifizierter und verschlüsselter Verbindungen zwischen vernetzten Computern. SSL/TLS-Zertifikate bestätigen die Identität einer Website und stellen eine verschlüsselte Verbindung her. Obwohl das SSL-Protokoll 1999 eingestellt und durch das TLS-Protokoll ersetzt wurde, werden diese verwandten Technologien nach wie vor häufig als „SSL“ oder „SSL/TLS“ bezeichnet – der Einheitlichkeit halber verwenden wir im weiteren Verlauf dieses Beitrags SSL/TLS.
• Web Application Firewall (WAF) – Ein Reverse-Proxy zur Erkennung und Abwehr komplexer Angriffe auf Anwendungen und APIs (einschließlich der OWASP Top 10 und anderer fortschrittlicher Bedrohungen), der gleichzeitig „sicheren“ Datenverkehr passieren lässt. WAFs schützen vor Angriffen, die darauf abzielen, dem Ziel durch den Diebstahl sensibler Daten oder die Übernahme des Systems zu schaden. Einige Anbieter bündeln WAF- und DoS-Schutz in einem einzigen Tool, während andere separate Tools für WAF- und DoS-Schutz anbieten.
• Zero Trust – Ein Sicherheitskonzept, das häufig in Organisationen mit hohen Sicherheitsanforderungen eingesetzt wird, aber für alle relevant ist. Dabei müssen Daten in allen Phasen der Speicherung und Übertragung geschützt werden. Das bedeutet, dass die Organisation beschlossen hat, Benutzern oder Geräten nicht standardmäßig zu „vertrauen“, sondern den gesamten Datenverkehr gründlich zu überprüfen. Eine Zero-Trust-Architektur umfasst in der Regel eine Kombination aus Authentifizierung, Autorisierung und mTLS, wobei die Organisation mit hoher Wahrscheinlichkeit auch E2EE implementiert.

Anwendungsfall: CVEs schnell beheben, um Cyberangriffe zu verhindern

Lösung: Verwenden Sie Tools mit zeitnahen und proaktiven Benachrichtigungen über Patches

Laut einer Studie des Ponemon Institute betrug die durchschnittliche „Schonfrist“ im Jahr 2019 43 Tage – von der Veröffentlichung eines Patches für eine kritische oder hochpriorisierte Schwachstelle bis zu den ersten Angriffen auf Unternehmen, bei denen versucht wurde, diese Schwachstelle auszunutzen. Bei F5 NGINX haben wir beobachtet, dass sich dieses Zeitfenster in den darauffolgenden Jahren deutlich verkürzt hat (im Fall von Apple iOS 15 im Jahr 2021 sogar bis auf Tag null). Deshalb empfehlen wir, Patches so schnell wie möglich einzuspielen. Doch was ist, wenn Patches für Ihre Traffic-Management-Tools erst Wochen oder sogar Monate nach Bekanntgabe einer CVE verfügbar sind?

Bei Tools, die von Mitwirkenden aus der Community (und nicht von einem eigens dafür zuständigen Entwicklungsteam) entwickelt und gepflegt werden, kann es nach der Bekanntgabe von CVEs Wochen oder Monate dauern, bis sie aktualisiert werden. Daher ist es unwahrscheinlich, dass Unternehmen innerhalb dieses 43-Tage-Zeitfensters Patches einspielen können. In einem Fall dauerte es vier Monate, bis OpenResty einen NGINX-bezogenen Sicherheitspatch implementierte. Dadurch waren alle, die einen auf OpenResty basierenden Ingress-Controller verwendeten, mindestens vier Monate lang gefährdet. Realistisch betrachtet kommt jedoch meist noch eine weitere Verzögerung hinzu, bevor Patches für Software verfügbar sind, die von einem Open-Source-Projekt abhängt.

Um CVE-Sicherheitslücken so schnell wie möglich zu schließen, sollten Sie bei der Auswahl von Traffic-Management-Tools auf zwei Merkmale achten:

• Ein dediziertes Entwicklungsteam – Wenn die Entwicklung des Tools von einem Entwicklungsteam statt von freiwilligen Mitgliedern der Community betreut wird, können Sie sicher sein, dass sich eine Gruppe von Fachleuten um die Funktionsfähigkeit des Tools kümmert und die schnellstmögliche Veröffentlichung eines Patches priorisieren kann.
• Eine integrierte Codebasis – Da keine externen Abhängigkeiten bestehen (wie im Zusammenhang mit OpenResty erläutert), lassen sich Patches innerhalb eines einzigen agilen Sprints bereitstellen.

Weitere Informationen zum Beheben von CVEs finden Sie unter „Sicherheitslücken mit NGINX Plus schnell und einfach schließen“.

Anwendungsfall: OWASP-Top-10- und DoS-Angriffe abwehren

Lösung: Stellen Sie einen flexiblen, Kubernetes-freundlichen WAF- und DoS-Schutz bereit

Die Wahl des richtigen WAF- und DoS-Schutzes für Kubernetes-Anwendungen hängt – neben dem Funktionsumfang – von zwei Faktoren ab:

• Flexibilität – In manchen Szenarien ist es am besten, Tools innerhalb von Kubernetes bereitzustellen. Daher benötigen Sie infrastrukturunabhängige Tools, die sowohl innerhalb als auch außerhalb von Kubernetes ausgeführt werden können. Wenn Sie für alle Ihre Bereitstellungen dasselbe Tool verwenden, können Sie Richtlinien wiederverwenden und den Einarbeitungsaufwand für Ihre SecOps-Teams reduzieren.
• Ressourcenbedarf – Die besten Kubernetes-Tools haben einen geringen Ressourcenbedarf. Dadurch verbrauchen sie angemessen wenig Ressourcen und beeinträchtigen Durchsatz, Anfragen pro Sekunde und Latenz nur minimal. Da DevOps-Teams Sicherheitstools häufig ablehnen, weil sie befürchten, dass diese Anwendungen verlangsamen, kann die Wahl eines leistungsstarken Tools mit geringem Ressourcenbedarf die Akzeptanz erhöhen.

Ein Tool, das WAF- und DoS-Schutz kombiniert, mag zwar effizienter erscheinen, tatsächlich ist jedoch sowohl bei der CPU-Auslastung (aufgrund des größeren Ressourcenbedarfs) als auch bei der Flexibilität mit Problemen zu rechnen. Sie sind gezwungen, den WAF- und DoS-Schutz gemeinsam bereitzustellen, selbst wenn Sie nicht beides benötigen. Letztlich können beide Aspekte die Gesamtbetriebskosten Ihrer Kubernetes-Bereitstellungen erhöhen und zugleich das Budget für andere unverzichtbare Tools und Dienste belasten.

Nachdem Sie die richtigen Sicherheitstools für Ihr Unternehmen ausgewählt haben, müssen Sie entscheiden, wo diese Tools bereitgestellt werden sollen. An vier Stellen können Anwendungsdienste üblicherweise bereitgestellt werden, um Kubernetes-Anwendungen zu schützen:

• Am Eingangspunkt (auf einem externen Load Balancer wie F5 NGINX Plus oder F5 BIG‑IP) – Gut geeignet für einen globalen Schutz mit geringer Granularität, da sich damit globale Richtlinien clusterübergreifend anwenden lassen
• Am Netzwerkrand (auf einem Ingress-Controller wie dem F5 NGINX Ingress Controller) – Ideal für einen „feingranularen“ Schutz, der einheitlich für einen einzelnen Cluster gilt
• Auf Dienstebene (auf einem schlanken Load Balancer wie NGINX Plus) – Dieser Ansatz kann erforderlich sein, wenn es innerhalb eines Clusters eine kleine Anzahl von Diensten gibt, die gemeinsam spezielle Richtlinien benötigen
• Auf Pod-Ebene (als Teil der Anwendung) – Ein stark individualisierter Ansatz, der sich anbietet, wenn die Richtlinie speziell auf die Anwendung zugeschnitten ist

Welche der vier Optionen ist also die beste? Nun ja … das kommt darauf an!

Wo eine WAF bereitgestellt werden sollte

Zunächst betrachten wir die Optionen für die Bereitstellung einer WAF, da diese Entscheidung in der Regel etwas differenzierter ausfällt.

• Eingangspunkt und Edge – Wenn Ihr Unternehmen eine mehrschichtige Sicherheitsstrategie („Defense in Depth“) bevorzugt, empfehlen wir, sowohl am externen Load Balancer als auch am Ingress-Controller eine WAF bereitzustellen, um globale und benutzerdefinierte Schutzmaßnahmen effizient miteinander zu kombinieren.
• Eingangspunkt oder Edge – Wenn keine mehrschichtige Sicherheitsstrategie („Defense in Depth“) verfolgt wird, ist ein einzelner Bereitstellungsort ausreichend. Welcher Ort gewählt wird, hängt von den Zuständigkeiten ab. Ist ein klassisches NetOps-Team für die Sicherheit verantwortlich, bevorzugt es möglicherweise die Verwaltung über einen herkömmlichen Proxy (den externen Load Balancer). DevSecOps-Teams hingegen, die mit Kubernetes vertraut sind und ihre Sicherheitskonfiguration möglichst in der Nähe ihrer Clusterkonfigurationen verwalten möchten, können eine WAF auf Ingress-Ebene bereitstellen.
• Pro Dienst oder Pod – Wenn Ihre Teams spezifische Anforderungen an ihre Dienste oder Anwendungen haben, können sie bei Bedarf zusätzliche WAFs bereitstellen. Beachten Sie jedoch, dass diese Bereitstellungsorte mit höheren Kosten verbunden sind. Neben einem höheren Entwicklungsaufwand und einem größeren Cloud-Budget kann diese Entscheidung auch die Betriebskosten für die Fehlerbehebung erhöhen – etwa bei der Klärung der Frage: „Welche unserer WAFs blockiert unbeabsichtigt den Datenverkehr?“

Wo DoS-Schutz bereitgestellt werden sollte

Der Schutz vor DoS-Angriffen ist einfacher, da er nur an einer Stelle benötigt wird – entweder am Front Door oder am Ingress-Controller. Wenn Sie sowohl am Front Door als auch am Edge eine WAF bereitstellen, empfehlen wir, den DoS-Schutz vor der Front-Door-WAF zu platzieren, da diese den größten globalen Wirkungsbereich hat. So lässt sich unerwünschter Datenverkehr reduzieren, bevor er die WAF erreicht, wodurch Sie Rechenressourcen effizienter nutzen können.

Weitere Informationen zu den einzelnen Bereitstellungsszenarien finden Sie unter „Bereitstellung von Anwendungsdiensten in Kubernetes, Teil 2“.

Anwendungsfall: Authentifizierung und Autorisierung aus Apps auslagern

Lösung: Authentifizierung und Autorisierung am Eingangspunkt zentralisieren

Eine häufige nicht funktionale Anforderung, die in Anwendungen und Dienste integriert wird, ist die Authentifizierung und Autorisierung. In kleinem Maßstab führt dies zu einer überschaubaren zusätzlichen Komplexität, die vertretbar ist, wenn die Anwendung nicht häufig aktualisiert werden muss. Bei einer höheren Veröffentlichungsgeschwindigkeit und in größerem Maßstab ist es jedoch nicht mehr praktikabel, Authentifizierung und Autorisierung direkt in Ihre Anwendungen zu integrieren. Sicherzustellen, dass jede Anwendung die entsprechenden Zugriffsprotokolle einhält, kann von ihrer Geschäftslogik ablenken oder – schlimmer noch – übersehen werden und zu einer Datenschutzverletzung führen. Der Einsatz von SSO-Technologien kann zwar die Sicherheit erhöhen, indem separate Benutzernamen und Passwörter durch einen einzigen Satz von Anmeldedaten ersetzt werden, doch Entwickler müssen weiterhin Code in ihre Anwendungen integrieren, damit diese mit dem SSO-System kommunizieren können.

Es gibt einen besseren Weg: Lagern Sie die Authentifizierung und Autorisierung an einen Ingress-Controller aus.

Da der Ingress-Controller bereits den gesamten in den Cluster eingehenden Datenverkehr prüft und an die entsprechenden Services weiterleitet, eignet er sich hervorragend für eine zentralisierte Authentifizierung und Autorisierung. Dadurch müssen Entwickler die entsprechende Logik nicht mehr im Anwendungscode implementieren, pflegen und replizieren. Stattdessen können sie SSO-Technologien mithilfe der nativen Kubernetes-API schnell auf der Ingress-Ebene einsetzen.

Weitere Informationen zu diesem Thema finden Sie unter „Implementieren der OpenID-Connect-Authentifizierung für Kubernetes mit Okta und dem NGINX Ingress Controller“.

Anwendungsfall: Self-Service mit Guardrails einrichten

Lösung: Implementieren Sie eine rollenbasierte Zugriffskontrolle (RBAC)

Kubernetes verwendet RBAC, um zu steuern, welche Ressourcen und Vorgänge verschiedenen Benutzertypen zur Verfügung stehen. Dies ist eine wertvolle Sicherheitsmaßnahme, da Administratoren oder Superuser damit festlegen können, wie Benutzer oder Benutzergruppen mit beliebigen Kubernetes-Objekten oder bestimmten Namespaces im Cluster interagieren dürfen.

Kubernetes RBAC ist zwar standardmäßig aktiviert, Sie müssen jedoch sicherstellen, dass auch Ihre Tools für das Kubernetes-Traffic-Management RBAC unterstützen und auf die Sicherheitsanforderungen Ihres Unternehmens abgestimmt werden können. Mit RBAC erhalten Benutzer kontrollierten Zugriff auf die Funktionen, die sie für ihre Arbeit benötigen, ohne auf die Bearbeitung eines Tickets warten zu müssen. Ist RBAC jedoch nicht konfiguriert, können Benutzer Berechtigungen erhalten, die sie nicht benötigen oder zu denen sie nicht berechtigt sind. Werden diese Berechtigungen missbraucht, kann dies zu Sicherheitslücken führen.

Ein Ingress-Controller ist ein hervorragendes Beispiel für ein Tool, das bei entsprechender RBAC-Konfiguration von zahlreichen Personen und Teams genutzt werden kann. Wenn der Ingress-Controller eine fein abgestufte Zugriffsverwaltung ermöglicht – bis hinunter auf einen einzelnen Namespace –, können Sie mithilfe von RBAC durch Mandantenfähigkeit eine effiziente Ressourcennutzung ermöglichen.

Beispielsweise könnten mehrere Teams den Ingress-Controller wie folgt verwenden:

• NetOps-Team – Konfiguriert den externen Einstiegspunkt der Anwendung (z. B. den Hostnamen und die TLS-Zertifikate) und delegiert Richtlinien zur Datenverkehrssteuerung an verschiedene Teams
• DevOps-Team A – Stellt TCP/UDP-Lastverteilung und Routing-Richtlinien bereit
• DevOps-Team B – Konfiguriert Richtlinien zur Ratenbegrenzung, um Dienste vor übermäßig vielen Anfragen zu schützen
• Identitätsteam – Verwaltet Authentifizierungs- und Autorisierungskomponenten und konfiguriert gleichzeitig mTLS-Richtlinien als Teil einer Ende-zu-Ende-Verschlüsselungsstrategie
• DevSecOps-Team – Legt WAF-Richtlinien fest

Wenn Sie erfahren möchten, wie Sie RBAC im NGINX Ingress Controller nutzen können, sehen Sie sich Fortgeschrittene Kubernetes-Bereitstellungen mit dem NGINX Ingress Controller an. Ab 13:50 Uhr erklären unsere Experten, wie Sie RBAC und Ressourcenzuweisung für Sicherheit, Self-Service und Mandantenfähigkeit nutzen können.

Anwendungsfall: Ende-zu-Ende-Verschlüsselung implementieren

Lösung: Verwenden Sie Tools zur Verwaltung des Datenverkehrs

Ende-zu-Ende-Verschlüsselung (E2EE) wird für Organisationen, die sensible oder personenbezogene Daten verarbeiten, zunehmend zur Voraussetzung. Ob Finanzdaten oder Nachrichten in sozialen Medien: Die Erwartungen der Verbraucher an den Datenschutz und Vorschriften wie die DSGVO und HIPAA steigern die Nachfrage nach dieser Art von Schutz. Der erste Schritt zur Umsetzung von E2EE besteht darin, entweder Ihre Backend-Anwendungen so zu konzipieren, dass sie SSL/TLS-Datenverkehr akzeptieren, oder ein Tool einzusetzen, das die SSL/TLS-Verwaltung von Ihren Anwendungen übernimmt (die bevorzugte Option im Hinblick auf die Trennung von Sicherheitsfunktionen, Leistung, Schlüsselverwaltung usw.). Anschließend konfigurieren Sie Ihre Tools zur Datenverkehrsverwaltung entsprechend der Komplexität Ihrer Umgebung.

Häufigstes Szenario: E2EE mit einem Ingress-Controller

Wenn Sie Anwendungen mit nur einem Endpunkt haben (einfache Anwendungen oder monolithische Anwendungen, die Sie per „Lift-and-Shift“ zu Kubernetes migriert haben) oder wenn keine Kommunikation zwischen Diensten stattfindet, können Sie einen Ingress-Controller verwenden, um E2EE innerhalb von Kubernetes zu implementieren.

Schritt 1: Stellen Sie sicher, dass Ihr Ingress-Controller ausschließlich verschlüsselte SSL/TLS-Verbindungen mit serverseitigen Zertifikaten oder mTLS-Zertifikaten zulässt, idealerweise sowohl für eingehenden als auch für ausgehenden Datenverkehr.

Schritt 2: Ändern Sie die übliche Standardeinstellung, nach der der Ingress-Controller den Datenverkehr entschlüsseln und erneut verschlüsseln muss, bevor er ihn an die Anwendungen weiterleitet. Hierfür gibt es mehrere Möglichkeiten. Welche Methode Sie wählen, hängt von Ihrem Ingress-Controller und Ihren Anforderungen ab:

• Wenn Ihr Ingress-Controller SSL/TLS-Passthrough unterstützt, kann er SSL/TLS-verschlüsselte Verbindungen anhand des SNI-Headers (Server Name Indication) weiterleiten, ohne sie zu entschlüsseln oder Zugriff auf die SSL/TLS-Zertifikate oder -Schlüssel zu benötigen.
• Alternativ können Sie eine SSL/TLS-Terminierung einrichten, bei der der Ingress-Controller den Datenverkehr terminiert und ihn anschließend an die Backends oder Upstreams weiterleitet – entweder unverschlüsselt oder indem er den Datenverkehr mit mTLS oder dienstseitigem SSL/TLS für Ihre Kubernetes-Dienste erneut verschlüsselt.

Weniger häufiges Szenario: E2EE mit einem Ingress-Controller und einem Service Mesh

Wenn innerhalb Ihres Clusters eine Service-zu-Service-Kommunikation stattfindet, müssen Sie E2EE auf zwei Ebenen implementieren: für den Ingress-/Egress-Datenverkehr mit dem Ingress-Controller und für den Service-zu-Service-Datenverkehr mit einem Service Mesh. Bei E2EE besteht die Aufgabe eines Service Mesh darin, sicherzustellen, dass nur bestimmte Services miteinander kommunizieren dürfen und dass diese Kommunikation sicher erfolgt. Wenn Sie ein Service Mesh für E2EE einrichten, müssen Sie mithilfe von zwei Faktoren eine Zero-Trust-Umgebung schaffen: mTLS zwischen den Services (wobei ein Zertifikat zwingend erforderlich ist) und eine Zugriffskontrolle für den Datenverkehr zwischen den Services (die festlegt, welche Services miteinander kommunizieren dürfen). Idealerweise implementieren Sie außerdem mTLS zwischen den Anwendungen (verwaltet durch ein Service Mesh und den Ingress-/Egress-Controller), um im gesamten Kubernetes-Cluster echte E2EE-Sicherheit zu gewährleisten.

Weitere Informationen zur Verschlüsselung von Daten, die bei der Übertragung offengelegt wurden, finden Sie unter „Die mTLS-Architektur in NGINX Service Mesh“.

Anwendungsfall: Sicherstellen, dass Clients eine starke Verschlüsselung mit einer vertrauenswürdigen Implementierung verwenden

Lösung: Einhaltung der Federal Information Processing Standards (FIPS)

In der Softwarebranche bezieht sich FIPS üblicherweise auf die speziell der Kryptografie gewidmete Veröffentlichung FIPS PUB 140-2 Sicherheitsanforderungen für kryptografische Module, die gemeinsam von den Vereinigten Staaten und Kanada erarbeitet wurde. Sie standardisiert die Prüfung und Zertifizierung kryptografischer Module, die von den Bundesbehörden beider Länder zum Schutz vertraulicher Informationen anerkannt werden. „Aber Moment mal!“ sagen Sie. „FIPS ist für mich nicht relevant, weil ich nicht mit nordamerikanischen Regierungsbehörden zusammenarbeite.“ Die FIPS-Konformität kann unabhängig von Ihrer Branche oder Ihrem Standort eine kluge Entscheidung sein, da FIPS zugleich der De-facto-Standard für Kryptografie weltweit ist.

Die Einhaltung von FIPS muss nicht schwierig sein, setzt jedoch voraus, dass sowohl Ihr Betriebssystem als auch die relevanten Tools zur Datenverkehrssteuerung im FIPS-Modus betrieben werden können. Häufig wird fälschlicherweise angenommen, dass es für die FIPS-Konformität ausreicht, das Betriebssystem im FIPS-Modus auszuführen. Doch selbst dann ist nicht gewährleistet, dass Clients, die mit Ihrem Ingress-Controller kommunizieren, eine starke Verschlüsselung verwenden. Im FIPS-Modus dürfen Ihr Betriebssystem und Ihr Ingress-Controller möglicherweise nur eine Teilmenge der üblichen SSL/TLS-Verschlüsselungsverfahren verwenden.

Die Einrichtung von FIPS für Ihre Kubernetes-Bereitstellungen erfolgt in vier Schritten:

• Schritt 1: Konfigurieren Sie Ihr Betriebssystem für den FIPS-Modus
• Schritt 2: Überprüfen Sie, ob sich das Betriebssystem und OpenSSL im FIPS-Modus befinden
• Schritt 3: Installieren Sie den Ingress-Controller
• Schritt 4: Überprüfen Sie die Konformität mit FIPS 140-2, indem Sie den FIPS-Status prüfen

Im folgenden Beispiel wird bei aktiviertem FIPS-Modus sowohl für das Betriebssystem als auch für die von NGINX Plus verwendete OpenSSL-Implementierung der gesamte Endbenutzer-Datenverkehr zu und von NGINX Plus mithilfe einer validierten, FIPS-fähigen Kryptografie-Engine entschlüsselt und verschlüsselt.

Weitere Informationen zu FIPS finden Sie unter „FIPS-Konformität mit NGINX Plus erreichen“.

Kubernetes mit NGINX sicherer machen

Wenn Sie bereit sind, einige (oder alle) dieser Sicherheitsmethoden zu implementieren, müssen Sie sicherstellen, dass Ihre Tools über die richtigen Funktionen und Fähigkeiten verfügen, um Ihre Anwendungsfälle zu unterstützen. NGINX bietet Ihnen dafür eine Reihe produktionsreifer Tools für das Kubernetes-Traffic-Management:

• NGINX Ingress Controller – Auf NGINX Plus basierender Ingress-Controller für Kubernetes, der erweiterte Funktionen zur Datenverkehrssteuerung und -formung, Überwachung und Transparenz sowie Authentifizierung und SSO bietet und als API-Gateway fungiert.
• F5 NGINX App Protect – Umfassender Schutz für moderne Anwendungen und APIs, der auf den marktführenden Sicherheitstechnologien von F5 basiert und sich in NGINX Ingress Controller und NGINX Plus integrieren lässt. Nutzen Sie einen modularen Ansatz für mehr Flexibilität bei Bereitstellungsszenarien und eine optimale Ressourcennutzung:
  • NGINX App Protect WAF – Eine leistungsstarke, schlanke WAF, die vor den OWASP Top 10 und weiteren Bedrohungen schützt und PCI-DDS-konform ist.
  • NGINX App Protect DoS – Verhaltensbasierte Erkennung und Abwehr von DoS-Angriffen mit konsistentem und adaptivem Schutz über verschiedene Clouds und Architekturen hinweg.
• F5 NGINX Service Mesh – Leichtgewichtiges, schlüsselfertiges und entwicklerfreundliches Service Mesh mit NGINX Plus als Enterprise-Sidecar.

Fordern Sie zunächst Ihre kostenlose 30-Tage-Testversion von NGINX Ingress Controller mit NGINX App Protect WAF und DoS an und laden Sie die dauerhaft kostenlose NGINX Service Mesh herunter.

Über den Autor

Jenn GileLeiter Produktmarketing, NGINX

Weitere Blogbeiträge von Jenn Gile