Шифрование данных для бизнеса: защита переписки с клиентами

За каждым заказом в WhatsApp, каждым сообщением в Instagram Direct и каждым обращением в поддержку в Telegram остаются данные клиентов: номера телефонов, адреса доставки, история переписки и токены доступа, которыми подключены ваши каналы. Шифрование данных для бизнеса превращает эти данные в нечитаемый шифротекст для всех, у кого нет ключа, — и пока они идут по сети, и пока лежат в базах данных и резервных копиях.

Главное

У шифрования данных для бизнеса два слоя: шифрование при передаче (TLS) защищает данные в движении, а шифрование при хранении (обычно AES) — сохранённые данные.
Токены доступа к каналам, API-ключи и секреты вебхуков — это учётные данные. Утёкший токен позволяет злоумышленнику действовать от имени вашей компании, поэтому шифруйте их на уровне полей.
Шифрование диска спасает от кражи накопителя, но не от взлома работающего сервера. Шифрование на уровне полей с ключами за пределами базы данных защищает такие поля даже в утёкшем дампе.
AES-256-GCM — аутентифицированное шифрование: оно скрывает данные и распознаёт подмену, и держится на том, что nonce никогда не повторяется с одним и тем же ключом.
Шифрование не останавливает тех, кому расшифровывать разрешено. Платформа ИИ-автоответов обязана читать сообщения, чтобы на них отвечать, поэтому контроль доступа и сроки хранения значат не меньше, чем сами шифры.

Что должно охватывать шифрование данных для бизнеса в компании, которая продаёт в чатах

У компании, которая продаёт в переписке — например, через ИИ-инбокс для WhatsApp, — свой перечень данных:

Учётные данные и секреты. Токены доступа к странице Facebook и к WhatsApp Business, токены Telegram-ботов, ключи ИИ-провайдеров, ключи платёжных провайдеров и секреты вебхуков.
Персональные данные клиентов. Номера телефонов, адреса электронной почты, адреса доставки и идентификаторы клиентов. В торговле через чаты номер телефона часто и есть идентификатор клиента.
История переписки и медиафайлы. Стенограммы диалогов, голосовые сообщения, фотографии и счета, которые присылают клиенты.
Пароли сотрудников. Их нужно хешировать, а не шифровать (подробнее ниже).
Устройства сотрудников. Ноутбуки и телефоны, с которых открывают инбокс или на которых лежат выгрузки. Включите FileVault или BitLocker, код блокировки и удалённое стирание.
Копии. Резервные копии, выгрузки CSV, логи и тестовые базы — их обычно защищают хуже, чем продакшен.

Простое правило для шифрования данных клиентов: всё, что даёт доступ или идентифицирует человека, шифруйте на уровне полей, а любой копии давайте ту же защиту, что и оригиналу.

Шифрование при хранении и шифрование при передаче

Шифрование при передаче защищает данные, пока они идут между браузером, вашим сервером и сторонними API. Шифрование при хранении, его же называют шифрованием в состоянии покоя, защищает данные на дисках, в базах данных и в резервных копиях.

Аспект	Шифрование при передаче	Шифрование при хранении
От чего защищает	Перехват, подмена, поддельные серверы	Кража дисков, утёкшие дампы, открытые бэкапы
Типичный стандарт	TLS 1.2 или TLS 1.3	AES-256, чаще всего AES-256-GCM
Где применяется	Браузер — приложение, вебхуки, вызовы API	Диск, база данных, отдельные поля, бэкапы
Что не покрывает	Данные после доставки и расшифровки	Данные в работе у запущенного приложения

NIST SP 800-52 Rev. 2 требует, чтобы TLS-серверы госорганов США поддерживали TLS 1.2, а к январю 2024 года — и TLS 1.3. Для любого бизнеса это разумная отправная точка: принимайте TLS 1.2 и 1.3, всё более старое отключайте.

TLS защищает только дорогу. WhatsApp Cloud API доставляет вебхуки по HTTPS, а в документации Meta сказано, что Cloud API расшифровывает входящие сообщения и передаёт их бизнесу, храня сообщения не дольше 30 дней. Дальше в дело вступают хранение и контроль доступа.

Шифрование диска, базы данных и на уровне полей

Шифрование при хранении бывает нескольких уровней:

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

Плата за это — поиск: по зашифрованной колонке обычный SQL-фильтр не отработает. На практике шифрование на уровне полей оставляют для секретов и особо чувствительных контактных данных. Если команде нужно искать клиента по телефону или почте, рядом с шифротекстом хранят хеш с ключом (слепой индекс) и ищут по нему.

AES-256-GCM: длина ключа и режим

AES описан в FIPS 197 с ключами 128, 192 и 256 бит. AES-256 использует самый длинный из трёх.

Режим важен не меньше длины ключа. GCM (NIST SP 800-38D) — это аутентифицированное шифрование: оно сохраняет конфиденциальность данных и показывает, менял ли кто-то шифротекст. Никогда не используйте nonce повторно с тем же ключом: повтор nonce разрушает гарантии GCM, поэтому доверьте генерацию nonce поддерживаемой библиотеке и никогда не пишите криптографию сами.

