Аудит ИСПДн: как доказать удаление и не вернуть данные при восстановлении

Если аудит ИСПДн ограничивается успешным ответом API или пустой карточкой пользователя, его доказательств недостаточно. Запрос на удаление может убрать основную строку, но оставить читаемую реплику, документ поискового индекса, запись кеша, аналитическую выгрузку, версию объекта, событие отслеживания изменений (CDC) или восстанавливаемую резервную копию. При следующем восстановлении запись может снова стать видимой.

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

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

Определите удаление как результат, а не вызов API

«Удалить пользователя» — действие интерфейса. Проверяемый результат должен отвечать на вопросы: что становится недоступно, где, для каких ролей и каким тестом это подтверждается. Для каждого класса данных оператор задаёт один из трёх исходов: вывести данные из активной обработки; сохранить по документированному исключению с ограниченным доступом; либо безопасно очистить носитель или уничтожить ключи в согласованной области, если выборочное удаление технически применимо и разрешено. Если эти исходы смешаны, доказательства будут ложноположительными.

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

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

По возможности используйте синтетические тестовые записи. Запись A, предназначенная для удаления, должна быть уникальной, присутствовать на каждом проверяемом уровне и не содержать реальных персональных данных. Рядом нужна контрольная запись B, которую следует сохранить. Эти записи отличаются от технического маркера удаления в очереди событий. Без контрольной записи B пустой результат может означать сломанный запрос, недоступную реплику, неудачное восстановление или пустую среду, а не корректное удаление.

Превратите граф копий в матрицу тестов

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

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

Логическое удаление в БД не равно безопасной очистке носителя

Логическое удаление и физическая очистка носителя отвечают на разные вопросы. PostgreSQL хорошо показывает различие. При MVCC старая версия строки после UPDATE или DELETE не удаляется немедленно. Обычный VACUUM позднее освобождает место мёртвых версий для повторного использования и, как правило, не возвращает его операционной системе. Это поведение базы, а не доказательство доступности записи через приложение и не гарантия безопасного стирания.

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

У массового удаления из индекса своя ловушка. Elasticsearch delete-by-query работает со снимком состояния, может встретить конфликт версий, а успешно обработанные пакеты не откатываются, даже если более поздний пакет завершился ошибкой. Статус успеха без анализа failures, конфликтов, затронутых алиасов, индексов за алиасами и итогового поиска — неполное доказательство. Refresh меняет видимость для поиска, но не доказывает очистку снимков, сегментов или внешних экспортов.

Проверяйте CDC как протокол удаления

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

Debezium можно использовать как пример механики. Удаление строки способно создать событие delete с прежними значениями и tombstone с тем же ключом. Режим трансформации может сохранить, переписать или отбросить эти записи. Компактация Kafka использует tombstone для удаления старых записей с данным ключом, а настройка хранения tombstone ограничивает время, за которое пересобирающийся потребитель должен его увидеть. Это свойства продукта, а не срок хранения персональных данных и не доказательство применения удаления всеми целевыми хранилищами.

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

Нельзя навсегда запрещать сам идентификатор. Человек может позднее создать новую законную учётную запись с тем же email или бизнес-идентификатором. Подавление должно относиться к удалённому поколению сущности или другой версионированной идентичности. Тест обязан показать, что старое поколение отвергается при повторном проигрывании, а новое допустимое создание проходит. Иначе «контроль приватности» превращается в скрытую потерю корректных данных.

Включите кеши, индексы, выгрузки и версии объектов

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

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

Версионированное объектное хранилище может дать особенно обманчивый результат. В примере с S3 Object Lock простой DELETE способен вернуть успех и создать delete marker, хотя защищённая предыдущая версия останется. Срок удержания и блокировка legal hold относятся к конкретным версиям; обход защиты в режиме governance требует специальных полномочий. В тесте перечисляют версии и состояние блокировок. Это пример семантики версий, а не рекомендация размещения и не вывод о соответствии российскому праву.

Проверьте неизменяемые резервные копии и условия их удаления

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

Восстановление PostgreSQL на выбранный момент времени (PITR) объясняет, почему путь восстановления входит в аудит: физическая базовая копия вместе с архивом WAL позволяет реконструировать состояние и проиграть изменения до выбранной точки. Восстановление на момент до удаления может вернуть старую запись. Контроль удаления не завершён, если инструкция по восстановлению не сверяет удаления до того, как восстановленная система становится основным источником данных.

NIST SP 800-88r2 связывает криптографическое стирание с проверенным шифрованием и уничтожением ключей. Ранее сохранённый открытый текст и восстанавливаемые копии ключей мешают такому выводу: проверьте депонирование ключей, резервные копии и восстановление через внешний KMS. Область действия ключа должна соответствовать удаляемым данным: общий ключ затрагивает другие записи. Нужны проверенная реализация и подтверждённое уничтожение ключей; удаления ссылки недостаточно.

Восстанавливайте в карантин и сверяйте до открытия доступа

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

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

1. Подготовкаизолировать среду, заблокировать интеграции с рабочей средой и установить первую границу сверки реестра
2. Восстановлениезагрузить резервную копию и доказать наличие тестовых записей A и B в исходном снимке
3. Сверкавыполнить управляемое проигрывание событий в карантине и применить удаления по поколениям во всех пересобранных целевых хранилищах
4. Проверкаприменить последние удаления до согласованной границы запуска и подтвердить отсутствие A и работоспособность B без нерешённых ошибок
5. Открытиевключить интеграции с рабочей средой только после подписанной сверки и сохранить пакет доказательств

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

Конкретный пакет приёмки

Рассмотрим явно вымышленный пример ритейлера с профильной БД, репликой для чтения, CDC через Kafka, поисковым кластером, ночной CSV-выгрузкой и неизменяемыми резервными копиями. Аудит создаёт тестовую запись A для удаления и контрольную запись B для сохранения, подтверждает наличие обеих записей на всех уровнях и запускает согласованное удаление A. При проверке работающей системы запись A должна исчезнуть, B — остаться. Одного потребителя намеренно останавливают для проверки задержки, другое целевое хранилище пересобирают из истории. Экспорт запускают до и после удаления, версии объектов перечисляют.

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

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

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

Когда нужен независимый пентест

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

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