Крипто-казино
Torrent Gear
Чому важливо шифрування всіх даних користувача
Дані гравця - це не тільки 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/логах, обмеження де-шифрування на стороні додатків; для особливо критичного - ТЕЄ/конфіденційні обчислення.
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'a.
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 - і навіть у разі інциденту ви збережете довіру гравців, регуляторів і партнерів, обмеживши наслідки до керованих.