Załącznik-nr-1-do-RFQ

Spis treści

Spis treści...........................................................................................................................................1

1. Definicje..............................................................................................................................3

2. Wstęp...............................................................................................................................13

2.1. Podstawa opracowania projektu..........................................................................................13

2.2. Cele realizacji sieci OSE.........................................................................................................13

2.3. Założenia projektowe...........................................................................................................13

2.3.1. Podstawowe założenia............................................................................................13

2.3.2. Węzły sieci..............................................................................................................13

2.3.3. Systemy bezpieczeństwa w Centralnych Węzłach Bezpieczeństwa..........................16

2.3.4. Założenia techniczne dla Zwirtualizowanej infrastruktury obliczeniowej.................16

2.3.5. Ośrodki przetwarzania danych................................................................................18

3. Szczegółowy opis przedmiotu zamówienia.......................................................................18

3.1. Funkcjonalności Systemu......................................................................................................20

3.2. Architektura Systemu...........................................................................................................20

3.3. Skalowanie Systemu.............................................................................................................21

3.3.1. Zasoby obliczeniowe zarezerwowane do realizacji przedmiotu zamówienia............21

3.3.2. Wymagania wydajnościowe na System w ROPD......................................................22

3.3.3. Wymagania wydajnościowe na System w COPD......................................................22

3.3.4. Wymagania wydajnościowe na System w Węźle laboratoryjnym............................23

3.3.5. Wymagania wydajnościowe w ramach prawa opcji.................................................23

3.4. Wymagania dla komponentów Systemu..............................................................................23

3.4.1. Licencjonowanie Systemu.......................................................................................23

3.5. Wymagania dotyczące zarządzania infrastrukturą Systemu.................................................24

3.6. Wymagania dotyczące integracji z innymi systemami Zamawiającego................................26

3.7. Wymagania dotyczące funkcjonalności Systemu..................................................................26

3.7.1. Wymagania dotyczące funkcjonalności w zakresie anti-malware.....................................26

3.7.2. Wymagania dotyczące funkcjonalności w zakresie monitorowania integralności, inspekcji logów oraz kontroli aplikacji.............................................................................................................28

1

3.7.3. Wymagania dotyczące funkcjonalności ochrony przed atakami sieciowymi (IPS), skanowania podatności oraz zapory sieciowej (firewall)..................................................................29

3.8. Wymagania dotyczące raportowania...................................................................................31

3.9. Węzeł laboratoryjny.............................................................................................................31

3.10. Integracje z systemami Zamawiającego............................................................................32

3.10.1. System Fault Management.....................................................................................32

3.10.2. System Performance Management.........................................................................32

3.10.3. System Inventory....................................................................................................32

3.10.4. System Config Management...................................................................................33

3.10.5. System SIEM...........................................................................................................33

1.Definicje

2

Aktualizacje Systemu

Zestaw poprawek, ulepszeń oraz nowych funkcjonalności dla Systemu dostarczanych przez Wykonawcę celem usunięcia zidentyfikowanych nieprawidłowości działania, usunięcia Błędów i/lub Wad oraz poprawienia właściwości Systemu.

API (Application Programming Interface)Zbiór reguł ściśle opisujący sposób, w jaki programy lub podprogramy komunikują się ze sobą.

Awaria

Wystąpienie Problemu, w wyniku którego zostaje spełniona jedna z wymienionych niżej przesłanek:

nie jest możliwe korzystanie przez Zamawiającego z jakiejkolwiek funkcjonalności lub elementów Systemu, zgodnie z wymaganiami opisanymi w Załączniku nr 1;

istnieją zakłócenia w działaniu funkcjonalności Systemu mające wpływ na świadczenie przez Zamawiającego usług OSE;

nie jest zapewniona lub jest zakłócona redundancja poszczególnych elementów Systemu;

System wykazuje niestabilność, która może wpłynąć na utratę wydajności Systemu, elementów Systemu lub pogorszenie jakości usług;

stwierdzenie stanu Systemu, lub elementów Systemu jest utrudnione.

Awaria Krytyczna

Wystąpienie Problemu, w wyniku którego zostaje spełniona jedna z wymienionych niżej przesłanek:

nie jest możliwe korzystanie przez Zamawiającego z Systemu lub korzystanie z Systemu jest znacząco utrudnione (degradacja wydajności lub funkcjonalności);

nie działają funkcjonalności Systemu umożliwiające świadczenie przez Zamawiającego usług OSE lub występuje ich znacząca degradacja;

wydajność Systemu uległa obniżeniu o co najmniej 20% w stosunku do wartości wymaganej zgodnie z Załącznikiem nr 1;

nie jest możliwe stwierdzenie stanu Systemu lub elementów Systemu.

Backup/RestorePojęcia związane z mechanizmem wykonywania kopii zapasowych danych (Backup) oraz ich odtwarzaniem (Restore).

Błędy i/lub Wady Przez Błędy i/lub Wady rozumie się każdą niezgodność

3

Systemu z wymaganiami Zamawiającego i /lub niespełniające wymagań pojemnościowych i/lub wpływające na zakres i jakość usług zapewnianych przez System, a także na wydajność Systemu, stwierdzoną na etapie Testów Odbiorczych.

BSS

System wsparcia biznesu (Business Support Systems) - czyli zespół komponentów i systemów IT, którego operator telekomunikacyjny używa dla wsparcia i realizacji procesów obsługi klienta, partnerów biznesowych i procesów wewnętrznych przedsiębiorstwa.

Centralny Ośrodek Przetwarzania Danych (COPD)Część Zwirtualizowanej infrastruktury obliczeniowej zainstalowana w ramach poszczególnych Kolokacji znajdujących się w Poznaniu i Warszawie

Centralny Węzeł Bezpieczeństwa (CWB)Węzeł Bezpieczeństwa zlokalizowany w węźle centralnym dostarczający mechanizmy ochrony Zasobów obliczeniowych OSE.

CPE

(ang. Customer Premises Equipment) - urządzenia znajdujące się w placówkach abonenta zwane wyposażeniem CPE (ang. Customer Premises Equipment) - urządzenia końcowe użytkownika zapewniające komunikację na "ostatniej mili".

Czas NaprawyCzas, który upłynął od chwili przekazania Wykonawcy Zgłoszenia do chwili dokonania Naprawy.

Czas przywrócenia Systemu – zastosowanie Obejścia

Czas, który upłynął od chwili przekazania Wykonawcy Zgłoszenia do chwili zastosowania Obejścia.

Czas ReakcjiCzas liczony od chwili przekazania Wykonawcy Zgłoszenia do chwili potwierdzenia przyjęcia Zgłoszenia do realizacji.

DNS

(Domain Name System)

Usługa sieciowa obsługująca rozproszoną bazę danych adresów sieciowych. Pozwala na zamianę adresów zrozumiałych dla użytkowników Internetu na adresy zrozumiałe dla urządzeń tworzących sieć komputerową.

DNS Firewall

System realizujący funkcję serwera DNS odpowiadającego na zapytania opisane w dokumencie RFC 1035, posiadający możliwość blokowania części z nich w oparciu o reputacje poszczególnych domen lub w oparciu o przypisane do nich kategorie treści, dzięki temu zapewniając ochronę przed szkodliwym oprogramowaniem i/lub dostępem do treści nielegalnych i szkodliwych.

DNS resolver System realizujący funkcję serwerów DNS dla sieci OSE.

4

Jego zadaniem jest usprawnienie oraz przyśpieszenie procesu dostarczania odpowiedzi systemom i użytkownikom OSE na zapytania dotyczące adresów sieciowych.

Dokumentacja Systemu / Dokumentacja

Wszelka dokumentacja dostarczona lub zrealizowana przez Wykonawcę w związku z realizacją Umowy, tj.:

a) Dokumentacja Gotowego Oprogramowania – dokumentacja dotycząca Gotowego Oprogramowania Systemowego lub Gotowego Oprogramowania Aplikacyjnego oraz wszelka inna dokumentacja dotycząca realizacji przedmiotu zamówienia, opracowana niezależnie od realizacji Umowy;

b) Dokumentacja Dedykowana – dokumentacja opracowana przez Wykonawcę w ramach realizacji Umowy, w szczególności Dokumentacja Techniczna opisana w Załączniku nr 11 (Wytyczne dla Dokumentacji Technicznej), oraz Dokumentacja Powykonawcza opisana w Załączniku nr 6 (Zakres dokumentacji powykonawczej).

Dzień RoboczyKażdy dzień od poniedziałku do piątku, z wyjątkiem dni ustawowo wolnych od pracy w Polsce.

FW

(Firewall)

Funkcjonalność zapewniająca kontrolę ruchu sieciowego na poziomie połączeń z sieciami o różnych poziomach zaufania, zapewniająca separację niechcianego ruchu sieciowego w celu uniemożliwienia dostępu nieuprawnionym osobom z sieci zewnętrznych do sieci chronionej.

Gwarancja

Usługa świadczona na rzecz Zamawiającego obejmująca między innymi zobowiązania Wykonawcy do usuwania Problemów oraz wykonywania innych czynności określonych w Załączniku nr 8 do RFQ.

Infrastruktura bezpieczeństwa

Zbiór urządzeń i oprogramowania zapewniających bezpieczeństwo teleinformatyczne OSE oraz dostarczających usług bezpieczeństwa dla użytkowników OSE. Składa się z systemów SWG, NG Firewall, ADC, DNS, inspekcji ruchu SSL/TLS, zainstalowanych w Regionalnych i Centralnych Węzłach Bezpieczeństwa.

Instruktaż Oznacza Usługę opisaną w Załączniku nr 7 do RFQ.

Integracja Element wdrożenia, oznaczający integrację Systemu z istniejącymi bądź wdrażanymi w ramach budowy OSE systemami Zamawiającego lub ich komponentami

5

wskazanymi w Załączniku nr 1 do RFQ. W ramach Integracji Wykonawca jest zobowiązany do współpracy z wykonawcami innych systemów wdrażanych w ramach budowy OSE.

IPSSystem wykrywania i atakom i włamaniom do systemów teleinformatycznych.

Kopie zapasowe/archiwum

Architektura serwerowa służąca do tworzenia i przechowywania kopii systemów produkcyjnych, umożliwiająca w przypadku awarii systemów produkcyjnych ich odtworzenie z zapisanych danych. Archiwum jest to wydzielona część komponentu, zapewniająca przechowywanie kopii systemów produkcyjnych przez długi okres czasu.

Macierz Obiektowa

Architektura serwerowa służąca do przechowywania i udostępniania danych w formie obiektów, co oznacza, że oprócz danych przechowywane są również metadane opisujące przechowywane dane, a także unikalny globalnie identyfikator.

LDAP (Lightweight Directory Access Protocol)

Protokół przeznaczony do korzystania z usług katalogowych. Jest to również nazwa własna usługi katalogowej przechowującej informacje o użytkownikach i ich atrybutach.

Naprawa

Przywrócenie funkcjonowania Systemu poprzez usunięcie Błędu lub Wady i doprowadzenie do działania Systemu zgodnego z wymaganiami Zamawiającego, parametrami eksploatacyjnymi, specyfikacją, dokumentacją lub ewentualnymi innymi uzgodnieniami pomiędzy Stronami. Naprawę uważa się za dokonaną z chwilą jej weryfikacji i potwierdzenia jej wykonania przez osobę zgłaszającą po stronie Zamawiającego.

Obejście Przywrócenie funkcjonowania Systemu poprzez usunięcie Problemu, Błędu lub Wady i doprowadzenie do działania Systemu zgodnego z wymaganiami Zamawiającego zawartymi w SOPZ. Obejście nie jest normalnym działaniem Systemu lub jego funkcjonalności, w przypadku zastosowania Obejścia System działa poniżej oczekiwań wynikających z jego specyfikacji. Obejście nie jest Naprawą. Obejście pozwala realizować wszystkie procesy związane z prawidłowym działaniem Systemu, jednak wymaga podejmowania przez Użytkowników dodatkowych czynności lub powoduje działanie Systemu poniżej wymagań określonych parametrami eksploatacyjnymi. Obejściem może być również – pod warunkiem

6

akceptacji przez Zamawiającego, zmiana realizacji przebiegu procesów Systemu.

Odbiór KońcowySzereg czynności wykonywanych przez Strony mających na celu stwierdzenie stanu wdrożenia Systemu po zakończeniu Okresu Stabilizacji.

Odbiór Wstępny

Szereg czynności wykonywanych przez Strony, mających na celu stwierdzenie stanu wdrożenia Systemu zgodnie z wymaganiami określonymi w zapytaniu, w tym w Załączniku nr 1, m.in. przeprowadzenie Testów Odbiorczych, akceptacja Dokumentacji powykonawczej.

Okres Stabilizacji

Okres, w którym Wykonawca sprawdza poprawność działania Systemu, sprawdza i testuje działanie poszczególnych bloków funkcjonalnych, udziela wsparcia powdrożeniowego, usuwa Problemy, Błędy i/lub Wady, szczegółowo opisany w Załączniku nr 9 do RFQ.

Centralny Ośrodek Przetwarzania-Danych (COPD)

W OSE istnieją 3 Ośrodki Przetwarzania Danych, oznaczone odpowiednio:

COPD1 - WARSZAWA

COPD2 - POZNAŃ

COPD3 - KATOWICE

Oprogramowanie Systemu / Oprogramowanie

Całość lub dowolny element oprogramowania dostarczanego lub wykonywanego w ramach realizacji Umowy. W jego skład może wchodzić:

1) Gotowe Oprogramowanie Systemowe – oprogramowanie tworzące środowisko, w którym uruchamiane jest pozostałe Oprogramowanie Systemu;

2) Gotowe Oprogramowanie Aplikacyjne – oprogramowanie stanowiące bazę do stworzenia Systemu, istniejące i dystrybuowane przed zawarciem Umowy;

3) Oprogramowanie Dedykowane – oprogramowanie stworzone na potrzeby realizacji Umowy;

4) Oprogramowanie Open Source – oprogramowanie rozpowszechnianie na podstawie licencji otwartych.

OSS System Wsparcia Sieci (Operations Support Systems)) – czyli zespół komponentów i systemów IT, służący do zarządzania siecią telekomunikacyjną i wspierający funkcje zarzadzania, takie jak, inwentaryzacja sieci, provisioning usług, konfiguracja sieci i zarządzanie

7

problemami.

POP3

Protokół internetowy wykorzystywany do pobierania poczty elektronicznej ze zdalnego serwera do komputera lokalnego. Działa poprzez port 110 TCP, a jego wersja szyfrowana poprzez port 995, opisany w dokumencie RFC 1734. Dodatkowo Wersja SSL została opisana w dokumencie RFC 3207

Dokumenty opisujące dodatkowe funkcjonalności POP3:

RFC 1939 – Post Office Protocol – Version 3,RFC 2449 – POP3 Mechanizm Rozszerzania,RFC 1734 – Polecenia uwierzytelniania POP3 AUTH,RFC 2222 – Uwierzytelnianie SASL,RFC 3206 – Kody błędów SYS oraz AUTH POP.

Portal OSEPortal udostępniający użytkownikom informacje o stanie usług OSE oraz umożliwiający sterowanie tymi usługami.

Prace Planowe

Prace zgłoszone przez Wykonawcę Zamawiającemu z wyprzedzeniem min. 3 Dni Roboczych, o zakresie i czasie trwania zaakceptowanym przez Zamawiającego, których celem jest Aktualizacja Systemu, i które mogą się wiązać z przerwaniem dostępności Systemu w całości (System nie jest dostępny i nie realizuje w tym czasie swoich funkcji) lub jego części (działanie Systemu jest ograniczone, np. nie pozwala na wykonywania raportów, nie zapewnia możliwości zalogowania użytkownika do konsoli). Prace Planowe mogą być realizowane wyłącznie poza Godzinami Roboczymi.

PriorytetNadawany Zgłoszeniu status, w oparciu o który definiowane są Czas Reakcji i Czas Naprawy.

Problem

Oznacza zdarzenie, które uniemożliwia lub w jakikolwiek sposób ogranicza możliwość korzystania przez Zamawiającego z Systemu zgodnie z wymaganiami opisanymi w zapytaniu, w tym w Załączniku nr 1 do RFQ, Problem będą kategoryzowane jako Awaria, Awaria Krytyczna i Usterka.

Protokół HTTP Protokół warstwy aplikacyjnej obsługujący w sieci komunikację ruchu webowego związanego z przestrzenią WWW (World Wide Web). Obecną definicję HTTP stanowi dokument RFC 2616.

Za pomocą Protokołu HTTP przesyła się żądania udostępnienia dokumentów WWW i informacje o kliknięciu odnośnika oraz informacje z formularzy.

Zadaniem stron WWW jest publikowanie informacji –

8

natomiast Protokół HTTP właśnie to umożliwia.

Protokół HTTP standardowo korzysta z portu nr 80 (TCP).

Protokół HTTPS

Szyfrowana wersja Protokołu HTTP, w przeciwieństwie do komunikacji nieszyfrowanego tekstu w transmisji HTTP klient-serwer, HTTPS szyfruje dane przy pomocy protokołu TLS. HTTPS działa domyślnie na porcie nr 443 w protokole TCP , opisuje go dokument RFC 2660.

RADIUS

Remote Authentication Dial In User Service – usługa zdalnego uwierzytelniania Użytkowników, używana głównie z systemami telekomunikacyjnymi. Zdefiniowana w następujących dokumentach: RFC 2865, RFC 2866, RFC 3579.

Regionalny Węzeł Bezpieczeństwa (RWB)

Węzeł Bezpieczeństwa zlokalizowany w węźle regionalnym, dostarczający funkcjonalności usług bezpieczeństwa dla szkół podłączonych do danego węzła regionalnego.

Regionalny Ośrodek Przetwarzania Danych (ROPD)

Część Zwirtualizowanej infrastruktury obliczeniowej zainstalowana w ramach poszczególnych Kolokacji. Zamawiający wyszczególnia 16 ROPD podłączonych do każdego z Węzłów.

SDN (Software-Defined Network)

Rozwiązanie polegające na centralnym programowaniu i kontrolowaniu pracy sieci, w którym zbiór urządzeń realizuje zadania zgodnie z logiką centralnej warstwy kontrolnej.

SDS (Software-Defined Storage)Rozwiązanie polegające na uniezależnieniu pamięci masowej od warstwy sprzętowej poprzez wirtualizację pamięci masowej.

Sieć OSE (Ogólnopolska Sieć Edukacyjna)

Publiczna sieć telekomunikacyjna służąca świadczeniu publicznie dostępnych usług telekomunikacyjnych szkole w rozumieniu art. 2 pkt 2 ustawy z dnia 14 grudnia 2016 r. – Prawo oświatowe (Dz. U. z 2017 r. poz. 59 i 949), z wyjątkiem szkół dla dorosłych, zwanej dalej „szkołą”.

SIEM

System odpowiedzialny za zbieranie logów zdarzeń z urządzeń sieciowych, systemów operacyjnych oraz aplikacji. System posiada funkcjonalności takie jak: zbieranie logów, agregację logów, retencję logów oraz przeszukiwanie, raportowanie i tworzenie reguł korelacyjnych.

Siła wyższa Wydarzenie lub okoliczność o charakterze nadzwyczajnym, na którą Wykonawca ani Zamawiający

9

nie mają wpływu, wystąpieniu której Wykonawca ani Zamawiający, działając racjonalnie, nie mogli zapobiec przed zawarciem umowy, której w przypadku jej wystąpienia, Wykonawca ani Zamawiający, działając racjonalnie, nie mogli uniknąć lub jej zapobiec; oraz która nie może być zasadniczo przypisana Wykonawcy ani Zamawiającemu.

SMTP

Protokół internetowy wykorzystywany do przekazywania poczty elektronicznej w Internecie. Standard został zdefiniowany w dokumencie RFC 821, a następnie zaktualizowany w 2008 roku w dokumencie RFC 5321.

SNMP

Rodzina protokołów sieciowych wykorzystywanych do zarządzania urządzeniami sieciowymi i serwerami za pośrednictwem sieci IP.

Do transmisji wiadomości SNMP wykorzystywany jest głównie protokół UDP: standardowo port 161 wykorzystywany jest do wysyłania i odbierania żądań, natomiast port 162 wykorzystywany jest do przechwytywania sygnałów trap od urządzeń.

SSH

Protokół szyfrowania komunikacji typu klient-serwer, służący do terminalowego łączenia się ze zdalnymi komputerami (następca protokołu telnet). Protokoły z rodziny SSH korzystają zwykle z portu 22 protokołu TCP.

Protokół SSH jest zaimplementowany na warstwie aplikacji modelu OSI w ramach połączenia TCP. Protokół SSH jest opisany szczegółowo w dokumentach RFC 4251 i RFC 4254.

SSL VPN dla DC

(SSL-VPN – skrót od ang. Secure Socket Layer i Virtual Private Network)

System służący do bezpiecznej, szyfrowanej transmisji danych w ramach „prywatnej sieci wirtualnej ”. W sieci OSE wykorzystywany do umożliwienia bezpiecznego, zdalnego dostępu dla administratorów sieci OSE oraz zewnętrznych Wykonawców systemów współpracujących z siecią teleinformatyczną Operatora OSE.

Syslog

Protokół umożliwiający rejestrowanie zachodzących zdarzeń przy pomocy scentralizowanego mechanizmu logowania. Działa na porcie 514 udp / tcp .

Jest opisany w następujących dokumentach RFC 5424 i RFC 3164.

System ADC (Application Delivery Controller)

System realizujący równoważenie obciążenia Infrastruktury bezpieczeństwa oraz zapewniający optymalizację wydajności dostarczanych usług w sieci

10

OSE.

System NG Firewall

(NGFW – Next Generation Firewall)

System kontrolujący dostęp do sieci w oparciu o polityki klasyfikujące ruch bazujący na informacjach pozyskanych z protokołów działających w 4 i 7 warstwie modelu OSI, z wykorzystaniem mechanizmów: statefull packet inspection, intrusion prevetion system, application control, antivirus.

System SWG (Security Web Gateway)

System zapewniający funkcje ochrony użytkownika sieci OSE pod kątem filtracji treści nielegalnych i szkodliwych udostępnionych w Internecie z wykorzystaniem funkcjonalności filtracji adresów URL, funkcjonalności dynamicznej analizy treści i funkcjonalności AV.

System bezpieczeństwa dla środowisk zwirtualizowanych / System

Oprogramowanie będące przedmiotem niniejszego postępowania, zapewniające funkcje ochrony Zwirtualizowanej infrastruktury obliczeniowej.

System zarządzającyZbiór oprogramowania, zapewniający Zamawiającemu możliwość zarządzania dostarczanym Systemem.

Usługi

Oznaczają wszystkie prace opisane w Załącznikach, które Wykonawca będzie świadczył na rzecz Zamawiającego zgodnie z niniejszą treścią zapytania, w tym w szczególności Dostawę, Wdrożenie, Utrzymanie, Instruktaż, Gwarancję

Ustawa OSEUstawa z dnia 27 października 2017 r. o Ogólnopolskiej Sieci Edukacyjnej.

Usterka

Działanie Systemu niezgodne z wymaganiami Zamawiającego opisanymi w szczególności w SOPZ oraz w Umowie, wpływające na zakres i jakość działania Systemu, skutkujące niedogodnościami w działaniu Systemu nieograniczającymi możliwości wykonywania funkcji Systemu, ale utrudniającymi pracę Użytkowników Systemu.

Utrzymanie

Ogół czynności realizowanych w celu zapewnienia bezpiecznej, niezawodnej i wydajnej eksploatacji odebranego Systemu, świadczona przez Wykonawcę zgodnie z zakresem opisanym w Załączniku 12 do RFQ.

WAF

(Web Application Firewall)

System Web Application Firewall zapewniający ochronę aplikacyjną dla udostępnianych przez Operatora OSE serwisów www, np. portal OSE, systemy udostępniane zewnętrznym firmom współpracującym z Operatorem OSE.

11

Wdrożenie Systemu

Dostawa, instalacja, integracja, konfiguracja i uruchomienie Systemu wraz z dostarczeniem Dokumentacji, zgodnie z wytycznymi i wymaganiami Zamawiającego. Wykonanie Wdrożenia Systemu zostanie potwierdzone w protokole Odbioru Systemu.

Węzeł / Kolokacja Miejsce fizyczne, powierzchnia kolokacyjna, w którym pracuje Węzeł sieci OSE/ Węzeł Bezpieczeństwa OSE.

Węzeł AgregacyjnyWęzeł, do którego dołączone są łącza dostępowe do szkół, węzeł ten nie ma bezpośredniego połączenia do sieci Internet.

Węzeł Bezpieczeństwa

Zestaw urządzeń wraz z oprogramowaniem, realizujących funkcje bezpieczeństwa (m.in. dekrypcja SSL, funkcjonalność IPS, NG Firewall, SWG itd.). Zamawiający wyróżnia dwa typy Regionalny Węzeł Bezpieczeństwa (RWB) oraz Centralny Węzeł Bezpieczeństwa (CWB)

Węzeł Laboratoryjny

Środowisko wirtualne odzwierciedlające działanie Węzła Bezpieczeństwa, przeznaczone do testowania nowych usług, funkcjonalności, konfiguracji oraz testowania Aktualizacji Systemu.

Węzeł SzkieletowyWęzeł zapewniający przeniesienie ruchu z węzłów agregacyjnych do sieci Internet, a także inżynierię ruchu, na styku sieci OSE z Internetem.

Wsparcie techniczne producenta

Zakupiony przez Wykonawcę u producenta razem z Systemem pakiet wsparcia technicznego, umożliwiający zgłoszenie i usuwanie Błędów i Usterek.

Zasoby obliczeniowe OSE / Zwirtualizowana infrastruktura obliczeniowa (ZIO)

Infrastruktura serwerowa udostępniona przez Zamawiającego w celu zapewnienia mocy obliczeniowej tj. procesory, pamięć RAM, przestrzeń dyskowa na potrzeby systemów i usług OSE.

ZgłoszeniePoinformowanie Wykonawcy o wystąpieniu Problemu, Błędu lub Wady, a także poinformowanie Zamawiającego o Pracach planowych.

2. Wstęp2.1. Podstawa opracowania projektu

Ogólnopolska Sieć Edukacyjna ma na celu zapewnienie dostępu do szybkiego, bezpiecznego Internetu dla szkół. OSE jest publiczną siecią telekomunikacyjną, opartą o istniejącą infrastrukturę szerokopasmową wybudowaną w ramach inwestycji komercyjnych oraz

12

dofinansowanych ze środków publicznych w ramach Programu Operacyjnego Polska Cyfrowa. Za uruchomienie i utrzymanie Sieci OSE, oraz w szczególności za dostarczenie szkołom usługi dostępu do Internetu o symetrycznej przepustowości co najmniej 100 Mb/s wraz z kompleksowymi usługami bezpieczeństwa sieciowego, w tym ochrony przed zagrożeniami dla prawidłowego rozwoju uczniów, odpowiedzialny jest Operator OSE, którym jest NASK Państwowy Instytut Badawczy.

2.2. Cele realizacji sieci OSEW Polsce istnieje około 20 000 szkół zlokalizowanych w około 17 000 lokalizacjach. Podstawowym zadaniem OSE ma być zapewnienie szkołom w Polsce możliwości dostępu do bezpiecznego Internetu i zasobów edukacyjnych wraz z szeregiem usług powiązanych, w tym:

1. Zapewnienie usług dostępu do sieci Internet o przepływności minimum 100 Mb/s symetrycznie,

2. Zapewnienie usług bezpieczeństwa, w tym umożliwiających ochronę użytkowników Sieci OSE,

3. Zapewnienie dostawcom treści edukacyjnych dostępu do użytkowników Sieci OSE,4. Umożliwienia wspomagania procesu kształcenia w szkole.

2.3. Założenia projektowePoniżej opisano główne założenia koncepcyjne, jak również zestaw wymagań, jakie musi spełniać System, w celu umożliwienia realizacji usług zgodnie z założeniami.

2.3.1. Podstawowe założenia

W ramach budowy OSE uruchomiona została rozległa sieć transmisji danych, wybrane systemy bezpieczeństwa wraz z systemami wsparcia obejmującymi m.in. OSS, BSS, jak również dostarczone i zainstalowane zostały do szkół urządzenia abonenckie (CPE), przełączniki, punkty dostępowe sieci bezprzewodowej (AP). Usługi OSE obejmują swoim zasięgiem terytorium Polski. Sieć OSE zbudowana jest z wykorzystaniem Węzłów Bezpieczeństwa zlokalizowanych na terenie 16 województw.

2.3.2. Węzły sieci

W sieci OSE istnieją dwa funkcjonalne rodzaje węzłów:

Węzeł Regionalny składa się z Węzła Agregacyjnego, do którego są dołączone łącza ze szkół, Regionalnego Węzła Bezpieczeństwa oraz z Zasobów obliczeniowych OSE,

Węzeł Centralny, składa się z Węzła Szkieletowego, do którego są dołączone Węzły Agregacyjne, z Centralnego Węzła Bezpieczeństwa oraz z Zasobów obliczeniowych OSE. Węzły te zapewniają łączność z siecią Internet.

Schemat ideowy budowy węzłów został przedstawiony na poniższym schemacie.

13

Rys. 1 Schemat ideowy węzłów bezpieczeństwa

Centralne Węzły Bezpieczeństwa są zlokalizowane w dwóch Węzłach Centralnych, w Warszawie i Poznaniu. Obiekty, w których zainstalowane są Węzły sieci OSE, przedstawiono w poniższej tabeli.

Województwo Lokalizacja węzła

Regionalny Węzeł Bezpieczeństwa

Centralny Węzeł Bezpieczeństwa

mazowieckie Warszawa WAW WAW Core

śląskie Katowice KAT -

wielkopolskie Poznań POZ POZ Core

dolnośląskie Wrocław WRO -

kujawsko-pomorskie Toruń TOR -

lubelskie Lublin LUB -

lubuskie Zielona Góra ZGO -

łódzkie Łódź LOD -

14

Województwo Lokalizacja węzła

Regionalny Węzeł Bezpieczeństwa

Centralny Węzeł Bezpieczeństwa

małopolskie Kraków KRA -

opolskie Opole OPO -

podkarpackie Rzeszów RZE -

podlaskie Białystok BIA -

pomorskie Gdańsk GDA -

świętokrzyskie Kielce KIE -

warmińsko-mazurskie Olsztyn OLS -

zachodniopomorskie Szczecin SZC -

Tabela 1 Węzły sieci OSE

Schemat połączeń Węzłów Centralnych i Regionalnych został pokazany poniżej.

Rysunek nr 2 Topologia sieci rozległej OSE

15

Każdy węzeł Sieci OSE wyposażony został w urządzenia sieciowe, systemy bezpieczeństwa, systemy OSS/BSS oraz w systemy zarządzania siecią, zapewniające dostęp administracyjny do wszystkich urządzeń zlokalizowanych w węźle.

Na potrzeby skalowania wszystkich komponentów Systemu należy przyjąć, że całość ruchu do / ze szkoły kierowana jest z / do sieci Internet.

Sumaryczna ilość ruchu z sieci Internet do szkół wyniesie 1 058 Gbps, a ze szkół do sieci Internet 385 Gbps (wartości określone dla sieci projektowanej na rok 2025).

Zakłada się, że ok. 60% ww. ruchu będzie wychodziło do Internetu przez węzeł WAW-Core, a pozostałe 40% będzie równomiernie rozłożone pomiędzy pozostałe dwa Węzły Centralne. W przypadku awarii dowolnego Węzła Centralnego, ruch przechodzący przez ten węzeł rozłoży się proporcjonalnie na pozostałe dwa Węzły Centralne.

2.3.3. Systemy bezpieczeństwa w Centralnych Węzłach Bezpieczeństwa

Zamawiający posiada urządzenia bezpieczeństwa dedykowane do współpracy z dostarczonym Systemem. Są to urządzenia realizujące funkcjonalność zapory Firewall NG wraz usługami m.in. AV, IPS. Natomiast do ochrony ruchu HTTP, HTTPS (bezpiecznego dostępu do usług) i rozkładania obciążenia Zamawiający posiada urządzenia typu ADC.

Zamawiający zbudował dwa Centralne Węzły Bezpieczeństwa w obu Centrach Danych CWB POZ i CWB WAW składające się lustrzanych kompletów urządzeń.

Lista urządzeń w CWB:

a) NG Firewall - Fortinet Fortigate 3000D – 2 szt.b) Loadbalancer - F5 Networks i11800 – 2 szt.

Zamawiający założył następujące wymagania wydajnościowe dla CWB. W poniższej tabeli przedstawiono wymagane skalowanie Infrastruktury bezpieczeństwa dla poszczególnych Węzłów:

LokalizacjaIlość sesji SSLVPN

Przepustowość NG Firewall

Przepustowość ADC

Przepustowość WAF

COPD1 500 20 Gbps 20 Gbps 8 Gbps

COPD2 500 20 Gbps 20 Gbps 8 Gbps

Tabela nr 2 Wymagania wydajnościowe dla CWB

2.3.4. Założenia techniczne dla Zwirtualizowanej infrastruktury obliczeniowej

Zasoby obliczeniowe, jakie Zamawiający planuje udostępnić na potrzeby budowy Systemu, będą zrealizowane w modelu zwirtualizowanej infrastruktury obliczeniowej. Infrastruktura zostanie rozciągnięta pomiędzy dwoma centralnymi aktywnymi ośrodkami przetwarzania

16

danych COPD1 i COPD2 oraz szesnastoma regionalnymi ośrodkami przetwarzania (ROPD) – ROPD1-16.

Architektura infrastruktury obliczeniowej, obejmująca centralne COPD WAW i COPD POZ, będzie dostosowana do potrzeb systemów OSS, BSS, systemów usługowych NASK OSE (takich jak. np. Portal OSE, zasoby wideo, aplikacje), systemu zarządzania kolokacjami OSE, systemów zarządzania, monitorowania i automatyzacji Zwirtualizowanej infrastruktury obliczeniowej, systemu retencji logów, systemów wspierających infrastrukturę OSE.

Dwa Centralne Ośrodki Przetwarzania Danych COPD -1 oraz COPD-2, będą mieściły się w tych samych fizycznych lokalizacjach co ROPD-1 oraz ROPD-2.

Pomiędzy ROPD i COPD jest dostępna sieć OSE IP/MPLS umożliwiająca wydzieloną komunikację na potrzeby połączenia COPD / ROPD, która w normalnym stanie pracy zapewnia RTT (ang. Round Trip Time) nie niż 8ms dla każdej relacji. W sytuacji awarii łącza opóźnienie może wzrosnąć (przekroczyć dwukrotnie określoną wcześniej wartość), jak również może nastąpić zwiększenie jitter'a.

Projekt sieci OSE zakłada połączenie Zwirtualizowanej infrastruktury obliczeniowej do sieci OSE w COPD z wykorzystaniem pasma o sumarycznej wielkości 80Gbps realizowanego w technologii HA (min. 40Gbps w przypadku wystąpienia awarii).

Podstawowe cechy dostarczanej Zwirtualizowanej infrastruktury obliczeniowej (ZIO):

1) umożliwi rozbudowę poprzez dodawanie powtarzalnych elementów składowych, takich jak np.: serwery HCI i wymagane licencje;

2) umożliwi elastyczne dodawanie zasobów zewnętrznych i funkcjonalności poprzez integrację z zewnętrznymi chmurami obliczeniowymi;

3) umożliwi automatyczne, pół-automatyczne i ręczne przełączanie usług w przypadku awarii jednego COPD (COPD-WAW, COPD-POZ);

4) zapewni wysoką dostępność, integralności i poufności informacji przechowywanych;5) zapewni jednolitą platformę sieci definiowanej programowo (SDN) dla ZIO pracującej w

COPD1 i COPD2; 6) uprości zarządzanie infrastrukturą, przechowywania danych, zarządzania bezpieczeństwem

i wprowadzania zmian w ZIO;7) uprości proces dokonywania zmian i aktualizacji ZIO na poziomie Komponentów SDN, HCI,

Compute, SDS, w sposób scentralizowany i automatyczny dla COPD i ROPD; 8) architektura zakłada uruchomienie niezbędnych elementów odpowiedzialnych za obsługę,

nadzorowanie i zarządzanie ZIO w formie maszyn wirtualnych na zasobach dostarczonej infrastruktury;

9) zarządzanie wszystkimi składnikami ZIO będzie realizowane centralnie i zapewni możliwość centralnego kreowania nowych usług;

10) umożliwi udostępnianie aplikacji w modelu A/A i A/S w COPD-WAW i COPD-POZ.

Architektura Zwirtualizowanej infrastruktury obliczeniowej będzie wzorować się na architekturze referencyjnej producentów oferowanych rozwiązań. Ogólną architekturę logiczną Zwirtualizowanej infrastruktury obliczeniowej przedstawia poniższy rysunek, kolejne akapity zawierają charakterystykę poszczególnych warstw i bloków funkcyjnych.

17

Rysunek nr 3 Architektura logiczna infrastruktury obliczeniowej

2.3.5. Ośrodki przetwarzania danych

Zwirtualizowana infrastruktura obliczeniowa ulokowana w COPD-1 i COPD-2 będzie stanowiła uzupełniającą się i wzajemnie zabezpieczającą się parę (Active/Active, HA/DR [High Availability and Disaster Recovery]), gwarantując utrzymanie działania wszystkich usług przy braku dostępności jednego z dwóch ośrodków centralnych.

Infrastruktura sieciowa Zamawiającego będzie ujednolicona w każdym z COPD/ROPD. W COPD1 i COPD2 dostępna będzie sieć definiowana programowo typu SDN (Software Defined Networking).

COPD1 i COPD2 będą miejscem przechowywania kopii zapasowych środowiska na potrzeby zapewnienia ciągłości działania w przypadku awarii COPD.

Oprogramowanie odpowiedzialne za orkiestrację, administrację, zarządzanie, eksploatację i monitoring Zwirtualizowanej infrastruktury obliczeniowej będzie ulokowane w COPD1 i COPD2 i będzie pracować w modelu Active/Passive lub Active/Active.

3. Szczegółowy opis przedmiotu zamówienia

Przedmiotem zamówienia jest dostawa Systemu bezpieczeństwa dla środowisk zwirtualizowanych (System). W zakres przedmiotu zamówienia wchodzą:

Dostawa Oprogramowania, o cechach, funkcjonalności i parametrach technicznych szczegółowo wyspecyfikowanych w Szczegółowym Opisie Przedmiotu Zamówienia, stanowiącym Załącznik nr 1 do RFQ;

Przekazanie wieczystych licencji do Oprogramowania niezbędnego do prawidłowego funkcjonowania Systemu oraz praw autorskich dla utworów powstałych w trakcie

18

realizacji projektu (w tym w szczególności dokumentacji projektowej dla Systemu oraz Dokumentacji powykonawczej);

Wdrożenie Systemu, na które składają się wdrożenia elementów Systemu w poszczególnych COPD i ROPD zgodnie z zatwierdzoną Dokumentacją Techniczną oraz wykonanie Integracji zgodnie z pkt. 3.11 niniejszego dokumentu;

Przeprowadzenie Testów Odbiorczych zgodnie z Załącznikiem nr 10 do RFQ; Wykonanie i przekazanie Zamawiającemu Dokumentacji Powykonawczej oraz jej

aktualizacji, w przypadku zmian w Systemie, zgodnie z opisem w Załączniku nr 6 do RFQ;

Przeprowadzenie Instruktaży dla osób wskazanych przez Zamawiającego w zakresie opisanym w Załączniku nr 7 do RFQ;

Udzielenie Gwarancji na Oprogramowanie oraz na wykonane Usługi, na okres 5 lat od daty podpisania protokołu odbioru Systemu;

Realizacja obowiązków Wykonawcy w Okresie Stabilizacji, zgodnie z wymaganiami opisanymi w Załączniku nr 9 do RFQ;

Przygotowanie Planu Testów Odbiorczych na bazie wytycznych zawartych w Załączniku nr 10 do RFQ;

Przygotowanie Dokumentacji Technicznej zgodnie z opisem zawartym w Załączniku nr 11 do RFQ;

Utrzymywanie Systemu na warunkach określonych w Załączniku nr 12 do RFQ.

W celu zrealizowania wymaganych funkcjonalności, opisanych w niniejszym dokumencie, Wykonawca zobowiązany jest do dostarczenia Oprogramowania niezbędnego do zbudowania rozwiązania, stanowiącego System instalowanego na Zwirtualizowanej infrastrukturze obliczeniowej Zamawiającego, opisanej w pkt. 2.3.4 i 2.3.5 niniejszego dokumentu. Dostarczony System musi spełniać poniższe założenia:

1) Dostarczane Oprogramowanie musi zostać wdrożone zgodnie z wymaganiami Zamawiającego zawartymi w niniejszym dokumencie.

