`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Михаил Бейрак

Что мы подписываем?

+1111
голосов

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

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

Сразу же были подняты вопросы о достоверности данных на электронных носителях, о необходимости наличия ЭЦП на электронных входящих документах и ответственности тех, кто накладывает ЭЦП. Законодательная база в то время не позволяла разговаривать об ответственности за использование ЭЦП. 

Следующий вопрос, который оказался в центре обсуждения клиентов – что они подписывают. Действительно, каждый из клиентов финансового учреждения готовил первичные финансовые документы в разных программах (от MS Excel и MS Word до разнообразных ERP систем). Каждая из этих систем позволяла просматривать сгенерированные финансовые документы на экране. Но ЭЦП применялось совершенно не к изображению на экране, а к файлу документа. Идентичность одного другому – полностью на совести авторов систем. Проверка такой идентичности – вопрос отдельной сертификации каждой из систем. Т.о. один из выходов из ситуации – использование заранее сертифицированных систем для подготовки электронных документов, использующих ЭЦП.

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

+1111
голосов

Напечатать Отправить другу

Читайте также

На курсе по безопасности, который я в свое время вел, я показал, как обычный текстовый документ, подготовленный в старом-старом Lixicon (еще раз повторю, текстовый!) может допустить разночтения. Если же говорить о документах высокоуровневых форматов (MS Word, Excel, PDF) то там разночтений может быть еще больше.
Вывод. Либо документы идут в формате Plain Text, либо нужна сертифицированная программа по набору и отображению файлов, принятая обеими сторонами. Я не могу себе представиь чтобы ради удобства использования ЭЦП несколько организаций договорились об использовании подобного, явно не бесплатного ПО. А вы?
Microsoft Security Trusted Adviser
MVP Consumer Security

В зависимости от способа подготовки, электронные документы бывают разными.
Бывает что электронны едокументы готовят в тех же системах, в которых принимают. Например - системы электронных платежей. Там все работает замечательно уже много лет.
Бывает что работают с электронными отсканированными изображениями бумажных документов. Тут тоже ЭЦП замечательно работает, потому что изменить изображение сложно.
А вот в остальных случаях об успехах известно мало.

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

С одной стороны да, а с другой? Если ЭЦП используют две и более компаний?
Microsoft Security Trusted Adviser
MVP Consumer Security

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

Способ решения проблемы в текстовых редакторах - имплементация XAdES. Поддерживается в Microsoft Office 2010.

Согласен, практически стандартное решение. Но и текстовые редакторы бывают разные в разных организациях. Процедура замены существующих текстовых редакторов на Microsoft Office 2010 во всех организациях, которые хотят использовать электронные документы с ЭЦП, выглядит решением проблемы. Но стоимость ....

Вопрос стоимости я комментировал вот здесь: http://ko.com.ua/node/43283
и здесь: http://ko.com.ua/node/43942
Либо универсальное решение (как Microsoft Office 2010), либо специализированное. Один вопрос - где они, специализированные решения?

Большое спасибо автору - вопрос из ряда очевидных после. Однако проблема.
Обсуждение, по-моему, ушло в сторону. Проблема - в обеспечении гарантированного однозначного соответствия изображения объекта на экране и в долговременной энергонезависимой памяти.
На мой взгляд, программное решение в данном случае неразумно - при сколь угодно глубокой сертификации кода для закрытых систем останется проблема соответствия код-исполняемый файл (сертифицированный код - данная версия исполняемого файла), для открытых - корректность в этом отношении операции компиляции... и ad infinitum. Примеры компроментации тщательно сертифицированных на уровне кода систем за счет присутствия постороннего софта также, увы, неединичны.
Более рациональным выглядит решение на уровне железа - аппаратный "отображатель" области... (условно) диска на экран.
Мимо ОС. Мимо вирусов. Мимо "имплементаций" (XAdES гарантирует неизменность файла и возможность верификации подписи независимо от устойчивости алгоритма, но не его соответствие тому что видел подписывавший - или я не прав?). "Высокоуровневые" лабильные форматы с посторонней информацией очевидно невыгодны.
Но - необходима стандартизация неинтеллектуального аппаратного интерфейса носитель-экран.

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

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

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

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

Тут было бы полезно уточнить, что в этом документе содержится и насколько может быть разнообразным его содержимое. И, вообще, зачем нужно приносить сразу в двух видах.
Если сдается отчетность по ограниченному количеству стандартных форм - XML в руки, плагин для экпорта или шаблон+конвертор в каждое приложение, и подпись на конечный XML-файл с существенными данными. Заодно, следующим логичным шагом будет какой-нибудь EDI. :)
Если же документ может быть произвольным, такой подход не подойдет, тут лучше всего, действительно, скан бумажного документа. Хотя, возникает вопрос, зачем вообще нужно приносить электронную копию такого документа, если данные из неё вытащить практически невозможно (т.к. документ произвольный) - гораздо проще класть под сканер сразу при его сдаче и подписывать изображение ЭЦП сотрудника, принявшего бумагу.

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

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT