Standardy infrastruktury technicznej i oprogramowania dla klas bezpieczeństwa i klas systemów informatycznych resortu finansów

Transkrypt

1 Dane dokumentu Nazwa Projektu: Kontrakt Konsolidacja i Centralizacja Systemów Celnych i Podatkowych Studium Projektowe Konsolidacji i Centralizacji Systemów Celnych i Podatkowych (SPKiCSCP) Numer wersji dokumentu: Umowa MF: C/123/09/DI/B/140 Data wersji dokumentu: Strona 1 z 246

2 Spis treści: 1. Cel i przeznaczenie dokumentu Słownik pojęć Dokumenty stowarzyszone Wprowadzenie Budowa standardów infrastrukturalnych na bazie wymagań systemów, dobrych praktyk i aktualnych rozwiązań technologicznych Zestawienie obszarów standaryzacji Zestawienie detalicznej listy standardów Opracowanie opisów standardów według przyjętych szablonów Standardy komponentów Standardy branŝowe Strona 2 z 246

3 1. Cel i przeznaczenie dokumentu Dokument definiuje standardy infrastruktury technicznej i oprogramowania w warstwach określonych w dokumencie Architektura referencyjna środowiska IT CPD MF dla klas bezpieczeństwa i klas systemów zdefiniowanych w dokumentach Standard określania klasy systemu informatycznego resortu finansów i Standard określania klasy bezpieczeństwa systemu informatycznego resortu finansów. 2. Słownik pojęć Rozdział usunięty intencjonalnie. 3. Dokumenty stowarzyszone Rozdział usunięty intencjonalnie. 4. Wprowadzenie Standardy przedstawione w niniejszym dokumencie definiują i opisują właściwe komponenty infrastruktury technicznej oraz oprogramowania, które mapują się na wymagania poszczególnych klas systemów i klas bezpieczeństwa. Przygotowane standardy są elastyczne, skalowalne oraz neutralne technologicznie i przez cały cykl ich Ŝycia powinny pozostawać dokumentami Ŝywymi, aktualizowanymi cyklicznie, wraz z rozwojem technologii dostępnych na rynku i zmianami wymagań stawianych przez poszczególne jednostki organizacyjne resortu finansów. Zbiór standardów architektonicznych w zakresie infrastruktury i oprogramowania serwerów został przygotowany w postaci opisów bloków architektonicznych, z których mogą być budowane systemy. Opisy bloków architektonicznych zostały zamieszczone w załącznikach: Architektura referencyjna środowiska IT CPD MF (Załącznik VIII do SOPZ) oraz Systemy realizujące funkcje biznesowe (Załącznik IX do SOPZ). 5. Budowa standardów infrastrukturalnych na bazie wymagań systemów, dobrych praktyk i aktualnych rozwiązań technologicznych 5.1. Zestawienie obszarów standaryzacji Standardy opracowano w dwóch obszarach: 1. Infrastruktury 2. Oprogramowania Strona 3 z 246

4 W pierwszym z obszarów ulokowano standardy rozwiązań, które umiejscawiane są w obszarze infrastruktury, jednakŝe naleŝy pamiętać, Ŝe niektóre spośród opisywanych funkcjonalności mogą być realizowane z uŝyciem oprogramowania pracującego poza urządzeniem infrastrukturalnym. Drugi obszar dotyczy rozwiązań typowo programowych. Istnieją standardy obejmujące zarówno obszar infrastruktury, jak i oprogramowania dotyczy to przypadków, w których wyraźne rozdzielenie funkcjonalności infrastrukturalnych od funkcjonalności oprogramowania nie jest moŝliwe, a takŝe przypadków standardów branŝowych technologicznych i bezpieczeństwa znajdujących zastosowanie zarówno w obszarze infrastruktury, jak i oprogramowania. Poza ulokowaniem w odpowiednim obszarze, odnosząc się do zapisów umowy, standardy opracowano w odniesieniu do: Stref: 1. Serwerów, 2. Zasobów danych, 3. LAN, 4. SAN, 5. WAN; Warstw: 1. Proxy, 2. Aplikacyjnej, 3. Baz danych, 4. Zasobów danych; Rodzajów i podrodzajów, dla których wyróŝniono: 1. Standardy architektoniczne/konstrukcyjne, w zakresie a. Klastrów, b. Farm, c. Struktur LAN, d. Serwerów, e. Struktur SAN; 2. Standardy oprogramowania, a. Systemów operacyjnych, b. Wirtualizacji, c. Serwerów aplikacji, d. Baz danych, e. Middleware. 3. Standardy bezpieczeństwa, a. W zakresie dostępu, b. W zakresie szyfrowania; 4. Standardy technologiczne, w zakresie: a. Macierzy, b. Bibliotek taśmowych i wirtualnych, c. Serwerów, d. Aplikacji, e. LAN, f. SAN, g. WAN; 5. Standardy sprzętowe/techniczne dla Strona 4 z 246

5 a. Serwerów, b. Przełączników LAN, c. Przełączników SAN, d. Macierzy, e. Bibliotek; 6. Standardy proceduralne, w odniesieniu do procedur a. Operacyjnych, b. Administracyjnych, c. Awaryjnych; 7. Standardy dokumentacyjne w zakresie dokumentacji a. Projektowej, b. Powykonawczej, c. Zbiorczej. KaŜdemu ze standardów przydzielono unikalny identyfikator, zgodnie z informacją zawartą w poniŝszych tabelach Zestawienie detalicznej listy standardów Identyfikator Nazwa S.IA Standardy infrastrukturalne S.IA.PSR.B Standard serwerów kasetowych. S.IA.PSR.R Standard serwerów stelażowych. S.IA.STO.TLB Standard bibliotek taśmowych. S.IA.STO.VLB Standard bibliotek wirtualnych. S.IA.STO.UNI Standard dyskowych pamięci masowych. S.IA.SAN.SW Standard przełączników SAN. S.IA.LAN.SW Standard przełączników LAN i WAN. S.IA.LAN.FW Standard zapór sieciowych. S.IA.LAN.IPS Standard urządzeń IPS. S.IA.LAN.RTR Standard ruterów. S.IA.LAN.LB Standard urządzeń równoważenia ruchu sieciowego. S.SW Standardy oprogramowania S.SW.PX.HTT Standard oprogramowania dla serwera pośredniczącego-typ 1. S.SW.PX.SMT Standard oprogramowania dla serwera pośredniczącego-typ 2. S.SW.AP.JEE Standard oprogramowania dla serwera aplikacyjnego-typ 1. S.SW.AP.NET Standard oprogramowania dla serwera aplikacyjnego-typ 2. S.SW.AP.JSP Standard oprogramowania dla serwera aplikacyjnego-typ 3. S.SW.DB Standard oprogramowania dla serwerów baz danych. S.SW.VRT.X86 Standard oprogramowania do wirtualizacji platformy x86/64. S.SW.VRT.RE Standard oprogramowania do wirtualizacji platformy RISC. S.SW.OS.X86 Standard systemów operacyjnych dla platformy sprzętowej x86/64. S.SW.OS.RE Standard systemów operacyjnych dla platformy sprzętowej RISC. S.AR Standardy architektoniczne S.AR.LAN Standard architektoniczny infrastruktury dla sieci LAN i WAN. Strona 5 z 246

6 S.AR.SAN Standard architektoniczny infrastruktury sieci SAN. S.AR.CL.X86 Standard architektury klastrów dla platformy sprzętowej x86/64. S.AR.CL.RE Standard architektury klastrów dla platformy sprzętowej RISC. S.AR.FR.PX Standard architektury farm dla warstwy proxy. S.AR.FR.AP Standard architektury farm dla warstwy aplikacyjnej. S.AR.CL.DB Standard architektury klastrów wydajnościowych dla warstwy baz danych. S.SE Standardy bezpieczeństwa S.SE.EN.DK Standard bezpieczeństwa w zakresie szyfrowania danych na dyskach. S.SE.EN.DB Standard bezpieczeństwa w zakresie szyfrowania danych w bazach danych. S.SE.EN.TP Standard bezpieczeństwa w zakresie szyfrowania danych na taśmach. S.SE.AT Standard bezpieczeństwa w zakresie dostępu i autoryzacji. S.SE.EN.TR Standard bezpieczeństwa w zakresie szyfrowania danych w transmisji. S.TE Standardy branżowe S.TE.3DES Standard branżowy - 3DES S.TE.AES Standard branżowy - AES S.TE.PAM Standard branżowy - PAM S.TE.DH Standard branżowy - Diffie-Helmann S.TE.SSL Standard branżowy - SSL S.TE.TLS Standard branżowy - TLS S.TE.SSH Standard branżowy - SSH S.TE.IPSEC Standard branżowy - IPSec S.TE.HTTP Standard branżowy - HTTP S.TE.HTTPS Standard branżowy - HTTPS S.TE.ASP Standard branżowy - ASP S.TE.DNET Standard branżowy -.NET S.TE.JEE Standard branżowy - J2EE S.TE.JSP Standard branżowy - JSP S.TE.SMTP Standard branżowy - SMTP S.TE.DNS Standard branżowy - DNS S.TE.ISCSI Standard branżowy - iscsi S.TE.IP Standard branżowy - IP S.TE.NAT Standard branżowy - NAT S.TE.DWDM Standard branżowy - DWDM S.TE.ETH Standard branżowy - Ethernet S.TE.FC Standard branżowy - FC S.TE.VLAN Standard branżowy - VLAN S.TE.LACP Standard branżowy - LACP S.TE.FIPS140.2 Standard branżowy - FIPS S.TE.RDP Standard branżowy - RDP S.TE.EFS Standard branżowy - EFS S.TE.DMCR Standard branżowy - DM-Crypt S.TE.SMIME Standard branżowy - S/MIME S.TE.LDAP Standard branżowy - LDAP S.TE.RADIUS Standard branżowy - RADIUS S.TE.KERB Standard branżowy - Kerberos S.TE.X509 Standard branżowy - X.509 S.TE.FIPS180.2 Standard branżowy - FIPS S.TE.FIPS197 Standard branżowy - FIPS 197 Strona 6 z 246

7 S.TE.PKCS.1 S.TE.PKCS.7 S.TE.PKCS.10 S.TE.PKCS.11 S.TE.PKCS.12 S.TE.TSP S.TE.OCSP S.TE.UTF8 S.TE.SAML S.PR S.PR.OP.SR S.PR.AD.SR S.PR.FL.SR S.PR.OP.STO S.PR.AD.STO S.PR.FL.STO S.PR.OP.LAN S.PR.AD.LAN S.PR.FL.LAN S.PR.OP.SAN S.PR.AD.SAN S.PR.FL.SAN S.PR.OP.PX S.PR.AD.PX S.PR.FL.PX S.PR.OP.AP S.PR.AD.AP S.PR.FL.AP S.PR.OP.DB S.PR.AD.DB S.PR.FL.DB S.PR.TPL S.DO S.DO.PROJ.IA S.DO.PROJ.SW S.DO.ASB.IA Standard branżowy - PKCS#1 Standard branżowy - PKCS#7 Standard branżowy - PKCS#10 Standard branżowy - PKCS#11 Standard branżowy - PKCS#12 Standard branżowy - TSP Standard branżowy - OCSP Standard branżowy - UTF-8 Standard branżowy - SAML Standardy proceduralne Standard procedur operacyjnych dla serwerów. Standard procedur administracyjnych dla serwerów. Standard procedur awaryjnych dla serwerów. Standard procedur operacyjnych dla pamięci masowych. Standard procedur administracyjnych dla pamięci masowych. Standard procedur awaryjnych dla pamięci masowych. Standard procedur operacyjnych dla sieci LAN i WAN. Standard procedur administracyjnych dla sieci LAN i WAN. Standard procedur awaryjnych dla sieci LAN i WAN. Standard procedur operacyjnych dla sieci SAN. Standard procedur administracyjnych dla sieci SAN. Standard procedur awaryjnych dla sieci SAN. Standard procedur operacyjnych dla oprogramowania w warstwie proxy. Standard procedur administracyjnych dla oprogramowania w warstwie proxy. Standard procedur awaryjnych dla oprogramowania w warstwie proxy. Standard procedur operacyjnych dla oprogramowania w warstwie aplikacyjnej. Standard procedur administracyjnych dla oprogramowania w warstwie aplikacyjnej. Standard procedur awaryjnych dla oprogramowania w warstwie aplikacyjnej. Standard procedur operacyjnych dla oprogramowania w warstwie baz danych. Standard procedur administracyjnych dla oprogramowania w warstwie baz danych. Standard procedur awaryjnych dla oprogramowania w warstwie baz danych. Szablon procedury Standardy dokumentacyjne Standard dokumentacji projektowej infrastruktury. Standard dokumentacji projektowej oprogramowania. Standard dokumentacji powykonawczej infrastruktury. S.DO.ASB.SW Standard dokumentacji powykonawczej oprogramowania. S.DO.BULK Standard dokumentacji zbiorczej infrastruktury i oprogramowania. Tabela 1 przedstawia listę identyfikatorów oraz nazw standardów zawartych w kolejnych podsekcjach dokumentu. Identyfikator Nazwa S.IA S.IA.PSR.B S.IA.PSR.R S.IA.STO.TLB Standardy infrastrukturalne Standard serwerów kasetowych. Standard serwerów stelażowych. Standard bibliotek taśmowych. Strona 7 z 246

8 S.IA.STO.VLB S.IA.STO.UNI S.IA.SAN.SW S.IA.LAN.SW S.IA.LAN.FW S.IA.LAN.IPS S.IA.LAN.RTR S.IA.LAN.LB S.SW Standard bibliotek wirtualnych. Standard dyskowych pamięci masowych. Standard przełączników SAN. Standard przełączników LAN i WAN. Standard zapór sieciowych. Standard urządzeń IPS. Standard ruterów. Standard urządzeń równoważenia ruchu sieciowego. Standardy oprogramowania S.SW.PX.HTT Standard oprogramowania dla serwera pośredniczącego-typ 1. S.SW.PX.SMT Standard oprogramowania dla serwera pośredniczącego-typ 2. S.SW.AP.JEE Standard oprogramowania dla serwera aplikacyjnego-typ 1. S.SW.AP.NET Standard oprogramowania dla serwera aplikacyjnego-typ 2. S.SW.AP.JSP Standard oprogramowania dla serwera aplikacyjnego-typ 3. S.SW.DB S.SW.VRT.X86 S.SW.VRT.RE S.SW.OS.X86 S.SW.OS.RE S.AR S.AR.LAN S.AR.SAN S.AR.CL.X86 S.AR.CL.RE S.AR.FR.PX S.AR.FR.AP S.AR.CL.DB S.SE S.SE.EN.DK S.SE.EN.DB S.SE.EN.TP S.SE.AT S.SE.EN.TR S.TE S.TE.3DES S.TE.AES S.TE.PAM S.TE.DH S.TE.SSL S.TE.TLS S.TE.SSH S.TE.IPSEC S.TE.HTTP S.TE.HTTPS S.TE.ASP S.TE.DNET S.TE.JEE S.TE.JSP Standard oprogramowania dla serwerów baz danych. Standard oprogramowania do wirtualizacji platformy x86/64. Standard oprogramowania do wirtualizacji platformy RISC. Standard systemów operacyjnych dla platformy sprzętowej x86/64. Standard systemów operacyjnych dla platformy sprzętowej RISC. Standardy architektoniczne Standard architektoniczny infrastruktury dla sieci LAN i WAN. Standard architektoniczny infrastruktury sieci SAN. Standard architektury klastrów dla platformy sprzętowej x86/64. Standard architektury klastrów dla platformy sprzętowej RISC. Standard architektury farm dla warstwy proxy. Standard architektury farm dla warstwy aplikacyjnej. Standard architektury klastrów wydajnościowych dla warstwy baz danych. Standardy bezpieczeństwa Standard bezpieczeństwa w zakresie szyfrowania danych na dyskach. Standard bezpieczeństwa w zakresie szyfrowania danych w bazach danych. Standard bezpieczeństwa w zakresie szyfrowania danych na taśmach. Standard bezpieczeństwa w zakresie dostępu i autoryzacji. Standard bezpieczeństwa w zakresie szyfrowania danych w transmisji. Standardy branżowe Standard branżowy - 3DES Standard branżowy - AES Standard branżowy - PAM Standard branżowy - Diffie-Helmann Standard branżowy - SSL Standard branżowy - TLS Standard branżowy - SSH Standard branżowy - IPSec Standard branżowy - HTTP Standard branżowy - HTTPS Standard branżowy - ASP Standard branżowy -.NET Standard branżowy - J2EE Standard branżowy - JSP Strona 8 z 246

9 S.TE.SMTP Standard branżowy - SMTP S.TE.DNS Standard branżowy - DNS S.TE.ISCSI Standard branżowy - iscsi S.TE.IP Standard branżowy - IP S.TE.NAT Standard branżowy - NAT S.TE.DWDM Standard branżowy - DWDM S.TE.ETH Standard branżowy - Ethernet S.TE.FC Standard branżowy - FC S.TE.VLAN Standard branżowy - VLAN S.TE.LACP Standard branżowy - LACP S.TE.FIPS140.2 Standard branżowy - FIPS S.TE.RDP Standard branżowy - RDP S.TE.EFS Standard branżowy - EFS S.TE.DMCR Standard branżowy - DM-Crypt S.TE.SMIME Standard branżowy - S/MIME S.TE.LDAP Standard branżowy - LDAP S.TE.RADIUS Standard branżowy - RADIUS S.TE.KERB Standard branżowy - Kerberos S.TE.X509 Standard branżowy - X.509 S.TE.FIPS180.2 Standard branżowy - FIPS S.TE.FIPS197 Standard branżowy - FIPS 197 S.TE.PKCS.1 Standard branżowy - PKCS#1 S.TE.PKCS.7 Standard branżowy - PKCS#7 S.TE.PKCS.10 Standard branżowy - PKCS#10 S.TE.PKCS.11 Standard branżowy - PKCS#11 S.TE.PKCS.12 Standard branżowy - PKCS#12 S.TE.TSP Standard branżowy - TSP S.TE.OCSP Standard branżowy - OCSP S.TE.UTF8 Standard branżowy - UTF-8 S.TE.SAML Standard branżowy - SAML S.PR Standardy proceduralne S.PR.OP.SR Standard procedur operacyjnych dla serwerów. S.PR.AD.SR Standard procedur administracyjnych dla serwerów. S.PR.FL.SR Standard procedur awaryjnych dla serwerów. S.PR.OP.STO Standard procedur operacyjnych dla pamięci masowych. S.PR.AD.STO Standard procedur administracyjnych dla pamięci masowych. S.PR.FL.STO Standard procedur awaryjnych dla pamięci masowych. S.PR.OP.LAN Standard procedur operacyjnych dla sieci LAN i WAN. S.PR.AD.LAN Standard procedur administracyjnych dla sieci LAN i WAN. S.PR.FL.LAN Standard procedur awaryjnych dla sieci LAN i WAN. S.PR.OP.SAN Standard procedur operacyjnych dla sieci SAN. S.PR.AD.SAN Standard procedur administracyjnych dla sieci SAN. S.PR.FL.SAN Standard procedur awaryjnych dla sieci SAN. S.PR.OP.PX Standard procedur operacyjnych dla oprogramowania w warstwie proxy. S.PR.AD.PX Standard procedur administracyjnych dla oprogramowania w warstwie proxy. S.PR.FL.PX Standard procedur awaryjnych dla oprogramowania w warstwie proxy. S.PR.OP.AP Standard procedur operacyjnych dla oprogramowania w warstwie aplikacyjnej. S.PR.AD.AP Standard procedur administracyjnych dla oprogramowania w warstwie aplikacyjnej. Strona 9 z 246

10 S.PR.FL.AP S.PR.OP.DB S.PR.AD.DB S.PR.FL.DB S.PR.TPL S.DO S.DO.PROJ.IA S.DO.PROJ.SW S.DO.ASB.IA S.DO.ASB.SW S.DO.BULK Standard procedur awaryjnych dla oprogramowania w warstwie aplikacyjnej. Standard procedur operacyjnych dla oprogramowania w warstwie baz danych. Standard procedur administracyjnych dla oprogramowania w warstwie baz danych. Standard procedur awaryjnych dla oprogramowania w warstwie baz danych. Szablon procedury Standardy dokumentacyjne Standard dokumentacji projektowej infrastruktury. Standard dokumentacji projektowej oprogramowania. Standard dokumentacji powykonawczej infrastruktury. Standard dokumentacji powykonawczej oprogramowania. Standard dokumentacji zbiorczej infrastruktury i oprogramowania. Tabela 1 Lista identyfikatorów i nazw standardów Strona 10 z 246

11 5.3. Opracowanie opisów standardów według przyjętych szablonów Standardy komponentów Identyfikator Nazwa Obszar Strefa Warstwa Rodzaj systemów bezpieczeństwa Streszczenie Opis S.AR.LAN Standard architektoniczny infrastruktury dla sieci LAN i WAN. Standardy infrastrukturalne LAN, WAN Wszystkie Architektoniczny I II III IV B3 B2 B1 BX Dokument opisuje standard architektury w zakresie budowy infrastruktury sprzętowej dla sieci LAN oraz WAN, obsługującej ruch we wszystkich warstwach komponentów. PoniŜej przedstawiono opis standardu w odniesieniu do poszczególnych węzłów i bloków sieci. Na końcu dokumentu zawarto rysunek obrazujący modelowe połączenie pomiędzy wszystkimi węzłami oraz urządzeniami w blokach. W kaŝdym ośrodku przetwarzania musi istnieć sieć LAN o jednakowej strukturze. Na trasach pomiędzy lokalizacją główną oraz lokalizacjami zapasowymi muszą istnieć trakty DWDM. W ten sposób wszystkie odrębne sieci LAN muszą być połączone w jedną sieć rozległą. W kaŝdym ośrodku przetwarzania sieć LAN musi składać się z trzech węzłów: Węzła bramki internetowej i intranetowej Węzła rdzeniowego Węzła dystrybucyjnego. KaŜdy węzeł musi zawierać odpowiednie bloki funkcjonalne, np. blok przełączników dostępowych, blok przełączników dystrybucyjnych, blok zapór sieciowych, itp. KaŜdy blok funkcjonalny musi składać się z dwóch identycznych urządzeń zapewniających redundancję połączeń. Strona 11 z 246

12 Rysunek 1 Schemat zakresu funkcjonowania bloków architektonicznych infrastruktury LAN/WAN. Węzeł rdzeniowy Węzeł rdzeniowy występuje w kaŝdym Ośrodku Przetwarzania, pełniąc funkcję centralnego punktu sieci LAN i zapewniając szybkie przełączanie pomiędzy podsieciami węzła bramki internetowej i intranetowej oraz węzłami dystrybucyjnymi. Funkcjonalność i technologie Klasa I, II, III, IV: Węzły rdzeniowe wszystkich ośrodków przetwarzania muszą być połączone poprzez trakty DWDM. Węzeł rdzeniowy będzie zawierał blok przełączników rdzeniowych składający się z dwóch przełączników oraz dwa bloki urządzeń DWDM. Infrastruktura bloku przełączników rdzeniowych musi być zbudowana z przełączników modułowych. Całkowita przepustowość wewnętrzna kaŝdego komponentu infrastruktury musi pozwalać na równoczesną obsługę pełnej przepustowości wszystkich jego portów. Urządzenia infrastruktury muszą być wyposaŝone w interfejsy o przepustowości 10 Gb/s. Urządzenia infrastruktury muszą mieć moŝliwość obsługi interfejsów światłowodowych. Urządzenia infrastruktury muszą obsługiwać trasowanie ruchu pomiędzy Strona 12 z 246

13 lokalnymi podsieciami IP. KaŜdy blok urządzeń DWDM będzie zbudowany z dwóch urządzeń DWDM. Wirtualizacja Klasa I, II, III, IV: Infrastruktura musi umoŝliwiać tworzenie przełączników wirtualnych. Infrastruktura musi umoŝliwiać obsługę wirtualnych sieci lokalnych (VLAN). Infrastruktura musi umoŝliwiać znakowanie ramek z wykorzystaniem standardu IEEE 802.1Q. Infrastruktura musi umoŝliwiać agregowanie ruchu w portach wirtualnych (ang. trunking). Niezawodność i dostępność Klasa I, II, III, IV: Infrastruktura pojedynczego bloku przełączników rdzeniowych musi być zbudowana z dwóch przełączników modułowych. Układ urządzeń DWDM łączących węzły rdzeniowe wszystkich ośrodków przetwarzania musi być redundantny. Bezpieczeństwo Wymagania dotyczące bezpieczeństwa urządzeń aktywnych zawarto w standardach opisujących właściwe komponenty. Klasa B3, B2, B1: Architektura rdzenia sieci LAN kaŝdego ośrodka przetwarzania musi spełniać wymagania dla klasy B1, zapewniając tym samym moŝliwość pracy systemom w niŝszych klasach. Klasa BX: Wszelkie systemy klasy BX ulokowane w ośrodku przetwarzania muszą być odseparowane fizycznie od innych systemów resortu finansów. Jeśli systemy klasy BX korzystają z innych zasobów infrastruktury resortu finansów, to muszą być stosowane odpowiednie mechanizmy: o kontroli dostępu, o monitorowania zdarzeń bezpieczeństwa, o filtrowania ruchu. Zarządzanie Wymagania w zakresie zarządzania urządzeniami aktywnymi zawarto w standardach opisujących właściwe komponenty. Węzeł dystrybucyjny Węzły dystrybucyjne będą występować w kaŝdym Ośrodku Przetwarzania i będą podłączone redundantnie do węzła rdzeniowego. Strona 13 z 246

14 Zadaniem węzła dystrybucyjnego jest: podłączenie lokalnej grupy zasobów do Węzła rdzeniowego poprzez blok przełączników dystrybucyjnych podłączenie serwerów bazodanowych poprzez blok przełączników dystrybucyjnych; podłączenie bloków przełączników dostępowych oraz bloków przełączników dostępowych w kasetach obsługujących serwery aplikacyjne; filtrowanie ruchu sieciowego poprzez blok zapór sieciowych; rozdzielanie ruchu sieciowego do serwerów bazodanowych i aplikacyjnych poprzez blok urządzeń równowaŝących obciąŝenie (ang. loadbalancer). Funkcjonalność i technologie Klasa I, II, III, IV: Infrastruktura pojedynczego węzła dystrybucyjnego musi zawierać następujące bloki funkcjonalne: o blok przełączników dystrybucyjnych; o blok przełączników dostępowych; o blok przełączników dostępowych w kasetach; o blok zapór sieciowych; o blok urządzeń równowaŝących obciąŝenie. Blok przełączników dystrybucyjnych musi być zbudowany z przełączników modułowych podłączonych do węzła rdzeniowego. Całkowita przepustowość wewnętrzna kaŝdego urządzenia infrastrukturalnego w bloku przełączników dystrybucyjnych musi pozwalać na równoczesną obsługę pełnej przepustowości wszystkich jego portów. Komponenty modułowe w bloku przełączników dystrybucyjnych muszą być wyposaŝone w interfejsy o przepustowości 10 Gb/s. KaŜde urządzenie modułowe w bloku przełączników dystrybucyjnych musi mieć moŝliwość obsługi interfejsów o przepustowości 1 Gb/s. KaŜdy przełącznik w bloku przełączników dystrybucyjnych musi obsługiwać trasowanie ruchu pomiędzy lokalnymi podsieciami IP. Bloki przełączników dostępowych i bloki przełączników dostępowych w kasetach mają posiadać stałą ilość portów. Przepustowość wewnętrzna przełączników dostępowych moŝe być mniejsza od pełnej przepustowości wszystkich ich portów. Komponenty infrastrukturalne muszą być wyposaŝone w interfejsy o przepustowości 1Gb/s i 10 Gb/s. Komponenty infrastrukturalne muszą mieć moŝliwość obsługi interfejsów światłowodowych. Komponenty infrastrukturalne muszą mieć moŝliwość obsługi interfejsów w standardzie 1000BaseT. Wirtualizacja Klasa I, II, III, IV: Strona 14 z 246

15 Infrastruktura musi umoŝliwiać tworzenie przełączników wirtualnych. Infrastruktura musi umoŝliwiać obsługę wirtualnych sieci lokalnych (VLAN). Infrastruktura musi umoŝliwiać znakowanie ramek z wykorzystaniem standardu IEEE 802.1Q. Infrastruktura musi umoŝliwiać agregowanie ruchu w portach wirtualnych (ang. trunking). Niezawodność i dostępność Klasa I, II, III, IV: Infrastruktura pojedynczego bloku przełączników dystrybucyjnych musi być zbudowana z dwóch przełączników modułowych. Infrastruktura pojedynczego bloku przełączników dostępowych oraz bloku przełączników dostępowych w kasetach musi być zbudowana z dwóch przełączników o stałej ilości portów. KaŜdy blok zapór sieciowych będzie składał się z redundantnego układu dwóch urządzeń. KaŜdy blok urządzeń rozdzielających ruch będzie zbudowany z redundantnego układu dwóch urządzeń. Bezpieczeństwo Wymagania dotyczące bezpieczeństwa urządzeń aktywnych zawarto w standardach opisujących właściwe komponenty. Klasa B3, B2, B1: Architektura rdzenia sieci LAN kaŝdego ośrodka przetwarzania musi spełniać wymagania dla klasy B1, zapewniając tym samym moŝliwość pracy systemom w niŝszych klasach. Klasa BX: Wszelkie systemy klasy BX ulokowane w ośrodku przetwarzania muszą być odseparowane fizycznie od innych systemów resortu finansów. Jeśli systemy klasy BX korzystają z innych zasobów infrastruktury resortu finansów, to muszą być stosowane odpowiednie mechanizmy: o kontroli dostępu, o monitorowania zdarzeń bezpieczeństwa, o filtrowania ruchu. Zarządzanie Wymagania w zakresie zarządzania urządzeniami aktywnymi zawarto w standardach opisujących właściwe komponenty. Węzeł bramki internetowej i intranetowej Węzeł bramki internetowej i intranetowej będzie występował w kaŝdym ośrodku przetwarzania i będzie łączył ten ośrodek z siecią Internet oraz wewnętrzną siecią Strona 15 z 246

16 WAN Ministerstwa Finansów. W kaŝdym ośrodku przetwarzania musi istnieć jeden węzeł bramki internetowej i intranetowej. Węzeł bramki internetowej i intranetowej musi być podłączony do węzła rdzeniowego poprzez blok przełączników dystrybucyjnych. Zadaniem węzła bramki internetowej i intranetowej jest: podłączenie sieci LAN w danej lokalizacji do Internetu poprzez blok ruterów; podłączenie sieci LAN w danej lokalizacji do intranetu poprzez blok ruterów; filtrowanie ruchu sieciowego przy pomocy bloku zapór sieciowych; śledzenie ruchu danych przy pomocy sond sieciowych; podłączenie lokalnych serwerów proxy poprzez blok przełączników dystrybucyjnych rozdzielanie ruchu sieciowego do serwerów proxy poprzez blok urządzeń równowaŝących obciąŝenie (ang. loadbalancer); obsługa wydzielonych stref DMZ zawierających serwery pocztowe, serwery nazw (DNS), itp. Funkcjonalność i technologie Klasa I, II, III, IV: Infrastruktura pojedynczego węzła bramki internetowej i intranetowej będzie zawierać następujące bloki funkcjonalne: o blok ruterów łączący do Internetu; o blok ruterów łączący do intranetu; o blok przełączników dostępowych do podłączenia ruterów; o blok zapór sieciowych; o blok urządzeń równowaŝących obciąŝenie; o blok przełączników dostępowych dla serwerów w strefach DMZ; o blok przełączników dystrybucyjnych; o blok przełączników dostępowych dla serwerów proxy. Blok Przełączników Dystrybucyjnych w Węźle Bramki musi być zbudowany z przełączników modułowych; Całkowita przepustowość wewnętrzna kaŝdego przełącznika modułowego w Bloku Przełączników Dystrybucyjnych musi pozwalać na równoczesną obsługę pełnej przepustowości wszystkich jego portów. KaŜdy przełącznik modułowy w Bloku Przełączników Dystrybucyjnych musi być wyposaŝony w interfejsy o przepustowości 10 Gb/s. KaŜde urządzenie modułowe w Bloku Przełączników Dystrybucyjnych musi mieć moŝliwość obsługi interfejsów o przepustowości 1 Gb/s. KaŜdy przełącznik w Bloku Przełączników Dystrybucyjnych musi obsługiwać trasowanie ruchu pomiędzy lokalnymi podsieciami IP. Bloki Przełączników Dostępowych w węźle mają posiadać stałą ilość portów. KaŜdy przełącznik dostępowy musi być wyposaŝony w interfejsy o przepustowości 1Gb/s i 10 Gb/s. Strona 16 z 246

17 KaŜdy przełącznik musi mieć moŝliwość obsługi interfejsów światłowodowych. KaŜdy przełącznik musi mieć moŝliwość obsługi interfejsów w standardzie 1000BaseT. KaŜdy blok zapór sieciowych będzie składał się z redundantnego układu dwóch urządzeń pozwalających na filtrowanie ruchu danych według opracowanej polityki bezpieczeństwa. KaŜdy Blok Urządzeń RównowaŜących ObciąŜenie będzie zbudowany z redundantnego układu dwóch urządzeń pozwalających na rozdzielanie ruchu sieciowego do serwerów świadczących jednakowe usługi. Wirtualizacja przełączników Klasa I, II, III, IV: KaŜdy przełącznik musi umoŝliwiać programowe połączenie przełączników fizycznych w przełącznik wirtualny. KaŜdy przełącznik musi umoŝliwiać obsługę wirtualnych sieci lokalnych (VLAN). KaŜdy przełącznik musi umoŝliwiać znakowanie ramek z wykorzystaniem standardu IEEE 802.1Q. KaŜdy przełącznik musi umoŝliwiać agregowanie portów fizycznych w pojedynczy port wirtualny (ang. trunking) w sposób statyczny lub z uŝyciem protokołu LACP 802.3ad. Niezawodność i dostępność Klasa I, II, III, IV: Infrastruktura pojedynczego Bloku Przełączników Dystrybucyjnych musi być zbudowana z dwóch przełączników modułowych. Infrastruktura pojedynczego Bloku Przełączników Dostępowych oraz Bloku Przełączników Dostępowych w Kasetach musi być zbudowana z dwóch przełączników o stałej ilości portów. KaŜdy Blok Zapór Sieciowych będzie składał się z redundantnego układu dwóch urządzeń. KaŜdy Blok Urządzeń Rozdzielających Ruch będzie zbudowany z redundantnego układu dwóch urządzeń. Bezpieczeństwo Wymagania dotyczące bezpieczeństwa urządzeń aktywnych zawarto w standardach opisujących właściwe komponenty. Klasa B3, B2, B1: Architektura rdzenia sieci LAN kaŝdego ośrodka przetwarzania musi spełniać wymagania dla klasy B1, zapewniając tym samym moŝliwość pracy systemom w niŝszych klasach. Klasa BX: Wszelkie systemy klasy BX ulokowane w ośrodku przetwarzania muszą Strona 17 z 246

18 być odseparowane fizycznie od innych systemów resortu finansów. Jeśli systemy klasy BX korzystają z innych zasobów infrastruktury resortu finansów, to muszą być stosowane odpowiednie mechanizmy: o kontroli dostępu, o monitorowania zdarzeń bezpieczeństwa, o filtrowania ruchu. Zarządzanie Wymagania w zakresie zarządzania urządzeniami aktywnymi zawarto w standardach opisujących właściwe komponenty. Przykład infrastruktury LAN/WAN PoniŜej przedstawiono przykładowy obraz bloków infrastrukturalnych sieci LAN/WAN. Strona 18 z 246

19 Rysunek 2 Przykład infrastruktury LAN/WAN. Strona 19 z 246

20 Powiązane standardy MF Historia zmian Standard przełączników LAN i WAN. Karta standardu branŝowego VLAN. Karta standardu branŝowego LACP. Karta standardu branŝowego DNS. Karta standardu branŝowego DWDM. Data Autor Zmiana Utworzenie dokumentu. Wersja zaakceptowana. Kontakt Status dokumentu Imię Nazwisko, telefon, adres poczty elektronicznej Zaakceptowany Strona 20 z 246

21 Identyfikator S.SW.PX.HTT Nazwa Standard oprogramowania dla serwera pośredniczącego-typ 1. Obszar Oprogramowania Strefa Serwerów Warstwa Proxy Rodzaj Oprogramowania systemów I II III bezpieczeństwa Streszczenie Opis IV B3 B2 B1 BX Dokument opisuje standard oprogramowania pośredniczącego (tzw. HTTP proxy) w dostępie do usług HTTP. Funkcjonalność i technologie I, II, III, IV: Rozwiązanie musi być zbudowane w oparciu o: o specjalizowane oprogramowanie, działające w systemie operacyjnym zdefiniowanym dla platformy x86-64, na maszynie wirtualnej lub fizycznej; o samodzielnie działające urządzenie (tzw. appliance). Rozwiązanie musi być zbudowane w oparciu o specjalizowane oprogramowanie działające w systemie operacyjnym zdefiniowanym dla platformy x86-64, na maszynie fizycznej w przypadku, gdy zachodzi konieczność przechowywania kluczy prywatnych (obsługa protokołu HTTPS) zabezpieczonych specjalizowanym sprzętem (modułem HSM). Rozwiązanie musi zapewniać moŝliwość buforowania danych (odpowiedzi) dla ruchu HTTP. Rozwiązanie musi wspierać protokół HTTP 1.1. Rozwiązanie musi wspierać protokół HTTPS zabezpieczany mechanizmami TLS v1 oraz SSL v3. Rozwiązanie musi umoŝliwiać przekierowanie Ŝądań (tryb proxy). Rozwiązanie musi posiadać mechanizmy pozwalające na ograniczenie pasma sieciowego oraz ilości realizowanych połączeń względem portów oraz adresów IP. Rozwiązanie musi mieć moŝliwość kontroli dostępu uŝytkowników do usług, dla których stanowi ono pośredni element dostępowy. Rozwiązanie musi mieć moŝliwość zdefiniowania listy zawierającej informacje o zasobach, do których dostęp jest bezwzględnie zabroniony. Rozwiązanie musi udostępniać mechanizm filtrowania zawartości przesyłanej treści, z moŝliwością odcięcia uŝytkownikowi dostępu do zasobów zawierających określone słowa kluczowe. Rozwiązanie musi być wyposaŝone w mechanizmy trasowania oraz translacji adresów sieciowych. Strona 21 z 246

22 Wirtualizacja Rozwiązanie musi posiadać wsparcie producenta dla rozwiązań uruchamianych w środowiskach zwirtualizowanych. Niezawodność i dostępność Klasa I, II, III, IV: Rozwiązanie musi posiadać co najmniej jedną z funkcjonalności: o o współpracować z mechanizmami balansowania ruchu sieciowego; zapewniać mechanizmy wysokiej dostępności lub wspierać pracę z zewnętrznymi mechanizmami zapewnienia wysokiej dostępności. Bezpieczeństwo Rozwiązanie musi posiadać wsparcie ze strony producenta w zakresie ujawniania oraz naprawiania błędów i luk bezpieczeństwa, dostarczane przez dedykowany zespół specjalistów. Producent rozwiązania musi udostępniać listę opisującą historię wykrytych w rozwiązaniu błędów i zawierającą stosowne poprawki. Rozwiązanie musi umoŝliwiać tworzenie kopii zapasowej jego konfiguracji. Jeśli rozwiązanie zbudowane jest w oparciu o specjalizowane oprogramowanie, działające w systemie operacyjnym zdefiniowanym dla platformy x86-64 lub RISC, musi posiadać moŝliwość integracji z automatycznym systemem tworzenia kopii zapasowych w zakresie kopiowania jago konfiguracji, plików wykonawczych oraz bibliotek. Jeśli rozwiązanie zbudowane jest w oparciu o samodzielnie działające urządzenie (tzw. appliance), musi posiadać moŝliwość ręcznego lub automatycznego wykonania kopii zapasowej w zakresie jego konfiguracji. Klasa B1: Rozwiązanie musi stosować mechanizmy kryptograficzne do transmisji danych przesyłanych w sieciach publicznych: o podczas uwierzytelniania uŝytkowników, o podczas przesyłania danych konfiguracyjnych. Rozwiązanie musi posiadać moŝliwość centralnego uwierzytelniania uŝytkowników. Musi posiadać moŝliwość lokalnego autoryzowania dostępu uŝytkowników. Musi posiadać moŝliwość centralnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi wspierać granularny przydział uprawnień. Rozwiązanie musi mieć moŝliwość lokalnego rejestrowania zdarzeń bezpieczeństwa. Rozwiązanie musi mieć moŝliwość integracji z centralnym systemem rejestrowania zdarzeń bezpieczeństwa. Jeśli rozwiązanie funkcjonuje na styku z sieciami publicznymi, musi mieć moŝliwość integracji z systemem rejestrowania i monitoringu zdarzeń bezpieczeństwa. Klasa B2: Strona 22 z 246

23 Rozwiązanie musi stosować mechanizmy kryptograficzne do transmisji danych przesyłanych w sieciach publicznych: o podczas uwierzytelniania uŝytkowników, o podczas przesyłania danych konfiguracyjnych. Rozwiązanie musi posiadać moŝliwość uwierzytelniania uŝytkowników. Musi posiadać moŝliwość lokalnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi posiadać moŝliwość centralnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi mieć moŝliwość lokalnego rejestrowania zdarzeń bezpieczeństwa. Rozwiązanie musi mieć moŝliwość integracji z centralnym systemem rejestrowania zdarzeń bezpieczeństwa. Jeśli rozwiązanie funkcjonuje na styku z sieciami publicznymi, musi zapewniać moŝliwość rejestrowania i monitoringu zdarzeń bezpieczeństwa. Klasa B3: Rozwiązanie musi stosować mechanizmy kryptograficzne do transmisji danych przesyłanych w sieciach publicznych: o podczas uwierzytelniania uŝytkowników, o podczas przesyłania danych konfiguracyjnych. Rozwiązanie musi posiadać moŝliwość uwierzytelniania uŝytkowników. Musi posiadać moŝliwość lokalnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi mieć moŝliwość lokalnego rejestrowania zdarzeń. Jeśli rozwiązanie funkcjonuje na styku z sieciami publicznymi, musi zapewniać moŝliwość rejestrowania i monitoringu zdarzeń bezpieczeństwa. Klasa BX: Rozwiązanie wykorzystane w klasie BX musi być odseparowane fizycznie od innych systemów resortu finansów. Jeśli rozwiązanie korzysta z innych zasobów infrastruktury resortu finansów, to muszą być stosowane odpowiednie mechanizmy: o kontroli dostępu, o monitorowania zdarzeń bezpieczeństwa, o filtrowania ruchu. Zarządzanie Jeśli rozwiązanie zbudowane jest w oparciu o specjalizowane oprogramowanie, działające w systemie operacyjnym zdefiniowanym dla platformy x86-64 lub RISC, musi istnieć moŝliwość zdalnej aktualizacji tego oprogramowania. Jeśli rozwiązanie zbudowane jest w oparciu o samodzielnie działające urządzenie (tzw. appliance), musi istnieć moŝliwość aktualizacji mikrokodu (oprogramowania wewnętrznego) urządzenia. Rozwiązanie musi mieć moŝliwość zdalnego zrządzania poprzez aplikację webową lub konsolę administracyjną graficzną lub tekstową. Powiązane standardy MF Standard oprogramowania do wirtualizacji platformy x86/64. Standard serwerów kasetowych. Strona 23 z 246

24 Standard serwerów stelaŝowych. Historia zmian Data Autor Zmiana Utwrzenie doumentu. Wersja zaakceptowana. Kontakt Status dokumentu Imię Nazwisko, telefon, adres poczty elektronicznej Zaakceptowany Strona 24 z 246

25 Identyfikator S.SW.PX.SMT Nazwa Standard oprogramowania dla serwera pośredniczącego-typ 2. Obszar Oprogramowania Strefa Serwerów Warstwa Proxy Rodzaj Oprogramowania systemów I II III bezpieczeństwa Streszczenie Opis IV B3 B2 B1 BX Dokument opisuje standard oprogramowania pośredniczącego (tzw. SMTP proxy) w dostępie do usług SMTP. Funkcjonalność i technologie I, II, III, IV: Rozwiązanie musi być zbudowane w oparciu na jednym z poniŝszych sposobów: o w oparciu o specjalizowane oprogramowanie, działające w systemie operacyjnym zdefiniowanym dla platformy x86-64, na maszynie wirtualnej lub fizycznej; o w oparciu o samodzielnie działające urządzenie (tzw. appliance). Rozwiązanie musi być zbudowane w oparciu o specjalizowane oprogramowanie działające w systemie operacyjnym zdefiniowanym dla platformy x86-64, na maszynie fizycznej w przypadku, gdy zachodzi konieczność przechowywania kluczy prywatnych (obsługa protokołu SMTP+TLS/SSL) zabezpieczonych specjalizowanym sprzętem (HSM). Rozwiązanie musi umoŝliwiać przekazywanie ruchu SMTP (tryb SMTP relay). Rozwiązanie musi spełniać co najmniej jeden z poniŝszych warunków: o być wyposaŝone w mechanizmy filtrowania niepoŝądanych przesyłek poczty elektronicznej (spamu); o posiadać moŝliwość integracji za pomocą API z zewnętrznym systemem filtrowania spamu. Rozwiązanie musi spełniać co najmniej jeden z poniŝszych warunków: o o zawierać mechanizm ochrony antywirusowej; posiadać moŝliwość integracji za pomocą API z zewnętrznym systemem ochrony antywirusowej. Rozwiązanie musi zawierać mechanizmy ograniczające liczbę połączeń realizowanych do docelowego serwera SMTP i filtrujące zdarzenia sieciowe związane z nagłym wzrostem ilości doręczanych przesyłek. Rozwiązanie musi zawierać mechanizmy powiadamiania o zaistniałych stanach nietypowych oraz zaistniałych awariach w zakresie obsługiwanej przez nie transmisji. Rozwiązanie musi wspierać protokół SMTP zabezpieczany mechanizmami Strona 25 z 246

26 TLS v1 oraz SSL v3. Rozwiązanie musi posiadać wsparcie producenta w zakresie ujawniania błędów oraz moŝliwość instalacji poprawek i aktualizowania oprogramowania. Wirtualizacja Rozwiązanie musi posiadać wsparcie producenta dla rozwiązań uruchamianych w środowiskach zwirtualizowanych, w których działa, zdefiniowanych w Standardzie oprogramowania do wirtualizacji platformy x86/64. Niezawodność i dostępność Klasa I, II, III, IV: Rozwiązanie musi posiadać co najmniej jedną z funkcjonalności: o o współpracować z mechanizmami balansowania ruchu sieciowego; zapewniać mechanizmy wysokiej dostępności lub wspierać pracę z zewnętrznymi mechanizmami zapewnienia wysokiej dostępności. Bezpieczeństwo Rozwiązanie musi posiadać wsparcie ze strony producenta w zakresie ujawniania oraz naprawiania błędów i luk bezpieczeństwa, dostarczane przez dedykowany zespół specjalistów. Producent rozwiązania musi udostępniać listę opisującą historię wykrytych w rozwiązaniu błędów i zawierającą stosowne poprawki. Rozwiązanie musi umoŝliwiać tworzenie kopii zapasowej jego konfiguracji. Klasa B1: Rozwiązanie musi stosować mechanizmy kryptograficzne do transmisji danych przesyłanych w sieciach publicznych: o podczas uwierzytelniania uŝytkowników, o podczas przesyłania danych konfiguracyjnych. Rozwiązanie musi posiadać moŝliwość centralnego uwierzytelniania uŝytkowników. Musi posiadać moŝliwość lokalnego autoryzowania dostępu uŝytkowników. Musi posiadać moŝliwość centralnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi wspierać granularny przydział uprawnień. Rozwiązanie musi mieć moŝliwość lokalnego rejestrowania zdarzeń bezpieczeństwa. Rozwiązanie musi mieć moŝliwość integracji z centralnym systemem rejestrowania zdarzeń bezpieczeństwa. Jeśli rozwiązanie funkcjonuje na styku z sieciami publicznymi, musi mieć moŝliwość integracji z systemem rejestrowania i monitoringu zdarzeń bezpieczeństwa. Klasa B2: Rozwiązanie musi stosować mechanizmy kryptograficzne do transmisji danych przesyłanych w sieciach publicznych: Strona 26 z 246

27 o podczas uwierzytelniania uŝytkowników, o podczas przesyłania danych konfiguracyjnych. Rozwiązanie musi posiadać moŝliwość uwierzytelniania uŝytkowników. Musi posiadać moŝliwość lokalnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi posiadać moŝliwość centralnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi mieć moŝliwość lokalnego rejestrowania zdarzeń. Rozwiązanie musi mieć moŝliwość integracji z centralnym systemem rejestrowania zdarzeń bezpieczeństwa. Jeśli rozwiązanie funkcjonuje na styku z sieciami publicznymi, musi zapewniać moŝliwość rejestrowania i monitoringu zdarzeń bezpieczeństwa. Klasa B3: Rozwiązanie musi stosować mechanizmy kryptograficzne do transmisji danych przesyłanych w sieciach publicznych: o podczas uwierzytelniania uŝytkowników, o podczas przesyłania danych konfiguracyjnych. Rozwiązanie musi posiadać moŝliwość uwierzytelniania uŝytkowników. Rozwiązanie musi posiadać moŝliwość lokalnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi mieć moŝliwość lokalnego rejestrowania zdarzeń bezpieczeństwa. Jeśli rozwiązanie funkcjonuje na styku z sieciami publicznymi, musi zapewniać moŝliwość rejestrowania i monitoringu zdarzeń bezpieczeństwa. Klasa BX: Rozwiązanie wykorzystane w klasie BX musi być odseparowane fizycznie od innych systemów resortu finansów. Jeśli rozwiązanie korzysta z innych zasobów infrastruktury resortu finansów, to muszą być stosowane odpowiednie mechanizmy: o kontroli dostępu, o monitorowania zdarzeń bezpieczeństwa, o filtrowania ruchu. Zarządzanie Jeśli rozwiązanie zbudowane jest w oparciu o specjalizowane oprogramowanie, działające w systemie operacyjnym zdefiniowanym dla platformy x86-64 lub RISC, musi istnieć moŝliwość zdalnej aktualizacji tego oprogramowania. Jeśli rozwiązanie zbudowane jest w oparciu o samodzielnie działające urządzenie (tzw. appliance), musi istnieć moŝliwość aktualizacji mikrokodu (oprogramowania wewnętrznego) urządzenia. Rozwiązanie musi mieć moŝliwość zdalnego zrządzania poprzez aplikację webową lub konsolę administracyjną graficzną lub tekstową. Powiązane standardy MF Historia zmian Brak. Strona 27 z 246

28 Data Autor Zmiana Utworzenie dokumentu. Wersja zaakceptowana. Kontakt Status dokumentu Imię Nazwisko, telefon, adres poczty elektronicznej Zaakceptowany Strona 28 z 246

29 Identyfikator S.SW.AP.NET Nazwa Standard oprogramowania dla serwera aplikacyjnego-typ 2. Obszar Oprogramowania Strefa Serwerów Warstwa Aplikacyjna Rodzaj Oprogramowania systemów I II III bezpieczeństwa Streszczenie Opis IV B3 B2 B1 BX Niniejszy dokument opisuje standard oprogramowania aplikacyjnego wykorzystywanego jako środowisko uruchomieniowe aplikacji rozproszonych, tworzonych z wykorzystaniem technologii ASP.NET. Funkcjonalność i technologie Klasa I, II, III, IV: Serwer aplikacji funkcjonujący w ramach platformy aplikacyjnej musi w pełni wspierać obsługę standardu ASP.NET w wersji co najmniej 3.5. Rozwiązanie moŝe być zbudowane w oparciu o specjalizowane oprogramowanie, działające w systemie operacyjnym WIN, równieŝ na maszynie wirtualnej, zgodnej z platformą wirtualizującą, zdefiniowaną w Standardzie oprogramowania do wirtualizacji platformy x86/64. Rozwiązanie musi posiadać cechy skalowalności poziomej, pozwalające na rozbudowywanie środowiska o nowe komponenty oraz powiększanie jego mocy obliczeniowej poprzez dodawanie kolejnych bloków funkcjonalnych. Rozwiązanie musi umoŝliwiać tworzenie systemów otwartych, pozwalających na komunikację z systemami zbudowanymi w innych technologiach. Rozwiązanie musi umoŝliwiać budowanie oprogramowania: o pracującego w klastrze, zawierającego mechanizmy wysokiej dostępności lub wspieranego przez mechanizmy wysokiej dostępności; o umoŝliwiającego równowaŝenie obciąŝenia aplikacji; o udostępniającego usługi sieciowe (web services); o umoŝliwiającego stworzenie chmury obliczeniowej; o wyposaŝonego w mechanizmy uwierzytelniania uŝytkowników; o szyfrującego transmisję danych w sieci. Rozwiązanie musi udostępniać własne zintegrowane środowisko programistyczne lub dostarczać komponenty pozwalające na tworzenie oprogramowania w jednym z dostępnych środowisk programistycznych. Wirtualizacja Klasa I, II, III, IV: Platforma aplikacyjna musi posiadać wsparcie producenta dla rozwiązań Strona 29 z 246

30 uruchamianych w środowiskach zwirtualizowanych, w których działa, zdefiniowanych w Standardzie oprogramowania do wirtualizacji platformy x86/64. Niezawodność i dostępność Klasa I, II, III, IV: Rozwiązanie musi posiadać moŝliwość integracji z centralnym systemem monitorowania usług. Klasa I, II: Rozwiązanie musi umoŝliwiać budowanie oprogramowania: o pracującego w klastrze, zawierającego mechanizmy wysokiej dostępności; o umoŝliwiającego równowaŝenie obciąŝenia aplikacji; o umoŝliwiającego replikację danych o sesji aplikacyjnej. Klasa III: Rozwiązanie musi umoŝliwiać budowanie oprogramowania : o pracującego w klastrze, zawierającego mechanizmy wysokiej dostępności; o umoŝliwiającego równowaŝenie obciąŝenia aplikacji. Bezpieczeństwo Rozwiązanie musi posiadać wsparcie ze strony producenta w zakresie ujawniania oraz naprawiania błędów i luk bezpieczeństwa, dostarczane przez dedykowany zespół specjalistów. Producent rozwiązania musi udostępniać listę opisującą historię wykrytych w rozwiązaniu błędów i zawierającą stosowne poprawki. Rozwiązanie musi posiadać moŝliwość integracji z automatycznym systemem tworzenia kopii zapasowych w zakresie kopiowania konfiguracji serwera aplikacyjnego i aplikacji, ich plików wykonawczych, bibliotek oraz danych. Klasa B2,B1: Rozwiązanie musi stosować mechanizmy kryptograficzne do transmisji danych przesyłanych w sieciach publicznych: o podczas uwierzytelniania uŝytkowników, o podczas przesyłania danych konfiguracyjnych. Rozwiązanie musi posiadać moŝliwość uwierzytelniania uŝytkowników. Musi posiadać moŝliwość lokalnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi posiadać moŝliwość centralnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi wspierać granularny przydział uprawnień. Rozwiązanie musi wspierać mechanizmy jednokrotnego logowania. Rozwiązanie musi mieć moŝliwość lokalnego rejestrowania zdarzeń bezpieczeństwa. Rozwiązanie musi mieć moŝliwość integracji z centralnym systemem rejestrowania zdarzeń bezpieczeństwa. Strona 30 z 246

