TLS/SSL

Sie sehen sich die Dokumentation zu Apigee Edge an.
Sehen Sie sich die Apigee X-Dokumentation an. info

Transport Layer Security (TLS), dessen Vorgänger Secure Sockets Layer (SSL) ist, ist die Standardsicherheitstechnologie zum Aufbau 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, privat bleiben. Wenn TLS verwendet wird, sendet ein Client eine sichere Anfrage an den Server, indem er das verschlüsselte HTTPS-Protokoll anstelle des unverschlüsselten HTTP-Protokolls verwendet.

Edge unterstützt uni- und bidirektionale TLS sowohl bei der Cloud- als auch bei der On-Premises-Bereitstellung. Informationen zu den unterstützten TLS-Versionen finden Sie unter Unterstützte Software und unterstützte Versionen. Bei Einweg-TLS kann der TLS-Client die Identität des TLS-Servers überprüfen. So kann beispielsweise eine App, die auf einem Android-Smartphone (Client) ausgeführt wird, die Identität von Edge APIs (Server) überprüfen.

Apigee unterstützt auch eine stärkere Authentifizierungsform mit bidirektionaler TLS- oder Client-TLS-Authentifizierung. Sie implementieren in der Regel Zwei-Wege-TLS, um die Sicherheit von Anfang bis Ende zu verbessern und Ihre Daten vor Clientangriffen wie Client-Spoofing oder Man-in-the-Middle-Angriffen zu schützen. Bei der beidseitigen TLS-Verschlüsselung prüft der Client die Identität des Servers, gefolgt von der Überprüfung der Identität des Clients durch den Server.

TLS-Terminologie

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

Begriff	Definition
CA	Zertifizierungsstelle. Eine vertrauenswürdige Instanz wie Symantec oder VeriSign, die Zertifikate ausstellt und die Echtheit eines Zertifikats bestätigt. Für eine Art von Zertifikat, das sogenannte selbst signierte Zertifikat, ist keine Zertifizierungsstelle erforderlich.
Zertifikatskette	Häufig haben Sie kein Zertifikat, das vom privaten Stammschlü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 vom privaten Stammschlüssel der Zertifizierungsstelle signiert.
CSR	Zertifikatsignaturanfrage. Ein CSR ist eine Datei, die auf dem TLS-Server basierend auf dem privaten Schlüssel generiert wird. Die 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. Sie generieren in der Regel einen CSR, wenn Sie ein abgelaufenes Zertifikat haben und es verlängern möchten.
DER	Distinguished Encoding Rules. Das DER-Format ist eine Binärform eines Zertifikats anstelle des ASCII-PEM-Formats. Manchmal hat es die Dateiendung „.der“, oft aber „.cer“. Der einzige Unterschied zwischen einer DER-CER-Datei und einer PEM-CER-Datei besteht darin, dass in der Datei die Anweisungen BEGIN und END zu finden sind. 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 eindeutig einen Schlüsselspeichereintrag (TLS-Zertifikat und entsprechender privater Schlüssel) im Schlüsselspeicher. In Apigee Edge wird KeyAlias als alias bezeichnet, wenn Sie das Zertifikat/den Schlüssel über die Benutzeroberfläche oder die API in die Schlüsselspeicher hochladen.
Keystore	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 Schlüsselspeicher in Apigee Edge gespeichert. Bei der Südverbindung fungiert der Message Processor als Client und der Backend-Server als Server. Das Clientzertifikat und sein privater Schlüssel werden im Schlüsselspeicher in Apigee Edge gespeichert.
P7B	Das PKCS #7- oder P7B-Format wird in der Regel 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 Zertifikatsketten, 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 jedem Texteditor geöffnet werden. Der tatsächliche Zertifikatsinhalt wird zwischen den Anweisungen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- begrenzt. Sie entspricht dem X.509-Format für das Speichern eines Zertifikats, einer Zertifikatskette oder eines privaten Schlüssels. Wenn Ihr Zertifikat oder Ihr privater Schlüssel nicht durch eine PEM-Datei definiert ist, können Sie ihn mithilfe von Dienstprogrammen wie OpenSSL in eine PEM-Datei konvertieren.
PKCS #12/PFX	Das PKCS #12- oder PFX-Format ist ein Binärformat 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 an TLS-Clients weitergegeben.
Ö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 gewisse Indirektheit für Schlüsselspeicher. Daher ist für Schlüsselspeicheränderungen kein Aktualisieren des virtuellen Hosts erforderlich, solange dieselbe Referenz 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 werden mit dem privaten Schlüssel signiert, der mit dem darin enthaltenen öffentlichen Schlüssel übereinstimmt.
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 Entität in einer TLS-Transaktion identifiziert. Je nach TLS-Konfiguration kann ein Zertifikat (cert) 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 sind. 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 Südverbindung 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 in einer ein- oder zweiseitigen TLS-Kommunikation zwischen Apigee Edge und dem Back-End-Server prüfen möchten. Apigee Edge hat kein separates Truststore-Objekt. Daher werden die Truststores als Keystore-Objekt erstellt, aber überall dort als Truststore referenziert, wo sie verwendet werden (z. B. in virtuellen Hosts, Zielendpunkten, Zielservern usw.).
Virtueller Host	Der virtuelle Host stellt den Apigee API-Endpunkt für Clientanwendungen dar. Es ist eine Entität, die beim Hosten mehrerer Domainnamen (mit separater Verarbeitung jedes Namens) auf einem einzigen Server (oder einem Serverpool) unterstützt. 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-fähig) bereitstellen. Ein SSL-fähiger virtueller Host kann im One-Way- oder Bidirektional-TLS-Modus konfiguriert werden. Sie wird mit den folgenden Elementen konfiguriert: Ein oder mehrere Hostaliasse (DNS-Namen des API-Endpunkts). Port Schlüsselspeicher Schlüsselalias zur eindeutigen Identifizierung eines der Serverzertifikate im Schlüsselspeicher. Optional: Truststore (bei bidirektionaler TLS, bei der die Clientauthentifizierung aktiviert ist)

