Может ли endpoint-агент работать стабильно на 300 тысяч + рабочих станций? Делимся секретами успеха

Введение

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

Сетевая нагрузка

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

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

Такой сервер способен получать трафик на указанный порт и распределять полученный от агентов поток по различным узлам. Их количество зависит от общего числа автоматизированных рабочих мест (АРМ), контролируемых в компании, и рассчитывается еще до внедрения. Теперь все endpoint-агенты обращаются к балансировщику, который распределяет трафик между узлами. Казалось бы, проблема решена… Но не все так просто!

Разгружаем сервер

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

Большинство java веб-серверов – синхронные. Особенность их работы заключается в резервировании отдельного потока (thread) на каждый http-запрос. В случаях медленного или нестабильного сетевого взаимодействия между агентом и сервером, а также при большом объеме перехваченных данных передача не может осуществляться мгновенно. Обработка будет происходить частями. Значит, на каждый запрос будет открыт новый thread, который не освободится до тех пор, пока запрос полностью не будет обработан. Лишь после этого он вернется обратно в пул, откуда может быть использован повторно.

Легко можно рассчитать, что на 1000 запросов с таймингом обработки каждого в 1 секунду сервер израсходует 1000 потоков. Это не слишком критично, когда агентов несколько сотен, но при большем количестве заметно уменьшается производительность.

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

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

Виртуальное счастье

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

Однажды, один из заказчиков обратился к нам с предложением рассмотреть возможность взять под контроль и такие рабочие места. Главной проблемой здесь стала невозможность отслеживать временные виртуальные АРМ и своевременно удалять более не используемые. В небольших организациях можно попытаться реализовать такой контроль в ручном режиме, однако в масштабах заказчика (более 300 тыс. динамических АРМ) это становилось непосильной задачей. Кроме этого, агент на клонированной машине должен быть уникальным с собственным персональным ID. Очевидно, требовалась автоматизация процесса.

Мы проанализировали ситуацию и сформулировали 3 основные задачи, которые требовалось решить.

1. Автоматическое распределение клонированной АРМ в группу с соответствующими настройками перехватов на сервере DLP-системы.
2. Своевременное удаление неиспользуемых АРМ из списка.
3. Триггеры для генерации уникального идентификационного номера каждого агента.

Для решения этих задач endpoint-агент получил в свое распоряжение два дополнительных параметра – метка и флаг. Они позволили немного скорректировать запрос от клонированных машин. Теперь при их наличии агент передает произвольную метку (заказчик может сгенерировать ее самостоятельно). При указании такой же метки в настройках группы на сервере, куда предполагается распределить АРМ, система получает возможность выполнять автоматическое добавление станций в группу.

Рисунок 1. Настройка автодобавления станций в группу

Флаг позволяет идентифицировать вновь созданную машину как временную и сгенерировать ряд параметров для помещения ее в категорию временных АРМ (рис. 2), а также определить таймаут удаления из списка агентов на сервере (рис. 3). Для более комфортного управления была добавлена настройка, позволяющая задавать период таймаута. Кроме этого, флагом диктуется необходимость присвоения уникального ID.

Рисунок 2. Категория временных станций

Рисунок 3. Настройки по выставлению таймаутов

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

Победа любит подготовку

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

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

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

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

Рисунок 4. Элементы управления Endpoint Agent с сервера

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

В данном случае размер такой таблицы увеличивался в прямой прогрессии и мог вырасти с 1ГБ до 300ГБ всего за несколько дней. Это, в свою очередь, сказывалось и на ее производительности. Ведь при последовательной обработке приходилось считывать большее количество частично заполненных блоков. При малом количестве агентов подобная проблема не критична и практически не оказывает влияния на работу, однако в описываемом кейсе масштабной интеграции она становилась заметнее и приводила к ошибкам. После оптимизации таблицы проблема была успешно устранена.

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

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

Выводы

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

Автор: Евгений Гришкин, инженер 3-й линии поддержки компании «Ростелеком-Солар»