На сьогодні все більше документів існує виключно у електронному виглядіє, тому виникає актуальна задача архівного зберігання таких документів, особливо якщо документи призначені не лише для внутрішнього використання, але й для передачі в інші установи. Як правило, такі документи повинні мати кваліфікований електронний підпис (КЕП), але не обов'язково. Строки зберігання таких документів вимірюється десятиліттями, наявна необхідність перевірки КЕП всіма підписантами для встановлення:
-
Цілісність.
-
Конфіденційність.
-
Достовірність.
Актуально на сьогодні для державного, банківського та страхового секторів.
Стандартний підхід
Використання КЕП у форматі ASiC/CAdES X-Long, яка дозволяє забезпечити довготривалу перевірку КЕП.
- Рішення про достовірність КЕП приймається, якщо вона успішно перевіряється, при створенні.
- Після певного періоду часу неможливо перевірити КЕП згідно чинних нормативних документів.
Функції
-
Перевірка КЕП, перед занесенням документу в архів*.
-
Перевірка КЕП у форматі CAdES X-Long та документу з архіву*.
*- КЕП зберігається разом з документами в архіві.
Розширений (Blockchain) підхід
У доповнення до Стандартного підходу, пропонується використовувати модифіковані механізми блокчейн, на основі імітовставки.
- Рішення про коректність КЕП приймається, коли вона успішно перевіряється при створенні.
- Сам КЕП та результати її перевірки, а також всі використовувані для перевірки дані заносяться до БД та зчеплюються з попередніми записами за допомогою імітовставки.
- При перевірці КЕП, безпосередньо сам підпис не перевіряється, а лише перевіряється цілісність всіх зчеплених записів у БД.
Функції
-
Отримання КЕП, перед занесенням документу в архів*.
-
Перевірка КЕП
- Відправка запитів до ЦЗО (OCSP)
- Відправка запитів до ЦСК (OCSP)
- Розширення підпису до CAdES X-Long (у випадку необхідності)
- Формування QR-code для КЕП CAdES X-Long
- Додавання відкріпленого КЕП, хеш-образ у БД зі зчепленими записами
-
Перевірка цілісності документу з архіву
- Порівняння хеш-образу документу та записи з БД зі зчепленими записами
-
Перевірка цілісності БД зі зчепленими записами
- Перевірка цілісності БД зі зчепленими записами, завдяки її відтворення
*- КЕП зберігається у БД архіву КЕП зі зчепленими записами, без документів
Недоліки та переваги обох підходів
|
Недоліки
|
Переваги
|
Стандартний підхід
|
-
Обмежений строк гарантованої перевірки КЕП:
- Строк дії сертифікату ЦЗО (ЦЗО).
- Строк дії сертифікату ЦСК (ЦЗО).
- Строк дії сертифікату OCSP (ЦСК).
- Строк дії сертифікату TSP (ЦЗО).
- Можливість компрометації використовуваних ключів.
- Можливість відмови від існуючих стандартів КЕП, з причини їх морального старіння.
- Необхідність розширення КЕП до формату CAdES X-Long.
- Перевірка КЕП з архіву онлайн з ЦСК та ЦЗО.
|
- Простота використання.
- Відсутність БД.
- Відсутність необхідності у забезпеченні додаткових механізмів захисту.
- Документи зберігаються в окремій системі.
|
Розширений підхід (Blockchain)
|
- Складність рішення.
- Необхідність ведення БД з відкріпленою КЕП зчепленими записами.
- Необхідність періодично здійснювати перевірку цілісності всієї БД зі зчепленими записами.
- Необхідність розширення підпису до формату CAdES X-Long.
- Необхідність при забезпеченні захисту ключа імітовставки для блокчейну.
|
- Необмежений строк гарантованої перевірки КЕП, так як сам КЕП не перевіряється, а перевіряється лише цілісність зчеплених записів у БД з відкріпленним КЕП.
- Компрометація використовуваних ключів не впливає на вже перевірені КЕП.
- Відмова від існуючи стандартів КЕП не вливає, на вже перевірені КЕП.
- Документи зберігаються в окремій системі.
- Перевірка КЕП з архіву в офлайн (без ЦСК та ЦЗО).
|
Корпоративний архів з використанням Шифр-Arch
Система архівування документів, яка дозволяє забезпечити структуроване та довготривале зберігання електронних документів у томі місці, де гарантована перевірка цілісності зчеплених записів у БД (blockchain), навіть після неможливості перевірки КЕП.
Характерристики
Шифр-Arch, як система ведення довготривалого архіву дозволяє:
-
Працювати одразу у кількох ЦОД, у вигляді єдиного кластеру.
-
Працювати автономно у кожному ЦОД, якщо єдиний кластер “розвалився”.
-
Відновлення єдиного кластеру, після його “розвалу”, на основі кластерів одного з ЦОД.
-
Горизонтальне масштабування, до 32-х серверів у кластері БД з документами.
-
Зберігання документів: не обмежено за об'ємом (здійснювалася перевірка на192 ТБ).
-
Розмір документу: до 5 ТБ.
-
Клонування вузлів з пов'язаними ланцюжками для підвищення довіри/захисту від підробки.
-
Автентифікація за допомогою JWT (JSON Web Token).
-
Захист каналів зв'язку:
-
Робота в середині системи через HTTPS/TLS.
-
Робота з API через HTTPS/TSL.
-
Web-інтерфейс через HTTPS/TLS.
Функції
-
Перевірка КЕП, перед занесення документу в архів*.
-
Перервірка КЕП:
-
Розширення підпису до CAdES X-Long (у випадку необхідності).
-
Додатково можна додати до КЕП документу:
-
Додавання відкріпленого КЕП, хеш-образу документу та результатів перевірки КЕП у БД зі зчепленими записами.
-
Пошук документу за реквізитами та підписантами (текст документу не індексується).
-
Перевірка КЕП, перед занесенням документу в архів*.
-
Перевірка цілісності документу з архіву:
-
Перевірка цілісності БД зі зчепленими записами (кілька таких БД):
-
Перевірка цілісності БД зі зчепленими записами, за допомогою відтворення.
-
Прийняття рішення за результатами консолідованої перевірки з кількома вузлами.
-
За розкладом.
Рольова модель:
-
Адміністратор архіву.
-
Оператор архіву.
*- КЕП зберігається у БД архіву КЕП зі зчепленими записами, без документів.
Криптографія
Використовувані криптографічні алгоритми:
*- на даний момент не затребуване, можливе підключення за необхідністю.
Використовувані сховища ключів:
Архітектура системи довготривалого зберігання документів (архіву)
Користувацький веб-клієнт
На рисунках продемонстровано головну сторінку та сторінку додавання документу.
Рисунок 1. Головна сторінка вкладки "Документи в архіві"
Рисунок 2. Процес додавання документу в архів