WSF.2. Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka

Transkrypt

1 Załącznik nr 2 do SIWZ znak sprawy:23/di/pn/2013 Szczegółowy opis, zakres i warunki realizacji przedmiotu zamówienia 1. Przedmiotem zamówienia jest dostawa 8 licencji oprogramowania Oracle API Gateway lub rozwiązania równowaŝnego W ramach zamówienia konieczne jest dostarczenie licencji oprogramowania typu firewall usług sieciowych umoŝliwiającego filtrowanie złośliwych lub niebezpiecznych Ŝądań w warstwie usług sieciowych. 3. Dostarczone licencje umoŝliwią zainstalowanie i uruchomienie bezpośrednio w systemie operacyjnym serwerów posiadanych przez Zamawiającego, bez pośrednictwa warstwy wirtualizacji. Dostarczone licencje powinny umoŝliwiać uruchomienie jednocześnie na dwóch maszynach fizycznych x86, kaŝda posiadająca 8 rdzeni CPU oraz 16 GB pamięci. 4. Konieczne jest dostarczenie licencji umoŝliwiających uruchomienie dwóch klastrów: produkcyjnego oraz testowego. KaŜdy z klastrów powinien składać się z przynajmniej dwóch instancji oprogramowania. Instancje kaŝdego z klastrów powinny działać jednocześnie na kaŝdej z dwóch maszyn. 5. Dostarczone licencje umoŝliwią uŝytkowanie nieograniczone wolumetrycznie. W szczególności nie moŝe być ograniczona liczba przetwarzanych Ŝądań i liczba uŝytkowników. 6. Dostarczone licencje obsłuŝą przynajmniej 400 Ŝądań na sekundę przy załoŝeniu wykorzystania protokołu SOAP/HTTP. Przesyłane komunikaty mają średni rozmiar 10 kb i wykorzystują mechanizm WS Security x509 Token Profile do uwierzytelniania i weryfikacji podpisu pod całym komunikatem SOAP. WdroŜone rozwiązanie powinno przy takim obciąŝeniu utylizować procesory najwyŝej w 70%. 7. Minimalne wymagania oprogramowania typu firewall usług sieciowych jakie musi spełniać w zakresie: Identyfikator wymagania Minimalne wymagania techniczne i funkcjonalne: Podstawowej funkcjonalności moŝliwości integracyjne WSF.1 MoŜliwość wirtualizacji API usług, które mapowane są na usługi źródłowe w celu wprowadzenia izolacji klientów od implementacji. WSF.1 MoŜliwość wirtualizacji portów mapowanych na rzeczywiste porty i serwery. 1 O ile inaczej nie zaznaczono, wszelkie zapisy dotyczące parametrów oprogramowania typu firewall usług sieciowych naleŝy odczytywać, jako parametry minimalne. UŜyte sformułowania lub równowaŝne oznaczają, Ŝe Zamawiający dopuszcza rozwiązania posiadające cechy i funkcjonalności takie same lub lepsze w stosunku do określonych. Pod pojęciem rozwiązań równowaŝnych Zamawiający rozumie takie rozwiązania w oprogramowaniu, które posiadają parametry techniczne i funkcjonalne co najmniej równe do określonych w niniejszym dokumencie. Zgodnie z art. 30 ust. 5 ustawy Pzp Wykonawca, który powołuje się na rozwiązania równowaŝne opisywanym przez Zamawiającego, jest obowiązany wykazać, Ŝe oferowane przez niego dostawy, usługi spełniają wymagania określone przez zamawiającego. 1

