Інфраструктура простий електронного підпису. Частина 4: Практичні аспекти реалізації

image

частина 1, частина 2, частини 3 були розглянуті основні системи інфраструктури ПЕП. В цій частині буде розглянуто порядок проектування для практичної реалізації інфраструктури. Відразу зазначу, що опис носить узагальнений характер, і не є ні туториалом, ні інструкцією, ні керівництвом. Як було зазначено в першої частини, вся стаття представляє собою лише особисте бачення, засноване на практиці впровадження ПЕП інформаційні системи агентів, що надають складні, багатоетапні технологічні послуги. Мета впровадження ПЕП — розширити географію обслуговування за рахунок перенесення в мережу Інтернет документообігу при наданні послуги фізичним особам та мінімізації необхідності особистих візитів клієнтів в офіс компанії. Для спрощення прикладу, не будемо розглядати великі компанії зі складним документообігом, а візьмемо абстрактну компанію, що надає послуги домашньої автоматизації. Документообіг послуги такої компанії в мінімальному варіанті складається з заявки на проектування, договір з технічним завданням та акту виконаних робіт.

Вимоги і опис архітектури
Перед початком проектування необхідно систематизувати опису архітектури і зібрати вимоги зацікавлених сторін. В першу чергу відзначимо, що в системній інженерії, вимоги федерального законодавства, регіонального законодавства, різних відомчих та корпоративних нормативних актів не є вимогами зацікавлених сторін. Держава не є зацікавленою стороною проекту, держава виступає в ролі аналітика і проектувальника і закон надає високорівневий опис архітектури, концепцію, а не вимоги. Ця концепція повинна бути обов'язково втілена в готовому продукті, щоб вважати проект успішним з точки зору держави в особі виконавчих і контролюючих органів.

Концепція, яка описана в нормативних актах, практично завжди буває розкидана по різних документів. Єдину концепцію з усіх цих розрізнених описів формують з допомогою виписок та роз'яснень. Виписка – це частина документа, яка трасується на вихідний документ за допомогою реквізитів виписки – номер, дата й заголовок вихідного документа і положення у вихідному документі (номер розділу, пункту, абзацу). Іноді на практиці трапляється, що виписка має невизначеність, у такому випадку використовується додатковий документ – роз'яснення, зазвичай оформлене у вигляді листа державного органу.

Реальними вимогами, які надають будь-якого проекту унікальність, є тільки очікування та потреби конкретних фізичних осіб, чиє життя може змінити або на чиє життя може вплинути життєвий цикл результату проекту — проектування, планування, втілення і експлуатація результату проекту. У цій статті такі вимоги не будуть розглядатись, так як є специфічними і унікальними для кожного проекту.

Законодавча концепція архітектури ПЕП
Система зберігання ключів
Основою підпису є інформація, яку вона передає. Як було показано при аналізі цільової системи, підпис передає інформацію про ПД, і необхідно вирішити, які ПД контрагента локально будуть зареєстровані у системі діловодства агента. Відповідь на це питання дає виписка статей 20 і 21 ЦК РФ – ПІБ і місце проживання. Для локального простору довіри цих ПД достатньо, але якщо є мета юридичної значимості ПЕП, то необхідні ідентифікаційні коди, присвоєні цим ПД уповноваженої системі реєстрації. Уповноважена система РФ – це МВС. МВС для ПІБ і місця проживання присвоює ідентифікаційний код – серія і номер паспорта. Таким чином, щоб локальна реєстрація потенційно стала уповноважене-локальній, необхідно реєструвати ПІБ, місце проживання, серію і номер паспорта.

Наступним етапом є визначення ключів ПЕП – відкритого і закритого ключа. Теоретично, в якості ключів ПЕП можна використовувати будь-які унікальні набори кодів, паролів та інших засобів, які пов'язані з ПД. Виписка з ФЗ-63, а саме стаття 4, не конкретизує, що це за ключі. Але так як потрібно домогтися значущості підпису, тут ми можемо спертися на документи іншого роду – судову практику. Як показує судова практика, основний момент, який оскаржується в судах – це те, що вибраний метод підпису не має ознак аналога власноручного підпису (АЛП). Різні зацікавлені сторони по-різному вирішують це питання. Найголовніший ознака АЛП — невідчужуваність від персональних даних В якості відкритого ключа не можна вигадувати код, цей код повинен однозначно вказувати на ПД, аналогічно монограмі особистого підпису та повинен бути зареєстрований в уповноваженому органі, аналогічно, як у паспорті зареєстрована монограма. На поточний момент таким кодом є тільки СНІЛС. Він і використовується в якості відкритого ключа ПЕП при наданні державних послуг, більше того, він використовується в якості відкритого ключа ПЕП в інформації електронних сертифікатів ЕЦП. Дискусійним є питання, наскільки СНІЛС уповноважений виконувати цю роль, так як законодавчо він призначений зовсім для іншого використання. На законодавчому рівні є пропозиції ввести новий код, саме для цих цілей, але поки що де-факто практика склалася так, що використовується СНІЛС, який є незмінним і унікальним, а також зареєстрований в уповноваженому органі.

