Инфраструктура простой электронной подписи. Часть 2: Моделирование целевой системы

в 11:47, , рубрики: IT-стандарты, анализ, Анализ и проектирование систем, инфраструктура, моделирование, простая электронная подпись, Разработка под e-commerce, Системная инженерия, целевая система

Инфраструктура простой электронной подписи. Часть 2: Моделирование целевой системы - 1
В предыдущей части была построена диаграмма использующих систем в проектируемой инфраструктуре ПЭП. Следующим этапом необходимо проанализировать целевую систему в этой инфраструктуре. Целевой системой у нас является ПЭП, которая, согласно законодательству, является аналогом личной собственноручной подписи. Поэтому дальнейший анализ будет вестись как для личной собственноручной подписи, так и для ПЭП.

Целевая система в использующей системе контрагента

С технической точки зрения, собственноручная подпись представляет собой выработанный двигательный навык определенного движения рукой, в результате которого визуализируется траектория движения руки в виде монограммы с необязательными дополнительными элементами – росчерками и штрихами. По монограмме система делопроизводства получает информацию о персональных данных (ПД), т.е. по виду монограммы она может идентифицировать, кто именно создал монограмму. Двигательный навык руки, по сути, это записанная в мозг цепочка команд для мышц руки. Таким образом, элементами собственноручной подписи являются: человек, мозг, навык, рука, визуальная монограмма. Если рассмотреть все эти элементы, то можно сформировать следующую модель элементов системы собственноручной подписи:

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

Функция системы собственноручной подписи – передача информации о ПД субъекта с помощью закрытого и открытого ключей. Это важный момент. Подпись – это передача информации о ПЕРСОНАЛЬНЫХ ДАННЫХ. Если открытый ключ никак не связан с ПД, если по открытому ключу невозможно определить ПД, то этот открытый ключ НЕ будет аналогом собственноручной подписи, и поэтому такой открытый ключ НЕ будет юридически значимой подписью. Это просто сообщение, но никак не подпись. Бытует ошибочное мнение, что любой логин/пароль – это простая электронная подпись пользователя. Это не так, до тех пор, пока логин/пароль не свяжутся с ПД.

С учетом вышесказанного, контрагент на диаграмме использующих систем — это субъект ПД, обладающий системой, которая формирует сообщение о ПД с использованием закрытого и открытого ключей. Субъект – это стейкхолдер, его интересы мы должны будем учесть при проектировании. На диаграмме мы не указываем стейкхолдера, поэтому контрагентом у нас выступает система формирования сообщения о персональных данных, элементами которой выступают собственно ПД, а также системы открытого и закрытого ключей. Контрагент показан на следующей диаграмме:
Инфраструктура простой электронной подписи. Часть 2: Моделирование целевой системы - 2

Эта модель несколько абстрактна, так как в ней нет элементов, существующих в реальных системах подписи – монограммы для собственноручной подписи, ключей ПЭП или сертификатов электронно-цифровой подписи. Это пока еще метамодель. Для того, чтобы метамодель стала моделью, нам необходимо показать конструктивные элементы целевой системы. Диаграмма несколько видоизменится, так как в реальности у подписи существует несколько архитектурных решений.
Инфраструктура простой электронной подписи. Часть 2: Моделирование целевой системы - 3На этой диаграмме показаны несколько архитектурных решений, выполняющих одну и ту же функцию. Каждое техническое решение в реальности – конструктивный модуль, существование которых предполагается у контрагента.

Разберем подробнее конструктивное решение для ПЭП, а именно систему использования закрытого ключа для передачи открытого ключа – это наша целевая система. В первую очередь нужно ответить на вопрос – что такое «закрытый ключ» ПЭП? Как следует из определения ПЭП в ФЗ-63 – это код или пароль, то есть набор определенных символов. Исходя из того, что мы проектируем аналог собственноручной подписи, то закрытый ключ должен быть известен исключительно контрагенту, аналогично как правильный двигательный навык руки в собственноручной подписи известен только контрагенту. Закрытый ключ является конфиденциальными данными ПЭП и, согласно ФЗ-63, владелец конфиденциальных данных подписи несет ответственность за сохранение конфиденциальности. Знание закрытого ключа дает доступ к использованию системы передачи открытого ключа. В целом, не очень важно, что используется в качестве открытого ключа ПЭП, при соблюдении трех условий:

  1. Доступ к системе передачи открытого ключа, т.е. к процессу подписания, можно получить, только с помощью закрытого ключа и никак иначе;
  2. Открытый ключ должен быть уникален. Тем самым достигается связь «один-к-одному» персональные данные – закрытый ключ – открытый ключ;
  3. Для каждого документа открытый ключ должен передаваться отдельно, как это происходит с собственноручной подписью. Одна передача ключа для нескольких документов не допускается, если это не один файл-архив;

ФЗ-63 в статье 12 пункт 2 предъявляет к системе передачи открытого ключа дополнительные условия:

  1. Создавать электронную подпись только после подтверждения лицом, подписывающим электронный документ, операции по созданию электронной подписи;
  2. Однозначно показывать, что электронная подпись создана;

При этом, согласно статьи 9 ФЗ-63, данные условия не распространяются на простую ПЭП. Это делает невозможным доказательство факта подписания, что негативно влияет на значимость подписи. В техническом решении рекомендуется выполнить все условия статьи 12 пункт 2 ФЗ-63, даже если это необязательно.

На практике, в качестве ключей обычно используются следующие решения:

  1. Логин/пароль к личному кабинету в информационной системе. Пароль выступает в качестве закрытого ключа, логин – в качестве открытого. Это допустимое решение в случае, если при выдаче логина/пароля обязательно установлена связь с ПД. Но, как говорилось выше, необходимо, чтобы закрытый ключ подписи давал доступ только к системе передачи открытого ключа. Поэтому очень желательно при подписании добавить два дополнительных ключа – номер телефона и код SMS подтверждения. Номер телефона, сам по себе являясь ПД, выступает в качестве дополнительного открытого ключа, в дополнение к логину, а код подтверждения становится дополнительной частью закрытого ключа и дает доступ к системе передачи открытого ключа – т.е. возможность подписания.
  2. Использование электронного почтового ящика. Адрес электронной почты – открытый ключ, пароль к почтовому ящику – закрытый ключ. Это допустимое решение для ПЭП в целом, при условии, что будет установлена однозначная связь адреса электронной почты с ПД. Но не очень хорошее решение для юридически значимой ПЭП, так как имеет много ограничений на подписание иных документов, кроме собственно переписки. Вложения не могут считаться подписанными значимой ПЭП, по той причине, что каждый документ, если это не архив в одном файле, должен подписываться отдельно, как это происходит с собственноручной подписью. Но письмо с вложением, фактически, включает в себя, как минимум, два документа – само письмо и вложение/вложения. Поэтому подписанным можно считать только письмо, но не вложения. Если этот нюанс не является проблемой, вложений в переписке не будет или подпись вложений не важна, то вполне возможно организовать значимую ПЭП с использованием электронной почты.

Целевая система в использующей системе агента

В системе агента, т.е. в делопроизводстве, при получении документа от контрагента, закрытый ключ не используется, используется только открытый ключ. Открытым ключом, в случае собственноручной подписи, является монограмма. Согласно правил делопроизводства, подпись является реквизитом документа, поэтому использующей системой будет документ. Понятие «реквизиты документа» и какие элементы в него входят, регламентируются двумя нормативными актами:

  1. ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» – для российских документов
  2. 85-ФЗ «Об участии в международном информационном обмене» — для международных документов.

В итоге, для документа, как использующей системы, можно выделить следующие элементы:
Инфраструктура простой электронной подписи. Часть 2: Моделирование целевой системы - 4

Подпись является элементом оформления документа. В целях данного анализа, нас не интересуют все конструктивные элементы оформления, поэтому выделим только два конструктивных элемента оформления: подпись и иные реквизиты. Выше мы определили, что подпись в системе агента – это открытый ключ.
Инфраструктура простой электронной подписи. Часть 2: Моделирование целевой системы - 5

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

  1. Система оформления ВСТРОЕННОГО в документ открытого ключа
    1. Описание архитектуры собственноручной подписи
      1. Система идентификации субъекта персональных данных по монограмме
      2. Монограмма, добавляемая контрагентом в текст документа, согласно правилам делопроизводства агента
    2. Описание архитектуры простой электронной подписи
      1. Система идентификации субъекта персональных данных по кодам простой электронной подписи
      2. Кода подписи в тексте электронного документа, согласно правилам делопроизводства агента
    3. Описание архитектуры электронно-цифровой подписи
      1. Система идентификации субъекта персональных данных по квалифицированному сертификату, неквалифицированному сертификату проверки ключа, иные способы идентификации неквалифицированной подписи.
      2. Информация, добавляемая в электронный документ с помощью криптографических алгоритмов
  2. Система оформления ОТСОЕДИНЕННОГО от документа открытого ключа
    1. Описание архитектуры собственноручной подписи
      1. Система идентификации субъекта персональных данных по монограмме
      2. Монограмма, добавляемая контрагентом в текст особого документа, являющегося приложением к подписываемому документу, согласно правилам делопроизводства агента

    2. Описание архитектуры простой электронной подписи
      1. Система идентификации субъекта персональных данных по кодам простой электронной подписи
      2. Кода подписи в тексте соглашения, оформляемого между агентом и контрагентом согласно действующего законодательства.

    3. Описание архитектуры электронно-цифровой подписи
      1. Система идентификации субъекта персональных данных по квалифицированному сертификату, неквалифицированному сертификату проверки ключа, иные способы идентификации неквалифицированной подписи
      2. Информация, сохраняемая в виде отдельного файла электронно-цифровой подписи

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

Автор: Irkin

Источник

Поделиться

* - обязательные к заполнению поля