|
|
Изисквания за реализиране на отказоустойчивост, непрекъсваемост и балансиране на натоварването
|
Изисквания за реализиране на отказоустойчивост, непрекъсваемост и балансиране на натоварването
|
| -
|
Всички приложни системи и подсистеми задължително трябва да оперират върху клъстери / уеб-ферми с минимум два (2) сървъра или виртуални машини във всеки от двата информационни центъра на Възложителя. При проблем с някой от сървърите, съответната система или подсистема трябва да продължи да функционира без смущения, намаляване на функционалностите или прекъсвания. Където това е възможно, се допуска използването на функциите на софтуера за виртуализация, осигуряващи равномерно разпределение на натоварването и възможност за продължаване на работата без прекъсване, в случай на отпадане, на някой от компонентите на изчислителната инфраструктура.
|
|
| -
|
Компонентите на приложната архитектура трябва да бъдат резервирани в двата информационни центъра, като работят в режим активен/активен с автоматично разпределение на натоварването (Active/Active Load Balancing).
Това изискване е задължително за Production и Staging средите. Допуска се Development и Sandbox Testing средите да не бъдат двойно резервирани за икономия на сървърни ресурси.
|
|
| -
|
При реализация на TLS Mutual Authentication компонентът, реализиращ разпределението на натоварването следва да терминира TLS сесията, да прочита клиентския сертификат и да препраща данните от него към приложните сървъри в „Custom Header Attribute”, както и информация за подписания Challenge. При подаване на „Custom Header Attribute” директно в заявката, той следва да бъде премахван, за да се избегнат „Spoofing” атаки.
|
|
| -
|
Load balancer системата трябва да позволява частично "reverse proxy" по даден URL location – например за пренасочване на API calls към приложните сървъри, а статичното съдържание към CDN сървъри.
|
|
| -
|
Участникът да предложи и други методи за балансиране на натоварването, необходими за специфичните компоненти на системата. Това могат да бъдат възможност за дефиниране на критерии за балансиране, поддръжка на session stickiness, поддръжка за динамично пренасочване и извличане на ресурси чрез X-Reproxy-URL и др.
|
|
|
|
Изисквания за бързодействие при реализация на потребителски интерфейси
|
Изисквания за бързодействие при реализация на потребителски интерфейси
|
| -
|
При визуализация на уеб-страници или екрани от уеб-базирани потребителски интерфейси, системите трябва да осигуряват висока производителност и минимално време за отговор на заявки - средното време за отговор на заявка трябва да бъде по-малко от 1 секунда, с максимум 1 секунда стандартно отклонение, за 95% от заявките, без да се включва мрежовото времезакъснение (Network Latency) при транспорт на пакети между клиента и сървъра.
Изискването не се прилага, когато като част от бизнес-процеса, потребителският интерфейс (UI) трябва да визуализира справки, анализи, както и за електронни документи, за чието генериране се изисква ръчен процес.
|
|
| -
|
Трябва да бъдат създадени и приложени тестове за стресово натоварване, с подходящи софтуерни инструменти, чрез които да се изследва поведението на потребителските интерфейси при пиково натоварване и да се измери реалната им производителност.
Провеждането на стрес тестове ще бъде част от процеса по приемане на изпълнениeто на договора за обществена поръчка.
|
|
|
|
Изисквания за бързодействие при реализация на програмни интерфейси (API)
|
Изисквания за бързодействие при реализация на програмни интерфейси (API)
|
| -
|
Програмните интерфейси (APIs) на системите, подсистемите, модулите и др., трябва да осигуряват висока производителност и минимално време за отговор на "sync pull" заявки, когато обслужването на такъв тип заявки е предвидено по проект. Средното време за отговор на заявка трябва да бъде по-малко от 1 секунда, с максимум 1 секунда стандартно отклонение, за 95% от заявките, без да се включва мрежовото времезакъснение (Network Latency) при транспорт на пакети между клиента и сървъра.
Изискването не се прилага, когато като част от бизнес-процеса и архитектурният дизайн, програмният интерфейс (API) предоставя уеб-услуги в режими / по модели "async pull" и "subscribe – push".
|
|
| -
|
Трябва да бъдат създадени и приложени тестове за стресово натоварване, с подходящи софтуерни инструменти, чрез които да се изследва поведението на програмните интерфейси при пиково натоварване и да се измери реалната им производителност.
Провеждането на стрес тестове ще бъде част от процеса по приемане на изпълненито на договора за обществена поръчка.
|
|
|
|
Изисквания за прилагане на кохерентно кеширане на данни
|
Изисквания за прилагане на кохерентно кеширане на данни
|
| -
|
Отделните информационни системи, подсистеми и интерфейси, трябва да бъдат проектирани и да използват системи за разпределен кохерентен кеш, в случаите, в които това би довело до подобряване на производителността и мащабируемостта.
|
|
| -
|
Разпределеният кохерентен кеш или конкретната приложна имплементация, използваща разпределения кохерентен кеш, трябва да поддържа възможност за компресия на подходящите за това данни – например тези от текстов тип.
|
|
| -
|
Използваният алгоритъм за създаване на ключове за съхранение / намиране на данни в кеша трябва да не допуска колизии и оптимално да използва процесорните ресурси за генериране на хешове.
|
|
| -
|
Разпределеният кохерентен кеш трябва да поддържа различни времена-за-живот (TTL) за отделните видове данни, които трябва да бъдат конфигурирани по целесъобразност, за да се оптимизира консумацията на RAM памет.
|
|
| -
|
Изпълнителят трябва да подбере подходящи софтуерни решения с отворен код за реализиране на буфериране и кеширане на данните в оперативната памет на сървърите. В зависимост от конкретните приложни случаи (Use Cases) е допустимо да се използват и внедрят различни технологии, които покриват по-добре конкретните нужди – например решения с отворен код като Memcached или Redis в комбинация с Redis GeoAPI могат да осигурят порядъци по-висока мащабируемост и производителност за често достъпвани оперативни данни, номенклатурни данни или документи.
|
|
| -
|
Като минимум разпределен кохерентен кеш трябва да се предвиди и реализира в следните приложни случаи (Use Cases):
-
Номенклатури и атомарни данни, предоставяни от първичните регистри;
-
Извличане на информация от Регистъра на удостоверенията за електронна идентичност;
-
Извличане на информация от Регистъра на електронните идентификатори;
-
Извличане на информация от Регистъра на администраторите на електронна идентичност и центрове на електронна идентичност;
-
Извличане на информация от Регистъра на овластяванията;
-
Документи и съобщения от системата за сигурно връчване;
-
Информация от лога на транзакциите при достъп с еИД до дадена услуга;
-
Информация за извършените плащания.
|
|
| -
|
Трябва да бъдат реализирани специфични архитектурни, системни, мрежови и конфигурационни мерки за гарантиране на информационната сигурност и защитата на данните, буферирани в разпределения кохерентен кеш, с цел да бъде гарантиран интегритетът и контролът на достъп до данните.
|
|
| -
|
Участникът да опише детайлно подхода и използваните механизми и технологии за реализация на разпределен кохерентен кеш, както и системните компоненти, които ще използват разпределен кохерентен кеш, съгласно изискванията на ТС.
Следва да бъде описан и типизираният подход (Design Pattern) за осигуряване и гарантиране на кохерентност между данните, записани в постоянния сторидж (Persistent Storage) и тези в кеша (RAM Cache), специфичните мерки за информационна сигурност и гарантиране на интегритета на данните.
|
|
|
|
Изисквания за използване на HTTP/2 при реализация на публични потребителски интерфейси
|
Изисквания за използване на HTTP/2 при реализация на публични потребителски интерфейси
|
| -
|
Съгласно подзаконовата нормативна уредба на ЗЕУ, с оглед намаляване на служебния трафик, времената за отговор и натоварването на сървърите, за услугите предоставяни през публични уеб-базирани потребителски интерфейси, трябва да се имплементира и конфигурира поддръжка за HTTP/2 протокол (съгласно RFC 7540).
При конфигурирането на HTTP/2 трябва да бъдат поддържани и включени следните възможности:
-
Включена компресия на хедърите (Header Compression);
-
Използване на Brotli алгоритъм за компресия;
-
Включен HTTP pipelining;
-
HTTP/2 Server Push, приоритизиращ специфични компоненти, изграждащи страниците (CSS, JavaScript файлове и др.).
|
|
| -
|
Публичните потребителски интерфейси трябва да поддържат автоматичен динамичен избор на алгоритми за криптиране (Dynamic selection of TLS chipher suites) според вида на процесорната архитектура на клиентското устройство:
-
AES-GCM за x86 работни станции и преносими компютри (с налични AES-NI CPU разширения)
-
ChaCha20/Poly1305 за мобилни устройства (основно базирани на ARM процесори).
|
|
| -
|
Ако клиентският браузър/клиент не поддържа HTTP2 протокол, трябва да бъде предвиден автоматичен "fall-back" механизъм към HTTP 1.1. Тази възможност трябва да може да се изключва чрез конфигурационни промени в бъдеще, когато браузърите/клиентите, неподдържащи HTTP/2 бъдат незначителен брой.
|
|
|
|
Изисквания за използване на HTTP/2 при реализация на програмни интерфейси (API)
|
Изисквания за използване на HTTP/2 при реализация на програмни интерфейси (API)
|
| -
|
С оглед намаляване на служебния трафик, времената за отговор и натоварването на сървърите и постигане на максимално високо ниво на сигурност, за услугите предоставяни през програмни интерфейси (APIs), трябва да се имплементира и конфигурира поддръжка за HTTP/2 протокол (съгласно RFC 7540) с допълнителни изисквания.
При конфигурирането на HTTP/2 за програмните интерфейси (APIs) трябва да бъдат анализирани и включени възможностите на HTTP/2, които са приложими и биха донесли положителен ефект:
-
Включена компресия на хедърите (Header Compression);
-
Използване на Brotli алгоритъм за компресия;
-
Включен HTTP pipelining;
В допълнение на изискванията на RFC 7540, Участниците да предложат имплементации, при които се прилагат задължително (MUST) функционалности, които са опционални (MAY) в текущата версия на стандарта, като например:
-
RFC 7540, Section 9.2.1 – Задължително прекъсване на връзката, в случай че клиент не покрива минималните изисквания за сигурност, а именно версия на TLS версия 1.2 или по-висока
-
RFC 7540, Section 9.2.2. – Задължително прекъсване на връзката, в случай че клиент изпраща заявка за договаряне на алгоритъм за криптиране, включен в "черен списък"
-
RFC 7540, Section 10.5 (Denial-of-Service Considerations) – Задължително третиране на необичайни / подозрителни активности като грешки при свързване от тип ENHANCE_YOUR_CALM
|
|
| -
|
Публичните потребителски интерфейси трябва да поддържат автоматичен динамичен избор на алгоритми за криптиране (Dynamic selection of TLS chipher suites) според вида на процесорната архитектура на клиентското устройство:
-
AES-GCM за x86 работни станции и преносими компютри (с налични AES-NI CPU разширения)
-
ChaCha20/Poly1305 за мобилни устройства (основно базирани на ARM процесори).
|
|
| -
|
Ако клиентската система не поддържа HTTP2 протокол, трябва да бъде блокирана възможността за автоматичен "fall-back" към HTTP 1.1. Тази възможност трябва да може да се включва / изключва чрез конфигурационни промени в бъдеще.
|
|
|
|
Изисквания за постигане на бързодействие при реализация на функционалности за подписване на електронни документи
|
Изисквания за постигане на бързодействие при реализация на функционалности за подписване на електронни документи
|
| -
|
При реализацията на функционалности за подписване на електронни документи с удостоверение за електронен подпис трябва да се подписва хеш, генериран на базата на документа, вместо цялото съдържание на документа.
|
|
| -
|
Минимално допустимият алгоритъм за хеширане, който трябва да се използва при електронно подписване е SHA-256. В случаите, в които не се подписва уеб съдържание (например документи, файлове и др.) е необходимо да се реализира поточно хеширане, като се избягва зареждането на цялото съдържание в оперативната памет.
|
|
|
|
Изисквания за мащабируемост при реализация на системи, подсистеми, модули и компоненти, обслужващи критични процеси
|
Изисквания за мащабируемост при реализация на системи, подсистеми, модули и компоненти, обслужващи критични процеси
|
| -
|
Националната схема за електронна идентификация трябва да обслужва редица критични административни и бизнес процеси, от които зависи функционирането и нормалната работа на множество публични информационни системи, предоставянето на ЕАУ и достъпът на гражданите до множество публични и финансови услуги.
С оглед на дългосрочното оразмеряване и проектиране на архитектурата на националната схема за електронна идентификация, са идентифицирани следните критични процеси и функционалности, за които може да се очакват и съществени пикови натоварвания:
-
Проверка на удостоверения за електронна идентичност;
-
Предоставяне на информация по атомични въпроси за обстоятелства;
-
Публикуване на актуална и навременна информация за спрените/прекратените удостоверения за електронна идентичност;
-
Процеси по издаване на удостоверения за електронна идентичност, включително и в процеса на персонализация на лични документи и документи за пътуване;
-
Процеси по журналиране на събития и операции.
Изпълнителят трябва да посочи и опише всички системи, подсистеми, модули, компоненти и елементи на техническата инфраструктура, които трябва да бъдат мащабирани в бъдеще, с оглед посрещане на пикови или обичайни натоварвания на националната схема за електронна идентификация.
|
|
| -
|
Изпълнителят трябва да опише подробно като минимум:
-
Подходите за вертикално мащабиране - например добавяне/премахване (напр. поради overprovisioning) на ресурси към виртуалните машини – RAM / CPU / Storage)
-
Подходите за хоризонтално мащабиране - например добавяне / премахване на инстанции или сървъри, балансиране на натоварването между множество сървъри и др.
В описанието трябва да се включи очакваният ефект върху производителността и необходимите конфигурации, които трябва да се приложат на системно и приложно ниво (конфигуриране на операционна система, база данни, система за разпределен кохерентен кеш, системи за балансиране на натоварването, приложения.
|
|
|
|
Общи изисквания за осигуряване на интегритет на вписванията в нормативно-установени регистри
|
Общи изисквания за осигуряване на интегритет на вписванията в нормативно-установени регистри
|
| -
|
Всички регистри, реализирани като информационни системи с транзакционни системи за управление на бази данни, трябва да поддържат само операции по добавяне на записи за статус и актуализиране на определени колони за статус, без възможност за изтриване на записи, свързани с промяна на статус и/или извършване на действие.
|
|
| -
|
Транзакциите по вписване, промяна и заличаване на обстоятелства в регистрите трябва да бъдат реализирани единствено чрез добавяне на нови записи, които отразяват съответното действие / обстоятелство.
|
|
|
|
Общи изисквания към сигурността и защитата на личните данни
|
Общи изисквания към сигурността и защитата на личните данни
|
| -
|
Всички елементи на Националната схема за електронна идентичност трябва да отговарят на изискванията на Регламент (ЕС) 2016/679 на Европейския парламент и на Съвета относно защитата на физическите лица във връзка с обработването на лични данни и относно свободното движение на такива данни.
|
|
| -
|
Националната схема за електронна идентификация трябва да покрива изискванията за най-високото Ниво 4 на сигурност, описано в ISO/IEC 29115:2013 съгласно Регламент 910/2014. Участникът да опише подхода си за постигане на изискванията на стандарта и Регламента.
|
|
| -
|
Изпълнителят трябва да опише подхода си за постигане на изискванията за гарантиране на сигурността при управлението на процесите по разработка, тестване, разгръщане на нови версии, системна администрация и поддръжка на системите и услугите, така че да бъдат елиминирани рискове и заплахи, предизвикани от пропуски в оперативната работа и/или човешки грешки.
|
|
|
|
|