Цілком припустимо, з прив'язкою до СНІЛС, зробити додатковий ключ, назвемо його вторинним. Це може якийсь унікальний логін. Якщо говорити про аналог власноручного підпису, то такий логін – це власноручний запис ініціалів ПІБ. Для власноручного підпису запис ініціалів не скасовує монограму, для ПЕП – не скасовує СНІЛС.

Як закритого ключа можна використовувати будь-який пароль. Але дуже бажано, щоб цей пароль використовувався тільки в цілях підпису і не поєднував у собі інші ролі, такі як вхід на сайт. Тим самим вирішуються дві технічні завдання: є закритий ключ відомий тільки власнику ПД (аналог рухового навику власноручного підпису, проаналізований у частині 2) і є подія електронного підпису – введення закритого ключа ПЕП аналогічний руху руки при візуалізації моногр.

Додатково можна перевірити, що «рухає рукою» саме власник. Для цього використовується вторинний відкритий ключ – номер телефону. На номер телефону відправляється SMS повідомлення з кодом, який, в даному випадку відіграє роль одноразового закритого ключа. Введення коду при підписи аналогічний застосування закритого ключа. При такому застосуванні номера телефону бажано забезпечити неугадываемость кодів, що гарантує, що закритий ключ в момент підпису відомий тільки власнику ПД. Допустимо використання номера телефону просто в якості додаткового відкритого ключа, застосування якого підтверджує факт підпису. У цьому випадку высылаемый код не є закритим ключем і закритий ключ повинен бути окремий.

Підсумовуючи все вищесказане, в системі обробки ПД, повинні зберігатися:

  1. Персональні дані контрагента – ПІБ і адресу місця проживання;
  2. Ідентифікаційний код уповноваженої реєстрації персональних даних — номер та серія паспорта;
  3. Уповноважений відкритий ключ (зразок підпису) – СНІЛС;
  4. Вторинні відкриті ключі (при необхідності) — логін сайту, адреса електронної пошти, номер телефону;
В сумі це утворює якийсь зліпок електронного паспорта – локально-уповноваженого аналога звичайного паспорта, де СНІЛС – аналог монограми власноручного підпису.

Система формування повідомлення про персональних даних контрагента
Наступним етапом є вирішення питання про те, як ПД реєструються в системі агента. Тут ми впираємося в протиріччя, закладене в описі архітектури роботи з ПД ФЗ-152 і ФЗ-63. Виписка статті 9 ФЗ-152 говорить:
У випадках, передбачених федеральним законом, обробка персональних даних здійснюється лише за згодою в письмовій формі суб'єкта персональних даних. Рівнозначним містить власноручний підпис суб'єкта персональних даних згоди у письмовій формі на паперовому носії визнається згода у формі електронного документа, підписаного у відповідності з федеральним законом електронним підписом.
Проблема в тому, що у випадку з ПЕП, необхідно отримати ПД, щоб сформувати електронний підпис, а для того щоб зібрати ПД, необхідно отримати згоду, вже підписаний електронним підписом. Плюс до цього, згідно з випискою статті 9 ФЗ-63, необхідно угода про використанні простий електронного підпису. Виходить замкнуте коло, яке, з першого погляду, можна розірвати лише власноручним підписом угоди та згоди з особистим візитом. Але, якщо використовувати певну форму угоди про використання ПЕП, а саме договір приєднання(публічну оферту), і поєднати отримання ПД з підписанням згоди, можливо зробити все віддалено. Таким чином, практично без варіантів, закон диктує наступний алгоритм реєстрації ПД контрагента для використання в системах ПЕП, якщо ставиться завдання обійтися без особистих візитів:

  1. Потрібно угода про використання простий електронного підпису, розроблене кваліфікованими юристами, яке повинно прийматися анонімно, без використання підпису. Це дає правову основу для електронного підпису згоди на надання ПД з допомогою ПЕП. Закон надає варіант організації анонімного угоди: договір приєднання, до якого може приєднатися необмежене коло користувачів (публічна оферта). Це перше, що повинен побачити користувач при реєстрації. Факт приєднання до оферти(акцепт) підтверджується формуванням та введенням закритого ключа. Процес залежить від того, чи буде в подальшому використовуватися багаторазовий закритий ключ (пароль) або одноразові закриті ключі.
  2. Форма введення персональних даних, перелічених вище, а саме ПІБ, місце проживання, серія і номер паспорта, СНІЛС і т. д., повинна включати в себе згоду на надання персональних даних. Сама згода має бути персональним, і, крім типових пунктів, перелічених у статті 9 ФЗ-152, повинно містити пункт про те, що згода підписується ПЕП з перерахуванням відкритих ключів: СНІЛС + вторинні ключі (якщо є). Підписується вся форма (персональні дані та згоду) однією дією. Докладніше пристрій системи підпису буде описано далі в розділі «Система передачі відкритого ключа на основі закритого ключа»
  3. Після виконання цих дій користувач реєструється в системі і отримує можливість подавати заяви, заяви, звернення та скарги, підписані ПЕП. Згода необхідно зберегти, так як воно може бути відкликано.
Визначившись з переліком зберігаються ПД, необхідно запроектувати архітектуру, закладену в описі ФЗ-152. Реалізація цієї архітектури складається з технічних і організаційних заходів, які захищають ПД від несанкціонованого доступу. Основні кроки, які необхідно зробити:

  1. Вибрати платформу, сертифіковану ФСТЕК для роботи з ПД. Платформа, згідно з вимогами закону, в мінімальному варіанті повинна забезпечувати розмежування доступу до ПД і логування всіх операцій доступу до ПД. У моїй практиці зазвичай розглядалися наступні варіанти: MS SharePoint 2013/2016, Бітрікс, Alfresco, Liferay, і відповідно, в якості БД – MS SQL Server, PostgreSQL (у складі сертифікованого AltLinux), MySQL. Звичайно, можливі й інші варіанти. Вибір на користь того або іншого варіанта робиться на основі порівняльного аналізу вартості володіння і на основі очікувань технічного відділу агента – яку платформу їм простіше буде супроводжувати.
  2. Розробитиполітику обробки персональних даних
  3. На основі розробленої політики обробки ПД потрібно вирішити, чи необхідні додаткові сертифіковані засоби захисту ПД і реєстрація в якості оператора персональних даних. Є певні методики виконання цього кроку і краще залучити ліцензованих фахівців, особливо якщо ПД закон обворачивает в слово «таємниця», наприклад – лікарська таємниця.
В найпростішому випадку, якщо ПД неможливо використовувати ні для яких інших цілей, окрім як ідентифікації суб'єкта ПД в цілях надання послуги та ПД ні при яких умовах не можуть бути передані третім особам, крок 3 допустимо пропустити, з обґрунтованого дозволу кваліфікованого фахівця з інформаційної безпеки.

Простір довіри
Наступним етапом є вирішення питання про простір довіри ПЕП. Якщо джерелом ПД для зберігання в системі обробки ПД є сайт агента, то це локальне простір довіри та довіряти може тільки агент. Для підвищення статусу довіри необхідно звірити ці дані з оригіналом документа, що видається при реєстрації уповноваженої ПД – з оригіналом паспорта. Саме оригіналом, так як отримання скан-копій паспортів через сайт – це просто ускладнений введення ПД, і він мало чим відрізняється від просто введення ПД. Віддалено запитувати скан-копії паспортів особливого сенсу не має статусу довіри до даних не підвищує, але при цьому підвищує рівень вимог до захисту ПД. І з боку контрагентів запит скан-копій паспортів часто провокує негативну реакцію, і від такого варіанту варто відмовитися. Для звірки може застосовуватися як окремий особистий візит контрагента, також це може бути поєднане з якимось етапом надання послуги, при якому виникає особиста взаємодія з контрагентом. Державні електронні послуги використовують звірку з ЕСИА. Планується також створення окремого механізму для електронної звірки персональних даних. Таким чином, запис ПД в системі обробки персональних даних може мати два статуси – підтверджена/не підтверджена. Аналогічні статуси використовуються і на порталах державних послуг.

Система оформлення підпису
Мета системи оформлення підпису – забезпечити її непереносимість на інші документи. Та агент, контрагент повинні бути впевнені, що ПЕП, якою контрагент підписав деякий документ, не можна буде згодом віднести до іншого документу, про який він і гадки не має. В цілому, законодавчі акти не передбачають для ПЕП такої функції, як непереносимість, але для юридичної значимості підпису це важливо. Для того, щоб зв'язати ПЕП з конкретним документом, в системі агента необхідно мати електронний реєстр ПЕП, де кожна ПЕП отримає унікальний інкрементний ідентифікаційний номер. Інкремент дозволяє прив'язати підпис до часу її постановки, менший номер говорить про те, що підпис отримана раніше. Фактично, такий номер ПЕП – це вторинний відкритий ключ ПЕП. Реєстр, крім власне матеріалізації ПЕП, повинен пов'язувати зв'язком «один-до-одного» ПД контрагента, ідентифікаційний номер і дату документа, на час підписання та ПЕП.

Реєстр забезпечує та іншу важливу можливість системи оформлення підпису – конвертацію документа з підписом електронного виду в паперовий. У багатьох організаціях, наприклад в судах, прийнятий паперовий документообіг. Для того, щоб, при необхідності, можна було уявити таку організацію документ з підписом, у системі повинен бути сервіс конвертації документів з електронного виду в паперовий. Конвертують підписані документи у формат PDF. При візуалізації простий електронного підпису в паперовій формі, повинні бути візуалізовані відкриті ключі ПЕП (первинні і вторинні), тобто, виходячи з нашого проектування, повинні бути візуалізовані ПІБ, СНІЛС, номер телефону (якщо використовується), унікальний ідентифікаційний номер ПЕП. Візуалізуються вони згідно з прийнятими правилами діловодства, зазвичай під вмістом документа, наприклад так:
Підписано простий електронної підписом:
Іванов Іван Іванович, СНІЛС 000-000-000 00, Телефон (000) 000-00-00.
Реєстраційний номер підписи: 0000000 від 31.01.2017 10:05:47
Можна також спиратися на методичні рекомендації міжвідомчого електронного документообігу (МЕДО) і візуалізувати в стандарті PDF/А.с

Система використання цього закритого ключа для передачі відкритого ключа
Система досить докладно розібрана в частина 2. Архітектура будується на основі статті 12 ФЗ-63, тобто система обов'язково повинна забезпечувати:

  1. Повідомлення контрагента про те, що він запускається процедура підписання. Повідомлення користувачу повинні бути показані реквізити документа, який він підписує, в ідеалі документ повинен бути відкритий для читання. Контрагент повинен ввести закритий ключ підпису, конфіденційно відомий тільки йому, для підтвердження факту та моменту підпису;
  2. Повідомлення користувача про те, що документ підписаний. Технічно процедура підписання полягає в тому, що створюється запис в реєстрі ПЕП і присвоюється унікальний номер. Бажано продублювати реєстраційний номер підпису, реєстраційний номер документа та час підписання з допомогою SMS. Тим самим користувач віртуально отримує «другий примірник документа» у своє володіння;
Адаптація системи діловодства
Адаптація системи діловодства повинна забезпечити незмінність документа після його підписання. ПЕП, по своїй структурі, ніяк не може виконувати цю роль. Всі документи, що надходять у систему діловодства, можна розділити на два типу: односторонні і багатосторонні. Односторонні документи, підписані тільки контрагентом, такі, як заяви і звернення, зазвичай не вимагають забезпечення незмінюваності, так як, за своєю природою є инициирующими, стартовими. Вони можуть змінюватися, редагуватися, відхилятися. Для таких документів достатньо тільки ПЕП контрагента, яка в деяких випадках може бути завірена посиленою підписом агента при вступі в систему діловодства. На противагу одностороннім документів, багатосторонні документи повинні бути не можна буде змінити, тому на таких документах першу підпис ставить агент, і ця підпис має бути посиленою, з використанням криптографії, для забезпечення незмінюваності документа. Для того, щоб надати контрагенту гарантії того, що документ не зміниться після того, як на нього буде поставлена ПЕП, важливу роль відіграє час підписування. Посилена підпис агента повинна бути за часом раніше, ніж ПЕП контрагента, і цей факт повинен бути зафіксований незалежними джерелами. Відповідно, посилена підпис має бути з можливістю постановки штампів часу (OID 1.2.643.2.2.34.25). Виконання цих умов покликана забезпечити як довіра між контрагентом і агентом, так і довіру третіх сторін.

Висновок
Останнім часом намітився відчутний тренд до переходу до простої електронного підпису документообіг з фізичними особами через складність і витратність інфраструктури відкритих ключів. Портал державних послуг переводить на ПЕП більшість державних послуг для фізичних осіб.Сподіваюся, ця стаття буде корисною для зацікавлених осіб в розробці і застосуванні інфраструктури ПЕП при наданні послуг фізичним особам через мережу Інтернет.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.