Унапређење сервиса за локално дигитално потписивање и унапређење структуре квалификованих електронских сертификата за потпис

Tehnicka - Unapredjenje sistema za potpisivanje.docx ТЕХНИЧКА СПЕЦИФИКАЦИЈА – ВРСТА И ОПИС ПРЕДМЕТА НАБАВКЕ Предмет набавке је унапређење сервиса за локално дигитално потписивање EupravaDigSignService, као и унапређење структуре квалификованих електронских сертификата за потпис у клауду, а у складу са овом Спецификацијом. Појмови и скраћенице Термин Опис eID Electronic Identification – национални систем електронске идентификације у оквиру чијег екосистема се користе функционалности обухваћене овом техничком спецификацијом. API Application Programming Interface – програмски интерфејс који омогућава комуникацију и размену података између софтверских компоненти. HTTPS Hypertext Transfer Protocol Secure – HTTP комуникација заштићена применом TLS протокола. JSON JavaScript Object Notation – структурирани формат за размену података између клијентске апликације и локалног сервиса. PDF Portable Document Format – формат електронског документа за који сервис обезбеђује квалификовано електронско потписивање. XML Extensible Markup Language – структурирани формат података за који сервис обезбеђује електронско потписивање. XAdES XML Advanced Electronic Signatures – стандард за напредне електронске потписе над XML документима. XML-DSig XML Digital Signature – основни стандард за креирање XML електронских потписа на којем се заснива XAdES. PKCS#11 Public-Key Cryptography Standards #11 – стандардни програмски интерфејс за приступ криптографским уређајима, smart картицама и токенима. middleware Посреднички софтверски слој који обезбеђује комуникацију између локалног сервиса и PKCS#11 криптографског уређаја. smart картица Криптографски уређај на којем се налазе приватни кључ и дигитални сертификат корисника, у класичном ID-1 формату или у оквиру USB токена. PIN Personal Identification Number – поверљиви код који корисник уноси ради приступа приватном кључу на smart картици или USB токену. USB Universal Serial Bus – интерфејс који се, између осталог, користи за повезивање криптографских токена са корисничким рачунаром. TLS Transport Layer Security – криптографски протокол за заштиту комуникације и преноса података преко мреже. SSL Secure Sockets Layer – претходна генерација протокола за заштиту мрежне комуникације која се у оквиру захтева ове спецификације не користи. Base64 Начин кодирања бинарних података у текстуални облик ради преноса садржаја документа и резултујућег потписа унутар JSON захтева и одговора. CA Certification Authority – сертификационо тело, односно систем/организација која издаје и управља електронским сертификатима. ADSS Ascertia Digital Signing Server – платформа у оквиру које су дефинисани профили квалификованих електронских сертификата обухваћени овом спецификацијом. Certificate Templates Профили у оквиру ADSS платформе којима се дефинишу структура и релевантни параметри електронских сертификата. Certificate Policies Екстензија електронског сертификата која садржи идентификаторе политика сертификата. qcStatements Qualified Certificate Statements – стандардизована екстензија квалификованог електронског сертификата која садржи изјаве о његовим квалификованим својствима. Subject Поље електронског сертификата које садржи податке о субјекту на кога се сертификат односи. Common Name / commonName Атрибут Subject поља сертификата који у предметном профилу садржи име и презиме субјекта. serialNumber Атрибут сертификата у којем се задржава нумерички идентификатор потребан за једнозначну идентификацију субјекта. Key Usage Екстензија електронског сертификата којом се дефинишу дозвољене намене криптографског кључа, укључујући Digital Signature и Non-Repudiation у сценаријима дефинисаним овом спецификацијом. 1. Увод Електронско потписивање представља важан део eID екосистема и ослања се на међусобно усклађен рад клијентских компоненти за локално потписивање, криптографских уређаја и квалификованих електронских сертификата. Поузданост, интероперабилност и одрживост овог процеса зависе како од функционалности сервиса којим се потписивање реализује на корисничком рачунару, тако и од исправно дефинисане структуре сертификата који се у процесу користе. Овом техничком спецификацијом су обухваћене две развојне целине: унапређење сервиса за локално дигитално потписивање докумената и унапређење структуре квалификованих електронских сертификата за електронски потпис у клауду. Заједнички циљ развојних активности је унапређење функционалности, компатибилности, конфигурабилности и безбедности локалног процеса електронског потписивања, као и усаглашавање релевантних елемената профила квалификованих електронских сертификата са захтевима и стандардима који се на њих примењују, уз очување стабилности постојећих процеса и континуитета пружања услуга. 1.1 Предмет и обухват набавке Предмет набавке је реализација скупа функционалних, техничких и конфигурационих унапређења у области локалног дигиталног потписивања и квалификованих електронских сертификата за потпис у клауду, у складу са захтевима дефинисаним овом техничком спецификацијом. Добављач је у обавези да реализује, тестира и испоручи све активности које припадају следећим развојним целинама: развој и имплементација нове верзије локалног сервиса EupravaDigSignService, намењеног креирању квалификованих електронских потписа над PDF и XML документима коришћењем приватних кључева и дигиталних сертификата смештених на smart картицама крајњих корисника; унапређење профила квалификованих електронских сертификата за електронски потпис у клауду, кроз измену идентификатора политике сертификата, допуну изјава у оквиру qcStatements екстензије и усаглашавање формата појединих Subject атрибута. Све активности морају бити реализоване контролисано и верификоване у складу са функционалним, интеграционим, безбедносним и другим критеријумима дефинисаним у одговарајућим деловима ове техничке спецификације. 1.2 Развојне целине Техничка спецификација организована је кроз две развојне целине: Сервис за локално дигитално потписивање докумената – развој нове верзије локалног сервиса, унапређење подршке за PDF и XML потписивање, сертификациона тела и крипто-уређаје, управљање PKCS#11 middleware-ом, корисничку интеракцију, безбедност и API комуникацију; Унапређење структуре квалификованих електронских сертификата за потпис у клауду – циљане измене профила сертификата у ADSS платформи и релевантним компонентама процеса издавања сертификата. 2. Сервис за локално дигитално потписивање докумената 2.1 Контекст унапређења Локални сервис за дигитално потписивање представља саставни део eID екосистема који омогућава креирање квалификованих електронских потписа коришћењем приватних кључева смештених на smart картицама крајњих корисника. Сервис представља везу између wеб апликација које иницирају поступак електронског потписивања и локалних безбедносних уређаја корисника (smart картица), обезбеђујући поуздано извршавање процеса потписивања PDF и XML докумената. Постојећа имплементација успешно је подржавала досадашње потребе система, али су током експлоатације идентификована функционална и техничка ограничења која утичу на компатибилност са различитим типовима smart картица, флексибилност конфигурације, могућности визуелне репрезентације потписа и ниво безбедносних контрола током процеса електронског потписивања. Предмет унапређења је развој нове верзије сервиса којом се унапређује функционалност, компатибилност, конфигурабилност и безбедност процеса локалног дигиталног потписивања докумената. 2.2 Предмет набавке Добављач је у обавези да имплементира, тестира и испоручи нову верзију локалног сервиса EupravaDigSignService, намењеног креирању квалификованих електронских потписа над PDF и XML документима коришћењем приватних кључева и дигиталних сертификата смештених на smart клартицама крајњих корисника. Имплементирано решење треба да обезбеди унапређену подршку за различите квалификоване сертификационе ауторитете и типове smart картица, проширене могућности електронског потписивања, флексибилнију конфигурацију PKCS#11 middleware, унапређене безбедносне контроле, као и стандардизован HTTPS/JSON интерфејс за комуникацију са клијентским апликацијама. 2.3 Обухват развоја Добављач је у обавези да у оквиру развоја имплементира следећа функционална унапређења: реализацију локалног HTTPS сервиса доступног на корисничком рачунару; имплементацију стандардизованог JSON API-ја за комуникацију са клијентским апликацијама; подршку за дигитално потписивање PDF докумената са унапређеном визуелном репрезентацијом потписа; подршку за дигитално потписивање XML докумената у складу са XAdES стандардом; подршку за комбиновано потписивање PDF и XML докумената у оквиру јединственог захтева; унапређење компатибилности са различитим квалификованим сертификационим ауторитетима и smart картицама; унапређење конфигурабилности PKCS#11 middleware; унапређење корисничке интеракције током процеса електронског потписивања; унапређење безбедносних контрола процеса електронског потписивања; имплементацију API интерфејса дефинисаног овом техничком спецификацијом. 2.4 Функционална спецификација Ово поглавље дефинише функционалне захтеве које је Добављач у обавези да реализује у оквиру развоја нове верзије локалног сервиса EupravaDigSignService. Функционалности су организоване у логичке целине које обухватају комуникациони модел сервиса, подршку за дигитално потписивање PDF и XML докумената, интероперабилност са квалификованим сертификационим телима и smart картицама, управљање конфигурацијом, унапређење корисничке интеракције и примену безбедносних механизама. Свака функционална целина представља скуп захтева који чине основ за пројектовање, имплементацију, тестирање и испоруку унапређеног решења. 2.4.1 Локални HTTPS сервис и комуникациони модел Добављач треба да развије нову верзију сервиса као локални HTTPS сервис који се покреће на корисничком рачунару и представља комуникациони слој између клијентских апликација и smart картица коришћених за електронско потписивање садржаја докумената. Сервис прихвата захтеве за потписивање путем стандардизованог JSON API-ја, комуницира са smart картицом преко PKCS#11 middleware и након успешно извршеног процеса враћа потписани документ апликацији која је иницирала захтев. Сервис мора обезбедити следеће основне функционалности: дигитално потписивање PDF докумената, са или без визуелне репрезентације потписа; дигитално потписивање XML докумената применом XAdES стандарда; комбиновано потписивање PDF и XML докумената у оквиру јединственог захтева, уз једно уношење PIN кода smart картице. 2.4.2 Подршка за дигитално потписивање PDF докумената Нова верзија сервиса омогућава креирање квалификованих електронских потписа над PDF документима уз унапређену контролу процеса потписивања и проширене могућности дефинисања визуелне репрезентације електронског потписа. Сервис омогућава потписивање PDF докумената, дефинисање позиције и изгледа визуелног потписа, избор странице документа на којој ће потпис бити приказан, управљање садржајем визуелне репрезентације потписа, као и дефинисање параметара који одређују начин креирања електронског потписа у складу са захтевима система. У оквиру реализације потребно је да Добављач обезбеди следеће функционалности: могућност избора једне од шест унапред дефинисаних позиција за приказ визуелне репрезентације потписа (горе лево, горе средина, горе десно, доле лево, доле средина и доле десно), уз аутоматско прилагођавање величине приказа садржају (fit-to-content); могућност произвољног позиционирања визуелне репрезентације потписа у pdf документу дефинисањем X и Y координата, као и референтне тачке правоугаоника за приказ потписа; могућност избора странице PDF документа на којој ће бити приказана визуелна репрезентација потписа; могућност конфигурације садржаја визуелне репрезентације потписа који може обухватити податке из сертификата потписника, датум и време креирања потписа, као и произвољан текст прослеђен од стране клијентске апликације; могућност дефинисања врсте и величине фонта који се користи за приказ садржаја визуелне репрезентације потписа; подршку за креирање квалификованог електронског потписа без визуелне репрезентације на PDF документу (невидљив потпис), уз очување потпуне валидности и могућности верификације потписа стандардним алатима. 2.4.3 Подршка за дигитално потписивање XML докумената Сервис треба да омогући креирање квалификованих електронских потписа над XML документима у складу са XAdES (XML Advanced Electronic Signatures) стандардом, који представља проширење XML-DSig стандарда и омогућава укључивање додатних квалификованих атрибута електронског потписа у складу са захтевима за напредни и квалификовани електронски потпис. Имплементација обухвата обраду произвољних XML докумената, креирање одговарајуће структуре електронског потписа и враћање потписаног документа клијентској апликацији путем стандардизованог HTTPS/JSON интерфејса. Добављач треба да развије сервис који треба да обезбеди следеће функционалности: креирање квалификованог електронског потписа над произвољним XML документима применом XAdES стандарда, укључујући XML-DSig потпис и додатне квалификоване атрибуте, као што су време потписивања, подаци о сертификату потписника и политика потписивања; коришћење истог механизма за избор и валидацију сертификата потписника који се примењује и приликом потписивања PDF докумената, чиме се обезбеђује јединствено понашање сервиса без обзира на тип документа; могућност комбинованог потписивања XML и PDF документа у оквиру једног HTTPS захтева, коришћењем исте отворене сесије према smart картици и уз једно уношење PIN кода за оба потписа. 2.4.4 Подршка за сертификациона тела и крипто-уређаје Сервис мора обезбедити компатибилност са квалификованим дигиталним сертификатима издатим од стране свих квалификованих пружаоца услуга од поверења у Републици Србији, као и поуздан рад са различитим типовима smart картица који користе PKCS#11 стандард. Имплементација обухвата подршку за класичне smart картице интегрисане у ID-1 формату (стандардне пластичне картице пуне величине са интегрисаним криптографским чипом, које се користе посредством читача smart картица) и smart картице интегрисане у USB токенима, уз унапређење механизама за детекцију уређаја, управљање PKCS#11 сесијама и избор одговарајућег сертификата за електронско потписивање. Циљ унапређења је обезбеђивање јединственог и поузданог понашања сервиса, независно од произвођача сертификата или типа smart картице. Сервис, који развија Добављач, мора обезбедити следеће функционалности: подршку за креирање квалификованих електронских потписа коришћењем класичних smart картица и USB токена издатих од свих сертификационих тела регистрованих у Републици Србији (Пошта Србије, Министарство унутрашњих послова Републике Србије, Министарсво одбране Републике Србије, eSmart,Halcom и Привредна комора Србије); унапређен механизам за детекцију и коришћење класичних smart картица, којим се обезбеђује поуздан рад након промена PKCS#11 middleware, укључујући исправно проналажење асиметричног приватног кључа и одговарајућег дигиталног сертификата за електронско потписивање; унапређену подршку за smart картице у USB токенима кроз оптимизацију логике иницијализације и коришћења PKCS#11 модула, укључујући правилно препознавање USB уређаја и коректно управљање животним циклусом PKCS#11 сесије (иницијализација и финализација модула), чиме се спречавају конфликти приликом узастопних захтева према истом уређају; јединствен механизам за избор дигиталног сертификата и асиметричног приватног кључа за електронско потписивање, независно од квалификованог сертификационог тела или типа smart картице који корисник користи. 2.4.5 Управљање конфигурацијом PKCS#11 middleware-а Сервис мора омогућити флексибилно управљање конфигурацијом PKCS#11 middleware-а без потребе за изменом изворног кода или поновном компилацијом апликације. Имплементација треба да обезбеди конфигурабилно управљање параметрима који дефинишу подржане PKCS#11 библиотеке и начин њиховог коришћења, чиме се поједностављује одржавање сервиса и омогућава једноставније прилагођавање новим сертификационим телима, верзијама middleware-а и променама у корисничком окружењу. Добављач кроз нову верзију сервиса, треба да обезбеди следеће функционалности: могућност дефинисања и одржавања листе подржаних PKCS#11 библиотека путем конфигурационих параметара, без потребе за изменом апликативног кода; учитавање конфигурације PKCS#11 библиотека из Windows registry или environment варијабле приликом покретања сервиса, при чему конфигурација мора омогућити једноставно додавање, измену или уклањање подржаних middleware библиотека; аутоматско коришћење одговарајуће PKCS#11 библиотеке на основу конфигурације и доступне smart картице, без додатне интервенције корисника; могућност проширења подршке за нове PKCS#11 библиотеке и сертификациона тела искључиво изменом конфигурације (Windows registry ili environment варијабле без потребе за развојем нове верзије сервиса). 2.4.6 Корисничка интеракција током процеса потписивања Сервис мора обезбедити једноставно, јасно и конзистентно корисничко искуство током процеса електронског потписивања, независно од типа smart картице или квалификованог сертификационог тела које корисник користи. Имплементација треба да унапреди начин интеракције са корисником током процеса потписивања, унос PIN кода smart картице и приказ информација о току извршавања процеса. Циљ унапређења је смањење могућности корисничких грешака, повећање прегледности процеса и обезбеђивање уједначеног начина рада за све подржане сценарије електронског потписивања. Добављач, кроз нову верзију сервиса, мора да обезбеди следеће функционалности: приказ стандардног дијалога за унос PIN кода одговарајуће smart картице, при чему сервис не сме евидентирати нити трајно чувати унети PIN; поновно коришћење постојеће аутентиковане PKCS#11 сесије када се у оквиру једног захтева извршава више операција електронског потписивања, чиме се избегава вишеструко тражење уноса PIN кода од корисника; приказ јасних и разумљивих порука о грешкама и статусу извршавања процеса електронског потписивања, како би корисник могао да препозна узрок евентуалног неуспешног извршавања и предузме одговарајуће активности. 2.4.7 Безбедносни захтеви сервиса Сервис мора обезбедити безбедно извршавање процеса електронског потписивања и заштиту приватних асиметричних криптографских кључева који се налазе на smart картицама. Безбедносна унапређења обухватају проверу валидности дигиталних сертификата, избор искључиво сертификата намењених за електронско потписивање, заштиту комуникације између клијентских апликација и локалног сервиса, као и примену дефинисаних безбедносних стандарда и протокола током размене података. Сервис, који је предмет развоја од стране Добављача, треба да обезбеди следеће функционалности: проверу временске валидности дигиталног сертификата пре креирања електронског потписа, при чему сервис мора утврдити да ли је тренутни тренутак унутар периода важења сертификата дефинисаног атрибутима Not Before и Not After. Уколико сертификат није временски валидан, захтев за потписивање мора бити одбијен и електронски потпис не сме бити креиран; избор искључиво дигиталних сертификата намењених за електронско потписивање, при чему сервис мора користити само сертификате чија X.509 v3 екстензија Key Usage садржи одговарајуће атрибуте Digital Signature и Non-Repudiation, односно сертификате који су намењени за креирање квалификованих електронских потписа; реализацију комплетне комуникације између клијентске апликације и локалног сервиса искључиво коришћењем HTTPS протокола, уз подршку за TLS 1.3 као примарни протокол и TLS 1.2 ради компатибилности са постојећим окружењима. Употреба застарелих протокола (SSL, TLS 1.0 и TLS 1.1) не сме бити подржана. 2.5 API спецификација Ово поглавље дефинише API интерфејс локалног сервиса EupravaDigSignService, који омогућава стандардизовану комуникацију између клијентских апликација и сервиса за локално дигитално потписивање докумената. API је заснован на HTTPS комуникацији и размени података у JSON формату и представља јединствени комуникациони механизам за коришћење функционалности дефинисаних овом техничком спецификацијом. API спецификација обухвата опис доступних операција, структуру улазних и излазних параметара, формат размене података, као и очекивано понашање сервиса приликом обраде захтева. Сервис мора излагати следеће HTTP (POST, JSON) endpoint-e: Endpoint Опис /getcurrentversion Враћа текућу верзију сервиса – за проверу доступности/верзије без интеракције са smart картицом. /SignXml Креира XAdES електронски потпис над прослеђеним садржајем XML документа. /SignPDF Креира електронски потпис над прослеђеним садржајем PDF документа, уз конфигурабилну визуелну репрезентацију (поглавље 2.4.2) или без ње. /SignXmlAndPDF Комбиновано потписивање садржаја XML и PDF документа у оквиру једног захтева, уз једно уношење PIN кода smart картице за оба потписа. Улазни и излазни подаци (садржај документа, резултујући потпис) морају се преносити у Base64-кодираном облику унутар JSON тела захтева/одговора. 2.6 Критеријуми прихватања Имплементација нове верзије сервиса сматраће се прихваћеном уколико су реализоване све функционалности дефинисане овом техничком спецификацијом и уколико сервис успешно прође предвиђене процедуре функционалног, интеграционог и прихватног тестирања. Критеријуми прихватања представљају основ за верификацију исправности имплементације, потврду усклађености са дефинисаним функционалним и безбедносним захтевима, као и проверу интероперабилности са подржаним квалификованим сертификационим телима, smart картицама и клијентским апликацијама. Прихватљиво решење мора обезбедити стабилан и поуздан рад сервиса у свим сценаријима дефинисаним овом техничком спецификацијом. Реализација се сматра успешном када су испуњени следећи критеријуми: Успешно потписивање PDF и XML докумената smart картицама свих пет сертификационих тела (ПТТ, МУП, Министарство одбране реоублике Србије, eSmart, Halcom, ПКС), укључујући и USB токене. Додавање/измена PKCS#11 middleware-а могуће искључиво изменом registry конфигурације или environment променљиве, без измене и рекомпајлирања изворног кода. Дијалог за унос PIN кода приказује назив (лабелу) токена/картице за који се PIN тражи. Визуелна репрезентација PDF потписа подржава шест предефинисаних позиција, произвољне (X, Y) координате, избор странице, конфигурабилан садржај и фонт, као и невидљив потпис. Комбиновано XML+PDF електронско потписивање у једном захтеву извршава се уз једно уношење PIN кода smart картице. Сервис одбија потписивање временски невалидним сертификатом и бира искључиво сертификат са Key Usage који има постављене бите Digital Signature и Non-Repudiation. Комуникација је могућа искључиво преко TLS 1.3 (односно TLS 1.2 као резервне опције); SSL и TLS 1.0/1.1 су онемогућени. 3. Унапређење структуре квалификованих електронских сертификата 3.1 Контекст унапређења Циљ ове развојне целине је унапређење профила квалификованих електронских сертификата за електронски потпис у кладу (Cloud Signing), кроз измену идентификатора политике сертификата, допуну изјава у оквиру qcStatements екстензије и усаглашавање формата појединих Subject атрибута. Предвиђене измене треба да обезбеде да структура и садржај сертификата буду усклађени са релевантним захтевима и стандардима који се примењују на квалификоване електронске сертификате, уз очување стабилности постојећег процеса издавања сертификата и континуитета пружања сертификационих услуга. 3.2 Предмет набавке Сертификационо тело издаје квалификоване електронске сертификате за електронски потпис кроз ADSS платформу, на основу профила дефинисаних у оквиру Certificate Templates. Анализом постојећих профила сертификата идентификована је потреба за изменом појединих елемената њихове структуре и садржаја. Идентификована унапређења односе се на садржај Certificate Policies екстензије, изјаве у оквиру qcStatements екстензије, као и формат појединих атрибута у Subject пољу сертификата. Потреба за реализацијом предметних унапређења произлази из обавезе усклађивања постојећег система са новим регулаторним захтевима који се односе на квалификована средства за креирање електронског потписа и електронског печата. Наведени захтеви произлазе из измена и допуна Правилника о условима које мора да испуњава квалификовано средство за креирање електронског потписа односно печата и условима које мора да испуњава именовано тело, као и из релевантних ETSI стандарда на које се наведени пропис позива. Имајући у виду да је за примену појединих нових захтева прописан прелазни рок, неопходно је благовремено извршити одговарајуће измене и доградње система како би се обезбедила његова пуна функционална и регулаторна усаглашеност по истеку прописаног рока за примену нових одредаба. Предметна развојна целина обухвата имплементацију свих неопходних функционалности, измена пословне логике и техничких механизама чија је сврха обезбеђивање усклађености система са важећим прописима и стандардима који регулишу употребу квалификованих средстава за креирање електронског потписа и електронског печата. Реализација ових измена захтева циљане измене конфигурације профила сертификата у ADSS платформи, као и измене у компонентама које учествују у формирању података за издавање сертификата, тамо где је то применљиво. Све измене од стране Добављача, морају бити реализоване контролисано, уз претходну верификацију на тест и acceptance окружењима и потврду да не нарушавају постојеће процесе издавања и коришћења квалификованих електронских сертификата. Напомена: Измене дефинисане овом развојном целином примењују се на сертификате издате након имплементације нових профила сертификата. Постојећи, претходно издати сертификати нису предмет измене или поновног издавања у оквиру ове техничке спецификације и настављају да се користе у складу са својим важећим статусом и периодом важења. 3.3 Усклађивање идентификатора политике сертификата (Certificate Policies) Добављач је у обавези да спроведе следеће активности: уклони идентификатор политике која није прописана од стране Републике Србије (МИТ) из профила сертификата за електронски потпис, уколико постоји; омогући задржавање сопственог идентификатора политике Сертификационог тела. 3.3.1 Предвиђено унапређење Профили сертификата за електронски потпис тренутно у Certificate Policies екстензији садрже два идентификатора политике: стандардни идентификатор дефинисан у оквиру постојећег модела и идентификатор политике Сертификационог тела. У оквиру унапређења профила сертификата потребно је прећи на модел у којем се у издатом сертификату користи идентификатор политике Сертификационог тела који је јасно дефинисан, документован и указуjе на званичну политику CA. Потребно је да Добављач усклади садржај Certificate Policies екстензије тако да издати сертификати садрже искључиво идентификатор политике Сертификационог тела, који мора бити јасно дефинисан, документован и доследно примењен на одговарајуће профиле сертификата. Предвиђа се измена конфигурације профила сертификата за електронски потпис у ADSS платформи уклањањем постојећег спољног идентификатора политике, уз задржавање сопственог идентификатора политике Сертификационог тела. Измена мора бити примењена доследно на профилу сертификата и не сме имати негативан утицај на остале елементе структуре сертификата нити на постојећи процес њиховог издавања. 3.3.2 Имплементација Реализација активности од стране Добављача треба да обухвати: уклањање постојећег спољног идентификатора политике из профила сертификата за електронски потпис; задржавање идентификатора политике Сертификационог тела у профилу; верификацију конфигурације Certificate Policies екстензије; издавање пробног сертификата и провера да Certificate Policies екстензија садржи искључиво предвиђени идентификатор политике; проверу да измена нема негативан утицај на постојећи процес издавања и коришћења сертификата. 3.3.3 Очекивани ефекти Реализацијом предложеног унапређења очекују се: издати сертификати садрже јасно дефинисан и документован идентификатор политике; обезбеђена доследна примена идентификатора политике на профиле електронских сертификата које издаје Наручилац као Сертификационо тело (CA – Certification Authority); усклађена конфигурација Certificate Policies екстензије у ADSS платформи; поједностављен и једнозначан модел идентификације политике сертификата; успостављен јасан и одржив модел политике сертификата који омогућава даље прилагођавање профила сертификата релевантним захтевима и стандардима. 3.3.4 Компоненте на које се унапређење односи КОМПОНЕНТА УТИЦАЈ ADSS Certificate Templates Измена конфигурације Certificate Policies екстензије за профил електронског потписа 3.4 Допуна изјава у qcStatements екстензији Добављач је у обавези да спроведе следеће измене: додавање изјаве о земљи примењивог законодавства за профил електронског потписа; додавање семантичког идентификатора субјекта за профил електронског потписа; 3.4.1 Предвиђено унапређење qcStatements екстензија постојећих сертификата садржи скуп изјава којима се дефинишу релевантне карактеристике квалификованог сертификата, укључујући квалификовани статус сертификата, тип сертификата и информације које се односе на коришћење квалификованог средства за креирање електронског потписа. Анализом постојећих профила идентификована је потреба за допуном qcStatements екстензије додатним изјавама које се односе на земљу примењивог законодавства и семантичку идентификацију субјекта сертификата. Потребне измене односе се на оба профила сертификата, уз одговарајуће разликовање типа субјекта – физичког лица код сертификата за електронски потпис и правног лица код сертификата за електронски печат. Потребно је да Добављач допуни qcStatements екстензију оба профила сертификата како би садржала комплетан скуп предвиђених изјава и омогућила једнозначно представљање релевантних информација о квалификованом сертификату и субјекту на који се сертификат односи. Предвиђа се допуна конфигурације профила сертификата за електронски потпис у ADSS платформи додавањем qcStatesments атрибута у складу са стандардом ETSI EN 319 412-5: qcCompliance; QcType са вредношћу id-etsi-qct-esign QcCClegislation са вредношћу RS qcSSCD Семантички идентификатор мора бити конфигурисан у складу са типом субјекта сертификата, односно за физичко лице код профила електронског потписа и правно лице код профила електронског печата. 3.4.2 Имплементација Реализација активности од стране Добављача мора да обухвати: додавање изјаве о земљи примењивог законодавства у профил сертификата за електронски потпис; додавање семантичког идентификатора за физичко лице у профил сертификата за електронски потпис; проверу исправности конфигурације qcStatements екстензије; издавање пробног сертификата; верификацију садржаја и структуре qcStatements екстензије на издатом пробном сертификату; проверу да измене немају негативан утицај на постојећи процес издавања и коришћења сертификата. 3.4.3 Очекивани ефекти Реализацијом предложеног унапређења очекују се: допуњен скуп изјава у qcStatements екстензији за профил сертификата; доследна примена одговарајућих изјава у зависности од типа сертификата и субјекта; усклађена конфигурација qcStatements екстензије у ADSS Certificate Templates; једнозначно представљање релевантних информација о сертификату и типу субјекта; успостављен комплетнији и одржив модел qcStatements екстензије који омогућава даље прилагођавање профила сертификата релевантним захтевима и стандардима. 3.4.4 Компоненте на које се унапређење односи КОМПОНЕНТА УТИЦАЈ ADSS Certificate Templates Допуна конфигурације qcStatements екстензије за профиле електронског потписа 3.5 Усаглашавање формата Common Name атрибута 3.5.1 Предвиђено унапређење Subject поље сертификата за електронски потпис у клауду садржи commonName атрибут који, поред имена и презимена субјекта, у постојећој конфигурацији садржи и додатни нумерички идентификатор корисника. Исти идентификатор је истовремено доступан у оквиру посебног serialNumber атрибута сертификата. Анализом постојећег формата идентификована је потреба за изменом начина формирања commonName атрибута, тако да овај атрибут садржи име и презиме субјекта без додатног нумеричког идентификатора, док се податак неопходан за једнозначну идентификацију субјекта задржава у за то предвиђеном serialNumber атрибуту. Потребно је да Добављач измени формат commonName атрибута за профил сертификата за електронски потпис у клауду како би се јасно раздвојила улога атрибута који представља име субјекта од атрибута који садржи његов идентификациони податак. Измена мора бити реализована уз очување постојећег механизма једнозначне идентификације субјекта путем serialNumber атрибута. Предвиђа се измена логике формирања вредности commonName атрибута тако да вредност садржи искључиво име и презиме субјекта, без додатног нумеричког идентификатора на крају вредности. Нумерички идентификатор корисника остаје непромењено доступан у оквиру постојећег serialNumber атрибута, чиме се задржава могућност једнозначне идентификације субјекта у оквиру Сертификационог тела. 3.5.2 Имплементација Реализација активности од стране Добављача мора да обухвати: идентификацију компоненте у процесу издавања сертификата која формира вредност commonName атрибута; измену логике формирања commonName атрибута тако да вредност садржи искључиво име и презиме субјекта; задржавање постојећег нумеричког идентификатора у оквиру serialNumber атрибута; верификацију да једнозначна идентификација субјекта остаје обезбеђена након измене; издавање пробног сертификата након спроведене измене; верификацију структуре и садржаја Subject поља пробног сертификата; проверу да измена нема негативан утицај на компоненте и процесе који користе Subject податке сертификата. 3.5.3 Очекивани ефекти Реализацијом предложеног унапређења очекују се: унапређен формат commonName атрибута у сертификату за електронски потпис; очувана једнозначна идентификација субјекта путем serialNumber атрибута; јасно раздвојена улога commonName и serialNumber атрибута; стандардизован начин формирања Subject података у сертификату; успостављен одржив модел формирања Subject атрибута који омогућава даље прилагођавање профила сертификата релевантним захтевима и стандардима. 3.5.4 Компоненте на које се унапређење односи КОМПОНЕНТА УТИЦАЈ СИСТЕМ ЗА ГЕНЕРИСАЊЕ ЗАХТЕВА ЗА СЕРТИФИКАТ Измена логике формирања commonName атрибута ADSS Certificate Templates Верификација структуре и формата Subject поља издатих сертификата 4. Пројектни захтеви 4.1 Пројектни захтеви Добављач у понуди треба да предложи методологију управљања пројектом коју сматра оптималном за овај пројекат, као и прелиминарни план пројекта, који обухвата и план кључних међурезултата (eng. milestone). Добављач ће као први корак извршити анализу захтева и постојећег окружења, након чега ће предложити детаљан план пројекта, који мора усагласити са пројектним тимом Наручиоца. Добављач је у обавези да именује руководиоца пројекта који ће са стране Добављача бити задужен за следеће активности: координација пројекта; управљање опсегом пројекта; управљање временским распоредом пројекта; управљање квалитетом пројекта; управљање разменом информација у пројекту; управљање ризицима; управљање променама. Пројектни план и пројектни документи треба да обухвате најмање следеће целине: спецификација захтева; фазе пројекта; организациона структура пројекта; матрица комуникације између чланова пројектних тимова Наручиоца и Добављача; план потребних интеракција, укључујући учешће чланова пројектног тима Наручиоца; временски план пројекта; план управљања квалитетом; план управљања ризицима; план управљања променама. Пројектне фазе и рокови Пројекат је подељен на две фазе и то: Фаза 1 Обухвата анализу, развој, имплементацију и испоруку: Сервиса за локално дигитално потписивање докумената (описано у оквиру поглавља број 2) и Рок за завршетак Фазе 1 је најкасније 2 месеца од закључења уговора. Фаза 2 Обухвата анализу, развој, имплементацију и испоруку: Унапређења структуре квалификованих електронских сертификата (описано у оквиру поглавља број 3). Рок за завршетак Фазе 2 је најкасније 3 месецa од закључења уговора. Гарантни период је 12 месеци од датума уласка у продукцију, односно потписивања Записника о испоруци добара. 4.3 Документација Документација ће бити дефинисана по фазама пројекта након усвајања детаљног плана пројекта. Документација мора да обухвати области наведене у наставку овог документа. Документација о имплементираним пословним процесима и сервисима Потребно је да се документује и опише: сваки имплементирани пословни процес; сваки имплементирани сервис. Документација о апликативном решењу Апликативно решење потребно је документовати тако да описује: архитектурално решење; минималне хардверско/софтверске захтеве; сву другу документацију која је потребна за инсталацију и одржавање апликативног решења. Документација о извршеном тестирању За потребе тестирања, као и за прихватање унапређеног решења неопходно је да постоје: тест план; тест сценарији; извештај о тестирању. Документација о одржавању Документација о одржавању мора да садржи: листу иницијалних параметара система, листу иницијалних елемената речника, детаљно документовану процедуру одржавања, начин промене конфигурације, прављење backup-а, recovery-ја, downtime процедуре 4.4 Тестирање пре прихватања ‒ надзор Након испоруке модула у одређеној фази Наручилац или лице које за то буде овлашћено од стране Наручиоца може извршити тестирање. Извршавање тестирања пре прихватања апликативног решења првенствено ће бити одговорност Наручиоца, али његово извршавање треба да води Добављач у фази финалног пуштања система, односно одговарајућег подсистема. Циљ овог тестирања јесте потврда да су испуњени сви технички захтеви у погледу захтеваних функционалности, укључујући, али се не ограничавајући само на њих, и захтеве у погледу перформанси система и осталих нефункционалних захтева. Након сваке фазе имплементације, када се реше критични проблеми, дефинисаће се временски период за тестирање у симулираним условима реалног радног окружења. Овај пробни период биће основ за прихватање решења. Уколико се у том периоду наиђе на суштинске проблеме, они ће се решити и по њиховом решавању поново ће се започети рад у симулираним реалним условима. 4.5 Пројектни план Почетак пројекта Уводни састанак Добављача са релевантним представницима Наручиоца са следећим темама: Дискусија о циљевима пројекта, тимовима који ће учествовати у пројекту и плану комуникације; Прикупљање основних информација о активностима на пројекту, временском распореду активности, предметима испоруке и ризицима на пројекту, на бази чега ће бити израђен Пројектни план. Добављач ће сачинити белешку са састанка и доставити представницима Наручиоца. На бази разговора са уводног састанка Добављач ће израдити и доставити Пројектни план у складу за дефинисаним Фазама пројекта. Пројектни план треба да садржи активности са временским распоредом, учесницима са улогама и одговорностима на страни Добављача и Наручиоца, ризике и управљање ризицима. Анализа и пројектовање Добављач ће спровести анализу за сваку фазу пројекта, на основу које ће бити израђена усаглашена спецификација софтверских захтева за сваку фазу пројекта. Добављач је у обавези да на основу Спецификације софтверских захтева дефинише архитектуру система која мора описати: Како су објекти груписани у компоненте на системском нивоу; Како су ове компоненте структуриране; Како су интерфејси компоненти дизајнирани; Како ове компоненте интерагују. За дефинисану архитектуру система Добављач мора Наручиоцу доставити захтеве у погледу архитектуре и дизајна. Имплементација и тестирања У току имплементације потребно је на основу пројекта израдити софтвер и пратећу документацију (техничку и корисничку). Релација између дизајна и имплементације зависи од изабраног модела процеса развоја софтвера (итеративни, инкрементални, агилни приступ). Дизајн, имплементација и тестирање не морају временски бити оштро раздвојени, тако да ће Пројекат за израду софтвера и сам софтвер који се развија до краја фазе развоја бити континуирано и конзистентно развијани и ажурирани до своје коначне верзије. У току имплементације потребно је спроводити тестирање компоненти, а на крају фазе и интегрално тестирање и потврдити испуњеност захтева. Тестирање Пре почетка завршног тестирања Добављач ће представницима Наручиоца доставити корисничку документацију и спровести обуке групе запослених на страни Наручиоца која ће спровести завршно тестирање система. Завршно тестирање ће бити спроведено на основу плана завршног тестирања који ће припремити Добављач, а само тестирање ће спровести представници Наручиоца уз подршку Добављача. Циљ завршног тестирања је провера квалитета испорученог система, како у погледу опсега (уверити се да су све договорене функционалности имплементиране), тако и у погледу исправности рада система. На крају тестирања Добављач ће израдити Извештај завршног тестирања система који мора бити прихваћен од стране Наручиоца. По успешно спроведеном тестирању система Добављач ће систем поставити на радно окружење Наручиоца, извршити превођење података и документације из постојећег извора у нов систем и систем пустити у оперативан рад. ДЕФИНИЦИЈА УСЛУГЕ ОДРЖАВАЊА СЕРВИСА, КАО И ПРУЖАЊА ТЕХНИЧКЕ ПОДРШКЕ У ГАРАНТНОМ РОКУ Добављач је дужан да услуге врши квалитетно, у складу са важећим прописима, стандардима и правилима струке. Добављач је дужан да обезбеди техничку подршку и одржавање у наредном периоду од минимално 12 (дванаест) месеци. Под техничком подршком и одржавањем подразумева се: утврђивање кварова; довођење сервиса у исправно (радно) стање; превентива; промена/upgrade верзије софтвера; услуге стручне техничке помоћи; све потребне конфигурационе промене на систему који је предмет одржавања, по захтеву Наручиоца, у току трајања уговора. Техничка подршка обухвата: отклањање свих евентуалних недостатака у функционисању система; консултације везане за рад и употребу система; доставу и имплементацију свих корекција које утичу на функционалност и сигурност система; анализу и решавање специфичних проблема са подацима на основу пријаве од стране корисничке подршке и информисање администратора система о могућностима побољшања рада применом нових технологија и пружање помоћи у њиховој примени. Интервенције на систему се спроводе хитно, по успостављању захтева за хитном интервенцијом, сем активности које имају карактер превентивног деловања. Одржавање система се састоји из следећих сервиса и услуга: приступ центру за прихватање, прослеђивање и архивирање пријава; интервентно одржавање; проактивна подршка; техничка подршка; систем инжењерска помоћ. За услуге интервентног одржавања примењују се сервисне гаранције у зависности од нивоа приоритета проблема. Током важења уговора неопходно је пружање техничке подршке, што подразумева разрешавање конкретних проблема у раду крајњих корисника наведених система. Техничка подршка удаљеним приступом се организује кроз систем нивоа: Први ниво подршке пружа aдминистратор кроз своју апликативну ролу и одговоре на најопштија питања која припадају категорији – често постављања питања и прослеђује нерешена питања (везана за систем података, мрежу, инфраструктуру) вишем нивоу подршке. Други ниво анализира и решава проблеме у подешавању и конфигурисању апликативних сервера и база података, идентификује проблеме у раду програмског система и прослеђује их програмском тиму, пружа помоћ у спровођењу правила система заштите. Виши ниво подршке организован је кроз тимове сарадника у зависности од њихове специјализације. Приступ центру за прихватање, прослеђивање и архивирање пријава Пријаве кварова и/или проблема у раду система се прихватају на централном пријемном месту у центру за прихватање, прослеђивање и архивирање позива. Центру за прихватање, прослеђивање и архивирање позива се приступа имејлом или позивањем одговарајућег телефонског броја Добављача. Време пријаве квара и/или проблема је 24 сата дневно, 7 дана у недељи, 365 дана у години. Овлашћене особе Наручиоца пријављују проблем наводећи кратак опис проблема, након чега се за њих отвара случај. Пријаве се прослеђују одговарајућој особи Добављача, одговорној за сегмент од интереса, и обавља се архивирање и слање потврде о прихваћеној пријави. У року предвиђеном за ниво критичности пријављеног проблема инжењер специјализован за ту врсту проблема мора да контактира са особом која је пријавила проблем и да приступи решавању проблема. За потребе приступа центру за прихватање, прослеђивање и архивирање пријава Наручиоцу се дефинишу одговарајући имејлови, односно ауторизациони бројеви за пријаву грешака или кварова телефонским путем. Добављач ће Наручиоцу доставити и две контакт особе за ескалацију, из свог руководећег слоја, хијерархијски надређено тиму за решавање проблема, за случај да не може остварити пријаву проблема или постоји изазов у решавању. Потребно је доставити име и презиме особе, функцију, телефон и имејл за контакт. Интервентно одржавање Предмет ове услуге је систем наведен у овој спецификацији. Под интервентним одржавањем се подразумева отклањање грешке или квара у случају проблема на систему. У оквиру ове услуге врши се опоравак функција система у року предвиђеном у тачки Сервисне гаранције. Проактивна подршка Проактивна техничка подршка подразумева превентивно прегледање стања апликативног и системског софтвера, праћење промена у систему Наручиоца као и прикупљање и анализу података и логова о статусу сервиса и перформанси система. На основу свих наведених анализа Добављач је дужан да формира препоруке и изврши акције над системом (примена предложених проактивних мера), односно појединим компонентама система и о томе сачини одговарајући извештај и достави га Наручиоцу. Сервисне гаранције Динамика пружања услуга дефинише критеријум за оцењивање квалитета извршене услуге. За услуге интервентног одржавања примењују се временске гаранције, време одзива, време опоравка и време решавања. Сервисне гаранције могу бити различите у зависности од нивоа приоритета проблема. Временски рокови спровођења активности одржавања у случају евентуалних проблема у раду система су дефинисани према подацима у следећој табели: Технички ниво квара Време одзива Време опоравка Време решавања Ниво 1 – критичан 60 минута 4 сата 5 дана Ниво 2 – озбиљан 90 минута 8 сати 15 дана Ниво 3 – низак 8 сати 24 сата 20 дана Технички ниво проблема дефинише озбиљност проблема са аспекта функционисања система: Ниво 1 – критичан. Подразумева стање прекида у раду система делимично или у целини, које има критичне последице; Ниво 2 – озбиљан. Подразумева стање делимичне неоперативности система, систем се већим делом може користити, али неоперативност појединих делова представља значајан проблем. Угроженост система је велика, али мања него у случају Нивоа 1; Ниво 3 – низак. Подразумева стање у коме рад система не изазива прекид у раду сервиса, али поједине компоненте нарушавају перформансе система или изазивају мање проблеме у раду, који у перспективи могу да ескалирају. Време одзива дефинише временски период у коме долази до реализације активности појединих услуга и представља временски интервал који почиње тренутком пријема пријаве проблема од стране Добављача и завршава се тренутком у коме се одговарајућа особа јавља Наручиоцу и започиње рад на решавању проблема. Време опоравка/поправке дефинише временски период у коме се успоставља функционалност система након пријаве и потврде пријаве проблема. Време решавања проблема дефинише временски период у коме се успоставља стање које се може сматрати коначним решењем проблема у раду система након пријаве и потврде пријаве проблема. Место испоруке: рок Рок испоруке: Понуђач са којим буде закључен уговор – Добављач је дужан да испоручи и имплементира добра у складу са Техничком спецификацијом, најкасније у року од три месеца од дана закључења уговора. Начин плаћања: Наручилац ће изабраном понуђачу / Добављачу извршити плаћање за испоручена добра након испоруке добара и испуњења свих обавеза Добављача из Техничке спецификације, у року од 30 (тридесет) дана након достављене уредне фактуре и Записника о испоруци добара који сачињава Добављач и који мора да садржи детаљну спецификацију, односно врсту, опис и обим испоручених добара, који потписују овлашћени представници Наручиоца и Добављача. Гарантни рок: Гарантни рок мора бити минимално 12 (дванаест) месеци од потписивања Записника о испоруци добара. Kriterijumi za dodelu ugovora.pdf КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ 1 Наручилац: КАНЦЕЛАРИЈА ЗА ИНФОРМАЦИОНЕ ТЕХНОЛОГИЈЕ И ЕЛЕКТРОНСКУ УПРАВУ 110177886 Назив поступка: Унапређење сервиса за локално дигитално потписивање и унапређење структуре квалификованих електронских сертификата за потпис Референтни број: 004191057 2026 10258 004 002 405 001 КРИТЕРИЈУМИ ЗА ДОДЕЛУ УГОВОРА И ОСТАЛИ ЗАХТЕВИ НАБАВКЕ Део конкурсне документације који је генерисан путем Портала у случају када је наручилац означио опцију аутоматског рангирања понуда на Порталу јавних набавки Назив предмета / партије: Унапређење сервиса за локално дигитално потписивање и унапређење структуре квалификованих електронских сертификата за потпис Наручилац је дефинисао критеријуме за доделу уговора на основу: Цене Изабран начин рангирања прихватљивих понуда: Аутоматско рангирање Остали захтеви набавке (који нису наведени изнад као критеријуми) Назив: рок испоруке Јединица мере: месец Ограничења: Ограничена је минимална вредност коју понуђач може да понуди Ограничена је максимална вредност коју понуђач може да понуди Максимална дозвољена вредност: 3,00 Назив: гарантни рок Јединица мере: месец Ограничења: Ограничена је минимална вредност коју понуђач може да понуди Минимална дозвољена вредност: 12,00 Ограничена је максимална вредност коју понуђач може да понуди Напомена: У овом делу наведени су остали захтеви набавке који нису претходно наведени као критеријуми за доделу уговора, а понуђач мора на њих да одговори приликом попуњавања електронског обрасца понуде. Ти захтеви могу да се односе на захтеве набавке, које наручилац сматра релевантним за закључење уговора и који се мог