PolishAPI a bezpieczeństwo, czyli kolejne starcie z najnowszymi rekomendacjami ZBP w sprawie bezpieczeństwa
W piątek cashless.pl opublikowało, powołując się na słowa rzecznika prasowego Komisji Nadzoru Finansowego, informację o tym, że żaden z polskich fintechów ubiegających się o zezwolenie na wykonywanie usług PIS oraz AIS nie uzyskał zezwolenia. Z kolei w ostatnim artykule przeszliśmy przez pierwszych kilka rekomendacji Grupy roboczej ds. PolishAPI przy Związku Banków Polskich. Rekomendacje mają istotne znaczenie zarówno dla Third Party Providers, jak i banków (i to nie tylko w roli dostawców prowadzących rachunki, ale również TPP). Warto przyjrzeć się pozostałym wskazówkom, również w kontekście świadczenia usług kluczowych oraz zapewnienia cyberbezpieczeństwa, które w kontekście działalności bankowej i płatniczej mają szczególne znaczenie. To także istotna wskazówka dla fintechów odnośnie wymogów jakie stawia KNF w procesie licencyjnym (co potwierdza zresztą treść projektowanego Rozporządzenia w sprawie wymogów „dokumentowych” – Rozporządzenie). Dzisiaj przejdziemy przez kolejne wymagania dotyczące organizacji wewnętrznej.
Kolejnym wymogiem jest posiadanie odpowiednich zabezpieczeń przed nieuprawnionym dostępem do pomieszczeń, w którym przetwarzane są dane wrażliwe (w tym stanowiące tajemnicę zawodową i bankową), a ponadto należy wdrożyć odpowiednie środki bezpieczeństwa środowiskowego dla systemu.
Bezpieczeństwo fizyczne i środowiskowe
Generalnie rekomendacja będzie odnosiła się przede wszystkim do serwerowni (data center) i/lub pomieszczeń, w których zapewnia się dostęp do danych wrażliwych (w tym poprzez cloud connectivity). Ten element został wskazany nie tylko w rekomendacji grupy ds. PolishAPI, ale również w § 5 pkt 5) ww. Rozporządzenia. Rekomendacja ponownie jest dość ogólna i wskazuje na pewne pożądane zabezpieczenia, w tym wykorzystanie kamer czy innych mechanizmów kontroli fizycznej (np. dostęp z wykorzystaniem linii papilarnych). Nagrania z kamer powinny być przechowywane przez co najmniej 3 miesiące (lub dłużej). Bardzo istotne będzie również przechowywanie logów z systemu, szczególnie jeżeli niektórzy pracownicy korzystają ze zdalnego dostępu, który nota bene powinien być maksymalnie ograniczony.
Nieco bardziej precyzyjne są z kolei zapisy projektowanego Rozporządzenia w sprawie warunków organizacyjnych i technicznych dla podmiotów świadczących usługi z zakresu cyberbezpieczeństwa oraz wewnętrznych struktur organizacyjnych operatorów usług kluczowych odpowiedzialnych za cyberbezpieczeństwo (§ 2), które można wykorzystywać posiłkowo i oczywiście proporcjonalnie. Te przepisy przykładowo stanowią o konieczności posiadania systemów sygnalizacji włamania i napadu zgodnie z normami krajowymi (PN-EN-5013101) czy szafy zgodnie z PN-EN-14450. Wymogów szczegółowych jest jednak znacznie więcej.
Procedury?
Niezwykle istotne jest maksymalne ograniczenie dostępu do pomieszczeń (oraz samej infrastruktury), w których przetwarzane są dane wrażliwe. Oznacza to konieczność wdrożenia stosownych procedur i regulaminów, w tym w zakresie nadawania oraz unieważniania dostępów. W tym miejscu warto wskazać na wytyczne EBA w sprawie ryzyk operacyjnych i bezpieczeństwa (wytyczna nr 4.9), które „nakazują” ograniczenie dostępu do wrażliwych danych jedynie osobom, które bezwzględnie muszą posiadać do nich dostęp ze względów biznesowych (i prawnych). Sam proces nadawania uprawnień powinien odbywać się na zasadzie wiedzy koniecznej oraz z użyciem silnego uwierzytelniania (nie mylić z SCA w rozumieniu Rozporządzenia 2018/389). Jest to o tyle istotne, że nadanie zbyt wielu uprawnień (w kontekście ich „szerokości”) zbyt wielu osobom rodzi problemy natury dowodowej w przypadku wystąpienia incydentu. Zasad „deny all” znajduje tutaj swoje zastosowanie.
Rekomendacja ZBP wskazuje również na wymóg prowadzania tzw. „księgi gości” czy ich eskortowanie przez upoważnionego pracownika. Ważne jest dokumentowanie wszystkich tego typu sytuacji. Nie mniej istotne jest również wdrożenie procedur ochrony przed zagrożeniami zewnętrznymi, jak pożary, zalanie czy inne katastrofy naturalne lub wywołane przez człowieka. Elementem tych procedur, co może wydawać się nieco zaskakujące, jest również polityka czystego ekranu czy czystego biurka. Mają one na celu zminimalizowanie ryzyka „wycieku” wrażliwych danych.
Same polityki i procedury bezpieczeństwa powinny podlegać regularnemu przeglądowi (podobnie z resztą jak same uprawnienia dostępowe). W szczególności powinny być aktualizowane w przypadku wykrycia istotnych incydentów, które wpływają na jej „ważność” i poziom gwarantowanego bezpieczeństwa. Poza przeglądem dokonywanym przez komórki bezpieczeństwa, powinny one być sprawdzane przez komórki kontroli wewnętrznej. Wszystkich pracowników, które takie polityki lub procedury mogą „dotykać”, należy przeszkolić i zebrać stosowne oświadczenia odnośnie zapoznania się z ich treścią.
Eksploatacja i zarządzania zmianami
Kolejna rekomendacja grupy ds. PolishAPI ma wprawdzie charakter stricte dotyczący tego standardu, jednak mogą być one stosowane z powodzeniem w ogóle do różnych środowisk teleinformatycznych. ZBP sugeruje wyraźną separację środowiska testowego od środowiska produkcyjnego. Na obecnym etapie będzie to miało znaczenie raczej w przypadku wystawiania tzw. sandboxów przez niektóre banki (w tym na potrzeby wewnętrzne). Z drugiej strony API może podlegać nieustannym zmianom, w szczególności wobec pojawiania się nowych wersji, ale również zmiany dostawców technologicznych.
Z tego względu istotne będzie wprowadzenie separacji obowiązków (w regulaminach organizacyjnych oraz polityce bezpieczeństwa) w stosunku do osób, które odpowiadają za środowisko testowe i produkcyjne (tutaj zgodnie z ww. wytycznymi w zakresie „niezbędnej wiedzy”). Bardzo istotne, nie tylko z punktu widzenia polityki bezpieczeństwa, ale również Prawa bankowego (art. 105), Rozporządzenia 2016/679 czy ustawy o usługach płatniczych (m.in. art. 10). Chodzi o sytuację wykorzystania danych produkcyjnych dla potrzeb testowych. W chwili obecnej takie sytuacje będą należały raczej do rzadkości, choć nie można wykluczyć, że niektóre banki zdecydują się na testowanie nowych usług typu premium w ramach swoich interfejsów dostępowych. W takiej sytuacji procedury i procesy selekcji i anonimizacji danych oraz ograniczonego dostępu powinny również mieć zastosowanie.
Nie mniej istotne będzie również wdrożenie odpowiednich zasad dotyczących wprowadzania zmian w oprogramowaniu, co ma szczególne znacznie dla zapewnienie cyberbezpieczeństwa (wyobraźmy sobie możliwość „patchowania” oprogramowania obsługującego wrażliwe dane bez odpowiedniej kontroli). Grupa rekomenduje więc, aby każda zmiana była wprowadzana przez upoważnionego pracownika, który wykona również stosowne testy funkcjonalności oraz udokumentuje jej wprowadzenie.
Zapewnienie bezpieczeństwa w całym cyklu życia
Tutaj istotne znaczenie będzie spełnienie (z punktu widzenia banku oczywiście) wymagań projektowanego rozporządzenia w sprawie w sprawie sposobu tworzenia, utrwalania, przekazywania, przechowywania i zabezpieczania dokumentów związanych z czynnościami bankowymi, sporządzanych na elektronicznych nośnikach informacji (choć sama rekomendacja nie odnosi się wprost do tego rozporządzenia). Na dużym poziomie ogólności można wskazać, że podmiot musi wdrożyć procedury zapewniające integralność i poufność danych wrażliwych w całym cyklu życia systemów ICT (tutaj oczywiście grupa odnosi się do danych wykorzystywanych na potrzeby PolishAPI).
Patrząc bardziej szczegółowo, podmiot musi posiadać takie rozwiązania, które zapewniają, że w przypadku „stawiania” nowej infrastruktury czy oprogramowania spełniały one wymogi dla PolishAPI (a więc taki dostawca, w tym cloud’owy powinien stosować się do rekomendacji ZBP). Obejmuje to m.in. ochronę przed nieautoryzowanym dostępem do kodu źródłowego czy regularne monitorowanie występujących luk w zabezpieczeniach. To także nieustanne debugowanie oprogramowania i weryfikacja czy spełnia on standardy rynkowe, w tym w zakresie programowania.
Incydenty
Rekomendacja w zakresie zgłaszania i obsługi incydentów pokrywa się zasadniczo z wytycznymi EBA w zakresie zgłaszania istotnych incydentów. Oba dokumenty wymagają wdrożenia takich rozwiązań, które zapewniają szybką, skuteczną i uporządkowaną reakcję na incydenty bezpieczeństwa i szerzej – operacyjne. Rekomendacja grupy wskazuje na konieczność opracowania planu reakcji, który obejmuje m.in. określenie zasad odpowiedzialności i eskalacji, gromadzenia danych (szczególnie istotne w świetle komunikatu KNF) oraz raportowania.
Co w kolejnej odsłonie?
Skończymy kwestie organizacyjne i przejdziemy do bardziej szczegółowych wymagań w zakresie infrastruktury ICT.