Einweg-TLS/SSL

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

Bei 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 nie 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 signiert ist.
• Der Client und der Server tauschen noch einige Nachrichten aus, um die Schlüssel zu validieren.
• Der Client startet die TLS-Datenübertragung mit dem Server.

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

Wenn der TLS-Server ein selbst signiertes Zertifikat oder ein Zertifikat verwendet, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde, erstellen Sie einen Truststore auf dem Client. Der Client füllt seinen Truststore mit Serverzertifikaten und öffentlichen Schlüsseln, denen er vertraut, auf. Wenn der Client ein Zertifikat erhält, wird es 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 befindet sich der Keystore mit dem Zertifikat und dem privaten Schlüssel auf Edge.

• Edge als TLS-Client

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

Bidirektionale TLS

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

Bei der beidseitigen TLS-Verschlüsselung sieht der Handshake so aus:

• Der Client und der Server haben jeweils eigene Schlüsselspeicher. 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 überprü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 wurde, 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 vom Server gesendeten Zertifikat, um die Identität des Servers zu überprüfen.
• Wenn der TLS-Client ein selbst signiertes Zertifikat oder ein Zertifikat verwendet, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert wurde, erstellen Sie einen Truststore auf dem Server.Der Server enthält eine Kopie des Zertifikats des Clients in seinem Truststore. Während des TLS-Handshakes vergleicht der Server das Zertifikat in seinem Truststore mit dem vom Client gesendeten Zertifikat, um die Identität des Clients zu überprüfen.

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

Bei der bidirektionalen 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 Schlüsselspeicher, der sein Zertifikat und seinen privaten Schlüssel enthält.

  Edge muss auch einen Schlüsselspeicher definieren, der das Zertifikat enthält, das zur Validierung beim Backend-Dienst erforderlich ist, und optional einen Truststore mit dem Zertifikat des Backend-Servers, falls der Server ein selbst signiertes Zertifikat oder ein Zertifikat verwendet, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert ist.

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 diese Ziele dasselbe Zertifikat verwenden müssen.

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

Nach Norden und Süden

In Apigee bezieht sich „Northbound“ auf den API-Endpunkt, der von Clientanwendungen zum Aufrufen des API-Proxys verwendet wird. Der Router ist in der Regel 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, über den Apigee mit dem Backend-Server kommuniziert. Daher wird in Apigee der Endpunkt, der für die Kommunikation zwischen dem Apigee Edge (Nachrichtenprozessor) und dem Backend-Server verwendet wird, 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: