Блог · Для бізнесу

Як обрати рішення для КЕП на сайті: чек-лист для бізнесу

Опубліковано

Впровадження електронного підпису — рішення, яке ухвалюють на роки. Розповідаємо, які сім питань поставити постачальнику до підписання договору: від архітектури обробки ключа до вартості володіння і свободи піти.

Опубліковано 7 серпня 2026


Коротка відповідь. Рішення для КЕП обирають не за брендом і не за довжиною прайс-листа, а за архітектурою. Ключові критерії: приватний ключ користувача має оброблятися лише в його браузері (в ізольованому iframe, а не на сервері й не в коді вашої сторінки); криптографія має покривати повний стек нацстандартів ДСТУ і всі потрібні формати підпису, включно з довгостроковими; перевірка має бути повною (ланцюжок, OCSP, TSP) і відрізняти КЕП від просто дійсного підпису; а модель постачання — прозорою: production-ядро, підписка з відомою ціною, інтеграція за хвилини і відмова без «викорчовування» чужих файлів з інфраструктури. Нижче — чек-лист із семи питань, який покриває все це.

Чому вибір рішення для КЕП — критичне рішення

Кваліфікований електронний підпис — не «ще одна кнопка» у продукті. Ключ КЕП юридично представляє особу: документ, підписаний ним, має силу власноручного підпису. Це означає, що архітектурна помилка у поводженні з ключами — не технічний борг, який можна виправити в наступному спринті, а прямий юридичний і репутаційний ризик. Якщо ключі клієнтів проходять через ваш сервер і сервер скомпрометують, зловмисник зможе підписувати документи від імені ваших користувачів — і пояснювати це доведеться вам.

Друга причина: КЕП впроваджують надовго. Формати підписів, які ви почнете створювати сьогодні, перевірятимуть через роки; стандарти гешування в державі оновлюються; постачальник, який не супроводжує криптографію, з часом стає джерелом проблем. Тому питання до рішення для КЕП варто ставити до впровадження — далі власне чек-лист.

Чек-лист: сім питань до постачальника

1. Де обробляється приватний ключ?

Найважливіше питання. Варіантів три. На сервері — найгірший: усі ключі проходять через одну точку, компрометація якої означає компрометацію всіх користувачів одразу. У коді вашої сторінки — краще, але будь-який XSS на сайті (у тому числі через сторонні скрипти аналітики чи чату) дотягується до ключа. В ізольованому iframe на окремому origin — архітектурно найсильніший варіант: ключ і пароль вводяться всередині iframe, і Same-Origin Policy браузера гарантує, що ні ваш код, ні XSS на вашому сайті фізично не мають до них доступу. Детально ми розбирали це у статті «Чому приватний ключ ніколи не повинен покидати браузер».

2. Які стандарти підтримано?

Український КЕП — це підпис ДСТУ 4145 на еліптичних кривих. Але сам-один він не працює: у парі йдуть геш-функція і, за потреби, шифрування. Перевірте, що рішення підтримує і чинний геш ДСТУ ГОСТ 34.311-95 (саме його сьогодні приймають держвалідатори), і сучасну «Купину» (ДСТУ 7564:2014) — інакше при переході держсистем на новий стандарт вам доведеться міняти постачальника. Для шифрування даних стандарт — «Калина» (ДСТУ 7624:2014). Рішення, що покриває весь стек, готове і до сьогоднішніх вимог, і до завтрашніх.

3. Які формати і рівні підпису доступні?

Різні документи вимагають різних контейнерів: CAdES для довільних файлів, PAdES для підпису всередині PDF, XAdES для XML, ASiC для контейнерів з кількома файлами. Не менш важливі рівні: базовий підпис (BES) з часом стає неперевірюваним — сертифікат спливає, сервіси статусів вимикаються. Для договорів і архівів потрібні довгострокові рівні CAdES-XL і PAdES-LTA, де мітки часу і дані про статус сертифіката вкладено у сам контейнер. Чому це критично — у статті про довгостроковий підпис.

4. Чи повна перевірка — і чи видно, що це саме КЕП?

«Підпис математично коректний» — це лише третина перевірки. Повна валідація включає ланцюжок сертифікатів до довіреного кореня, актуальний статус сертифіката через OCSP/CRL і перевірку міток часу TSP. І окремо: дійсний підпис — ще не КЕП. Кваліфікованим його робить сертифікат від акредитованого надавача, тож рішення має явно повертати цю ознаку (у DSTUcrypt — поле accredited у результаті підпису й перевірки, плюс авторитетна серверна перевірка для рішень, які ухвалює ваш бекенд).

5. Хто супроводжує криптографію?

Криптографічний код — не місце для експериментів: у чисто-JS реалізаціях ДСТУ відомі вразливості на кшталт timing-атак і відновлення ключа з підписів. Питайте, на якому ядрі працює рішення і хто його оновлює. DSTUcrypt працює на перевіреній нативній C/C++-бібліотеці, що роками працює в українській PKI, скомпільованій у WebAssembly. Це production-рішення з передбачуваними оновленнями, а не community-експеримент, який може лишитися без підтримки.

6. Скільки коштує володіння?

Порівнюйте не ціну ліцензії, а повну вартість: власна розробка означає штатних криптофахівців, супровід оновлень стандартів, сертифікаційні питання і відповідальність за інциденти. Сервісна модель переносить це на постачальника за фіксовану суму. Для орієнтиру — прозора модель DSTUcrypt: 4 500 грн/міс або 38 880 грн/рік за домен, опційно «Персональний дизайн» (+1 200 грн/міс), «Кілька підписантів» (+700 грн/міс) і «Шифрування» (+900 грн/міс), із 7 днями безкоштовного тестування на кожному новому домені. Це менше, ніж година роботи криптоконсультанта на місяць.

