GH GambleHub

Шифрування даних і TLS

1) Карта загроз і мети

У каналі (in-transit): перехоплення/модифікація трафіку, MitM, даунгрейд.
У спокої (at-rest): крадіжка дисків/бекапів, дампи БД/логів, інсайдери.
Ключі: витоку секретів, слабка ротація, повторне використання.
Мета - забезпечити конфіденційність, цілісність і справжність, з вимірюваними SLO і керованою криптоагільністю.

2) Класифікація даних і політика

Класи: Public / Internal / Confidential / Restricted (PII/финансы/PAN).
Мітки: `data. class`, `tenant`, `region`, `retention`.
Обов'язкові заходи: для Restricted - шифрування на рівні поля/об'єкта, журнал доступу, окремі ключі per-tenant/region.

3) Шифрування «в спокої» (at-rest)

3. 1 Envelope-шифрування

DEK (Data Encryption Key) шифрує дані; KEK/CMK (KMS/HSM) шифрує DEK.
Ротація KEK не вимагає розшифровки даних - пере-wrap DEK.
DEK бажано per-об'єкт/партія/тенант з коротким TTL.

3. 2 Рівні

Транспарантне (TDE): диск/табличні простори (PostgreSQL/MySQL/SQL Server). Просто, але без гранулярного контролю.
На рівні додатку: поля/об'єкти (PAN, секрети) - краще для multi-tenant і мінімумів доступу.
Сховища/хмари: S3/GCS SSE-KMS; для ACID-даних - FLE (field-level encryption) де можливо.

3. 3 Алгоритми та режими

AEAD: AES-256-GCM або ChaCha20-Poly1305 (на CPU без AES-NI).
IV/nonce: унікальність строго обов'язкова; зберігати поруч з ciphertext; не повторювати.
Хешування: паролі - Argon2id (або scrypt/bcrypt) з сіллю і параметрами по залізу.
МАС/підписи: HMAC-SHA-256 для цілісності, або AEAD вбудована мітка.

3. 4 Практика для БД/файлів

PostgreSQL: pgcrypto/розширення; на write - шифрувати чутливі поля в додатку.
Mongo/Doc-сховища: client-side FLE, ключі в KMS.
Бекапи: окремі ключі і доступні тільки з CI/CD-агента; офсайт-копії - завжди шифровані.

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

Джерело правди: KMS/HSM; приватні ключі не залишають апарат/сервіс.
Версіонування: `kid`, `purpose`, `alg`, `created_at`, `rotates_at`.
Доступ: least-privilege; розподіл обов'язків (SoD).
Ротація: за розкладом (3-6 міс для підпису), за подією (інцидент), rotate-on-use для refresh-токенів.
Аудит: незмінні журнали: хто, коли, що підписав/розшифрував.
Мульти-тенант: ключі per-tenant/brand/region; BYOK/HYOK при вимогах замовника.

5) Шифрування «в каналі» (TLS)

5. 1 Мінімуми

TLS 1. 2 +, переважно TLS 1. 3; HSTS на доменах.
Шифросюїти: TLS1. 3 - зумовлені (AES_256_GCM_SHA384/ CHACHA20_POLY1305_SHA256).
PFS: всі ключові обміни епемерні (ECDHE).
ALPN: HTTP/2 і HTTP/3 (QUIC) включати свідомо; стежити за таймерами.

5. 2 Сертифікати, OCSP, pinning

OCSP stapling і короткі ланцюжки.
Перевикористання сесій: TLS tickets з коротким TTL.
0-RTT (TLS 1. 3): включати обережно (тільки ідемпотентні GET).
Pinning: тільки'public-key pinning via TSP/Key continuity'в додатках/мобілках (не жорсткий HPKP).
mTLS: всередині периметра/між сервісами і партнерами; атестація по SAN.

5. 3 gRPC/HTTP/QUIC

gRPC передає Deadline і метадані - перевіряйте і обмежуйте per-try timeout.
HTTP/3 (QUIC) прискорює first-byte; перевірте сумісність WAF/балансувальників.

6) mTLS і сервіс-меш

SPIFFE/SPIRE або mesh-CA для автоматичної видачі коротких сертифікатів (7-30 днів).
Політики: хто з ким говорить (SVID→SVID), authZ на рівні L7.
Ротація - прозора; revoke через trust-bundle оновлення.

7) Продуктивність та експлуатація

