Przewodnik po konfiguracji PCI dla Edge Public Cloud

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
Informacje

Aby klient był zgodny z PCI w Apigee Edge Public Cloud, musi mieć pewne działania i procesy w ramach „modelu współdzielonej odpowiedzialności”. Poniższe elementy powinny zostać sprawdzone przez klientów, którzy kupili pakiet zgodności z PCI i muszą spełniać wymagania PCI. Te elementy są samoobsługowe w Edge i muszą być zaadresowane, aby organizacja klienta (organizacja) była zgodna z PCI. Nadrzędna koncepcja brzmi: „Google zabezpiecza platformę, a klient chroni swoje dane”.

Struktura odpowiedzialności klienta

Przeprowadzając audyt PCI, klienci powinni skorzystać z Matrix odpowiedzialności Google Apigee PCI-DSS 3.2.1 i udostępnić te informacje swojemu specjaliście ds. bezpieczeństwa PCI.

Mapowanie wymagań PCI

Wymóg PCI Section
Wymaganie 7. Ogranicz dostęp do danych posiadacza karty w zależności od potrzeb biznesowych

Użycie/autoryzacje

Wymóg 3. Ochrona przechowywanych danych posiadacza karty

Maskowanie danych

Wymóg 10. Monitoruj i monitoruj cały dostęp do zasobów sieciowych i danych posiadacza karty

Rejestr kontrolny

Wymaganie 8. Przypisz unikalny identyfikator każdej osobie mającej dostęp do komputera

Złożone wymagania dotyczące haseł lub SAML

Wymóg 11. Regularne testowanie systemów i procesów zabezpieczeń

Skanowanie punktów końcowych

Wymóg 4. Zaszyfruj transmisję danych posiadacza karty w otwartych sieciach publicznych

Konfiguracja TLS

Wymóg 3. Ochrona przechowywanych danych posiadacza karty

Przechowywanie danych

Wymóg 4. Zaszyfruj transmisję danych posiadacza karty w otwartych sieciach publicznych

Szyfrowanie danych

Aby uzyskać certyfikat zgodności ze standardem PCI Data Security (AOC), prześlij zgłoszenie do zespołu pomocy Apigee lub skontaktuj się z zespołem sprzedaży Apigee.

Śledzenie / debugowanie

Trace/Debugowanie to narzędzie do rozwiązywania problemów, które umożliwia użytkownikowi wyświetlanie stanu i treści wywołania interfejsu API podczas przetwarzania przez procesor wiadomości Apigee. Trace i Debugowanie to 2 nazwy tej samej usługi, do których dostęp mają różne mechanizmy. Trace to nazwa tej usługi w interfejsie użytkownika Edge. Debugowanie to nazwa usługi użytej w wywołaniach interfejsu API. Terminy „Trace” możesz w tym dokumencie używać zarówno w ramach śledzenia, jak i debugowania.

Podczas sesji śledzenia wymuszane jest „maskowanie danych”. To narzędzie może zablokować wyświetlanie danych podczas śledzenia. Przeczytaj sekcję Maskowanie danych poniżej.

W przypadku klientów korzystających z PCI można używać zaszyfrowanych map wartości klucza (KVM). Jeśli używana jest szyfrowana maszyna wirtualna, można nadal korzystać z systemu Trace, ale niektóre zmienne nie będą widoczne na ekranie wyświetlania logu czasu. Możesz wykonać dodatkowe czynności, aby wyświetlić te zmienne w logu czasu.

Szczegółowe instrukcje dotyczące korzystania z narzędzia Trace znajdziesz na stronie Korzystanie z narzędzia do śledzenia.

Szczegółowe informacje na temat KVM, w tym zaszyfrowanych KVM, znajdziesz w artykule Praca z mapami par klucz-wartość (w języku angielskim).

Użytkowanie/autoryzacje

Dostępem do usługi Trace zarządza system RBAC (kontrola dostępu opartego na rolach) dla kont użytkowników w Edge. Szczegółowe instrukcje dotyczące używania systemu RBAC do przyznawania i anulowania uprawnień do śledzenia znajdują się w sekcjach Przypisywanie ról i Tworzenie ról niestandardowych w interfejsie. Uprawnienia do śledzenia pozwalają użytkownikowi uruchomić śledzenie, zatrzymać śledzenie i uzyskać dostęp do danych wyjściowych z sesji śledzenia.

Usługa Trace ma dostęp do ładunku wywołań interfejsu API (nazywanych wcześniej „treścią wiadomości”), dlatego należy zastanowić się, kto ma dostęp do uruchomienia logu czasu. Ponieważ za zarządzanie użytkownikami spoczywa obowiązek klienta, za przyznanie uprawnień do śledzenia również należy klient. Apigee, jako właściciel platformy, może dodawać użytkownika do organizacji klienta i przypisywać uprawnienia. Ta możliwość jest używana tylko na prośbę klienta o pomoc, gdy wydaje się, że usługa działa zawodowo i uznajemy, że weryfikacja sesji śledzenia zapewnia najlepsze informacje na temat głównej przyczyny.

