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

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

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

Что означает подтверждённое устранение замечания

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

Удобная базовая цепочка выглядит так:

Каждый элемент отвечает на отдельный вопрос. Замечание описывает факт. Критерий объясняет, почему факт важен. Решение показывает выбранный способ исправления. Версия и публикация связывают задачу с рабочим сайтом. Повторная проверка подтверждает результат. Решение о закрытии закрепляет ответственность.

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

Исправление, корректирующее действие, ретест, повторный аудит и принятие риска

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

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

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

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

Практические рекомендации ISO/IAF по работе с несоответствиями предлагают разделять коррекцию, анализ причины и корректирующее действие, а закрывать пункт после появления объективных подтверждений реализации и эффективности принятых мер [5]. Этот подход хорошо переносится на веб-разработку и информационную безопасность.

Что требуют российские правила

Для операторов персональных данных правовая основа начинается со статей 18.1 и 19 Федерального закона № 152-ФЗ. Статья 18.1 относит к мерам оператора внутренний контроль или аудит соответствия обработки персональных данных требованиям закона, политике и локальным актам. Она также предусматривает процедуры, направленные на предотвращение и выявление нарушений и устранение их последствий. По запросу Роскомнадзора оператор представляет документы и локальные акты либо иным способом подтверждает принятие предусмотренных мер [1].

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

Для информационных систем персональных данных приказ ФСТЭК России № 21 предусматривает регистрацию событий безопасности, систематический анализ защищённости, тестирование работоспособности системы защиты, реагирование на инциденты и документирование изменений конфигурации. Оценка эффективности реализованных мер проводится с периодичностью, установленной приказом [2]. Конкретный набор мер выбирают с учётом уровня защищённости, актуальных угроз и особенностей информационной системы. Поэтому содержание комплекта подтверждений для небольшого сайта и сложной ИСПДн будет различаться.

Маршрут одного замечания от аудита до закрытия

1. Зарегистрировать замечание. Присвоить постоянный ID, указать источник, объект, дату и точное наблюдение. Формулировка должна позволять другому специалисту найти то же состояние.
2. Связать с критерием. Это может быть норма закона, пункт договора, требование OWASP ASVS, внутренняя политика или согласованный критерий аудита.
3. Оценить риск и приоритет. Учитывают доступность уязвимого объекта, тип данных, возможные последствия, существующие меры и сложность эксплуатации.
4. Назначить владельца и срок. Владелец организует решение, собирает сведения и передаёт пункт на проверку. Исполнителей может быть несколько.
5. Согласовать способ устранения. Полезно заранее определить ожидаемый результат и способ его проверки. Тогда разработчик и проверяющий понимают одну и ту же задачу.
6. Зафиксировать изменение. Сохранить ссылку на задачу, версию кода или документа, изменение конфигурации, миграцию базы и результаты внутреннего теста.
7. Подтвердить публикацию. Добавить номер релиза, сборки или развёртывания, рабочую среду и время. Одна ссылка на commit показывает содержание изменения, но не факт его выхода на production.
8. Провести ретест. Повторить исходный сценарий, проверить близкие варианты и убедиться, что основная функция сайта сохранилась.
9. Закрыть пункт. Проверяющий фиксирует результат, дату, использованный метод и остаточные условия. Для принятого риска указывает отдельное решение и дату пересмотра.

Какие рабочие документы удобно вести

Комплект может состоять из нескольких простых документов. Их можно вести в системе задач, корпоративной базе знаний, GRC-системе или таблице с контролем доступа.

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

Какие поля нужны в реестре замечаний

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

Из чего складывается комплект подтверждений

Полезный комплект содержит ровно столько сведений, сколько нужно для понимания и повторения проверки. У него семь смысловых слоёв.

1. Исходное состояние. Отчёт аудита, дата, объект, шаги воспроизведения и исходные технические данные.
2. Критерий. Требование, по которому состояние признано замечанием, нарушением или уязвимостью.
3. Решение. Описание согласованного результата, анализа причины и выбранных мер.
4. История изменения. Задача, версия кода, настроек или документа, согласование и исполнитель.
5. Факт публикации. Связь изменения со сборкой, релизом и рабочей средой.
6. Результат проверки. Протокол ретеста, ответы системы, логи, выгрузки или отчёт инструмента.
7. Устойчивость. Наблюдение после выпуска, контрольное событие или повторный замер через согласованный период.

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

Подтверждения для разных видов замечаний

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

Как проводить повторную проверку

Ретест начинается с исходного замечания. Проверяющий восстанавливает условия, при которых проблема проявлялась: URL и параметры, роль пользователя, версию браузера или API, состояние записи, последовательность действий. Затем повторяет прежний тест на версии, опубликованной в нужной среде.

Хорошая повторная проверка включает несколько уровней:

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

Для уязвимостей OWASP WSTG рекомендует фиксировать цель, объём, сроки, ограничения, найденные проблемы и план исправления [7]. OWASP ASVS можно использовать как открытую основу для определения проверяемых технических требований к веб-приложению [8]. Автоматический сканер ускоряет контроль известных признаков, а ручная проверка помогает оценить бизнес-логику и возможные обходы.

Результат ретеста описывают проверяемо: «18 августа на production повторён запрос из пункта WEB-2026-014 с ролью редактора; сервер вернул 403; разрешённое действие для администратора сохранилось; версия приложения 4.18.2». Фраза «уязвимость исправлена» без условий и результата оставляет слишком много вопросов.

Чем ретест отличается от повторного аудита

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

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

Для планирования удобно использовать правило: критичные и системные замечания проходят ретест сразу после выпуска, а более широкий аудит выполняется по риску, после существенных изменений или по утверждённому графику. Приказ ФСТЭК № 21 отдельно говорит о систематическом анализе защищённости и тестировании системы защиты для применимой ИСПДн [2].

