Jak przeprowadzić audyt stacku SaaS

dlaczego audyt saas jest potrzebny

SaaS sprawl to naturalny efekt wzrostu. Każda funkcja w rosnącej organizacji rozwiązuje swoje problemy, wdrażając potrzebne jej narzędzia, a suma cicho narasta z czasem. Wiele z tych narzędzi zostało wdrożonych szybko, bez formalnego procesu IT, bo proces był albo za wolny, albo w ogóle wtedy nie istniał. Decyzje zakupowe są dziś rozproszone: szefowie działów i pojedynczy pracownicy wybierają narzędzia bez etapu zatwierdzenia przez IT, bo praca tego wymaga, a czekanie wydaje się zbędnym obciążeniem.

Efekt to środowisko, którego nikt nie zaprojektował. Aplikacje przetwarzają dane klientów bez podpisanych umów z dostawcą. Narzędzia poza dostawcą tożsamości umykają offboardingowi. Granty OAuth utrzymują się po aplikacjach, które już nie istnieją jako niezależne firmy. Byli pracownicy zachowują aktywne konta na platformach, o których IT nigdy nie wiedziało. Problem ma charakter strukturalny, nie wynika z braku dyscypliny. Potrzebny jest proces, który pozwoli zobaczyć i objąć zarządzaniem to, co faktycznie tam jest, a audyt SaaS jest właśnie takim procesem.

krok 1: zbuduj inwentarz

Pierwsze zadanie to zbudowanie listy każdej aktywnie używanej aplikacji. Żadne pojedyncze źródło nie da ci tej listy, więc zbierasz dane z kilku i je uzgadniasz.

Konsola administracyjna dostawcy tożsamości (IdP) daje listę aplikacji zarejestrowanych do SSO w Google Workspace, Microsoft Entra albo Okta. To twój zarządzany obwód: kompletny dla aplikacji, które przeszły przez IdP, i ślepy na wszystko inne. Granty OAuth z IdP ujawniają aplikacje, które pracownicy podłączyli do twojego środowiska, niezależnie od tego, czy są formalnie zarejestrowane do SSO; lista grantów często zawiera dużo więcej aplikacji niż lista SSO. Dane finansowe i wydatkowe, w formie raportu cyklicznych opłat SaaS obejmującego wyciągi z kart działowych, ujawniają każdą subskrypcję spoza IdP. Dane z zarządzania endpointami z MDM lub narzędzia endpointowego ujawniają aplikacje desktopowe i rozszerzenia przeglądarki niewidoczne przez IdP. Ankiety wśród liderów działów, krótkie i bezpośrednie pytanie o narzędzia, których zespół używa codziennie, płaci za nie kartą działową albo podłączył do konta Google lub Microsoft, regularnie ujawniają aplikacje, które nie pojawiają się w żadnym z systemowych źródeł. Uzgodnij wszystkie pięć źródeł w jedną listę, oznacz każdą aplikację źródłem pochodzenia i traktuj luki między źródłami jako miejsce, gdzie koncentruje się ryzyko.

krok 2: zidentyfikuj shadow saas

Shadow SaaS to aplikacje w twoim środowisku, które nigdy nie przeszły procesu przeglądu IT. Niekoniecznie są zakazane, po prostu są nieznane. Zestaw uzgodniony inwentarz z dostępnymi zapisami zatwierdzeń albo zgłoszeń. Aplikacje, które pojawiają się w danych wydatkowych, grantach OAuth albo ankietach działowych, ale nie w zapisach IT, to kandydaci na shadow SaaS.

Dla każdej nierozpoznanej aplikacji odpowiedz na trzy pytania: jakie dane przetwarza, czy dostawca ma dostępną umowę powierzenia (DPA), i czy dostawca przechowuje dane w lokalizacji zgodnej z twoimi wymogami RODO i rezydencji danych. Odpowiedzi określają poziom ryzyka. Aplikacja używana przez jednego pracownika do zarządzania własnymi zadaniami niesie inne ryzyko niż aplikacja, w której zespół sprzedaży przechowuje dane kontaktowe leadów i klientów.

krok 3: przejrzyj granty i scope'y OAuth

Granty OAuth to najczęstsze źródło dostępu, którego nikt nie pilnuje. Gdy pracownik podłącza narzędzie zewnętrzne do Google Workspace albo Microsoft 365, to narzędzie dostaje grant określający, do czego ma dostęp: poczty, kalendarza, plików, kontaktów albo jakiejś kombinacji. Grant nie wygasa, gdy pracownik przestaje korzystać z narzędzia albo odchodzi z firmy. Trwa, dopóki ktoś go wyraźnie nie cofnie.

Pobierz z IdP każdy aktywny grant, zapisując nazwę aplikacji, przyznany scope, użytkownika, który go autoryzował, i to, czy konto tego użytkownika jest obecnie aktywne. Trzy kategorie wymagają natychmiastowej uwagi. Granty na nieaktywnych kontach nadal mogą nieść żywy dostęp, jeśli aplikacja ponownie uwierzytelnia się tokenem odświeżającym, i powinny zostać cofnięte natychmiast. Granty o szerokim scope, w tym pełny dostęp do odczytu skrzynki albo pełny dostęp do plików, wymagają zweryfikowania względem faktycznej funkcji aplikacji; narzędzie do powiadomień nie ma żadnego powodu czytać całej skrzynki, więc cofnij grant i autoryzuj ponownie na węższym scope tam, gdzie dostawca to wspiera. Granty z nierozpoznanych aplikacji to znaleziska shadow SaaS do dodania do inwentarza.

krok 4: sprawdź pokrycie sso i scim

Single Sign-On (SSO) kieruje uwierzytelnianie aplikacji przez twojego centralnego dostawcę tożsamości. Aplikacje wewnątrz SSO są zarządzane centralnie: zamknij jedno konto w katalogu, a razem z nim zamyka się dostęp do wszystkich aplikacji podłączonych do SSO. Aplikacje poza SSO uwierzytelniają się niezależnie i są niewidoczne dla twojego procesu joiner-mover-leaver.

Na podstawie uzgodnionego inwentarza określ, które aplikacje są wewnątrz SSO i skonfigurowane (pod centralną kontrolą), które obsługują SSO, ale nie są skonfigurowane (luka warta zamknięcia, jeśli aplikacja przetwarza dane wrażliwe, a SSO jest dostępne, często w wyższym planie cenowym), a które są poza SSO bez opcji SSO (wymagają ręcznego zarządzania dostępem, jawnego śledzenia i uwzględnienia z nazwy w checklistach offboardingowych oraz w każdym przeglądzie dostępów). Provisioning SCIM to kolejny poziom: automatyczne tworzenie, aktualizacja i dezaktywacja kont przez API provisioningu IdP. Aplikacje z aktywnym SCIM obsługują zmiany ról i offboarding automatycznie, bez ręcznego kroku w samej aplikacji, i SCIM warto priorytetyzować dla aplikacji przetwarzających dane pracowników, klientów albo dane finansowe.

krok 5: znajdź konta byłych pracowników

Offboarding przez katalog zamyka dostęp podłączony do SSO. Nie zamyka kont w aplikacjach, które uwierzytelniają się niezależnie. 83% pracowników przyznaje, że nadal ma dostęp do co najmniej jednego konta u poprzedniego pracodawcy (Beyond Identity, 2022, dane self-reported). Mechanizm jest prosty: narzędzia wdrożone poza SSO trzymają własne rejestry użytkowników, nienaruszone, gdy konto w katalogu się zamyka.

Pobierz listę pracowników, którzy odeszli w ciągu ostatnich 12 do 24 miesięcy. Dla każdej aplikacji działającej poza SSO albo bez provisioningu SCIM zestaw jej listę użytkowników z listą osób odchodzących; każde dopasowanie to aktywne konto, które powinno było zostać zamknięte przy offboardingu. Dla aplikacji podłączonych przez OAuth sprawdź granty autoryzowane przez konta byłych pracowników, bo aktywny grant może nadal nieść ważny dostęp, nawet gdy konto w katalogu jest już zamknięte. 36% naruszeń z wykorzystaniem skradzionych danych uwierzytelniających (Verizon DBIR) często prowadzi do kont, które nie zostały w pełni zamknięte, a konta byłych pracowników w SaaS to jedna z najczęstszych dróg.

krok 6: przejrzyj integracje między aplikacjami

Poza grantami OAuth użytkowników istnieje druga warstwa dostępu, którą większość audytów pomija: integracje między aplikacjami działające bez udziału człowieka. Narzędzie do automatyzacji marketingu synchronizujące się z CRM, platforma HR wysyłająca dane do systemu płacowego, helpdesk zintegrowany z narzędziem komunikacyjnym. Każda integracja trzyma klucz API albo token serwisowy, który daje dostęp do danych, a gdy integracja przestaje być potrzebna, token rzadko jest cofany, bo nikt nie pamięta, że w ogóle powstał.

Sprawdź konsole administracyjne swoich najbardziej ryzykownych aplikacji, zwłaszcza tych, które przechowują dane klientów, dane finansowe albo dane pracowników. Większość ma sekcję z listą aktywnych połączeń API albo zainstalowanych integracji. Dla każdej integracji potwierdź, czy jest wciąż aktywnie używana, do jakiej aplikacji daje dostęp token i jaki scope obejmuje ten dostęp. Dezaktywuj tokeny z integracji, które nie są już używane. Klucze API domyślnie nie mają terminu ważności; integracja skonfigurowana podczas projektu sprzed dwóch lat może nadal mieć aktywny dostęp zapisu do twojego CRM.

krok 7: przejrzyj wydatki i zduplikowane narzędzia

Wydatki na SaaS i zarządzanie dostępem pokrywają się bardziej, niż większość organizacji zdaje sobie sprawę. Narzędzia kupione poza standardowym procesem zakupowym to narzędzia, których bezpieczeństwo nigdy nie zostało ocenione, a zduplikowane narzędzia do tej samej funkcji oznaczają, że te same dane istnieją w wielu środowiskach dostawców o różnym poziomie zabezpieczeń.

Na podstawie danych finansowych zidentyfikuj nieużywane albo niedowykorzystane licencje (liczba aktywnych użytkowników wyraźnie niższa niż liczba wykupionych miejsc, co oznacza zarówno marnotrawstwo, jak i uśpione konta warte zamknięcia), zduplikowane narzędzia (funkcje realizowane przez więcej niż jedną aplikację, często wdrażane przez osobne zespoły; typowe przykłady to kilka narzędzi do zarządzania projektami albo do podpisywania dokumentów, gdzie konsolidacja obniża zarówno koszt, jak i powierzchnię ryzyka) oraz narzędzia kupione poza procesem zakupowym (subskrypcje widoczne wyłącznie na wyciągach z kart działowych, bez żadnego przeglądu dostawcy w dokumentacji, traktowane jako shadow SaaS niezależnie od tego, jak zostały opłacone).

krok 8: zbuduj rejestr dostawców, umów powierzenia i rezydencji danych

Wynik kroków inwentaryzacji i przeglądu zasila utrzymywany rejestr aplikacji, fundament wszystkiego, co dalej: od niego zależą przeglądy dostępów, checklisty offboardingowe, oceny dostawców i dokumentacja compliance. Dla każdej aplikacji minimalny wpis w rejestrze obejmuje nazwę aplikacji i dostawcę, wewnętrznego właściciela albo odpowiedzialny zespół, główną funkcję i typy przetwarzanych danych, czy umowa powierzenia jest podpisana i w dokumentacji, lokalizację przechowywania danych (UE, spoza UE albo konkretny kraj), certyfikaty bezpieczeństwa, jakie ma dostawca (ISO 27001, SOC 2), oraz czy aplikacja jest wewnątrz SSO i czy ma aktywny SCIM.

Rezydencja danych ma znaczenie dla zgodności z RODO i coraz częściej dla wymogów klientów enterprise. Aplikacje przechowujące dane osobowe z UE na serwerach spoza UE wymagają albo standardowych klauzul umownych, albo decyzji o adekwatności, a bez rejestru nie jesteś w stanie odpowiedzieć na to pytanie.

jak priorytetyzować znaleziska

Pierwszy audyt produkuje listę dłuższą, niż zespół jest w stanie ogarnąć od razu, więc priorytetyzacja utrzymuje pracę w ruchu. P0, zajmij się natychmiast: aktywne konta należące do byłych pracowników w dowolnej aplikacji, granty OAuth na nieaktywnych albo zamkniętych kontach, aplikacje przetwarzające dane osobowe bez umowy powierzenia i granty OAuth o szerokim scope z nierozpoznanych aplikacji. P1, zajmij się w tym kwartale: aplikacje poza SSO, które przetwarzają dane wrażliwe i mają dostępne SSO, granty OAuth o szerokim scope z rozpoznanych, ale niskopriorytetowych narzędzi, tokeny integracji między aplikacjami z integracji, które nie są już używane, oraz aplikacje bez przypisanego wewnętrznego właściciela. P2, zaplanuj na kolejny cykl: aplikacje bez provisioningu SCIM, które wspierają go w obecnym planie, porządkowanie nieużywanych licencji, konsolidację zduplikowanych narzędzi i uzupełnienie brakujących pól drugorzędnych w rejestrze.

mapowanie na rodo, nis2 i dora

Audyt SaaS to przede wszystkim projekt widoczności, a widoczność, którą daje, wprost pokrywa się z tym, co kilka regulacji wymaga od ciebie wykazać. Artykuł 28 RODO wymaga umowy powierzenia z każdym podmiotem przetwarzającym dane osobowe w twoim imieniu, a artykuł 30 wymaga prowadzenia rejestru czynności przetwarzania obejmującego przepływy danych do podmiotów przetwarzających; rejestr aplikacji z udokumentowanym statusem umowy powierzenia i typami danych spełnia oba wymogi. Artykuł 32 RODO wymaga odpowiednich środków technicznych i organizacyjnych, wobec których niecofnięte granty OAuth, konta byłych pracowników i aplikacje bez przeglądu dostępów to luki, które wykrywa audyt. NIS2 wymaga od organizacji objętych regulacją zarządzania bezpieczeństwem łańcucha dostaw, w tym usług stron trzecich; dostawcy SaaS to łańcuch dostaw, więc oceny dostawców, umowy powierzenia i sprawdzanie certyfikatów są częścią obronnej postawy. DORA wymaga od objętych regulacją instytucji finansowych identyfikowania i zarządzania zależnościami od zewnętrznych dostawców ICT, dla którego rejestr aplikacji SaaS z polami dostawcy, typu danych i krytyczności jest fundamentem. Żaden z tych standardów nie wymaga konkretnego narzędzia; wymagają wykazywalnej kontroli i udokumentowanych procesów, które daje dobrze przeprowadzony audyt.

typowe błędy

Traktowanie listy z IdP jako pełnego inwentarza pokazuje to, co zarejestrowało IT, a nie to, czego faktycznie używają pracownicy. Zatrzymanie się na inwentarzu bez przeglądu dostępów zostawia bez odpowiedzi pytania, kto ma dostęp, czy ta osoba nadal pracuje w firmie i jakie dane przetwarza aplikacja. Audytowanie grantów OAuth bez sprawdzenia statusu konta pomija fakt, że grant przypisany do konta byłego pracownika to P0, podczas gdy ten sam grant od aktywnego pracownika już nie. Zbudowanie rejestru raz i nigdy jego nieaktualizowanie daje dokument historyczny, który dezaktualizuje się już po kilku tygodniach. Traktowanie shadow SaaS jako problemu dyscypliny źle definiuje cel, którym jest widoczność, a nie egzekwowanie, skoro pracownicy wdrażają narzędzia właśnie dlatego, że są zaradni. A pominięcie finansów pomija narzędzia, które zespoły finansowe wykryły, a liderzy działów wdrożyli poza jakimkolwiek procesem IT; krok uzgodnienia z finansami nie jest opcjonalny.

jak utrzymać to na bieżąco

Pełny audyt raz w roku to rozsądny punkt wyjścia, ale bardziej liczą się procesy ciągłe: kwartalny przegląd grantów OAuth, wymóg wpisu do rejestru dla każdego nowego narzędzia i uwzględnianie wszystkich aplikacji spoza SSO w checklistach offboardingowych. Celem jest utrzymywany inwentarz, a nie okresowe migawki. Bez procesu wymagającego wpisu do rejestru dla każdego nowego narzędzia inwentarz traci aktualność w ciągu kilku tygodni.