Проверяйте весь маршрут чата, а не только ярлык шифрования
Сквозное шифрование не позволяет посредникам прочитать содержимое сообщений при передаче между целевыми конечными точками, но само по себе оно не способно обеспечить защиту всех аспектов общения в приложении-компаньоне. Полезный вопрос заключается не просто в том, заявляет ли приложение о «шифровании». Определите конечную точку отправителя, каждую службу или этап обработки, конечную точку получателя, привязанные устройства, экспортируемые файлы и резервные копии. Затем выясните, где данные существуют в открытом виде, кто контролирует ключи, как отображаются изменения идентификационных данных и какие метаданные остаются за рамками защиты содержимого. Четкое заявление должно выдерживать такую пошаговую проверку маршрута; абстрактный значок не следует воспринимать как исчерпывающий ответ по безопасности.
Начните с фиксации пути сообщения
Опишите схему одного обычного диалога от момента ввода текста до его отображения. Укажите устройство, на котором вводится текст, компонент, который его шифрует, сетевые службы, передающие его, устройство или процесс, расшифровывающий его, и каждое место, где может быть сохранена копия в открытом виде. В глоссарии NIST отмечается, что информация о маршрутизации может оставаться видимой даже при использовании сквозного шифрования. Это различие помогает избежать распространенной категориальной ошибки: защищенное содержимое — это не то же самое, что невидимый трафик. Зафиксируйте, распространяются ли заявления о защите на текст, вложения, голосовые сообщения, изображения, реакции, поисковые индексы и уведомления. Если в документации говорится лишь о шифровании «при передаче» (in transit), не следует самовольно приравнивать эту формулировку к сквозной защите.
Проверьте, кто хранит ключи и как меняются идентификаторы
В понятном описании должно быть указано, где создаются ключи, как подключаются новые устройства и может ли поставщик получить ключ расшифровки. Обратите внимание на наличие методов проверки, таких как код безопасности (safety number), список устройств, отпечаток ключа или явное уведомление об изменении ключа идентификации. Принципы безопасной связи NCSC рассматривают аутентификацию участников отдельно от защиты транспортного уровня. Это крайне важно, поскольку шифрование для неверной учетной записи или незамеченного замененного устройства будет исправно защищать переписку, но уже для нежелательной конечной точки. Также изучите логику восстановления и сброса аккаунта. Если восстановление незаметно возобновляет доступ на новом устройстве, обратите внимание на то, какие подтверждения приходят на существующие устройства и какие старые сессии остаются активными.
Считайте каждое привязанное устройство отдельной конечной точкой
Телефоны, планшеты, клиенты для настольных ПК и сеансы браузера расширяют перечень мест, где открытый текст может быть прочитан. Откройте страницу устройств или сессий учетной записи и сопоставьте ее со списком устройств, которые вы физически опознаете. Фиксируйте время последнего использования только как подсказку, а не как доказательство владения. Удалите неизвестное или вышедшее из употребления устройство, затем проверьте, подтверждает ли сервис отзыв доступа и остается ли загруженная локальная история вне досягаемости учетной записи. Руководство по протоколам NCSC подчеркивает, что конечные точки могут быть скомпрометированы, поэтому возможность снижения уровня доверия или его отзыва имеет принципиальное значение. Надежная архитектура передачи данных не может защитить от незаблокированного экрана, вредоносного расширения, скопированного уведомления, снимка экрана или сохранения данных получателем, у которого есть легитимный доступ к их прочтению.
Проверяйте резервное копирование, экспорт и синхронизацию как отдельные маршруты
Не считайте, что шифрование текущего чата автоматически распространяется на резервное копирование в облако, перенос между устройствами, файлы экспорта или поисковые индексы. Например, в текущей справочной документации Signal безопасное резервное копирование, локальные файлы резервных копий и прямая передача между устройствами описаны как отдельные сценарии со своими собственными данными для восстановления и ограничениями совместимости. Главный вывод здесь заключается в самом факте разделения, а не в том, что все сервисы работают так же, как Signal. Применительно к используемому приложению выясните, является ли резервное копирование опциональным, где хранится секрет восстановления, какие устройства могут его восстановить и шифруются ли экспортированные архивы после загрузки. Проведите тест с нейтральным содержимым и удалите тестовую копию, вместо того чтобы отправлять личные диалоги по непроверенному пути резервного копирования.
Разделяйте конфиденциальность контента, метаданные и операции сервиса
Даже при зашифрованном содержимом сервису могут требоваться идентификаторы учетных записей, время доставки, сведения об устройствах, журналы подключений или другие данные маршрутизации. Руководство NCSC рекомендует понимать, какие метаданные собираются, и ограничивать их сбор только необходимыми целями. Ознакомьтесь с актуальной информацией о конфиденциальности продукта, чтобы узнать о категориях данных, целях их использования, сроках хранения и получателях; не делайте выводов на основе одного лишь значка замка. Также узнайте, как работают борьба со спамом, жалобы на нарушения, поиск по содержимому и предпросмотр ссылок. Добровольная жалоба может отправить на сервер фрагмент открытого текста или контекст, тогда как локальный поисковый индекс может оставаться на устройстве. Эти пути зависят от архитектуры конкретного решения. Задокументируйте заявления провайдера, доступные вам элементы управления в интерфейсе и оставшиеся без ответа вопросы.
Определите границу обработки с помощью ИИ
Функциям компаньона может требоваться обработка открытого текста для генерации ответа. Эта конечная точка обработки должна быть четко отражена в описании маршрута. Выясните, где заканчивается шифрование: на вашем устройстве, на сервере под контролем провайдера или на другом конкретном компоненте; выполняется ли обработка локально или удаленно; получает ли контент третья сторона; и могут ли данные диалогов повторно использоваться в соответствии с отдельными настройками. Не стоит утверждать, что удаленная обработка и сквозное шифрование в принципе несовместимы, поскольку архитектуры бывают разными. Вместо этого требуйте точной документации о том, кто, что, для какой задачи и на какой срок может расшифровывать. Если сервис ограничивается лишь общими маркетинговыми формулировками, считайте границу обработки неизвестной, не строя догадок.
Проведите проверку на нейтральных данных и сохраните результат
Используйте не содержащий секретов тестовый диалог. Проверьте индикаторы шифрования на обоих концах, добавьте и удалите привязанное устройство, проследите за уведомлениями о смене ключей, изучите предпросмотр в уведомлениях, просмотрите параметры резервного копирования и экспорта и удалите тестовые данные с помощью предусмотренных средств. Составьте краткий отчет: версия приложения, учетная запись, протестированные типы контента, список конечных точек, статус резервного копирования, объяснение по метаданным, граница обработки, нерешенные вопросы и повод для следующей проверки. Повторите аудит после крупного обновления приложения, смены устройства или существенного изменения политик. Итогом должен быть статус «проверено для этого пути», «частично проверено» или «неизвестно», а не абстрактная метка «безопасно / небезопасно». Сквозное шифрование — весомый аргумент, но только в тех границах, которые вы реально подтвердили.
Частые вопросы
Доказывает ли значок замка наличие сквозного шифрования?
Нет. Ознакомьтесь с документацией провайдера по маршрутам, ключам, конечным точкам и резервному копированию, а также уточните, на какие типы контента распространяется данный индикатор.
Может ли сквозное шифрование защитить метаданные?
Некоторые архитектурные решения позволяют сократить объем определенных метаданных, однако само по себе наличие шифрования не дает ответа на вопрос, какие данные о маршрутизации или учетной записи остаются видимыми.
Удаляет ли отвязка устройства его локальную историю?
Не обязательно. Отзыв доступа может заблокировать дальнейшее использование учетной записи, однако для файлов, уже сохраненных на этом устройстве, требуются отдельные меры очистки.
