Udostępnij za pośrednictwem

Microsoft Entra ID i PCI-DSS Wymaganie 6

  • Artykuł

Wymaganie 6. Opracowywanie i obsługa bezpiecznych systemów i wymagań dotyczących podejścia zdefiniowanego programowo

6.1 Procesy i mechanizmy tworzenia i utrzymywania bezpiecznych systemów i oprogramowania są definiowane i zrozumiałe.

Wymagania dotyczące podejścia zdefiniowanego przez PCI-DSS Microsoft Entra guidance and recommendations (Wskazówki i zalecenia firmy Microsoft)
6.1.1 Wszystkie zasady zabezpieczeń i procedury operacyjne, które zostały zidentyfikowane w wymaganiach 6, to:
Udokumentowano
aktualną datę
W użyciu
znane wszystkim stronom, których dotyczy problem		 Skorzystaj ze wskazówek i linków w tym dokumencie, aby utworzyć dokumentację, aby spełnić wymagania na podstawie konfiguracji środowiska.
6.1.2 Role i obowiązki związane z wykonywaniem działań w wymaganiach 6 są udokumentowane, przypisane i zrozumiałe. Skorzystaj ze wskazówek i linków w tym dokumencie, aby utworzyć dokumentację, aby spełnić wymagania na podstawie konfiguracji środowiska.

6.2 Bespoke i niestandardowe oprogramowanie są opracowywane bezpiecznie.

Wymagania dotyczące podejścia zdefiniowanego przez PCI-DSS Microsoft Entra guidance and recommendations (Wskazówki i zalecenia firmy Microsoft)
6.2.1 Oprogramowanie na zamówienie i oprogramowanie niestandardowe są opracowywane bezpiecznie w następujący sposób:
Na podstawie standardów branżowych i/lub najlepszych rozwiązań dotyczących bezpiecznego programowania.
Zgodnie z normą PCI-DSS (na przykład bezpieczne uwierzytelnianie i rejestrowanie).
Uwzględnienie zagadnień dotyczących zabezpieczeń informacji na każdym etapie cyklu tworzenia oprogramowania.		 Pozyskiwanie i opracowywanie aplikacji korzystających z nowoczesnych protokołów uwierzytelniania, takich jak OAuth2 i OpenID Connect (OIDC), które integrują się z identyfikatorem Entra firmy Microsoft.
Tworzenie oprogramowania przy użyciu Platforma tożsamości Microsoft. Platforma tożsamości Microsoft najlepszych rozwiązań i zaleceń
6.2.2 Personel ds. tworzenia oprogramowania pracujący nad oprogramowaniem na zamówienie i oprogramowaniem niestandardowym jest szkolony co najmniej raz na 12 miesięcy w następujący sposób:
Na temat zabezpieczeń oprogramowania istotnych dla ich funkcji i języków programowania.
Uwzględnianie bezpiecznego projektowania oprogramowania i bezpiecznych technik kodowania.
W tym, jeśli są używane narzędzia do testowania zabezpieczeń, jak używać narzędzi do wykrywania luk w zabezpieczeniach w oprogramowaniu.		 Skorzystaj z następującego egzaminu, aby zapewnić dowód biegłości w zakresie Platforma tożsamości Microsoft: Egzamin MS-600: Tworzenie aplikacji i rozwiązań za pomocą usługi Microsoft 365 Core Services Skorzystaj z następującego szkolenia, aby przygotować się do egzaminu: MS-600: Implementowanie tożsamości firmy Microsoft
6.2.3 Oprogramowanie niestandardowe i niestandardowe jest sprawdzane przed udostępnieniem w środowisku produkcyjnym lub klientom, aby zidentyfikować i poprawić potencjalne luki w zabezpieczeniach kodowania, w następujący sposób:
Przeglądy kodu zapewniają opracowanie kodu zgodnie z bezpiecznymi wytycznymi dotyczącymi kodowania.
Przeglądy kodu szukają zarówno istniejących, jak i pojawiających się luk w zabezpieczeniach oprogramowania.
Odpowiednie poprawki są implementowane przed wydaniem.		 Nie dotyczy identyfikatora Entra firmy Microsoft.
6.2.3.1 Jeśli ręczne przeglądy kodu są wykonywane dla oprogramowania na zamówienie i niestandardowego oprogramowania przed wydaniem do środowiska produkcyjnego, zmiany kodu są sprawdzane
przez osoby inne niż autor kodu źródłowego i które są w stanie zapoznać się z technikami przeglądu kodu i bezpiecznymi praktykami kodowania.
Przegląd i zatwierdzenie przez zarządzanie przed wydaniem.		 Nie dotyczy identyfikatora Entra firmy Microsoft.
6.2.4 Techniki inżynierii oprogramowania lub inne metody są definiowane i używane przez personel deweloperów oprogramowania w celu zapobiegania lub eliminowania typowych ataków oprogramowania oraz powiązanych luk w zabezpieczeniach na zamówienie i oprogramowania niestandardowego, w tym nie tylko następujących:
ataki iniekcyjne, w tym ataki iniekcyjne, w tym SQL, LDAP, XPath lub inne polecenia, parametr, obiekt, błąd lub wady typu iniekcji.
Ataki na dane i struktury danych, w tym próby manipulowania, wskaźnikami, danymi wejściowymi lub udostępnionymi danymi.
Ataki na użycie kryptografii, w tym próby wykorzystania słabych, niezabezpieczonych lub nieodpowiednich implementacji kryptograficznych, algorytmów, zestawów szyfrowania lub trybów operacji.
Ataki na logikę biznesową, w tym próby nadużywania lub pomijania funkcji i funkcji aplikacji poprzez manipulowanie interfejsami API, protokołami komunikacyjnymi i kanałami, funkcjami po stronie klienta lub innymi funkcjami i zasobami systemu/aplikacji. Obejmuje to skrypty między witrynami (XSS) i fałszerzowanie żądań między witrynami (CSRF).
Ataki na mechanizmy kontroli dostępu, w tym próby obejścia lub nadużyć identyfikacji, uwierzytelniania lub mechanizmów autoryzacji lub próby wykorzystania słabych stron w implementacji takich mechanizmów.
Ataki za pośrednictwem wszelkich luk w zabezpieczeniach "wysokiego ryzyka" zidentyfikowanych w procesie identyfikacji luk w zabezpieczeniach zgodnie z definicją w wymaganiach 6.3.1.		 Nie dotyczy identyfikatora Entra firmy Microsoft.

6.3 Zidentyfikowano i rozwiązano luki w zabezpieczeniach.

Wymagania dotyczące podejścia zdefiniowanego przez PCI-DSS Microsoft Entra guidance and recommendations (Wskazówki i zalecenia firmy Microsoft)
6.3.1 Luki w zabezpieczeniach są identyfikowane i zarządzane w następujący sposób:
Nowe luki w zabezpieczeniach są identyfikowane przy użyciu uznanych w branży źródeł informacji o lukach w zabezpieczeniach, w tym alertów międzynarodowych i regionalnych zespołów reagowania kryzysowego (CERT).
Luki w zabezpieczeniach są przypisywane do klasyfikacji ryzyka na podstawie najlepszych rozwiązań branżowych i rozważenia potencjalnego wpływu.
Rankingi ryzyka identyfikują co najmniej wszystkie luki w zabezpieczeniach uważane za wysokie ryzyko lub krytyczne dla środowiska.
Omówiono luki w zabezpieczeniach dla oprogramowania niestandardowego i niestandardowego oraz oprogramowania innych firm (na przykład systemów operacyjnych i baz danych).		 Dowiedz się więcej o lukach w zabezpieczeniach. MSRC | Aktualizacje zabezpieczeń, przewodnik po aktualizacji zabezpieczeń
6.3.2 Spis oprogramowania niestandardowego i niestandardowego oraz składników oprogramowania innych firm uwzględnionych na zamówienie i niestandardowego oprogramowania jest utrzymywany w celu ułatwienia zarządzania lukami w zabezpieczeniach i poprawkami. Generowanie raportów dla aplikacji przy użyciu identyfikatora Entra firmy Microsoft na potrzeby uwierzytelniania spisu. applicationSignInDetailedSummary typ
zasobu Aplikacje wymienione w aplikacjach dla przedsiębiorstw
6.3.3 Wszystkie składniki systemowe są chronione przed znanymi lukami w zabezpieczeniach, instalując odpowiednie poprawki zabezpieczeń/aktualizacje w następujący sposób:
Poprawki krytyczne lub aktualizacje o wysokim poziomie zabezpieczeń (zidentyfikowane zgodnie z procesem klasyfikacji ryzyka w wymaganiach 6.3.1) są instalowane w ciągu jednego miesiąca od wydania.
Wszystkie inne odpowiednie poprawki zabezpieczeń/aktualizacje są instalowane w odpowiednim przedziale czasu określonym przez jednostkę (na przykład w ciągu trzech miesięcy od wydania).		 Nie dotyczy identyfikatora Entra firmy Microsoft.

6.4 Publiczne aplikacje internetowe są chronione przed atakami.

Wymagania dotyczące podejścia zdefiniowanego przez PCI-DSS Microsoft Entra guidance and recommendations (Wskazówki i zalecenia firmy Microsoft)
6.4.1 W przypadku publicznych aplikacji internetowych nowe zagrożenia i luki w zabezpieczeniach są stale rozwiązywane, a te aplikacje są chronione przed znanymi atakami w następujący sposób: Przeglądanie publicznych aplikacji internetowych za pośrednictwem narzędzi lub metod oceny zabezpieczeń luk w zabezpieczeniach aplikacji ręcznych lub zautomatyzowanych aplikacji w następujący sposób:
– Co najmniej raz na 12 miesięcy i po znaczących zmianach.
— Według jednostki specjalizującej się w zabezpieczeniach aplikacji.
— Łącznie z co najmniej wszystkimi typowymi atakami na oprogramowanie w wymaganiach 6.2.4.
— Wszystkie luki w zabezpieczeniach są klasyfikowane zgodnie z wymaganiami 6.3.1.
— Wszystkie luki w zabezpieczeniach są poprawiane.
— Aplikacja jest ponownie oceniane po korektach
LUB
zainstalowaniu zautomatyzowanych rozwiązań technicznych, które stale wykrywają i uniemożliwiają ataki internetowe w następujący sposób:
— zainstalowane przed publicznymi aplikacjami internetowymi w celu wykrywania i zapobiegania atakom internetowym.
– Aktywne działanie i aktualna zgodnie z obowiązującymi przepisami.
— Generowanie dzienników inspekcji.
— Skonfigurowane do blokowania ataków internetowych lub generowania alertu, który jest natychmiast badany.		 Nie dotyczy identyfikatora Entra firmy Microsoft.
6.4.2 W przypadku publicznych aplikacji internetowych wdrażane jest zautomatyzowane rozwiązanie techniczne, które stale wykrywa i zapobiega atakom internetowym, przy użyciu co najmniej następujących elementów:
jest instalowany przed publicznymi aplikacjami internetowymi i jest skonfigurowany do wykrywania i zapobiegania atakom internetowym.
Aktywne działanie i aktualna zgodnie z obowiązującymi przepisami.
Generowanie dzienników inspekcji.
Skonfigurowane do blokowania ataków internetowych lub generowania alertu, który jest natychmiast badany.		 Nie dotyczy identyfikatora Entra firmy Microsoft.
6.4.3 Wszystkie skrypty strony płatności, które są ładowane i wykonywane w przeglądarce konsumenta, są zarządzane w następujący sposób:
Metoda jest implementowana w celu potwierdzenia, że każdy skrypt jest autoryzowany.
Zaimplementowano metodę w celu zapewnienia integralności każdego skryptu.
Spis wszystkich skryptów jest utrzymywany z pisemnym uzasadnieniem, dlaczego każda z nich jest niezbędna.		 Nie dotyczy identyfikatora Entra firmy Microsoft.

