Перспективная разработка Компании - Сервер Атрибутных сертификатов по рекомендациям RFC 3281. Предпосылками к проекту послужили произошедшие за последние годы изменения в тенденциях развития IT-сектора - это в первую очередь появление на рынке компаний, позиционирующих себя на оказании публичных криптографических услуг, разработка стандартов представления информации с использованием отечественных криптографических алгоритмов, открытие профильных Государственных Программ, и с другой стороны, востребованность на рынке решений на технологии открытых ключей.

Служба атрибутирования решает две задачи:

• Позволяет осуществить криптографическую связь сертификата ключа подписи с дополнительной информацией, защищенной ЭЦП, определяющей роль владельца сертификата в ИС, например, для целей разграничения доступа, размещения персональной информации, размещения информации уточняющей полномочия и т.п.

• Позволяет осуществить криптографическую связь между абстрактным блоком данных и дополнительной информацией (метаданными), например, такой атрибутный контейнер можно ассоциировать с электронным документом вместе с метаданными при межсистемном (межведомственном) информационном обмене. Дополнительно, используемая технология позволяет (ЭЦП в виде CMS или PKCS#7, или «подпись с расширенными данными для проверки» по ETSI TS 101 733 не может это обеспечить) ввести понятие срока действительности документа, включая механизмы экстренного признания размещенной в контейнере информации недействительной. Данное уникальное свойство может быть использовано при выпуске электронных разрешений, например, импортно карантинные разрешения, лицензии (в том числе и на программное обеспечение) и т.п.

1. Атрибутные сертификаты, связанные с сертификатом открытого ключа

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

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

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

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

Области использования.

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

Следующий пример, ниже приведён слайд из презентации нашего партнёра Unizeto Technologies S.A. демонстрирующий способ указания полномочий автора ЭЦП при использовании квалифицированных сертификатов физических лиц и реестра полномочий для юридического лица, нечто аналогичное у нас ЕГЮРЛ, в котором зафиксированы сотрудники юрлица имеющие право выступать от имени юрлица без доверенности.

Для клиент-серверных решений АС могут использоваться и для субъекта и для объекта доступа. протокол получения АС не определен в RFC и может быть любым, например, LDAP(s) или HTTP(s). В общем случае АС могут применяться не только в клиент-серверных системах, например, АС может содержаться в S/MIME контексте и в этом случае участники почтовой переписки являются и субъектами и объектами доступа одновременно.

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

2. Атрибутные сертификаты, связанные с информационным объектом

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

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

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

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

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

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

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

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

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

Возможные области применения