Twój zespół używa dziesiątek aplikacji SaaS, których nie kontrolujesz
Bezpieczeństwo SaaS to zarządzanie ryzykiem wynikającym z aplikacji, integracji i uprawnień, które narastają szybciej niż jakikolwiek ręczny proces jest w stanie za nimi nadążyć.
W firmach zatrudniających nawet kilkudziesięciu pracowników to jeden z najbardziej niedocenionych obszarów ekspozycji
Średni czas wykrycia nieautoryzowanego dostępu to 197 dni. (IBM)
pracowników wykorzystuje narzędzia AI w pracy niezależnie od zgody pracodawcy
Microsoft
wyższe jest faktyczne wykorzystanie AI w firmach względem deklarowanego
Eurostat
osób używających AI w pracy robi to bez wiedzy pracodawcy
Microsoft
Co obejmuje obszar bezpieczeństwa SaaS?
SaaS security (SSPM, SaaS Security Posture Management), to domena zajmująca się ryzykiem wynikającym z używania aplikacji w modelu Software-as-a-Service.
Nie chodzi o to, czy dane aplikacje są bezpieczne same w sobie, ale o to, jak są używane, przez kogo, z jakimi uprawnieniami i z jakimi innymi systemami są połączone.
W praktyce SaaS security obejmuje kilka warstw
inwentaryzację tego, co w ogóle jest używane w organizacji,
(wliczając aplikacje, o których IT nie wie)
zarządzanie dostępami w tych aplikacjach,
(kto ma jakie uprawnienia i czy powinien)
kontrolę nad integracjami między aplikacjami,
(co ma dostęp do czego przez OAuth lub API)
higienę kont.
(czy konta byłych pracowników zostały zamknięte we wszystkich narzędziach, nie tylko w katalogu głównym)
SaaS security nie jest równoznaczne z zakazem używania aplikacji, leczo opiera się na zarządzaniu widocznością i ryzykiem w środowisku, które te aplikacje zawiera.
SaaS sprawl jest naturalnym efektem rozwoju organizacji
Każda firma, która rośnie, kupuje SaaS-y w podobnym rytmie.
Marketing wdraża narzędzie do automatyzacji. Sprzedaż podłącza CRM i kilka narzędzi do prospectingu. Developerzy używają narzędzi do zarządzania kodem i deploymentu. HR wprowadza system do rekrutacji i onboardingu. Finanse obsługują fakturowanie przez dedykowany SaaS.
Na poziomie 100 pracowników i kilkudziesięciu narzędzi używanych przez kilka działów z różnymi potrzebami, obraz wdrożonych aplikacji SaaS przestaje być czytelny. Na poziomie 500 osób, po kilku rundach zatrudniania, kilku zmianach strategii i kilku przejęciach, jest praktycznie niemożliwy do odtworzenia bez narzędzia.
Decyzje o wdrożeniu aplikacji są rozproszone
Menedżerowie działów podejmują decyzje o narzędziach samodzielnie, często bez formalnego procesu akceptacji IT. To racjonalne z perspektywy efektywności: czekanie na zatwierdzenie IT spowalnia pracę. Ale każda taka decyzja tworzy punkt ekspozycji, którego IT nie widzi.
Każda aplikacja ma własny model uprawnień
Nie istnieje jedno miejsce, w którym widać kto ma dostęp do wszystkich narzędzi. Każda aplikacja ma swój panel administracyjny, swoje role, swoje listy użytkowników. Bez centralizacji (SSO + SCIM) zarządzanie jest z definicji ręczne i zawodne.
Offboarding nie dosięga wszystkich aplikacji
Konto byłego pracownika można zamknąć w Microsoft 365. Konto w narzędziu do analityki, które ten pracownik zainstalował rok temu i o którym IT nie wiedziało, zostaje. Tak samo konto w platformie do zarządzania projektami, narzędziu do wideokonferencji, CRM-ie działowym i pięciu innych appkach, do których miał dostęp.
Integracje między SaaS-ami to ukryta sieć dostępów
OAuth grants, webhooki, klucze API: każda integracja to ścieżka dostępu, która działa poza świadomością IT. Appka do zarządzania dokumentami ma dostęp do kalendarzy. Narzędzie do marketingu ma dostęp do listy kontaktów. Platforma HR ma dostęp do poczty menedżerów. Nikt tych połączeń nie przegląda, bo nie ma widoku, który by je pokazał.
Ryzyka w obszarze bezpieczeństwa SaaS
Ryzyka, która pojawia się regularnie w rosnących organizacjach. Bez narzędzia do inwentaryzacji pełny obraz jest niewidoczny
Shadow SaaS
Shadow SaaS to aplikacje używane przez pracowników lub zespoły, które nie przeszły przez żaden proces akceptacji IT. Nie są to aplikacje zakazane. Są po prostu nieznane. Pracownicy sięgają po nie, bo są wygodne, bo polecił je kolega z poprzedniej firmy, bo rozwiązują konkretny problem szybciej niż korporacyjne narzędzie zatwierdzone pół roku temu.
Badania pokazują, że liczba aplikacji używanych poza wiedzą IT jest wielokrotnie wyższa niż IT szacuje. W firmach 200+ różnica między tym, co IT widzi, a tym, co faktycznie jest używane, sięga setek aplikacji.
Ryzyko nie leży w samych aplikacjach. Leży w tym, że bez wiedzy o ich istnieniu nie można weryfikować, jakie dane do nich trafiają, jakie mają uprawnienia i czy są obsługiwane przez dostawcę zgodnie z wymaganiami bezpieczeństwa.
Aplikacje poza SSO
Single Sign-On (SSO) to mechanizm, który pozwala użytkownikom logować się do wszystkich aplikacji firmowych przez jeden centralny dostawca tożsamości (Microsoft Entra ID, Google Workspace, Okta). Aplikacje objęte SSO są widoczne w katalogu: można zarządzać dostępem, egzekwować MFA, i wyłączyć dostęp do wszystkich poprzez zamknięcie jednego konta.
Aplikacje poza SSO działają niezależnie. Mają własne loginy i hasła. Offboarding nie zamknie kont w tych aplikacjach. IT nie widzi, kto się do nich loguje ani czy konta byłych pracowników wciąż są aktywne.
W średnich firmach typowo duża część aplikacji SaaS nie jest objęta SSO, szczególnie narzędzia działowe wdrożone bez udziału IT i aplikacje, których plan cenowy nie obejmuje integracji SSO bez dopłaty.
Niekontrolowane wydatki na SaaS
Rozrost aplikacji SaaS ma wymiar finansowy. Subskrypcje opłacane kartami działowymi, licencje wykupione na poziomie indywidualnym, narzędzia z planami freemium, które nagle przekształciły się w płatne, zduplikowane funkcjonalności kupowane przez różne działy.
Szacunkowo 25–40% wydatków na SaaS w firmach tej wielkości to koszty, które można by ograniczyć: nieużywane licencje, nakładające się narzędzia, plany niedopasowane do rzeczywistego użycia.
Nieśledzony koszt SaaS to jednak nie tylko problem finansowy. Narzędzia kupowane poza standardowym procesem zakupowym to narzędzia, których bezpieczeństwo nie było weryfikowane i które nie przeszły przez żadną ocenę ryzyka
Brak weryfikacji uprawnień
Każda aplikacja SaaS, która dostaje OAuth grant lub klucz API, prosi o określony zakres uprawnień (scope). Narzędzie do podpisywania dokumentów prosi o dostęp do plików. Narzędzie do zarządzania mediami społecznościowymi prosi o dostęp do profilu. Narzędzie do analizy e-maili prosi o dostęp do całej skrzynki.
Zakres tych uprawnień rzadko jest weryfikowany w momencie przyznania. Jeszcze rzadziej jest weryfikowany cyklicznie. Aplikacja może mieć szerszy dostęp niż faktycznie potrzebuje do realizacji zadań, a nikt w organizacji o tym nie wie.
Brak SCIM Provisioning
SCIM (System for Cross-domain Identity Management) to protokół, który pozwala automatycznie tworzyć, aktualizować i usuwać konta w aplikacjach SaaS na podstawie zmian w katalogu tożsamości. Gdy nowy pracownik pojawia się w Active Directory lub Google Workspace, SCIM może automatycznie założyć mu konta w dziesiątkach podłączonych aplikacji. Gdy pracownik odchodzi, te konta są automatycznie dezaktywowane.
Aplikacje bez SCIM wymagają ręcznego zarządzania. W środowiskach z dziesiątkami aplikacji i regularną rotacją pracowników, ręczne zarządzanie prowadzi do pominięć. Pominięcia prowadzą do kont, o których nikt nie wie.
Niebezpieczne rozszerzenia przeglądarki
Rozszerzenia przeglądarki to aplikacje, które działają bezpośrednio w środowisku pracy pracownika i mają dostęp do treści stron, które przegląda. Rozszerzenie do sprawdzania pisowni czyta każdy tekst, który pracownik wpisuje. Rozszerzenie do zarządzania hasłami ma dostęp do formularzy. Rozszerzenie do produktywności może mieć dostęp do otwartych kart i historii przeglądania.
Rozszerzenia przeglądarki są poza zasięgiem standardowych narzędzi do zarządzania SaaS. Nie są aplikacjami z własnym panelem administracyjnym. Ich wpływ na bezpieczeństwo danych jest realny, ale inwentaryzacja wymaga osobnego narzędzia lub polityki zarządzania urządzeniami.
Niekontrolowane OAuth Grants
OAuth to protokół, który pozwala jednej aplikacji uzyskać dostęp do zasobów innej w imieniu użytkownika. W praktyce: gdy pracownik podłącza nowe narzędzie do Google Workspace lub Microsoft 365, aplikacja ta dostaje grant OAuth, który może dawać jej dostęp do poczty, kalendarza, plików lub kontaktów.
Problem z OAuth grantami polega na tym, że są trwałe. Użytkownik kliknął "Zezwól" raz. Appka ma dostęp dopóki ktoś go ręcznie nie cofnie. Nikt go nie cofa, bo nikt nie wie, że istnieje. Nikt nie wie, że istnieje, bo nie ma widoku, który by te granty pokazywał.
W typowym środowisku średniej firmy istnieje kilkaset aktywnych grantów OAuth. Część z nich pochodzi od aplikacji, które już nie są używane. Część od aplikacji bez właściciela. Część od aplikacji, których dostawca przestał świadczyć usługę. Wszystkie wciąż mają aktywny dostęp do danych.
Brak widoczności użycia narzędzi AI
Firma bez widoczności użycia AI nie może zarządzać tym ryzykiem. Nie wie, ile osób używa zewnętrznych modeli AI. Nie wie, przez jakie narzędzia. Nie wie, jakie dane do nich trafiają. Nie ma możliwości wykrycia, gdy pracownik postępuje niezgodnie z polityką, bo polityka nie ma żadnego przełożenia technicznego.
Widoczność użycia AI jest warunkiem koniecznym każdego pozostałego elementu governance. Bez niej polityka jest dokumentem, który nie ma żadnego rzeczywistego efektu.
Integracje między aplikacjami
Oprócz OAuth grantów użytkowników istnieje jeszcze jedna warstwa: integracje między aplikacjami, które działają bez udziału człowieka. Narzędzie do automatyzacji marketingu synchronizuje się z CRM-em. Platforma HR wysyła dane do systemu płacowego. Helpdesk integruje się z komunikatorem. Każda z tych integracji ma własny klucz API lub token, który daje jej dostęp do danych.
Integracje SaaS-to-SaaS są niewidoczne na poziomie katalogu tożsamości, bo nie są powiązane z konkretnym kontem użytkownika. Istnieją w warstwie technicznej, między systemami. Gdy integracja przestaje być potrzebna, token rzadko jest cofany, bo nikt nie pamięta, że został wygenerowany.
Brak rejestru aplikacji
Firma, która nie ma pełnej listy swoich aplikacji SaaS, nie jest w stanie odpowiedzieć na kilka podstawowych pytań bezpieczeństwa: które narzędzia przetwarzają dane osobowe pracowników lub klientów? Które mają podpisane DPA (Data Processing Agreement)? Które przechowują dane w UE? Które mają certyfikaty bezpieczeństwa, a które nie?
Bez inwentaryzacji dostawców odpowiedź na te pytania jest szacunkowa w najlepszym razie. W przypadku audytu RODO, incydentu lub pytania od dużego klienta, "szacunkowa" nie wystarczy
Dostępy byłych pracowników
To punkt przecięcia z obszarem IAM, ale w kontekście SaaS ma własną specyfikę. Offboarding zamyka konto w katalogu tożsamości. Nie zamyka kont w aplikacjach, które nie są objęte SSO lub SCIM. Były pracownik może nadal logować się do narzędzia projektowego, platformy komunikacyjnej lub CRM-u, używając własnych poświadczeń, przez tygodnie lub miesiące po odejściu.
Ryzyko jest wyższe przy pracownikach, którzy odchodzą w złych warunkach lub przechodzą do konkurencji. Ale nawet przy standardowych odejściach niezamknięte konta w aplikacjach SaaS to otwarte drzwi, które najczęściej pozostają niezauważone
Porzucone triale
Każda firma testuje więcej aplikacji niż ostatecznie wdraża. Konta próbne są zakładane przez konkretną osobę, często z służbowym adresem e-mail. Jeśli aplikacja nie zostaje wdrożona, konto próbne zazwyczaj nie jest usuwane. Zostaje z aktywnymi poświadczeniami, z dostępem do danych, które zostały załadowane podczas testu, i bez właściciela, który by je monitorował.
Zduplikowane narzędzia
Różne działy tej samej firmy regularnie używają narzędzi realizujących tę samą funkcję, nie wiedząc o sobie nawzajem. Marketing ma narzędzie do wideokonferencji, sprzedaż ma inne. HR używa innej platformy do onboardingu niż IT. Finanse mają własne narzędzie do podpisywania dokumentów, a prawny innego vendora.
Nakładające się narzędzia to koszt, ale też ryzyko: te same dane (klientów, pracowników, dokumenty) istnieją w dwóch lub trzech systemach różnych dostawców, z różnymi politykami bezpieczeństwa i poziomem kontroli.
Jak utrzymać SaaS-y pod faktyczną kontrolą?
Kontrola nad środowiskiem SaaS nie oznacza zakazu używania nowych aplikacji. Oznacza widoczność i procesy, które pozwalają ocenić ryzyko i zarządzać nim świadomie.
Aktualny rejestr aplikacji
Organizacja wie, które aplikacje SaaS są używane, przez kogo, z jakimi danymi i przez jakiego dostawcę. Lista jest utrzymywana, nie jest zdjęciem ze sprzed roku.
OAuth grants są przeglądane cyklicznie
Co miesiąc, kwartał lub co pół roku ktoś weryfikuje, które granty OAuth są aktywne, czy aplikacje, którym zostały przyznane, wciąż są używane i czy zakres uprawnień jest adekwatny do funkcji narzędzia.
Kluczowe aplikacje są objęte SSO
Dostęp do aplikacji przetwarzających wrażliwe dane lub dane klientów jest centralizowany przez dostawcę tożsamości. Offboarding jednego konta wyłącza dostęp do wszystkich aplikacji.
SCIM jest wdrożony w aplikacjach o wyższym ryzyku
Konta w aplikacjach przetwarzających dane pracowników, klientów lub dane finansowe są zarządzane automatycznie: tworzone przy onboardingu, aktualizowane przy zmianie roli, dezaktywowane przy offboardingu.
Nowe aplikacje przechodzą przez proces oceny
Nie każda aplikacja wymaga pełnego security review. Ale przed podłączeniem nowego narzędzia do firmowych danych powinna istnieć odpowiedź na podstawowe pytania: gdzie są przechowywane dane, czy mamy DPA, czy dostawca ma certyfikaty bezpieczeństwa.
Wydatki SaaS są widoczne w jednym miejscu
Subskrypcje są śledzone całościowo, a nie przez osobne zespoły. Nieużywane licencje są identyfikowane i wygaszane.
Kiedy trzeba zabezpieczyć środowisko SaaS-ów?
Firmy rzadko podejmują temat zarządzania tożsamością bez powodu. Zazwyczaj jest coś, co sprawia, że pytanie "kto ma dostęp do czego" staje się pilne.
Pewne sytuacje powtarzają się jednak regularnie
Odejście kluczowej osoby z IT
Gdy osoba, która "wiedziała wszystko o systemach", odchodzi, organizacja nagle zdaje sobie sprawę, że ta wiedza nie była nigdzie zapisana. Offboarding tej osoby staje się pierwszym testem tego, jak dobrze działa zarządzanie dostępami.
Audyt bezpieczeństwa lub due diligence
SOC 2, ISO 27001, audyt zewnętrzny, due diligence przed inwestycją lub przejęciem. Każdy z tych procesów wymaga wykazania, że dostępy są pod kontrolą i weryfikowane. To jeden z najczęstszych punktów niezgodności w audytach, stąd staje się to priorytetem.
Incydent lub niemal-incydent
Odkrycie, że konto byłego pracownika wciąż jest aktywne. Wyciek hasła i niemożność szybkiej oceny zakresu dostępu. Ktoś z zewnątrz prosi o hasło "bo musi coś sprawdzić".
Wzrost firmy pokazuje nieporadność ręcznego zarządzania
Przekroczenie pewnego progu liczby pracowników, wdrożenie nowego systemu ERP, przejście na pracę zdalną. Każda z tych zmian ujawnia, że ręczne zarządzanie dostępami nie skaluje się.
Wymagania klientów lub kontrahentów
Klienci, szczególnie korporacje i firmy podlegające regulacjom, coraz częściej wymagają wykazania kontroli nad dostępami jako warunku współpracy. Pytania o polityki bezpieczeństwa i access management stają się częścią procesu vendor assessment.
Wdrożenie regulacji
NIS2, DORA i wymagania sektorowe dla firm finansowych lub ochrony zdrowia. Każde z nich wymaga możliwości wykazania pełnej kontroli nad dostępami do systemów krytycznych i przetwarzanych danych.
Narzędzia, z którymi pracujemy w tym obszarze
Wybór narzędzia do zarządzania tożsamością zależy od skali, architektury i dojrzałości procesów w organizacji. Nie ma jednego właściwego. Są narzędzia adekwatne do konkretnego etapu.
Dlaczego tożsamość staje się problemem dopiero przy pewnej skali?
Mniejsze firmy zwykle radzą sobie z dostępami intuicyjnie. IT zna każdego i wie, kto czego używa, offboarding robi jedna osoba w ciągu godziny, a lista aplikacji mieści się w głowie.
W firmach 100+ to przestaje działać, gdyż skala zmienia mechanikę problemu. Zespoły pracują między sobą, rotacja jest większa, przestajesz kojarzyć nowych pracowników, a część z nich pracuje tylko zdalnie.
To jest moment, w którym firmy zaczynają rozmawiać o IAM nie jako o projekcie bezpieczeństwa, ale jako o podstawowej higienie operacyjnej.
Liczba systemów rośnie nieliniowo
Firma 50-osobowa używa szacunkowo kilkudziesięciu aplikacji. Firma 200-osobowa, szczególnie jeśli ma kilka działów z różnymi potrzebami, używa wielokrotnie więcej. Każda aplikacja to osobny model dostępu, osobna lista użytkowników, osobne uprawnienia do zarządzania
Rotacja rośnie
Im więcej ludzi, tym więcej zmian: awanse, zmiany działów, odejścia, kontrahenci na czas określony. Każda zmiana powinna pociągać za sobą aktualizację uprawnień. W praktyce to często nie następuje, bo nikt nie ma czasu, bo procedura nie jest jednoznaczna, albo system, w którym trzeba coś zmienić, nie jest podłączony do centralnego katalogu.
Odpowiedzialność jest rozmyta
W małej firmie offboarding robi konkretna osoba. W firmie 100+ HR zamyka konto w systemie kadrowym, IT zamyka konto w Active Directory, a za aplikacje SaaS, repozytoria na GitHubie i konto w narzędziu do analityki odpowiada każdy i nikt.
Historyczne decyzje kumulują się
Każde konto, które nie zostało zamknięte w odpowiednim momencie, każde uprawnienie nadane "tymczasowo" i każdy token wygenerowany do projektu, który się skończył, zostaje w systemie. Po trzech latach takich decyzji masz środowisko, którego nie da się zrozumieć bez narzędzia, które je zmapuje.
Jak możemy pomóc
Jeśli tematyka tej strony jest bliska temu, co widzisz w swoim środowisku, to są dwa miejsca, od których warto zacząć.
Audyt tożsamości i dostępów →
14-dniowy audyt kończący się pełnym raportem. Mapujemy każde konto, każdy OAuth grant i każde uprawnienie w trybie read-only. Bez zmian w środowisku. Po audycie wiesz dokładnie, co masz i co wymaga uwagi.
Dobór i wdrożenie IAM →
Doradztwo w doborze narzędzia, projekt architektury i pełne wdrożenie. Od JML przez SSO i MFA po access reviews i IGA dla firm z bardziej zaawansowanymi wymaganiami governance oraz compliance.
Jeśli chcesz lepiej poznać ten obszar
You don't need to overhaul everything. Start with what you can see. Build from there
Zero Trust: A Modern Framework for Digital-First Companies
