Почему важно шифрование всех пользовательских данных

Данные игрока — это не только e-mail и пароль. Это документы KYC, платежные токены, журналы ставок, устройства, IP, поведенческие метрики. Любая утечка бьёт по репутации, лицензии и P&L. Полное шифрование (в пути, в хранении и частично «в использовании») минимизирует последствия инцидентов: украденный дамп или перехваченный трафик превращаются в бессмысленный набор байтов без ключей.

1) Модель угроз: от чего нас защищает шифрование

Перехват трафика (MITM, небезопасные сети) → TLS 1.2+/1.3.

Кража бэкапов/снимков дисков → шифрование на хранении (disk/db/object).

Ошибки доступа/неправильные права → полевое шифрование, токенизация, маскирование.

Компрометация учёток/внутренние злоупотребления → разделение ключей и данных, RBAC/ABAC.

Физическая потеря носителей/устройства сотрудников → FDE/MDM.

Важно: шифрование дополняет, а не заменяет контроль доступа, журналирование и сетевую сегментацию.

2) Три слоя шифрования (вместе, а не по отдельности)

1. В пути (in transit): HTTPS/TLS 1.2+/1.3, mTLS между сервисами, HSTS, подписи вебхуков (HMAC) + anti-replay (`timestamp`, nonce).

2. На хранении (at rest):

Диски/тома: LUKS/BitLocker/eCryptfs, auto-mount с KMS.
Базы/объекты: AES-256-GCM, отдельные ключи по доменам данных (PII, финансы, логи).
Бэкапы/снапшоты: отдельная ключевая политика, offsite/Geo, проверка восстановления.
3. В использовании (in use): полевое шифрование чувствительных полей, маскирование в UI/логах, ограничение де-шифрования на стороне приложений; для особо критичного — TEE/конфиденциальные вычисления.

3) Ключи — важнее шифров: KMS/HSM и операции

KMS/HSM: генерация/хранение корневых ключей, ротация, аудит операций.

Иерархия: CMK (root) → DEK (data) → ключи для разных доменов (wallet/KYC/logs).

Ротация: плановая (90–180 дней) и внеплановая (компрометация), crypto-shred при отзыве.

Разделение обязанностей (SoD): админ БД не имеет доступа к ключам; крипто-офицер не видит данные.

Доступ «по запросу времени» (JIT) + MFA для админов.

4) Что именно шифровать (и как глубоко)

PII: ФИО, адрес, дата рождения, контакты → полевое шифрование в БД, маскирование в логах.

KYC: документы, селфи, liveness → отдельное хранилище/ключи, короткая ретенция.

Платежи: никогда не хранить PAN; токенизация, PCI DSS scope-редукция, хостед-пейджи PSP.

Игровые журналы/честность: сиды/nonce, контроль версий — чтение read-only, подписи.

Телеметрия и BI: анонимизация/псевдонимизация, дифференциальная приватность где уместно.

5) Алгоритмы и настройки по умолчанию

Симметричное: AES-256-GCM/ChaCha20-Poly1305 (AEAD, защита целостности).

Обмен ключами/сессия: ECDHE с PFS.

Криптография на ключах: ECDSA P-256/P-384 или RSA-3072 для подписи.

Хэш паролей: Argon2id (или scrypt/bcrypt с корректными параметрами), не SHA-256.

TLS: 1.3 включён, 1.2 как совместимость; шифры только AEAD, отключить CBC/RC4.

IV/nonce: уникальные, неповторяемые; хранить вместе с шифртекстом.

6) Производительность: как не «уронить» FPS и кассу

Используйте аппаратные инструкции (AES-NI) и пулы ключей.

Шифруйте поля, а не всю строку там, где нужен поиск/индексы.

Для статичных ассетов — TLS+CDN (edge-кэш), HTTP/2/3.

Не шифруйте «горячие» данные много раз на каждом хопе — стройте криптоконвейер.

Профилируйте: чаще «тормозит» не крипто, а I/O/сериализация.

7) Логи, бэкапы и тестовые среды

Логи: маскируйте токены/PII, храните в неизменяемом WORM-хранилище, шифруйте архивы.

Бэкапы: шифрование отдельными ключами, периодические DR-тесты (restore rehearsal), ретенция по политике.

Dev/Stage: никогда не использовать реальную PII; синтетика/маскирование, отдельные ключи и сети.

8) Приватность и комплаенс

GDPR/локальные аналоги: законные основания обработки, DSR (доступ/удаление/исправление), минимизация.

PCI DSS: токенизация карт, шифрование транспорта, сегрегация платёжного контура.

Договоры с процессорами: DPIA, SCC/DTIA при трансграничной передаче.

Политики ретенции: «не нужно — удаляйте», crypto-erase как часть offboarding’а.

9) Типичные ошибки (и как их не допустить)

Шифруем данные, а ключи — в коде/репозитории. Держите ключи в KMS/Vault, включите скан секретов.

Единый ключ «на всё». Делите по доменам и окружениям.

TLS есть, но нет HSTS/пиннинга/подписей вебхуков. Добавьте HSTS preload, HMAC и anti-replay.

Логи с PII в открытом виде. Маскирование + отдельное ключевое пространство для архивов.

Нет ротации и аудита ключей. Настройте расписание, алерты и журнал операций.

Тесты с реальными документами. Только синтетика/анонимизация.

10) Чеклист внедрения «шифрование по умолчанию»

TLS 1.2+/1.3 везде (edge, межсервисно), HSTS, `wss://`
KMS/HSM, иерархия ключей, ротация и аудит
Шифрование БД/объектов/бэкапов + полевое шифрование PII
Токенизация карт, PCI scope-редукция
Hash паролей на Argon2id, соль на пользователя
Маскирование PII в логах, WORM-хранилище, SIEM
Dev/Stage без реальной PII; отдельные ключи/сети
Политики ретенции/crypto-shred, процессы DSR (GDPR)
Подписи вебхуков (HMAC), anti-replay, mTLS внутри
DR-тесты восстановления, offsite-бэкапы, мониторинг утечек

11) Мини-FAQ

Шифрование «на диске» достаточно? Нет. Нужны TLS + полевое шифрование + управление ключами.

Замедлит ли шифрование игру? При правильной архитектуре — нет: узкие места обычно в сети/рендере.

Зачем токенизация, если есть шифрование? Токены исключают хранение PAN и уменьшают PCI-периметр.

Нужно ли шифровать телеметрию? Да, минимум в пути и при архивировании; плюс анонимизация.

Что делать при компрометации ключа? Немедленная ротация/отзыв, crypto-shred, анализ доступа, уведомления по политике IR.

Шифрование всех пользовательских данных — это базовый слой безопасности, который работает только вместе с правильным управлением ключами, сегрегацией доступа, минимизацией данных и дисциплиной DevSecOps. Стройте криптоархитектуру «по умолчанию», автоматизируйте ротации и DR-тесты, шифруйте бэкапы и логи, маскируйте PII — и даже в случае инцидента вы сохраните доверие игроков, регуляторов и партнёров, ограничив последствия до управляемых.