Зміцнення прод-оточення

1) Мета і рамка

Зміцнення (hardening) прод-оточення - це системний набір практик, який знижує ймовірність інцидентів і збиток від них. Фокус: API-периметр, дані клієнтів/платежів, CI/CD, контейнерна платформа, доступи, контроль змін, спостережуваність і відповідність регуляторним вимогам.

Ключові принципи:

Security by Design & Default: мінімально необхідні привілеї, безпечні дефолти.
Zero Trust: не довіряти ні мережі, ні ідентичностям без верифікації.
Defence-in-Depth: багаторівневий захист (мережа → сервіс → додаток → дані).
Іммутабельність артефактів: «build once, run many».
E2E-сліди та аудіюваність: хто, коли, що змінив - і чому.

2) Модель загроз і критичні активи

Активи: рахунки і платіжні токени, PII/паспортні дані, RNG/ігрові баланси, ключі шифрування, секрети інтеграцій, пайплайни деплою, образи контейнерів.
Вектори: уразливості залежностей, витоку токенів, неправильна конфігурація хмари/K8s, SSRF/RCE в API, supply chain (компрометація CI/CD/репозиторію), інсайдерський доступ, DDoS/бот Трафік.
Сценарії: виведення коштів неавторизованим суб'єктом, підміна коефіцієнтів/балансів, злив бази, захоплення пайплайну, ручні правки в проді.

3) Мережева архітектура та ізоляція

Сегментація: окремі VPC/VNet для prod/stage/dev. Всередині prod - підмережі для edge (LB/WAF), API, БД, аналітики, адмін-сервісів.
Політика «явно дозволено»: deny-all між підмережами, відкриваємо тільки потрібні порти/напрямки.
mTLS між сервісами, ротація сертифікатів автоматизована.

Приклад K8s NetworkPolicy (deny-all + allow-list):

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: default-deny namespace: prod spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: allow-api-to-db namespace: prod spec:
podSelector:
matchLabels: {app: db}
ingress:
- from:
- podSelector: {matchLabels: {app: api}}
ports: [{protocol: TCP, port: 5432}]

4) Ідентичності та доступ (PAM/JIT)

SSO + MFA для всіх людей-доступів.
RBAC & ABAC: ролі на рівні хмари, кластеру, простору імен і додатка.
PAM: jump/bastion, JIT-доступ (обмежений час), session recording.
Break-glass: запечатані обліки з апаратним ключем, видача, що журналюється.
Регулярні скани «хто до чого має доступ», рев'ю раз на 30 днів.

5) Секрети і ключі

Сховище секретів (Vault/KMS/Secrets Manager), виключаємо секрети з Git.
KMS/HSM для master-ключів; KEK/DEK, автоматична ротація.
Політики TTL: короткоживучі токени (OIDC/JWT), тимчасові обліки для CI.
Шифрування: в спокої (AES-256/GCM), в польоті (TLS 1. 2 +/mTLS), колонки PII/карткових даних - окремим ключем.

6) Supply chain и CI/CD hardening

Ізоляція runner'ів для prod (self-hosted в приватній мережі).
Підпис артефактів (Sigstore/cosign), перевірка підпису на деплое.
SBOM (CycloneDX/SPDX), SCA/VA на кожному комміті і перед релізом.
Політики «no tag latest», тільки іммутабельні теги.
4-очний принцип: обов'язковий code review і change approval.
Infrastructure as Code: Terraform/Helm с policy-as-code (OPA/Conftest).

Приклад OPA-регла (заборона public S3/Storage):

rego package iac. guardrails

deny[msg] {
input. resource. type == "storage_bucket"
input. resource. acl == "public-read"
msg:= sprintf("Public bucket forbidden: %s", [input. resource. name])
}

7) Контейнери та Kubernetes

Мінімальна база образу (distroless), rootless, read-only FS, drop CAPs.
Admission-контроль: заборона privileged, hostPath, hostNetwork.
Pod Security Standards: baseline/restricted для prod ns.
ImagePolicyWebhook: пропуск тільки підписаних образів.
Runtime-політики (Falco/eBPF): алерти на аномальні syscalls.
Quota/LimitRange: захист вузлів від «галасливих сусідів».

8) API-периметр: WAF, Rate Limits, Bot/DDoS

API Gateway: аутентифікація (OAuth2/JWT/HMAC), нормалізація, mTLS, schema validation.
WAF: базові правила + кастом під бізнес-метрики.
Rate limits: глобальні/по IP/по ключу клієнта; «токени» і burst.

Приклад NGINX-rate-limit:

nginx limit_req_zone $binary_remote_addr zone=api:20m rate=10r/s;

server {
location /api/ {
limit_req zone=api burst=30 nodelay;
proxy_pass http://api_backend;
}
}

Bot management: поведінкові сигнали, device fingerprint, challenge.
DDoS: CDN/edge-скруббінг, autoscaling, «dark-launch» для гарячих фічів.

9) Політики конфігурацій і безпечні дефолти

Feature flags/kill-switches для швидкого відключення ризикових функцій.
Config-as-Code з валідацією схем, canary/blue-green для конфігів.
Time-to-Revoke як KPI при відкликанні конфігов/ключів.

10) Дані та приватність

Класифікація: PII/фінанси/операційні логи/телеметрія.
Мінімізація: зберігати тільки потрібне, анонімізація/псевдонімізація.
Backups: окремий аккаунт/проект, шифрування, регулярні DR-репетиції.
Правила виводу: same-method, velocity-ліміти, risk-скоринг, 4-очі.
Legal Hold/ретеншн: графіки зберігання, керована утилізація.

11) Спостережуваність, алерти і реагування

Тріада: логи (не містять секрети), метрики (SLO/SLA), трейси (W3C).
Сигнали безпеки: успіх/неуспіх входів, ескалації привілеїв, зміни секретів, відхилення трафіку.
SIEM + SOAR: кореляція і напівавтоматичні плейбуки.
Плейбуки інцидентів: DDoS, витік секретів, компрометація runner'a, rollback релізу, «заморожування» платежів.
MTTD/MTTR як основні метрики оперативності.

12) Управління змінами та випуском

Change Advisory Board (легкий) для high-risk змін.
Pre-prod gates: тести, безпека, перф, міграції БД.
Canary/Blue-Green/Shadow деплої, автоматичний rollback по SLO.
Заборона прямих правок у проді: зміни тільки через пайплайн.

13) Вразливості і патчі

Patch policy: критичні - ASAP; high - протягом N днів.
Повторне сканування після фіксу; CVE-зважування по експозиції.
Chaos-security: періодичні вправи «table-top» і атаки «червоної команди» у виділених вікнах.

14) Відповідність та аудит

Контрольні фреймворки: PCI DSS (платежі), SOC 2, ISO 27001.
Артефакти: матриця контролів, журнали змін, звіти сканів, результати DR-тестів, access-review.
Безперервна готовність: «evidence as code» - артефакти збираються автоматично з пайплайнів і систем.

15) Економіка і надійність

Guardrails за вартістю: квоти, бюджети, алерти, автоматичне вимикання невикористовуваних ресурсів.
Ємність: SLO-орієнтоване планування, навантажувальні тести, «дні хаосу».
Пріоритети відновлення: RTO/RPO по сервісах, карта залежностей.

16) Анти-патерни

Секрети в.env в Git, загальний «адмін» для всіх, «прямий SSH в прод», ручні фікси в контейнерах, «latest» теги, один загальний кластер для всього, публічні бакети, CI-runner з outbound-інтернетом в prod-мережі, логи з PII, відсутній kill-switch для «гарячих» фічів.

17) Чек-лист швидкого старту (90 днів)

0-30 днів

Увімкнути MFA/SSO, рев'ю доступів; deny-all мережеві політики; Secrets Manager/KMS; заборона privileged в K8s; увімкнути WAF/Rate-limit; базові алерти входу/ескалації.

31-60 днів

Підпис образів + ImagePolicy; SBOM + SCA в CI; canary/rollback; SIEM кореляції; плейбуки IR; JIT/PAM; резервне копіювання з DR-тестом.

61-90 днів

OPA-guardrails для IaC; eBPF/Falco; бот-менеджмент; periodic access-review; chaos-security вправа; аудит конфігів і cost-guardrails.

18) Метрики зрілості

Доступи: % обліків з MFA, середній вік токенів, час відкликання.
Пайплайн: % образів з підписом/SBOM, покриття SAST/DAST.
Платформа: частка pod'ів з read-only FS, PSS-restricted, покриття NetworkPolicy.
Периметр: % API з rate-limit/WAF правилами, середня відповідь на DDoS.
IR: MTTD/MTTR, частота «table-top», відсоток успішних DR-репетицій.
Відповідність: частка контролів з автоматичними доказами.

19) Додаток: шаблони політик

AWS SCP (заборона публічних бакетів)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyPublicS3",
"Effect": "Deny",
"Action": ["s3:PutBucketAcl","s3:PutBucketPolicy"],
"Resource": "",
"Condition": {"StringEquals": {"s3:x-amz-acl": "public-read"}}
}]
}

Kubernetes PodSecurity (namespace-label)

yaml apiVersion: v1 kind: Namespace metadata:
name: prod labels:
pod-security. kubernetes. io/enforce: restricted pod-security. kubernetes. io/audit: restricted

OPA для контейнерів (заборона privileged)

rego package k8s. admission deny[msg] {
input. request. object. spec. containers[_].securityContext. privileged == true msg:= "Privileged containers are not allowed in prod"
}

20) Висновок

Зміцнення прод-оточення - це безперервний процес. Приоритизуйте заходи з максимальним зниженням ризику: доступи і секрети, мережеву ізоляцію, підпис артефактів і контроль пайплайна, захист API-периметра, спостережуваність і дисципліну змін. Решту нарощуйте ітеративно, фіксуючи метрики зрілості та економіку контролю.

Зміцнення прод-оточення