Привет, Хабр!

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

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

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

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

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

Итого перед специалистами по ИБ была поставлена задача – найти решение, которое позволит не только ограничить объем передаваемых во внешнюю сеть данных, но и анализировать «на лету» содержимое этих данных, передаваемых с корпоративных ПК в интернет через опубликованный в терминальной сессии браузер. В таком решении нам было необходимо создать некий набор правил, который бы не позволял пользователям копировать со своих рабочих станций в терминальный браузер ничего, кроме ссылок (URL) – этот вид данных действительно необходим для удобства работы пользователей, так чтобы им не приходилось набирать руками адреса сайтов. При этом для снижения риска от попыток перекинуть конфиденциальные данные под видом ссылок, их размер должен быть ограничен неким минимальным объемом, достаточным для переноса ссылок, но не более того - например, пара-тройка килобайт. Также необходимо разрешить передавать только отрезки текста, вставляемые в буфер обмена, но не целые файлы различных форматов. При таком подходе пользователи смогут переходить по URL-ссылкам, предварительно скопированным с рабочей станции и вставленным в адресную строку «терминального» браузера, но не смогут отправлять внутрь браузера объемную произвольную информацию другого характера и другого формата (файлы, рисунки, схемы и т.д.), что позволяет вполне комфортно «ходить в интернет» и защищает банк от утечки конфиденциальных данных.

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

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

На деле же найти решение, которое бы позволило полноценно решить эту задачу, оказалось сложно. Было потрачено несколько месяцев на тестирование разных продуктов. Практически во всех задача комплексно не решалась, одно из требований не выполнялось в полном объеме (!). Предлагался либо жесткий «рубильник» для доступа к буферу обмена для всех сразу и всего контента без должного анализа, либо (и это в лучшем случае) анализ постфактум, т. е. предполагалось, что пользователь никак не будет ограничен в передаче данных по «защищаемому» каналу, а потом уже по журналам придется разбираться — кто, куда и какую информацию передавал. Очевидно, что от утечки это не убережет, в лучшем случае позволит выявить нарушителя. Такой подход специалистов банка не устраивал.

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

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

И вот уже на протяжении 7 лет этот программный продукт, который теперь известен на российском рынке под другим именем – Кибер Протего, используется в этом банке, и планов переходить на что-то другое в обозримом будущем нет.

Как все это устроено?

Для организации интернет-киоска создана и функционирует ферма терминальных серверов на базе Citrix XenApp с общим числом пользователей, превышающим 10 000. На серверах разворачивается VDI-рабочая среда с использованием «золотого образа» windows-машины, в котором установлен агент Кибер Протего с настроенной политикой контроля терминального буфера обмена в направлении «на выход» (здесь «на выход» - с точки зрения пользователя, а для терминального сервера это будет «на вход»), и набор браузеров для выхода пользователей в интернет. Каждый сервер одновременно обслуживает 50-70 пользовательских сессий, XenApp предоставляет пользователю именно браузер, а не всю виртуальную windows-машину. Сервер назначается пользователям в случайном порядке из наименее загруженных.

 Теперь – о том, каким образом в Кибер Протего настраивается политика с необходимыми требованиями.

Для начала идем в раздел настроек Кибер Протего, отвечающий за контроль доступа, где выделена отдельная группа каналов передачи данных «ТС-Устройства». В нее входят:

• контроль чтения/записи на подключенный диск – это может быть как флешка, так и любая папка на локальном диске, перенаправленная с удаленного ПК/тонкого клиента в терминальной сессии на терминальном сервере;

• контроль доступа к последовательному порту (Serial, он же COM);

• контроль доступа к USB порту;

• избирательный контроль входящего и исходящего буфера обмена в зависимости от содержимого:

  • текст;

  • изображения;

  • аудио данные;

  • файлы;

  • неизвестные данные (т.е. все те, формат которых не относится к вышеперечисленным).

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

В базовом сценарии требуется оставить разрешенным только Буфер обмена исходящий текст, для того чтобы пользователи могли копировать текст из терминального браузера на свои рабочие станции. Там, где разрешения не проставлены – доступов не будет по умолчанию. В терминах продукта это означает предоставить указанным пользователям право «Разрешено» для этого канала.

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

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

Идем дальше, к разделу «Контентные правила». Здесь немного посложнее, двумя кликами не обойтись. 

Начнем с того, что в Кибер Протего можно создавать контентные правила на базе контентных групп, так мы называем базовые варианты анализа содержимого:

• по типу файлов (определение типа файла основывается на сигнатурном методе, что исключает методы обхода изменением расширения файла);

• по ключевым словам;

• по регулярным выражениям (RegExp);

