Załącznik nr 1 Dostawa systemu równoważenia obciążenia serwerów aplikacyjnych, zapewniającego ich stałą dostępność oraz przeciwdziałanie naruszeniom protokołów w ruchu web. Wymagane jest aby system składał się z co najmniej następujących elementów: 1. Klaster urządzeń realizujących równoważenie obciążenia serwerów i zapewnienia stałej dostępności zwany dalej w opisie także klastrem 2. Klaster urządzeń przeciwdziałających naruszeniom protokołów w ruchu web składający się z co najmniej: dwóch urządzeń wykonawczych i dwóch urządzeń zarządzających zwany dalej w opisie także klastrem Wymagania dotyczące poszczególnych części: 1. Klaster urządzeń realizujących równoważenie obciążenia serwerów i zapewnienia stałej dostępności a. Klaster musi realizować co najmniej następujące funkcje: i. Rozkład ruchu pomiędzy serwerami aplikacji Web ii. Selektywny http caching iii. Selektywna kompresja danych iv. Terminacja sesji SSL v. Filtrowanie pakietów b. Wszystkie wymienione w punkcie a) funkcje muszą być dostępne w obrębie jednego urządzenia c. Klaster musi posiadać co najmniej następujące metody równoważenia obciążenia: i. Cykliczna ii. Ważona iii. Najmniejsza liczba połączeń iv. Najszybsza odpowiedź serwera v. Najmniejsza liczba połączeń i najszybsza odpowiedź serwera vi. Najmniejsza liczba połączeń i najszybsza odpowiedź serwera w zdefiniowanym czasie vii. Dynamicznie ważona oparta na SNMP/WMI viii. Definiowana na podstawie grupy priorytetów dla serwerów d. Urządzenia w klastrze muszą posiadać wbudowany w system operacyjny urządzenia język skryptowy, posiadający co najmniej następujące cechy: i. Analiza, zmiana oraz zastępowanie parametrów w nagłówku http oraz w zawartości (polu danych) ii. Obsługa protokołów: http, tcp, xml, rtsp, sip iii. Funkcja inspekcji protokołów LDAP oraz RADIUS e. Musi istnieć możliwość modyfikacji metod równoważenia obciążenia pomiędzy serwerami przy wykorzystaniu wbudowanego języka skryptowego f. Urządzenia muszą być dostarczone z nieodpłatną, specjalizowaną aplikacją do analizy poprawności składni skryptów pisanych przy wykorzystaniu języka skryptowego opisanego w punkcie d. Aplikacja musi posiadać wbudowane
szablony skryptów oraz funkcję auto uzupełniania wpisywanych komend. Aplikacja musi być tego samego producenta co urządzenia. g. Klaster musi pracować w trybie pełnego proxy h. Klaster musi posiadać programowalny interfejs API do integracji z zewnętrznymi systemami oraz automatyzacji wykonywania operacji i. Klaster musi posiadać co najmniej następujące interfejsy administracyjne: i. GUI przy wykorzystaniu protokołu https ii. Zarządzanie poprzez SSH iii. Zarządzanie poprzez SOAP-SSL j. Autoryzacja administratorów klastra musi bazować na rolach użytkowników k. Klaster musi posiadać funkcje (tworzone przez administratora systemu przy wykorzystaniu języka skryptowego z punktu d) przywiązywania sesji (Session persistence) przy wykorzystaniu co najmniej następujących atrybutów: i. Cookie (hash, rewrite, custom, insert, passive) ii. Adres źródła iii. SIP call ID iv. Identyfikator sesji SSL v. Microsoft Terminal Services (RDP) nazwa użytkownika vi. Adres docelowy l. Klaster musi posiadać funkcję sprawdzania dostępności usług (ang. health monitoring) przy wykorzystaniu co najmniej następujących metod: icmp, echo (port 7/TCP), zapytanie MS SQL, zapytanie Oracle, sprawdzanie odpowiedzi poprzez wyszukiwanie wyrażeń regularnych, TCP half-open, wykorzystanie protokołów: http, https, ftp, sip, nntp, smb, pop3, imap, smtp, ssl, radius. Dodatkowo musi istnieć możliwość wykorzystania skryptów do tworzenia złożonych monitorów sprawdzających aktywność usług. m. Klaster musi posiadać funkcję definiowania maksymalnej ilości obsługiwanych przez dany serwer połączeń, w przypadku przekroczenia zdefiniowanej wartości musi istnieć możliwość wysłania klientowi strony błędu lub przekierowania klienta na inny serwer. n. Klaster musi obsługiwać sieci VLAN w standardzie 802.1q o. Klaster musi obsługiwać agregację linków w standardzie 802.3ad (LACP) p. Klaster musi świadczyć co najmniej następujące usługi w warstwach 4-7: i. Inspekcja warstwy aplikacji, w tym inspekcja nagłówka http ii. Ukrywanie zasobów iii. Zmiana odpowiedzi serwera iv. Przepisywanie odpowiedzi (response rewriting) v. Ochrona przed atakami typu DoS/DDoS vi. Ochrona przed atakami typu SYN Flood vii. Multipleksowanie połączeń http q. Klaster musi posiadać następujące funkcje zarządzania siecią: i. Obsługa protokołu SNMP v1/v2c/v3 ii. Zewnętrzny syslog iii. Zbieranie danych i ich wyświetlanie iv. Zbieranie danych zgodnie z ustawieniami administratora v. Osobny default gateway dla interfejsu zarządzającego vi. Wsparcie dla przynajmniej 2 wersji oprogramowania (multi-boot) vii. Zapisywanie konfiguracji (możliwość szyfrowania i eksportu kluczy)
viii. Dedykowany podsystem monitorowania stanu pracy urządzenia z funkcjami restartu, wstrzymania oraz sprzętowego resetu systemu. r. Klaster musi posiadać funkcję integracji z zewnętrznymi serwerami uwierzytelnienia użytkowników LDAP, RADIUS, TACACS. s. Klaster musi posiadać funkcję definiowania i edycji szablonów konfiguracji aplikacji web. Szablony powinny służyć do optymalizacji procesu wdrażania systemu zarówno dla znanych aplikacji biznesowych, jak i własnych aplikacji web. W ramach opisanych szablonów musi istnieć możliwość automatycznej kontroli poszczególnych elementów konfiguracji szablonu i zabezpieczenie ich przed modyfikacją i usunięciem. t. Klaster musi posiadać moduł analizy ruchu http. Moduł musi zbierać co najmniej następujące metryki: i. Czas odpowiedzi per serwer ii. Czas odpowiedzi per URI iii. Ilość sesji użytkownika iv. Przepustowość v. Adres źródła vi. Kraj vii. User Agent (wykorzystywana przez klienta aplikacja) viii. Metoda dostępu u. System musi posiadać funkcję walidacji certyfikatów klientów łączących się przy wykorzystaniu protokołu SSL. v. System musi posiadać funkcjonalność SSL VPN co najmniej dla 10 równolegle pracujących użytkowników. w. System musi posiadać moduł pozwalający na analizę działania aplikacji a w szczególności powinien udostępniać informacje dotyczące: i. opóźnienia odpowiedzi serwerów aplikacyjnych ii. adresów URL odpytywanych przez klientów iii. kodów odpowiedzi HTTP zwracanych przez aplikację iv. adresów IP klientów łączących się do aplikacji x. Każde urządzenie sieciowe w klastrze musi co najmniej spełniać wymogi przedstawione w poniższej tabeli lp parametr wymagania 1 Przepływność 5 Gbps 2 Ilość jednocześnie obsługiwanych połączeń 3 Ilość transakcji SSL na sekundę 4 Ilość jednocześnie obsługiwanych połączeń SSL 5 Przepływność ruchu szyfrowanego 5 000 000 20 000 900 000 3,5 Gbps
6 Ilość jednoczesnych połączeń na sekundę w warstwie 4 130 000 7 Kompresja danych Z wydajnością 3,5 Gbps realizowaną na dedykowanym module sprzętowym 8 Interfejsy sieciowe Osiem interfejsów 10/100/1000 Base-T, 2 interfejsy umożliwiające obsadzenie wkładkami SFP+, oddzielny interfejs zarządzania. Jeden interfejs SFP+ musi być obsadzony wkładką SFP 1Gb-SX. 9 Obudowa Przeznaczona do zamontowania w szafie RACK 19, nie większa niż 2U 10 Zasilanie Dwa redundantne wewnętrzne zasilacze 230VAC 2. Klaster urządzeń przeciwdziałających naruszeniom protokołów w ruchu web a. Klaster musi się składać z następujących elementów całkowicie niezależnych fizycznie: i. Dwa urządzenia wykonawcze działające w klastrze ii. Dwa urządzenia zarządzające działające w klastrze b. Wszystkie urządzenia wchodzące w skład klastra jak również oprogramowanie wykonawcze i zarządzające muszą pochodzić od jednego producenta c. Minimalne wymagania pojedynczego urządzenia wykonawczego: lp parametr wymagania 1 Wymagane tryby pracy - Transparent in-line (2 warstwa ISO/OSI) - Transparent Reverse Proxy - Reverse Proxy - Sniffing 2 Ilość i rodzaj interfejsów sieciowych 6 portów 10/100/1000 Ethernet, w tym 2 porty do zarządzania 3 Wydajność - przepływność 500Mbps - 20 000 transakcji http na sekundę 4 Funkcjonalność zapewniająca niezawodność wbudowany fizyczny bypass dla interfejsów inspekcyjnych pracujących w trybie Transparent in-line 5 Obudowa Przeznaczona do zamontowania w szafie RACK 19. Wysokość nie większa niż 1U. 6 Zasilanie 230VAC
d. Minimalne wymagania pojedynczego urządzenia zarządzającego: lp parametr wymagania 1 Ilość i rodzaj interfejsów sieciowych 2 porty 10/100/1000 Ethernet 2 Obudowa Przeznaczona do zamontowania w szafie RACK 19. Wysokość nie większa niż 1U. 3 Zasilanie 230VAC e. Klaster musi zawierać co najmniej następujące mechanizmy ochrony: i. Stateful Firewall ii. Weryfikacja zgodności komunikacji sieciowej ze standardem protokołu tcp/ip, opisanym w RFC iii. Sieciowy system ochrony przed intruzami bazujący na sygnaturach ataków. Wymagane są sygnatury dla nie mniej niż: 1. Sieci 2. Aplikacji Web 3. Zapytań Web iv. Wykrywanie znanych oraz nieznanych robaków sieciowych poprzez analizę heurystyczną v. Automatyczne tworzenie i aktualizowanie profili aplikacji Web oraz wykrywanie przy ich użyciu naruszeń bezpieczeństwa. Profil aplikacji Web musi być budowany w sposób automatyczny poprzez analizę ruchu sieciowego. Musi istnieć możliwość automatycznej aktualizacji profilu w przypadku wystąpienia zmiany w strukturze aplikacji. Profil musi uwzględniać nie mniej niż następujące elementy: katalogi, URLe, cookies, metody dostępu, parametry, typy znaków oraz wartości minimalne/maksymalne wpisywane przez użytkowników w poszczególnych polach formularza. Dodatkowo system musi posiadać możliwość sprawdzenia, które z wykorzystywanych pól są typu readonly i nie mogą być zmieniane przez klientów. vi. Wykrywanie złożonych ataków poprzez mechanizm korelacji wielu zdarzeń. Mechanizm musi umożliwiać definiowanie reguł polityki bezpieczeństwa przy uwzględnieniu co najmniej następujących kryteriów: nagłówki http, źródłowy adres IP, identyfikator sesji lub nazwy użytkownika, ilość wystąpień w określonym przez administratora takcie czasu, elementy aplikacji (URL-e, parametry), nazwa aplikacji klienta, akceptowany język przeglądarki, rozmiar zwróconej strony oraz czas odpowiedzi serwera Web. vii. Identyfikacja nazw użytkowników aplikacji web oraz umieszczanie informacji o użytkowniku w logach, a także możliwość pisania reguł polityki bezpieczeństwa z uwzględnieniem atrybutu username.
Obsługiwane muszą być nie mniej niż następujące metody uwierzytelnienia: formularze html, certyfikat cyfrowy, kerberos, NTLM. Musi istnieć możliwość integracji z zewnętrznymi serwerami (Active Directory, LDAP, SQL, import plików CSV z zewnętrznych systemów) w celu uzyskania dodatkowych informacji w logach na temat źródła oraz jako kryterium dla reguł polityki bezpieczeństwa. f. Wszystkie funkcjonalności opisane w punkcie e. muszą być dostępne w ramach pojedynczej licencji dostarczonej łącznie z urządzeniem g. Minimum 3 letni dostęp do serwisu internetowego producenta ( serwis reputacyjny ) udostępniającego listy niebezpiecznych adresów IP w sieci Internet. Baza adresów IP musi być pogrupowana według zagrożeń a także automatycznie aktualizowana we współpracy z zewnętrznymi dostawcami. Wykrywane muszą być co najmniej następujące zagrożenia: wrogie adresy IP, z których wykonywane są ataki, podszywające się strony (ataki phishing), adresy sieci TOR, anonimowe proxy maskujące tożsamość użytkowników h. Dostęp i konfiguracja do opisanego w punkcie g. serwisu reputacyjnego musi odbywać się bez restartu urządzeń. Funkcjonalność ta musi być dostępna bez osobnych licencji lub jeśli licencje są potrzebne to mają być na tą funkcjonalność dostarczone. i. System musi posiadać możliwość identyfikacji incydentów typu web scraping poprzez zliczanie ilości odwołań do oddzielnych części serwisu, wykrywania malware poprzez integrację z systemami fraud prevention oraz identyfikację ataków z sieci Bot dzięki wykorzystaniu skryptów java wykonywanych w przeglądarce klienta. j. System musi posiadać możliwość rejestrowania naruszeń bezpieczeństwa oraz udostępniać administratorom co najmniej następujące informacje o zdarzeniach: nazwa użytkownika aplikacyjnego (jeżeli klient zalogował się w systemie przez aplikację Web) oraz zapytanie HTTP przesłane do serwera aplikacji Web. Musi istnieć możliwość rejestrowania kodu źródłowego strony zwracanej klientowi przez aplikację Web. k. System musi posiadać mechanizm ochrony oraz profilowania serwisów Web, uwzględniając elementy XML oraz akcje SOAP. l. System musi analizować zarówno zapytania http jak i odpowiedzi w celu wykrycia nadużyć oraz wycieku danych m. System musi posiadać następujące metody reakcji na incydenty: i. W trybie in-line: 1. Blokowanie pakietu 2. Blokowanie źródła ataku w postaci adresu IP, nazwy użytkownika lub sesji (jeżeli użytkownik uwierzytelnił się w systemie) ii. W trybie nasłuchu: 1. Wysyłanie pakietu TCP RST do klienta oraz serwera n. System musi posiadać funkcję wysyłania informacji o zdarzeniach: poprzez protokół SNMP, syslog (wymagane gotowe formaty CEF oraz RSA envision),
poprzez zgłoszenia do systemu Remedy oraz wiadomość e-mail. Musi istnieć możliwość wysłania wielu powiadomień do różnych serwerów przy wystąpieniu jednego incydentu o. Musi istnieć możliwość uruchomienia skryptu shell w przypadku wykrycia incydentu. p. System musi posiadać gotowe raporty dotyczące i. Alarmów bezpieczeństwa ii. Zdarzeń systemowych iii. Zmian w profilach aplikacji. q. Musi istnieć możliwość tworzenia własnych raportów, zarówno w formie tekstowej jak i prezentacji graficznej. r. System musi posiadać funkcję korzystania ze źródłowego adresu IP przekazywanego w nagłówku http X-Forwared-For, umożliwiającą identyfikację w alarmach zabezpieczeń oryginalnego adresu źródłowego w przypadku wdrożenia systemu za serwerem typu proxy. s. Musi być zapewniona możliwość aktualizacji co najmniej: sygnatury ataków, listy reguł polityki bezpieczeństwa oraz listy raportów. Jeśli na funkcjonalność tą potrzebna jest licencja wymaga się dostarczenie takowej. Musi być możliwość automatycznego i ręcznego pobierania aktualizacji. Ze względu na specyfikę pracy musi być możliwość wykorzystania osobnego serwera proxy do pobierania aktualizacji. t. W celu zautomatyzowania procesu definiowania reguł polityki bezpieczeństwa bazujących na wynikach działania skanera zabezpieczeń musi być możliwość integracji z co najmniej następującymi skanerami zabezpieczeń: IBM AppScan, HP WebInspect, Cenzic, WhiteHat Security, Qualys, NT Objectives. Funkcjonalność ta musi być dostępna bez osobnych licencji lub jeśli licencje są potrzebne to mają być na tą funkcjonalność dostarczone. u. Pracując w trybie transparentnym In-line urządzenia wykonawcze muszą gwarantować opóźnienie nie większe niż 1 milisekunda. v. Klaster zabezpieczeń musi być zbudowany w architekturze klastra urządzeń wykonawczych, pracującego w trybie active backup. Konfiguracja oraz zarządzanie klastrem musi odbywać się poprzez centralny moduł zarządzania (połączony z dwóch urządzeń również w klaster). w. Zarządzanie systemem musi odbywać się poprzez interfejs przeglądarki Web. x. Konfiguracja oraz logi muszą być przechowywane na centralnym serwerze zarządzania. 3. Minimalne warunki serwisu i wsparcia serwisowego: a. Na każde dostarczone urządzenie wymagane jest zapewnienie udzielenia gwarancji i wsparcia serwisu przez okres minimum 3 lat. b. Gwarancja i wsparcie musi obejmować minimum naprawę/wymianę urządzeń w przypadku awarii, obsługę problemów technicznych, dostęp do aktualizacji oprogramowania oraz dokumentacji technicznej urządzeń. c. W przypadku awarii pierwszego elementu klastra wykonawca musi zapewnić naprawę/wymianę urządzenia w ciągu 5 dni roboczych. Jeśli naprawa lub
wymiana urządzenia nie jest możliwa w tym terminie to wykonawca musi zapewnić urządzenie zastępcze. d. W przypadku jednoczesnej awarii drugiego urządzenia w klastrze wykonawca musi zapewnić naprawę/wymianę urządzenia lub urządzenie zastępcze w ciągu 24 godzin od zgłoszenia. e. Wsparcie serwisowe wykonawcy w miejscu zainstalowania urządzenia w zakresie konfiguracji, administracji, rozwiązywania problemów eksploatacyjnych w okresie trwania gwarancji w liczbie minimum 60 godzin (nie wlicza się czasu dojazdu oraz ilości osób zapewniających wsparcie). 4. Wymagania odnośnie szkoleń: W ramach wsparcia serwisowego wykonawca zapewni minimum 5 dniowe szkolenie dla co najmniej dwóch pracowników zamawiającego w miejscu posiadającym odpowiednią infrastrukturę na przeprowadzenie warsztatów z zaoferowanych technologii. Jeżeli miejsce szkolenia znajduje się poza Krakowem, wykonawca musi zapewnić odpowiednią bazę noclegową. 5. Wdrożenie: Wykonawca zobowiązany jest do wykonania następujących usług instalacyjno wdrożeniowych a. Przygotowanie projektu wdrożeniowego, zawierającego szczegółowy harmonogram wdrożenia, konfigurację zaoferowanych urządzeńschemat instalacji w sieci, opis poszczególnych reguł wraz z ich uzasadnieniem. b. Fizyczny montaż urządzeń w szafie rack. c. Konfiguracja sieciowa urządzeń. d. Konfiguracja klastrów urządzeń wraz z testami. e. Instalacja i konfiguracja serwerów. f. Przypisanie klas ruchu do serwerów. g. Konfiguracja akceleracji SSL. h. Konfiguracja http caching oraz akceleracji ruchu http. i. Konfiguracja mechanizmów przypisywania sesji (Session persistence). j. Konfiguracja mechanizmów równoważenia obciążenia serwerów. k. Konfiguracja mechanizmów wykrywania nieprawidłowych odpowiedzi (sprawdzania dostępności usług (ang. health monitoring)) oraz przekierowania ruchu na serwery sprawne. l. Włączenie ochrony sygnatur. m. Konfiguracja ochrony przed atakami synflood, DoS/DDoS. n. Włączenie urządzenia w tryb samouczenia. o. Monitoring i sprawdzenie ruchu. p. Konfiguracja serwisu reputacyjnego. q. Modyfikacja i akceptacja polityki działania urządzeń. r. Przełączenie urządzenia w tryb ochrony. s. Konfiguracja logowania. t. Wykonanie dokumentacji powdrożeniowej.