Неовластен пристап до сертификатот не претставува само безбедносен ризик. Тој претставува ризик за контролата, одговорноста и дигиталниот идентитет на компанијата.

🔐 Клучни пораки

✅ Сертификатот не е обичен фајл. Тој е дел од дигиталниот идентитет на компанијата.

✅ API интеграциите воведуваат нови безбедносни сценарија кои не постоеја кај класичната употреба на токен сертификати.

✅ Не сите решенија за е-Фактура користат иста безбедносна архитектура или ист модел за управување со сертификати.

✅ Доколку сертификатот, приватниот клуч и лозинката се достапни надвор од компанијата, потребни се дополнителни контроли, процедури и договорни обврски.

✅ Компаниите треба да знаат каде се чува сертификатот, кој има пристап до него и како се евидентира неговата употреба.

✅ Изборот помеѓу токен сертификат, софтверски сертификат и Azure Key Vault не е само техничка, туку и безбедносна и организациска одлука.

✅ Пред избор на решение за е-Фактура, побарајте објаснување на безбедносната архитектура, моделот за сертификати, корисничките улоги и ревизорската трага.

Со години дигиталните сертификати во Македонија се користат за пристап и потпишување документи во системите на УЈП, Централен регистар, деловните банки, електронските јавни набавки и други државни и приватни електронски услуги.

Во најголем дел од случаите сертификатот беше заштитен во физички токен. PIN кодот беше познат само на корисникот, а приватниот клуч никогаш не го напушташе уредот. Корисникот лично се најавуваше и лично ја потврдуваше секоја активност.

Со воведувањето на API интеграциите и автоматизираната размена на документи, особено во контекст на е-Фактура на УЈП, се појавува нова ситуација.

👉 Што се случува кога сертификатот повеќе не го користи човекот, туку софтверот?

За разлика од класичните веб апликации како кај УЈП, кај ERP и API интеграциите самата апликација мора да може да ги потпишува документите и комуникацијата кон надворешните системи. Во одредени архитектури тоа значи дека сертификатот, приватниот клуч и лозинката стануваат достапни за софтверот, а во одредени случаи и за добавувачот кој ја конфигурира интеграцијата.

Токму тука започнува новата безбедносна димензија на е-Фактура.

Овој текст не е наменет да создаде страв од сертификатите или од автоматизацијата.

Напротив. Целта е компаниите да ги разберат разликите помеѓу различните модели на работа, потенцијалните ризици и прашањата што треба да ги постават пред да донесат одлука за решение, интеграција или добавувач.

Безбедноста на сертификатите не зависи само од типот на сертификатот

Сертификатите сами по себе не се безбедни или небезбедни.

Во пракса, нивото на безбедност најчесто зависи од:

• каде се чува приватниот клуч,

• кој има пристап до него,

• дали може да се копира,

• како се контролира неговото користење,

• дали постои ревизорска трага,

• како се управува со промените на корисници и одговорни лица.

Токму поради тоа не постои еден универзално најдобар модел за сите организации.

Различни компании имаат различни потреби за автоматизација, контрола, достапност и безбедност.

Најчесто денес се користат три модели.

Три модели што денес се користат за е-Фактура

Модел	Ниво на автоматизација	Ниво на контрола на приватниот клуч	Корисничка интеракција	Типична употреба
🔵 Токен сертификат	Ниска	Висока	Да	Рачно потпишување
🟠 Софтверски сертификат	Висока	Средна до висока*	Не	ERP и API интеграции
🟢 Ентерпрајс модели (Azure Key Vault / HSM)	Многу висока	Многу висока	Не	Поголеми организации

Важно е да се разбере дека ниту еден модел не е апсолутно безбеден или апсолутно небезбеден. Разликата најчесто не е во сертификатот, туку во архитектурата на решението и начинот на кој компанијата управува со него.

🔵 Токен сертификат

Токен сертификатот е моделот со кој најголем дел од компаниите во Македонија веќе се запознаени преку УЈП, Централен регистар и деловните банки.

Неговата најголема предност е што приватниот клуч останува во физичкиот уред и не може лесно да се копира или пренесе.

