Система и способ предоставления доступа к защищенным услугам с однократным вводом пароля
Настоящее изобретение относится в широком смысле к аутентификации, авторизации и контролю доступа, а более конкретно - к способу и системе для аутентификации на базе инфраструктуры открытых ключей PKI, позволяющей пользователям с помощью единственного электронного идентификатора (ИД) получить защищенный доступ ко всем видам сервисов и услуг. Техническим результатом является расширение функциональных возможностей системы и способа благодаря обеспечению аутентификации на базе PKI. За счет предложения услуг по валидации, а также и авторизации другим сервис-провайдерам система способна обеспечить инфраструктуру для универсальной аутентификации на базе PKI, принимающей электронные идентификаторы от любого провайдера подобных ИД. 3 н. и 10 з.п. ф-лы, 5 ил.
Область техники, к которой относится изобретение
Настоящее изобретение относится в широком смысле к аутентификации, авторизации и контролю доступа, а более конкретно - к способу и системе для аутентификации на базе инфраструктуры открытых ключей (PKI - Public Key Infrastructure). Система и способ по изобретению позволяют пользователям с помощью единственного электронного идентификатора (ИД) получить защищенный доступ ко всем видам сервисов (услуг).
Уровень техники
Аутентификация, авторизация и контроль доступа представляют собой три области, которые являются существенными для большинства провайдеров (коммуникационных) сервисов. Исключениями являются только полностью открытые сервисы и анонимные сервисы с отдельной оплатой за реальное использование. В типичной ситуации идентифицируемые пользователи получают право на пользование конкретным сервисом. Пользователь получает доступ к подобным сервисам в случае успешной аутентификации, при условии выполнения процедуры контроля доступа.
Современные решения задачи аутентификации (идентификации подлинности пользователя), ориентированные на Интернет сервис-провайдеров (ISPs, Internet Service Providers) или других провайдеров коммуникационных сервисов, основанных на Интернет-протоколе, базируются, в основном, на именах пользователей и паролях. Протокол RADIUS (Remote Authentication Dial-In User Service) подобно протоколам типа TACACS+ (Terminal Access Controller Access Control System) обеспечивает доступ к сервисам, которые предусматривают централизованное администрирование и валидацию (подтверждение соответствия) как аутентифицирующей информации, так и авторизации, которая приписана аутентифицированным именам пользователей. Группа инженеров Internet (IETF - Internet Engineering Task Force) силами своей рабочей группы Diameter продолжает работу по разработке следующего поколения подобных протоколов.
Обычно пользователь должен иметь отдельный пароль для каждого сервиса. По мере увеличения количества предлагаемых сервисов аутентификация, основанная на применении паролей, становится все более сложной, особенно в связи с тем, что каждый сервис обычно требует использования для аутентификации отдельного пароля. Чтобы справиться с этой сложностью, пользователи обычно выбирают пароли, которые легко запомнить, и многократно используют один и тот же пароль (и одно и тоже имя пользователя).
В связи с тем, что через Интернет предлагается все больше сервисов, обладающих дополнительными возможностями, весьма желательно снабдить пользователей средствами идентификации пользователя на основе инфраструктуры PKI, способными устранить сложности и слабости аутентификации на базе паролей, защитить пользователей от кражи сервисов и упростить процедуру использования ввода login (учетного имени) за счет использования единственного электронного идентификатора (ИД) для всех сервисов. Для того чтобы защитить пользователей и сервис-провайдеров от подделок, потребуется также эффективная процедура идентификации.
Уровень техники, достигнутый в сфере PKI, еще не имеет требуемого уровня общности. Наоборот, пользователи часто сталкиваются с использованием различных решений на базе PKI (взамен применения различных имен пользователей и паролей) для получения доступа к различным сервисам. Кроме того, не так много сервисов в настоящее время доступны через PKI, хотя подобная возможность может потенциально присутствовать применительно ко многим сервисам в форме процедур аутентификации клиента типа протоколов SSL/TLS (Secure Socket Layer/Transport Layer Security). Описываемая далее система развивает уровень техники путем разработки единой аутентификации на базе PKI. Предлагая услуги по валидации, а также, возможно, и авторизации другим сервис-провайдерам, система способна обеспечить создание инфраструктуры для широкой аутентификации на базе PKI.
Раскрытие изобретения
Таким образом, в данном описании будет представлено усовершенствованное решение задачи аутентификации, авторизации и контроля доступа, основанное на использовании сертификатов и PKI-технологии совместно с механизмами, делающими доступными платные сервисы, предлагаемые через компьютерные сети. Главные преимущества предлагаемого решения на базе PKI - это общность, возможность постепенного развития и расширенная функциональность (управление ключом шифрования, цифровая подпись). В будущем пользователь должен иметь единственный носитель ключа (например, смарт-карту), содержащий личные (секретные) ключи и сертификаты, которые формируют электронный ИД пользователя. Электронный ИД пользователя обычно состоит из двух или трех различных пар личный ключ/сертификат, служащих для различных применений. Большинство решений используют две таких пары, одну для шифрования (рассчитанного на применение только этого конкретного личного ключа), а вторую - для всех остальных применений. При этом часто рекомендуется возложить функцию цифровой подписи на отдельную, третью пару; однако эта рекомендация не нашла широкой поддержки в различных продуктах и сервисах.
Пользователь должен иметь свободу выбора организации, выпускающей электронные ИД (т.е. издателя, или провайдера сертификатов). Сервисы, доступ к которым пользователь хочет получить, не должны предписывать использование только конкретных издателей сертификатов. При этом пользователь должен иметь свободу получения любого желаемого количества электронных ИД.
В настоящее время провайдеры, которые используют аутентификацию пользователей, основанную на PKI, в типичном случае способны принимать сертификаты только от одного или нескольких издателей сертификатов. Поскольку сервисы по выдаче сертификатов отличаются друг от друга, сервис-провайдеры должны, по возможности, обеспечивать совместимость своих услуг по отдельности со всеми издателями сертификатов. Такой подход слишком быстро становится неприемлемо сложным, в частности, при необходимости принимать сертификаты от нескольких различных издателей.
В то же время в мире уже существует несколько сотен издателей открытых сертификатов, причем ожидается, что это количество будет возрастать. Кроме того, сервис-провайдер может быть заинтересован в приеме сертификатов от различных внутренних служб фирмы, выпускающих сертификаты (такой подход является обычным в рамках интрасетей).
Описываемая далее архитектура переносит сложность интеграции в отношении множества издателей сертификатов на отдельные специализированные компоненты, что устраняет сложности, связанные непосредственно с сервисами. Пользователь должен зарегистрировать электронный ИД (электронные ИД), т.е. сертификат(ы), которым(и) пользователь предполагает воспользоваться. Имя, указанное в сертификате, а также другие характеристики, такие как уровень качества, увязываются с сервисным профилем пользователя. Сервисный профиль хранится в единственном месте. Некоторые сервисы для предоставления доступа могут затребовать высококачественный электронный ИД.
Имя, указанное в сертификате, не обязательно должно быть истинным именем пользователя. В зависимости от принятых правил, оно может быть и псевдонимом, ролевым именем, названием организации, именем подписчика и т.д.
Используя электронный ИД, пользователь может зарегистрироваться в сети и получить доступ ко всем сервисам, на которые он подписан. Описанная система может работать с единственным паролем в отношении сервисов, которые подготовлены к такому варианту доступа. Что касается сервисов, которые требуют отдельной аутентификации, достоинство описанной системы состоит в том, что по отношению к ним можно повторно использовать электронный ИД пользователя вместо того, чтобы поддерживать отдельный пароль для каждого сервиса. Пользователь должен будет провести аутентификацию несколько раз, но при этом каждый раз он применяет один и тот же метод. Данный вариант исходит из доступности соответствующей службы (сервиса) валидации и, в определенной степени, службы (сервиса) авторизации.
Гибкость данной системы обеспечивает также пользователям свободный выбор операционной системы. Программное обеспечение для работы с электронными ИД часто зависит от используемой базовой платформы. В предлагаемом открытом решении на базе PKI пользователь может выбрать такой электронный ИД, который может поддерживаться выбранной им операционной системой.
Фирмы, выпускающие или использующие кредитные карты, начинают требовать аутентификации пользователя через Интернет, причем аутентификация пароля принимается только на короткое время. Введение общего PKI позволит таким фирмам принимать электронный ИД, который уже имеется у пользователя (при условии, что он отвечает предъявляемым квалификационным требованиям), и тем самым устранить необходимость выпуска отдельного электронного ИД для использования при осуществлении платежей.
Описываемая далее система обеспечит средства для защищенной аутентификации, авторизации и контроля доступа применительно к платным сервисам, таким как Video on Demand (VOD - "Видео по запросу"), а также средства для осуществления защищенных платежей.
Таким образом, изобретение относится в широком смысле к аутентификации, авторизации и контролю доступа, а более конкретно - к способу и системе для аутентификации на базе инфраструктуры открытых ключей (PKI - Public Key Infrastructure), позволяющей пользователям с помощью единственного электронного идентификатора (ИД) получить защищенный доступ ко всем видам сервисов (услуг). Система по изобретению развивает уровень техники путем разработки единой аутентификации на базе PKI. Благодаря тому что система предлагает услуги по валидации и, возможно, аутентификации другим сервис-провайдерам, она позволяет создать инфраструктуру для универсальной аутентификации на базе PKI.
Иными словами, изобретение относится к системе, охарактеризованной в независимом п.1 формулы изобретения. Изобретение относится также к применению, охарактеризованному в независимом п.11. Далее, изобретение относится к способу, охарактеризованному в независимом п.13 формулы изобретения. Рекомендуемые варианты изобретения представлены в зависимых пунктах формулы.
Краткое описание чертежей
Далее изобретение будет описано со ссылками на прилагаемые чертежи.
На фиг.1 представлен общий вид архитектуры для осуществления аутентификации и авторизации.
Фиг.2 иллюстрирует альтернативный способ проверки достоверности сертификата пользователя.
На фиг.3 представлена блок-схема процесса аутентификации, проверки авторизации и доступа к сервису.
Фиг.4 иллюстрирует доступ к платному сервису.
Фиг.5 дает общее представление о службе валидации.
Осуществление изобретения
На фиг.1 представлена архитектура системы по настоящему изобретению. Аутентификация пользователя (клиента) в типичном варианте осуществляется в режиме аутентификации клиента по протоколам SSL/TLS, после чего пользователю предоставляется доступ (на сервере доступа) к сетевому интерфейсу, снабженному меню, относящемуся к комплекту сервисов, на которые пользователь может подписаться. Коммуникация между клиентом и сервером доступа должна иметь криптографическую защиту. Протоколы SSL/TLS представляют желательный вариант, поскольку соответствуют обычному способу защиты коммуникаций (HTTP) в сети и, кроме того, могут включать аутентификацию пользователя. В качестве альтернативной двусторонней связи может быть назван протокол IPSec/VPN (Internet Protocol Security/Virtual Private Network).
Применяемый протокол аутентификации (например, SSL/TLS с аутентификацией как клиента, так и сервиса) в неявной форме идентифицирует пользователя по имени в сертификате пользователя, который передается на сервер доступа в качестве части протокола. Пользователь может также использовать соответствующий личный ключ для того, чтобы подписать последовательность вызов/ответ, которая подтверждает обладание личным ключом.
Получив сертификат пользователя и его подпись, сервер доступа может затем завершить процесс аутентификации. Однако в случае правильного осуществления этого процесса, с проверкой отзыва и с обеспечением возможности приема различных сертификатов, выпущенных различными издателями сертификатов, валидация сертификата представляется слишком сложным процессом для того, чтобы осуществлять его на любом сервере доступа. В предлагаемой архитектуре для этого предусмотрен отдельный компонент, а именно служба (сервис) валидации, на которую возложена ответственность (и нагрузка), связанная с соответствующей частью обработки сертификатов. В случае необходимости служба валидации может быть реализована в нескольких экземплярах (т.е. в виде нескольких отделений). В предельном случае сервер доступа может просто извлекать сертификат пользователя и направлять его службе валидации. Данная служба возвращает в качестве ответа оценку "да/нет" действительности сертификата, уровень его качества (что может быть полезным в отношении авторизации, которая может быть предоставлена пользователю), имя пользователя (учетное имя, логин), которое извлекается из имени, указанного в сертификате пользователя, и, возможно, дополнительную информацию (если она необходима). Однако распределение нагрузки между сервером доступа и службой валидации может быть осуществлено и иным способом. В частности, основная часть обработки сертификатов может осуществляться локально, на сервере доступа, тогда как службе валидации оставляется, в основном, задача (обычно наиболее ресурсоемкая) проверки отзыва.
Профили пользователей предпочтительно хранятся в одном месте, а именно в службе (сервисе) авторизации. Переход от имени, указанного в сертификате, к соответствующему имени пользователя составляет часть указанного профиля.
Соответственно, для осуществления этого перехода служба валидации после извлечения имени из сертификата должна обратиться к службе авторизации. В качестве альтернативы, служба валидации может возвратить имя из сертификата на сервер доступа, который затем осуществляет указанный переход (отображение) посредством отдельного обращения к службе авторизации. В этом случае отсутствует интерфейс между службой валидации и службой авторизации.
На фиг.2 приведена блок-схема процедур аутентификации, проверки авторизации и доступа к сервису. Применительно к службе валидации могут использоваться несколько различных протоколов. Если служба валидации должна предлагаться сервис-провайдерам в качестве отдельной услуги, то должен использоваться протокол стандартного типа. Возможной альтернативой является протокол OCSPv1 (On-line Certificate Status Protocol, version 1 - Протокол онлайнового состояния сертификата, версия 1), который позволяет осуществлять проверку статуса сертификата в отношении его отзыва и возвращает также некоторую дополнительную информацию, например имя пользователя. Однако пока нельзя передать в службу валидации полный сертификат стандартизованным образом; это можно сделать только с помощью нестандартизованного "расширения". Возможность пересылки полного сертификата обеспечит протокол OCSPv2, который находится пока в версии RFC (Request For Comments). Протокол SCVP (Simple Certificate Validation Protocol - Простой протокол валидации сертификата) имеет тот же статус, что и OCSPv2, и обеспечивает те же функциональные возможности. XKMS (XML Key Management Specification - Спецификация использования открытого ключа на языке XML), как и другие механизмы на базе схем XML, является еще одной альтернативой, в частности, с применением протокола SOAP (Simple Object Access Protocol - Простой протокол доступа к объекту).
Располагая подтвержденной идентификацией пользователя, сервер доступа запрашивает службу авторизации о правах доступа, которые должны быть предоставлены поименованному пользователю. Запрос может быть расширен за счет дополнительной информации, например, касающейся качества процедуры аутентификации пользователя, а также контекстной информации типа текущего местоположения пользователя, времени дня и т.д. Доступ к службе авторизации должен быть основан на стандартном протоколе, каковым может служить, в частности, LDAP (Lightweight Directory Access Protocol - Упрощенный каталог службы протоколов), RADIUS, его планируемый заменитель DIAMETER или какой-либо иной протокол.
Можно также возложить обращение к службе авторизации на службу валидации. В этом случае сервер доступа будет выполнять только вызов службы валидации и получать от нее имя пользователя и другую информацию, относящуюся к вышеописанной процедуре аутентификации, а также перечень полномочий, которые должны быть предоставлены пользователю.
По завершении описанной процедуры пользователю представляется корректное сервисное меню. Как будет описано далее, следующим шагом является выбор сервиса.
Блок-схема, приведенная на фиг.2, показывает операции (шаги), выполняемые в рамках процедур аутентификации, проверки авторизации и доступа к сервису.
Далее будет описан типичный вариант установления связи и доступа к сервисам. Оборудование пользователя или его домашняя сеть подсоединены к инфраструктуре, предлагаемой оператором сети, через какую-либо точку доступа, которая в типовом случае обеспечивает протоколы в канале данных или в слое доступа, или в сетевом слое (например, IP-протокол). На фиг.1 точка доступа не изображена, поскольку она функционирует только в качестве трассировщика в части сетевого доступа между пользователем и сервером доступа. Точка доступа может быть разделена на два компонента, один из которых предлагает услуги на уровне канала данных/слоя доступа, тогда как второй является IP-трассировщиком.
Когда оборудование пользователя подсоединяется к сетевой инфраструктуре, в типичном случае оно получает доступ по умолчанию, т.е. минимальный набор разрешенных коммуникационных трактов. В архитектуре, представленной на чертеже, должен быть активирован тракт к серверу доступа; кроме того, обычно активируется также Domain Name Service (DNS - доменная система имен). К этой минимальной конфигурации могут быть добавлены и другие сервисы/тракты.
Когда пользователь на своем оборудовании открывает браузер, то для того, чтобы пользователь мог получить доступ к сервисам, на браузере должен быть задан Uniform Resource Locator (URL - Унифицированный указатель ресурсов) сервера доступа. Далее пользователь должен пройти процедуру аутентификации и проверки авторизации, после чего ему будет предоставлен доступ к сервисному меню.
Доступные сервисы относятся к трем базовым категориям: коммуникационные сервисы, сервисы на основе Web и медийные сервисы, включающие мультимедиа. При этом третья категория может быть представлена как комбинация двух других. Далее будут описаны действия, совершаемые применительно к каждой из названных категорий.
Коммуникационные сервисы. Когда пользователь выбирает коммуникационный сервис, его запрос должен быть привязан к точке доступа пользователя для того, чтобы создать тракт в направлении выбранной точки назначения. Тракт может быть активирован в IP-слое, открывая возможности для графика от IP-адреса (адресов) пользователя к конкретной точке (конкретным точкам) назначения. Тракт может быть активирован также в слое канала данных, например, путем формирования виртуального контура АТМ (Asynchronous Transfer Mode - Режим асинхронной передачи).
Одним из примеров коммуникационных сервисов является предоставление доступа к Интернет через сервис-провайдера Интернет. Выбор в сервисном меню доступа к Интернет приведет к активации тракта от пользователя к узлу доступа Интернет сервис-провайдера (пограничного маршрутизатора), от которого может быть осуществлен дальнейший доступ.
Сервер доступа должен передавать соответствующие команды к точке доступа пользователя для того, чтобы активировать затребованный коммуникационный сервис. Для этой цели могут быть использованы несколько протоколов, причем самой распространенной альтернативой является RADIUS, запланированной заменой которого является DIAMETER.
Существуют три различных сценария для осуществления доступа к сетевым сервисам из сервисного меню на сервере доступа.
Согласно первому сценарию сервер доступа выступает в качестве посредника (связующего звена) в процедуре с однократным вводом пароля, передавая сервису пароль в виде соответствующей лексемы (маркера). В простейшем варианте такой лексемой является имя пользователя и пароль для сервиса в запросе типа HTTP Post, с прозрачной регистрацией пользователя на сервисе. После этого пользователь либо перенаправляется на сервис, либо сервер доступа продолжает осуществлять операцию в качестве HTTP-посредника. Разработано несколько продуктов и технологий для предъявления пароля, так что имеется возможность использования маркеров из этих технологий. Возможно, сервер доступа может также написать cookie-файл для браузера пользователя, который будет распознаваться и приниматься в качестве пароля-маркера, когда пользователь получает прямой доступ к сервису. При этом сервис может иметь доступ к службе авторизации, например, для более детальной проверки привилегий пользователя в части пользования сервисом.
Во втором сценарии сервис предлагается в рамках описанной системы, но требует отдельной аутентификации. При этом по отношению к сервису используется электронный ИД пользователя (личный ключ и сертификат), т.е. у пользователя имеется только единственный механизм аутентификации. Сервис имеет доступ к службе валидации и может также использовать службу авторизации.
По третьему сценарию сервис предлагается вне рамок описанной системы. Если сервис готов принять описанную аутентификацию, то для этого используется электронный ИД пользователя (личный ключ и сертификат), т.е. и здесь у пользователя имеется только единственный механизм. Сервис имеет доступ к службе валидации, но, поскольку он находится вне системы, как правило, он не имеет доступа к службе авторизации.
Служба валидации является общей, т.е. ее услуги могут быть предложены взаимодействующим организациям и подразделениям как внутри, так и вне системы по изобретению. Служба валидации может быть сконфигурирована таким образом, чтобы возвращать различную информацию (например, различные имена пользователей) в зависимости от сервиса, который к ней обращается. Данное свойство является прямым результатом общего характера аутентификации на базе PKI. Подобный режим не может быть разрешен в случае аутентификации, основанной на паролях, поскольку в этом случае пароли были бы раскрыты сторонним лицам.
В отличие от этого, служба авторизации, как правило, должна быть доступна только изнутри системы. Предоставление возможности сторонним лицам иметь доступ к внутрисистемной информации, относящейся к авторизации, или даже управлять этой информацией через тот же самый сервис в большинстве случаев является недопустимым.
Медийные/мультимедийные сервисы. Как уже упоминалось, (мульти)медийные сервисы могут рассматриваться как комбинация коммуникационных и сетевых сервисов. Некоторые медийные сервисы могут быть реализованы как полностью сетевые или как полностью коммуникационные; однако обычный сценарий соответствует сервису, обеспечивающему сетевой интерфейс для запуска сервиса и реализацию сервиса, которая использует функциональные возможности сети.
Если сервер доступа действует в качестве прокси-сервера между пользователем и медийным сервером, он может улавливать передаваемую информацию и оказывать соответствующую поддержку типа инициирования виртуальной сети VPN между сторонами или выдачи информации в многоабонентскую систему.
На фиг.3 иллюстрируется альтернативный вариант проверки действительности сертификата пользователя. Вместо того чтобы посылать имя сертификата пользователя в службу авторизации, оно посылается на сервер доступа, который затем получает идентификационные данные пользователя от службы авторизации.
На фиг.4 приведен пример аутентификации, авторизации и доступа к платному сервису, такому как Video on Demand (VOD), а также защищенного платежа (в режиме платы за фактическое использование).
Аутентификация пользователя производится с применением архитектуры аутентификации, описанной со ссылкой на фиг.1. Содержимое защищается посредством его шифрования на протяжении всей сессии, тогда как платеж осуществляется в режиме платы за фактическое использование (pay-per-use). Содержимое может шифроваться с помощью пользовательских ключей, обеспечиваемых электронным ИД. Пользователь может выбрать метод платежа, например с выпиской счета или с использованием кредитной карты, и подписать транзакцию, используя тот же электронный ИД, который был использован для аутентификации. Альтернативно, пользователь может воспользоваться внешним механизмом для осуществления платежа и осуществления защищенной транзакции.
Далее изобретение будет описано более подробно со ссылкой на фиг.2.
Сервер доступа функционирует для пользователей в качестве точки доступа к сервисам путем аутентификации пользователей и предоставления им соответствующего сервисного меню. Для того чтобы играть требуемую роль в составе системы, сервер доступа должен выполнять следующие функции:
-поддерживать HTTPS (HTTP по протоколу SSL/TLS) или, альтернативно, быть способным обеспечивать другие средства формирования защищенных коммуникационных каналов;
- иметь возможность аутентифицировать себя клиентам/пользователям, предпочтительно с использованием PKI-технологии (в частности, в режиме аутентификации сервера по протоколу SSL/TLS);
- поддерживать протоколы, необходимые для осуществления коммуникации со службами валидации и авторизации;
- поддерживать один или более протоколов для аутентификации клиента/пользователя на базе PKI-технологии, как правило, по протоколу SSL/TLS;
- обладать функциональностью, требуемой для предоставления пользователю необходимой информации (такой как сервисное меню) и для обработки входных сигналов, поступающих от пользователя;
- действовать в качестве посредника (прокси-сервера) между пользователем и сервисом, т.е. обеспечивать прозрачный канал передачи информации между ними.
Для того чтобы получить доступ к сервису, пользователь должен настроить браузер на сетевой интерфейс, обеспечиваемый сервером доступа. В обычном случае произойдет немедленная аутентификация пользователя в режиме аутентификации клиента по протоколу SSL/TLS, как это было описано выше.
При этом имеются два альтернативных способа: если применяется иной метод аутентификации на базе PKI, то сессия по протоколу SSL/TLS может быть проведена только для аутентификации сервера, после чего в созданном тем самым защищенном канале может выполняться протокол аутентификации пользователя. Если при выборе метода аутентификации существуют несколько альтернатив, то для выбора метода пользователю может быть предоставлена чисто текстовая страница (например, http-страница). После осуществления выбора метода аутентификация будет продолжена, например, путем установления SSL/TLS-сессии для аутентификации клиента.
Как было описано выше, сервер доступа функционирует в расчете на получение сертификата пользователя непосредственно от пользователя. Однако дополнительно могут быть реализованы и другие средства получения сертификата, например просмотр соответствующего указателя.
Как будет описано далее, как можно большая часть обработки сертификата должна быть отобрана у сервера доступа и передана службе валидации. Сервер доступа должен, таким образом, осуществлять валидацию сертификата пользователя с помощью службы валидации, верифицировать подпись пользователя на той части протокола аутентификации, которая относится к вызову, и далее действовать в зависимости от того, была ли аутентификация успешной или неуспешной. Формирование вызова и верификация подписи на нем может быть осуществлена вне сервера доступа. Поскольку сервер доступа может подвергаться атакам со стороны пользователей, для осуществления рассмотренных операций, критичных в отношении защищенности, может оказаться желательным использование более надежно защищенного компьютера.
Первым действием, которое обычно следует за аутентификацией пользователя, является получение формуляра пользователя от службы авторизации (если он не был получен ранее от службы валидации). После этого сервер доступа действует в зависимости от входных сигналов, поступающих от пользователя, и в соответствии с принятой политикой, а также при взаимодействии со службой авторизации при выполнении действий, которые требуют проверок в отношении профиля пользователя. Как показано на фиг.1, на этой стадии могут быть реализованы механизмы предъявления единственного пароля.
Служба валидации оптимизирована для обработки сертификатов. Она получает сертификат или идентификацию сертификата и его издателя и выполняет следующие действия:
- считывает имя издателя;
- получает открытый ключ издателя из списка "хороших" ключей, прошедших предшествующую оценку; при этом все операции по перекрестной сертификации или построению иерархий также проводятся заранее, а все открытые ключи издателя непосредственно принимаются как истинные, т.е. в обработке цепочек сертификатов нет необходимости;
- выполняет проверку отзыва, предпочтительно с обращением к локальной, предварительно обработанной информации об отзывах, собранной путем периодического получения списков отозванных сертификатов (Certificate Revocation List - CRL);
- если был получен полный сертификат, производит анализ сертификата, проверяя подпись, срок действия, а также извлекая содержимое сертификата. Названные операции должны быть индивидуализированы в зависимости от профилей сертификатов;
- извлекает информацию, полученную преобразованием информации, включенной в сертификат, в том числе имя пользователя, извлекаемое на основе имени, указанного в сертификате, уровень качества (определяемый заранее на основе анализа стратегии, действующих в отношении данного сертификата) и т.д. Информация может быть общего характера или специально ориентированной на лицо (или организацию), запросившее (запросившую) валидацию сертификата.
Перечисленные операции могут быть оптимизированы в службе валидации таким образом, чтобы обеспечить требуемые малые времена отклика. В частности, обработка цепочек сертификатов и их отзыва обычно создает большую нагрузку на сервер. По этой причине в современных службах, действующих по технологии PKI, правильная проверка отзыва часто отменяется. Для того чтобы ускорить процесс проверки, сервер валидации заранее обрабатывает информацию об отзывах.
Для работы со службой валидации могут быть применены несколько протоколов. В настоящее время доступным является, в частности, протокол OCSP version 1. Однако он не включает стандартизованный метод передачи полного сертификата. Такая возможность введена в OCSP-протокол version 2, который в настоящее время имеется в Интернет в виде предварительной версии. Альтернативными протоколами, которые способны заменить или дополнить OCSP-протокол, являются вышеупомянутые SCVP, который в настоящее время является версией, имеющейся в Интернет, и XKMS. Протоколы могут быть основаны также на протоколе SOAP (по существу, представляющем комбинацию XML и HTTP) или на аналогичных технологиях; кроме того, может быть разработан и какой-то специальный протокол на правах частной собственности. Все подобные протоколы, в дополнение к ответу типа "да/нет/неизвестен" на запрос о валидации, должны обеспечивать также возможность возврата дополнительной информации лицу, направившему запрос.
OCSP-протокол разработан прежде всего в качестве замены практики выпуска списков CRL одной организацией, ответственной за выдачу сертификатов. Вместо списков CRL или в дополнение к ним издатель сертификатов обеспечивает OCSP-интерфейс, который отвечает на запросы относительно действительности сертификатов, выпущенных именно данным издателем сертификатов. В контексте изобретения служба валидации будет обеспечивать единый OCSP-сервис для всех тех организаций, выдающих сертификаты, которые могут взаимодействовать с данной службой.
Протокол OCSPvl описывает проверку отзыва как единственную функцию OCSP-службы (сервиса). Такое описание является слишком узким, в связи с чем предлагается расширить его. Во-первых, служба валидации должна не только проверять, отозван сертификат или нет, но также, в случае, если срок его действия не истек, осуществлять проверку подлинности подписи издателя сертификата. Во-вторых, служба валидации должна проводить анализ содержимого сертификата и определять на основе такого анализа уровень качества, имя пользователя и, возможно, какую-либо иную информацию.
OCSP-протокол обеспечивает аутентификацию клиента и защиту целостности запросов благодаря предоставлению запрашивающему лицу возможности снабдить запрос (или его части) цифровой подписью. Соответственно, сервер валидации тоже может подписывать свои ответы. Такой режим может быть реализован и для других альтернативных протоколов. Использование подписанных ответов может оказаться весьма важным, поскольку сфальсифицированные или модифицированные ответы могут представлять значительную угрозу. Для того чтобы возвращать информацию, специфичную для лица, направившего запрос, может оказаться необходимым использовать подписанные запросы, если для аутентификации пользователя не используются какие-либо другие методы.
Однако, поскольку обработка подписи (которая обычно подразумевает и обработку сертификата) имеет относительно большую длительность, может оказаться предпочтительным осуществлять обращение к службе валидации по защищенному каналу, например, с применением средств VPN. Именно такой выбор должен быть сделан в отношении канала между сервером доступа и сервером валидации, а возможно, и каналов между сервисами, являющимися внутренними для системы, и службой валидации. Если услуги службы валидации предоставляются внешним субъектам, должны использоваться подписанные запросы и ответы, поскольку, скорее всего, нельзя будет требовать наличие средств VPN от всех подобных внешних субъектов.
Далее перечисляются требования к серверам, которые пользуются услугами службы валидации. В особенности эти требования приложимы к серверу доступа.
В частности, подобная служба может быть размещена на сервере доступа. Для того чтобы воспользоваться услугами службы валидации, определенные части процесса обработки сертификата должны быть "замкнуты" на данную службу. Далее будут описаны некоторые сценарии обработки, выполняемой на сервере.
- Аутентификация SSL-кпиента: обработка по SSL-протоколу на сервере должна приводить к извлечению сертификата клиента. Этот сертификат либо направляется, без дальнейшей обработки, в службу валидации, либо подвергается некоторой локальной обработке перед пересылкой полного сертификата или извлеченной из него информации. В зависимости от ответа использование SSL-протокола либо продолжается, либо прерывается.
- Получение сообщения, снабженного цифровой подписью. Сертификат клиента (пославшего сообщение) может быть извлечен из данного сообщения (или получен другими средствами) и отправлен в службу валидации. Альтернативно, сертификат может быть подвергнут некоторой локальной обработке перед пересылкой полного сертификата или извлеченной из него информации в службу валидации. При успешном завершении валидации может быть проведена локальная верификация подписи. Вместо этого услуги службы валидации могут быть расширены таким образом, чтобы осуществлять всю обработку подписей в системе, как на сообщениях, так и на сертификатах.
- Валидация сертификата, который затем будет использован (для управления ключами) при шифровании сообщения или канала связи с определенным субъектом. Обработка в этом случае будет аналогична обработке при приеме сертификата в рамках сообщения, снабженного цифровой подписью.
- Развертывание виртуальной сети VPN. Обработка на этом этапе будет примерно такой же, что и по сценарию аутентификации клиента по протоколу SSL.
- Другие протоколы аутентификации на базе PKI. Сервер должен получить от клиента сертификат, а затем послать вызов в службу валидации, как это описано в рассмотренных сценариях. Обработка сертификата может быть полностью предоставлена службе валидации, или может иметь место некоторая его локальная обработка.
Для того чтобы произвести обращение к службе валидации (с использованием альтернативных протоколов, перечисленных выше), необходимо модифицировать программное обеспечение сервера. Объем локальной обработки, которая может быть передана от сервера, будет зависеть от того, какие модификации могут быть внесены применительно к конкретной серверной платформе. Для оптимизации показателей работы обращение в службу валидации должно быть встроено в другие виды обработки, производимой на сервере. Это обращение должно полностью или частично заменить функционирование сервера (в части локальной обработки), которое предусмотрено для большинства серверных платформ. Подобные модификации часто являются довольно сложными и зависящими от степени открытости платформы. Альтернативой является расширение функциональности, в дополнение к уже имеющейся, а также использование открытых интерфейсов, причем локальная обработка производится только в пределах, определяемых конфигурационными параметрами.
Представляется также возможным создание интерфейса между пользователями (клиентами) и службой валидации. В этом случае обработка сертификата в браузере пользователя (в типичном случае на оборудовании пользователя может иметься и какое-либо иное программное обеспечение) полностью или частично заменяется обращением к службе валидации. Такой режим аналогичен рассмотренной ситуации с сервером. Главное назначение подобного интерфейса будет состоять в обработке сертификатов сервера по SSL-протоколу, однако использование интерфейса может быть связано и с развертыванием виртуальной сети VPN, с получением сообщений с цифровой подписью и с валидацией сертификатов, которые будут применены для шифрования сообщений/трафика в направлении других участников. В этом случае ответы от службы валидации, как и запросы пользователей, могут быть подписаны. Если служба валидации верифицирует подписи на сертификатах в интересах пользователя, то оборудование пользователя может не включать в себя перечень открытых ключей издателей сертификатов (в настоящее время содержащий около 150 ключей), который обычно заранее включается в стандартные браузеры (в том числе в новейшие версии операционных систем Microsoft). Операции с подобными открытыми ключами провайдеров со стороны пользователей являются одним из главных препятствий для широкого использования PKI.
Введение службы валидации основано на двух базовых идеях, касающихся поддержки различных издателей сертификатов:
- высокая эффективность благодаря оптимизации сервиса по обработке сертификатов, особенно за счет отказа от проверки цепочек сертификатов и благодаря проверке отзыва сертификата путем обращения к локальной базе данных взамен обработки списков CRL;
- обеспечение единого пункта, в котором интегрированы сервисы (услуги), рассчитанные на принятие сертификатов от более чем одного издателя сертификатов.
В настоящее время сервис, использующий аутентификацию на базе PKI, должен быть индивидуально интегрирован по отношению к каждому издателю сертификатов, чьи сертификаты он намерен принимать. Сложность такого интегрирования обусловлена, в первую очередь, необходимостью работы с различными форматами сертификатов, различными схемами именования, различными точками доступа для получения информации об отзыве и взаимодействия с провайдером открытых ключей. Как следствие, сервис может напрямую интегрироваться лишь с несколькими отобранными издателями сертификатов. Служба валидации освобождает сервисы от этой сложности.
Однако даже служба валидации сталкивается с аналогичной сложностью, когда необходимо обеспечить поддержку многих издателей сертификатов. Главная сложность заключается при этом в определении уровня качества, как это будет пояснено далее. Работа с открытыми ключами различных провайдеров должна иметь высокую надежность при постоянном отслеживании отзывов и других текущих изменений. Необходимо учитывать различия в форматах сертификатов от различных издателей путем разработки специальных программ анализа (хотя данная задача до некоторой степени упрощается за счет стандартизированных профилей, однако необходимо определять такие профили). С технической точки зрения служба валидации не является слишком сложной, но управление ею требует соответствующих ресурсов. Однако во многих контекстах более удобно централизовать эту сложность, чем иметь с ней дело по отдельности для каждого сервиса.
В связи с этим возникает вопрос, сколько и каких именно издателей сертификатов желательно поддерживать с помощью подобной службы. Во всем мире существует несколько сотен издателей открытых сертификатов, причем их количество будет расти. Кроме того, все чаще будут появляться корпоративные системы (использующие интрасети), которые могут быть основаны на стандартных продуктах (например, от фирм Microsoft или IBM/Lotus), позволяющих всем желающим организовать сервис по выпуску сертификатов. Хотя большинство подобных сервисов будут иметь очень низкие рейтинги в отношении качества и надежности (поскольку они будут выпускаться без какой-либо гарантии) и, следовательно, окажутся практически бесполезными вне корпоративной интрасети, могут возникать ситуации, когда будет желательно иметь возможность принять сертификат от сотрудничающей фирмы или от корпоративного клиента.
Решение по данному вопросу относится скорее к сфере менеджмента, чем к технике, до тех пор, пока реализованная служба валидации имеет достаточные возможности расширения масштабов своей деятельности.
Одно из критических требований заключается в том, что сертификат должен обеспечивать, непосредственно или косвенно, информацию, необходимую для дальнейшей обработки, прежде всего, имя, которое может быть использовано для осуществления контроля доступа и расчетов.
В плане категоризации сертификатов и их уровня качества служба выпуска сертификатов характеризуется следующими компонентами:
- юридическим статусом и соответствующими соглашениями;
- сертификационной стратегией (политикой), которая предусматривает выработку требований к процедурам, относящимся к ее функционированию, и, как правило, охватывает целый ряд юридических аспектов и соглашений (однако часто эти аспекты должны быть сформулированы явным образом и, следовательно, желательно выделить их в отдельный раздел);
- описанием практических аспектов, которое поясняет, как требования, сформулированные в рамках стратегии, будут обеспечиваться данной конкретной службой - в этом случае возможны ссылки на внутренние документы, описывающие процедуру работы;
- форматом сертификата, в частности правилами, связанными с именами;
- моделью проявления доверия по отношению к другим участникам и особенно позицией в отношении иерархических структур и режимов перекрестной сертификации;
- информационными услугами в отношении сертификатов, информацией об отзывах, информацией о стратегии и прочей релевантной информацией.
Аспекты качества службы сертификатов определяются, в основном, выбранной стратегией. Эта стратегия формулирует требования к процедуре регистрации, которую должен пройти пользователь для того, чтобы получить сертификат (например, подача электронной заявки в качестве альтернативы личной явки с физической аутентификацией и т.д.), меру ответственности, которую издатель готов принять на себя в случае ошибок, требования по защищенности, накладываемые на работу службы, и т.п. К счастью, существует несколько стандартизированных подходов для формулирования стратегии, причем большинство издателей сертификатов следуют одному из них. Благодаря этому появляется возможность проводить сравнение между различными стратегиями по отдельным пунктам.
Вместе с тем, категоризация (классификация) сертификационных стратегий - это основная задача из выполняемых вручную, причем она требует определенной квалификации. Необходимо разработать критерии классификации и методические основы ее проведения. Какие критерии должны быть реализованы для того, чтобы обеспечить определенный уровень качества? К этому добавляются такие трудности, как необходимость анализа стратегий, изложенных на иностранных языках, а также наличие ссылок на законы и правила иностранных государств. До тех пор, пока не появится независимая служба по классификации стратегий, разработчик сервиса валидации должен самостоятельно осуществлять процесс оценки отдельно для каждого издателя сертификатов. Это означает, что начинать следует с небольшого количества наиболее важных издателей с расширением их числа по мере необходимости.
Необходим также постоянный мониторинг реализуемых стратегий. Однако, как правило, описания стратегий будут включать процедуры по их изменению, причем многие издатели будут поддерживать политику активного уведомления других участников в случае существенных изменений стратегии.
Категория (класс) качества может быть выражена простым численным значением, например, в шкале 1-4, в которой высший уровень соответствует 1, а низкий уровень качества - 4. Пока проведена лишь небольшая работа по стандартизации подобных уровней. В пределах Европейского Сообщества более или менее принято, что уровень "квалификационного сертификата" является индикатором высокого качества, пригодного для применения с формальными цифровыми подписями. В США некоторые уровни качества сертификатов определены "Федеральной согласующей службой сертификатов" ("federal bridge certificate authority"). Издатель сертификатов, который обеспечивает услуги по отношению к федеральному сектору, должен провести перекрестную сертификацию с указанной федеральной службой с указанием соответствия между его стратегией и подходящим уровнем качества, сформулированным данной федеральной службой. Европейский институт стандартизации в области связи (European Telecommunications Standards Institute - ETSI) в настоящее время разрабатывает "рамочные правила для стратегий, не являющихся квалификационными", которые должны определить некоторые индикаторы, подлежащие учету при отнесении стратегии к определенной категории.
Кроме того, классификация по качеству может быть намного более многоаспектной, чем простая индикация уровня. Основываясь на общих правилах типа разрабатываемых ETSI, можно извлечь из сформулированной стратегии некоторую структуру, которую можно возвращать по соответствующему запросу. В качестве примера, ответственность, которую готов нести издатель сертификата, может оказывать влияние на ценность транзакции, которая может быть основана на аутентификации на базе сертификата, полученного от данного издателя. Еще одним важным параметром является юрисдикция, указанная в формулировке стратегии.
Следующее важное обстоятельство состоит в том, является ли уровень качества (сформулированная стратегия и вытекающие из нее практические правила) просто объявленным(и) издателем сертификатов, или его заявления находят объективное подтверждение со стороны третьих лиц. Многие стратегии, касающиеся выдачи сертификатов, требуют независимого аудита для того, чтобы гарантировать соответствие реальных действий заявленным стратегии, практическим правилам и внутренним процедурам. Наличие отчета о подобном аудите, вероятно, будет соответствовать более высокому рейтингу в отношении качества или, по меньшей мере, большей уверенности в таком рейтинге. В этом аспекте должны учитываться также сертификаты типа ISO9000 и ISO17799.
Наконец, следует отметить, что качество сервиса не всегда означает доверие к нему. Гипотетическая организация "Мафия и Ко" может добиться высокого рейтинга по качеству, но из этого не следует, что ее сертификаты будут приниматься.
В дополнение к стратегии и уровню качества сертификатов необходимо принимать во внимание и другие аспекты сервиса по выдаче сертификатов. В частности, могут быть сформулированы требования по формату сертификатов, например, касающиеся определенных полей, атрибутов или расширений, которые должны или, наоборот, не должны присутствовать. Отдельный аспект связан с именами, причем для описываемой системы должна быть обеспечена возможность перехода от имени, указанного в сертификате, к действующему имени пользователя. Еще одно требование, которое может возникнуть в некоторых случаях, состоит в том, что имя должно быть "подлинным", а не псевдонимом.
На фиг.5 представлена предлагаемая архитектура службы валидации. В ее состав входят следующие части:
- OCSP-сервер, который обрабатывает синтаксис и семантику, относящиеся к OCSP-протоколу (изображенные штриховыми линиями дополнительные фронтальные блоки для работы с другими протоколами могут быть добавлены позднее);
- процессор валидации, который осуществляет обработку сертификатов, проверяет их действительность и извлекает из них информацию;
- отдельный процессор для того, чтобы заранее собирать и обрабатывать списки CRL от всех сертификационных центров (Certificate Authorities), которые используются в работе службы;
- программа OCSP-клиент, которая может оказаться необходимой для получения доступа к информации по отзыву от издателей сертификатов, не поддерживающих списки CRL;
- база данных, в которой содержится информация об издателях сертификатов, их открытых ключах, заявленных стратегиях и соответствующих уровнях качества, информация об отзывах, обновляемая вышеописанными методами, а также дополнительная информация, которая может быть извлечена из сертификатов;
- интерфейс (предпочтительно LDAP) для связи со службой авторизации с целью получения данных по переходу от имени, указанного в сертификате, к действительному имени пользователя, используемому в рамках системы, а также, возможно, к другим формам имен для других доменов (как уже упоминалось выше, данный интерфейс может входить в состав не службы валидации, а сервера доступа);
- в состав службы валидации, почти наверняка, должно входить и криптографическое оборудование (на фиг.5 не изображено).
В процессе функционирования OCSP-сервер и другие фронтальные блоки осуществляют, в соответствии с используемым протоколом, обработку данных, необходимую для работы службы валидации. Эта работа включает осуществление валидации и генерирование подписей на запросах и ответах, требующих цифровой подписи.
Фронтальные блоки снабжены прикладными программными интерфейсами (API - Application Programming Interface) для связи с процессором валидации. Процессор валидации должен осуществлять анализ сертификата (если он включен в сообщение) или иным образом реагировать на представленную сертификационную информацию.
После этого сертификат подвергается проверкам действительности: подпись соответствующая, формат соответствующий, срок действия соответствующий, не отозван и не приостановлен. Некоторые из этих проверок рассчитаны на работу с полным сертификатом и не могут быть проведены, если представлены только выдержки из него. Уровень качества определяется на основе стратегии, указанной в сертификате (или из заранее подготовленных сведений в том нежелательном случае, когда издатель не включает в свои сертификаты рекомендуемый идентификатор стратегии). Ранее извлеченная информация получается из базы данных, а результаты возвращаются через API на OCSP-сервер (или в другие фронтальные блоки) в форме, определяемой API.
Проверка наличия отзыва в обычном случае будет соответствовать простому обращению в базу данных, поскольку отдельный процессор будет заранее собирать необходимую информацию (как это описано далее), Однако, если издатель сертификатов обеспечивает только OCSP-интерфейс для проверки отзывов и не имеет службы по выпуску списков CRL, то процессор валидации должен напрямую обращаться к провайдеру OCSP-сервиса.
Можно также представить себе ситуацию, когда услуги по валидации могут образовывать цепочку с другими услугами, а вызов осуществляется с использованием протокола (не обязательно OCSP-протокола), поддерживаемого внешним интерфейсом удаленной службы валидации.
В настоящее время, насколько это известно заявителю, большинство сертификационных центров используют заверенные подписью списки CRL для того, чтобы информировать об отзыве или приостановке сертификатов. Списки CRL выпускаются регулярно, причем в каждом таком списке содержится плановое время выпуска следующей версии. Однако в случае необходимости списки CRL могут выпускаться и раньше запланированного срока. Обычно используются полные списки CRL, т.е. такой список содержит серийные номера всех отозванных сертификатов. Сертификат исключается из очередного списка CRL, когда срок действия сертификата истекает до времени выпуска этого списка. Могут использоваться также и так называемые дельта-списки, или инкрементальные списки CRL, которые содержат только новые поступления в список отозванных сертификатов, появившиеся после выхода предшествующего списка. При наличии дельта-списков полные списки выпускаются регулярно, но намного реже, чем в случае использования только полных списков.
Таким образом, в обычном случае функция отдельного процессора для сбора списков CRL состоит в запуске демон-процесса по отношению к каждому поддерживаемому издателю сертификатов, а также в получении и обработке полного списка CRL от издателя в момент, по возможности, близкий к запланированному времени выпуска этого списка. Результаты обработки списков хранятся в базе данных. Однако при этом необходимо поддерживать и некоторые дополнительные варианты, причем служба валидации должна знать планы выпуска списков CRL, которых придерживаются различные издатели сертификатов и которые изложены в их заявленных стратегиях. Служба валидации, разумеется, должна знать распределительные пункты для списков CRL и иметь доступ к этим пунктам. К спискам CRL должен иметься открытый доступ; однако некоторые издатели могут взимать плату за их получение. В таком случае эта плата должна либо переноситься на обращающихся с запросами, либо учитываться каким-либо иным образом.
Если издатель выпускает дельта-списки CRL, именно они должны использоваться в первую очередь отдельным процессором, получающим списки, поскольку в этом случае объем данных, подлежащих загрузке при каждой операции доставки, будет намного меньшим, чем в случае полного списка.
Если издатель установил значительные интервалы времени между очередными списками CRL, это может означать, что он придерживается стратегии "выпуска списка CRL по мере необходимости". В таком случае процессору, собирающему списки CRL, следует регулярно опрашивать издателей в определенном порядке, не дожидаясь планового срока выпуска списка. Временной интервал между очередными списками CRL, который служба валидации согласна принять, - это настраиваемый параметр, влияющий на качество службы валидации. Данный интервал следует выбрать равным времени опроса издателей в определенном порядке, причем все издатели, у которых частота выпуска списков является более высокой, чем частота, соответствующая данному интервалу, должны быть включены в список опрашиваемых в определенном порядке.
Применительно к широкомасштабным операциям в международном масштабе использование единственной центральной установки, которая получает потенциально очень длинные списки CRL от всех издателей, очевидно, является неэффективным. Установка, расположенная, например, в Норвегии, которая каждый час должна забирать данные в объеме многих мегабайт от сотен издателей, расположенных по всему миру, может быть работоспособной, но ее эффективность будет низкой. Соответственно, распространение информации об отзывах будет идти с малой скоростью. В связи с этим для процессора, собирающего списки CRL, целесообразно использовать распределенную архитектуру. Однако рассмотрение подобного варианта выходит за рамки данного описания.
Могут существовать также издатели, которые вообще не выпускают списки CRL, a полностью опираются на OCSP-интерфейс для проверки наличия отзыва. В таком случае процессор, собирающий списки CRL, бесполезен, так что процессор валидации, когда это необходимо, должен обращаться к соответствующему OCSP-интерфейсу (или к другой службе валидации, как это было описано выше).
Стратегии, реализуемые процессором, собирающим списки CRL, должны настраиваться и по другим аспектам. Поскольку, помимо рассмотренных, на результаты его работы будут влиять и другие параметры, основное требование связано с величиной задержки относительно момента распространения информации об отзывах, которая является приемлемой. Между выпуском списка CRL и моментом завершения обработки этого списка процессором, собирающим подобные списки, неизбежен временной промежуток. На запрос, который поступит в службу валидации во время этого промежутка, либо должен следовать ответ, выдаваемый с задержкой (если служба валидации будет ожидать окончания завершения своей работы процессором, собирающим списки CRL), либо возникает риск ошибочного ответа (если служба валидации отвечает немедленно, основываясь на ранее полученных данных об отзывах).
Существует также риск того, что служба распределения списков CRL у издателя будет перегружена запросами при каждом выпуске планового списка. Это связано с тем, что многие субъекты одновременно пытаются загрузить новый список CRL в локальную кэш-память. Чтобы справиться с этой трудностью, некоторые издатели используют стратегию "избыточного выпуска". В этом случае списки CRL выпускаются с большей частотой, чем указанная в объявленной стратегии. Подобные обстоятельства должны учитываться процессором, собирающим списки CRL.
База данных будет хранить информацию о каждом издателе сертификатов и о его заявленных стратегиях, а также информацию об отзывах. Возможно также хранение информации о пользователях; однако в контексте описываемой системы по изобретению целесообразно предоставить хранение и управление информацией о пользователях службе авторизации.
Информация о пользователе будет состоять из имени издателя (которое указывается в поле "Имя издателя" сертификата), идентификации заявленной стратегии (в составе сертификата (почти) всегда имеется Идентификатор задач, отражающий заявленную стратегию), открытого ключа или перечня открытых ключей (с указанием срока их действия и идентификатора ключа в виде значения хеш-функции), которые должны быть использованы при валидации сертификатов, а также из показателей качества, зависящих, как это описано выше, от заявленной стратегии и издателя сертификата.
Управление открытыми ключами издателей сертификатов в настоящее время является источником "головной боли", поскольку оно всегда осуществляется в форме локальных списков издателей, заслуживающих доверия, и их ключей, часто в форме сертификатов, заверенных собственной подписью (что обеспечивает защиту целостности, но не аутентификацию). В предлагаемой системе управление ключами издателей предпочтительно централизовано в службе валидации. Такое решение возможно только в случае, если в службу валидации направляются полные сертификаты, тогда как локальная проверка подписи издателя на сертификате замыкается на систему вызовов.
Валидация ключей издателей сертификатов представляет собой процесс, который частично осуществляется вручную (с целью гарантии его качества), а частично автоматически, причем ключи хранятся в базе данных. Отзыв ключа издателя - весьма редкое, но также и весьма серьезное событие. Необходимо осуществлять мониторинг информационных каналов для того, чтобы гарантировать обнаружение таких отзывов. В некоторых случаях подобный отзыв осуществляется посредством списков CRL, выпускаемых издателями сертификатов, на высоком уровне иерархии. В других случаях издатель сертификатов не будет являться членом какой-либо системы доверия и должен самостоятельно организовать отзыв. Однако порядок уведомления об отзыве всегда должен быть описан в заявленной стратегии.
Некоторые издатели сертификатов будут постоянно использовать только одну пару ключей, если не считать того, что смена ключей обычно означает для издателя наличие интервала времени, в котором старый открытый ключ все еще действует для валидации сертификатов, в то время как личный ключ не является действительным для подписывания новых сертификатов. Другие издатели могут принять политику частой смены ключей. В этом случае одновременно могут действовать несколько ключей (по меньшей мере, для валидации сертификатов). В связи со сказанным, вероятно, существует потребность в ручной процедуре для учета текущих изменений в базе данных открытых ключей издателей сертификатов.
Управление информацией об отзывах осуществляется процессором, собирающим списки CRL. Проверка отзывов осуществляется локально, путем проведения поиска в базе данных, чтобы установить, отмечен ли серийный номер интересующего сертификата как отозванный. Информация об отзывах должна иметь временную привязку: указание времени отбора текущей информации и времени, назначенного для выполнения следующей операции.
Основная мотивация для существования службы авторизации состоит в необходимости управления и защиты информации, относящейся к пользователям, из одного места. В настоящее время принято иметь отдельные системы аутентификации и авторизации для каждого сервиса или, по меньшей мере, для каждой сервисной платформы. Как следствие, управление информацией о подписчиках/пользователях - т.е. ввод новой информации, изменение или стирание информации - становится громоздким и подверженным ошибкам.
Служба авторизации хранит информацию по каждому пользователю в одной базе данных. При этом и данная служба, и база данных могут существовать в нескольких копиях (отделениях). В качестве "пользователей" обычно выступают индивидуальные люди, но пользователем может быть и обозначение подписчика, имя группы или какое-либо иное поименованное сообщество. Хранящаяся информация относится как к аутентификации, так и к авторизации. В систему может быть легко добавлена бухгалтерская (учетная) информация, хотя в данном описании этот вариант не рассматривается. Информация может быть чувствительной в отношении конфиденциальности и целостности, так что служба авторизации и база данных должны иметь надежную защиту.
В настоящее время служба авторизации должна поддерживать два стандартных протокола: LDAP и RADIUS. Необходимо будет поддерживать также протокол DIAMETER, когда будут готовы его спецификации. Могут поддерживаться и другие протоколы. Поскольку служба авторизации имеет дело с чувствительной информацией, перед тем как возвратить какую-либо информацию, она должна осуществить аутентификацию и контроль доступа в отношении лиц, обратившихся к данной службе. Эти процедуры могут являться частью используемого протокола или быть основаны на "базовых протоколах" (таких как SSL, TLS, IPSec) или на других VPN-технологиях. Альтернативно, для этого могут быть использованы выделенные коммуникационные каналы (физические или логические). В связи с использованием различных протоколов будет существовать необходимость во фронтальных блоках, специфичных по отношению к конкретным протоколам, подобно тому, как это было описано применительно к службе валидации.
Служба авторизации осуществляет преобразование имен для аутентификации и для доступа к сервису. Применяемые протоколы аутентификации на базе PKI обеспечивают аутентификацию имени, указанного в сертификате. Это имя может быть отослано в службу авторизации, которая возвратит соответствующее имя пользователя. Имя сервиса, для которого требуется данное имя, должно являться параметром вызова, поскольку у пользователя может иметься несколько имен пользователя, предназначенных для различных сервисов. Вместе с именем пользователя может быть возвращен и пароль, если он необходим и был затребован.
На последующих стадиях сеанса в службу авторизации, если это необходимо, может быть направлен запрос на получение других имен пользователя. В службу авторизации может быть передана, в частности, пара имя пользователя/сервис для того, чтобы преобразовать ее в другую пару имя пользователя/сервис с целью получения доступа к другому сервису. Служба авторизации должна регистрировать силу механизма аутентификации, примененного последним в отношении поименованного пользователя, и действовать с учетом этого при предоставлении доступа к сервису или при отказе в таком доступе соответственно путем возвращения или невозвращения запрошенной информации.
Первый уровень авторизации в системе служит для предоставления доступа к сервисам как таковым. Авторизация может быть увязана с определенными условиями, например с использованием достаточно качественного механизма аутентификации, локализацией в разрешенных зонах, применением только определенного оборудования, временем дня и т.д. Другим условием является отчетность и гарантированный платеж. В настоящее время этот вопрос решается индивидуальными сервисами, но позже он может быть передан в службу авторизации. Для получения доступа необходимо выполнить все названные условия.
Кроме того, в базе данных могут храниться авторизации, специфичные для определенных сервисов. В таком случае обращение к службе авторизации в случае попытки получения доступа к конкретным объектам (например, типа части содержимого) может быть непосредственно от самого сервиса для того, чтобы определить, следует ли удовлетворить поступивший запрос или нет.
Ниже перечисляются (без подробного описания) дальнейшие направления расширения службы авторизации.
- Выдача криптологически защищенных лексем (tokens) в качестве подтверждений авторизации, Такие лексемы могут быть основаны на подписанных привилегированных (атрибутивных) сертификатах, Kerberos-мандатах или на других аналогичных технологиях.
- Управление делегированием авторизациями от одного пользователя/участника другому.
- Группирование авторизации от нескольких пользователей/участников для принятия решений в отношении доступа.
В описываемой системе аутентификация базируется на имеющихся коммерческих (или некоммерческих) центрах сертификации. Управление сертификатами (включая регистрацию, присвоение имен, выпуск сертификатов и их отзыв) должны брать на себя провайдеры услуг по сертификации.
Служба авторизации должна поддерживать базу данных имен пользователей и соотнесенных с ними привилегий. Имена, указываемые в сертификатах, не могут непосредственно использоваться в данном контексте. Следовательно, необходимо осуществлять преобразование между именем пользователя и именем (именами) в сертификате (сертификатах), которое (которые) пользователь хочет использовать для аутентификации. Эта процедура может быть расширена добавлением других имен пользователя, ассоциированных с другими сервисами, и, возможно, также паролей или другой аутентифицирующей информации для того, чтобы сервис доступа мог прозрачным образом подключить пользователя к сервису, который поддерживает в качестве механизма аутентификации только комбинацию имя пользователя/пароль.
Могут иметь место случаи, когда формат присвоения имен, используемый конкретным издателем сертификатов, может быть автоматически транслирован в имя пользователя. Однако в большинстве случаев переход от имени в сертификате к имени пользователя должен быть явным образом сконфигурирован в базе данных. Чтобы избежать излишних расходов на администрирование, такой переход целесообразно реализовать, в основном, в виде интерфейса самообслуживания для пользователей. Тем не менее, будет существовать необходимость и в административном интерфейсе, а также в определении операторов с правами расширенного доступа к базе данных.
Пользователи должны иметь доступ к указанному интерфейсу самообслуживания, через который они могут представить сертификат и детали, касающиеся их подписки, для того, чтобы имя, указанное на сертификате, было зарегистрировано и ассоциировано с именем пользователя. Связь между двумя формами имен должна, разумеется, устанавливаться в защищенной форме. Существует возможность предоставления пользователям двух альтернативных вариантов.
Первый из них состоит в том, чтобы подписаться на открытие счета и одновременно заказать электронный ИД у предпочтительного партнера владельца системы или у издателя сертификатов, выбранного из списка альтернативных издателей. В зависимости от заявленной стратегии издателя сертификатов электронный ИД может быть доступен для немедленного использования или же потребуется его активация на более поздней стадии (например, если пользователю понадобится приобрести смарт-карту). Однако для службы авторизации важной информацией в этом случае является имя, которое будет проставлено на сертификате.
Второй вариант заключается в том, чтобы подписаться на открытие счета и указать существующий сертификат, который будет использован для аутентификации пользователя. Приемлемость сертификата должна быть проверена в отношении существующих требований (в частности, с точки зрения безопасности), при этом необходимо проверить, что сертификат действительно принадлежит новому пользователю. При этом достаточно зарегистрировать единственный сертификат, предоставив пользователю возможность позднее добавить другие сертификаты.
Существующим пользователям должно быть разрешено регистрировать дополнительные сертификаты или заменители уже зарегистрированных сертификатов. Соответствующая процедура может выполняться в режиме самообслуживания и быть доступной в форме сетевого сервиса. Следует отметить, что необходимо иметь правила в отношении приемлемых методов аутентификации применительно к новому сертификату, который будет зарегистрирован. Например, нельзя будет сначала предложить сертификат низкого качества, а затем использовать его для того, чтобы зарегистрировать высококачественный сертификат как новый метод аутентификации. В подобном случае сертификат высокого качества будет обеспечивать, по существу, ту же степень защищенности, что и аутентификация на базе сертификата низкого качества. При этом существующая конфигурация может предусматривать ограничения доступа по сертификату низкого качества, в то же время разрешая доступ для аутентификации, которая (в данном примере ложно) представляется высококачественной. Как следствие, метод аутентификации может быть использован только для введения новых методов на том же или более низком уровне защищенности.
Для того чтобы перейти на более сильный метод аутентификации, следует применять процедуры, аналогичные принятым для новых пользователей. При этом самообслуживание возможно только до некоторой степени, не исключено, что в какой-то степени окажутся необходимыми и ручные процедуры.
Администраторы должны иметь право добавлять, удалять или изменять информацию для других пользователей. Администраторы должны быть определены внутри системы для организации, которая реализует службу авторизации, а также по отношению к сервис-провайдерам, доступ к которым будет осуществляться через рассматриваемую систему, а также, например, к корпоративным клиентам, которые должны управлять подпиской для нескольких пользователей. Администраторы могут использовать тот же интерфейс, что и обычные пользователи, или, если это целесообразно, отдельный интерфейс. Необходимо также предусмотреть возможность обработки информации в пакетном режиме, в частности ввод информации о многих пользователях за одну операцию.
В большинстве случаев представляется экономически эффективным предоставить администрирование подписки (т.е. авторизацию на пользование сервисами) индивидуальному пользователю. Таким образом, самообслуживание, которое было описано применительно к администрированию аутентифицирующей информации, должно также охватывать и другую информацию о пользователе (в действительности, подобное использование будет, вероятно, превалировать над управлением аутентифицирующей информацией).
Первый уровень авторизации соответствует допуску к сервисам как таковым - т.е. подписке на сервис или прекращению подписки. На более детальном уровне может быть включено управление авторизациями, относящимися к характеристикам индивидуальных сервисов (если сервис делегировал такое управление службе авторизации). Примером может служить изменение ширины полосы применительно к коммуникационному сервису.
Когда пользователи осуществляют рассмотренные административные процедуры, должны выполняться определенные ограничения, в том числе в отношении авторизации. Например, пользователь может подписаться на сервис, требующий сильной процедуры аутентификации, только если на его имя зарегистрирован сертификат достаточно высокого качества. Другим примером является подписка на определенное содержимое на сервере, которая может быть разрешена только для лиц старше определенного возраста.
Администраторы необходимы также для управления авторизациями. В качестве примера можно отметить, что, согласно стратегии, только определенные лица могут управлять правами доступа к некоторым сервисам для корпоративных пользователей. Для управления информацией о многих пользователях в ходе единственной операции необходим интерфейс, ориентированный на пакетный режим работы.
1. Система для предоставления пользователю защищенного доступа, по меньшей мере, к одному сервису, предлагаемому сервис-провайдером, причем пользователь и сервис-провайдер обладают средствами подключения к общей компьютерной сети, содержащая
одно или более отделений службы валидации, выполненных с возможностью выполнения следующих операций:
получение от сервера доступа имени, указанного в сертификате пользователя,
контроль действительности сертификата пользователя,
если сертификат пользователя является действительным, то либо отправка имени, указанного в сертификате пользователя, в отделение службы авторизации для преобразования в имя пользователя с передачей имени пользователя, возвращенного службой авторизации, серверу доступа, либо передача имени, указанного в сертификате пользователя, серверу доступа, если сертификат пользователя является недействительным, отказ пользователю в доступе к сервису;
одно или более отделений службы авторизации, выполненных с возможностью выполнения следующих операций:
получение от отделения службы валидации или от сервера доступа имени, указанного в сертификате пользователя,
отправка имени, указанного в сертификате пользователя, в базу данных, получение имени пользователя и его профиля от базы данных,
передача идентификатора поименованного пользователя отделению службы валидации или серверу доступа,
получение от сервера доступа запроса о правах на доступ,
посылка в базу данных запроса на информацию о подписке,
получение от базы данных информации о подписке,
определение прав доступа на основе указанной информации о подписке,
передача прав доступа на сервер доступа;
одно или более ролевых отделений авторизации с ассоциированными базами данных, выполненных с возможностью выполнения следующих операций:
получение от отделения службы авторизации сертификата пользователя, обнаружение имени пользователя и его профиля в базе данных, отправка имени пользователя и его профиля отделению службы авторизации, получение запроса на информацию о подписке от отделения службы авторизации, отправка информации о подписке отделению службы авторизации.
2. Система по п.1, отличающаяся тем, что дополнительно содержит, по меньшей мере, один сервер доступа, выполненный с возможностью выполнения следующих операций:
получение запроса от пользователя,
аутентификация себя пользователю и запрашивание аутентификации от пользователя,
выполнение последовательности вызов/ответ,
истребование от пользователя сертификата и подтверждения обладания личным ключом,
передача имени, указанного в сертификате, отделению службы валидации,
в случае если сертификат пользователя является действительным, получение идентификатора поименованного пользователя от отделения службы авторизации, запрашивание отделения службы авторизации о правах доступа,
получение прав доступа от отделения службы авторизации,
обнаружение соответствующего сервисного меню,
представление сервисного меню пользователю и
передача информации между пользователем и сервис-провайдером.
3. Система по п.1 или 2, отличающаяся тем, что сервер доступа содержит
средства HTTPS или иные средства для обеспечения защищенности коммуникационных каналов,
средства аутентификации сервера доступа клиентам/пользователям, предпочтительно с использованием технологии PKI,
средства, необходимые для осуществления коммуникации со службой валидации и с отделением службы авторизации,
средства поддержки одного или более протоколов для аутентификации клиентов/пользователей на основе технологии PKI,
средства для осуществления функций, необходимых для представления информации пользователю и приема/обработки входных сигналов от пользователей,
средства для осуществления функций прокси-сервера между пользователем и сервисом.
4. Система по п.1 или 2, отличающаяся тем, что выполнена с возможностью истребования сертификата и подтверждения обладания личным ключом от пользователя путем просмотра указателя.
5. Система по п.1 или 2, отличающаяся тем, что сервер доступа выполнен с возможностью служить посредником при осуществлении прямого доступа к сервису с однократным вводом пароля.
6. Система по п.1 или 2, отличающаяся тем, что база данных, хранящая имя пользователя и его профиль, хранит также другую информацию о пользователе.
7. Система по п.3, отличающаяся тем, что сервер доступа выполнен с возможностью, в случае использования других средств обеспечения защищенности коммуникационного канала, осуществления SSL/TLS-сеанса только для аутентификации сервера и выполнения протокола аутентификации пользователя по сформированному защищенному каналу.
8. Система по п.3, отличающаяся тем, что выполнена с возможностью, при доступности нескольких альтернативных методов аутентификации, предоставлять пользователю возможность выбора, с осуществлением сервером доступа SSL/TLS-сеанса при использовании метода аутентификации, выбранного клиентом.
9. Система по п.5, отличающаяся тем, что в состав системы входит сервис-провайдер, способный получать доступ к отделению службы авторизации и осуществлять с ней обмен информацией,
10. Система по п.1, отличающаяся тем, что указанные отделения службы валидации, отделения службы авторизации и ролевые отделения авторизации реализованы в компьютерной форме.
11. Применение системы по п.1 или 2 для обеспечения аутентификации, авторизации и доступа к платному сервису, такому как Video on Demand.
12. Способ предоставления пользователю доступа, по меньшей мере, к одному защищенному сервису, предлагаемому сервис-провайдером, причем пользователь и сервис-провайдер обладают средствами подключения к общей компьютерной сети, включающий следующие операции:
выполняемые посредством одного или более отделений службы валидации
получение от сервера доступа имени, указанного в сертификате пользователя,
контроль действительности сертификата пользователя,
если сертификат пользователя является действительным, то либо отправка имени, указанного в сертификате пользователя, в отделение службы авторизации для преобразования в имя пользователя с передачей имени пользователя, возвращенного службой авторизации, серверу доступа, либо передача имени, указанного в сертификате пользователя, серверу доступа, если сертификат пользователя является не действительным, отказ пользователю в доступе к сервису;
выполняемые посредством одного или более отделений службы авторизации
получение от отделения службы валидации или от сервера доступа имени, указанного в сертификате пользователя,
отправка имени, указанного в сертификате пользователя, в базу данных,
получение имени пользователя и его профиля от базы данных,
передача идентификатора поименованного пользователя отделению службы валидации или серверу доступа,
получение от сервера доступа запроса о правах на доступ,
посылка в базу данных запроса на информацию о подписке,
получение от базы данных информации о подписке,
определение прав доступа на основе указанной информации о подписке,
передача прав доступа на сервер доступа;
выполняемые посредством одного или более ролевых отделений авторизации с ассоциированными базами данных
получение от отделения службы авторизации сертификата пользователя, обнаружение имени пользователя и его профиля в базе данных, отправка имени пользователя и его профиля отделению службы авторизации, получение запроса на информацию о подписке от отделения службы авторизации, отправка информации о подписке отделению службы авторизации.
13. Способ по п.12, отличающийся тем, что дополнительно включает следующие операции, осуществляемые, по меньшей мере, одним сервером доступа
получение запроса от пользователя,
аутентификация себя пользователю и запрашивание аутентификации от пользователя, выполнение последовательности вызов/ответ,
истребование сертификата и подтверждения обладания личным ключом от пользователя,
передача имени, указанного в сертификате, отделению службы валидации,
в случае если сертификат пользователя является действительным, получение идентификатора поименованного пользователя от отделения службы авторизации,
запрашивание отделения службы авторизации о правах доступа,
получение прав доступа от отделения службы авторизации,
обнаружение соответствующего сервисного меню,
представление сервисного меню пользователю и
передача информации между пользователем и сервис-провайдером.
