Какие модели архитектуры удостоверяющих центров применяются на практике

Инфраструктура открытых ключей в Windows Server 2016. Часть 1. Предварительный этап

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

Как бы там ни было, задача внедрения и поддержания собственных инфраструктур осталась, а раз так, то стоит разобраться с особенностями ее внедрения. Впрочем, прежде чем говорить о внедрении, имеет смысл обсудить вопросы правильного использования и проектирования. Журнал не раз затрагивал эту тему в своих публикациях, поэтому мы можем просто сослаться на ранее опубликованную статью, которая поможет читателю ознакомиться с этой темой [1]. Великолепным источником является руководство Брайана Комара [3], которое поможет получить глубокие знания предмета.

Кроме того, разумно ознакомиться и с первоисточником, если мы говорим о внедрении решения на основе PKI Microsoft, так как разработчик предлагает полное руководство по проектированию [2].

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

Типовой сценарий

Пусть у нас есть организация, имеющая два основных центра обработки данных и несколько филиалов. Современные тенденции ведения бизнеса предполагают наличие не только стационарных пользователей, но и мобильных. Многие сотрудники компании применяют в своей работе не только обычные рабочие места, но и мобильные устройства. Предполагается необходимость взаимодействия с партнерами и заказчиками, с предоставлением им доступа к некоторым ресурсам компании. Служба каталога предприятия традиционно использует службу каталога на основе Microsoft Active Directory Domain Services. Структурная схема типового ЦОД предприятия может выглядеть так, как это показано на рис. 1. Конечно, говоря о центре обработки данных, мы делаем некоторое преувеличение, скорее здесь мы можем говорить о штаб-квартире и крупных филиалах. Поддержка собственного дата-центра в настоящем понимании этого термина оказывается под силу далеко не всем, но в некотором приближении будем считать, что говорим о ЦОД.

Внедрение корпоративной PKI обусловлено ростом потребности в обеспечении безопасности внутри предприятия. Подобное краткое описание нередко оказывается типовой историей для многих компаний. Так как же внедрить PKI для такой организации?

Как я уже упоминал выше, с проектированием решения можно познакомиться в статьях [1] и [2]. Обычно в подобной ситуации мы будем говорить о двухуровневой иерархии, состоящей из корневого отключенного от сети центра сертификации (Stand-Alone Root CA) и подчиненного издающего корпоративного центра сертификации. Не исключено, а скорее всего обязательно будет присутствовать потребность в использовании и публичных удостоверяющих центров, например, для обеспечения возможности работы внешних клиентов компании.

Разумеется, возможны и другие варианты, которые мы обсудим в этом цикле статей, но в качестве, скажем так, типового и наиболее часто встречающегося имеет смысл рассматривать именно этот. Более сложные иерархии с использованием дополнительных уровней иерархии с использованием промежуточных серверов политик Policy CA встречаются только для крупных компаний, где требования к политикам сертификатов могут варьироваться, что и приводит к усложнению структуры. Таким образом, типовая структурная схема может выглядеть так, как это показано на рис. 2.

Предварительный этап

Этап подготовки развертывания, с точки зрения практических аспектов, будет состоять из настройки точек распространения (Distribution Point), добавления дополнительной записи на сервере DNS и подготовки файлов capolicy.inf, определяющих начальную настройку и параметры работы серверов сертификатов. Наиболее часто используемыми точками распространения являются HTTP и LDAP. Первый вариант обусловлен его универсальностью для любого типа клиента, второй – удобством поиска и доступа для типового клиента Active Directory. Соответственно, администратор сталкивается с задачами:

