Журнал "Information Security/ Информационная безопасность" #3, 2021

Продуманный и удобный интерфейс может быть кос- венным признаком того, что разработчик в состоянии обеспечить квалитативную разработку, а функциональ- ные компоненты системы качественны и эффективны. Если же консолей несколько, например имеют- ся специальные консоли для управления отдельными модулями, это говорит о том, что продукт не про- ектировался и не разраба- тывался как единая, логиче- ски законченная система. Если для "пилота" на 50–100 клиентов нужно более одного сервера, это означает, что архитектура системы не оптимальна и, скорее всего, будет требо- вать повышенных ресурсов и на этапе промышленной эксплуатации. Для серьезной DLP- системы характерна под- держка множества вариан- тов внедрения. иной DLP-системы. Например, если endpoint-агент передает информацию для анализа на DLP-сервер по протоколу SMTP, то можно предположить, что про- дукт начинался с модуля конт- роля электронной почты. При этом сервер может возвращать результат анализа на агент, а может и не возвращать. В последнем случае функция блокировки по содержимому при записи на USB-диск или при печати вообще отсутствует. Понятно, что при такой архитек- туре требуется постоянное соединение с сервером, а загруз- ка сети может быть слабым местом. В тендерной докумен- тации иногда можно встретить вопрос, поддерживает ли DLP- система приоритизацию сетевого трафика (QoS, Quality of Service). Это, скорее всего, означает, что рассматривалась только одна такая система, поскольку при грамотном проектировании кон- тентный анализ выполняется там же, где применяются политики. Необходимость в передаче боль- ших объемов информации по сети просто отсутствует, и вопрос приоритизации сетевого трафика неактуален. Как работает агент системы, когда нет соединения с корпоративной сетью Этот вопрос является логи- ческим продолжением преды- дущего. Но проблема не только в том, чтобы оптимизировать использование сетевого трафи- ка. Агент, кроме выполнения контентного анализа и приме- нения политик, должен переда- вать информацию о событиях, а также теневые копии и другие данные на сервер для записи в архив. Если связь с архивом отсутствует, то вся эта инфор- мация не должна теряться. Как правило, она сохраняется на локальном диске и передается на сервер в момент, когда соединение установлено. В идеале политики должны применяться на агенте в зави- симости от того, есть ли непо- средственное подключение к локальной сети, или компьютер подключен через VPN, или под- ключение отсутствует. Таким образом, для каждой среды можно устанавливать соответ- ствующие правила. Это бывает важно, когда сотрудник с рабо- чим компьютером находится вне офиса, например в коман- дировке или на удаленке. Удобно ли управлять системой Удобство управления – это весьма субъективный критерий. Кому-то привычнее управлять системой с помощью командной строки, а кому-то удобно соз- давать политики и правила, про- граммируя на скриптовом языке. Тем не менее продуман- ный и удобный интерфейс может быть косвенным призна- ком того, что разработчик в состоянии обеспечить квалита- тивную разработку, а функцио- нальные компоненты системы качественны и эффективны. В плане удобства и прорабо- танности интерфейса важно отметить два аспекта. Во-первых, единая консоль управления. Сейчас чаще всего предпочтение отдается веб-кон- солям. Они платформонезави- симы, не требуют установки дополнительного ПО, могут рабо- тать на мобильных устройствах. Если же консолей несколько, например имеются специальные консоли для управления отдель- ными модулями, это говорит о том, что продукт не проектиро- вался и не разрабатывался как единая, логически законченная система. Возможно, модули дописывались разными коман- дами и "прилеплялись" (каждый со своей консолью) друг к другу в ходе ускоренного эволюцион- ного развития. Может, они вообще собраны "с миру по нитке" – лицензированы у разных производителей и интегрирова- ны не так, как следовало бы, а так, как получилось. Во-вторых, зрелая DLP-систе- ма должна иметь омниканальные политики. Это означает, что если требуется создать политику для контроля, например, тендерной документации, то достаточно сде- лать это один раз и просто ука- зать, к каким каналам она будет применяться (электронная почта, веб, USB-устройства и т.д.). Менее совершенная система потребует создавать однотипные политики для каждого канала отдельно. Это может показаться небольшой проблемой, но коли- чество политик имеет тенденцию к росту. Когда оно переваливает за сотню, а в правилах исполь- зуются сложные условия, где присутствуют не только контент- ные правила, а еще и группы пользователей, дни недели и т.д., поддержание такого набора в синхронизированном состоянии может превратиться в серьезную головную боль. Какое минимальное количество серверов нужно для внедрения Еще одним явным признаком дефектной архитектуры, види- мым уже на "пилоте", может стать количество серверов, необходи- мых для работы системы. Если для "пилота" на 50–100 клиентов нужно более одного сервера, это означает, что архитектура системы не оптимальна и, ско- рее всего, будет требовать повышенных ресурсов и на этапе промышленной эксплуа- тации. Качественная система уровня enterprise одинаково хорошо масштабируется в обе стороны. Безусловно, при уве- личении масштаба внедрения потребуется возможность раз- несения отдельных компонентов системы на разные серверы и их кластеризация. Но на малых внедрениях DLP-система не должна требовать неоправданно больших ресурсов. Легко ли развернуть систему? Набор вариантов внедрения Для серьезной DLP-системы характерна поддержка множества вариантов внедрения. Это, во- первых, упрощает задачу совме- щения DLP-системы с существую- щей ИТ-инфраструктурой, а во- вторых, позволяет гибко балан- сировать функциональную и вычислительную нагрузку при контроле различных каналов. Сегодня на рынке есть ряд систем, предусматривающих контроль всех каналов на уровне только endpoint-агента. Это сильно упро- щает задачу вендору, позволяет сэкономить на команде разра- ботчиков и сократить сроки раз- работки и выпуска новых версий. Однако такая архитектура не может считаться уровнем enter- prise. Большинство сетевых кана- лов более естественно контроли- ровать на уровне шлюза, особен- но для масштабных внедрений. Зрелая DLP-система кроме агента для конечных точек пред- лагает следующие варианты шлюзового внедрения: l интеграция с почтовыми сер- верами (например, Microsoft Exchange), в этом случае можно удобно контролировать и внут- реннюю почту; l прием почты из технического почтового ящика; l интеграция с имеющимся интернет-шлюзом по протоколу ICAP; l собственный почтовый транс- портный сервер. • 17 DLP www.itsec.ru