Maskowanie danych

Maskowanie danych zapobiega wyświetlaniu danych wrażliwych tylko w trakcie sesji śledzenia i debugowania, zarówno w interfejsie Trace (interfejsie Edge), jak i w backendzie za pomocą debugowania (Edge API). Szczegółowe informacje o konfigurowaniu maskowania znajdziesz w artykule Maskowanie i ukrywanie danych. Maskowanie danych wrażliwych jest częścią wymogu PCI 3 – ochrony przechowywanych danych posiadacza karty

Maskowanie danych NIE zapobiega ich wyświetlaniu w plikach logów, pamięci podręcznej, statystykach itp. Aby uzyskać pomoc dotyczącą maskowania danych w logach, możesz dodać do pliku logback.xml wzorzec wyrażenia regularnego. Dane poufne zwykle nie powinny być zapisywane w pamięci podręcznej lub analiz bez solidnego uzasadnienia biznesowego i sprawdzenia przez zespoły prawne oraz zespoły ds. bezpieczeństwa klienta.

Pamięć podręczna L1 i L2

Pamięć podręczna jest dostępna dla klientów PCI tylko na potrzeby danych nieregulowanych. Z pamięci podręcznej nie należy korzystać w przypadku danych posiadacza karty PCI (CHD). Nie została ona zatwierdzona przez kontrolę zgodności Apigee PCI jako lokalizacja pamięci masowej CHD. Zgodnie ze wskazówkami PCI (wymaganie 3: ochrona przechowywanych danych posiadacza karty) dane PCI powinny być przechowywane tylko w miejscu zgodnym z PCI. Użycie pamięci podręcznej L1 automatycznie korzysta też z pamięci podręcznej L2. Pamięć podręczna L1 działa tylko w pamięci, podczas gdy pamięć podręczna L2 zapisuje dane na dysku, aby zsynchronizować je w wielu pamięciach podręcznych L1. Pamięć podręczna L2 umożliwia synchronizację wielu procesorów wiadomości w regionie i globalnie. Obecnie nie można włączyć pamięci podręcznej L1 bez pamięci podręcznej L2. Pamięć podręczna L2 zapisuje dane na dysku, tak aby można je było zsynchronizować z innymi procesorami wiadomości w organizacji klienta. Ponieważ pamięć podręczna L2 zapisuje dane na dysku, nie jest obsługiwane używanie pamięci podręcznej na potrzeby CHD ani innych danych objętych ograniczeniami.

Klienci mogą korzystać z pamięci podręcznej w przypadku danych innych niż CHD i innych nieobjętych ograniczeniami. Domyślnie nie wyłączamy pamięci podręcznej u klientów PCI, ponieważ niektórzy z nich wykonują w jednej organizacji wywołania interfejsu API zarówno PCI, jak i niezwiązane z PCI. Ponieważ ta funkcja jest nadal włączona dla klientów PCI, obowiązkiem klienta jest odpowiednie korzystanie z usługi oraz przeszkolenie użytkowników, aby nie korzystali z pamięci podręcznej, gdy dane PCI prawdopodobnie będą zawarte w wywołaniu interfejsu API. Kontrola zgodności Apigee z PCI nie obsługuje CHD przechowywanych w pamięci podręcznej.

Szczegółowe instrukcje na temat korzystania z pamięci podręcznej znajdziesz w artykule Dodawanie pamięci podręcznej i trwałości.

Rejestr kontrolny

Klienci mogą przeglądać rejestr kontrolny wszystkich działań administracyjnych w organizacji klienta, w tym korzystania z usługi Trace. Szczegółowe instrukcje znajdziesz tutaj oraz w artykule Korzystanie z narzędzia do śledzenia. Wymóg PCI 10. Śledź i monitoruj cały dostęp do zasobów sieciowych i danych posiadacza karty

Złożone wymagania dotyczące haseł lub SAML

Klienci z określonymi wymaganiami dotyczącymi hasła powinni używać SAML, aby spełnić indywidualne wymagania dotyczące hasła. Zobacz Włączanie uwierzytelniania SAML dla przeglądarki Edge. Edge udostępnia też uwierzytelnianie wielopoziomowe (wymagania PCI 8: przypisz unikalny identyfikator każdej osobie mającej dostęp do komputera). Zobacz Włączanie uwierzytelniania dwuskładnikowego na koncie Apigee.

Zabezpieczenia punktów końcowych

Skanowanie punktów końcowych

