Техническа спецификация обща информация


Изграждане на National Public Key Directory (NPKD)



страница2/3
Дата03.04.2017
Размер360.73 Kb.
#18375
1   2   3

Изграждане на National Public Key Directory (NPKD)

  1. Изисквания към NPKD

    1. Да бъде изградена национална Директория за поддържане на публичните ключове - NPKD, която да съдържа всички български и чужди сертификати, списъците с невалидните сертификати (CRL) и основните списъци (masterlist), използвани при пасивната автентекация както и други списъци при необходимост.

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

    3. Да бъде изграден LDAP сървър за съхранение на сертификатите и списъците на анулирани сертификати (CRL). За работа с този сървър да се използва LDAP протокол - Lightweight Directory Access Protocol LDAP - v3 (RFC 2251), предоставящ възможност на директорийните услуги за представяне на данните. Да се изгради NPKD, като се определи подобна на ICAO-PKD спецификация за изпълнение.

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

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

          2. Organization (организация);

          3. Organizational Unit - организационна единица и обекти листа. Обектите листа са физически или логически мрежови ресурси. Поради това, че обектите листа са най-ниската част от йерархичната структура - те не могат да съдържат други обекти. Обекти от тип листа са: cn - за запис на DS и CRL;

          4. Общо наименование;

          5. Сериен номер.

Атрибутите са описани и специфицирани в RFC2256.

        1. За достъп до директорията да се използва LDAP протокол.

        2. За предаване на данни да се използва LDAPS протокол.

      1. Зареждане на NPKD

        1. Да се разработят програмни средства за зареждане на NPKD с български и чуждестранни сертификати, CRL и др. списъци, постъпващи от различни източници (от Country Signing Certification Authority - CSCA България, от ICAO Public Key Directory - PKD, от двустранни контакти, от работни групи)

        2. Да има възможност ръчно да се създава LDIF файл, използвайки данни от PKI.

        3. Да се поддържа синхронизация на данните за DSс и CRL издавани от CA, както и чуждите сертификати на други държави, изтеглени от ICAO PKD.

      2. Извличане и предоставяне на сертификатите и CRL от NPKD.

        1. Да бъде предоставена функционалност за извличане на сертификатите и CRL от NPKD и управление на процеса на предоставянето им за целите на АИС „ГК“. За тази функционалност да се предоставипрограмен интерфейс във вид на динамична програмна библиотека.

    1. Изграждане на SPOC

      1. Автоматизирано изпращане на заявки за издаване на DV-сертификати през SPOC на държавите-членки на ЕС;

      2. Автоматизирано получаване на заявки за издаване на DV-сертификати от SPOC на държавите-членки на ЕС;

      3. Уведомяване за получени заявки и обслужване на заявките чрез интерфейс за ръчно обслужване (приемане на заявката и връщане на съответния сертификат);

      4. Автоматизирана дистрибуция на DV - сертификати и вериги сертификати през SPOC на държавите-членки на ЕС;

      5. Автоматизирано приемане на DV - сертификати и вериги сертификати от SPOC на държавите - членки на ЕС;

      6. Автоматизирано инсталиране на приетите сертификати на DV;

      7. Автоматизирано приемане на искане за сертификати и вериги сертификати, необходими за EAC от SPOC на държавите-членки на ЕС;

      8. Автоматизирано изпращане на искане за сертификати и вериги сертификати необходими за EAC към SPOC на държавите-членки на ЕС и получаването им;

      9. Автоматизирано инсталиране на получените сертификати и вериги сертификати върху DV;

      10. Автоматизирано получаване на искане за сертификати и вериги сертификати необходими за EAC от SPOC на държавите-членки на ЕС и изпращането им към искащия SPOC.

