Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Gegenseitige Authentifizierung mit TLS In-Application Application Load Balancer
Die gegenseitige TLS Authentifizierung ist eine Variante von Transport Layer Security (TLS). TLSTraditionell wird eine sichere Kommunikation zwischen einem Server und einem Client hergestellt, wobei der Server seinen Clients seine Identität mitteilen muss. Bei Mutual TLS handelt ein Load Balancer während der Verhandlungen die gegenseitige Authentifizierung zwischen dem Client und dem Server aus. TLS Wenn Sie Mutual TLS zusammen mit Application Load Balancer verwenden, vereinfachen Sie das Authentifizierungsmanagement und reduzieren die Belastung Ihrer Anwendungen.
Durch die Verwendung von Mutual TLS mit Application Load Balancer kann Ihr Load Balancer die Client-Authentifizierung verwalten und so sicherstellen, dass nur vertrauenswürdige Clients mit Ihren Backend-Anwendungen kommunizieren. Wenn Sie diese Funktion verwenden, authentifiziert Application Load Balancer Clients mit Zertifikaten von einer Zertifizierungsstelle (CA) eines Drittanbieters oder mithilfe von AWS Private Certificate Authority (PCA), optional, mit Sperrprüfungen. Application Load Balancer leitet Client-Zertifikatsinformationen an das Backend weiter, die Ihre Anwendungen für die Autorisierung verwenden können. Durch die Verwendung von Mutual TLS in Application Load Balancer erhalten Sie eine integrierte, skalierbare, verwaltete Authentifizierung für zertifikatsbasierte Entitäten, die etablierte Bibliotheken verwendet.
Mutual TLS for Application Load Balancers bietet die folgenden zwei Optionen für die Validierung Ihrer X.509v3-Client-Zertifikate:
Hinweis: X.509v1-Client-Zertifikate werden nicht unterstützt.
Gegenseitiges TLS Passthrough: Wenn Sie den Mutual TLS Passthrough-Modus verwenden, sendet Application Load Balancer die gesamte Client-Zertifikatskette mithilfe von Headern an das Ziel. HTTP Mithilfe der Client-Zertifikatskette können Sie dann die entsprechende Load Balancer-Authentifizierung und Zielautorisierungslogik in Ihrer Anwendung implementieren.
Gegenseitige TLS Überprüfung: Wenn Sie den Modus für die gegenseitige TLS Überprüfung verwenden, führt Application Load Balancer die X.509-Client-Zertifikatsauthentifizierung für Clients durch, wenn ein Load Balancer Verbindungen aushandelt. TLS
Um mit Mutual TLS in Application Load Balancer unter Verwendung von Passthrough zu beginnen, müssen Sie den Listener nur so konfigurieren, dass er Zertifikate von Clients akzeptiert. Um Mutual TLS mit Verifizierung zu verwenden, müssen Sie wie folgt vorgehen:
Erstellen Sie eine neue Trust Store-Ressource.
Laden Sie Ihr Zertifizierungsstellenpaket (CA) und optional Sperrlisten hoch.
Hängen Sie den Trust Store an den Listener an, der für die Überprüfung von Client-Zertifikaten konfiguriert ist.
step-by-stepVerfahren zur Konfiguration des Modus für die gegenseitige TLS Überprüfung mit Ihrem Application Load Balancer finden Sie unterKonfiguration von Mutual TLS auf einem Application Load Balancer.
Bevor Sie mit der Konfiguration von Mutual TLS auf Ihrem Application Load Balancer beginnen
Bevor Sie mit der Konfiguration von Mutual TLS auf Ihrem Application Load Balancer beginnen, sollten Sie Folgendes beachten:
- Kontingente
Application Load Balancers enthalten bestimmte Beschränkungen, die sich auf die Anzahl der in Ihrem AWS Konto verwendeten Trust Stores, CA-Zertifikate und Zertifikatssperrlisten beziehen.
Weitere Informationen finden Sie unter Kontingente für Ihre Application Load Balancers.
- Anforderungen für Zertifikate
Application Load Balancers unterstützen Folgendes für Zertifikate, die mit gegenseitiger TLS Authentifizierung verwendet werden:
Unterstütztes Zertifikat: X.509v3
Unterstützte öffentliche Schlüssel: RSA 2K — 8K oder ECDSA secp256r1, secp384r1, secp521r1
Unterstützte Signaturalgorithmen:, 384, 512 mit/SHA256, 384, 512 mit EC/ ,384,512 Hash mit - mit RSA SHA256 SHA256 RSASSA PSS MGF1
- CA-Zertifikatspakete
Folgendes gilt für Zertifizierungsstellen-Pakete (CA):
Application Load Balancers laden jedes Zertifikatspaket der Zertifizierungsstelle (CA) als Batch hoch. Application Load Balancers unterstützen das Hochladen einzelner Zertifikate nicht. Wenn Sie neue Zertifikate hinzufügen müssen, müssen Sie die Zertifikatspaketdatei hochladen.
Um ein CA-Zertifikatspaket zu ersetzen, verwenden Sie den ModifyTrustStoreAPI.
- Reihenfolge der Zertifikate für Passthrough
Wenn Sie Mutual TLS Passthrough verwenden, fügt der Application Load Balancer Header ein, um den Backend-Zielen die Zertifikatskette des Clients zu präsentieren. Die Reihenfolge der Präsentation beginnt mit den Blattzertifikaten und endet mit dem Stammzertifikat.
- Wiederaufnahme der Sitzung
Die Wiederaufnahme der Sitzung wird nicht unterstützt, wenn der Modus „Mutual TLS Passthrough“ oder „Verify“ mit einem Application Load Balancer verwendet wird.
- HTTPKopfzeilen
Application Load Balancers verwenden
X-Amzn-MtlsHeader, um Zertifikatsinformationen zu senden, wenn sie Clientverbindungen auf Gegenseitigkeit aushandeln. TLS Weitere Informationen und Beispiel-Header finden Sie unter. HTTPHeader und gemeinsame TLS- CA-Zertifikatsdateien
CA-Zertifikatsdateien müssen die folgenden Anforderungen erfüllen:
Die Zertifikatsdatei muss das Format PEM (Privacy Enhanced Mail) verwenden.
Der Inhalt des Zertifikats muss innerhalb der
-----END CERTIFICATE-----Grenzen-----BEGIN CERTIFICATE-----und liegen.Den Kommentaren muss ein
#Zeichen vorangestellt werden und sie dürfen keine-Zeichen enthalten.Es dürfen keine Leerzeilen vorhanden sein.
Beispielzertifikat, das nicht akzeptiert wird (ungültig):
# comments Certificate: Data: Version: 3 (0x2) Serial Number: 01 Signature Algorithm: ecdsa-with-SHA384 Issuer: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE Validity Not Before: Jan 11 23:57:57 2024 GMT Not After : Jan 10 00:57:57 2029 GMT Subject: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 00:01:02:03:04:05:06:07:08 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 00:01:02:03:04:05:06:07:08 X509v3 Subject Alternative Name: URI:EXAMPLE.COM Signature Algorithm: ecdsa-with-SHA384 00:01:02:03:04:05:06:07:08 -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE-----Beispielzertifikate, die akzeptiert werden (gültig):
-
Einzelzertifikat (PEM—codiert):
# comments -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE----- -
Mehrere Zertifikate (PEM—codiert):
# comments -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE----- # comments -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Base64–encoded certificate -----END CERTIFICATE-----
HTTPHeader und gemeinsame TLS
In diesem Abschnitt werden die HTTP Header beschrieben, die Application Load Balancers verwenden, um Zertifikatsinformationen zu senden, wenn Verbindungen mit Clients über Gegenseitigkeit ausgehandelt werden. TLS Die spezifischen X-Amzn-Mtls Header, die der Application Load Balancer verwendet, hängen vom angegebenen gegenseitigen TLS Modus ab: Passthrough-Modus oder Überprüfungsmodus.
Hinweise zu anderen HTTP Headern, die von Application Load Balancers unterstützt werden, finden Sie unter. HTTPHeader und Application Load Balancer
HTTPHeader für den Passthrough-Modus
Für den Modus Mutual TLS im Passthrough-Modus verwenden Application Load Balancer den folgenden Header.
Dieser Header enthält das URL -kodierte PEM Format der gesamten Client-Zertifikatskette, die in der Verbindung dargestellt wird, mit sicheren Zeichen. +=/
Beispiel für den Inhalt einer Kopfzeile:
X-Amzn-Mtls-Clientcert: -----BEGIN%20CERTIFICATE-----%0AMIID<...reduced...>do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICATE-----%0AMIID1<...reduced...>3eZlyKA%3D%3D%0A-----END%20CERTIFICATE-----%0AHTTPHeader für den Überprüfungsmodus
TLSIm Modus „Gegenseitige Überprüfung“ verwenden Application Load Balancers die folgenden Header.
Dieser Header enthält eine hexadezimale Darstellung der Seriennummer des Leaf-Zertifikats.
Beispiel für den Inhalt der Kopfzeile:
X-Amzn-Mtls-Clientcert-Serial-Number: 03A5B1Dieser Header enthält eine RFC2253 Zeichenkettendarstellung des definierten Namens (DN) des Emittenten.
Beispiel für den Inhalt der Kopfzeile:
X-Amzn-Mtls-Clientcert-Issuer: CN=rootcamtls.com,OU=rootCA,O=mTLS,L=Seattle,ST=Washington,C=USDieser Header enthält eine RFC2253 Zeichenkettendarstellung des definierten Namens (DN) des Betreffs.
Beispiel für den Inhalt einer Kopfzeile:
X-Amzn-Mtls-Clientcert-Subject: CN=client_.com,OU=client-3,O=mTLS,ST=Washington,C=USDieser Header enthält das Und-Datum im Format 01. ISO86 notBefore notAfter
Beispiel für den Inhalt einer Kopfzeile:
X-Amzn-Mtls-Clientcert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17ZDieser Header enthält ein URL -codiertes Format des Leaf-Zertifikats mit sicheren ZeichenPEM. +=/
Beispiel für den Inhalt einer Kopfzeile:
X-Amzn-Mtls-Clientcert-Leaf: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0AVerbindungsprotokolle für Application Load Balancer
Elastic Load Balancing stellt Verbindungsprotokolle bereit, die Attribute der Anfragen erfassen, die an Ihre Application Load Balancer gesendet wurden. Verbindungsprotokolle enthalten Informationen wie die Client-IP-Adresse und den Port, Informationen zum Client-Zertifikat, die Verbindungsergebnisse und die verwendeten TLS Chiffren. Diese Verbindungsprotokolle können dann verwendet werden, um Anforderungsmuster und andere Trends zu überprüfen.
Weitere Informationen zu Verbindungsprotokollen finden Sie unter Verbindungsprotokolle für Ihren Application Load Balancer
