Financial Stability Board o chmurze. Czy lokalne centra danych to dobre rozwiązanie?

O projekcie komunikatu KNF ws. wykorzystania chmury obliczeniowej w sektorze finansowym napisano wiele (sam wolę nie komentować niepublicznego dokumentu regulatora). Przy okazji publikowania wytycznych czy rekomendacji (np. Europejskiego Urzędu Nadzoru Bankowego EBA w sprawie outsourcingu i komunikatu KNF – więcej w tym artykule). Poza oczywistymi zagrożeniami dla bezpieczeństwa danych klientów, często zapomina się o równie istotnych aspektach systemowych, które mogą stanowić wyzwanie nie tylko dla samej instytucji finansowej, ale również całej gospodarki. Tej „palącej” kwestii przyjrzała się Financial Stability Board, która w najnowszym raporcie „Third-party dependencies in cloud services. Considerations on financial stability implications” nakreśla potencjalne ryzyka związane z użyciem chmury. Przejdźmy przez najważniejsze elementy raportu. Zaczynamy!

O chmurze i wymaganiach związanych z jej wykorzystaniem w sektorze finansowym pisałem m.in. tutaj, więc zainteresowanych poszerzeniem wiedzy na jej temat zachęcam do zapoznania się z artykułem. W dalszej części pominę kwestie „podstawowe” (definicyjne).

Pierwsze i najważniejsze

Wcale nie obawa o bezpieczeństwo danych (a przynajmniej nie bezpośrednio) może przyczynić się do wygenerowania ryzyka systemowego. Największym „wyzwaniem” dla organów publicznych jest skalowalność rozwiązań chmurowych (oraz praktycznie nieograniczona zastępowalność funkcji wykonywanych przez banki „osobiście) i stosunkowo niewielka liczba znaczących dostawców (np. istotnych „regionalnie” – może nowa kategoria Systemically Important Cloud Provider?).

Jak sektor finansowy wykorzystuje chmurę i gdzie największe ryzyka?

Oczywiście na wiele sposobów, ale w przypadku „mniej istotnych” funkcji, które zazwyczaj nie są powiązane z przetwarzaniem danych osobowych (tajemnicy zawodowej/bankowej) ryzyko – potencjalnie – nie jest aż tak wysokie. Zazwyczaj skupiamy się więc na tzw. outsourcingu szczególnym, specjalnym, istotnym czy krytycznym (zależnie od tego do jakich wytycznych się odnosimy).

Zdaniem FSB nie jest to podejście do końca uzasadnione. Zauważalna jest tendencja do powierzania dostawcom chmurowych takich funkcji jak zarządzanie kadrami, relacjami z klientami czy sprawozdawczością finansową. Na pierwszy rzut oka nie widać dużego ryzyka, jeżeli jednak jako instytucja „uzależnimy” się od usług zewnętrznego dostawcy (dodatkowo trudno zastępowalnego) i zrezygnujemy z rozwiązań on-site, to okazać się może, że mamy ryzyko koncentracji (i to nie tylko na poziomie indywidualnym, ale i sektorowym).

Największym ryzykiem jest „zależność” (interdependencies), która o ile nie występuje lub jest trudna do zrealizowania, może zaszkodzić instytucji. Jeżeli dołożymy do tego kolejne podmioty w „łańcuchu”, np. fintechy z którymi współpracują bankami, a które zazwyczaj „wchodzą” w chmurę, to powinna zapalić się pomarańczowa lampka.

Zróbmy analizę zysków i strat

A zaczniemy od potencjalnych benefitów. Zdaniem FSB należą do nich m.in. możliwość obniżenia kosztów (bezsprzecznie), elastyczność (szczególnie w modelu SaaS), skalowalność (pod warunkiem uzyskania zgody regulatora), standaryzacja (zasadniczo wszyscy oferują to samo), bezpieczeństwo i odporność (to oczywiście zależy od dostawcy, ale i samej instytucji – więcej nt. zarządzania ryzykiem IT i bezpieczeństwa w tym artykule).

I płynnie przejdźmy do ryzyk. Po pierwsze w przypadku błędu/awarii (a FSB podaje dane, że w jednej z ankiet „wyszło”, że ilość incydentów operacyjnych przy użyciu IaaS może być znacząca) po stronie dostawcy usługi chmurowej odpowiedzialność względem klientów i tak ponosi instytucja (zakładając oczywiście model „unijny”). Dołóżmy do tego „niechęć” do (roz)budowy własnej infrastruktury oraz rozwiązań w zakresie outsourcingowego audytu i compliance wobec łatwej i szybkiej skalowalności przez cloud i problem – potencjalnie – gotowy.

FSB ma świadomość również, że ryzyko znaczącego błędu/awarii po stronie dostawców chmurowych (mam wrażenie przy tym, że raport koncentruje się tylko na największych graczach jak AWS czy Azure) jest niewielkie, ale nie niemożliwe i musi być ujęte w planie zarządzania ryzykiem oraz planach ciągłości działania (oraz Exit Planie). Plan będzie ważny też przy całkowitej utracie danych (co również jest możliwe).

Ryzyko koncentracji

Największym zagrożeniem będzie na rynkach gdzie dostęp do mniejszych dostawców jest ograniczony (lub podyktowany konstrukcją wytycznych regulatora). Wyzwaniem dodatkowo może być brak danych co do „koncentracji” outsourcingu wokół konkretnych dostawców (w Polsce takie dane są raczej dostępne regulatorowi, choć pozostaje pytanie czy były przeprowadzane stosowne „ćwiczenia” – być może stress-testy).

Jeżeli więc dojdzie do awarii/upadłości jednego podmiotu to zagrożony może być cały system finansowy. Nawet jeżeli jest to „solidny” dostawca to – idąc tropem FSB – ryzyko nadal istnieje i powinno być w odpowiedni sposób mitygowane (to wyraźna rekomendacja FSB, aby umowy outsourcingowe takie scenariusze również zawierały). Takim mitygantem będzie np. wdrożenie odpowiednich rozwiązań prawnych, operacyjnych i technologicznych umożliwiających uruchomienie „upadłej” usługi u innego dostawcy. Inna sprawa, że nie zawsze może być to możliwe, szczególnie jeżeli instytucja nie będzie miała odpowiedniej „capacity” do utrzymania usług/i lub transfer do innego dostawcy z jakichś powodów może być utrudniony (zgoda organu nadzoru i/lub brak zastępowalności).

Można więc skorzystać z usług wielu dostawców. Też niezupełnie. Oznaczałoby to konieczność zawierania wielu umów i być może korzystania przez dostawców chmury z różnych standardów/wytycznych, co również może obrócić się przeciwko instytucji. Łatwo więc nie jest.

Mamy też aspekt międzynarodowy, czyli lokalne data center

Dobrze znany sektorowi bankowemu w Polsce i polegający na pewnych trudnościach w egzekwowaniu umów outsourcingowych zawieranych z dostawcami spoza Europejskiego Obszaru Gospodarczego (oraz analogicznym trudnościom dla regulatorów). Temat opisany wielokrotnie, więc nie ma sensu go powielać. Warto zwrócić jednak uwagę na to jak odnosi się do tego FSB.

Rada zwróciła uwagę, że w niektórych jurysdykcjach istnieje lub będzie istniał obowiązek korzystania z lokalnym centrów danych. Jest to wyraz dbałości o bezpieczeństwo, w tym poprzez ułatwienie nadzorcom dostępu do tych danych (np. w przypadku upadłości podmiotu), ale jest też druga strona medalu.

FSB wskazuje bowiem, że – abstrahując od kosztów implementacji – możemy mieć tutaj inne wyzwania. Poza ryzykami dla bezpieczeństwa (wszyscy wiemy, gdzie są dane), mamy również ograniczenia w zakresie wykorzystania globalnych rozwiązań compliance oraz zarządzania ryzykami, co ma szczególne znaczenie w przypadku dużych podmiotów (w tym należących do grup kapitałowych). Dodatkowo, pewne trudności może rodzić ewentualny dostęp do danych przez innych regulatorów (a co zdaniem FSB jest to kluczowe dla utrzymania stabilności finansowej na międzynarodowym poziomie).

Co więc rekomenduje FSB?

Zasadniczo trzy kwestie. Po pierwsze dyskusje na temat potrzeby uregulowania ryzyk związanych z wykorzystaniem chmury przez instytucje finansowe na poziomie międzynarodowym. Po drugie – rozważenie ewentualnej współpracy pomiędzy nadzorcami w przypadku wykorzystania chmury przez sektor. I po trzecie wreszcie, „wystandaryzowanie” zasad dotyczących tzw. interoperability w środowisku chmurowym. Tyle.