Как безопасно хранить API-ключи и токены доступа

Выбор зависит от того, нужно ли вам исходное значение обратно:

Шифруйте секреты, которые вы передаёте кому-то ещё: токены доступа WhatsApp и Instagram, токены Telegram-ботов, ключи ИИ-провайдеров и платёжные ключи. Используйте AES-GCM на уровне полей, а ключ держите вне базы данных.
Хешируйте секреты, которые вы только проверяете: пароли, партнёрские API-ключи и одноразовые коды. Хеш нельзя расшифровать обратно, но короткие и предсказуемые значения подбираются перебором, поэтому для паролей берите медленный хеш — Argon2id или bcrypt, — а для кодов HMAC с ключом.
Держите их вне логов, сообщений об ошибках, аналитики и URL.
Ограничивайте права и ротируйте токены. Запрашивайте только те разрешения, которые токену нужны, и заменяйте токены, когда уходит человек с доступом.

Шифрование при хранении не защищает токен, пока он расшифрован в памяти во время вызова API. Этот риск снижают укрепление сервера и минимальные привилегии.

Основы управления ключами шифрования

Шифрование настолько надёжно, насколько надёжно место хранения ключа. Классический провал — ключ рядом с данными: в той же базе или в закоммиченном конфиге.

Отделяйте ключи от данных. Держите их в менеджере секретов, KMS или конфигурации сервера, до которой база данных не дотягивается.
На масштабе используйте конвертное шифрование. Мастер-ключ шифрует ключи данных, поэтому его ротация не означает перешифровку всего.
Выводите отдельные ключи под каждую задачу функцией формирования ключей, например HKDF.
Продумайте ротацию и восстановление. Потерянный ключ — это потерянные данные, в том числе в резервных копиях.

Контроль доступа и минимальные привилегии: одного шифрования мало

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

То же самое происходит и выше по цепочке. Технический документ WhatsApp о безопасности не считает переписку с компаниями на Cloud API защищённой сквозным шифрованием, потому что сообщения не доставляются напрямую на конечную точку, которой управляет бизнес. Перед выбором схемы посмотрите WhatsApp Business Cloud API против приложения Business.

Дальше вопрос в том, кто вообще дотягивается до данных:

Контроль доступа по принципу минимальных привилегий: давайте каждому сотруднику наименьшую роль, с которой он справится. Оператору, который отвечает в чатах, биллинг не нужен.
Надёжный вход: добавьте второй шаг проверки и отзывайте сессии при выходе.
Изоляция между компаниями: каждый запрос должен подтверждать, что вызывающий относится именно к этому бизнесу.
Журналы аудита и сроки хранения: фиксируйте привилегированные действия и держите переписку ровно столько, сколько нужно.

Резервные копии, выгрузки и сроки хранения

Резервные копии — это полные копии клиентских данных, которые обычно хранят дольше и проверяют реже, чем продакшен. Шифруйте файлы бэкапов, ограничьте круг тех, кто может их скачать, проверяйте восстановление вместе с восстановлением ключей и удаляйте старые выгрузки CSV, разосланные по почте или в чатах.

У шифрования есть и юридический вес. Статья 32 GDPR называет шифрование мерой безопасности, а статья 34(3)(a) разрешает оператору данных не уведомлять пострадавших об утечке, если шифрование сделало данные нечитаемыми для посторонних. Обязанность по статье 33 уведомить надзорный орган в течение 72 часов с момента, когда об утечке стало известно, действует отдельно. Саудовский PDPL и турецкий KVKK тоже устанавливают 72-часовой срок для регулятора.

Это общая информация, а не юридическая консультация. Применяется ли GDPR или другой закон и подходит ли исключение к конкретной утечке, зависит от вашей ситуации, поэтому советуйтесь с квалифицированным юристом.

Вопросы, которые стоит задать любому поставщику чат-платформы или CRM

Прежде чем подключать каналы, отправьте эти вопросы о безопасности письменной анкетой:

Какие версии TLS принимают ваши эндпоинты?
Какие данные зашифрованы при хранении и на каком уровне? Входит ли туда содержимое сообщений?
Шифруются ли токены каналов и API-ключи на уровне полей и где хранится ключ?
Шифруются ли резервные копии и у кого есть к ним доступ?
Могут ли ваши сотрудники читать наши диалоги и логируется ли такой доступ?
Какие роли и разрешения мы можем настроить для своей команды?
Как наши данные изолированы от данных других клиентов?
Используются ли наши переписки для обучения ИИ-моделей — вами или вашими ИИ-провайдерами?
Кто ваши субобработчики и где хранятся данные?
Подпишете ли вы DPA и как быстро данные удаляются после нашего ухода?

Относитесь скептически к ответам вроде «шифрование военного уровня» или «все данные полностью зашифрованы». Поставщик, которому можно доверять, называет алгоритм, уровень и пробелы.

