Чи можна вважати електронний ключ скомпрометованим, якщо пароль до нього передається програмі або електронному пристрою для автоматичного підписання документів?
Це питання лежить на межі технічної зручності, юридичної відповідальності та кібербезпеки. Сам факт використання ключа програмою ще не доводить компрометацію. Однак якщо файл ключа, пароль або можливість підписання стають доступними сторонній особі, віддаленому сервісу чи неконтрольованому програмному середовищу, це вже може бути підозрою на компрометацію і потребує негайної перевірки.
Нижче розбираємо, де саме виникає ризик і як безпечніше організувати автоматизовану роботу ПРРО.
1. Юридичний аспект: контроль особистого ключа
Закон України № 2155-VIII зобов’язує користувача електронних довірчих послуг забезпечувати конфіденційність особистого ключа та неможливість доступу до нього інших осіб. Також користувач повинен невідкладно повідомити надавача електронних довірчих послуг про підозру або факт компрометації та не використовувати ключ після компрометації.
Компрометація особистого ключа визначається як подія, що призвела або може призвести до несанкціонованого доступу до нього. Тому оцінювати потрібно не лише факт введення пароля, а весь спосіб роботи програми: де зберігається ключ, хто може його прочитати, куди передається пароль і чи може система створити підпис без контролю уповноваженої особи.
Передавання пароля програмі
Якщо пароль вводиться у сторонню програму, скрипт або вебформу, важливо розуміти, що відбувається далі. Локальна перевірена програма може використовувати ключ без його передавання третій стороні. Натомість завантаження файла ключа разом із паролем на чужий сервер або передавання цих даних працівнику підтримки означає втрату одноосібного контролю й створює серйозний ризик несанкціонованого використання.
Відповідальність за підписані документи
Документи, створені з використанням чинного електронного підпису або печатки, пов’язуються з власником відповідного сертифіката. Якщо система підпише документ через помилку, неправильне налаштування або злам, з’ясування обставин може бути складним. Саме тому важливі технічні журнали, розмежування прав, контроль операцій і своєчасне повідомлення про підозру на компрометацію.
Не варто наперед прогнозувати позицію ДПС або суду: юридична оцінка залежатиме від конкретних обставин і доказів. Але добровільне передавання файла ключа та пароля стороннім особам суттєво ускладнює підтвердження того, що ключ використовувався без дозволу власника.
2. Технічні ризики
Передавання ключа й пароля автоматизованій системі може створити кілька вразливостей.
2.1. Зберігання пароля
Потрібно з’ясувати, де саме програма зберігає пароль. Якщо він записаний у відкритому файлі конфігурації, коді скрипту, базі даних або незахищеному сховищі, його може отримати розробник, адміністратор або зловмисник, який дістав доступ до системи.
Навіть коли програма показує позначку «запам’ятати пароль», користувач має розуміти, чи зашифровано ці дані, до якого пристрою вони прив’язані та хто може їх відновити.
2.2. Логи та перехоплення
Пароль може випадково потрапити до журналів програми або сервера. Ризик також виникає, коли ключ і пароль передаються мережею без належного захисту або надсилаються електронною поштою, у чаті чи месенджері.
2.3. Відсутність контролю над змістом
Електронний підпис підтверджує цілісність документа та пов’язує його з підписувачем або створювачем печатки. При повній автоматизації людина може не бачити кожен документ безпосередньо перед підписанням. Тому система повинна мати чіткі правила формування документів, розмежування ролей, журнал операцій і можливість перевірити, що саме було підписано.
3. Що робити, якщо ключ або пароль уже передано ненадійній системі
Якщо файл ключа та пароль уже були завантажені на сторонній сервер, передані іншій особі або зберігалися у програмі, якій ви більше не довіряєте:
- Припиніть використання цього ключа до з’ясування обставин.
- Перевірте журнали операцій і документи, підписані за період можливого ризику.
- Зверніться до кваліфікованого надавача, який видав ключ, та повідомте про підозру на компрометацію.
- За рекомендацією надавача заблокуйте або скасуйте сертифікат і отримайте новий ключ.
- Оновіть дані про ключі касирів або електронну печатку, які використовуються у ПРРО.
Проста зміна пароля не завжди доступна та не усуває ризику, якщо копія особистого ключа вже могла потрапити до сторонньої особи. Центральний засвідчувальний орган рекомендує у разі втрати ключа або пароля звертатися до надавача для зміни статусу сертифіката та отримання нового ключа.
4. Чекліст безпеки програми
Щоб зрозуміти, чи можна довіряти програмі, перевірте не лише її рекламу, а фактичний спосіб роботи.
4.1. Перевірте тип інтеграції
Програми можуть взаємодіяти з електронним ключем по-різному.
Контрольований локальний сценарій. Файл ключа залишається на комп’ютері, захищеному носії або іншому пристрої користувача. Підпис створюється локальним модулем, а сторонній сервер отримує лише готовий підписаний документ. Потрібно перевірити, чи не передаються ключ і пароль за межі пристрою та як захищене локальне сховище.
Ризиковий віддалений сценарій. Програма просить завантажити файл ключа (.jks, .zs2, .pfx або інший формат) і ввести пароль у вебформі, після чого ці дані опиняються на сервері розробника. У такому випадку розробник технічно може отримати можливість використовувати ключ, а користувач залежить від того, як саме організований захист сервера.
Не кожне поле для введення пароля автоматично означає порушення. Критично важливо, де виконується операція, чи залишаються дані на пристрої та чи описує розробник архітектуру захисту.
4.2. Перевірте розробника
Перед введенням даних з’ясуйте:
- хто є розробником і постачальником програми;
- чи існує офіційний сайт, договір та політика конфіденційності;
- де зберігаються ключі й паролі;
- чи є незалежний аудит, підтвердження відповідності або опис системи захисту;
- як користувача повідомляють про інциденти;
- чи можна видалити збережений ключ і журнал операцій.
Відомий бренд сам по собі не замінює технічної перевірки, але прозорість компанії та зрозуміла відповідальність зменшують ризик порівняно з анонімним сервісом або скриптом невідомого походження.
4.3. КСЗІ та підтвердження захисту
Комплексна система захисту інформації, незалежний аудит або інше належне підтвердження відповідності дають додаткові докази того, що архітектуру й процеси захисту перевіряли не лише самі розробники.
Водночас відсутність саме атестата КСЗІ не доводить автоматично, що конкретний приватний ПРРО незаконний або небезпечний. Застосування вимог Закону № 80/94-ВР залежить від власника системи, виду інформації та встановлених законом вимог до її захисту. Тому потрібно перевіряти фактичну документацію конкретного рішення, а не покладатися лише на наявність або відсутність одного рекламного формулювання.
Для ПРРО особливо важливо знати:
- чи залишається особистий ключ під контролем користувача;
- чи може персонал розробника отримати ключ або пароль;
- чи ведеться журнал підписаних операцій;
- чи можна обмежити ключ лише касовими операціями;
- як захищені резервні копії та віддалений доступ.
4.4. Технічні ознаки небезпеки
Уникайте програм або способів підтримки, які:
- Просять надіслати файл ключа та пароль у чат, месенджер або електронною поштою.
- Не пояснюють, де саме зберігається пароль після вибору «запам’ятати».
- Передають конфіденційні дані через незашифроване HTTP-з’єднання.
- Не дають перевірити історію створених і підписаних документів.
- Не мають зрозумілих реквізитів розробника або правил реагування на інциденти.
- Вимагають основний ключ керівника, хоча для роботи достатньо окремого касира чи печатки ПРРО.
5. Як безпечніше автоматизувати роботу ПРРО
Найпрактичніший підхід — розподілити ролі й не використовувати один універсальний ключ для всіх задач бізнесу.
- Не використовуйте основний ключ директора або ФОП у щоденному касовому програмному забезпеченні, якщо для роботи можна створити окремий ключ.
- Отримайте окремий ключ касира або номерну електронну печатку для ПРРО. ДПС прямо передбачає обидва варіанти: підпис уповноваженої особи або печатку каси.
- Надавайте ключу лише потрібну роль у ПРРО та своєчасно припиняйте доступ звільнених працівників.
- Захистіть пристрій, на якому зберігається ключ: окремий обліковий запис, актуальна система, резервні копії, контроль віддаленого доступу й антивірусний захист.
- Регулярно перевіряйте журнали ПРРО та фіскальні документи, щоб швидко помітити операцію, якої користувач не виконував.
Окремий ключ не усуває всі ризики, але обмежує можливі наслідки. Ключ касира або печатки ПРРО не слід використовувати як основний підпис для звітності, банківських чи інших адміністративних операцій.
Хмарні ключі та підпис у смартфоні можуть бути доречними для операцій, де користувач особисто підтверджує кожен документ. Для автоматизованої касової роботи потрібно заздалегідь перевірити, чи підтримує обраний ПРРО відповідний тип ключа та як організовано регулярне підписання чеків.
6. Що дає незалежне підтвердження захисту
Коли система має належно підтверджений захист, користувач отримує не абсолютну гарантію, а додаткову перевірку процесів.
Незалежний аудит
Експерти можуть перевіряти архітектуру, налаштування серверів, правила доступу, журнали, резервне копіювання та реакцію на інциденти. Без незалежної перевірки користувач переважно покладається на внутрішні стандарти й репутацію розробника.
Захист від типових помилок
Перевірені процедури зменшують імовірність того, що пароль опиниться у відкритому журналі, резервній копії або конфігураційному файлі. Проте жоден сертифікат чи аудит не означає, що витік технічно неможливий.
Юридична визначеність
Документація системи, договори, журнали подій і підтверджені правила захисту допомагають установити обставини інциденту. За відсутності таких матеріалів користувачеві складніше довести, як саме стороння особа могла отримати доступ до ключа.
7. Розбір ризиків
Відсутність незалежної перевірки
За наявності підтвердженої системи захисту або аудиту: можна ознайомитися з межами перевірки, вимогами до інфраструктури й відповідальністю постачальника.
Без підтвердженої перевірки: доводиться покладатися на опис і внутрішні стандарти розробника. Якщо пароль помилково записується у відкритий лог або ключ передається до незахищеного сховища, користувач може дізнатися про це лише після інциденту.
Юридичний ризик
Якщо ключ використали для незаконної або помилкової операції, важливими будуть фактичні докази: хто мав доступ, де зберігався ключ, які журнали залишила система, коли власник повідомив про компрометацію та які дії виконав після виявлення ризику.
Наявність перевірених процедур не звільняє власника ключа від обов’язку зберігати його конфіденційність. Водночас добровільне передавання ключа і пароля сторонньому сервісу без перевірки значно підвищує ризик і послаблює позицію власника під час з’ясування обставин.
Резюме
Саме автоматичне підписання документів у ПРРО не означає, що ключ уже скомпрометований. Ключове питання — чи зберігає власник контроль над особистим ключем і чи виключений несанкціонований доступ до нього.
Гарантувати абсолютну безпеку не може жодна програма або сертифікат. Безпечніша практика — використовувати окремий ключ касира або електронну печатку ПРРО, не передавати файл ключа й пароль стороннім особам, перевіряти спосіб інтеграції, захищати робочий пристрій і контролювати журнал підписаних документів.
Масштаб бізнесу не скасовує цих правил. Для невеликої торгової точки наслідки можуть відрізнятися від ризиків великої мережі, але рішення слід приймати на основі реальної архітектури програми, цінності даних і можливого впливу інциденту, а не лише зручності автоматичного входу.