Типовые требования к управлению электронными официальными документами (стр. 28 )

Электронная э(29) подпись, в качестве термина, используемого в MoReq2, является формой «усовершенствованной электронной э(29) подписи», как определено в Европейской «Директиве по структуре сообщества для электронных подписей» 1999/93/EC. Усовершенствованная электронная э(29) подпись – это подпись, соответствующая определению в Директиве, а именно такая подпись:

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

Другой, не применяемый здесь, стандарт для структуры электронных э(29) подписей – X.509 (смотри приложение 7).

Примерами широко признанных алгоритмов электронной э(29) подписи являются Алгоритм цифровой подписи – Digital Signature Algorithm (DSA) как определено в FIPS 186-2 (смотри приложение 7) и RSA/SHA-1.

Электронная почта стала по умолчанию средством коммуникации для многих организаций, результат этого – широко распространенное движение документов э(26) и официальных документов э(52) в относительно неконтролируемой обстановке. Использование электронных э(29) подписей для аутентификации э(5) и подтверждения целостности становится по этой причине широко применяемым, особенно там, где это касается официальных документов э(52) деловых транзакций.

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

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

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

№	Требование	Тест
СУЭОД э(32) обязательно должна быть способна захватывать э(8), проверять по требованию и сохранять во время захвата э(8) официального документа э(52) электронные э(29) подписи, относящиеся к ним электронные э(29) сертификаты и данные поставщиков, связанных со службой сертификации.	Д
Это особенно важно, поскольку не всегда будет возможным восстановить данную информацию в более позднее время.
СУЭОД э(32) обязательно должна разрешать ролям администраторов э(1) конфигурировать систему на этапе конфигурации э(20) или позже с целью хранения вместе с официальным документом э(52) метаданных э(40) о верификации (о проверке) официальных документов э(52) с электронной э(29) подписью, включая открытые ключи. Они могут содержать: факт успешного удостоверения; специфическую информацию относительно процесса удостоверения; все удостоверенные данные.	Д
Это особенно важно, поскольку не всегда будет возможным восстановить данную информацию в более позднее время.
СУЭОД э(32) должна иметь основанный на стандартах интерфейс, который позволяет легко подключать и использовать новые технологии электронной э(29) подписи по мере их представления.	Н
Примером подходящей стандартной основы является XML Key Management Spec (XKMS, смотри приложение 7).
Это особенно важно, ввиду происходящих в области электронной подписи изменений.
СУЭОД э(32) должна быть способна выполнять проверку достоверности электронной э(29) подписи, включая сверку сертификата официального документа э(52), во время захвата э(8), со списком отмены электронных э(29) сертификатов и должна сохранять результат проверки в метаданных э(40) официального документа э(52). Она должна выдавать отчет о неверных результатах проверки указанному пользователю э(68) или роли администратора э(1).	Д
Это важно, поскольку не всегда может быть возможно провести эту проверку информации позднее.
Во время захвата э(8) сообщений электронной почты СУЭОД э(32) обязательно должна быть способна автоматически регистрировать и сохранять в качестве метаданных э(40) детали процесса проверки достоверности электронной э(29) подписи, включая: факт того, что достоверность подписи была проверена; личность человека, инициировавшего проверку (где применимо); кем выдан сертификат; серийный номер электронного э(29) сертификата, удостоверяющего подпись; поставщик службы сертификации, которая удостоверила подпись; дата и время, когда произошла проверка.	Д
Это важно, поскольку не всегда может быть возможным восстановить эту информации позднее. Поскольку программное обеспечение меняется, поскольку срок действия сертификатов истекает и поскольку внешние ответственные лица могут перестать осуществлять полномочия, электронные э(29) подписи не могут быть гарантированно удостоверенными длительное время; отсюда это требование регистрировать факт, что подпись была успешно удостоверена.
СУЭОД э(32) должна включать функции, которые демонстрируют, что целостность официальных документов э(52), содержащих электронные э(29) подписи, поддерживается.	Н
Примером этого будет удостоверение электронной э(29) подписи. Такая демонстрация целостности должна применяться даже если роль администратора э(1) произвела уполномоченные изменения в метаданных э(40) официального документа э(52).
Как это достигается, не предопределятся.
СУЭОД э(32) должна быть способна хранить вместе с электронным официальным документом э(31): электронную э(29) подпись(и), ассоциированную с этим официальным документом э(52); электронный э(29) сертификат(ы), удостоверяющий подпись.	Д
Должно быть возможным для администратора э(2) СУЭОД э(32) определить, будет ли СУЭОД э(32) хранить квитанцию о проверке, возвращенную системой, которая проверяла электронную э(29) подпись.	Д
Квитанцию о проверке иногда называют «жетоном / token».
СУЭОД э(32) должна предоставлять возможность роли администратора э(1) применять электронную э(29) подпись к делу э(34) или официальному документу э(52) или передаваемому сообщению во время экспорта э(33) или процесса передачи э(67), чтобы целостность и происхождение дела э(34), документа э(52) или передаваемого сообщения могли быть удостоверены соответствующим образом.	Д
Сообщения о передаче э(67) являются неотъемлемой частю протокола, используемого для управления процессом передачи э(67) между системами.
Электронная э(29) подпись, примененная во время экспорта э(33) или передачи э(67) (см. э10.7.9), должна иметь возможность быть удостоверенной извне, чтобы целостность и происхождение дела э(34), официального документа э(52) или передаваемого сообщения могли быть удостоверены соответствующим образом.	Д
Для этого СУЭОД э(32) обязательно должна быть способна экспортировать э(33) электронный э(29) сертификат с открытыми ключами организации вместе с официальным документом э(52).

Шифрование

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

Требования данного раздела применимы только в случаях, когда есть необходимость обеспечивать работу с зашифрованными официальными документами э(52).

№	Требование	Тест
В случаях, когда электронные официальные документы э(31) отправляются и принимаются в зашифрованном виде при помощи приложения, интегрированного с СУЭОД э(32), система обязательно должна быть способна ограничить доступ к таким официальным документам э(52), предоставив его только пользователям э(68), включенным в список держателей соответствующего ключа дешифровки в дополнение к любым другим ограничениям доступа, соответствующим этим официальным документам э(52).	Д
СУЭОД э(32) обязательно должна быть способна захватывать э(8) и сохранять во время захвата э(8) официального документа э(52) информацию, относящуюся к шифрованию и детали удостоверяющих агентств, связанных с ним.	Д
Если электронный официальный документ э(31) передается в зашифрованном виде приложением, интегрированным с СУЭОД э(32), система должна быть способна хранить как метаданные э(40) вместе с официальным документом э(52) следующую информацию: факт передачи в зашифрованном виде; номер серии электронного э(29) сертификата (где применимо); тип алгоритма; используемый уровень шифрования; дата и время шифрования и/или процесс дешифровки, где применимо.	Д
СУЭОД э(32) должна быть способна гарантировать захват э(8) зашифрованных официальных документов э(52) непосредственно из приложения, которое обладает функциями шифрования.	Д
СУЭОД э(32) должна позволять расшифровывать официальные документы э(52) при импорте э(38) или захвате э(8). Эта функция должна быть настроена ролью администратора э(1) на этапе конфигурации э(20) или позднее.	Д
Эта функция может быть желательна в некоторых больших архивах, когда требуется обеспечить долгосрочное хранение официальных документов э(52) (потому что шифрование привносит риск, что по прошествии долгого времени официальный документ э(52) будет невозможно прочесть). В этом случае организация полагается на протокол аудита э(4) и подобные средства, чтобы доказать при необходимости, что осуществлялось шифрование, а потом шифрование было снято. В других случаях эта функция может быть нежелательной в силу юридических причин. См 5.3 и 3.1 для более детальной информации по перемещению и импорту.
СУЭОД э(32) должна иметь структуру, которая позволяет легко подключать и использовать различные технологии шифрования.	Н

Управление правами на цифровую интеллектуальную собственность

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