Безпека даних та шифрування

1) Навіщо це критично в iGaming

iGaming-платформа працює з PII, фінансовими реквізитами, ігровими сесіями, поведінковими ознаками, антифрод-сигналами і ML-моделями. Витік або підміна цих даних веде до штрафів, блокувань ринків, репутаційного збитку і регресу метрик (GGR, утримання).

• Конфіденційність (мінімальний доступ до PII/фінансів).
• Цілісність (захист від підміни і «брудних» даних).
• Доступність (SLO на читання/запис, DR-плани).
• Простежуваність (хто що дивився/міняв і коли).

2) Модель загроз (скорочено)

Зовнішні: компрометація API/інтеграцій, MITM, ransomware, постачальники (supply chain).
Внутрішні: надлишкові права, «тіньові» вивантаження, токсичні логи, помилки конфігурацій.
Дані та ML: підміна подій/фіч, модельна інверсія, membership inference.
Юрисдикції: транскордонні обмеження, локальні вимоги зберігання та видалення.

3) Шифрування в транзиті (In Transit)

TLS 1. 2+/1. 3 тільки, відключити слабкі шифросuites; перевага TLS 1. 3.
mTLS для S2S (yadro↔dataleyk↔katalog↔fichestor↔provaydery).
PFS (ECDHE) - обов'язкова.
Certificate pinning на мобільних/десктоп-клієнтах і критичних інтеграціях.
API-підпис запитів провайдерам/PSP (HMAC-SHA-256) і контроль часу/повторів (nonce, idempotency keys).

4) Шифрування на зберіганні (At Rest)

• Шифрування томів/об'єктів у хмарі/K8s (прозоро, але не захищає від «легітимного» читання скомпрометованим сервісом).

• TDE (Transparent Data Encryption) - базовий шар.
• FLE/Column-level AEAD для «гарячих» полів (email, телефон, PAN-токени): AES-256-GCM або ChaCha20-Poly1305.
• Row-level ключі для особливо чутливих записів (VIP, виплати).

• Envelope encryption (KMS-managed DEK, ротація), контроль доступу до ключів.
• Підпис маніфестів і контроль цілісності (hash/checksum, Merkle-дерева для пакетів).

5) Криптографічні вибори (практика)

Симетричне шифрування: AES-GCM/ChaCha20-Poly1305 (AEAD) з унікальними nonce/IV; зберігати'ciphertext + auth tag'.
Хешування: SHA-256/512 для цілісності; для паролів - Argon2id (або bcrypt/scrypt) з параметризацією і сіллю.
Підпис: Ed25519/ECDSA P-256 для артефактів/пакетів; HMAC-SHA-256 для API-підпису.
Ключові домовленості: ECDH (P-256/Curve25519).

6) Керування ключами (KMS/HSM)

KMS + HSM для генерації/зберігання майстер-ключів; envelope encryption для DEK.
Ротація: регулярна (календарна) і по події (інцидент). Підтримка dual-read на період міграції.
Розділення обов'язків (SoD), M-of-N для «break-glass», журналювання всіх операцій.
Split-key/Shamir для особливо критичних секретів (наприклад, підпис пей-аутів).
Geo-scoping ключів: різні ключі для регіонів/брендів.

7) Секрет-менеджмент

Централізований Secrets Manager (не в змінних оточення репозиторію).
JIT-секрети (короткоживучі), авто-ротація і відгук.
Sidecar/CSI для доставки секретів в поди K8s.
Заборона на логи/трейси з секретами; детектори витоків в CI.

8) Цілісність і довіра до даних

Підписання подій/пакетів (продюсером) і верифікація (консюмером).
Евент-ідемпотентність і унікальні ключі для анти-replay.
Контроль схем (Schema Registry, сумісність), Data Contracts як «межі довіри».
WORM-сховище для критичних журналів і звітності.

9) Токенізація, маскування і DLP

Токенізація PII/фінансів (vault/FPE/DET) - використання токенів в логах, вітринах, фічах.
Маскування в UI і вивантаженнях; редакція PII в текстах тікетів/чатів (NLP-санітайзинг).
DLP-політики: заборонені шаблони (PAN, IBAN, паспорт), блок вивантажень, інспекція пошти/FTP/S3.

10) Доступ і аудит

RBAC/ABAC: роль + атрибути (країна, бренд, середовище); найменші права.
JIT-доступи з авто-відгуком; раз на N днів - рев'ю прав.
mTLS + IP allowlist для адмін-панелей і критичних end-points.
Аудит-логи незмінні (WORM/append-only), кореляція з SIEM.
Break-glass: окремі ролі/ключі, обов'язковий пост-мортем.

11) Резервне копіювання та DR

3-2-1: 3 копії, 2 різних носія/ХСД, 1 офлайн/ізольована (air-gapped).
Шифрування бекапів власними ключами (не провайдера), тест відновлення за розкладом.
RPO/RTO для доменів (платежі <X хв., події ігор <Y хв.).
Регіональна реплікація з криптоізоляцією ключів і мереж.

12) Приватність і комплаєнс

Класифікація даних (Public/Internal/Confidential/Restricted).
Мінімізація та цільова зв'язка (KYC, AML, RG, звітність).
Політики зберігання та видалення: графіки, Legal Hold, DSAR; крипто-стирання.
Транскордонність: геозонування та кейси локального зберігання.

13) Спостережуваність безпеки даних

Zero-PII в логах (метрики покриття), алерти при спрацьовуванні DLP.
Key health: ротації, відмови шифрооперацій, аномалії KMS/HSM.
Integrity SLI: частка підписаних пакетів/подій і перевірених signature-checks.
Latency SLO: p95 токенізації/детокенізації, шифрування/дешифрування.
Access SLO: частка JIT-заявок оброблених в цільовий час.

14) Інструменти та технологічні шари (категорії)

KMS/HSM: майстер-ключі, envelope, підпис.
Secrets Manager: JIT-секрети, ротація.
TLS-термінація/mTLS-mesh: ingress/service mesh.
DLP/Masking: інспекція, санітайзинг.
Schema Registry/Contracts: сумісність, заборони PII.
SIEM/SOAR: кореляція аудит-логів, автоматичні реакції.
Backup/DR: оркестрація бекапів, тест відновлення.

15) Шаблони (готово до використання)

15. 1 Політика шифрування (фрагмент)

Алгоритми: AES-256-GCM/ChaCha20-Poly1305; підпис Ed25519; хеш SHA-256.
Ключі: генерація в HSM; ротація 90 днів або при інциденті; geo-scoped.
Доступ: тільки сервісні обліки через mTLS; JIT-токени.
Журнали: WORM-режим; зберігання ≥ N місяців.
Винятки: за рішенням CISO/DPO, із записом обґрунтування.

15. 2 Паспорт захищеного набору даних

Домен/таблиця: payments. transactions

Клас: Restricted (фінанси)

Шифрування: FLE (AES-GCM) по полях'card _ token','iban','payer _ id '

Ключі: DEK per-field (envelope KMS)

Токенізація: vault токени для PAN/phone/email

Доступ: ABAC (країна, роль «Payments-Ops»), JIT

Журнали: підпис пакетів, WORM, ретеншн 2 роки

15. 3 Чек-лист релізу даних

• Контракт забороняє PII в «сірих» зонах, поля позначені'pii/tokenized '
• TLS 1. 3 і mTLS на S2S включені
• FLE/TDE налаштовані, ключі в KMS/HSM, ротація активна
• DLP-правила і маскування логів проходять тести
• Бекапи шифруються, перевірений тест відновлення
• SIEM отримує аудит-логи; алерти на спробу детокенізації поза «чистою зоною»

16) Дорожня карта впровадження

0-30 днів (MVP)

1. Класифікація даних і карта потоків (PII/фінанси/ML).
2. Увімкнути TLS 1. 3/mTLS для S2S; заборона слабких шифросьютів.
3. Підняти KMS/HSM; перевести ключі на envelope-схему.
4. Включити TDE і FLE для 3 критичних доменів (Payments/KYC/RG).
5. Маскування логів і базові DLP-правила; атестація Zero-PII.

30-90 днів

1. Токенізація PII/фінансів (vault/FPE); JIT-доступи та аудит детокенізації.
2. Підпис подій і integrity-чеки в ingestion/ETL.
3. Регулярна ротація ключів, split-key для VIP-виплат.
4. Бекапи: 3-2-1, офлайн-копія, щомісячний restore-день.
5. Дашборди SLO (Zero-PII, Integrity, Key-Health, Latency).

3-6 місяців

1. Geo-scoped ключі/дані по юрисдикціях; Транскордонні політики.
2. WORM-сховище для аудиту/звітності; SOAR-плейбуки.
3. Повне покриття токенами аналітики/ML; заборона PII у вітринах.
4. Щоквартальні навчання: інцидент-симуляції (ransomware, key leak, data poisoning).
5. Щорічна пересертифікація та зовнішній аудит.

17) RACI (приклад)

Політики та контроль: CISO/CDO (A), DPO (C), SecOps (R), Domain Owners (C).
Ключі/KMS/HSM: Security/Platform (R), CTO (A), Audit (C).
Токенізація/DLP: Data Platform (R), DPO (A), Domains (C).
Бекапи/DR: SRE (R), CIO (A).
Моніторинг/інциденти: SecOps (R), SOAR (R), Legal/PR (C).

18) Метрики та SLO безпеки даних

Zero-PII в логах: ≥ 99. 99% подій.
Integrity-pass: ≥ 99. 9% підписаних пакетів успішно перевірені.
Key-hygiene: 100% своєчасних ротацій, 0 прострочених ключів.
Detokenization SLO: p95 ≤ X хв., тільки за заявками з обґрунтуванням.
Backup restore-rate: успішні тест-відновлення ≥ 99%.
Access review: закрито ≥ 95% зайвих прав за квартальним аудитом.
Incident MTTR: ≤ цільового порогу для типів P1/P2.

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

TDE «заради галочки» без FLE і токенізації чутливих полів.
Зберігання секретів у змінних оточення/репозиторіях.
Загальні ключі/pepper для всіх доменів/регіонів.
Логи з PII/секретами; дампи прод-баз без шифрування.
Відсутність підписів/перевірок цілісності в пайплайнах.
«Єдиний адмін» на всі KMS/HSM; немає SoD і M-of-N.

20) Інцидент-плейбук (коротко)

1. Детект: SIEM/DLP/аудит-лог/скарга.
2. Стабілізація: ізоляція сегмента, відкликання ключів/секретів, останів проблемних потоків.
3. Оцінка: що витекло/спотворилося, масштаб, юрисдикції, постраждалі.
4. Комунікації: Legal/PR/регулятор (де потрібно), партнери/гравці.
5. Мітигації: ротації, ретро-токенізація/шифрування, backfill/перевірки цілісності.
6. Пост-мортем: причини, уроки, оновлення політик/порогів/тестів.

21) Пов'язані розділи

Токенізація даних, Походження і шлях даних, Етика і приватність, Конфіденційне ML, Federated Learning, Зниження упередженості, DSAR/Legal Hold, Спостережуваність даних.

Підсумок

Надійний захист даних - це багаторівнева архітектура + дисципліна процесів: сучасна криптографія, строгий KMS/HSM, токенізація, підписана цілісність, чисті логи, керовані доступи і перевіряються бекапи. У iGaming виграють платформи, де дані захищені за замовчуванням, а зміни - прозорі, відтворювані і відповідають вимогам.