Инсайдерские угрозы в 2026 году: от диагностики риска до выбора DLP-системы

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

Что такое инсайдерская угроза и почему это не только про хакеров

Инсайдерская угроза — риск для компании, связанный с намеренными или непреднамеренными действиями сотрудников, подрядчиков и партнеров, имеющих легитимный доступ к системам и данным.

Выделяют три основных типа инсайдеров:

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

Проблема остается актуальной и для российских компаний. По данным исследования, утечка информации происходила в 56% успешных атак на российские организации. В 30% случаев среди похищенных данных были служебные документы с коммерческой тайной, в 24% — учетные записи, в 17% — персональные данные. При атаках на IT-компании социальная инженерия использовалась в 57% случаев.

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

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

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

Кому это действительно нужно, а кому — избыточно

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

В зоне повышенного риска:

• финансовый сектор — банки, страховые и финтех-компании работают с большими объемами финансовых и персональных данных;
• ИТ-компании — хранят исходный код, данные клиентов, коммерческие разработки и доступы к инфраструктуре;
• ритейл и e-commerce — обрабатывают базы клиентов, платежную информацию и историю заказов;
• промышленность — защищает техническую документацию, конструкторские разработки и ноу-хау;
• организации, работающие с ПДн, гостайной и другой чувствительной информацией.

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

Никита Туркин
Аналитик информационной безопасности, УЦСБ

Для крупного предприятия выявление инсайдерских угроз — обязательный шаг: торговля информацией или подкуп сотрудников вредят бюджету и репутации. Крупный бизнес применяет организационные (ОРД, разделение доступов) и технические меры (DLP с модулями UEBA, DCAP). Например, один из системообразующих банков внедрил поведенческие модули DLP во всех дочерних организациях для аудита ИБ.

В среднем бизнесе при преобладании ручного труда внедрение СЗИ нецелесообразно. Если специфика — интеллектуальный труд на ПК, ставить DLP на ПК сторожа, в кадры или АХО избыточно. Правильное решение — оценка рисков: например, производителю приборов в первую очередь необходимо защитить информацию о производстве и каналах сбыта.

Для небольшого ИТ-предприятия на 10 человек достаточно начать с организационных мер: ОРД, аренда инфраструктуры (облако, почта, БД) и настройка доступов. Если же это консалтинговое агентство с конфиденциальными данными, имеет смысл подключить и специализированные СЗИ.

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

Владимир Арышев
Эксперт по комплексным проектам информационной безопасности STEP LOGIC

Не каждой компании нужны сложные системы выявления инсайдерских угроз. Если речь идет о небольшой организации с десятком сотрудников в одном офисе, то обычно бывает достаточно грамотно настроенных прав доступа, журналирования событий и базовых средств контроля. Совсем другая ситуация в случае крупных компаний с распределенной структурой, удаленными сотрудниками, подрядчиками и большим объемом конфиденциальной информации, как, например, банки, промышленные предприятия, телеком, ритейл, ИТ-компании, медицинские организации. Более того, они регулярно сталкиваются с рисками, связанными не только с умышленными действиями сотрудников, но и с их обычными ошибками. К сожалению, именно человеческий фактор остается одной из самых распространенных причин утечек.

С чего начать построение системы защиты

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

Александр Красницкий
Заместитель руководителя отдела расследования высокотехнологичных преступлений Angara MTDR
Начинать необходимо с определения критичных данных и опасных сценариев. То есть фактически создать модель угроз, как бы бюрократизировано это ни звучало. Определить недопустимые для компании события и попытаться спрогнозировать их последствия: потерю денег, репутационный ущерб, штрафы регуляторов, утрату доверия клиентов или остановку бизнеса. Также необходимо учитывать не только собственные риски компании, но и требования законов и регуляторов к защите персональных данных, коммерческой тайны, а для отдельных организаций — объектов критической информационной инфраструктуры.

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

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

Дмитрий Карасовский
Руководитель отдела по информационной безопасности Axiom JDK
На этом пути организации часто совершают одни и те же ошибки. Противопоставление безопасности бизнесу приводит к тому, что сотрудники начинают саботировать систему и искать обходные пути. Одновременное включение всех политик останавливает рабочие процессы и демотивирует персонал. А игнорирование исключений порождает поток ложных срабатываний, который снижает доверие к системе в целом.

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

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

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

Технические и организационные требования до внедрения DLP/UEBA

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

Али Гаджиев

Руководитель продукта Solar Dozor ГК «Солар»

Для DLP прежде всего необходимо понимать, какие категории информации компания считает чувствительными и по каким каналам они могут передаваться. По данным «Солара», 35% утечек происходили через мессенджеры, еще 23% — через корпоративную электронную почту. В конкретной компании к ним могут добавляться облачные хранилища, веб-сервисы, съемные носители или печать документов.

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

Полезен и централизованный сбор событий: он позволяет сопоставлять данные DLP или UEBA с активностью в других системах. Но наличие SIEM я бы не считал обязательным условием для старта. Критичнее качество исходных данных и наличие процесса, по которому выявленный сигнал превращается в расследование.

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

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

Есть и юридическая сторона. Мониторинг действий сотрудников затрагивает обработку персональных данных и трудовые отношения, поэтому до запуска системы необходимо определить правовые основания для такого контроля, уведомления и локальные нормативные документы. При работе с персональными данными нужно учитывать требования 152-ФЗ «О персональных данных» и трудового законодательства.

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

Роли участников проекта внедрения

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

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

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

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

Этапы внедрения проекта

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

1. Пилотный запуск

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

2. Настройка политик и правил детектирования

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

3. Обучение и коммуникация

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

4. Постепенное масштабирование

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

Чек-лист запуска

• Определен пилотный контур и ответственные за проект.
• Проверены интеграции с необходимыми корпоративными системами.
• Определены критичные данные и сценарии контроля.
• Настроены и протестированы политики детектирования.
• Проверено количество ложных срабатываний.
• Сотрудники уведомлены о запуске и правилах мониторинга.
• Определен порядок расследования и реагирования на инциденты.
• Зафиксированы критерии успешности пилота.
• Подготовлен план масштабирования.

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

Как выбрать решение

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

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

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

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

На практике решения могут дополнять друг друга, например, DLP контролирует передачу данных, UEBA выявляет аномальное поведение, а SIEM собирает события из этих систем и связывает их с другими событиями безопасности.

При сравнении продуктов стоит смотреть прежде всего на:

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

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

Николай Перетягин
Менеджер по продукту Dataplan, компания NGR Softlab
Необходимо все же в первую очередь отталкиваться от решаемой задачи. Если для выявления инсайдерской деятельности достаточно применить правила и условия сравнения параметров поведения с точно известными предельными значениями, то будет достаточно использования встроенных в SIEM, DLP, DCAP и подобных решений политик/правил/движков поведенческого анализа.

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

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

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

Как оценить эффективность системы после внедрения

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