Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. info
Protokół TLS (Transport Layer Security), którego poprzednikiem jest protokół SSL (Secure Sockets Layer), to standardowa technologia zabezpieczeń
służąca do tworzenia zaszyfrowanego połączenia między serwerem internetowym 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ć protokołu 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 lokalnego (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. Zazwyczaj wdrażasz dwukierunkowy protokół TLS, aby zwiększyć bezpieczeństwo na całej długości połączenia i chronić dane przed atakami ze strony 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:
|
Termin |
Definicja |
|---|---|
|
CA |
Urząd certyfikacji. Zaufany podmiot, np. Symantec lub VeriSign, który wydaje certyfikaty i weryfikuje 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 przez główny klucz prywatny 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. Żądanie CSR zawiera klucz publiczny i inne informacje, takie jak nazwa organizacji, lokalizacja i nazwa domeny. Urząd certyfikacji podpisuje żądanie podpisania certyfikatu, 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 postać certyfikatu, a nie format PEM ASCII. Czasami ma rozszerzenie .der, ale często ma rozszerzenie .cer. Jedynym sposobem na odróżnienie pliku DER w formacie .cer od pliku PEM w formacie .cer jest otwarcie pliku w edytorze tekstu i wyszukanie instrukcji |
| Alias klucza |
Alias klucza jednoznacznie identyfikuje wpis w magazynie kluczy (certyfikat TLS i odpowiadający mu klucz prywatny).
W Apigee Edge |
|
Keystore |
Magazyn kluczy to repozytorium zawierające co najmniej 1 certyfikat TLS i odpowiedni klucz prywatny, który służy 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 wiadomości 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. 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 zmniejszyć zależność od zespołu pomocy Apigee. |
|
Certyfikat z podpisem własnym |
certyfikat, który nie został 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 TLS jednokierunkowym lub dwukierunkowym. Jest on skonfigurowany w ten sposób:
|
Jednokierunkowe TLS/SSL
Na poniższym rysunku 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 na kliencie:
Jeśli serwer TLS używa certyfikatu podpisanego samodzielnie lub certyfikatu, który nie jest podpisany przez zaufany urząd certyfikacji, musisz utworzyć magazyn zaufania na kliencie. Klient wypełnia swój magazyn zaufanych certyfikatów certyfikatami serwera i kluczami publicznymi, którym ufa. Gdy klient otrzyma certyfikat, jest on weryfikowany na podstawie certyfikatów w jego magazynie zaufania.
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 TLS, który odpowiada serwerowi proxy 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 przebiega w ten sposób:
- 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, zanim wyśle do niego swój certyfikat.
- Klient TLS przedstawia swój certyfikat serwerowi TLS, aby uwierzytelnić się na serwerze.
Na poniższym rysunku przedstawiono uzgadnianie połączenia TLS z użyciem opcjonalnego magazynu zaufanych certyfikatów:
W tym scenariuszu uzgadnianie połączenia wygląda tak:
- Jeśli serwer TLS używa certyfikatu podpisanego samodzielnie lub certyfikatu, który nie jest podpisany przez zaufany urząd certyfikacji, utwórz magazyn zaufania 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 TLS używa certyfikatu podpisanego samodzielnie lub certyfikatu, który nie jest podpisany przez zaufany urząd certyfikacji, utwórz magazyn zaufania na serwerze.Serwer ma w swoim magazynie zaufania 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.
Zaufane repozytorium może być używane przez klienta, serwer lub oba te elementy.
W przypadku dwukierunkowego protokołu TLS Edge może być serwerem lub klientem:
-
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 CA.
-
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 serwerów proxy 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 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 interfejsu API używanego przez aplikacje klienckie do wywoływania serwera 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 północnym.
W Apigee kierunek południowy odnosi się do docelowego punktu końcowego, którego Apigee używa do komunikacji z serwerem backendu. Dlatego w Apigee punkt końcowy używany do komunikacji między Apigee Edge (procesorem wiadomości) a serwerem backendu jest nazywany połączeniem wychodzącym. Procesor wiadomości 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:
