Gewährleistung der Datensicherheit

Mendix für Private Cloud gewährleistet Datensicherheit durch die Implementierung von TLS auf mehrere Arten:

• „Ingress-TLS“ – wird verwendet, um den Datenverkehr zwischen einem Webbrowser (oder einem anderen HTTP-Client) und dem Mendix Laufzeit.
• „Client-TLS“ – Client-Zertifikate (wie Sie sie in der Runtime konfigurieren können) werden vom Remote-Server verwendet, um die Identität des Mendix Laufzeit. Gleichzeitig wird die Mendix Runtime verwendet das vom Remote-Server vorgelegte Zertifikat, um seine Identität zu validieren.
• „TLS-Vertrauen“ – wird verwendet, um einer privaten Stammzertifizierungsstelle beim Herstellen einer Verbindung zu einer Datenbank, einem Dateispeicher oder einem Register zu vertrauen. Die vertrauenswürdigen Stammzertifikate validieren die Authentizität des Remote-Servers und werden auch beim Herstellen einer Verbindung zu anderen externen Diensten verwendet (z. B. alle REST- oder SOAP-Dienste, die innerhalb eines Mendix app).

Wofür brauchen wir also Service Mesh? Und was ist es eigentlich? Beginnen wir damit, die Grundlagen sicherer Kommunikation zu verstehen.

Was ist TLS?

TLS (Transport Layer Security) ist ein kryptografisches Protokoll, das durch Verschlüsselung von Daten, Überprüfung von Identitäten und Wahrung der Datenintegrität eine sichere Kommunikation zwischen zwei Geräten über ein potenziell nicht vertrauenswürdiges Netzwerk gewährleistet.

Die Hauptkomponenten sind:

• Zwei Schlüssel, öffentliche und private Schlüssel genannt.
• Beide Schlüssel haben eine festgelegte Ablauffrist.
• Mit dem öffentlichen Schlüssel verschlüsselte Daten können nur mit dem privaten Schlüssel entschlüsselt werden.
• Mit dem privaten Schlüssel verschlüsselte Daten können nur mit seinem öffentlichen Schlüssel entschlüsselt werden.

Wie funktioniert TLS?

Kurz gesagt, der Server verfügt über ein TLS-Zertifikat und auch über das Schlüsselpaar. Der Prozess läuft dann folgendermaßen ab:

1. Der Client stellt eine Verbindung zum Server her.
2. Der Server sendet sein TLS-Zertifikat.
3. Der Client überprüft das Zertifikat des Servers (TLS-Handshake).
4. Client und Server tauschen Informationen über eine verschlüsselte TLS-Verbindung aus.

Der Schlüssel besteht hier darin, zu verstehen, dass bei TLS nur der Client die Serveridentität überprüft.

Ok, was ist also mTLS?

Mutual Transport Level Security (mTLS) basiert auf TLS. Der Prozess ist sehr ähnlich, allerdings bringt der Client zusätzlich sein eigenes Zertifikat und Schlüsselpaar mit. Mit anderen Worten: Client und Server verifizieren gegenseitig ihre Identität.

So funktioniert mTLS:

1. Der Client stellt eine Verbindung zum Server her.
2. Der Server sendet sein TLS-Zertifikat.
3. Der Client überprüft das Zertifikat des Servers (TLS-Handshake).
4. Der Client sendet sein TLS-Zertifikat.
5. Der Server überprüft das Zertifikat des Clients (erneut TLS-Handshake).
6. Anschließend wird die Verbindung über einen gesicherten Kanal hergestellt.

Was sind also Service Meshes?

Ein Service Mesh ist eine Netzwerkinfrastruktur, die innerhalb einer Microservices-Architektur betrieben wird. Ihr Hauptziel besteht darin, die Sicherheit zu verbessern und die Verschlüsselung von Daten zu verwalten, während diese zwischen diesen Diensten übertragen werden.

