Informationen zur gegenseitigen Authentifizierung per „ TLS “ für Anwendungs-Load-Balancer
Die gegenseitige TLS-Authentifizierung ( mTLS ) bietet erhöhte Sicherheit für Ihren IBM Cloud® Application Load Balancer (ALB), indem sie eine zertifikatsbasierte Authentifizierung zwischen Clients und dem Load Balancer sowie zwischen dem Load Balancer und den Backend-Servern ermöglicht.
Was ist „Mutual TLS “?
mTLS ist eine Erweiterung des Standardprotokolls „ TLS “, bei der sich beide Teilnehmer einer Verbindung gegenseitig mithilfe digitaler Zertifikate authentifizieren müssen. Während bei der Standard- TLS-Verbindung lediglich der Server dem Client ein Zertifikat vorlegen muss, müssen bei der mTLS-Verbindung sowohl der Client als auch der Server Zertifikate vorlegen, wodurch ein Mechanismus zur gegenseitigen Authentifizierung entsteht.
Mit der Unterstützung von ALBs durch „ mTLS “ können Sie die zertifikatsbasierte Authentifizierung auf zwei Ebenen implementieren:
- Frontend-Authentifizierung
- Überprüfen Sie die Identität der Clients, indem Sie von diesen verlangen, bei der Verbindung mit dem Load-Balancer-Listener gültige Zertifikate vorzulegen.
- Backend-Authentifizierung
- Authentifizieren Sie den Load Balancer gegenüber den Backend-Servern durch Vorlage eines Client-Zertifikats und überprüfen Sie optional die Zertifikate der Backend-Server.
Wichtige Leistungsmerkmale
Die ALB-Unterstützung ( mTLS ) bietet folgende Funktionen:
- Überprüfung des Client-Zertifikats auf der Empfänger-Seite
- Aktivieren Sie die Client-Authentifizierung am Frontend des Load Balancers, indem Sie ein Zertifikat einer Zertifizierungsstelle (CA) konfigurieren, um Client-Zertifikate zu überprüfen. Die Überprüfung stellt sicher, dass nur Clients mit gültigen Zertifikaten, die von der vertrauenswürdigen Zertifizierungsstelle signiert wurden, Verbindungen herstellen können.
- Unterstützung für Zertifikatssperrlisten (CRL)
- Laden Sie eine CRL hoch, um zu überprüfen, ob Client-Zertifikate widerrufen wurden, und sorgen Sie so für eine zusätzliche Sicherheitsebene, indem kompromittierte oder abgelaufene Zertifikate abgelehnt werden.
- Überprüfung des Backend-Server-Zertifikats
- Überprüfen Sie die Zertifikate der Backend-Server während des „ TLS “-Handshakes, um sicherzustellen, dass der Load Balancer nur eine Verbindung zu vertrauenswürdigen Backend-Servern herstellt. Die Validierung trägt dazu bei, Man-in-the-Middle-Angriffe zu verhindern.
- Client-Authentifizierung auf Backend-Ebene
- Legen Sie den Backend-Servern ein Client-Zertifikat vom Load Balancer vor, wenn die Backend-Infrastruktur „ mTLS “ erfordert, um eine sichere bidirektionale Authentifizierung zu ermöglichen.
Anwendungsfälle
mTLS Die Authentifizierung ist in Situationen von großem Nutzen, in denen Sie erhöhte Sicherheit und eine Identitätsüberprüfung benötigen:
- Zero-Trust-Sicherheitsarchitekturen
- Setzen Sie Zero-Trust-Prinzipien um, indem Sie für alle Verbindungen eine zertifikatsbasierte Authentifizierung vorschreiben und so sicherstellen, dass jeder Client und jeder Server vor dem Aufbau der Kommunikation überprüft wird.
- API-Sicherheit
- Schützen Sie API-Endpunkte, indem Sie von Clients verlangen, gültige Zertifikate vorzulegen. So verhindern Sie unbefugten Zugriff auf sensible APIs und stellen sicher, dass nur authentifizierte Anwendungen Ihre Dienste nutzen können.
- Kommunikation zwischen Microservices
- Sichern Sie die Kommunikation zwischen Microservices durch die Implementierung von „ mTLS “ sowohl im Frontend als auch im Backend, um sicherzustellen, dass die gesamte Kommunikation zwischen den Diensten authentifiziert und verschlüsselt ist.
- Compliance-Anforderungen
- Erfüllen Sie die gesetzlichen Anforderungen, die starke Authentifizierungsmechanismen vorschreiben, beispielsweise in den Bereichen Finanzdienstleistungen, Gesundheitswesen oder im öffentlichen Sektor.
- Validierung auf dem Backend-Server
- Stellen Sie sicher, dass Ihr Load Balancer nur Verbindungen zu legitimen Backend-Servern herstellt, indem Sie deren Zertifikate überprüfen und so Schutz vor betrügerischen oder kompromittierten Backend-Instanzen bieten.
So funktioniert „ mTLS “ mit Anwendungs-Load-Balancern
ALBs unterstützen „ mTLS “ sowohl für Verbindungen vom Client zum Load Balancer als auch für Verbindungen vom Load Balancer zum Server. Die folgenden Abläufe veranschaulichen, wie die Zertifikatsüberprüfung bei jedem „ TLS “-Handshake abläuft.
Front-End- mTLS en (Listener-Ebene)
Wenn Sie die Client-Authentifizierung ( mTLS ) auf Listener-Ebene aktivieren:
- Ein Client baut eine „ HTTPS “-Verbindung zum Load Balancer auf.
- Der Load Balancer legt dem Client sein Serverzertifikat vor.
- Der Load Balancer fordert vom Client ein Client-Zertifikat an.
- Der Client legt dem Load Balancer sein Zertifikat vor.
- Der Load Balancer vergleicht das Client-Zertifikat mit dem konfigurierten CA-Zertifikat.
- Wenn eine CRL konfiguriert ist, prüft der Load Balancer, ob das Zertifikat widerrufen wurde.
- Wenn die Überprüfung erfolgreich ist, wird die Verbindung hergestellt. Andernfalls wird die Verbindung abgelehnt.
Backend- mTLS en (Pool-Ebene)
Wenn Sie die Serverauthentifizierung oder die Vorlage von Client-Zertifikaten auf Pool-Ebene aktivieren:
- Der Load Balancer baut eine Verbindung zu einem Backend-Server auf.
- Der Backend-Server legt dem Load Balancer sein Zertifikat vor.
- Wenn die Serverüberprüfung aktiviert ist, vergleicht der Load Balancer das Zertifikat des Backend-Servers mit dem konfigurierten CA-Zertifikat.
- Wenn der Backend-Server eine Client-Authentifizierung verlangt, legt der Load Balancer sein Client-Zertifikat vor.
- Der Backend-Server überprüft das Client-Zertifikat.
- Wenn die Überprüfung erfolgreich ist, wird die Verbindung hergestellt und der Datenverkehr wird an den Backend-Server weitergeleitet.
Unterstützung für Zertifikatssperrlisten (CRL)
Eine CRL ist eine Liste von Zertifikaten, die von der Zertifizierungsstelle vor ihrem Ablaufdatum widerrufen wurden. Zertifikate können aus verschiedenen Gründen widerrufen werden, darunter:
- Der private Schlüssel ist kompromittiert worden
- Das Zertifikat wurde fehlerhaft ausgestellt
- Die Berechtigungen des Zertifikatsinhabers haben sich geändert
- Das Zertifikat wird nicht mehr benötigt
Wenn Sie eine CRL für Ihren Listener konfigurieren, vergleicht der Load Balancer jedes Client-Zertifikat während des „ TLS “-Handshakes mit der Sperrliste. Wenn ein Zertifikat in der CRL aufgeführt ist, wird die Verbindung abgelehnt, auch wenn das Zertifikat ansonsten gültig und ordnungsgemäß signiert ist.
Die CRL-Unterstützung bietet eine zusätzliche Sicherheitsebene, indem sie sicherstellt, dass kompromittierte oder ungültig gewordene Zertifikate nicht für den Zugriff auf Ihre Dienste verwendet werden können, selbst wenn sie noch nicht abgelaufen sind.
Voraussetzungen
Bevor Sie „ mTLS “ für Ihren ALB konfigurieren, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:
- Sie verfügen über eine ALB mit einem Profil, das „ mTLS “ unterstützt. Überprüfen Sie die Eigenschaft „
mtls_supported“ im Load-Balancer-Profil. - Ihr Listener nutzt das „ HTTPS “-Protokoll. „ mTLS “ steht ausschließlich für „ HTTPS “-Listener zur Verfügung.
- Sie haben gültige Zertifikate im Format „ PEM “, die unter „ Secrets Manager “ gespeichert sind.
- Sie verfügen über die erforderlichen IAM-Berechtigungen, um Load Balancer zu verwalten und auf Zertifikate unter Secrets Manager zuzugreifen.
Zertifikatsanforderungen
Alle für mTLS verwendeten Zertifikate müssen die folgenden Anforderungen erfüllen:
- Zertifikate müssen im Format „ PEM “ vorliegen.
- Zertifikate müssen unter Secrets Manager gespeichert und anhand ihrer CRN referenziert werden.
- CA-Zertifikate, die zur Verifizierung verwendet werden, müssen die vollständige Zertifikatskette (Stamm- und Zwischenzertifikate) enthalten.
- Client-Zertifikate, die vom Load Balancer an die Backend-Server übermittelt werden, müssen den privaten Schlüssel enthalten.
- Zertifikate müssen gültig sein (d. h. nicht abgelaufen) und ordnungsgemäß von einer vertrauenswürdigen Zertifizierungsstelle signiert sein.
Wichtige Überlegungen
Beachten Sie bei der Implementierung bitte die folgenden Punkte mTLS:
- Verantwortung für die Zertifikatsverwaltung
- Sie sind für die Verwaltung aller Zertifikate verantwortlich, einschließlich der Beschaffung, des Hochladens, der Verlängerung und des Widerrufs von Zertifikaten. IBM Cloud verwaltet oder verlängert Zertifikate nicht automatisch.
- Zertifikatsüberprüfung
- Sie müssen sicherstellen, dass die Zertifikate ordnungsgemäß von den vorgesehenen Zertifizierungsstellen signiert sind und dass die Vertrauensbeziehungen korrekt eingerichtet sind. Ungültige oder nicht übereinstimmende Zertifikate führen zu Fehlern beim Handshake von „ TLS “ und zur Nichtverfügbarkeit des Dienstes.
- Überprüfung des Backend-Servers
- Die Überprüfung durch den Backend-Server ist standardmäßig deaktiviert, um die Abwärtskompatibilität zu gewährleisten. Wenn diese Option aktiviert ist, müssen Sie sicherstellen, dass eine gültige Vertrauensbeziehung zwischen dem Load Balancer und den Backend-Servern besteht, indem Sie das entsprechende CA-Zertifikat hochladen.
- Konfiguration auf Pool-Ebene
- Sowohl die Überprüfung durch den Backend-Server als auch die Client-Authentifizierung werden auf Pool-Ebene konfiguriert. Alle Backend-Server innerhalb eines Pools verwenden dieselbe Konfiguration. Wenn Sie für verschiedene Backend-Server unterschiedliche Zertifikatsrichtlinien benötigen, erstellen Sie separate Pools.
- Zertifikatsaktualisierungen
- Damit Aktualisierungen oder Widerrufe von Zertifikaten wirksam werden, muss der Lastenausgleichsdienst möglicherweise neu gestartet werden. Planen Sie Zertifikatsaktualisierungen während Wartungsfenstern, um Betriebsunterbrechungen auf ein Minimum zu beschränken.
- Mehrere Zertifizierungsstellen
- Wenn Backend-Server im selben Pool von verschiedenen Zertifizierungsstellen signiert sind, können Sie eine gebündelte CA-Datei bereitstellen, die alle relevanten Stamm- und Zwischenzertifikate enthält. Alle Backend-Server gelten als vertrauenswürdig, wenn ihre Zertifikatsketten zu einer beliebigen Zertifizierungsstelle im Bundle führen.