Шифрование данных и 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) с солью и параметрами по железу.
MAC/подписи: 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 roots9.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-осознанная сегментация.