GH GambleHub

Зміцнення прод-середовища та аудит

1) Цілі та зона відповідальності

Продакшен - це не тільки «найстабільніше середовище», але і найбільш атакується. Наше завдання:
  • мінімізувати площу атаки і Blast Radius;
  • захистити канали, обліки, секрети та артефакти постачання;
  • виявляти і реагувати на інциденти швидше MTTR-цілей;
  • підтверджувати відповідність нормативам (GDPR/PCI DSS/локальні правила);
  • зберігати перевірюваність (auditability) всіх критичних дій.

Ключові принципи: Zero Trust, Least Privilege, Segmentation, Everything-as-Code, Security-by-Default.

2) Мережевий периметр і сегментація

Сегменти: Edge (WAF, бот-менеджмент, DDoS), DMZ (gateway), App (мікросервіси), Data (БД/кеші), Backoffice/Ops (CI/CD, observability).
Політики L4/L7: deny-by-default, явні allow по сервісах/неймспейсам/портам.
mTLS всередині кластера; TLS 1. 2 + на периметрі, HSTS, безпечні шифри.
Вхідний фільтр: WAF (OWASP Top-10), анти-бот, rate limits, гео/ASN-блоки, CAPTCHA на ризик-шляху.
DDoS protection: always-on + auto-mitigation, окремі профілі для API/статичного контенту.
Egress-контроль: тільки необхідні зовнішні хости для провайдерів (PSP/KYC/ігри).

3) Ідентичності, доступ і привілеї (IAM/PAM)

SSO (OIDC/SAML) + MFA для людей; OIDC-токени/Workload Identity для сервісів.
RBAC/ABAC: ролі з мінімально необхідними дозволами; «break-glass» доступ під аудитом і TTL.
PAM: виписування привілейованих сесій за запитом, повний запис і журналювання.
CIEM (хмари): пошук надмірних прав і мертвих ролей, авто-ремедіація.
Доступ до прод-даних: тільки через схвалені jump/проксі, з маскуванням PII.

4) Секрети і криптографія

KMS/HSM: зберігання ключів, envelope-шифрування, ротації з повідомленнями.
Секрет-менеджер: короткоживучі креди, виключити секрети з Git/логів.
Підписи: артефактів (cosign), webhooks (HMAC), службових токенів.
Поля PAN/PII: токенізація/шифрування at-rest; маскування в логах і прев'ю.
Політики ротації: ключі/сертифікати/паролі - регламентно і примусово.

5) Контейнери та Kubernetes (CWPP/KSPM)

Базові образи: мінімальні, скан вразливостей на CI; rootless де можливо.
Admission-політики (OPA/Gatekeeper/Kyverno): забороняємо':latest`, `privileged`, hostPath; вимагаємо підпису образів.
NetworkPolicies: міжсервісний зв'язок тільки за необхідності.
PodSecurity: обмежені capabilities, read-only FS, seccomp, AppArmor.
Секрети: из Secret Store CSI (KMS); жодного plain-секрету в маніфестах.
Runtime-захист: поведінкові правила (eBPF), алерти на аномалії.

Приклад OPA-правила (заборона незапідписаних образів):
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) Ланцюжок поставки: довіряй, але перевіряй

SBOM на кожен білд; зберігання і зв'язування з релізом.
Підписи образів/маніфестів, перевірка в admission-контролері.
SLSA-атестації: доведене походження артефактів.
Policy-as-Code: Conftest/OPA на Terraform/Helm/K8s перед мержем.
Заборона «last-minute patching» на проді: всі зміни - тільки через пайплайн.

7) Управління вразливостями та патчами

SCA/SAST/DAST в CI; пороги блокування для critical/high.
Щотижневі батчі оновлень (образи, ОС-пакети, бібліотеки) + екстрені позапланово.
Виконані виправлення → тікети/релізи з прив'язкою до CVE/SBOM.
EASM: зовнішній огляд поверхні атаки (піддомени, відкриті порти, сертифікати).
Регулярні пен-тести: мінімум раз на рік + таргетні по критичних потоках (платежі/КУС).

8) Логи, метрики, трасування та зберігання артефактів аудиту

Стандартизовані логи (JSON) з'trace _ id','request _ id', user/tenant/geo (псевдонімно), без PII/PAN.
Метрики: p50/p95/p99, error-rate, saturation, DLQ, ретраї, бізнес-KPI (Time-to-Wallet).
Трейсинг (OTel): end-to-end для критичних маршрутів (депозит/КУС/виведення).
SIEM: кореляція подій (автентифікація, зміни ролей, адмін-дії, правила WAF/ботів).
SOAR: авто-реакції (ізоляція пода, відгук токена, блок IP/ASN, заборона релізу).
Ретеншн: операційні логи - 30-90 днів гаряче зберігання, аудит-артефакти - довше, за політиками.

Мінімальний формат логу (приклад):
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) Антибот, шахрайство і захисні сценарії

Бот-менеджмент: сигнатури/поведінка, device-fingerprint, динамічні челенджі.
Rate limits/quotas: per-user/tenant/IP; адаптивні при аномаліях.
RASP-датчики на критичних ендпоінтах (спроби обходу підпису webhooks, дрейф годинників, повторна доставка).
Fraud-сигнали: кореляція по каналах (логіни, платежі, KYC), авто-ескалації.

10) Резервування, DR і BCP

RTO/RPO цілі визначені і тестуються (наприклад, RTO ≤ 1 година, RPO ≤ 5 хвилин для платіжних БД).
Бекапи: шифровані, періодично в офлайн-сховищі; регулярні restore-тести.
Гео-дублювання: актив-пасив/актив-актив по регіонах; DNS-failover з TTL-контролем.
Каталог критичних залежностей (PSP/KYC/агрегатори ігор) і плани перемикання.

11) Інциденти та реагування

Runbooks: для падіння провайдера, зростання латентності, компрометації токена, DDoS.
On-call: 24/7, ротації та бласт-пейджі; спільна «war-room» практика.
Комунікації: шаблони повідомлень клієнтам/партнерам і регуляторам.
Post-mortem (blameless): дії щодо запобігання повторень, оновлення політик/плейбуків.

12) Комплаєнс і приватність

GDPR: мінімізація даних, регістри згоди, право на видалення/портування; DPIA для нових провайдерів.
PCI DSS: токенізація/ізольовані зони PAN, мережеві сегменти, строгі журнали доступу.
Локальні вимоги (юрисдикції ринків): зберігання даних в регіоні, звітність, вікна оновлень.
Data Lineage: де і як течуть PII/PAN; схеми і DPIA в DevPortal.

13) Аудит: типи, артефакти і цикл

Типи аудиту:
  • Внутрішній (щоквартально): відповідність політикам, контроль змін, доступів, секретів, логів, пайплайнів.
  • Зовнішній (щорічно/за вимогами): PCI/GDPR/локальні регулятори, пен-тести, SOC-звіти провайдерів.
Ключові артефакти (що готувати заздалегідь):
  • Політики безпеки, IAM-матриця ролей, список винятків з датою закінчення.
  • Логи змін інфраструктури (IaC), звіти CI/CD (SBOM, підписи, тести).
  • Реєстр провайдерів (PSP/KYC/ігри), DPIA/вендор-ризик-оцінки, договори і SLA.
  • Журнали доступу в прод, результати ротацій секретів, звіти SIEM/SOAR.
  • Плани DR/BCP і протоколи останніх restore-тестів.
Підхід до аудиту:
  • «Evidence-first»: кожна практика - перевіряється артефакт.
  • «No humans in prod»: максимум через пайплайни і схвалені заявки; всі сесії - під журнал.
  • «Trace everything»: співвіднесіть зміни з інцидентами/метриками.

14) Guardrails-as-Code: приклади

Conftest для Terraform (заборона публічних БД):
rego package terraform. deny deny[msg] {
input. resource. type == "aws_db_instance"
input. resource. publicly_accessible == true msg:= "RDS must not be public"
}

AdmissionPolicy (K8s): вимагаємо мітки безпеки та ресурс-ліміти

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) Чек-лист щоденної гігієни прод-середовища

  • WAF/бот-політики активні, сигнатури оновлені; анти-DDoS в режимі always-on.
  • Admission-контролери в кластері в стані enforce, не audit.
  • Всі прод-образи підписані; SBOM доступний і прив'язаний до релізу.
  • Уразливості critical/high - відсутні або зафіксовані винятками з датою.
  • Ротації секретів/сертифікатів - за графіком, прострочень немає.
  • SIEM корелює події входу/зміни IAM/релізів; SOAR-плейбуки тестуються.
  • Бекапи пройшли, restore-тест в розкладі; DR-план валіден.
  • Доступи в прод - тільки через SSO + MFA/PAM; всі сесії записуються.
  • «No PII in logs» - валідується сканерами; маскування включено.
  • Release gates і спостережуваність оновлені «as-code».

16) Модель зрілості (коротко)

1. Базова - ручні зміни, єдиний периметр, частковий моніторинг.
2. Просунута - сегментація, IAM/RBAC, підписані артефакти, WAF/DDoS, SIEM, регулярні патчі.
3. Експертна - Zero Trust, guardrails-as-code, SLSA-атестації, runtime-захист, SOAR-автоматизація, «no humans in prod», безперервний аудит.

17) Дорожня карта впровадження

M0–M1 (MVP): сегментація мережі, WAF/DDoS, SSO + MFA, KMS, базові Admission-policy, стандартизовані логи/метрики/трейси, SIEM.
M2–M3: підписи образів і перевірка admission, SBOM, Conftest/OPA на IaC, PAM, план ротацій, регулярні патчі, перші DR-тести.
M4–M6: SOAR-плейбуки, eBPF/runtime-детект, EASM, комплаєнс-пакет (PCI/GDPR), повний набір артефактів аудиту, ring-DR по регіонах.
M6+: Zero-Trust мережа (mTLS скрізь), CIEM, автоматизовані контрольні звіти аудиту, постійне «purple-team» тестування.

Короткий висновок

Сильний прод - це не набір «залізних» правил, а система: сегментація, строгі ідентичності і секрети, захищена поставка, керовані контейнери, спостережуваність і автоматизована реакція. Додайте до цього перевірюваність (артефакти аудиту, SBOM/підписи, журнали), і прод-середовище стає передбачуваною, керованою і готовою до зовнішніх перевірок - без компромісів по швидкості релізів і бізнес-SLO.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.