В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
Устанавливается на выделенный сервер и может представлять собой сервис, работающий по архитектуре RPC (удаленный вызов процедур) на основе протокола обмена сообщениями. Компонент можно разбить на две части:
Сервис должен обрабатывать запросы как обычных пользователей (например, запрос идентификации, получение списка разрешенных приложений), так и администраторов (запросы на добавление/удаление/модификацию аутентификационной информации пользователей, назначение их прав и т.п.).
При выполнении запросов производится обязательная проверка прав пользователя. Инициатором соединения всегда должен являться клиент сервиса аутентификации. После установки соединения общение с сервисом может происходить по схеме "запрос-ответ".
Сервис безопасности выполняет функции по аутентификации пользователей и компонентов системы, по контролю доступа пользователей к серверам и терминальным станциям, а также по контролю межкомпонентного взаимодействия.
Компонент устанавливается на выделенный сервер, например на тот же, что и сервис аутентификации. Консоль администрирования - это, по сути, сервис, который предоставляет аутентификацию. Этот компонент предоставляет интерфейс командной строки для выполнения необходимых действий по администрированию сервиса безопасности.
Для использования консоли администрирования пользователь должен обязательно проходить процедуру аутентификации на ее сервисе.
При выполнении любого запроса проверяется идентификатор сессии пользователя путем обращения к сервису аутентификации.
Консоль администрирования как минимум должна выполнять функции:
Обеспечивает балансировку нагрузки на серверы приложений, а также серверы, на которых устанавливаются компоненты системы защиты, например сервис аутентификации.
Механизм взаимодействия с компонентом следующий:
Очевидно, что балансировка нагрузки также должна быть аутентифицированной.
Компонент обеспечивает передачу ОС на терминал пользователя, при этом должен быть произведен контроль ее целостности.
Также он представляет собой сервис, работающий по архитектуре RPC на основе протокола обмена сообщениями.
Механизм взаимодействия с компонентом должен быть таким же, как и с сервисом балансировки нагрузки, то есть инициатором соединения должен всегда являться терминал и выполнение любого запроса должно предваряться проверкой идентификатора сессии пользователя с использованием сервиса аутентификации.
Он обеспечивает механизмы аутентификации пользователя на терминале, а терминала и пользователя - в системе. По сути, этот компонент должен быть микропрошивкой. Он загружает по сети образ ОС и разворачивает его в оперативную память терминала.
Модуль должен выполнять как минимум следующие функции:
После старта модуль безопасности в нормальном режиме должен выполнять статическую проверку целостности оборудования, после чего устанавливать соединение с сервисом аутентификации. Затем выполняется аутентификация оборудования. Если оборудование не зарегистрировано в системе, сервис аутентификации должен сообщить об этом модулю безопасности и соединение с системой должно обрываться. В случае ее успешного прохождения модуль из сервиса распространения терминальной ОС получает ОС, проверяет ее целостность, распаковывает в оперативную память и передает ей управление.
Для настройки терминала в модуле безопасности предусмотрен режим инициализации и настройки на работу с сервисом безопасности.
Обеспечивает установление RDP-сессии с сервером приложений и удаленный запуск приложений на данном сервере. При этом ОС терминала абсолютно статична, то есть она не подвергается изменениям и модификации, в ней не устанавливаются никакие программы. В силу централизации хранения ОС в едином центре можно облегчить процедуру ее обновления. Администратор подготавливает новую сборку ОС и выкладывает ее в сервис распространения. При следующей загрузке терминал уже будет работать с обновленным образом.
Терминальная ОС должна поддерживать функции многоконтурности.
При ее загрузке, кроме обычных процессов, должен происходить запуск компонента синхронизации окружения пользователя и выполняться его автоматический вход, который ранее аутентифицировался с помощью модуля безопасности.
При запуске синхронизации окружения пользователя должны происходить следующие действия:
ПО сервера приложений должно состоять из компонента аутентификации TCP-сессий и средства разграничения доступа. Кроме того, для повышения СБ предлагается следующее решение: если пользователь не запускает никаких приложений, его учетная запись отсутствует в ОС Windows. Таким образом, если злоумышленнику удастся получить доступ к серверу приложений, то войти в ОС под реальным пользователем, в обход сервиса аутентификации, ему не удастся, так как учетной записи пользователя просто не будет существовать в ОС. За реализацию такой функции должен отвечать специальный провайдер аутентификации. Он является заменой существующего провайдера аутентификации Windows, расширяя его функциональность и позволяя аутентифицироваться в системе по данным, хранящимся на удаленном сервере; корректно поддерживать протокол RDP, обеспечивая удаленный вход в систему в случае успешной аутентификации; выполнять функции стандартного провайдера аутентификации.
Пользователь, устанавливая RDP-сессию, может аутентифицироваться по локальной и удаленной БД. В случае успешной аутентификации создается локальный пользователь с соответствующими правами в системе и происходит автоматический вход.
Компонент аутентификации TCP-сессий представляет собой пакет драйверов для аутентификации произвольного ТСР-соединения. Все соединения должны быть аутентифицированы.
Средства разграничения доступа к ресурсам сервера приложений должны быть построены в соответствии с идеологией запрета доступа ко всем ресурсам, кроме исполняемых файлов. В этом случае задача сводится к назначению для пользователя набора приложений, необходимых для решения функциональных задач. В рамках запущенного приложения он должен иметь право доступа ко всем ресурсам сервера приложений, к которым оно обращается.
Особая роль СРД при работе в режиме терминального доступа - изоляция приложений различных пользователей, работающих на одном сервере. Один из подходов, который может быть реализован для этого, - создание "песочницы" для каждого приложения. Оно видит только ресурсы, отведенные системой именно ему, и не видит целиком все ресурсы сервера приложений.
Это своего рода драйверы-фильтры для обеспечения шифрования IP-пакетов в соответствии с выбранным протоколом. Все шифрование производится с помощью сертифицированных средств криптографической защиты на основе алгоритма ГОСТ 28147-89.
Для повышения безопасности системы можно использовать аппаратно-программные модули доверенной загрузки.
Для загрузки сервера приложений администратор аутентифицируется в сервисе проверки подлинности. После этого производится аутентификация сервера приложений. Если она завершилась неудачей, то сервер выдает ошибку и просит пройти процедуру повторно. Если он зарегистрирован для работы в ферме серверов, за которую отвечает сервис аутентификации, модуль проверяет целостность ОС и иных файлов, заданных администратором в списке контроля, инициирует загрузку сервера приложений. После загрузки сервер приложений готов принимать терминальные сессии пользователей.
После всего вышеперечисленного могут начинать работу пользователи.
Зарегистрированный в системе пользователь включает терминал. Терминал производит процедуру аутентификации с помощью модуля безопасности, и в случае неудачи терминал сообщает пользователю о том, что данное устройство не имеет права работать в системе, и отключается. После успешного завершения аутентификации терминала появляется окно запроса логина и пароля с приглашением пройти проверку подлинности, при этом возможно использовать двухфакторную аутентификацию. Пользователь, если требуется, подключает АНП и вводит логин и пароль - аутентификация пользователя в системе. В случае успешной аутентификации на терминал загружается образ ОС терминала. Проверяется ее целостность, и если она не нарушена, то ОС распаковывается в оперативной памяти терминала и загружается. Далее терминал, взаимодействуя с сервисом аутентификации, получает список доступных для связки "терминал - пользователь" приложений (предварительно установленные и опубликованные на серверах приложений). Кроме того, пользователю присваивается специальный электронный билет, который дает право работы на сервере приложений. Ему может выделяться пул серверов приложений, на которых он может работать. После загрузки ОС запускается приложение типа "рабочий стол", в котором располагаются ссылки на опубликованные для пользователя в системе приложения. Терминал готов к работе и пользователь может запускать разрешенные приложения.
При запуске приложений происходит обращение терминальной ОС к сервису балансировки нагрузки со специально выданным электронным билетом. При получении запроса балансировщик нагрузки выбирает наименее загруженный сервер приложений из списка доступных пользователю. Сервер приложений проверяет валидность электронного билета и либо отказывает, либо выполняет действия, необходимые для установления терминальной сессии. Взаимодействие терминала с сервером приложений осуществляется по протоколу RDP. При этом в процессе работы пользователю передается только картинка с сервера приложений, а не реальные данные. Приложение выполняется на сервере под контролем СРД, изолирующей процессы каждого пользователя от процессов других. От пользователя к серверу приложений передаются координаты мыши, факт нажатия кнопки мыши и факт нажатия клавиш клавиатуры.
Данная архитектура, безусловно, не является неоспоримой истиной. Однако, на взгляд автора, позволяет комплексно и эффективно решить проблему безопасности любой системы, построенной на основе терминального доступа, а не только обеспечить шифрование RDP-трафика.
Опубликовано: Журнал "Information Security/ Информационная безопасность" #6, 2012