Слои безопасности в инфраструктуре
(Раздел: Технологии и Инфраструктура)
Краткое резюме
Безопасность — это система слоев: каждый слой сдерживает и обнаруживает атаки, если предыдущий дал сбой. Для iGaming это особенно критично: платежные потоки, PII, партнерские интеграции и пиковые нагрузки. Ниже — каркас defense-in-depth, который соединяет сеть, идентичность, приложения, данные и операционные процессы в одну управляемую программу.
1) Модель угроз и базовые принципы
Threat Modeling: STRIDE/kill chain для ключевых потоков (логин, депозит, ставка, вывод, бэкофис).
Zero Trust: «не доверять по умолчанию», минимальные права, проверка на каждом хопе.
Least Privilege & Segregation of Duties: роли атомарны, чувствительные операции разделены.
Secure by Default: закрытые порты, deny-all политики, безопасные дефолты.
Auditability: все доступы/изменения — в централизованном аудите.
2) Сеть и периметр
Цель: не допускать бокового перемещения и изоляционно управлять риском.
Сегментация/зоны: Edge (CDN/WAF) → API → сервисы → данные (DB/KMS) → админ/бэкофис.
VPC/VNet изоляция + подсети для публичных/приватных сервисов; NAT/egress-контроль (в т.ч. egress-allowlist к PSP/провайдерам игр).
mTLS повсюду (mesh/Ingress), TLS 1.2+/HSTS/четкая криптоконфигурация.
WAF/бот-менеджмент/DDoS на периметре; анти-скоринг для credential stuffing.
DNS-безопасность: split-horizon, DNSSEC, отказоустойчивость, кэш-пинning для критичных доменов.
yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: api-deny-all, namespace: prod }
spec:
podSelector: { matchLabels: { app: api } }
policyTypes: [Ingress, Egress]
ingress: [] # deny-all egress:
- to:
- namespaceSelector: { matchLabels: { name: prod } }
podSelector: { matchLabels: { app: payments } }
ports: [{ protocol: TCP, port: 8080 }]3) Идентичность и доступ (IAM/PAM)
Цель: каждый доступ обоснован, ограничен и прозрачно аудируется.
SSO + MFA для людей и машин; аппаратные ключи для привилегированных учеток.
RBAC/ABAC для облака/K8s/бэкофиса; SCIM — автоматическое включение/выключение.
JIT-доступ (временный), break-glass с усиленным аудитом.
Service Accounts с короткоживущими токенами (OIDC/JWT), аудит клиентских секретов.
Bastion/зеркалирование команд: доступ к прод-БД/узлам — только через bastion и сессии под запись.
4) Секреты и ключи
Цель: исключить утечки и обеспечить управляемый жизненный цикл ключей.
KMS/HSM (ключ мастера), регулярная ротация; разделение ключей по зонам/целям.
Хранилище секретов (Vault/Cloud KMS Secrets) с dynamic-creds и lease.
- At rest (DB/бакеты/снапшоты) с envelope encryption.
- In transit (TLS/mTLS).
- Tokenization для платежных данных; PAN-safe потоки и 3-domain security (PCI DSS).
hcl path "kv/prod/payments/" {
capabilities = ["read","list"]
}
path "database/creds/readonly" {
capabilities = ["read"]
}5) Безопасность контейнеров и Kubernetes
Цель: минимизировать поверхность атаки на уровне рантайма.
Образы: минимальные базовые, без компиляторов/шеллов; подписи (cosign) и SBOM.
Admission-контроль (OPA/Gatekeeper/Kyverno): запрет `:latest`, `privileged`, `hostPath`, `root`.
Runtime-политики: Seccomp/AppArmor, `readOnlyRootFilesystem`, `drop ALL` capabilities + allow-list.
Secrets как volume/env из менеджера секретов; без bake-in в образ.
PodSecurity (или Pod Security Admission): enforce restricted.
Регистры: приватные, с проверкой уязвимостей (SAST/DAST/CSA).
yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sAllowedRepos metadata: { name: only-internal-registry }
spec:
repos: ["registry.internal.local/"]6) Supply-chain и CI/CD
Цель: доверять артефактам от коммита до продакшна.
Branch-policies: код-ревью, защищенные ветки, обязательные проверки.
Подпись артефактов и provenance (SLSA/COSIGN), неизменяемые теги (иммутабельные образы).
SBOM (CycloneDX/SPDX), Dependabot/Renovate и пинning зависимостей.
Изоляция CI: эфемерные раннеры, секреты только в защищенных джобах, no-plaintext.
CD-гейты: quality/SAST/лицензии/вендор-политики; промоушен только через GitOps.
7) Безопасность приложений (API/веб/мобайл)
Цель: предотвращать логические и технические атаки.
AuthN/AuthZ: OAuth2/OIDC/JWT; короткий TTL, ротации ключей, audience/issuer проверки.
Input Security: валидация/нормализация, защита от инъекций, шаблоны с параметрами.
CSP/HSTS/XFO/XSS-Protection, строгий CORS, ограничение загружаемых MIME/размеров.
Rate limit/quotas, idempotency-keys для платежей/выплат.
Фичефлаги: быстрый kill-switch для опасных функций.
nginx add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:;" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;8) Данные, PII и комплаенс (в т.ч. PCI)
Цель: минимальный сбор, минимальный доступ, максимальная прозрачность.
Data-zones/классы: `public/internal/confidential/pii/pci`. Теги в хранилищах и логах.
Минимизация PII: псевдонимизация `player_id`, токенизация платежных реквизитов.
Политики хранения: горячее/холодное, WORM для аудита; автоматическое удаление по TTL.
Доступ: только через согласованные роли и атрибуты (регион/цель).
PCI-сегментация: изолированный сегмент, журналы доступа, регулярные сканы/ASV.
9) Edge-слой: CDN/WAF/DDoS/бот-защита
Цель: отсеивать «мусор» до ядра платформы.
CDN: гео-блоки, кеш-стратегии, защита от layer-7.
WAF: базовые сигнатуры + кастомные правила под API (JSON-схемы, запрет нестандартных методов).
Боты: поведенческая аналитика, device fingerprint, rate-limit/капчи при аномалиях.
TLS/ALPN: выключить старые шифры, включить OCSP stapling.
10) Мониторинг, телеметрия и SecOps
Цель: видеть атаки и реагировать до инцидента.
Наблюдаемость: метрики/логи/трейсы с `trace_id` и audit-полями.
SIEM/SOAR: корреляция событий (аутентификация, изменения IAM, WAF срабатывания, доступ к секретам).
Правила обнаружения: всплески 401/403, role-escalation, массовые выплаты, аномалии гео.
Сканирование: SAST/DAST/IAST, CSPM/KSPM, регулярные pene-тесты и баг-баунти.
Анти-фрод: скоринг транзакций/поведения, velocity-фильтры, санкционные списки.
11) Надежность, резерв и бизнес-континуитет
Цель: пережить сбой без утраты данных и SLA.
Репликация и PITR для БД, частые снапшоты с восстановлением тестов.
DR-план: RTO/RPO, сценарии region failover, тесты переключения.
Секреты в DR: независимые ключи/реплика KMS, процесс аварийной ротации.
Формальные гайды: чек-листы восстановления и учения game-day.
12) Операционные процессы и культура
Цель: чтобы безопасность была «по умолчанию».
Security by PR: обязательный security-review для чувствительных изменений.
Политики релизов: ночные/пиковые окна закрыты; pre-flight чек-листы.
Secure Runbooks: инструкции с безопасными параметрами, аудит действий.
Обучение: фишинг-симуляции, тренировки по инцидентам, «живые» tabletop-сессии.
13) Контрольные списки (коротко)
Сеть и периметр
- Все ingress за WAF/CDN; DDoS включен
- mTLS между сервисами; deny-all сетевые политики
- Egress-allowlist к внешним провайдерам
Идентичность
- SSO+MFA; JIT и break-glass с аудитом
- RBAC/ABAC, SCIM-деактивация увольнений
- Service Accounts с короткими токенами
K8s/контейнеры
- Подписи образов + SBOM; запрет `:latest`
- Seccomp/AppArmor, read-only FS, drop caps
- Gatekeeper/Kyverno политики и deny-списки
Секреты/ключи
- Vault/KMS, ротации, разделение ключей
- Шифрование at rest/in transit
- Tokenization для платежей
CI/CD и supply-chain
- Эфемерные раннеры; секреты только в защищенных джобах
- SAST/DAST/лицензии; подписи артефактов
- GitOps-промоушен, гейты качества
Данные/PII/PCI
- Классификация данных и теги в хранилищах
- Политики retention/WORM; доступ по ролям
- Изоляция PCI-сегмента, ASV-сканы
SecOps
- SIEM/SOAR правила, алерты по эскалациям
- Анти-фрод и velocity-фильтры
- План DR, тесты RTO/RPO
14) Примеры «жестких» политик
Kyverno: запрет привилегированных контейнеров
yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: { name: disallow-privileged }
spec:
rules:
- name: no-priv match: { resources: { kinds: ["Pod"] } }
validate:
message: "Privileged containers are not allowed"
pattern:
spec:
containers:
- securityContext:
privileged: "false"OPA (Rego): запрет `hostNetwork`
rego package kubernetes.admission
violation[msg] {
input.request.kind.kind == "Pod"
input.request.object.spec.hostNetwork == true msg:= "hostNetwork is not allowed"
}15) Анти-паттерны
«Защищаем периметр» без внутреннего mTLS/segmentation → боковое перемещение.
Секреты в env-переменных CI, выгрузка в логи.
Образы `:latest`, отсутствие подписей и SBOM.
Политика allow-all в кластере; общие неймспейсы для всего.
Шифрование «на бумаге» без реальной ротации ключей и тестов восстановления.
Полагаться на WAF вместо исправления логики и валидации данных.
Нет учений DR/табличных сценариев — план «пылится».
16) Как начать (план на 90 дней)
1. Неделя 1–2: инвентаризация ассетов/данных, классификация, карта потоков.
2. Неделя 3–4: включить mTLS/deny-all сетевые политики, WAF/DDoS/бот-фильтры.
3. Неделя 5–6: Vault/KMS, ротации ключей, токенизация платежей.
4. Неделя 7–8: Gatekeeper/Kyverno, Seccomp/AppArmor, запреты `privileged`/`hostPath`.
5. Неделя 9–10: подписи образов, SBOM, гейты CI/CD, GitOps-промоушен.
6. Неделя 11–12: SIEM/SOAR правила, алерты эскалаций, анти-фрод.
7. Неделя 13: DR-учение, обновление рунабуков и статуса соответствия (PII/PCI).
Итоги
Слои безопасности — это архитектура решений, а не набор «галочек». Соедините сегментацию сети и Zero Trust, строгий IAM, безопасные контейнеры/K8s, управляемые секреты и крипто, защищенные пайплайны, edge-оборону и наблюдаемость SecOps. Тогда даже при атаках и сбоях платформа сохранит целостность данных, конфиденциальность PII/PCI и доступность ключевых потоков — депозитов, ставок и выводов — в любые пиковые часы.