А. Г. Сабанов, ЗАО «Аладдин Р.Д.»
Вопросы юридически значимого (ЮЗ) ЭДО активно обсуждаются специалистами, но единого подхода на момент написания данной статьи так и не выработано. Сказывается отсутствие долгожданной законодательной основы, в частности, по электронному документу (ЭД) и электронным сделкам. Практически в нулевом состоянии и сопутствующая нормативная база по поддержанию в доверенном состоянии онлайн-сервисов, гарантирующих юридическую силу ЭД, а также сам минимальный набор таких доверенных сервисов, необходимых и достаточных для придания юридической силы ЭД. Без перечисленных документов только организационными мерами создать ЮЗ ЭДО проблематично.
Тем не менее, замена бумажного документооборота юридически значимым электронным уже не за горами, и оценить некоторые перспективы перевода в облака с точки зрения задач («а что для этого надо сделать?») можно уже сегодня.
Рассмотрим проблемы построения ЮЗ ЭДО для обычных информационных систем (ИС), а затем более подробно – как изменятся задачи такого построения при переходе к облачным вычислениям на примере частного облака и облака публичного.
Проблемы обеспечения юридической силы электронного документа
Проанализируем ситуацию, условно объединив близкие по природе проблемы в комплексы.
Главный из них – отсутствие адекватной нормативной базы, которая позволила бы двигаться вперед. Во-первых, катастрофически не хватает нормативной базы регулирования ЭДО. Нет узаконенных понятий ЭД, электронной сделки и т. д. Во-вторых, не решен комплекс задач архивного хранения электронных документов и, что особенно важно, ЭД, обладающих ЮС. Согласно действующему 63-ФЗ «Об электронной подписи» ЭП имеет ограниченный срок действия. По окончании этого срока ЭП «умирает», подобно выцветанию чернил собственноручно поставленной подписи под ярким солнцем. Как проверить действительность подписи и наличие полномочий через 10−20 лет? И это лишь один вопрос из множества по архивному хранению. В-третьих, не решены задачи нормативного обеспечения гарантированной идентификации и аутентификации сторон при удаленном электронном взаимодействии. На Западе гарантом является государство, имеется целая система обязательных стандартов и системы проверок в рамках специальных госпрограмм по идентификации. В РФ ничего этого пока нет. В-четвертых, до сих пор отсутствует нормативное понятие копии ЭД. Также не решены задачи унифицированных форматов ЭД при обмене, хранении и обработке… Короче говоря, в части регулирования ЭДО мы еще в начале пути. Те скупые частички регулирования, которые можно найти в 149-ФЗ, 63-ФЗ и Административном кодексе, уже не позволяют развивать ЭДО, тем более, обеспечивать реальную ЮС ЭД.
Вторым комплексом причин является процесс внедрения системы ЭДО с ЭП. Разработчикам ЭДО при внедрении проще продать дополнительные функциональные модули, чем возиться с настройками, связанными с внедрением «доверенных» средств аутентификации и квалифицированной подписи, − для этого надо поднять УЦ, выполнить комплекс работ по установке и легализации СКЗИ… Вопросы лицензирования деятельности такого рода и применения сертифицированных средств требуют участия в работах по внедрению лицензиатов ФСБ России и ФСТЭК России. Как правило, на данном этапе внедрения СЭД к работам подключаются специализированные интеграторы по вопросам информационной безопасности (ИБ). Зачастую на вопросы ИБ элементарно не хватает бюджета.
Третий комплекс причин − неготовность к переходу к ЭДО с ЮС ЭД самих услуг и участников УЭВ, а также контролирующих органов. Ярким примером в данном случае является официально разрешенные счета-фактуры в электронном виде, до сих пор не получившие широкого распространения. Применение ЭД, обладающих ЮС, на момент написания статьи наиболее часто удается в отдельных отраслях народного хозяйства. Типичный пример − система электронных накладных ЭТРАН, используемая уже несколько лет в системе ОАО «РЖД», где с помощью отраслевой нормативной базы, организационных мер и единой технической политики (в том числе при использовании одного УЦ и унифицированных сервисов безопасности) удалось создать отраслевую СЭД с ЭД, обладающих ЮС.
Каковы же способы создания широкой сети СЭД с ЮС ЭД?
Как уже упоминалось, это должен быть комплекс мер, включающих нормативно-правовые, организационные и технические меры. Рассмотрим технические меры.
С технической точки зрения ЮС ЭД может придать только совокупность применения нескольких доверенных сервисов, в число которых, прежде всего, входит усиленная квалифицированная электронная подпись (УКП). Одним из достаточно распространенных заблуждений является мнение о том, что применение одной лишь УКП достаточно для того, чтобы ЭД стал обладать ЮС. Можно показать, что минимальный набор инфраструктурных доверенных сервисов для придания ЮС в электронном документообороте состоит из:
- инфраструктуры и доверенных средств генерации, применения и проверки УКП;
- развитой системы проставления меток доверенного времени, синхронизированного в каждом аккредитованном удостоверяющем центре с временем корневого УЦ;
- поддерживаемой в актуальном состоянии с заданным интервалом времени (в часах) системы реестров полномочий и правомочий владельцев УКП;
- доверенных сервисов идентификации и аутентификации, строго регламентированных для каждого аккредитованного УЦ с регулярным внешним контролем порядка и правил выполнения основных процедур.
Перечислим минимальный набор клиентских доверенных сервисов, необходимых для обеспечения ЭД ЮС.
Электронная подпись. Электронная подпись является уникальным сервисом безопасности, вобравшим в себя следующие доверенные сервисы:
- аутентификация источника данных – подтверждение подлинности источника полученных данных (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 X.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-ФЗ закрытый ключ ЭП должен находиться под полным контролем пользователя. Для физических лиц, пользующихся облачными сервисами, риски, связанные с хранением и применением средства ЭП, автоматически переходят на пользователей. Если они примут эти риски и подпишут договор на облачное обслуживание, то система может заработать. С юридическими лицами (а именно они могут стать основными пользователями облаков при построении информационного общества) не так просто. Например, при заключении договора на обслуживание в облаке юридическое лицо может пожелать, чтобы действующая корпоративная система формирования ключевого материала была принята облачными сервисами as it is, и на сформированный корпоративными средствами открытый ключ был бы выпущен сертификат для работы в облаке.
Система меток доверенного времени. В современных публичных облаках данный сервис можно настроить для корневого облака и присоединенных сервисных информационных систем. Причем закрепить это можно в договорах на присоединение.
Система реестров полномочий и правомочий владельцев УКП. Этот сервис, к сожалению, пока не удается построить и поддерживать в гарантированно актуальном состоянии и на «земле», не говоря уже об облаках.
Система доверенных сервисов идентификации и аутентификации. Данную проблему решить можно, но только не совсем просто и исключительно локально, для конкретного облака и присоединенных сервисов. Дело в том, что в РФ нет утвержденной стратегии, а также архитектуры и способов построения системы трансляции доверия идентификации и аутентификации от одной ИС к другой. На эту тему написано достаточно много статей, в том числе автором на страницах журнала «Connect! Мир связи».
Подведем итоги
Вопросы обеспечения ЮС ЭД до сих пор не решены для обычных информационных систем. В закрытой корпоративной системе локальное решение проблем ЮС ЭД реально. Соответственно, также возможно обеспечить ЮС ЭД в частном облаке. Для решения проблем обеспечения ЮС ЭД в публичных облаках требуются решения на законодательном, нормативном, организационном и техническом уровнях.
