Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info
Aby klient korzystający z Apigee Edge w chmurze publicznej spełniał wymagania PCI, musi podjąć pewne działania i wdrożyć procesy w ramach „Modelu odpowiedzialności współdzielonej”. Poniższe elementy powinni sprawdzić klienci, którzy kupili pakiet zgodności z normą PCI i muszą spełniać wymagania tej normy. Te elementy są dostępne w ramach samodzielnej obsługi w Edge i muszą zostać rozwiązane, aby organizacja klienta była zgodna ze standardem PCI. Ogólna koncepcja brzmi: „Google zabezpiecza platformę, a klient zabezpiecza swoje dane”.
Macierz odpowiedzialności klienta
Klienci powinni zapoznać się z dokumentem Google Cloud Platform: PCI DSS w wersji 4.0.1 – macierz wspólnej odpowiedzialności i udostępnić go certyfikowanemu biegłemu ds. bezpieczeństwa (Qualified Security Assessor, QSA) podczas przeprowadzania własnego audytu PCI.
Mapowanie wymagań PCI
| Wymagania PCI | Sekcja |
|---|---|
| Wymaganie 7. Ograniczanie dostępu do komponentów systemu i danych posiadacza karty na podstawie zasady „musisz wiedzieć” | |
| Wymaganie 3. Ochrona przechowywanych danych na koncie | |
| Wymaganie 10. Rejestrowanie i monitorowanie całego dostępu do komponentów systemu i danych posiadacza karty | |
| Wymaganie 8. Identyfikowanie użytkowników i uwierzytelnianie dostępu do komponentów systemu | |
| Wymaganie 11. Regularnie testuj bezpieczeństwo systemów i sieci | |
| Wymaganie 4. Chroń dane posiadacza karty za pomocą silnej kryptografii podczas przesyłania ich przez otwarte sieci publiczne. | |
| Wymaganie 3. Ochrona przechowywanych danych na koncie | |
| Wymaganie 4. Chroń dane posiadacza karty za pomocą silnej kryptografii podczas przesyłania ich przez otwarte sieci publiczne. |
Aby uzyskać certyfikat zgodności z normą PCI Data Security Standard (AOC), otwórz zgłoszenie do zespołu pomocy Apigee lub skontaktuj się z zespołem sprzedaży Apigee.
Śledzenie / debugowanie
Śledzenie/debugowanie to narzędzie do rozwiązywania problemów, które umożliwia użytkownikowi wyświetlanie stanu i zawartości wywołania interfejsu API podczas jego przetwarzania przez procesor komunikatów Apigee. Śledzenie i debugowanie to 2 nazwy tej samej usługi, ale dostęp do niej uzyskuje się za pomocą różnych mechanizmów. Trace to nazwa tej usługi w interfejsie Edge. Debug to nazwa tej samej usługi, gdy jest używana w wywołaniach interfejsu API. Użycie terminu „ślad” w tym dokumencie jest prawidłowe zarówno w przypadku śladu, jak i debugowania.
Podczas sesji śledzenia obowiązuje „Maskowanie danych”. To narzędzie może blokować wyświetlanie danych podczas śledzenia. Więcej informacji znajdziesz w sekcji Maskowanie danych poniżej.
Klienci, którzy muszą spełniać wymagania PCI, mogą używać zaszyfrowanych map klucz-wartość. Jeśli używasz zaszyfrowanego przełącznika KVM, możesz nadal korzystać z funkcji Trace, ale niektóre zmienne nie będą widoczne na ekranie Trace. Możesz wykonać dodatkowe czynności, aby wyświetlać te zmienne podczas śledzenia.
Szczegółowe instrukcje korzystania z narzędzia Trace znajdziesz w artykule Korzystanie z narzędzia Trace.
Szczegółowe informacje o mapach par klucz-wartość, w tym o zaszyfrowanych mapach par klucz-wartość, znajdziesz w artykule Praca z mapami par klucz-wartość.
Użycie/autoryzacje
Dostęp do narzędzia Trace jest zarządzany przez system RBAC (kontrola dostępu oparta na rolach) dla kont użytkowników w Edge. Szczegółowe instrukcje dotyczące używania systemu RBAC do przyznawania i odbierania uprawnień do śledzenia znajdziesz w artykułach Przypisywanie ról i Tworzenie ról niestandardowych w interfejsie. Uprawnienia śledzenia umożliwiają użytkownikowi uruchamianie i zatrzymywanie śledzenia oraz uzyskiwanie dostępu do danych wyjściowych z sesji śledzenia.
Trace ma dostęp do ładunku wywołań interfejsu API (formalnie nazywanego „treścią wiadomości”), dlatego ważne jest, aby zastanowić się, kto ma uprawnienia do uruchamiania Trace. Zarządzanie użytkownikami jest obowiązkiem klienta, dlatego przyznawanie uprawnień do śledzenia również należy do jego obowiązków. Apigee jako właściciel platformy ma możliwość dodania użytkownika do organizacji klienta i przypisania mu uprawnień. Ta funkcja jest używana tylko na prośbę klienta o pomoc w sytuacji, w której obsługa klienta nie działa prawidłowo, a przeanalizowanie sesji śledzenia może dostarczyć najlepszych informacji o przyczynie problemu.
Maskowanie danych
Maskowanie danych zapobiega wyświetlaniu danych wrażliwych tylko podczas sesji śledzenia/debugowania, zarówno w śledzeniu (interfejs Edge), jak i na backendzie przez debugowanie (interfejs Edge API). Szczegółowe informacje o konfigurowaniu maskowania znajdziesz w artykule Maskowanie i ukrywanie danych. Maskowanie danych wrażliwych jest częścią wymagania 3 standardu PCI – ochrona przechowywanych danych posiadacza karty.
Maskowanie danych NIE zapobiega wyświetlaniu danych w plikach dziennika, pamięci podręcznej, statystykach itp. Aby uzyskać pomoc dotyczącą maskowania danych w logach, rozważ dodanie wzorca wyrażenia regularnego do pliku logback.xml. Wrażliwych danych nie należy zwykle zapisywać w pamięci podręcznej ani w usługach analitycznych bez uzasadnienia biznesowego i sprawdzenia przez zespoły ds. bezpieczeństwa i prawne klienta.
Pamięć podręczna L1 i L2
Pamięć podręczna jest dostępna dla klientów spełniających wymagania PCI i może być używana tylko w przypadku danych niepodlegających regulacjom. Pamięci podręcznej nie należy używać do przechowywania danych posiadacza karty PCI (CHD). Nie jest ona zatwierdzona przez audyt zgodności z PCI Apigee jako miejsce przechowywania danych CHD. Zgodnie z wytycznymi PCI (wymaganie 3: chroń przechowywane dane posiadacza karty) dane PCI powinny być przechowywane tylko w miejscu zgodnym z PCI. Korzystanie z pamięci podręcznej poziomu 1 automatycznie powoduje też korzystanie z pamięci podręcznej poziomu 2. Pamięć podręczna L1 to „tylko pamięć”, a pamięć podręczna L2 zapisuje dane na dysku, aby synchronizować je z wieloma pamięciami podręcznymi L1. Pamięć podręczna L2 zapewnia synchronizację wielu procesorów wiadomości w regionie i na całym świecie. 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, aby można je było zsynchronizować z innymi procesorami wiadomości w organizacji klienta. Ponieważ pamięć podręczna poziomu 2 zapisuje dane na dysku, używanie pamięci podręcznej w przypadku danych CHD lub innych danych podlegających ograniczeniom nie jest obsługiwane.
Klienci mogą korzystać z pamięci podręcznej w przypadku danych innych niż CHD i innych danych nieobjętych ograniczeniami. Domyślnie nie wyłączamy pamięci podręcznej w przypadku klientów, którzy podlegają standardowi PCI, ponieważ niektórzy z nich wykonują wywołania interfejsu API związane i niezwiązane z tym standardem w ramach jednej organizacji. Funkcja jest nadal włączona dla klientów korzystających z PCI, dlatego to oni ponoszą odpowiedzialność za właściwe korzystanie z usługi i szkolenie użytkowników w zakresie nieużywania pamięci podręcznej, gdy w wywołaniu interfejsu API mogą znajdować się dane PCI. Audyt zgodności Apigee z PCI nie obsługuje danych CHD przechowywanych w pamięci podręcznej.
Szczegółowe instrukcje 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 wykonywanych w organizacji klienta, w tym korzystania z narzędzia Trace. Szczegółowe instrukcje znajdziesz tutaj oraz w artykule Korzystanie z narzędzia Śledzenie. (PCI Wymaganie 10: śledzenie i monitorowanie całego dostępu do zasobów sieciowych i danych posiadacza karty)
Wymagania dotyczące złożonych haseł lub SAML
Klienci, którzy mają określone wymagania dotyczące haseł, powinni używać SAML, aby spełnić swoje indywidualne wymagania. Zobacz Włączanie uwierzytelniania SAML w Edge. Edge oferuje też uwierzytelnianie wielopoziomowe (wymaganie 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 w przypadku zgodności z PCI (wymaganie 11: regularne testowanie systemów i procesów bezpieczeństwa). 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 klienta powinny obejmować rzeczywiste usługi proxy interfejsu API hostowane na platformie Edge, do których jest wysyłany ruch interfejsu API przed przetworzeniem i dostarczeniem do centrum danych klienta. Testowanie zasobów współdzielonych, takich jak interfejs portalu zarządzania, nie jest zatwierdzone dla poszczególnych klientów (raport zewnętrzny dotyczący testowania usług współdzielonych jest dostępny dla klientów na podstawie umowy o nieujawnianiu informacji i na żądanie).
Klienci powinni testować punkty końcowe interfejsu API i zachęcamy ich do tego. Umowa z Apigee nie zabrania testowania punktów końcowych interfejsu API, ale nie zezwalamy na testowanie wspólnego interfejsu zarządzania. Jeśli jednak potrzebujesz dodatkowych wyjaśnień, otwórz zgłoszenie w sprawie pomocy technicznej, w którym odniesiesz się do planowanych testów. Z góry dziękujemy za powiadomienie nas o tym, abyśmy mogli monitorować ruch testowy.
Klienci testujący swoje punkty końcowe powinni szukać problemów związanych z interfejsem API, problemów związanych z usługami Apigee, a także sprawdzać TLS i inne konfigurowalne elementy. Wszelkie problemy związane z usługami Apigee należy zgłaszać zespołowi Apigee w ramach prośby o pomoc.
Większość problemów związanych z punktem końcowym dotyczy samodzielnego zarządzania przez klienta i można je rozwiązać, zapoznając się z dokumentacją Edge. Jeśli są elementy, w przypadku których nie wiesz, jak je naprawić, otwórz zgłoszenie do zespołu pomocy.
Konfiguracja TLS
Zgodnie ze standardami PCI protokoły SSL i starsze wersje TLS muszą zostać zastąpione bezpiecznymi wersjami. Klienci są odpowiedzialni za definiowanie i konfigurowanie własnych punktów końcowych TLS dla proxy interfejsu API. Jest to funkcja samoobsługowa w Edge. Wymagania klientów dotyczące szyfrowania, protokołu i wyboru algorytmu są bardzo zróżnicowane i zależą od konkretnych przypadków użycia. Apigee nie zna szczegółów dotyczących projektu interfejsu API i ładunków danych każdego klienta, dlatego klienci są odpowiedzialni za określenie odpowiedniego szyfrowania danych w ruchu. Szczegółowe instrukcje dotyczące konfiguracji TLS znajdziesz w artykule TLS/SSL.
Przechowywanie danych
Aby Edge działał prawidłowo, nie jest wymagane przechowywanie danych w Edge. Istnieją jednak usługi przechowywania danych na urządzeniach brzegowych. Klienci mogą używać pamięci podręcznej, map par klucz-wartość lub analityki do przechowywania danych. Żadna z tych usług nie jest autoryzowana do przechowywania danych posiadacza karty zgodnie z audytem PCI Apigee. Zgodnie z wymaganiem 3 normy PCI (ochrona przechowywanych danych posiadacza karty) dane PCI powinny być przechowywane tylko w lokalizacjach zgodnych z tą normą. Klienci mogą korzystać z tych usług do przechowywania danych niezwiązanych z PCI lub innych danych bez ograniczeń, z zastrzeżeniem wymagań klienta dotyczących bezpieczeństwa i wymagań prawnych. Są to usługi samoobsługowe, więc to klient odpowiada za ich konfigurację w taki sposób, aby nie rejestrowały ani nie przechowywały danych posiadaczy kart. Aby uniknąć przypadkowego lub złośliwego wykorzystania usług przechowywania danych w Edge w sposób niezgodny z przepisami, zalecamy administratorom klientów sprawdzanie konfiguracji, zasad i wdrożeń .
Szyfrowanie danych
Narzędzia do szyfrowania danych nie są oferowane klientom do użytku w Edge. Klienci mogą jednak zaszyfrować dane PCI przed wysłaniem ich do Edge. Wymaganie 4 standardu PCI: (szyfrowanie transmisji danych posiadacza karty w otwartych sieciach publicznych) zaleca szyfrowanie danych posiadacza karty w otwartych sieciach publicznych. Zaszyfrowane dane w ładunku (lub treści wiadomości) nie uniemożliwiają działania Edge. Niektóre zasady Edge mogą nie być w stanie przetwarzać danych, jeśli są one przesyłane przez klienta w postaci zaszyfrowanej. Na przykład przekształcenie nie jest możliwe, jeśli dane nie są dostępne dla Edge, aby je zmienić. Inne zasady, zasady i pakiety utworzone przez klienta będą jednak działać nawet wtedy, gdy ładunek danych jest zaszyfrowany.