Контакты
Подписка
МЕНЮ
Контакты
Подписка

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

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

В рубрику "Оборудование и технологии" | К списку рубрик  |  К списку авторов  |  К списку публикаций

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

В 2008 г. Ричард Столлман, известный как основатель движения свободного программного обеспечения, в интервью газете "Гардиан" (The Guardian) заявил, что "одна из причин по которой нам не следует использовать Web-приложения для осуществления собственных вычислений, состоит в том, что мы теряем контроль над ними". Обобщая слова Столлмана, можно утверждать, что использование любого удаленного сервиса ограничивает свободу пользователя.
Иван Чижов
Начальник отдела разработки
средств защиты "Инлайн Технолоджис",
к.ф.-м.н.

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

Все началось с продукта 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. В связи с этим использовать этот протокол повсеместно не всегда представляется возможным.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к информационной безопасности системы
Все требования можно разделить на пять больших групп:
1) к идентификации и аутентификации;
2) к разграничению доступа;
3) к регистрации и учету;
4) к обеспечению целостности;
5) по защите передаваемой и хранимой информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опубликовано: Журнал "Information Security/ Информационная безопасность" #5, 2012
Посещений: 12270

Приобрести этот номер или подписаться
  Автор

Иван Чижов

Иван Чижов

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

Всего статей:  2

В рубрику "Оборудование и технологии" | К списку рубрик  |  К списку авторов  |  К списку публикаций