Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Protokół Transport Layer Security (TLS), którego poprzednikiem jest Secure Sockets Layer (SSL), to standardowa technologia zabezpieczeń służąca do nawiązywania zaszyfrowanego połączenia między serwerem WWW a klientem WWW, takim jak przeglądarka lub aplikacja. Zaszyfrowane połączenie zapewnia, że wszystkie dane przesyłane między serwerem a klientem pozostają prywatne. Aby korzystać z TLS, klient wysyła bezpieczne żądanie do serwera, używając szyfrowanego protokołu HTTPS zamiast niezaszyfrowanego protokołu HTTP.
Edge obsługuje szyfrowanie TLS w jednym i obu kierunkach zarówno w rozwiązaniu wdrożonym lokalnie, jak i w chmurze (obsługiwane wersje TLS znajdziesz w sekcji Obsługiwane oprogramowanie i wersje). TLS w jednym kierunku 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ż mocniejszą formę uwierzytelniania za pomocą dwukierunkowego protokołu TLS. Zwykle wdrażasz dwukierunkowy TLS, aby zwiększyć bezpieczeństwo na wszystkich poziomach i chronić swoje dane przed atakami na klienta, takimi jak podszywanie się pod klienta lub ataki typu „człowiek w środku”. W przypadku dwukierunkowego 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 |
|---|---|
|
Kalifornia |
Urząd certyfikacji. zaufany podmiot, np. Symantec lub VeriSign, używany do wydawania certyfikatów i weryfikowania ich autentyczności; Jeden typ certyfikatu, zwany podpisem własnym, nie wymaga urzędu certyfikacji. |
|
Łańcuch certyfikatów |
Często nie masz certyfikatu podpisanego kluczem prywatnym głównego urzędu certyfikacji. Zamiast tego masz certyfikat wraz z co najmniej jednym certyfikatem pośrednim, które tworzą łańcuch. Ostatni pośredni certyfikat w łańcuchu jest zwykle podpisany kluczem prywatnym głównego urzędu certyfikacji. |
|
CSR |
Żądanie podpisania certyfikatu. CSR to plik wygenerowany na serwerze TLS na podstawie klucza prywatnego. CSR zawiera klucz publiczny i inne informacje, takie jak nazwa organizacji, lokalizacja i nazwa domeny. Urząd certyfikacji podpisuje żądanie certyfikatu, aby utworzyć certyfikat TLS. Zazwyczaj generujesz CSR, gdy masz wygasły certyfikat i chcesz go odnowić. |
| DER |
Wyróżniające się reguły kodowania. Format DER to binarna forma certyfikatu zamiast formatu ASCII PEM. Czasami ma rozszerzenie .der, ale często .cer. Jedynym sposobem na odróżnienie pliku DER .cer od pliku PEM .cer jest otwarcie pliku w edytorze tekstu i sprawdzenie, czy znajdują się w nim instrukcje |
| Alias klucza |
Alias klucza jednoznacznie identyfikuje wpis w magazynie kluczy (certyfikat TLS i odpowiadający mu klucz prywatny) w magazynie kluczy.
W Apigee Edge |
|
Keystore |
Sklep z kluczami to repozytorium zawierające co najmniej jeden certyfikat TLS i odpowiadający mu klucz prywatny, który służy do identyfikowania podmiotu podczas uzgadniania połączenia TLS między klientem a serwerem. W przypadku połączenia północnego router działa jako serwer, a jego certyfikat jest przechowywany w magazynie kluczy w Apigee Edge. W przypadku połączenia southbound procesor wiadomości działa jako klient, a serwer backendu jako 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 i ma rozszerzenie .p7b lub .p7c. Certyfikaty P7B zawierają oświadczenia |
|
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 otworzyć w dowolnym edytorze tekstu, a rzeczywista treść certyfikatu jest ograniczona między 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ć do pliku PEM za pomocą takich narzędzi jak OpenSSL. |
| PKCS #12/PFX | Format PKCS #12 lub PFX to format binarny służący do przechowywania certyfikatu serwera, wszelkich 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. Klucz prywatny ma tylko serwer TLS. 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ą pewien poziom pośrednictwa w przypadku repozytoriów kluczy, dlatego zmiany w repozytorium kluczy nie wymagają aktualizacji hosta wirtualnego, o ile nie zmieni się odwołanie ani alias klucza. Dzięki temu możesz samodzielnie wprowadzać te zmiany i zmniejszać zależność od zespołu pomocy Apigee. |
|
Certyfikat z podpisem własnym |
certyfikat, który nie jest podpisany przez zaufany urząd certyfikacji; Wystawca i podmiot są identyczne; są one podpisane kluczem prywatnym, który odpowiada kluczowi publicznemu. |
|
SNI |
Wskazanie nazwy serwera. Umożliwia obsługę wielu celów HTTPS przy użyciu tego samego adresu IP i portu bez konieczności używania przez te cele tego samego certyfikatu. |
|
Certyfikat TLS |
Plik cyfrowy, który identyfikuje podmiot w transakcji TLS. Certyfikat (cert) może być używany do identyfikowania serwera TLS i klienta TLS w zależności od konfiguracji TLS. |
|
Truststore |
Zawiera zaufane certyfikaty klienta TLS używane do weryfikacji 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 z wyjścia certyfikaty aplikacji klienta są przechowywane w magazynie zaufania w Apigee Edge. Jest to wymagane tylko wtedy, gdy skonfigurowano dwukierunkowe szyfrowanie TLS między klientem a Apigee. W przypadku połączenia na południe certyfikaty serwera zaplecza są przechowywane w magazynie zaufania w Apigee Edge. Jest to wymagane, jeśli chcesz zweryfikować certyfikat backendu w Apigee Edge w ramach komunikacji jednokierunkowej lub dwukierunkowej TLS między Apigee Edge a serwerem backendu. Apigee Edge nie ma osobnego obiektu repozytorium zaufania. Dlatego repozytoria zaufania są tworzone jako obiekty repozytorium kluczy, ale są odwoływane jako repozytorium zaufania w miejscach ich użycia (na przykład w przypadku hosta wirtualnego, docelowych punktów końcowych, serwerów docelowych itp.). |
| Wirtualny gospodarz |
Host wirtualny reprezentuje punkt końcowy interfejsu API Apigee dla aplikacji klienckich. Jest to element, który ułatwia hostowanie wielu nazwy domen (z osobnym obsługą każdej nazwy) na jednym serwerze (lub puli serwerów). Umożliwia to udostępnianie zasobów, takich jak pamięć i cykle procesora, przez jeden serwer 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). Host wirtualny obsługujący protokół SSL może być skonfigurowany w trybie jednokierunkowego lub dwukierunkowego TLS. Jest on skonfigurowany z użyciem tych elementów:
|
Jednokierunkowy TLS/SSL
Poniższy rysunek przedstawia uzgadnianie TLS/SSL w ramach uwierzytelniania jednokierunkowego między klientem TLS a serwerem TLS:
W konfiguracji TLS w jednym kierunku uzgadnianie połączenia przebiega w ten sposób:
- Klient wysyła żądanie sesji do serwera.
- Serwer odpowiada certyfikatem zawierającym klucz publiczny. Ten certyfikat pochodzi z magazynu kluczy serwera, który zawiera również klucz prywatny serwera. Klucz prywatny nigdy nie jest wysyłany do klienta.
- W przypadku podpisanego certyfikatu klient używa zaufanej pamięci podręcznej zawierającej certyfikaty serwera i klucze publiczne, aby sprawdzić, czy łańcuch certyfikatów został podpisany przez zaufany urząd certyfikacji (CA).
- Klient i serwer wymieniają się jeszcze kilkoma wiadomościami, aby zweryfikować klucze.
- Klient rozpoczyna przesyłanie danych TLS z serwerem.
Rysunek poniżej przedstawia proces nawiązywania połączenia TLS/SSL przy użyciu opcjonalnego repozytorium zaufania na kliencie:
Jeśli serwer TLS używa samodzielnie podpisanego certyfikatu lub certyfikatu, który nie jest podpisany przez zaufany urząd certyfikacji, utwórz magazyn zaufania na kliencie. Klient wypełnia swój magazyn zaufania certyfikatami serwera i kluczami publicznymi, którym ufa. Gdy klient otrzyma certyfikat, przychodzący certyfikat jest weryfikowany na podstawie certyfikatów w jego zaufanej pamięci.
W przypadku szyfrowania po stronie serwera Edge może być serwerem lub klientem w następujący sposób:
-
Edge jako serwer TLS
Edge to serwer hostujący punkt końcowy TLS, gdzie punkt końcowy TLS odpowiada serwerowi proxy API wdrożonemu na hoście wirtualnym. Klient to 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 działa jako klient, który uzyskuje dostęp do usługi backendowej. W tym przypadku usługa backendu odpowiada serwerowi, na którym działa punkt końcowy TLS. Dlatego serwer zaplecza ma magazyn kluczy zawierający certyfikat i klucz prywatny.
Dwukierunkowe uwierzytelnianie TLS
Poniższy rysunek przedstawia proces nawiązywania połączenia TLS/SSL w ramach uwierzytelniania dwustronnego TLS między klientem a serwerem:
W przypadku dwukierunkowego 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 certyfikat i klucz prywatny.
- Serwer TLS przedstawia swój certyfikat klientowi TLS, aby uwierzytelnić się. Następnie klient weryfikuje tożsamość serwera, zanim wyśle certyfikat na serwer.
- Klient TLS przedstawia swój certyfikat serwerowi TLS, aby uwierzytelnić się na serwerze.
Rysunek poniżej przedstawia uzgadnianie połączenia TLS z użyciem opcjonalnego repozytorium zaufania:
W tym scenariuszu proces uzgadniania wygląda tak:
- Jeśli serwer TLS używa samodzielnie podpisanego certyfikatu lub certyfikatu, który nie został podpisany przez zaufany urząd certyfikacji, utwórz magazyn zaufania na kliencie. Klient ma kopię certyfikatu serwera w swoim magazynie zaufania. Podczas uzgadniania połączenia TLS klient porównuje certyfikat w swoim repozytorium 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 został podpisany przez zaufany urząd certyfikacji, należy utworzyć magazyn zaufania na serwerze.Serwer ma kopię certyfikatu klienta w swoim magazynie zaufania. Podczas nawiązywania połączenia TLS serwer porównuje certyfikat w swoim magazynie zaufania z certyfikatem wysłanym przez klienta, aby zweryfikować tożsamość klienta.
Zaufany magazyn kluczy może być używany przez klienta, serwer lub oba te urządzenia.
W przypadku dwukierunkowego TLS Edge może być serwerem lub klientem w następujący sposób:
-
Edge jako serwer
Edge to serwer hostujący punkt końcowy TLS, gdzie punkt końcowy TLS odpowiada serwerowi proxy interfejsu API. Klient to 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 zaufania 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 backendowej. W tym przypadku usługa backendu odpowiada serwerowi, na którym znajduje się punkt końcowy TLS. Dlatego serwer backendowy ma magazyn kluczy zawierający certyfikat i klucz prywatny.
Edge musi też zdefiniować magazyn kluczy zawierający certyfikat potrzebny do weryfikacji siebie w usłudze zaplecza oraz opcjonalnie magazyn zaufania zawierający certyfikat z serwera zaplecza, jeśli serwer używa certyfikatu podpisanego samodzielnie lub certyfikatu, który nie został podpisany przez zaufany urząd certyfikacji.
Pamiętaj, że Edge jest na tyle elastyczny, że obsługuje dwukierunkowy TLS niezależnie od tego, jak go skonfigurujesz.
Obsługa SNI
Edge obsługuje użycie Server Name Indication (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.
Dzięki SNI, które jest rozszerzeniem TLS/SSL, wiele docelowych adresów HTTPS może być obsługiwanych za pomocą tego samego adresu IP i portu bez konieczności używania tych samych certyfikatów.
Informacje o włączaniu SNI w przypadku instalacji lokalnej znajdziesz w artykule Korzystanie z protokołu SNI w Edge.
W kierunku północnym i południowym
W Apigee termin „północny” odnosi się do punktu końcowego interfejsu API używanego przez aplikacje klienckie do wywoływania proxy interfejsu API. Router jest zwykle punktem wejścia w usłudze Apigee Edge i obsługuje żądania przychodzące do Apigee Edge. Dlatego w usłudze Apigee punkt końcowy używany do komunikacji między aplikacją klienta a Apigee Edge (Router) jest nazywany północny.
W Apigee termin „southbound” odnosi się do docelowego punktu końcowego, którego Apigee używa do komunikacji z serwerem backendowym. Dlatego w Apigee punkt końcowy używany do komunikacji między Apigee Edge (procesorem wiadomości) a serwerem backendu jest określany jako southbound (w kierunku serwera). Przetwarzanie wiadomości to komponent Apigee Edge, który pośredniczy w przesyłaniu żądań interfejsu API do serwerów docelowych w systemie backendu.
Poniższy rysunek przedstawia połączenia Apigee Edge w kierunku północnym i południowym:
