1Информационный поиск и систематизация научно-технических источников по теме проекта
С целью создания информационной базы для проведения анализа средств и методов построения виртуальных сетей с разграничением доступа и управления информационным обменом на основе распределенной модели данных, выбора и обоснования направления исследований, был выполнен информационный поиск научно-технических источников по теме проекта. Научно-технические источники были систематизированы по следующим направлениям исследования, представленным в таблице 1.1. Результаты информационного поиска и систематизации научно-технических источников представлены в форме упорядоченного, в соответствии с направлениями исследований, списка источников в конце отчета. Диапазоны чисел в столбце «Номера источников» соответствуют номерам источников в списке.
Таблица 1.1 – Систематизированный перечень научно-технических источников по теме проекта
№ п/п
|
Направление исследований
|
Номера источников
| | |
Технологии и методы аутентификации.
|
1-16
| | |
Технологии и методы авторизации и модели управления доступом.
|
17-29
| | |
Технологии и методы построения виртуальных сетей.
|
30-36
| | |
Технологии и методы построения распределенных баз данных.
|
37-44
| | |
Взаимодействие массивов данных. Хранилища данных.
|
45-55
| | |
Подходы к интеграции разнородных систем.
|
56-80
| | |
Средства и технологии разработки программного обеспечения автоматизированных систем.
|
81-92
| | |
Принципы исследования, построения, организации функционирования сложных систем и автоматизации управления ими.
|
93-100
| 2Проведение анализа средств и методов построения виртуальных сетей с разграничением доступа и управления информационным обменом на основе распределенной модели хранения данных 2.1Аутентификация
Аутентификация – это процедура, позволяющая одной сущности проверить объявленные свойства другой. Процедура взаимодействия между общающимися пользователями называется протоколом.
Аутентификацию можно разделить на три вида:
аутентификация источника данных;
аутентификация сущности;
генерация аутентифицированных ключей.
2.1.1Аутентификация источника данных
Аутентификация источника данных (также называемая аутентификацией сообщения) тесно связана с защитой целостности данных.
Однако, аутентификация источника данных и защита целостности данных представляют собой совершенно разные понятия. Их различают по нескольким аспектам.
1 Аутентификация источника данных обязательно связана с каналами связи. Она представляет собой службу безопасности получателя, предназначенную для верификации источников запросов. Защита целостности данных не обязательно связана с коммуникациями: она может распространяться на данные, хранящиеся в компьютере.
2 Аутентификация источника данных обязательно связана с его идентификацией, а защита целостности данных – нет.
3 Аутентификации источника запроса обязательно связана с проверкой его «свежести» (freshness), а защита целостности данных – нет: фрагмент устаревшей информации может превосходно соответствовать критериям целостности данных. Для того чтобы аутентифицировать источник данных, получатель сообщения должен удостовериться, что сообщение было послано недавно. Только в этом случае сообщение может считаться "свежим". "Свежесть" информации свидетельствует о хорошей согласованности между общающимися сторонами и снижает вероятность диверсии со стороны пользователей, аппаратуры, системы или самого сообщения [2].
Аутентификация источника данных и защита целостности данных в некоторых ситуациях различаются наличием анонимных мандатов (например, невидимой подписи (blind signature)). Пользователь может выдать анонимный мандат, позволяющий его владельцу воспользоваться услугами системы, доступными только для ее членов. Заметим, что целостность данных в таком случае также гарантируется, однако система не может идентифицировать пользователя.
Итак, аутентификация источника данных предусматривает следующие действия:
1 Передача сообщения от отправителя к получателю, проверяющему достоверность сообщения перед его принятием;
2 Идентификация отправителя сообщения;
3 Проверка целостности данных, полученных от отправителя;
4 Проверка реальности отправителя сообщения.
2.1.2Аутентификация сущности
Аутентификация сущности – это процесс обмена информацией (т.е. протокол), в ходе которого пользователь устанавливает подлинность (lively correspondence) другого пользователя [9].
Как правило, в ходе протокола аутентификации выясняется подлинность сообщения. В таких ситуациях, чтобы убедиться в подлинности сообщения и его автора, следует воспользоваться механизмом аутентификации источника данных. Действительно, если в протоколе проверяется подлинность сообщения, достоверность его автора лучше всего проверять именно с помощью механизма аутентификации источника данных.
Существует несколько сценариев аутентификации сущности в распределенных системах. Перечислим некоторые из них [6].
Обмен сообщениями между двумя узлами сети (host-host type). Участниками протокола являются узлы или платформы распределенной системы. Их работа, как правило, должна быть согласованной. Например, если одна из удаленных платформ "перезагружается", она должна идентифицировать достоверный сервер и передать ему необходимую информацию, например, достоверную копию операционной системы, достоверные установки таймера или достоверные установки окружения. Определение достоверности информации обычно выполняется с помощью протокола аутентификации.
Обмен сообщениями между пользователем и узлом сети (user-host type). Пользователь получает доступ к компьютерной системе, регистрируясь в главном компьютере. При этом запускается протокол аутентификации пароля. В приложениях, в которых скомпрометированный узел может привести к большим потерям, необходима взаимная аутентификация (mutual authentication).
Обмен сообщениями между процессом и узлом сети (process-host type). В настоящее время развитие методов распределенных вычислений предоставило пользователям широкие функциональные возможности. Узел может предоставлять внешним процессам широкие права.
Члены клуба (member-club type). Доказательство членства в клубе представляет собой мандат, в отличие от способа, основанного на обмене сообщениями между пользователем и узлом. В этом случае клуб интересует только мандат его члена, а не информация о нем. В частности, клуб не интересуется подлинностью личности члена клуба, имеющего мандат. Данный сценарий реализуется в протоколах идентификации с нулевым разглашением (zero-knowledge identification protocol) и схемах неоспоримой цифровой подписи (undeniable signature schemes).
2.1.3Генерация аутентифицированных ключей
Стороны, обменивающиеся информацией, запускают протокол аутентификации сущности для того, чтобы в дальнейшем перевести общение на более высокий уровень. В современной криптографии в основе организации защищенных каналов связи лежат криптографические ключи. Следовательно, протоколы аутентификации сущностей для дальнейшего обмена информацией по защищенным каналам в качестве составной части должны содержать механизм генерации аутентифицированных ключей (authenticated key establishment), или обмена ключами (key exchange), или согласования ключей (key agreement) [11].
Протоколы аутентификации сущностей могут предусматривать аутентификацию источника данных. Аналогично, в протоколах генерации аутентифицированных ключей протокольные запросы содержат параметры ключей, источник которых также подлежит аутентификации.
В литературе [9] протоколы аутентификации (сущностей), протоколы генерации аутентифицированных ключей (обмена ключами, согласования ключей), протоколы для защиты данных и даже криптографические протоколы часто называют протоколами связи (communication protocols).
2.1.4Основные методы аутентификации
Перечислим основные методы аутентификации, рассматриваемые ниже.
1 Стандартные механизмы определения "свежести" сообщения и существования пользователя.
2 Взаимная аутентификация и односторонняя аутентификация.
3 Аутентификация с привлечением доверенного посредника.
2.1.4.1"Свежесть" сообщения и существование пользователя
Проверка "свежести" сообщения – неотъемлемая часть аутентификации источника данных, а также аутентификации сущностей, в процессе которой пользователь должен интенсивно обмениваться информацией с подлинным партнером. Следовательно, механизмы, позволяющие установить "свежесть" сообщения или существование пользователя, относятся к основным компонентам протокола аутентификации.
Опишем стандартные механизмы, позволяющие решить поставленную задачу. В наших описаниях узел А будет заявлять о некотором свойстве (например, своем существовании или "свежести" сообщения), а узел В будет проверять, соответствует ли это действительности. Будем считать, что узел А и узел В владеют общим ключом КАВ, если механизм аутентификации использует симметричные криптографические методы, или узлу В известен открытый ключ узла А, распространяемый через систему сертификации открытых ключей, если в основе механизма аутентификации лежат методы асимметричной криптографии.
В стратегии "оклик-отзыв" (challenge-response mechanism) Узел В (верификатор) получает смесь, состоящую из протокольного сообщения и криптографической операции, выполненной Узлом А (претендентом) таким образом, чтобы Узел В мог убедиться в ее существовании, проверив "свежесть" полученной информации. Как правило, Узел В получает одноразовое случайное число NB, заблаговременно сгенерированное им и посланное Узлу А. Первое сообщение, посланное Узлом В Узлу А, называется окликом (challenge), а второе сообщение, посланное Узлом А Узлу В называется отзывом (response). Узел В является инициатором (initiator), а Узел А – ответчиком (responder).
Описанная выше стратегия использует метод симметричной криптографии, а именно, симметричное шифрование. Следовательно, получив ответ от Узла А Узел В должен расшифровать порцию шифрованного текста, используя совместный ключ КАВ. Если расшифровка правильно восстанавливает случайное число NB, то Узел В имеет основания считать, что Узел А действительно зашифровал его после получения оклика. Если интервал между окликом и отзывом достаточно мал, сообщение М считается "свежим". Эта стратегия основана на уверенности пользователя в том, что Узел А выполняет шифрование после получения оклика от Узла В. Поскольку случайное число, посланное Узлом В, было извлечено из достаточно большого пространства, нет никакой возможности предсказать его заранее.
На первый взгляд может показаться, что применение симметричного шифрования гарантирует секретность сообщения. На самом деле секретность сообщения обеспечивает целостность данных. Если алгоритм шифрования, используемый в стратегии аутентификации, не гарантирует целостности данных, то Узел В не может проверить "свежесть" сообщения М.
Действительно правильной и стандартной стратегией, гарантирующей целостность данных при использовании симметричных методов шифрования, является применение кода распознавания манипуляций (MDC). Следовательно, шифрование следует сопровождать кодом MDC, зашифрованным с помощью общего ключа и являющимся частью зашифрованного текста. Это обеспечивает защиту целостности сообщения [4].
Международная организация по стандартизации (International Organization for Standardization – ISO) и Международная электротехническая комиссия (International Electrotechnical Commission – IEC) приняли три стратегии в качестве стандартных конструкций стратегии односторонней аутентификации сущности (unilateral entity authentication).
1 Двухпроходный односторонний протокол аутентификации (ISO Two-pass Unilateral Authentication Protocol).
2 Однопроходный односторонний протокол аутентификации с симметричным ключом (ISO Symmetric Key One-Pass Unilateral Authentication Protocol).
3 Однопроходный односторонний протокол аутентификации с использованием криптографической текстовой функции (CCF) (ISO One-Pass Unilateral Authentication with Cryptographic Check Function).
2.1.4.2Взаимная аутентификация
До сих пор механизмы проверки "свежести" сообщения и существования пользователя обеспечивали только так называемую "одностороннюю аутентификацию", в которой аутентифицировался только один из двух участников протокола. При взаимной аутентификации (mutual authentication) пользователи аутентифицируют друг друга.
Международный институт по стандартизации и Международная электротехническая комиссия стандартизировали большое количество протоколов взаимной аутентификации. Протокол 11.1 описывает стратегию, основанную на применении цифровой подписи: "Трехпроходный протокол взаимной аутентификации с открытым ключом ISO" ("ISO Public Key Three-Pass Mutual Authentication Protocol").
2.1.4.3Аутентификация с привлечением доверенного посредника
В основных конструкциях протоколов аутентификации, описанных выше, говорилось, что между участниками протокола установлен защищенный канал (созданный с помощью методов симметричной криптографии) или они знают открытый ключ партнера (если используются методы асимметричной криптографии). Итак, можно утверждать, что эти протоколы применяются пользователями, уже знакомыми друг с другом.
В стандартном режиме функционирования открытых систем пользователи взаимодействуют, а затем "забывают" друг друга. Открытые системы слишком велики, чтобы пользователь мог хранить информацию о своих контактах с другими пользователями. Если два пользователя, незнакомых друг с другом, захотят установить между собой секретную связь, они могут организовать защищенный канал связи. В современной криптографии такой канал связи защищается криптографическим ключом. Следовательно, два пользователя, желающих установить защищенный канал связи между собой, должны запустить протокол аутентификации, который называется протоколом генерации аутентифицированного ключа. Завершив сеанс секретной связи, они разрушают канал. Термин "разрушение канала" означает, что пользователи забывают ключ защищавший канал, и никогда больше не используют его. Вот почему канал, используемый для генерации аутентифицированного ключа, часто называется сеансовым каналом, а ключ, защищавший его, называют сеансовым ключом.
Как правило, для аутентификации и генерации ключей в открытых системах используется централизованная служба аутентификации, известная под названием доверенный посредник (trusted third party - TP). Такая служба может быть интерактивной (online) или автономной (offline) [9].
Если аутентификация осуществляется интерактивным доверенным посредником, считается, что между ним и большим количеством пользователей в системе существуют долговременные отношения. Протоколы аутентификации и генерации аутентифицированных ключей в интерактивных системах с использованием доверенного посредника разрабатываются на основе основных конструкций, описанных выше, в которых одним из "знакомых" пользователей является сам доверенный посредник. Криптографические операции, выполняемые доверенным посредником, могут зависеть от криптографических операций, выполняемых пользователями. С помощью доверенного посредника можно установить защищенный канал даже между пользователями, не знакомыми друг с другом. [11]
Стандартные протоколы аутентификации (серия 9798), одобренные организациями ISO/IEC, содержат две стандартные конструкции, в которых участвует интерактивный доверенный посредник. Одна из таких стратегий называется "Четырехпроходным протоколом аутентификации ISO" (ISO Four-Pass Authentification Protocol), а другая – "Пятипроходным протоколом аутентификации ISO" ("ISO Five-Pass Authentication Protocol"). Эти протоколы обеспечивают взаимную аутентификацию пользователей и генерацию аутентичных сеансовых ключей.
Эти протоколы построены на основе стандартных протокольных конструкций, описанных выше. Они уже представляют собой полноценные протоколы аутентификации и не должны использоваться в качестве строительных конструкций для создания протоколов аутентификации более высокого уровня. Интерпретатор
2.1.5Модели передачи аутентификационной информации
Выделяют несколько базовых моделей взаимодействия [9]:
браузер – web-сервер;
клиентский интерпретируемый программный код – web-сервер;
браузер – серверный интерпретируемый программный код;
клиентский интерпретируемый программный код – серверный интерпретируемый программный код.
Первый тип модели объединяет направления, описывающие взаимодействия сервера и клиента с целью аутентификации и авторизации, при которых обработка аутентификацинных запросов и ответов производится непосредственно браузером, содержащим технологию взаимодействия с сервером на основе определенного протокола. При этом не требуется дополнительных надстроек над этими протоколами.
Основными ветвлениями направлений обеспечения аутентификации является критерий "сохранение межзапросной аутентификационной информации".
К первому типу относятся архитектуры, не способные хранить результат аутентификации. Следовательно, при их использовании необходимо обеспечивать хранение сессионных данных внешними по отношению к данным протоколам механизмами. Примерами подобных протоколов могут быть EAP / CHAP / PAP.
Ко второму типу относятся архитектуры, предусматривающие механизм хранения результата однажды прошедшей аутентификации. Примером подобного подхода может служить протокол Kerberos [16].
При использовании других трех моделей передачи аутентификационной информации способ аутентификации и авторизации остается на усмотрении интерпретируемого алгоритма, работающего на стороне клиента и/или сервера. Эти функции более не являются задачами браузера или web-сервера. Методы сокрытия пароля и шифрования организуются на прикладном уровне. Возможные разрабатываемые на основе этих моделей протоколы на уровне приложения имеют характер надстройки над протоколом HTTP.
2.1.6Подходы к проверке аутентификационной информации
Подход, описываемый протоколом RADIUS, обеспечивает обмен учетными сведениями (accounting) между серверами доступа NAS и серверами учета (Accounting Server).
Сервер доступа (NAS) выступает в качестве клиента служб RADIUS accounting. Клиент отвечает за передачу учетных сведений серверам RADIUS.
Серверы RADIUS отвечают за прием учетных запросов и возврат клиенту информации, подтверждающей получение запроса. Сервер RADIUS может выступать в качестве клиента-посредника (proxy client) других серверов RADIUS.
Аутентификация транзакций между клиентом и сервером RADIUS accounting осуществляется с использованием разделяемого ключа (shared secret), который никогда не передается через сеть.
Когда клиент настроен на использование RADIUS на начальном этапе предоставления услуг этот клиент будет генерировать пакет Accounting Start, описывающий тип предоставляемого пользователю сервиса, который передается серверу RADIUS с подтверждением от него приема такого пакета. При завершении пользовательского сеанса клиент будет генерировать пакет Accounting Stop, описывающий тип предоставленного пользователю сервиса. Этот пакет может также включать статистические сведения о работе пользователя – продолжительность сеанса, число пакетов и байтов, принятых и переданных пользователем. Пакет передается серверу RADIUS Accounting, который будет возвращать подтверждение приема. [16]
Пакет Accounting-Request (Start или Stop) передается серверу RADIUS через сеть. Клиенту рекомендуется повторять передачу пакета Accounting-Request до тех пор, пока от сервера не будет получено подтверждение приема. Если в течение заданного времени подтверждение не будет получено, передача пакета повторяется заданное число раз. Клиент может также переслать запрос дополнительным серверам в тех случаях, когда основной сервер не работает или недоступен. Обращаться к альтернативному серверу после заданного числа неудачных попыток связи с основным сервером или в режиме перебора по кругу.
Сервер RADIUS может делать запросы к другим серверам для выполнения, полученного от клиента, запроса. В таких случаях сервер сам выступает в роли клиента.
TACACS (Terminal Access Controller Access Control System) прошел через три поколения: TACACS, Extended TACACS (XTACACS) и TACACS+. TACACS объединяет процессы аутентификации и авторизации, XTACACS разделяет процессы аутентификации, авторизации и аудита, а TACACS+ – это XTACACS с расширенной двухфакторной аутентификацией пользователей. TACACS использует постоянные пароли для аутентификации, а TACACS+ позволяет использовать динамические (одноразовые) пароли, обеспечивая более высокий уровень безопасности.
TACACS+ реализует в основном ту же функциональность, что и RADIUS с некоторыми отличиями. Во-первых, TACACS+ использует в качестве транспорта протокол TCP вместо протокола UDP в RADIUS, и поэтому ему не требуется дополнительный код для обнаружения и исправления ошибок передачи сетевых пакетов. Во-вторых, TACACS+ шифрует всю информацию (включая имя пользователя, данные учета и авторизации), а RADIUS шифрует только пароль пользователя, позволяя злоумышленнику перехватить важную информацию. В-третьих, TACACS+ использует настоящую архитектуру ААА, обеспечивая дополнительную гибкость при настройке процесса аутентификации удаленных пользователей, тогда как RADIUS объединяет функциональность аутентификации и авторизации.
Альтернативным решением является подход DIAMETER – сеансовый протокол, созданный, отчасти, для преодоления некоторых ограничений протокола RADIUS. Обеспечивает взаимодействие между клиентами в целях аутентификации, авторизации и учёта различных сервисов (AAA, англ. authentication, authorization, accounting). Он является основным протоколом архитектуры IMS. В основе протокола DIAMETER лежит концепция в создании базового протокола с возможностью его расширения для предоставления сервисов AAA при появлении новых технологий доступа.
В среде Microsoft Windows поддерживается альтернативный подход к проверке аутентификационной информации IAS (Information Access Service), который является аналогом протокола RADIUS, но функционирует только в среде Windows.
Также существуют несколько подходов к обеспечению взаимодействия между хранилищами аутентификационной информации:
доверительные отношения;
федеративные отношения;
синхронизирующие модели.
|
