Почему PPAP вреден для безопасности электронной почты? Как делать правильно

«Действительно ли безопасно отправлять ZIP-архив с паролем, а затем пароль от него - отдельным письмом?» Этот вопрос до сих пор возникает регулярно. Внешне это выглядит безопасно, ведь данные зашифрованы, но именно в этом и кроется ловушка на практике.

Так называемый PPAP слабо защищает от перехвата, недостаточен как защита от ошибочной отправки, а вдобавок склонен мешать проверке на пути следования почты - поэтому в современной практике защиты электронной почты его сложно рекомендовать.¹²³⁴

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

1. Сначала вывод

Отказ от PPAP - это не отказ от шифрования как такового. Отказаться нужно от самой схемы: «зашифровать вложение в ZIP-архив и позже отправить пароль тем же почтовым каналом».

Вместо этого стоит рассмотреть три следующих подхода.

1. Для обычной деловой переписки исходить из защиты канала передачи, такой как TLS / STARTTLS.⁷¹⁰
2. Если нужна подлинность или шифрование самого письма, использовать механизм вроде S/MIME.⁵³⁶
3. Для передачи конфиденциальных файлов вместо вложений использовать загрузку с аутентификацией или обмен с контролем доступа.⁴⁸⁹

Иными словами, важно не пытаться решить все проблемы электронной почты одним паролем от ZIP-архива.

2. Что такое PPAP на самом деле

Под PPAP здесь обычно понимают следующую последовательность действий.

1. Упаковать файл в ZIP-архив с паролем
2. Отправить архив первым письмом
3. Отправить пароль вторым письмом

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

PPAP далеко не так универсален, как кажется на первый взгляд: проблема в том, что он «выглядит вроде бы безопасным», но не защищает самое важное.

3. Почему PPAP - это плохо

3.1 Слабая защита от перехвата

Кабинет министров Японии заключил, что автоматическая отправка пароля по тому же каналу, что и сам ZIP-файл, - неприемлемый метод.¹ Важно, что проектирование теряет смысл, если учитывать только сам факт шифрования файла, но не то, как передаётся ключ.

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

3.2 Недостаточная защита от ошибочной отправки

Некоторые считают PPAP защитой от ошибочной отправки, но и здесь он слаб.

В модельных ответах IPA к экзамену Applied Information Technology Engineer в качестве проблемы PPAP указывается, что при ошибочной отправке основного письма пароль для расшифровки тоже попадёт не тому получателю.³ В документе Цифрового агентства Японии приводится схожий вывод: «отправка отдельным письмом означает отправку тому же самому адресату, поэтому это не работает как контроль».⁴

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

3.3 Мешает проверке на вредоносное ПО

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

IPA предупреждает, что во вредоносных письмах Emotet с ZIP-вложениями, защищёнными паролем, из-за шифрования вложения высока вероятность того, что оно обойдёт обнаружение и карантин средств защиты на пути доставки почты и дойдёт до получателя.²

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

3.4 Не обеспечивает подлинность и контроль доступа

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

При этом IPA рассматривает электронную почту с цифровой подписью, такую как S/MIME, что по смыслу связано с ней как с альтернативой PPAP.⁵⁶ А в материалах IPA по веб-безопасности указывается, что для веб-сайтов, работающих с непубличной информацией, необходимы функции аутентификации и контроля доступа.⁸

Если сопоставить эти два факта, ответ становится довольно очевидным.

• Если нужна подлинность письма и обнаружение подделки - S/MIME
• Если нужны права на просмотр файла и управление их отзывом - загрузка с аутентификацией

Отправка пароля от ZIP-архива отдельным письмом не даёт чёткого ответа ни на один из этих запросов.

4. Правильный подход - «разделение по назначению»

Требование «хотим отправить безопасно» на самом деле не единственное. Если не разделить его на составляющие, попытка решить всё через PPAP разрушает архитектуру решения.

4.1 Обычная деловая переписка

Для обычной деловой переписки прежде всего исходят из защиты канала передачи, такой как TLS / STARTTLS.⁷¹⁰ Далее, если нужна подлинность отправителя, обнаружение подделки или шифрование самого текста письма, логично рассмотреть S/MIME.⁵³⁶

4.2 Передача конфиденциальных файлов

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

Например, следующие требования удобнее реализовать на стороне веб-сайта, чем через вложения.

