При организации взаимодействия систем, принадлежащих различным организациям, возникают вопросы по реализации интеграции ИС и юридическо – правового плана. Хотелось бы поделиться небольшим опытом и выводами, полученными в проектах такого плана. Информация может показаться интересной аналитикам, проектировщикам, разработчикам и может интересующимся руководителям.
Первое отступление.
Первый раз столкнулся с ЭЦП в своей деятельности, работая над аукционной площадкой. Требование подписывать документы появилось из-за возможного варианта отказа победителя от оплаты выигранного аукциона на повышение (английский метод) с последующим требованием возврата страхового депозита (гарантийного платежа). Аналитики вообще слабо представляли, как это все должно происходить, поэтому пришлось разбираться с одним умным разработчиком, вдаваясь в некоторые юридические подробности. И не факт, что я правильно понял все технические моменты.
Второй раз столкнулся в проекте по доработке государственной системы в роли аналитика но, ни программисты, ни руководитель проекта, не понимая сути проблемы, пошли по наилегкому пути, причем первые думали, что поступают правильно, а второй для укладывания в сроки, получается, обманул Заказчика.
Для последующей работы в этой сфере пришлось собраться старой компании за маленьким столиком и немного пообсуждать проблему.
Второе отступление, в котором немного сути
У нас, в РК, сейчас довольно актуальны проекты по интеграции различных систем с использованием веб-сервисов. Различные системы посылают друг другу запросы на получение информации и получают ответы, содержащие необходимую информацию, на свои запросы. И прежде чем переходить к сути проблемы рассмотрим абсурдный пример:
Аэрокосмическое агентство хочет быстро получить информацию об учете в наркодиспансере потенциального космического туриста. Департамент по учету наркоманов владеет базой лиц, состоящих на учете. Какие действия будут происходить:
1. Сотрудник Агентства пишет письмо с запросом в Департамент, указывая данные потенциального туриста, подписывает его у уполномоченного лица, ставит печать, регистрирует исходящий номер у делопроизводителя и отправляет по факсу/письмом, с просьбой тут же отправить факс/письмо с указанием входящих номера и даты письма.
2. Секретарь Департамента принимает письмо, регистрирует в специальном журнале, присваивая номер и дату, направляет письмо по неопределенному маршруту на исполнение и отсылает в Агентство входящий номер и дату письма.
3. Сотрудник Агентства получает входящий номер и дату, и занимается своими делами, с уверенностью, что его запрос исполнят.
4. Сотрудник департамента проверяет наличие в базе/картотеке потенциального туриста и пишет письмо с ответом на запрос, указанием идентификационных сведений запроса, подписывает, ставит печать, регистрирует исходящий номер у делопроизводителя и отправляет по факсу/письмом. И в идеале запрашивает входящий номер и дату на свой ответ.
5. Секретарь Агентства принимает письмо, регистрирует входящий номер и дату письма, направляет письмо запросившему сотруднику. И в идеале отправляет входящий номер и дату в Департамент.
Для чего нужны все эти с виду бюрократические процедуры:
1. Агентство знает, что запрос пришел и должен поступить в обработку.
2. Агентство может предпринять какие либо действия, если не получило ответ в установленный срок.
3. Агентство может предпринять какие-либо действия, если ответ содержал некорректные данные.
4. Агентство всегда может отчитаться комиссии по запросам, которые они посылали и ответам, которые они получали.
5. Департамент может утверждать, что запрос не был получен, если они его не получали и не регистрировали.
6. Департамент может утверждать, что ответ на запрос был получен Агентством.
7. Департамент может отчитаться за сроки отправки ответа на запрос.
8. Департамент может утверждать, что ответ был получен именно в том виде, в котором они его отправили.
9. Департамент может отчитаться комиссии по правам наркоманов за все ответы, которые они давали, с указанием запросивших.
Т.е. все эти процедуры уменьшают непонимания, недоразумения и взаимные обвинения двух сторон и они необходимы для решения спорных моментов. Рассматривая аналогию взаимодействия информационных систем, мы снижаем риски при функционировании информационных систем.
Как же все происходит в окружающем меня бардаке.
На деле я вижу ситуацию, когда в большинстве случаев происходит интеграция двух систем с использованием одного веб-сервиса и одного клиента веб-сервиса. При этом чаще всего происходят следующие действия:
1. Клиент устанавливает защищенное соединение с использованием сертификата, выданного аккредитованным удостоверяющим центром (АУЦ) и отправляет запрос.
2. Сервис делает непонятные проверки (в плане того, что иногда не обладающие нужными знаниями разработчики умудряются сделать отнюдь не все проверки, но будут доказывать, что все работает правильно) по авторизации и идентификации пользователя, формирует ответ, подписывает ответ электронной цифровой подписью ответственного лица (тут тоже могут быть нюансы) и отправляет ответ клиенту. Все происходит синхронно в рамках одной сессии.
3. Клиент получает ответ, сохраняет его (может даже не проверять корректность ЭЦП, и такое видели) и заносит данные в свою систему (иногда даже сохраняя ссылку на сохраненный запрос, и это тоже видели).
Проблемы, которые я вижу:
Если наши разработчики неполные ландухи, то при функционировании системы у нас всплывают следующие проблемы, решенные в бумажном документообороте, приведенном выше:
1. Клиент может не доказать, что его запросы не принимаются или не обрабатываются.
2. Соответственно сервис может утверждать, что к нему запросы не поступали.
3. Сервис может утверждать, что ответы не приходят в связи с проблемами транспортной среды при длительной обработке запроса.
4. Сервис может утверждать, что ответы он отправляет, но клиент их не получает или не сохраняет.
5. Клиент может утверждать, что ответы он не получает.
6. Комиссия, при расследовании какого-либо инцидента не может проверить все запросы различных клиентов на правомерность и ответы на эти запросы.
А если наши разработчики ландухи, то тут вообще до подсудного дела дойти может. Так что все держится, по моему мнению, на доверии и на том, что пока никто не хочет поднимать данную проблему.
Я считаю, что должно быть так …
Что нам гласит закон о ЭЦП и документообороте:
Закон Республики Казахстан от 07.01.2003 N 370-II «Об электронном документе и электронной цифровой подписи»
Глава 2. Электронный документ
Статья 7. Требования к электронному документообороту
1. Электронный документ может быть создан, передан, сохранен и подан электронными средствами. Электронный документ, соответствующий требованиям настоящего Закона, равнозначен документу на бумажном носителе.
2. Электронный документ считается отправленным с момента его передачи по информационно-коммуникационной сети.
3. Входящий электронный документ считается поступившим после его фиксации в информационной системе адресата.
4. Уведомление о получении должно содержать данные о факте и времени получения электронного документа и его отправителе. В случае непоступления его автору считается, что документ не получен адресатом.
(Тут все опять вспомнили, что я из РК. Что делать, местные законы есть под рукой, аналогичный закон РФ немного неаналогчен, и если кто-то сможет покопать в данном направлении, буду рад. Скорее всего, что где-нибудь найдутся похожие или аналогичные требования.)
Причем здесь документооборот, можете спросить вы. Притом, что запрос (SOAP, XML RPC и пр.), который посылает клиент – есть аналог своего бумажного запроса, письма с текстом «Просим вас предоставить информацию … блаблабла». И ответ тоже является документом.
И что же делать?
Использовать модель бумажного документооборота. Для этого можно применить технологию асинхронных веб — сервисов. Не в плане многопоточности. Очень простенько на рисунке:
Технически, должны проводится следующие шаги:
1. Запрашивающая сторона формирует запрос с необходимыми параметрами. Запрос подписывается ЭЦП и к нему прикрепляется «временная метка». Запрос сохраняется в журнале отправленных запросов и посылается отвечающей стороне.
2. Отвечающая сторона принимает запрос, проверяет отправителя запроса, правильность подписания, метку времени и входные параметры запроса, сохраняет запрос в журнале входящих запросов, передает запрос на последующую обработку в ИС и отвечает Запрашивающей стороне подписанным ЭЦП и с меткой времени сообщением, о принятии запроса в обработку.
3. Запрашивающая сторона проверяет сообщение о принятии запроса в обработку на правильность подписания и метку времени, сохраняет сообщение и помечает запрос, который она отправляла как принятый в обработку.
4. Отвечающая сторона после формирования ответа подписывает его, добавляет метку времени, сохраняет ответ в журнале отправленных ответов, и посылает ответ запрашивающей стороне.
5. Запрашивающая сторона принимает ответ, проверяет отправителя ответа, правильность подписания, метку времени, сохраняет ответ, помечает запрос в журнале отправленных запросов как отработанный, передает данные из ответа в ИС и отвечает Отвечающей стороне подписанным ЭЦП и с меткой времени сообщением, о принятии ответа.
6. Отвечающая сторона проверяет сообщение о принятии ответа на правильность подписания и метку времени, сохраняет сообщение и помечает запрос в журнале принятых запросов как отработанный, а ответ как доставленный.
Данный подход позволяет организовать обмен данными с максимальной юридической ответственностью сторон и быстро диагностировать проблемы при передаче. Вместо того, чтобы ругаться межу собой, руководители интеграции с обеих сторон будут четко знать, на каком этапе произошел сбой.
И для придания всему этому юридической силы:
1. Сертификаты для генерации подписи должен быть выданы/заверены аккредитованным удостоверяющим центром (у нас в РК есть единый «НУЦ» — национальный) ответственному за ИС лицу, с правом подписи документов от ЮЛ – владельца ИС.
2. Сертификаты для установления SSL соединения тоже должны быть выданы/заверены аккредитованным удостоверяющим центром.
3. Для генерации ЭЦП используется сертифицированный криптопровайдер, формирующий подпись согласно утвержденному ГОСТу.
И в качестве послесловия.
Надеюсь, что кому то данная статья будет нужной и поможет при принятии решений. И надеюсь, что предложенный метод рано или поздно закрепят каким-нибудь нормативно-правовым актом для того, чтобы возникало как можно меньше непониманий при использовании электронного документооборота. Буду писать Медведеву (смайлик). У меня же будет ещё не один проект по интеграции ИС, так что могут появиться новые топики с описанием типовых ошибок и систематизированных рисков, присущих данным проектам.
И да. Может кому-нибудь показаться стиль изложения абсолютно нечитаемым. Ну уж простите, так устроен.
