Безопасность данных и шифрование

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 (ядро↔даталейк↔каталог↔фичестор↔провайдеры).
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 выигрывают платформы, где данные защищены по умолчанию, а изменения — прозрачны, воспроизводимы и соответствуют требованиям.