Правовая рамка: закон, разрешение и область работ

Зачем это нужно

• Выход за область охвата — самая частая причина реальных правовых последствий у начинающих.
• Заказчик и исполнитель по-разному понимают «тест безопасности»; документ убирает двусмысленность.
• Правильное оформление защищает и вас, и заказчика, и третьих лиц.

Теория

Правовая основа работ — согласие владельца системы на конкретные действия, в конкретном объёме и в конкретное время. Незаконный доступ, создание и распространение вредоносных программ, нарушение правил эксплуатации систем и незаконный оборот персональных данных влекут ответственность во всех странах. В России это прежде всего статьи 272, 273, 274, 274.1 УК РФ, требования закона о персональных данных (152-ФЗ) и закона о критической информационной инфраструктуре (187-ФЗ); в других юрисдикциях действуют аналоги: UK Computer Misuse Act, US CFAA, GDPR. Мы не даём юридических консультаций — перед реальной работой консультируйтесь с юристом.

Область работ (scope) фиксирует: какие адреса и домены, какие приложения и учётные записи, какие временные окна, какие техники разрешены и какие запрещены (например, проверки на отказ в обслуживании, социальная инженерия против сотрудников, работа с реальными данными). Правила взаимодействия (Rules of Engagement) добавляют порядок коммуникации, экстренный контакт, требования к хранению и удалению собранных данных.

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

Ключевые концепции

Scope (область работ)

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

Rules of Engagement

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

Authorization letter

Письменное подтверждение от владельца системы, дающее право исполнителю выполнять согласованные действия.

Safe harbor

Условие программы баг-баунти или договора, защищающее исследователя от претензий при соблюдении правил.

Responsible disclosure

Раскрытие уязвимости в согласованном с вендором порядке и сроке; эталоны — ISO/IEC 29147 и 30111.

NDA

Соглашение о конфиденциальности: запрещает распространять сведения о системах и находках.

Инструменты

• Шаблоны PTES и CREST — заготовки документов о согласии и правилах работ.
• disclose.io — стандартные формулировки безопасной гавани для исследователей.
• ISO/IEC 29147, 30111 и программа CVE — процесс координированного раскрытия и присвоения идентификаторов.
• Менеджер заметок (Obsidian, CherryTree) — черновик журнала работ, который войдёт в отчёт.

Практика в легальных лабораториях

• Составьте учебный документ о правилах работ на две страницы для вымышленного интернет-магазина: цели, запреты, время, контакты.
• Напишите шаблон письма владельцу собственного ресурса о разрешении тестирования лаборатории.
• Разберите правила любой публичной программы баг-баунти и выпишите, что в ней прямо запрещено.
• Составьте перечень данных, которые вы обязаны удалить после теста в своей лаборатории.

Защита, детект и защитные меры

• Со стороны заказчика: зафиксируйте точку входа для тестировщиков, чтобы ИБ-команда отличала чужой тест от настоящей атаки.
• Сообщите в SOC о запланированном тесте и создайте исключения в детектах только на время и только для согласованных адресов.
• Проверьте, что подрядчик имеет договор и страховку профессиональной ответственности.
• После теста требуйте подтверждение удаления копий данных и закрытия всех созданных учётных записей.

Правовая рамка и этика

• Без подписанного разрешения и перечня целей активные проверки не выполняются; исключение — ваша собственная лаборатория.
• Ст. 272 УК РФ — неправомерный доступ к компьютерной информации; ст. 273 — создание и распространение вредоносных программ; ст. 274.1 — критическая информационная инфраструктура.
• Соблюдайте режим персональных данных: не копируйте реальные данные, используйте маскированные наборы.
• Договор описывает не только права, но и обязанности: сроки, конфиденциальность, удаление данных.

Типичные ошибки

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

Чек-лист «умею»

• Умею составить область работ и правила взаимодействия по шаблону.
• Проверяю каждое действие на соответствие области работ.
• Знаю статьи закона, о которых обязан предупредить заказчика.
• Всегда докладываю о критической находке в согласованном канале.
• Умею оформить координированное раскрытие по ISO/IEC 29147.

Вопросы на интервью

• Владелец сайта попросил «просто проверить» без документов. Ваши действия?
• Как вы отличите разрешённую проверку от нарушения закона?
• Что такое безопасная гавань и зачем она исследователю?

Источники и первоисточники

• ISO/IEC 29147 — раскрытие уязвимостей
• disclose.io — стандарт безопасной гавани
• NIST SP 800-115 — планирование и проведение оценок
• OWASP Web Security Testing Guide