Зміцнення прод-середовища та аудит
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), алерти на аномалії.
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.