Одна и та же команда nmap -sV target.com — легальный пентест или статья 272 УК РФ. Разница не в технике. Разница в одной бумажке, которую ты забыл подписать.
Навыки White Hat и Black Hat идентичны. Разница между «этичным хакером» и «уголовником» лежит не в коде и не в намерениях — она лежит в документе с подписью и печатью. Без него ты не пентестер. Ты человек, который взломал систему без разрешения, и закон не спрашивает, был ли у тебя добрый умысел.
⚖️ Что говорит закон: жёстко и без иллюзий
Россия — статья 272 УК РФ
Статья защищает право владельца на неприкосновенность и конфиденциальность информации в его системе. Для привлечения к ответственности нужны два условия одновременно:
|
1 2 |
1. Собственник данных НЕ давал разрешения на доступ 2. Ты совершил действие с данными: скопировал, изменил, удалил, заблокировал |
Обрати внимание — намерение не важно. Даже если ты нашёл уязвимость случайно и ничего плохого не сделал, простой факт неправомерного доступа уже подпадает под статью.
Наказание по ст. 272 УК РФ:
| Часть статьи | Обстоятельства | Наказание |
|---|---|---|
| Ч.1 | Базовый неправомерный доступ | Штраф до 200 000 ₽, либо ограничение свободы до 2 лет, либо лишение свободы до 2 лет |
| Ч.2 | Корыстная цель или крупный ущерб | Штраф до 300 000 ₽, лишение свободы до 4 лет |
| Ч.3 | Группой лиц, с использованием служебного положения | Лишение свободы до 5 лет |
| Ч.4 | Тяжкие последствия или угроза их наступления | Лишение свободы до 7 лет |
Великобритания — Computer Misuse Act 1990
Закон криминализирует неавторизованный доступ к компьютерной системе вне зависимости от намерения. Пентестер обязан получить явное разрешение от владельца системы до начала любых тестовых действий — устного согласия недостаточно.
США — Computer Fraud and Abuse Act (18 U.S.C. § 1030)
Любая offensive-активность без формально оформленного соглашения о правилах взаимодействия (Rules of Engagement) рискует квалифицироваться как неавторизованный доступ к компьютеру — федеральное преступление.
📜 Rules of Engagement (RoE) — твой единственный щит
Rules of Engagement — документ, который определяет контрактные, технические и юридические границы, в рамках которых проводится авторизованный пентест. Без него любая offensive-активность — это просто взлом.
Структура RoE — что обязательно должно быть внутри
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
1. SCOPE (Область применения) ├── Список всех систем, приложений, IP-адресов, доменов ├── Явно указано, что ВНЕ scope (запрещено трогать) ├── Физические локации (если применимо) └── Сторонние интеграции и облачные сервисы 2. LEGAL AUTHORIZATION (Юридическое разрешение) ├── Письменное разрешение от лиц, принимающих решения ├── Подписанные договоры и waiver'ы └── Покрывает и твою команду, и консультантов 3. ПЕРИОД ДЕЙСТВИЯ ├── Точные даты начала и окончания ├── Временные окна (например, только ночью) └── Часовые пояса, если команда распределена 4. РАЗРЕШЁННЫЕ МЕТОДЫ ├── Какие техники допустимы (DoS? Social Engineering?) ├── Какие инструменты разрешены └── Что категорически запрещено 5. КОММУНИКАЦИЯ И ЭСКАЛАЦИЯ ├── Контакты для экстренных случаев ├── Кому звонить, если что-то сломалось └── Процедура при обнаружении критической уязвимости 6. ОБРАБОТКА ДАННЫХ ├── Как защищаются данные, полученные во время теста ├── Что можно включать в отчёт └── NDA и соглашения о конфиденциальности |
🔥 Ключевое правило: никакое действие вне утверждённого RoE не разрешено без предварительного явного согласия клиента. Если в процессе теста хочется попробовать что-то за пределами scope — стоп, запрос разрешения, и только потом продолжение.
✍️ Letter of Authorization (LoA) — бумажка, которая спасает от тюрьмы
Отдельный документ, короче RoE, но не менее критичный:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
## ПИСЬМО-РАЗРЕШЕНИЕ НА ПРОВЕДЕНИЕ ПЕНТЕСТА Настоящим [Название компании], в лице [ФИО, должность], предоставляет [Имя пентестера / название компании-подрядчика] разрешение на проведение тестирования безопасности следующих систем: СИСТЕМЫ В SCOPE: - 192.168.1.0/24 (внутренняя сеть) - app.company.com (веб-приложение) - API endpoints: api.company.com/* ПЕРИОД ДЕЙСТВИЯ: с [дата] по [дата] РАЗРЕШЁННЫЕ ДЕЙСТВИЯ: ☑ Сканирование портов и сервисов ☑ Эксплуатация обнаруженных уязвимостей ☑ Социальная инженерия (фишинговые кампании) ☐ DoS/DDoS атаки — НЕ разрешено ☐ Тестирование за пределами указанных временных окон требует отдельного письменного согласования Подпись уполномоченного лица: _______________ Дата: _______________ Печать организации: _______________ |
Без такого документа — ты просто открыл
nmap против чужой инфраструктуры без спроса. Разница между PoC для отчёта и explicit unauthorized access — исключительно в наличии этой подписи.
🗺️ Scope — граница между легальностью и статьёй
Scope определяет точно, что можно трогать, а что — табу. Это не формальность, это твоя единственная защита в суде.
Что обязательно включать в scope
|
1 2 3 4 5 |
✅ Точный список IP-адресов и доменов ✅ Версии приложений и API-эндпоинтов ✅ Физические адреса (для физического пентеста) ✅ Разрешённые техники (черный/белый/серый ящик) ✅ Third-party системы, которые могут быть затронуты косвенно |
Что обязательно исключать явно
|
1 2 3 4 5 |
❌ Системы с персональными данными клиентов, не входящие в scope ❌ Production-базы данных с реальными транзакциями ❌ Legacy-оборудование, которое может выйти из строя от скана ❌ Shared hosting — чужие сайты на том же сервере ❌ Сторонние интеграции (платёжные системы, CDN third-party) |
⚠️ Исключения имеют равный юридический вес со включениями. Если ты просканировал IP, который не был явно указан в scope — даже если он «оказался» частью инфраструктуры цели — ты вышел за границы разрешения. Это уже не пентест.
🚨 Реальные ситуации, где границы стираются
Ситуация 1: «Я нашёл уязвимость случайно, пока гулял по сайту»
|
1 2 3 4 5 |
Ты зашёл на публичный сайт, изменил параметр в URL, увидел чужие данные. Это IDOR. Юридически: ты получил неправомерный доступ к данным, даже если не скачивал и не изменял их. |
Правильные действия: не трогать дальше, зафиксировать факт (скриншот), сообщить через официальную программу responsible disclosure или Bug Bounty.
Ситуация 2: «Клиент разрешил тестировать сеть, я нашёл уязвимость в стороннем облачном сервисе, который они используют»
|
1 2 |
Third-party система технически не принадлежит клиенту. Клиент не может дать тебе разрешение на неё. |
Правильные действия: остановиться на границе scope, задокументировать находку, уведомить клиента — пусть он сам решает вопрос с третьей стороной.
Ситуация 3: «Мы договорились устно, письма пока нет, но время тикает»
|
1 2 |
Устное согласие = ноль юридической защиты. Если что-то пойдёт не так — у тебя нет доказательств разрешения. |
Правильные действия: никогда не начинать тест без подписанного LoA. Проект подождёт день-два — тюремный срок ждать не должен.
📋 Чеклист перед началом любого пентеста
|
1 2 3 4 5 6 7 8 9 10 |
✅ Letter of Authorization подписан уполномоченным лицом ✅ Rules of Engagement детально описывает scope ✅ Явно прописаны исключения — что НЕ трогать ✅ Указаны точные даты и временные окна тестирования ✅ Есть контакты для экстренной связи (24/7) ✅ NDA подписано с обеих сторон ✅ Third-party системы либо в scope с их согласия, либо исключены ✅ Определена процедура действий при найденной критической уязвимости ✅ У тебя есть физическая или электронная копия всех документов ✅ Юрист клиента подтвердил legal clearance |
🎯 Bug Bounty — легальная альтернатива без бумажной волокиты
Программы Bug Bounty (HackerOne, Bugcrowd, Standoff365) уже содержат встроенное разрешение — правила программы сами являются формой Letter of Authorization. Именно поэтому это самый доступный легальный путь для новичка:
|
1 2 3 4 |
✅ Программа явно указывает scope (какие домены/приложения в игре) ✅ Программа явно указывает запрещённые действия ✅ Согласие на тестирование дано публично и юридически закреплено ✅ Ты действуешь в рамках правил — ты защищён |
💡 Начинающему White Hat лучше стартовать именно через Bug Bounty программы — там разрешение уже есть, и единственная твоя задача — не выходить за scope программы.
🧠 Главный вывод
Скиллы решают половину дела. Вторая половина — бумага с подписью, определяющая, где заканчивается легальность и начинается уголовное дело. NIST SP 800-115 прямо называет планирование и авторизацию фундаментальными предпосылками для любого тестирования безопасности — не рекомендацией, а обязательным условием.
