Клиент и сервер: как найти компромисс?
Требования к корпоративному решению по безопасности
Пример: система защиты от утечек информации
Подавляющее большинство корпоративных информационных систем использует клиент-серверную архитектуру. Это означает, что система обладает единой серверной частью, к которой подключаются небольшие программы-клиенты, установленные на каждом пользовательском компьютере. Функциональность системы распределяется между клиентской и серверной частями по-разному, и каждый разработчик должен самостоятельно решить, какое разделение будет применяться в его системе.
По мнению экспертов компании Perimetrix, несмотря на кажущуюся малозначительность, распределение функциональности является одним из ключевых параметров системы. Например, если перегрузить клиента слишком сложными задачами, то производительность системы неизбежно упадет. К тому же обширная функциональность клиента существенно усложняет работу с ним, а это автоматически означает рост расходов на обучение и загрузку службы технической поддержки. Отличным примером, показывающим критическую важность простоты клиентской части, являются последние разработки Microsoft, в частности огромные инвестиции корпорации в разработку новых интерфейсов для Windows Vista и Office 2007.
Обратная крайность — максимальный перенос функциональности на серверную часть — тоже приводит к не самым хорошим последствиям. Ярким примером этого является популярный IM-клиент ICQ и его серверная версия ICQ2Go, которой крайне трудно пользоваться. Локальный клиент обязан выполнять какие-то функции самостоятельно — в противном случае катастрофически падает удобство работы с ним.
В данной статье будет рассмотрен вопрос о распределении клиентских и серверных функций в системах, отвечающих за информационную безопасность (ИБ). В целом этот сегмент ИТ-рынка не выделяется из общей канвы данного вопроса, хотя и имеет некоторые особенности. О них мы и поговорим в первую очередь.
Чем специфична безопасность
Чем отличается система безопасности от любой другой информационной системы? Ответ очевиден: безопасность не несет в себе никаких полезных функций и выполняет лишь сервисную роль. В идеале система безопасности должна быть абсолютно незаметной для пользователя, но, тем не менее, максимально эффективной. В этом свете упомянутая ранее система Windows Vista вместе с функциональностью UAC (User Account Control) выглядит по меньшей мере странно, хотя она и не является решением по информационной безопасности.
Напомним, что функция UAC в системе Windows Vista постоянно выдает различные оповещения и просит пользователя подтвердить потенциально опасные действия. Концептуальная проблема Vista связана с тем, что подавляющее большинство этих оповещений не говорит ни о какой угрозе, а просто нервирует пользователя. Качественная система безопасности не должна вести себя подобным образом. Ее задача — обеспечить защиту компьютера и информации, которая на нем хранится, не снижая производительность труда пользователя.
На деле таких систем, конечно же, не существует. Реальная безопасность всегда является компромиссом между защитой и удобством работы. Чем выше защита, тем ниже удобство и наоборот.
Это означает, что производителям абсолютно необходимо не только распределить функциональность между клиентской и серверной частями, но и найти компромисс между удобством и безопасностью. Например, даже самый качественный антивирус, который ловит все вредоносное ПО, окажется бесполезным, если будет предъявлять слишком высокие требования к системе. К сожалению, далеко не все вендоры понимают это простое утверждение и на рынке постоянно появляются продукты, с которыми просто невозможно работать.
Таким образом, пользовательская часть любого корпоративного решения по безопасности должна быть максимально незаметной. В некоторых продуктах клиентская часть вовсе отсутствует, поскольку попросту не нужна. Однако объективная реальность такова, что большинство современных систем нуждаются хотя бы в самых простых агентских приложениях, поскольку контролировать рабочие станции удаленно можно далеко не всегда. Не стоит забывать и о мобильных компьютерах, которые периодически оказываются за пределами корпоративной информационной среды.
Требования к корпоративному решению по безопасности
Во-первых, из последнего абзаца следует очевидное требование к корпоративной системе безопасности, включающей клиентские модули. Такое решение должно поддерживать централизованное управление пулом этих модулей, в том числе их централизованную установку и удаление. В противном случае задача распространения клиентских программ в корпоративной сети становится просто нерешаемой.
Во-вторых, в рамках управления клиентскими программами необходимо контролировать их состояние. Выше мы уже отмечали, что агенты должны работать незаметно для пользователя, но даже если это не получается — они все равно должны работать. В противном случае становится неясно, с какой целью внедряется система в принципе. Контроль агентских приложений должен осуществляться в реальном времени хотя бы для тех компьютеров, которые расположены внутри периметра корпоративной сети. В том случае, если пользователь каким-то образом закрывает агент (или сам агент допускает ошибку), офицер безопасности должен получить уведомление.
Наконец, третьим требованием к управлению пулом клиентских приложений является централизованная система аудита и протоколирования всех действий с клиентами — некий архив, в который попадают все события, происходящие с каждым установленным агентом. Как правило, такая система решает две основные задачи: во-первых, предоставляет инструментарий для расследования возникающих инцидентов, а во-вторых, обеспечивает функциональность для создания аналитических отчетов и мониторинга общих проблем безопасности.
«В реальной жизни далеко не все решения по безопасности имеют подобную систему аудита, — отмечает менеджер проектов по информационной безопасности компании «УСП КомпьюЛинк» Александр Юрков. — Ее отсутствие является серьезным недостатком отдельно взятого продукта. Мне кажется, что система протоколирования событий предоставляет организации не только прямую, но и косвенную выгоду. Дело в том, что ряд важнейших нормативных документов требует проводить аудит целостности информации и контролировать движение приватных документов».
Вопрос о распределении функциональности между клиентской и серверной частями должен рассматриваться отдельно для каждой конкретной системы. В целом можно выделить три основных подхода к реализации функционального распределения, которые представлены в таблице.
Обозначенные подходы в определенной степени идеализированы — на практике не существует решений, которые принадлежат только к одному из обозначенных классов. Как правило, первая часть функций системы безопасности дублируется, вторая часть используется только в рамках локального клиента, а третья — предоставляется исключительно на сервере. В зависимости от соотношения этих частей каждый продукт приближается к одному из подходов и имеет соответствующие преимущества и недостатки.
Пример: система защиты от утечек информации
Сегмент решений для защиты от утечек информации является отличным примером, показывающим распределение функциональности между клиентской и серверной частями систем ИБ. Данный сегмент интересен прежде всего тем, что в нем присутствуют решения, в которых реализован каждый из трех подходов.
Основная задача защиты от утечек состоит в контроле исходящих данных на предмет наличия конфиденциальной информации. Очевидно, что наиболее простым способом контроля является банальный запрет этого трафика. В случае интернет-трафика такой подход абсолютно неприменим, однако для контроля локального трафика он используется довольно часто.
Как правило, запрет локального трафика реализуется посредством установки небольших агентских приложений, которые блокируют физические порты, а также беспроводные интерфейсы компьютера. Несмотря на то что функциональность этих агентов весьма ограниченна, в данном случае используется идеология «толстого» клиента. Серверная часть системы защиты выполняет только сервисные функции по управлению пулом агентов и сбору поступающей от них информации.
Рассматривая системы физической блокировки доступа, можно увидеть практически все концептуальные недостатки, свойственные подходу с «толстыми» клиентами. Основная проблема подобных систем заключается в их недостаточной гибкости, поскольку локальные агенты позволяют реализовать лишь «грубую» функциональность жесткой блокировки портов. А блокировка портов, в свою очередь, означает серьезные ограничения на работу пользователей.
Вторым серьезным недостатком «толстого» подхода являются проблемы с контролем агентских приложений и их постоянным функционированием. В большинстве случаев серверу чрезвычайно трудно проконтролировать статус работы клиентов. А поскольку клиент максимально заметен для пользователя, велика вероятность его принудительного выключения.
Прямо противоположный подход применяют системы защиты от утечек, основанные на контентной фильтрации. Такие решения используют интеллектуальные алгоритмы для анализа трафика и на выходе выдают вердикт, является ли этот трафик конфиденциальным. Сильной стороной подобных систем является контроль трафика на уровне шлюза, который происходит на специальном сервере.
Но даже если алгоритмы анализа трафика не допускают ошибок (на деле это почти невозможно), то системы контентной фильтрации испытывают значительные трудности с контролем локального трафика. Во-первых, реализовать анализ копируемых, например, через USB-порт файлов через удаленный сервер контентной фильтрации технически очень сложно, а во-вторых, непонятно, что делать в том случае, если доступ к серверу фильтрации отсутствует.
Как следствие, организации, внедряющие системы контентной фильтрации, попросту закрывают локальный трафик другими решениями (о них мы говорили ранее). В результате достигается приемлемый уровень защиты (в случае качественной фильтрации, конечно), который сопровождается двумя концептуальными проблемами:
локальный трафик, как правило, приходится закрывать. В результате снижается производительность труда служащих;
система защиты от утечек фактически состоит из двух разрозненных компонентов, которые по-разному управляются и настраиваются. Теоретически возможно соединение функций фильтрации глобального и блокировки локального трафика в одно интегрированное решение, однако авторам статьи о подобных продуктах пока неизвестно.
Впрочем, сегодня на рынке имеются альтернативные системы, которые применяют комбинированный подход, обеспечивающий функциональную нагрузку как для клиентских, так и для серверных приложений. Подобные решения используют элегантную технологию, предполагающую установку специальных меток на все конфиденциальные документы.
С помощью меток достигается максимальная точность фильтрации, поскольку системе не требуется анализировать контент на предмет наличия в нем секретных сведений. Вдобавок появляется возможность переложить функции фильтрации на локальных клиентов, поскольку задача проверки инкапсулированной метки значительно проще задачи контентной фильтрации.
Но каким образом можно правильно расставить метки на все конфиденциальные документы? Именно здесь начинает «играть» серверная составляющая решения, которая централизованно расставляет метки в соответствии с заданными правилами. В дальнейшем метки начинают самостоятельно «размножаться», передаваясь из старых документов в только что созданные файлы.
«Даже несмотря на технологии расстановки и размножения меток, в организации все равно останутся непомеченные документы, — комментирует менеджер проектов по информационной безопасности компании «УСП КомпьюЛинк» Александр Юрков. — Именно поэтому в качественных комплексных решениях по защите от утечек должны применяться и методы контентной фильтрации. Таким образом, документ будет проверен на конфиденциальность в любом случае, даже при отсутствии инкапсулированной метки».
Система Perimetrix SafeSpace, в которой планируется реализовать данную функциональность, принадлежит к классу DLP-решений третьего поколения. По мнению отраслевых экспертов, данный продукт обладает одной из наиболее совершенных архитектур среди представленных на рынке решений. На наш взгляд, одной из основных причин успеха Perimetrix является грамотное распределение функциональности между клиентской и серверной частями продукта.
 |
|