Предности

• приватниот клуч не може лесно да се копира

• високо ниво на контрола

• јасна поврзаност помеѓу корисникот и потписот

• помал ризик од неовластено користење

Недостатоци

• отежната автоматизација

• зависност од достапност на корисникот

• ограничувања за работа во позадина

Најсоодветно за

• сопственици

• управители

• финансиски директори

• компании со помал број документи

🟠 Софтверски сертификат

Софтверските сертификати овозможуваат целосна автоматизација и затоа претставуваат најчестиот избор за ERP и API интеграции.

Меѓутоа, токму поради автоматизацијата, начинот на кој се управува со сертификатот добива многу поголемо значење отколку кај токен сертификатите.

Ако сертификатот не е соодветно заштитен, ризикот не произлегува од самиот сертификат, туку од начинот на негово складирање, користење и споделување.

Предности

• автоматска размена на документи

• нема потреба од физичко присуство

• поддршка за позадинска обработка

• висока оперативна ефикасност

Недостатоци

• сертификатот може да биде копиран

• потребни се дополнителни контроли

• потребни се процедури за управување со пристап

Најсоодветно за

• ERP системи

• API интеграции

• компании со поголем број фактури

• автоматизирани процеси

🟢 Enterprise модели за управување со сертификати

Кај овој модел приватниот клуч не е достапен директно на корисници или деловни апликации, туку се чува во специјализирана инфраструктура за управување со клучеви и дигитални потписи.

Примери се Azure Key Vault, HSM решенија и други enterprise платформи.

Предности

• највисоко ниво на безбедност

• централизирано управување

• подобра следливост

• поедноставена ротација на сертификати

• подобра усогласеност со безбедносни политики

Недостатоци

• поголема комплексност

• почетна конфигурација

• дополнителни трошоци

Најсоодветно за

• поголеми компании

• групации

• организации со повисоки безбедносни барања

⚖️ Кој модел е најсоодветен?

Не постои сертификат што е најдобар за сите компании.

Изборот најчесто зависи од:

• бројот на документи што се обработуваат,

• потребата за автоматизација,

• безбедносните политики,

• внатрешните контроли,

• улогите и одговорностите,

• ИТ инфраструктурата на организацијата.

Компании со мал број документи често успешно работат со токен сертификати.

Организации што бараат ERP и API интеграции најчесто користат софтверски сертификати.

Поголемите организации се’ почесто користат централизирани сервиси како Azure Key Vault или HSM решенија.

👤 Дигиталниот идентитет не треба да биде заедничка одговорност

Во добро организирана компанија секоја важна активност треба да има јасна одговорност.

Треба да биде познато:

• кој ја извршил активноста,

• кога ја извршил,

• со кои овластувања ја извршил,

• под чија одговорност се случила.

Истото правило треба да важи и за сертификатите.

Колку повеќе лица имаат пристап до ист сертификат, толку потешко станува да се утврди кој навистина ја извршил активноста.

Затоа безбедноста не се сведува само на заштита на сертификатот.

Таа се однесува и на зачувување на одговорноста и следливоста во компанијата.

⚠️ Најчести ризици поврзани со сертификатите

Во најголем дел од случаите проблемот не започнува со сертификатот.

Проблемот започнува кога организацијата ќе ја изгуби контролата врз него.

Најчестите ризици се:

• сертификатот е зачуван на повеќе локации;

• сертификатот е достапен на повеќе лица;

• лозинката е позната на повеќе корисници;

• не постои евиденција кој го користел сертификатот;

• не постои јасна одговорност за управување со сертификатот;

• не постојат процедури за промена на одговорни лица;

• не постојат процедури за заминување на вработени;

• постојат копии во тестни околини кои никогаш не биле отстранети.

Кога сертификатот ќе излезе надвор од компанијата

Во одредени интеграциски сценарија, компанијата може да биде побарана да обезбеди:

• сертификат,

• приватен клуч,

• лозинка,

за да може добавувачот на софтвер да ја воспостави комуникацијата со е-Фактура.

Таквиот пристап може да биде технички возможен. Но истовремено отвора дополнителни безбедносни ризици.

Откако сертификатот и лозинката ќе станат достапни надвор од компанијата, организацијата повеќе нема целосна контрола врз тоа:

• каде се чува сертификатот,

• колку копии постојат,

• кој има пристап,

• дали се користи во тестни околини,

• дали пристапите се ограничени,

• како се заштитени системите каде што е складиран.

Довербата е важна, но добрата безбедност мора да биде поддржана со процедури, контроли и јасно дефинирани одговорности.

Хипотетички пример

Компанија одлучува да воведе ERP интеграција со е-Фактура.

Добавувачот на софтвер бара:

• сертификат,

• приватен клуч,

• лозинка,

... за да ја конфигурира интеграцијата.

По некое време во компанијата никој повеќе не знае:

• каде е зачуван сертификатот,

• колку копии постојат,

• кој има пристап до нив,

• дали се користат во тестна околина,

• дали се избришани од старите системи.

Во текот на годините се менуваат вработени, сервери, инфраструктура и надворешни партнери, а компанијата сè потешко може да утврди каде се наоѓаат копиите од сертификатот и кој има пристап до нив.

По неколку години компанијата сака да утврди кој и кога користел одреден сертификат.

Во меѓувреме дел од вработените заминале, инфраструктурата е променета, а документацијата не е целосна.

Сертификатот се' уште функционира. Но одговорноста повеќе не е целосно јасна.

Не секогаш е проблем да се достави сертификат. Проблем е кога нема правила.

Во одредени случаи добавувачот на софтвер може легитимно да помогне во конфигурацијата на сертификатот.

Прашањето не е дали постои пристап.

Прашањето е како е контролиран тој пристап.

Добра практика е компанијата да знае:

• кој ќе има пристап;

• колку долго ќе трае пристапот;

• каде ќе биде зачуван сертификатот;

• дали ќе се чуваат копии;

• кои договорни обврски постојат;

• како ќе биде отстранет пристапот по завршувањето на конфигурацијата.

Кога овие правила се јасно дефинирани, ризикот значително се намалува.

Потенцијални последици од компромитиран сертификат

Најголем дел од организациите никогаш нема да доживеат безбедносен инцидент поврзан со сертификат. Но кога ќе се случи таков инцидент, последиците можат да бидат значајни.

Можни последици се:

• неовластено користење на дигиталниот идентитет,

• потпишување активности без знаење на одговорните лица,

• губење на контролата врз тоа кој ја извршил активноста,

• нарушување на ревизорската трага,

• дополнителни внатрешни и надворешни проверки,

• правни и регулаторни последици,

• нарушување на довербата кај деловните партнери.

Во вакви ситуации најголемиот проблем често не е самиот инцидент.

Најголемиот проблем е невозможноста недвосмислено да се утврди:

👉 кој ја извршил активноста и под чија одговорност се случила.

Ова е директно поврзано со темата на претходните текстови од оваа серија: одговорност, следливост и контрола.

Препорачани практики

Добрата безбедност не зависи од еден производ.

Таа зависи од процесите.

Препорачливо е компаниите да обезбедат:

✓ дефиниран сопственик на сертификатот

✓ јасно назначено одговорно лице

✓ евиденција на сите лица со пристап

✓ процедури за повлекување пристап

✓ периодична ревизија на овластувањата

✓ раздвојување на кориснички и административни улоги

✓ трага за извршените активности

✓ план за замена и обновување на сертификатите

✓ усогласување на сертификатите со внатрешните безбедносни политики

Не сите ERP решенија работат на ист начин

Кај некои решенија компанијата самостојно го внесува и управува сертификатот.

Кај некои решенија компанијата самостојно го внесува и управува сертификатот без да ги споделува сертификатот, приватниот клуч или лозинката со трета страна.

Кај други решенија конфигурацијата ја извршува добавувачот на софтвер.

Кај некои решенија постои поддршка за токен сертификати, софтверски сертификати и enterprise модели како Azure Key Vault.

Кај други постои само еден модел на работа.