настройки места хранения файлов сертификатов, списка отзыва и заявления поставщика, прав доступа на этот или эти ресурсы;
установки и настройки сервера веб для выполнения роли Distribution Point для PKI;
добавления специальной записи на корпоративном DNS-сервере, которая обеспечит поиск необходимых ресурсов;
обеспечения отказоустойчивости и доступности как самих издающих серверов сертификатов, так и точек распространения, причем, говоря о них, не следует забывать о необходимости своевременной синхронизации данных между веб-серверами, выполняющими эту роль. Например, публикация нового CRL-файла означает необходимость предоставления доступа к нему с помощью любого сервера веб-фермы, выполняющего роль Distribution Point, но к этому мы еще вернемся несколько позже.

Администратору необходимо создать каталог для хранения вышеуказанных файлов и предоставить к нему доступ требуемым группам пользователей, то есть если предполагается «внутреннее» использование, то выбираются соответствующие группы, обычно речь идет о группе Users, поскольку, как правило, работают с сертификатами все пользователи компании, если же мы говорим о необходимости работы внешних пользователей, то придется использовать группу everyone.

Кроме того, встроенной группе Cert Publishers [4] необходимо предоставить права для изменений внутри этой папки. Это требуется для правильного подхода при построении строгой ролевой модели.

На веб-сервере создается виртуальный каталог, указывающий на соответствующий ресурс в хранилище. Необходимо удостовериться в том, что активна опция Directory Browsing (см. рис. 3), и если предусматривается использование разностных списков отзыва (Delta CRL), которые в имени файлов используют символ «+», то потребуется обеспечить так называемый Double Escaping, что также подразумевает дополнительную настройку на веб-сервере (см. рис. 4).

Методы повышения стойкости удостоверяющих центров к раскрытию секретных ключей Текст научной статьи по специальности «Компьютерные и информационные науки»

Текст научной работы на тему «Методы повышения стойкости удостоверяющих центров к раскрытию секретных ключей»

Россия, г. Москва, МИФИ

МЕТОДЫ ПОВЫШЕНИЯ СТОЙКОСТИ УДОСТОВЕРЯЮЩИХ ЦЕНТРОВ К РАСКРЫТИЮ СЕКРЕТНЫХ КЛЮЧЕЙ

В настоящее время актуальным является вопрос защиты секретных ключей удостоверяющих центров (УЦ) — ядра инфраструктуры открытых ключей (ИОК). Известны различные методы обеспечения секретности ключей, в число которых входят аппаратные, программные, административные, а также схемы разделения секрета. Программный метод защиты секретного ключа, как наиболее дешевый и легко реализуемый, заключается в хранении ключа в зашифрованном виде на обычном носителе (дискета, жесткий диск и т.п.). Из плюсов данного метода можно отметить его дешевизну, а также возможность резервного копирования для последующего восстановления утерянного ключа. Очевидным минусом описываемого способа хранения ключей является то, что при всех операциях с ключом, выполняемых программно, последний находится в памяти в открытом виде и может стать доступным злоумышленнику. В качестве аппаратных методов широко применяются аппаратные модули защиты — Host Security Module (HSM), в задачи которых входит генерация секретного ключа, его хранение и использование (например, для формирования ЭЦП). Особенностью описанных аппаратных модулей является то, что все операции с секретным ключом происходят исключительно внутри модуля, а при попытке вскрыть (физически) модуль хранящийся в нем ключ уничтожается. Т.о. секретный ключ никогда не появляется «снаружи» модуля. Еще одним вариантом хранилища секретного ключа может являться смарт-карта. Здесь, так же как и в случае с HSM, все операции с ключом происходят внутри карты. Из достоинств можно отметить то, что секретный ключ никогда не покидает устройства его хранения и обработки. Еще один плюс — значительно большая скорость криптографических преобразований по сравнению с программными методами, использующими универсальный процессор. Недостаток же заключается в следующем: для доступа к ключу необходимо «всего лишь» подобрать (или получить) код (для смарт-карты он может составлять четыре десятичных цифры). Существуют криптографические сопроцессоры, позволяющие хранить в защищенном от взлома регистре процессора так называемые мастер-ключи, используемые для зашифрования ключей пользователей и ключей УЦ. Преимуществом такого подхода является то, что зашифрование ключей происходит в хранилище процессора (или в дополнительном хранилище). Однако у этого способа хранения мастер-ключа имеется существенный недостаток — при аппаратном сбое по какой-либо причине мастер-ключ оказывается потерянным навсегда, так же как и зашифрованные на нем ключи.

Одним из вариантов применения административных мер является отключение головного УЦ (УЦ верхнего уровня) как наиболее критичного компонента системы от сети (инфраструктуры) на время простоя, что уменьшает вероятность его компрометации. Подчиненные УЦ не отключаются от сети в менее защищенных, но более функциональных средах. Еще более жестким ограничением может быть автономная работа УЦ без физической связи с инфраструктурой. Недостатком рассмотренных мер является невозможность функционирования УЦ в режиме реального времени (например, автоматическая обработка запросов на отзыв сертификата). С точки зрения защиты секретного ключа от компрометации интерес представляет метод, основанный на схеме разделения секрета. Так, секретный ключ УЦ «разбивается» на несколько частей, которые помещаются на территори-

ально разнесенные средства обработки (например, программно-аппаратный комплекс другого УЦ). Такая схема называется (/, п)-пороговой схемой разделения секрета, где п — количество участников, среди которых распределяются части ключа; t — количество участников, которые смогут восстановить секретный ключ, «объединив» свои части по определенному алгоритму. Таким образом, противник, даже получив (скомпрометировав) несколько частей, составляющих секретный ключ (но в количестве, меньшем порогового числа), не сможет корректно восстановить ключ УЦ, причем здесь обеспечивается совершенная секретность в смысле теоретико-информационной стойкости. Еще более усложнить задачу противника по восстановлению секретного ключа из составляющих его частей можно путем периодической смены уравнения (в случае схемы разделения секрета Шамира), по которому вычисляются части ключа и восстанавливается секретный ключ. При этом сам секретный ключ не изменяется, а части ключа, полученные по различным уравнениям, никак не связаны между собой. Вследствие этого противнику для корректного восстановления секретного ключа необходимо скомпрометировать не менее t частей, полученных по одному уравнению. Таким образом, оцениваемый период смены упомянутого уравнения должен быть менее оцениваемого времени, необходимого противнику для компрометации t частей ключа. Еще одним плюсом данного метода (помимо упоминавшейся совершенной секретности) является повышенная стойкость к злоумышленным действиям со стороны законных участников схемы, так как для восстановления секретного ключа необходимо объединиться не менее чем t участникам. Из недостатков метода можно выделить необходимость в некоторых схемах наличия секретного аутентичного канала для распределения частей общего секрета.

Э.Ф. Зорин, А.В. Федченко

Россия, г. Юбилейный, Московской обл., 4 ЦНИИ МО РФ

МАТЕМАТИЧЕСКАЯ МОДЕЛЬ КОНТРОЛЯ НАКОПЛЕНИЯ ИНФОРМАЦИИ В БАЗЕ ДАННЫХ ТЕЛЕКОММУНИКАЦИОННЫХ СИСТЕМ