31 Jeśli rozwiązanie funkcjonuje na styku z sieciami publicznymi, musi zapewniać moŝliwość rejestrowania i monitoringu zdarzeń bezpieczeństwa. Klasa B3: Rozwiązanie musi stosować mechanizmy kryptograficzne do transmisji danych przesyłanych w sieciach publicznych: o podczas uwierzytelniania uŝytkowników, o podczas przesyłania danych konfiguracyjnych. Rozwiązanie musi posiadać moŝliwość uwierzytelniania uŝytkowników. Musi posiadać moŝliwość lokalnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi wspierać granularny przydział uprawnień. Rozwiązanie musi mieć moŝliwość lokalnego rejestrowania zdarzeń bezpieczeństwa. Jeśli rozwiązanie funkcjonuje na styku z sieciami publicznymi, musi zapewniać moŝliwość rejestrowania i monitoringu zdarzeń bezpieczeństwa. Klasa BX: Rozwiązanie wykorzystane w klasie BX musi być odseparowane fizycznie od innych systemów resortu finansów. Jeśli rozwiązanie korzysta z innych zasobów infrastruktury resortu finansów, to muszą być stosowane odpowiednie mechanizmy: o kontroli dostępu, o monitorowania zdarzeń bezpieczeństwa, o filtrowania ruchu. Zarządzanie Rozwiązanie musi umoŝliwiać wsadowe wykonywanie działań administracyjnych. Rozwiązanie musi umoŝliwiać zdalne aktualizowanie serwera aplikacyjnego oraz aplikacji. Rozwiązanie musi mieć moŝliwość zdalnego zrządzania poprzez aplikację webową lub konsolę zdalnej administracji. Rozwiązanie musi umoŝliwiać zarządzanie połączeniami z bazą danych przez konsolę administracyjną. Powiązane standardy MF Historia zmian Standard oprogramowania do wirtualizacji platformy x86/64. Data Autor Zmiana Utworzenie dokumenu. Wersja zaakceptowana. Kontakt Status dokumentu Imię Nazwisko, telefon, adres poczty elektronicznej Zaakceptowany Strona 31 z 246

32 Identyfikator S.SW.AP.JEE Nazwa Standard oprogramowania dla serwera aplikacyjnego-typ 1. Obszar Oprogramowania Strefa Serwerów Warstwa Aplikacyjna Rodzaj Oprogramowania systemów I II III bezpieczeństwa Streszczenie Opis IV B3 B2 B1 BX Niniejszy dokument opisuje standard oprogramowania aplikacyjnego wykorzystywanego jako środowisko uruchomieniowe aplikacji rozproszonych, tworzonych z wykorzystaniem technologii Java EE. Funkcjonalność i technologie Klasa I, II, III, IV: Serwer aplikacji funkcjonujący w ramach rozwiązania musi być serwerem certyfikowanym dla Java Enterprise Edition w wersji 5 lub wyŝszej. Rozwiązanie musi być zbudowane w oparciu o specjalizowane oprogramowanie, działające w systemie operacyjnym typ 1, typ 2, typ 3, typ 4, typ 5 równieŝ na maszynie wirtualnej, zgodnej z platformą wirtualizującą, zdefiniowaną w Standardzie oprogramowania do wirtualizacji platformy x86/64. Rozwiązanie musi posiadać cechy skalowalności poziomej, pozwalające na rozbudowywanie środowiska o nowe komponenty oraz powiększanie jego mocy obliczeniowej poprzez dodawanie kolejnych bloków funkcjonalnych. Rozwiązanie musi umoŝliwiać tworzenie systemów otwartych, pozwalających na komunikację z systemami zbudowanymi w innych technologiach. Rozwiązanie musi umoŝliwiać budowanie oprogramowania: o pracującego w klastrze, zawierającego mechanizmy wysokiej dostępności lub wspieranego przez mechanizmy wysokiej dostępności; o umoŝliwiającego równowaŝenie obciąŝenia aplikacji; o udostępniającego usługi sieciowe (web services); o umoŝliwiającego stworzenie chmury obliczeniowej; o wyposaŝonego w mechanizmy uwierzytelniania uŝytkowników; o szyfrującego transmisję danych w sieci. Rozwiązanie musi udostępniać własne zintegrowane środowisko programistyczne lub dostarczać komponenty pozwalające na tworzenie oprogramowania w jednym z dostępnych środowisk programistycznych. Wirtualizacja Klasa I, II, III, IV: Rozwiązanie musi posiadać wsparcie producenta dla rozwiązań Strona 32 z 246

33 uruchamianych w środowiskach zwirtualizowanych, w których działa, zdefiniowanych w Standardzie oprogramowania do wirtualizacji platformy x86/64. Niezawodność i dostępność Klasa I, II, III, IV: Rozwiązanie musi posiadać moŝliwość integracji z centralnym systemem monitorowania usług. Klasa I, II: Rozwiązanie musi umoŝliwiać budowanie oprogramowania: o pracującego w klastrze, zawierającego mechanizmy wysokiej dostępności; o umoŝliwiającego równowaŝenie obciąŝenia aplikacji; o umoŝliwiającego replikację danych o sesji aplikacyjnej. Klasa III: Rozwiązanie musi umoŝliwiać budowania oprogramowania: o pracującego w klastrze, zawierającego mechanizmy wysokiej dostępności; o umoŝliwiającego równowaŝenie obciąŝenia aplikacji. Bezpieczeństwo Rozwiązanie musi posiadać wsparcie ze strony producenta w zakresie ujawniania oraz naprawiania błędów i luk bezpieczeństwa, dostarczane przez dedykowany zespół specjalistów. Producent rozwiązania musi udostępniać listę opisującą historię wykrytych w rozwiązaniu błędów i zawierającą stosowne poprawki. Rozwiązanie musi posiadać moŝliwość integracji z automatycznym systemem tworzenia kopii zapasowych w zakresie kopiowania konfiguracji serwera aplikacyjnego i aplikacji, ich plików wykonawczych, bibliotek oraz danych. Klasa B1: Rozwiązanie musi stosować mechanizmy kryptograficzne do transmisji danych przesyłanych w sieciach publicznych: o podczas uwierzytelniania uŝytkowników, o podczas przesyłania danych konfiguracyjnych. Rozwiązanie musi posiadać moŝliwość centralnego uwierzytelniania uŝytkowników. Musi posiadać moŝliwość lokalnego autoryzowania dostępu uŝytkowników. Musi posiadać moŝliwość centralnego autoryzowania dostępu uŝytkowników. Rozwiązanie musi wspierać granularny przydział uprawnień. Rozwiązanie musi wspierać mechanizmy jednokrotnego logowania. Rozwiązanie musi mieć moŝliwość lokalnego rejestrowania zdarzeń. Rozwiązanie musi mieć moŝliwość integracji z centralnym systemem rejestrowania zdarzeń bezpieczeństwa. Strona 33 z 246