2 WSF.2 WSF.3 1. MoŜliwość statycznej i dynamicznej walidacji schematów, 2. MoŜliwość dynamicznego wyboru XSD do walidacji, 3. MoŜliwość dynamicznego sprawdzania schematów przechowywanych na zewnątrz. Wsparcie dla następujących protokołów na wejściu, wyjściu i w trakcie tłumaczenia : HTTP i HTTPS, FTP, FTPS, i SFTP, JMS, Raw TCP/IP, SMTP, POP3. WSF.4 Wsparcie dla następujących standardów na wejściu, wyjściu i w trakcie tłumaczenia: SOAP 1.1 i 1.2, SOAP with Attachments, WSDL 1.1 i 2.0, Plain XML (POX), XPath 2.0, XQUERY 1.0, XSLT 2.0, WS-Addressing 1.0, WS-Policy 1.2 and 1.5. WSF.5 Wsparcie dla róŝnego rodzaju zawartości: wiadomości binarne, XML, dane strukturalne i niestrukturalne. WSF.6 Wsparcie transformacji XML przy uŝyciu XSLT. Rozwiązanie nie moŝe korzystać z XSLT do innych zadań niŝ transformacji XML a. WSF.7 Wsparcie dla interfejsów REST i JSON. WSF.8 Rozwiązanie musi umoŝliwiać walidację wiadomości JSON względem schematu JSON. WSF.9 Rozwiązanie musi umoŝliwiać odczytanie pojedynczego elementu z wiadomości JSON w oparciu o zdefiniowaną ścieŝkę. WSF.10 Rozwiązanie musi pozwalać na automatyczne tłumaczenie wiadomości z JSON na XML oraz z XML na JSON. WSF.11 MoŜliwość tworzenia API w technologii REST dla usługi źródłowej SOAP. WSF.12 Rozwiązanie musi posiadać moŝliwość integracji z rejestrem usług zgodnym z UDDI v3.0. Podstawowej funkcjonalności bezpieczeństwo WSF.13 MoŜliwość detekcji typów MIME załączników w SOAP. WSF.14 MoŜliwość detekcji załączników SOAP które są nie zgodne z definicją bezpieczeństwa (np. pliki wykonywalne). WSF.15 Wykrywanie głęboko zagnieŝdŝonych Ŝądań XML. WSF.16 Wykrywanie Ŝądań XML zawierających nadmierną ilość atrybutów wskazującą na moŝliwość ataku na poziomie zawartości wiadomości. WSF.17 Detekcja dobrze sformatowanych ale zbyt duŝych wiadomości XML. MoŜliwość limitowania wielkości dokumentów XML włączając lub wyłączając 2

3 załączniki. WSF.18 MoŜliwość zablokowania odniesień do arbitralnych lokalizacji SchemaLocation schematów zdefiniowanych w WSDL. WSF.19 Detekcja ataków typu SQL injection i XPATH injections. WSF.20 MoŜliwość zamiany standardowych informacji o błędach własnymi dowolnie zdefiniowanymi komunikatami. WSF.21 MoŜliwość limitowania liczby wiadomości w określonym okresie czasu (sekundy, minuty, godziny, dni). MoŜliwość limitowania liczby równoległych połączeń do wybranych usług. WSF.22 MoŜliwość wykrywania ataków typu reply na pojedynczej instancji i w klastrze. WSF.23 MoŜliwość wykrywania wirusów w wiadomościach. WSF.24 Gotowa integracja z oprogramowaniem anty wirusowym takim jak: McAfee, Sophos, ClamAV. WSF.25 MoŜliwość skanowania w poszukiwaniu słów i wyraŝeń regularnych w celu minimalizacji ryzyka udostępnienia poufnych danych. WSF.26 MoŜliwość uruchomienia w trybie tylko przeglądania ruchu. WSF.27 MoŜliwość usuwania, podmiany, szyfrowania, maskowania (pełnego i częściowego) poufnych informacji. WSF.28 Detekcja wyjątkowo wysokich aktywności mogących potencjalnie stanowić skanowanie w poszukiwania informacji. Generowanie alarmów i informowanie o wykryciu podobnych sytuacji. WSF.29 MoŜliwość cyfrowego podpisywania komunikatów i ich szyfrowania. WSF.30 MoŜliwość cyfrowego podpisywania dokumentów XML. MoŜliwość uŝycia XPath do specyfikacji części komunikatu XML do podpisania. Wsparcie dla rekomendacji W3C XML Signature. WSF.31 MoŜliwość weryfikacji cyfrowego podpisu dokumentu XML. WSF.32 MoŜliwość wykrycia modyfikacji cyfrowo podpisanej widomości. WSF.33 MoŜliwość szyfrowania i odszyfrowywania wiadomości XML Wsparcie dla standardu WS-- Security i XML Encryption. WSF.34 Wsparcie dla co najmniej następujących algorytmów szyfrujących: 3DES AES RSA PGP MoŜliwość uŝycia własnych algorytmów. WSF.35 Wsparcie dla algorytmów kryptograficznych opartych o elliptic curve takich jak EC DSA. WSF.36 MoŜliwość cyfrowego podpisywania i weryfikacji nagłówków WS-- Addressing. WSF.37 MoŜliwość wykorzystania HSM do szyfrowania i cyfrowego podpisywania. WSF.38 MoŜliwość weryfikacji waŝności certyfikatu w oparciu o CRL. WSF.39 MoŜliwość pobierania CRL z zewnętrznego repozytorium - katalogu LDAP. WSF.40 Wsparcie dla jedno i dwu kierunkowego SSL. WSF.41 Wsparcie dla jedno i dwu kierunkowego TLS. Podstawowej funkcjonalności Kontrola dostępu i zarządzanie toŝsamością 3

4 WSF.42 WSF.43 WSF.44 WSF.45 WSF.46 WSF.47 WSF.48 WSF.49 WSF.50 WSF.51 WSF.52 WSF.53 WSF.54 WSF.55 Blokowanie dostępu z nieautoryzowanego adresu IP lub podsieci. Blokowanie dostępu z adresu na liście blacklist adresów lub podsieci. MoŜliwość udostępniania usług tylko dla maszyn o adresach lub sieciach z listy whitelist. MoŜliwość kombinacji funkcjonalności blacklist i whitelist dla bardziej złoŝonych wymagań. Egzekwowanie polityk uwierzytelniania. MoŜliwość delegowania decyzji o uwierzytelnianiu do zewnętrznych systemów. Uwierzytelnianie w oparciu o następujące metody: HTTP Basic i HTTP Digest, WS-Security Username Token oraz Binary Security Token, Asercje Security Assertion Markup Language (SAML), Certyfikaty X.509, Kerberos, tokeny OAuth, API key, JASON Web Token. Blokowanie prób dostępu opartych o niewłaściwe, stare, nie zaufane, znajdujące się na blacklist informacje uwierzytelniające. Wsparcie dla tokenów SAML dla asercji typu authentication, attribute, oraz authorization. Wsparcie dla SAML 1.2 oraz 2.0. Wsparcie dla następujących typów w OAuth: HTTP basic authentication, SAML bearer token, JWT bearer token, HMAC token. MoŜliwość integracji z rozwiązaniami katalogowymi LDAP v.3.0, RADIUS, katalogi wirtualne oraz Microsoft ActiveDirectory. MoŜliwość egzekwowanie szczegółowej polityki autoryzacji. MoŜliwość delegowania decyzji do zewnętrznych systemów autoryzacyjnych. MoŜliwość integracji z zewnętrznym systemem autoryzacji z oparciu o protokół XACML. MoŜliwość blokowania dostępu w oparciu o aktualny kontekst lub atrybuty np. pora dnia, ilość prób logowania, poprzednia lokalizacja. WSF.56 Wsparcie dla OAuth 2.0: Resources server, Authorization Server, Client. WSF.57 Wsparcie dla standardu WS-Trust. WSF.58 Mapowanie informacji o toŝsamości z wiadomości przychodzących na wiadomości wychodzące. WSF.59 MoŜliwość dodawania lokalnych atrybutów do uwierzytelnionej toŝsamości. Podstawowej funkcjonalności akceleracja przetwarzania 4

5 WSF.60 Przekazywanie wiadomości w oparciu o róŝne elementy takie jak toŝsamość klienta, treść wiadomości, format, rozmiar. WSF.61 MoŜliwość dynamicznych zmian w tabeli routingu w trakcie działania systemu. WSF.62 MoŜliwość routingu wiadomości w oparciu o informacje kontekstowe takie jak stan sieci, wielkość ruchu, historię dostępu. WSF.63 Throttling w klastrze gatewayów w oparciu o parametry takie jak: uŝytkownik, klient, atrybuty. WSF.64 MoŜliwość zarządzania ruchem wobec przyznanych limitów na grupie lub klastrze gatewayów.. WSF.65 MoŜliwość zmiany parametrów throttlingu bez wyłączania gatewaya. Dostępność strony webowej do administracji parametrów throtlingu. WSF.66 MoŜliwość monitorowania SLA i wysyłania powiadomień w przypadku spadku wydajności. WSF.67 MoŜliwość priorytetyzacji ruchu w oparciu o róŝne element i kontekst. WSF.68 Rozwiązanie musi posiadać dedykowany wysoko wydajny silnik procesowania XML. WSF.69 Rozwiązanie musi posiadać moŝliwość cache ownia na poziomie wiadomości, atrybutów, tokenów. W środowisku HA cache musi być rozłoŝony pomiędzy róŝne instancje. Zaawanasowanej funkcjonalności modelowanie polityk bezpieczeństwa WSF.70 Rozwiązanie musi posiadać dedykowane, graficzne środowisko, wspomagające uŝytkownika w projektowaniu, edycji i zarządzaniu politykami bezpieczeństwa. WSF.71 Środowisko graficzne musi posiadać wbudowany walidator poprawności zbudowanych polityk, działający bez potrzeby uruchamiania polityki na serwerze. WSF.72 Środowisko graficzne musi wspierać zarządzanie cyklem Ŝycia polityk: wersjonowanie, pakowanie w kompletne zestawy polityk (wszystkie polityki lub wybrane), z moŝliwością ukrywania zawartości polityk przed niepowołanym odczytem, automatyczną dystrybucję pomiędzy środowiskami testowymi i produkcyjnym, wsparcie dla pracy grupowej. Zaawanasowanej funkcjonalności charakterystyka polityk bezpieczeństwa WSF.73 Polityka musi mieć moŝliwość korzystania z informacji takich jak nagłówki warstwy transportowej i wiadomości oraz zawartości wiadomości. WSF.74 Polityka musi mieć moŝliwość korzystania z informacji kontekstowych takich jak pora dnia, protokół dostępu, metryki. WSF.75 Polityka musi mieć moŝliwość korzystania z informacji zewnętrznej pobieranej między innymi z baz danych, katalogów LDAP, lub zewnętrznego API. WSF.76 Musi być moŝliwość budowania pętli w polityce. WSF.77 MoŜliwość stosowania tak zwanych wildcards (*,!) przy definiowaniu polityki. WSF.78 MoŜliwość definiowania rozgałęzień warunkowych w polityce na bazie testowania wartości atrybutów, typu klienta, i innych informacji kontekstowych. WSF.79 Rozwiązanie musi posiadać moŝliwość graficznej prezentacji i edycji polityki. 5