Одним из основных элементов информационно-телекоммуникационных систем являются их базы данных. При этом процесс накопления информации в базе данных может быть представлен следующим образом. В каждый момент времени в базу данных коммуникационной системы поступают данные, интенсивность поступления которых равна 1(1). В то же время в каждый последующий момент времени данные из базы данных могут изыматься с интенсивностью р($. Будем полагать также, что как входной поток информационных данных, так и поток изъятия данных из базы данных в канале являются пуассоновскими. Таким образом, процесс, протекающий в информационно-телекоммуникационной системе, является марковским с непрерывным временем и дискретными состояниями. Множество этих состояний (х0, хь х2, х„) ставится в однозначное соответствие с рядом целых неотрицательных чисел (0, 1, 2, п), характеризующих количество данных, накопленных в базе. Введенные допущения на практике приводят к относительно небольшим погрешностям (~ 15%), что соизмеримо с точностью данных, закладываемых в модель.

Для любого состояния этого процесса (за исключением граничных точек х0 и хп), соседними могут быть только те, индексы которых отличаются от индекса рассматриваемого состояния на величину ± 1.

Об архитектуре системы удостоверяющих центров и типах сертификатов

Продолжая обсуждение темы о развитии систем PKI (Public Key Infrastructure) в нашей стране (см. PC Week/RE, N 44/2003, с. 28), остановимся еще на двух моментах — архитектуре системы удостоверяющих центров (УЦ) в России и типах выпускаемых ими сертификатов. Целесообразно обсудить эти темы именно сейчас, когда готовятся положения по лицензированию деятельности УЦ, сертификации, требованиям к безопасности и другие важные документы, призванные регулировать данную сферу деятельности. Ясность в этих вопросах позволит каждому действующему УЦ определить свое назначение и место в общей архитектуре и понять предъявляемые к нему требования.

Основной задачей создания системы УЦ будем считать построение юридически значимого пространства информационного обмена в существующей системе межсубъектных отношений. Таковыми субъектами являются: государство (в том числе органы муниципальной власти), юридические и физические лица, взаимодействующие между собой по схемам: 1) государственная структура — государственная структура; 2) государственная структура — юридическое лицо; 3) государственная структура — физическое лицо; 4) юридическое лицо — юридическое лицо; 5) юридическое лицо — физическое лицо; 6) физическое лицо — физическое лицо.

Модель структуры УЦ России

В качестве примеров взаимодействия можно привести системы административного и бухгалтерского документооборота (схемы 1, 2, 4), финансового документооборота (1-5), доверительных отношений (3, 5, 6).

Для достижения эффекта единого информационного пространства взаимодействие по всем схемам должно проходить в рамках создания публичных PKI-систем. При этом схемы 1, 4 и 5 допускают создание собственных информационных пространств (корпоративных PKI-систем).

Состав участников информационного обмена в рамках публичных PKI-систем предполагает наличие как минимум двух типов сертификатов: · для физических лиц высокой степени доверия, изготавливаемых на основе паспортных данных и соответственно имеющих статус электронного удостоверения личности; · для юридических лиц высокой степени доверия, также выдаваемых на имя физического лица при предъявлении им комплекта документов, которыми подтверждаются его полномочия от той или иной организации (собственно тот же комплект документов , что и при оформлении карточек с образцами подписей для банка).

При этом необходимо предусмотреть и изготовление тестовых сертификатов низкой степени доверия с выдачей их через Интернет.

Каждому типу выпускаемого сертификата должна соответствовать своя сертификационная политика и практика, единая для каждого задействованного в системе УЦ и согласованная с уполномоченным федеральным органом (УФО).

Все, что касается физических лиц, особенно при взаимодействии по схемам 3 и 6, должно быть реализовано в рамках государственной программы, не только закрепляющей порядок изготовления и выдачи сертификатов, но и направленной на создание соответствующих электронных сервисов. Если же говорить об архитектуре системы УЦ для этой программы, то представляется, что это должен быть единый российский государственный УЦ (РГУЦ) с разветвленной сетью регистрационных центров (РЦ). РЦ должны быть установлены по всей стране в паспортных столах (выдача паспортов) и ЗАГСах (ликвидация паспортов в связи со смертью). В последних можно устанавливать только рабочие места для передачи в УЦ уже недействительных сертификатов. Размещение РЦ именно в этих учреждениях позволит сформировать единую базу данных «электронных паспортов» граждан РФ, необходимую для функционирования государственных электронных сервисов, с обеспечением ее соответствия базе данных обычных паспортов. Такая архитектура при минимальных затратах реально обеспечит высокие требования к единому РГУЦ, а создание РЦ не приведет к появлению серьезных технологических проблем в эксплуатирующих их структурах. С сертификатами, изготовленными РГУЦ, возможна работа не только в рамках взаимодействия по схемам 3 и 6, но и в корпоративных системах (схема 5) при условии признания конкретной корпоративной системой соответствующей сертификационной политики и практики РГУЦ.

