Gegenseitige TLS-Authentifizierung

Die gegenseitige TLS-Authentifizierung (Transport Layer Security) ist eine optionale Komponente von TLS, die eine bidirektionale Peer-Authentifizierung bietet. Die gegenseitige TLS-Authentifizierung bietet eine zusätzliche Sicherheitsebene gegenüber TLS und ermöglicht es Ihren Diensten, den Client zu verifizieren, der die Verbindung herstellt.

Der Client in der Client-Server-Beziehung stellt während der Sitzungsaushandlung auch ein X.509-Zertifikat bereit. Der Server verwendet dieses Zertifikat, um den Client zu identifizieren und zu authentifizieren. Dieser Prozess hilft zu überprüfen, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) ausgestellt wurde und ob es sich bei dem Zertifikat um ein gültiges Zertifikat handelt. Außerdem wird der auf dem Zertifikat angegebene Subject Alternative Name (SAN) verwendet, um den Client zu identifizieren.

Sie können die gegenseitige TLS-Authentifizierung für alle Protokolle aktivieren, die von unterstützt werden AWS App Mesh. Sie sind TCP, HTTP/1.1, HTTP/2, gRPC.

Anmerkung

Mit App Mesh können Sie die gegenseitige TLS-Authentifizierung für die Kommunikation zwischen Envoy-Proxys von Ihren Diensten aus konfigurieren. Die Kommunikation zwischen Ihren Anwendungen und Envoy-Proxys ist jedoch unverschlüsselt.

Gegenseitige TLS-Authentifizierungszertifikate

AWS App Mesh unterstützt zwei mögliche Zertifikatsquellen für die gegenseitige TLS-Authentifizierung. Clientzertifikate in einer TLS-Client-Richtlinie und die Servervalidierung in einer Listener-TLS-Konfiguration können bezogen werden von:

• Dateisystem — Zertifikate aus dem lokalen Dateisystem des Envoy-Proxys, der gerade ausgeführt wird. Um Zertifikate an Envoy zu verteilen, müssen Sie Dateipfade für die Zertifikatskette und den privaten Schlüssel für die App Mesh Mesh-API angeben.

• Der Secret Discovery Service (SDS) von Envoy — ring-your-own B-Sidecars, die SDS implementieren und das Senden von Zertifikaten an Envoy ermöglichen. Dazu gehört das SPIFFE Runtime Environment (SPIRE).

Wichtig

App Mesh speichert keine Zertifikate oder privaten Schlüssel, die für die gegenseitige TLS-Authentifizierung verwendet werden. Stattdessen speichert Envoy sie im Speicher.

Mesh-Endpunkte konfigurieren

Konfigurieren Sie die gegenseitige TLS-Authentifizierung für Ihre Mesh-Endpunkte, z. B. virtuelle Knoten oder Gateways. Diese Endpunkte stellen Zertifikate bereit und spezifizieren vertrauenswürdige Behörden.

Dazu müssen Sie X.509-Zertifikate sowohl für den Client als auch für den Server bereitstellen und im Validierungskontext sowohl für die TLS-Terminierung als auch für den TLS-Ursprung explizit Zertifikate für vertrauenswürdige Stellen definieren.

Vertrauen innerhalb eines Netzes

Serverseitige Zertifikate werden in Virtual Node-Listenern (TLS-Terminierung) konfiguriert, und clientseitige Zertifikate werden in Virtual Nodes Service-Backends (TLS-Origination) konfiguriert. Als Alternative zu dieser Konfiguration können Sie eine Standard-Client-Richtlinie für alle Dienst-Back-Ends eines virtuellen Knotens definieren und diese Richtlinie dann bei Bedarf für bestimmte Backends überschreiben. Virtuelle Gateways können nur mit einer Standard-Client-Richtlinie konfiguriert werden, die für alle Back-Ends gilt.

Sie können das Vertrauen zwischen verschiedenen Meshes konfigurieren, indem Sie die gegenseitige TLS-Authentifizierung für eingehenden Datenverkehr auf den virtuellen Gateways für beide Meshes aktivieren.

Vertrauen außerhalb eines Meshs