AES-NI: на серверах з підтримкою - AES-GCM швидше. На мобільних/старих CPU - ChaCha20-Poly1305.
TLS-тюнінг: короткі ключі з PFS, але в розумних межах (P-256/25519); кеш рукостискань.
Batching: мінімізуйте дрібні запити; TLS-overhead пропорційний кількості з'єднань.
Offload: TLS на периметрі (Envoy/NGINX), всередині - mTLS в mesh.

8) Політики секретів і логів

Секрети тільки в KMS/Vault; в Kubernetes - шифрування etcd + KMS-провайдер.
Заборона логів: ключі/токени/PAN/секрети; маскування.
Снапшоти/дампи: шифрувати і обмежити доступ; моніторити звернення до ключів.

9) Конфіги і приклади

9. 1 NGINX (TLS строгий профіль)

nginx ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_prefer_server_ciphers on;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
ssl_ecdh_curve X25519:P-256;
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

9. 2 Envoy (mTLS до апстриму, псевдо)

yaml transport_socket:
name: envoy. transport_sockets. tls typed_config:
common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_2 tls_certificate_sds_secret_configs:
- name: service_cert # client certificate validation_context_sds_secret_config:
name: mesh_ca_bundle # trusted roots

9. 3 Приклад використання AEAD (псевдо)

pseudo nonce = random(12)
ciphertext, tag = AES256_GCM. encrypt(key=DEK, nonce, aad=tenant    object_id, plaintext)
store(nonce    ciphertext    tag)

10) Ротація та відкликані ключі

JWKS/' kid'для JWT; короткі'exp'.
Списки'jti '/' sid'для відкликання токенів з TTL.
Секрети HMAC (вебхукі): активний + канарний; прийом обома до крайньої дати.
TLS: алерти T-30/T-7/T-1, автоматичне продовження, безпечний canary.

11) Спостережуваність і алерти

Метрики: `tls_handshake_fail_total{reason}`, `tls_version_share`, `cipher_share`, `ocsp_stapling_errors`, `kms_ops_total{op}`, `decrypt_fail_total`, `jwks_kid_share`.
Логи доступу: протокол/версія/шифр (без секретів).
Алерти: сертифікати, що закінчуються, сплеск'bad _ record _ mac', зростання «недовірених ланцюжків», невдалі дешифрування.

12) Специфіка iGaming/фінансів

PAN-safe потоки: токенізація, зберігання тільки токенів; PAN - у PSP/токен-сховища.
PCI DSS: шифрування даних власників карток, обмеження доступу до ключів, журнал крипто-операцій, сегментація мережі.
Регіональність: ключі і дані в регіоні гравця (латентність/суверенітет).
Backoffice: mTLS + SSO, короткі сесії, FIDO2 для адмінів.

13) Антипатерни

TLS < 1. 2; дозволені слабкі шифри/RC4/3DES.
Загальні «вічні» секрети і ключі без ротації і'kid'.
Повтор IV/nonce в GCM (фатально для безпеки).
Логи з секретами/ключами/пан-даними.
Тільки TDE без шифрування чутливих полів.
HPKP-пінінг в проді (ризик «самозапирання»).
0-RTT на write/неідемпотентних запитах.

14) Чек-лист prod-готовності

Класифікація даних і політика шифрування (per-class).

  • AEAD (AES-GCM/ChaCha20-Poly1305); унікальні nonce; Argon2id для паролів.
  • Envelope-шифрування: DEK per-об'єкт/тенант; KEK в KMS/HSM.
  • TLS 1. 2+/1. 3, HSTS, OCSP stapling; розумний набір шифрів.
  • mTLS всередині; автоматична видача/ротація коротких сертифікатів.
  • JWKS/' kid', короткі'exp', списки'jti'; ротація секретів/сертів з перекриттям.
  • Бекапи і логи шифровані; доступи та операції аудіюються.
  • Дашборди/алерти по TLS/KMS/JWKS; тести деградації і canary.
  • Документація: процедури інцидентів (компрометація ключа/серта).

15) TL; DR

Шифруйте скрізь: в каналі - TLS 1. 3/1. 2 з PFS і строгим периметром; всередині - mTLS. У спокої - envelope (DEK/KEK) з ключами в KMS/HSM, гранулярно шифруйте чутливі поля. Керуйте ключами через'kid '/JWKS і регулярну ротацію з перекриттям, зберігайте журнали крипто-операцій. Вибирайте AES-GCM (або ChaCha20-Poly1305), не reuse-те nonce, шифруйте бекапи/логи. Для iGaming/PAN - токенізація і PCI-усвідомлена сегментація.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.