2) Wszystkie wymagania i parametry, w tym techniczne, funkcjonalne i wydajnościowe zawarte w niniejszym dokumencie mają charakter obligatoryjny i Wykonawca zobowiązany jest do ich spełnienia w ramach oferowanego rozwiązania.

3) Wszystkie wymagania i parametry musza być spełnione łącznie. 4) Wszystkie wymagania podane w niniejszym dokumencie muszą być spełnione dla

wielkości ruchu określonej w niniejszych wymaganiach, chyba że w opisie danej funkcjonalności podano inaczej.

5) W przypadku wskazania wymagań złożonych, konieczne jest spełnienie wszystkich z elementów.

6) Wykonawca dokona doboru odpowiedniego Oprogramowania do realizacji wymagań Zamawiającego w zakresie budowy Systemu w Centralnych i Regionalnych Węzłach Bezpieczeństwa. Zamawiający dopuszcza oferowanie wielu komponentów realizujących zadania Systemu w węzłach lub też jednego komponentu realizującego wszystkie niezbędne funkcje przy zachowaniu parametrów niezawodnościowych (HA). Jednocześnie proponowane rozwiązania powinny być zunifikowane.

7) Wykonawca jest zobowiązany do Wdrożenia Systemu w każdym z 2 Centralnych, Węzłów Bezpieczeństwa i 16 Regionalnych Węzłów Bezpieczeństwa oraz 1 Węzła laboratoryjnego.

19

8) Wykonawca jest zobowiązany do współpracy z innymi dostawcami wskazanymi przez Zamawiającego przy wykonaniu Integracji Systemu z innymi systemami, wskazanymi przez Zamawiającego.

9) W ramach oferowanego przedmiotu zamówienia Wykonawca dostarczy również System zarządzający, umożliwiający Zamawiającemu konfigurację i administrację udostępnionym Systemem w pełnym zakresie funkcjonalnym, opisanym poniżej w punkcie 3.7 "System zarządzający”.

3.1. Funkcjonalności Systemu

1. System zainstalowany w każdym z Węzłów Bezpieczeństwa będzie zawierać komponenty mające za zadanie chronić Zwirtualizowaną infrastrukturę obliczeniową w zakresie:

a) Detekcji niebezpiecznego kodu wykrytego na objętym ochroną systemie poprzez analizę typu anty-wirus/anty-malware,

b) Filtrowania ruchu sieciowego za pomocą zapory sieciowej,c) Skanowania podatności wykrywającego podatności serwerów, które mogą być

wykorzystane do przeprowadzenia skutecznego ataku,d) Wykrywania i zapobiegania atakom wykorzystującym podatności systemu

operacyjnego i aplikacji za pomocą mechanizmu IPS,e) Monitorowania integralności kluczowych plików, katalogów, kluczy rejestrów,

działających procesów oraz otwartych portów,f) Monitorowania i blokowania nowego potencjalnie niebezpiecznego kodu

poprzez mechanizm kontroli aplikacji,g) Inspekcji logów generowanych przez serwer i uruchomione na serwerze usługi.

2. System musi zapewniać ochronę w sposób agentowy. 3. System musi umożliwiać ochronę następujących dystrybucji systemu operacyjnego Linux:

RedHat Enterprise Linux, CentOS, Oracle Linux, SUSE Linux, Ubuntu, Debian, Cloud Linux, Solaris, AIX.

4. System musi umożliwiać ochronę następujących wersji systemu operacyjnego Windows: Windows 2012, Windows 2012 R2 Core, Windows 2016, Windows 2019.

5. System musi zapewniać bezpieczeństwo zarówno serwerów wirtualnych, jak i fizycznych.6. W ramach realizacji przedmiotu zamówienia, Wykonawca zainstaluje Węzeł

laboratoryjny realizujący wszystkie funkcje wskazane dla COPD i ROPD. Węzeł laboratoryjny pozwoli na przeprowadzenie:a) Testów aktualizacyjnych Oprogramowania b) Testów przy większych zmianach konfiguracyjnych.

3.2. Architektura Systemu

1. System, ze wszystkimi jego funkcjonalnościami, musi zostać uruchomiony w dwóch węzłach: COPD-1 i COPD-rozproszonych geograficznie. Węzeł COPD1 stanowi lustrzane odbicie węzła COPD2, co obrazuje poniższy schemat:

20

Rysunek nr 4 Budowa CWB

2. System musi pracować w modelu nadmiarowym, a proces przywrócenia funkcjonalności Systemu w przypadku awarii COPD nie może przekroczyć 15 minut i musi być automatyczny (wymagane przywrócenie funkcjonalności rozwiązania).

3. Zarządzanie Systemem, z wyłączeniem uszkodzonej lokalizacji, musi odbywać się w sposób analogiczny, jak przed wystąpieniem awarii w wyłączonej lokalizacji.

4. W ramach realizacji przedmiotu zamówienia wymagane jest zaplanowanie mechanizmów realizujących przełączanie usług uruchomionych w Systemie pomiędzy COPD-1 i COPD-2.

3.3. Skalowanie Systemu

Poniższe dane mają charakter danych projektowych i zostały przedstawione w celu umożliwienia Wykonawcy zaoferowania optymalnego rozwiązania w postaci Systemu spełniającego wszystkie parametry i wymagania Zamawiającego zawarte w niniejszym dokumencie.

3.3.1. Zasoby obliczeniowe zarezerwowane do realizacji przedmiotu zamówienia

Poniższa tabela wskazuje maksymalne wartości mocy obliczeniowej (liczba fizycznych rdzeni CPU), pamięci RAM (GB) i przestrzeni dyskowej (GB), jakie Zamawiający przewiduje na potrzeby instalacji i działania Systemu wdrożonego w ramach zamówienia podstawowego w poszczególnych węzłach, na dostarczonej przez Zamawiającego Zwirtualizowanej infrastrukturze obliczeniowej. W celu realizacji prawa opcji, Zamawiający udostępni Wykonawcy dodatkowe zasoby, których ilość zostanie ustalona pomiędzy stronami w trybie roboczym.

vCPU RAM Przestrzeń dyskowa

[Liczba rdzeni procesora] [GB] [GB]

COPD-1 70 280 1200COPD-2 54 235 1000

Każdy ROPD 16 60 800Tabela nr 3 Zasoby obliczeniowe w COPD i ROPD

Zwirtualizowana infrastruktura obliczeniowa będzie zapewniać komponenty Compute i SDS umieszczone w dwóch centralnych Centrach Danych, umożliwiając wirtualizację zasobów

21

sprzętowych, przechowywania danych i automatyczne przenoszenia maszyn wirtualnych między dwoma Centrami Danych po awarii.Węzeł laboratoryjny musi zostać zainstalowanych w ramach zasobów udostępnionych w COPD-1.

Rozwiązanie:

a) będzie zapewniało wirtualizację dla systemów operacyjnych Linux i Windows, b) będzie zapewniało wirtualizację dla zagnieżdżonej wirtualizacji, c) będzie zapewniało bezprzerwową pracę infrastruktury i bezpieczeństwa w oparciu o

możliwość wykorzystania wirtualnego TPM 2.0, d) będzie automatycznie rozkładało obciążenie i przenosiło maszyny wirtualne w wyniku

zwiększonego zapotrzebowania na moc obliczeniową między hostami, e) umożliwi dodawanie zasobów systemowych podczas pracy, f) zapewni globalną konsolę administracyjną.

3.3.2. Wymagania wydajnościowe na System w ROPD

W poniższej tabeli przedstawiono wymiarowanie Zwirtualizowanej infrastruktury obliczeniowej w rozbiciu na poszczególne Regionalne Ośrodki Przetwarzania Danych.

Województwo ROPDLiczba maszyn

wirtualnych objętych ochroną

MAZOWIECKIE WAW 120ŚLĄSKIE KAT 72

MAŁOPOLSKIE KRA 37WIELKOPOLSKIE POZ 45PODKARPACKIE RZE 26

LUBELSKIE LUB 24DOLNOŚLĄSKIE WRO 23

ŁÓDZKIE LOD 23POMORSKIE GDA 22

KUJAWSKO-POMORSKIE TOR 20ZACHODNIOPOMORSKIE SZC 19

WARMIŃSKO-MAZURSKIE OLS 16ŚWIĘTOKRZYSKIE KIE 15

PODLASKIE BIA 15OPOLSKIE OPO 12LUBUSKIE ZGO 10

Tabela nr 4 Wymiarowanie Zwirtualizowanej infrastruktury obliczeniowej w ROPD.

3.3.3. Wymagania wydajnościowe na System w COPD

W poniższej tabeli przedstawiono wymiarowanie Zwirtualizowanej infrastruktury obliczeniowej w rozbiciu na poszczególne COPD.

22

Województwo OPDLiczba maszyn

wirtualnych objętych ochroną

MAZOWIECKIE WAW 500ŚLĄSKIE KAT 100

WIELKOPOLSKIE POZ 500Tabela nr 5 Wymiarowanie Zwirtualizowanej infrastruktury obliczeniowej w COPD

3.3.4. Wymagania wydajnościowe na System w Węźle laboratoryjnym

Wydajność Węzła laboratoryjnego*

Liczba maszyn wirtualnych objętych ochroną 50

*) minimalna wydajność przy założeniu realizacji wszystkich zakładanych funkcjonalności realizowanych w ROPD i COPD dla wskazanej w tabeli liczby maszyn wirtualnych objętych ochroną.

3.3.5. Wymagania wydajnościowe w ramach prawa opcji

W ramach prawa opcji Zamawiający może rozbudować System w poszczególnych węzłach. Każdorazowo Zamawiający będzie mógł rozszerzyć liczbę chronionych maszyn wirtualnych o 25 sztuk. Maksymalna liczba takich pakietów to 20 sztuk po 25 licencji – czyli sumarycznie Zamawiający może zwiększyć wydajność całego Systemu o 500 sztuk. Poszczególne pakiety licencyjne zamówione w ramach prawa opcji będą mogły być wykorzystane przez Zamawiającego do powiększenia wydajności bazowej każdego z węzłów. Termin licencji na Oprogramowanie zapewnianych w ramach realizacji prawa opcji nie może być krótszy niż czas obowiązywania Gwarancji.

3.4. Wymagania dla komponentów Systemu

3.4.1. Licencjonowanie Systemu.

1. Wykonawca zobowiązany jest dostarczyć wszystkie niezbędne licencje umożliwiające pełną funkcjonalność Systemu wymaganą w niniejszym dokumencie.

2. Licencje dostarczone/zapewnione wraz z Systemem nie mogą ograniczać liczby Użytkowników oraz administratorów, korzystających jednocześnie z Systemu, jak również ilości przetwarzanych danych.

3. Jeżeli System będzie wymagał dodatkowych licencji baz danych, systemów operacyjnych i innych elementów koniecznych do realizacji przedmiotu zamówienia, Wykonawca dostarczy je w ramach wynagrodzenia z tytułu realizacji przedmiotu zamówienia.

3.4.2. Wymagania dotyczące elementów centralnych oraz zarządzających Systemem

1) Wszystkie elementy centralne i zarządzające muszą być dostarczone, jako:

23

a) Oprogramowanie, instalowane na systemie wirtualnym pracującym pod kontrolą systemu operacyjnego Windows Server lub Linux Server, lub

b) Wirtualny appliance, który może być wdrożony w Zwirtualizowanej infrastrukturze obliczeniowej,

2) Każdy element centralny Systemu musi działać w klastrze wysokiej dostępności, który będzie gwarantował ciągłość działania Systemu w przypadku awarii jednego z elementów klastra lub jednego z dwóch ośrodków, w których klaster zostanie wdrożony.

3) Klaster wysokiej dostępności musi być zainstalowany w ośrodkach opisanych w rozdziale 2.3.4.

4) Wszystkie czynności związane z przełączeniem elementów centralnych oraz zarządzania, związane z awarią, muszą odbywać się w sposób automatyczny i nie może trwać dłużej niż 15 min od momentu wystąpienia awarii.

5) Zasoby Zwirtualizowanej infrastruktury obliczeniowej potrzebne do uruchomienia Systemu nie mogą przekroczyć wartości wyspecyfikowanych w rozdziale 3.3.1.

3.4.3. Aktualizacje Systemu

1. Dostawca musi zapewnić dedykowane dla Zamawiającego repozytorium, w którym systematycznie i na bieżąco będzie umieszczał Aktualizacje Systemu.

2. System musi posiadać funkcjonalność, która umożliwia sprawdzenie, czy w repozytorium znajdują się nowsze wersje Oprogramowania, niż aktualnie zainstalowane u Zamawiającego.

3. System musi posiadać funkcjonalność, która powiadomi administratora o tym, że są dostępne Aktualizacje Systemu oczekujące na wykonanie.

4. System musi posiadać funkcjonalność, która umożliwia aktualizację elementów Systemu na bazie Oprogramowania umieszczonego w dedykowanym repozytorium.

5. System musi zapewniać, aby proces Aktualizacji nie wymagał wyłączenia kluczowych komponentów systemu na czas Aktualizacji, czyli powinna przebiegać „w tle”. Jeżeli wymagany będzie restart Systemu winien on być wykonany w taki sposób aby nie kolidował z działaniem innych modułów Systemu.

6. Do każdej Aktualizacji musi zostać przygotowany raport w formie graficznej lub tekstowej, opisujący które komponenty systemu zostaną poddane Aktualizacji oraz jakie zmiany, poprawki wprowadza dana Aktualizacja.

3.5. Wymagania dotyczące zarządzania infrastrukturą Systemu

1) Zarządzanie wszystkimi elementami Systemu musi odbywać się bezpośrednio i z wykorzystaniem Systemu zarządzającego, za pomocą graficznej konsoli Web GUI, dostępnej przez przeglądarkę WWW, zabezpieczonej z wykorzystaniem protokołu TLS minimum 1.1 RFC 4346 . Zamawiający wyraża zgodę na wdrożenie Systemu o parametrach wymuszających konieczność instalacji dodatkowego oprogramowania na stacji administratora, które Wykonawca dostarczy Zamawiającemu w celu efektywnego zarządzania dostarczonym Systemem, zgodnie z wymaganymi parametrami.

2) Funkcjonalność zarządzania Systemem musi zapewniać Zamawiającemu możliwość uwierzytelniania administratorów za pomocą bazy lokalnej i z wykorzystaniem, co najmniej dwóch z wymienionych mechanizmów: RADIUS lub LDAP lub SAML.

3) Funkcjonalność zarządzania System musi posiadać funkcjonalność określenia harmonogramu lub częstotliwości pobierania Aktualizacji nowych wersji

24

Oprogramowania lub jego części, w szczególności baz reputacyjnych i sygnatur, od producenta Oprogramowania;

4) System musi posiadać funkcjonalność zarządzania zdarzeniami i raportowanie – natychmiastowe alarmowanie o aktywności niebezpiecznego kodu na chronionym serwerze lub wykryciu ataku kierowanego na chroniony serwer.

5) System musi umożliwiać nanoszenie zmian w profilach bezpieczeństwa w czasie rzeczywistym bez potrzeby restartu Systemu i chronionych obiektów;

6) System musi posiadać możliwość pracy w trybie wieloinstancyjnym tj. pozwalać na równoległe współistnienie wielu użytkowników posiadających dostęp do wydzielonej części infrastruktury i zarządzania jej bezpieczeństwem;

7) Wymagana jest całkowita separacja danych między poszczególnymi instacjami.8) System musi pozwalać na generowanie raportów przez użytkowników poszczególnych

instancji.9) System musi posiadać funkcjonalność zapewniającą dostęp do konsoli zarządzającej z

kilku stacji jednocześnie.10) Dostęp do konsoli zarządzającej musi być zapewniony z następujących przeglądarek:

Microsoft Internet Explorer, Microsoft Edge, Google Chrome, Mozilla Firefox bez potrzeby stosowania dodatkowych komponentów lub rozszerzeń;

11) System musi posiadać funkcjonalność tworzenia kont dla administratorów o różnych poziomach uprawnień w odniesieniu do chronionych maszyn wirtualnych lub ich grup z dokładnością do pojedynczej polityki lub serwera;

12) System musi mieć funkcjonalność tworzenia ról administratorów i przydzielania im uprawnień, co najmniej w zakresie zarządzania:

a) serwerami lub grupami serwerów;b) politykami lub grupami polityk;c) poszczególnymi funkcjonalnościami Oprogramowania antywirusowego;

13) Zarządzanie rolami w Systemie musi pozwalać na zdefiniowanie uprawnień dających możliwość administrowania wyłącznie jednym chronionym obiektem oraz pojedynczymi funkcjonalnościami Systemu bez możliwości zmiany nadrzędnego profilu bezpieczeństwa;

14) System musi mieć funkcjonalność tworzenia logicznych grup serwerów w celu zarządzania tymi grupami oraz wymuszania stosowania określonych dla grup zasad bezpieczeństwa, ustanawianych dla każdej z grupy indywidualnie;

15) System musi mieć funkcjonalność tworzenia hierarchii polityk, w której polityki pochodne dziedziczą ustawienia od polityk na wyższym poziomie. Administratorzy posiadający uprawnienia jedynie do polityk pochodnych nie mogą mieć możliwości wprowadzania zmian do ustawień dziedziczonych;

16) Wszystkie elementy wchodzące w skład Systemu muszą współpracować z rozwiązaniami do monitorowania poprzez protokół SNMP;

17) Wszystkie bazy sygnatur, kategoryzacji i feedów dostarczone i wdrożone w ramach Systemu muszą być na bieżąco, cyklicznie aktualizowane przez producenta Oprogramowania, zgodnie z harmonogramem zdefiniowanym przez Zamawiającego, przez cały okres trwania Gwarancji. Harmonogram zostanie ustalony z Wykonawcą na etapie Wdrożenia;

18) Wszystkie elementy wchodzące w skład Systemu muszą wysyłać zdarzenia (logi) do serwera SIEM za pomocą protokołu Syslog, w formacie CEF lub LEEF lub równoważnym RFC 5424. Logowanie musi obejmować zdarzenia dotyczące wszystkich elementów Systemu;

25

19) System zarządzający Oprogramowania zabezpieczającego musi posiadać API pozwalające na jego integrację z zewnętrznymi systemami zarządzającymi firm trzecich. Dokumentacja API zapewniająca integrację z zewnętrznymi systemami zarządzającymi firm trzecich musi być powszechnie dostępna;

20) System musi być dostarczony z aktywnymi licencjami na opisane moduły funkcjonalne na okres co najmniej 5 lat;

21) Licencje dostarczone wraz z Systemem nie mogą ograniczać liczby użytkowników, administratorów, korzystających jednocześnie z Systemu .

3.6. Wymagania dotyczące integracji z innymi systemami Zamawiającego

1) System musi umożliwiać bieżące identyfikowanie i wyświetlanie aktualnej listy maszyn wirtualnych uruchomionych na Zwirtualizowanej infrastrukturze obliczeniowej w konsoli zarządzającej.

2) W ramach Wdrożenia Wykonawca musi wykonać integrację Systemu zarządzającego ze środowiskiem Zwirtualizowanej infrastruktury obliczeniowej.

3) System musi umożliwiać integrację z Zwirtualizowaną infrastrukturą obliczeniową w celu ochrony serwerów;

4) System musi pozwalać na bezproblemową integrację i wykorzystanie technologii VMware NSX-T, lub równoważnej, do zapewnienia ochrony serwerów m.in. poprzez dynamiczne przenoszenie chronionego serwera do innej grupy bezpieczeństwa za pomocą funkcjonalności NSX Security Tagging, lub równoważnej, w przypadku wykrycia eksplorowania podatności przez moduł ochrony IPS;

5) System musi pozwalać na pracę w trybie mieszanym VMware NSX, lub równoważnej, oraz bez NSX;

6) System musi pozwalać na swobodny wybór ochrony agentowej lub bezagentowej w przypadku serwerów wirtualnych;

7) System musi posiadać funkcjonalność automatycznego przypisywania polityk w oparciu o algorytmy zdefiniowane przez administratora, co najmniej w przypadku utworzenia nowego serwera wirtualnego, jego przeniesienia lub zmiany adresacji IP;

8) Algorytmy, w oparciu o które System przydziela polityki, muszą posiadać funkcjonalność definiowania automatycznych działań, co najmniej w zależności od:

a) nazwy serwera;b) systemu operacyjnego.

3.7. Wymagania dotyczące funkcjonalności Systemu

3.7.1. Wymagania dotyczące funkcjonalności w zakresie anti-malware.

