В части 1, части 2, части 3 были рассмотрены основные системы инфраструктуры ПЭП. В этой части будет рассмотрен порядок проектирования для практической реализации инфраструктуры. Сразу отмечу, что описание носит обобщенный характер, и не является ни туториалом, ни инструкцией, ни руководством. Как было отмечено в первой части, вся статья представляет собой только личное видение, основанное на практике внедрения ПЭП в информационные системы агентов, оказывающих сложные, многоэтапные технологические услуги. Цель внедрения ПЭП — расширить географию обслуживания за счет переноса в сеть Интернет документооборота при оказании услуги физическим лицам и минимизации необходимости личных визитов клиентов в офис компании. Для упрощения примера, не будем рассматривать большие компании со сложным документооборотом, а возьмем абстрактную компанию, оказывающей услуги домашней автоматизации. Документооборот услуги такой компании в минимальном варианте состоит из заявки на проектирование, договор с техническим заданием и акта выполненных работ.
Требования и описание архитектуры
Перед началом проектирования необходимо систематизировать имеющиеся описания архитектуры и собрать требования заинтересованных сторон. В первую очередь отметим, что в системной инженерии, требования федерального законодательства, регионального законодательства, различных ведомственных и корпоративных нормативных актов не являются требованиями заинтересованных сторон. Государство не является заинтересованной стороной проекта, государство выступает в роли аналитика и проектировщика и закон предоставляет высокоуровневое описание архитектуры, концепцию, а не требования. Эта концепция должна быть обязательно воплощена в готовом продукте, чтобы считать проект успешным с точки зрения государства в лице исполнительных и контролирующих органов.
Концепция, которая описана в нормативных актах, практически всегда бывает разбросана по различным документам. Единую концепцию из всех этих разрозненных описаний формируют с помощью выписок и разъяснений. Выписка – это часть документа, которая трассируется на исходный документ с помощью реквизитов выписки – номер, дата и заголовок исходного документа и положение в исходном документе (номер раздела, пункта, абзаца). Иногда на практике случается, что выписка имеет неопределенность, в таком случае используется дополнительный документ – разъяснение, обычно оформленное в виде письма государственного органа.
Реальными требованиями, придающими любому проекту уникальность, являются только ожидания и потребности конкретных физических лиц, чью жизнь может изменить или на чью жизнь может повлиять жизненный цикл результата проекта — проектирование, планирование, воплощение и эксплуатация результата проекта. В данной статье такие требования рассматриваться не будут, так как являются специфичными и уникальными для каждого проекта.
Законодательная концепция архитектуры ПЭП
Система хранения ключей
Основой подписи является информация, которую она передает. Как было показано при анализе целевой системы, подпись передает информацию о ПД, и необходимо решить, какие ПД контрагента будут локально зарегистрированы в системе делопроизводства агента. Ответ на этот вопрос дает выписка статей 20 и 21 ГК РФ – ФИО и место жительства. Для локального пространства доверия этих ПД достаточно, но если есть цель юридической значимости ПЭП, то необходимы идентификационные коды, присвоенные этим ПД в уполномоченной системе регистрации. Уполномоченная система в РФ – это МВД. МВД для ФИО и места жительства присваивает идентификационный код – серия и номер паспорта. Таким образом, чтобы локальная регистрация потенциально стала уполномочено-локальной, необходимо регистрировать ФИО, место жительства, серию и номер паспорта.
Следующим этапом является определение ключей ПЭП – открытого и закрытого ключа. Теоретически, в качестве ключей ПЭП можно использовать любые уникальные наборы кодов, паролей и иных средств, сопоставленные с ПД. Выписка из ФЗ-63, а именно статья 4, не конкретизирует, что это за ключи. Но так как нужно добиться значимости подписи, здесь мы можем опереться на документы иного рода – судебную практику. Как показывает судебная практика, основной момент, который оспаривается в судах – это то, что выбранный метод подписи не имеет признаков аналога собственноручной подписи (АЛП). Разные заинтересованные стороны по разному решают этот вопрос. Самый главный признак АЛП — неотчуждаемость от персональных данных В качестве открытого ключа нельзя выдумывать код, этот код должен однозначно указывать на ПД, аналогично монограмме личной подписи и должен быть зарегистрирован в уполномоченном органе, аналогично, как в паспорте зарегистрирована монограмма. На текущий момент таким кодом является только СНИЛС. Он и используется в качестве открытого ключа ПЭП при предоставлении государственных услуг, более того, он используется в качестве открытого ключа ПЭП в информации электронных сертификатов ЭЦП. Дискуссионным является вопрос, насколько СНИЛС уполномочен выполнять это роль, так как законодательно он предназначен совсем для другого использования. На законодательном уровне есть предложения ввести новый код, именно для этих целей, но пока де-факто практика сложилась так, что используется СНИЛС, который является неизменным и уникальным, а также зарегистрирован в уполномоченном органе.
Вполне допустимо, с привязкой к СНИЛС, сделать дополнительный ключ, назовем его вторичным. Это может какой-то уникальный логин. Если говорить об аналоге собственноручной подписи, то такой логин – это собственноручная запись инициалов ФИО. Для собственноручной подписи запись инициалов не отменяет монограмму, для ПЭП – не отменяет СНИЛС.
В качестве закрытого ключа можно использовать любой пароль. Но очень желательно, чтобы данный пароль использовался только в целях подписи и не совмещал в себе другие роли, такие как вход на сайт. Тем самым решаются две технические задачи: есть закрытый ключ, известный только владельцу ПД (аналог двигательного навыка собственноручной подписи, проанализированный в части 2) и есть событие электронной подписи – ввод закрытого ключа ПЭП аналогичен движению руки при визуализации монограммы.
Дополнительно можно проверить, что «рукой движет» именно владелец. Для этого используется вторичный открытый ключ – номер телефона. На номер телефона отправляется SMS c кодом, который, в данном случае, играет роль одноразового закрытого ключа. Ввод кода при подписи аналогичен применению закрытого ключа. При таком применении номера телефона желательно обеспечить неугадываемость кодов, что гарантирует, что закрытый ключ в момент подписи известен только владельцу ПД. Допустимо использование номера телефона просто в качестве дополнительного открытого ключа, применение которого подтверждает факт подписи. В этом случае высылаемый код не является закрытым ключом и закрытый ключ должен быть отдельный.
Суммируя все вышесказанное, в системе обработки ПД, должны храниться:
- Персональные данные контрагента – ФИО и адрес места жительства;
- Идентификационный код уполномоченной регистрации персональных данных — номер и серия паспорта;
- Уполномоченный открытый ключ (образец подписи) – СНИЛС;
- Вторичные открытые ключи (при необходимости) — логин сайта, адрес электронной почты, номер телефона;
В сумме это образует некий слепок электронного паспорта – локально-уполномоченного аналога обычного паспорта, где СНИЛС – аналог монограммы собственноручной подписи.
Система формирования сообщения о персональных данных контрагента
Следующим этапом является решение вопроса о том, как ПД регистрируются в системе агента. Здесь мы упираемся в большое противоречие, заложенное в описании архитектуры работы с ПД в ФЗ-152 и ФЗ-63. Выписка статьи 9 из ФЗ-152 гласит:
В случаях, предусмотренных федеральным законом, обработка персональных данных осуществляется только с согласия в письменной форме субъекта персональных данных. Равнозначным содержащему собственноручную подпись субъекта персональных данных согласию в письменной форме на бумажном носителе признается согласие в форме электронного документа, подписанного в соответствии с федеральным законом электронной подписью.
Проблема в том, что, в случае с ПЭП, необходимо получить ПД, чтобы сформировать электронную подпись, а для того чтобы собрать ПД, необходимо получить согласие, уже подписанное электронной подписью. Плюс к этому, согласно выписке статьи 9 из ФЗ-63, необходимо соглашение о использовании простой электронной подписи. Получается замкнутый круг, который, с первого взгляда, можно разорвать лишь собственноручной подписью соглашения и согласия с личным визитом. Но, если использовать определенную форму соглашения об использовании ПЭП, а именно договор присоединения(публичную оферту), и совместить получение ПД с подписанием согласия, возможно сделать все удаленно. Таким образом, практически без вариантов, закон диктует следующий алгоритм регистрации ПД контрагента для использования в системах ПЭП, если ставится задача обойтись без личных визитов:
- Необходимо соглашение об использовании простой электронной подписи, разработанное квалифицированными юристами, которое должно приниматься анонимно, без использования подписи. Это дает правовую основу для электронной подписи согласия на предоставление ПД с помощью ПЭП. Закон предоставляет вариант организации анонимного соглашения: договор присоединения, к которому может присоединиться неограниченный круг пользователей (публичная оферта). Это первое, что должен увидеть пользователь при регистрации. Факт присоединения к оферте(акцепт) подтверждается формированием и вводом закрытого ключа. Процесс зависит от того, будет в дальнейшем использоваться многоразовый закрытый ключ (пароль) или одноразовые закрытые ключи.
- Форма ввода персональных данных, перечисленных выше, а именно ФИО, место жительства, серия и номер паспорта, СНИЛС и т.д., должна включать в себя согласие на предоставление персональных данных. Само согласие должно быть персональным, и, кроме типовых пунктов, перечисленных в статье 9 ФЗ-152, должно содержать пункт о том, что согласие подписывается ПЭП с перечислением открытых ключей: СНИЛС + вторичные ключи (если есть). Подписывается вся форма (персональные данные и согласие) одним действием. Подробнее устройство системы подписи будет описано далее в разделе «Система передачи открытого ключа на основе закрытого ключа»
- После выполнения этих действий пользователь регистрируется в системе и получает возможность подавать заявления, заявки, обращения и жалобы, подписанные ПЭП. Согласие необходимо сохранить, так как оно может быть отозвано.
Определившись с перечнем сохраняемых ПД, необходимо запроектировать архитектуру, заложенную в описании ФЗ-152. Реализация этой архитектуры состоит из технических и организационных мер, защищающих ПД от несанкционированного доступа. Основные шаги, которые необходимо сделать:
- Выбрать платформу, сертифицированную ФСТЭК для работы с ПД. Платформа, согласно требованиям закона, в минимальном варианте должна обеспечивать разграничение доступа к ПД и логирование всех операций доступа к ПД. В моей практике обычно рассматривались следующие варианты: MS SharePoint 2013/2016, Битрикс, Alfresco, Liferay, и соответственно, в качестве БД – MS SQL Server, PostgreSQL (в составе сертифицированного AltLinux), MySQL. Естественно, возможны и другие варианты. Выбор в пользу того или иного варианта делается на основе сравнительного анализа стоимости владения и на основе ожиданий технического отдела агента – какую платформу им проще будет сопровождать.
- Разработать политику обработки персональных данных
- На основе разработанной политики обработки ПД нужно решить, необходимы ли дополнительные сертифицированные средства защиты ПД и регистрация в качестве оператора персональных данных. Есть определенные методики выполнения этого шага и лучше привлечь лицензированных специалистов, особенно если ПД закон обворачивает в слово «тайна», например – врачебная тайна.
В самом простом случае, если ПД невозможно использовать ни для каких других целей, кроме как идентификации субъекта ПД в целях оказания услуги и ПД ни при каких условиях не могут быть переданы третьим лицам, шаг 3 допустимо пропустить, с обоснованного разрешения квалифицированного специалиста по информационной безопасности.
Пространство доверия
Следующим этапом является решение вопроса о пространстве доверия ПЭП. Если источником ПД для хранения в системе обработки ПД является сайт агента, то это локальное пространство доверия и доверять может только агент. Для повышения статуса доверия необходимо сверить эти данные с оригиналом документа, выдаваемого при уполномоченной регистрации ПД – с оригиналом паспорта. Именно оригиналом, так как получение скан-копий паспортов через сайт – это просто усложненный ввод ПД, и он мало чем отличается от просто ввода ПД. Удаленно запрашивать скан-копии паспортов особого смысла не имеет и статуса доверия к данным не повышает, но при этом повышает уровень требований к защите ПД. И со стороны контрагентов запрос скан-копий паспортов часто провоцирует негативную реакцию, и от такого варианта стоит отказаться. Для сверки может применяться как отдельный личный визит контрагента, также это может быть совмещено с каким-либо этапом оказания услуги, при котором возникает личное взаимодействие с контрагентом. Государственные электронные услуги используют сверку с ЕСИА. Планируется также создание отдельного механизма для электронной сверки персональных данных. Таким образом, запись ПД в системе обработки персональных данных может иметь два статуса – подтверждена/не подтверждена. Аналогичные статусы используются и на порталах государственных услуг.
Система оформления подписи
Цель системы оформления подписи – обеспечить ее непереносимость на другие документы. И агент, и контрагент должны быть уверены, что ПЭП, которой контрагент подписал некоторый документ, нельзя будет впоследствии отнести к другому документу, о котором он и понятия не имеет. В целом, законодательные акты не предусматривают для ПЭП такой функции, как непереносимость, но для юридической значимости подписи это важно. Для того, чтобы связать ПЭП с конкретным документом, в системе агента необходимо иметь электронный реестр ПЭП, где каждая ПЭП получит уникальный инкрементный идентификационный номер. Инкремент позволяет привязать подпись к времени ее постановки, меньший номер говорит о том, что подпись получена раньше. Фактически, такой номер ПЭП – это вторичный открытый ключ ПЭП. Реестр, кроме собственно материализации ПЭП, должен связывать связью «один-к-одному» ПД контрагента, идентификационный номер и дату документа, время подписания и ПЭП.
Реестр обеспечивает и другую важную возможность системы оформления подписи – конвертацию документа с подписью из электронного вида в бумажный. Во многих организациях, например в судах, принят бумажный документооборот. Для того, чтобы, при необходимости, можно было представить в такую организацию документ с подписью, в системе должен быть сервис конвертации документов из электронного вида в бумажный. Конвертируют подписанные документы в формат PDF. При визуализации простой электронной подписи в бумажной форме, должны быть визуализированы открытые ключи ПЭП (первичные и вторичные), т.е., исходя из нашего проектирования, должны быть визуализированы ФИО, СНИЛС, номер телефона (если используется), уникальный идентификационный номер ПЭП. Визуализируются они согласно принятым правилам делопроизводства, обычно под содержимым документа, например так:
Подписано простой электронной подписью:
Иванов Иван Иванович, СНИЛС 000-000-000 00, Телефон (000) 000-00-00.
Регистрационный номер подписи: 0000000 от 31.01.2017 10:05:47
Можно также опереться на методические рекомендации межведомственного электронного документооборота (МЭДО) и визуализировать в стандарте PDF/А.
Система использования закрытого ключа для передачи открытого ключа
Система достаточно подробно разобрана в части 2. Архитектура строится на основе статьи 12 ФЗ-63, т.е система обязательно должна обеспечивать:
- Уведомление контрагента о том, что он запускается процедура подписания. В уведомлении пользователю должны быть показаны реквизиты документа, который он подписывает, в идеале документ должен быть открыт для чтения. Контрагент должен ввести закрытый ключ подписи, конфиденциально известный только ему, для подтверждения и факта и момента подписи;
- Уведомление пользователя о том, что документ подписан. Технически процедура подписания состоит в том, что создается запись в реестре ПЭП и присваивается уникальный номер. Желательно продублировать регистрационный номер подписи, регистрационный номер документа и время подписания с помощью SMS. Тем самым пользователь виртуально получает «второй экземпляр документа» в свое владение;
Адаптация системы делопроизводства
Адаптация системы делопроизводства должна обеспечить неизменяемость документа после подписания. ПЭП, по своей структуре, никак не может выполнять эту роль. Все документы, поступающие в систему делопроизводства, можно разделить на два типа: односторонние и многосторонние. Односторонние документы, подписанные только контрагентом, такие, как заявления и обращения, обычно не требуют обеспечения неизменяемости, так как, по своей природе являются инициирующими, стартовыми. Они могут меняться, редактироваться, отклоняться. Для таких документов достаточно только ПЭП контрагента, которая, в некоторых случаях, может быть заверена усиленной подписью агента при поступлении в систему делопроизводства. В противоположность односторонним документам, многосторонние документы должны быть неизменяемы, поэтому на таких документах первую подпись ставит агент, и эта подпись должна быть усиленной, с использованием криптографии, для обеспечения неизменяемости документа. Для того, чтобы предоставить контрагенту гарантии того, что документ не изменится после того, как на него будет поставлена ПЭП, важную роль играет время постановки подписи. Усиленная подпись агента должна быть по времени раньше, чем ПЭП контрагента, и этот факт должен быть зафиксирован независимыми источниками. Соответственно, усиленная подпись должна быть с возможностью постановки штампов времени (OID 1.2.643.2.2.34.25). Выполнение этих условий призвано обеспечить как доверие между контрагентом и агентом, так и доверие третьих сторон.
Заключение
В последнее время наметился ощутимый тренд к переходу к простой электронной подписи в документообороте с физическими лицами ввиду сложности и затратности инфраструктуры открытых ключей. Портал государственных услуг переводит на ПЭП большинство государственных услуг для физических лиц.Надеюсь, эта статья будет полезной для заинтересованных лиц в разработке и применении инфраструктуры ПЭП при оказании услуг физическим лицам через сеть Интернет.
Автор: Irkin
