Чи можна вважати електронний ключ (підпис) скомпрометованим, якщо файл ключа та пароль передаються програмному РРО або пов’язаному сервісу для автоматичного підпису чеків?
Так. Якщо коротко: у більшості поширених моделей роботи ПРРО це вже не просто "ризик", а фактичний вихід за межі законного використання КЕП. Проблема не в самій цифровізації. Проблема в тому, що Закон України «Про електронну ідентифікацію та електронні довірчі послуги» № 2155-VIII вимагає одноосібного контролю над особистим ключем, тоді як практична модель ПРРО дуже часто будується навколо завантаження файла ключа, введення пароля в інтерфейс сторонньої системи, автоматичного підписання чеків агентом або винесення ключа в зовнішній сервіс. У такій конфігурації особистий ключ перестає бути особистим у юридичному сенсі.
Юридичний аспект: що саме вимагає закон
Закон № 2155-VIII прямо визначає, що компрометація особистого ключа - це будь-яка подія, що призвела або може призвести до несанкціонованого доступу до особистого ключа. Той самий закон зобов’язує користувача забезпечувати конфіденційність особистого ключа та неможливість доступу інших осіб до нього, невідкладно повідомляти надавача про підозру або факт компрометації і не використовувати ключ у разі його компрометації. Крім того, удосконалений електронний підпис або печатка мають створюватися з використанням ключа, який підписувач або створювач печатки використовує під власним одноосібним контролем, а кваліфікований електронний підпис має таку саму юридичну силу, як і власноручний підпис. Саме тому передача файла ключа, пароля або функції підписання сторонньому програмному контуру - це не побутова "зручність", а правова проблема.
Чому в моделі ПРРО це вже компрометація
Порядок реєстрації, ведення реєстру та застосування ПРРО, затверджений наказом Мінфіну № 317, дозволяє проводити розрахункові операції на ПРРО з використанням електронного підпису особи або електронної печатки суб’єкта господарювання після внесення сертифікатів до Реєстру. Але той самий Порядок № 317 окремо встановлює: використання електронної печатки в ПРРО можливе лише за умови доступу до особистого ключа печатки лише створювача або його уповноваженого представника та захисту такого ключа від несанкціонованого доступу інших осіб. Отже, сам нормативний акт для ПРРО виходить із того, що чужого доступу до ключа бути не повинно.
Тепер порівняймо це з практикою. Податкова служба у своїх роз’ясненнях прямо пише, що для роботи з ПРРО ключ касира та сертифікат потрібно помістити в одну папку на пристрої, з якого буде здійснюватися робота. ДПС також окремо пояснює, що якщо програмне забезпечення ПРРО просить вказати шлях до секретного ключа і сертифіката, то вони повинні перебувати в одній теці. Тобто навіть офіційна модель ПРРО виходить із того, що особистий ключ працює всередині прикладного програмного середовища, а не залишається повністю відокремленим від нього.
Що показує практика комерційних ПРРО
У документації Checkbox.Підпис прямо сказано, що це ПЗ автоматично підписує чеки, які потім відправляються в ДПС, і що завдяки цьому не потрібно підписувати кожен чек вручну. Там же рекомендується завантажити файловий ЕЦП касира на "захищений хмарний сервіс" для автоматичного підписання транзакцій без участі касира. А в довідці для касирів Checkbox описує запуск такого сервісу через додавання файла ключа, введення пароля і появу статусу "Агент підпису працює". Це означає, що підпис уже не є окремим усвідомленим актом людини, а вбудовується в сервісну автоматизовану інфраструктуру.
У документації Device Manager від Вчасно.Каса прямо зазначено, що застосунок служить для збереження і використання ключа ЕЦП для підпису чеків та інтегрується з іншими системами через HTTP REST API. На сторінці "Електронний підпис для роботи ПРРО" сказано, що для роботи з ПРРО обов’язково використовується електронний ключ для підписання всіх чеків, що надсилаються в ДПС, а серед варіантів прямо названо файловий ключ, хмарний підпис і підписання через сховище ключів Вчасно.Каса. На сторінці створення ПРРО Вчасно.Каса також вказує, що ключ для підпису чеків можна завантажити, а при використанні сховища Вчасно.Каса ключ потрібно обов’язково завантажити до цього сховища. Це вже не особисте використання ключа, а передача його в сторонній прикладний контур.
До чого це призводить з точки зору закону
Оскільки закон визначає компрометацію як подію, що призвела або може призвести до несанкціонованого доступу, то передача файла ключа, введення пароля у сторонньому інтерфейсі, завантаження ключа в окремий сервіс, збереження ключа в прикладній системі або автоматичне підписання чеків без участі касира дають усі підстави вважати, що особистий ключ уже використовується поза межами одноосібного контролю. А це саме та межа, яку захищає Закон № 2155-VIII.
Далі спрацьовують прямі правові наслідки. Порядок № 317 передбачає, що у разі виявлення компрометації особистого ключа суб’єкт господарювання протягом дня зобов’язаний подати повідомлення за формою № 2-ПРРО до контролюючого органу, виробника ПРРО та/або центру сервісного обслуговування. Більше того, реєстрація ПРРО скасовується, зокрема, на підставі такого повідомлення з позначкою "крадіжка пристрою чи компрометація ключа". Окремо КНЕДП ДПС зазначає, що обробка заяви про блокування або поновлення сертифіката та інформування користувача мають бути здійснені протягом двох годин з моменту отримання заяви. Тобто закон не знає конструкції "ключ уже переданий у сторонній сервіс, але це нормально". Навпаки, він запускає процедуру повідомлення, блокування і припинення роботи такого ключа.
Юридичний ризик посилюється тим, що кваліфікований електронний підпис має таку саму юридичну силу, як і власноручний підпис. Це означає, що чеки, звіти та інші електронні документи, які проходять через ПРРО з використанням такого ключа, зовні вважаються діями самого підписувача або створювача печатки. Іншими словами, система може працювати автоматично, а відповідальність лишається персональною.
Чому посилання лише на КСЗІ не вирішує проблему
Питання КСЗІ важливе, але воно не скасовує вимоги Закону № 2155-VIII про одноосібний контроль над особистим ключем. Справді, окремі постачальники ПРРО вже публічно заявляють про проходження КСЗІ. Наприклад, Checkbox пише про отримання атестата відповідності КСЗІ, а в довідці для касирів називає себе першим ПРРО, який пройшов державну атестацію КСЗІ. Але навіть якщо припустити, що конкретний провайдер добре захищає свою інфраструктуру, це не знімає головного питання: чи залишився особистий ключ під одноосібним контролем підписувача, якщо він завантажений у сторонню систему, запускає автоматичне підписання або працює через окремий агент чи зовнішнє сховище? Відповідь тут негативна: КСЗІ може стосуватися захисту системи, але не перетворює сервісне автоматичне використання ключа назад на особистий підпис людини.
Технічні ризики: чому це небезпечно на практиці
Коли ключ і пароль передаються ПРРО або пов’язаному сервісу, виникають очевидні технічні ризики: з’являється додаткова точка збереження або використання ключа; підписання може відбуватися автоматично без прямої участі касира; ключ починає працювати через агент, веб-сервіс, API або окреме сховище; а помилка, збій або несанкціонований доступ тягнуть за собою вже не лише технічні, а й податкові та правові наслідки. Це не припущення "зі стелі", а логічний висновок із тієї архітектури, яку самі постачальники ПРРО описують у власній документації.
Показово, що навіть сама ДПС у своїх роз’ясненнях рекомендує для кожного ПРРО реєструвати та застосовувати окремий ключ касира. Така порада не усуває проблему, але добре показує її масштаб: ризик уже настільки очевидний, що його пропонують хоча б локалізувати рознесенням по різних ключах. Це не доказ безпечності моделі, а навпаки - доказ її початкової вразливості.
Як зрозуміти, що модель ПРРО є небезпечною
Модель слід вважати небезпечною, якщо система просить завантажити файл ключа до свого інтерфейсу або власного сховища, просить ввести пароль від ключа у своєму вікні, рекламує автоматичне підписання чеків без участі касира, використовує окремий агент чи сервіс, який "працює" з ключем замість людини, або переносить ключ у хмарний сервіс самого постачальника ПРРО. Якщо хоча б один із цих елементів є частиною штатної роботи системи, говорити про повний одноосібний контроль підписувача над особистим ключем уже немає підстав.
Висновок
Якщо файл ключа та пароль передаються ПРРО, його агенту, зовнішньому сервісу або внутрішньому сховищу для автоматичного підписання чеків, це слід розцінювати не як "зручну автоматизацію", а як використання КЕП у режимі, що суперечить самій логіці закону. З правової точки зору проблема виникає не тоді, коли хтось уже довів крадіжку ключа. Вона виникає раніше - у той момент, коли створено режим, за якого сторонній доступ до особистого ключа стає можливим або коли сам підпис виходить з-під одноосібного контролю підписувача. Саме тому в нинішній масовій моделі ПРРО є всі підстави говорити не просто про ризик, а про фактичну компрометацію особистого ключа в розумінні закону.
Основні посилання :
Закон України «Про електронну ідентифікацію та електронні довірчі послуги» № 2155-VIII
Наказ Мінфіну № 317 / Порядок реєстрації, ведення реєстру та застосування ПРРО
ДПС: як зареєструвати ПРРО - ключ і сертифікат в одній папці
ДПС: дії, якщо ПЗ ПРРО вимагає шлях до ключа і сертифіката
ДПС: для кожного ПРРО - окремий ключ касира
КНЕДП ДПС: блокування, скасування та поновлення сертифікатів
Checkbox.Підпис
Checkbox: робота з ключами касира
Device Manager від Вчасно.Каса
Вчасно.Каса: електронний підпис для роботи ПРРО
Вчасно.Каса: створення ПРРО і завантаження ключа
Checkbox: повідомлення про отримання атестата КСЗІ