1) System musi posiadać funkcjonalność ciągłego, bieżącego i automatycznego wykrywania zagrożeń co najmniej typu: „spyware", „greyware”, „adware", „keylogger”, „dialer”, „trojan”, „malware”;

2) System musi posiadać ochronę przed zagrożeniami typu „ransomware”;

26

3) System musi umożliwiać agentową i bezagentową ochronę maszyn fizycznych i wirtualnych.

4) Ochrona typu anti-malware musi być wspierana na wielu systemach operacyjnych, co najmniej na takich jak:

a) Windows Server 2012 i nowszych, b) Linux RedHat, c) Linux CentOS, d) Linux Suse, e) Linux Debian, f) Linux Ubuntu.

5) System musi umożliwiać bezagentową ochronę maszyn wirtualnych pracujących pod kontrolą systemu operacyjnego Windows w środowisku Zwirtualizowanej infrastruktury obliczeniowej.

6) System musi pozwalać na powiadamianie użytkownika w przypadku skorzystania z niebezpiecznych zasobów lub pobrania niebezpiecznego pliku, zarówno w trybie agentowym, jak i bezagentowym;

7) W przypadku ochrony w trybie bezagentowym dopuszcza się możliwość instalacji na chronionym serwerze Oprogramowania mającego na celu informowanie administratora serwera o wykrytym zdarzeniu bezpieczeństwa.

8) System musi posiadać funkcjonalność określenia obszarów skanowania, typów skanowanych plików, momentu ich skanowania (otwarcie i/lub modyfikacja) oraz na wykluczenie ze skanowania określonych obszarów dla skanowania w czasie rzeczywistym, ręcznego skanowania oraz skanowania określonego w harmonogramie;

9) System musi pozwalać na określenie reakcji w przypadku wykrycia wirusa;10) System musi zapewniać określenie harmonogramu skanowania (obiekty i grupy) oraz

wymuszenia skanowania w danej chwili;11) System musi stosować mechanizm skanowania nowych bądź zmienionych plików w celu

skrócenia czasu skanowania oraz zwiększenia wydajności skanowania;12) System musi posiadać funkcjonalność zdefiniowania harmonogramu lub częstotliwości

pobierania aktualizacji bazy wirusów, wszelkich poprawek oprogramowania oraz umożliwiać określenie centralnego punktu dystrybucji uaktualnień i poprawek oprogramowania w infrastrukturze zamawiającego;

13) System musi posiadać funkcjonalność predefiniowania reakcji w przypadku wykrycia wirusa, w tym co najmniej: czyszczenie, usunięcie, kwarantanna, „false positive”, oraz natychmiastowego automatycznego wykonywania tej reakcji, a także raportowania o zdarzeniach w formie co najmniej: e-mail, wiadomość SNMP;

14) System nie może wymagać restartu chronionych komputerów i serwerów po dokonaniu aktualizacji definicji wirusów;

15) System musi posiadać funkcjonalność ciągłego, bieżącego i automatycznego blokowania połączeń do adresów URL określonych przez producenta Systemu jako niebezpieczne, również w przypadku, gdy połączenia są nawiązywane przez procesy działające na chronionych serwerach, oraz bieżącego aktualizowania listy tych adresów;

16) System musi posiadać funkcjonalność definiowania statycznych list adresów URL do których połączenia są ciągle, na bieżąco i automatycznie blokowane;

17) System musi posiadać funkcjonalność generowania i wysyłania e-mailem na zdefiniowany adres raportów w wybranym formacie ( co najmniej .pdf);

27

18) System musi posiadać funkcjonalność ciągłego, bieżącego i automatycznego identyfikowania i rejestrowania zdarzeń, które wpływają lub mogą wpływać na bezpieczeństwo chronionych zasobów.

19) System musi posiadać możliwość przekazywania zdarzenia (rozumianego jako wszystkie informacje o zidentyfikowanym przez oprogramowanie antywirusowe zdarzeniu wpływającym na bezpieczeństwo - w formie zbioru informacji (rekordu)) do centralnego serwera lub systemu typu SIEM (wg. predefiniowanego wyboru administratora) z wykorzystaniem szyfrowanego kanału komunikacji. W przypadku wysyłania informacji o zdarzeniach do systemu SIEM administrator musi mieć możliwość zdefiniowania centralnego systemu SIEM lub odrębnych systemów dla każdej z polityk, grup chronionych serwerów lub pojedynczych serwerów;

3.7.2. Wymagania dotyczące funkcjonalności w zakresie monitorowania integralności, inspekcji logów oraz kontroli aplikacji

1) System musi pozwalać na monitorowanie wskazanych plików, katalogów, serwisów, wpisów w rejestrach oraz procesów i informowanie o wprowadzanych zmianach.

2) Informacja o wprowadzonych zmianach musi zawierać, co najmniej nazwę pliku lub wpisu w rejestrze, w którym została wprowadzona zmiana, datę i czas wprowadzenia zmiany, nazwę serwera, na którym została wprowadzona zmiana, oraz nazwę reguły, która została wykorzystana;

3) System musi posiadać predefiniowany zestaw reguł dostarczonych przez producenta oprogramowania określających wskazane do monitorowania pliki, wpisy w rejestrach oraz monitorowane serwisy, w zależności od chronionego systemu lub aplikacji lub posiadać funkcjonalność rekomendowania administratorowi uruchomienia konkretnych reguł definiowanych i dostarczanych przez producenta oprogramowania. Rekomendacja powinna być specyficzna dla konkretnego chronionego systemu. Rekomendacja powinna opierać się na cyklicznej, co najmniej raz na dobę analizie chronionego sytemu operacyjnego – jego wersji oraz zainstalowanym oprogramowaniu. Rekomendacja powinna dotyczyć, co najmniej elementów systemu operacyjnego, jakie należy monitorować pod kątem integralności (takie jak pliki, procesy).

4) System musi posiadać funkcjonalność ręcznego definiowania reguł dotyczących monitorowanych plików oraz wpisów w rejestrach;

5) System musi posiadać funkcjonalność definiowania wykluczeń plików znajdujących się w monitorowanym katalogu;

6) System musi posiadać funkcjonalność automatycznego uruchamiania rekomendowanych reguł będących wynikiem wykonanej analizy dla każdego chronionego serwera. Automatyczna analiza i optymalizacja polityk dla serwerów powinna być wykonywana co najmniej raz na dobę.

7) System musi posiadać funkcjonalność analizy logów pochodzących z chronionych systemów oraz aplikacji;

8) System musi posiadać reguły dostarczone przez producenta określające wskazane do zbierania i analizy logi, w zależności od chronionego systemu lub aplikacji;

9) System musi posiadać funkcjonalność ręcznego definiowania przez administratora zbieranych i analizowanych logów;

28

10) System musi posiadać funkcjonalność dokonywania analizy logów co najmniej w dwóch z wymienionych formatów: syslog, snort, apache, squid, iis, nmapg, mysql, postgresql, eventlog;

11) System musi posiadać funkcjonalność analizowania nieustandaryzowanych logów generowanych przez aplikacje i systemy, w szczególności logów w postaci pojedynczej linijki tekstu;

12) System musi posiadać funkcjonalność tworzenia polityk stanowiących zbiór reguł dostarczonych przez producenta oraz zdefiniowanych przez administratora;

13) System musi posiadać funkcjonalność definiowania poziomu krytyczności każdej z reguł logów;

14) System musi posiadać predefiniowany zestaw reguł dotyczących monitorowania logów dostarczony przez producenta lub musi posiadać funkcjonalność rekomendowania administratorowi uruchomienia konkretnych reguł związanych z monitorowaniem logów. Rekomendacja powinna być specyficzna dla konkretnego chronionego systemu. Rekomendacja powinna opierać się na cyklicznej, co najmniej raz na dobę analizie chronionego sytemu operacyjnego – jego wersji oraz zainstalowanym oprogramowaniu. Rekomendacja powinna dotyczyć, logów generowanych przez system, które należy monitorować i informacja, o których będzie prezentowana w konsoli centralnej.

15) System musi posiadać mechanizm kontroli aplikacji uniemożliwiający na instalowanie jakichkolwiek niezatwierdzonych do działania w środowisku aplikacji. System musi posiadać możliwość otwierania tzw. „okien czasowych”, w których zespoły mogą wprowadzać zmiany do konfiguracji aplikacji na serwerach;

16) Mechanizm kontroli aplikacji musi umożliwiać określenie stanu początkowego, w którym każdy kod wykonywalny znajdujący się na serwerze traktowany jest, jako zaufany.

17) Mechanizm kontroli aplikacji musi traktować każdy kod wykonywalny, który pojawi się na serwerze po określeniu staniu początkowego, jako potencjalnie niebezpieczny.

18) Mechanizm kontroli aplikacji musi umożliwiać blokowanie każdego potencjalnie niebezpiecznego kodu lub w zależności od polityki pozwolić na jego uruchomienie, ale wygenerować zdarzenie bezpieczeństwa, które zostanie przesłane do centralnej konsoli zarządzającej.

19) Mechanizm kontroli aplikacji, jako kod wykonywalny, musi traktować co najmniej trzy typy plików spośród wymienionych: EXE, BIN, DLL, skrypty powershell oraz bash, SYS, SO, JAR, VBS, JS, WSE . Do tych plików powinna być egzekwowana polityka bezpieczeństwa.

20) Mechanizm monitorowania integralności, inspekcji logów i kontroli aplikacji musi być wspierany na wielu systemach operacyjnych, co najmniej na takich jak:

a) Windows Server 2012 i nowszych, b) Linux RedHat, c) Linux CentOS, d) Linux Suse, e) Linux Debian, f) Linux Ubuntu.

3.7.3. Wymagania dotyczące funkcjonalności ochrony przed atakami sieciowymi (IPS), skanowania podatności oraz zapory sieciowej (firewall)

29

1) System musi posiadać funkcjonalność ciągłej, bieżącej i automatycznej kontroli oraz blokowania skierowanych na serwer ataków w warstwie sieciowej za pomocą mechanizmu IPS;

2) Mechanizm IPS musi umożliwiać wykrywanie i blokowanie ataków generowanych wewnątrz ośrodków przetwarzania danych (COPD, ROPD). W szczególności musi być możliwość wykrycia i zablokowania ataku wygenerowanego z serwera wirtualnego znajdującego się na tym samym serwerze fizycznym (hoście), co serwer atakowany;

