На связи Илья Иванов, я отвечаю за развитие продукта Гарда DLP. Инсайдерские риски — это не только про умышленные сливы данных. Сотрудник может случайно ошибиться, нарушить регламент или воспользоваться внешним сервисом, который компания не контролирует.
В такой ситуации желание бизнеса защититься по максимуму вполне понятно. DLP (Data Leak Prevention) как раз позволяет контролировать передачу данных и помогает разобраться в произошедшем, если что-то пошло не так. Неудивительно, что для многих российских компаний DLP остается одним из основных инструментов защиты информации. Это подтверждает свежее исследование Piccard «На пути к платформе защиты данных» за 2026 год. При выборе решения компании в том числе смотрят на охват каналов коммуникации, возможности сбора дополнительной информации и количество рабочих машин, которые можно подключить к системе.
Но желание защититься по максимуму может привести к новым сложностям.
Для сотрудника DLP, о нюансах работы которой он мало что знает, система легко превращается в цифрового Цербера: кажется, что она следит за каждым шагом, а что именно она собирает и кто потом это увидит, непонятно. Такие страхи создают лишнее напряжение и могут негативно сказаться как на атмосфере в коллективе, так и на качестве работы человека. С другой стороны, компания может настолько опасаться задеть ментальное здоровье сотрудников, что часть возможностей DLP останется невостребованной. Или пойти в другую крайность и настроить контроль по принципу «пусть собирает максимум из возможного, а там разберемся». В обоих случаях получить от системы всю заложенную в решении пользу не получится.
В этой статье попробую разобраться, где проходит граница между достаточным контролем и его избытком, почему вокруг DLP возникает столько страхов и как использовать возможности системы так, чтобы они действительно помогали защищать данные, а не порождали новые риски.
Страхи вокруг DLP
У многих сотрудников при слове DLP в голове загорается та самая лампочка Ильича: а что теперь будет видеть работодатель?
Мне кажется, основная причина настороженного отношения к DLP как раз в том, что далеко не все понимают, как именно работает решение и что происходит за кулисами. А когда информации мало, мозг легко достраивает недостающие детали сам — отсюда страхи, стереотипы и кривотолки вокруг DLP. С подобными опасениями я не раз сталкивался. Не претендую на исчерпывающий список — если встречали что-то еще, предлагайте свои варианты в комментариях. Пока попробую разобрать самые распространенные в моем шорт-листе.
DLP-cистема станет инструментом для сведения личных счетов между руководителем и подчиненным. Я бы отнес этот страх в разряд стереотипов. Все мы не раз видели, как в фильмах биг босс отдает по телефону указание, и уже через полчаса на человека приносят толстую папку с компроматом, собранным на основе анализа содержимого его ноутбука. В реальности подразделения ИБ (а только они могут получить доступ к информации от DLP) подчиняются, если не лично генеральному директору, то кому-то из топ-менеджмента. Руководители уровнем ниже уж точно не могут просто попросить ИБ собрать информацию о каком-то неугодном коллеге.
Вдобавок взять и просто так использовать данные в качестве основания для увольнения не удастся. Если не было нарушения правил информационной безопасности, то и полученная с помощью систем защиты информация не может использоваться в других целях. Суд такие доказательства не примет.
Личные данные станут общественным достоянием. Предположить, что при нарушении со стороны сотрудника правил использования корпоративного оборудования офицеры ИБ увидят личные данные, можно, но что разгласят их — крайне маловероятно.
Должностные инструкции офицеров ИБ жестко ограничивают возможные действия с информацией, полученной ими в ходе служебной деятельности. Как правило, все системы DLP имеют нередактируемый журнал действий пользователей системы, а возможность экспорта данных DLP ограничивается ролевой моделью.
По времени работы на ноутбуке или компьютере будут судить о продуктивности. И это, пожалуй, единственно возможный реальный сценарий. Но здесь тоже не всё так однозначно. Такой контроль экономически целесообразен, если речь идет о сотрудниках, в чьи обязанности входит непрерывно находиться на «посту». Например, специалисты первой линии технической поддержки, операторы кол-центра и т. д. Контроль рабочего времени остальных зачастую не показателен, и большинство компаний это понимает.
Когда излишняя лояльность мешает защите данных
Есть компании, которые в борьбе за хороший климат в коллективе запускают DLP либо только после реального инцидента, либо при наличии веских оснований подозревать утечку. Безусловно, этот подход прямо кричит о доверии. Но есть одно большое «но»: при таком подходе DLP, как правило, уже не поможет. Если произошла целенаправленная кража данных, вероятность обнаружить улики или хотя бы косвенные признаки заметно снижается.
Более зрелый подход работы с DLP — заранее определить, какие события и каналы действительно важны для защиты данных, и обеспечить постоянный мониторинг именно там, где он нужен. Ибо у специалистов ИБ нет задачи вести тотальный контроль, им нужна именно возможность восстановить картину событий, когда это действительно понадобится.
Ретроспективный анализ, а ИБ-расследование — это всегда ретроспективный анализ, эффективен, только если есть архив событий безопасности и объектов перехвата DLP.
Когда происходит утечка данных, то круг людей, которые работали с этой информацией, обычно ограничен. ИБ-специалистам хочется как можно быстрее положить на стол руководству результаты расследования, наказать виновного и приступить к реализации превентивных защитных мер. Но спешка тут — плохой помощник. Не стоит пренебрегать данными, которые хранят архивы объектов контроля. К примеру, у нас был кейс, когда такое расследование внезапно показало, что утекшими данными «интересовался» совершенно другой сотрудник — тот, кто вообще не должен был иметь к ним доступа. Просмотрели настройки учетных записей и обнаружили, что год назад действительно выдавали временный доступ к информации, но закрыть его забыли.
Есть еще один сценарий, когда DLP может сослужить хорошую службу уже самим сотрудникам. Согласно последней статистике, 21% опрошенных сотрудников отправляли электронную почту с чувствительной информацией не тому адресату. И хорошо, если просто не тому коллеге, но зачастую письмо улетало клиентам, подрядчикам, а то и вовсе незнакомым людям (например, когда ошиблись в букве имени почтового адреса). DLP как раз может стать для сотрудника защитным зонтиком: она заблокирует отправку небезопасного письма, ИБ увидит алерт, начнет расследование и выяснит, что ошибка в адресе возникла случайно. Сотрудник, скорее всего, отделается предупреждением (утечки ведь не произошло). А вот без DLP утечка всё же произойдет, но доказать свою невиновность человеку было бы в разы сложнее, да и последствия были бы куда серьезнее.
Что DLP видит на самом деле, а что только фантазии
Не стану подробно описывать всю функциональность DLP-систем. Вместо этого посмотрим, что именно видит DLP на примере двух распространенных кейсов: публичного мессенджера и личного облачного хранилища, установленных на рабочей машине и используемых в том числе для корпоративных задач и коммуникаций.
Ситуации, когда личные мессенджеры и облачные хранилища используются для решения рабочих задач, встречаются довольно часто. Большинство компаний работает с клиентами, субподрядчиками и иными контрагентами. Поэтому, если не брать в расчет электронную почту, публичные мессенджеры остаются эффективным, а иногда и единственным средством оперативной коммуникации.
Похожая история с публичными облачными хранилищами: доступ внешних лиц к корпоративным облачным хранилищам, как правило, либо заблокирован, либо существенно затруднен. А иногда бывает нужно оперативно поделиться драфтом договора или записью общей встречи в ВКС.
В обоих случаях у сотрудника возникает вполне логичный вопрос: контроль всего, чем я обмениваюсь с коллегами, партнерами или подрядчиками по работе — это нормально, но что насчет личной переписки?
Облачные хранилища
Первый и самый важный момент — DLP контролирует исключительно движение файлов. Система не получит (и даже не пытается) креды от вашего личного облачного хранилища. То есть сценарий, когда ИБ «под покровом ночи» входит в личное облачное хранилище сотрудника и изучает всё, что там находится, абсолютно исключен.
Более того, DLP не видит ни перечень файлов, ни содержимое личного облачного хранилища сотрудника. Система контролирует только те данные, которые сотрудники загружают или выгружают из личного облака на рабочую машину.
Отмечу, что DLP сначала производит контентный анализ содержимого файлов с целью поиска в них конфиденциальной или критичной для бизнеса информации. И только при наличии таковой создается событие безопасности, в рамках которого ИБ может увидеть, а точнее, обязан изучить, содержимое передаваемого файла.
Ситуация, когда политики настроены на тотальный перехват и ИБ видит все загружаемые или передаваемые файлы на рабочую машину, скорее, из области фантастики. Повторюсь, если данные просто хранятся в облаке и сотрудник никак не взаимодействует с ними через рабочую машину, DLP не сможет их получить.
Мессенджеры
Технически DLP-система может увидеть все исходящие и входящие сообщения и передаваемые через мессенджер файлы, но, как я обозначил ранее, DLP работает с данными в движении. Иными словами, вся предшествующая переписка в многочисленных чатах останется для системы невидимой. Конечно, нельзя исключать ситуацию, когда вы на компьютере открыли мессенджер, чтобы ответить заказчику, а в этот момент вам в соседнем чате начали писать друзья и спрашивать о планах на выходные. Если сотрудник решит с рабочей машины ответить на сообщение другу, это сообщение тоже попадет в поле зрения DLP, так как оно относится к данным в движении. Но, как и в предыдущем кейсе с облаком, содержимое сообщения будет подвергнуто контентному анализу, и только если в нем DLP обнаружит конфиденциальную или критичную информацию, это станет событием безопасности.
В отношении мессенджеров DLP точно не сможет получить креды от аккаунта, увидеть полный список контактов (кроме тех, с кем будет переписка с рабочей машины), созданные чаты или всю историю переписки. Она видит только то, что проходит через рабочую машину в моменте: название чата, дату, время и имя пользователя, которому отправлено или от которого получено сообщение, содержимое сообщения или файла.
На примере этих двух кейсов я постарался объяснить принцип работы DLP в целом и логику работы ИБ. Далее поделюсь четырьмя постулатами относительно DLP, которые помогают понять, как устроен процесс контроля и как можно снизить количество лишних вопросов со стороны сотрудников.

