Sie sehen die Dokumentation zu Apigee Edge.
Rufen Sie die Apigee X-Dokumentation auf. weitere Informationen
Transport Layer Security (TLS), dessen Vorgänger Secure Sockets Layer (SSL) ist, ist die Standardsicherheitstechnologie zum Herstellen einer verschlüsselten Verbindung zwischen einem Webserver und einem Webclient, z. B. einem Browser oder einer Anwendung. Ein verschlüsselter Link sorgt dafür, dass alle Daten, die zwischen dem Server und dem Client übertragen werden, privat bleiben. Zur Verwendung von TLS stellt ein Client eine sichere Anfrage an den Server. Dazu verwendet er das verschlüsselte HTTPS-Protokoll anstelle des unverschlüsselten HTTP-Protokolls.
Edge unterstützt One-Way-TLS und Zwei-Wege-TLS sowohl in einer Cloud- als auch einer lokalen Bereitstellung. Informationen zu unterstützten TLS-Versionen finden Sie unter Unterstützte Software und unterstützte Versionen. Mit One-Way-TLS kann der TLS-Client die Identität des TLS-Servers prüfen. Beispielsweise kann eine App, die auf einem Android-Smartphone (Client) ausgeführt wird, die Identität von Edge APIs (Server) prüfen.
Apigee unterstützt auch eine stärkere Form der Authentifizierung mit Zwei-Wege- oder Client-TLS. In der Regel implementieren Sie Zwei-Wege-TLS, um die Sicherheit des End-to-End zu verbessern und Ihre Daten vor Client-Angriffen wie Client-Spoofing oder Man-in-the-Middle-Angriffen zu schützen. Bei der Zwei-Wege-TLS-Prüfung überprüft der Client die Identität des Servers, gefolgt vom Server, der die Identität des Clients überprüft.
TLS-Terminologie
Sie sollten mit den folgenden wichtigen Begriffen und Konzepten vertraut sein, bevor Sie TLS konfigurieren:
|
Laufzeit |
Definition |
|---|---|
|
Kanada |
Zertifizierungsstelle. Eine vertrauenswürdige Entität wie Symantec oder VeriSign, die zum Ausstellen von Zertifikaten und zur Validierung der Authentizität eines Zertifikats verwendet wird. Für einen Zertifikattyp, der als selbst signiertes Zertifikat bezeichnet wird, ist keine Zertifizierungsstelle erforderlich. |
|
Zertifikatskette |
Oft haben Sie kein Zertifikat, das vom privaten Root-Schlüssel Ihrer Zertifizierungsstelle signiert wurde. Stattdessen steht Ihnen Ihr Zertifikat zusammen mit einem oder mehreren Zwischenzertifikaten zur Verfügung, die eine Kette bilden. Das letzte Zwischenzertifikat in der Kette wird in der Regel vom privaten Root-Schlüssel der Zertifizierungsstelle signiert. |
|
Kundenbetreuer |
Anfrage zur Zertifikatssignierung. Eine 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 weitere Informationen wie den Namen der Organisation, den Standort und den Domainnamen. Die Zertifizierungsstelle signiert die CSR, um ein TLS-Zertifikat zu erstellen. In der Regel generieren Sie eine CSR, wenn Sie ein abgelaufenes Zertifikat haben und es verlängern möchten. |
| DEER |
Distinguished Encoding Rules. Das DER-Format ist eine Binärform eines Zertifikats und nicht das ASCII-PEM-Format. Die Dateiendung lautet manchmal „.der“, oft aber die Dateiendung „.cer“. Die einzige Möglichkeit, zwischen einer DER-CER-Datei und einer PEM-CER-Datei zu unterscheiden, besteht darin, die Datei in einem Texteditor zu öffnen und nach den Anweisungen |
| Schlüsselalias |
Ein Schlüsselalias identifiziert einen Schlüsselspeichereintrag (TLS-Zertifikat und entsprechender privater Schlüssel) im Schlüsselspeicher eindeutig.
In Apigee Edge wird |
|
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 Verbindung nach Norden fungiert der Router als Server und sein Zertifikat wird im Schlüsselspeicher in Apigee Edge gespeichert. Bei der southbound-Verbindung fungiert der Message Processor als Client und der Back-End-Server als Server. Das Clientzertifikat und sein privater Schlüssel werden im Schlüsselspeicher in Apigee Edge gespeichert. |
| Pixel 7b |
Das PKCS #7- oder P7B-Format wird normalerweise im Base64-ASCII-Format gespeichert und hat die Dateiendung „.p7b“ oder „.p7c“. P7B-Zertifikate enthalten die Anweisungen |
|
PEM |
Das PEM-Format (Privacy Enhanced Mail) ist ein textbasiertes ASCII-Format, das eine Base64-Codierung des DER-Formats (binary Distinguished Encoding Rules) ist. PEM-Zertifikate können in einem beliebigen Texteditor geöffnet werden. Der tatsächliche Inhalt des Zertifikats wird zwischen den Anweisungen Sie entspricht dem X.509-Format zum Speichern eines Zertifikats, einer Zertifikatskette oder eines privaten Schlüssels. Wenn Ihr Zertifikat oder Ihr privater Schlüssel nicht in einer PEM-Datei definiert ist, können Sie sie mit 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 die Endung „.pfx“ und „.p12“. PFX-Dateien werden in der Regel auf Windows-Computern verwendet, um Zertifikate und private Schlüssel zu importieren und zu exportieren. |
|
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 zum Verschlüsseln von Daten verwendet, 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 | Referenzen bieten eine indirekte Ebene für Schlüsselspeicher. Daher ist für Schlüsselspeicheränderungen keine Aktualisierung des virtuellen Hosts erforderlich, solange dieselbe Referenz und derselbe Schlüsselalias beibehalten werden. So können Sie diese Änderungen selbst bereitstellen und die Abhängigkeiten mit dem Apigee-Supportteam reduzieren. |
|
Selbst signiertes Zertifikat |
Ein Zertifikat, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert ist. Der Aussteller und das Subjekt sind identisch. Sie werden mit dem privaten Schlüssel signiert, der mit dem öffentlichen Schlüssel übereinstimmt, den sie enthalten. |
|
SNI |
Servername-Angabe. 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 oder cert verwendet werden, um den TLS-Server und TLS-Client zu identifizieren. |
|
Truststore |
Enthält vertrauenswürdige Zertifikate auf einem TLS-Client, mit denen das Zertifikat eines TLS-Servers validiert wird, das dem Client angezeigt wird. Dies sind in der Regel selbst signierte Zertifikate oder Zertifikate, die nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert wurden. Bei der Verbindung nach Norden werden die Zertifikate der Clientbibliothek im Truststore in Apigee Edge gespeichert. Dies ist nur erforderlich, wenn Sie eine Zwei-Wege-TLS zwischen dem Client und Apigee konfiguriert haben. Bei der southbound-Verbindung werden die Zertifikate des Back-End-Servers im Truststore in Apigee Edge gespeichert. Dies ist erforderlich, wenn Sie das Zertifikat des Back-Ends in Apigee Edge mit 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 Schlüsselspeicherobjekt erstellt, aber überall dort als Truststore bezeichnet, wo sie verwendet werden (z. B. in virtuellen Hosts, Zielendpunkten, Zielservern usw.). |
| Virtueller Host |
Virtueller Host stellt den Apigee API-Endpunkt für Clientanwendungen dar. Es ist eine Entität, die das Hosten mehrerer Domainnamen (mit separater Verarbeitung jedes Namens) auf einem einzelnen Server (oder Pool von Servern) unterstützt. Dadurch kann ein Server seine Ressourcen wie Arbeitsspeicher- und Prozessorzyklen gemeinsam nutzen, ohne dass alle bereitgestellten Dienste denselben Hostnamen verwenden müssen. Ein virtueller Host kann entweder HTTP- oder (SSL-fähigen) HTTPS-Traffic verarbeiten. Ein SSL-fähiger virtueller Host kann im Einweg- oder Zwei-Wege-TLS-Modus konfiguriert werden. Es ist so konfiguriert:
|
One-Way-TLS/SSL
Die folgende Abbildung zeigt das TLS/SSL-Handshake für die Einweg-Authentifizierung zwischen einem TLS-Client und einem TLS-Server:
In einer Einweg-TLS-Konfiguration sieht der Handshake so aus:
- Der Client sendet eine Sitzungsanfrage an den Server.
- Der Server antwortet mit einem Zertifikat, das den ö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.
- Für ein signiertes 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 mehrere weitere Nachrichten aus, um die Schlüssel zu validieren.
- Der Client startet die TLS-Datenübertragung mit dem Server.
Die folgende Abbildung zeigt TLS/SSL-Handshake mit einem optionalen Truststore auf dem Client:
Wenn der TLS-Server ein selbst signiertes oder ein nicht von einer vertrauenswürdigen Zertifizierungsstelle signiertes Zertifikat verwendet, 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 erhält, wird es anhand der Zertifikate im 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, wobei der TLS-Endpunkt einem API-Proxy entspricht, der auf einem virtuellen Host bereitgestellt wird. Der Client ist eine Anwendung, die versucht, auf den API-Proxy zuzugreifen. In diesem Szenario hat Edge den Schlüsselspeicher, der das Zertifikat und den privaten Schlüssel enthält.
-
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, der einen TLS-Endpunkt hostet. Daher verfügt der Back-End-Server über einen Schlüsselspeicher, der das zugehörige Zertifikat und den privaten Schlüssel enthält.
Zwei-Wege-TLS
Die folgende Abbildung zeigt das TLS/SSL-Handshake für die Zwei-Wege-TLS-Authentifizierung zwischen einem Client und einem Server:
Bei Zwei-Wege-TLS sieht der Handshake so aus:
- Der Client und der Server haben beide jeweils einen eigenen Schlüsselspeicher. Der Schlüsselspeicher des Clients enthält das Zertifikat und den privaten Schlüssel, der Schlüsselspeicher des Servers enthält das Zertifikat und den 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 präsentiert dem TLS-Server sein Zertifikat, um sich beim Server zu authentifizieren.
Die folgende Abbildung zeigt TLS-Handshake mit einem optionalen Truststore:
In diesem Szenario sieht der Handshake wie folgt aus:
- Wenn der TLS-Server ein selbst signiertes oder nicht von einer vertrauenswürdigen Zertifizierungsstelle signiertes Zertifikat verwendet, erstellen Sie einen Truststore auf dem Client. Der Client hat eine Kopie des Serverzertifikats im Truststore. Beim TLS-Handshake vergleicht der Client das Zertifikat im Truststore mit dem Zertifikat, das vom Server gesendet wird, um die Identität des Servers zu verifizieren.
- Wenn der TLS-Client ein selbst signiertes oder nicht von einer vertrauenswürdigen Zertifizierungsstelle signiertes Zertifikat verwendet, erstellen Sie einen Truststore auf dem Server.Auf dem Server befindet sich eine Kopie des Clientzertifikats im Truststore. Beim TLS-Handshake vergleicht der Server das Zertifikat in seinem Truststore mit dem Zertifikat, das vom Client gesendet wird, um die Identität des Clients zu verifizieren.
Der Client oder der Server oder beide können einen Truststore verwenden.
Bei 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, wobei der TLS-Endpunkt einem API-Proxy entspricht. Der Client ist eine Anwendung, die versucht, auf den API-Proxy zuzugreifen. In diesem Szenario hat Edge einen Schlüsselspeicher, der das Zertifikat und den privaten Schlüssel enthält, und benötigt einen Truststore, der das Zertifikat und die CA-Kette des Clients enthält.
-
Edge als Client
Edge fungiert als Client, der auf einen Back-End-Dienst zugreift. In diesem Fall entspricht der Back-End-Dienst dem Server, auf dem der TLS-Endpunkt gehostet wird. Der Back-End-Server hat daher einen Schlüsselspeicher, der das zugehörige Zertifikat und den privaten Schlüssel enthält.
Edge muss auch einen Schlüsselspeicher definieren, der das Zertifikat enthält, das für die Validierung beim Back-End-Dienst erforderlich ist, sowie optional einen Truststore, der das Zertifikat vom Back-End-Server enthält, wenn der Server ein selbst signiertes Zertifikat oder ein Zertifikat verwendet, das nicht von einer vertrauenswürdigen Zertifizierungsstelle signiert ist.
Wichtig ist, dass Sie daran denken, dass Edge flexibel genug ist, um Zwei-Wege-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, bei denen Edge als TLS-Client sowohl in Cloud- als auch in Private Cloud-Installationen agiert.
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.
Richtung Norden und Süden
In Apigee bezieht sich Norden auf den API-Endpunkt, der von Clientanwendungen zum Aufrufen des API-Proxys verwendet wird. In der Regel ist der Router der Einstiegspunkt in Apigee Edge und verarbeitet die eingehenden Anfragen an Apigee Edge. Daher wird in Apigee der für die Kommunikation zwischen der Clientanwendung und Apigee Edge (Router) verwendete Endpunkt als Richtung Norden bezeichnet.
In Apigee bezieht sich „Southbound“ (Richtung Süden) auf den Zielendpunkt, den Apigee für die Kommunikation mit dem Back-End-Server verwendet. Daher wird in Apigee der Endpunkt, der für die Kommunikation zwischen dem Apigee Edge (Nachrichtenprozessor) und dem Back-End-Server verwendet wird, als southbound bezeichnet. Der Message Processor ist eine Komponente von Apigee Edge, die API-Anfragen an Back-End-Zielserver weiterleitet.
Die folgende Abbildung zeigt Verbindungen nach Norden und Süden für Apigee Edge:
