Предложение за изпълнение на поръчката


Изисквания за журналиране на събитията и операциите в ИСЦЕИ



страница7/38
Дата17.06.2017
Размер4.56 Mb.
#23756
1   2   3   4   5   6   7   8   9   10   ...   38

Изисквания за журналиране на събитията и операциите в ИСЦЕИ

Изисквания за журналиране на събитията и операциите в ИСЦЕИ



Всички операции, които се извършват в ИСЦЕИ, трябва да се записват и съхраняват в локален журнал на събитията, който да осигурява одитна проследимост.






В локалния журнал трябва да се регистрират всички операции, независимо дали са инициирани през потребителски или чрез програмен интерфейс (API).






Трябва да бъде реализирана системна функционалност за гарантиране на интегритета на журнала - електронно подписване по време на група от записи, през определен интервал от време, или на определен брой записи.






Записите в журнала не трябва да могат да се изтриват.






В съответствие със Закона за електронната идентификация, в журнала не се записват данни, идентифициращи устройството или локацията, от които е извършена идентификация.






При извършване на проверка на електронна идентичност, лицата, осъществяващи дейност на център за електронна идентификация и държавните органи, трябва да съхраняват информация за извършените проверки за срок от 10 години.






Минималният набор реквизити, които трябва да се записват и съхраняват в журнала са следните:

  • Уникален идентификатор на събитието;

  • Уникален идентификатор (сериен номер) на удостоверението за електронна идентичност;

  • Уникален идентификатор на доставчика на услуга;

  • Код (параметър), определя, в какво качество се идентифицира съответното лице / в какво качество се използва съответното УЕИ (служебно или лично);

  • Статус на режима на автентикация (еднофакторна / многофакторна и др.)

  • Статус на искането за достъп от страна на потребителя - потвърдено или отхвърлено;

  • Статус на операцията;

  • Secure Timestamp върху hash от всички реквизити за запис в журнала;






Участникът може да предложи допълнителни реквизити, които да бъдат включени в журнала на събитията.






Освен опитите за електронна идентификация, в журнала се записва и всеки осъществен и отказан достъп до данни за гражданите от страна на доставчиците на услуги.






Всички операции, които се записват в локалния журнал на събитията трябва да се репликират или изпращат в реално време и към Подсистемата "Журнал на събитията" (ПЖС), през която се осигурява достъп и функционалности за контрол от страна на гражданите.







Контрол на достъпа до данни от страна на гражданите

Контрол на достъпа до данни от страна на гражданите



При всяка заявка за идентификация, на гражданите трябва да се показва наборът от данни, до които ще получи достъп съответният ДЕАУ или лице, пред което се идентифицира гражданинът.

За всяка поискана данна трябва да има налично описание на нормативното изискване / основание, поради което се изисква информацията.








Гражданинът може да откаже предоставянето на данни, с което идентификацията приключва успешно, но ИСЦЕИ връща код за грешка (отказ на гражданина за предоставяне на данни).






Трябва да се разгледат възможните решения и от гледна точка на ползваемост (UX) за реализиране на потвърждения за предоставяне на данни:

  • дали да се визуализират с пренасочване към специална публична уеб-страница (Landing Page) на ИСЦЕИ (което ще изисква и функционалност от страна на порталите на доставчиците, за връщане на предходна стъпка след потвърждение)

  • дали да бъде реализиран по-прозрачен начин, чрез Pop-Up, но при съобразяване с техническите възможности за гарантиране на висока сигурност и защита на потребителите от Phishing / Man-in-the-Middle атаки и ограниченията на браузърите.






При всяка проверка на електронна идентичност, която се извършва при вход в информационна система, от страна на служител на администрация в неговото служебно качество, преди да е приключил процесът по идентификация, на лицето трябва да бъде показвана визуална индикация за това, че се идентифицира в служебно качество.






Гражданинът, който се идентифицира в служебно качество, може да откаже идентификацията, с което процесът по идентификация приключва, а ИСЦЕИ връща код за грешка (отказ на гражданина за идентификация в служебно качество).






Трябва да се разгледат възможните решения и от гледна точка на ползваемост (UX) за реализиране на визуална индикация за идентификация в служебно качество:

  • дали да се визуализират с пренасочване към специална публична уеб-страница (Landing Page) на ИСЦЕИ (което ще изисква и функционалност от страна на порталите на доставчиците, за връщане на предходна стъпка след потвърждение)

  • дали да бъде реализиран по-прозрачен начин, чрез Pop-Up, но при съобразяване с техническите възможности за гарантиране на висока сигурност и защита на потребителите от Phishing / Man-in-the-Middle атаки и ограниченията на браузърите.







Изисквания за задължителна поддръжка на протоколи

Изисквания за задължителна поддръжка на протоколи



За процеса по идентификация съгласно ППЗЕИ трябва да се поддържат задължително два протокола:

  • OpenID Connect 1.0

  • SAML 2.0 (Security Assertion Markup Language 2.0)






Доставчикът на услуга (SP) избира кой протокол да използва, като може да прави това:

  • При всяка заявка (препращане) към ИСЦЕИ (чрез параметър)

  • Чрез обща настройка по подразбиране, зададена в конфигурационният си панел






За идентифицирането на граждани, ИСЦЕИ трябва да използва TLS 1.2+ Mutual authentication, като прочита подадения от страна на гражданина eID сертификат и го използва за по-нататъшни проверки.






TLS Mutual authentication трябва да е включено само за ресурсите на ИСЦЕИ, които са предназначени за идентификация (т.е. за URL адреса, към който Доставчиците на услуги препращат, както и идентификацията за нуждите на портала).






Успешните и неуспешните TLS Mutual authentication трябва да се съхраняват в локалния журнал на събитията, за нуждите на одитната следа.






