Развертываем endpoint-агенты легким движением руки

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

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

Итак, агенты DLP-системы Solar Dozor контролируют такие каналы передачи данных, как мессенджеры, съемные носители, облачные сервисы, принтеры и другие. В нашей практике Dozor Endpoint Agent не раз предотвращал утечки через эти каналы. Например, сотрудник перед увольнением решил «прикопать» себе десяток документов для дальнейшего использования на другом месте работы. Другой захотел обогатиться и слить базу клиентов конкурентам. А третий при копировании фотографий с корпоратива на флешку случайно прихватил и папку с фотографиями паспортов клиентов.

Для администраторов DLP-системы важно, чтобы все задачи решались предельно просто и так же просто можно было понять, всё ли было решено корректно. Ведь, как правило, работают с системой от одного до нескольких десятков человек, и при этом они обеспечивают безопасность конфиденциальных данных компании с численностью сотрудников от 10 до нескольких сотен тысяч(!) человек. Согласитесь, весьма не просто было бы выполнять такую работу, не используя подобные системы.

Информация о станциях и управление агентами

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

Рисунок 1. Внешний вид интерфейса системы, зона «Перехватчики - Endpoint Agent»

В нашей DLP-системе предусмотрено несколько способов провести удачное «знакомство».

Самым быстрым является добавление АРМ (автоматизированного рабочего места) вручную по IP-адресу или hostname. Используя этот метод, пользователь получает возможность сразу определить АРМ в нужную группу с необходимыми настройками и дистрибутивами агента.

Предварительная настройка серверной части позволяет синхронизироваться с Active Directory (AD) и добавлять станции в пару кликов. Конечно же предусмотрен вариант и для небольших компаний, которые не имеют в своем арсенале AD. Они могут проделать данную операцию, явно указывая имя хоста или IP-адрес АРМ.

Рисунок 2. Инструмент для добавления рабочих станций

Однако наша DLP-система этим способом не ограничена. Разработанный ГК «Солар» специальный модуль развертывания может попасть на подконтрольную АРМ несколькими способами на выбор. Это могут быть сторонние средства, такие как групповые политики AD, корпоративное ПО, способное выполнять функцию установки/удаления ПО, или же можно установить модуль вручную.

После установки и запуска модуль отправляет в Solar Dozor необходимую для регистрации АРМ информацию. Серверная часть ее обрабатывает и регистрирует АРМ во временной группе в списке станций. При этом запись получает статус «Ожидает распределение по группам», который подсказывает администратору дальнейшие шаги для выполнения установки Dozor Endpoint Agent.

Администратору системы доступна следующая информация по добавленной станции:

• Имя хоста и IP-адрес
• Имена сотрудников, использующих станцию
• Информация об установленной ОС (в том числе её версия)
• Версия установленного агента

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

Если говорить о способах установки агента, то здесь предусмотрен весьма широкий спектр разнообразных вариантов. Самые основные:

• Установка вручную
• Установка через пользовательский интерфейс Solar Dozor
• Установка с помощью сторонних средств централизованного развёртывания ПО

Отдельно отмечу, что предусмотрено всё необходимое для установки и использования агента в VDI-среде.

Обо всех способах установки мы обязательно подробнее расскажем в отдельной статье.

А сейчас хотелось бы поговорить о проблемах, с которыми сталкиваются пользователи DLP-систем.

Диагностирование проблем и рекомендации по их решению

Часто в случае возникновения каких-либо ошибок при работе с программным обеспечением (ПО) пользователь получает в лучшем случае всплывающее окно с кратким описанием проблемы.

Бывает, что вместо понятной ошибки выдается только код этой самой ошибки. При этом для разбора проблемы пользователь вынужден либо анализировать журналы ПО, либо искать ответы где-то ещё (техническая поддержка, сеть интернет и т.д.).

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

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

Проблемы могут быть разного характера. Например, такие как:

• проблемы с доступностью станции при развертывании агента (отсутствует доступ к станции по протоколам SMB или WinRM)
• проблемы с учетной записью администратора, используемой для доступа к станции (некорректные учетные данные, отсутствие необходимых прав)
• наличие компонентов конфликтного ПО
• отсутствие необходимых обновлений ОС или неподдерживаемая версия ОС

Для выявления, решения и предотвращения таких и аналогичных проблем необходимо, чтобы система могла их корректно диагностировать.

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

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

Когда возникает проблема, которую решить силами заказчика невозможно (отсутствие возможности внесения изменений в инфраструктуру), можно попробовать найти обходной вариант решения, исходя из имеющегося функционала. Если и тут ничего не помогло, то остается только один вариант – доработка продукта.

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

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

Типичные проблемы, с которыми сталкиваются пользователи DLP-систем

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

Диагностика проблем доступности станции

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

Диагностика проблем с учетной записью администратора, используемой для подключения к станции

Часто встречаемая проблема. Необходимо максимально понятным языком обозначать возникшую проблему.

Выявление наличия ПО, которое может вызывать конфликты

Может оказаться, что на станции присутствует ПО, которое может вызывать проблемы при работе агента. Например, агент будет работать некорректно. А может и вовсе привести к тому, что операционная система (ОС) начнет «уходить» в т.н. «синий экран» (он же «экран смерти»).

Самое лучшее – это выявлять наличие такого ПО ещё до начала установки агента. Таким образом удастся не допустить возникновения описанных выше проблем (а главное - их последствий).

Выявление отсутствия необходимых обновлений ОС Windows на станции

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

Выявление неподдерживаемой версии ОС, установленной на станции

Что бывает, когда выполняется попытка установки ПО на неподдерживаемую версию ОС? Правильно – можно нарваться на неприятности столкнуться с последствиями, которые потом придётся устранять (возможно, долго). Поэтому инструмент диагностирования также должен выявлять и такие нюансы.

Нарушение целостности компонентов агента

Может случиться, что установка агента была выполнена корректно, а затем по тем или иным причинам что-то произошло с его компонентами. Возникает риск потери важных перехватов.

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

Endpoint Agent недоступен

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

В любом случае, необходимо «сигнализировать» о таких станциях своевременно.

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

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

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

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