• Загрузка доступна только после входа в систему
• Ссылку можно ограничить по сроку действия
• Права можно разделить для разных получателей
• При необходимости можно вести историю обращений

4.3 Когда вложение действительно необходимо

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

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

5. Порядок перехода для малого и среднего бизнеса

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

5.1 Что нужно остановить в первую очередь

• Автоматическое шифрование в ZIP
• Автоматическую отправку пароля отдельным письмом по тому же почтовому каналу
• Универсальное правило «все важные файлы - через PPAP»

5.2 Что нужно определить дальше

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

5.3 Подход к минимальной конфигурации

Для начала достаточно разделить процессы всего на два направления.

1. Обычная почта
   • Деловая переписка
   • S/MIME по мере необходимости
2. Конфиденциальные файлы
   • Загрузка с аутентификацией
   • Настройка прав доступа
   • Обмен с ограниченным сроком действия

Если оставить это разделение расплывчатым, на местах в итоге снова вернутся к «PPAP на всякий случай».

6. Схема принятия решения

flowchart TD
    A[Что нужно передать получателю] --> B{Это конфиденциальный файл?}
    B -- Нет --> C[Обычная деловая почта]
    C --> C1[Отправка на основе TLS / STARTTLS]
    C --> C2[Если важна подлинность или шифрование - S/MIME]

    B -- Да --> D{Получатель может войти в систему, чтобы получить файл?}
    D -- Да --> E[Загрузка с аутентификацией / обмен с контролем доступа]
    E --> E1[При необходимости настроить права, срок действия и отзыв]

    D -- Нет --> F{Вложение действительно необходимо?}
    F -- Да --> G[Зашифрованный файл + пароль вручную по другому каналу]
    F -- Нет --> E

Важно в этой схеме то, что PPAP не рассматривается как универсальное промежуточное решение. Электронную почту и передачу файлов проще проектировать, если рассматривать их отдельно друг от друга.

7. Частые заблуждения

7.1 «ZIP-архив зашифрован, значит это безопасно»

Даже при наличии шифрования этого недостаточно, если способ передачи ключа слаб. Более того, ZIP-архив с паролем может мешать проверке на пути следования.¹²

7.2 «Достаточно отправить отдельным письмом»

Досылка тому же получателю по тому же почтовому каналу не является надёжным контролем.¹⁴

7.3 «Если отказаться от PPAP, вложения станут невозможны»

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

7.4 «S/MIME подходит только крупным компаниям и нереалистичен»

Поддержку со стороны получателя действительно нужно проверять, но по крайней мере логика S/MIME куда лучше соответствует тому, что именно требуется защитить, чем PPAP. А для получателей, которым S/MIME не подходит, остаётся другой вариант - загрузка с аутентификацией.

8. Итог

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

• Отправка отдельным письмом по тому же почтовому каналу даёт слабую конфиденциальность
• Недостаточная защита от ошибочной отправки
• ZIP-архив с паролем мешает проверке на пути следования
• Не обеспечивается ни подлинность отправителя, ни контроль доступа

¹²³⁴

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

Если сформулировать одной фразой:

Отказ от PPAP - это не отказ от шифрования, а отказ от неправильного контроля в пользу контроля, соответствующего цели.

Похожие статьи

• Как спроектировать массовую рассылку писем для малого и среднего бизнеса без привязки к конкретному сервису
• Как связать статьи и страницы услуг - основы проектирования внутренних ссылок
• Как создавать страницы услуг - порядок структурирования для технической сферы и B2B

Источники

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

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

Вопросы, которые часто возникают при консультациях по теме статьи.

Что такое PPAP?

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

Почему PPAP опасен?

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

Что использовать вместо PPAP?

Базовый подход - разделить задачи по назначению на три группы. Для обычной деловой переписки исходят из защиты канала передачи, такой как TLS или STARTTLS, а если нужна подлинность или шифрование самого письма, используют S/MIME. Для передачи конфиденциальных файлов вместо вложений лучше использовать загрузку с аутентификацией или обмен с контролем доступа - тогда можно настраивать права, ссылки с ограниченным сроком действия и отзыв доступа. Важно не пытаться решить все проблемы электронной почты одним паролем от ZIP-архива.

Что делать, если файл всё же необходимо отправить вложением?

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

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.