При реализацията на OpenID Connect имплементацията е необходимо да се вземат предвид резултатите от извършения анализ на сигурността на OAuth 2.0 (A Comprehensive Formal Security Analysis of OAuth 2.0 - https://arxiv.org/pdf/1601.01229v3.pdf).






Предложеният и реализиран протокол за идентификация с участието на мобилно устройство, използвано като четец за носител на УЕИ.







Изисквания за реализиране на програмен интерфейс (API) на ИСЦЕИ

Изисквания за реализиране на програмен интерфейс (API) на ИСЦЕИ



Трябва да бъде реализиран програмен интерфейси (API) за автоматизиран междусистемен достъп до услугите, функционалностите и данните на ИСЦЕИ.






Услугите и функционалностите на програмния интерфейс (API) трябва да бъдат съобразени и разработени така, че като минимум да се посрещнат нуждите на порталите, информационните системи, подсистемите и модулите, за които е предвиден достъп, съгласно изискванията в настоящата ТС.






Програмният интерфейс (API) трябва да отговаря и на общите технически и функционални изисквания за реализиране на програмни интерфейси (APIs), съгласно т. Error: Reference source not found от ТС.







Изисквания за контрол на достъпа до ИСЦЕИ

Изисквания за контрол на достъпа до ИСЦЕИ



ИСЦЕИ не е публичен регистър, съдържа чувствителна информация, и трябва да бъде защитен от прониквания и манипулации с инструменти и системи за сигурност, в съответствие с изискванията за информационна сигурност по ЗЕУ.






Достъп до ИСЦЕИ трябва да се осъществя само чрез отделен Модул за приемане и обработване на заявления за електронна идентичност (МПОЗЕИ), който да бъде интегриран към програмния интерфейс (API) на ИСЦЕИ.






Служебен потребителски достъп до ИСЦЕИ през МПОЗЕИ трябва да имат само регистрирани администратори на електронна идентичност и лица, определени със заповед на Министъра на вътрешните работи, които трябва да се идентифицират по електронен път преди всяко осъществяване на достъп.






Служебен системен достъп до ИСЦЕИ през програмния интерфейс (API) на ИСЦЕИ, трябва да имат само информационни системи на регистрирани администратори на електронна идентичност, центрове за електронна идентификация и лица, определени със заповед на Министъра на вътрешните работи, които трябва да се идентифицират по електронен път преди всяко осъществяване на достъп.







Изисквания за реализиране програмен интерфейс (API) на ИСЦЕИ опериращ в "Sandbox" среда за експерименти и тестова интеграция на ДЕАУ към ИСЦЕИ

Изисквания за реализиране програмен интерфейс (API) на ИСЦЕИ опериращ в "Sandbox" среда за експерименти и тестова интеграция на ДЕАУ към ИСЦЕИ



За улесняване на интеграцията на доставчиците на услуги, ИСЦЕИ трябва да предоставя програмен интерфейс (API) за експериментална интеграция и провеждане на интеграционни тестове с т.нар. "Sandbox" среда.

Предвид, че в Пътната карта за изпълнение на Стратегията за развитие на електронното управление в Република България 2016 – 2020 г. е предвидена реализацията на 30 приоритетни проекта в периода 2016 – 2018 г., които ще бъдат изпълнявани паралелно с настоящата обществена поръчка, "Sandbox" средата на ИСЦЕИ е необходима за изпълнението на всички останали проекти.








Трябва да бъде реализиран програмен интерфейс (API) за тестови и експериментални нужди, с функционалност, която да имитира напълно продукционната, в изолирана "sandbox" среда, конфигурирана с примерни / тестови данни, вместо с реални данни.






Програмният интерфейс (API) разгърнат в "Sandbox" средата трябва да функционира на различен URL от другите интерфейси / среди. URL-ът трябва да е публично достъпен.






Доставчик на услуги трябва да може да създава и конфигурира различни електронни идентификатори и съответните им тестови данни, за които да бъдат връщани различни отговори (напр. успешна проверка, спряно удостоверение, изтекло удостоверение, смърт или поставяне под запрещение на физическото лице).






Sandbox средата трябва да функционира без да е свързана и без да има необходимост от функциониращи Инфраструктури за публични ключове, Сертифициращи органи и др. елементи на инфраструктурата на националната схема за електронна идентификация.






Sandbox средата трябва да бъде пусната в експлоатация до 4 (четири) месеца от началото на изпълнение на договора за обществен поръчка.







Изисквания за изготвяне на документация за ИСЦЕИ

Изисквания за изготвяне на документация за ИСЦЕИ



Трябва да бъде изготвена техническа документация, отговаряща на релевантните изисквания, и с обхват, в съответствие с т. Error: Reference source not found от ТС







Изисквания към текущата поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка

Изисквания към текущата поддръжка за периода до приключване на дейностите по договора за възлагане на обществена поръчка



Изпълнителят трябва да осигури наблюдение на работоспособността и натовареността на ИСЦЕИ, и при необходимост оптимизации за по-добра производителност и надеждност.






Изпълнителят трябва да осигури изменения в изходния код и реализираните процеси в ИСЦЕИ, вследствие на изменения в нормативната уредба, настъпили преди края на договора за обществена поръчка.







Изисквания към гаранционна поддръжка и отстраняването на дефекти и отклонения от Техническата спецификация (ТС)

Изисквания към гаранционна поддръжка и отстраняването на дефекти и отклонения от Техническата спецификация (ТС)



Изпълнителят трябва да осигури гаранционна поддръжка на ИСЦЕИ за период от 36 (тридесет и шест) месеца.






Изпълнителят трябва да осигури гаранционна поддръжка за непрекъсната работоспособност на ИСЦЕИ, без отклонения от изискванията на ТС.






Изпълнителят трябва да осигури отстраняване на грешки и пропуски в сигурността, допуснати в изходния код на ИСЦЕИ, както и корекции за отстраняване на отклонения от изискванията на ТС.







Общи изисквания за реализиране на Портал за доставчици на електронни административни услуги (ПДЕАУ)

Общи изисквания за реализиране на Портал за доставчици на електронни административни услуги (ПДЕАУ)



Трябва да бъде реализиран Портал за доставчици на електронни административни услуги (ПДЕАУ), чрез който да се обслужват административните и бизнес процеси по взаимодействие между ЦЕИ и доставчиците на електронни административни услуги (ДЕАУ), които са регистрирани в ЦЕИ.






Трябва да бъде реализирана възможност за саморегистрация на ДЕАУ в ПДЕАУ, като достъпът на новорегистрираните ДЕАУ до функционалности, за които се изисква одобрение от ЦЕИ трябва да бъде ограничен.

Новорегистриран ДЕАУ, който не е получил одобрение от ЦЕИ, трябва да има ограничен достъп само до:



  • обща публична информация, предназначена за ДЕАУ

  • функционалност за вписване на услуги / конфигуриране на услуги

  • функционалност за конфигуриране на тестове данни за тестове / експерименти за интеграция с програмния интерфейс (API) на ИСЦЕИ

  • програмния интерфейс (API) на ИСЦЕИ опериращ в "Sandbox" среда за експерименти и тестова интеграция на ДЕАУ към ИСЦЕИ

Регистриран ДЕАУ, който е получил одобрение от ЦЕИ, трябва да има достъп пълната функционалност на ПДЕАУ.






Трябва да бъде разработена детайлна процедура за включване на ДЕАУ в продукционен режим на онлайн интеграция с ИСЦЕИ. Процедурата трябва да включва като минимум всички стъпки от процеса и необходимите изискуеми документи, и да бъде достъпна през служебния потребителски интерфейс за ДАЕУ.






При реализацията трябва да бъдат изпълнени релевантните общи изисквания, описани в т. Error: Reference source not found от ТС







Общи изисквания за реализиране на клиентски интеграции с програмни интерфейси (APIs) на други / външни АИС

Общи изисквания за реализиране на клиентски интеграции с програмни интерфейси (APIs) на други / външни АИС



Трябва да бъде реализирана клиентска интеграция между ПДЕАУ и програмните интерфейси (APIs) на ИСЦЕИ за обслужване, като минимум, на описаните основни процеси в т.Error: Reference source not found на ТС, които касаят взаимодействието между ДЕАУ и ЦЕИ.






Трябва да бъде реализирана клиентска интеграция между ПДЕАУ и програмните интерфейси (APIs) на РО, обслужваща като минимум процесите описани в т. Error: Reference source not found от ТС.






Трябва да бъде реализирана клиентска интеграция между ПДЕАУ и Подсистемата за управление на плащанията (ПУП), чрез програмния интерфейс (API) на ПУП.






Трябва да бъде реализирана клиентска интеграция между ПДЕАУ и Сертифициращите органи (СО), чрез програмния интерфейс (API) на СО.






Трябва да бъде реализирана клиентска интеграция между ПДЕАУ и "Журнал на събитията" (ПЖС), чрез програмния интерфейс (API) на ПЖС.






Трябва да бъде реализирана клиентска интеграция между ПДЕАУ и Подсистемата за автоматични нотификации (ПАН), чрез програмния интерфейс (API) на ПАН







Каталог: rdonlyres
rdonlyres -> Областна дирекция на мвр – р а з г р а д районно управление на мвр – р а з г р а д
rdonlyres -> Република българия министерство на вътрешните работи а н а л и з
rdonlyres -> Стара Загора Дата Време
rdonlyres -> „развитие на човешките ресурси” Ч
rdonlyres -> Дипломна работа за получаване на образователно-квалификационна степен „Магистър" по специалността „Стратегическо ръководство и управление на сигурността и обществения ред"
rdonlyres -> Наредба за условията и реда за функциониране на националната система за ранно предупреждение и оповестяване на органите на изпълнителната власт и населението при бедствия и за оповестяване при въздушна опасност
rdonlyres -> Решение за откриване на процедура за възлагане на обществена поръчка
rdonlyres -> Закон за движението по пътищата в сила от 01. 09. 1999 г. Отразена деноминацията от 05. 07. 1999 г
rdonlyres -> Наредба №8121з-968 от 10 декември 2014 Г. За правилата и нормите за пожарна безопасност при извършване на дейности в земеделските земи


Сподели с приятели:
1   2   3   4   5   6   7   8   9   10   ...   38




©obuch.info 2024
отнасят до администрацията

    Начална страница