Укрепление прод-среды и аудит

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: внешний обзор поверхности атаки (поддомены, открытые порты, сертификаты).
Регулярные пен-тесты: минимум раз в год + таргетные по критичным потокам (платежи/KYC).

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 для критичных маршрутов (депозит/KYC/вывод).
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: примеры

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.