Создание архитектуры системы УЦ, ориентированных на выдачу сертификатов юридическим лицам, необходимо проводить с учетом сложившейся ситуации и наличия определенного количества уже действующих УЦ, в том числе и в регионах, обслуживающих конкретные PKI-системы. Эти УЦ могут составить нижний уровень в двухуровневой иерархической системе негосударственных УЦ с обязательной поддержкой сертификационной политики и практики по изготовлению и выдаче сертификатов высокой степени доверия для юридических лиц. В качестве УЦ верхнего уровня можно предложить РГУЦ.

Для поддержки взаимодействия между государственными структурами (схема 1) может быть также использована двухуровневая архитектура УЦ, где на нижнем уровне действуют ведомственные УЦ с разветвленной сетью РЦ, а на верхнем — все тот же РГУЦ. Сертификационная политика и практика та же самая, что и в случае с обычными юридическими лицами.

Все негосударственные УЦ, действующие на нижнем уровне иерархической структуры, могут дополнительно поддерживать и другие сертификационные политики и практики для предоставления услуг аутсорсинга (схемы 4 и 5), если того требует корпоративная система.

Предлагаемая модель архитектуры УЦ России представлена на рисунке. Ее внедрение позволит создать единое информационное пространство для юридически значимого электронного документооборота для всех схем взаимодействия хозяйствующих субъектов России и сформулировать требования к УЦ разных уровней.

Безусловно, это только один вариант построения архитектуры системы УЦ, да и в нем возможны дополнения, такие, как кросс-сертификационные связи между различными УЦ, мостовые УЦ и др., однако понять разрабатываемую архитектуру на текущем этапе представляется очень важным.

С автором можно связаться по адресу: v.smirnov@gin.ru.

Модели и механизмы доверия

Модель распределенного доверия разделяет доверие между двумя или несколькими удостоверяющими центрами. Пусть пользователь А владеет копией открытого ключа своего пункта доверия — УЦ₁ , а пользователь В — копией открытого ключа своего пункта доверия — УЦ₂ . УЦ₁ — корень строгой иерархии, которая включает пользователя А , УЦ₂ — корень строгой иерархии, в которую входит пользователь В . Если каждая из этих иерархий является неглубокой иерархией с доверенным издателем, то вместе они образуют полностью одноранговую сеть , потому что все удостоверяющие центры являются действительно независимыми одноранговыми узлами сети. В этой архитектуре отсутствуют подчиненные удостоверяющие центры. С другой стороны, если каждая иерархия является многоуровневой, то результат объединения иерархий имеет полностью древовидную структуру. Отметим, что головные удостоверяющие центры связаны друг с другом равноправными отношениями, но каждый головной УЦ действует как вышестоящий для одного или более подчиненных удостоверяющих центров. Одним из вариантов архитектуры распределенного доверия может быть гибридная конфигурация с одной или более иерархиями с доверенным издателем или одним или более многоуровневыми деревьями [44]. Эта конфигурация изображена на рис. 5.2.

Архитектура распределенного доверия

Рис. 5.2. Архитектура распределенного доверия

Обычно (хотя и не всегда) архитектура полностью одноранговой сети выбирается при развертывании PKI внутри отдельного корпоративного домена (например, внутри отдельной компании). Полностью древовидные и гибридные архитектуры часто возникают в результате связывания независимых PKI , ранее принадлежавших разным корпоративным доменам, причем эти инфраструктуры не обязательно подчиняются общему головному УЦ.

Изолированные PKI -домены могут быть сконфигурированы разными способами, в том числе на базе строгой иерархии, архитектуры полностью одноранговой сети или любой модели доверия , обсуждающейся в данной лекции. Важно, чтобы поддерживалась функциональная совместимость между любой комбинацией этих моделей доверия [96].