7. Як швидко впровадити — і як швидко піти?

Хороше рішення легко і підключити, і вимкнути. Якщо впровадження вимагає встановлювати пакети, хостити криптофайли у себе і збирати WASM — ви отримуєте не лише тижні інтеграції, а й вендор-лок: чужі артефакти вростають у вашу інфраструктуру. В iframe-моделі інтеграція — один імпорт SDK, а відмова — видалення кількох рядків коду; при цьому підписані документи лишаються стандартними контейнерами, перевірюваними будь-яким сумісним засобом.

Зведена таблиця: питання → на що дивитися

Питання На що звернути увагу Як у DSTUcrypt
Де обробляється ключ сервер і код сторінки — ризик; ізольований iframe — еталон лише браузер користувача, iframe на окремому origin
Стандарти ДСТУ 4145 + обидва геші (ГОСТ 34.311 і «Купина») + «Калина» повний стек, «Купина» вмикається однією опцією
Формати і рівні CAdES/PAdES/XAdES/ASiC, довгострокові -XL/-LTA 16 форматів, включно з CAdES-XL і PAdES-B-LTA
Перевірка ланцюжок + OCSP + TSP, ознака саме КЕП повна валідація, поле accredited, серверний API
Супровід production-ядро проти самописного коду криптоядро (C/C++ → WASM), оновлення на боці сервісу
Вартість володіння повна вартість, а не лише ліцензія 4 500 грн/міс або 38 880 грн/рік за домен, 7 днів тріалу
Впровадження і вихід без пакетів, без файлів у себе, без вендор-локу один імпорт SDK; відмова — видалити кілька рядків

Наскільки складна інтеграція насправді

Критерій «швидко впровадити» легко перевірити на практиці: попросіть у постачальника мінімальний робочий приклад. Ось повна інтеграція підпису з DSTUcrypt — без встановлення пакетів і без жодного файлу на вашому сервері:

повна інтеграція підпису — один імпорт

import { embed } from 'https://dstucrypt.io/embed/dstucrypt-embed.mjs';

const signer = await embed('sign', { mount: 'modal' });
const { signature, accredited } = await signer.sign(fileBytes, {
  format: 'CAdES-T', // формат і рівень — одна опція
});
signature.download('document.p7s');

Покроковий розбір цього прикладу — у статті «Як додати КЕП на сайт за 10 хвилин».

Чому DSTUcrypt проходить цей чек-лист повністю. Ключ і пароль обробляються лише у браузері користувача, в ізольованому iframe; криптографію виконує production-криптоядро на WebAssembly з повним стеком нацстандартів — ДСТУ 4145, обидва геші (ГОСТ 34.311 і «Купина»), «Калина»; 16 форматів підпису аж до CAdES-XL і PAdES-B-LTA; повна перевірка з ознакою accredited; прозора підписка без прихованих витрат і жодного файлу у вашій інфраструктурі.

Висновок

Впровадження електронного підпису для бізнесу — це насамперед вибір архітектури, і сім питань вище дозволяють оцінити її за одну зустріч із постачальником. Якщо коротко: ключ — лише у браузері користувача, стандарти — повний стек ДСТУ, формати — з довгостроковими рівнями, перевірка — повна і з ознакою КЕП, ядро — production-класу, ціна — прозора, вихід — безболісний. Рішення, яке відповідає на всі сім, не доведеться міняти ні після аудиту безпеки, ні після оновлення держстандартів.

Поширені запитання

Чи потрібні власні криптофахівці, щоб впровадити електронний підпис на сайті?

Ні. У сервісній моделі криптографію супроводжує постачальник: DSTUcrypt працює на production-ядрі, а оновлення алгоритмів і форматів відбуваються на боці сервісу автоматично. Вашій команді достатньо фронтенд-розробника, який зробить один імпорт SDK і викличе кілька методів.

Скільки коштує рішення для КЕП від DSTUcrypt?

Базова підписка — 4 500 грн/міс або 38 880 грн/рік за домен. Опційно: «Персональний дизайн» (+1 200 грн/міс або +10 368 грн/рік), «Кілька підписантів» (+700 грн/міс або +6 048 грн/рік), «Шифрування та розшифрування» (+900 грн/міс або +7 776 грн/рік). Кожен новий домен отримує 7 днів безкоштовно автоматично.

Чому обробка приватного ключа на сервері — це ризик?

Ключ КЕП юридично представляє особу підписанта, тому будь-яка його копія поза контролем власника — це можливість підписувати документи від його імені. Якщо ключі користувачів проходять через сервер, компрометація цього сервера означає компрометацію одразу всіх ключів. Безпечніша архітектура — коли ключ обробляється лише у браузері користувача, в ізольованому iframe на окремому origin.

Як швидко можна запустити КЕП — і чи легко потім відмовитися від сервісу?

Інтеграція — це один імпорт SDK і кілька рядків коду: типове підключення займає лічені хвилини, без встановлення пакетів і хостингу файлів у себе. Відмова так само проста: у вашій інфраструктурі немає жодних файлів сервісу, а підписані документи — стандартні CAdES/PAdES/XAdES/ASiC-контейнери, які перевіряються будь-яким сумісним засобом.

Читайте також

Рішення для КЕП, що проходить увесь чек-лист — за 10 хвилин

Готові віджети підпису, перевірки та шифрування за ДСТУ. Ключ і пароль не покидають браузер користувача. На кожному новому домені — 7 днів безкоштовно.

Живе демоЯк підключити

Спробуйте КЕП на своєму сайті

Готові віджети підпису, перевірки та входу за ДСТУ. На кожному новому домені — 7 днів безкоштовно.