Укрепление прод-окружения

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’а, 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-периметра, наблюдаемость и дисциплину изменений. Остальное наращивайте итеративно, фиксируя метрики зрелости и экономику контроля.

Укрепление прод-окружения