Аудит по 152-ФЗ: где заканчиваются правовые обязанности и начинаются технические доказательства

Возьмём условный пример, который не описывает ни одну реальную компанию. Онлайн-ритейлер готовится запустить программу лояльности: регистрация на сайте, мобильное приложение, CRM с историей покупок, колл-центр на стороне подрядчика и сервис рассылок. За месяц до запуска руководство ставит задачу «пройти аудит по 152-ФЗ и получить сертификат». Бюджета хватает на одну работу, и выбор склоняется к пентесту личного кабинета. Решение кажется простым, но в нём смешаны три разных вопроса. Применим ли закон и какие обязанности он возлагает на компанию как оператора? Выполнены ли организационные обязанности: цели, правовые основания, документы, роли, договоры с обработчиками? И работают ли технические меры в конкретных системах так, как заявлено?

Пентест отвечает только на часть третьего вопроса. Он может стать сильным источником технических доказательств, но сам по себе не устанавливает соответствие правовым, организационным и документальным требованиям и не подтверждает законность обработки. Частный аудит или пентест — это не «сертификат 152-ФЗ», не аттестация и не заключение с гарантией уверенности. Ниже разбираем, как разделить эти слои, как выстроить техническую часть на воспроизводимых доказательствах и как заказчику принимать результат.

Сначала правовая применимость, потом технический охват

Федеральный закон № 152-ФЗ «О персональных данных» — основной закон о персональных данных в России. Его заявленная цель — защита прав и свобод человека и гражданина при обработке его персональных данных, включая право на неприкосновенность частной жизни, личную и семейную тайну. Закон существенно менялся, в том числе Федеральным законом № 266-ФЗ в 2022 году, поэтому первоначальная редакция 2006 года или недатированные пересказы не годятся как описание действующих требований. Конкретные выводы о том, что обязан делать конкретный оператор, требуют квалифицированной юридической оценки и проверки по актуальной консолидированной редакции на дату работ.

Для технического исполнителя из этого следует практическое правило: не делать выводов об охвате, пока не определены исходные данные. Иначе пентест проверит то, что удобно проверять, а не то, что важно.

Оператор, цели и категории данных

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

Информационные системы, модель угроз и уровень защищённости

Следующий шаг — перечень информационных систем персональных данных, модель угроз и применимый уровень защищённости. Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных в таких системах определены приказом ФСТЭК России № 21 от 18 февраля 2013 года, зарегистрированным Минюстом 14 мая 2013 года под № 28375. Рядом с ним стоят постановление Правительства № 1119, требования ФСБ России к криптографической защите, если она применяется, и более поздние изменения. Эти документы нужно читать в действующей редакции, а интерпретировать их для конкретного оператора должен юрист вместе со специалистом по защите информации. Задача технической команды — получить готовую модель угроз и уровень защищённости как исходные данные, а не придумывать их самостоятельно в ходе тестирования.

Три вида работы и границы между ними

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

Самые полезные находки лежат на стыке колонок, там, где заявленное состояние расходится с фактическим. Сильный аудит связывает каждое существенное утверждение в документах с технической проверкой, а утверждения, которые проверить нельзя, прямо помечает как непроверенные.

Что пентест может доказать, а что нет

NIST SP 800-115 называет две цели технического тестирования: поиск уязвимостей и проверку соответствия политике или иным требованиям. Именно вторая цель делает пентест ценным для аудита персональных данных: он показывает, работает ли заявленная мера на самом деле. Но тот же документ прямо оговаривает, что не является исчерпывающей программой тестирования. Пентест не скажет, законны ли цели обработки, достаточны ли согласия, правильно ли определён уровень защищённости и выполнены ли уведомительные обязанности. О том, как встроить тестирование в подготовку к проверке, подробнее рассказано в материале о пентесте для подготовки к аудиту.

Инвентаризация: системы, потоки и явные исключения

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

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

Веб-формы, cookie и сессии

Значительная часть сбора данных идёт через веб. Протокол HTTP сам по себе не хранит состояние, его добавляют cookie: сервер отправляет заголовок Set-Cookie, а браузер возвращает значение с каждым следующим запросом. Поэтому идентификаторы сессий в личном кабинете и на формах регистрации должны появиться и на схеме потоков, и в плане проверок.

Исключения как решение, а не умолчание

Если система на площадке подрядчика или устаревшее приложение не входят в охват, отчёт должен сказать об этом и объяснить причину. Руководство и будущий проверяющий не должны гадать, что именно проверялось. Текущий и целевой профили в духе NIST CSF 2.0 помогают зафиксировать исходное состояние и цель, чтобы план устранения имел структуру, а не превращался в плоский список замечаний.

Технические методы: от плана до отчёта

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

