Bezpieczeństwo SaaS według DORA

Digital Operational Resilience Act (rozporządzenie (UE) 2022/2554) to jednolity zbiór przepisów o cyfrowej odporności operacyjnej sektora finansowego UE. Stosuje się bezpośrednio we wszystkich państwach członkowskich od 17 stycznia 2025 r. Obejmuje banki, zakłady ubezpieczeń, firmy inwestycyjne, instytucje płatnicze i instytucje pieniądza elektronicznego oraz inne podmioty finansowe.

Rozporządzenie opiera się na pięciu filarach: zarządzaniu ryzykiem ICT, zarządzaniu incydentami ICT i ich zgłaszaniu, testowaniu cyfrowej odporności operacyjnej, zarządzaniu ryzykiem stron trzecich w ICT oraz wymianie informacji. SaaS dotyczy przede wszystkim filaru ryzyka stron trzecich.

Niemal każda aplikacja SaaS używana przez podmiot finansowy, na przykład pakiet do współpracy, CRM, HR, analitykę czy zarządzanie dokumentami, jest usługą ICT świadczoną przez stronę trzecią. Umowa liczy się więc jako umowa z zewnętrznym dostawcą usług ICT zgodnie z rozdziałem DORA o ryzyku stron trzecich.

Dostawcy uznani za krytycznych zewnętrznych dostawców usług ICT są dodatkowo nadzorowani bezpośrednio przez europejskie urzędy nadzoru. Nadzór ten nie przenosi odpowiedzialności: podmiot finansowy nadal odpowiada przed własnym organem nadzoru za odporność funkcji wspieranych przez SaaS.

DORA wymaga, aby każdy podmiot finansowy prowadził rejestr informacji obejmujący wszystkie umowy z zewnętrznymi dostawcami usług ICT. Każda umowa SaaS musi się w nim znaleźć. Rejestr zawiera tożsamość dostawcy, opis usług, informację, czy wspierają funkcje krytyczne lub ważne, łańcuch podwykonawców, lokalizacje danych i prawa do rozwiązania umowy.

Rejestr trafia do właściwych organów, które przekazują informacje Europejskim Urzędom Nadzoru. Niekompletne wpisy o SaaS wychodzą więc na jaw podczas kontroli nadzorczej, zamiast pozostać wewnętrzną luką. Dobrym punktem wyjścia jest dokładny rejestr aktywów IT.

Ocena to obowiązek przez cały cykl życia usługi, a nie formalność zakupowa. Przed poleganiem na usłudze SaaS podmiot musi ocenić zdolności techniczne dostawcy, jego praktyki bezpieczeństwa, jakość wsparcia i kondycję finansową, a przegląd powtarzać przy każdej zmianie okoliczności.

Koncentracji ryzyka poświęca się osobną uwagę. Gdy wiele podmiotów korzysta z tych samych kilku platform SaaS, awaria jednego dostawcy staje się zdarzeniem całego sektora, dlatego rejestr pokazuje też, na ile każda usługa jest zastępowalna.

DORA określa minimalną treść umów o usługi ICT. W praktyce umowa SaaS musi zawierać co najmniej te postanowienia:

DORA ujednolica klasyfikację i zgłaszanie poważnych incydentów związanych z ICT. Incydent, który zaczyna się u dostawcy SaaS, pozostaje incydentem podmiotu. Podmiot musi wykryć, że zależność uległa degradacji, i ocenić wpływ na własne funkcje.

Nie każdy poważny incydent to naruszenie danych. Awaria dostawcy, która zatrzymuje krytyczną usługę, też może podlegać zgłoszeniu. Raporty wstępny, pośredni i końcowy trzeba złożyć w wyznaczonych terminach, dlatego wcześniej trzeba wiedzieć, które funkcje opierają się na których usługach.

Testy odporności muszą uwzględniać wymiar stron trzecich. Programy testów, w tym testy penetracyjne oparte na analizie zagrożeń (TLPT) dla podmiotów wskazanych przez organ, powinny obejmować scenariusze, w których usługa SaaS jest niedostępna, zdegradowana lub skompromitowana. Trzeba sprawdzić, czy mechanizmy odtwarzania i strategie wyjścia działają pod presją, a nie tylko istnieją w dokumentacji.

Nie każdy obowiązek dotyczy każdej usługi w ten sam sposób. Takie obowiązki zwykle prowadzi się w ramach zarządzania zgodnością, a status poniżej zależy od zakresu.

Żadna pojedyncza kontrola nie obejmuje całego obrazu SaaS. Przegląd umów sprawdza dokumenty, a inwentarz i logi aktywności pokazują, czego faktycznie się używa. Usługi wdrażane bez zgody, czyli sedno Shadow IT, leżą w luce między nimi.

Rozporządzenie wyznacza obowiązki, ale praktyka zaczyna się od wiedzy, jakich usług SaaS organizacja faktycznie używa. Usługi wdrożone samowolnie przez poszczególne zespoły nigdy nie trafiają do rejestru i nie są oceniane, a przepływają nimi te same dane co przez usługi zatwierdzone.

Żadna z poniższych kontroli nie jest wymieniona w rozporządzeniu z nazwy. Bez nich obowiązki, które rozporządzenie wymienia, trudno spełnić. Egzekwowanie tego, jakie dane mogą trafić do której usługi, to zadanie zapobiegania utracie danych.

1. 1

   Zacznij od inwentarza

   Zapisz każdą używaną aplikację SaaS, także te, które pracownicy wdrażają samodzielnie.

2. 2

   Sklasyfikuj dane

   Określ, jakie dane mogą trafić do której usługi.

3. 3

   Obejmij kanały wejścia

   Stosuj zapobieganie utracie danych przy wysyłkach z przeglądarki, klientach synchronizacji i poczcie, aby dane regulowane trafiały tylko do usług z rejestru.

4. 4

   Rejestruj aktywność użytkowników

   Prowadź ślad dowodowy w aplikacjach SaaS i wokół nich, potrzebny przy klasyfikacji incydentów i pytaniach organów nadzoru.

Zacznij od danych, których wyciek zaszkodziłby najbardziej, a potem zmapuj usługi, które mogą je otrzymać. Polityka klasyfikacji danych daje wszystkim umowom i kontrolom wspólny punkt odniesienia.

Czytaj dalej: Koncepcja "Zero Trust".