PolishAPI. Rekomendacje dotyczące obszaru bezpieczeństwa dla podmiotów korzystających ze standardu

Transkrypt

1 PlishAPI Rekmendacje dtyczące bszaru bezpieczeństwa dla pdmitów krzystających ze standardu Dkument pracwany przez Grupę Prjektwą ds. PlishAPI 4 września 2019 Wersja 1.0

2 1 Spis treści 2 Wstęp Kntekst Struktura dkumentu Zastswanie dkumentu Załżenia Definicje Określenia używane d ustalenia prirytetu wymagań: Obszar 1: Wymagania rganizacyjne i prceswe Plityka bezpieczeństwa infrmacji Organizacja bezpieczeństwa infrmacji Zarządzanie usługami dstarczanymi przez zewnętrznych dstawców Zarządzanie aktywami (z punktu widzenia bezpieczeństwa infrmacji) Bezpieczeństw fizyczne i śrdwiskwe Bezpieczna eksplatacja raz zarządzanie zmianami Kntrla dstępu Zapewnienie bezpieczeństwa w całym cyklu życia systemów infrmacyjnych Obsługa Zdarzeń peracyjnych i Incydentów bezpieczeństwa, w tym charakterze teleinfrmatycznym Zarządzanie ciągłścią działania Plityki bezpieczneg użytkwania przez pracwników Bezpieczeństw zasbów ludzkich Zarządzanie ryzykiem raz testy bezpieczeństwa Przeciwdziałanie praniu pieniędzy Infrmwanie Użytkwników zasadach bezpieczeństwa Obszar 2: Wymagania dla infrastruktury systemu Knfiguracja sieciwa Knfiguracja serwerów, urządzeń raz prgramwania Kntrla dstępu lgiczneg Przetwarzanie Danych Chrninych p strnie serwerwej Zarządzanie kluczami kryptgraficznymi Zapewnienie wyskiej dstępnści usług Obszar 3: Wymagania dla interfejsu PlishAPI Uwierzytelnienie i autryzacja w ramach PlishAPI Mechanizmy kryptgraficzneg zabezpieczenia danych Walidacja danych Rzliczalnść zdarzeń / 28

3 7 Obszar 4: Przeciwdziałanie nadużycim i atakm Mnitrwanie zdarzeń Reguły wykrywania nadużyć Ochrna systemu przed atakami dmwy dstępu / 28

4 2 Wstęp 2.1 Kntekst Nwa dyrektywa w sprawie usług płatniczych w ramach rynku wewnętrzneg (PSD2) wprwadza ramy prawne dla ferwania nwych usług płatniczych usługi dstępu d infrmacji rachunku, usługi inicjwania płatnści raz usługi ptwierdzania dstępnści na rachunku płatniczym płatnika kwty niezbędnej d wyknania transakcji płatniczej. Zarówn banki, jak i spółdzielcze kasy szczędnściw-kredytwe czy ddziały instytucji kredytwych, a także tzw. pdmity trzecie (TPP), będą mgły świadczyć nwe usługi w parciu przepisy PSD2 uzyskując dstęp d rachunków płatniczych prwadznych n-line przez uprawnine d teg pdmity (ASPSP). Świadczenie nwych usług płatniczych i udzielanie ich dstawcm dstępu d rachunków płatniczych wymaga jednakże zastswania najwyższych śrdków bezpieczeństwa, które umżliwią w maksymalnym zakresie graniczenie ryzyka ujawnienia pufnych danych sbm nieuprawninym czy pwstania innych incydentów bezpieczeństwa. W tym celu zstał pracwany wspólny, uniwersalny standard API (dla któreg używana jest nazwa PlishAPI) dla wszystkich pdmitów birących udział w kmunikacji w ramach świadczenia nwych usług, tj. TPP i ASPSP. Zgdnie z zapisami rzdziału 6 dkumentacji standardu PlishAPI (Bezpieczeństw infrmacji), Grupa Prjektwa PlishAPI zstała zbwiązana d pracwania ddatkweg szczegółweg dkumentu, bejmująceg m.in. kwestie bezpieczeństwa implementacji, peracji i utrzymania systemów partych na PlishAPI. Niniejszy dkument stanwi wypełnienie teg zbwiązania. W dkumencie uwzględnin zapisy następujących regulacji raz wytycznych: 1) Dyrektywy 2007/64/WE Parlamentu Eurpejskieg i Rady 2015/2366 z dnia 25 listpada 2015 r. w sprawie usług płatniczych w ramach rynku wewnętrzneg (znwelizwana dyrektywa w sprawie usług płatniczych, PSD2), 2) Rzprządzenia Delegwaneg w dniesieniu d regulacyjnych standardów technicznych dtyczących silneg uwierzytelniania klienta i wspólnych i bezpiecznych twartych standardów kmunikacji (RTS), publikwane w Dzienniku Urzędwym Unii Eurpejskiej w dniu 13 marca 2018 rku, 3) Wytycznych w sprawie wymgów zgłaszania nadużyć finanswych na pdstawie art. 96 ust. 6 drugiej dyrektywy w sprawie usług płatniczych (PSD2), 4) Wytycznych dtyczących zgłaszania pważnych incydentów zgdnie z dyrektywą (UE) 2015/2366 (PSD2), 5) Wytycznych w sprawie śrdków bezpieczeństwa dtyczących ryzyk peracyjnych i ryzyk dla bezpieczeństwa usług płatniczych na mcy dyrektywy (UE) 2015/2366 (PSD2), 6) Opinia Eurpejskieg Nadzru Bankweg w sprawie wykrzystania certyfikatów eidas w ramach RTS dla SCA raz CSC. 2.2 Struktura dkumentu Dkument składa się z czterech części dtyczących następujących bszarów: 1) Obszar 1: Wymagania rganizacyjne i prceswe 2) Obszar 2: Wymagania dla infrastruktury systemu 3) Obszar 3: Wymagania dla interfejsu PlishAPI 4) Obszar 4: Przeciwdziałanie nadużycim i atakm. 4 / 28

5 2.3 Zastswanie dkumentu Wszystkie wymagania przedstawine w niniejszym dkumencie dtyczą wyłącznie elementów związanych z funkcjnalnścią interfejsu PlishAPI ile szczegółwe zapisy nie mówią inaczej. Niniejszy dkument ma zastswanie d dstawców usług płatniczych wykrzystujących standard PlishAPI, tj. zarówn TPP jak i ASPSP (łącznie jak "PSP"). 2.4 Załżenia 1) PSP mgą, wedle własneg uznania i przeprwadznej ceny ryzyka raz na własną dpwiedzialnść, pdjąć decyzję zastswaniu się d przedstawinych tutaj rekmendacji i wymagań, w całści lub części. 2) Niniejszy dkument nie stanwi także pinii prawnej. 5 / 28

6 3 Definicje Access tken ciąg znaków, stanwiący techniczną reprezentację sesji kmunikacyjnej, ustalnym czasie ważnści, nawiązanej pmiędzy TPP i ASPSP w kntekście ściśle kreślneg PSU i dla ściśle kreślneg zakresu usług i zasbów p strnie ASPSP, d których TPP uzyskał dstęp. Aktywa wszystk, c ma wartść dla rganizacji [ISO/IEC :2004]. Mżna wyróżnić dwa rdzaje aktywów: Aktywa pdstawwe: Prcesy i działania bizneswe Infrmacje Aktywa wspierające (wszystkich rdzajów): Sprzęt Oprgramwanie Sieć Persnel Siedziba Struktura rganizacyjna Bezpieczny kanał kmunikacyjny mechanizm kmunikacji zapewniający pufnść, integralnść raz dstępnść danych. Dane Chrnine zbiry wrażliwych infrmacji, mgących stanwić szczególnie chrnine infrmacje bejmujące: dane uwierzytelniające i autryzacyjne, dane transakcyjne (infrmacje transakcjach finanswych wyknanych w ramach interfejsu PlishAPI: kwty, pisy raz nazwy strn transakcji), dane bankwe (infrmacje rachunkach bankwych i ich saldach), dane sbwe (dane identyfikujące sby zgdnie z ustawą chrnie danych sbwych), klucze kryptgraficzne (np. wszelkie klucze prywatne występujące w śrdwisku raz klucz publiczny d certyfikatu TLS w przypadku użycia bustrnneg uwierzytelnienia w tym prtkle - w zakresie jeg integralnści) infrmacje wewnętrznej strukturze systemu (architektura wewnętrznych baz danych p strnie serwerwej, frmat kmunikatów przesyłanych pmiędzy systemami wewnętrznymi raz nazwy biektów wewnętrznych). EAT (External Authrizatin Tl) zewnętrzne narzędzie autryzacyjne, będące systemem zapewniającym prcedurę SCA czyli silneg uwierzytelnienia PSU. Incydent bezpieczeństwa pjedyncze zdarzenie lub seria zdarzeń nieplanwanych przez dstawcę usług płatniczych, które mają lub prawdpdbnie będą mieć niekrzystny wpływ na integralnść, dstępnść, pufnść, autentycznść, uwierzytelnienie i/lub ciągłść świadczenia usług płatniczych [ISO/IEC TR 18044:2004]. Media Chrnine fizyczne nśniki infrmacji zawierające Dane Chrnine. OAuth2 twarty standard autryzacji. Pzwala dzielić zasby przechwywane w jednej aplikacji z inną aplikacją bez kniecznści zagłębiania się w bsługę ich pświadczeń. W wyniku autryzacji w standardzie OAuth2 zapewniany jest dstęp d zasbów pmiędzy aplikacjami. Serwery frntend część infrastruktury PlishAPI dstępna w publicznej sieci. Serwery backend część infrastruktury PlishAPI niedstępna w sieci publicznej. 6 / 28

7 SCA (Strng Custmer Authenticatin, silne uwierzytelnienie klienta) uwierzytelnianie w parciu zastswanie c najmniej dwóch elementów (składników) należących d c najmniej dwóch różnych kategrii: wiedza (cś, c wie wyłącznie użytkwnik), psiadanie (cś, c psiada wyłącznie użytkwnik) i cechy klienta (cś, czym jest użytkwnik), niezależnych w tym sensie, że naruszenie jedneg z nich nie słabia wiarygdnści pzstałych, które t uwierzytelnianie jest zaprjektwane w spsób zapewniający chrnę pufnści danych uwierzytelniających. Standard standard PlishAPI. Śrdwisk Danych śrdwisk zawierające Dane Chrnine. TS specyfikacja techniczna nrmy dnszącej się d prfilu certyfikatów kwalifikwanych na ptrzeby dyrektywy w sprawie usług płatniczych (Electrnic Signatures and Infrastructures (ESI); Sectr Specific Requirements; Qualified Certificate Prfiles and TSP Plicy Requirements under the payment services Directive 2015/2366/EU). Użytkwnik użytkwnik rachunku płatniczeg, któreg dtyczą transakcje realizwane za pśrednictwem PlishAPI (tzw. PSU Payment Service User). Wrażliwe bszary bszary zawierające Dane Chrnine, wrażliwe lub krytyczne infrmacje raz śrdki przetwarzania infrmacji, np. data center. XS2A (Access t Accunt) interfejs pmiędzy TPP a ASPSP umżliwiający dstęp d rachunków płatniczych i wykrzystywany d wyknywania usług realizwanych w ramach PlishAPI. Zdarzenie peracyjne jest kreślną zmianą stanu systemu, usługi lub sieci, która wskazuje na mżliwe przełamanie plityki bezpieczeństwa infrmacji, błąd zabezpieczenia lub nieznaną dtychczas sytuację, która mże być związana z bezpieczeństwem [ISO/IEC TR 18044:2004] 3.1 Określenia używane d ustalenia prirytetu wymagań: Pisane wielkimi literami słwa kluczwe MUSI, MOŻE, POWINNO i ich warianty, dmiana raz frmy zaprzeczne, mają być interpretwane tak jak pisan pniżej: MUSI, WYMAGANE, NIE WOLNO, NIE MOŻE: Te słwa kluczwe znaczają bezwzględne wymaganie. Takie wymaganie musi być zaimplementwane we wszystkich systemach, które bejmuje standard. POWINNO, REKOMENDOWANE, NIE POWINNO, NIEREKOMENDOWANE: Te słwa znaczają mcną rekmendację. Brak spełnienia wymagania patrzneg zwrtem POWINEN dpuszczalny jest tylk w jawnie pisanych i uzasadninych przypadkach. Knieczne jest przeprwadzenie analizy skutków niewypełnienia zalecenia i związanych z tym ryzyk. MOŻE, OPCJONALNIE, NIE MUSI, NIEWYMAGANE: Te słwa kluczwe znaczają mżliwść pcjnalneg wdrżenia zalecenia. Pnadt niewdrżenie takich zaleceń nie musi być uzasadniane ani dkumentwane. 7 / 28

8 4 Obszar 1: Wymagania rganizacyjne i prceswe 4.1 Plityka bezpieczeństwa infrmacji Cel: Pdmit krzystający z PlishAPI MUSI mieć zatwierdzną przez najwyższe kierwnictw rganizacji, wprwadzną i regularnie aktualizwaną plitykę bezpieczeństwa infrmacji, która definiuje wszystkie bwiązki w zakresie bezpieczeństwa infrmacji raz jednznacznie przypisuje te bwiązki wyznacznym kmórkm/jednstkm. Pdmit krzystający z PlishAPI MUSI: 1. Psiadać zdefiniwane, publikwane wbec swich pracwników i współpracwników raz współpracujących firm zewnętrznych, zatwierdzne przez najwyższe kierwnictw, utrzymywane i rzpwszechniane plityki bezpieczeństwa. 2. Zadbać przestrzeganie w rganizacji i w pdmitach współpracujących prcedur w zakresie zarządzania ryzykiem peracyjnym i ryzykiem naruszenia bezpieczeństwa, w tym bezpieczeństwa teleinfrmatyczneg, a także skuteczne wdrżenie mechanizmów kntrli i bieżącej ceny śrdków graniczających ryzyk peracyjne i ryzyk naruszenia bezpieczeństwa w zakresie świadczenia usług płatniczych. 3. Dknywać regularnych przeglądów prcedur i plityk bezpieczeństwa raz aktualizwać je w związku ze zmianami isttnymi z punktu widzenia rganizacji. 4.2 Organizacja bezpieczeństwa infrmacji Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne plityki dtyczące zarządzaniem bezpieczeństwem infrmacji wewnątrz rganizacji raz wymiany infrmacji z pdmitami zewnętrznymi. Pdmit krzystający z PlishAPI MUSI: 1. Przypisać bwiązki i rle zarządzania bezpieczeństwem infrmacji wyznacznym kmórkm/jednstkm rganizacji, w szczególnści: Zdefiniwanie, udkumentwanie, zatwierdzanie i rzpwszechnianie plityk i prcedur bezpieczeństwa; Mnitrwanie i analiza alarmów bezpieczeństwa i infrmacji raz rzpwszechnianie d dpwiednich kmórek/jednstek rganizacji; Zdefiniwanie, udkumentwanie i rzpwszechnianie prcedury reakcji na zdarzenia peracyjne i incydenty bezpieczeństwa w celu zapewnienia niezwłczneg i efektywneg pstępwania; Zarządzanie kntami użytkwników, w tym ddawanie, mdyfikwanie i usuwanie; Mnitrwanie i kntrla dstępu d danych; Utrzymywanie należyteg kntaktu z dpwiednimi rganami, w tym w szczególnści Kmisją Nadzru Finansweg. 2. Zdefiniwać i wdrżyć prces autryzacji nwych śrdków przetwarzania infrmacji wprwadzanych d użycia, w szczególnści systemów infrmatycznych i elementów sieci infrmatycznej. 3. Definiwać wymgi dtyczące umów zachwaniu pufnści i dknywać regularnie ich przeglądów pd kątem zapewniania chrny infrmacji adekwatnej d aktualnych ptrzeb rganizacji. 8 / 28

9 4. Definiwać wymgi bezpieczeństwa dtyczące umów ze strnami trzecimi (w tym dstawcami systemów IT), w szczególnści dtyczącymi dstępu, przetwarzania lub zarządzania infrmacjami rganizacji w sieciach i systemach infrmatycznych. 5. Dknywać regularnych niezależnych przeglądów systemu bezpieczeństwa. 4.3 Zarządzanie usługami dstarczanymi przez zewnętrznych dstawców Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżną plitykę i prcedury zarządzania dstawcami usług, które będą pzwalały szacwać raz graniczać ryzyk związane z użyciem usług firm zewnętrznych. Pdmit krzystający z PlishAPI MUSI: 1. Utrzymać i wdrażać plityki i prcedury zarządzania dstawcami usług (w tym w szczególnści w ramach utsurcingu), którzy mają wpływ na bezpieczeństw Danych Chrninych, zgdnie z pniższymi wymaganiami: Stwrzenie i aktualizacja listy dstawców usług; Weryfikacja przed nawiązaniem współpracy z dstawcami usług, czy spełniają ni wymagania Standardu; Zapewnienie w umwach z pdmitami trzecimi zbwiązania d spełnienia przez te pdmity wymagań Standardu adekwatnie d zakresu świadcznych usług. Realizacja prgramu przynajmniej crczneg mnitrwania zgdnści dstawcy usług z wymaganiami Standardu, adekwatnie d zakresu świadcznej usługi. 4.4 Zarządzanie aktywami (z punktu widzenia bezpieczeństwa infrmacji) Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne prcesy związane z zarządzaniem aktywami (z punktu widzenia bezpieczeństwa infrmacji) bejmujące: inwentaryzację aktywów, kreślenie ich własnści raz ustalenie zasad akceptwalneg użycia, a także zasady klasyfikacji infrmacji, kmpnentów systemu raz zarządzania nśnikami danych. Przystępujący d krzystania z interfejsu PlishAPI, ASPSP MUSI, a TPP POWINIEN zapewnić: 1. Okreswą inwentaryzację aktywów i jej dkumentację. 2. Przypisywanie i dkumentwanie własnści aktywów dedykwanym pracwnikm rganizacji lub uprawninym sbm z firm zewnętrznych. 3. Definiwanie i dkumentwanie zasady akceptwalneg użycia aktywów. 4. Wdrżenie i aktualizację dkumentacji czynnści związanych z inwentaryzacją, przypisywaniem własnści i kreślaniem zasad akceptwalneg użycia aktywów zgdnie z wewnętrznymi regulacjami rganizacji. 5. Fizyczne zabezpieczenie wszystkich Mediów Chrninych (m.in urządzeń z pamięcią maswą, nśników danych, drukwanych dkumentów itp.). Przechwywanie kpii zapaswych Mediów Chrninych w bezpiecznych lkalizacjach, preferencyjnie w miejscu zlkalizwanym pza siedzibą rganizacji, w której fizycznie znajdują się te Media Chrnine. 6. Utrzymanie ścisłej kntrli nad używaniem i dystrybuwaniem Mediów Chrninych zarówn wewnątrz jak i pza rganizacją zgdnie z wdrżnymi w rganizacji regulacjami, w tym: Przesyłanie Mediów Chrninych bezpieczną metdą, w szczególnści pzwalającą na dkładne śledzenie przesyłki; 7. Niszczenie Mediów Chrninych, które nie są już ptrzebne d celów bizneswych czy z pwdów prawnych. Niszczenie fizycznych nśników infrmacji (wydruki, płyty itp.) przy wykrzystaniu niszczarki, metd spalania czy innych metd mechanicznych/sprzętwych w 9 / 28

10 celu uniemżliwienia dtwrzenia Danych Chrninych. Zabezpieczenie pjemników d przechwywania materiałów przeznacznych d zniszczenia. 8. Udkumentwanie i wykrzystywanie plityk i prcedur dtyczących graniczenia fizyczneg dstępu d Danych Chrninych. 4.5 Bezpieczeństw fizyczne i śrdwiskwe Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne skuteczne zabezpieczenia przed nieautryzwanym dstępem fizycznym d pmieszczeń, w których przetwarzane są Dane Chrnine. MUSZĄ zstać zapewnine śrdki bezpieczeństwa śrdwiskweg dla systemu. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Wykrzystanie dpwiednich śrdków kntrli dstępu w celu graniczenia i mnitrwania fizyczneg dstępu d systemów w Śrdwisku Danych: Wykrzystanie kamer wide i/lub mechanizmów kntrli dstępu w celu mnitrwania fizyczneg dstępu d Wrażliwych bszarów. Wymagane jest przechwywanie nagrań przynajmniej przez 3 miesiące, chyba że praw nakazuje inaczej. Grmadzenie lgów z systemu kntrli dstępu raz przechwywanie ich minimum przez kres 1 rku. Wdrżenie fizycznych i/lub lgicznych mechanizmów kntrli w celu graniczenia dstępu d gólndstępnych gniazdek sieciwych. Ograniczenie fizyczneg dstępu d bezprzewdwych punktów dstępu, bram sieciwych, urządzeń przenśnych, sprzętu sieciweg i łącznści, linii telekmunikacyjnych. 2. Ustanwienie prcedur w celu ułatwienia rzróżniania gści d persnelu: Identyfikacja gści (np. plakietki, identyfikatry). Unieważnienie dstępu byłym pracwnikm lub dla nieważnych identyfikatrów gści. Zapisy regulujące zmiany w wymaganiach dstępu dla gści. 3. Kntrlę fizyczneg dstępu pracwników d wrażliwych lkalizacji pprzez: Upważnienie na dstęp zgdnie z bwiązkami wyknywanymi przez daneg pracwnika. Bezzwłczne unieważnienie dstępu pracwnikm z chwilą zakńczenia stsunku pracy raz bezzwłczny zwrt urządzeń/przedmitów wykrzystywanych d kntrli dstępu (np. klucze, karty magnetyczne, identyfikatry, itp.). 4. Wdrżenie prcedur identyfikacji gści i upważnienia na ich dstęp: Upważnienie d dstępu gści przed wstępem, eskrtwanie gści w czasie przebywania na bszarach, gdzie Dane Chrnine są przetwarzane lub przechwywane. Identyfikacja gści na pdstawie plakietek lub innych identyfikatrów, które z czasem wygasają i pzwalają na wizualne dróżnienie d persnelu. Zwrt plakietek lub innych identyfikatrów przed puszczeniem placówki lub w dniu wygaśnięcia. Wykrzystywanie księgi gści lub rejestru elektrniczneg d ewidencji gści uzyskujących dstęp d placówki, w której przechwywane są Dane Chrnine. Knieczne jest udkumentwanie m.in.: imienia i nazwiska gścia, reprezentwanej firmy raz nazwisk sby upważniającej d wstępu. Przechwywanie księgi przez minimum trzy miesiące chyba, że praw stanwi inaczej. 5. Wdrżenie prcedur chrny przed zagrżeniami typu: pwódź, zalanie, pżar, przegrzanie raz innych frm katastrf naturalnych lub spwdwanych przez człwieka. 10 / 28

11 4.6 Bezpieczna eksplatacja raz zarządzanie zmianami Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne prcedury bezpiecznej eksplatacji należących d niej kmpnentów interfejsu PlishAPI raz zasady zarządzania zmianami w tych kmpnentach. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Separację śrdwisk służących d twrzenia/testwania prgramwania d śrdwiska prdukcyjneg raz wykrzystanie kntrli dstępu użytkwników i innych systemów rganizacji d tych śrdwisk. 2. Separację bwiązków sób birących udział przy twrzeniu/testwaniu prgramwania raz zarządzających śrdwiskiem prdukcyjnym, adekwatnie d aktualnie bwiązujących plityk bezpieczeństwa infrmacji w rganizacji. 3. Ograniczenie wykrzystywania danych prdukcyjnych d testów czy przy twrzeniu prgramwania, a przy uzasadninej kniecznści takieg użycia, pracwanie i zastswanie prcedury przygtwania danych prdukcyjnych d zastswań testwych (np. annimizacja danych, selekcja danych, dstęp d danych wyłącznie dla upważninych sób). 4. Usunięcie danych raz knt testwych przed uruchmieniem prdukcyjnym. 5. Usunięcie lub wyłączenie zbędnych usług, prcesów, traswań, płączeń sieciwych (tzw. hardening) na wszystkich kmpnentach systemu. 6. Prcedury zarządzania zmianą dtyczące wdrżenia pprawek bezpieczeństwa raz mdyfikacji prgramwania, które w zastswaniu spwdują: Wytwrzenie udkumentwanej zmiany, zaakceptwanej przez upważniny persnel; Wyknanie i udkumentwanie testów w celu weryfikacji, czy zmiana nie wpływa niekrzystnie na bezpieczeństw systemu; Wytwrzenie prcedury cfnięcia dknanych zmian. 4.7 Kntrla dstępu Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne prcedury zapewniające graniczenie dstępu d danych chrninych wyłącznie d minimum wymaganeg przez realizwane prcesy bizneswe. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Ograniczenie dstępu d kmpnentów systemu i Danych Chrninych d grna sób, których zadania służbwe wymagają takieg dstępu: Zdefiniwanie ptrzeb dstępu dla każdej rli: a) Określenie kmpnentów systemu i źródeł danych, d których dstęp dla danej rli jest niezbędny, b) Wymagany d dstępu d źródeł pzim uprawnień (np. użytkwnik, administratr itp.). Ograniczenie użytkwnikm psiadanych uprawnień d minimalnych, kniecznych d wyknywania pwierznych bwiązków służbwych zgdnie z zasadą least privileges. Przyznawanie dstępu na pdstawie indywidualnej klasyfikacji zadań i funkcji persnelu Wymaganie udkumentwanej (pisemnej lub elektrnicznej) zgdy autryzwaneg pdmitu na przyznanie uprawnień. Przydzielanie pracwnikm danych uwierzytelniających (tzw. credentiali): a) przez zastswanie frmalnie ustanwinej i udkumentwanej prcedury bezpieczeństwa. 11 / 28

12 b) z zachwaniem pufnści, przy uprzedniej identyfikacji pracwników. Użytkwanie przez pracwników danych uwierzytelniających (tzw. credentiali) w spsób graniczający mżliwść uzyskania d nich dstępu przez sby nieupważnine. Zdefiniwanie, udkumentwanie, stswanie i kreswy przegląd minimalnych wymagań wbec metd uwierzytelniania i danych uwierzytelniających, jakie rganizacja mże stswać w systemie (w szczególnści tzw. plityki haseł). 2. Wykrzystanie systemu kntrli dstępu d kmpnentów systemu, który granicza dstęp na zasadzie "need t knw" z dmyślnym ustawieniem "deny all". System kntrli dstępu MUSI dstarczać: Pkrycie wszystkich kmpnentów systemu, w tym sieci infrmatycznej i urządzeń sieciwych. Przyznawanie dstępu pszczególnym sbm lub grupm sób na pdstawie zadań i funkcji. 3. Udkumentwanie, wykrzystywanie i udstępnienie użytkwnikm plityk i prcedur bezpieczeństwa dtyczących graniczenia dstępu d Danych Chrninych. 4. Pddawanie cyklicznym przeglądm plityk i prcedur bezpieczeństwa dtyczących graniczenia dstępu d Danych Chrninych. 5. Ustanwienie, udkumentwanie i realizację prcesu regularnych przeglądów praw dstępu użytkwników d wszystkich kmpnentów interfejsu PlishAPI, pzstających w bezpśrednim zarzadzaniu rganizacji. 6. Ustanwienie, udkumentwanie i realizację plityki czysteg biurka i plityki czysteg ekranu uwzględniających: Kniecznść przechwywania w pufnści dkumentów papierwych, nśników danych, dkumentów elektrnicznych wbec strn nieautryzwanych (w tym nieautryzwanych pracwników rganizacji). Kniecznść bezzwłczneg niszczenia dkumentów papierwych, nśników danych, dkumentów elektrnicznych, które nie wymagają dalszeg przetwarzania w ramach systemu i które nie pdlegają bwiązkwi przechwywania na pdstawie bwiązujących przepisów prawa państwweg lub przepisów wewnętrznych rganizacji. 4.8 Zapewnienie bezpieczeństwa w całym cyklu życia systemów infrmacyjnych Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne prcedury zapewniające bezpieczeństw infrmacji w całym cyklu życia systemów infrmacyjnych będących kmpnentami interfejsu PlishAPI, czyli na etapach pzyskiwania, rzwju, utrzymania i wycfania z użycia tych systemów. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Aby wymagania bizneswe dtyczące nwych systemów infrmatycznych wchdzących w skład interfejsu PlishAPI lub jeg rzszerzenia zawierały wymagania dtyczące bezpieczeństwa infrmacji i bezpieczeństwa IT. 2. Zabezpieczenie interfejsu PlishAPI przed nadużyciami związanymi z błędami w kmpnentach teg systemu, utratą i nieuprawniną mdyfikacją danych wejściwych i wyjściwych w nim przetwarzanych, w szczególnści pprzez wieletapwe testy i frmalne dbiry pszczególnych funkcjnalnści systemu. 3. Ochrnę przed nieautryzwanym dstępem raz wersjnwanie kdu źródłweg kmpnentów systemu. 4. Ochrnę pufnści i integralnści Danych Chrninych wraz z rzpczęciem prdukcyjneg użytkwania nwych kmpnentów systemu lub kmpnentów rzwijanych. 12 / 28

13 5. Nadzór nad pracami rzwjwymi interfejsu PlishAPI, pwierznymi firmie zewnętrznej. 6. Ustanwienie, udkumentwanie i realizację prcesu zarządzania pdatnściami kmpnentów interfejsu PlishAPI, w celu bezzwłcznej likwidacji tych pdatnści i chrny przed narażeniem systemu na utratę dstępnści, pufnści lub integralnści danych. 7. Bezpieczne twrzenie aplikacji (w tym dstęp administracyjny d aplikacji przez sieć): Zgdnie ze Standardem (np. bezpieczne uwierzytelnianie i autryzacja), W parciu standardy branżwe raz najlepsze praktyki, Z wykrzystaniem technik bezpieczeństwa infrmacji w całym cyklu twrzenia prgramwania. 8. Ocenę mdyfikacji kdu przed instalacją prdukcyjną lub przed przekazaniem użytkwnikwi w celu zidentyfikwania ptencjalnych luk (przy pmcy ręczneg lub autmatyczneg prcesu) przynajmniej z uwzględnieniem czy: Oceny mdyfikacji kdu są przeprwadzane przez inne sby niż te, które są ich twórcami, psiadające dpwiednią wiedzę na temat technik ceny kdu i praktyk bezpieczneg prgramwania, Osby ceniające zapewniają, że kd jest napisany zgdnie z wytycznymi bezpieczneg prgramwania, w szczególnści z uwzględnieniem pkt. 4, Wymagane pprawki są nanszne przed udstępnieniem aplikacji, Wyniki ceny kdu pdlegają weryfikacji i akceptacji sób d teg uprawninych przed udstępnieniem aplikacji. 9. Usuwanie częst sptykanych błędów prgramistycznych zgdnie z zapisami aktualnej, publicznie dstępnej listy OWASP TOP 10, w tym: Brak walidacji danych wejściwych i wyjściwych aplikacji, w szczególnści pdatnść na ataki typu injectin, np. SQL injectin, cde injectin, OS injectin. Przepełnienie bufra. Błędy szyfrwania danych. Niezabezpieczna kmunikacja danych. Niedpwiednie zarządzanie błędami. Pdatnść na atak Crss-site scripting (XSS, skrypty międzyserwiswe) Niedpwiednia kntrla dstępu (np. niezabezpieczne bezpśrednie dwłania d biektów, niegraniczny dstęp URL, niegraniczny dstęp użytkwników d funkcji). Pdatnść na ataki Crss-site request frgery. Niepprawna bsługa uwierzytelniania i sesji. 10. Usuwanie wszystkich pdatnści krytyczneg i wyskieg ryzyka zidentyfikwanych w prcesie identyfikacji luk bezpieczeństwa. 11. Usunięcie knt prgramistów, testerów raz pzstałych ID użytkwników i haseł zanim system zstanie uruchminy w śrdwisku prdukcyjnym. 12. Zminimalizwanie błędów pprzez zapewnienie szklenia prgramistów w zakresie: a. bezpieczeństwa twrzneg prgramwania, b. unikania pwszechnych luk bezpieczeństwa, c. zrzumienia, jak wrażliwe dane są przetwarzane w pamięci. 13. Ciągła chrna raz identyfikwanie luk bezpieczeństwa aplikacji: Ocena bezpieczeństwa aplikacji przy pmcy ręcznych przeglądów lub autmatycznych narzędzi d ceny bezpieczeństwa, przynajmniej raz na rk, Błędy uznane za krytyczne zgdnie z klasyfikacją stswaną w rganizacji MUSZĄ być usuwane niezwłcznie. 14. Oprgramwanie PlishAPI MUSI krzystać wyłącznie z biblitek, które nie zawierają publicznie publikwanych, isttnych pdatnści bezpieczeństwa. Wydawca prgramwania PlishAPI MUSI na bieżąc mnitrwać publikwane infrmacje pdatnściach w biblitekach, z jakich krzysta jeg prgramwanie. Czas pmiędzy publikwaniem infrmacji isttnej pdatnści bezpieczeństwa w takiej biblitece, a wdrżeniem pprawki 13 / 28

14 w prgramwaniu PlishAPI MUSI wynikać z analizy ryzyka i nie mże przekraczać 3 miesięcy dla pdatnści wyskich. 4.9 Obsługa Zdarzeń peracyjnych i Incydentów bezpieczeństwa, w tym charakterze teleinfrmatycznym Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne stswne prcedury zapewniające szybką, skuteczną i uprządkwaną reakcję na incydenty związane z bezpieczeństwem infrmacji w celu zminimalizwania szkód finanswych i reputacyjnych. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Stwrzenie raz skuteczne wdrżenie planu reakcji na Zdarzenie peracyjne i Incydent bezpieczeństwa dtyczący usług pwiązanych z interfejsem PlishAPI zapewniająceg natychmiastwe działania w celu minimalizacji zasięgu i skutków Zdarzenia peracyjneg lub Incydentu bezpieczeństwa, zebrania materiału dwdweg raz wyciągnięcia stswnych wnisków i wdrżenia adekwatnych zabezpieczeń. Plan POWINIEN przynajmniej: Opisywać rle, dpwiedzialnści i strategię kmunikacji i kntaktu na wypadek wystąpienia Zdarzenia peracyjneg raz Incydentu bezpieczeństwa lub nawet jeg pdejrzenia, Pdawać szczegóły i czasy reakcji na każdy rdzaj Zdarzenia peracyjneg raz Incydentu bezpieczeństwa, Zawierać prcedury dtwrzenia/zapewnienia ciągłści bizneswej, Definiwać spsób raprtwania działań pdjętych pdczas bsługi Zdarzenia peracyjneg raz Incydentu bezpieczeństwa, w tym zewnętrzneg raprtwania pważnych Incydentów bezpieczeństwa, Obejmwać wszystkie kmpnenty systemu, 2. Cykliczne przeprwadzenie testu, weryfikacji i/lub aktualizacji planu reakcji. 3. Przypisanie persnelu w celu reakcji i bsługi Zdarzeń peracyjnych i Incydentów bezpieczeństwa raz zapewnienie jeg dstępnści na pzimie adekwatnym d skali i pwagi dntwaneg Zdarzenia peracyjneg lub Incydentu bezpieczeństwa. 4. Zapewnienie dpwiednich szkleń sbm dpwiedzialnym za reakcję na Zdarzenie peracyjne lub Incydent bezpieczeństwa. 5. Zdefiniwanie prcesu mdyfikacji i udsknalania planu reakcji na Incydent bezpieczeństwa, mająceg na celu uwzględnienie dświadczeń rganizacji raz pstępu w branży. 6. Grmadzenie, przechwywanie i udstępnianie materiału dwdweg zgdnie z zasadami materiału dwdweg bwiązującymi w dpwiednim prawdawstwie (prawdawstwach) Zarządzanie ciągłścią działania Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne i regularnie testwane plany utrzymania ciągłści działania raz dtwarzania działalnści w zakresie funkcjnwania interfejsu PlishAPI Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Opracwanie i wdrżenie planów ciągłści na pdstawie wyników analizy wpływu na biznes (Business Impact Analysis) raz szacwania ryzyka. 2. Zachwanie jednlitej struktury planów, aby plany były ze sbą spójne. 3. Cyklicznie sprawdzanie skutecznści planu ciągłści działania. 4. Utrzymanie i testwanie planu ciągłści działania raz, w razie kniecznści, jeg krektę i pnwną cenę. 14 / 28

15 5. Utrzymywanie i aktualizację listy krytycznych dla rganizacji prcesów. 6. Zawarcie w planie ciągłści działania przynajmniej: Listy prcesów krytycznych wraz z przypisanymi prirytetami raz czasami RTO/RPO, Spsbu funkcjnwania rganizacji w trakcie trwania sytuacji kryzyswej i p jej zakńczeniu, Struktury zarządzania kryzysweg wraz z kreśleniem ról i dpwiedzialnści, Kmunikacji i współdziałania z pdmitami zewnętrznymi. Pwrtu d nrmalnej działalnści 4.11 Plityki bezpieczneg użytkwania przez pracwników Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne plityki bezpieczneg użytkwania dla isttnych z punktu widzenia bezpieczeństwa technlgii przez jej pracwników (np. zdalny dstęp, użycie urządzeń przenśnych, użycie sieci bezprzewdwych, itp.). Wprwadzenie nwych technlgii w rganizacji MUSI wymagać przeprwadzenia frmalneg prcesu (w szczególnści pprzez prces zarządzania zmianami). Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Opracwanie i wdrżenie plityk wprwadzania nwych technlgii wraz z definicjami pprawneg krzystania z tych technlgii np. technlgie zdalneg i bezprzewdweg dstępu, laptpy, tablety, inne przenśne urządzenia elektrniczne (np. pendrive), wykrzystanie a i Internetu. Plityki wprwadzania nwych technlgii MUSZĄ pisywać następujące bszary: Zgda autryzwaneg pdmitu Zapewnienie uwierzytelnienia przy krzystaniu nwych technlgii tam gdzie jest t zasadne Zapewnienie mechanizmów kntrli dstępu d zasbów infrastruktury rganizacji Metda szybkiej identyfikacji użytkwnika wykrzystująceg elementy infrastruktury rganizacji Dpuszczalne spsby wykrzystania technlgii Lista technlgii dpuszcznych d użytku 2. Zakaz kpiwania, przenszenia i przechwywania Danych Chrninych na urządzenia przenśne bez mechanizmów zapewniających zachwanie pufnści Bezpieczeństw zasbów ludzkich Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne plityki związane z bezpieczeństwem zasbów ludzkich minimalizujące ryzyka dla bezpieczeństwa infrmacji wynikające z rekrutacji nwych pracwników, wyknywania przez nich bwiązków służbwych raz związane z zakńczeniem przez nich pracy lub zmianą stanwiska. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Wdrżenie frmalneg prgramu budwania świadmści persnelu nt. bezpieczeństwa infrmacji, mająceg na celu uświadmienie ważnści bezpieczeństwa Danych Chrninych. Prces ten MUSI uwzględniać: a. Dknywanie szczegółwej weryfikacji kandydatów na pracwników rganizacji, z zachwaniem należytej starannści przed ich zatrudnieniem, zgdnie z bwiązującym prawem w celu minimalizacji ryzyka. b. Szklenie persnelu p zatrudnieniu i przynajmniej raz w rku, dpwiedni d pwierznych bwiązków służbwych i pzimu uprawnień dstępu. 15 / 28

16 c. Ptwierdzanie przez persnel zapznania się i rzumienia prcedur i plityk bezpieczeństwa rganizacji Zarządzanie ryzykiem raz testy bezpieczeństwa Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżny prces regularneg przeprwadzania analizy, graniczania i akceptwania ryzyka raz testwania bezpieczeństwa należących d niej kmpnentów interfejsu PlishAPI. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Wdrżenie prcesu identyfikacji luk bezpieczeństwa przy wykrzystaniu rzetelnych źródeł infrmacji raz stwrzenie klasyfikacji pzimu ryzyk w celu pisywania nw dkrytych luk. 2. Ochrnę wszystkich kmpnentów systemu przed znanymi zagrżeniami bezpieczeństwa pprzez instalwanie dpwiednich pprawek dstawcy w terminie wynikającym z klasyfikacji aplikacji pd względem pzimu ryzyka biznesweg raz zidentyfikwanej luki. 3. Wdrżenie cykliczneg prcesu sprawdzania becnści nieautryzwanych urządzeń w sieci wewnętrznej, w tym bezprzewdwych punktów dstępu (802.11). 4. Uruchmienie wewnętrznych i zewnętrznych (z Internetu) skanów infrastruktury rganizacji ( vulnerability scan ) przynajmniej raz na rk i p wszystkich isttnych zmianach w sieci (np. instalacji nwych elementów systemu, zmian w tplgii sieci, aktualizacji prduktów) wraz z krektami i niezbędnymi pwtórzeniami, aż wszystkie prblemy wyskieg i krytyczneg ryzyka będą rzwiązane. 5. Realizację testów penetracyjnych kmpnentów interfejsu PlishAPI w parciu zalecenia OWASP (lub wypracwane własne pdejście d testów) i/lub branżwe metdyki testwania bezpieczeństwa przynajmniej raz w rku raz p każdej znaczącej mdyfikacji lub aktualizacji infrastruktury lub aplikacji. 6. Wyknywanie testów penetracyjnych przynajmniej raz w rku raz każdrazw p isttnej zmianie w infrastrukturze PlishAPI mającej wpływ na mechanizmy segmentacji lub separacji na pzimie sieci w celu weryfikacji, czy Śrdwisk Danych jest skutecznie dizlwane d innych sieci. 7. Wykrzystanie technik wykrywania włamań i/lub technik zapbiegania włamanim (systemy IDS/IPS). Mnitrwanie całeg ruchu na brzeżach Śrdwiska Danych i alarmwanie persnelu w przypadku pdejrzenia kmprmitacji. Aktualizwanie wszystkich silników wykrywania i zapbiegania włamanim w krótkim czasie p ukazaniu się aktualizacji. 8. Udkumentwanie, wykrzystywanie, uaktualnianie plityk i prcedur mnitrwania i testów bezpieczeństwa 4.14 Przeciwdziałanie praniu pieniędzy Cel: Pdmit krzystający z PlishAPI MUSI mieć wdrżne plityki związane z przeciwdziałaniem praniu pieniędzy. Pdmit krzystający z PlishAPI MUSI przestrzegać zapisów Ustawy przeciwdziałaniu praniu pieniędzy raz finanswaniu terrryzmu z dnia (Dz. U pz. 723 z późn. zm.), w zakresie wymaganym przez tę Ustawę. 16 / 28

17 4.15 Infrmwanie Użytkwników zasadach bezpieczeństwa Cel: Pdmit krzystający z PlishAPI MUSI infrmwać swich klientów zasadach bezpieczneg użytkwania interfejsu PlishAPI raz uświadamiać klientów istniejących zagrżeniach w tym zakresie. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Udstępnienie klientm przynajmniej jedneg Bezpieczneg kanału kmunikacyjneg (np. dedykwana strna www) d celów kmunikacji związanej z prawidłwym i bezpiecznym wykrzystywaniu interfejsu PlishAPI, a w tym kanale Klient POWINIEN zstać pwiadminy następujących kwestiach: Że każdy inny spsób kmunikacji mże wiązać się z próbą szustwa, Przebieg prcesu zgłaszania przez klienta pdejrzanych transakcji (fraudów), pdejrzanych zdarzeń lub anmalii w czasie sesji usługi płatnści czy pdejrzenia stswanie metd scjtechniki, Przebieg dpwiedzi na zgłszenie klienta, Przebieg prcesu pwiadamiania klienta ptencjalnych fraudach i strzeganiu atakach. 2. Infrmwanie klienta aktualizacjach prcedur bezpieczeństwa pprzez Bezpieczny kanał kmunikacyjny, pdbnie jak pwiadmienia nwych zagrżeniach (np. infrmacja próbach wyłudzenia infrmacji). 3. Udstępnienie wsparcia klienta w przypadku pytań, skarg i reklamacji, zgłszeń nieautryzwanych transakcji płatniczych, ptrzeby uzyskania pmcy technicznej, pwiadmień nietypwych sytuacjach, ptrzeby zgłaszania incydentów związanych z usługami płatniczymi i usług pwiązanych. 4. Udstępnienie klientwi niżej wymieninych infrmacji związanych z płatnściami: Wymagania dtyczące prgramwania i innych niezbędnych narzędzi (np. prgramwanie antywiruswe, firewall), Wskazówki dtyczące prawidłweg i bezpieczneg krzystania z pświadczeń służących uwierzytelnianiu, Szczegółwy pis klejnych krków prcedury wyknania i autryzwania transakcji płatniczej raz uzyskania infrmacji, w tym knsekwencje każdej czynnści, Wskazówki dtyczące prawidłweg i bezpieczneg krzystania ze sprzętu i prgramwania dstarczneg klientwi, Prcedura pstępwania na wypadek kradzieży lub zagubienia pświadczeń służących uwierzytelnianiu, sprzętu lub prgramwania, służących d lgwania się i przeprwadzania transakcji, Prcedura pstępwania w przypadku, gdy klient wykryje lub pdejrzewa incydent bezpieczeństwa lub incydent peracyjny, Opis dpwiedzialnści strn w kntekście krzystania z usług realizwanych pprzez interfejs PlishAPI. W przypadku TPP pis krków, jakie należy pdjąć celem zainicjwania przez sameg klienta prcesu wyłączenia usług. Opis warunków blkwania transakcji klienta, pwiadamiania g tym fakcie i spsbu jej wyłączenia. 5. Pinfrmwanie Użytkwnika tym, że w sytuacjach zagrżenia bezpieczeństwa transakcji, pjedyncze transakcje lub usługa płatnści mgą być blkwane. Jedncześnie MUSI zstać kreślna metda i warunki pwiadamiania klienta blkadzie i spsbie jej wyłączenia. 17 / 28

18 6. Prwadzenie prgramu edukacji i pprawy świadmści Użytkwników na temat bezpieczeństwa, mająceg na celu pmc w zrzumieniu ptrzeb dtyczących: Ochrny danych uwierzytelniających raz wszelkich pufnych danych, Zarządzania bezpieczeństwem prgramwania pprzez instalwanie i aktualizacje kmpnentów bezpieczeństwa (np. antywirusów, pprawek bezpieczeństwa itp.), Unikania zagrżeń związanych z pbieraniem i instalwaniem prgramwania pchdząceg z niezaufanych źródeł. 18 / 28

