Сквозное шифрование и шифрование при передаче: в чём разница

Сквозное шифрование (end-to-end, E2E) значит, что сообщение расшифровывается только на устройстве получателя — сервер мессенджера видит лишь набор зашифрованных байт и прочитать переписку не может физически. Шифрование при передаче (TLS/HTTPS) защищает данные лишь по пути к серверу: дальше провайдер хранит сообщения в виде, пригодном для чтения его же инфраструктурой, — это разные гарантии, и путать их дорого для бизнеса, который работает с персональными данными клиентов.

сквозное шифрование и шифрование при передаче: в чём разница

Разница не в «сильнее» или «слабее», а в том, кто держит ключ. При шифровании на транспортном уровне ключи генерирует сервер мессенджера и сам же расшифровывает трафик на входе — это обычный TLS, тот же протокол, что у любого сайта с замком в адресной строке браузера. Он закрывает канал от перехвата в открытой Wi-Fi-сети кафе или в офисном роутере, но не закрывает переписку от самого сервиса: администратор сервера технически может выгрузить историю чата в читаемом виде — сам, по запросу правоохранителей или после взлома базы.

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

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

что именно защищено на каждом уровне

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

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

В компании на 60 сотрудников бухгалтерия вечером в пятницу пересылает в корпоративном чате сканы паспортов клиентов и подписанные договоры — обычная рутина перед закрытием месяца. В карточке мессенджера в описании написано «защищённый обмен сообщениями», в договоре с вендором — «шифрование данных». Но когда через полгода служба безопасности готовит компанию к проверке по 152-ФЗ и запрашивает у поставщика мессенджера логи переписки для внутреннего аудита, выясняется: сообщения хранятся на сервере провайдера в открытом виде, потому что «шифрование» в описании относится только к каналу передачи, а не к содержимому чата на сервере.

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

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

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

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

чек-лист для ИБ-отдела

• ✓для обмена персональными данными клиентов и договорами использовать только режимы с подтверждённым сквозным шифрованием, а не общий групповой чат «для всего»
• ✓проверить, входит ли выбранный мессенджер в реестр российского ПО — для госзаказчиков и части коммерческих тендеров это обязательное условие при выборе поставщика связи
• ✓развести каналы: технические уведомления от учётных систем — в один канал, документы с персональными данными — в другой, с более строгим режимом доступа и сроком хранения
• ✓закрепить в регламенте прямой запрет на пересылку сканов документов в общий чат без шифрования, а не оставлять решение на усмотрение конкретного сотрудника
• ✓прописать в договоре с поставщиком мессенджера, кто и на каком основании может получить доступ к содержимому переписки — без этого пункта разбираться с инцидентом придётся постфактум и без рычагов давления

Отдельная сложность в том, что настоящие E2E-режимы (тот же Secret Chats в Telegram) обычно не синхронизируются между устройствами и не хранят историю на сервере. Это неудобно для командной работы, но именно так работает сквозное шифрование: сервер физически не может отдать историю на новое устройство, потому что не хранит ключ расшифровки. Компромисс между удобством и защитой здесь настоящий, и его стоит проговаривать с сотрудниками заранее, а не после инцидента.

что делать, если утечка данных через мессенджер повторяется

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

В такой связке 1С формирует сообщение с суммой заказа, ИНН контрагента или номером счёта и отправляет его через API мессенджера от имени бота. Даже если сам мессенджер поддерживает сквозное шифрование для ручной переписки сотрудников, API-интеграция почти всегда идёт через обычный TLS-канал, то есть данные из 1С оседают на сервере мессенджера в читаемом виде — ровно то, от чего пытались уйти, меняя приложение. Ещё один частый источник повторных утечек — теневые каналы: сотрудники сами заводят рабочие группы в личных аккаунтах или пересылают документы в собственное облако «для удобства», в обход любых корпоративных настроек шифрования.

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

как предотвратить утечки при интеграции мессенджера с 1С

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

что проверить перед стартом интеграции

Второй момент — версия учётной системы. Старые конфигурации 1С нередко используют устаревшие протоколы обмена без поддержки актуального TLS и без токенной авторизации API, и тогда любая интеграция с мессенджером наследует эту слабость независимо от того, что обещает сам мессенджер в своей рекламе. Обновление 1С до поддерживаемой версии закрывает эту брешь на уровне протокола обмена, а не на уровне отдельного чата, и снимает вопрос сразу для всех интеграций компании, а не только для одной.

Третий момент — где физически стоит сервер, который связывает 1С и мессенджер. Промежуточный сервис для отправки уведомлений часто ставят на тот же сервер, что и саму базу 1С, и любая уязвимость в нём открывает доступ сразу к учётным данным и к каналу связи с клиентами. Разделение ролей — база отдельно, интеграционный слой отдельно, на контролируемой инфраструктуре — снижает эту связку рисков вдвое просто за счёт того, что взлом одного узла не даёт доступа ко второму.

Мы в ukved настраиваем такие интеграции и проверяем их именно с этой стороны: не «какой мессенджер выбрать», а какой канал реально защищён и что из 1С в него уходит. Сопровождение и работа сисадмина стоят от 3800 руб/час, аренда отдельного сервера под учётную систему — от 3300 руб/мес. На практике часто дешевле развернуть промежуточный контролируемый сервер для интеграции с мессенджером, чем потом разбирать утечку персональных данных клиентов и объяснять её заказчику или проверяющему.

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

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

Шифрование при передаче (TLS) защищает канал до сервера мессенджера, но на самом сервере переписка хранится в читаемом виде, и провайдер технически может её открыть. Сквозное шифрование (E2E) означает, что ключ есть только у отправителя и получателя — сервер видит лишь зашифрованные данные и прочитать их не может.

Какие мессенджеры используют сквозное шифрование по умолчанию для всех чатов?

По умолчанию для всей переписки, включая групповые чаты, E2E применяют немногие сервисы. В Telegram, например, сквозное шифрование действует только в режиме Secret Chats, а обычные облачные чаты и API-боты защищены лишь шифрованием при передаче, что важно учитывать при работе с персональными данными клиентов.

Нужно ли сквозное шифрование для B2B-переписки, если в чате нет персональных данных?

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

Как проверить, что интеграция мессенджера с 1С не раскрывает данные клиентов?

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

Что делать, если утечка персональных данных через мессенджер уже произошла?

Сначала зафиксировать, какие именно данные и через какой канал утекли — это нужно для отчёта перед проверяющим органом по 152-ФЗ. Затем закрыть источник: пересмотреть, что уходит в сообщения из учётной системы, и перевести обмен персональными данными на канал со сквозным шифрованием.