Пишува: Ванчо Орданоски
Главен софтверски архитект, Инфопроект
Повеќето ИТ компании во Македонија во моментов брзаат да „додадат дигитален потпис“ за е-Фактура.
И тука е проблемот. Кај многу решенија, „дигитален потпис“ се сведува на:
- Копче „Потпиши“
- Еден сертификат некаде на сервер
- Неколку полиња во база
- Надеж дека тоа е доволно
А најчесто не е доволно.
Од 5 јануари 2026 системот е-Фактура е официјално пуштен, УЈП веќе работи со тестирање преку API, бара усогласување со техничките и функционалните барања, регистрација на валиден дигитален сертификат, и доставување дигитално потпишани тест е-фактури. УЈП јасно кажува и дека по успешна валидација фактурата добива единствен идентификатор, а тоа е моментот на нејзината правна важност.
Затоа прашањето не е дали сте „ставиле потпис“. Прашањето е дали сте изградиле систем за потпишување. Еве што, според мене, голем дел од фирмите најверојатно сè уште немаат разработено како што треба:
1. Каде и како се чуваат клучевите? Ако квалификуван клуч или печат стои како обичен фајл на сервер, достапен за повеќе луѓе или процеси, тоа не е сериозна архитектура. КИБС во својата документација зборува за цел животен циклус на сертификатите, управување, обновување, поништување, политики за квалификуван потпис и квалификуван печат, па дури и за документи за key ceremony и безбедносни процедури. Тоа не е случајно.
2. Дали правите разлика меѓу:
- Квалификуван електронски потпис,
- Квалификуван електронски печат,
- Интерен компаниски потпис,
- Далечинско потпишување од физичко лице?
Законот не ги третира сите исто. Квалификуваниот електронски потпис има правно дејство еднакво на своерачен потпис, а квалификуваниот електронски печат служи за докажување потекло и интегритет на податоците. Тоа се различни работи, со различни последици.
3. Дали знаете кој документ со што смее да се потпише? Една фактура не е исто што и интерен акт од Човечки ресурси. Договор со физичко лице не е исто што и излезна фактура. Кај едни случаи треба организациски печат, кај други потпис од овластено лице, а кај трети и потпис од самото физичко лице преку далечинска услуга.
4. Дали поддржувате повеќе клучеви и повеќе правила? Многу системи се прават како да постои „еден сертификат за фирмата“. Во пракса, една компанија може да има:
- различен сертификат за извозни и домашни фактури,
- различен потпис/печат по правен субјект,
- различни правила по подсистем,
- повеќе потписници по документ,
- сериски или паралелни потписи.
Ако ова не е моделирано однапред, многу брзо ќе завршите со импровизации во код и рачни исклучоци.
5. Дали имате траги и докази, или само “success = true”? Кај далечинско потпишување, провајдерите чуваат дневници за настанот, времето на потпишување, праќање/примање документ и системски идентификатори. Ако вашиот систем не чува сопствени детални траги, утре нема да можете да објасните:
- кој го иницирал потпишувањето,
- од кој систем дошло барањето за потпис,
- со кој сертификат било потпишано,
- дали сертификатот бил валиден во тој момент,
- кој документ точно бил потпишан,
- дали документот подоцна бил изменет.
6. Дали вршите валидација по потпишувањето? Не е доволно само да „се залепи“ потписот во PDF. Треба да се провери:
- дали потписот е технички валиден,
- дали синџирот е валиден,
- дали сертификатот е повлечен или истечен,
- дали е соодветен за таа намена,
- дали постои временски доказ кога е потпишано.
7. Дали имате план ако клучот утре стане невалиден? Поништување, истек, замена, суспензија, нов овластен потписник, промена на правно лице, промена на провајдер — сето ова мора да постои како процес, не како паника во продукција.
8. Дали личен потпис од клиент го третирате правилно?Кај договори со физички лица, системот не треба да се однесува како фирмата да го „поседува“ клучот на клиентот. Кај далечинско потпишување тоа е посебен провајдерски процес, со сопствена идентификација, логови и доказен траг.
9. Дали правите разлика меѓу тест и продукција? УЈП јасно наведува тест-платформа, регистрација на валиден сертификат, тест API и дека тест фактурите немаат правна или даночна важност. Ако некој прави „брза интеграција“ без јасно раздвоени средини, тоа е пат кон проблем.
10. Дали сте подготвени за прашањата што ќе ви ги постави клиентот кога ќе дојде ревизија? Не само „дали документот е потпишан“, туку:
- Кој клуч е користен?
- Кој имал пристап до него?
- Како е заштитен?
- Кој го одобрил тоа правило?
- Дали има логови?
- Дали има доказ за валидност во моментот на потпишување?
- Дали може да се реконструира настанот?
И тука доаѓа непријатниот дел.
Ако ова не е средено, ризикот не е само технички. Ризикот е:
- документот да биде оспорен,
- клиентот да падне на ревизија,
- да се отвори прашање за усогласеност со закон и интерни правила,
- да се појави спор околу тоа кој, кога и со што потпишал,
- да мора итно да се преправа архитектура што требало да биде поставена правилно од почеток.
Со други зборови: е-Фактура не е „уште едно API поле“. Тоа е нова довербена инфраструктура во софтверот.
Кој денес прави само „да помине потписот“, многу веројатно утре ќе прави:
- редизајн на безбедност,
- редизајн на логирање,
- редизајн на правила,
- и објаснување пред клиент зошто „потпишано“ не значело и „правилно спроведено“. И уште две многу важни прашања што скоро никој не ги отвора доволно гласно:
11. Каде физички и логички се чува клучот? Клуч за квалификуван потпис или квалификуван печат не смее во практика да се сведе на „фајл во некоја папка на сервер“. Не во keys/, не на desktop од администратор, не на споделен диск, не во backup zip, не во Docker image, не во environment variable што го знаат пет луѓе.
Токму затоа постојат HSM (Hardware Security Module) решенија и други безбедни уреди/средини за чување на клучеви. Нивната суштина е едноставна: приватниот клуч да не шета низ системот и да не биде лесно копиран, извезен или злоупотребен.
Кога клучот е чуван како обичен фајл, ризиците се многу конкретни:
- некој администратор може да го ископира без да остави јасна трага,
- може да влезе во backup, snapshot или реплика,
- може да биде преземен при пробив на сервер,
- може да биде употребен надвор од предвидениот процес,
- а после тоа сите ќе тврдат дека „системот формално потпишувал исправно“.
Не е поентата само документот да излезе потпишан. Поентата е да можете да докажете дека клучот бил чуван и користен на контролиран и безбеден начин.
12. Ако софтверот ви е SaaS, дали навистина сте подготвени да чувате туѓ квалификуван клуч кај вас? Ова е прашање што мора да си го постави секоја SaaS компанија.
Затоа што во тој момент вие не чувате само „уште една конфигурација на клиент“. Вие чувате средство со кое правно и деловно се потпишуваат документи во име на клиентот.
И тука веднаш следуваат непријатни прашања:
- Во која средина се чува клучот?
- Кој има пристап до него?
- Дали може да се извезе?
- Дали е одвоен по клиент?
- Што ако некој од вашиот тим има привилегиран пристап?
- Што ако ви биде компромитиран SaaS серверот?
- Што ако утре клиентот побара доказ дека никој кај вас не можел да го злоупотреби неговиот клуч?
- Како воопшто клиентот ќе ви го достави клучот, со remote upload? Колку е тоа безбедно?
Кај SaaS (Software as a service) ова е уште почувствително, затоа што клиентот практично мора да ви верува дека:
- неговиот клуч е изолиран,
- не може да се користи за друг клиент,
- не може да се копира,
- не може да се употреби рачно „од позадина“,
- и дека секое потпишување остава целосна и проверлива трага.
Ако ова не е решено архитектонски, тогаш SaaS моделот станува не само технички, туку и договорен, безбедносен и ревизорски ризик.
Во превод: ако продавате SaaS и планирате да чувате квалификувани клучеви кај вас, тогаш веќе не продавате само ERP, DMS или финансиски модул. Вие практично влегувате во зона на довербена инфраструктура, со многу поголема одговорност отколку што повеќето тимови си признаваат.
Затоа прашањето не е: „Може ли технички да го ставиме сертификатот на сервер?“
Туку: „Дали смееме, дали е безбедно, дали е одбранливо, и дали утре ќе можеме тоа да му го објасниме на клиент, ревизор или инспекција?“
Мој совет до сите што сега го допираат ова: почнете да размислувате во 4 слоја: правила, клучеви, докази, ревизија.
Ако еден од тие четири слоја ви недостасува, решението не е завршено.
