TLS/SSL

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X info

Transport Layer Security (TLS), dessen Vorgänger Secure Sockets Layer (SSL) ist, ist die Standardsicherheitstechnologie zum Einrichten einer verschlüsselten Verbindung zwischen einem Webserver und einem Webclient, z. B. einem Browser oder einer App. Eine verschlüsselte Verbindung sorgt dafür, dass alle Daten, die zwischen dem Server und dem Client übertragen werden, vertraulich bleiben. Um TLS zu verwenden, sendet ein Client eine sichere Anfrage an den Server über das verschlüsselte HTTPS-Protokoll anstelle des unverschlüsselten HTTP-Protokolls.

Edge unterstützt unidirektionale und bidirektionale TLS sowohl in einer Cloud- als auch in einer On-Premise-Bereitstellung. Informationen zu den unterstützten TLS-Versionen finden Sie unter Unterstützte Software und unterstützte Versionen. Bei unidirektionalem TLS kann der TLS-Client die Identität des TLS-Servers überprüfen. Beispielsweise kann eine App, die auf einem Android-Smartphone (Client) ausgeführt wird, die Identität von Edge-APIs (Server) bestätigen.

Apigee unterstützt auch eine stärkere Form der Authentifizierung mit bidirektionaler oder Client-TLS. Normalerweise implementieren Sie Zwei-Wege-TLS, um die End-to-End-Sicherheit zu erhöhen und Ihre Daten vor Clientangriffen wie Client-Spoofing oder Man-in-the-Middle-Angriffen zu schützen. Bei der bidirektionalen TLS-Authentifizierung überprüft der Client die Identität des Servers und der Server die Identität des Clients.

TLS-Terminologie

Bevor Sie TLS konfigurieren, sollten Sie sich mit den folgenden wichtigen Begriffen und Konzepten vertraut machen:

Begriff	Definition
CA	Zertifizierungsstelle Eine vertrauenswürdige Stelle wie Symantec oder VeriSign, die Zertifikate ausstellt und die Authentizität eines Zertifikats validiert. Für eine Art von Zertifikat, das als selbst signiertes Zertifikat bezeichnet wird, ist keine Zertifizierungsstelle erforderlich.
Zertifikatskette	Häufig haben Sie kein Zertifikat, das mit dem privaten Stamm-CA-Schlüssel Ihrer Zertifizierungsstelle signiert wurde. Stattdessen haben Sie Ihr Zertifikat zusammen mit einem oder mehreren Zwischenzertifikaten, die eine Kette bilden. Das letzte Zwischenzertifikat in der Kette wird in der Regel mit dem privaten Stamm-CA-Schlüssel signiert.
CSR	Zertifikatsignierungsanfrage Ein CSR ist eine Datei, die auf dem TLS-Server auf Grundlage des privaten Schlüssels generiert wird. Der CSR enthält den öffentlichen Schlüssel und andere Informationen wie den Namen, den Standort und den Domainnamen der Organisation. Die Zertifizierungsstelle signiert die CSR, um ein TLS-Zertifikat zu erstellen. Normalerweise generieren Sie einen CSR, wenn Sie ein abgelaufenes Zertifikat verlängern möchten.
DER	Distinguished Encoding Rules Das DER-Format ist eine binäre Form eines Zertifikats anstelle des ASCII-PEM-Formats. Manchmal hat sie die Dateiendung „.der“, oft aber auch „.cer“. Der einzige Weg, um zwischen einer DER-Datei (.cer) und einer PEM-Datei (.cer) zu unterscheiden, besteht darin, die Datei in einem Texteditor zu öffnen und nach den Anweisungen BEGIN und END zu suchen. Alle Arten von Zertifikaten und privaten Schlüsseln können im DER-Format codiert werden. DER wird in der Regel mit Java-Plattformen verwendet.
Schlüsselalias	Ein Schlüsselalias identifiziert einen Schlüsselspeichereintrag (TLS-Zertifikat und zugehöriger privater Schlüssel) im Schlüsselspeicher eindeutig. In Apigee Edge wird KeyAlias als alias bezeichnet, wenn Sie das Zertifikat/den Schlüssel über die Benutzeroberfläche oder die API in die Keystores hochladen.
Schlüsselspeicher	Ein Schlüsselspeicher ist ein Repository, das ein oder mehrere TLS-Zertifikate und einen entsprechenden privaten Schlüssel enthält, mit dem die Entität während eines TLS-Handshakes zwischen einem Client und einem Server identifiziert wird. Bei der Northbound-Verbindung fungiert der Router als Server und sein Zertifikat wird im Keystore in Apigee Edge gespeichert. Bei der Southbound-Verbindung fungiert der Message Processor als Client und der Backend-Server als Server. Das Clientzertifikat und der zugehörige private Schlüssel werden im Schlüsselspeicher in Apigee Edge gespeichert.
P7B	Das PKCS #7- oder P7B-Format wird normalerweise im Base64-ASCII-Format gespeichert und hat die Dateiendung .p7b oder .p7c. P7B-Zertifikate enthalten -----BEGIN PKCS7------ und -----END PKCS7------Anweisungen. Eine P7B-Datei enthält nur Zertifikate und Kettenzertifikate, nicht den privaten Schlüssel.
PEM	Das PEM-Format (Privacy Enhanced Mail) ist ein textbasiertes ASCII-Format, das eine Base64-Codierung des binären DER-Formats (Distinguished Encoding Rules) ist. PEM-Zertifikate können in einem beliebigen Texteditor geöffnet werden. Der tatsächliche Zertifikatsinhalt wird durch die Anweisungen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- begrenzt. Es entspricht dem X.509-Format zum Speichern eines Zertifikats, einer Zertifikatskette oder eines privaten Schlüssels. Wenn Ihr Zertifikat oder privater Schlüssel nicht durch eine PEM-Datei definiert ist, können Sie es mit Dienstprogrammen wie OpenSSL in eine PEM-Datei konvertieren.
PKCS #12/PFX	Das PKCS #12- oder PFX-Format ist ein binäres Format zum Speichern des Serverzertifikats, aller Zwischenzertifikate und des privaten Schlüssels in einer verschlüsselbaren Datei. PFX-Dateien haben in der Regel Erweiterungen wie .pfx und .p12. PFX-Dateien werden in der Regel auf Windows-Computern zum Importieren und Exportieren von Zertifikaten und privaten Schlüsseln verwendet.
Privater Schlüssel	Wird auf dem TLS-Server zum Entschlüsseln von Daten verwendet. Nur der TLS-Server hat den privaten Schlüssel. Er wird nicht für TLS-Clients freigegeben.
Öffentlicher Schlüssel	Wird verwendet, um Daten zu verschlüsseln, die von einem TLS-Client an einen TLS-Server gesendet werden. Der öffentliche Schlüssel ist im Zertifikat enthalten. Alle TLS-Clients haben eine Kopie des öffentlichen Schlüssels des Servers.
References	Verweise bieten eine Ebene der Indirektion für Schlüsselspeicher. Daher ist für Änderungen am Schlüsselspeicher keine Aktualisierung des virtuellen Hosts erforderlich, solange derselbe Verweis und derselbe Schlüsselalias beibehalten werden. So können Sie diese Änderungen selbst vornehmen und die Abhängigkeiten vom Apigee-Supportteam reduzieren.
Selbst signiertes Zertifikat	Ein Zertifikat, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde. Aussteller und Subjekt sind identisch. Sie sind mit dem privaten Schlüssel signiert, der dem darin enthaltenen öffentlichen Schlüssel entspricht.
SNI	Server Name Indication. Ermöglicht die Bereitstellung mehrerer HTTPS-Ziele über dieselbe IP-Adresse und denselben Port, ohne dass diese Ziele dasselbe Zertifikat verwenden müssen.
TLS-Zertifikat	Eine digitale Datei, die eine Identität in einer TLS-Transaktion identifiziert. Ein Zertifikat oder cert kann je nach TLS-Konfiguration verwendet werden, um den TLS-Server und den TLS-Client zu identifizieren.
Truststore	Enthält vertrauenswürdige Zertifikate auf einem TLS-Client, mit denen das dem Client dargestellte Zertifikat eines TLS-Servers validiert wird. Diese Zertifikate sind in der Regel selbst signierte Zertifikate oder Zertifikate, die nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert wurden. Bei der Northbound-Verbindung werden die Zertifikate der Clientanwendung im Truststore in Apigee Edge gespeichert. Dies ist nur erforderlich, wenn Sie eine bidirektionale TLS-Verbindung zwischen dem Client und Apigee konfiguriert haben. Bei der Southbound-Verbindung werden die Zertifikate des Backend-Servers im Truststore in Apigee Edge gespeichert. Dies ist erforderlich, wenn Sie das Zertifikat des Back-Ends in Apigee Edge bei der einseitigen oder bidirektionalen TLS-Kommunikation zwischen Apigee Edge und dem Back-End-Server prüfen möchten. In Apigee Edge gibt es kein separates Truststore-Objekt. Daher werden die Truststores als Keystore-Objekt erstellt, aber überall dort, wo sie verwendet werden (z. B. in virtuellen Hosts, Zielendpunkten, Zielservern usw.), als Truststore referenziert.
Virtueller Host	Ein virtueller Host stellt den Apigee API-Endpunkt für Clientanwendungen dar. Es handelt sich um eine Einheit, die das Hosten mehrerer Domainnamen (mit separater Verarbeitung jedes Namens) auf einem einzelnen Server (oder Serverpool) ermöglicht. So kann ein Server seine Ressourcen wie Arbeitsspeicher und Prozessorzyklen freigeben, ohne dass alle bereitgestellten Dienste denselben Hostnamen verwenden müssen. Ein virtueller Host kann entweder HTTP- oder HTTPS-Traffic (SSL-aktiviert) bereitstellen. Ein SSL-fähiger virtueller Host kann im One-Way- oder Two-Way-TLS-Modus konfiguriert werden. Sie wird mit Folgendem konfiguriert: Ein oder mehrere Hostaliase (DNS-Name des API-Endpunkts). Port Schlüsselspeicher Schlüsselalias zur eindeutigen Identifizierung eines der Serverzertifikate im Schlüsselspeicher. Optional: Ein Truststore (bei bidirektionaler TLS, wenn die Clientauthentifizierung aktiviert ist).

One-Way-TLS/SSL

Die folgende Abbildung zeigt den TLS-/SSL-Handshake für die Einwegauthentifizierung zwischen einem TLS-Client und einem TLS-Server:

In einer One-Way-TLS-Konfiguration sieht der Handshake so aus:

• Der Client sendet eine Sitzungsanfrage an den Server.
• Der Server antwortet mit einem Zertifikat, das seinen öffentlichen Schlüssel enthält. Dieses Zertifikat stammt aus dem Schlüsselspeicher des Servers, der auch den privaten Schlüssel des Servers enthält. Der private Schlüssel wird niemals an den Client gesendet.
• Bei einem signierten Zertifikat verwendet der Client einen Truststore mit Serverzertifikaten und öffentlichen Schlüsseln, um zu prüfen, ob die Zertifikatskette von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) signiert wurde.
• Der Client und der Server tauschen mehrere weitere Nachrichten aus, um die Schlüssel zu validieren.
• Der Client beginnt mit der TLS-Datenübertragung mit dem Server.

Die folgende Abbildung zeigt den TLS-/SSL-Handshake mit einem optionalen Truststore auf dem Client:

Wenn der TLS-Server ein selbstsigniertes Zertifikat oder ein Zertifikat verwendet, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert ist, erstellen Sie einen Truststore auf dem Client. Der Client füllt seinen Truststore mit Serverzertifikaten und öffentlichen Schlüsseln, denen er vertraut. Wenn der Client ein Zertifikat empfängt, wird das eingehende Zertifikat anhand der Zertifikate in seinem Truststore validiert.

Bei One-Way-TLS kann Edge entweder der Server oder der Client sein:

• Edge als TLS-Server

  Edge ist der Server, auf dem der TLS-Endpunkt gehostet wird. Der TLS-Endpunkt entspricht einem API-Proxy, der auf einem virtuellen Host bereitgestellt wird. Der Client ist eine App, die versucht, auf den API-Proxy zuzugreifen. In diesem Szenario enthält Edge den Keystore mit dem Zertifikat und dem privaten Schlüssel.

• Edge als TLS-Client

  Edge fungiert als Client, der auf einen Backend-Dienst zugreift. In diesem Fall entspricht der Back-End-Dienst dem Server, auf dem ein TLS-Endpunkt gehostet wird. Der Backend-Server hat daher einen Keystore, der sein Zertifikat und seinen privaten Schlüssel enthält.

Bidirektionales TLS

Die folgende Abbildung zeigt den TLS-/SSL-Handshake für die Zwei-Wege-TLS-Authentifizierung zwischen einem Client und einem Server:

Bei bidirektionalem TLS läuft der Handshake so ab:

• Client und Server haben jeweils eigene Keystores. Der Schlüsselspeicher des Clients enthält sein Zertifikat und seinen privaten Schlüssel und der Schlüsselspeicher des Servers enthält sein Zertifikat und seinen privaten Schlüssel.
• Der TLS-Server stellt dem TLS-Client sein Zertifikat zur Authentifizierung bereit. Der Client prüft dann die Identität des Servers, bevor er sein Zertifikat an den Server sendet.
• Der TLS-Client stellt dem TLS-Server sein Zertifikat zur Authentifizierung bereit.

Die folgende Abbildung zeigt den TLS-Handshake mit einem optionalen Truststore:

In diesem Szenario sieht der Handshake so aus:

• Wenn der TLS-Server ein selbst signiertes Zertifikat oder ein Zertifikat verwendet, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert ist, erstellen Sie einen Truststore auf dem Client. Der Client hat eine Kopie des Serverzertifikats in seinem Truststore. Während des TLS-Handshakes vergleicht der Client das Zertifikat in seinem Truststore mit dem Zertifikat, das vom Server gesendet wird, um die Identität des Servers zu bestätigen.
• Wenn der TLS-Client ein selbst signiertes Zertifikat oder ein Zertifikat verwendet, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert ist, erstellen Sie einen Truststore auf dem Server.Der Server enthält eine Kopie des Clientzertifikats in seinem Truststore. Während des TLS-Handshakes vergleicht der Server das Zertifikat in seinem Truststore mit dem Zertifikat, das vom Client gesendet wurde, um die Identität des Clients zu bestätigen.

Der Client, der Server oder beide können einen Truststore verwenden.

Bei der Zwei-Wege-TLS kann Edge entweder der Server oder der Client sein:

• Edge als Server

  Edge ist der Server, auf dem der TLS-Endpunkt gehostet wird. Der TLS-Endpunkt entspricht einem API-Proxy. Der Client ist eine App, die versucht, auf den API-Proxy zuzugreifen. In diesem Szenario hat Edge einen Schlüsselspeicher mit dem Zertifikat und dem privaten Schlüssel und benötigt einen Truststore mit dem Zertifikat und der CA-Kette des Clients.

• Edge als Client

  Edge fungiert als Client, der auf einen Back-End-Dienst zugreift. In diesem Fall entspricht der Backend-Dienst dem Server, auf dem der TLS-Endpunkt gehostet wird. Der Backend-Server hat daher einen Keystore, der sein Zertifikat und seinen privaten Schlüssel enthält.

  Edge muss auch einen Keystore definieren, der das Zertifikat enthält, das zur Validierung des Backend-Dienstes erforderlich ist, und optional einen Truststore, der das Zertifikat des Backend-Servers enthält, wenn der Server ein selbst signiertes Zertifikat oder ein Zertifikat verwendet, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde.

Wichtig ist, dass Edge flexibel genug ist, um bidirektionales TLS zu unterstützen, unabhängig davon, wie Sie es konfigurieren.

SNI-Unterstützung

Edge unterstützt die Verwendung von Server Name Indication (SNI) von API-Proxys zu Edge, wobei Edge als TLS-Server fungiert, und von Edge zu Zielendpunkten, wobei Edge als TLS-Client fungiert, sowohl in Cloud- als auch in Private Cloud-Installationen.

Mit SNI, einer Erweiterung von TLS/SSL, können mehrere HTTPS-Ziele über dieselbe IP-Adresse und denselben Port bereitgestellt werden, ohne dass für diese Ziele dasselbe Zertifikat erforderlich ist.

Informationen zum Aktivieren von SNI für eine lokale Installation finden Sie unter SNI mit Edge verwenden.

Nord- und Südrichtung

In Apigee bezieht sich „northbound“ auf den API-Endpunkt, der von Clientanwendungen zum Aufrufen des API-Proxys verwendet wird. Normalerweise ist der Router der Einstiegspunkt in Apigee Edge und verarbeitet die eingehenden Anfragen an Apigee Edge. Daher wird in Apigee der Endpunkt, der für die Kommunikation zwischen der Clientanwendung und Apigee Edge (Router) verwendet wird, als Northbound bezeichnet.

In Apigee bezieht sich „Southbound“ auf den Zielendpunkt, den Apigee für die Kommunikation mit dem Backend-Server verwendet. In Apigee wird der Endpunkt, der für die Kommunikation zwischen Apigee Edge (Message Processor) und dem Backend-Server verwendet wird, daher als Southbound bezeichnet. Der Message Processor ist eine Komponente von Apigee Edge, die API-Anfragen an Backend-Zielserver weiterleitet.

Die folgende Abbildung zeigt Northbound- und Southbound-Verbindungen für Apigee Edge: