GH GambleHub

Wzmocnienie środowiska produkcyjnego i audyt

1) Cele i obszar odpowiedzialności

Produkcja jest nie tylko „najbardziej stabilnym środowiskiem”, ale także najbardziej zaatakowanym. Nasze zadanie:
  • zminimalizować obszar ataku i promień wybuchu;
  • ochrona kanałów, kont, tajemnic i artefaktów dostawy;
  • Wykrywanie i reagowanie na incydenty szybciej niż cele MTTR
  • Potwierdzenie zgodności (RODO/PCI DSS/zasady lokalne)
  • zachować możliwość audytu wszystkich działań krytycznych.

Kluczowe zasady: Zero Trust, Least Privilege, Segmentacja, Everything-as-Code, Security-by-Default.

2) Obwód sieci i segmentacja

Segmenty: Edge (WAF, bot management, DDoS), DMZ (gateway), App (microservices), Data (DB/caches), Backoffice/Ops (CI/CD, observability).
Zasady L4/L7: odmowa domyślnie, wprost zezwala przez usługi/obszary nazw/porty.
mTLS w klastrze TLS 1. 2 + na obwodzie, HSTS, szyfry zabezpieczone.
Filtr wejściowy: WAF (OWASP Top-10), anty-bot, limity szybkości, bloki geo/ASN, CAPTCHA na ścieżkach ryzyka.
Ochrona DDoS: zawsze-on + auto-mitigation, oddzielne profile dla zawartości API/statycznej.
Sterowanie Egress: tylko niezbędne zewnętrzne hosty dla dostawców (PSP/KYC/gry).

3) Tożsamość, dostęp i uprawnienia (IAM/PAM)

SSO (OIDC/SAML) + MFA dla ludzi; Tokeny OIDC/Identyfikacja obciążenia pracą dla usług.
RBAC/ABAC: role z minimalnymi wymaganymi uprawnieniami; dostęp „break-glass” w ramach audytu i TTL.
PAM: uprzywilejowana realizacja sesji na żądanie, pełne nagrywanie i rejestrowanie.
CIEM (chmury): poszukiwanie nadmiernych praw i martwych ról, automatyczna naprawa.
Dostęp do danych produkcyjnych: tylko poprzez zatwierdzony skok/proxy, z maskowaniem PII.

4) Tajemnice i kryptografia

KMS/HSM: pamięć masowa klucza, szyfrowanie koperty, obrót z powiadomieniami.
Sekretny menedżer: kredyty krótkotrwałe, wyłączenie tajemnic z Git/logów.
Podpisy: artefakty (cosign), haki internetowe (HMAC), żetony serwisowe.
Pola PAN/PII: tokenizacja/szyfrowanie w miejscu odpoczynku; maskowanie w dziennikach i podglądach.
Zasady rotacji: klucze/certyfikaty/hasła - rutynowe i wymuszone.

5) Kontenery i kubernety (CWPP/KSPM)

Obrazy bazowe: minimalne, skanowanie luk na CI; bez korzeni, w miarę możliwości.
Polityka wjazdu (OPA/Gatekeeper/Kyverno): zakaz „: najnowszy”, „uprzywilejowany”, wymagają podpisu obrazu.
Polityka: Komunikacja między usługami tylko w razie potrzeby.
PodSecurity: ograniczone możliwości, tylko do odczytu FS, seccomp, AppArmor.
Sekrety: z Secret Store CSI (KMS); Brak zwykłej tajemnicy w manifestach.
Ochrona runtime: reguły zachowania (eBPF), alerty do anomalii.

Przykład reguły OPA (wyłączyć niepodpisane obrazy):
rego package k8sadmission deny[msg] {
input. request. kind. kind == "Pod"
some c image:= input. request. object. spec. containers[c].image not startswith(image, "registry. company. com/signed/")
msg:= sprintf("Image must be signed and come from trusted registry: %v", [image])
}

6) Łańcuch dostaw: zaufanie, ale sprawdź

SBOM na budowę; przechowywanie i łączenie do uwolnienia.
Podpisy obrazu/manifestu, walidacja kontrolera wstęp.
Certyfikaty SLSA: możliwe do udowodnienia pochodzenie artefaktów.
Policy-as-Code: Conftest/OPA na Terraform/Helm/K8s przed połączeniem.
Zakaz „last minute patching” na produkcie: wszystkie zmiany są tylko przez rurociąg.

7) Podatność i zarządzanie łatami

SCA/SAST/DAST БCI; progi blokowania dla krytycznych/wysokich.
Tygodniowe partie aktualizacji (obrazy, pakiety systemu operacyjnego, biblioteki) + awaryjne nieplanowane.
Korekty wykonywane → bilety/wydania związane z CVE/SBOM.
EASM: zewnętrzny widok powierzchni ataku (poddomeny, otwarte porty, certyfikaty).
Regularne testy długopisu: co najmniej raz w roku + ukierunkowane na przepływy krytyczne (płatności/CCM).

8) Kłody, mierniki, ślady i przechowywanie artefaktów audytowych

Standardowe dzienniki (JSON) z 'trace _ id',' request _ id', użytkownik/najemca/geo (pseudonim), bez PII/PAN.
Metryki: p50/p95/p99, wskaźnik błędów, nasycenie, DLQ, retrai, KPI biznesowe (Time-to-Wallet).
OTel: koniec do końca dla tras krytycznych (depozyt/CCL/wyjście).
SIEM: korelacja zdarzeń (uwierzytelnianie, zmiany ról, akcje administratora, zasady WAF/bot).
SOAR: automatyczne reakcje (izolacja pala, odzyskiwanie żetonu, blok IP/ASN, zakaz uwalniania).
Retencja: dzienniki operacyjne - 30-90 dni przechowywania na gorąco, artefakty audytu - dłuższe, zgodnie z zasadami.

Minimalny format dziennika (przykład):
json
{
"ts":"2025-11-05T15:00:00Z",
"sev":"WARN",
"svc":"payments-api",
"route":"POST /v1/payments",
"trace_id":"2f9f...e1",
"user":"anon",
"tenant":"eu-casino-12",
"geo":"EU",
"event":"circuit_breaker_open",
"provider":"psp-1"
}

9) Anty-boty, oszustwa i scenariusze obronne

Zarządzanie botem: podpisy/zachowanie, odcisk palca urządzenia, wyzwania dynamiczne.
limity/kwoty stawek: na użytkownika/najemcę/IP; adaptacyjne w anomaliach.
Czujniki RASP na krytycznych punktach końcowych (próby ominięcia podpisów haków webowych, dryfowanie zegara, ponowne dostarczenie).
Sygnały oszustwa: korelacja kanałami (loginy, płatności, KYC), automatyczna eskalacja.

10) Ochrona, DR i BCP

Cele RTO/RPO są definiowane i testowane (na przykład RTO ≤ 1 godzina, RPO ≤ 5 minut dla baz danych płatności).
Kopie zapasowe: zaszyfrowane, okresowo w pamięci offline; regularne testy przywracania.
Dublowanie geograficzne: aktywa-zobowiązania/aktywa-składniki aktywów w podziale na regiony; Awaria DNS z kontrolą TTL.
Katalog zależności krytycznych (PSP/KYC/agregatory gier) i plany przełączania.

11) Incydenty i reakcja

Runbooks: dla dostawcy spadek, opóźnienie wzrostu, token kompromis, DDoS.
Dyżur: 24/7, obroty i strony wybuchowe; wspólna praktyka „pokoju wojennego”.
Komunikacja: szablony wiadomości dla klientów/partnerów i regulatorów.
Pośmiertne (nienaganne): działania zapobiegające powtarzaniu, aktualizowaniu zasad/odtwarzania.

12) Zgodność i prywatność

RODO: minimalizacja danych, rejestry zgody, prawo do usunięcia/port; DPIA dla nowych dostawców.
PCI DSS: strefy tokenizacji/izolacji PAN, segmenty sieci, rygorystyczne dzienniki dostępu.
Lokalne wymagania (jurysdykcje rynkowe): przechowywanie danych w regionie, raportowanie, aktualizowanie okien.
Rodowód danych: gdzie i w jaki sposób przepływ PII/PAN; programy i DPIA w DevPortal.

13) Audyt: Rodzaje, artefakty i cykl

Rodzaje audytu:
  • Wewnętrzne (kwartalne): zgodność z polityką, kontrola zmian, dostępu, tajemnic, kłód, rurociągów.
  • Zewnętrzne (rocznie/według wymagań): PCI/RODO/lokalne regulatory, testy pióra, raporty SOC dostawców.
Kluczowe artefakty (co gotować z góry):
  • Zasady bezpieczeństwa, macierz IAM, lista wyjątków z datą wygaśnięcia.
  • Dzienniki zmiany infrastruktury (IaC), raporty CI/CD (SBOM, podpisy, testy).
  • Rejestr dostawców (PSP/KYC/games), DPIA/sprzedawca-oceny ryzyka, kontrakty i SLA.
  • Dzienniki dostępu do sprzedaży, tajne wyniki rotacji, raporty SIEM/SOAR.
  • Plany DR/BCP i protokoły ostatnich testów przywrócenia.
Podejście audytowe:
  • „Dowód-pierwszy”: każda praktyka jest sprawdzalnym artefaktem.
  • "Brak ludzi w prod': maksymalnie rurociągami i zatwierdzonymi zastosowaniami; wszystkie sesje - pod dziennikiem.
  • Śledź wszystko - Mapa zmienia się na incydenty/metryki.

14) Guardrails-as-Code: Przykłady

Konftest dla Terraform (publiczny zakaz bazy danych):
rego package terraform. deny deny[msg] {
input. resource. type == "aws_db_instance"
input. resource. publicly_accessible == true msg:= "RDS must not be public"
}

Polityka Adi (K8s): wymagać etykiet bezpieczeństwa i limitów zasobów

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: enforce-security-labels-and-limits spec:
rules:
- name: require-labels match: {resources: {kinds: ["Deployment","StatefulSet"]}}
validate:
message: "security labels required"
pattern:
metadata:
labels:
security. tier: "?"
data. classification: "?"
- name: require-limits match: {resources: {kinds: ["Deployment","StatefulSet"]}}
validate:
message: "resources limits/requests required"
pattern:
spec:
template:
spec:
containers:
- resources:
limits:
cpu: "?"
memory: "?"
requests:
cpu: "?"
memory: "?"

15) Dzienna lista kontrolna higieny

  • Aktywna polityka WAF/bot, uaktualnione podpisy; anty-DDoS w trybie zawsze włączonym.
  • Kontrolerzy wstęp w klastrze w państwie egzekwowania, a nie audyt.
  • Wszystkie obrazy produkcyjne są podpisane; SBOM jest dostępny i związany z wydaniem.
  • Krytyczne/wysokie luki - brakujące lub ustalone z wyjątkiem daty.
  • Rotacja tajemnic/certyfikatów - w harmonogramie, bez opóźnień.
  • SIEM odpowiada zdarzeniom IAM/release entry/change; SOAR playbooks są testowane.
  • Przeszedł kopia zapasowa, przywrócić test w harmonogramie; Plan DR jest ważny.
  • Dostęp do żywności - wyłącznie za pośrednictwem SSO + MFA/PAM; wszystkie sesje są rejestrowane.
  • "No PII in logs' - zatwierdzone przez skanery; Maskowanie jest włączone.
  • Bramki uwolnienia i obserwowalność zaktualizowane „as-code”.

16) Model zapadalności (krótki)

1. Podstawowe - ręczne zmiany, pojedynczy obwód, częściowy monitoring.
2. Zaawansowane - segmentacja, IAM/RBAC, podpisane artefakty, WAF/DDoS, SIEM, regularne plastry.
3. Ekspert - Zero Trust, guardrails-as-code, SLSA-attestation, runtime-protection, SOAR-automation, "no people in prod', ciągły audyt.

17) Plan działania w zakresie wdrażania

M0-M1 (MVP): segmentacja sieci, WAF/DDoS, SSO + MFA, KMS, podstawowe zasady przyjmowania, standardowe dzienniki/mierniki/ścieżki, SIEM.
M2-M3: podpisy obrazu i weryfikacja dopuszczenia, SBOM, Conftest/OPA na IaC, PAM, plan rotacji, regularne plastry, pierwsze testy DR.
M4-M6: playbooks SOAR, wykrywanie eBPF/runtime, EASM, pakiet zgodności (PCI/RODO), pełny zestaw artefaktów audytu, ring-DR według regionu.
M6 +: sieć Zero-Trust (wszędzie mTLS), CIEM, zautomatyzowane sprawozdania z audytu, ciągłe testowanie „fioletowego zespołu”.

Podsumowanie

Strong prod to nie zestaw „żelaznych” zasad, ale system: segmentacja, ścisłe tożsamości i tajemnice, bezpieczna dostawa, zarządzane kontenery, obserwowalność i automatyczna reakcja. Dodaj możliwość weryfikacji (artefakty audytu, SBOM/podpisy, dzienniki), a środowisko produkcyjne staje się przewidywalne, zarządzalne i gotowe do zewnętrznych audytów - bez kompromisów w zakresie prędkości uwolnienia i SLO biznesowych.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Telegram
@Gamble_GC
Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.