Geben Sie serverseitige Zertifikate im Virtual Gateway-Listener für die TLS-Terminierung an. Konfigurieren Sie den externen Dienst, der mit Ihrem Virtual Gateway kommuniziert, so, dass er clientseitige Zertifikate vorlegt. Die Zertifikate sollten von einer der gleichen Zertifizierungsstellen (CAs) abgeleitet werden, die die serverseitigen Zertifikate auf dem Virtual Gateway-Listener für die TLS-Erstellung verwenden.

Migrieren Sie Dienste zur gegenseitigen TLS-Authentifizierung

Folgen Sie diesen Richtlinien, um die Konnektivität aufrechtzuerhalten, wenn Sie Ihre bestehenden Dienste in App Mesh auf gegenseitige TLS-Authentifizierung migrieren.

Migration von Diensten, die über Klartext kommunizieren

1. Aktivieren Sie den PERMISSIVE Modus für die TLS-Konfiguration auf dem Serverendpunkt. In diesem Modus kann Klartext-Verkehr eine Verbindung zum Endpunkt herstellen.

2. Konfigurieren Sie die gegenseitige TLS-Authentifizierung auf Ihrem Server und geben Sie das Serverzertifikat, die Vertrauenskette und optional die vertrauenswürdigen SANs an.

3. Stellen Sie sicher, dass die Kommunikation über eine TLS-Verbindung erfolgt.

4. Konfigurieren Sie die gegenseitige TLS-Authentifizierung auf Ihren Clients und geben Sie das Client-Zertifikat, die Vertrauenskette und optional die vertrauenswürdigen SANs an.

5. Aktivieren Sie den STRICT Modus für die TLS-Konfiguration auf dem Server.

Dienste, die über TLS kommunizieren, werden migriert

1. Konfigurieren Sie die gegenseitigen TLS-Einstellungen auf Ihren Clients und geben Sie das Client-Zertifikat und optional die vertrauenswürdigen SANs an. Das Client-Zertifikat wird erst an das Back-End gesendet, nachdem der Backend-Server es angefordert hat.

2. Konfigurieren Sie die gegenseitigen TLS-Einstellungen auf Ihrem Server und geben Sie dabei die Vertrauenskette und optional die vertrauenswürdigen SANs an. Dazu fordert Ihr Server ein Client-Zertifikat an.

Überprüfung der gegenseitigen TLS-Authentifizierung

In der Dokumentation Transport Layer Security: Verify encryption können Sie nachlesen, wie genau Envoy TLS-bezogene Statistiken ausgibt. Für die gegenseitige TLS-Authentifizierung sollten Sie sich die folgenden Statistiken ansehen:

• ssl.handshake

• ssl.no_certificate

• ssl.fail_verify_no_cert

• ssl.fail_verify_san

Die beiden folgenden Statistikbeispiele zeigen zusammen, dass erfolgreiche TLS-Verbindungen, die mit dem virtuellen Knoten enden, alle von einem Client stammen, der ein Zertifikat bereitgestellt hat.

listener.0.0.0.0_15000.ssl.handshake: 3

listener.0.0.0.0_15000.ssl.no_certificate: 0

Das nächste Beispiel einer Statistik zeigt, dass die Verbindungen von einem virtuellen Clientknoten (oder Gateway) zu einem virtuellen Backend-Knoten fehlgeschlagen sind. Der alternative Subject Name (SAN), der im Serverzertifikat angegeben ist, stimmt mit keinem der SANs überein, denen der Client vertraut.

cluster.cds_egress_my-mesh_my-backend-node_http_9080.ssl.fail_verify_san: 5

Exemplarische Vorgehensweisen zur gegenseitigen TLS-Authentifizierung von App Mesh

• Exemplarische Vorgehensweise zur gegenseitigen TLS-Authentifizierung: In dieser exemplarischen Vorgehensweise wird beschrieben, wie Sie mit der App Mesh-CLI eine Farb-App mit gegenseitiger TLS-Authentifizierung erstellen können.

• Amazon EKS Mutual TLS SDS-basierte Komplettlösung: Diese exemplarische Vorgehensweise zeigt, wie Sie die gegenseitige TLS-SDS-basierte Authentifizierung mit Amazon EKS und SPIFFE Runtime Environment (SPIRE) verwenden können.

• Dateibasierte Vorgehensweise für Amazon EKS Mutual TLS: Diese exemplarische Vorgehensweise zeigt, wie Sie die gegenseitige dateibasierte TLS-Authentifizierung mit Amazon EKS und SPIFFE Runtime Environment (SPIRE) verwenden können.