Утечки данных в компаниях — дело не только в хакерах, но и в «слепых зонах»

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

По данным Positive Technologies, до 54% успешных кибератак заканчиваются утечкой конфиденциальной информации. Только за 2025 год в открытый доступ попало более 767 млн записей с персональными данными россиян, и это количество продолжает расти. В статье разберемся, где возникают слабые места в безопасности, и ответим на главный вопрос: как строить систему хранения данных так, чтобы действительно обезопасить ее от злоумышленников.

Корпоративная почта: основной канал утечек данных

Около 95% всех утечек данных вызваны человеческим фактором. И основным инструментом злоумышленников остается социальная инженерия — манипуляция человеком, чтобы он добровольно выдал доступы или перевел деньги. По данным исследования Positive Technologies, в 2025 году злоумышленники использовали электронную почту в 80% киберпреступлений, которые начинались с применения социальной инженерии.

Кроме того, зафиксировано 70% случаев доставки вредоносного программного обеспечения через этот канал связи. Только за прошлый год было предотвращено 554 миллиона попыток перехода по фишинговым ссылкам и заблокировано 144 миллиона вредоносных вложений.

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

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

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

Увольнение сотрудников: риски последней недели и процедура offboarding

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

В зоне особого риска оказываются данные, к которым конкретный сотрудник имел прямой доступ по роду деятельности — и здесь профиль риска сильно зависит от отдела. У специалистов по продажам это прежде всего клиентские данные из CRM и коммерческая тайна: сведения о сделках, выгрузки, финансовая отчетность. У разработчиков — исходный код компании, в котором нередко «зашиты» пароли и API‑ключи для доступа к внутренней инфраструктуре или продуктам компании: даже при понимании, что так делать не стоит, эта практика на деле встречается из года в год, а иногда такой код случайно попадает и в публичные репозитории вроде GitHub.

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

Поэтому при расставании с сотрудником, прежде всего нужно максимально быстро прекратить все его активные сессии — оборвать VPN‑подключение, доступ к почте, любые открытые сеансы в корпоративных системах. Это обеспечивает 80–90% защищенности. Более зрелый следующий шаг — перегенерировать пароли и ключи к общим сервисным учетным записям, к которым у уволенного сотрудника был доступ. Это не всегда делают точно в момент увольнения, но зрелые компании выполняют такую ротацию регулярно, например, раз в квартал, вне зависимости от кадровых изменений. Идеальный вариант — организовать доступ не как «доступ в корпоративную сеть вообще», а как доступ к конкретной системе для конкретных операций и на конкретный срок, тогда вопрос «отключать сразу или подождать» решается сам собой, потому что доступ и так ограничен временем и задачей.

Удаленная работа и аутсорсинг: новые границы ответственности

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

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

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

Отдельный полезный инструмент здесь — маскирование данных: если внешнему разработчику для работы не нужны реальные персональные данные, а нужна просто корректно устроенная тестовая выборка, настоящие ФИО и даты рождения можно на лету или заранее подменить на правдоподобные, но не настоящие значения.

Подрядчики и временные доступы: невидимые игроки в утечках

Проблемы усугубляются, когда часть ИТ‑функций или бизнес‑процессов отдается на аутсорсинг. Внешний провайдер может иметь собственные уязвимости, а компания‑заказчик часто не в состоянии их проверить. В результате данные компании оказываются в контурах, которые она не контролирует, а количество потенциальных точек утечки растет. Доля успешных кибератак через подрядчиков выросла втрое. Если годом ранее доля таких инцидентов не превышала 10%, то сегодня треть всех расследованных компрометаций инфраструктуры российских компаний (около 33%) связана с атаками через подрядчиков.

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

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

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

Чек‑лист: как выстроить регламент обработки и хранения персональных данных

Осознать наличие «слепых зон» — это полдела. Гораздо сложнее выстроить систему, которая будет работать не на бумаге, а в реальных процессах компании. Регламент обработки и хранения персональных данных — это не просто документ для галочки и не набор запретов. Это живой механизм, который должен учитывать, как сотрудники реально работают, где возникают соблазны обойти правила, и какие технические средства помогут эти правила не нарушать. Выстраивать такую систему стоит в три последовательных этапа — и именно в этом порядке, а не наоборот.

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

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

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

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