Как новый ГОСТ изменит рынок СЭД
Накануне нового года в России стало одним ГОСТом больше - Федеральное агентство по техническому регулированию и метрологии РФ утвердило ГОСТ Р ИСО/МЭК 26300-2010, в котором в качестве стандартного формата для офисных приложений определен Open Document Format (ODF). Документ идентичен принятому четыре года назад международному стандарту ISO/IEC 26300:2006. Что это дает индустрии электронного документооборота?
В основном, это все. Достаточно ли этого пользователям? Увы, их никто не спрашивает. Многие СЭД вообще работают с электронными документами только в режиме "выписка-возврат", когда сначала нужно получить документ из системы, сохранить его локально на своем диске и потом уже открыть на редактирование. При сохранении — обратная процедура, отредактированный файл нужно загрузить в систему.
Таким образом, получается, что вся работа с документом, с его содержательной частью происходит вне системы документооборота, на рабочей станции пользователя при помощи текстового процессора. Какой в таком случае смысл тогда говорить о безопасности СЭД, разграничении доступа и контроле? Пользователь в это время имеет полный контроль над документом, и его действия системой не протоколируются.
Разработчикам СЭД стоит пересмотреть свою позицию и начать считать средства редактирования документов неотъемлемой частью системы документооборота - только тогда можно будет говорить о комплексной безопасности и контроле.
Разнобой форматов отнюдь не способствует реализации этого подхода, разработка такой тесной интеграции с каждым приложением может оказаться накладной. Но переход к единому формату сильно упрощает задачу.
Взять хотя бы внутренние документы — пожалуй, на 90% это служебные записки, заявления, заявки, сопроводительные письма, протоколы совещаний и другие документы, совершенно непритязательные по части верстки и оформления. Для их создания достаточно будет простого ODF-редактора, встроенного непосредственно в СЭД. Тут вполне можно использовать Open Office, поскольку его лицензия не запрещает создавать производные продукты на его основе.
Что мы подписываем ЭЦП?
Все разговоры о юридической значимости электронного документооборота неизменно переходят в обсуждение проблем ЭЦП — удостоверяющих центров, генерации ключей, алгоритмов, и т.д. При этом редко поднимается вопрос о том, что именно мы подписываем своей ЭЦП. Это просто некий файл, и никто не интересуется, что у него там внутри: считается, раз документ согласован, то его можно подписать.
Достаточно редко поднимается вопрос о том, что именно человек подписывает своей ЭЦП
При этом всем известно, что современные офисные форматы сохраняют в файле документа большое количество сведений, которые может и не следовало бы сообщать другим. Например, это история правки документа, информация об авторе, скрытый текст. Будет ли все это считаться официально подписанным?
Возьмем еще возможность вставлять в документы поля и макросы. Конечно, это удобно и позволяет создавать более красивые материалы. Предположим, в документе есть поле "Текущая дата" - ведь пока идет согласование, может пройти много времени, а так документ всегда актуален. И вот документ подписан "как есть", с полем "текущая дата", отправлен контрагенту. Будучи просмотрен или напечатан, он, формально говоря, будет отличаться от вашей исходной версии.
Макросы могут быть и гораздо более сложными и до неузнаваемости изменить содержимое документа, их присутствие в окончательной редакции вовсе лишнее. Поэтому подписывание электронной подписью документа, который может самоизменяться, носит, вообще говоря, двусмысленный характер – какая именно информация будет считаться подписанной? То, что было первоначально или то что отображается сейчас? Целостность файла при этом не нарушается, проверка ЭЦП покажет его подлинность.
Если продолжать использовать закрытые проприетарные форматы, то этот риск устранить полностью невозможно. Разумеется, есть средства, которые позволяют вычистить всю лишнюю информацию из документа в формате MS Word, но здесь снова придется полагаться только на заявления разработчиков.
Единственно надежным решением будет использование открытого формата ODF, который полностью документирован. Чтобы устранить упомянутые риски, следует использовать некое подмножество этого формата, которое допускает наличие только тех XML-тэгов, которые безопасны и не могут изменять содержание документа. А перед подписанием нужно будет проверить документ на соответствие этому подмножеству стандарта, что должно делаться встроенными средствами СЭД.
Настоящий электронный документооборот
Полноценный электронный документооборот невозможен, пока мы не определимся с тем, что такое электронный документ. И тут не стоит смотреть в сторону законодателей, на их уровне сделано достаточно (см., например, 227-ФЗ), у нас есть право подавать в электронном виде самые разнообразные документы. Но если не спуститься на уровень ниже и не решить все технические вопросы, то проблем не избежать. Будет ли документ считаться принятым, если он не читается — например, гражданин пришлет заявление в ODF, а в организации стоит только MS Word и не настроен конвертер?
Или продвинутое ведомство пришлет ответ в новом формате docx, а у гражданина только старенькая Windows XP, и он вовсе не ИТ-специалист и не может самостоятельно установить все нужные компоненты, чтобы прочитать этот ответ.
А любая лишняя итерация — это сроки, и часто бывает, что важен каждый день. И что считать здесь произволом чиновников, а что разумными техническими требованиями?
Говоря об электронных документах, все почему-то зацикливаются на проблеме обеспечения их аутентичности и дальше темы ЭЦП не идут, забывая о том, что стандарт ГОСТ ИСО 15489 подразумевает также то, что документ должен обладать свойством "возможность использования", т. е. быть прочитан, напечатан или воспроизведен иным образом.
И еще один тезис следует принять во внимание. Согласно определению закона, "документ – информация, зафиксированная с реквизитами, позволяющими ее идентифицировать". Для бумажного документа все просто – все реквизиты есть прямо на нем — подпись, дата, все, что положено.
А с электронными документами — беда. Файл с текстом отдельно, реквизиты отдельно. И где гарантии, что в процессе обработки ничего не потеряется и не перепутается?
Так почему бы не инкапсулировать метаданные в документ, расширив описание формата набором тегов, которые нужны для хранения реквизитов документа? Это также можно было бы сделать на основе принятого стандарта на формат ODF. Тогда электронный документ стал бы более цельным, отпала бы необходимость передавать его реквизиты отдельно.
Короткая ссылка на материал: //cnews.ru/link/a2524
