Электронный документооборот, ЭЦП и интеграция систем. Философские выводы за бокальчиком вина

    При организации взаимодействия систем, принадлежащих различным организациям, возникают вопросы по реализации интеграции ИС и юридическо – правового плана. Хотелось бы поделиться небольшим опытом и выводами, полученными в проектах такого плана. Информация может показаться интересной аналитикам, проектировщикам, разработчикам и может интересующимся руководителям.


    Первое отступление.



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

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

    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 и пр.), который посылает клиент – есть аналог своего бумажного запроса, письма с текстом «Просим вас предоставить информацию … блаблабла». И ответ тоже является документом.

    И что же делать?



    Использовать модель бумажного документооборота. Для этого можно применить технологию асинхронных веб — сервисов. Не в плане многопоточности. Очень простенько на рисунке:

    image

    Технически, должны проводится следующие шаги:

    1. Запрашивающая сторона формирует запрос с необходимыми параметрами. Запрос подписывается ЭЦП и к нему прикрепляется «временная метка». Запрос сохраняется в журнале отправленных запросов и посылается отвечающей стороне.
    2. Отвечающая сторона принимает запрос, проверяет отправителя запроса, правильность подписания, метку времени и входные параметры запроса, сохраняет запрос в журнале входящих запросов, передает запрос на последующую обработку в ИС и отвечает Запрашивающей стороне подписанным ЭЦП и с меткой времени сообщением, о принятии запроса в обработку.
    3. Запрашивающая сторона проверяет сообщение о принятии запроса в обработку на правильность подписания и метку времени, сохраняет сообщение и помечает запрос, который она отправляла как принятый в обработку.
    4. Отвечающая сторона после формирования ответа подписывает его, добавляет метку времени, сохраняет ответ в журнале отправленных ответов, и посылает ответ запрашивающей стороне.
    5. Запрашивающая сторона принимает ответ, проверяет отправителя ответа, правильность подписания, метку времени, сохраняет ответ, помечает запрос в журнале отправленных запросов как отработанный, передает данные из ответа в ИС и отвечает Отвечающей стороне подписанным ЭЦП и с меткой времени сообщением, о принятии ответа.
    6. Отвечающая сторона проверяет сообщение о принятии ответа на правильность подписания и метку времени, сохраняет сообщение и помечает запрос в журнале принятых запросов как отработанный, а ответ как доставленный.

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

    1. Сертификаты для генерации подписи должен быть выданы/заверены аккредитованным удостоверяющим центром (у нас в РК есть единый «НУЦ» — национальный) ответственному за ИС лицу, с правом подписи документов от ЮЛ – владельца ИС.
    2. Сертификаты для установления SSL соединения тоже должны быть выданы/заверены аккредитованным удостоверяющим центром.
    3. Для генерации ЭЦП используется сертифицированный криптопровайдер, формирующий подпись согласно утвержденному ГОСТу.

    И в качестве послесловия.


    Надеюсь, что кому то данная статья будет нужной и поможет при принятии решений. И надеюсь, что предложенный метод рано или поздно закрепят каким-нибудь нормативно-правовым актом для того, чтобы возникало как можно меньше непониманий при использовании электронного документооборота. Буду писать Медведеву (смайлик). У меня же будет ещё не один проект по интеграции ИС, так что могут появиться новые топики с описанием типовых ошибок и систематизированных рисков, присущих данным проектам.
    И да. Может кому-нибудь показаться стиль изложения абсолютно нечитаемым. Ну уж простите, так мозг устроен.
    Поделиться публикацией

    Комментарии 8

      0
      А вот в плане работы веб-сайта, подпись запросов — это каждый http запрос, грубо говоря подписывать надо или как? Извините, если некорректно вопрос поставил, я не особо в теме.
        0
        В плане работы веб сайта подписывать ничего не надо, потому что никто от вас этого не требует (я считаю это требование абсурдным). Если вы хотите выкладывать подписанные документы, то к документу вы должны прикладывать хеш документа, подпись, метку времени и публичный сертификат. Это необходимо для доказательства подписи документа, существования подписи документа на какой то момент времени и подписавшего.
        Если кратко, то как-то так.
        0
        Я не согласен с Вашей схемой, что будет если клиент не имеет внешнего адреса, как сервер запросит у него подтверждение получения ответа?
        Предлагаю немного другую схему:
        1) клиент запрашивает данные
        а) сервер вернул нужные данные — регистрируем получение ответа
        б) сервер либо недоступен, либо вернул неверные данные — регистрируем результат (с уведомлением клиента о неудачной попытке, и сервера по другому каналу связи)
        2) клиент отправляет подтверждение о получении ответа серверу
        Таким образом каждый из них будет иметь полную информацию о текущем состоянии процесса.
          0
          Все проблемы о которых я говорил имеются:
          1. Клиент может не доказать, что его запросы не принимаются или не обрабатываются.
          2. Соответственно сервис может утверждать, что к нему запросы не поступали.
          3. Сервис может утверждать, что ответы не приходят в связи с проблемами транспортной среды при длительной обработке запроса.
          4. Сервис может утверждать, что ответы он отправляет, но клиент их не получает или не сохраняет.
          5. Клиент может утверждать, что ответы он не получает.

          Например: Мы запросили отчет, на формирование которого уходит продолжительное время или вообще обработка происходит во время появления свободных мощностей. За это время вероятность обрыва tcp сессии велика. Плюс если сервер тупо не отвечал клиенту (рушился без какого либо ответа во время обработки запроса и закрывал сессию) и фигушки вы докажите, что позавчера я принимал запросы, но не обрабатывал их. В то же время процедура приема сообщения и ответа о принятии настолько проста по сравнению с остальными обработками, что вероятность появления ошибки в ней меньше на много порядков.

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

          Суть проблемы не простое техническое решение, а максимально непретензионное со стороны других лиц. Ещё раз перечитайте пожалуйста бумажный вариант и проблемы в простой технической реализации. Ии разжуйте мне, чего я не понимаю в вашем варианте.

          0
          Неудивительно слышать такие вещи о нашем электронном правительстве. Я знал, что и с подписями у них не все гладко, раз с простыми паролями такая фигня…
            0
            Никаких проблем с подписями нет. Все подписывается так, как должно по мнению разработчиков.
            0
            А можно вопрос: работает ли ЭЦП в линуксе?
              0
              Работает, если у вас есть криптопровайдер или сдк с функционалом криптопровайдера.
              Ну и если понудить: ЭЦП не работает, оно формируется. Работает криптопровайдер. Ему нужен сертификат.
              Сертификат это не ЭЦП. ЭЦП если совсем просто — это набор символов.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое