%A2%D0%97-%D0... · Web viewВ момента документооборотните системи на държавната администрация обменят електронни

Приложение № 4

Държавна агенция „Електронно управление“

ТЕХНИЧЕСКО ЗАДАНИЕ (ТЕХНИЧЕСКА СПЕЦИФИКАЦИЯ)

за

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

2 / 34

1. РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ 5

1.1. Използвани акроними.......................................................................................5

1.2. Технологични дефиниции.................................................................................5

1.3. Дефиниции за нива на електронизация на услугите......................................5

2. ВЪВЕДЕНИЕ 6

2.1. Цел на документа...............................................................................................6

2.2. За Възложителя – функции...............................................................................6

2.3. За проекта...........................................................................................................7

2.4. Нормативна рамка.............................................................................................7

3. ЦЕЛИ, ОБХВАТ И ОЧАКВАНИ РЕЗУЛТАТИ ОТ ИЗПЪЛНЕНИЕТО НА ПРОЕКТА 8

3.1. Общи и специфични цели на проекта..............................................................8

3.2. Обхват на проекта............................................................................................10

3.2.1. Дейност „Анализ и проектиране“..........................................................................103.2.2. Дейност „Разработване и внедряване“.................................................................103.2.3. Дейност „Разширена гаранционна поддръжка“..................................................103.2.4. Дейност „Разширение на системата с до 500 потребителя (със стъпка 100

потребителя)“..................................................................................................................................103.2.5. Дейност „Хардуерно разширение на бек енд на системата“............................11

3.3. Целеви групи....................................................................................................11

3.4. Очаквани резултати.........................................................................................11

3.4.1. По дейност „Анализ и проектиране“....................................................................113.4.2. По дейност „Разработване и внедряване“............................................................113.4.3. По дейност „Разширена гаранционна поддръжка“.............................................113.4.4. По дейност „Разширение на системата с до 500 потребителя (със стъпка

100 потребителя)“...........................................................................................................................113.4.5. По дейност „Хардуерно разширение на бек енд на системата“.......................11

3.5. Период на изпълнение.....................................................................................11

4. ТЕКУЩО СЪСТОЯНИЕ 12

5. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА 13

5.1. Общи изисквания към изпълнението на обществената поръчка...............13

5.2. Общи организационни принципи...................................................................14

5.3. Управление на проекта...................................................................................15

5.4. Управление на риска.......................................................................................16

6. ЕТАПИ НА ИЗПЪЛНЕНИЕ НА ПРОЕКТА 16

6.1. Анализ, проектиране, разработване и внедряване.......................................16

6.1.1. Анализ и проектиране..............................................................................................166.1.2. Разработване и внедряване......................................................................................17

6.2. Гаранционна поддръжка.................................................................................17

3 / 34

7. ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ 18

7.1. Функционални изисквания към информационната система......................18

7.1.1. Интеграция с външни информационни системи................................................187.1.2. Интеграционен слой.................................................................................................187.1.3. Технически изисквания към интерфейсите.........................................................197.1.4. Електронна идентификация на потребителите...............................................197.1.5. Формиране на изгледи..............................................................................................197.1.6. Отворени данни........................................................................................................197.1.7. Администриране на системата.............................................................................19

7.2. Нефункционални изисквания към информационната система..................19

7.2.1. Авторски права и изходен код.................................................................................197.2.2. Системна и приложна архитектура....................................................................207.2.3. Повторно използване (преизползване) на ресурси и готови разработки..........217.2.4. Подход за работа с външните софтуерни ресурси..............................................217.2.5. Изграждане и поддръжка на множество среди...................................................227.2.6. Процес на разработка, тестване и разгръщане...................................................227.2.7. Бързодействие и мащабируемост..........................................................................227.2.8. Информационна сигурност и интегритет на данните.....................................237.2.9. Използваемост..........................................................................................................247.2.10. Дизайн на бази данни и взаимодействие с тях....................................................27

8. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА28

8.1. Дейност „Анализ и проектиране“...................................................................28

8.1.1. Описание на дейността...........................................................................................288.1.2. Изисквания към изпълнение на дейността..........................................................288.1.3. Очаквани резултати................................................................................................28

8.2. Дейност „Разработване и внедряване“..........................................................29


8.3. Дейност „Разширена гаранционна поддръжка“...........................................30


8.4. Дейност „Разширение на системата с до 500 потребителя (със стъпка 100 потребителя)“..............................................................................................................31


8.5. Дейност „Хардуерно разширение на бек енд на системата“ – по заявка на възложителя през срока на разширената гаранционна поддръжка, съгласно предложената от изпълнителя цена в ценовото му предложение..........................31


9. ДОКУМЕНТАЦИЯ 32

9.1. Изисквания към документацията..................................................................32

4 / 34

9.2. Прозрачност и отчетност.................................................................................32

9.3. Системен проект (технически проект)...........................................................33

9.4. Техническа документация...............................................................................33

9.5. Протоколи.........................................................................................................33

9.6. Комуникация и доклади..................................................................................33

9.6.1. Встъпителен доклад................................................................................................339.6.2. Междинни доклади...................................................................................................339.6.3. Окончателен доклад.................................................................................................339.6.4. Списък на документите, които задължително трябва да се представят в

хода на изпълнение на Проекта.....................................................................................................3410. РЕЗУЛТАТИ 34

5 / 34

1. РЕЧНИК НА ТЕРМИНИ, ДЕФИНИЦИИ И СЪКРАЩЕНИЯ

1.1. Използвани акроними

Акроним ОписаниеДАЕУ Държавна агенция „Електронно управление“ЕЕСМ Единна електронна съобщителна мрежа на държавната администрация и

за нуждите на националната сигурностЗЗКИ Закон за защита на класифицираната информацияКИИ Комуникационна и информационна инфраструктураРДКИ Разрешение за достъп до класифицирана информацияСАИАЕД Система за автоматизирана инспекция и анализ на електронни документиСЕОС Система за електронен обмен на съобщенияССЕВ Система за сигурно електронно връчване

API Application Programming Interface – приложен програмен интерфейс

1.2. Технологични дефиниции

Термин Описание политика за автоматизирана инспекция и анализ на електронни документи

съвкупност от правила и действия (алгоритъм), които се изпълняват автоматизирано при настъпване на определени събития.

електронен документ определението по чл.3, т.35 от РЕГЛАМЕНТ (ЕС) № 910/2014 на ЕП – „електронен документ“ означава всяко съдържание, съхранявано в електронна форма, по-специално текстови или звуков, визуален или аудио-визуален запис

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

1.3. Дефиниции за нива на електронизация на услугите

Термин Описание Ниво 1 Информация – предоставяне на информация за административни услуги по

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

Ниво 2 Едностранна комуникация – информация съгласно дефиницията за Ниво 1 и осигурен публичен онлайн достъп до шаблони на електронни формуляри.

Ниво 3 Двустранна комуникация – заявяване и получаване на услуги изцяло по електронен път, включително електронно подаване на данни и документи, електронна обработка на формуляри и електронна персонална идентификация на потребителите.

Ниво 4 Извършване на сделки или транзакции по услуги от Ниво 3, включващи онлайн разплащане или доставка.

6 / 34

2. ВЪВЕДЕНИЕ

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

Системите и услугите, които се защитават от САИАЕД са описани на сайта на ДАЕУ:

система за сигурно електронно включване – https://e-gov.bg/bg/152; система за електронен обмен на съобщения – https://e-gov.bg/bg/119.

2.1. Цел на документа

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

В настоящата техническа спецификация са описани и изискванията към проектната организация, документацията и отчетността.

2.2. За Възложителя – функции

ДАЕУ е създадена със Закона за електронното управление. Агенцията е юридическо лице на бюджетна издръжка със седалище в град София. Председателят на ДАЕУ е първостепенен разпоредител с бюджет, определя се с Решение на Министерския съвет и се назначава от министър-председателя за срок от 5 години.

ДАЕУ е правоприемник на дирекция „Електронно управление” в Министерството на транспорта, информационните технологии и съобщенията и на Изпълнителната агенция „Електронни съобщителни мрежи и информационни системи” и има функции по издаване, налагане и контрол на политики, правила и добри практики в областта на електронното управление, стратегическо планиране и инициативи, бюджетно програмиране и контрол, координация на секторни политики и секторни и междуведомствени проекти. Също така поддържа централизирани регистри за нуждите на електронното управление, други централизирани регистри, държавен частен облак и Единната електронна съобщителна мрежа (ЕЕСМ) на държавната администрация и за нуждите на националната сигурност.

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

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

7 / 34

2.3. За проекта

Министерският съвет на Република България, с Решение № 357 от 29 юни 2017г., задължи ръководителите на всички администрации да приведат системите си за електронен документооборот в съответствие с определения от председателя на ДАЕУ технически протокол по чл. 18 от Наредбата за общите изисквания към информационните системи, регистрите и електронните административни услуги. С това решение се осигури техническа възможност за обмен на документи между администрациите в електронен вид, чрез използване на Системата за електронен обмен на съобщения (СЕОС). Задължението за всички администрации да обменят документи помежду си единствено по електронен път е в сила от 1 ноември 2018 година.