SPOC да бъде изпълнен съгласно изискванията на ЕК - Решения на ЕК (С (2009) 7476(final), (C(2011) 5478final), европейски стандарт CSN 36 9791 и Общата сертификационна политика за EAC на държавите-членки на ЕС (COMMON CERTIFICATE POLICY FOR THE EXTENDED ACCESS CONTROL INFRASTRUCTURE FOR PASSPORTS AND TRAVEL DOCUMENTS ISSUED BY EU MEMBER STATES).

За осигуряване на сигурна връзка със SPOC на държавите-членка на ЕС да бъде създаден SPOC CA съгласно изискванията на ЕК - Решения на ЕК (С (2009) 7476 final), (C (2011) 5478 final), европейски стандарт CSN 36 9791 и съответстващ на Общата сертификационна политика за EAC на държавите-членки на ЕС (COMMON CERTIFICATE POLICY FOR THE EXTENDED ACCESS CONTROL INFRASTRUCTURE FOR PASSPORTS AND TRAVEL DOCUMENTS ISSUED BY EU MEMBER STATES).



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

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

      1. Off-line - интерфейс (използва се за ръчна обработка с операторска намеса); Да се използва при генериране на ключове и сертификати на CSCA и CVCA за сертифициране в PKI;

      2. Външни – интерфейси извън изградената PKI система. Тези интерфейси да бъдат автоматични и да се използват за връзка от и към други държави:

        1. NPKD – ICAO - LDAP – on-line, за получаване и изпращане на DSC и CRL през доверителен канал към базата на ICAO LDAP;

        2. NPKD – ICAO - LDIF – off-line, за ръчно изтегляне и записване (download/import) на DSC и CRL-(резервен ICAO-интерфейс), от ICAO-уеб страницата;

        3. SPOC - on-line, за обмен на DV-заявки за сертификати и DV-сертификати между държавите-членки на ЕС съгласно изискванията на ЕК.

        4. SPOC - off-line, за обмен на DV-заявки за сертификати и DV-сертификати между държавите-членки на ЕС съгласно изискванията на ЕК в случаи на технически проблеми за работа на SPOC - on-line.

      3. Интерфейс за връзка между NPKD и АИС „ГК”:

        1. Дистрибутиране сертификатите на CSCA, DSCs, CRLs изтеглени от ICAO до IS за граничен контрол;

      4. Интерфейс за връзка на CVCA и CSCA с NPKD, и DVCA „ГК” и SPOC - за предоставяне на сертификатите, издадени от Българската PKI за издаване на е-документи за пътуване

Да бъдат осигурени следните функционалности:

        1. За пакетна обработка на данни, свързани със заявки за издаване на сертификати и издадени сертификати;

        2. Да се получават и обработват заявки за DV сертификати от SPOC;

        3. Да събира DV заявки (действие на оператор);

        4. Да извършва трансфери (от оператор) DV заявки към CVCA (off-line трансфер);

        5. Оператор да извършва процеса по сертифициране от CVCA и да прави експорт на всички получени сертификати;

        6. Да извършва трансфер на DV сертификатите обратно към SPOC (off-line трансфер, също действие извършвано от оператор),

        7. SPOC автоматично да разпределя обработените заявки за сертификати на съответните заявители (on-line трансфер).

        8. Да управлява, разпространява и съхранява всички ICAO-PKD данни за страната, както и да ги зарежда в NPKD.

        9. Да дава възможност за доверително Trusted управление на сертификатите, идващи от ICAO-PKD и masterlists.

        10. Да бъде осигурено всичко необходимо за on-line връзка с ICAO LDAP, on-line връзка на SPOC с другите SPOC. Да работи като регистриращ орган за националното CVCA (поддръжане на приложения за всички необходими обработки за първоначалната регистрация на външните CSCA, CVCA и DV).

        11. Да бъдат осигурени следните функционалности за CS PKI:

          1. Да се използват автоматизирани процеси за записване на българските DS, CRL в NPKD и в ICAO - PKD чрез ICAO - LDAP;

          2. За изтегляне на чуждите сертификати на DS, CRL и основните списъци (masterlists) на CSCA от ICAO - LDAP;

          3. Неавтоматизирани CS процеси (Ръчна намеса от страна на оператор);

            1. Регистриране и импортиране на чуждестранни CSCA-сертификати;

            2. Изтегляне на чуждите DS, CRL, CSCA masterlist (резервно изтегляне чрез ICAO - LDIF от ICAO - PKD);

            3. Обработване на DS-група заявки;

            4. Импортиране на DS-група сертификати;

        12. Да бъдат осигурени следните функционалности за CV PKI:

          1. Автоматизирани CV процеси за IS-тип 1 на ГК. Издаване на CVCA сертификационна верига (заявка и нейната дистрибуция);

          2. Локални неавтоматизирани CV процеси (чрез ръчна намеса от страна на оператор);

            1. DV / CVCA регистриране;

            2. Заявка и издаване на DV - сертификат, подписан от CVCA;

            3. Изпращане на чуждестранните SPOC;

            4. Генериране на DV-група заявки за сертифициране от CVCA;

            5. Издаване на DV-групата сертификати;

            6. Да има осигурена възможност за изпращане на e-mail за уведомяване за издадените сертификати в отговор на чужди заявки;

    1. Разработване на програмни средства за работа със сертификати при изпълнение на EAC

      1. Да бъде разработен програмен интерфейс към АИС ГК, осигуряващ механизма за изпълнение на EAC за достъп до пръстовите отпечатъци, записани в чипа;

        1. Да бъде разработено приложение, което да не е WEB базирано, да работи с четец „3М“, използван в АИС „ГК”. Да се предоставят изходните кодове;

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

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

  1. Специфициране на техническите средства: комуникационни, сървъри, криптомодули, работни станции и др. с техните роли и функции.

    1. Централна компонента (сървъри, Hardware Security Modules – HSM и др.)

      1. За гарантиране на режим на работа 24х7 (двадесет и четири часа, седем дни в седмицата) с минимални прекъсвания (включително планирани) оборудването ще бъде разположено в Основен и Резервен център. Връзката между двата центъра е 100 Mbps TCP/IP.

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

        1. Да бъде предложена архитектура, която осигурява максимална надеждност в рамките на Основния център, включително автоматично рестартиране на виртуалните машини при спиране на един физически сървър (high availability) и преместването им без спиране върху друг физически сървър, и осигурява автоматизирано прехвърляне на работата в Резервния център за не повече от 30 минути след вземане на решение, включително преконфигуриране на репликацията на данни в правилната посока. Всички основни компоненти в Основния център да бъдат резервирани по начин, който да гарантира, че само фактори извън доставеното оборудване могат до доведат до необходимостта от прехвърляне на работата в Резервния център.

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

          1. Шест HSM в Основен (1 - за DVCA, 3 - за инспекционните системи и 2 - за SPOC и SPOC CA) и два HSM в Резервен център (1 - за DVCA, 1 - за инспекционна система);

          2. Два сървъра за виртуализация в Основен и един сървър за виртуализация в Резервен център;

          3. Два сървъра за SPOC в Основен център;

          4. Два LAN/SAN комутаторa в Основен и един LAN/SAN комутатор в Резервен център;

          5. Два LAN комутаторa в основен и един LAN комутатор в резервен център;

          6. По един дисков масив и в двата центъра;

          7. По едно диск-базирано архивиращо устройство за всеки център;

          8. Базов и системен софтуер, включително необходимите лицензи;

          9. HSM устройствата да бъдат сертифицирани съгласно задължителните международни стандарти за сигурност – FIPS 140-1 ниво 3 и ниво 4 за „Physical Security“, и/или по Common Criteria EAL4+ SOF – High. Да имат възможност за използване на RSA криптиращи алгоритми с дължина на ключа до 16 384 бита; DSA, ECDSA; AES, DES, Triple DES; Хеш алгоритми SHA-1, SHA-2 family, Diffie-Hellman и др. допълнителни алгоритми при поискване. Като производителност поне - 500 RSA подписа (1024 бита) на секунда, 2 500 ECDSA подписа (160 бита) на секунда, Triple DES криптиране 8 MByte/sec и 10 000 PIN операции на секунда;

          10. Виртуализационен клъстер – да осигури възможността за конфигуриране на виртуални машини на всички сървъри, които са минимум следните:

            1. NPKD - 2 сървъра в клъстер (за база данни съдържаща български и чужди сертификати, CRL);

            2. DVRA - 2 сървъра в клъстер (за регистрация на Инспекционни системи (IS от тип 1) и за обработка на постъпващите от тях заявки за издаване на сертификати);

            3. DVCA - 2 сървъра в клъстер (за издаване и управление на сертификатите на инспекционните системи– IS от тип 1);

            4. IS – 3 сървъра (инспекционните системи (тип 1));

        3. Тестова среда – 1 виртуализационен сървър;

    2. Сървърите и дисковите масиви да са включени в листата със съвместими устройства, публикувана от производителя на софтуера за виртуализация и в листата за съвместимост на Microsoft за Windows Server.

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

При използване на повече от един сървър за приложения, като неразделна част от предложението да бъде включено и решение за разпределение на натоварването (load-balancing) между тях. Хардуерът, който се предлага да е съвместим с наличния - посочен в т.3.2.



Виртуализационните сървъри да са минимум двупроцесорни сървъри с процесори 2 x E5-2650 или по-мощни (според SPECint_rate2006) с 48 GB RAM, или еквивалентни. Да се гарантира отговор в рамките на 1.2 sec при едновременна заявка (заявки, постъпили за период до 5 sec) от 50 крайни устройства, свързани към централната компонента на 256 kbps. Върху всички сървъри за виртуализация в Основен и Резервен център да бъде инсталирано и дисково пространство 6TB след RAID6, за да могат да бъдат използвани и за архивиране, развой и обучение без да се натоварват дисковите системи и мрежата за данни. Всички сървъри да бъдат оборудвани поне с четири Ethernet порта (2 LAN 1 Gbps, 2 LAN/SAN 10 Gbps) и да позволяват teaming/bonding. Всеки един сървър да позволява пълно отдалечено управление, включително графична конзола, медия и захранване. Сървърите да са с резервирани захранвания. Софтуерът за виртуализация да се зарежда от пространство, вътрешно за сървъра, различно от цитираните по-горе 6 TB. Всички дискове, захранвания, вентилатори да са заменяеми без изключване на захранването (hot-swap).

      1. Централните мрежови комутатори (ЦМК) от трето ниво се явяват ключови за производителността на разширението. Предназначението им е да осъществяват връзка между компонентите на разширението в Основния и между компонентите на разширението в Резервния център. Трафика за управление и трафика, генериран от и към крайните потребители, да бъдат изнесени в отделни комутатори. В случай че за срока на договора ЦМК не осигуряват достатъчна производителност и надеждност, Изпълнителят да подмени за своя сметка доставените комутатори с подходящи. За подсигуряване на стабилната работа на iSCSI е необходимо и поддръжка на FlowControl и 9K JumboFrames едновременно, UnicastStormControl, RapidSpanning Tree, VLAN support, Layer 3 dynamic routing, non-blockingdesign, поне 256 KB packet buffer per SAN port. С цел да се редуцират пътищата за многомаршрутност (Multipathing), те да позволяват конфигуриране в стек и bounding/teaming между портове на отделните елементи на стека. Комутаторите да са с резервирани захранвания. Отпадането на един комутатор не трябва да води до нарушаване на функционалността на разширението. Минималната конфигурация на LAN/SAN комутаторите да е 24x10 Gbps Ethernet-порта на комутатор. Комутаторите за управление и достъп да са с поне 24x1 Gbps Ethernet- порта на комутатор и да отговарят на описаните по-горе изисквания. Връзката между LAN/SAN комутаторите и комутаторите за достъп и управление да става по резервирана 10 Gbps линия.

      2. Дисковият масив да е оборудван с не по-малко от 10х300GB, 15 Krpm дискове. За осигуряване на необходимата надеждност, дисковият масив да разполага с поне два контролера, работещи в резервирана двойка и да предоставя поне по две 10Gbps Ethernet връзки на контролер с поддръжка на многомаршрутност (multipathing). Контролерите да поддържат поне RAID10, 5 и 6. Допустимо е дисковия масив да е базиран и на Fibre Channel 8Gbps или 16Gbps front-end връзки към сървърите, като Изпълнителят да осигури цялото необходимо допълнително оборудване. Дисковият масив да е с лицензи за реални и shadow копия на данните, лицензи за репликация, съвместими със софтуера за виртуализация и софтуера за автоматизирано превключване между Основен и Резервен център. Дисковата подсистема да поддържа поне 50 диска. Дисковият масив да е с резервирани захранвания и да гарантира, че при спиране на захранването няма да има загуба на данни, причинена от дисковия масив и че незаписаните данни ще бъдат пазени поне една седмица. Смяна на основни компоненти като захранвания и контролери не трябва да води до необходимост от спиране на системата.

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

      4. SPOC сървърите да са от същия модел като сървърите за виртуализация и да отговарят на същите изисквания, като процесорите да са 2 x Intel Xeon E5-2620, или еквивалент, 16 GB RAM, 4x 1 Gbps Ethernet порта, 1TB вътрешно дисково пространство след RAID.

    1. В Резервния център архитектурата да е аналогична, Дисковият масив, да е с капацитет не по-малко от 6 x 300 GB, 15 krpm и 6 x 3 TB. Да се осигури време на отговор не повече от 2.5 sec при едновременна заявка (заявки, постъпили за период до 5 sec) на 50 крайни устройства свързани към разширението на 256 kbps.

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

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

При конфигурирането на комутаторите да се използват VLANs за изолиране на трафика между SAN, LAN, хостовете и портовете, ангажирани с трафика между хостовете и мрежата за предаване на данни на МВР (МПД).

Да се предложи „План за преминаване от Основен към Резервен център и обратно“.

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


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

Софтуерната платформа да е напълно съвместима с посочения в 3.2. софтуер.

Софтуерната платформа да е последна версия към момента на изпълнение на проекта.

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

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



  1. Осигуряване на възможност за развитие на разширението.

  1. Разширението на системите за PKI да бъде изградено така, че в бъдеще да може да се използва и надгражда за:

    1. Други потребители в МВР;

    2. Други е-документи (лична карта, свидетелство за управление на моторно превозно средство, др.);

    3. SAC (Supplemental Access Control) - допълнителен контрол на достъпа за машинно четене на е-документи;

    4. PACE - (Password Authenticated Connection Establishment) - Изграждане на връзка с използването на парола.

  1. Административни процеси и дейности

Да бъдат изготвени документи, описващи следните процеси и дейности в разширението на PKI:

    1. Администриране на технологичните процеси;

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

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

    4. Генериране на ключове, извършване на криптографски операции (от HSMs), издаване на сертификати;

    5. Контрол за поддържане цялостта на записите на сертификатите в NPKD (осигуряване на консистентност на данните);

    6. Администриране на данните - архивиране / възстановяване;

    7. Администриране на ключове - архивиране / възстановяване;

    8. Контрол за правилното протичане на аварийни и възстановителни процедури;

    9. Управление на потребителите, които ще работят с разширението;

    10. Управление на NPKD и SPOC;

    11. Контрол на извършваните дейности в NPKD и SPOC;

    12. Процедури за извършване на одит на дейностите.

9. Функционални изисквания:

При генерирането, използването, съхранението и защитата на всички частни ключове и мастер списъци с подписи да се използват HSMs.

9.1.1. Подновяване на сертификат преди изтичане на неговата валидност;

9.1.2.Транспортиране на генерираните сертификати

9.1.3. Обявяване на сертификат за невалиден – CRL;

9.1.4. Издаване на предупредително съобщение за наближаващо изтичане (конфигурируем параметър) на валидността на сертификата.Срокът за валидност на сертификатите за IS трябва да бъде не повече от 1 месец.

9.1.5. Да няма възможност за продължаване срока на валидност – генерират се нови ключове и нов сетификат (верига от сертификaти).

Достъпът на потребителите до HSM да се поддържа от PIN PAD.

 10. Етапи на изпълнение:

10.1. Етап 1 - Изготвяне на проект на техническо решение, отговарящо на изискванията в настоящата „Техническа спецификация“.


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


Сподели с приятели:
1   2   3




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

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