Процесс взаимного связывания одноранговых головных удостоверяющих центров обычно называют кросс-сертификацией , хотя в последнее время все чаще используется термин «создание сети PKI » (в частности для полностью древовидной и гибридной архитектур). Для кросс-сертификации , как правило, используются два разных типа конфигурации PKI : сетевая и мостовая ( конфигурация hub-and-spoke).

Следует отметить, что в настоящее время специалистами изучаются и предлагаются и другие методы создания отношений доверия между PKI -доменами:

взаимное распознавание;
использование списков доверия к сертификатам;
применение сертификатов аккредитации.

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

Список доверия к сертификатам ( Certificate Trust List — CTL), по определению специалистов корпорации Microsoft, является заверенным цифровой подписью списком сертификатов головных удостоверяющих центров, который признается администратором корпоративной сети пригодным для выполнения аутентификации клиентов и защиты электронной почты.

Концепция сертификата аккредитации впервые появилась в проекте PKI правительства Австралии ( Gatekeeper ) и заключается в том, что хорошо известные и надежные удостоверяющие центры при определенных условиях ручаются за другие удостоверяющие центры [44]. Использование сертификатов аккредитации можно сравнить с односторонней кросс-сертификацией в том смысле, что аккредитационный УЦ выпускает сертификаты для всех удостоверяющих центров, которые удовлетворяют требованиям аккредитации. При этом иерархия не поддерживается, и аккредитованные удостоверяющие центры могут быть полностью автономными субъектами. Сертификаты аккредитации можно использовать для реализации идеи взаимного распознавания.

Сетевая конфигурация

В сетевой конфигурации все головные удостоверяющие центры потенциально кросс-сертифицированы друг с другом. Два головных удостоверяющих центра устанавливают отношения кросс-сертификации , если их сообществам необходимо иметь защищенные коммуникации друг с другом. В полностью связанном случае, иногда называемом полной сетью, это требует установления (n 2 — n) — кросс-сертифицированных соглашений при наличии n -головных удостоверяющих центров, хотя на практике чаще встречаются неполные сети. Рис. 5.2 иллюстрирует неполную сетевую гибридную архитектуру распределенного доверия . Она не является полной сетью, потому что между первым и третьим удостоверяющими центрами отсутствует прямое соглашение о кросс-сертификации .

Мостовая конфигурация (конфигурация hub-and-spoke)

В мостовой конфигурации каждый головной УЦ устанавливает отношения кросс-сертификации с единственным центральным УЦ, в чьи функции входит обеспечение таких взаимных связей [101]. Центральный УЦ иногда называют «втулкой» (hub), соединенной «спицами» (spoke) с различными головными удостоверяющими центрами, а иногда называют мостовым УЦ , устанавливающим связи между парами головных удостоверяющих центров. Преимущество этой конфигурации заключается в том, что в случае полной связи требуется заключение только n -соглашений о кросс-сертификации для n -головных удостоверяющих центров, потому что каждый головной УЦ кросс-сертифицируется только с центральным УЦ.

Мостовая конфигурация не создает иерархии, мостовой УЦ следует рассматривать как головной для всех систем, которые кросс-сертифицируются с ним. Фундаментальное различие между строгой иерархией и мостовой конфигурацией состоит в том, какими ключами владеют конечные субъекты. В строгой иерархии все субъекты владеют доверенной копией открытого ключа головного УЦ, обеспечивающего базу для валидации пути сертификации . В мостовой конфигурации конечные субъекты не владеют открытым ключом мостового УЦ , а имеют лишь копию открытого ключа головного УЦ в своем собственном домене. Каждый субъект, строя путь сертификации, при помощи этого ключа получает ключ мостового УЦ , затем ключ головного УЦ другого домена и, в конце концов, ключ конечного субъекта другого домена.