С Решение № 777 от 31 октомври 2018 г. на Министерския съвет на Република България задължи ръководителите на всички администрации да създадат профили в Системата за сигурно електронно връчване (ССЕВ), която се поддържа от ДАЕУ и да разработят вътрешни правила и процедури за приемане и изпращане на документи и съобщения чрез ССЕВ.

В края на 2018 г. ДАЕУ извърши интегриране на СЕОС и ССЕВ и така се осигури възможност потребители извън администрацията да изпращат до нея електронни документи.

С § 6 на Преходни и Заключителни разпоредби от „Наредба за общите изисквания към информационните системи, регистрите и електронните административни услуги“, задължението за използване на електронен документооборот по чл. 32, ал. 1 и 2 от наредбата влиза в сила от 1 ноември 2018 г. и е задължително за всички администрации.

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

Предвижда се да се надгради САИАЕД и да се осигури техническа поддръжка. Документите ще бъдат сканирани за заплахи в бек-енд компонентите на САИАЕД с два независими антивирусни софтуера, с възможност за автоматично стартиране на съмнителни приложения в изолирана среда (Sandbox) с цел да се идентифицират нови и непознати до момента заплахи за информационната сигурност. Комуникацията между системите в СЕОС и ССЕВ и САИАЕД ще бъде балансирана и ще се обслужва от няколко бек-енд компонента с цел постигане на отказоустойчивост. Ще се направи анализ на сегашните възможности на системата и ще се предложи мащабируемо решение.

2.4. Нормативна рамка

Проектът се осъществява в съответствие с изискванията, регламентирани със следните нормативни актове и стратегически документи:

закона за електронното управление; закон за електронния документ и електронните удостоверителни услуги; закон за киберсигурност; регламент (ЕС) № 910/2014; наредбата за общите изисквания към информационните системи, регистрите и

електронните административни услуги; наредба за обмена на документи в администрацията; наредба за общите изисквания за мрежова и информационна сигурност; решение № 357/2017 г. на Министерският съвет, което задължава

административните органи да приведат системите си за електронен документооборот в съответствие с техническия протокол за обмен;

решение № 3777/2018 г. на Министерският съвет, което задължава административните органи да създадат профили в ССЕВ;

8 / 34

стратегия за развитие на електронно управление в Република България 2014 – 2020, приета с Решение №163/2014 г. на Министерския съвет;

пътна карта за изпълнение на Стратегията за развитие на електронното управление в Република България за периода 2016-2020 г.

архитектурата на електронното управление в Република България, одобрена от председателя на ДАЕУ със Заповед № ДАЕУ-5040-11.04.2019 г.

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

3. ЦЕЛИ, ОБХВАТ И ОЧАКВАНИ РЕЗУЛТАТИ ОТ ИЗПЪЛНЕНИЕТО НА ПРОЕКТА

3.1. Общи и специфични цели на проекта

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

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

Постигането на общата цел ще бъде реализирано чрез следните специфични цели, съответстващи на планираните по проекта дейности:

осигуряване на възможност за функционална интеграция на САИАЕД с всички типове документообороти системи от СЕОС и със ССЕВ, с цел приемане на електронни документи от тях и автоматизираната им инспекция и анализ за наличието на злонамерен софтуер;

осигуряване на лицензиране и поддръжка на наличната в САИАЕД технология на Symantec Content Analysis System, която дава възможност за едновременно инспектиране и анализ на електронните документи за наличието на злонамерен софтуер чрез едновременно използване на минимум два независими антивирусни софтуера, поведенчески анализ, предвиждащ анализ и предоставяне на интегрирана изолирана среда за стартиране и анализ на съмнителни приложения;

предоставяне на възможност за конфигуриране на различни параметри, които да позволят да се прилагат адекватни политики за сканиране на електронни документи. Възможните параметри може да са слените, но и не само:o големина на инспектираните файлове и изпълнение на действие, в случай че

подаденият за сканиране файл е по-голям от предварително зададения максимален размер;

o време за сканиране и конкретно действие при надвишаване на конфигурирания интервал;

o инспектиране на архиви и изпълнение на действие, в случай че подаденият за сканиране архив съдържа повече файлове от предварително зададения максимален брой;

o конфигуриране на максимален брой вложени архиви и изпълнение на действие, в случай, че подаденият за сканиране архив съдържа повече вложени архиви от предварително зададения максимален брой;

9 / 34

o изпълнение на действие, в случай че подаденият за сканиране архив е защитен с парола;

o изпълнение на действие, в случай че един от файловете в подаденият за сканиране архив съдържа вирус;

o дефиниране на списък с файлови разширения, които да се блокират.o дефиниране на списък с файлови разширения, които да не се сканират;o изпълнение на действие, в случай че един от файловете в подаденият за

сканиране архив съдържа файл с разширение, което трябва да се блокира; осигуряване на мерки за защита на информацията, съдържаща се в

електронните документи при автоматизираната им инспекция и анализ, съизмерими с мерките, предприети в СЕОС и ССЕВ;

САИАЕД комуникира с документооборотите системи от СЕОС и ССЕВ чрез приложно-програмен интерфейс (Application Programming Interface – API), състоящ се от фронт-енд и мидълуер, който обслужва заявките за автоматизираната инспекция и анализ, като ги подава към бек-енд компонентите на СААИАФ и връща резултатите от анализа към съответните системи.

След приключване на дейностите по надграждане САИАЕД трябва минимално да отговаря и предоставя функционалности както следва:

използване на правила и политики за действие при различни сценарии; автоматизирана инспекция и анализ на електронни документи за наличие на

злонамерен софтуер, включваща:o два независими антивирусни софтуера (Anti-virus Engines);o поведенчески анализ на файловете (Behavior Analysis);o предвиждащ анализ (Predictive Analysis);

интегрирана изолирана среда (Sandbox) за автоматизирано стартиране и анализ на съмнителни и/или непознати приложения с цел идентификация на непознати до момента нови заплахи;

работата на 1000 потребителя (СЕВ или документооборотна система от СЕОС), с възможност за надграждането ѝ до 1500;

автоматизирана инспекция и анализ на до 6000 документа на ден, в интегрирана изолирана среда (Sandbox), всеки от тях с размер 10 MB, с възможност за надграждането ѝ до 50000 документа на ден, всеки от тях с размер 50 MB;

възможност за увеличаване на размера на инспектираните файлове до 2 GB; време за автоматизирана инспекция и анализ на електронни документи за

наличие на злонамерен софтуер до 5 /пет/ секунди за документи с големина до 10MB във формат текст (*.doc, *.docx, *.rtf, *.odt, *.pdf), електронна таблица (*.xls, *.xlsx, *.ods), изображения (*.jpg, *.jpeg, *.png, *.tif) и Microsoft Outlook (*.eml), считано от момента на постъпване на целия документ в САИАЕД;

време за автоматизирано стартиране и анализ на съмнителни и/или непознати приложения интегрирана изолирана среда (Sandbox) до 30 /тридесет/ секунди за документи с големина до 10MB във формат текст (*.doc, *.docx, *.rtf, *.odt, *.pdf), електронна таблица (*.xls, *.xlsx, *.ods), изображения (*.jpg, *.jpeg, *.png, *.tif) и Microsoft Outlook (*.eml), считано от момента на постъпване на целия документ в САИАЕД

бек-енд компонентите на системата за автоматизирана инспекция и анализ на електронни документи и интегрираната изолирана среда (Sandbox), да бъдат инсталирани на специализиран хардуер (сървър) препоръчан/доставен от производителя й и осигуряващ следните минимални характеристики:o стандартни мрежови интерфейси:

- (2) 1000Base-T Copper Ports (with bypass)- 1000Base-T Copper Ports (ICAP)- 1000Base-T Copper, System Management Port

10 / 34

- 1000Base-T Copper, BMC Management Porto възможност за използване на следните мрежови интерфейси:

- 4x10/100/1000Base-T (Copper with bypass capability)- 4x1GbE Fiber-SR (with bypass capability, full height slot only)- 2x10Gb Base-T (Copper with bypass capability)- 2x10Gb Base-T (Copper non-bypass)- 2x10Gb Fiber (SR with bypass capability)- 2x10Gb Fiber (LR with bypass capability)

o комуникационен капацитет – не по-малко от 100 mbps с едновременно активирани AV и Sandbox функции;

o обработка на 6000 файла (samples) на ден при едновременно активирани AV и Sandbox функции;

o хардуер с резервирано/двойно захранване от типа (Dual redundant and hot swappable power supplies)

o хардуер със следните оперативни характеристики:- Сторидж: 1TB (2 x 500GB)- Памет: не по-малко от RAM 30 GB- AC захранване: AC power 100-127V @ 8A 200-240V @ 4A, 47-63Hz- Съответствие с изискванията на Европейски съюз: за сигурност: CE –

EN60950-1, Second Edition, за електромагнитно съответствие: EN55022, Class A; EN55024; EN61000-3-2; EN61000-3-3

бек-енд компонентите на САИАЕД следва да са резервирани, така че да се осигурява отказоустойчивост, от типа Active-Active или Active-Passive, в случай на отпадане на бек-енд компонент;

