Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info
Transport Layer Security (TLS), którego poprzednikiem jest Secure Sockets Layer (SSL), to standardowa technologia zabezpieczeń do tworzenia zaszyfrowanego połączenia między serwerem WWW a klientem internetowym, takim jak przeglądarka lub aplikacja. Zaszyfrowane połączenie zapewnia, że wszystkie dane przesyłane między serwerem a klientem pozostają prywatne. Aby używać TLS, klient wysyła do serwera bezpieczne żądanie za pomocą zaszyfrowanego protokołu HTTPS zamiast niezaszyfrowanego protokołu HTTP.
Edge obsługuje jednokierunkowy i dwukierunkowy protokół TLS w przypadku wdrożenia w chmurze i lokalnie (obsługiwane wersje TLS znajdziesz w sekcji Obsługiwane oprogramowanie i obsługiwane wersje). Jednokierunkowy protokół TLS umożliwia klientowi TLS weryfikowanie tożsamości serwera TLS. Na przykład aplikacja działająca na telefonie z Androidem (klient) może weryfikować tożsamość interfejsów API Edge (serwer).
Apigee obsługuje też silniejszą formę uwierzytelniania za pomocą dwukierunkowego protokołu TLS lub protokołu TLS klienta. Dwukierunkowy protokół TLS jest zwykle wdrażany w celu zwiększenia bezpieczeństwa na całej długości połączenia i ochrony danych przed atakami na klienta, takimi jak podszywanie się pod klienta czy ataki typu „man-in-the-middle”. W przypadku dwukierunkowego protokołu TLS klient weryfikuje tożsamość serwera, a następnie serwer weryfikuje tożsamość klienta.
Terminologia TLS
Zanim skonfigurujesz TLS, zapoznaj się z tymi ważnymi terminami i pojęciami:
|
Okres obowiązywania |
Definicja |
|---|---|
|
CA |
Urząd certyfikacji. Zaufany podmiot, taki jak Symantec lub VeriSign, który wydaje certyfikaty i potwierdza ich autentyczność. Jeden z rodzajów certyfikatów, zwany certyfikatem podpisanym samodzielnie, nie wymaga urzędu certyfikacji. |
|
Łańcuch certyfikatów |
Często nie masz certyfikatu podpisanego głównym kluczem prywatnym urzędu certyfikacji. Zamiast tego masz certyfikat wraz z co najmniej 1 certyfikatem pośrednim, które tworzą łańcuch. Ostatni certyfikat pośredni w łańcuchu jest zwykle podpisywany głównym kluczem prywatnym urzędu certyfikacji. |
|
CSR |
Żądanie podpisania certyfikatu. CSR to plik generowany na serwerze TLS na podstawie klucza prywatnego. Zawiera on klucz publiczny i inne informacje, takie jak nazwa organizacji, lokalizacja i nazwa domeny. Urząd certyfikacji podpisuje żądanie CSR, aby utworzyć certyfikat TLS. Żądanie CSR generuje się zwykle wtedy, gdy certyfikat wygasł i chcesz go odnowić. |
| DER |
Wyróżniające się reguły kodowania. Format DER to binarna forma certyfikatu zamiast formatu PEM ASCII. Czasami ma rozszerzenie .der, ale często ma rozszerzenie .cer. Jedynym sposobem na odróżnienie pliku DER z rozszerzeniem .cer od pliku PEM z rozszerzeniem .cer jest otwarcie pliku w edytorze tekstu i wyszukanie instrukcji |
| Alias klucza |
Alias klucza jednoznacznie identyfikuje wpis w magazynie kluczy (certyfikat TLS i odpowiedni klucz prywatny) w magazynie kluczy.
W Apigee Edge |
|
Keystore |
Magazyn kluczy to repozytorium zawierające co najmniej 1 certyfikat TLS i odpowiedni klucz prywatny, który jest używany do identyfikowania podmiotu podczas uzgadniania połączenia TLS między klientem a serwerem. W przypadku połączenia wychodzącego router działa jako serwer, a jego certyfikat jest przechowywany w magazynie kluczy w Apigee Edge. W przypadku połączenia wychodzącego procesor komunikatów pełni rolę klienta, a serwer backendu – serwera. Certyfikat klienta i jego klucz prywatny są przechowywane w magazynie kluczy w Apigee Edge. |
| P7B |
Format PKCS #7 lub P7B jest zwykle przechowywany w formacie Base64 ASCII i ma rozszerzenie .p7b lub .p7c. Certyfikaty P7B zawierają instrukcje |
|
PEM |
Format PEM (Privacy Enhanced Mail) to tekstowy format ASCII, który jest kodowaniem Base64
binarnego formatu DER (Distinguished Encoding Rules). Certyfikaty PEM można otworzyć w dowolnym edytorze tekstu, a rzeczywista treść certyfikatu jest ograniczona instrukcjami Jest zgodny z formatem X.509 do przechowywania certyfikatu, łańcucha certyfikatów lub klucza prywatnego. Jeśli certyfikat lub klucz prywatny nie jest zdefiniowany przez plik PEM, możesz go przekonwertować na plik PEM za pomocą narzędzi takich jak OpenSSL. |
| PKCS #12/PFX | Format PKCS #12 lub PFX to format binarny do przechowywania certyfikatu serwera, wszystkich certyfikatów pośrednich i klucza prywatnego w jednym pliku, który można zaszyfrować. Pliki PFX mają zwykle rozszerzenia takie jak .pfx i .p12. Pliki PFX są zwykle używane na komputerach z systemem Windows do importowania i eksportowania certyfikatów oraz kluczy prywatnych. |
|
Klucz prywatny |
Używany na serwerze TLS do odszyfrowywania danych. Tylko serwer TLS ma klucz prywatny – nie jest on udostępniany klientom TLS. |
|
Klucz publiczny |
Służy do szyfrowania danych wysyłanych z klienta TLS na serwer TLS. Klucz publiczny jest zawarty w certyfikacie. Wszyscy klienci TLS mają kopię klucza publicznego serwera. |
| References | Odwołania zapewniają poziom pośredni dla magazynów kluczy, dlatego zmiany w magazynie kluczy nie wymagają aktualizacji hosta wirtualnego, o ile zachowane są to samo odwołanie i alias klucza. Dzięki temu możesz samodzielnie wprowadzać te zmiany i ograniczać zależności od zespołu pomocy Apigee. |
|
Certyfikat podpisany samodzielnie |
certyfikat, który nie jest podpisany przez zaufany urząd certyfikacji; Wystawca i podmiot są identyczni. Certyfikaty są podpisane kluczem prywatnym pasującym do klucza publicznego, który zawierają. |
|
SNI |
Wskazanie nazwy serwera. Umożliwia obsługę wielu miejsc docelowych HTTPS z tego samego adresu IP i portu bez konieczności używania przez nie tego samego certyfikatu. |
|
Certyfikat TLS |
Plik cyfrowy, który identyfikuje podmiot w transakcji TLS. Certyfikat, czyli cert, może służyć do identyfikowania serwera TLS i klienta TLS w zależności od konfiguracji TLS. |
|
Truststore |
Zawiera zaufane certyfikaty na kliencie TLS, które są używane do weryfikowania certyfikatu serwera TLS przedstawionego klientowi. Są to zwykle certyfikaty podpisane samodzielnie lub certyfikaty, które nie są podpisane przez zaufany urząd certyfikacji. W przypadku połączenia wychodzącego certyfikaty aplikacji klienckiej są przechowywane w magazynie zaufanych certyfikatów w Apigee Edge. Ten atrybut jest wymagany tylko wtedy, gdy skonfigurowano dwukierunkowy protokół TLS między klientem a Apigee. W przypadku połączenia wychodzącego certyfikaty serwera backendu są przechowywane w magazynie zaufanych certyfikatów w Apigee Edge. Jest to wymagane, jeśli chcesz zweryfikować certyfikat backendu w Apigee Edge w ramach jednokierunkowej lub dwukierunkowej komunikacji TLS między Apigee Edge a serwerem backendu. Apigee Edge nie ma osobnego obiektu truststore. Dlatego magazyny zaufanych certyfikatów są tworzone jako obiekt magazynu kluczy, ale w miejscach, w których są używane (np. w hostach wirtualnych, docelowych punktach końcowych, serwerach docelowych itp.), są określane jako magazyny zaufanych certyfikatów. |
| Wirtualny gospodarz |
Wirtualny host reprezentuje punkt końcowy interfejsu API Apigee dla aplikacji klienckich. Jest to podmiot, który pomaga w hostowaniu wielu nazw domen (z osobną obsługą każdej nazwy) na jednym serwerze (lub puli serwerów). Dzięki temu jeden serwer może udostępniać swoje zasoby, takie jak pamięć i cykle procesora, bez konieczności używania tej samej nazwy hosta przez wszystkie usługi. Host wirtualny może obsługiwać ruch HTTP lub HTTPS (z włączonym protokołem SSL). Wirtualny host z obsługą SSL można skonfigurować w trybie jednokierunkowego lub dwukierunkowego protokołu TLS. Jest on skonfigurowany w ten sposób:
|
Jednokierunkowe TLS/SSL
Na ilustracji poniżej przedstawiono uzgadnianie połączenia TLS/SSL w przypadku uwierzytelniania jednokierunkowego między klientem TLS a serwerem TLS:
W konfiguracji TLS w jednym kierunku uzgadnianie połączenia wygląda tak:
- Klient wysyła do serwera żądanie sesji.
- Serwer odpowiada certyfikatem, który zawiera jego klucz publiczny. Ten certyfikat pochodzi z magazynu kluczy serwera, który zawiera też klucz prywatny serwera. Klucz prywatny nigdy nie jest wysyłany do klienta.
- W przypadku podpisanego certyfikatu klient używa magazynu zaufanych certyfikatów zawierającego certyfikaty serwera i klucze publiczne, aby sprawdzić, czy łańcuch certyfikatów został podpisany przez zaufany urząd certyfikacji.
- Klient i serwer wymieniają jeszcze kilka wiadomości, aby zweryfikować klucze.
- Klient rozpoczyna przesyłanie danych TLS na serwer.
Na poniższym rysunku przedstawiono uzgadnianie połączenia TLS/SSL z użyciem opcjonalnego magazynu zaufanych certyfikatów po stronie klienta:
Jeśli serwer protokołu TLS używa certyfikatu podpisanego samodzielnie lub certyfikatu, który nie jest podpisany przez zaufany urząd certyfikacji, musisz utworzyć magazyn zaufanych certyfikatów na kliencie. Klient wypełnia magazyn zaufanych certyfikatów certyfikatami serwera i kluczami publicznymi, którym ufa. Gdy klient otrzyma certyfikat, przychodzący certyfikat jest weryfikowany na podstawie certyfikatów w jego magazynie zaufanych certyfikatów.
W przypadku jednokierunkowego protokołu TLS Edge może pełnić rolę serwera lub klienta:
-
Edge jako serwer TLS
Edge to serwer hostujący punkt końcowy protokołu TLS, gdzie punkt końcowy protokołu TLS odpowiada proxy interfejsu API wdrożonemu na hoście wirtualnym. Klientem jest aplikacja, która próbuje uzyskać dostęp do serwera proxy interfejsu API. W tym scenariuszu Edge ma magazyn kluczy zawierający certyfikat i klucz prywatny.
-
Edge jako klient TLS
Edge pełni funkcję klienta, który uzyskuje dostęp do usługi backendu. W tym przypadku usługa backendu odpowiada serwerowi hostującemu punkt końcowy TLS. Dlatego serwer backendu ma magazyn kluczy, który zawiera jego certyfikat i klucz prywatny.
Dwukierunkowe TLS
Na poniższym rysunku przedstawiono uzgadnianie połączenia TLS/SSL w przypadku dwukierunkowego uwierzytelniania TLS między klientem a serwerem:
W przypadku dwukierunkowego protokołu TLS uzgadnianie połączenia wygląda tak:
- Klient i serwer mają własne magazyny kluczy. Magazyn kluczy klienta zawiera jego certyfikat i klucz prywatny, a magazyn kluczy serwera zawiera jego certyfikat i klucz prywatny.
- Serwer TLS przedstawia swój certyfikat klientowi TLS, aby się uwierzytelnić. Klient weryfikuje tożsamość serwera przed wysłaniem do niego certyfikatu.
- Klient TLS przedstawia swój certyfikat serwerowi TLS, aby uwierzytelnić się na serwerze.
Ilustracja poniżej przedstawia uzgadnianie połączenia TLS z użyciem opcjonalnego magazynu zaufanych certyfikatów:
W tym scenariuszu uzgadnianie połączenia wygląda tak:
- Jeśli serwer protokołu TLS używa certyfikatu podpisanego samodzielnie lub certyfikatu, który nie jest podpisany przez zaufany urząd certyfikacji, utwórz magazyn zaufanych certyfikatów na kliencie. Klient ma w magazynie zaufanych certyfikatów kopię certyfikatu serwera. Podczas uzgadniania połączenia TLS klient porównuje certyfikat w swoim magazynie zaufanych certyfikatów z certyfikatem wysłanym z serwera, aby zweryfikować tożsamość serwera.
- Jeśli klient protokołu TLS używa certyfikatu podpisanego samodzielnie lub certyfikatu, który nie jest podpisany przez zaufany urząd certyfikacji, utwórz magazyn zaufanych certyfikatów na serwerze.Serwer ma w swoim magazynie zaufanych certyfikatów kopię certyfikatu klienta. Podczas uzgadniania połączenia TLS serwer porównuje certyfikat w swoim magazynie zaufanych certyfikatów z certyfikatem wysłanym przez klienta, aby zweryfikować tożsamość klienta.
Magazyn zaufanych certyfikatów może być używany przez klienta, serwer lub oba te elementy.
W dwukierunkowym protokole TLS Edge może pełnić rolę serwera lub klienta:
-
Edge jako serwer
Edge to serwer hostujący punkt końcowy TLS, który odpowiada proxy interfejsu API. Klientem jest aplikacja, która próbuje uzyskać dostęp do serwera proxy interfejsu API. W tym scenariuszu Edge ma magazyn kluczy zawierający certyfikat i klucz prywatny oraz wymaga magazynu zaufanych certyfikatów zawierającego certyfikat klienta i łańcuch urzędu certyfikacji.
-
Edge jako klient
Edge działa jako klient, który uzyskuje dostęp do usługi backendu. W tym przypadku usługa backendu odpowiada serwerowi hostującemu punkt końcowy TLS. Serwer backendu ma więc magazyn kluczy, który zawiera jego certyfikat i klucz prywatny.
Edge musi też zdefiniować magazyn kluczy zawierający certyfikat potrzebny do uwierzytelnienia się w usłudze backendu, a opcjonalnie magazyn zaufanych certyfikatów zawierający certyfikat serwera backendu, jeśli serwer używa certyfikatu podpisanego samodzielnie lub certyfikatu, który nie jest podpisany przez zaufany urząd certyfikacji.
Pamiętaj, że Edge jest wystarczająco elastyczny, aby obsługiwać dwukierunkowy protokół TLS niezależnie od tego, jak go skonfigurujesz.
Obsługa SNI
Edge obsługuje używanie wskaźnika nazwy serwera (SNI) z proxy interfejsu API do Edge, gdzie Edge działa jako serwer TLS, oraz z Edge do docelowych punktów końcowych, gdzie Edge działa jako klient TLS, zarówno w instalacjach w chmurze, jak i w chmurze prywatnej.
SNI, czyli rozszerzenie protokołu TLS/SSL, umożliwia obsługę wielu miejsc docelowych HTTPS z tego samego adresu IP i portu bez konieczności używania przez nie tego samego certyfikatu.
Informacje o włączaniu SNI w instalacji lokalnej znajdziesz w artykule Korzystanie z SNI w Edge.
w kierunku północnym i południowym,
W Apigee termin „northbound” odnosi się do punktu końcowego API używanego przez aplikacje klienckie do wywoływania proxy interfejsu API. Router jest zwykle punktem wejścia w Apigee Edge i obsługuje żądania przychodzące do Apigee Edge. Dlatego w Apigee punkt końcowy używany do komunikacji między aplikacją kliencką a Apigee Edge (routerem) jest nazywany węzłem północnym.
W Apigee ruch wychodzący odnosi się do docelowego punktu końcowego, którego Apigee używa do komunikacji z backendem serwera. Dlatego w Apigee punkt końcowy używany do komunikacji między Apigee Edge (procesorem komunikatów) a serwerem backendu jest nazywany połączeniem wychodzącym. Procesor komunikatów to komponent Apigee Edge, który przekazuje żądania interfejsu API do serwerów docelowych backendu.
Poniższy rysunek przedstawia połączenia przychodzące i wychodzące w przypadku Apigee Edge:
