Шари безпеки в інфраструктурі
(Розділ: Технології та Інфраструктура)
Коротке резюме
Безпека - це система шарів: кожен шар стримує і виявляє атаки, якщо попередній дав збій. Для 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, відмовостійкість, кеш-піннінг для критичних доменів.
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 і доступність ключових потоків - депозитів, ставок і висновків - в будь-який піковий годинник.