Информация >> Публикации сотрудников компании >>Смирнов В.А. «Об архитектуре системы удостоверяющих центров и типах сертификатов»
«PC Week», №48, 2003 декабрь

«PC Week», №48, 2003 декабрь

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

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

1. государственная структура - государственная структура

2. государственная структура - юридическое лицо

3. государственная структура - физическое лицо

4. юридическое лицо - юридическое лицо

5. юридическое лицо - физическое лицо

6. физическое лицо - физическое лицо

В качестве примеров взаимодействия можно привести:

- системы административного документооборота (уровни 1,2,4)

- системы бухгалтерского документооборота (уровни 1,2,4)

- системы финансового документооборота (уровни 1-5)

- системы доверительных отношений (уровни 3,5,6)

- и другие.

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

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

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

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

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

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

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