Что Raabt шифрует и защищает сегодня

Каждый пункт ниже отражает код Raabt по состоянию на сентябрь 2026 года.

Шифрование на уровне полей: чувствительные поля шифруются на уровне приложения алгоритмом AES-256-GCM. Новые записи используют ключ, выведенный через HKDF-SHA256, а более старые значения перешифровываются им при следующем сохранении. Приложение не запускается без ключа длиной не менее 32 символов.
Что зашифровано: учётные данные и токены (токены доступа к каналам Facebook, Instagram, WhatsApp и Telegram, API-ключи ИИ- и платёжных провайдеров, секреты вебхуков) и выбранные контактные данные (номера телефонов, адреса электронной почты и адреса в заказах клиентов).
Хеширование: пароли используют Argon2id (19 МиБ памяти, 2 итерации), а старые хеши bcrypt обновляются при входе. Секреты партнёрских API-ключей хранятся только в виде хешей SHA-256.
Вход: при входе по почте и паролю до выдачи сессии требуется одноразовый код, отправленный на почту пользователя (вход через Google этот код не использует). Коды хранятся только как хеши HMAC-SHA256, истекают и срабатывают один раз.
Доступ команды: четыре роли (владелец, администратор, оператор, наблюдатель) с разрешениями по разделам. Доступ к биллингу нельзя делегировать никому, кроме владельца.
Изоляция: эндпоинты бизнеса подтверждают, что вызывающий — активный участник этого бизнеса, и иначе возвращают «не найдено».
Вебхуки и медиа: вебхуки Meta отклоняются без действительной подписи X-Hub-Signature-256, вебхуки Telegram требуют секретный токен, а вложения отдаются только по подписанным ссылкам с ограниченным сроком действия.
Инфраструктура: приложение не выставлено в интернет напрямую; публичный трафик доходит до него через Cloudflare Tunnel. В логах ошибок базы данных никогда нет параметров запросов, поэтому номера телефонов и адреса почты туда не попадают.
Журнал аудита администраторов платформы: действия администраторов платформы пишутся в журнал аудита, куда можно только добавлять записи (кто, что, когда, IP, со снимками «до/после», в которых секреты замаскированы). Это не журнал сообщений клиентов.

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

Запросы Meta на удаление данных возвращают код подтверждения со ссылкой на статус на нашей странице удаления данных. Для удаления аккаунта нужны пароль и одноразовый код из письма; аккаунт деактивируется, а его адрес почты обезличивается.

Чек-лист: шифрование данных для бизнеса — порядок внедрения для небольшой команды

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

Отдавайте всё по HTTPS и только с TLS 1.2 или 1.3.
Включите полнодисковое шифрование и блокировку экрана на каждом устройстве, с которого открывают клиентские чаты.
Переведите токены и API-ключи на шифрование на уровне полей с отдельными ключами.
Хешируйте пароли через Argon2id или bcrypt и добавьте второй шаг входа.
Зашифруйте номера телефонов, адреса почты и адреса клиентов.
Шифруйте резервные копии, раздайте роли по минимальным привилегиям и задайте сроки хранения переписки.
Отправьте список вопросов каждому чат-сервису, CRM и ИИ-инструменту, которым вы пользуетесь.

Частые вопросы

Какие данные компании нужно шифровать?

Начните с того, что даёт доступ или идентифицирует человека: токены каналов, API-ключи, секреты вебхуков, а также номера телефонов, адреса почты и адреса клиентов. Затем закройте историю переписки, устройства сотрудников и каждую резервную копию или выгрузку.

Чем шифрование при передаче отличается от шифрования в состоянии покоя?

Шифрование при передаче, обычно TLS, защищает данные в движении между устройствами, серверами и API. Шифрование при хранении, обычно AES, защищает сохранённые данные.

Насколько надёжно шифрование AES-256 для защиты данных клиентов?

AES-256 стойкий, но слабым местом редко оказывается сам алгоритм. Обычно подводят плохое хранение ключей, повторно использованные nonce, слишком широкий доступ сотрудников и незащищённые резервные копии.

Как безопасно хранить API-ключи и токены доступа?

Токены, которые нужно использовать повторно, шифруйте через AES-GCM на уровне полей, а ключ держите вне базы данных. Секреты, которые вы только проверяете, — пароли и партнёрские API-ключи — хешируйте.

Если у меня HTTPS, данные на сервере защищены?

Нет. HTTPS защищает данные только при передаче. На сервере всё зависит от шифрования при хранении, контроля доступа и обращения с резервными копиями.

Что спросить у поставщика CRM или чат-бота о безопасности данных?

Спросите, какие версии TLS он принимает, что зашифровано при хранении и на каком уровне, где хранятся ключи, логируется ли доступ сотрудников к переписке, кто его субобработчики и где хранятся данные, используются ли чаты для обучения ИИ-моделей и подпишет ли он DPA со сроком удаления.

Готовы вести переписку в ИИ-инбоксе, который шифрует токены каналов и выбранные контактные данные клиентов? Начать бесплатно.