Привет, Хабр!

Меня зовут Александр Егоров, я инженер по техническому сопровождению продаж группы компаний «Гарда». Хочу поговорить об инструменте предотвращения утечек данных с помощью DLP. Базово компании внедряют такие решения, чтобы защищать конфиденциальные данные и ловить сотрудников, которые могут их сливать.

Конечно, в большинстве случаев ИБ-cпециалисты сталкиваются с типовыми сценариями, но иногда DLP позволяет сделать неожиданные открытия. В статье поделился личной коллекцией инцидентов, которые удавалось обнаружить с помощью DLP.

P.S. Некоторые кейсы могут показаться архаичными – «так же уже никто не делает». Но практика говорит об обратном. И одна из возможных причин – низкий уровень цифровой грамотности сотрудников.

История 1: «Медвежья услуга»

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

На первый взгляд, загрузка документов и данных в облачные онлайн-сервисы (PDF-редакторы, нейросети и т.п.) – это безобидное действие. Однако такие инструменты нередко бывают небезопасными, и через них могут утекать конфиденциальные корпоративные данные. Например, в 2024 году была новость о том, что два популярных зарубежных PDF-сервиса хранили более 89 тысяч загруженных файлов в открытом S3-контейнере.

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

С нейросетями тоже не все так однозначно. Еще в начале 2025 года Gartner предупредил о том, что к 2027 году более 40% утечек данных будут вызваны именно неправильным использованием генеративного ИИ. Именно поэтому важно доносить до сотрудников, что когда они загружают документы в облачный PDF-редактор или пишут запрос в чат нейросети – они не просто решают задачу быстрее, а передают данные третьим лицам, которые в реальности могут быть не готовы обеспечить сохранность этой информации.

А теперь вернемся к нашим «героям».

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

DLP зафиксировала передачу персональных данных во внешний контур. По анализу URL-адресов сотрудники информационной безопасности поняли, что это был PDF-редактор. После беседы с сотрудницей стало ясно, что намерения сливать данные у нее не было.

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

Как и в случае с бухгалтером, DLP зафиксировала отправку данных на домен публичной LLM. Анализ специалистом ИБ запроса показал, что в тексте содержались фрагменты исходного кода со структурой базы данных.

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

Тогда все закончилось благополучно: бухгалтера и разработчика не уволили. Однако итогам этих инцидентов руководство запустило внутреннюю кампанию по обучению цифровой грамотности.

История 2: «Кружок очумелые ручки»

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

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

Как удалось выйти на банду. Ремонтную «банду» рассекретила DLP. Интересно, что сначала сигнал от DLP сочли ложным срабатыванием. ИИ-алгоритм среагировал на передачу по WhatsApp изображения с цифрами, похожими на номера банковских карт. Одного из сотрудников вызвали на беседу, но тот уверил ИБ-инспектора, что всего лишь отправлял клиентам по запросу фото запчастей. Выбитые на деталях цифры действительно по формату походили на номера карт. Инцидент тогда закрыли.

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

Финал этой истории – печальный. «Кружок» был пойман с поличным, организатор уволен с волчьим билетом, а клиенту пришлось возместить моральный и материальный ущерб.

История 3: «План-капкан»

Предыстория: За несколько дней до увольнения сотрудник маркетинга загрузил в личное облако файл с безобидным названием «План_отпуска_2025.pdf». Но внутри была отнюдь не программа отдыха, а маркетинговая стратегия компании.

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

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

Дальнейшее ИБ-расследование показало, что сотрудник собирался использовать маркетинговую стратегию на новом месте работы. Причем он не считал свои действия «сливом». Для него это была просто «копия для портфолио», а вот с юридической точки зрения – разглашение коммерческой тайны.

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

История 4: «Ретроград как алиби»

Предыстория: Продажи менеджера по строительству резко упали: раньше он продавал порядка пяти домов в квартал, а теперь – всего один. При этом встречи и звонки от клиентов остались на прежнем уровне. Сотрудник разводил руками и говорил, что в падении выручки виноват, конечно, не он, а ретроградный Меркурий. Жаль, что DLP не читает гороскопы.

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

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

После той истории организация перестроила DLP-политики (включила в них автоблокировки). Кроме того, теперь при увольнении автоматически включался усиленный мониторинг активности сотрудников за последние 30 дней, а их внешние звонки и сообщения стали тщательнее анализироваться на предмет аномалий.

История 5: «Земельный вопрос»

Предыстория: Сотрудник телеком-оператора регулярно заходил на Avito с рабочего компьютера и просматривал объявления о продаже земельных участков. На первый взгляд ничего криминального, но это только на первый взгляд.

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

Как инцидент попал в поле зрения ИБ. Безопасники заметили аномальную активность: сотрудник часто в рабочее время заходил на Avito и просматривал объявления о продаже земли. Позже, когда стали разбираться, выяснилось, что именно эти участки попадали в закупочную программу.

Работник выкупал участки еще до того, как компания официально объявляла о своих планах, а затем сдавал их в аренду через подставных лиц. Схема не включала прямой слив данных. Это был просто тихий абьюз инсайдерской информации. Однако DLP и бдительные ИБ-специалисты справились на ура.

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

История 6: «Ничего личного, просто бизнес»

Предыстория: Руководитель инженерной группы пришел к ИБ с конкретным запросом. Он сказал: «У меня есть подозрение, что один из сотрудников работает на стороне. Помогите, пожалуйста, все проверить?»

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

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

Ключевой зацепкой стал не сам факт запуска AnyDesk, а тип подключения. Дело в том, что внутри компании все легитимные сессии удаленного доступа (если бы они были) шли по внутренним IP-адресам. А у сотрудника каждая сессия устанавливалась по уникальному AnyDesk ID, указывающему на внешний хост. Безопасники предположили, что инженер целенаправленно подключался к удаленным машинам другой компании.

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

История 7: «Свой-чужой»

Предыстория: DLP зафиксировала выгрузку фрагмента кода в публичный GitHub-репозиторий. У ИБ-команды сначала не было однозначного ответа: нарушение ли это? Ведь разработчики часто публикуют собственные проекты.

ИБ-отдел зафиксировал выгрузку кода во внешний репозиторий GitHub. Но в IT-среде выкладывать код в открытый доступ – не всегда преступление. Часто это могут быть личные проекты разработчиков или Open Source инициативы. Так началось расследование инцидента.

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

В ходе проверки также выяснили, что аккаунт на GitHub и репозиторий, куда выгрузили код, не были внесены в белый список. Таким образом DLP не просто заметила выгрузку, а точно установила, что утек именно код компании, а не личный проект. Разработчик объяснил, что «хотел сделать бэкап», но политика ИБ не предусматривала GitHub в качестве облака для резервного копирования.

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

История 8: «Работа на дом»

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

Сотрудница считала, что ее уволили несправедливо. Напоследок она решила отомстить работодателю, замаскировав месть под таким благовидным предлогом: «Забираю работу на дом, чтобы точно все завершить перед уходом». На деле же сотрудница копировала:

• сканы договоров с контрагентами;

• внутренние комментарии по переговорам;

• базы с контактами, ФИО и условиями сотрудничества.

Что послужило поводом для расследования. На сегодняшний день большинство DLP все еще слабо справляются с поведенческим профилированием. Они эффективно ловят утечки по объему. Например, когда сотрудник отправил 5 ГБ за сутки, а обычно работает с 50 МБ. Однако редко понимают, обращается ли пользователь к своим данным или к чужим.

В этом кейсе именно такой пробел. Расследовать инцидент специалистам помогли синергия DBF и DLP. В частности, DBF зафиксировала, что сотрудница копировала документы, с которыми обычно она не работает, а DLP в тот же момент показала, что эти данные были перенесены на флешку.

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

Конечно, во фразе «доделать отчет» нет ничего криминального, но, когда объем скачиваемых сотрудником данных превышает все мыслимые и не мыслимые размеры, это уже не рабочий героизм, а попытка «вынести» бизнес.

История 9 «Под маской идеальности»

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

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

Как сорвали «маску»: Сотрудник мечтал о повышении, но мечты продолжали оставаться мечтами. В итоге он решил имитировать бурную рабочую деятельность, установив на компьютер автокликер. Но работник плохо подготовился: не учел, что в компании есть DLP, которая может раскрыть такой обман в два счета.

DLP может отлавливать программные автокликеры через отчеты по рабочему времени. Причем программа справляется с этим самостоятельно – никаких интеграций с другими средствами защиты информации (СЗИ) не требуется. Вот как это работает: агент DLP на рабочем месте отслеживает, какие процессы запущены у пользователя. В отчете по рабочему времени видно, в каких программах сотрудник провел день, поскольку данные строятся на основе перехваченных процессов.

Эпилог

Ни одно СЗИ в одиночку не способно на 100% защитить корпоративные данные от атак и утечек. Информационная безопасность должна быть многоуровневой. DLP в этом контексте – не «волшебная кнопка», а инструмент усиления расследования.

DLP-cистема не всегда ловит утечку напрямую, но часто дает ИБ-специалистам почву для размышлений: скриншоты, логи, история коммуникаций, метаданные файлов, аудиозаписи, распознавание речи и пр. Все это облегчает сбор доказательств при проведении расследований инцидентов. Например, при поиске подтверждений того, что человек строит параллельный бизнес на вашей клиентской базе, перепродает оборудование, зарабатывает на инсайде, или просто спит в кабинете в рабочее время.

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

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