14 сентября 2012
Аутентификация как часть единого пространства доверия
А.Г. Сабанов
к.т.н.
ЗАО «Аладдин Р.Д.»
Приводится обзор зарубежной и российской нормативной базы по удаленной аутентификации и пространству доверия. Рассмотрены основные процессы удаленной аутентификации. Предложены уровни доверия аутентификации и модели построения пространства доверия аутентификации. Сформулировано понятие единого пространства доверия (ЕПД). Показана связь аутентификации с доверенными сервисами ЕПД.
Введение
Последовательное развертывание государственных программ «Электронное правительство» и «Информационное общество (2011- 2020)», основой функционирования которых является инфраструктура открытых ключей (PKI – Public Key Infrastructure), ставит ряд задач, связанных с созданием надежной системы удаленного взаимодействия пользователей и информационных ресурсов через открытые каналы связи с целью обеспечения юридически-значимого электронного документооборота, а также обеспечения трансграничных операций и услуг электронной коммерции с приемлемым уровнем рисков.
Решение этих задач невозможно без развития систем автоматической идентификации и аутентификации (ИА). Как показано в работе [1], средства аутентификации (подтверждения подлинности предъявленных пользователем идентификаторов) относятся к категории классических средств управления доступом и информационной безопасностью, как в корпоративных, так и в глобальных коммуникационных сетях. Согласно определению эти средства включают в себя подготовку, создание, изменение, удаление и аудит пользовательских учетных записей.
Говоря об аутентификации применительно к задачам доступа, общеупотребительным стал термин ААА (аутентификация, авторизация, администрирование), а иногда сюда добавляют четвертое А - аудит. Управление доступом и авторизацией пользователей прикладных систем, обрабатывающих конфиденциальную информацию (например, содержащую персональные данные), является одной из самых сложных задач даже для хорошо изученных корпоративных информационных систем (ИС) [2],[3].
Для территориально-распределенных ИС задача существенно усложняется, поскольку даже в случае наиболее часто встречающегося метода аутентификации - однократной (SSO - Single Sign On) – возникает непростой вопрос, как правильно выбрать способ синхронизации учетных записей пользователя в различных подсистемах. Чаще всего для этого вводятся либо централизованное управление учетными записями пользователей путем интеграции LDAP-каталогов в один мега-каталог, либо вводятся определенные правила синхронизации по мандатному или ролевому принципу. Отдельной, но тоже решаемой задачей при этом становится проблема интеграции средств аутентификации [4].
Однако при переходе к облачным вычислениям задача управления доступом существенно усложняется, причем огромное значение имеет тип облака.
Как известно, существует несколько типов «облаков», из которых, согласно [5] наиболее распространенными являются четыре.
- Частное (private cloud). Используется единственной организацией. Управляется как самой организацией, так и третьей стороной, может находиться в организации или за ее пределами.
- Облако сообщества (community cloud). Облачная инфраструктура, которая служит нескольким организациям с общими подходами (общие задачи, требования безопасности, политики, стандарты). Управляться она может как самими организациями, так и третьими сторонами. Местоположение инфраструктуры: как на территории сообщества, так и вне его.
- Публичное облако (public cloud). Общедоступная облачная инфраструктура (т.е. является информационной системой общего пользования, ИСОП), которая может быть доступна целой отрасли и принадлежать организации, предоставляющей облачные службы и сервисы на платной основе.
- Гибридное облако (hybrid cloud). Облачная инфраструктура, представляющая собой сочетание двух или более облаков (частного облака, облака сообщества и/ или общедоступного облака), которые сохраняют свою самобытность, но связанны общими технологиями, обеспечивающими переносимость данных и приложений.
Методология построения инфраструктур в рамках ранее названных программ на базе облачных вычислений предусматривает применение всех 4-х моделей. Заметим, что строящееся Ростелекомом федеральные облака по вышеуказанным ФЦП относятся к типу 3 с постепенным переходом на тип 4.
Кроме специфики облаков необходимо учитывать, что создаваемые федеральные ИС являются системами нового типа (согласно ст.2 п.13 №63-ФЗ «участниками электронного взаимодействия является неопределенный круг лиц и в использовании которых этим лицам не может быть отказано») и относятся к открытым информационным системам общего пользования (ИСОП).
И здесь задача управления доступом пользователей выходит на новый уровень [6]. В отличие от хорошо изученных корпоративных информационных систем в ИСОП владельцами прикладных сервисов в «облаке» являются разные юридические лица, не связанные между собой и с оператором облачных сервисов ни единой технической политикой, ни едиными подходами к настройкам сервисов безопасности. В данном случае такие известные приемы, как упомянутая выше интеграция LDAP-каталогов, не имеют смысла, поскольку число систем, предоставляющих сервисы, размещенных в облаках, может исчисляться десятками.
С другой стороны, пользователями облачных сервисов являются как физические, так и юридические лица. А в разных корпоративных системах последних уровень развития PKI, политики безопасности доступа и применения сервисов безопасности (например, электронной подписи) существенно отличаются друг от друга.
Следовательно, требуются новые подходы к организации систем управления доступом пользователей к различным ИС с разным уровнем конфиденциальности обрабатываемой (и хранимой) информации и облачным сервисам, в частности, для предоставления транс системного доступа.
Одним из способов решения данной задачи является введение уровней доверия к механизмам аутентификации пользователей, напрямую связанных с уровнем конфиденциальности регистрационных параметров пользователей. Тогда решение о предоставлении доступа пользователя к тому или иному сервису может приниматься исходя из соотношения уровней доверия аутентификации к уровню доверия (и защищенности) данного сервиса. Такой подход в сочетании с развитой системой PKI как базы данного решения позволяет также решить задачу передачи (трансляции) доверия и построить систему транс системного доступа. Изучению этого подхода посвящена данная работа.
Аутентификация
Основная цель удаленной аутентификации – установление отношений доверия в результате обмена сообщениями (Challenge-response), выполненного по безопасному протоколу с применением криптографических преобразований. Попробуем разобрать аутентификацию на элементарные процессы, из которых она состоит. Для этого сначала выделим участников процессов аутентификации:
- субъект доступа (называемый также аппликант, претендент, заявитель);
- центр регистрации (ЦР) – его основной задачей является установление и фиксация (закрепление) связи субъекта и его уникального секретного признака – аутентификатора. В качестве такого центра может выступать, например, удаленный центр регистрации удостоверяющего центра (УЦ), связанный доверительными отношениями с данным УЦ;
- доверяющая сторона – владелец ресурса, к которому претендует получить доступ субъект доступа. Владелец проверяет по протоколу аутентификации факт наличия у субъекта доступа соответствующего аутентификатора – секретной информации, или секрета, выданного субъекту центром регистрации;
- проверяющая сторона (центр валидации), входит в состав PKI, она проверяет наличие фиксированной ЦР-ом связи «субъект доступа – аутентификатор». Например, устанавливает, является ли ЭУ действительным (валидным) на момент проверки.
В основе аутентификации лежит три тесно взаимосвязанных процесса:
- Регистрация – установление (идентификация) личности и регистрация аутентификатора (секрета), а также издание связанного с ним электронного удостоверения (ЭУ), это процесс, который, по сути, является аналогом выдачи паспорта. В ходе регистрации обязательной процедурой является привязка зарегистрированного и изданного для данного субъекта ЭУ к его личности. По большому счету, главная цель ЭУ - связать секрет (аутентификатор) с личностью и предъявленными ею и проверенными идентификаторами или с новыми идентификаторами, которые выдает ЦР. Данная процедура подразделяется на несколько связанных между собой последовательных процессов и осуществляется в ЦР. В зависимости от уровня доверия ААА, процедура выполняется либо при личном присутствии пользователя, либо удаленно.
- Собственно аутентификация выполняется с помощью Протокола аутентификации – процедуры проверки факта владения претендентом секретом (аутентификатором). Ее аналогом может служить предъявление паспорта и сличение фотографии для идентификации личности. Эта процедура осуществляется доверяющей стороной, и имеет две модификации: с разделяемым и неразделяемым секретом. По степени защищенности процедура может быть реализована как устойчивой к атакам по каналу связи, так и неустойчивой.
Наиболее сложный вариант реализации, когда аутентификатор состоит из нескольких компонентов (факторов), и каждый из них проверяется по своему протоколу. Это - так называемая многофакторная аутентификация.
- Валидация (проверка действенности) – процедура проверки подлинности и периода действия ЭУ (аналог проверки действительности паспорта). Проверяется целостность, срок действия ЭУ, его наличие в списках отозванных и т.д. Осуществляется в центре валидации (ЦВ).
Каждый из этих процессов распадается на цепочки последовательно выполняемых взаимосвязанных процедур. Приведем такую цепочку для процесса регистрации:
- Субъект (аппликант) предъявляет в ЦР свои Credentials (ЭУ или бумажные действующие удостоверения личности, содержащие присвоенные ему идентификаторы. Примером идентификатора может быть номер паспорта, номер удостоверения, СНИЛС, ИНН,…).
- ЦР проверяет предъявленные бумажные или ЭУ на предмет совпадения принадлежности предъявленных документов данному субъекту и их действительности (валидация).
- На основании выполненной проверки ЦР создает учетную запись для данного субъекта в базе данных ЦР для доступа к информационным ресурсам (ресурсу).
- На основе записи для субъекта ЦР регистрирует/издает секрет (аутентификатор), ассоциированный с конкретным субъектом. Простейшим секретом может быть сформированный по тому или иному установленному алгоритму пароль, усиленным секретом -- одноразовый пароль. Самым строгим секретом является секретный ключ. Для данного секретного ключа на основе соответствующего открытого ключа формируется сертификат ключа подписи (ЭУ, называемое в западных документах Credentials), связывающий секретный ключ (аутентификатор) с его владельцем. В простейшем случае процесс издания Credentials сводится к регистрации пары логин-пароль. В самых сложных случаях для одного субъекта может быть издано несколько ЭУ (например, сертификаты ключа подписи, ключа шифрования, ключа логического доступа). Фактически ЭУ является своего рода «электронным паспортом», имеющим реквизиты издателя, время, место издания, срок действия, алгоритм формирования (издания), процедуру проверки (цепочку доверия) и т.д.
- Далее следует необязательная (иногда ее не требуется создавать) процедура делегирования прав доступа (фактически делегирование доверия к изданным аутентификатору и ЭУ) другой (или другим) ИС на основе доверительных отношений. При переходе к облачным вычислениям эта процедура становится весьма актуальной.
- Последним процессом регистрации является выдача изданных ЦР-ом аутентификатора и ЭУ на руки субъекту.
Краткий обзор зарубежного опыта
В развитых западных странах вопросам исследования аутентификации и выработки рекомендаций по использованию тех или иных средств удаленной аутентификации при взаимодействии пользователей с государственными информационными системами через открытые каналы связи уделяется большое внимание [5], [7]-[15], поскольку корректное решение данной задачи – есть основа управления доступом пользователей, применения электронной подписи и других сервисов безопасности. Наиболее общим подход заключается в разделении способов аутентификации на уровни, которые зависят от степени последствий при ошибках аутентификации и ненадлежащем использовании ЭУ.
В США разделение аутентификации на уровни доверия и, соответственно, уровни соответствующих гарантий (level of assurance) административно-бюджетный комитет администрации президента предложил еще в 2003г.[9] . Через год это требование было закреплено в виде обязательного к исполнению циркуляра президента, где требования разделения аутентификации на четыре уровня доверия (первый – самые легкие требования, четвертый – самые жесткие) были расширены не только на госслужащих, но и на сотрудников контрагентов [10]. На основе этих документов Национальный институт стандартов и технологий (НИСТ) разработал технические требования к процессам регистрации, подтверждению подлинности идентификаторов, аутентификаторам и протоколам аутентификации в зависимости от уровней доверия аутентификации, дополнив исследование рассмотрением основных угроз и методов их парирования [5]. Ценность данной работы состоит в системном подходе к решению задачи и формулировании конкретных требований к основным процессам аутентификации и их взаимосвязи с доверенными сервисами PKI.
В частности, запись фактов регистрации пользователей и отзывов их полномочий для уровней 2 и 3 должны храниться 7,5 лет со дня истечения срока действия, а для уровня 4 – 10,5 лет. Доверяющие стороны принимают подтверждения при условии, что они снабжены цифровой подписью доверенной стороны (например, проверяющей) или получены напрямую от доверенной стороны, при этом для второго уровня доверия срок действия подтверждений не должен превышать 12 часов, для третьего – уже 2часов. При отзыве сертификатов ключей подписи, называемых электронными удостоверениями (ЭУ), отозванный сертификат для второго уровня должен появиться в списке отозванных не позднее 72 часов, а для третьего и четвертого уровня доверия аутентификации - не позднее 24 часов. Без жесткого выполнения таких конкретных требований доверенный сервис перестает быть доверенным. Например, при проверке валидности ЭУ проверяющая сторона должна убедиться в том, что данный сертификат ключа подписи выдан не ранее 24 часов назад и является действительным.
На базе этих разработок НИСТ в 2006г. выпустил стандарт проверки идентификации [12] для сотрудников государственных органов и работающих с ведомствами по контрактам, где конкретизированы требования по применению интеллектуальных смарт-карт, в которых криптографические ключевые пары генерируются внутри чипа (так называемые устройства SSCD - Secure Signature Creation Device). В проекте новой версии этого стандарта, опубликованном в марте 2011г., уже обязательно вводятся ассиметричные ключевые пары для аутентификации, опционально добавлена возможность использования смарт-карт с поддержкой биометрии «на борту» и продлен максимальный срок жизни карты с 5 до 6 лет, причем уже не в рекомендательном, а в обязательном порядке.
Параллельно с США аналогичная нормативная база по аутентификации развивалась и в других странах. Так, в документе «Руководство по электронной аутентификации» [13], принятом международной организацией экономического сотрудничества и развития (ODCE), государствам и международным организациям при организации управления рисками в ходе электронного взаимодействия предлагается применять три уровня гарантий и доверия аутентификации: базовый, средний и высокий. Базовый уровень предлагает однофакторную аутентификацию (пара логин/пароль), при этом доставку логина и пароля рекомендуется производить с использованием разных каналов (например, он-лайн и по электронной почте). На среднем уровне -- использовать двухфакторную аутентификацию (в качестве фактора могут применяться аппаратные устройства с протоколами защищенного обмена, программные PKI-сертификаты, SMS по мобильному телефону), но рекомендуемым условием при этом является строгое соблюдение регламента при регистрации, издании и доставке секретных данных (аутентификаторов) по двум независимым каналам. Высокий уровень требует обязательной личной явки пользователя на процедуру регистрации, тщательной проверки предъявленных удостоверений личности, выпуска PKI-сертификатов на смарт-карте или USB-токене. Заметим, что требование использования SSCD-устройств для трансграничных операций появилось в Европе в 2003г. [8].
Подходы к уровням доверия аутентификации США и ОЭСР отличаются тем, что в США на самом низком (первом) уровне требований пользователю не нужны какая-либо аутентификация (так называемые No Name – пользователи). Предоставление доступа к информационным ресурсам таким пользователям аналогично поездке на транспорте или проходу на сеанс в кинотеатр: купил билет – пользуйся. В РФ такой уровень потребуется только в случае предоставления платных услуг, не требующих идентификации и аутентификации.
Уровни доверия аутентификации
На основе зарубежного опыта автор предлагает ввести простую и понятную трехуровневую модель доверия (и, соответственно, строгости) аутентификации. Такая модель наиболее полно согласуется с текущим состоянием нормативной базы РФ как в части оценки состояния защищенности ИС, обрабатывающих информацию ограниченного доступа, не содержащую гостайну, так и в части законодательства по защите персональных данных и введения трех видов электронной подписи.
Данная модель согласуется также с основными положениями №149-ФЗ, где сказано, что участниками электронного взаимодействия и обладателями информации могут являться 3 уровня пользователей: граждане (физические лица), организации (юридические лица), государство (государственные органы и органы местного самоуправления). Деление на три большие группы приемлемо как с точки зрения грубой оценки рисков (низкий, средний, высокий), так и для оценки надежности, а также последствий от ошибок ИА и атак (уровни: низкий, средний, высокий).
В сложившейся за период с 2002г. практике применения аутентификаторов (токенов) массово используются всего 3 типа аутентификации: многоразовый пароль, технология одноразовых паролей ОТР (One Time Password) и технология, основанная на применении PKI и цифровых сертификатов (например, строгая двухфакторная аутентификация с применением смарт-карт, содержащих не извлекаемый ключ электронной подписи, применение которого невозможно без ввода PIN-кода, т.е. по сути, технология электронной подписи.
Таким образом, основываясь на приведенных рассуждениях и исследованиях, результаты которых изложены в работе [6], можно выделить три уровня строгости (достоверности) аутентификации:
Уровень 1. Разрешенным токеном при удаленной аутентификации является многоразовый пароль. Аутентификация признается успешной при доказательстве владения токеном по одному из безопасных протоколов аутентификации, подробно рассмотренных в [3]. Пароль не должен в открытом виде передаваться по сети. Желательно соблюдать требования по длине пароля (не менее 6 символов). Разрешается использовать простую электронную подпись. Нет требований по надежности ИА. Основными обладателями информационных ресурсов на этом уровне предполагаются граждане, которые сами определяют риски проникновения на их ресурсы мошенников или принимают риски, предложенные им владельцами ИС, предоставляющих услуги. Безусловно, приветствуется использование на этом уровне аутентификаторов и ЭУ с уровней 2 и 3.
Уровень 2. Рекомендуется применение технологии ОТР с использованием криптографических алгоритмов или двухфакторной аутентификации (смарт-карта плюс PIN-код). При этом издавать ЭУ разрешено не только аккредитованным УЦ. Передача прав доверия третьим сторонам производится на основе двухсторонних соглашений (договоров) или на основе кросс-сертификации. Приветствуется использование технологий уровня 3. Основными обладателями информационных ресурсов могут быть организации с развитой инфраструктурой открытых ключей. Для взаимодействия с государственными органами рекомендуется применение аутентификации уровня 3 и криптоалгоритмов ГОСТ 34.10-2001 и ГОСТ 34.11-2001.
Уровень 3. Рекомендуется использование только строгой, как минимум, двухфакторной взаимной (информационный ресурс - претендент) аутентификации с применением аутентификаторов с неизвлекаемым ключом электронной подписи (устройства класса SSCD). Это позволяет обеспечить надежную защиту ключа подписи от компрометации. Согласно исследованию [16] биометрия может использоваться как дополнительный (но не основной) фактор аутентификации. Особое внимание следует уделять строгости процесса регистрации заявителей, изданию ЭУ и передаче прав доверительным сторонам. Рекомендуется использование только российских криптографических алгоритмов при издании ЭУ для электронной подписи и шифрования. При этом УЦ, издающий ЭУ, должен быть аккредитован в Минкомсвязи РФ.
Соответственно для предложенных трех уровней строгости аутентификации в дополнение к таблицам работы [6] можно привести соответствующие аутентификаторы, лежащие в основе системы аутентификации (табл.1).
Таблица 1 Типы аутентификаторов, которые можно использовать на различных уровнях доверия
Тип аутентификатора |
Уровень 1 |
Уровень 2 |
Уровень 3 |
Аппаратный криптографический аутентификатор с неизвлекаемым ключом |
v |
v |
v |
Устройство одноразовых паролей |
v |
v |
|
Программный криптографический аутентификатор |
v |
v |
|
Пароли и PIN-коды |
v |
|
|
Модели доверия аутентификации
Чтобы понять, как может быть построено пространство доверия ААА, и как может осуществляться процесс трансляции доверия, рассмотрим простейшие модели доверия на примере управления доступом пользователей.
Обозначим понятием «Субъект» взаимодействующую сторону. Это может быть собственно субъект, информационный ресурс и т.д.
Для того, чтобы у субъекта 2 появилось доверие к субъекту 1 (и между ними установились доверительные отношения) субъект 1 должен предъявить свой аутентификатор (Aut), а субъект 2 должен проверить этот аутентификатор с помощью некоего механизма проверки, который назовем валидатором (Val).
Для установления доверительных отношений между субъектами необходимо, чтобы у обоих было доверие к валидатору, а проверка прошла успешно.
Рис.1 Простейшая модель доверия субъекта 2 к субъекту 1
Если субъектов, имеющих аутентификаторы, и доверяющих конкретному валидатору, набирается некоторое количество, так образуется система доверия (рис.2).
Рис. 2 Простейшая система доверия ААА
Если валидатор один, но ему доверяют не только субъекты-претенденты (Суб.1-Суб3), но и информационные ресурсы, на которые эти субъекты хотят получить доступ, это называется доменом доверия (рис.3).
Рис.3 Домен доверия ААА
В случае образования в информационной системе двух доменов доверия, связанных трастовыми отношениями между собой, получаем пространство доверия (рис.4).
Рис.4 Простейшее пространство доверия ААА
Масштабирование пространства доверия может происходить разными способами (рис.5). Достоинства и недостатки есть у каждой модели масштабирования.
Так, распределенная модель (рис.5а) отличается повышенной устойчивостью. В случае компрометации одного домена доверия остальные домены доверия будут работать в штатном режиме. Однако если число доменов доверия исчисляется не единицами, а десятками, установление и поддержание доверительных отношений между всеми доменами легче проводить по мостовой схеме (рис.5б), где «мост» выполняет функции доверенной третьей стороны (ДТС). Однако ДТС не должен передавать функции управления для доменов, а является лишь «консолидатором» и «транслятором» доверия. С точки зрения управления наиболее привлекательна плоская схема (рис5в), в то же время в случае компрометации одного валидатора система прекратит работу до его восстановления.
Рис.5а Масштабирование. Сетевая модель
Рис.5б Масштабирование. Мостовая модель
Рис.5в Масштабирование. Плоская (централизованная) модель
Приведенные модели относятся, прежде всего, к пространству доверия аутентификации. Попробуем рассмотреть, что такое единое пространство доверия, и как сервис аутентификации связан с другими доверенными сервисами.
Единое пространство доверия
Часто употребляемое в последнее десятилетие понятие «единое пространство доверия» (ЕПД) до сих пор не имеет ни законодательного определения, ни регуляторного оформления. Доверие со стороны кого и кому, почему единое? Документально в приказе ФНС РФ [17] закреплено понятие «единое пространство доверия сертификатам ключей подписи». Согласно этому документу, «Единое пространство доверия – структура, определяющая организационные границы, в пределах которых находятся только заслуживающие доверия удостоверяющие центры, а сертификаты ключей подписей, изготовленные ими, признаются всеми участниками информационного взаимодействия в границах структуры и на равных условиях». Данное определение при взгляде не «изнутри», а снаружи вызывает много вопросов. Что за структура, как определяются организационные границы, как удостоверяющие центры могут стать «заслуживающими доверия»?
Можно попытаться сформулировать определение ЕПД с точки зрения целей его создания. ЕПД должна выполнять функции не только проверки и признания сертификатов ключей подписи, но и выполнения множества других доверенных операций (валидация, штампы времени и т.д.). Покажем это на простом примере. В настоящее время у всех аккредитованных и не аккредитованных в Минкомсвязи УЦ ставятся штампы времени, но время это не синхронизировано. В итоге, в некоторых случаях в одну и ту же секунду по часам одного УЦ сертификат (ЭУ) был действителен, по часам другого – нет. Следовательно, необходимо создать единую службу доверенного времени, при этом установить регламент периодической проверки часов всех УЦ на синхронность. Такие же примеры можно привести по сервисам реализации проверки подлинности электронной подписи (ЭП), реализации политик безопасности, службы каталогов сертификатов (в нее входят реестры сертификатов, реестры отозванных сертификатов, реестр состояния сертификата по сети --OCSP), службы атрибутирования (для часто изменяемых атрибутов пользователей), службы архивирования электронных документов (временного или постоянного хранения) и т.д. Эти службы связывает одно: все они развернуты или разворачиваются в удостоверяющих центрах и работают на базе PKI. Все основные процессы аутентификации для них полностью основаны на использовании доверенных сервисов: проверка валидности ЭУ, создание и проверка реестров, издание ЭУ, делегирование прав доступа,…Собственно сам процесс аутентификации с помощью протокола обмена по определению должен быть доверенным сервисом.
На основе приведенных данных попробуем сформулировать определение.
ЕПД - совокупность взаимосвязанных доверенных сервисов, развернутых на базе инфраструктуры открытых ключей.
Это определение кратко и емко отражает суть единого пространства доверия.
Под доверенными сервисами будем понимать электронные сервисы, участвующие в создании, валидации, обработке, хранении электронных подписей, электронных печатей, штампов времени, электронных документов, средств доставки электронных сообщений, аутентификации на Web-сайтах, электронных сертификатов и т.д.
Доверенные сервисы могут иметь разное назначение, уровни доверия и разную «направленность» (например, горизонтальную и вертикальную) в зависимости от модели построения ЕПД. Имеет смысл также говорить о ЕПД (в таком определении) в масштабах государства.
Для развития ЕПД в масштабах страны известны 3 модели: сетевая, браузерная и иерархическая. В РФ с июня 2012г. согласно приказам [18], [19] в Минкомсвязи должна производиться аккредитация удостоверяющих центров по иерархической модели. Эта модель предусматривает широкие возможности для регулирования. Однако при этом никаких технических требований к сервисам безопасности, кроме перечисленных в №63-ФЗ и Приказах Минкомсвязи [18], [19], касающихся квалифицированных сертификатов ключей проверки электронных подписей, в правилах аккредитации не содержится. В приказе ФСБ России № 796 от 27 декабря 2011г., правда, есть некоторые статьи, касающиеся аутентификации (ст.9.3, 9.5, 23). Так, начиная с УЦ класса КС2 и выше имеется требование о том, что «регистрация владельца сертификата ключа проверки ЭП (внесение в реестр пользователе средств УЦ) осуществляется только при предъявлении им документов, удостоверяющих личность» (п.23.4). В то же время ничего не сказано о том, должен ли владелец сертификата предъявлять документы лично или это можно сделать в удаленном режиме. Для того же УЦ класса КС2 «для всех пользователей средств УЦ допускается использование механизмов удаленной аутентификации. Специальные характеристики механизмов удаленной аутентификации должны быть подтверждены в рамках проведения проверки соответствия средств УЦ и объектов информатизации, использующих данные средства, настоящим требованиям» (там же).
Первым отдельным нормативным документом, посвященным вопросам построения систем аутентификации в РФ, является Постановление Правительства №977 [20]. Сама ЕСИА и выпущенные в мае 2012г. «Методические рекомендации по использованию Единой системы идентификации и аутентификации»[21], а также Положение [22], утвержденные Минкомсвязи в виде приказа от 13.04.2012г. №107 [23], явно нуждаются в доработке в части развития доверенных сервисов и особенно сервиса аутентификации. Предложенная в методических рекомендациях модель уровней доверия (в тексте «уровней достоверности аутентификации») является урезанной копией американского подхода [NIST]. Видимо, сжатые сроки ввода ЕСИА в эксплуатацию не позволили более тщательно разработать как саму систему, так и сопутствующие документы. Об этом и о понимании сложности создания таких масштабных систем говорится в весьма квалифицированной статье И.Трифаленкова [24].
В то же время в мире и, особенно, в Европе регулирование в области формирования доверенного пространства существенно опережает нормативную базу РФ. В Европейских регуляторных документах уже несколько лет нормативно вводится понятие Trusted УЦ – доверенный УЦ. Введена система аудита УЦ на состояние «доверенности» с ежегодными инспекционными проверками. В развитых европейских странах нет такого большого количества УЦ, как в РФ, но они оказывают доверенные услуги высокого качества, в том числе многие – услуги ДТС. А присутствие ДТС необходимо как для внутренних нужд экономики, так и для проведения трансграничных транзакций. В отличие от УЦ в рекомендациях Х.842 к ДТС описаны все доверенные сервисы (14 штук), включая сервис аутентификации. Хотя в последние 3 года появилась тенденция не выделять отдельно сервис аутентификации, а говорить о качестве электронной идентификации, в состав которой аутентификация входит как составная часть.
Например, в документе [25], разработанном специалистами Германии, Италии, Франции и Греции, для оценки качества электронной идентификации предлагаются 2 параметра. В качестве первого параметра приведена семиуровневая классификация качества политик электронной подписи, причем начиная с четвертого уровня для генерации ключевого материала требуется применение SSCD – устройств. Вторым параметром является восьмиуровневая шкала оценки независимого уровень гарантий, связанный с качеством регистрации клиентов.
В проекте европейской комиссии по регулированию по электронной идентификации и доверенным сервисам электронных транзакций на внутренних рынках [26] дано определение доверенного УЦ и квалифицированного доверенного УЦ, который должен проходить регулярный аудит на степень «доверенности». Доверенным удостоверяющим центром называется тот УЦ, у которого развернута хотя бы одна доверенная функция. Например, все УЦ, прошедшие аккредитацию в Минкомсвязи на корректность проверки СКП, могут считаться доверенными как по российской, так и по европейской шкале.
Для построения ЕПД на доверенном УЦ, кроме хорошо нормативно проработанных функций, связанных с проверкой СКП, требуется осуществлять дополнительные регламентированные процедуры. Например, связанные с регистрацией пользователей, синхронизацией времени с эталоном и проставлением квалифицированных штампов времени, проверкой актуальности реестров идентификаторов, валидности СКП и т.д. Тогда в терминах западных нормативных источников, в частности [26], этот УЦ может стать квалифицированным доверенным УЦ.
Заключение
В работе выполнен краткий обзор нормативной базы, касающейся вопросов аутентификации и единого пространства доверия. На основе выполненного обзора показано, что нормативная база РФ нуждается в совершенствовании в части вопросов аутентификации и доверенных сервисов.
Рассмотрены вопросы построения доверенных сервисов аутентификации, предложены модели доверия ААА. Сформулировано понятие единого пространства доверия (ЕПД). Показана связь аутентификации с доверенными сервисами ЕПД.
Рассмотренный подход к построению доверенных сервисов аутентификации как составной части ЕПД позволит построить систему управления доступом к прикладным системам и электронным сервисам при переходе к облачным вычислениям, в том числе, при транс системном доступе. Однако для практического построения таких систем необходима прежде всего нормативно-правовая, а также организационная и техническая поддержка.
Литература
- А. Сабруков, А.Грушо. «Аутентификация в компьютерных системах». Системы безопасности, №5 (53), 2003г.
- Шаньгин В.Ф. Комплексная защита информации в корпоративных системах: учеб. пособие / В.Ф. Шаньгин. – М.:ИД «ФОРУМ»: ИНФРА-М, 2010.-592с.:ил.
- Аутентификация. Теория и практика обеспечения безопасного доступа к информационным ресурсам. Учебное пособие для вузов / А.А. Афанасьев, Л.Т.Веденьев, А.А. Воронцов и др.;. Под ред. А.А. Шелупанова, С.Л. Груздева, Ю.С. Нахаева. М.: Горячая линия-Телеком, 2009. - 552с.: ил.
- Сабанов А.Г. Об интеграции средств аутентификации. Журнал «Connect! Мир связи» №9, сентябрь 2010г., стр.101-103 (первая часть), №10, стр.113-115.
- NIST Special Publication 800-63 April 2006. http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
- Сабанов А.Г. Аутентификация при электронном обмене документами /А.Г. Сабанов// Доклады Томского государственного университета систем управления и радиоэлектроники, 2011г., №2(24), С.263-266
- Declaration on Authentication for Electronic Commerce 7-9 October 1998. http://www.oecd.org/dataoecd/32/45/38921342.pdf
- CWA 14365 Guide of use of Electronic Signature. Jan.2003. http://www.standards.ru/print.aspx?control=27&id=3946978&print=yes
- OMB Memorandum M-04-04 E-Authentication Guidance for Federal Agencies December 16, 2003 & OMB Circular A-130 2003
- Homeland Security Presidential Directive 12 (HSPD-12) Policy for a Common Identification Standard for Federal Employees and Contractors. August 27, 2004
- ISO/IEC 10181-2, ITU-T Rec/x.811 Теоретические основы аутентификации. 2004
- FIPS PUB 201-1 Personal Identity Verification (PIV) of Federal Employees and Contractors. March 2006, FIPS PUB 201-2. March 2011
- OECD Recommendation on Electronic Authentication/2007. http://www.oecd.org/dataoecd/32/45/38921342.pdf
- ETSI draft SR 000 000 v0.0.2 Rationalised Framework for Electronic Signature Standardization August 2011 & ETSI TS 1, 103173,…
- National e-Authentication Framework/ January 2009. https://www.eid-stork.eu/dmdocuments/public/NeAF-framework.pdf
- Сабанов А.Г. «Обзор технологий идентификации и аутентификации» Журнал «Документальная электросвязь» №17, 2006г., с.23-27.
- Приказ ФНС РФ от 17.12.2008 N ММ-3-6/665@. Об утверждении Порядка ведения единого пространства доверия сертификатам ключей ЭЦП. bestpravo.ru›federalnoje/dg-pravila/y0k.htm
- Приказ Министерства связи и массовых коммуникаций Российской Федерации от 05.10.2011 г. № 250 «Об утверждении Порядка формирования и ведения реестров квалифицированных сертификатов ключей проверки электронной подписи, а также предоставления информации из таких реестров» (зарегистрирован в Министерстве юстиции Российской Федерации 28 ноября 2011 г., регистрационный № 22406). http://minsvyaz.ru/ru/doc/?id_4=777
- Приказ Минкомсвязи №108 от 13 апреля 2012г. Об обеспечении осуществления Министерством связи и массовых коммуникаций Российской Федерации функции головного удостоверяющего центра в отношении аккредитованных удостоверяющих центров. http://minsvyaz.ru/ru/doc/?id_4=777
- Постановление Правительства РФ от 28 ноября 2011г. №977 "О федеральной государственной информационной системе "Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме». http://base.consultant.ru/cons/cgi/online.cgi?req=doc&base=LAW&n=122455
- Методические рекомендации по использованию Единой системы идентификации и аутентификации. http://minsvyaz.ru/ru/doc/index.php?id_4=783
- Положение http://minsvyaz.ru/common/upload/Polozhenie_107.pdf
- Приказ Минкомсвязи от 13 апреля 2012г. «Об утверждении Положения о федеральной государственной информационной системе Единая система идентификации и аутентификации». http://minsvyaz.ru/ru/doc/?id_4=776
- Трифаленков И. «Электронная подпись в инфраструктуре электронного правительства». http://www.ib-bank.ru/bis/p/109
- PEPPOL. Deliverable D1.3 Demonstrator and functional Specifications for Cross-Border Use of e-Signature in Public Procurement. Part 7: eID and Signature Qualify Classification, revision 1.3.
- European Commission. Proposal for a Regulation of the European Parliament and of the Council on Electronic Identification and Trust Services for Electronic Transactions in the Internal Market. Brussels, XXX COM (2012) 238/2.
