Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację
Apigee X. informacje.
Protokół Transport Layer Security (TLS), którego poprzednik to protokół SSL (Secure Sockets Layer), jest standardową technologią zabezpieczeń służącą do tworzenia zaszyfrowanego połączenia między serwerem WWW a klientem internetowym, takim jak przeglądarka lub aplikacja. Zaszyfrowany link zapewnia, że wszystkie dane przesyłane między serwerem a klientem pozostają prywatne. Aby użyć protokołu TLS, klient wysyła bezpieczne żądanie do serwera za pomocą zaszyfrowanego protokołu HTTPS zamiast nieszyfrowanego protokołu HTTP.
Edge obsługuje jednokierunkowe i dwukierunkowe szyfrowanie TLS zarówno w chmurze, jak i lokalnie (informacje o obsługiwanych wersjach TLS znajdziesz w sekcji na temat obsługiwanych wersji oprogramowania i obsługiwanych wersji). Jednokierunkowy protokół TLS umożliwia klientowi TLS weryfikację tożsamości serwera TLS. Na przykład aplikacja uruchomiona na telefonie z Androidem (klient) może weryfikować tożsamość interfejsów API Edge (serwer).
Apigee obsługuje również silniejszą formę uwierzytelniania przy użyciu dwukierunkowego (klienta) protokołu TLS. Zwykle wdraża się dwukierunkowe protokół TLS, aby kompleksowo zwiększyć bezpieczeństwo i chronić dane przed atakami klientów, takimi jak podszywanie się pod klientów czy ataki typu „man in the middle”. W przypadku dwukierunkowego protokołu TLS klient weryfikuje tożsamość serwera, a potem serwer weryfikuje tożsamość klienta.
terminologia TLS
Przed skonfigurowaniem protokołu TLS należy zapoznać się z następującymi ważnymi terminami i pojęciami:
|
Termin |
Definicja |
|---|---|
|
Kanada |
Urząd certyfikacji. Zaufany podmiot, taki jak Symantec lub VeriSign, służy do wystawiania certyfikatów i potwierdzania ich autentyczności. Jeden typ certyfikatu, nazywany samodzielnym certyfikatem, 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óry tworzą łańcuch. Ostatni certyfikat pośredni w łańcuchu jest zwykle podpisany przez główny klucz prywatny urzędu certyfikacji. |
|
Przedstawiciel obsługi klienta |
Żądanie podpisania certyfikatu. Żądanie podpisania certyfikatu to plik wygenerowany na serwerze TLS na podstawie klucza prywatnego. Żądanie obsługi klienta 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. Zwykle żądanie podpisania certyfikatu jest generowane w momencie, gdy masz wygasły certyfikat i chcesz go odnowić. |
| DER |
Wyróżniające się reguły kodowania Format DER to binarny certyfikat zamiast formatu ASCII PEM. Czasami ma rozszerzenie .der, ale często .cer. Jedynym sposobem na odróżnienie pliku DER od pliku PEM .cer jest otwarcie go w edytorze tekstu i wyszukanie instrukcji |
| Alias klucza |
Alias klucza jednoznacznie identyfikuje wpis magazynu kluczy (certyfikat TLS i odpowiedni klucz prywatny) w magazynie kluczy.
Gdy prześlesz certyfikat/klucz do magazynów kluczy za pomocą interfejsu użytkownika lub interfejsu API, w Apigee Edge |
|
Magazyn kluczy |
Magazyn kluczy to repozytorium, które zawiera co najmniej 1 certyfikat TLS i odpowiadający mu klucz prywatny, który służy do identyfikowania encji podczas uzgadniania połączenia TLS między klientem a serwerem. W przypadku połączenia northbound router działa jako serwer, a jego certyfikat jest przechowywany w magazynie kluczy w Apigee Edge. W połączeniu southbound procesor wiadomości pełni rolę klienta, a serwer backendu – serwer. 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, a jego rozszerzenie to .p7b lub .p7c. Certyfikaty P7B zawierają instrukcje |
|
PEM |
Format PEM (Privacy Enhanced Mail) to tekstowy format ASCII, który jest kodowaniem Base64 binarnego formatu Distinguished Encoding Rules (DER). Certyfikaty PEM można otwierać w dowolnym edytorze tekstu, a treść certyfikatu jest rozdzielana między instrukcje Jest zgodny ze standardem X.509 służącym do przechowywania certyfikatu, łańcucha certyfikatów lub klucza prywatnego. Jeśli Twój certyfikat lub klucz prywatny nie jest zdefiniowany w pliku PEM, możesz go przekonwertować na plik PEM, korzystając z takich narzędzi jak OpenSSL. |
| PKCS #12/PFX | Format PKCS #12 lub PFX to format binarny służący do przechowywania certyfikatu serwera, 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 i 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. Certyfikat zawiera klucz publiczny. Wszystkie klienty TLS mają kopię klucza publicznego serwera. |
| References | Odwołania zapewniają poziom pośredni w przypadku magazynów kluczy. Z tego względu zmiany magazynu kluczy nie wymagają aktualizacji hosta wirtualnego, o ile zachowasz to samo odwołanie i ten sam alias klucza. Dzięki temu możesz samodzielnie wprowadzać te zmiany i zmniejszyć zależności od zespołu pomocy Apigee. |
|
Certyfikat podpisany samodzielnie |
Certyfikat, który nie jest podpisany przez zaufany urząd certyfikacji. Wydawca i podmiot są identyczne – są podpisane kluczem prywatnym zgodnym z kluczem publicznym, który zawiera. |
|
SNI |
Server Name Indication (Wskazanie nazwy serwera). Umożliwia obsługę wielu celów HTTPS z tego samego adresu IP i tego samego portu bez konieczności używania tego samego certyfikatu w miejscach docelowych. |
|
Certyfikat TLS |
Plik cyfrowy identyfikujący podmiot w transakcji TLS. W zależności od konfiguracji TLS do identyfikacji serwera TLS i klienta TLS może być używany certyfikat lub cert. |
|
Magazyn zaufania |
Zawiera zaufane certyfikaty dla klienta TLS używane do weryfikowania certyfikatu serwera TLS przedstawianego klientowi. Są to zwykle samodzielnie podpisane certyfikaty lub certyfikaty, które nie są podpisane przez zaufany urząd certyfikacji. W przypadku połączenia northbound certyfikaty aplikacji klienckiej są przechowywane w magazynie zaufania w Apigee Edge. Jest to wymagane tylko wtedy, gdy skonfigurowano dwukierunkowy protokół TLS między klientem a Apigee. W przypadku połączenia southbound certyfikaty serwera backendu są przechowywane w magazynie zaufania w Apigee Edge. Jest to wymagane, jeśli chcesz zweryfikować certyfikat backendu w Apigee Edge w jedno- lub dwukierunkowej komunikacji TLS między Apigee Edge a serwerem backendu. Apigee Edge nie ma osobnego obiektu zaufanego magazynu. Dlatego magazyny zaufania są tworzone jako obiekty magazynu kluczy, ale odwołują się do nich wszędzie tam, gdzie jest używany (na przykład w hoście wirtualnym, docelowych punktach końcowych, serwerach docelowych itp.). |
| Host wirtualny |
Host wirtualny reprezentuje punkt końcowy Apigee API dla aplikacji klienckich. Jest to jednostka, która ułatwia hostowanie wielu nazw domen (z osobną obsługą każdej z nich) na jednym serwerze (lub puli serwerów). Dzięki temu jeden serwer może współużytkować swoje zasoby, takie jak cykle pamięci i procesora, bez konieczności używania tej samej nazwy hosta przez wszystkie udostępniane usługi. Host wirtualny może obsługiwać ruch HTTP lub HTTPS (z włączonym protokołem SSL). Host wirtualny z obsługą SSL można skonfigurować w jedno- lub dwukierunkowy tryb TLS. Oto ich konfiguracja:
|
Jednokierunkowa transmisja TLS/SSL
Poniższy rysunek przedstawia uzgadnianie połączenia TLS/SSL w przypadku uwierzytelniania jednokierunkowego między klientem TLS a serwerem TLS:
W jednokierunkowej konfiguracji TLS uzgadnianie połączenia wygląda tak:
- Klient wysyła do serwera żądanie sesji.
- Serwer wysyła w odpowiedzi certyfikat, który zawiera swój 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 zaufania zawierającego certyfikaty serwera i klucze publiczne, aby sprawdzić, czy łańcuch certyfikatów jest podpisany przez zaufany urząd certyfikacji.
- Klient i serwer wymieniają kilka kolejnych wiadomości, aby zweryfikować klucze.
- Klient rozpoczyna przesyłanie danych za pomocą protokołu TLS do serwera.
Poniższy rysunek przedstawia uzgadnianie połączeń TLS/SSL z użyciem opcjonalnego magazynu zaufania w kliencie:
Jeśli serwer TLS używa certyfikatu podpisanego samodzielnie lub niepodpisywanego przez zaufany urząd certyfikacji, musisz utworzyć w kliencie magazyn zaufania. Klient wypełnia swój magazyn zaufania zaufanymi certyfikatami serwera i kluczami publicznymi. Gdy klient otrzyma certyfikat, przychodzący certyfikat jest następnie weryfikowany pod kątem certyfikatów w jego magazynie zaufania.
W przypadku jednokierunkowego protokołu TLS Edge może być serwerem lub klientem w następujący sposób:
-
Zapewnianie dostępu do serwera TLS
Edge to serwer hostujący punkt końcowy TLS, gdzie punkt końcowy TLS odpowiada serwerowi proxy interfejsu API wdrożonemu na hoście wirtualnym. Klient to aplikacja próbująca uzyskać dostęp do serwera proxy interfejsu API. W tym scenariuszu Edge ma magazyn kluczy zawierający certyfikat i klucz prywatny.
-
Korzystaj z ochrony klienta TLS
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. Dlatego serwer backendu ma magazyn kluczy zawierający certyfikat i klucz prywatny.
Dwukierunkowy protokół TLS
Poniższy rysunek przedstawia 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 certyfikat i klucz prywatny, a magazyn kluczy serwera zawiera certyfikat i klucz prywatny.
- Serwer TLS przedstawia swój certyfikat klientowi TLS, aby się uwierzytelnić. Następnie klient weryfikuje tożsamość serwera przed wysłaniem swojego certyfikatu do serwera.
- Klient TLS przedstawia swój certyfikat serwerowi TLS, aby uwierzytelnić się na serwerze.
Poniższy rysunek przedstawia uzgadnianie połączenia TLS z użyciem opcjonalnego magazynu zaufania:
W tym scenariuszu uzgadnianie połączenia wygląda tak:
- Jeśli serwer TLS korzysta z certyfikatu podpisanego samodzielnie lub niepodpisanego przez zaufany urząd certyfikacji, w kliencie utworzysz magazyn zaufania. Klient ma kopię certyfikatu serwera w magazynie zaufanych. Podczas uzgadniania połączenia TLS klient porównuje certyfikat w swoim magazynie zaufania z certyfikatem wysłanym z serwera, aby zweryfikować tożsamość serwera.
- Jeśli klient TLS korzysta z certyfikatu podpisanego samodzielnie lub niepodpisanego przez zaufany urząd certyfikacji, musisz utworzyć magazyn zaufania na serwerze.Na serwerze znajduje się kopia certyfikatu klienta w swoim magazynie zaufania. Podczas uzgadniania połączenia TLS serwer porównuje certyfikat w swoim magazynie zaufania z certyfikatem wysłanym przez klienta, aby zweryfikować tożsamość klienta.
Klient lub serwer może używać magazynu zaufania.
W przypadku dwukierunkowego protokołu TLS Edge może być serwerem lub klientem w następujący sposób:
-
Zapewnianie dostępu do serwera
Edge to serwer hostujący punkt końcowy TLS, gdzie punkt końcowy TLS odpowiada serwerowi proxy interfejsu API. Klient to aplikacja próbująca 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 i łańcuch urzędów certyfikacji klienta.
-
Zgłębiaj kwestie w roli klienta
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 magazyn kluczy zawierający certyfikat i klucz prywatny.
Edge musi też zdefiniować magazyn kluczy zawierający certyfikat niezbędny do weryfikacji w usłudze backendu oraz opcjonalnie magazyn zaufania zawierający certyfikat z 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 na tyle elastyczne, aby obsługiwać dwukierunkowe protokół TLS, niezależnie od tego, jak go skonfigurujesz.
Obsługa SNI
Edge obsługuje korzystanie z serwerów proxy interfejsu API do Edge, gdzie Edge działa jako serwer TLS oraz od Edge do docelowych punktów końcowych, gdzie Edge działa jako klient TLS zarówno w instalacjach Cloud, jak i Private Cloud.
Za pomocą SNI, który jest rozszerzeniem protokołu TLS/SSL, można udostępniać wiele celów HTTPS z tego samego adresu IP i portu bez konieczności używania tego samego certyfikatu w miejscach docelowych.
Informacje na temat włączania SNI dla instalacji lokalnej znajdziesz w artykule o używaniu SNI z Edge.
W kierunku północnym i południowym
W Apigee kierowanie na północ odnosi się do punktu końcowego interfejsu API używanego przez aplikacje klienckie do wywoływania serwera proxy interfejsu API. Zwykle router jest punktem wejścia w Apigee Edge i obsługuje przychodzące żądania do Apigee Edge. Dlatego w Apigee punkt końcowy używany do komunikacji między aplikacją kliencką a Apigee Edge (router) jest nazywany northbound.
W Apigee granica południowa 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 (przetwarzający wiadomości) a serwerem backendu jest nazywany southbound. Procesor wiadomości jest komponentem Apigee Edge, który przekierowuje żądania interfejsu API do serwerów docelowych backendu.
Na rysunku poniżej przedstawiono połączenia w kierunku północnym i południowym dla Apigee Edge:
