Сегодня на связи Дмитрий Ларин, руководитель продуктового направления по защите баз данных, и Анастасия Комарова, менеджер по продуктовому маркетингу компании «Гарда». Мы регулярно общаемся с ИТ- и ИБ-командами, в том числе на пилотах и в ходе интервью на профильных мероприятиях. Возможно, кто-то из читателей уже отвечал на наши вопросы или участвовал в таких обсуждениях.
Со временем по итогам этого диалога сложилась такая картина: в разных компаниях и отраслях специфика отличается, но общий подход к данным почти всегда один. Production закрыт и находится под жестким контролем, а все, что происходит вокруг него, воспринимается как менее критичное. Однако на практике самые неприятные ситуации возникают не в production, а вокруг него. В тестовых средах, дампах, BI-витринах, песочницах и временных проектах. Именно там персональные данные начинают жить своей жизнью. Их копируют, переносят, пересылают, используют повторно. Если вы работаете с тестовыми базами, скорее всего, уже видели что-то похожее.
Чтобы показать, как это происходит, разберем несколько сценариев из практики крупного онлайн-ритейлера.
Подробности о герое нашей истории
Компания-ритейлер работает по всей стране, у нее несколько продуктовых команд, большой ИТ-блок и около 1500 сотрудников. Сайт и мобильное приложение ежедневно обрабатывают десятки тысяч заказов, а клиентская база насчитывает сотни тысяч активных пользователей. В периоды распродаж и праздников нагрузка возрастает кратно. Любая ошибка в оформлении заказа быстро перестает быть «технической» и начинает напрямую влиять на бизнес.
Описанные ниже ситуации типовые. Мы видим их не только в ритейле, но и в банках, финтехе, телекоме и e-commerce. Везде, где есть сложные ИТ-системы и большие массивы персональных данных.
Зачем разработчикам во время тестирования нужны «почти» реальные данные?
На синтетических или демонстрационных данных можно проверить, что «кнопка нажимается», но невозможно поймать ошибки, которые проявляются только в пользовательских сценариях. Например, у клиента может быть не один, а сразу несколько адресов доставки. Могут быть возвраты, повторные доставки, пересекающиеся бонусы и промокоды. Или возникать редкие комбинации статусов заказа, либо другие неочевидные граничные случаи в интеграциях.
Поэтому во многих компаниях встречается такая практика, когда тестовые среды периодически «освежают» данными из production. Прямой доступ к боевой базе или ее полноценной реплике с персональными данными не выдается по первой просьбе. Нужно оформить заявку, указать цель, систему, срок, уровень доступа и согласующих. Часто подключаются владелец данных, ИБ, а иногда и юристы.
Если все согласования получены, доступ выдается временно и строго в рамках утвержденной роли. Все действия логируются. С точки зрения защиты production эта схема действительно работает.
Проблемы начинаются в тот момент, когда компании нужно действовать быстро. Например, когда кому-то «очень срочно нужен свежий срез, иначе баг не удастся воспроизвести». Так начинает формироваться конфликт между скоростью реагирования на запросы бизнеса и безопасностью данных.
Из-за чего часто невозможно быстро получить доступ к production?
В спокойный период доступ к production можно получить за пару-тройку дней, но в пиковый «бег по кабинетам» легко растягивается на целую неделю. Дело в том, что заявка проходит целую цепочку согласований и приходится мириться с тем, что у каждого ответственного есть свои задачи. Так, нужный сотрудник может быть в отпуске, ЛПР на срочном совещании.
А когда все акцепты получены, у администраторов баз данных (Database administrator, DBA), которые физически выдают доступ или делают выгрузку, просто может не быть для вас свободного окошка. Кроме того, каждый «ок» приходится получать, буквально продираясь через массу уточняющих вопросов: «какие таблицы», «какие поля», «почему нельзя взять обезличенное».
Сценарий 1. «Баг, который не ловится на синтетике»
В службы поддержки и мониторинга ритейлера стали поступать жалобы. У некоторых клиентов при оформлении заказа внезапно начал «прыгать» адрес доставки: иногда в форму попадал уже неактуальный адрес, а иногда заказ уходил в другой регион. Эта ошибка не была массовой, но возникала с достаточной регулярностью, чтобы начать влиять на бизнес-метрики.
Когда проанализировали логи, выяснилось, что в некоторых сценариях адрес подтягивался так, будто система брала его из другой клиентской записи (словно в CRM перепутались связи). На синтетических тестовых данных и на демостенде этот баг не воспроизводился. Ошибка проявлялась только в боевой базе.
Пытаясь быстрее решить проблему, сотрудник backend-команды попросил DBA обновить тестовую базу свежим дампом из production. В письме он написал: «На текущих данных баг не воспроизводится. Поэтому, если быстро не обновим, будем долго искать проблему вслепую». DBA пошел на встречу и выполнил запрос.
Почему копия production не выглядит нарушением политик безопасности?
Формально администратор не предоставил прямой доступ к боевой системе, это была копия в тестовом контуре, где работали только разработчики.
В подобных случаях DLP и другие ИБ-системы могут не сработать, так как в большинстве компаний они сосредоточены на production-периметре, почте и корпоративных файловых хранилищах. В то время как тестовые сегменты часто защищены слабее: они считаются «внутренними», и избыточный контроль там быстро начинает тормозить процесс разработки.
Как и почему дамп может бесконтрольно распространиться внутри компании?
Получив свежие данные, сотрудник воспроизвел баг и понял, что проблема возникает из-за нетиповых изменений в профиле клиента. Чтобы быстрее разобраться, он подключил коллегу, отвечающего за модуль профилей и адресов в CRM, попросив прогнать сценарий локально, не тратя время на по��учение доступа в тестовый контур. Самым быстрым способом это сделать, оказалось взять дамп части базы и передать файл напрямую. Так и поступили. Архив передали через обычную «shared folder», минуя какие-либо разрешения.
Сегодня такие ситуации происходят регулярно. При этом никто из сотрудников не нарушает правила сознательно. Просто в какой-то момент скорость и удобство перевешивают формальности. Однако зачастую такие «временные» копии баз и становятся источниками утечек: дамп скачивается на личный ноутбук, а забытая база годами живет в тестовом сегменте без контроля. ИБ не видит этих потоков.
Сценарий 2. «Отправка подрядчику для примера персональных данных клиентов»
Компании было нужно интегрировать в ИТ-инфраструктуру внешний сервис (бонусную систему). Подрядчик не мог воспроизвести ошибку на своих данных и попросил отправить ему в качестве примера сведения о нескольких клиентах.
Проект был важный, сроки горели. Чтобы не нарушать дедлайны, часть дампа передали подрядчику. Формально он был проверенным: с ним был заключен контракт и подписан NDA. Однако фактически данные оказались за периметром компании-заказчика. Как известно все, что выходит за периметр, перестает контролироваться. И уже нельзя быть до конца быть уверенным, что подрядчик добросовестно удалит дамп, а не сделает резервное копирование и положит данные во внутренние репозитории.
И такая практика встречается повсеместно. Поэтому даже при соблюдении всех юридических формальностей компания перестает управлять жизненным циклом персональных данных сразу после их передачи. Подрядчик может быть добросовестен, но нет никаких гарантий, что его инфраструктура достаточно хорошо защищена. И если произойдет инцидент, ответственность ляжет на того, кто передал данные — то есть на заказчика.
Сценарий 3. «Создание витрины в BI на основе реальных данных»
Пока разработка чинила очередной баг в CRM, бизнесу срочно понадобились данные о том, сколько клиентов вернулись после возврата, какие сегменты наиболее лояльны. Аналитик сделал временную витрину в BI. Доступ к production согласовывать не стали, все же отчет руководству нужен был срочно. Поэтому данные для создания витрины взяли из тестовой базы.
Дашборд опубликовали, доступ к нему получили топ-менеджеры, продажники, маркетологи и продакты. BI-система в компании воспринималась как аналитический инструмент, а не как полноценная копия базы данных. Поэтому информацию из дашборда мог выгрузить в Excel практически любой сотрудник, а затем файлы начали жить своей жизнью: отправлялись в Slack, Teams, личные папки, презентации для инвесторов.
Наш опыт показывает, что подобные витрины и выгрузки являются одной из самых частых точек, откуда утекают ПДн. Причем никто не считает нарушением создание отчетов на основе реальных персональных данных. «Это же просто отчет», — думают сотрудники. Но с точки зрения законодательства это бесконтрольное распространение персональных данных. В отличие от production, такие копии почти никогда не попадают в поле зрения ИБ.
Сценарий 4. «Бесхозная база с реальными персональными данными в тестовом контуре»
Компания запустила ежегодный плановый аудит ИБ. Во время инвентаризации серверов в тестовом сегменте обнаружили старую базу с названием crm_test_old. Последний апдейт базы делали больше года назад.
Стали разбираться. Оказалось, что это была песочница для PoC. Данные брали из production, проект закрыли, сервер забыли. А DBA, который поднимал базу, уже не работает в компании. Документации нет, спросить не с кого.
Внутри базы находились реальные персональные данные без какой-либо защиты. Сервер был без патчей, пароли старые, а доступ к базе никак не ограничен. Анализ логов показал, что подключения были, но кто именно пользовался данными уже восстановить невозможно.
Самое неприятное в подобной ситуации — это даже не то, что утечка точно была, а то, что в случае чего компании будет проблематично доказать обратное.
Как организовать защиту данных?
После таких историй вывод напрашивается сам собой: мы не можем контролировать то, что постоянно создается вручную. Часто утечка начинается не с атаки, а с желания сделать быстрее.
Безусловно, копии в non-prod будут всегда. Их нельзя просто запретить, так как это может затормозить многие жизненно важные для бизнеса процессы. Однако можно сделать так, чтобы эти копии баз изначально не содержали персональных данных. Сделать это можно с помощью маскирования.
Маскирование данных снижает ущерб от человеческого фактора. Даже если база забыта, даже если доступы выданы шире, чем нужно, даже если дамп ушел за периметр. По замаскированным данным невозможно напрямую идентифицировать клиента. Поэтому компании все чаще приходят к необходимости использования решений класса Data Masking, таких как Гарда Data Masking. Это позволяет предоставить командам рабочие данные и при этом не разносить ПДн по тестам, витринам и подрядчикам.
Техники маскирования и подходы к легальному использованию персональных данных мы подробно разбираем в серии вебинаров, записи которых доступны на нашем сайте. ,
Приглашаем вас на ближайший вебинар, где расскажем, как даже корректно замаскированные данные теряют бизнес-смысл и искажают аналитику, какие «безобидные» ошибки в non-prod приводят к срыву релизов и пересборке баз, как построить процесс маскирования, который всех устраивает.
Зарегистрироваться на мероприятие можно по ссылке. Будем рады обсудить детали и ответить на ваши вопросы.
