Продвинутое шифрование в Пачке

Пачка объединяет удобство SaaS‑платформы с полным контролем над ключами шифрования, обеспечивая конфиденциальность корпоративной переписки и соответствие строгим требованиям безопасности.

Краткое содержание

Пачка поддерживает модель Bring Your Own Key (BYOK) — организация создаёт и управляет собственными ключами шифрования, а мессенджер выполняет крипто‑операции, не обладая доступом к мастер‑ключам. Документ описывает задачи, решаемые BYOK, архитектуру envelope шифрования, сценарии применения, поддерживаемые KMS и детали шифрования разных видов данных.

1 Зачем нужен BYOK

BYOK Features Table

Что обеспечивает	Как помогает BYOK
Конфиденциальность переписки и файлов	Ключи шифрования остаются в участке инфраструктуры, контролируемом организацией.
Контроль доступа	Администратор может в любой момент отозвать или ротировать ключ и немедленно заблокировать расшифровку данных.
Суверенитет данных	Ключи можно хранить в локальном дата‑центре, даже если сами данные размещены где-то ещё.
Полная прозрачность доступа	Демонстрирует «Privacy by Design», аудит операций с ключами и минимизацию доверия к провайдеру.

2 Как работает: архитектура envelope шифрования

Модель продвинутого шифрования основана на концепции Envelope шифрования. При шифровании Пачка обращается в Key Management Service (KMS) клиента, чтобы сгенерировать Data Encryption Key (DEK) для фрагмента данных и и его шифрованную версию. В базу данных сохраняется только зашифрованный вариант. Когда Пачке нужно получить доступ к зашифрованным данным, он запрашивает у KMS расшифровку ключа данных с помощью мастер-ключа.

2.1 Поток операций

Передача сообщения. Клиентское приложение отправляет незашифрованный контент по SSL в сервис EKM внутри инфраструктуры Пачки.
Генерация DEK. EKM вызывает Key Management Service клиента, и запрашивает DEK и EDEK на основе предоставленного encryptionContext (чат, организация, время). Возможно реализовать связь через VPN тунель.
Возврат DEK и зашифрованного DEK. KMS возвращает DEK и EDEK; событие записывается в журналы KMS, доступные заказчику.
Шифрование сообщения. EKM мгновенно шифрует контент с использованием DEK; открытый текст более не сохраняется.
Сохранение в БД. EKM удаляет открытый DEK из памяти и сохраняет в базу зашифрованное сообщение + EDEK.
1. Аудит. Запись об операции wrap/decrypt автоматически поступает в систему логирования клиента, обеспечивая полную трассировку.

Мастер‑ключ никогда не покидает пределы KMS клиента. Расшифрованные ключи шифрования хранятся только в оперативной памяти и никогда не записываются на диск.

2.2 Иерархия ключей

Encryption Keys Hierarchy Table

Уровень	Назначение	Типичная «длина жизни»
Master Key (Ключ клиента в KMS)	Хранится в KMS, содержит политику доступа; используется для вывода KEK	Годы; ротация редко
KEK (Key Encryption Key)	Выводится (derive) из Master Key + Encryption Context; задаёт границы доступа (чат, время, организация)	Постоянен для данного контекста; при смене политики может быть пересоздан
DEK (Data Encryption Key)	Шифрует конкретное сообщение или файл	Минуты‑часы; уничтожается сразу после шифрования

3 Сценарии использования

Полная прозрачность доступа. Журналы KMS и приложения фиксируют каждую операцию расшифровки, что ускоряет расследование инцидентов и повышает доверие клиентов.
Гибкое управление доступом («Kill Switch»). Администратор может мгновенно отключить KEK и сделать историю или её часть недоступной. Это важный элемент стратегии Zero Trust и плана реагирования на инциденты.
Разделение обязанностей (SoD). Служба безопасности управляет ключами, SaaS‑провайдер отвечает за инфраструктуру, а внутреннее ИТ занимается администрированием пользователей.
Контрактные обязательства и аудит. Ключи остаются у компании, что позволяет наглядно подтвердить соблюдение NDA, требований клиентов и условий регуляторных проверок.

4 Продвинутое шифрование vs Стандартное шифрование

Продвинутое шифрование дополняет стандартное шифрование доступное всем пользователям Пачки.

Data Encryption States Comparison Table

Состояние данных	Продвинутое шифрование	Стандартное шифрование
В транзите (in transit)	Данные шифруются с использованием управляемых клиентом ключей как можно раньше — на уровне HTTP-прокси или эквивалентной точки входа.	Все взаимодействия с интерфейсом Пачки и API шифруются через стандартные HTTPS и TLS 1.2+ по публичным сетям. Это гарантирует безопасность трафика между вами и Пачкой во время передачи.
В состоянии покоя (at rest)	Данные в базе остаются зашифрованными. Если третья сторона попытается получить доступ к работающей базе, данные будут возвращены в виде шифртекста.	Сервисные данные зашифрованы при хранении в Пачке с использованием ключей AES-256.
В использовании (in use)	Данные остаются зашифрованными даже при использовании и расшифровываются только при наличии конкретного бизнес-кейса. Любые операции расшифровки логируются и могут быть проверены через внешнюю систему SIEM.	Данные извлекаются из хранилищ и обрабатываются в открытом виде (plaintext).

5 Поддерживаемые KMS (на сегодня)

Yandex Key Management Service.
HashiCorp Vault. Также дополнительно в отличии от Yandex KMS через ограничения прав через контекст шифрования можно:
- Ограничить ключ конкретными чатами или списком чатов .
- Задать временное окно: например, разрешить расшифровку только до определённой даты или в конкретный день.
- Комбинировать условия (чат + дата/период) в политиках.