KNF każe prześwietlić SaaS: certyfikat dostawcy już nie wystarczy

Urząd Komisji Nadzoru Finansowego w komunikacie z 5 października 2026 r. zalecił podmiotom rynku finansowego przegląd używanych usług SaaS oraz mechanizmów zarządzania ryzykiem dostawców ICT. Powodem są obserwowane ataki na dostawców oprogramowania i incydenty naruszenia bezpieczeństwa przetwarzanych przez nich danych. Ocena ma ustalić, jakie dane trafiają do usługi, kto i na jakich prawach z niej korzysta, z czym jest połączona oraz czy przejęte konto lub poświadczenia mogą otworzyć dostęp do kolejnych zasobów.

Przegląd sięga poza główne systemy instytucji. Jak opisuje ITReseller, obejmuje również aplikacje księgowe, kadrowe, sprzedażowe i komunikacyjne, także kupowane samodzielnie przez poszczególne działy. Publikacja wskazuje incydenty dotyczące MyDr, Qbusoft/Medyc i Fakturowni jako kontekst zaleceń. Usługa pomocnicza może bowiem przechowywać dane wymagające ochrony lub mieć połączenie z ważniejszym systemem.

Certyfikat trzeba odnieść do konkretnej usługi

W pełnych rekomendacjach UKNF zapisano: „Posiadanie certyfikatu nie powinno być traktowane jako wystarczające potwierdzenie bezpieczeństwa usługi”. Przy ponownej ocenie dostawcy trzeba sprawdzić autentyczność i aktualność certyfikatów oraz raportów z audytu. Liczy się również ich zakres: dokument dotyczący firmy nie daje jeszcze odpowiedzi, czy obejmuje usługę i środowisko, w którym przetwarzane są dane danego podmiotu.

Do oceny należą skuteczność zabezpieczeń, wyniki testów i sposób usuwania stwierdzonych nieprawidłowości. Jeśli deklarowane środki odbiegają od rzeczywistego sposobu świadczenia usługi, braki trzeba omówić z dostawcą i ustalić sposób ich usunięcia albo ograniczenia ryzyka. Istotna zmiana usługi, incydent lub zmiana zakresu certyfikacji uzasadniają ponowną ocenę; wcześniej zebrany raport nie opisuje automatycznie nowych warunków.

Osobnym ustaleniem jest podział odpowiedzialności. Przy każdej usłudze powinno być jasne, kto konfiguruje zabezpieczenia, zarządza tożsamością użytkowników, rejestruje zdarzenia i odtwarza dane. Taki podział pokazuje, które działania instytucja może wykonać sama, a które wymagają współpracy z dostawcą.

Co powinno znaleźć się w przeglądzie SaaS

Podstawą jest kompletna inwentaryzacja usług, powiązana z ewidencją umów i oceną znaczenia wspieranych funkcji. Dla każdej aplikacji trzeba wskazać właściciela po stronie instytucji, obsługiwany proces, kategorie danych oraz skutki naruszenia ich poufności, integralności lub dostępności. Dopiero taki obraz pozwala oceniać uprawnienia i zabezpieczenia w kontekście rzeczywistego użycia usługi.

• Dane: które informacje są przekazywane dostawcy i czy każda kategoria jest potrzebna do wykonania usługi? Zakres obejmuje również archiwa, eksporty, kopie zapasowe i środowiska testowe. Trzeba ustalić uzasadniony czas przechowywania oraz zasady zwrotu i usunięcia danych po zakończeniu współpracy, wraz z możliwością potwierdzenia tych czynności.
• Uprawnienia: które konta administracyjne, techniczne i aplikacyjne mogą odczytywać dane albo zmieniać ustawienia? Dostęp powinien mieć właściciela, zatwierdzenie i ślad umożliwiający późniejszą kontrolę. Nieużywane konta należy wyłączyć, a uprawnienia ponownie ocenić po zmianie stanowiska pracownika, zakończeniu współpracy lub zmianie celu integracji.
• Integracje: z jakimi systemami wewnętrznymi i zewnętrznymi łączy się SaaS, jakie dane przechodzą przez połączenie i jakie operacje można za jego pomocą wykonać? Szczególnej uwagi wymagają integracje pozwalające na masowy odczyt lub eksport danych, zmianę uprawnień oraz działanie w wielu systemach. Gdy pozwala na to architektura, instytucja powinna móc szybko odciąć pojedyncze połączenie bez oczekiwania na dostawcę.
• Poświadczenia: gdzie znajdują się hasła, tokeny, klucze API i certyfikaty techniczne, kto odpowiada za ich wymianę i jak można je unieważnić? Przegląd obejmuje ochronę kluczy prywatnych, rozdzielenie poświadczeń między integracjami i środowiskami oraz możliwość zakończenia aktywnych sesji po podejrzeniu przejęcia. Dla kont administracyjnych zalecane jest uwierzytelnianie wieloskładnikowe.

Te obszary trzeba oceniać łącznie. Ograniczony dostęp użytkownika nie wystarczy, jeśli token integracyjny nadal pozwala pobierać duże ilości danych; poprawnie skonfigurowane połączenie nie rozwiązuje z kolei problemu zbędnych kopii pozostających u dostawcy. Wynikiem przeglądu powinien być opis faktycznych dostępów, przepływów danych i możliwości ich ograniczenia.

Wspólni podwykonawcy łączą pozornie odrębne usługi

Ocena dostawcy musi sięgać dalej niż nazwa firmy na umowie. Instytucja powinna ustalić, jakie podmioty uczestniczą w świadczeniu usługi, gdzie przetwarzają dane i kto może uzyskać do nich dostęp. Znaczenie mają również zmiany w łańcuchu dostaw oraz zależność od podwykonawców, których działanie warunkuje dostępność usługi.

Dwie aplikacje mogą wyglądać na niezależne, a korzystać z tego samego dostawcy chmury lub mechanizmu uwierzytelniania. Awaria wspólnego elementu mogłaby wtedy zakłócić kilka procesów naraz, także dostęp do rozwiązania przewidzianego jako zastępcze. Dlatego ewidencja usług powinna pokazywać powiązania między nimi, a nie wyłącznie osobne oceny poszczególnych dostawców.

Incydent sprawdzi możliwość odcięcia dostępu i odtworzenia usługi

Uzgodnienia z dostawcą powinny określać powiadamianie o incydentach, współpracę przy ich obsłudze oraz dostęp do informacji i logów potrzebnych do oceny skutków. Procedura reagowania ma uwzględniać odłączenie integracji, unieważnienie zagrożonych poświadczeń, sprawdzenie integralności danych i analizę operacji wykonanych przez przejęte konto. Ważne jest również, czy instytucja potrafi zabezpieczyć dowody niezależnie od dostawcy.

Rekomendacje przewidują sprawdzenie odzyskiwania danych, uruchamiania rozwiązań zastępczych i zakończenia korzystania z usługi. Ćwiczenie może obejmować przejęcie konta administratora albo naruszenie środowiska usługodawcy; jego wynik powinien pokazać, czy organizacja umie ograniczyć dostęp, odtworzyć usługę i skoordynować komunikację. Test niedostępności dostawcy powinien uwzględniać także zależności, które mogłyby zablokować rozwiązanie awaryjne.

Wyniki przeglądu powinny trafić do udokumentowanej oceny ryzyka i planu naprawczego z priorytetami, właścicielami działań, terminami oraz sposobem potwierdzenia usunięcia nieprawidłowości. Istotne ustalenia mają zostać przedstawione organowi zarządzającemu. Dla podmiotów objętych DORA korzystanie z zewnętrznego SaaS pozostaje częścią własnej odpowiedzialności za ryzyko ICT; o realnej kontroli zdecyduje więc także zdolność instytucji do samodzielnego ograniczenia skutków incydentu.

Przeczytaj także:

• Dzień bez spotkań nie wystarczy: asynchroniczna praca potrzebuje zasad
• Barter też jest reklamą — samo „współpraca” nie wystarczy
• Signal czy WhatsApp? Szyfrowanie jest wspólne, metadane już nie