(Окончание, предыдущую часть см. http://rusrim.blogspot.com/2011/11/ii.html )
Целостность электронных документов
Пункты 9 и 10 требуют обеспечить целостность электронных документов. При использовании ЭЦП/усиленной электронной подписи для этого используется значение хеш-функции. Однако в тех случаях, когда электронный документ не подписывается ЭЦП/усиленной ЭП (например, если используется простая электронная подпись), нужно быть готовыми ответить на вопрос о том, какие механизмы обеспечения целостности применяются в системе.
Управление многокомпонентными документами
Пункт 13 предусматривает, что СЭД должна обеспечить ввод всех компонент многокомпонентного электронного документа, и дальнейшее управление таким документом как единым целым. В требованиях MoReq, откуда взята эта формулировка, в первую очередь здесь имелись в виду сообщения электронной почты с приложениями и веб-страницы с графическими изображениями и другими отдельными элементами.
Документирование результатов проверки ЭЦП/ЭП
Пункт 15 содержит требование, которое, скорее всего, в данный момент в большинстве систем не реализовано:
Очень серьёзные требования к сбору и хранению контрольной информации содержатся в пп.17-18. Тем производителям ПО, у которых подобные возможности не реализованы, предстоит выполнить существенные доработки:
Резервное копирование
Серьёзные требования по поддержке резервного копирования содержатся в п.32 (правда, допускается их выполнение за счет интеграции с другой системой).
Терминология
В заключение скажу и о проблеме терминологии. Мне использованная в требованиях терминология представляется, в целом, удачной. Однако я уверена, что ряд терминов (классификационная схема, метаданные, контрольная информация и т.д.) пока ещё непривычен для многих наших специалистов, поэтому Минкомсвязи следует подумать о проведении в этом направлении определенной разъяснительной работы. В ряде случаев желательно на примерах пояснить, что конкретно имеется в виду.
Источник: Консультант Плюс
http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=121840
Целостность электронных документов
Пункты 9 и 10 требуют обеспечить целостность электронных документов. При использовании ЭЦП/усиленной электронной подписи для этого используется значение хеш-функции. Однако в тех случаях, когда электронный документ не подписывается ЭЦП/усиленной ЭП (например, если используется простая электронная подпись), нужно быть готовыми ответить на вопрос о том, какие механизмы обеспечения целостности применяются в системе.
Управление многокомпонентными документами
Пункт 13 предусматривает, что СЭД должна обеспечить ввод всех компонент многокомпонентного электронного документа, и дальнейшее управление таким документом как единым целым. В требованиях MoReq, откуда взята эта формулировка, в первую очередь здесь имелись в виду сообщения электронной почты с приложениями и веб-страницы с графическими изображениями и другими отдельными элементами.
Документирование результатов проверки ЭЦП/ЭП
Пункт 15 содержит требование, которое, скорее всего, в данный момент в большинстве систем не реализовано:
15. Для проверки аутентичности, целостности и достоверности электронных документов СЭД ФОИВ должна обеспечивать:Сбор и хранение контрольной информации (протоколов аудита)
...хранить результат проверки электронной подписи в виде метаданных электронного документа;
Очень серьёзные требования к сбору и хранению контрольной информации содержатся в пп.17-18. Тем производителям ПО, у которых подобные возможности не реализованы, предстоит выполнить существенные доработки:
17. СЭД ФОИВ должна обеспечивать фиксирование контрольной информации с целью выявления и отслеживания действий, на которые у пользователя СЭД ФОИВ нет разрешений (прав) на выполнение.Пункт 18 дополнительно ужесточает эти положения.
При этом СЭД ФОИВ должна обеспечивать соответствие сроков хранения контрольной информации и протоколируемых действий срокам хранения документа.
СЭД ФОИВ должна сохранять в защищённом от изменений виде следующую контрольную информацию:
В число действий, фиксируемых в составе контрольной информации, должны входить:
- обо всех действиях, совершённых с документами или наборами документов, проектами документов, классификационной схемой;
- о пользователе СЭД ФОИВ, выполнившим действие;
- о дате и времени совершения действия.
- ввод в СЭД ФОИВ документов, проектов документов;
- перемещение раздела (подраздела) в классификационной схеме;
- любые изменения в указаниях по срокам хранения и последующим действиям с документами;
- любые действия, выполненные администратором СЭД ФОИВ в ходе экспертизы ценности документа, проводимой в соответствии с Федеральным законом от 22 октября 2004 г. № 125-ФЗ «Об архивном деле в Российской Федерации» (Собрание законодательства Российской Федерации, 2004, № 43, ст. 4169; 2006, № 50, ст. 5280; 2007, № 49, ст. 6079; 2008, № 20, ст. 2253; 2010, № 19, ст. 2291; № 31, ст. 4196);
- наложение и снятие запрета на уничтожение раздела (подраздела) классификационной схемы;
- любые изменения метаданных классификационной схемы, разделов и документов;
- внесение изменений и уничтожение метаданных пользователем СЭД ФОИВ;
- изменения прав доступа;
- создание, модификация и уничтожение пользователя СЭД ФОИВ или группы пользователей СЭД ФОИВ;
- передача документов;
- уничтожение документов;
- печать документа или метаданных.
Резервное копирование
Серьёзные требования по поддержке резервного копирования содержатся в п.32 (правда, допускается их выполнение за счет интеграции с другой системой).
Терминология
В заключение скажу и о проблеме терминологии. Мне использованная в требованиях терминология представляется, в целом, удачной. Однако я уверена, что ряд терминов (классификационная схема, метаданные, контрольная информация и т.д.) пока ещё непривычен для многих наших специалистов, поэтому Минкомсвязи следует подумать о проведении в этом направлении определенной разъяснительной работы. В ряде случаев желательно на примерах пояснить, что конкретно имеется в виду.
Источник: Консультант Плюс
http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=121840
Наталья Александровна! Прошло уже достаточно времени, чтобы сделать вывод о практической ценности данного документа. Прежде всего интересует, повлиял ли он как-то на производителей СЭД, на требования ОГВ к СЭД при создании, внедрении, сопровождении и появились ли в СЭД тот функционал, которого не было до выхода данного приказа, а так же вообще целесообразно ли учитывать данный приказ, работая в качестве поставщика, внедренца, сопровождающей организации по СЭД в ОГВ?
ОтветитьУдалить…повлиял ли он как-то на производителей СЭД, на требования ОГВ к СЭД при создании, внедрении, сопровождении и появились ли в СЭД тот функционал, которого не было до выхода данного приказа … ?
ОтветитьУдалитьНет, не повлиял. Как, впрочем, и ожидалось :(
… целесообразно ли учитывать данный приказ, работая в качестве поставщика, внедренца, сопровождающей организации по СЭД в ОГВ?
Учитывать - целесообразно, поскольку что, во-первых, большинство требований вполне разумные, и, во-вторых, рано или поздно (скорее даже рано) аналогичные требования будут сформулированы снова, но уже всерьёз – с контролем исполнения и соответствующими санкциями.