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

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

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

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

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

Представляем вашему вниманию продолжение статьи Ивана Чижова, опубликованной в 5-м номере журнала "Информационная безопасность". В первой части говорилось о возникновении самой идеи терминального доступа, ее развитии и трансформации в современную модель; ИБ системы и различные требования к ее реализации и архитектура системы защиты терминального доступа. Во второй части статьи более подробно рассмотрим компоненты, которые должны быть в системе.
Иван Чижов
начальник отдела разработки
средств защиты "Инлайн Технолоджис",
к.ф.-м.н.

Сервис аутентификации

Устанавливается на выделенный сервер и может представлять собой сервис, работающий по архитектуре RPC (удаленный вызов процедур) на основе протокола обмена сообщениями. Компонент можно разбить на две части:

  • обработчик входящих соединений;
  • БД для хранения аутентификационных данных и драйвер работы с ней.

Сервис должен обрабатывать запросы как обычных пользователей (например, запрос идентификации, получение списка разрешенных приложений), так и администраторов (запросы на добавление/удаление/модификацию аутентификационной информации пользователей, назначение их прав и т.п.).

При выполнении запросов производится обязательная проверка прав пользователя. Инициатором соединения всегда должен являться клиент сервиса аутентификации. После установки соединения общение с сервисом может происходить по схеме "запрос-ответ".

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

Консоль администрирования

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

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

Для использования консоли администрирования пользователь должен обязательно проходить процедуру аутентификации на ее сервисе.

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

Консоль администрирования как минимум должна выполнять функции:

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

Сервис балансировки нагрузки

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

Механизм взаимодействия с компонентом следующий:

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

Очевидно, что балансировка нагрузки также должна быть аутентифицированной.

Сервис распространения терминальной ОС

Для настройки терминала в модуле безопасности предусмотрен режим инициализации и настройки на работу с сервисом безопасности.

Компонент обеспечивает передачу ОС на терминал пользователя, при этом должен быть произведен контроль ее целостности.

Также он представляет собой сервис, работающий по архитектуре RPC на основе протокола обмена сообщениями.

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

Модуль безопасности

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

Модуль должен выполнять как минимум следующие функции:

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

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

Для настройки терминала в модуле безопасности предусмотрен режим инициализации и настройки на работу с сервисом безопасности.

Терминальная ОС

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

Терминальная ОС должна поддерживать функции многоконтурности.

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

При запуске синхронизации окружения пользователя должны происходить следующие действия:

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

Сервер приложений

ПО сервера приложений должно состоять из компонента аутентификации TCP-сессий и средства разграничения доступа. Кроме того, для повышения СБ предлагается следующее решение: если пользователь не запускает никаких приложений, его учетная запись отсутствует в ОС Windows. Таким образом, если злоумышленнику удастся получить доступ к серверу приложений, то войти в ОС под реальным пользователем, в обход сервиса  аутентификации, ему не удастся, так как учетной записи пользователя просто не будет существовать в ОС. За реализацию такой функции должен отвечать специальный провайдер аутентификации. Он является заменой существующего провайдера аутентификации Windows, расширяя его функциональность и позволяя аутентифицироваться в системе по данным, хранящимся на удаленном сервере; корректно поддерживать протокол RDP, обеспечивая удаленный вход в систему в случае успешной аутентификации; выполнять функции стандартного провайдера аутентификации.


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

Компонент аутентификации TCP-сессий представляет собой пакет драйверов для аутентификации произвольного ТСР-соединения. Все соединения должны быть аутентифицированы.

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

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

Драйверы шифрования IР-трафика

Это своего рода драйверы-фильтры для обеспечения шифрования IP-пакетов в соответствии с выбранным протоколом. Все шифрование производится с помощью сертифицированных средств криптографической защиты на основе алгоритма ГОСТ 28147-89.

Для повышения безопасности системы можно использовать аппаратно-программные модули доверенной загрузки.

Возможный типовой алгоритм работы защищенной клиент-серверной архитектуры

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

После всего вышеперечисленного могут начинать работу пользователи.

Возможный типовой алгоритм работы пользователя в системе

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

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

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

Достоинства описанной архитектуры

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

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

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

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

Иван Чижов

Иван Чижов

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

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

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