О доверенных сервисах при построении электронного правительства

Алексей Сабанов
заместитель генерального директора
ЗАО "Аладдин Р.Д.", к.т.н.

Текущее состояние построения информационного общества и электронного правительства можно кратко охарактеризовать следующим образом.

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

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

В настоящее время активно обсуждается и готовится к принятию проект закона "Об электронной подписи", который, с одной стороны, дает возможность более широко подойти к защите электронных документов, в частности использовать различные технологии для защиты СЭД в зависимости от их принадлежности и других условий. С другой - появляется реальная необходимость обеспечения и понимание механизмов придания электронным документам юридической силы наравне с бумажными.

Юридическая сила электронного документа

В сегодняшнем правовом поле (конец 2010 г.) для обеспечения юридической значимости электронному документу имеется непростой, но уже хорошо известный алгоритм, включающий в себя ряд технологических, правовых и организационных мер. Так, при создании и использовании ключей ЭЦП в общем случае необходимо использовать только сертифицированные средства ЭЦП и средства криптографической защиты информации (ст. 5 № 1-ФЗ). Для признания документов с ЭЦП равнозначными привычным бумажным документам необходимо также введение понятия аналога собственноручной подписи и создание регламента использования ЭЦП в каждой СЭД или заключение соглашения сторон об использовании ЭЦП в СЭД (согласно ст. 1 № 1-ФЗ, а также ст. 160 ГК и ст. 11 № 149-ФЗ).

В проекте нового закона "Об электронной подписи" ст. 5 полностью посвящена условиям признания электронных документов, подписанных электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью. Если данная статья будет принята, это даст электронному документу с ЭЦП и другими сервисами безопасности новую жизнь.

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

Эти сервисы должны в совокупности с системой доверенных УЦ составлять основу единого пространства доверия.

Что это за сервисы, откуда они берутся и зачем они нужны?

Зачем нужны доверенные сервисы PKI

Рассмотрим, что же такое юридическая сила документа. Согласно ГОСТ Р 51141-98 это свойство официального документа, сообщаемое ему действующим законодательством, компетенцией издавшего его органа и установленным порядком оформления.

Официальный бумажный документ в своем оформлении имеет определенные реквизиты.

Рекомендации по составу реквизитов документов без конкретизации сферы их применения стандартизированы в России в ГОСТ Р 6.30-2003. "Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов", в котором описано 30 возможных реквизитов документов.

Например, единый порядок делопроизводства в федеральных органах исполнительной власти должен исполняться в соответствии с постановлением № 477 Правительства Российской Федерации от 15 июня 2009 г. Согласно этому постановлению при оформлении документов, создаваемых в процессе деятельности федерального органа исполнительной власти, элементами оформления документа могут являться следующие 24 реквизита: Государственный герб Российской Федерации; наименование федерального органа исполнительной власти; должность лица, подписавшего документ; подпись должностного лица; вид документа; место составления (издания) документа; справочные данные о федеральном органе исполнительной власти; адресат; дата документа; регистрационный номер документа; наименование документа; текст документа; ссылка на исходящий номер и дату документа адресанта; отметка о наличии приложений; гриф согласования; гриф утверждения; виза; оттиск печати; отметка о заверении копии; отметка об исполнителе; указания по исполнению документа; отметка о контроле документа; отметка об исполнении документа; отметка о конфиденциальности.

По идее, для обеспечения юридической значимости все эти реквизиты должны иметь соответствующие аналоги при переводе документа в электронный вид.

Например, аналогом собственноручной подписи согласно № 1-ФЗ является доверенный сервис – ЭЦП (обозначено цифрой 1 на рисунке), цифрой 2 на этом же рисунке обозначено выражение цифрового правомочия (соответственно расшифровка подписи для бумажного варианта документа), цифрой 3 представлено цифровое полномочие (соответственно указание должности для бумажного варианта), правовому статусу электронного документа может соответствовать угловой штамп для бумажного документа, в электронном документе в ряде случаев необходимо строго фиксировать место (5) и время (6 – штамп времени). Список легко продолжить. Имея в качестве инструмента цифровой сертификат Х.509 v.3, естественным желанием было бы разместить в поля сертификата как можно больше из указанных в Постановлении Правительства № 477 реквизитов для возможности автоматической обработки хотя бы части реквизитов. Но не все так просто. Во-первых, мало какие аналоги реквизитов можно поместить в поля сертификата. Во-вторых, в отсутствие руководящей и направляющей силы по стандартизации в некоторые поля сертификата в разных ведомствах и разных удостоверяющих центрах зачастую пишется неоднородная информация.

Поэтому до сих пор остается открытым вопрос: что использовать в качестве идентификатора чиновника? СНИЛС или ИНН не подходит (это идентификатор гражданина – физического лица), а надо учитывать статус (должность и полномочия по уровням работы с документами – имеешь право чтения, внесения исправлений, визирования, подписи или нет). В одном из ведомств в качестве идентификатора госслужащего взяли OID его компьютера, включенного в пространство доверия ведомства, в свою очередь, вошедшего в пространство доверия России, которое в настоящее время ведет Росинформтехноло-гии. Возможно, это на сегодня один из вынужденно правильных подходов. Однако он хорош для федеральной структуры (где длина кодов OID не так велика), а какой длины будет OID для уровня сельсовета? На сегодня многие вопросы остаются нерешенными.

Среди них отдельную проблему при переводе документов в электронный вид занимает нотариальное заверение и апостиль.

Электронный нотариат

При построении электронного государства неизбежно возникает потребность в электронном нотариате. Построить легитимный работающий электронный нотариат (ЭН) не так-то просто. Основная функция обычного нотариуса – придание частным соглашениям аутентичного характера, особой доказательной и исполнительной силы, защита публичного интереса. Основными функциями  ЭН  должны  быть разработка и удостоверение юридических актов, совершенных в электронной форме (электронная нотаризация), также в электронной форме. Для выполнения нотариальных действий в электронном виде нотариусам  необходим  аппаратно-программный комплекс нотаризации, который должен быть специально разработан и установлен у каждого лица, уполномоченного выполнять нотариальные действия в электронном виде. Для выполнения нотариального действия в электронном виде требуется наличие   у   нотариуса   ЭЦП, а также возможность проставления метки времени совершения нотариального действия. Проставление метки времени обязательно. Оно необходимо для того, чтобы впоследствии невозможно было изменить содержание электронного нотариального документа. Законодательство об ЭН существует во всех штатах США, есть примеры работающей системы ЭН. Из европейских стран активно развитием законодательства в сфере ЭН занимается Венгрия. В Венгрии с 1 мая 2006 г. вступил в силу нормативный акт, позволяющий нотариусам удостоверять подлинность электронных документов при помощи электронной подписи. С этого дня документ, заверенный таким образом, имеет ту же юридическую силу, что и документ, заверенный обычной печатью. В России технических реализаций функций ЭН довольно много, как правило, в виде дополнительного сервиса в составе УЦ. Более полный типовой набор технической реализации функций ЭН может состоять из следующих операций, применяющих доверенные сервисы PKI:

1. Удостоверение обладания информацией с или без ее представления сервису (CCPD – Certification of Claim of Possession & Data или CPD – Certification of Possession & Data) по RFC 3029 или выработка квитанции, содержащей штамп времени по RFC 3161 Time-Stamp Protocol (TSP).
2. Проверка действительности ЭЦП на текущий момент времени по RFC 3029.
3. Проверка действительности сертификата открытого ключа по Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (DVCS), RFC3029; или такая проверка зачастую выполняется с помощью OCSP RFC 2560 Online Certificate Status Protocol (OCSP).

Как видите, при построении ЭН уже требуется так называемая доверенная третья сторона, роль которой выполняет доверенный сервер, выписывающий квитанции по указанным выше протоколам.

Трансграничные операции

В настоящее время достаточно интенсивно идет работа по расширению международного сотрудничества в области согласования требований законодательства и правил работы при трансграничной передаче персональных данных со странами СНГ и дальнего зарубежья. Почему эта задача актуальна?

Она встает во многих сегментах экономики. Много вопросов сегодня решается только с помощью бумажного документооборота или даже личных встреч. Например, масса вопросов требует современного разрешения использования документов в электронном виде для страхователей, имеющих пенсионное обеспечение (более 10 млн россиян проживают на территориях ближнего и дальнего зарубежья). Также эта задача актуальна для Таможенного союза, для решения вопросов страхования граждан, выезжающих за рубеж (более 10 млн россиян ежегодно выезжают в командировки и на отдых). Развивается электронная торговля, телемедицина, дистанционное обучение и другие виды деятельности, требующие международного документального взаимодействия офлайн и онлайн.

При трансграничных взаимодействиях международная доверенная третья сторона как совокупность взаимосвязанных доверенных третьих сторон стран необходима прежде всего для того, чтобы "перезаверять" трансграничные сообщения.

Фактически она должна выполнять роль моста доверия между двумя пространствами доверия, в котором создается и в котором будет рассматриваться и использоваться документ. Причем в данном случае это две разные страны. Для международного признания официальных документов установленного образца (типичный пример – диплом об окончании вуза) используется апостиль (нотариальное заверение перевода официального документа на другой язык). Что касается электронных документов – это пока нерешенная задача. Усилиями мирового сообщества с трудом за несколько десятилетий был налажен апостиль бумажных документов. Технически перевод электронных документов может производиться быстрее, но для международного заверения перевода требуется международная доверенная третья сторона со своими доверенными сервисами (TSP, DVCS, OCSP, AC – атрибутирования, см. [5]), а во многих странах (включая и Россию) пока еще нет и полноценной внутренней доверенной третьей стороны. Так что это задача на ближайшее будущее.

Что в итоге?

К сожалению, к моменту написания данной работы пока не определены такие понятия, как "архитектура" и "основные компоненты" единого пространства доверия (ЕПД). По какому пути пойдем мы в строительстве ЕПД – иерархическая, браузерная или сетевая модель? Наверное, проще всего в условиях имеющейся кусочно-непрерывной модели ЕПД, построенной с той или иной степенью успеха в отдельных ведомствах, пойти по пути сетевой модели. Тем более что в мировой практике имеется опыт реализации всех трех перечисленных видов архитектуры. До конца года мы узнаем, по какому пути мы пойдем.

В настоящее время специалистами Ростелекома разрабатывается Технический проект электронного правительства. Первый этап – подготовку семи томов, описывающих общее техническое решение, включающее в себя архитектуру и компоненты ЭП, – по словам вице-президента компании "Ростелеком" по федеральным программам А. Нащекина, планируется завершить к концу 2010 г. [2].

Тем не менее фактическое строительство элементов ЕПД идет у нас в стране с двух сторон. Во-первых, для всех ветвей исполнительной власти согласно Постановлению Правительства № 754 от 22.09.2009 г. (ответственный исполнитель – ФСО России) развивается проект межведомственного электронного документооборота федеральных органов исполнительной власти (МЭДО). А во-вторых, согласно постановлению Правительства № 697 от 08.09.2010 г. (ответственный исполнитель – Минкомсвязи РФ) развивается проект строительства единой системы межведомственного электронного взаимодействия (СМЭВ).

В принятом системном проекте, разработанном под руководством Минкомсвязи РФ, сказано: "Для обеспечения возможности обмена в автоматизированном режиме электронными почтовыми сообщениями между Администрацией Президента Российской Федерации, Аппаратом Правительства Российской Федерации, федеральными органами исполнительной власти и иными федеральными органами государственной власти используется система межведомственного электронного документооборота (система МЭДО). Система МЭДО не является элементом СМЭВ. Оператор системы МЭДО определяется отдельным нормативным правовым актом Российской Федерации".

СМЭВ создается с целью решения следующих задач:

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

Таким образом, на концептуальном уровне СМЭВ, выступая в роли интеграционной шины и/или "интеграционного брокера", не отвергает концепции ЭДО, а является дополнением к ней.
Понятно, что главным локомотивом перехода органов власти к ЭДО является МЭДО. Из этого проекта вырастет система межведомственного документооборота не только федеральных органов власти, но и региональных. По мнению многих специалистов, проекты СМЭВ и МЭДО сомкнутся, когда оба дойдут до нижних этажей органов власти. Очень бы хотелось, чтобы к тому времени задачи, поставленные в данной работе, и связанные с ними проблемы были решены или близки к решению. Тогда доверенные сервисы (ЭЦП, TSP, DVCS, OCSP, AC) будут эффективно выполнять свои функции для развития электронного документооборота.

Литература

1. Системный проект формирования в Российской Федерации инфраструктуры электронного правительства. Министерство связи и массовых коммуникаций Российской Федерации. 2010. www.filearchive.cnews.ru/-doc/2010/06/17/sp.doc.
2. Интервью с А. Нащекиным "Мы создаем новый рынок для всех IT-компаний" // Информ-Курьер-Связь. – 2010. – № 11. – С. 37.
3. Храмцовская Н.А. Современные идеи и опыт в области госуправления: межведомственное электронное взаимодействие. – М.: Полиграфия Дизайн, 2010. – 172 с.
4. http://wiki.elrussia.ru/in-dex.php/%D0%9D%D0%BE%D1 %82%D0%B0%D1%80%D0%B8 %D0%B0%D1%82.
5. http://www.top-cross.ru/Com-pany/InfoSec-6_2007_Page_44.pdf.