3) Funkcjonalność ochrony przed atakami kierowanymi na serwer w warstwie sieciowej musi być dostarczona w ramach agenta zainstalowanego na chronionym serwerze lub bezagentowo poprzez integrację z technologią VMware z technologią NSX-T, lub równoważnej;

4) W przypadku ochrony bezagentowej wydajność sytemu IPS musi wynosić co najmniej 10Gps dla każdego chronionego hosta wirtualnego;

5) System musi posiadać funkcjonalność przełączania pomiędzy trybem blokowania ruchu i trybem detekcji zdarzeń w sposób globalny dla wszystkich reguł;

6) System musi posiadać funkcjonalność ciągłego, bieżącego i automatycznego wykrywania ataków typu SQL injection oraz cross-site-scripting wraz z możliwością ustanowienia progów alarmów;

7) System musi posiadać moduł zapewniający blokowanie transmisji na podstawie zdefiniowanej charakterystyki ruchu poprzez sygnatury lub zdefiniowane ciągi znaków;

8) System musi posiadać możliwość automatycznego uruchamiania dla chronionych serwerów tzw. wirtualnych poprawek, pozwalających na ochronę przed atakami wykorzystującymi podatności systemów operacyjnych i aplikacji do czasu zainstalowania standardowych poprawek producenta i restartu systemów;

9) W przypadku ochrony agentowej polityka w zakresie uruchamiana tzw. wirtualnych poprawek musi być tworzona automatycznie, indywidualnie dla każdego chronionego zasobu bazując na analizie jego wersji, zainstalowanych poprawkach bezpieczeństwa i zainstalowanym oprogramowaniu. Taka analiza i optymalizacja polityki musi być wykonywana co najmniej raz na dobę, a strojenie polityki musi się odbywać zaraz po zakończeniu analizy;

10) W przypadku ochrony agentowej System musi mieć możliwość wykonania dla każdego serwera skanu podatności, oraz wygenerowania raportu o wykrytych podatnościach, i przedstawienia w formie jednego dokumentu, informacji dotyczących wykrytych podatności oraz uruchomionych wirtualnych patchy w agentowym systemie klasy IPS;

11) W przypadku ochrony bezagentowej, co najmniej dla systemów z rodziny Windows Serwer 2012 i nowszych, System musi mieć możliwość wykonania dla każdego serwera skanu podatności, oraz wygenerowania raportu o wykrytych podatnościach, oraz zestawienia w formie jednego dokumentu, w którym będą się znajdować informacje dotyczące wykrytych podatności oraz uruchomionych wirtualnych patchy w bezagentowym systemie klasy IPS. Raport oraz zestawienie musi być wykonane w czasie nie dłuższym niż 15 min od momentu zakończeniu zadania skanowania podatności;

12) Zarówno w przypadku ochrony agentowej jak i bezagentowej, wynik skanowania podatności na serwerach powinien zawierać co najmniej: nazwę wykrytej podatności, jej krytyczność, charakterystykę oraz numer CVE, jeżeli dla danej podatności został nadany;

13) W przypadku ochrony agentowej wydajność mechanizmu skanowania podatności musi umożliwiać przeskanowanie każdego objętego ochroną systemu z rodziny Windows serwer co najmniej raz na dobę;

30

14) W przypadku ochrony bezagentowej wydajność mechanizmu skanowania podatności musi umożliwiać przeskanowanie każdego objętego ochroną systemu z rodziny Windows serwer co najmniej raz na 3 dni;

15) System musi posiadać dwukierunkowy stanowy firewall (stateful firewall) zapewniający izolację interfejsów bez konieczności restartów chronionych serwerów. Funkcjonalność ta powinna być dostarczana zarówno w ramach agenta zainstalowanego na chronionym serwerze lub bezagentowo;

16) W przypadku ochrony bezagentowej wydajność sytemu firewall musi wynosić co najmniej 10Gps dla każdego chronionego hosta wirtualnego;

17) Funkcjonalność firewall musi pozwalać na wykonanie miko-segmentacji sieci, w szczególności filtrowanie ruchu sieciowego pochodzącego z innych systemów wirtualnych znajdujących się na tym samym serwerze fizycznym;

18) System musi zapewniać wsparcie dla protokołu w wersjach: IPv4 i IPv6;19) System musi posiadać funkcjonalność ciągłej, bieżącej i automatycznej kontroli połączeń

wychodzących i przychodzących w komunikacji sieciowej z możliwością kontroli niestandardowych portów TCP (funkcjonalność definiowania na podstawie numeru protokołu oraz numeru typu ramki);

20) System musi posiadać funkcjonalność przełączenia trybu działania reguł firewall z trybu blokowania ruchu w tryb detekcji zdarzeń;

21) System musi zapewniać analizę ruchu sieciowego pod kątem występowania anomalii, w szczególności: zdeformowanych pakietów, brakujących flag;

22) System musi posiadać możliwość definiowania polityk firewall oraz IPS dla każdego serwera wirtualnego oddzielnie. Musi wykrywać zagrożenia i zabezpieczać przed nimi zarówno w ruchu sieciowym pomiędzy środowiskiem zwirtualizowanym a środowiskiem zewnętrznym jak i w ruchu wewnętrznym pomiędzy maszynami wirtualnymi.

23) System musi posiadać funkcjonalność inspekcji protokołu HTTPS bez konieczności instalacji dodatkowego oprogramowania.

3.8. Wymagania dotyczące raportowania

1) System musi umożliwiać generowanie raportów dotyczących zdarzeń i incydentów związanych z działaniem każdego z mechanizmów bezpieczeństwa stanowiących część wdrażanego Systemu. W szczególności System musi umożliwiać generowanie raportów dotyczących:a) wykrytego i zablokowanego na objętych ochroną serwerach niebezpiecznego kodu,b) wykrytych na objętych ochroną serwerach podatności,c) wykrytych i zablokowanych na objętych ochroną serwerach ataków sieciowych, w

tym ataków wykorzystujących podatności,d) wykrytych na objętych ochroną serwerach zdarzeń naruszenia polityki

monitorowania integralności,e) wykrytych na objętych ochroną serwerach zdarzeń naruszenia polityki kontroli

aplikacji,f) wykrytej na objętych ochroną serwerach komunikacji do domen skalsyfikowanych,

jako niebezpieczne;2) System musi umożliwiać generowanie raportu, w którym zostanie przedstawione

zestawienie wszystkich wykrytych podatności na objętych ochroną serwerach oraz oraz

31

zainstalowanych w środowisku wirtualnych patchy mających za zadanie chronić serwery przed atakami wykorzystującymi zidentyfikowane podatności.

3) System musi umożliwiać generowanie raportów, co najmniej w formacie PDF;4) System musi umożliwiać generowanie raportów na żądanie oraz cyklicznie według

zdefiniowanego harmonogramu;5) System musi umożliwiać automatyczne wysyłanie wygenerowanych raportów na

wskazany adres e-mail.

3.9. Węzeł laboratoryjny.

Węzeł laboratoryjny musi odzwierciedlać pod kątem funkcjonalnym wszystkie elementy Systemu wdrożone w ramach realizacji przedmiotu zamówienia. Wydajność Węzła laboratoryjnego musi być zgodna z tabelą zamieszczoną w pkt. 3.3.4 „Wymagania wydajnościowe na Węzeł laboratoryjny”. Węzeł laboratoryjny zostanie zainstalowany na Zwirtualizowanej infrastrukturze obliczeniowej Zamawiającego zlokalizowanej w Warszawie.

W ramach wdrożenia Węzła laboratoryjnego Wykonawca jest zobowiązany do dostarczenia co najmniej 16 kompletnych licencji (CPU i CAL) na system operacyjny Windows Server 2019, co najmniej w wersji Standard.

3.10. Integracje z systemami Zamawiającego3.10.1. System Fault Management

Wykonawca jest zobowiązany do integracji Systemu z systemami Fault Management w celu zapewnienia poprawnego funkcjonowania oraz monitorowania Systemu z wykorzystaniem protokołów SYSLOG i SNMP (w tym SNMP Trap). Szczegółowy zakres integracji zostanie doprecyzowany na etapie tworzenia Dokumentacji Technicznej.

3.10.2. System Performance Management

Wykonawca jest zobowiązany do integracji Systemu z systemami Performance Management z wykorzystaniem co najmniej protokołu SNMP, w zakresie monitorowania i pobierania co najmniej następujących danych:

a) Pesistent Conectionsb) CPU – Idle timec) CPU – current overall CPU usaged) Memory – Total Freee) Memory – Total Realf) Memory – Avail. Swapg) Storage – disk usage

32

3.10.3. System Inventory

Wykonawca jest zobowiązany do integracji Systemu z systemem Inventory z wykorzystaniem co najmniej protokołu SNMP. W ramach integracji Zamawiający zamierza pobierać w sposób automatyczny co najmniej następujące dane:

a) Numer seryjny komponentu Systemu,b) Producent, model komponentu Systemu,c) Wersje oprogramowania,d) MAC adresy przypisane interfejsów sieciowych.

Szczegółowy zakres integracji zostanie określony na etapie tworzenia Dokumentacji Technicznej.

3.10.4. System Config Management

Wykonawca jest zobowiązany do integracji Systemu z systemem Config Management z wykorzystaniem co najmniej SNMP, bezpośredniej komunikacji z komponentami Systemu, co najmniej poprzez protokół SSH. Zakres integracji zakłada pobieranie przez system Config Management informacji dotyczących konfiguracji każdego z elementów Systemu i utrzymywanie go jako repozytorium aktualnej konfiguracji systemów.

Szczegółowy zakres integracji zostanie określony na etapie tworzenia Dokumentacji Technicznej.

3.10.5. System SIEM

System musi posiadać możliwość integracji z systemami typu SIEM w zakresie przekazywania zdarzeń do wskazanego przez Zamawiającego kolektora SIEM. Zamawiający zakłada, że czas buforowania zdarzeń przed przekazaniem ich do Systemu SIEM nie będzie dłuższy niż 48h. System zarządzający będzie przekazywał do Systemu SIEM zdarzenia o wszystkich akcjach administratorów Systemu.

Szczegółowy zakres integracji, w tym poziomy logowania, zostanie określony na etapie tworzenia Dokumentacji Technicznej.

System zamawiającego musi mieć pełną możliwość integracji z system klasy SIEM.

33