PCI DSS w środowiskach kontenerowych

Zaktualizowano: 4 lipca 2026

Czym są środowiska kontenerowe w kontekście PCI DSS? Konteneryzacja (Docker, Kubernetes, OpenShift) to technologia izolowania aplikacji w lekkich, przenośnych jednostkach wykonawczych. PCI DSS w środowiskach kontenerowych traktuje konteneryzację jak każdą inną infrastrukturę IT – jeśli kontenery przechowują, przetwarzają lub przesyłają dane kartowe (CHD), wchodzą w zakres certyfikacji. PCI DSS v4.0.1 nie ma osobnego zestawu wymogów dla kontenerów – obowiązują te same 12 obszarów wymagań, ale ich interpretacja i implementacja techniczna są specyficzne dla architektury kontenerowej. Niezrozumienie tej specyfiki prowadzi do najczęstszych błędów podczas audytu QSA.

PCI DSS w środowiskach kontenerowych – w skrócie:

Kontenery przechowujące, przetwarzające lub przesyłające CHD wchodzą w zakres PCI DSS – podobnie jak maszyny wirtualne i serwery fizyczne
Orchestrator (Kubernetes cluster, OpenShift) zarządzający kontenerami CDE wchodzi w zakres jako system connected-to
Container images używane przez systemy CDE muszą być skanowane pod kątem podatności (wymóg 6.3.3 PCI DSS v4.0.1)
Segmentacja sieci między namespace’ami Kubernetes musi być weryfikowalna i udokumentowana – Kubernetes Network Policies lub service mesh
Efemeryczność kontenerów tworzy wyzwania dla logowania i monitorowania (wymóg 10) – logi muszą być eksportowane do external SIEM przed usunięciem kontenera
Patronusec jako akredytowany QSA realizuje audyty PCI DSS dla środowisk hybrydowych (cloud + kontenery) i wspiera w przygotowaniu dokumentacji scope dla Kubernetes

Spis treści

Jak ustalić zakres PCI DSS (CDE) w środowisku Kubernetes?

Ustalenie zakresu CDE w środowisku Kubernetes jest bardziej złożone niż w tradycyjnej architekturze, bo granice sieciowe są dynamiczne, a kontenery mogą być przesuwane między węzłami.

Co wchodzi w zakres PCI DSS w środowisku Kubernetes:

Pody i kontenery przetwarzające CHD (cardholder data) – bezpośrednio w zakresie
Namespace Kubernetes zawierające pody CDE
Kubernetes control plane (API server, etcd, scheduler, controller manager) – jako connected-to, bo zarządza podami CDE
Worker nodes uruchamiające pody CDE
Container registry przechowujące obrazy używane przez CDE pody
CI/CD pipeline wdrażające zmiany do CDE środowiska

Co może być poza zakresem (przy prawidłowej segmentacji):

Namespace’y Kubernetes izolowane od CDE namespace’ów przez Network Policies
Worker nodes, które nigdy nie uruchamiają podów CDE (przez taints i tolerations)
Shared infrastructure przy prawidłowej segmentacji (load balancer, monitoring) – zależy od konfiguracji

Typowe pułapki przy ustalaniu zakresu w Kubernetes:

Shared etcd – etcd Kubernetes przechowuje stan całego klastra, w tym sekrety i konfiguracje. Jeśli etcd jest shared między namespace’ami CDE i non-CDE, cały shared cluster jest potencjalnie w zakresie. Rekomendacja: dedykowany cluster Kubernetes dla CDE lub etcd encryption.

Shared ingress controller – jeśli ingress controller obsługuje ruch zarówno do CDE jak i non-CDE serwisów, jest connected-to i wchodzi w zakres. Rekomendacja: dedykowany ingress dla CDE lub separacja na poziomie L4.

Patronusec Insight: Najczęstszą pułapką w audytach PCI DSS dla środowisk Kubernetes jest traktowanie namespace’u jako granicy bezpieczeństwa bez weryfikacji przez QSA. Kubernetes namespace jest granicą administracyjną, nie sieciową. Bez explicit Network Policies pody z różnych namespace’ów mogą komunikować się swobodnie – co oznacza, że non-CDE namespace jest connected-to CDE i wchodzi w zakres. Weryfikacja segmentacji Kubernetes to jeden z pierwszych kroków naszego scope assessment dla środowisk kontenerowych. Sprawdź naszą ofertę certyfikacji PCI DSS.

Jakie są wymagania PCI DSS v4.0.1 dotyczące bezpieczeństwa obrazów kontenerów?

PCI DSS v4.0.1 nie wymienia explicite „container images” w tekście, ale kilka wymogów bezpośrednio się do nich stosuje.

Wymóg 6.3.3 – Zarządzanie podatnościami w oprogramowaniu:

Wszystkie komponenty oprogramowania muszą być chronione przed znane podatnościami – co obejmuje base images i zależności w kontenerach. W praktyce oznacza to:

Skanowanie container images pod kątem CVE przed wdrożeniem (SAST dla obrazów: Trivy, Grype, Snyk Container)
Regularne skanowanie obrazów po wdrożeniu (nowe CVE mogą pojawić się po zbudowaniu obrazu)
Polityka akceptowalnych podatności (np. automatyczne blokowanie High/Critical CVE w CI/CD pipeline)
Aktualizacja base images i zależności w regularnym cyklu

Wymóg 2.2.1 – Konfiguracja bezpieczeństwa:

Kontenery muszą być konfigurowane bezpiecznie od momentu budowy. Dobre praktyki:

Non-root user w Dockerfile
Read-only filesystem tam gdzie możliwe
Minimal base image (distroless lub alpine zamiast pełnego OS)
Bez credentials zakodowanych w Dockerfile lub zmiennych środowiskowych (użyj secrets manager: Vault, AWS Secrets Manager, Kubernetes Secrets z encryption at rest)

Wymóg 6.2.4 – Bezpieczeństwo customowego kodu:

Dla organizacji piszących własne aplikacje wdrażane w kontenerach – wymogi code review, SAST i DAST stosują się do kodu aplikacji, nie tylko do obrazu bazowego.

Wymaganie	Implementacja w Kubernetes	Narzędzia
Skanowanie obrazów (6.3.3)	W CI/CD pipeline przed push do registry	Trivy, Snyk, Grype
Secure configuration (2.2.1)	PodSecurityStandards, SecurityContext	OPA/Gatekeeper, Kyverno
Network segmentation	Kubernetes Network Policies	Calico, Cilium
Secrets management	External secrets operator	Vault, AWS SM, Azure KV
Logging (10.x)	Sidecar lub daemonset log shipper	Fluentd, Filebeat

Masz środowisko Kubernetes z komponentami przetwarzającymi dane kartowe i planujesz certyfikację PCI DSS?

Patronusec przeprowadza scope assessment dla środowisk kontenerowych – mapujemy CDE, connected-to i wymagania dokumentacyjne specyficzne dla Kubernetes. Wynik: jasny zakres certyfikacji i lista działań przed audytem.

Zamów scope assessment dla środowisk kontenerowych

Jak spełnić wymogi logowania (PCI DSS wymóg 10) w efemerycznych środowiskach kontenerowych?

Efemeryczność kontenerów (krótki czas życia, automatyczne restartowanie) tworzy specyficzne wyzwania dla wymogów logowania PCI DSS.

Problem z logowaniem kontenerów:

Kontenery domyślnie zapisują logi lokalnie (stdout/stderr). Gdy kontener jest usunięty lub restartowany, logi przepadają. PCI DSS v4.0.1 wymóg 10.5.1 nakazuje przechowywanie logów przez 12 miesięcy z dostępnością ostatnich 3 miesięcy online. Lokalny storage kontenera tego nie zapewnia.

Rozwiązanie – centralizacja logów przed usunięciem kontenera:

Każdy log musi być exportowany do zewnętrznego systemu SIEM lub log aggregatora przed usunięciem kontenera. Popularne architektury:

Sidecar pattern: dedykowany kontener w każdym podzie zbierający logi i wysyłający do SIEM
DaemonSet log shipper: agent na każdym węźle zbierający logi ze wszystkich kontenerów
Log aggregator: Fluentd/Fluent Bit (jako DaemonSet) → Elasticsearch lub zewnętrzny SIEM

Co musi być logowane (wymóg 10.2):

W środowisku Kubernetes dodatkowe wymagania dotyczą:

Audit logs z Kubernetes API server (zmiany konfiguracji, dostęp do sekretów)
Logi z container registry (pull/push obrazów)
Logi z CI/CD pipeline (deploymenty do CDE środowiska)
Logi z node’ów (systemowe, kernel)

Patronusec Insight: Organizacje migrujące z tradycyjnej infrastruktury do Kubernetes często zakładają, że ich istniejące rozwiązanie logowania (SIEM, syslog) automatycznie obsłuży logi kontenerowe. W praktyce wymaga to integracji – Kubernetes nie wysyła logów „automatycznie” do tradycyjnych syslog collectorsów. Brak poprawnej konfiguracji logowania w środowisku Kubernetes to jeden z najczęstszych findings podczas naszych audytów QSA dla środowisk kontenerowych. Pomagamy klientom zaprojektować architekturę logowania akceptowalną dla QSA w ramach analizy luk PCI DSS.

Jak segmentacja sieciowa działa w Kubernetes i jak ją udokumentować dla QSA?

Segmentacja sieci w Kubernetes różni się fundamentalnie od segmentacji w tradycyjnej infrastrukturze (firewalle L3, VLAN). QSA musi zrozumieć mechanizm Kubernetes Network Policies, by ocenić czy segmentacja jest skuteczna.

Kubernetes Network Policies – jak działają:

Network Policies w Kubernetes to reguły na poziomie L3/L4 definiujące, które pody mogą komunikować się z którymi innymi podami lub zewnętrznymi IP. Wymagają CNI (Container Network Interface) obsługującego Network Policies – domyślny CNI w wielu dystrybucjach (np. flannel) nie obsługuje Network Policies. Wymagane CNI: Calico, Cilium, Weave Net lub podobne.

Dokumentacja segmentacji dla QSA:

QSA musi zobaczyć:

Listę wszystkich Network Policies zastosowanych w namespace’ach CDE
Potwierdzenie, że CNI implementuje Network Policies (nie tylko je definiuje)
Wyniki testów segmentacji (próby połączenia z non-CDE do CDE powinny być blokowane)
Diagram sieciowy pokazujący przepływ ruchu z zaznaczonym CDE i granicami segmentacji

Test segmentacji w Kubernetes:

PCI DSS v4.0.1 wymóg 11.4.4 nakazuje testowanie segmentacji co 12 miesięcy. W środowisku Kubernetes test obejmuje próbę nawiązania połączenia między podami w różnych namespace’ach i weryfikację, że Network Policies blokują nieautoryzowany ruch.

FAQ – PCI DSS w środowiskach kontenerowych

Czy potrzebuję osobnego klastra Kubernetes dla CDE?

Nie jest to wymóg PCI DSS – możliwe jest certyfikowanie środowiska CDE w shared Kubernetes cluster przy prawidłowej segmentacji. Jednak shared cluster zwiększa zakres certyfikacji (control plane, etcd, shared nodes stają się connected-to) i wymaga bardziej rygorystycznej dokumentacji. Dedykowany cluster CDE jest często prostszym i tańszym rozwiązaniem długoterminowo.

Czy logi z Kubernetes API server są wymagane przez PCI DSS?

Tak – Kubernetes API server jest systemem zarządzającym dostępem do CDE środowiska. Audit logs z API servera – szczególnie zmiany konfiguracji, dostęp do sekretów i deploymenty – są wymagane przez wymóg 10.2 PCI DSS jako logi dotyczące uprzywilejowanego dostępu i zmian konfiguracji.

Jak często trzeba skanować container images pod kątem PCI DSS?

PCI DSS v4.0.1 wymóg 6.3.3 wymaga skanowania „co najmniej raz na 12 miesięcy” oraz „po każdej znaczącej zmianie”. W środowisku CI/CD rekomenduje się skanowanie przy każdym build i przed każdym deploy do produkcji – jest to zarówno bezpieczniejsze jak i łatwiejsze do udokumentowania dla QSA.

Czy Helm charts i manifesty Kubernetes trzeba przeglądać pod kątem PCI DSS?

Tak – Helm charts i manifesty Kubernetes definiują konfigurację bezpieczeństwa podów (SecurityContext, resource limits, network policies). Przegląd tych dokumentów jest częścią oceny konfiguracji bezpieczeństwa (wymóg 2.2.1) i zarządzania zmianą (wymóg 6.4.x). QSA może poprosić o przegląd manifestów dla CDE namespace’ów.

Ile kosztuje audyt PCI DSS dla środowiska Kubernetes w Patronusec?

Koszt zależy od zakresu CDE w środowisku Kubernetes, liczby klastrów, modelu cloud (managed K8s vs. self-hosted), liczby aplikacji i złożoności segmentacji. Patronusec wycenia po bezpłatnej rozmowie i scope assessment. Środowiska Kubernetes wymagają zwykle więcej czasu na scope assessment niż tradycyjna infrastruktura – dlatego pre-audit jest szczególnie zalecany.

Czy certyfikacja PCI DSS dla środowisk Kubernetes różni się od standardowej?

Certyfikacja PCI DSS jest ta sama – te same 12 obszarów wymagań, te same dokumenty (ROC lub SAQ). Różni się implementacja kontroli i dokumentacja. QSA musi rozumieć specyfikę Kubernetes – nie każdy QSA ma doświadczenie z kontenerami. Wybierając QSA, pytaj o konkretne projekty w środowiskach Kubernetes/Docker.

Certyfikacja PCI DSS Kubernetes – bezpłatna konsultacja

Patronusec jako akredytowany QSA realizuje certyfikacje PCI DSS dla środowisk hybrydowych i cloud-native – w tym Kubernetes, Docker i OpenShift. Nasz zespół łączy doświadczenie QSA z wiedzą DevSecOps.

W bezpłatnej 30-minutowej konsultacji pomożemy Ci:

Wstępnie ocenić zakres CDE w Twoim środowisku Kubernetes i zidentyfikować connected-to systemy
Omówić wymagania dokumentacyjne specyficzne dla środowisk kontenerowych
Zaplanować scope assessment i harmonogram certyfikacji
Wybrać architekturę segmentacji i logowania akceptowalną przez QSA

Bezpłatna konsultacja | Certyfikacja PCI DSS | Analiza luk PCI DSS | Testy penetracyjne | vCISO