Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
Гаранционна поддръжка, отстраняване на дефекти и пропуски в сигурността
| -
|
Изпълнителят трябва да осигури гаранционна поддръжка на ПЖС за период от 36 (тридесет и шест) месеца.
|
|
-
|
Изпълнителят трябва да осигури гаранционна поддръжка за непрекъсната работоспособност на ПЖС, без отклонения от изискванията на ТС.
|
|
-
|
Изпълнителят трябва да осигури отстраняване на грешки и пропуски в сигурността, допуснати в изходния код на ПЖС, както и корекции за отстраняване на отклонения от изискванията на ТС.
|
|
|
Общи изисквания за реализиране на Портал за граждани (ПГ)
|
Общи изисквания за реализиране на Портал за граждани (ПГ)
|
-
|
Трябва да бъде реализиран публичен Портал за граждани (ПГ), чрез който
-
Да се предоставя публична информация за националната схема за електронна идентификация
-
Да се предоставя възможност за саморегистрация на нови потребители:
-
Да се предоставят тематични ЕАУ, свързани с националната схема за електронна идентификация и други услуги (след вход регистриран потребителски акаунт и УЕИ / КЕП);
|
|
-
|
Трябва да бъде реализирана интерактивна информационна функционалност за националната схема за електронна идентификация:
-
промотиране на ползите за потребителите (граждани и бизнес)
-
отговори на често задавани въпроси
-
специфична информация за информационната сигурност, защитата на личните данни и правата на гражданите
-
разяснения за трансграничната електронна идентификация (на ниво ЕС)
-
данни за органите и участниците в националната схема за е-идентификация
-
препратки към релевантната нормативна уредба (национална и на ЕС)
-
Функционалност за търсене:
-
Общо търсене в съдържание / документи на портала, по раздели и др.
-
Търсене на АЕИ по географски принцип / от карта
-
Търсене на ДЕАУ по географски принцип / от карта / по ключови думи
-
Търсене на ДУУ по географски принцип / от карта / по ключови думи
|
|
-
|
Трябва да бъде реализирана функционалност за саморегистрация на граждани:
-
Саморегистрация с попълване на форма за регистрация и потвърждаване на валиден e-mail адрес ("Ниско" ниво на сигурност при идентификация, съгласно Регламент ЕС 910/2014), при което които да получават ограничен достъп до допълнителни услуги
-
Саморегистрация с попълване на форма за регистрация, потвърждаване на валиден e-mail адрес и вход с портала с КЕП ("Високо" ниво на сигурност при идентификация, съгласно Регламент ЕС 910/2014), при което потребителят получава пълен достъп до всички услуги (приложимо за случаите, в които граждани вече имат валиден КЕП, съдържащ уникален граждански идентификатор, но не разполагат с валидно УЕИ)
|
|
-
|
Трябва да бъде реализирана функционалност за предоставяне на тематични ЕАУ, свързани с националната схема за електронна идентификация:
-
ЕАУ свързани с електронната идентификация (по реда на ЗЕИ)
-
ЕАУ свързани с електронно овластяване (по реда на ЗЕИ)
-
ЕАУ свързани с проверка на лични данни в първични регистри (по реда на ЗЕУ)
-
ЕАУ свързани с електронни разплащания (по реда на ЗЕУ)
-
ЕАУ свързани с регистриране и управление на предпочитани канали за комуникация
-
ЕАУ свързани с електронна препоръчана поща и сигурно връчване
-
ЕАУ свързани с преглед / търсене в журнали за събития
|
|
-
|
Трябва да бъдат реализирани всички процеси и други функционалности, свързани с обслужване на граждани и достъп на граждани до функционалности, които са предвидени във функционалните и технически изисквания на всички системи, подсистеми, модули и компоненти, в обхвата на настоящата ТС.
|
|
|
Общи изисквания за реализиране на клиентски интеграции с програмни интерфейси (APIs) на други / външни АИС
|
Общи изисквания за реализиране на клиентски интеграции с програмни интерфейси (APIs) на други / външни АИС
|
-
|
Трябва да бъде реализирана клиентска интеграция между ПГ и програмните интерфейси (APIs) на ИСЦЕИ за обслужване, като минимум, на описаните основни процеси в т.Error: Reference source not found на ТС, които касаят взаимодействието между граждани и ЦЕИ.
|
|
-
|
Трябва да бъде реализирана клиентска интеграция между ПГ и Подсистемата за интеграция с външни регистри (ПИВР), чрез програмния интерфейс (API) на ПИВР.
|
|
-
|
Трябва да бъде реализирана клиентска интеграция между ПГ и програмните интерфейси (APIs) на РО, обслужваща като минимум процесите описани в т. Error: Reference source not found от ТС.
|
|
-
|
Трябва да бъде реализирана клиентска интеграция между ПГ и Подсистемата за управление на плащанията (ПУП), чрез програмния интерфейс (API) на ПУП.
|
|
-
|
Трябва да бъде реализирана клиентска интеграция между ПГ и Подсистемата за автоматични нотификации (ПАН), чрез програмния интерфейс (API) на ПАН
|
|
-
|
Трябва да бъде реализирана клиентска интеграция между ПГ и Подсистемата за електронна препоръчана поща (ПЕПП), чрез програмния интерфейс (API) на ПЕПП
|
|
-
|
Трябва да бъде реализирана клиентска интеграция между ПГ и "Журнал на събитията" (ПЖС), чрез програмния интерфейс (API) на ПЖС.
|
|
|
Изисквания за реализиране на ЕАУ свързани с електронната идентификация
|
Изисквания за реализиране на ЕАУ свързани с електронната идентификация
|
-
|
Трябва да бъде реализирана функционалност за достъп до услугите, поддържани от Модула за приемане и обработка на заявления за електронна идентичност (МОЗЕИ), както и други функционалности, свързани с електронната идентификация;
|
|
-
|
Трябва да бъде реализирана функционалност за управление на УЕИ:
-
Преглед и управление на издадени удостоверения за електронна идентичност (УЕИ), ако има такива;
-
Конфигуриране на предпочитания за автентикация при използване на УЕИ;
-
Първоначално заявяване на УЕИ
-
Заявяване на допълнително УЕИ (изисква идентификация по реда на ЗЕИ, подпис с КЕП, но не изисква явяване пред АЕИ)
-
Спиране на УЕИ
-
Прекратяване на УЕИ:
-
Възобновяване на УЕИ
-
Подновяване на УЕИ (удължаване срока на валидност)
|
|
-
|
Преглед и управление на УЕИ:
-
Визуализиране на списък с издадени УЕИ, сортиране и филтриране по дати, статус и др. реквизити
-
Задаване на имена на УЕИ за по-лесно различаване на различните удостоверения
|
|
-
|
Конфигуриране на предпочитания за автентикация при използване на УЕИ:
-
Изискуем режим за автентикация за ползване на конкретна ЕАУ, група ЕАУ или за използване на услугите на определени ДЕАУ
-
Изискуем режим за автентикация при ползване на конкретно УЕИ
Режимите за автентикация могат да бъдат:
-
Еднофакторна само с еИД
-
Многофакторна с допълнителна функционалност през МПГ
|
|
-
|
Първоначално заявяване на УЕИ:
-
Първоначално заявяване на УЕИ е електронна услуга за улеснение на граждани, които вече разполагат с КЕП, но нямат издадено нито едно УЕИ
-
Изисква се регистрация на акаунт в ПГ (саморегистрация) и идентификация с КЕП за вход в ПГ, по реда на ЗЕИ
-
Попълва се електронно заявление за първоначално издаване на УЕИ:
-
Трябва да има възможност за търсене на АЕИ по локации / разстояние от географско място или точка;
-
трябва да има възможност да се посочи предпочитан АЕИ, при който гражданинът желае да се яви, за довършване на процеса (поради нормативни изисквания за проверка на физическата самоличност);
-
трябва да има възможност да не се посочва АЕИ, а гражданинът да избере в последствие, пред кой АЕИ да се яви за довършване на процеса;
-
Заявлението трябва да бъде електронно подписано с КЕП.
|
|
-
|
Заявяване на допълнително УЕИ:
-
Допълнителното УЕИ може да бъде заявено и издадено на алтернативен технически носител, който покрива минималните изисквания за сигурност.
-
Това може да бъде смарткарта (напр. вече налична от ДУУ), SSCD Token, SDCard Smartcards и др.
-
Заявлението трябва да бъде електронно подписано с КЕП.
|
|
-
|
Спиране на УЕИ:
-
Гражданин може да подаде искане за временно спиране на УЕИ за определен период от време.
-
Преди изтичането на този период УЕИ може да бъде възобновено на място при АЕИ.
-
Искането за спиране се подава след електронна идентификация по реда на ЗЕИ, а УЕИ се добавя в Списък със спрени УЕИ (CRL).
-
По време на периода на спиране гражданинът няма достъп до потребителската част на ПГ, освен ако не разполага с друго валидно УЕИ.
|
|
-
|
Прекратяване на УЕИ:
-
Гражданинът може да се откаже от използване на еИД като го прекрати.
-
Искането трябва да бъде подписано с Квалифициран електронен подпис (КЕП).
-
След обработката на искането се изключват нотификациите, издаденото еИД се добавя в Регистъра с прекратените еИД удостоверения (CRL)
-
Гражданинът губи достъп до потребителската част на Портала, освен ако не разполага с друго валидно УЕИ.
-
Гражданите при желание могат да заявят ново еИД на място при Администратор на електронна идентичност.
|
|
-
|
Удължаване срока на валидност:
-
Срокът на валидно УЕИ може да бъде удължен чрез подаване на съответното искане в Портала.
-
Искането за удължаване на срока се подава след електронна идентификация по реда на ЗЕИ.
|
|
|
Изисквания за реализиране на ЕАУ свързани с електронно овластяване
|
Изисквания за реализиране на ЕАУ свързани с електронно овластяване
|
-
|
Трябва да бъде реализирана функционалност за достъп до услугите, поддържани от Регистъра за овластяване (РО);
|
|
-
|
Потребителят трябва да има възможност да овласти друго лице за конкретна административна услуга, за набор от услуги или за представителство пред посочен административен орган или ДАЕУ.
|
|
-
|
Овластяването трябва да може да се заявява само чрез електронно подписване с КЕП от заявителя.
|
|
-
|
За електронни административни услуги, изискващи по-голяма грануларност на достъпа или специфична конфигурация (специфичен достъп), свързана с овластяването (напр. достъп до предходно подадени данни от овластеното лице, възможност само за подаване на данни и др.) се допуска пренасочване на овластителя към съответната ЕАУ за предоставяне на специфичния достъп.
|
|
-
|
Овластяването трябва да може да бъде ограничено за посочен времеви период, след изтичането на който, подсистемата трябва да прекратява овластяването автоматично.
|
|
-
|
Потребителят трябва да има възможност да избере, дали иска да бъде нотифициран автоматично при наближаване на срока на действие на овластяването.
|
|
-
|
Овластяването трябва да може да бъде и за неограничен период. При избор на такава опция, потребителят трябва да бъде информиран за рисковете от овластяване за неограничен период и да потвърди избора си.
|
|
|
Изисквания за реализиране на функционалности за електронна препоръчана поща и сигурно връчване
|
Изисквания за реализиране на функционалности за електронна препоръчана поща и сигурно връчване
|
-
|
Трябва да бъде реализирана функционалност за достъп до услугите, поддържани от Подсистемата за електронна препоръчана поща (ПЕПП);
|
|
-
|
Трябва да бъде реализирана функционалност за управление на електронна препоръчана поща и връчени документи:
-
Преглед на списък и търсене в списък с връчени документи
-
Преглед на детайли за връчен документ:
-
глобално уникален номер на документа / транзакцията
-
дата и време на създаване / постъпване
-
дата и време на връчване
-
организация връчила документа
-
детайли за връчения документ (номер на документ / преписка / друг референтен идентификатор на организацията заявила плащането
-
Сваляне / отваряне на връчен документ;
-
Иницииране на последващи действия, директно от съдържаща се покана за плащане във връчен документ (напр. за плащане на такса / глоба / услуга) по референция към уникално-глобален номер на транзакция в ПУП.
|
|
-
|
Трябва да се разгледат възможните решения и от гледна точка на ползваемост (UX) за реализиране на отваряне на връчен документ директно от ПГ и от МПГ:
-
дали да се визуализира с пренасочване към специална публична уеб-страница (Landing Page) на ПГ (което ще изисква и функционалност / plugin за визуализация на различни формати документи в браузъра на потребителя);
-
дали да бъде реализирана функционалност за сваляне на файла на клиентското устройство, ако браузърът не може да визуализира документа;
-
дали да се реализира отделна функционалност за отваряне на връчени документи от мобилни устройства, без потребителят е осъществил вход в ПГ:
|
|
-
|
Трябва да бъде реализирана справочна функционалност:
-
Генериране на справки за връчени съобщения и документи за периоди / по организации и др. критерии
-
Печат на справки / генериране на PDF със справки, включително електронно подписан
-
Експорт на платежна история в машинно четим вид
|
|
|
Изисквания за реализиране на функционалности за управление на плащания
|
Изисквания за реализиране на функционалности за управление на плащания
|
-
|
Трябва да бъде реализирана функционалност за регистриране и управление на платежни инструменти, поддържани от Подсистемата за управление на плащанията (ПУП);
|
|
-
|
Трябва да бъде реализирана функционалност за конфигуриране на предпочитания за одобрения на плащания, като минимум за:
-
Режим за плащане за конкретна ЕАУ, група ЕАУ или за използване на услугите на определени ДЕАУ
-
Режим за плащане за определени видове заявки за плащане (еднократна такса за ЕАУ / регулярна такса за ЕАУ / глоба или санкция / данък)
Режимите за плащане могат да бъдат:
-
само след изрично одобрение (по подразбиране)
-
автоматично, без изрично одобрение
-
автоматично, до определен лимит на сумата
|
|
-
|
Трябва да бъде реализирана функционалност за конфигуриране на предпочитания за изискуем режим на автентикация при управление на плащания, като минимум за:
-
Режим за автентикация при използване на ПГ
-
Режим за автентикация при използване на МПГ
-
Режим за автентикация за ползване на конкретна ЕАУ, група ЕАУ или за използване на услугите на определени ДЕАУ
-
Режим за автентикация при ползване на конкретно УЕИ
Режимите за автентикация могат да бъдат:
-
Еднофакторна само с еИД
-
Многофакторна с допълнителна функционалност през МПГ
|
|
-
|
Трябва да бъде реализирана функционалност за управление на плащания, като минимум за:
-
Преглед и одобрение (заплащане / отхвърляне) на транзакции със заявки за плащане
-
Преглед на детайли за заявки за плащане (чакащи / платени / отхвърлени)
-
глобално уникален номер на заявката / транзакцията
-
дата и време на създаване / постъпване
-
краен срок за плащане / дата за плащане
-
стойност на заявката за плащане;
-
организация заявила плащането
-
основание за плащане (услуга / такса / глоба / санкция / данък и пр.)
-
детайли за заявката (номер на документ / преписка / друг референтен идентификатор на организацията заявила плащането
|
|
-
|
Трябва да бъде реализирана справочна функционалност, като минимум за:
-
Генериране на справки за плащания за периоди / по доставчици на услуги и др. критерии
-
Печат на справки / генериране на PDF със справки, включително електронно подписан
-
Експорт на платежна история в машинно четим вид
|
|
|
Изисквания за реализиране на функционалности за управление на нотификации
|
Изисквания за реализиране на функционалности за управление на нотификации
|
-
|
Трябва да бъде реализирана функционалност за конфигуриране на предпочитанията за канали за нотификация на гражданите. Каналите за комуникация са описани в т. Error: Reference source not found от ТС.
|
|
-
|
При добавяне/редактиране на електронен канал за комуникация задължително се извършва потвърждение чрез изпращане на еднократна нотификация, чрез която се валидира коректността на данните.
|
|
-
|
Нотификациите трябва да са групирани в категории в зависимост от събитията – напр. връчени официални документи, извършено действие с еИД (идентификация, овластяване, спиране, възобновяване, удължаване на срока), очакващо и извършено плащане и др.
|
|
-
|
За всеки потвърден канал за нотификация трябва да се асоциират видовете нотификации, които потребителя ще получава.
|
|
-
|
По каналите за комуникация не трябва да се изпращат чувствителни и лични данни.
|
|
|
|