Затоа при избор на решение не е доволно да се провери дали поддржува е-Фактура.

Подеднакво важно е да се разбере како е решено управувањето со сертификатите, корисниците и безбедноста.

🔍 Контролна листа за избор на решение и добавувач

При избор на решение за е-Фактура, препорачливо е компанијата да постави неколку дополнителни прашања.

Сертификати

□ Кои типови сертификати се поддржани?

□ Дали се поддржани токен сертификати?

□ Дали се поддржани софтверски сертификати?

□ Дали се поддржани Azure Key Vault или HSM решенија?

□ Дали компанијата може подоцна да премине на друг модел?

Управување со сертификати

□ Дали добавувачот бара копија од сертификатот?

□ Дали добавувачот бара приватен клуч?

□ Дали добавувачот бара лозинка?

□ Каде ќе биде складиран сертификатот?

□ Каде ќе биде складирана лозинката?

□ Дали сертификатот се користи само во продукција или и во тестни околини?

□ Дали компанијата може самостојно да го внесе и замени сертификатот?

Архитектура и ревизија

□ Дали секоја активност се евидентира по корисник?

□ Дали може да се утврди кој испратил документ?

□ Дали може да се утврди кој потпишал документ?

□ Дали може да се утврди кој ја променил конфигурацијата?

□ Дали системот обезбедува ревизорска трага за сите активности?

Корисници и контрола

□ Дали секој корисник има сопствен идентитет?

□ Дали постојат различни улоги и овластувања?

□ Дали може да се ограничи пристапот до одредени активности?

□ Дали се евидентира кој ја извршил активноста?

□ Дали постои ревизорска трага?

□ Дали пристапот може веднаш да се повлече?

Безбедност и одговорност

□ Кој е одговорен за управување со сертификатите?

□ Како се постапува при заминување на вработен?

□ Како се постапува при компромитација на сертификат?

□ Како се обновуваат сертификатите?

□ Дали постојат безбедносни процедури што можат да се презентираат на клиентот?

📋 Контролна листа за раководство

Пред пуштање во употреба на решение за е-Фактура, препорачливо е компанијата да може да потврди:

□ Познато е каде се чува сертификатот.

□ Познато е кој има пристап.

□ Познато е кој е одговорен за управување со сертификатот.

□ Постојат процедури за промена на одговорни лица.

□ Постојат процедури за заминување на вработени.

□ Се води евиденција за активностите.

□ Пристапот е ограничен само на потребните лица.

□ Избран е модел што одговара на организацијата и нејзините ризици.

□ Сертификатите се дел од вкупната ИТ и безбедносна политика на компанијата.

🎯 Заклучок

Со години сертификатите во Македонија најчесто се користеа преку веб апликации, каде корисникот лично го поседуваше токенот, го знаеше PIN кодот и лично ја потврдуваше секоја активност.

Со API интеграциите и автоматизираната размена на документи се појавуваат нови можности, но и нови одговорности.

Затоа при избор на решение за е-Фактура не е доволно да се провери дали поддржува интеграција со УЈП.

Подеднакво е важно да се разбере:

• каде се чува сертификатот,

• кој има пристап до него,

• како се евидентира неговото користење,

• како се заштитува дигиталниот идентитет на компанијата.

Сертификатот не е само средство за потпишување документи.

👉 Тој е дел од довербата, одговорноста и дигиталниот идентитет на компанијата.

🚀 Подготовката за е-Фактура започнува многу пред првата интеграција

Изборот на сертификат е само еден дел од подготовката.

Подеднакво важни се улогите, одговорностите, привилегиите, процедурите и безбедносните контроли што ќе ја придружуваат имплементацијата.

Во рамките на е-Фактура Readiness Program помагаме компаниите да ги анализираат сертификатите, привилегиите, организациските улоги, ризиците и безбедносните контроли пред изборот на решение и пред почетокот на имплементацијата.

Целта не е само успешно да се испрати првата е-Фактура.

Целта е компанијата да воспостави процес кој ќе биде безбеден, контролиран и одржлив и по пуштањето во работа.