Почему DLP пора оторваться от агентов?

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

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

Как устроен «размытый» периметр

С распространением «удаленки» сотрудники стали массово использовать публичные сервисы: облака, мессенджеры, веб-редакторы – для совместной работы с корпоративными данными вне офиса, в любое время и с любого устройства. К удобству привыкли. Теперь мобильными становятся уже не публичные, а корпоративные сервисы, и бизнес берет их на вооружение. Например, даже рабочее ПО остается в контуре номинально: сотрудники часто подключаются к условным «Битриксу» или Jira через клиент или браузер с любого устройства. Это значит, что процессы работы с информацией выполняются не на рабочей станции, а на стороне сайта или внешнего сервера.

Кроме того, в рамках импортозамещения растет популярность Linux-систем. Не у всех из них есть графический интерфейс, поэтому разработчики корпоративного ПО для Linux чаще реализуют web-версии своих приложений. Это убирает необходимость локальной установки ПО и позволяет перенести серверную часть в облако в целях удобства. В свою очередь, импортозамещающиеся компании будут все активнее этим пользоваться. Так что тренд на сервисы, проводящие процессы не на ПК сотрудника, станет только актуальней.

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

• Мессенджеры и ВКС;

• СХД (любые сетевые/облачные хранилища);
• Браузеры (любая работа в веб);
• Почта;
• Съемные устройства (флешки и жесткие диски);
• Печать.

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

Контроль с обратной стороны

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

Например, у заказчиков распространены коммерческие ВКС и мессенджеры. Доступ к ним осуществляется как через корпоративную технику в ЛВС, так и через личные устройства сотрудников. Часто встречается сценарий, когда конфиденциальные данные выгружаются вовне через историю переписки: номинально их могли передавать на рабочем месте, но они сохраняются в чате, который можно прочитать откуда угодно. Если же интегрировать DLP с мессенджером напрямую, система сможет заблокировать данные в чате без привязки к устройству – потому что контролирует чат в месте его фактического существования. Это применимо и для облачных хранилищ, данные из которых можно передавать вовне в виде ссылок. DLP в момент формирования ссылки увидит, что контент по ней конфиденциальный, и сможет его защитить.

Однако возникает еще одна сложность. С ростом популярности «мобильного» бизнес-ПО количество таких сервисов растет по экспоненте. Реализовать контроль сразу всех «из коробки» разработчику DLP объективно не под силу.

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

Что может сделать заказчик

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

• REST API
• ICAP
• ODBC
• SYSLOG/CEF

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

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

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

Что должен сделать вендор

И все же универсальные технологии поддерживают не все сервисы, которые нужно контролировать с DLP. Это характерно для экосистем, которые работают по своим внутренним стандартам. И тут уже потребуется помощь вендора.

Так, чтобы внедриться в Microsoft 365, мы реализовали в нашей DLP поддержку формата Graph API. Это потребовало полновесной разработки нового функционала: работы архитекторов, программистов, тестировщиков. Если заказчику срочно нужна поддержка такой платформы, а у вендора нет готового решения, придется ждать. При этом потребность в контроле экосистем у заказчиков растет: например, у госсектора, который перевел работу в ГКС/VK Workspace (тоже развивается на собственной уникальной базе). Для решения задачи сегодня организациям требуется искать DLP, где нужные платформы уже поддержаны.

Хорошая новость в том, что подобных экосистем, ПО для совместной работы и т.д., достаточно широко используемых в реальной практике бизнеса, не так много. Поэтому разработчикам DLP под силу их поддержать. Основные игроки DLP-рынка уже работают с наиболее востребованным сервисами «из коробки», либо активно дорабатывают функционал. Помогают и разработчики самих платформ. Так, недавно «Яндекс» представил готовый механизм передачи данных из облачной бизнес-платформы «Яндекс 360» в DLP через API. Такое движение навстречу вендорам СЗИ – хорошая практика, которая имеет все шансы стать повсеместной, как уже стала среди российских разработчиков ОС, СУБД и ряда прикладного ПО.

Заключение

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

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

• Составить список корпоративных сервисов. Узнать, какие DLP поддерживают их «из коробки».
• Сравнить технологии обмена данными у корпоративных сервисов и DLP. Если готовой интеграции нет, она может быть доступна на уровне этих технологий. При наличии удобного интерфейса с их помощью можно интегрировать DLP самостоятельно – и получить результат сразу.
• В особых случаях нужно запрашивать у вендора доработки. Это распространенная практика. Она полезна как вендору, который внедряет нужный рынку функционал, так и клиенту. Например, за последние пару лет мы сделали больше сотни интеграций с разными сервисами и ПО, а всего реализовали более тысячи «фич» по запросам заказчиков.

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

Автор – Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».