In diesem Beitrag werde ich mich nur auf drei der vielen Funktionen konzentrieren, die ein Service Mesh bieten kann:

• Service-to-Service-Verschlüsselung: Ein Service Mesh verwendet TLS und mTLS, um diese Kommunikation zwischen den Diensten zu verschlüsseln und zu authentifizieren.
• Zertifikatsverwaltung: Ein Service Mesh vereinfacht die Verwaltung von TLS-Zertifikaten durch Automatisierung der Zertifikatsausstellung, -rotation und -verteilung.
• Zero-Trust-Netzwerke: Service Meshes verfolgen häufig einen „Zero Trust“-Ansatz, was bedeutet, dass die Kommunikation zwischen Diensten standardmäßig nicht vertrauenswürdig ist. TLS und mTLS spielen bei diesem Ansatz eine entscheidende Rolle, da sie die Identität der kommunizierenden Parteien überprüfen und die Daten verschlüsseln, selbst innerhalb vertrauenswürdiger Netzwerke.

Service Mesh in Mendix für Private Cloud

Für diese Demonstration wurde der offizielles Terraform-Bereitstellungsmodul für AWS EKS wurde zur Bereitstellung des Kubernetes-Clusters verwendet. Die konfigurierte Infrastruktur bietet daher von Anfang an die folgenden Hauptfunktionen:

• A Mendix Operator und Agent sind in einem Namespace namens „mendix“ konfiguriert.
• Eine sichere Verbindung (TLS) zwischen Mendix Anwendungen und wichtige Komponenten wie Datenbank, Speicher und Registrierung.
• Eine sichere Verbindung zwischen dem Load Balancer und dem Mendix Arbeitslasten.

Das Ziel besteht hier darin, ein Service Mesh zu ermöglichen, das Zero Trust Networking gewährleistet: Alle Pods kommunizieren auf sichere Weise mit gegenseitigem TLS mit allen internen Kubernetes-Diensten.

Sonst noch etwas? Ja, wir werden auch den Ingress-Controller in das „Mesh“ einbinden, um den gesamten externen Datenverkehr zu sichern, der an die Pods weitergeleitet wird.

Klingt aufregend?

Vielleicht verwirrend?

Vielleicht helfen ein paar Diagramme:

Hier stehen wir jetzt …

Beachten Sie das Mendix Agent und Entwicklerportal sind nur im Connected Mode anwendbar

…und das ist unser gewünschter Endzustand:

Ab Version 2.5 Mendix Operator ist mit Istio und Linkerd kompatibel, sowohl für Connected- als auch für Standalone-Angebote.

Der Einfachheit halber werde ich nur Linkerd untersuchen und aktivieren, aber der Prozess für Istio ist sehr ähnlich.

Linkerd installieren

Befolgen Sie die offizielle Dokumentation installieren:

• Linkerd CLI, abhängig von Ihrem Betriebssystem.
• Linkerd-CRDs
• Linkerd-Erweiterungen (Viz und Dashboard werden beide dringend empfohlen)

Mendix für die Mesh-Injektion in der Private Cloud

Ein ziemlich cooles Feature in Mendix für Private Cloud besteht darin, dass die Mesh-„Injektion“ entweder pro Umgebung (ideal für einen schnellen Validierungstest oder eine Isolierung) oder für den gesamten Namespace aktiviert werden kann.

Im Bild unten finden Sie eine Kurzanleitung zum Aktivieren von Linkerd. Weitere Informationen finden Sie in der offiziellen Dokumentation für vernetzt , Standalone für weitere Informationen an.

Aktivieren von Linkerd für eine Umgebung

Zunächst wird die Linkerd-Annotation direkt vom Entwicklerportal für eine Anwendung namens terrapp1 aktiviert.

Wie Sie sehen, wird nach der Aktivierung und Anwendung der Änderungen das Mendix Der Pod wird neu gestartet und das Linkerd-Dashboard erkennt die Anmerkung und markiert den Pod als vermascht:

