# Что защищает сквозное шифрование, а что нет

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

Сквозное шифрование предназначено для обеспечения возможности чтения содержимого сообщения только на взаимодействующих конечных точках. В приватном разговоре это устройства участников. В правильно спроектированной и реализованной системе служба, передающая зашифрованные сообщения, не может расшифровать их содержимое. [Архитектура безопасности обмена сообщениями IETF](https://www.rfc-editor.org/rfc/rfc9750.html#section-8.2.1) описывает это разделение между участниками и службой доставки.

## Между какими устройствами защищено сообщение?

Сообщение может быть зашифровано во время перемещения по Интернету и при этом оставаться доступным для чтения обслуживающей его службой.

Возьмем простой сервис, который использует TLS для защиты соединения между вашим телефоном и его сервером. Сервер — это один конец этого защищенного соединения. Он может получать читаемый текст, обрабатывать его, а затем отправлять получателю через другое зашифрованное соединение. [TLS защищает связь между своими конечными точками](https://www.rfc-editor.org/rfc/rfc8446.html#section-1), которыми могут быть устройство и сервер.

Сквозное шифрование защищает содержимое и при передаче через промежуточный сервис. Устройство отправителя шифрует сообщение перед доставкой, а устройство получателя расшифровывает его. Система также может использовать TLS, защищая сетевые соединения, по которым передается уже зашифрованное сообщение.

| Этап простого обмена со сквозным шифрованием | Что происходит с контентом |
|---|---|
| Устройство отправителя | Текст составлен и зашифрован. |
| Служба доставки | Служба передает зашифрованные данные. У неё нет ключей, необходимых для расшифровки содержимого. |
| Устройство получателя | Сообщение расшифровывается, и получатель может его прочитать. |

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

## Ваши устройства участвуют в разговоре

Перед отправкой необходимо прочитать текст. Получатель должен прочитать его после получения. В эти моменты слова доступны на устройствах на обоих концах.

Тот, кто может просматривать открытый разговор, может прочитать его, не нарушая шифрования. Вредоносное ПО, имеющее достаточный доступ к устройству, также может захватывать текст по мере его ввода или отображения. Последствия компрометации устройства зависят от полученного доступа и конструкции системы, как поясняет [обсуждение IETF компрометации конечных точек](https://www.rfc-editor.org/rfc/rfc9750.html#section-8.3).

Тот же разговор также может быть доступен на подключенном компьютере или планшете. Просмотрите эти устройства, удалите доступ, который вам больше не нужен, и обновляйте программное обеспечение. Это практические меры предосторожности, включенные в [руководство CISA по мобильной связи](https://www.govinfo.gov/content/pkg/GOVPUB-HS2-PURL-gpo250552/pdf/GOVPUB-HS2-PURL-gpo250552.pdf).

## Резервная копия имеет собственную защиту

Настройки, используемые для текущей переписки, сами по себе не говорят вам, как защищена сохраненная резервная копия.

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

[Руководство по шифрованию Electronic Frontier Foundation](https://ssd.eff.org/module/what-should-i-know-about-encryption) особенно рекомендует проверять шифрование резервных копий наряду с защитой, используемой при передаче.

## Слова — это только часть информации

Сохранение содержания сообщения в секрете не скрывает автоматически всю сопутствующую активность.

В зависимости от службы и наблюдателя такая информация, как время соединения, идентификаторы учетных записей, сетевые адреса или объем передаваемых данных, может оставаться доступной. Эти детали часто называют метаданными. Сетевой наблюдатель и поставщик услуг обмена сообщениями не обязательно будут видеть одну и ту же информацию.

Закономерности трафика могут рассказать что-то об обмене, даже если его содержимое нечитабельно. [Руководство IETF по конфиденциальности](https://www.rfc-editor.org/rfc/rfc6973.html#section-3.4) называет это анализом трафика.

## Проверьте, кто на другом конце

Знакомого имени профиля или фотографии недостаточно для подтверждения конфиденциального обмена.

Если приложение обеспечивает проверку контакта, сравните отпечаток ключа или защитный код с другим человеком лично или через независимый канал, которому вы уже доверяете. Если кто-то неожиданно свяжется с вами из новой учетной записи, подтвердите изменение через знакомый канал связи, прежде чем делиться конфиденциальной информацией.

Это помогает связать криптографический идентификатор с человеком, с которым вы хотите связаться. [Объяснение EFF о проверке отпечатков ключей](https://ssd.eff.org/module/deep-dive-end-end-encryption-how-do-public-key-encryption-systems-work) показывает, почему эта проверка важна.

## Перед следующим конфиденциальным сообщением

Начните с информации, которую вам действительно нужно отправить. Не включайте детали, которые не нужны получателю. Затем проверьте те части обмена, которые имеют значение для этой информации:

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

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

## Роль Layergram

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

При этом выбранный контент помещается на отдельный зашифрованный уровень, прежде чем он достигнет чата, используемого для отправки. Чат по-прежнему может сохранять информацию об обмене, а устройства и получатель остаются частью риска. Вы можете следить за рабочим процессом в разделе [Как работает Layergram](https://layergram.app/ru/%D0%BA%D0%B0%D0%BA-%D1%8D%D1%82%D0%BE-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D1%82/) и прочитать конкретные ограничения в нашем [описании безопасности](https://layergram.app/ru/%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D1%8C/).

Canonical HTML: https://layergram.app/ru/insights/%D1%87%D1%82%D0%BE-%D0%B7%D0%B0%D1%89%D0%B8%D1%89%D0%B0%D0%B5%D1%82-%D1%81%D0%BA%D0%B2%D0%BE%D0%B7%D0%BD%D0%BE%D0%B5-%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5/

Language: ru

Publisher: Layergram

Last updated: 2026-10-13T12:28:41Z