19 5 Obszar 2: Wymagania dla infrastruktury systemu 5.1 Knfiguracja sieciwa Cel: Pdmit krzystający z PlishAPI MUSI izlwać Serwery backend systemu d sieci publicznych, raz MUSI zapewniać użycie sieciwych systemów wykrywania lub przeciwdziałania włamanim. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Zastswanie knfiguracji sieciwej graniczającej płączenia pmiędzy niezaufanymi (znajdującymi się pza kntrlą rganizacji) sieciami a Śrdwiskiem Danych Ograniczenie ruchu przychdząceg i wychdząceg, niezbędneg dla Śrdwiska Danych, w szczególnści zablkwanie wszelkieg nieuzasadnineg ptrzebami bizneswymi ruchu sieciweg. Zabezpieczenie plików knfiguracji urządzeń sieciwych. 2. Zabezpieczenie przed nieautryzwanym dstępem d Śrdwiska Danych z sieci bezprzewdwych np. pprzez blkwanie ruchu sieciweg z sieci bezprzewdwych d Śrdwiska Danych, pza tym, który jest niezbędny z punktu widzenia wymagań bizneswych silne uwierzytelnianie dstępu (dwuskładnikwe) d sieci bezprzewdwych fizyczne graniczenie dystrybucji sygnału sieci bezprzewdwych wykrzystanie systemów kntrli dstępu d sieci (Netwrk Access Cntrl) 3. Uniemżliwienie bezpśrednieg płączenia pmiędzy Internetem a każdym kmpnentem systemu w Śrdwisku Danych, z wyłączeniem urządzeń infrastruktury brzegwej (na styku z Internetem), dedykwanej d teg celu: Zastswanie stref zdemilitaryzwanych (DMZ), w szczególnści w celu graniczenia ruchu przychdząceg tylk d tych niezbędnych kmpnentów i usług systemu, które zstały zatwierdzne d udstępnienia. Uniemżliwienie bezpśrednich płączeń przychdzących i wychdzących dla ruchu pmiędzy Internetem a Śrdwiskiem Danych. Wykrzystanie technik anty-spfingwych w celu wykrycia i zablkwania sfałszwanych źródłwych adresów IP. Zablkwanie nieautryzwaneg ruchu wychdząceg ze Śrdwiska Danych d Internetu. Wykrzystanie dynamiczneg filtrwania pakietów (SPI - Stateful Packet Inspectin: tylk już "ustanwine" płączenia są wpuszczane d sieci) Umieszczenie kmpnentów systemu przechwujących Dane Chrnine (takich jak bazy danych) w strefie sieci wewnętrznej, dseparwanej d niezaufanych sieci, w szczególnści sieci, z których i d których ruch z Internetu przychdzi bezpśredni. Ddatkw kmpnenty systemu POWINNY być separwane wewnątrz sieci na zasadzie minimalneg dstępu, wymaganeg d realizacji ptrzeb bizneswych. Utrzymanie w tajemnicy przed nieuprawninymi sbami prywatnych adresów IP raz infrmacji rutingu. 5.2 Knfiguracja serwerów, urządzeń raz prgramwania Cel: Pdmit krzystający z PlishAPI MUSI zapewniać aktualnść prgramwania, minimalizwać ryzyk związane ze złśliwym prgramwaniem i nieautryzwanym dstępem, zapewniać mnitrwanie zdarzeń raz uwzględniać rzdzielnść śrdwisk prdukcyjnych d testwych. 19 / 28

20 Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Zmianę dmyślnych ustawień dstępwych zawartych w knfiguracji dstawcy raz usunięcie lub dezaktywację zbędnych knt dmyślnych przed instalacją systemu w sieci. Dtyczy t wszystkich dmyślnych haseł m.in. d systemów peracyjnych, prgramwania dstarczająceg usługi bezpieczeństwa, aplikacji i knt systemwych, terminali POS, SNMP cmmunity strings itd. 2. Dla śrdwisk bezprzewdwych pdłącznych d Śrdwiska Danych lub przesyłających Dane Autryzacyjne, zmiana wszystkich dmyślnych ustawień przy instalacji m.in. dmyślnych kluczy kryptgraficznych, haseł, haseł SNMP (cmmunity strings) 3. Ustanwienie standardu knfiguracji dla wszystkich kmpnentów systemu z uwzględnieniem znanych luk bezpieczeństwa raz zgdnści z uznanymi w branży standardami hardeningu systemu, np. Center fr Internet Security (CIS), Internatinal Organizatin fr Standardizatin (ISO), SysAdmin Audit Netwrk Security (SANS) Institute, Natinal Institute f Standards Technlgy (NIST). Wdrżenie tylk jednej głównej funkcji na pjedynczej instancji systemu peracyjneg w celu zapbiegania współistnienia funkcji wymagających wykrzystania różnych pzimów bezpieczeństwa (np. serwisy bazdanwe, webwe, DNS wdrżne na sbnych serwerach) Uruchmienie tylk niezbędnych dla funkcjnwania systemu usług, prtkłów, demnów itp. Rzdział kmpnentów interfejsu PlishAPI na warstwę danych, warstwę kntrlera raz warstwę prezentacyjną. Wdrżenie ddatkwych zabezpieczeń dla wszystkich niezbędnych usług, prtkłów i demnów uważanych za niezabezpieczne, np. wykrzystanie technlgii gwarantujących pufnść i integralnść, jak SSH, SFTP, TLS czy IPSec w celu chrny niezabezpiecznych usług jak np. NetBIOS, Telnet, FTP itp. Knfiguracja parametrów bezpieczeństwa systemu zapbiegająca błędnemu użyciu. Usunięcie lub zablkwanie wszystkich zbędnych funkcjnalnści takich jak: skrypty, sterwniki, ddatki, pdsystemu, serwery plików, zbędne serwery webwe. 4. Szyfrwanie wszelkieg zdalneg dstępu administracyjneg z wykrzystaniem silnej kryptgrafii. Wykrzystanie technlgii takich jak SSH, VPN czy TLS d zarządzania z pzimu sieci web czy inneg typu zdalneg dstępu. 5. Utrzymanie aktualnej dkumentacji architektury kmpnentów i pwiązań systemów pdlegających pd interfejs PlishAPI. 6. Udkumentwanie, wykrzystywanie i udstępnienie zaintereswanym strnm plityk i prcedur, parametrów bezpieczeństwa służącym zarządzaniu i implementwaniu rzwiązań infrmatycznych 7. Oprgramwanie antywiruswe zainstalwane na wszystkich systemach narażnych na złśliwe prgramwanie, w szczególnści kmputerach sbistych i serwerach. Oprgramwanie antywiruswe MUSI być zdlne d wykrywania, usuwania złśliweg prgramwania. Dla systemów, na których stswanie systemów antywiruswych jest z biektywnych przyczyn niemżliwe lub bezzasadne, przeprwadzenie cyklicznej ceny celem identyfikacji i ceny ryzyka pd kątem ptwierdzenia czy te systemy nadal nie wymagają stswania prgramwania antywirusweg 8. Mechanizmy antywiruswe: Są aktualne, Wyknują kreswe skanwanie w pszukiwaniu złśliweg prgramwania, Generują lgi d celów audytwych. 9. Mechanizmy antywiruswe działają w spsób ciągły i nie mgą zstać zdezaktywwane przez użytkwników. 20 / 28