САИАЕД трябва да дава възможност заявките от СЕОС и ССЕВ да бъдат балансирани между няколко фронт-енд и мидълуер, комуникиращи си с няколко бек-енд системи;

лицензиране за три години.

3.2. Обхват на проекта

Описаните в т. 3.1 цели се осъществяват с изпълнението на следните основни дейности, които формират обхвата на проекта:

анализ и проектиране; разработване и внедряване; разширена гаранционна поддръжка; Разширение на системата с до 500 потребителя (със стъпка 100 потребителя; Хардуерно разширение на бек енд на системата.

3.2.1. Дейност „Анализ и проектиране“

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

3.2.2. Дейност „Разработване и внедряване“

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

3.2.3. Дейност „Разширена гаранционна поддръжка“

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

11 / 34

3.2.4. Дейност „Разширение на системата с до 500 потребителя (със стъпка 100 потребителя)“

В рамките на дейността се увеличават броя на лицензите, използвани от бек енд на системата в съотвествие с броя на потребителите на системата. Разширението се осъществява със стъпка 100 потребителя. Дейността се изпълнява по заявка на заявителя.

3.2.5. Дейност „Хардуерно разширение на бек енд на системата“

В рамките на дейността системата се разширява хардуерно с цел гарантиране и разширяване на параметрите на заложените функционалности. Дейността се изпълнява по заявка на заявителя.

3.3. Целеви групи

Целевите групи, към които е насочен проектът, обхващат: ДАЕУ; администрации и административни единици; лицата, осъществяващи публични функции и организациите, предоставящи

обществени услуги; юридически лица; физически лица.

3.4. Очаквани резултати

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

3.4.1. По дейност „Анализ и проектиране“

изготвен доклад с анализ и варианти за надграждане на САИАЕД; изготвен технически проект със спецификация.

3.4.2. По дейност „Разработване и внедряване“

разработен план за интеграция на САИАЕД в комуникационната и информационна инфраструктура (КИИ) на ДАЕУ;

проверка на концепцията за интеграцията на САИАЕД с до три документооборотни системи от СЕОС и със ССЕВ и извършване на последваща интеграция след успешна проверка;

извършени доставка, монтаж и конфигурация на компонентите на САИАЕД в КИИ на ДАЕУ;

проведено обучение на не по-малко от 5 (пет) служителя на ДАЕУ; проведени приемни изпитания и подписан окончателен приемо-предавателен

протокол.

3.4.3. По дейност „Разширена гаранционна поддръжка“

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

3.4.4. По дейност „Разширение на системата с до 500 потребителя (със стъпка 100 потребителя)“

Осигурена възможност на системата да работи с от 1001 до 1500 потребителя. Дейноста се изпълнява по заявка на заявителя.

3.4.5. По дейност „Хардуерно разширение на бек енд на системата“

12 / 34

Система, работеща в рамките на зададените (подобрени) параметри. Дейноста се изпълнява по заявка на заявителя.

3.5. Период на изпълнение

Периодът на изпълнение на дейностите „Анализ и проектиране“ и „Разработване и внедряване“ е до 90 дни (3 месеца) след подписване на договор, а за дейност „Разширена гаранционна поддръжка“ – 36 месеца.

Графикът за изпълнение трябва да бъде съобразен с продължителността на дейносттите и не може да надвишава 39 месеца от дата на сключване на договора.

4. ТЕКУЩО СЪСТОЯНИЕ

В момента документооборотните системи на държавната администрация обменят електронни документи посредством участието си в системата СЕОС. СЕОС предоставя комуникационна среда и протокол, за да обслужва комуникацията и обмена между разнородни документооборотни системи. СЕОС се базира на нарочно разработен комуникационен протокол, който използва методи за инкапсулация на съобщенията. Участниците в обмена на съобщения се автентикират посредством сертификати. Всички участници в СЕОС са описани в централизиран регистър не участниците. За да може една документооборотна система да участва в СЕОС, тя трябва да има достъп до СЕОС мрежата, да поддържа техническия протокол, да има издаден валиден сертификат като участник в СЕОС и да е вписана в регистъра на участниците. Към момента в СЕОС са регистрирани 934 административни единици –администрации, съгласно закона за администрацията, както и техните териториални структури.

Архитектурата на системата е децентрализирана и обмена на електронни документи се извършва директно между деловодните системи на подателя и получателя. Комуникацията е криптирана и не позволява прихващане на съдържанието от трети страни. В СЕОС административно е наложено ограничение размерът на обменяните файлове да не надвишава 10 MB, освен ако няма предварителна уговорка между страните за технологичната възможност да приемат файлове с по-голям обем. В СЕОС се обменят електронни документи с всякакво съдържание, файлов формат и големина. Това създава предпоставки освен истинските документи, неумишлено или умишлено да се разпространява и злонамерен софтуер, което е заплаха за получателите на съобщенията. Тези заплахи имат кибернетичен характер и като такива биха могли да се превърнат във вектор за атака, насочена към КИИ и информационните системи на държавната администрация.

ССЕВ позволява изпращане и/или получаване и съхраняване на електронни документи за/от публични органи, физически и юридически лица. Комуникацията чрез ССЕВ замества класическия метод за доставка на писма и е в съответствие Регламент (ЕС) № 910/2014, и Закона за електронното управление. ССЕВ осигурява еквивалент на препоръчаната поща с обратна разписка. Предназначена е за граждани и юридически лица, за администрации, за лица, осъществяващи публични функции и за организации, предоставящи обществени услуги. Всички потребители могат да интегрират ССЕВ към собствените си системи или да го използват чрез потребителски интерфейс на адрес https://edelivery.egov.bg/. Достъпът през интерфейса се осъществява след регистрация чрез средство за идентификация на потребителите.

Към момента в ССЕВ са регистрирани 653 административни единици, 1198 лица, осъществяващи публични функции, и организации, предоставящи обществени услуги 87 юридически и 18451 физически лица. Архитектурата на системата е централизирана. Комуникацията е криптирана и не позволява прихващане на съдържанието от трети страни. В ССЕВ няма наложено ограничение за съдържанието, файловия формат и големината на обменяните.

13 / 34

Осъзнатия риск, децентрализираната архитектура и спецификите на техническия протокол в СЕОС наложиха изграждането на САИАЕД. САИАЕД осигурява на участниците в СЕОС възможност за допълнителна автоматизирана инспекция и анализ на електронните документи.

При интегриране на документооборотна система към САИАЕД, автоматизираната инспекция и анализ на електронни документи за наличие на злонамерен се извършва на три независими места – в КИИ на изпращача, в САИАЕД и в КИИ на получателя, като се постигат много високи нива на киберсигурност.

Компонентите на САИАЕД работят в три слоя: фронт-енд – слой, чрез който САИАЕД си комуникира с други системи; мидълуер – междинен интеграционен слой; бек-енд – слой за същинска автоматизирана инспекция и анализ на

електронните документи.Във фронт-енд слоя е инсталиран Web-сървър. Той обработва заявките от/към

СЕОС и ССЕВ през HTTPS протокол.В мидълуер слоя работи API. API си комуникира с документооборотните системи

от СЕОС и със ССЕВ по протокол, описан във формат swagger-json. Комуникацията с бек-енд се извършва посредством WebSocket протокол, който предлага full-duplex комуникационен канал върху една единствена TCP конекция.

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

Фронд-енд и мидълуер слоевете се осигуряват от виртуална машина с инсталирани Debian 9, Nginx, SQlite, Python3.6 с python3-pip и virtualenv, Rabbitmq.

Бек-енд слоя е осигурен от виртуална машина с инсталиран Symantec Content Analysis System с модули Security Analytics и Malware Analytics, и използване на антивирусни машини (софтуери) на Kaspersky и Sophos.

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

на входа на СЕОС – ако подателя и/или получателя са интегрирали деловодните си системи със САИАЕД;

на изхода на СЕОС – ако само получателя е интегрирал деловодната си система със САИАЕД;

нито на входа, нито на изхода на СЕОС – ако подателя и получателя не са интегрирали деловодните си системи със САИАЕД;

САИАЕД е интегриран със ССЕВ и автоматизирана инспекция и анализ на електронните документи за наличието на злонамерен софтуер става на входа, при подаване на документите.

5. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕ НА ПОРЪЧКАТА

5.1. Общи изисквания към изпълнението на обществената поръчка

Обществената поръчка за „Надграждане на системата за автоматизирана инспекция и анализ на електронни документи, обменяни в рамките на системите за електронен обмен на съобщения и за сигурно електронно връчване, доставка на софтуерни лицензи и техническа поддръжка“ се финансира от бюджета на ДАЕУ.

Кандидатите за изпълнител трябва да представят в своите предложения Идеен проект за изграждането на САИАЕД. Предложенията трябва да съдържат техническо описание на предлаганата реализация. Предлаганите технологии трябва да са

14 / 34

съвместими с приложените технологи, описани в т. 4 Текущо състояние на настоящата техническа спецификация. Идейният проект трябва като минимум да съдържа:

концепция за надграждане на САИАЕД на базата на техническото задание; предложение на дизайн на информационната система, хардуерната и

комуникационната инфраструктура - описание на предлагното техническото оборудване и/или софтуерни продукти, ролята на предложения хардуер и/или софтуер с приложен подробен списък с използваните компоненти и лицензи (каталожен номер, описание, количество);

предложение на архитектура и спецификация на софтуерните изисквания към трите слоя на САИАЕД;

описание и последователност на технически и/или технологични и/или организационни дейности, които ще доведат до практическото реализиране на изискуемите параметри на САИАЕД;

план-график за изпълнение на поръчката; предложение и обосновка за разширение на системата в два варианта:o разширение на системата със 100 потребителя с лицензирани два

независими антивирусни софтуера (Anti-virus Engines) и с включени поведенчески анализ на файловете (Behavior Analysis) и предвиждащ анализ (Predictive Analysis);

o чрез използване на специализиран хардуер за разширение на бек-енд компонента на системата със следните характеристики:- стандартни мрежови интерфейси:

= (2) 1000Base-T Copper Ports (with bypass)= 1000Base-T Copper Ports (ICAP)= 1000Base-T Copper, System Management Port= 1000Base-T Copper, BMC Management Port

- възможност за използване на следните мрежови интерфейси:= 4x10/100/1000Base-T (Copper with bypass capability)= 4x1GbE Fiber-SR (with bypass capability, full height slot only)= 2x10Gb Base-T (Copper with bypass capability)= 2x10Gb Base-T (Copper non-bypass)= 2x10Gb Fiber (SR with bypass capability)= 2x10Gb Fiber (LR with bypass capability)

- комуникационен капацитет – не по-малко от 100 mbps с едновременно активирани AV и Sandbox функции;

- обработка на 6000 заявки (инспекции) на ден с едновременно активирани AV и Sandbox функции;

- хардуер с резервирано/двойно захранване от типа (Dual redundant and hot swappable power supplies).

В ценовото си предложение Изпълнителят следва да представи: обща цена и ценово предложение за изпълнение на дейности:o „Анализ и проектиране“;o „Разработване и внедряване“;o „Разширена гаранционна поддръжка“.

ценово предложение за разширение на системата със 100 потребителя с лицензиране за 3 години;

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

дейността на ДАЕУ и електронното управление в Република България.

5.2. Общи организационни принципи

Изисквания към участника:

15 / 34

участникът трябва да притежава и прилага сертифицирана система за управление на сигурността на информацията, съответстваща на стандарт ISO/IEC 27001 или еквивалент, с обхват приложим към предмета на поръчката. Сертификатът трябва да е валиден и да е издаден от независими лица, които са акредитирани по съответната серия европейски стандарти от Изпълнителна агенция „Българска служба за акредитация“ или от друг национален или европейски орган по акредитация, който е страна по Многостранното споразумение за взаимно признаване на Европейската организация за акредитация, за съответната област или да отговарят на изискванията за признаване съгласно чл. 5а, ал. 2 от Закона за националната акредитация на органи за оценяване на съответствието. Възложителят приема еквивалентни сертификати, издадени от органи, установени в други държави членки. Когато участникът не е имал достъп до такъв сертификат или е нямал възможност да го получи в съответните срокове по независещи от него причини, той може да представи други доказателства за еквивалентни мерки за осигуряване на система за управление на качеството. В тези случаи участникът трябва да е в състояние да докаже, че предлаганите мерки са еквивалентни на изискваните.

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

Място на изпълнение: дейностите по настоящата спецификация ще се изпълняват на територията на

Република България, в помещения на ДАЕУ; обучението ще се проведе в гр. София, в помещение, осигурено от ДАЕУ; материалите, резултат от изпълнението, ще се предават на адреса на ДАЕУ.Участникът следва да разпише подробно в своето предложение начините за

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

Участникът трябва да опише в своето техническо предложение: система за осигуряване на качеството и контрол – всички етапи, роли и

компоненти за осигуряване и контрол на качеството; процедури за осигуряване на качеството и контрол – описание на основните

процеси и стъпки по осигуряване на качеството и контрола; процедура за управление на промените, с която да се регламентира начинът, по

който ще бъдат подавани евентуални искания за промяна.

5.3. Управление на проекта

Участникът трябва да представи в своите предложения концепция за изпълнение на поръчката, включваща описание на избраната методология за управление на проекти (напр. PRINCE2, PMBOK, Six Sigma или еквивалентна). Участникът следва да опише предлаганата от него методология за управление на проекта, която да се базира на утвърдени стандарти и добри практики. Под управление на проекта следва да се разбират процесите по планиране и контрол на обхванатите от проекта дейности и ресурси, необходими за реализация му. Участникът трябва да опише:

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

етапи на проекта и основни дейности, характерни за всяка фаза;

16 / 34

примерен комуникационен план, с който да покаже по какъв начин с какви средства и с каква регулярност се планират комуникациите с възложителя;

ползите от прилагането на методологията за управление на проекти в контекста на настоящата поръчка;

начините за управление на качеството, съгласно точка 5.2 от настоящата техническа спецификация;

управление на риска, съгласно точка 5.4 от настоящата техническа спецификация.

5.4. Управление на риска

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

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

недостатъчна експертна подкрепа, съдействие и ангажираност от страна на екипа на Възложителя;

липса на информация или недостатъчна информация, необходима за изпълнение на задачите в рамките на поръчката;

неправилно и неефективно разпределяне на ресурсите и отговорностите при изпълнението на договора;

липса на сътрудничество между Възложител и Изпълнител; различни цели и очаквания на заинтересованите лица; промени в изискванията/обхвата по време на изпълнение на поръчката; изменения в нормативната уредба, които могат да предизвикат промяна в

обхвата на планирани действия или да наложат ограничителни мерки.

6. ЕТАПИ НА ИЗПЪЛНЕНИЕ НА ПРОЕКТА

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

6.1. Анализ, проектиране, разработване и внедряване

Необходимо е всички описани по-долу дейности да бъдат изпълнени в срок до 90 дни (3 месеца), считано от датата на подписване на договор с Изпълнителя.

6.1.1. Анализ и проектиране

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

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

17 / 34

както и последователността от технически и/или технологични и/или организационни дейности, които ще доведат до практическото реализиране на изискуемите параметри на САИАЕД. Спецификацията е отделно обособена, неразделна част от техническият проект. В нея подробно са описани компонентите (елементите) на системата. В спецификацията се съдържа като минимум следната информация: наименование (производител, серия и модел, каталожен номер), технически параметри, количество, единична цена без ДДС и др. Изготвянето на техническия проект включва следните основни задачи:

определяне на концепция на САИАЕД на базата на техническото задание; дефиниране на детайлни изисквания и бизнес процеси, които трябва да се

реализират в САИАЕД; дизайн на информационната система, хардуерната и комуникационната

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

забележки, корекции или допълнения от страна на Възложителя, Изпълнителят е длъжен да ги отрази в техническия проект в срок не по-късно от 5 работни дни. Възможни са до две итерации за корекции на техническия проект. При неодобрение на техническият проект от страна на Възложителя, договорът се прекратява.

6.1.2. Разработване и внедряване

По време на дейността Изпълнителят разработва План за разработване и внедряване в който се включва:

детайлен план за надграждане на САИАЕД в КИИ на ДАЕУ; план и процедури за провеждане на тестове за функционалност и

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

САИАЕД. Ще се проверят функционалните възможности на тестовата САИАЕД след интеграцията ѝ с до три документооборотни системи от СЕОС и със ССЕВ. Ще се тестват сценарии и политики за автоматизирана инспекция и анализ на електронни документи, и ще се проверят проектираните механизми за отказоустойчивост.

След успешно приключване на тестовете Изпълнителят ще извърши доставка, монтаж, инсталиране и конфигуриране на продукционните компонентите на САИАЕД и ще се предостави интерфейс за интеграцията на САИАЕД с документооборотните системи от СЕОС и ССЕВ. Ще се заложат конкретни политики за автоматизирана инспекция и анализ на електронни документи. Ще се извърши обучение на служители на възложителя за работа и администриране на САИАЕД.

Внедряването ще завърши с провеждане на тестове на продукционните компонентите на САИАЕД.

Необходимо е всички описани по-горе долу дейности да бъдат изпълнени в срок до 90 дни (3 месеца), считано от датата на подписване на договор с Изпълнителя.

6.2. Гаранционна поддръжка

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

При необходимост, по време на гаранционния период трябва да бъдат осъществявани дейности по осигуряване на експлоатационната годност на софтуера и

18 / 34

ефективното му използване от Възложителя, в случай че настъпят явни отклонения от нормалните експлоатационни характеристики, заложени в системния проект.

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

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

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

правилното функциониране на системите и модулите; съдействие при опериране на системата за осигуряване на нормалната ѝ

работоспособност; възстановяването на системата и данните при срив; консултации за разрешаване на проблеми по предложената от Изпълнителя

конфигурация на средата (операционна система, база данни, хардуер и мрежи), използвана от системата, включително промени в конфигурацията на софтуерната инфраструктура на мястото на инсталация;

експертни консултации по телефон и електронна поща; доразвиване на съществуващите функционалности на фронт-енд и мидълуер

компонентите на САИАЕД, включително ъпдейт и ъпгрейд на използваните софтуери и корекции в приложния код с цел надеждното функциониране на СЕОС и ССЕВ;

инсталиране и конфигуриране на допълнителни модули и/или устройства и/или лицензи за разширяване на капацитета;

надграждане на системата при излизане на нови версии на софтуера, включително и системния, и/или при надграждане на СЕОС и ССЕВ;

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

Забележка: на този етап по всяко време Възложителят може да поиска увеличение на потребителите на САИАЕД и/или хардуерно разширение на бек-енд компонента на системата.

7. ОБЩИ ИЗИСКВАНИЯ ЗА ИНФОРМАЦИОННИ СИСТЕМИ В ДЪРЖАВНАТА АДМИНИСТРАЦИЯ

7.1. Функционални изисквания към информационната система

7.1.1. Интеграция с външни информационни системи

За реализиране на функционалностите Системата за автоматизирана инспекция и анализ на електронни документи трябва да поддържа интеграция в реално време с информационни системи и приложения както следва:

СЕОС: във фронт-енд слоя на САИАЕД ще се получават файлове и съдържание от Документно-оборотни системи, част от СЕОС, в рамките на държавната администрация, през HTTP протокол (swagger.jason изходна спецификация).

ССЕВ: във фронт-енд слоя на САИАЕД ще се получават файлове и съдържание от ССЕВ, през HTTP протокол (swagger.jason изходна спецификация).

7.1.2. Интеграционен слой

19 / 34

Вътрешен интерфейс: WebSocket спецификация на API интерфейса на бек-енд слой на САИАЕД. Използва се за интеграция между междинен интеграционен слой (мидълуеър) и бек-енд слой за същинска обработка на данни от САИАЕД.

Външен интерфейс: този интерфейс е нужен, за да се обслужат HTTP заявките, подадени според swagger.jason изходна спецификация –това е спецификация на параметрите, подавани от СЕОС и ССЕВ към фронд-енд слой на САИАЕД.

7.1.3. Технически изисквания към интерфейсите

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

Вътрешен интерфейс: WebSocket спецификация на API интерфейс на бек-енд слой:o Референцияo API Guide for Content Analysis and Malware Analysiso CA Version 2.3

Външен интерфейс: Swagger.jason спецификация на API интерфейс на фронт-енд слой:o Референцияo Openapi.jason

7.1.4. Електронна идентификация на потребителите

Електронната идентификация се реализира на база механизмите, заложени в СЕОС. Към момента механизмите на СЕОС изискват използване на нарочни сертификати за идентификация.

7.1.5. Формиране на изгледи

Няма изисквания.

7.1.6. Отворени данни

Няма изисквания.

7.1.7. Администриране на системата

Според наличните механизми заложени в отделните компоненти. Като минимум CLI, SSH и/или GUI.

7.2. Нефункционални изисквания към информационната система

7.2.1. Авторски права и изходен код

Фронт-енд:

7.2.1.1. Фронт-енд

Всички компютърни програми, които се разработват за нуждите на фронт-енд копонента, трябва да отговарят на критериите и изискванията за софтуер с отворен код;

Всички авторски и сродни права върху произведения, обект на закрила на Закона за авторското право и сродните му права, включително, но не само, компютърните програми, техният изходен програмен код, структурата и дизайнът на интерфейсите и базите данни, чието разработване е включено в предмета на поръчката, възникват за Възложителя в пълен обем без ограничения в използването, изменението и разпространението им и представляват произведения, създадени по поръчка на Възложителя съгласно чл. 42, ал. 1 от Закона за авторското право и сродните му права;

Приложимите и допустими лицензи за софтуер с отворен код са:o NGNIX

7.2.1.2. Мидълуер

20 / 34

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

Всички авторски и сродни права върху произведения, обект на закрила на Закона за авторското право и сродните му права, включително, но не само, компютърните програми, техният изходен програмен код, структурата и дизайнът на интерфейсите и базите данни, чието разработване е включено в предмета на поръчката, възникват за Възложителя в пълен обем без ограничения в използването, изменението и разпространението им и представляват произведения, създадени по поръчка на Възложителя съгласно чл. 42, ал. 1 от Закона за авторското право и сродните му права;

приложимите и допустими лицензи за софтуер с отворен код са:o GPL (General Public License) 3.0;o LGPL (Lesser General Public License);o AGPL (Affero General Public License);o Apache License 2.0;o New BSD license;o MIT License;o Mozilla Public License 2.0o EUPL

изходният код (Source Code), разработван по проекта, както и цялата техническа документация трябва да бъдат публично достъпни онлайн като софтуер с отворен код от първия ден на разработка чрез използване на система за контрол на версиите и хранилището по чл. 7в, т.18 от ЗЕУ;

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

7.2.2. Системна и приложна архитектура

7.2.2.1. Надграждане на съществуващата САИАЕД

Необходимо е изпълнителят да надгради съществуващата САИАЕД като осигури нужните механизми за балансиране на трафика към няколко резервирани системи за автоматизирана инспекция и анализ на електронни документи или техни резервирани бек-енд компоненти в зависимост от предложения проект на решението. Изпълнителят е необходимо да осигури минимало изискуемите за решението функционални параметри и изискваните капацитети.

7.2.2.2. Общи изисквания за използваемост и достъпност

автоматизирана инспекция и анализ на електронни документи за наличие на злонамерен софтуер, включваща:o два независими антивирусни софтуера (Anti-virus Engines);o поведенчески анализ на файловете (Behavior Analysis);o предвиждащ анализ (Predictive Analysis);

интегрирана изолирана среда (Sandbox) за автоматизирано стартиране и анализ на съмнителни и/или непознати приложения с цел идентификация на непознати до момента нови заплахи;

работата на 1000 потребителя (СЕВ или документооборотна система от СЕОС), с възможност за надграждането ѝ до 1500;

автоматизирана инспекция и анализ на до 6000 документа на ден, в интегрирана изолирана среда (Sandbox), всеки от тях с размер 10 MB, с възможност за надграждането ѝ до 50000 документа на ден, всеки от тях с размер 50 MB;

21 / 34

Подаването на документи за инспекция и анализ от системите в СЕОС и ССЕВ към САИАЕД следва да се реализира според swagger.jason спецификацията на фронт-енд слоя на САИАЕД.

Подаването на документи за инспекция и анализ в САИАЕД към бек-енд компонентите на системата следва да се реализира според WebSocket спецификацията на бек-енд слоя на САИАЕД.

Времето за инспекция и анализ на съдържанието, след постъпването му в САИАЕД, не следва да да надвишава следните параметри:

време за автоматизирана инспекция и анализ на електронни документи за наличие на злонамерен софтуер - до 5 секунди за документи с големина до 10MB във формат текст (*.doc, *.docx, *.rtf, *.odt, *.pdf), електронна таблица (*.xls, *.xlsx, *.ods), изображения (*.jpg, *.jpeg, *.png, *.tif) и Microsoft Outlook (*.eml), считано от момента на постъпване на целия документ в САИАЕД;

време за автоматизирано стартиране и анализ на съмнителни и/или непознати приложения в интегрирана изолирана среда (Sandbox) - до 30 секунди за документи с големина до 10MB във формат текст (*.doc, *.docx, *.rtf, *.odt, *.pdf), електронна таблица (*.xls, *.xlsx, *.ods), изображения (*.jpg, *.jpeg, *.png, *.tif) и Microsoft Outlook (*.eml), считано от момента на постъпване на целия документ в САИАЕД;

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

7.2.2.3. Осигуряване на техническа поддръжка на САИАЕД

Изпълнителят е необходимо да осигури техническа поддръжка на така надградената САИАЕД за срок от 36 месеца и да обезпачи работата на доставените хардуер и софтуер с лицензи за поддръжка от техните производители за срок от 3 /три/ години.

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

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

Архитектурата на всички софтуерни компоненти (системни и приложни) трябва да бъдат така подбрани и/или разработени, че да осигуряват работоспособност и отказоустойчивост като единно цяло, както и недискриминационно инсталиране (без различни условия за инсталиране върху физическа и виртуална среда) и опериране в продуктивен режим, върху виртуална инфраструктура, съответно върху Държавния хибриден частен облак;

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

7.2.3. Повторно използване (преизползване) на ресурси и готови разработки

Проектът следва максимално да преизползва налични публично достъпни инструменти, библиотеки и платформи с отворен код.

22 / 34

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

7.2.4. Подход за работа с външните софтуерни ресурси

До изграждането на хранилището на изходен код в ДАЕУ, изпълнителите по договори за изграждане и надграждане на софтуер да използват съответното хранилище в общото хранилище за проекти с отворен код, финансирани с публични средства в България (към момента https://github.com/governmentbg). Използващите свободните библиотеки компоненти задават за "upstream repo" хранилищата в областта governmentbg, като задължително се реферира използваната версия/commit identificator.

Изпълнителят трябва да извърши необходимите действия за включване на направените промени в основния проект чрез "pull requests" и извършване на необходимите изисквани от разработчиците на основния проект промени до приемането им. Тези дейности трябва да бъдат извършвани по време на целия проект.

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

7.2.5. Изграждане и поддръжка на множество среди

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

Среда ОписаниеПродукционна Среда, която е достъпна за реална експлоатация и интеграция със

съответните външни системи и услуги.Тестова Среда, достъпна за използване и извършване на интеграционни

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

7.2.6. Процес на разработка, тестване и разгръщане

За всеки един разработван компонент Изпълнителят трябва да покрие следните изисквания за гарантиране на качеството на извършваната разработка и на крайния продукт:

Документиране на Системата в изходния код, минимум на ниво процедура/функция/клас;

Покритие на минимум 50% от изходния код с функционални тестове [в случай на надграждане на съществуваща система – 50% от новата функционалност и 20% от съществуващата];

Използване на continuous integration практики; Използване на dependency management.Участникът трябва да опише детайлно подхода си за покриване на изискванията.Във всеки един компонент на Системата, който се build-ва и подготвя за

инсталация (deployment), е необходимо да присъстват следните реквизити: Дата и час на build; Място/среда на build; Потребител извършил/стартирал build процеса; Идентификатор на ревизията от кодовото хранилище на компонента, срещу

която се извършва build-ът.

7.2.7. Бързодействие и мащабируемост

23 / 34

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

При поискване от страна на Възложителя САИАЕД следва да може да се разширява в два варианта:

разширение на системата със 100 потребителя с лицензирани два независими антивирусни софтуера (Anti-virus Engines); поведенчески анализ на файловете (Behavior Analysis); предвиждащ анализ (Predictive Analysis);

чрез използване на специализиран хардуер за разширение на бек-енд компонента на системата със следните характеристики:o комуникационен капацитет – не по-малко от 100 mbps с едновременно

активирани AV и Sandbox функции;o обработка на 6000 заявки (инспекции) на ден с едновременно активирани AV

и Sandbox функции;o хардуер с резервирано/двойно захранване от типа (Dual redundant and hot

swappable power supplies);Посредством интегрираните резервирани балансиращи компоненти и така

реализираните разширения, САИАЕД следва да може да работи като едно цяло с цел осигуряване на изискванията за мащабируемост.

Времето за инспекция и анализ на съдържанието, след постъпването му в САИАЕД, не следва да да надвишава следните параметри:

време за автоматизирана инспекция и анализ на електронни документи за наличие на злонамерен софтуер - до 5 секунди за документи с големина до 10MB във формат текст (*.doc, *.docx, *.rtf, *.odt, *.pdf), електронна таблица (*.xls, *.xlsx, *.ods), изображения (*.jpg, *.jpeg, *.png, *.tif) и Microsoft Outlook (*.eml), считано от момента на постъпване на целия документ в САИАЕД;

време за автоматизирано стартиране и анализ на съмнителни и/или непознати приложения в интегрирана изолирана среда (Sandbox) - до 30 секунди за документи с големина до 10MB във формат текст (*.doc, *.docx, *.rtf, *.odt, *.pdf), електронна таблица (*.xls, *.xlsx, *.ods), изображения (*.jpg, *.jpeg, *.png, *.tif) и Microsoft Outlook (*.eml), считано от момента на постъпване на целия документ в САИАЕД.

7.2.8. Информационна сигурност и интегритет на данните

Не се допуска съхранението на пароли на администратори, на вътрешни и външни потребители и на акаунти за достъп на системи (ако такива се използват) в явен вид. Всички пароли трябва да бъдат защитени с подходящи сигурни алгоритми (напр. BCrypt, PBKDF2, scrypt (RFC 7914) за съхранение на пароли и където е възможно, да се използва и прозрачно криптиране на данните в СУБД със сертификати (transparent data-at-rest encryption).

Да бъде предвидена система за резервни копия на данните, които да се съхраняват извън инфраструктурата на системата.

Всички уебстраници (вътрешни и публично достъпни в Интернет) трябва да бъдат достъпни единствено и само през протокол HTTPS. Криптирането трябва да се базира на сигурен сертификат с валидирана идентичност (Verified Identity), позволяващ задължително прилагане на TLS 1.2, който е издаден от удостоверителен орган, разпознаван от най-често използваните браузъри (Microsoft Internet Explorer, Google Chorme, Mozilla Firefox). Ежегодното преиздаване и подновяване на сертификата трябва да бъде включено като разходи и дейности в гаранционната поддръжка за целия срок на поддръжката.

Трябва да бъдат извършени тестове за сигурност на всички уебстраници, като минимум чрез автоматизираните средства на SSL Labs за изпитване на сървърна сигурност (https://www.ssllabs.com/ssltest/).

24 / 34

При разгръщането на всички уеб услуги (Web Services) трябва да се използва единствено протокол HTTPS със задължително прилагане на минимум TLS 1.2.

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

При проектирането и разработката на уеб приложенията и интерфейсите и при подготовката и разгръщането на средите трябва да се спазват последните актуални препоръки на OWASP (Open Web Application Security Project).

Астрономическото време за удостоверяване настъпването на факти с правно или техническо значение се отчита с точност до година, дата, час, минута, секунда и при технологична необходимост - милисекунда, изписани в съответствие със стандарта БДС ISO 8601:2006.

Астрономическото време за удостоверяване настъпването на факти с правно значение и на такива, за които се изисква противопоставимост, трябва да бъде удостоверявано с електронен времеви печат по смисъла на Глава III, Раздел 6 от Регламент ЕС 910/2014. Трябва да бъде реализирана функционалност за получаване на точно астрономическо време, отговарящо на горните условия, и от доставчик на доверителни услуги или от държавен орган, осигуряващ такава услуга, отговаряща на изискванията на RFC 3161.

Трябва да бъдат проведени тестове за проникване (penetration tests), с които да се идентифицират и коригират слаби места в сигурността.

7.2.9. Използваемост

7.2.9.1. Общи изисквания за използваемост и достъпност

При проектирането и разработката на софтуерните компоненти и потребителските интерфейси трябва да се спазват стандартите за достъпност на потребителския интерфейс за хора с увреждания WCAG 2.0, съответстващ на ISO/IEC 40500:2012;

Всички ресурси трябва да са достъпни чрез GET заявка на уникален адрес (URL). Не се допуска използване на POST за достигане при генериране на справка и други;

Функционалностите на потребителския интерфейс на Системата трябва да бъдат независими от използваните от потребителите интернет браузъри и устройства, при условие че последните са версии в период на поддръжка от съответните производители. Трябва да бъде осигурена възможност за ползване на публичните модули на приложимите услуги през мобилни устройства – таблети и смарт-телефони, чрез оптимизация на потребителските интерфейси за мобилни устройства (Responsive Design);

Не се допуска използване на капча (Captcha) като механизъм за ограничаване на достъпа до документи и/или услуги. Допуска се използването на Captcha единствено при иденетифицирани много последователни опити от предполагаем „бот“;

Публично достъпната информация, касаеща структурирани данни през уеб портал трябва да бъдат проектирана и оптимизирана за ефективно и бързо индексиране от търсещи машини с цел популяризиране сред потребителите и по-добра откриваемост при търсене по ключови думи и фрази. При разработката на Уеб приложенията и при изготвяне на автоматизираните процедури за разгръщане на нова версия на АИС на инвентаризация на ИКИ ресурсите трябва да се използват инструменти за минимизиране и оптимизация на размера на изходния код (HTML, JavaScript и пр.) с оглед намаляване обема на файловете и по-бързо зареждане на страниците;

Не се допуска използването на HTML Frames, за да не се пречи на оптимизациите за търсещи машини.

При разработката на публични уеб базирани страници трябва да се използват и да се реализира поддръжка на:

25 / 34

Стандартните семантични елементи на HTML5 (HTML Semantic Elements); JSON-LD 1.0 (http://www.w3.org/TR/json-ld/); Open Graph Protocol (http://ogp.me) за осигуряване на поддръжка за качествено

споделяне на ресурси в социални мрежи и мобилни приложения;В екранните форми на уеб приложенията трябва да се използват потребителски

бутони с унифициран размер и лесни за разбиране текстове в еднакъв стил.Всички текстови елементи от потребителския интерфейс трябва да бъдат

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

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

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

Всички търсения трябва да са нечувствителни към малки и главни букви.Полетата за пароли трябва задължително да различават малки и главни букви.Полетата за потребителски имена трябва да позволяват използване на имейл

адреси като потребителско име, включително да допускат всички символи, регламентирани в RFC 1123, за наименуването на хостове;

Главните и малките букви на въвежданите данни се запазват непроменени, не се допуска Приложението да променя капитализацията на данните, въвеждани от потребителите.

Уеб приложението трябва да позволява въвеждане на данни, съдържащи както на български език, така и английски език.

Наименованията на полетата следва да са достатъчно описателни, като максимално се доближават до характера на съдържащите се в тях данни.

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

Дългите списъци с резултати трябва да се разделят на номерирани страници с подходящи навигационни елементи за преминаване към предишна, следваща, първа и последна страница, към конкретна страница. Навигационните елементи трябва да са логически обособени и свързани със съответния списък и да се визуализират в началото и в края на HTML контейнера, съдържащ списъка;

За големите йерархически категоризации трябва да се предвиди възможност за навигация по нива или чрез отложено зареждане (lazy load).

7.2.9.2. Интернационализация

Приложението трябва да може да съхранява и едновременно да визуализира данни и съдържание, което е въведено/генерирано на различни езици;

Всички софтуерни приложения и използваните софтуерни библиотеки и развойни комплекти, приложните сървъри и сървърите за управление на бази данни, елементите от потребителския интерфейс, програмно-приложните интерфейси, уебуслугите и др. трябва да поддържат стандартно и да са конфигурирани изрично за спазване на минимум Unicode 5.2 стандарт при съхранението и обработката на текстови данни, съответно трябва да се използва само UTF-8 кодиране на текстовите данни.

26 / 34

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

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

Версиите на съдържанието на съответните езици трябва да включват всички текстове, които се визуализират във всички елементи на потребителския интерфейс, справките, генерираните от системата електронни документи, съобщения, нотификации, имейл съобщения, номенклатурите и таксономиите и др. Данните, които се съхраняват в приложението само на български език, се изписват/визуализират на български език;

При визуализация на числа трябва да се използва разделител за хиляди (интервал).

При визуализация на дати и точно време в елементи от потребителския интерфейс в генерирани справки или в електронни документи всички формати за дата и час трябва да са съобразени с избрания от потребителя език/локация в настройките на неговия профил:

За България стандартният формат е „DD.MM.YYYY HH:MM:SS”, като наличието на време към датата е в зависимост от вида на визуализираната информация и бизнес-смисъла от показването на точно време;

Приложението трябва да поддържа и всички формати съгласно ISO БДС 8601:2006;

7.2.9.3. Изисквания за използваемост на потребителския интерфейс

При надграждането на САИАЕД трябва да се гарантира, че въведените, валидираните и запазените от сървъра данни остават достъпни за потребителите дори за процеси, които не са приключили, така че при волно, неволно или автоматично прекъсване на потребителската сесия поради изтичане на периода за допустима липса на активност потребителят да може да продължи съответния процес след повторно влизане в системата, без да загуби въведените до момента данни и прикачените до момента електронни документи;

Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на приложението, без да са необходими промени в изходния код, на контекстна помощна информация за:

всяка електронна форма или стъпка от процес, за която има отделен екран/форма;

всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично);

всяко отделно поле за въвеждане на данни;Трябва да бъде разработена контекстна помощна информация за всички процеси,

екрани и електронни форми, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета;

Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и др. трябва да бъдат разработени като хипервръзки към съответните актуални версии на нормативни документи и/или към съответния речник/списък с акроними и термини;

Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин чрез подходящи навигационни

27 / 34

елементи, като например чрез подходящо разположени микро-бутони с икони, разположени до/пред/след етикета на съответния елемент, за който се отнася контекстната помощ, или чрез обработка на "Mouse Hover/Mouse Over" събития;

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

7.2.9.4. Системен журнал

Изгражданото решение задължително трябва да осигурява проследимост на действията на всеки потребител (одит), както и версия на предишното състояние на данните, които той е променил в резултат на своите действия (системен журнал).

Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни:

дата/час на действието; модул на системата, в който се извършва действието; действие; обект, над който е извършено действието; допълнителна информация; IP адрес и браузър на потребителя.Размерът на журнала на потребителските действия нараства по време на работа на

всяка система, което налага по-различното му третиране от гледна точка на организация на базата данни:

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

специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално предвидена за целта база данни, отделна от работната база данни на приложението;

Данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва да бъде достъпна информация за не повече от 2 месеца назад; при необходимост от информация за предишен период администраторът на приложението трябва първо да възстанови архивните данни.

7.2.10. Дизайн на бази данни и взаимодействие с тях

При използване на база данни (релационна или нерелационна(NoSQL) следва да бъдат следвани добрите практики за дизайн и взаимоедйствие с базата данни, в т.ч.:

дизайнът на схемата на базата данни (ако има такава) трябва да бъде с максимално ниво на нормализация, освен ако това не би навредило сериозно на производителността;

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

имената на таблиците и колоните трябва да следват унифицирана конвенция; трябва да бъдат създадени индекси по определени колони, така че да се

оптимизират най-често използваните заявки; създаването на индекс трябва да е мотивирано и подкрепено със замервания;

връзките между таблици трябва да са дефинирани чрез foreign key; периодично трябва да бъде правен анализ на заявките, включително чрез

EXPLAIN (при SQL бази данни), и да бъдат предприети мерки за оптимизиране на бавните такива;

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

при операции върху много записи (batch) следва да се избягват дългопродължаващи транзакции;

28 / 34

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

и базата данни, трябва да се минимизира броят на излишните заявки (т.нар. n+1 selects проблем);

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

8. ИЗИСКВАНИЯ КЪМ ИЗПЪЛНЕНИЕТО НА ДЕЙНОСТИТЕ ПО ПРОЕКТА

8.1. Дейност „Анализ и проектиране“

8.1.1. Описание на дейността

Осъществява се анализ на съществуващия САИАЕД и интеграцията ѝ със СЕОС и ССЕВ. Целта на анализа е да се потвърдят наличните спецификации на изискванията за подаване на заявки и спецификацията на интеграцията на API.

Осъществява се анализ на конкретните текущи и бъдещи възможности и изисквания на обмена на електронни документи в рамките на СЕОС и ССЕВ с цел да се планира архитектурата и капацитета на САИАЕД.

В рамките на тази дейност ще се проектира архитектурата на САИАЕД за осигуряване на планирания капацитет, балансиране на заявките и отказоустойчивост. Ще се подготви подробна спецификация на САИАЕД и дизайн за внедряването ѝ. Предложеното решение трябва да притежава скалируема архитектура, което да позволява надграждане при нарастване на броя участници, броя едновременно инспектирани и анализирани документи и тяхната големина.

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

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

8.1.2. Изисквания към изпълнение на дейността

Докладът с анализ се изготвят и предоставят до 15 дни след подписване на договор. Техническият проект се представя в срок от 30 дни след подписването на договора. Техническият проект подлежи на одобрение от Възложителя. Наличието на одобрен Технически проект е задължително условие за стартиране на последващите дейности.

8.1.3. Очаквани резултати

изготвен доклад с анализ и с възможности за надграждане на САИАЕД който включва:o преглед на текущото състояниеo увеличаване на броя на участниците;o увеличаване на броя на инспектираните документи;o увеличаване на големина на инспектираните документи;o варианти и стъпки за надграждане и цена.

изготвен технически проект със спецификация който включва:o определяне на концепция за надграждане на САИАЕД на базата на

техническото задание;o дизайн на информационната система, хардуерната и комуникационната

инфраструктура;o архитектура и спецификация на софтуерните и хардуерните изисквания към

трите слоя на САИАЕД;o описание на API и описание на интерфейсите

29 / 34

o спецификация с включена количествено-стойностна сметка на лицензите и оборудването;

o дизайн за внедряването на САИЕД;o подробен списък на експлоатационна документация, която трябва да бъде

изготвена и предоставена на Възложителя.

8.2. Дейност „Разработване и внедряване“


В рамките на дейността ще се разработи подробен план за интеграция на САИАЕД в КИИ на ДАЕУ и въвеждането на системата в експлоатация. Ще се извършат дейности по програмиране за постигане на заложените функционални възможности.

Изпълнителя ще извърши доставка и в сътрудничество с Възложителя ще извърши монтаж, инсталиране и конфигуриране на компонентите на САИАЕД в КИИ на ДАЕУ с тестови лицензи и хардуер, базирани на изготвения технически проект в рамките на етап „Анлиз и проектиране“ . Ще се тества внедряване на САИАЕД в КИИ на ДАЕУ и интеграцията ѝ с до три документооборотни системи от СЕОС и със ССЕВ. Ще се тестват сценарии и политики за автоматизирана инспекция и анализ на електронни документи, ще се проверят проектираните механизми за отказоустойчивост.

След успешно приключване на тестовете Изпълнителят ще извърши доставка, монтаж, инсталиране и конфигуриране на продукционните компонентите на САИАЕД в КИИ на ДАЕУ, с използването на продукционни лицензи и ще се предостави интерфейс за интеграцията на САИАЕД с документооборотните системи от СЕОС и ССЕВ. Ще се заложат конкретни политики за автоматизирана инспекция и анализ на електронни документи.

В края на дейността Възложителят ще извърши приемни изпитания, включващи проверка и тестване на изградената система по отношение на основни технически и оперативни параметри. Приемните изпитания започват след писмо от Изпълнителя за готовност за провеждане им.

Изпълнителят трябва да разработи план и процедури за проверка и тестване, които ще се одобрят от Възложителя.

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

В рамките на тази дейност ще се извърши обучение на служители на ДАЕУ.Дейността приключва с подписването на приемо-предавателен протокол.


Дейността завършва не по-късно от 90 дни (3 месеца) след подписване на договора.

При приключване на дейността Изпълнителят трябва да е извършил и предоставил следното:

пълен програмен код на разработените в обхвата на поръчката софтуерни модули функционалности;

тестови случаи за приемни тестове на функционалности; документация за разработените в обхвата на поръчката модули и

функционалности:o ръководство за администратора

30 / 34

o описание на разработени модули и функционалности – в изпълним и инсталационен вид, вкл. инструкции за инсталация и скриптове(ако има такива)

o описание на изходния програмен код. доставени лицензи за софтуер и хардуер (в случай, че Изпълнителят е

предложил такъв); предоставяне на всички пароли за достъп; обучение за работа и администриране на надградената система.


разработен План за разработване и внедряване; проверка на концепцията за интеграцията на САИАЕД с до три

документооборотни системи от СЕОС и със ССЕВ и извършване на последваща интеграция след успешна проверка;

извършени доставка, монтаж и конфигурация на компонентите на САИАЕД в КИИ на ДАЕУ;

проведено обучение на не по-малко от 5 (пет) служителя на ДАЕУ; проведени приемни изпитания и подписан окончателен приемо-предавателен

протокол.

8.3. Дейност „Разширена гаранционна поддръжка“


В рамките на тази дейност ще се извършва поддръжка на САИАЕД, която включва:

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

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

правилното функциониране на системите и модулите; съдействие при опериране на системата за осигуряване на нормалната ѝ

работоспособност; възстановяването на системата и данните при срив; консултации за разрешаване на проблеми по предложената от Изпълнителя

конфигурация на средата (операционна система, база данни, хардуер и мрежи), използвана от системата, включително промени в конфигурацията на софтуерната инфраструктура на мястото на инсталация;

експертни консултации по телефон и електронна поща; доразвиване на съществуващите функционалности на фронт-енд и мидълуер

компонентите на САИАЕД, включително ъпдейт и ъпгрейд на използваните софтуери и корекции в приложния код с цел надеждното функциониране на СЕОС и ССЕВ;

инсталиране и конфигуриране на допълнителни модули и/или устройства и/или лицензи за разширяване на капацитета;

надграждане на системата при излизане на нови версии на софтуера, включително и системния, и/или при надграждане на СЕОС и ССЕВ;

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

По всяко време Възложителят може да поиска увеличение на потребителите на САИАЕД и/или хардуерно разширение на бек-енд на системата.

31 / 34


За осъществяване на дейността Изпълнителят трябва да организира и поддържа център за техническа поддръжка (helpdesk) с работно време – от 08.00 ч. до 18.00 ч. с осигурена точка за контакт с три канала за подаване на информация: телефон, електронна поща и система за сервизна поддръжка.

По време на изпълнение на дейността Изпълнителят трябва да осигури следните времена за обслужване:

време за реакция:o в работно време – до 2 часа;o в извън работно време – до 4 часа.

време за отстраняване на проблем:o в работно време – до 6 часа;o в извън работно време – до 10 часа.

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

Приоритетите на проблемите се определят от Възложителя. Редът на отстраняване на проблемите се определя в зависимост от техния приоритет.


Наличие на набор от услуги, осигуряващи работоспособността и поддръжката на надградената система.

8.4. Дейност „Разширение на системата с до 500 потребителя (със стъпка 100 потребителя)“


В рамките на дейността се доставят и инсталират допълнителен брой на лицензи, използвани от бек енд на системата в съотвествие с броя на потребителите на системата. Доставката включва осигуряване на лицензи на предложения софтуер с два независими антивирусни софтуера (Anti-virus Engines); поведенчески анализ на файловете (Behavior Analysis); предвиждащ анализ (Predictive Analysis).

Разширението се осъществява със стъпка 100 потребителя и с лицензиране с продължителност до датата на изтичане на разширената гаранционна поддръжка и не надвишаваща 3 години.


Дейността се изпълнява по заявка на възложителя през срока на разширената гаранционна поддръжка. Срокът за изпълнение на дейността е не повече от 30 (тридесет) календарни дни от датата на възлагане от страна на възложителя.

Цената за увеличаване на потребителите със 100 не може да надвишава цената, заложена в ценовото предложение на Изпълнителя и следва да е пропорционална на оставащото време до приключване на разширената гаранционна подръжка.


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

32 / 34

8.5. Дейност „Хардуерно разширение на бек енд на системата“ – по заявка на възложителя през срока на разширената гаранционна поддръжка, съгласно предложената от изпълнителя цена в ценовото му предложение.


В рамките на дейността се доставя, инсталира, тества и пуска в експлоатация специализиран хардуер за разширение на бек-енд компонента на системата със следните характеристики:

- стандартни мрежови интерфейси:=(2) 1000Base-T Copper Ports (with bypass)=1000Base-T Copper Ports (ICAP)=1000Base-T Copper, System Management Port=1000Base-T Copper, BMC Management Port- възможност за използване на следните мрежови интерфейси:=4x10/100/1000Base-T (Copper with bypass capability)=4x1GbE Fiber-SR (with bypass capability, full height slot only)=2x10Gb Base-T (Copper with bypass capability)=2x10Gb Base-T (Copper non-bypass)=2x10Gb Fiber (SR with bypass capability)=2x10Gb Fiber (LR with bypass capability) - комуникационен капацитет – не по-малко от 100 mbps с едновременно

активирани AV и Sandbox функции;- обработка на 6000 заявки (инспекции) на ден с едновременно активирани AV и

Sandbox функции;- хардуер с резервирано/двойно захранване от типа (Dual redundant and hot

swappable power supplies).


Дейността се изпълнява по заявка на възложителя през срока на разширената гаранционна поддръжка. Срокът за изпълнение на дейността е не повече от 45 (четиридесет и пет) календарни дни от датата на възлагане от страна на възложителя.

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


Система, работеща в рамките на зададените (подобрени) параметри.

Забележка: Възложителят не е длъжен да възложи изпълнението на дейности „Разширение на системата с до 500 потребителя (със стъпка 100 потребителя)“ и „Хардуерно разширение на бек енд на системата“ за срока на изпълнение на договора.

9. ДОКУМЕНТАЦИЯ

9.1. Изисквания към документацията

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

Всички документи трябва да бъдат предоставени от Изпълнителя в електронен формат (ODF/ /Office Open XML/MS Word DOC/RTF/PDF/HTML или др.), позволяващ пълнотекстово търсене/търсене по ключови думи и копиране на части от съдържанието от оригиналните документи във външни документи, за вътрешна употреба на възложителя.

33 / 34

Навсякъде, където в документацията има включени диаграми или графики, те трябва да бъдат вградени в документите в оригиналния си векторен формат.

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

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

9.2. Прозрачност и отчетност

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

9.3. Системен проект (технически проект)

Изпълнителят на настоящата поръчка изготвя технически проект със спецификация. Изискванията към изготвянето на техническия проект и неговото съдържание са дадени в т. 6.1.1. и т. 8.1.3.

9.4. Техническа документация

Всички продукти, които ще се доставят, трябва да са със специфична документация за инсталиране и/или техническа документация, в това число:

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

Детайлно описание на базата данни; Описание на софтуерните модули; Описание на изходния програмен код.

9.5. Протоколи

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

9.6. Комуникация и доклади

9.6.1. Встъпителен доклад

Изпълнителят изготвя доклад с анализ. Изискванията към изготвянето на доклада и неговото съдържание са дадени в т. 6.1.1. и т. 8.1.3.

9.6.2. Междинни доклади

Междинните доклади трябва да бъдат представяни и да се предават при приключване на всяка от дейностите и/или при настъпване на събитие. За изпълнението на дейностите се подписват двустранни приемо-предавателни протоколи.

Междинните доклади трябва да съдържат информация относно изпълнението на дейностите.Всеки междинен доклад следва да бъде одобрен от възложителя.

9.6.3. Окончателен доклад

В края на периода за изпълнение на договора трябва да се представи окончателен доклад. Окончателният доклад съдържа описание на изпълнението и резултати.

Докладите се изпращат до отговорния служител на Възложителя. За тази цел Възложителят ще определи в договора отговорния/отговорните служител/служители.

34 / 34

Всички доклади се представят на български език в електронен формат и на хартиен носител. Докладите се одобряват от отговорния/отговорните служител/служители в срок до 5 работни дни.

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

Възложителят разглежда представените доклади и уведомява Изпълнителя за приемането им без забележки или ги връща за преработване, допълване и/или окомплектоване, ако не отговарят на изискванията, като чрез упълномощено в договора лице дава указания и определя срок за отстраняване на констатираните недостатъци и пропуски.

9.6.4. Списък на документите, които задължително трябва да се представят в хода на изпълнение на Проекта

Име на документа По време на коя дейност се представят

Доклад с анализ „Анализ и проектиране“Технически проект със спецификация „Анализ и проектиране“План за разработване и внедряване „Разработване и внедряване“Документация за разработените в обхвата на поръчката модули и функционалности

„Разработване и внедряване“

Приемо-предавателни протоколи След приключване на дейностОкончателен приемно - предавателен протокол

След приключване на дейности „Анализ и проектиране“ и „Разработване и внедряване“

Обобщен рапорт на обслужените заявки - годишно

„Разширена гаранционна поддръжка“

10. РЕЗУЛТАТИ

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

Documents

%A2%D0%97-%D0... · Web viewВ момента документооборотните системи на държавната администрация обменят електронни