Во время аудита одной из систем заказчика мы обнаружили рабочую базу в тестовой среде.

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

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

Но рядом существовала еще одна база.

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

В этом и была проблема.

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

 

Почему рабочие данные вообще попадают в тестовую среду

Разработчикам проще проверять систему на настоящей базе.

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

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

Само по себе тестирование на копии еще не означает, что кто-то намеренно нарушает правила. Чаще это обычный рабочий процесс, который никто отдельно не пересматривал с точки зрения защиты ПДн.

Разработчику нужно проверить обновление. Руководителю проекта важно не сорвать запуск. Администратор делает копию. Все заняты своей задачей.

Но после переноса базы появляется новая точка хранения данных. У нее свой сервер, свои учетные записи, свой круг пользователей и свой срок существования.

Если эти вопросы заранее не определить, временное решение быстро становится постоянным.

 

В чем был реальный риск

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

Главный риск в другом: эта копия фактически выпала из общего контроля.

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

Его создавали под конкретную задачу. Потом задача закончилась, а база осталась. При этом никто отдельно не проверял, кто еще может подключиться к серверу, актуальны ли учетные записи и нужен ли стенд вообще.

Для злоумышленника слово «тестовый» ничего не меняет. Если внутри реальные фамилии, телефоны, адреса и история обращений, это такая же ценная база.

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

Именно поэтому проверка только основной системы дает ложное ощущение порядка.

 

Почему проблему не нашли раньше

Потому что каждый участник видел только свой участок работы.

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

Такое расхождение появляется постепенно.

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

Каждое изменение выглядит локальным. Но вместе они меняют путь данных.

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

Поэтому аудит нельзя сводить к вопросу: «Все ли документы подготовлены?»

Нужно проверить, соответствует ли описанная схема тому, как компания действительно работает сегодня.

Отдельно требования Роскомнадзора к обработке и хранению ПДн, документам и подготовке к контрольным мероприятиям мы разобрали в статье «Как подготовиться к проверке Роскомнадзора по персональным данным».

 

Что проверяется во время аудита ПДн

Во время аудита мы смотрим не только документы и не только основную базу.

Наша задача понять, что в компании реально происходит с персональными данными.

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

Дальше обычно начинают всплывать детали.

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

Все это может не быть нарушением само по себе. Но пока эти участки не собраны в одну схему, компания не понимает, где на самом деле находятся ПДн.

Поэтому аудит должен отвечать на практические вопросы:

• Кто имеет доступ?
• Где лежат копии?
• Можно ли выгрузить базу целиком?
• Какие данные видит подрядчик?
• Что происходит с информацией после завершения задачи?
• Можно ли подтвердить удаление?
  
  

После этого уже сравниваем фактическую схему с документами и требованиями по защите ПДн.

Если в документах описана одна система, а данные давно живут еще в пяти сервисах, проблема не в формулировках. Сначала нужно привести в порядок сам процесс.

 

Что делать с рабочими данными на тестовом стенде

Лучший вариант: не переносить реальные ПДн в тестовую среду.

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

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

На словах все просто. На практике обезличивание тоже нужно проверять.

Можно заменить имя и оставить телефон. Удалить электронную почту, но сохранить адрес и историю обращений. Человек все еще будет определяться по совокупности данных.

Поэтому для тестовых копий нужен отдельный порядок:

1. Определить, какие данные действительно требуются разработчикам.
2. Удалить поля, без которых можно провести проверку.
3. Заменить сведения, по которым можно определить пользователя.
4. Ограничить доступ конкретной командой.
5. Установить срок существования копии.
6. Зафиксировать удаление после завершения работ.

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

Такую копию нельзя создавать «на всякий случай». Нужны понятная цель, ответственный, ограниченный доступ и конкретная дата удаления.

 

Тестовая база редко бывает единственной незаметной копией

После обнаружения тестовой базы важно не останавливаться на одном сервере.

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

Например, разработчик мог скачать резервную копию на свой компьютер. Файл мог быть передан подрядчику через облачное хранилище. Отдельная версия могла сохраниться на предыдущем тестовом стенде.

Похожая ситуация возникает и без участия разработчиков.

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

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

Если компания проверяет только основную базу, эти участки остаются за пределами контроля.

 

Когда аудит уже нельзя откладывать

Обычно это видно без сложной диагностики.

Например, компания не может быстро ответить, где хранятся персональные данные клиентов.

ИТ-служба знает про серверы. Отдел продаж про CRM. Маркетинг про рассылки. Разработчики про тестовые стенды. Подрядчики про свои копии и доступы.

Но общей картины нет.

Еще один сигнал: инфраструктура заметно изменилась, а правила работы с ПДн остались прежними.

Появилась новая CRM. Подключили облачный сервис. Сменили подрядчика. Начали использовать ИИ. Перенесли систему. Запустили мобильное приложение.

Каждое такое изменение меняет путь данных.

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

В такой ситуации вопрос уже не в том, есть ли риск.

Вопрос в том, где он находится и сколько времени компания его не замечает.

 

Что должно остаться после аудита

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

Компания должна получить рабочую картину:

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

Отдельно нужен план действий.

Часть нарушений можно устранить сразу: отключить старую учетную запись, закрыть лишний доступ, удалить ненужную копию.

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

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

Так аудит связывает техническую инфраструктуру, работу сотрудников и требования к обработке ПДн в одну систему.

 

Основной риск находится за пределами основной базы

В обнаруженном нами случае никто не пытался обойти защиту.

Копию рабочей базы создали в рамках обычной разработки. Команде нужно было проверить доработки на реальных данных. На этом этапе решение выглядело удобным и логичным.

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

Именно для этого нужен аудит ПДн.

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

Защита персональных данных начинается не с уверенности, что основная база настроена правильно.

Она начинается с ответа на более сложный вопрос: где еще находятся эти данные?

Проведем аудит обработки и защиты ПДн

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

По итогам компания получает перечень обнаруженных рисков и план их устранения с приоритетами.