Информационный обмен между изолированными системами (Взаимодействие информационных систем)

Сергей Муругов

В разделе 7.3 RFC 3281 указано: "В некоторых случаях может потребоваться, чтобы атрибутный сертификат (АС) не был привязан ни к личности владельца, ни к сертификату открытого ключа. В таком случае возможно использование варианта objectDigestInfo поля holder... Смысл данного варианта поля holder в том, чтобы обеспечить связь АС и некоторого объекта, которому он "принадлежит" посредством указания значения хэшфункции от данного объекта. Такой подход, например, позволяет связывать АС с исполняемыми объектами, такими, как Java-класс".

Постановка задачи

Исходящая и соответственно входящая информация для информационных систем организаций представляет собой более сложную структуру, нежели просто электронный документ, пусть даже с ЭЦП. В соответствии с действующим ГОСТ Р ИСО 15489-1–2007, помимо содержания документ должен иметь соотнесенные с контентом метаданные, отражающие операции деловой деятельности, и быть постоянно связанным или объединенным с ними. Такого рода метаданные, сопровождающие документ, должны содержать указания, обеспечивающие пригодность документа для последующего его использования, отражающие возможность локализации и поиска документа, воспроизводимости электронного документа техническими средствами визуализации.

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

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

- Контейнер должен иметь механизмы защиты целостности данных и идентификации источника данных.

- Язык описания и правил кодирования контейнера должен быть в достаточной степени универсальным, чтобы описывать сложные структуры и типы данных. В качестве примера такого языка может выступать XML (при выборе языка следует иметь в виду, что в РФ (насколько известно) отсутствует государственный стандарт на XML) или ASN.1 (существует целое семейство действующих стандартов).

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

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

Очевидно, что привычный всем формат ЭЦП в виде CMS или PKCS#7 или "подпись с расширенными данными для проверки" по ETSI TS 101 733 в явном виде не сможет обеспечить все вышеперечисленные требования.

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

Возможные области применения По предварительному анализу некоторых видов деловой активности можно явно выделить приложения использования такого рода контейнера ("удостоверяющего свидетельства"):

1. Бизнес-процессы, в которых исходящие/входящие документы имеют свойство разрешения на что-либо. Например, в задачах фитосанитарного контроля импортное карантинное разрешение (ИКР) в полной мере может быть в электронном виде представлено средствами "удостоверяющего свидетельства". В этом случае решаются требования и сложной вложенной структуры самого документа, и метаданных ИКР с указанием периода его действия, а также возможности у Россельхознадзора отозвать конкретный ИКР с автоматическим выводом его из действительного оборота, например в случаях выявления заболевания в отдельном регионе поставки и т.п.

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

3. Электронная лицензия на программное обеспечение или иную информацию, причем в таком варианте использования автоматически решается задача контроля целостности и неизменности программного обеспечения или иной информации.

4. Для обмена сведениями о физических и юридических лицах с уполномоченными органами (кредитными организациями, государственными агентствами, ведомствами, министерствами), например, для приема различных заявлений от физических лиц (дистанционным способом), а также в банковской деятельности на территории РФ в соответствии с положениями 115–ФЗ п. 1, 1.3 и п. 31. ст. 7.

Архитектура компонентсистемы, использующей атрибутные сертификаты В общем виде можно выделить следующие принципы: 1. Издатель атрибутных сертификатов должен входить в структуру СЭД организации, поскольку ЭЦП на атрибутном сертификате ("удостоверяющем свидетельстве") вырабатывается на ключе уполномоченного лица организации (атрибутный сертификат есть исходящий документ именно из организации и от имени организации), а делегирование данной функции внешней, пусть даже вышестоящей организации может встать в противоречие с регламентом функционирования организации или нормативной базой.

2. Доверие к информации в атрибутном сертификате определяется доверием к его издателю.

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

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

- централизованное управление и поддержка единой зоны обращения ЭЦП.

Выводы 1. Использование атрибутного сертификата в качестве защищенного контейнера НЕ противоречит действующей нормативной базе, поскольку контейнер представляет собой структурированную связанную информацию, правила формирования которой общедоступны и опираются на национальные и международные стандарты и рекомендации, а также защищены ЭЦП в соответствии с действующим законодательством.

2. Правила управления периодом действительности информации в контейнере опираются на доступную технологию, апробированную годами в УЦ.

3. Контейнер идеально подходит для инкапсуляции документов, исходящих из СЭД во внешние системы, а с учетом того, что издатель контейнера принадлежит СЭД (сертификат издателя "содержит необходимые при осуществлении данных отношений сведения о правомочиях его владельца") и СЭД обслуживает документооборот организации, можно представлять защищенный ЭЦП-контейнер как техническую реализацию формы исходящего документа.

4. Техническая реализация структуры контейнера опирается на принцип предварительной регистрации типов объектных идентификаторов (OID), описывающих структуры данных, поскольку технология и организационная структура регистрации и ведения OID уже существует, то обмен документов, инкапсулированных в защищенный контейнер между различными СЭД ведомств, очень легко реализуем на практике.

Поделитесь этой записью или добавьте в закладки