6.5 Zmiany we wszystkich składnikach systemu są zarządzane bezpiecznie.

Wymagania dotyczące podejścia zdefiniowanego przez PCI-DSS Microsoft Entra guidance and recommendations (Wskazówki i zalecenia firmy Microsoft)
6.5.1 Zmiany we wszystkich składnikach systemu w środowisku produkcyjnym są wprowadzane zgodnie z ustalonymi procedurami, które obejmują:
przyczynę i opis zmiany.
Dokumentacja wpływu na zabezpieczenia.
Udokumentowane zatwierdzenie zmian przez autoryzowane strony.
Testowanie w celu sprawdzenia, czy zmiana nie ma negatywnego wpływu na bezpieczeństwo systemu.
W przypadku zmian oprogramowania niestandardowego i na zamówienie wszystkie aktualizacje są testowane pod kątem zgodności z wymaganiami 6.2.4 przed wdrożeniem w środowisku produkcyjnym.
Procedury rozwiązywania błędów i powrotu do bezpiecznego stanu.		 Uwzględnij zmiany w konfiguracji firmy Microsoft Entra w procesie kontroli zmian.
6.5.2 Po zakończeniu znaczącej zmiany wszystkie odpowiednie wymagania PCI-DSS są potwierdzane, że zostaną wprowadzone we wszystkich nowych lub zmienionych systemach i sieciach, a dokumentacja zostanie zaktualizowana zgodnie z potrzebami. Nie dotyczy identyfikatora Entra firmy Microsoft.
6.5.3 Środowiska przedprodukcyjne są oddzielone od środowisk produkcyjnych, a separacja jest wymuszana za pomocą kontroli dostępu. Podejścia do oddzielnego środowiska przedprodukcyjnego i produkcyjnego na podstawie wymagań organizacyjnych. Izolacja zasobów w jednej dzierżawie
Izolacja zasobów z wieloma dzierżawami
6.5.4 Role i funkcje są oddzielone między środowiskami produkcyjnymi i przedprodukcyjnymi w celu zapewnienia odpowiedzialności, tak aby wdrażane są tylko przejrzyszone i zatwierdzone zmiany. Dowiedz się więcej o rolach uprzywilejowanych i dedykowanych dzierżawach przedprodukcyjnych. Najlepsze rozwiązania dotyczące ról firmy Microsoft Entra
6.5.5 Aktywne sieci PAN nie są używane w środowiskach przedprodukcyjnych, z wyjątkiem sytuacji, w których te środowiska są zawarte w usłudze CDE i chronione zgodnie ze wszystkimi odpowiednimi wymaganiami PCI-DSS. Nie dotyczy identyfikatora Entra firmy Microsoft.
6.5.6 Dane testowe i konta testowe są usuwane ze składników systemowych, zanim system przejdzie do środowiska produkcyjnego. Nie dotyczy identyfikatora Entra firmy Microsoft.

Następne kroki

Wymagania PCI-DSS 3, 4, 9 i 12 nie są stosowane do identyfikatora Entra firmy Microsoft, dlatego nie ma odpowiednich artykułów. Aby zobaczyć wszystkie wymagania, przejdź do pcisecuritystandards.org: Oficjalna witryna Rady Standardów Bezpieczeństwa PCI.

Aby skonfigurować identyfikator Entra firmy Microsoft w celu zachowania zgodności z standardem PCI-DSS, zobacz następujące artykuły.