Skanowanie i testowanie hostów jest wymagane pod kątem zgodności z PCI (wymóg 11. Regularne testowanie systemów i procesów zabezpieczeń). W przypadku Edge Cloud klienci są odpowiedzialni za skanowanie i testowanie punktów końcowych interfejsu API (czasami nazywanych „komponentami środowiska wykonawczego”) w Edge. Testy klientów powinny obejmować rzeczywiste usługi proxy interfejsu API hostowane na serwerach brzegowych, w których ruch z interfejsu API jest przesyłany do Edge przed przetworzeniem, a następnie przekazanie do centrum danych klienta. Testowanie udostępnionych zasobów, takich jak interfejs portalu zarządzania, nie jest zatwierdzone w przypadku klientów indywidualnych (raport zewnętrzny dotyczący testowania udostępnianych usług jest dostępny dla klientów na mocy umowy o nieujawnianiu informacji oraz na żądanie).

Klienci powinni przetestować punkty końcowe interfejsu API i zachęcamy ich do tego. Twoja umowa z Apigee nie zabrania testowania punktów końcowych interfejsu API, ale nie zezwalamy na testowanie interfejsu zarządzania współdzielonym. Jeśli potrzebujesz dodatkowych wyjaśnień, prześlij prośbę o pomoc dotyczącą planowanego testowania. Przekazujemy do Apigee z wyprzedzeniem powiadomienie o ruchu testowym.

Klienci testujący punkty końcowe powinni poszukać problemów z interfejsami API i usług Apigee, a także sprawdzić protokół TLS i inne elementy konfigurowalne. Wszystkie elementy powiązane z usługami Apigee należy przekazać do Apigee za pomocą prośby o pomoc.

Większość elementów powiązanych z punktem końcowym to elementy samoobsługowe klienta i można je naprawić, zapoznając się z dokumentacją Edge. Jeśli w przypadku niektórych elementów nie wiesz, jak je poprawić, skontaktuj się z zespołem pomocy.

Konfiguracja TLS

Zgodnie ze standardami PCI SSL i wczesnej wersji TLS trzeba przenieść do wersji zabezpieczonych. Klienci są odpowiedzialni za definiowanie i konfigurowanie własnych punktów końcowych TLS dla serwerów proxy interfejsów API. To jest funkcja samoobsługowa w Edge. Wymagania klientów dotyczące szyfrowania, protokołu i algorytmu są bardzo zróżnicowane i zależą od konkretnych przypadków użycia. Apigee nie zna szczegółów projektu i ładunków danych interfejsu API każdego klienta, dlatego klienci są odpowiedzialni za określenie odpowiedniego szyfrowania danych przesyłanych. Szczegółowe instrukcje dotyczące konfiguracji TLS są dostępne na stronie TLS/SSL.

Miejsce na dane

Przechowywanie danych w Edge nie jest wymagane do prawidłowego działania Edge. Istnieją jednak usługi przechowywania danych na serwerach brzegowych. Klienci mogą do przechowywania danych używać pamięci podręcznej, map par klucz-wartość lub usług analitycznych. Według audytu PCI Apigee żadna z tych usług nie jest uprawniona do przechowywania CHD. Zgodnie z wymogiem PCI 3 (Ochrona przechowywanych danych posiadacza karty) dane PCI powinny być przechowywane tylko w lokalizacjach zgodnych z normą PCI. Z tych usług mogą korzystać klienci w celu przechowywania danych innych niż PCI lub innych danych nieograniczonych, z zastrzeżeniem wymogów bezpieczeństwa i wymagań prawnych klienta. Te usługi są elementami samoobsługowymi klienta, więc obowiązkiem klienta jest skonfigurowanie ich w taki sposób, aby nie przechwytywały ani nie zapisywały CHD. Sprawdzenie konfiguracji, zasad i wdrożeń przez administratorów klientów zaleca się uniknąć przypadkowego lub szkodliwego wykorzystania usług przechowywania danych w Edge w sposób niezgodny z zasadami .

Szyfrowanie danych

Narzędzia do szyfrowania danych nie są udostępniane klientom w Edge. Klienci mogą jednak szyfrować dane PCI przed przesłaniem ich do Edge. Wymóg PCI 4. (Szyfruj transmisję danych posiadacza karty w otwartych, publicznych sieciach) zalecamy szyfrowanie danych posiadacza karty w otwartych, publicznych sieciach. Zaszyfrowane dane w ładunku (lub treści wiadomości) nie uniemożliwiają działania Edge. Niektóre zasady Edge mogą nie mieć możliwości interakcji z danymi, jeśli zostaną one zaszyfrowane przez klienta. Na przykład przekształcenie nie jest możliwe, jeśli Edge nie ma możliwości zmiany samych danych. Inne zasady oraz zasady i pakiety utworzone przez klienta będą jednak działać nawet wtedy, gdy ładunek danych będzie zaszyfrowany.