Криптография обычно ломается не в математике, а в том, как устроены ключи, сертификаты и точки доверия вокруг нее.
Глава связывает асимметричное шифрование, PKI, сертификаты, жизненный цикл ключей и TLS 1.3 в одну цепочку, где защита канала зависит от всей key infrastructure, а не от галочки "HTTPS enabled".
На интервью этот материал помогает уверенно обсуждать trust anchors, mTLS, termination points, certificate rotation и то, где transport security заканчивается, а начинаются другие уровни защиты.
Практическая польза главы
Практика проектирования
Используйте материал по криптографических механизмах, key management и TLS для защиты каналов, чтобы формировать архитектурные security-требования до этапа реализации.
Качество решений
Проверяйте решения через модель угроз, security invariants и управляемость контролей в production, а не только через чеклист соответствия.
Interview articulation
Стройте ответ в формате threat -> control -> residual risk, показывая связь между бизнес-сценарием и техническими мерами защиты.
Trade-off framing
Явно описывайте компромиссы по криптографических механизмах, key management и TLS для защиты каналов: UX friction, latency overhead, стоимость сопровождения и требования compliance.
RFC
TLS 1.3 (RFC 8446)
Базовый стандарт современного TLS handshake и key schedule.
Когда мы говорим про безопасность канала и доверие между сервисами, почти всегда за кулисами работают три слоя: криптографические примитивы, инфраструктура ключей и протокол транспорта. На практике это выглядит как связка асимметрии + PKI + TLS, а не как один «магический» алгоритм.
Что важно понимать про шифрование
Asymmetric Encryption
- Пара ключей: public key можно распространять, private key должен оставаться секретным.
- Шифрование обычно делают гибридно: данные шифруют симметричным ключом, а ключ - через public key.
- Основная практическая роль: безопасный обмен ключами и bootstrap доверия.
Digital Signatures
- Подпись подтверждает целостность и источник данных (authenticity + integrity).
- Sign: private key, Verify: public key.
- В TLS подписи используются для доказательства владения серверным ключом.
Key Management
- Реальная безопасность зависит от lifecycle ключей: генерация, хранение, ротация, отзыв.
- KMS/HSM, key versioning, access policies и audit trail - базовый production минимум.
- Компрометация private key часто опаснее, чем баг в самом протоколе.
PKI
X.509 / RFC 5280
Стандарт сертификатов и базовых правил certificate chain validation.
Инфраструктура открытых и закрытых ключей (PKI)
Root CA
Якорь доверия. Обычно офлайн, с жестким контролем доступа.
Intermediate CA
Подписывает серверные сертификаты, изолируя риск от root ключа.
Leaf Certificate
Сертификат конкретного домена/сервиса с public key и сроком действия.
Revocation / Rotation
CRL/OCSP, короткие TTL сертификатов и регулярная ротация ключей.
Production-подход: private keys должны храниться в KMS/HSM с минимальными правами доступа, регулярной ротацией и обязательным аудитом операций с ключами.
Контроли жизненного цикла сертификатов и ключей
| Этап | Обязательные контроли | Действие при провале |
|---|---|---|
| Issuance | Автоматическая выдача сертификатов, проверка domain ownership, минимальный TTL. | Блокировать выпуск сертификата и открыть security-ticket для владельца сервиса. |
| Storage | Private key только в KMS/HSM, строгий IAM, запрет экспорта ключей по умолчанию. | Отклонить deploy и перевести сервис в режим без выдачи новых сессий. |
| Rotation | Плановая ротация cert/key, overlap-window старого и нового сертификата, health checks. | Остановить rollout и автоматически откатить на предыдущую валидную версию. |
| Revocation | CRL/OCSP, быстрый emergency revoke, короткие сертификаты для снижения blast radius. | Изолировать контур, запретить соединения с compromised identity, активировать incident playbook. |
| Observability | Expiry monitoring, handshake error metrics, audit trail по операциям с ключами. | Поднять high-priority alert и включить временную защитную policy на трафик. |
Как работает TLS 1.3 (упрощенно)
До завершения handshake стороны договариваются о параметрах и ключах, после Finished приложение работает через защищённый канал.
Нажмите Start визуализации, чтобы пройти TLS 1.3 handshake по шагам.
TLS 1.3 убрал устаревшие механизмы и ускорил handshake при сохранении security guarantees.
Даже идеальный TLS не решает бизнес-авторизацию: AuthZ должен быть отдельным слоем.
Операционные метрики криптоконтуров
Доля сертификатов с auto-rotation
Target: >= 95%
Показывает зрелость управления ключами и снижает риск ручных ошибок.
Время аварийного revoke ключа
Target: < 15 минут
Критично для ограничения времени компрометации при утечке private key.
TLS handshake failure rate
Target: < 0.5%
Позволяет рано заметить проблемы в PKI, настройках cipher suites и сертификатах.
Процент сервисов с mTLS
Target: >= 90%
Отражает, насколько глубоко реализована модель zero-trust во внутреннем трафике.
Roadmap внедрения
Фаза 1 (0-30 дней)
Фокус: Инвентаризация криптоактивов
Результат: Полный список сертификатов/ключей, владельцы, сроки действия и критичные зависимости.
Фаза 2 (30-60 дней)
Фокус: Стандартизация TLS baseline
Результат: Единые cipher suites, минимальные TLS версии, централизованный certificate policy.
Фаза 3 (60-90 дней)
Фокус: Автоматизация lifecycle
Результат: Auto-issuance, auto-rotation, expiry alerts и автоматический revoke-процесс.
Фаза 4 (90+ дней)
Фокус: Операционная устойчивость
Результат: Регулярные drill-сценарии компрометации ключей и измеримые SLO для криптоконтуров.
Типичные ошибки
- Считать, что 'HTTPS включен' автоматически закрывает все риски: TLS закрывает канал, но не заменяет AuthN/AuthZ.
- Длинноживущие сертификаты и ключи без ротации.
- Игнорирование проверки certificate chain и hostname.
- Хранение private keys в plain text на хостах без KMS/HSM и контроля доступа.
- Одинаковые ключи для разных сред (dev/stage/prod).
- Отсутствие мониторинга expiry и процедур аварийного key revoke.
Связанные главы
- Identification -> AuthN -> AuthZ - Связывает TLS-канал с прикладной моделью доверия: шифрование защищает транспорт, IAM управляет доступом.
- Zero Trust: современный подход к безопасности архитектуры - Расширяет тему mTLS и постоянной верификации identity для внутренних и внешних запросов.
- Secrets Management Patterns - Дополняет TLS практиками безопасного хранения, ротации и отзыва ключевого материала.
- Supply Chain Security - Показывает, как защищать ключи и сертификаты в CI/CD и при доставке артефактов.
- Data Governance & Compliance - Добавляет регуляторные требования к шифрованию данных, аудиту операций и управлению жизненным циклом ключей.