Großartig, unsere erste App wurde jetzt erfolgreich zu Linkerd hinzugefügt und mTLS ist bereits im Einsatz.

Aktivieren von Linkerd für den gesamten Namespace

Kommen wir zum nächsten Schritt, dem Hinzufügen des gesamten Mendix Namespace zum Mesh, wodurch die Verbindung zwischen Operator, Agent und Anwendung gesichert wird!

Wie im folgenden Video gezeigt, müssen wir:

1. Kommentieren Sie den gesamten Namespace (genannt „mendix“) für die Linkerd-Injektion
2. Bestätigen Sie, dass die Annotation zum Namespace hinzugefügt wurde, indem Sie sich die Konfiguration ansehen.

Hinweis: Wenn Pods nicht automatisch zum Mesh hinzugefügt werden, empfiehlt es sich, jede Bereitstellung herunter- und hochskalieren:

• • Kubectl-Skalierungsbereitstellung mendix-operator – Replikate = 0
  • Kubectl-Skalierungsbereitstellung mendix-agent – ​​Replikate = 0
  • Wiederholen Sie den obigen Vorgang und fügen Sie replicas=1 hinzu

Juhuu! Jetzt kommen wir dem Ziel des Zero-Trust-Networkings näher. Lassen Sie uns eine neue Anwendung aus dem Entwicklerportal bereitstellen und sehen, wie sie automatisch zum Mesh hinzugefügt wird!

Hinzufügen von NGINX-Ingress zum Mesh

In den meisten Kundenkonfigurationen TLS-Terminierung wird im Ingress-Controller konfiguriert, der sich im Kubernetes-Cluster befindet. Einfach ausgedrückt bedeutet dies, dass externer eingehender Datenverkehr verschlüsselt (TLS) beim Ingress-Dienst ankommt und unverschlüsselt (einfaches HTTP) an den Pod übermittelt wird.

Unser letzter Schritt besteht darin, mTLS auch zwischen dem Ingress-Controller und allen Diensten innerhalb des Mendix Namespace. Dazu müssen wir:

• Fügen Sie die Bereitstellung des NGINX-Ingress-Controllers zum Mesh hinzu. Folge den Anweisungen abhängig davon, wie Sie NGINX in Ihrem Cluster installiert haben (Helm oder von YAML).
• Stellen Sie sicher, dass Sie hinzufügen thenginx.ingress.kubernetes.io/service-upstream Annotation ordnungsgemäß, um sicherzustellen, dass der Controller nicht die Pod-Endpunkte verwendet, sondern stattdessen die Cluster-IP und den Port des Dienstes nutzt.

Jetzt ist es Zeit zu bestätigen, dass der gesamte Datenverkehr zu den Pods mTLS verwendet, sobald Nginx zum Mesh hinzugefügt wurde:

NGINX ist vernetzt und sendet den Datenverkehr sicher an Mendix Anwendung

Fazit

Die Bedeutung einer robusten Service-Mesh-Architektur kann nicht genug betont werden und ihre Fähigkeit, detaillierte Transparenz, sichere Kommunikation und Richtliniendurchsetzung innerhalb einer Microservices-Umgebung bereitzustellen, ist für die Sicherung von Daten und Systemen von größter Bedeutung.

Nutzung Mendix Durch die nahtlose Integration von Private Cloud mit Istio und Linkerd können Unternehmen eine harmonische Mischung aus Agilität und Sicherheit erreichen. MendixDie schnellen Entwicklungsfunktionen von ergänzen die strengen Sicherheitsmaßnahmen eines Service Mesh und ermöglichen Unternehmen Innovationen, ohne ihre Verteidigungsposition zu gefährden.

In dieser Zeit sich ständig weiterentwickelnder Bedrohungen ist die Fusion von Service Mesh und Mendix für Private Cloud ist ein Beispiel für einen zukunftsweisenden Ansatz zur Informationssicherheit.

Viel Spaß beim Meshing!