• свойствам документа (размеру, владельцу, расширению, метки классификации и т.д. параметры);

• цифровые отпечатки.

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

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

Для рассматриваемой задачи все это богатство оказалось во многом невостребованным – для выявления в тексте URL-ов, ограниченных размером, понадобилось создать всего ОДНО составное правило, основанное на объединении двух контентных групп через оператор «И»:

«шаблон URL-адреса» И «объем буфера данных меньше задаваемого порога»,

и затем применить это правило к каналу ТС-устройства - Буфер обмена входящий текст. Ставим также галочку на чекбоксе «Разрешения», чтобы указать, что работать правило должно именно для задачи разрешения или запрета доступа, а в правах указанного пользователя или группы отмечаем также «Разрешено» - то есть правило должно работать именно как разрешающее, а не запрещающее. Это означает также, что данные, не соответствующие такому разрешающему правилу, не будут валидированы – то есть попросту не пройдут контентный фильтр.

Соответственно, все входящие в буфер обмена данные, не подпадающие под это правило, должны блокироваться, а всё что подпадает под правило – должно пропускаться.

Это правило работает в запущенной в дело системе практически без изменений и нареканий с момента запуска Кибер Протего в эксплуатацию. Почему «практически»? Об этом чуть ниже.

Важный момент! Решение, а точнее его агентская часть, ставится ТОЛЬКО на терминальном сервере (в «золотом образе»), на пользовательские компьютеры ничего дополнительно ставить не надо. Это значит, что сотрудники могут выходить в интернет через данный киоск с компьютеров с любыми операционными системами. С установкой серверной части тоже никаких сложностей в целом нет. В процессе внедрения в банке привлекать интеграторов не потребовалось, хватило наших подсказок и рекомендаций, а все настройки задавали сами специалисты банка.

Еще один ключевой момент – пользователям предоставляется не какой-то один-единственный браузер, а выбор из Chrome, Firefox и IE (Edge). Для Кибер Протего разницы нет, контроль одинаков для всех.

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

Наш заказчик также отметил в своем рассказе удачную архитектуру продукта: «Три звена и каждое может работать автономно какое-то время без потери контроля. Можно апдейтить СУБД – данные и функции контроля не пропадут. Можно выполнять какие-либо работы на сервере управления – тот же эффект».

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

Внимательный хабровчанин наверняка заметил, что на скрине одно из составляющих контентного правила называется “URL_no_cyrillic.” Еще в начале эксплуатации выяснилось, что регулярное выражение для определения URL-ов в тексте, которое предоставляется «из коробки», прекрасно пропускает кириллицу. Разумеется, это было недопустимо по вполне понятным соображениям. В принципе администратор Кибер Протего и сам может разобраться в коде Regexp’а, но есть же техподдержка? Результат в виде модифицированного шаблона был быстро передан в банк, добавлен в список. Вуаля. 

Далее было обнаружено, что этот же regexp считает равнозначными разные виды ссылок – и http, и ftp, и другие варианты URL -ов. Еще раз к разработчикам, снова быстрое решение.

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

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

Вторая проблема, относительно недавняя (почти год для больших систем – это недавно), была обнаружена в августе 2023 г. и была связана с обновлением Windows. После этого обновления, достаточно редко, в произвольный момент времени контроль терминального буфера для новой сессии пропадал полностью. На решение проблемы у наших разработчиков ушло чуть менее месяца – и только после подтверждения от заказчика, что проблема ушла, мы опубликовали фикс в новой версии продукта. Конечно, любому заказчику не всегда приятно быть первыми, кто «ловит» проблемы, но полагаем, что скорость их решения более чем достойная, что в данном случае (впрочем, как обычно) подтверждает и заказчик.

Со времени реализации контроля «терминального браузера» в банке перешли к использованию DLP Кибер Протего не только для описанной в этой статье задачи, решаемых задач стало больше. В том числе – со специфическими, именно под запросы банка, доработками в продукте. При этом других качественных решений для задачи полноценного контроля терминальных сессий и Citrix, в частности, на российском рынке за прошедшие годы так и не появилось. С гордостью отметим, что не так давно еще один банк из ведущей тройки внедрил у себя практически такой же подход, тоже на больших фермах с Citrix, и тоже на основе Кибер Протего.

И в завершение немного о будущем, о насущной для всех теме импортозамещения, которое в данном случае означает переход с Windows на Linux. 

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

Подробнее о возможностях Кибер Протего рассказывали здесь. Также недавно мы проводили вебинар, посвященный выходу Кибер Протего 10.2 и Кибер Файлов 9.0. На мероприятии не только рассказывали о новинках, но и показывали множество сценариев совместного использования продуктов. Запись доступна здесь.