Алгоритм единой аутентификации в кластерных системах архитектуры «тонкий клиент»

© Кирилл Аверченко, Андрей Ларчиков, Сергей Панасенко, 2011.

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

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

Кластеризация и балансировка нагрузки

Кластеризация – устоявшаяся технология масштабирования компьютерных систем, применяющаяся для решения разного рода задач. Под кластером понимается группа отдельных серверов, работу которых координирует специальное программное обеспечение таким образом, что все подключенные к ней клиенты считают, что имеют дело с единственным компьютером [2].
Таким образом, кластер повышает показатели отказоустойчивости информационных систем, а также дает возможность в любой момент времени отключить один или несколько компонентов для проведения технического обслуживания серверов или обновления программного обеспечения, входящего в кластер.
Балансировка нагрузки позволяет повысить быстродействие системы, состоящей из объединенных в кластерную группу компьютеров. Например, кластер с работающим диспетчером сетевой нагрузки (Microsoft Load Balancing) выступает для клиентов как один сервер. При этом все входящие запросы равномерно распределяются между узлами кластера. Кроме распределения нагрузки, балансировка позволяет постепенно масштабировать мощности информационной системы, вводя в кластер новые серверы. При этом не обязательно использование однотипных компьютеров для узлов кластера.
Применительно к архитектуре тонкого клиента можно выделить следующие явные преимущества балансировки нагрузки:

1. Балансировка нагрузки позволяет добиться бесперебойной работы серверных модулей архитектуры независимо от аппаратных или программных сбоев.
2. Обеспечивается возможность увеличения мощности серверных модулей по мере роста нагрузки (т. е. масштабирование системы). Для увеличения количества обрабатываемых запросов достаточно добавить в кластер еще один сервер.
3. На любых приложениях и серверах, добавленных в кластер, можно проводить чередующиеся обновления. Процесс обновления отдельных компонентов кластера практически незаметен для пользователя.

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

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

Рассмотрим принципы балансировки нагрузки на терминальные серверы Citrix, наиболее часто используемые в качестве серверов приложений архитектуры тонкого клиента.
Для балансировки нагрузки серверов приложений все серверы Citrix включаются в ферму серверов Citrix Metaframe Farm [3].
После опубликования приложений на всех серверах, входящих в ферму, процесс подключения терминального клиента выглядит следующим образом:

1. Клиент запускает ICA-файл (файл с параметрами запуска) интересующего приложения.
2. ICA-клиент отправляет широковещательный запрос, в котором присутствует имя запускаемого приложения.
3. Между серверами, входящими в ферму Citrix и имеющими опубликованное приложение, проводятся выборы наиболее свободного сервера, который будет осуществлять запуск приложения.
4. Сервер, выигравший выборы, соединяется с клиентом и сообщает ему свой адрес.
5. Далее клиент аутентифицируется на этом сервере.
6. В случае успешной аутентификации сервер выполняет запуск приложения.

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

Использование двухфакторной аутентификации клиента

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

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

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

Алгоритм аутентификации и формирования общего ключа

Для аутентификации пользователей и формирования общего ключа для дальнейшего обмена сообщениями может быть использован алгоритм взаимной аутентификации (первичная аутентификация) на основе модифицированного алгоритма Нидхема-Шрёдера [4]. Работа алгоритма основывается на том, что системное время между клиентом и сервером синхронизировано. Аутентификация и выработка ключа происходят по следующей схеме:

1. Клиент отправляет на сервер номер идентифицирующего носителя (ID) и зашифрованные алгоритмом шифрования E на ключе сервера key данные, содержащие текущую метку времени T1 и случайно сгенерированное число N1.

2. Сервер расшифровывает полученные данные и проверяет, чтобы расхождение времени сервера и метки времени было в пределах заданных настроек. Затем сервер проверяет, что в базе данных присутствует пользователь с идентификатором ID, тем самым идентифицируя его. После этого сервер генерирует случайный сессионный ключ Ksession и случайное число N2, после чего инкрементирует полученное число N1 и вместе с текущей меткой времени отправляет клиенту, предварительно зашифровав на ключе клиента. Ключ клиента (Kclient) является производным от идентификационного номера и пароля пользователя.

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

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

На этом процесс аутентификации и выработки сессионного ключа завершен.

Запуск приложения при использовании единой аутентификации

Рассмотрим процесс запуска приложения на сервере приложений (СП) при использовании совмещенной технологии тонкого клиента и единой аутентификации. Предполагаем, что, помимо серверов приложений, серверные модули архитектуры тонкого клиента включают и один или несколько серверов управления (СУ), каждый из которых отвечает за первичную аутентификацию пользователя (рис. 1). Принципы работы сервера управления подробно описаны в цикле статей [5].
Данный процесс включает следующие основные этапы:

1. Получение разрешения на сервере управления на запуск приложения.
2. Получения ICA-файла для запуска приложения с СП.
3. Непосредственный запуск приложения.

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

Литература:

1. Материалы свободной энциклопедии «Википедия». // http://ru.wikipedia.org.
2. Возможности масштабируемости и кластеризации. Материалы сайта http://www.microsoft.com.
3. Материалы сайта http://support.citrix.com.
4. Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си. – Пер. с англ.: М.: Издательство ТРИУМФ, 2002 – 816 с.
5. Панасенко С. Принципы разработки серверных модулей распределенных систем защиты информации. Части 1-4. // Вопросы защиты информации. – 2009 – № 2 – с. 30-44, 2010 – № 2 – с. 43-62.

Рисунки:

1. Архитектура тонкого клиента с кластеризацией серверов.

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