Где проходит граница необходимого контроля за данными
При приеме на работу сотрудник, как правило, подписывает соглашение, в котором обязуется использовать оборудование в рабочих целях. Однако это вовсе не означает, что компания автоматически получает право собирать и хранить любую информацию, которая окажется на рабочем устройстве. Согласие сотрудника на мониторинг рабочего оборудования не означает согласия на сбор информации о его частной жизни в смысле статьи 24 Конституции РФ. Работодатель вправе контролировать только сохранность имущества и отслеживать, насколько корректно человек выполняет служебные задачи.
Согласие сотрудника на мониторинг действий на рабочем компьютере не является «индульгенцией на всё».
Как я уже отметил выше, в процессе работы DLP фиксирует события, связанные с передачей и обработкой данных. Но компания не всегда задумывается о том, что происходит с этой информацией после того, как она попадает в систему.
И здесь как раз возникает парадокс: DLP устанавливают, чтобы защитить данные от утечек, но в процессе работы сама система создает новый массив информации, который тоже нужно защищать. В ее архиве могут оказаться персональные данные сотрудников или других людей, документы и прочие сведения, с которыми они взаимодействуют в ходе работы.
О чем стоит подумать CISO, чтобы DLP не создала новых рисков
Выше мы уже поговорили о том, что DLP технически может увидеть больше, чем компании действительно нужно для защиты. Поэтому перед внедрением такого решения бизнесу важно ответить не только на вопрос, что умеет продукт, но и на то, что именно нужно защищать и какой объем защитных мероприятий для этого действительно необходим.
Для этого сначала придется понять, от каких угроз компания хочет защититься, какие каналы требуют контроля и насколько глубоко в них действительно нужно заглядывать. Затем — определить, какие данные компания считает ценными и конфиденциальными, доведя эти правила до сотрудников. Человек не должен догадываться, можно ли передавать тот или иной файл или данные: у него должна быть понятная инструкция и единый источник, где это можно проверить.
Причем это важно не только для последующей настройки DLP. Если сотрудникам заранее объяснить, какие данные компания считает ценными и почему их нельзя распространять бездумно, часть рисков можно снять еще до внедрения технических средств контроля. Исследования за последние три года показывают, что более 40% утечек происходит неумышленно — из-за незнания и по неосторожности.
Отдельный вопрос — что делать с данными, которые DLP получает в процессе работы. Не вся информация требует одинакового уровня контроля: где-то достаточно зафиксировать сам факт действия, где-то — скрыть содержимое, а где-то — вообще не стоит его сохранять. Для защиты собранного массива данных могут использоваться технологии маскирования или шифрования, разграничение доступа к архиву и ограничения на срок хранения. При этом важно заранее определить, кто и в каком объеме может получить доступ к данным DLP.
Резюмируя, еще раз подсвечу, что задача здесь не в том, чтобы собрать как можно больше информации о действиях сотрудников. Важно найти минимально достаточный уровень контроля, который позволит защищать действительно ценные данные, не превращая при этом инструмент контроля в источник дополнительных рисков.
Чтобы не потерять эти вопросы при внедрении DLP, собрал их в короткий чек-лист.

Практически со всеми популярными возражениями со стороны противников DLP можно работать, и в целом важно помнить, что DLP — всего лишь инструмент, а как им пользоваться — зависит уже от принятой в компании концепции и полномочий ИБ.
А с какими препятствиями вы сталкиваетесь, когда речь заходит об установке DLP?
stackshortlist
Хорошо, что подняли тему прозрачности для сотрудников, на практике именно непонимание того, что собирает система, вызывает больше всего сопротивления. Мне кажется, многое решает понятный внутренний регламент: какие каналы контролируются, кто имеет доступ к инцидентам и сколько хранятся данные. Интересно, рекомендуете ли вы заранее показывать сотрудникам, как выглядит карточка инцидента, или это скорее вредит?