Третье дыхание терминального доступа, или Организация защиты в системах терминального доступаЧасть 1

Иван Чижов
Начальник отдела разработки
средств защиты "Инлайн Технолоджис",
к.ф.-м.н.

История терминального доступа

Все началось с продукта WinFrame, молодой на тот момент компании Citrix. Эта программа была не чем иным, как ОС Windows NT 3.51 с поддержкой многопользовательского режима. Чуть позже, в 1998 г., на базе WinFrame компанией Microsoft была разработана первая ОС Windows NT 4.0 Terminal Server Edition, которая позволяла пользователям вести удаленную работу. То есть программы выполнялись на некоем сервере, а пользователю на рабочую станцию транслировалась только картинка. В основу удаленной работы пользователей был положен протокол RDP 4.0, получивший в дальнейшем широкое распространение. Это привело к тому, что хакеры стали уделять особое внимание поиску уязвимостей в нем, которых на поверку оказалось немало. В определенный момент администраторы стали отказываться от применения этого протокола, опасаясь взлома серверов. И только возможность использовать для его защиты протокол TLS подарила RDP вторую жизнь.

Протокол RDP

Текущая версия протокола RDP имеет номер 7.1. В ней исправлены многие ошибки, недостатки и уязвимости младших версий. Среди основных ее особенностей можно отметить:

• возможность публикации приложений для пользователя;
• поддержку аутентификации сетевого уровня;
• увеличение производительности;
• снижение длительности задержки при воспроизведении аудио и видео.

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

Следует отметить, что наряду с RDP развивались и другие протоколы терминального доступа. Одним из старейших и достаточно популярных протоколов является протокол ICA, который лежит в основе линейки продуктов компании Citrix. Основной его недостаток - он является собственностью компании Citrix, поэтому провести независимое исследование протокола на наличие в нем уязвимостей и недокументированных возможностей практически невозможно. А проведение таких исследований необходимо, например, в том случае, если система обрабатывает ПДн класса К1. В связи с этим использовать этот протокол повсеместно не всегда представляется возможным.

С точки зрения ИБ технология терминального доступа имеет ряд привлекательных особенностей:

• терминалы, или тонкие клиенты, с которых можно получать доступ к ресурсам системы, не имеют жесткого диска;
• используют специализированную ОС, одна из задач которой - организовать сессию с терминальным сервером для работы пользователя;
• не имеют в своем составе подвижных деталей;
• исполняются в специализированных корпусах с полностью пассивным охлаждением.

А значит, пользователь, работая за терминалом, не может ничего записать, так как у него нет жесткого диска. Используемую ОС можно урезать до единственной функции - установления RDP-сессии, что позволяет существенно ограничить действия на рабочей станции. Подключение к терминалу внешних накопителей не позволит пользователю записать на них информацию, поскольку в ОС отсутствует функциональность по монтированию подобных устройств на сервер приложений. Монолитность терминала усложняет доступ пользователя к его внутренностям. ОС и ПО, которые использует терминал, практически не требуют обновления, поэтому их можно зафиксировать, сертифицировать и забыть, не тратя деньги на сертификацию новых версий и обновлений. Покупая такое ПО, можно быть уверенным, что в течение длительного времени не потребуется изменений и обновлений. Кроме того, указанная монолитность и некоторая "статичность" терминала позволяют не использовать для защиты терминальных станций антивирусное ПО.

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

Возьмем два сервера приложений и установим на один интернет-браузер все программы, которые необходимы для работы пользователей в сети Интернет, а на другой - установим программы обработки конфиденциальной информации. Вместо рабочих станций установим пользователям терминалы (тонкие клиенты). И предположим, что в качестве ОС на терминале используется Linux с поддержкой двух рабочих столов. И они полностью изолированы друг от друга, а обмен информацией между ними невозможен. Установим на первом рабочем столе RDP-сессию к первому серверу приложений, а на втором - ко второму. Таким образом, за одним и тем же терминалом на одном рабочем столе пользователь сидит в Интернете, а на другом - обрабатывает конфиденциальную информацию. Владелец системы спит спокойно, не переживая о возможной утечке конфиденциальных данных.

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

Типовая архитектура системы защиты терминального доступа

Принято считать, что для реализации защищенного терминального доступа, основанного на использовании протокола RDP, необходимо:

• использовать протокол SSLTTLS для защиты данных;
• включить аутентификацию пользователей, например через домен по логину и паролю.

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

Рассмотрим типовую архитектуру защиты системы, построенной на основе технологии терминального доступа (рис. 1).

Предположим, что имеется ферма терминальных серверов приложений и множество клиентских устройств (терминалов), которые взаимодействуют по протоколу RDP и предоставляют возможность использования приложений, необходимых пользователям. Как сделать так, чтобы описанная система стала защищенной?

Требование к разграничению доступа

В системе обязательно должен быть реализован механизм разграничения доступа к ресурсам. Он должен основываться на заданиях правил доступа на основе групповых характеристик пользователей, запускаемых ими программ и объектов. Как правило, рассматриваются следующие права доступа: чтение, запись, удаление и выполнение.

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

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

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

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

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

Необходимо также запретить пользователю загружать собственную ОС на терминале.

Требования к регистрации и учету

Обычно системе регистрации и учета подвергаются:

• подключение пользователей к системе;
• запуск приложений;
• доступ к контролируемым объектам доступа;
• создание защищаемых объектов доступа;
• изменение полномочий субъектов доступа.

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

Требования к обеспечению целостности

1. По обеспечению целостности программных средств защиты.
2. По неизменности программной среды.

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

Архитектура системы защиты

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

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

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

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