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

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

Тем не менее замена бумажного документооборота юридически значимым электронным уже не за горами и оценить некоторые перспективы перевода в облака с точки зрения задач ("а что для этого надо сделать?") можно уже сегодня.

Рассмотрим проблемы построения ЮЗ ЭДО для обычных информационных систем (ИС), а затем более подробно - как изменятся задачи такого построения при переходе к облачным вычислениям на примере частного облака и облака публичного.

Проблемы обеспечения юридической силы электронного документа

Проанализируем ситуацию, условно объединив близкие по природе проблемы в комплексы.

Главный из них - отсутствие адекватной нормативной базы, которая позволила бы двигаться вперед. Во-первых, катастрофически не хватает нормативной базы регулирования ЭДО. Нет узаконенных понятий ЭД, электронной сделки и т.д. Во-вторых, не решён комплекс задач архивного хранения электронных документов и, что особенно важно, ЭД, обладающих ЮС. Согласно действующему № 63-Ф3 "Об электронной подписи" ЭП имеет ограниченный срок действия. По окончании этого срока ЭП "умирает", подобно выцветанию чернил собственноручно поставленной подписи под ярким солнцем. Как проверить действительность подписи и наличие полномочий через 10-20 лет? И это лишь один вопрос из множества по архивному хранению. В-третьих, не решены задачи нормативного обеспечения гарантированной идентификации и аутентификации сторон при удалённом электронном взаимодействии. На Западе гарантом является государство, имеется целая система обязательных стандартов и системы проверок в рамках специальных госпрограмм по идентификации. В РФ ничего этого пока нет. В-четвёртых, до сих пор отсутствует нормативное понятие копии ЭД. Также не решены задачи унифицированных форматов ЭД при обмене, хранении и обработке... Короче говоря, в части регулирования ЭДО мы ещё в начале пути. Те скупые частички регулирования, которые можно найти в № 149-ФЗ, 63-Ф3 и Административном кодексе, уже не позволяют развивать ЭДО, тем более обеспечивать реальную ЮС ЭД.

Вторым комплексом причин является процесс внедрения системы ЭДО с ЭП. Разработчикам ЭДО при внедрении проще продать дополнительные функциональные модули, чем возиться с настройками, связанными с внедрением "доверенных" средств аутентификации и квалифицированной подписи, - для этого надо поднять УЦ, выполнить комплекс работ по установке и легализации СКЗИ... Вопросы лицензирования деятельности такого рода и применения сертифицированных средств требуют участия в работах по внедрению лицензиатов ФСБ России и ФСТЭК России. Как правило, на данном этапе внедрения СЭД к работам подключаются специализированные интеграторы по вопросам информационной безопасности (ИБ). Зачастую на вопросы ИБ элементарно не хватает бюджета.

Третий комплекс причин - неготовность к переходу к ЭДО с ЮС ЭД самих услуг и участников УЭВ, а также контролирующих органов. Ярким примером в данном случае является официально разрешённые счета-фактуры в электронном виде, до сих пор не получившие широкого распространения. Применение ЭД, обладающих ЮС, на момент написания статьи наиболее часто удаётся в отдельных отраслях народного хозяйства. Типичный пример: система электронных накладных ЭТРАН, используемая уже несколько лет в системе ОАО "РЖД", где с помощью отраслевой нормативной базы, организационных мер и единой технической политики (в том числе при использовании одного УЦ и унифицированных сервисов безопасности) удалось создать отраслевую СЭД с ЭД, обладающих ЮС.

Каковы же способы создания широкой сети СЭД с ЮС ЭД?

Как уже упоминалось, это должен быть комплекс мер, включающих нормативно-правовые, организационные и технические меры. Рассмотрим технические меры.

С технической точки зрения ЮС ЭД может придать только совокупность применения нескольких доверенных сервисов, в число которых прежде всего входит усиленная квалифицированная электронная подпись (УКП). Одним из достаточно распространённых заблуждений является мнение о том, что применение одной лишь УКП достаточно для того, чтобы ЭД стал обладать ЮС. Можно показать, что минимальный набор инфраструктурных доверенных сервисов для придания ЮС в электронном документообороте состоит из:

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

Перечислим минимальный набор клиентских доверенных сервисов, необходимых для обеспечения ЭД ЮС.

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

• аутентификация источника данных - подтверждение подлинности источника полученных данных (ISO 7498-2);
• обеспечение целостности данных, означающее, что данные не были модифицированы или уничтожены неавторизованным образом (ISO 7498-2);
• невозможность отрицания авторства - сервис защиты от отрицания автором факта создания или отправления им сообщения (ISO/ IEC 13888-1).

Сервис аутентификации. Аутентификация при удалённом взаимодействии должна обеспечивать связанные процессы подтверждения подлинности предъявленных пользователем идентификаторов с помощью зарегистрированного в системе секрета и доказательства принадлежности конкретному пользователю идентификаторов и секрета. Этот сервис также является сложным, содержащим следующие составляющие:

• обеспечение доказательства подлинности предъявленного идентификатора (ISO/IEC 10181-2);
• доказательство принадлежности аутентификатора, с помощью которого производится доказательство подлинности, конкретному субъекту (ISO/IEC 10181-2);
• аутентификация сторон - подтверждение того, что взаимодействующая сторона является той, за которую себя выдаёт (ISO 7498-2).

Сервис доверенного времени. Сервис меток доверенного времени совместно с сервисом штампов времени (RFC 3161 Time-Stamp Protocol) образуют службу доверенного времени. Суть сервиса состоит в синхронизации серверного времени для всех УЦ, участвующих в формировании и проверке статуса сертификата.

Сервис валидации. Сервис валидации (RFC 2459), как правило, входит в состав службы "Заверения электронных сообщений" и может являться дополнительным сервисом в автоматизированной системе, выполняющей функции УЦ. Проверка действительности данных, связанных с подписанным сообщением или документом, а также сертификатов ключей подписи может проводиться по стандартному протоколу Internet Х.509 Public Key Infrastructure Data Validation and Certification Server Protocols (DVCS) с квитанцией за подписью сервера (RFC 3029). Для проверки статуса сертификата также используется On-line Certificate Status Protocol - OCSP (RFC 2560). Отдельно может проводиться проверка действительности сертификата открытого ключа - Validation of Public Key Certificates (VPKC).

Сервис проверки действительности правомочий и полномочий субъекта на момент подписи. Также подтверждается квитированием (подписанной сервером квитанцией).

Особое внимание необходимо обратить на поддержание в доверенном состоянии сервиса аутентификации, который применяется всегда перед подписанием документа.

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

Итак, для обеспечения ЮС ЭД необходимо поддерживать в актуальном и доверенном состоянии следующие виды инфраструктур:

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

Как перечисленные задачи и инфраструктурные решения смогут обеспечивать ЮС ЭД в облаках? Рассмотрим два крайних случая: частное облако и публичное облако.

Частное облако

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

Публичное облако

Главный вопрос при переходе к облачному взаимодействию - это вопрос доверия. Инфраструктурные решения облака не принадлежат владельцу информации - пользователю облачных сервисов, а находятся под контролем либо оператора облака, либо владельцев программных решений, "присоединённых" к облачной структуре по договорам о предоставлении сервисов, или вообще состоят на аутсорсинге у третьей стороны. Требования по безопасности и "доверенности" присоединенных сервисов формируются оператором облака и зачастую занимают далеко не первые места по сравнению с требованиями по функциональности, интероперабельности и доступности. Рассмотрим, какие из инфраструктурных решений могут стать "доверенными" в публичном облаке и какие очевидные трудности могут встретиться на пути выстраивания системы доверия "пользователь - облако" для обеспечения ЮС ЭД.

Инфраструктура и доверенные средства генерации, применения и проверки УКП. Инфраструктуру открытых ключей, способную в режиме онлайн проверять ЭП, в облаке теоретически выстроить можно. Проблемы могут возникнуть у оператора, даже если он обладает всем набором необходимых лицензий на производство работ и услуг, связанных с крипто-средствами. Сертифицированных средств ЭП в России тоже достаточно, но их распространение подлежит строгому учёту, и для этого тоже требуются лицензии, аттестация пунктов выдачи и обученный персонал. Согласно № 63-Ф3 закрытый ключ ЭП должен находиться под полным контролем пользователя. Для физических лиц, пользующихся облачными сервисами, риски, связанные с хранением и применением средства ЭП, автоматически переходят на пользователей. Если они примут эти риски и подпишут договор на облачное обслуживание, то система может заработать. С юридическими лицами (а именно они могут стать основными пользователями облаков при построении информационного общества) не так просто. Например, при заключении договора на обслуживание в облаке юридическое лицо может пожелать, чтобы действующая корпоративная система формирования ключевого материала была принята облачными сервисами as it is и на сформированный корпоративными средствами открытый ключ был бы выпущен сертификат для работы в облаке.

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

Система реестров полномочий и правомочий владельцев УКП. Этот сервис, к сожалению, пока не удаётся построить и поддерживать в гарантированно актуальном состоянии и на "земле", не говоря уже об облаках.

Система доверенных сервисов идентификации и аутентификации. Данную проблему решить можно, но только не совсем просто и исключительно локально, для конкретного облака и присоединённых сервисов. Дело в том, что в РФ нет утвержденной стратегии, а также архитектуры и способов построения системы трансляции доверия идентификации и аутентификации от одной ИС к другой. На эту тему написано достаточно много статей, в том числе автором на страницах журнала Connect.

Подведем итоги

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