JWKS и шифрование данных: как мы защищаем ваши данные
Привет! Сегодня поговорим о теме, которая редко попадает в маркетинговые материалы, но от которой зависит буквально всё — криптография и защита данных в SEG-T.
Статья для тех, кто хочет понять, как SEG-T защищает данные, но не хочет читать RFC на 80 страниц. Принципы и подходы — просто, но без потери смысла.
Почему криптография — это фундамент
- Доверие клиентов — если мы не можем защитить свою инфраструктуру, мы не имеем права защищать чужую
- Регуляторные требования — 152-ФЗ обязывает применять криптографические средства защиты ПДн
- Микросервисная архитектура — каждый канал связи между сервисами должен быть защищён
- Высокая ценность данных — email-контент, учётные данные, ключи интеграций
Два вида криптографии
SEG-T использует оба подхода — каждый для своих задач:
Симметричная
Один ключ для шифрования и расшифровки. Быстрая, но ключ нужно безопасно передать.
Используем для: шифрования данных в базе
Асимметричная
Два ключа — приватный и публичный. Приватный подписывает, публичный проверяет.
Используем для: подписи и проверки JWT-токенов
Симметричная — сейф с одним ключом. Асимметричная — почтовый ящик: щель доступна всем, но открыть может только владелец.
JWT — цифровой пропуск
JWT — компактный токен из трёх частей:
Метаданные — алгоритм подписи и идентификатор ключа
Информация о пользователе. НЕ зашифрована — закодирована в Base64
Цифровая подпись — гарантирует целостность. Создаётся приватным ключом
JWT не шифрует данные — он гарантирует целостность.
JWKS — реестр публичных ключей
Стандартный формат публикации криптографических ключей (RFC 7517). Мы выбрали JWKS-эндпоинт — стандартный подход всех крупных провайдеров.
JWT — это паспорт с печатью, JWKS — реестр образцов печатей в пункте контроля. Любой пограничник может свериться, не обращаясь к тому, кто выдал паспорт.
Как работает аутентификация
Пользователь вводит логин и пароль
Сервис аутентификации проверяет данные.
Сервер генерирует JWT
Токен подписывается приватным ключом.
Токен отправляется клиенту
Ограниченный срок жизни, автообновление сессии.
Запросы с токеном
Микросервис проверяет самостоятельно, без auth-сервиса.
Проверка через JWKS
Публичный ключ по kid из токена.
Проверка прав
Подпись валидна + токен не истёк → проверка доступа.
Почему асимметричная подпись
Симметричный подход
Каждый микросервис знает секрет. Кто знает секрет — может создавать поддельные токены.
Асимметричный подход
Приватный ключ знает только один сервис. Остальные могут проверить, но не создать токен.
Ротация ключей
- Ограничение ущерба — при утечке регулярная ротация ограничивает окно
- Криптографическая гигиена — периодическая замена снижает риски
- Compliance — PCI DSS, SOC 2 и др. требуют ротации
Многослойная защита данных
Defense in depth — если один слой скомпрометирован, остальные продолжают защищать.
Уровни защиты
Шифрование при передаче
TLS для всех каналов — клиент→сервер, сервис→сервис, сервис→хранилища.
Шифрование при хранении
Физические диски содержат только зашифрованные блоки.
Шифрование полей
Authenticated encryption для особо чувствительных данных на уровне приложения.
Хеширование паролей
Адаптивный алгоритм — намеренно медленный, с уникальной солью для каждого пароля.
Безопасное хранение ключей
- Выделенное хранилище секретов — полный аудит-лог обращений
- JWKS-эндпоинт — стандартный подход по RFC 7517
- Разделение по назначению — разные задачи = разные ключи
- Безопасная доставка — через защищённые каналы, не в код и не в логи
Принцип минимальных привилегий
Каждый компонент получает доступ только к нужным ключам. Компрометация одного — ограниченный инцидент, а не каскадный отказ.
Безопасность — это процесс, а не состояние. Мы постоянно пересматриваем криптографическую инфраструктуру. Вопросы — пишите в поддержку.