21 10. Udkumentwanie, wykrzystywanie i udstępnienie zaintereswanym strnm plityk i prcedur bezpieczeństwa dtyczących chrny systemów przed złśliwym prgramwaniem. 5.3 Kntrla dstępu lgiczneg Cel: System MUSI zapewniać identyfikację użytkwników i rzliczalnść działań raz zarządzanie użytkwnikami i uprawnieniami zgdnie z zasadami minimalneg dstępu. Pdmit krzystający z PlishAPI MUSI: 1. Zapewnić graniczenie dstępu d kmpnentów interfejsu PlishAPI i Danych Autryzacyjnych d grna sób, których zadania służbwe wymagają takieg dstępu. 2. Zdefiniwać wymgi dstępu dla każdej rli: Określić kmpnenty systemu i źródeł danych, d których dstęp dla danej rli jest niezbędny. Określić wymagany d dstępu d źródeł danych pzim uprawnień (np. użytkwnik, administratr itp.). Uprawnienia użytkwników graniczyć d minimalneg zakresu niezbędneg d wyknywania bwiązków służbwych. Przyznawać dstęp na pdstawie indywidualnej klasyfikacji zadań i funkcji persnelu. Wymagać udkumentwanej (pisemnej lub elektrnicznej) zgdy autryzwaneg pdmitu na przyznanie uprawnień. Stswać zasadę separacji Segregatin Of Duties. 3. Wykrzystywać system kntrli dstępu d kmpnentów systemu, który granicza dstęp na zasadzie "need t knw" z dmyślnym ustawieniem "deny all". System kntrli dstępu MUSI zawierać: Pkrycie wszystkich kmpnentów systemu Przyznawanie dstępu pszczególnym sbm na pdstawie zadań i funkcji Dmyślne ustawienie "deny all" 4. Udkumentwać, wykrzystywać i udstępniać zaintereswanym strnm plityki i prcedury bezpieczeństwa dtyczących graniczenia dstępu d Danych Autryzacyjnych 5.4 Przetwarzanie Danych Chrninych p strnie serwerwej Cel: Dane chrnine MUSZĄ być zabezpieczne zgdnie z przyjętą krytycznścią w bszarze integralnści i pufnści w trakcie przechwywania, transprtu, mdyfikacji, usuwania. Pdmit krzystający z PlishAPI MUSI zapewnić: 1. Zapewnienie integralnści i pufnści Danych Chrninych na całej drdze ich przesyłania. 2. Dstęp d Danych Chrninych jest lgwany, w spsób zapewniający ślad audytwy, przynajmniej w zakresie umżliwiającym mżliwść identyfikacji uzyskująceg dstęp persnelu lub elementu infrastruktury infrmatycznej. 3. Mdyfikacja Danych Chrninych jest mżliwa jedynie przez uprzedni uwierzytelniny i autryzwany persnel. 4. Usuwanie danych z nśników realizwane w spsób uniemżliwiający ich dtwrzenie. 5. Dane Autryzacyjne mgą być przechwywane przez Pdmit krzystający z PlishAPI jedynie przez czas niezbędnie wymagany d bsługi prcesu płatnści i reklamacji. Pdmit krzystający z PlishAPI MUSI dłżyć wszelkich starań, aby zagwarantwać integralnść raz pufnść Danych Chrninych przetwarzanych w infrastrukturze. 21 / 28

22 5.5 Zarządzanie kluczami kryptgraficznymi Cel: System MUSI zapewniać bezpieczeństw kluczy kryptgraficznych w całym ich cyklu życia. Pdmit krzystający z PlishAPI MUSI: 1. Wdrżyć zasady krzystania z zabezpieczeń kryptgraficznych. 2. Wdrżyć zasady zarządzania kluczami, które umżliwią krzystanie z technik kryptgraficznych, zawierające przynajmniej: Generwanie klucza. Przechwywanie raz kpie zapaswe kluczy. Cel użycia klucza. Długść klucza. Czas życia klucza. Dystrybucja klucza. Wymiana klucza. Usuwanie i archiwizacja klucza. 5.6 Zapewnienie wyskiej dstępnści usług Cel: System MUSI zapewniać wyską dstępnść usług zgdnie z przyjętą klasyfikacją krytycznści, w szczególnści pprzez redundancję kmpnentów, wyknywanie kpii zapaswych danych i prgramwania raz autmatyczne pdtrzymywanie ciągłści pracy systemu. Pdmit krzystający z PlishAPI MUSI: 1. Zapewnić dstępnść usług systemu zgdnie przyjętymi warunkami SLA zawartymi w umwach raz wynikami analizy ryzyk przeprwadznej przez Pdmitu krzystająceg z PlishAPI. 22 / 28

23 6 Obszar 3: Wymagania dla interfejsu PlishAPI 6.1 Uwierzytelnienie i autryzacja w ramach PlishAPI Cel: Dstęp d usług interfejsu PlishAPI MUSI być mżliwy jedynie dla uprawnineg Pdmitu krzystająceg z PlishAPI raz Użytkwnika. Spsób uwierzytelnienia Pdmitu krzystająceg z PlishAPI i Użytkwnika raz autryzacji ich działań MUSI zapewniać minimalizację ryzyka nieautryzwaneg dstępu. 1. Pdmity krzystające z PlishAPI MUSZĄ zstać pprawnie uwierzytelnine przed udzieleniem im dstępu d interfejsu XS2A. Błędy uwierzytelnienia MUSZĄ skutkwać dmwą dstępu d interfejsu XS2A. 2. Uwierzytelnienie MUSI nastąpić w parciu certyfikaty klucza publiczneg w prcesie wzajemneg uwierzytelnienia ( Mutual authenticatin ) za pmcą prtkłu TLS Pdmity krzystające z PlishAPI MUSZĄ psiadać ważny certyfikat, służący d wzajemnej identyfikacji w interfejsie XS2A, trzymany d kwalifikwaneg dstawcy usług zaufania, spełniająceg wymgi regulacyjne w bszarze usług zaufania raz identyfikacji elektrnicznej. Certyfikat ten MUSI spełniać wymagania zdefiniwane w RTS raz specyfikacji technicznej ETSI (TS ). Pdmity krzystające z PlishAPI MUSZĄ każdrazw w ramach prcesu uwierzytelnienia zweryfikwać ważnść (przy wykrzystaniu prtkłu OCSP lub listy CRL) wszystkich certyfikatów znajdujących się na ścieżce certyfikacji. 4. TPP MUSI być zarejestrwane w przynajmniej jednym rejestrze w kraju człnkwskim Unii Eurpejskiej w rli, w której chce występwać pdczas realizacji kmunikacji partej na standardzie PlishAPI. ASPSP POWINNO zweryfikwać status rejestracji TPP w ramach prcedury uwierzytelnienia. 5. Autryzacja TPP MUSI być parta na mdelu RBAC (Rle Based Access Cntrl), w którym pzim i zakres dstępu d pszczególnych zasbów API zależy d rli Pdmitu krzystająceg z PlishAPI. 6. Użycie pszczególnych metd w ramach interfejsu PlishAPI MUSI być autryzwane w taki spsób, aby uprawnienia były zależne d rli Pdmitu krzystająceg z PlishAPI i zakresu udzielnych mu przez Użytkwnika zgód. W szczególnści, pzim i zakres autryzacji POWINIEN być różny dla TPP w zależnści d zakresu ich uprawnień. 7. Użytkwnik (PSU) MUSI zstać uwierzytelniny p strnie ASPSP lub w zewnętrznym narzędziu autryzacyjnym (EAT). 8. Uwierzytelnienie Użytkwnika (PSU) MUSI zstać przeprwadzne z wykrzystaniem prcedury SCA we wszystkich przypadkach wymaganych przez dyrektywę PSD2. W przypadku mżliwści zwlnienia transakcji z bwiązku realizacji prcedury SCA, decyzja taka pzstaje w gestii ASPSP. 9. Uwierzytelnienie p strnie ASPSP MUSI nastąpić p przekierwaniu na strnę ASPSP, przez c dane uwierzytelniające i autryzacyjne PSU MUSZĄ być przekazywane wyłącznie ASPSP. 10. W przypadku aplikacji mbilnych, przekierwanie na strnę ASPSP i z pwrtem na strnę TPP MUSI dbywać się w przeglądarce systemwej (nie są dpuszczne przeglądarki inne niż systemwa, nie jest dpuszczne stswanie WebView), a nie w samej aplikacji mbilnej. TPP mże zarejestrwać dpwiedni URL w systemie peracyjnym urządzenia, aby p przekierwaniu d TPP autmatycznie wznwić aplikację mbilną. 11. Uwierzytelnianie PSU w zewnętrznym narzędziu autryzacyjnym (EAT) MUSI spełniać następujące warunki: EAT MUSI zapewniać funkcjnalnść silneg uwierzytelnienia PSU SCA, w rzumieniu technicznych wymgów dyrektywy PSD2; PSU MUSI uprzedni pmyślnie aktywwać dstęp d narzędzia EAT zgdnie z prcedurą pracwaną i wymaganą przez każdeg z ASPSP; 23 / 28