Infrastruktura GCP dla fintechu - PCI DSS i SOC 2 na Google Cloud

Google Cloud jest certyfikowany jako PCI DSS Level 1 Service Provider i posiada raport SOC 2 Type II. To oznacza, że infrastruktura GCP sama w sobie spełnia wymagania tych standardów. Ale Twoja aplikacja na GCP - niekoniecznie.

Model odpowiedzialności dzielonej (Shared Responsibility) oznacza, że GCP odpowiada za bezpieczeństwo fizyczne, sieci i hypervisora. Ty odpowiadasz za konfigurację IAM, izolację sieciową, szyfrowanie na poziomie aplikacji i zbieranie logów audytowych.

W praktyce widzimy, że polskie fintechy zaczynające na GCP popełniają te same błędy: zbyt płaska struktura projektów, brak VPC Service Controls, domyślne ustawienia GKE bez wzmocnienia zabezpieczeń (hardening), i brak automatycznego zbierania dowodów na audyt. Ten artykuł eliminuje te problemy.

PCI DSS i SOC 2 - czym się różnią i kiedy potrzebujesz obu

PCI DSS (Payment Card Industry Data Security Standard)

PCI DSS jest wymagany, gdy Twoja aplikacja przetwarza, przechowuje lub przesyła dane kart płatniczych (PAN, CVV, data ważności). Dotyczy to:

• Bramek płatniczych
• Systemów obsługujących subskrypcje z kartą
• Marketplace z płatnościami kartą
• Portfeli cyfrowych przechowujących tokeny kart

Wersja obowiązująca: PCI DSS v4.0.1 (od marca 2025, obowiązkowa od marca 2025). Kluczowe zmiany wobec v3.2.1: wymóg MFA dla wszystkich użytkowników z dostępem do CDE, continuous monitoring zamiast okresowych skanów, bardziej rygorystyczne wymagania logowania.

SOC 2 (Service Organization Control)

SOC 2 nie jest wymagany prawnie, ale jest de facto wymuszony przez klientów klasy korporacyjnej i partnerów integracyjnych. Raport SOC 2 Type II potwierdza, że Twoja organizacja przez okres 6-12 miesięcy utrzymywała kontrole w obszarach:

• Security (wymagany)
• Availability
• Processing Integrity
• Confidentiality
• Privacy

Dla fintechu typowo wymagane są Security + Availability + Confidentiality.

Kiedy potrzebujesz obu

Jeśli jesteś fintechem przetwarzającym płatności kartą I dostarczającym usługi innym firmom (model B2B lub SaaS), potrzebujesz obu. PCI DSS na środowisko przetwarzania kart (CDE - Cardholder Data Environment). SOC 2 na całą organizację i infrastrukturę.

Architektura referencyjna - struktura projektów GCP

Izolacja jest fundamentem compliance. Na GCP separacja odbywa się przez projekty (projects), które stanowią granice IAM, bilingu i sieci.

Organization (fintech-company.io)
├── Folder: Production
│   ├── Project: prod-cde          (Cardholder Data Environment)
│   ├── Project: prod-app          (aplikacja bez danych kart)
│   ├── Project: prod-data         (BigQuery, analytics)
│   └── Project: prod-networking   (Shared VPC host)
├── Folder: Non-Production
│   ├── Project: staging-app
│   ├── Project: dev-app
│   └── Project: dev-networking
├── Folder: Security
│   ├── Project: security-logging  (centralne logi audytowe)
│   ├── Project: security-keys     (Cloud KMS)
│   └── Project: security-scc      (Security Command Center)
└── Folder: CI/CD
    └── Project: cicd-pipeline     (Cloud Build, Artifact Registry)

Dlaczego osobny projekt na CDE

PCI DSS wymaga jasno zdefiniowanego zakresu (scope). Im mniejszy zakres, tym mniej kontroli do wdrożenia i mniej do audytowania. Izolacja CDE w osobnym projekcie GCP daje:

• Osobne IAM policies (minimalna liczba osób z dostępem)
• Osobne VPC (brak połączenia z systemami poza zakresem)
• Osobne logi (łatwiej wykazać kompletność na audycie)
• Osobny billing (widoczność kosztów compliance)

Organization Policy Constraints

Na poziomie organizacji ustaw constraints, które wymuszają bezpieczeństwo:

# Ograniczenie regionów - dane zostają w EU
constraints/gcp.resourceLocations:
  allowedValues:
    - europe-west1   # Belgia
    - europe-west3   # Frankfurt
    - europe-west4   # Holandia

# Wyłączenie domyślnych service accounts
constraints/iam.automaticIamGrantsForDefaultServiceAccounts:
  enforced: true

# Wymuszenie uniform bucket-level access
constraints/storage.uniformBucketLevelAccess:
  enforced: true

# Blokada publicznych IP na VM
constraints/compute.vmExternalIpAccess:
  deniedValues:
    - ALL

Izolacja sieciowa - VPC Service Controls i Private Google Access

VPC Service Controls - perymetr bezpieczeństwa

VPC Service Controls (VPC-SC) tworzą perymetr wokół zasobów GCP, który blokuje exfiltrację danych nawet przez uprawnione konta. To jest unikalna funkcja GCP bez bezpośredniego odpowiednika na AWS czy Azure.

Co VPC-SC blokuje:

• Kopiowanie danych z BigQuery w projekcie CDE do projektu poza perymetrem
• Odczyt obiektów z Cloud Storage CDE przez konto spoza perymetru
• Eksport logów z projektu CDE do zewnętrznego projektu

# Definicja perymetru VPC-SC (Terraform)
resource "google_access_context_manager_service_perimeter" "cde_perimeter" {
  parent = "accessPolicies/${var.access_policy_id}"
  name   = "accessPolicies/${var.access_policy_id}/servicePerimeters/cde"
  title  = "CDE Perimeter"

  status {
    resources = [
      "projects/${google_project.prod_cde.number}",
      "projects/${google_project.security_logging.number}",
      "projects/${google_project.security_keys.number}",
    ]

    restricted_services = [
      "bigquery.googleapis.com",
      "storage.googleapis.com",
      "cloudkms.googleapis.com",
      "logging.googleapis.com",
    ]

    access_levels = [
      google_access_context_manager_access_level.corp_network.name,
    ]
  }
}

Architektura sieciowa dla CDE

┌─────────────────────────────────────────────────────────┐
│  Shared VPC (prod-networking)                           │
│                                                         │
│  ┌──────────────────┐  ┌─────────────────────────────┐  │
│  │ Subnet: app      │  │ Subnet: cde                 │  │
│  │ 10.0.1.0/24      │  │ 10.0.2.0/24                 │  │
│  │ (prod-app)       │  │ (prod-cde)                  │  │
│  │                  │  │ - Private Google Access: ON │  │
│  │                  │  │ - Flow logs: ON             │  │
│  │                  │  │ - No external IP            │  │
│  └──────────────────┘  └─────────────────────────────┘  │
│                                                         │
│  Firewall rules:                                        │
│  - Deny all ingress (default)                           │
│  - Allow app → cde: port 8443 only (mTLS)               │
│  - Allow cde → Cloud SQL: port 5432 (Private IP)        │
│  - Deny cde → internet (no egress except GCP APIs)      │
└─────────────────────────────────────────────────────────┘

Kluczowe elementy:

• Private Google Access - komunikacja z usługami GCP (KMS, Logging, Storage) bez wychodzenia do internetu publicznego
• Flow Logs na subnecie CDE - wymagane przez PCI DSS Requirement 10 (monitoring ruchu)
• mTLS między aplikacją a CDE - wzajemna autentykacja certyfikatami, nie tylko TLS

GKE Hardening - konfiguracja Kubernetes dla fintechu

Jeśli Twoja aplikacja fintechowa działa na GKE, domyślna konfiguracja klastra nie spełnia wymagań PCI DSS. Poniżej lista ustawień wymaganych dla compliance.

Konfiguracja klastra GKE (Terraform)

resource "google_container_cluster" "cde_cluster" {
  name     = "cde-gke"
  location = "europe-west1"
  project  = google_project.prod_cde.project_id

  # Private cluster - brak publicznych IP na nodach
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = true
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }

  # Workload Identity - eliminacja kluczy service account
  workload_identity_config {
    workload_pool = "${google_project.prod_cde.project_id}.svc.id.goog"
  }

  # Binary Authorization - tylko podpisane obrazy
  binary_authorization {
    evaluation_mode = "PROJECT_SINGLETON_POLICY_ENFORCE"
  }

  # Shielded Nodes - integralność boot
  node_config {
    shielded_instance_config {
      enable_secure_boot          = true
      enable_integrity_monitoring = true
    }
  }

  # Network Policy enforcement
  network_policy {
    enabled  = true
    provider = "CALICO"
  }

  # Automatyczne aktualizacje bezpieczeństwa
  release_channel {
    channel = "REGULAR"
  }

  # Cloud Logging i Monitoring
  logging_config {
    enable_components = ["SYSTEM_COMPONENTS", "WORKLOADS"]
  }
}

Kluczowe ustawienia i ich mapowanie na wymagania

Network Policies - mikrosegmentacja w klastrze

PCI DSS wymaga segmentacji sieci. W Kubernetes oznacza to Network Policies, które blokują komunikację między pod-to-pod, chyba że jest jawnie dozwolona:

# Domyślna polityka: deny all ingress w namespace CDE
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: cde
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

---
# Pozwól payment-service na komunikację z card-vault
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-payment-to-vault
  namespace: cde
spec:
  podSelector:
    matchLabels:
      app: card-vault
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: payment-service
      ports:
        - port: 8443
          protocol: TCP

Szyfrowanie - Cloud KMS i CMEK

PCI DSS Requirement 3 wymaga szyfrowania danych kart w spoczynku (at-rest). GCP domyślnie szyfruje wszystkie dane w spoczynku (AES-256), ale używa kluczy zarządzanych przez Google. Dla PCI DSS potrzebujesz Customer-Managed Encryption Keys (CMEK) - kluczy, nad którymi masz pełną kontrolę.

Konfiguracja Cloud KMS

# Key Ring w osobnym projekcie security-keys
resource "google_kms_key_ring" "cde_keyring" {
  name     = "cde-keyring"
  location = "europe-west1"
  project  = google_project.security_keys.project_id
}

# Klucz do szyfrowania danych kart
resource "google_kms_crypto_key" "card_data_key" {
  name     = "card-data-encryption"
  key_ring = google_kms_key_ring.cde_keyring.id

  rotation_period = "7776000s"  # 90 dni - PCI DSS wymaga rotacji

  version_template {
    algorithm        = "GOOGLE_SYMMETRIC_ENCRYPTION"
    protection_level = "HSM"  # Hardware Security Module
  }

  lifecycle {
    prevent_destroy = true
  }
}

Gdzie stosować CMEK

Application-Level Encryption (tokenizacja)

Samo CMEK szyfruje dane w spoczynku na poziomie infrastruktury. Ale PCI DSS v4.0 zaleca dodatkową warstwę - tokenizację na poziomie aplikacji:

Klient → [PAN: 4111...1111] → Payment Service → Tokenizer
                                                      ↓
                                              [Token: tok_abc123]
                                                      ↓
                                              Card Vault (encrypted with CMEK)
                                                      ↓
Reszta systemu widzi TYLKO token → [tok_abc123]

Tokenizacja redukuje zakres PCI DSS. Jeśli reszta Twojego systemu nigdy nie widzi prawdziwego PAN (tylko tokeny), to CDE ogranicza się wyłącznie do Tokenizer + Card Vault.

Logowanie i monitoring - dowody audytowe

PCI DSS Requirement 10 wymaga kompletnego logowania wszystkich dostępów do danych kart. SOC 2 CC7.2 wymaga ciągłego monitoringu bezpieczeństwa. Na GCP realizujesz to przez trzy mechanizmy.

1. Cloud Audit Logs

GCP automatycznie generuje audit logs dla wszystkich operacji administracyjnych. Upewnij się, że masz włączone:

• Admin Activity logs (domyślnie ON, nie można wyłączyć)
• Data Access logs (domyślnie OFF - musisz włączyć dla CDE)
• System Event logs (domyślnie ON)

# Włączenie Data Access logs dla projektu CDE
resource "google_project_iam_audit_config" "cde_audit" {
  project = google_project.prod_cde.project_id
  service = "allServices"

  audit_log_config {
    log_type = "ADMIN_READ"
  }
  audit_log_config {
    log_type = "DATA_READ"
  }
  audit_log_config {
    log_type = "DATA_WRITE"
  }
}

2. Centralizacja logów (Log Sink)

Logi z projektu CDE muszą być przechowywane w osobnym projekcie (security-logging), do którego administratorzy CDE nie mają dostępu. To zapewnia integralność logów (PCI DSS Req 10.5).

# Sink eksportujący logi z CDE do centralnego projektu
resource "google_logging_project_sink" "cde_to_central" {
  name        = "cde-audit-sink"
  project     = google_project.prod_cde.project_id
  destination = "bigquery.googleapis.com/projects/${google_project.security_logging.project_id}/datasets/audit_logs"

  filter = "logName:\"logs/cloudaudit.googleapis.com\""

  bigquery_options {
    use_partitioned_tables = true
  }
}

3. Security Command Center (SCC)

SCC Premium to centralna platforma bezpieczeństwa GCP. Dla fintechu daje:

• Threat Detection - wykrywanie anomalii w dostępie do danych
• Vulnerability scanning - automatyczne skanowanie konfiguracji pod kątem CIS Benchmarks
• Compliance monitoring - gotowe raporty mapujące stan infrastruktury na wymagania PCI DSS i SOC 2
• Event Threat Detection - wykrywanie podejrzanych aktywności (brute force, privilege escalation)

Koszt: SCC Premium to ~$0.15/zasób/miesiąc. Dla typowego fintechu z 50-200 zasobami to $7.50-30/miesiąc - to nic w porównaniu do kosztu niezgodności.

IAM - zasada least privilege dla fintechu

PCI DSS Requirement 7 wymaga ograniczenia dostępu do danych kart wyłącznie do osób, które potrzebują tego dostępu do wykonywania swoich obowiązków. Na GCP realizujesz to przez:

Hierarchia ról

Custom IAM Roles

Zamiast używać wbudowanych ról (predefined roles), które często dają zbyt szerokie uprawnienia, twórz dedykowane role z precyzyjnym zestawem uprawnień:

# Custom role dla service account payment-service
resource "google_project_iam_custom_role" "payment_service_role" {
  project     = google_project.prod_cde.project_id
  role_id     = "paymentServiceRole"
  title       = "Payment Service CDE Access"
  permissions = [
    "cloudkms.cryptoKeyVersions.useToEncrypt",
    "cloudkms.cryptoKeyVersions.useToDecrypt",
    "cloudsql.instances.connect",
    "logging.logEntries.create",
  ]
}

Wymuszenie MFA

PCI DSS v4.0 wymaga MFA dla wszystkich użytkowników z dostępem do CDE. Na GCP wymuszasz to przez:

1. Cloud Identity / Workspace - ustawienie MFA jako obowiązkowe dla grupy cde-admins@
2. IAM Conditions - dodanie warunku request.auth.claims.amr sprawdzającego, czy sesja używa MFA
3. Context-Aware Access - polityki dostępu wymagające konkretnego poziomu uwierzytelnienia

CI/CD dla środowiska PCI DSS

PCI DSS Requirement 6 wymaga bezpiecznego procesu dostarczania oprogramowania. SOC 2 CC8.1 wymaga kontroli zmian. Pipeline CI/CD musi zapewniać:

• Skanowanie podatności w obrazach kontenerów
• Podpisywanie artefaktów (Binary Authorization)
• Separacja środowisk (dev nie ma dostępu do prod-cde)
• Pełna audytowalność (kto zaaplikował zmianę, kiedy, co zawierała)

Pipeline z Binary Authorization

Developer → Push to Git → Cloud Build (scan + build + sign) → Artifact Registry
                                                                      ↓
                                                            Binary Authorization
                                                            (weryfikacja podpisu)
                                                                      ↓
                                                              GKE CDE Cluster
                                                            (deploy podpisanego obrazu)

# cloudbuild.yaml - pipeline z podpisywaniem
steps:
  # 1. Skanowanie podatności
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', '${_IMAGE}', '.']

  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args:
      - 'artifacts'
      - 'docker'
      - 'images'
      - 'scan'
      - '${_IMAGE}'
      - '--format=json'

  # 2. Push do Artifact Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', '${_IMAGE}']

  # 3. Podpisanie obrazu (attestation)
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args:
      - 'container'
      - 'binauthz'
      - 'attestations'
      - 'sign-and-create'
      - '--artifact-url=${_IMAGE}@${_DIGEST}'
      - '--attestor=projects/${PROJECT_ID}/attestors/build-attestor'
      - '--keyversion=projects/${_KMS_PROJECT}/locations/europe-west1/keyRings/cde-keyring/cryptoKeys/attestor-key/cryptoKeyVersions/1'

Separacja pipeline CDE od reszty

Pipeline dostarczający kod do CDE musi być oddzielny od pipeline ogólnego. W praktyce:

• Osobny Cloud Build trigger dla repo CDE
• Osobny service account z uprawnieniami tylko do projektu prod-cde
• Wymagany code review + approval przed merge do main (Branch Protection Rules)
• Automatyczny scan SAST/DAST przed deployment

Zbieranie dowodów na audyt - automatyzacja

Największy ból fintechu podczas audytu PCI DSS i SOC 2 to zbieranie dowodów. Audytor pyta: “Pokaż mi, że przez ostatnie 6 miesięcy szyfrowanie było aktywne na wszystkich bazach danych”. Ręczne przygotowywanie screenshotów to tygodnie pracy.

Automatyzacja z GCP:

Ciągłe sprawdzanie compliance (SCC + Custom Findings)

# Cloud Function sprawdzająca compliance co godzinę
def check_cde_compliance(event, context):
    """Weryfikuj krytyczne kontrole CDE i raportuj do SCC."""
    
    checks = [
        check_cmek_enabled_all_databases(),
        check_vpc_sc_perimeter_active(),
        check_binary_authorization_enforced(),
        check_audit_logs_enabled(),
        check_no_public_ips_in_cde(),
    ]
    
    for check in checks:
        if not check.passed:
            create_scc_finding(
                category="PCI_DSS_VIOLATION",
                resource=check.resource,
                description=check.failure_reason,
                severity="HIGH"
            )

Raport na audyt (generowany automatycznie)

Zamiast ręcznego zbierania dowodów, eksportuj dane z GCP API:

• IAM Policy snapshots - co miesiąc eksportuj kto ma jakie role w projekcie CDE
• KMS key rotation history - pokaż, że klucze są rotowane co 90 dni
• Audit Log retention proof - pokaż, że logi są przechowywane minimum 1 rok
• Vulnerability scan results - historia skanów z Artifact Analysis
• Network configuration - eksport firewall rules i VPC-SC perimeter config

Koszty compliance na GCP

Ile kosztuje utrzymanie infrastruktury zgodnej z PCI DSS i SOC 2 na GCP? Poniżej szacunek dla typowego fintechu (50-100 pracowników, jeden produkt SaaS z płatnościami).

Do tego dochodzą koszty ludzkie:

• Przygotowanie do audytu (jednorazowo): 2-4 tygodnie pracy inżyniera
• Utrzymanie compliance (ongoing): ~0.2 FTE (kilka godzin tygodniowo)
• Audyt QSA/SOC 2 (roczny koszt zewnętrzny): $15,000-50,000

Infrastruktura compliance na GCP kosztuje $2,000-6,000 rocznie. To jest nic w porównaniu do kosztu naruszenia PCI DSS (kary $5,000-100,000/miesiąc) lub utraty certyfikacji SOC 2 (utrata klientów enterprise).

Podsumowanie - checklist wdrożenia

Faza 1: Fundament (tydzień 1-2)

• Struktura projektów GCP (osobny projekt na CDE)
• Organization Policy Constraints (regiony, publiczne IP)
• VPC z izolacją subnetu CDE
• Private Google Access na subnecie CDE
• Cloud KMS z kluczami HSM

Faza 2: Compute i deployment (tydzień 3-4)

• GKE cluster z wzmocnionymi zabezpieczeniami (private, Workload Identity, Shielded Nodes)
• Network Policies (default deny + explicit allow)
• Binary Authorization
• CI/CD pipeline z vulnerability scanning

Faza 3: Monitoring i audyt (tydzień 5-6)

• Data Access Audit Logs włączone
• Log Sink do centralnego projektu
• Security Command Center Premium
• VPC Service Controls perimeter
• Automatyczne sprawdzanie compliance (Cloud Function)

Faza 4: Dokumentacja i przygotowanie do audytu (tydzień 7-8)

• Mapa zakresu PCI DSS (network diagram, data flow diagram)
• Polityki i procedury (access control, incident response, patch management)
• Automatyczny eksport dowodów
• Testy penetracyjne (ASV scan + internal pentest)

Jak możemy pomóc

W Devopsity projektujemy infrastrukturę GCP dla firm fintech - od pierwszej konfiguracji po przygotowanie do audytu PCI DSS i SOC 2. Typowa współpraca:

• Assessment (2-3 dni) - ocena aktualnej infrastruktury, identyfikacja luk compliance
• Wdrożenie (4-6 tygodni) - architektura referencyjna z Terraform, wzmocnienie GKE, VPC-SC, monitoring
• Przygotowanie do audytu (2-3 tygodnie) - dokumentacja, automatyzacja zbierania dowodów, wsparcie audytora
• Utrzymanie (ongoing) - kwartalne przeglądy compliance, reakcja na incydenty

Budujesz fintech na GCP?

Umów się na bezpłatną konsultację. Omówimy Twoją architekturę pod kątem PCI DSS i SOC 2.

Umów rozmowę

Najczęściej zadawane pytania

Czy GCP jest certyfikowany PCI DSS?

Tak. Google Cloud jest certyfikowanym PCI DSS Level 1 Service Provider. Certyfikacja obejmuje infrastrukturę (compute, storage, networking) i wybrane managed services (GKE, Cloud SQL, BigQuery). Ale certyfikacja GCP nie zwalnia Cię z obowiązku certyfikacji Twojej aplikacji - model odpowiedzialności dzielonej.

Ile trwa przygotowanie fintechu do audytu PCI DSS na GCP?

Dla nowej infrastruktury budowanej od zera z uwzględnieniem compliance: 8-12 tygodni. Dla istniejącej infrastruktury wymagającej dostosowania: 12-20 tygodni. Czas zależy od złożoności systemu i zakresu (ile komponentów ma kontakt z danymi kart).

Czy VPC Service Controls są obowiązkowe dla PCI DSS?

Nie są wprost wymagane przez standard, ale spełniają wymaganie segmentacji sieci (Req 1) i ochrony przed exfiltracją danych. W praktyce każdy audytor QSA doceni ich obecność, bo znacząco redukują ryzyko wycieku danych.

Czy mogę uruchomić prod-cde i prod-app w jednym klastrze GKE?

Technicznie tak (z namespace isolation i Network Policies), ale nie jest to rekomendowane. Osobne klastry GKE dla CDE i reszty aplikacji dają silniejszą izolację i prostszy zakres audytu. Dodatkowy koszt (~$75/miesiąc za control plane) jest marginalny wobec korzyści.

Czy SOC 2 Type II mogę zrobić od razu, czy muszę zacząć od Type I?

Type I potwierdza, że kontrole istnieją w danym momencie. Type II potwierdza, że działały przez okres 6-12 miesięcy. Możesz przejść od razu do Type II, ale audytor musi mieć dowody z minimum 6 miesięcy. Wiele firm startuje od Type I (szybszy do uzyskania) i przechodzi na Type II po pół roku.