Разрешение и правила работ

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

Работа с реальными персональными данными

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

Веб-приложения и API: проверки, которые можно повторить

Веб-приложения и API — обычная точка входа персональных данных, поэтому для них нужен структурированный каталог проверок, а не общая формулировка. OWASP Web Security Testing Guide даёт такой каталог: план работ может ссылаться на конкретные разделы WSTG, и тогда охват становится видимым и сравнимым между исполнителями. Как выстроить проверку веб-приложения на основе стандартов, разобрано в статье о тестировании веб-приложений на уязвимости.

Версионированные требования вместо общих ссылок

OWASP ASVS задаёт требования к техническим мерам защиты и рекомендует ссылаться на них с указанием версии, например в форме v5.0.0-1.2.5, поскольку нумерация может меняться между выпусками. Для аудита это значит, что заказчик и исполнитель заранее согласуют применимые главы и уровень ASVS, находки ссылаются на версионированные идентификаторы, а повторная проверка оценивает ровно то же требование. OWASP Top 10 полезен как общий словарь, но отчёт с формулировкой «проверено по Top 10» даёт более слабые доказательства, чем сопоставление с тестами WSTG и требованиями ASVS. Методика, которая связывает стандарты с управленческими решениями, описана в материале об аудите безопасности приложений.

HTTP-уровень и базовая гигиена

Ряд мер виден прямо на страницах, где собираются данные: атрибуты cookie, заголовок Content-Security-Policy, который помогает обнаруживать и смягчать межсайтовый скриптинг и внедрение данных, настройки CORS для межсайтовых запросов, Permissions Policy для ограничения функций браузера. Такие проверки недороги, воспроизводимы и хорошо подтверждают базовую гигиену, хотя и не заменяют проверку логики доступа.

Приоритизация находок по риску для данных

Для аудита персональных данных главный риск — их кража или раскрытие, поэтому находки разумно ранжировать по влиянию на данные, а не по количеству. Корневые категории CWE Top 25 помогают связать конкретную ошибку с классом слабости, а перечень слабостей, связанных с каталогом известных эксплуатируемых уязвимостей CISA (KEV), подсказывает, какие находки поднимать выше теоретических.

Независимые источники сходятся на одних и тех же классах дефектов: межсайтовый скриптинг, внедрение команд ОС, обход каталогов. Значит, проверки на внедрение и межсайтовый скриптинг должны входить в охват любой веб-системы с персональными данными. Отдельно стоит проверить базовые меры, которые CISA относит к безопасности «из коробки»: включена ли многофакторная аутентификация для административного и привилегированного доступа, включено ли журналирование и хранятся ли журналы, централизован ли доступ там, где продукт это поддерживает.

Устранение и повторная проверка: какие доказательства принимать

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

1. ФиксацияНаходка описана с указанием системы, условий воспроизведения, доказательства и версионированной ссылки на требование
2. УстранениеВладелец системы вносит исправление и описывает, что изменено и где
3. Повторная проверкаИсполнитель повторяет исходный тест тем же приёмом и против той же версии требования
4. ПриёмкаНаходка закрывается только при воспроизводимом отрицательном результате, иначе возвращается владельцу

Критерии приёмки

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

Компромиссы глубины и цены уверенности

Глубина технической части зависит от открытости систем и чувствительности данных. Полное тестирование оправдано, если системы доступны из интернета, содержат большие объёмы или чувствительные категории данных либо заметно изменились с прошлой оценки. Для небольших внутренних систем может хватить документальной проверки и анализа конфигураций, но такое решение нужно записать в отчёт как осознанный выбор охвата.

Документы или тестирование

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

Автоматизация или ручная работа

Сканирование даёт широкий и воспроизводимый охват, но пропускает ошибки бизнес-логики и разграничения доступа. Ручное тестирование находит их, но за то же время охватывает меньше. Убедительный отчёт сочетает оба подхода и указывает источник каждой находки.

Продуктив или стенд

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

Как выбрать исполнителя и чего от него не требовать

Выбирайте исполнителя после того, как определены охват и цель, иначе предложения невозможно сравнить. Оценивайте три вещи: прозрачность методики, способность закрыть нужные слои или честно обозначить, какие из них остаются за юристом, и порядок обращения с персональными данными в ходе работ. Если нужна проверка организационных и технических мер по требованиям регулятора, полезно сопоставить подход с материалом об аудите соответствия требованиям ФСТЭК. Практичный следующий шаг — описать контур технической части: системы, доступы, ограничения и ожидаемые доказательства можно заранее подготовить на странице подготовки контура пентеста Pentest.red.

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

Вопросы исполнителю

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

Тревожные признаки

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

Что решить до заказа

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

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