6 WSF.80 Rozwiązanie musi posiadać moŝliwość korzystania z jednej zdefiniowanej polityki w innej. WSF.81 Polityka musi mieć moŝliwość wywoływania programów napisanych w języku Java. WSF.82 Rozwiązanie musi posiadać moŝliwość definiowania polityk globalnych egzekwowanych dla wszystkich usług i wykonywanych przed innymi politykami. WSF.83 Rozwiązanie musi posiadać moŝliwość delegowania uprawnień administracyjnych do odpowiednich grup uŝytkowników z uwzględnieniem granularnej autoryzacji. Np. administracja globalnymi politykami realizowana przez inną grupę niŝ inne szczegółowe polityki usługowe. WSF.84 W celu umoŝliwienia dynamicznej modyfikacji polityk w czasie działania musi istnieć moŝliwość parametryzacji definiowanych polityk oraz zarządzanie wartościami tych parametrów przez interfejs webowy. Musi istnieć moŝliwość przechowywania parametrów polityk w następujących repozytoriach: bazie danych, plikach, katalogu LDAP. WSF.85 Parametry muszą być definiowane za pomocą składni zgodnej z Unified Expression Language. WSF.86 Musi istnieć moŝliwość definiowania parametrów, których wartości są wyliczane dynamicznie (np. w oparciu o zmienne środowiskowe). WSF.87 Rozwiązanie musi udostępniać API do zarządzania parametrami polityk. Zaawanasowanej funkcjonalności zarządzanie politykami WSF.88 Rozwiązanie musi zawierać narzędzie do testowania konfiguracji a w szczególności zdefiniowanych polityk. Testowanie powinno umoŝliwić symulowanie róŝnych ataków w celu weryfikacji poprawności konfiguracji. WSF.89 MoŜliwość dynamicznego włączania logowania i ustawiania poziomu w zaleŝności od aktualnych potrzeb. Logowanie powinno bezpośrednio mapować się na poszczególne kroki zdefiniowanych polityk. WSF.90 Rozwiązanie musi umoŝliwiać monitorowanie transakcji na Ŝywo w trakcie kiedy są realizowane. Musi istnieć moŝliwość przedstawienia aktualnego ruchu na graficznych wykresach. WSF.91 Rozwiązanie musi wspierać scentralizowany model zarządzania cyklem Ŝycia polityk: Centralne zarządzanie dla wszystkich instancji w HA, Migrowanie polityk ze środowisk deweloperskich na testowe i produkcyjne, Wersjonowanie polityk, Porównywanie wersji polityk, MoŜliwość integracji z zewnętrznym systemem kontroli wersji, Audyt uruchamiania poszczególnych wersji jako produkcyjne. WSF.92 Rozwiązanie musi umoŝliwiać grupowanie polityk bezpieczeństwa w pakiety tzw. black box (zdefiniowana funkcjonalność i interfejs bez moŝliwości modyfikacji 6

7 zawartości przez uŝytkowników). WSF.93 Rozwiązanie musi umoŝliwiać instalowanie pakietów polityk na poszczególnych instancjach systemu. Funkcji administracyjnych konsola WSF.94 Rozwiązanie musi udostępniać konsole do zarządzania instancjami. Zarządzanie musi udostępniać moŝliwość automatyzacji zarządzania za pomocą skryptów Jython lub Ant. Zarządzanie musi udostępniać moŝliwość monitorowania działania systemu oraz informowania w przypadku braku działania poszczególnych elementów. WSF.95 Rozwiązanie musi udostępniać dedykowaną konsolę do zarządzania politykami. Konsola powinna umoŝliwiać automatyczne przekazanie skonfigurowanych polityk do działających instancji systemu. WSF.96 Interfejs administracyjny musi wspierać kontrolę dostępu opartą o RBAC. Rozwiązanie musi mieć moŝliwość stosowania katalogu LDAP do przechowywania kont administracyjnych i uprawnień. Interfejs administracyjny powinien pokazywać topologię wdroŝenia instancji systemu. Autoryzacja w obszarze administracji musi umoŝliwiać definiowanie uprawnień na róŝnych poziomach: pojedynczej instancji, grupy instancji, całej domeny bezpieczeństwa. WSF.97 Konsola administracyjna musi udostępniać funkcjonalność typu dashboard prezentującą podstawowe informacje o działaniu systemu. WSF.98 Dashboard musi prezentować informacje o ilości przetwarzanych wiadomości z podziałem na instancje, grupy instancji i całe domeny bezpieczeństwa. WSF.99 Konsola administracyjna musi umoŝliwiać wyszukiwanie informacji o wiadomościach które spowodowały wyjątek lub błąd oraz udostępniać moŝliwość pokazania szczegółów takiego zdarzenia. WSF.100 Konsola administracyjna musi udostępniać informacje o alertach SLA dla wszystkich instancji systemu. WSF.101 Konsola administracyjna musi udostępniać funkcjonalność dostępu do logów dla kaŝdej instancji systemu. WSF.102 Konsola administracyjna musi udostępniać moŝliwość zarządzania dynamicznymi parametrami kaŝdej z zarządzanych instancji systemu. Funkcji administracyjnych audytowalność WSF.103 Rozwiązanie musi udostępniać pełne logowanie i audyt transakcji. WSF.104 Poziom logowania powinien być w pełni konfigurowalny oraz moŝliwy do przełączenia w trakcie działania systemu (bez potrzeby ponownego uruchamiania). WSF.105 Wsparcie dla dowolnie definiowanych wiadomości o błędach, udanych transakcjach i innych. WSF.106 MoŜliwość wykorzystania róŝnych technologii do przechowywania logów: pliki płaskie, Syslog, Windows Event Log, Baza danych. 7

8 WSF.107 MoŜliwość skonfigurowania centralnego repozytorium logów. WSF.108 MoŜliwość odseparowania zdarzeń związanych z bezpieczeństwem od innych. WSF.109 MoŜliwość przeszukiwania logów, podpisywania cyfrowego, szyfrowania. Funkcji administracyjnych raportowanie WSF.110 Rozwiązanie musi posiadać następujące interfejsy do raportowania: REST, Java API, flat file export. WSF.111 Rozwiązanie musi posiadać moŝliwość mierzenia zdefiniowanego poziomu SLA wraz z raportowaniem aktualnego stanu i historycznych wartości. WSF.112 Rozwiązanie musi posiadać moŝliwość definiowania automatycznego dostarczania raportów w oparciu o zdefiniowany harmonogram. Architektury rozwiązania WSF.113 Rozwiązanie musi posiadać moŝliwość rozbudowy i dostosowania przy pomocy języków takich jak Java,.NET. WSF.114 Rozwiązanie musi pozwalać na logiczne grupowanie instancji w klastrze HA które działają według tej samej konfiguracji (takie same polityki bezpieczeństwa). WSF.115 Rozwiązanie musi pozwalać na tworzenie logicznych domen administracyjnych składających się z wielu grup instancji systemu. WSF.116 Rozwiązanie musi wspierać architekturę High Availability i Disaster Recovery. Między innymi hot and warm failover. WSF.117 Rozwiązanie musi umoŝliwiać pracę w trybie klienta, tj. być wykorzystywane do korzystania z zewnętrznych usług (np. rejestrów na poziomie krajowym). 8