Привет! Я Максим Чеплиёв, менеджер продукта Staffcop, одного из ИБ-сервисов Контура. Расскажу, как мы разрабатываем Staffcop так, чтобы он не нагружал безмерно IT-инфраструктуру клиента. Сразу оговорюсь, что не буду рассказывать о технической реализации на уровне кода, но обращу внимание на уровень архитектуры и стратегических решений.
Staffcop — это сервис для расследования ИБ-инцидентов и мониторинга действий сотрудников на компьютерах. Работает он так: на устройства сотрудников ставятся «агенты», которые передают данные об их действиях на сервер сервиса, развёрнутый в инфраструктуре клиента. Поэтому работа Staffcop связана не только с технической инфраструктурой, но и с работой специалистов по безопасности, которые используют сервис по назначению, IT-специалистов, которые занимаются его развёртыванием, и рядовых сотрудников, на чьих компьютерах установлены агенты.
Дисклеймер: установка Staffcop легальна. Агенты ставятся только на рабочих компьютерах — это собственность работодателя и он имеет право контролировать действия сотрудника на служебных ПК. Кроме этого, сотрудники подписывают согласие с ИБ-политикой компании.
Архитектура решения состоит из агентов, сервера и сети, по которой информация от агентов передаётся к серверу. Поэтому дальше расскажу, как каждый из элементов может нагружать инфраструктуру, и как мы с этим справляемся. В конце будет про то, как мы пытаемся снизить нагрузку на людей, а не только на технику.
Элемент первый: агенты
Зачем они нужны
Основная задача сервиса — расследование ИБ-инцидентов. Инцидент — это, например, утечка данных из-за их передачи через мессенджер. Агенты устанавливаются на компьютерах сотрудников и как раз фиксируют действия пользователей, например, передачу файлов третьим лицам.
Проблема 1: большая нагрузка на память
Раз агент устанавливается на компьютере сотрудника, то его работа может саботировать действия пользователя. Например, слишком большой объём агента или нагрузка на операционную память может помешать сотруднику выполнять его задачи. Кроме этого, агент взаимодействует с другими приложениями, и важно, чтобы это не приводило к каскадному росту нагрузки: в Telegram передаётся файл, агент его копирует и это дополнительно нагружает арм пользователя.
Как мы спасаем ситуацию
Чтобы не блокировать работу пользователя, мы делаем агенты лёгкими, а также выставляем ограничения на работу с памятью и на трафик.
Что же такое лёгкие агенты
Агент собирает данные практически со всех каналов, взаимодействуя с операционной системой, сетевыми ресурсами, сертификатами и реестром. Чтобы не повышать нагрузку и не тратить ресурсы, которые нужны на работу приложений, мы сразу сделали агент минимального размера. Ещё на этапе разработки архитектуры учитывали, что он должен иметь минимум модулей, потребляющих память, и заранее закладывали небольшой размер пакетов для установки.
Инструменты управления работой агента
Агент не только собирает данные, но и передаёт их серверу, чтобы затем их можно было использовать для расследования инцидентов. Но если сервер недоступен или рабочую станцию использует удалённый сотрудник, нужно сохранять данные на рабочей станции.
Чтобы снизить нагрузку, мы регулируем, контролируем и ограничиваем объём хранимых данных. Кроме этого, организовали их ротацию, так что при переполнении памяти удалять будут файлы, а не события — и это не повлияет на статистику по действиям пользователя.
Также эти ограничения пригождаются не только при логировании, но и при перехвате файлов. Пользователь передаёт запрещённый файл через мессенджеры, агент сохраняет файл, чтобы затем передать его на сервер, и тратит оперативную память.
Оптимизация функций
Сильнее прочего ресурсы нагружает функция видеозаписи действий пользователя. Причём нагружает не только оперативную память ПК, но и сеть, и конечный сервер. Оптимизация потока не решает проблему кардинально. Поэтому мы заменили запись видео на запись снимков экрана. По сути, это серия скриншотов, снятых с разницей в миллисекунду, при этом, это не полноценные скриншоты, а запись изменений.
Кроме этого, мы используем вариативный алгоритм сжатия, чтобы ещё сильнее уменьшить объём скриншотов. Инструмент по созданию пакетов сам меняет алгоритм в зависимости от доступных ресурсов на конечной рабочей станции. Чем больше процессов запущено, тем сильнее сжимаются данные.
В итоге это позволяет снижать объём одного и того же куска информации с 500 мб при видео до 10 мб для серии скриншотов.
Проблема 2. Конфликты при контроле трафика
Агенты анализируют обращения приложений к ресурсам сети посредством подмены сертификата, за счёт чего перехватывают факты передачи данных по сетевым каналам. Такой тип анализа может потенциально привести к конфликту с другими решениями или к проблеме в процессе передачи данных по сети.
Как мы спасаем ситуацию
Иногда возникают конфликты между агентом Staffcop и другими решениями, контролирующими трафик, или между стандартным шифрованием на веб-ресурсе. Чтобы этот конфликт не привёл к блокировке ресурса, мы реализовали настройку исключений ресурсов, где не будет осуществляться анализ данных, передаваемых по сети. Настройка исключений — процесс в основном ручной, но благодаря механизму MITM, он требуется только в редких случаях, когда веб-сервис жёстко требует соответствия сертификатов (например, «Госуслуги») или когда MITM осуществляет другое решение. Если агент не может автоматически проверить возможное наличие конфликтов, у нас реализованы широкие настройки исключений — администратор системы может сам внести все необходимые ресурсы в «белый список». Например, те ресурсы, которые не несут рисков в рамках ИБ-политик (банковские ресурсы, «Госуслуги»).
Элемент второй: сеть
Зачем нужен элемент
Так как система реализована в архитектуре агент-сервер, становится крайне критичным процесс взаимодействия между этими компонентами. Очень важно иметь возможность оперативно реагировать на события безопасности и изменения в правилах работы агента. Сеть здесь выступает инструментом взаимодействия: агент обращается к серверу, передаёт собранные данные, получает по необходимости команды, новые правила. И, как раз, — небольшой объём данных, которые курсируют между агентом и сервером, а также возможность управлять этим потоком — важны для организаций, где канал передачи имеет ограничения или используется несколькими сервисами.
Проблема 1. Нагрузка на сеть
Поскольку сеть общая и её используют не только ИБ-решения, но и любые производственные приложения, важно, чтобы передача данных о действиях пользователя не перегружала сеть.
Как мы спасаем от этого
Объём
Информация о действиях пользователей, так называемых «событиях», на 90% состоит из текстовых файлов. Их объём небольшой — даже передача 1000 событий в день с каждого агента (в среднем не более 200 Мб) не даст большой нагрузки на сеть.
Кроме этого, мы можем регулировать объёмы передачи данных с агента на сервер с помощью трёх параметров:
Количество данных и их регулярность. Администратор может выбрать, передаются данные маленькими пакетами, но часто, или большими, но редко.
Количество данных, поступающих на сервер. Чаще всего Staffcop устанавливают на виртуальном сервере и важно не перегрузить передачей данных все ресурсы сервера, которые критичнее тратить на антивирус и NGFW.
Такая регулировка позволяет настроить работу Staffcop под конкретного клиента — ведь в каждой компании своя сетевая структура (с филиалами и без), свой набор приложений, которые грузят сеть.
Элемент третий: сервер
Зачем нужен элемент
Сервер — это основной инструмент системы. Если агенты — это руки, сервер — всё остальное. Он управляет и взаимодействует с агентами, получает и записывает в себя данные, передаёт новые правила и команды агентам. Собранные данные он анализирует, обрабатывает политиками безопасности, выявляет инциденты, анализирует содержимое\контент. Хранит собранную информацию и предоставляет доступ к ней специалистам по безопасности. И, в итоге, предоставляет специалистам множество инструментов по анализу данных, администрированию и настройкам самой системы.
Проблема 1. Хранение и автоматический анализ данных
В требованиях тех или иных регуляторов и внутренних ИБ-политик прописано, какие данные нужно хранить на серверах и в течение какого времени. Чем больше данных, тем больше это грузит сервер.
Как мы спасаемся
Нагрузка на объёмы памяти, оперативную память и центральный процессор зависит от того, сколько данных хранится на сервере. И для оптимизации процессов важно не само «железо», а эффективное использование этого железа с распределением мощностей, чтобы не было гонки за ресурсы между различными компонентами системы.
Для снижения нагрузки используем удаление и автоочистку. Например, пользователь может удалить ненужные данные не только по периоду, но и автоматически точечно удалять события, которые востребованы для расследования. Такая же ситуация с фильтрацией — можно указать агенту исключить сбор ряда данных, которые не несут ценности.
Кроме этого, наша поддержка имеет высокую квалификацию по работе с базой данных Postgres и, зачастую, может помочь клиенту донастроить её в зависимости от особенностей собираемых клиентом данных. Например, настроить использование кластера и архивирование данных для распределения нагрузки. Также можем дублировать данные в дополнительную базу данных Clickhouse — это требует больше места для хранения, но существенно увеличивает скорость загрузки данных в веб-интерфейсе.
Элемент четвёртый: пользователи и администраторы
Чем важен элемент
Конечный пользователь системы — это специалист службы безопасности, который получает с сервера Staffcop данные о действиях пользователей в виде отчётов и дашбордов. Администратор — это IT-специалист, который обслуживает систему. У него не должно возникать проблемы при настройке Staffcop.
Проблема 1. Отчёты для пользователя без нагрузки на инфраструктуру
Конечный пользователь должен получать уведомления и отчёты от Staffcop своевременно и с минимумом ложноположительных срабатываний. Одно из возможных решений — это ML, которая автоматически интерпретирует большие объёмы данных и выдаёт результаты в виде отчётов. Но ML требует дополнительных ресурсов для обработки данных.
Как мы спасаемся
В основном для расследования инцидентов зачастую требуется анализировать более свежие данные, обращаясь к старым только в случае необходимости. Для этого часть старых данных можно вынести в холодное хранилище, тем самым снизив нагрузку при поиске. К тому же, можно распределить нагрузку между несколькими серверами кластера: запросы будут передаваться каждому по отдельности, поиск по меньшему объёму данных, а вывод в рамках одного отчёта.
Для того, чтобы увеличить скорость отображения данных и загрузки отчётов, используем Clickhouse. Это колоночная СУБД, запросы к которой в связи со структурой хранения информации выполняются быстрее. Данные из Postgres синхронизируются с Clickhouse, в итоге полностью архив данных хранится в Postgres, но быстрый поиск выполняется в Clickhouse.
Проблема 2. Техническое обслуживание системы.
Система должна логировать процесс работы и возможные проблемы. Логи должны хранить все необходимые данные, при этом, не занимать много места. Иначе под них придётся выделять отдельные диски и отдельные каналы передачи информации.
Кроме этого, с этими логами должно быть удобно работать.
Как мы справляемся
Для работы с логами существуют специальные решения, например, Grafana. Мы их рекомендуем и помогаем с настройками. Это позволяет оперативно выявлять аномалии и отклонения в инфраструктуре заказчика как на уровне работы системы, так и на уровне влияния этой системы на инфраструктуру заказчика. Администратор может увидеть, какой объём трафика занят, чем занят, как используются данные. В итоге у нашей технической поддержки есть информация из логов, с которой они могут решить проблемы заказчика. Например, внести изменения в конфигурационных файлах или в продукте. Например, поменяли спуллер, потому что однопоточный перестал справляться с объёмом клиентских данных.
Проблема 3. Управление настройками Staffcop
Администратор должен управлять данными, настраивать их хранение, распространять агенты и следить за их состоянием. Это связано с логированием, но не только. Например, Staffcop контролирует переписку пользователей в мессенджере. Если разработчики того или иного мессенджера поменяют протоколы, то данные будут недоступны для Staffcop. В худшем случае начнётся конфликт, который приведёт к блокировке мессенджера на компьютере сотрудника.
Как мы с этим справляемся
Следим за изменениями в настройках приложений, с которыми взаимодействует Staffcop, и учитываем их в новых версиях нашего решения. Кроме этого, мы уведомляем администраторов о наличии новых версий агентов и рекомендуем обновиться. Уведомления присылаем в продукте, рассылках или напрямую через менеджера, закреплённого за клиентом.
Также мы рассказываем клиентам о том, что ранее выявленные проблемы мы решили.