Что подтверждают скриншот, commit и хэш

Скриншот хорошо показывает внешний вид страницы и состояние интерфейса. К нему полезно добавить URL, дату, версию страницы и технический результат. Для формы таким результатом станет сетевой запрос и запись в системе-получателе; для доступа — ответ сервера и событие журнала; для настройки заголовка — фактический HTTP-ответ.

Commit или pull request показывает изменение исходного кода и историю его согласования. Факт работы на production подтверждают журнал развёртывания, идентификатор сборки, версия приложения и проверка ответа рабочего сайта. Такая связка особенно важна, когда одна ветка кода разворачивается в нескольких средах.

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

Когда материалы могут использоваться при расследовании или споре, полезны принципы ISO/IEC 27037 и ISO/IEC 27042: идентификация, сбор, сохранение, воспроизводимость и возможность независимой проверки цифровых данных [9][10]. Для обычного закрытия замечаний применяется более лёгкий процесс, сохраняя те же свойства — происхождение, целостность и понятный контекст.

Как хранить материалы и ограничивать доступ

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

• Единое место. Реестр содержит постоянные ссылки на задачи, версии, протоколы и файлы.
• Разделение ролей. Исполнители добавляют материалы, проверяющие фиксируют результат, владельцы риска принимают решения.
• История версий. Сохраняются предыдущие редакции и авторы изменений.
• Единое время. Серверы и инструменты используют синхронизированные часы и один явно указанный часовой пояс.
• Защита секретов. В копиях для обсуждения маскируются токены, пароли, cookie и персональные данные.
• Резервная копия. Реестр и вложения входят в резервное копирование и проверку восстановления.
• Срок хранения. Его устанавливают с учётом договора, внутренних правил, типа инцидента и применимых требований.

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

Разбор ситуации: исправление формы сайта

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

В реестре создают пункт FORM-2026-008. В качестве исходных материалов сохраняют URL формы, её версию, состав полей и обезличенную тестовую запись. Критерием становится внутреннее правило компании о фиксации версии текста для каждой заявки.

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

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

Когда нужен акт устранения замечаний

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

В акт или итоговый отчёт обычно включают:

• основание и реквизиты исходного аудита;
• проверенный объём и период выполнения;
• таблицу замечаний с постоянными ID;
• краткое описание выполненных действий;
• ссылки на подтверждающие материалы;
• результат повторной проверки;
• открытые пункты и принятые риски;
• ответственных лиц и даты согласования.

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

Частые ошибки при закрытии замечаний

• Статус без результата. В задаче стоит «готово», но отсутствуют версия, среда и протокол проверки.
• Тест только на стенде. Исправление успешно работает до публикации, а production остаётся на прежней сборке или конфигурации.
• Проверка другого сценария. Повторный тест отличается от исходного настолько, что сравнить результаты невозможно.
• Один позитивный тест. Основная функция работает, однако запрещённый сценарий и возможный обход не проверены.
• Скриншот без контекста. На изображении нет URL, версии, даты или фактического поведения системы.
• Отчёт сканера без параметров. Не указаны область, профиль, версия инструмента и ограничения проверки.
• Закрытие проявления без причины. Проблема исчезла на одной странице и повторилась в аналогичном шаблоне.
• Секреты в приложениях. Токены, cookie и персональные данные попали в общедоступную задачу или презентацию.
• Бессрочно принятый риск. Решение не содержит владельца, компенсирующих мер и даты пересмотра.

Часто спрашивают

Что считается подтверждением устранения замечания?

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

Достаточно ли скриншота после исправления?

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

Кто должен закрывать замечание?

Исполнитель передаёт пункт на проверку вместе с материалами. Закрытие фиксирует проверяющий, владелец контроля или другое лицо, определённое внутренним порядком. Для существенного риска полезно разделять выполнение и проверку.

Чем ретест отличается от повторного аудита?

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

Как подтвердить, что изменение попало на рабочий сайт?

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

Как оформить принятие остаточного риска?

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

Сколько хранить отчёты и протоколы?

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

Для чего нужен хэш файла?

Хэш позволяет проверить совпадение файла с ранее зафиксированной версией. Происхождение, автора и время фиксации показывают дополнительные записи, электронная подпись или доверенная отметка времени.

Какие сведения следует скрывать в копии отчёта?

Пароли, токены, cookie, ключи API, персональные данные, подробности активной уязвимости и внутренние адреса передают только тем, кому они нужны для работы. В общей копии используют маскирование и обезличенные примеры.

Официальные источники и стандарты

1. Правительство России — Федеральный закон № 152-ФЗ «О персональных данных», статьи 18.1 и 19.
2. ФСТЭК России — приказ от 18.02.2013 № 21: состав и содержание мер защиты персональных данных в ИСПДн.
3. Официальный интернет-портал правовой информации — приказ ФСТЭК России от 14.05.2020 № 68 с изменениями к приказу № 21.
4. ФСТЭК России — Методика оценки угроз безопасности информации от 05.02.2021.
5. ISO/IAF Auditing Practices Group — Review of Nonconformity: correction, cause analysis, corrective action and verification.
6. ISO — ISO 19011:2026, Guidelines for auditing management systems.
7. OWASP Foundation — Web Security Testing Guide: Reporting.
8. OWASP Foundation — Application Security Verification Standard.
9. ISO — ISO/IEC 27037:2012, identification, collection, acquisition and preservation of digital evidence.
10. ISO — ISO/IEC 27042:2015, analysis and interpretation of digital evidence.
11. NIST — SP 800-53A Rev. 5, Assessing Security and Privacy Controls.
12. ФСТЭК России — Банк данных угроз безопасности информации.