BYOK: Bring Your Own Key в Пачке
Как работает шифрование собственным ключом в Пачке
Пачка объединяет удобство SaaS‑платформы с полным контролем над ключами шифрования, обеспечивая конфиденциальность корпоративной переписки и соответствие строгим требованиям безопасности.
Краткое содержание
Пачка поддерживает модель Bring Your Own Key (BYOK) — организация создаёт и управляет собственными ключами шифрования, а мессенджер выполняет крипто‑операции, не обладая доступом к мастер‑ключам. Документ описывает задачи, решаемые BYOK, архитектуру envelope шифрования, сценарии применения, поддерживаемые KMS и детали шифрования разных видов данных.
Зачем нужен BYOK
Что обеспечивает
Как помогает BYOK
Ключи шифрования остаются в участке инфраструктуры, контролируемом организацией.
Администратор может в любой момент отозвать или ротировать ключ и немедленно заблокировать расшифровку данных.
Ключи можно хранить в локальном дата-центре, даже если сами данные размещены где-то ещё.
Демонстрирует «Privacy by Design», аудит операций с ключами и минимизацию доверия к провайдеру.
Как работает: архитектура envelope шифрования
Модель продвинутого шифрования основана на концепции Envelope шифрования. При шифровании Пачка обращается в Key Management Service (KMS) клиента, чтобы сгенерировать Data Encryption Key (DEK) для фрагмента данных и и его шифрованную версию. В базу данных сохраняется только зашифрованный вариант. Когда Пачке нужно получить доступ к зашифрованным данным, он запрашивает у KMS расшифровку ключа данных с помощью мастер-ключа.
Поток операций
-
Передача сообщения. Клиентское приложение отправляет незашифрованный контент по SSL в сервис EKM внутри инфраструктуры Пачки.
-
Генерация DEK. EKM вызывает Key Management Service клиента, и запрашивает DEK и EDEK на основе предоставленного encryptionContext (чат, организация, время). Возможно реализовать связь через VPN тунель.
-
Возврат DEK и зашифрованного DEK. KMS возвращает DEK и EDEK; событие записывается в журналы KMS, доступные заказчику.
-
Шифрование сообщения. EKM мгновенно шифрует контент с использованием DEK; открытый текст более не сохраняется.
-
Сохранение в БД. EKM удаляет открытый DEK из памяти и сохраняет в базу зашифрованное сообщение + EDEK.
-
Аудит. Запись об операции wrap/decrypt автоматически поступает в систему логирования клиента, обеспечивая полную трассировку.
Важно: Мастер-ключ никогда не покидает пределы KMS клиента. Расшифрованные ключи шифрования хранятся только в оперативной памяти и никогда не записываются на диск.
Иерархия ключей
Уровень
Назначение
Типичная «длина жизни»
Хранится в KMS, содержит политику доступа; используется для вывода KEK.
Выводится (derive) из Master Key + Encryption Context; задаёт границы доступа (чат, время, организация)
Шифрует конкретное сообщение или файл
Сценарии использования
-
Полная прозрачность доступа. Журналы KMS и приложения фиксируют каждую операцию расшифровки, что ускоряет расследование инцидентов и повышает доверие клиентов.
-
Гибкое управление доступом («Kill Switch»). Администратор может мгновенно отключить KEK и сделать историю или её часть недоступной. Это важный элемент стратегии Zero Trust и плана реагирования на инциденты.
-
Разделение обязанностей (SoD). Служба безопасности управляет ключами, SaaS‑провайдер отвечает за инфраструктуру, а внутреннее ИТ занимается администрированием пользователей.
-
Контрактные обязательства и аудит. Ключи остаются у компании, что позволяет наглядно подтвердить соблюдение NDA, требований клиентов и условий регуляторных проверок.
Продвинутое шифрование vs Стандартное шифрование
Продвинутое шифрование дополняет стандартное шифрование доступное всем пользователям Пачки.
Состояние данных
Продвинутое шифрование
Стандартное шифрование
Данные шифруются с использованием управляемых клиентом ключей как можно раньше — на уровне HTTP-прокси или эквивалентной точки входа.
Все взаимодействия с интерфейсом Пачки и API шифруются через стандартные HTTPS и TLS 1.2+ по публичным сетям. Это гарантирует безопасность трафика между вами и Пачкой во время передачи.
Данные в базе остаются зашифрованными. Если третья сторона попытается получить доступ к работающей базе, данные будут возвращены в виде шифртекста.
Сервисные данные зашифрованы при хранении в Пачке с использованием ключей AES-256.
Данные остаются зашифрованными даже при использовании и расшифровываются только при наличии конкретного бизнес-кейса. Любые операции расшифровки логируются и могут быть проверены через внешнюю систему SIEM.
Данные извлекаются из хранилищ и обрабатываются в открытом виде (plaintext).
Поддерживаемые KMS (на сегодня)
-
Yandex Key Management Service
-
Cloud.ru
-
HashiCorp Vault. Также дополнительно в отличии от Yandex KMS через ограничения прав через контекст шифрования можно:
- Ограничить ключ конкретными чатами или списком чатов .
- Задать временное окно: например, разрешить расшифровку только до определённой даты или в конкретный день.
- Комбинировать условия (чат + дата/период) в политиках.
Как шифруются разные данные
Сообщения: DEK генерируется на каждое сообщение, либо если переписка идет активно, то на группу сообщений.
Поисковый индекс: Индекс также шифруется через KMS, одним KEK, для обеспечения работы глобального поиска.
Файлы: Шифруются ключом сообщения к которому они принадлежат. Шифрование происходит асинхронно сразу после загрузки файла в хранилище.