Отчёт о найденных дырах уходит клиенту: шифрование и своё хранилище

MAATRIX

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

Почему отчёт пентестера — самый токсичный документ в проекте

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

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

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

Где чаще всего утекает отчёт: разбор популярных способов передачи

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

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

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

Мессенджеры. Удобно, но файл оседает в чате навсегда (если явно не настроено исчезающее сообщение), синхронизируется на все устройства заказчика, включая рабочий телефон, который сам может быть объектом следующего аудита.

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

Принцип: свой сервер как контролируемый канал, а не просто ещё одно хранилище

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

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

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

Как настроить приём и раздачу отчётов на практике

Дальше — рабочая последовательность действий для отдельного арендованного сервера, который используется только под передачу отчётов (не смешивайте эту роль с сервером, где крутятся стенды для тестирования, — разделение ролей само по себе снижает риск).

Шаг 1. Зашифрованный раздел под входящие/исходящие документы.

# создаём отдельный зашифрованный раздел под файлы отчётов
cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 reports_vault
mkfs.ext4 /dev/mapper/reports_vault
mkdir -p /srv/reports
mount /dev/mapper/reports_vault /srv/reports

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

Шаг 2. Веб-сервер только для раздачи, без индексации и с базовой авторизацией.

location /delivery/ {
    alias /srv/reports/outgoing/;
    autoindex off;
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd_reports;
}

autoindex off обязателен — иначе при угадывании базового URL клиент (или кто угодно) увидит список всех файлов в директории, включая отчёты для других заказчиков.

Шаг 3. Ограничение времени жизни ссылки.

Здесь есть два практичных варианта в зависимости от того, сколько времени вы готовы тратить на настройку:

• *Простой:* отдельная поддиректория и пароль на каждого клиента, вручную удаляемая после подтверждённого скачивания.
• *Автоматизированный:* модуль nginx secure_link с параметром истечения — ссылка перестаёт работать через заданное число часов после генерации, без вашего ручного вмешательства.

location /delivery/ {
    secure_link $arg_md5,$arg_expires;
    secure_link_md5 "$secure_link_expires$uri secret_string";

    if ($secure_link = "") { return 403; }
    if ($secure_link = "0") { return 410; }

    alias /srv/reports/outgoing/;
}

Такую ссылку с ограниченным сроком действия вы генерируете отдельным скриптом при подготовке передачи и отправляете клиенту — а не выкладываете постоянный URL, который проживёт дольше, чем нужно.

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

Шифрование до отправки: что делает получателя бессильным без ключа

Шифрование транспорта (HTTPS, SSH) защищает файл, пока он в пути. Оно не защищает файл, если сам сервер или конечная точка получателя скомпрометированы уже после доставки. Поэтому вторым, независимым слоем должно быть шифрование самого файла отчёта, а не только канала.

Общий принцип — симметричное шифрование файла паролем, известным только вам и заказчику, переданным по отдельному каналу связи (не тем же письмом или сообщением, где лежит ссылка на скачивание):

# на вашей стороне перед загрузкой на сервер
gpg --symmetric --cipher-algo AES256 report_client_2026-08.pdf
# получаем report_client_2026-08.pdf.gpg — исходный файл на сервер не попадает вовсе

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

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

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

Контроль после отправки: подтверждение, срок жизни, что делать с копией

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

• Лог доступа. Nginx или SSH-сервер по умолчанию логируют каждое обращение — IP, время, факт успешной загрузки. Этого достаточно, чтобы у вас на руках было подтверждение, что файл скачан именно один раз и именно в ожидаемое время.

# быстрая проверка, кто и когда забрал файл
grep "report_client_2026-08" /var/log/nginx/access.log

• Подтверждение получения. Не полагайтесь только на лог — запросите у заказчика короткое письменное подтверждение, что файл получен и расшифрован. Это и юридически полезная точка (фиксирует момент передачи ответственности), и практическая: если заказчик не смог расшифровать файл (опечатался в пароле, использует старую версию инструмента), вы узнаете об этом сразу, а не через неделю.
• Удаление копии с сервера-канала. После подтверждённого получения зашифрованная копия удаляется с раздачи вручную или по cron-задаче с заданным сроком (например, через 48–72 часа после публикации ссылки, если для вашего процесса это разумный запас на случай, если заказчик открывает почту не сразу). Хранить отчёт на публично доступном (пусть и запароленном) разделе дольше, чем нужно для факта передачи, — лишний риск без пользы.
• Архивная копия — отдельно и по-другому. Рабочая копия для истории проекта хранится не в той же директории, что раздача, а в отдельном зашифрованном архиве с более строгим доступом (в идеале — вообще без сетевого интерфейса, доступном только локально или по SSH-ключу).

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

Организационные и юридические нюансы

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

Что стоит проговорить с заказчиком ещё до старта работ, а не постфактум при отправке первого отчёта:

• Способ передачи как пункт договора или NDA. Формулировка вида «отчёт передаётся через защищённый канал с шифрованием, ссылка действительна ограниченное время» снимает вопросы «а почему не на почту» в момент, когда отчёт уже готов и обе стороны торопятся.
• Кто отвечает за хранение после получения. Ваша ответственность заканчивается на моменте подтверждённой и корректной доставки; дальнейшее хранение расшифрованной копии — зона ответственности заказчика, и это стоит явно проговорить, а не подразумевать.
• Что происходит с промежуточными артефактами. Скриншоты, логи сканеров, черновые заметки во время самого тестирования — они тоже чувствительны и должны попадать под тот же режим хранения, что и итоговый отчёт, а не оседать в личных заметках на рабочем ноутбуке.
• Retention-политика на вашей стороне. Сколько времени вы сами храните копию отчёта после сдачи проекта — тоже вопрос, на который у вас должен быть заранее определённый ответ, а не решение по ситуации для каждого нового клиента.

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

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