JWKS и шифрование данных: как мы защищаем ваши данные

Почему криптография — это фундамент

SEG-T — это система безопасности, через которую проходит корпоративная почта целых организаций. Это накладывает особые требования:

• Доверие клиентов — организации передают нам контроль над почтовым трафиком. Если мы не можем защитить собственную инфраструктуру — мы не имеем права защищать чужую
• Регуляторные требования — 152-ФЗ о персональных данных обязывает применять криптографические средства защиты при обработке и хранении ПДн
• Микросервисная архитектура — множество сервисов общаются друг с другом, и каждый канал связи должен быть защищён. Компрометация одного сервиса не должна ставить под угрозу всю систему
• Высокая ценность данных — email-контент, учётные данные, ключи интеграций — всё это привлекательные цели для злоумышленников

Криптография в SEG-T — это не «галочка для аудита», а фундамент архитектуры. Каждое решение о том, как хранить, передавать и проверять данные, начинается с вопроса: «Как это защищено?»

Два вида криптографии: симметричная и асимметричная

Прежде чем разбираться в JWKS и JWT, нужно понять два базовых подхода к криптографии, потому что SEG-T использует оба — каждый для своих задач.

JWT — цифровой пропуск пользователя

JWT (JSON Web Token) — это компактный токен, который сервер выдаёт пользователю после успешной аутентификации. По сути это строка из трёх частей, разделённых точками:

Важный момент: JWT не шифрует данные пользователя. Payload можно декодировать и прочитать — это обычный Base64. Задача JWT — не скрыть информацию, а гарантировать её целостность. Подпись доказывает, что токен был выдан нашей системой и никто не менял его содержимое.

JWKS — реестр публичных ключей

JWKS (JSON Web Key Set) — это стандартный формат для публикации криптографических ключей, описанный в RFC 7517. Проще говоря, это JSON-документ, в котором лежат публичные ключи для проверки подписей JWT-токенов.

Когда пользователь логинится, сервис аутентификации подписывает JWT приватным ключом. Когда этот же пользователь обращается к другому микросервису — тот должен проверить подпись. Для этого ему нужен публичный ключ. Вопрос: где его взять?

Вариантов несколько: вшить в конфиг каждого сервиса (плохо — нельзя ротировать), передавать через переменные окружения (лучше, но всё равно не гибко) или раздавать через стандартный API-эндпоинт. Мы выбрали третий вариант — JWKS-эндпоинт. Это стандартный подход, который используют все крупные провайдеры идентификации.

Каждый ключ в JWKS имеет уникальный идентификатор — kid (Key ID). Этот же kid записывается в header JWT-токена. Благодаря этому микросервис точно знает, каким ключом проверять подпись — даже если в JWKS лежат несколько ключей одновременно (а это важно для ротации, о которой расскажем ниже).

Как работает аутентификация в SEG-T

Теперь, когда мы разобрались с компонентами, посмотрим, как всё это работает вместе. Аутентификация в SEG-T построена на асимметричной криптографии. Вот общий flow:

Такой подход обеспечивает высокую производительность и отказоустойчивость — микросервисы проверяют токены самостоятельно через публичные ключи, не создавая узких мест в системе.

Почему асимметричная подпись, а не симметричная

При выборе алгоритма подписи для JWT стоит ключевой вопрос: симметричный или асимметричный? Разница критична для микросервисной архитектуры:

В монолитном приложении с одним сервером симметричный подход может быть приемлемым. Но в микросервисной архитектуре, где множество сервисов проверяют токены, распространение общего секрета — это неприемлемый риск. Компрометация любого сервиса означала бы компрометацию всей системы аутентификации. Асимметричный подход устраняет эту проблему по дизайну.

Ротация ключей: зачем и как

Даже самый надёжный ключ не должен использоваться вечно — это фундаментальный принцип криптографии. Причин несколько:

• Ограничение ущерба — если приватный ключ когда-либо утечёт, злоумышленник сможет подписывать поддельные токены. Регулярная ротация ограничивает окно, в котором скомпрометированный ключ может быть использован
• Криптографическая гигиена — чем дольше используется ключ, тем больше подписей с ним создано. Периодическая замена снижает теоретические риски
• Compliance — стандарты безопасности (PCI DSS, SOC 2 и др.) требуют регулярной ротации криптографических ключей

Но просто взять и заменить ключ нельзя — нужно обеспечить плавный переход, чтобы пользователи не заметили смену ключей. Поэтому ротация — это управляемый процесс:

Ключевой механизм — поле kid (Key ID). Каждый JWT-токен содержит идентификатор ключа, которым он подписан. Микросервис смотрит kid, находит соответствующий публичный ключ в JWKS и проверяет подпись. Даже если в JWKS лежат несколько ключей одновременно — конфликта не будет, каждый токен знает «свой» ключ.

Многослойная защита данных

Аутентификация через JWT и JWKS — это про «кто ты?». Но не менее важен вопрос «как защищены данные?». В SEG-T мы применяем модель defense in depth — многослойную защиту, где каждый уровень страхует предыдущий. Если один слой скомпрометирован — остальные продолжают защищать данные.

Уровень 1: Шифрование при передаче

Каждый байт данных, передаваемый между компонентами системы, зашифрован с помощью актуальной версии TLS. Но защита распространяется не только на внешний трафик:

• Клиент → Сервер — весь HTTPS-трафик между браузером и нашим API
• Сервис → Сервис — внутренняя коммуникация между микросервисами также зашифрована
• Сервис → Хранилища — подключения к хранилищам данных также защищены шифрованием

Мы используем только актуальные версии TLS с современными cipher suites, исключая устаревшие и скомпрометированные алгоритмы.

Уровень 2: Шифрование при хранении

Все данные в базе данных зашифрованы на уровне хранилища. Это означает, что физические диски содержат только зашифрованные блоки.

Зачем это нужно? Представьте сценарий: злоумышленник получает физический доступ к серверу или его резервной копии. Без шифрования на уровне хранилища он просто скопирует файлы базы данных и прочитает всё. С шифрованием — он получит бессмысленный набор байтов.

Ключи шифрования хранилища управляются отдельно от приложения и ротируются автоматически — это дополнительный уровень изоляции.

Уровень 3: Шифрование отдельных полей

Шифрование при хранении — важный, но не единственный уровень защиты. Для особо чувствительных полей мы применяем дополнительное шифрование на уровне приложения — ещё один независимый барьер.

Важная деталь: мы используем authenticated encryption — режим, который обеспечивает не только конфиденциальность, но и целостность данных. При расшифровке проверяется, были ли данные изменены после шифрования. Если злоумышленник модифицирует зашифрованное поле в базе — расшифровка провалится, и мы это сразу обнаружим.

Уровень 4: Хеширование паролей

Пароли — особый случай. Их не нужно расшифровывать — нужно только проверять. Поэтому вместо шифрования мы используем одностороннее хеширование: из пароля создаётся хеш, из которого невозможно восстановить исходный пароль.

Мы используем современный адаптивный алгоритм хеширования, специально спроектированный для паролей. Вот почему это принципиально:

Безопасное хранение ключей

Алгоритмы — это только половина дела. Если ключи хранятся неправильно, даже самый надёжный алгоритм бесполезен. Вот принципы, которым мы следуем:

Принцип минимальных привилегий

Один из ключевых архитектурных принципов — каждый компонент системы получает доступ только к тем ключам и секретам, которые ему необходимы для работы. Ни больше, ни меньше.

Если скомпрометирован один компонент — последствия ограничены только тем, к чему этот компонент имел доступ. Остальные части системы остаются защищёнными.