Enterprise w nazwie, chaos w architekturze.

Enterprise w nazwie, chaos w architekturze. Dlaczego SaaS wciąż nie rozumie bezpieczeństwa przedsiębiorstw?

Jest coś, co niezmiennie mnie zadziwia w branży IT.

Od lat uczymy się, jak projektować bezpieczne aplikacje. Rozmawiamy o RBAC, zasadzie najmniejszych uprawnień, separacji obowiązków, kontach serwisowych, audytowalności, centralnym zarządzaniu, zgodności regulacyjnej i odpowiedzialności administratorów. Tworzymy architektury, modele bezpieczeństwa, standardy i dobre praktyki.

A potem dostajemy do ręki kolejną aplikację SaaS, która nie realizuje połowy tych założeń.

Co więcej, często jest to produkt dużego, rozpoznawalnego dostawcy. Produkt z planem licencyjnym nazwanym Enterprise. Produkt reklamowany jako gotowy dla organizacji, które mają tysiące użytkowników, rygorystyczne wymagania bezpieczeństwa i rozbudowane procesy zarządzania.

Tylko że po wejściu głębiej okazuje się, że Enterprise kończy się tam, gdzie zaczyna się prawdziwe enterprise management.

I nie mówię o niszowych funkcjach, zaawansowanej analityce czy integracjach, bez których można się obejść.

Mówię o fundamentach.

1. Konta serwisowe? Nie, poprosimy imię i nazwisko.

Zacznijmy od czegoś, co powinno być oczywistością.

Nie każdy podmiot korzystający z aplikacji jest człowiekiem.

Organizacje mają konta serwisowe, konta techniczne, tożsamości workloadów, integracje, procesy automatyzacji i systemy, które muszą ze sobą współpracować bez udziału konkretnego pracownika.

To absolutnie podstawowy element nowoczesnej architektury IT.

Tymczasem wciąż trafiam na aplikacje, których model tożsamości zakłada, że każdy użytkownik musi być konkretną osobą. Formularz wymaga imienia i nazwiska. Zaproszenie jest powiązane z osobistym adresem e-mail. Właściciel integracji musi być żywym użytkownikiem, a uprawnienia do zasobów są przypisywane do jego konta.

Można oczywiście wpisać „Automation” w polu imienia i „Service Account” w polu nazwiska. Technicznie problem rozwiązany. Architektura nadal płacze w kącie.

A czasami nawet tego obejścia nie da się zastosować, bo proces rejestracji, weryfikacji, aktywacji lub przypisywania licencji wymaga prawdziwej osoby.

Przykłady konsekwencji?

• Integracje i automatyzacja: skrypt korzysta z prywatnego tokenu administratora, bo aplikacja nie oferuje tożsamości technicznej ani odpowiedniego modelu uwierzytelniania workloadów.
• Własność zasobów: konfiguracja, projekt lub integracja należy do pracownika, a jego odejście uruchamia proces ratowania dostępu i przenoszenia własności.
• CI/CD: pipeline wdrożeniowy wymaga poświadczeń konkretnego użytkownika, zamiast kontrolowanej tożsamości technicznej z ograniczonymi uprawnieniami.
• Zatwierdzanie operacji: workflow wymaga wskazania konkretnej osoby, mimo że proces powinien być realizowany przez kontrolowaną tożsamość systemową.
• Audyt: logi pokazują aktywność konta technicznego podszywającego się pod człowieka, co zaciera granicę między działaniem użytkownika a działaniem automatyzacji.

Oczywiście nie każda aplikacja musi oferować identyczny mechanizm. Nie każda potrzebuje klasycznego konta serwisowego. Nowoczesnym rozwiązaniem mogą być aplikacyjne tożsamości workloadów, service principals, OAuth client credentials czy krótkotrwałe poświadczenia federacyjne.

Ale jakiś właściwy mechanizm musi istnieć.

Jeżeli automatyzacja jest wspierana marketingowo, a bezpieczna automatyzacja jest architektonicznie niemożliwa, to mamy problem projektowy, nie problem użytkownika.

2. Centralne zarządzanie? Użytkownik już sobie coś założył.

Drugi problem jest jeszcze poważniejszy.

Użytkownicy potrafią samodzielnie założyć workspace, organizację, tenant, przestrzeń roboczą czy środowisko. W wielu produktach mogą zacząć pracę, zaprosić współpracowników i umieścić dane firmowe w nowo utworzonej przestrzeni, zanim centralne IT w ogóle dowie się o jej istnieniu.

To jest wygodne.

Do czasu, aż próbujesz tym zarządzać.

Niedawno natknęłam się na ten problem w Notion. Użytkownicy założyli własne workspace’y. W organizacji skonfigurowałam SSO i weryfikację domeny, oczekując, że mechanizmy te będą częścią spójnego modelu zarządzania tożsamością i przestrzeniami organizacyjnymi.

Kiedy odkryłam te workspace’y, zwróciłam się do wsparcia z prośbą o wskazanie możliwości ich odnalezienia i uporządkowania.

Odpowiedź sprowadzała się do tego, że nie mogą udostępnić informacji ze względu na swoją politykę.

I tutaj zaczyna się absurd.

Moja organizacja ponosi ryzyko związane z danymi, tożsamościami i dostępem. Ale dostawca nie może pomóc mi zidentyfikować środowisk, które mogą to ryzyko generować, ponieważ jego własna polityka mu na to nie pozwala.

Rozumiem ochronę prywatności. Rozumiem separację klientów. Rozumiem, że administrator jednej organizacji nie powinien otrzymywać swobodnego dostępu do danych innej organizacji.

Ale identyfikacja workspace’u na podstawie zweryfikowanej domeny, wykazanie powiązania z organizacją, bezpieczne przejęcie zarządzania czy uruchomienie kontrolowanego procesu konsolidacji to zupełnie inne kwestie niż dostęp do cudzej zawartości.

Jeśli produkt nie potrafi ich rozróżnić, to jego model zarządzania jest niewystarczający dla przedsiębiorstw.

Co właściwie powinna zapewniać platforma SaaS?

• Odkrywanie środowisk utworzonych przez użytkowników z domeny organizacji.
• Centralny katalog workspace’ów, tenantów lub innych jednostek zarządzania.
• Możliwość kontrolowanego przejęcia zarządzania lub konsolidacji środowisk, z zachowaniem odpowiednich zabezpieczeń.
• Polityki ograniczające tworzenie nowych, niezarządzanych przestrzeni.
• Centralne egzekwowanie SSO, MFA i zasad dostępu warunkowego tam, gdzie produkt i jego architektura na to pozwalają.
• Widoczność zdarzeń, integracji, aplikacji i aktywnych połączeń.
• Mechanizmy eksportu, retencji, audytu i reagowania na incydenty.

Nie wszystko musi być dostępne w każdej licencji. Ale jeśli dostawca sprzedaje produkt jako rozwiązanie Enterprise, musi umieć odpowiedzieć na pytanie: jak organizacja ma nim zarządzać jako całością?

Samo SSO nie jest odpowiedzią na to pytanie.

SSO kontroluje określony etap uwierzytelniania. Nie jest automatycznie mechanizmem odkrywania workspace’ów, wymuszania przynależności do organizacji, zarządzania danymi ani zapobiegania shadow IT.

Weryfikacja domeny również nie oznacza automatycznie, że wszystkie istniejące środowiska zostaną przypisane do centralnej organizacji.

To są różne mechanizmy. I właśnie dlatego architektura ma znaczenie.

3. Enterprise to nie licencja. To model zarządzania.

Mam wrażenie, że część rynku SaaS pomyliła dwie rzeczy: produkt dostępny dla dużej liczby użytkowników oraz produkt, którym można zarządzać w dużej organizacji.

To nie jest to samo.

Można mieć aplikację, która doskonale obsługuje milion użytkowników, a jednocześnie nie pozwala administratorowi odpowiedzieć na podstawowe pytania:

• Jakie środowiska istnieją w naszej organizacji?
• Kto nimi zarządza?
• Gdzie znajdują się nasze dane?
• Kto ma dostęp do jakich zasobów?
• Jakie integracje i tokeny są aktywne?
• Jakie operacje wykonano?
• Czy możemy wymusić określoną konfigurację?
• Czy możemy wykryć i zablokować niezgodne konfiguracje?
• Czy potrafimy bezpiecznie odebrać dostęp, wyeksportować dane i przeprowadzić offboarding?

To nie są pytania dla administratora, który lubi mieć wszystko pod kontrolą.

To są pytania niezbędne do prowadzenia odpowiedzialnego IT.

W środowiskach regulowanych dochodzą do tego wymagania dotyczące audytowalności, retencji, ochrony danych, zarządzania ryzykiem dostawców, separacji obowiązków oraz wykazywania zgodności.

Jeżeli produkt nie oferuje odpowiednich kontrolek, organizacja nie może po prostu zadeklarować, że będzie zarządzać ryzykiem. Musi mieć techniczną możliwość realizowania tego zarządzania.

Polityka na papierze nie zastąpi brakującej funkcji.

4. Dwa modele IT, których nie da się po prostu skleić

Myślę, że źródła problemu należy szukać również w sposobie, w jaki powstają współczesne aplikacje.

Jeden model zakłada, że użytkownik powinien móc zacząć pracę natychmiast.

Zakłada własną rejestrację, self-service, szybkie tworzenie środowisk, samodzielne zapraszanie współpracowników, integracje dostępne na kliknięcie i jak najmniej przeszkód. To podejście doskonale odpowiada potrzebom małych zespołów, startupów i indywidualnych użytkowników.

Nazwijmy je modelem self-service IT.

Drugi model zaczyna się od innych pytań.

Jak aplikacja zostanie wdrożona? Jak będzie zarządzana? Jakie polityki zostaną zastosowane? Jak będzie monitorowana? Jak wykryjemy niepożądane zachowania? Jak administratorzy będą reagować na incydenty? Jak aplikacja będzie współpracowała z istniejącym modelem tożsamości, systemami SIEM, procesami zarządzania zmianą i wymaganiami compliance?

To model centrally managed enterprise IT.

W tym podejściu użytkownik nadal może mieć wygodny interfejs i dużo samodzielności. Różnica polega na tym, że działa w ramach kontrolowanego środowiska.

Self-service nie musi oznaczać braku governance.

Problem pojawia się wtedy, gdy dostawca projektuje produkt niemal wyłącznie pod pierwszy model, a następnie próbuje sprzedać go klientom oczekującym drugiego.

I wtedy zaczyna się dokładanie kolejnych funkcji: SSO, SCIM, role administratorów, logi audytowe, polityki bezpieczeństwa, integracje z SIEM.

Każda z nich może być wartościowa. Ale jeśli podstawowy model obiektów, tożsamości i uprawnień od początku nie przewidywał centralnego zarządzania, późniejsze rozszerzenia bywają kosztowne, niespójne i pełne wyjątków.

Nie wystarczy dodać administratora do produktu, który nigdy nie został zaprojektowany z myślą o administratorach.

5. Microsoft Teams pokazał, że można dojść do tego z drugiej strony

To nie jest problem nowy.

Pamiętam początki Microsoft Teams, kiedy wizja współpracy w chmurze była znacznie prostsza niż model zarządzania, którego oczekiwały duże organizacje.

Współpraca miała być łatwa, szybka i dostępna. Tworzenie zespołów, zapraszanie ludzi i dzielenie się informacjami miało być naturalne.

Tyle że dla administratora przedsiębiorstwa „łatwo udostępnić” i „bezpiecznie udostępnić zgodnie z polityką organizacji” nie są synonimami.

Z czasem ekosystem Teams i Microsoft 365 rozwijał mechanizmy administracyjne, polityki, kontrolę dostępu, audyt oraz narzędzia governance. Nie wszystkie problemy zniknęły, a zarządzanie tym ekosystemem nadal bywa skomplikowane, ale sam rozwój pokazuje, jak istotna jest ewolucja od prostego narzędzia współpracy do platformy zarządzanej na poziomie przedsiębiorstwa.

Jednocześnie doświadczenie Microsoftu pokazuje, że nie jest to zmiana, którą można przeprowadzić jednym przełącznikiem w panelu administracyjnym.

Jeżeli swoboda użytkownika jest fundamentem produktu, ograniczenia wprowadzane później muszą współistnieć z istniejącymi mechanizmami, zależnościami i przyzwyczajeniami.

To znacznie trudniejsze niż zaprojektowanie właściwych granic od początku.

6. Keeper i paradoks świetnej automatyzacji

Podobny rozdźwięk widzę w produktach, które są świetne pod względem funkcjonalnym, ale problematyczne w obszarze zarządzania uprawnieniami.

Przykładem z mojego doświadczenia jest Keeper.

To password manager z bardzo interesującymi możliwościami automatyzacji i funkcjami przydatnymi dla deweloperów. Jednocześnie jego model uprawnień i przywilejów okazał się dla mnie jednym z najbardziej frustrujących modeli, z jakimi miałam do czynienia.

Problem nie polega na tym, że brakuje jakiejkolwiek kontroli dostępu. Problem polega na tym, że przy próbie odwzorowania rzeczywistych wymagań organizacji można trafiać na kolejne przypadki brzegowe, których nie da się sensownie zaadresować w ramach dostępnych mechanizmów.

A to prowadzi do sytuacji, w której centralne zarządzanie istnieje formalnie, lecz praktyczne odwzorowanie polityki bezpieczeństwa staje się niezwykle trudne.

W bezpieczeństwie nie wystarczy, że produkt ma role, foldery, polityki i administratorów.

Liczy się to, czy da się z nich zbudować spójny, przewidywalny model uprawnień, który działa w rzeczywistych scenariuszach, a nie tylko w dokumentacji.

Jeżeli każda nietypowa sytuacja wymaga kompromisu, wyjątku albo obejścia, to złożoność zarządzania zaczyna zjadać korzyści z wdrożenia.

To również nie jest problem, który można rozwiązać samym dodaniem kolejnej roli.

7. Vibe coding nie jest problemem. Problemem jest architektura, która nie dojrzewa razem z produktem.

Łatwo byłoby obwinić za wszystko vibe coding, startupy i kulturę szybkiego dostarczania oprogramowania.

Nie byłoby to jednak uczciwe.

Szybkie prototypowanie, iteracyjny rozwój i samodzielne wdrażanie narzędzi są wartościowe. Citizen IT może zwiększać produktywność, a self-service potrafi odciążyć centralne zespoły IT.

Problem pojawia się wtedy, gdy początkowy model produktu staje się jego trwałym ograniczeniem.

Aplikacja powstaje z myślą o pojedynczym użytkowniku lub małym zespole. Tożsamość jest tożsamością człowieka. Własność zasobów jest lokalna. Uprawnienia są proste. Konfiguracja należy do użytkownika. Integracje bazują na jego tokenach. Administracja oznacza kilka dodatkowych przycisków.

Produkt zdobywa popularność.

Następnie przychodzi czas na Enterprise.

I nagle okazuje się, że trzeba dobudować hierarchię organizacji, centralne polityki, delegowanie uprawnień, zarządzanie cyklem życia, dziedziczenie ustawień, audyt, odkrywanie środowisk, kontrolę integracji, retencję i cały model operacyjny.

Tymczasem pierwotna architektura nie zawsze jest na to gotowa.

Nie każda aplikacja zbudowana w modelu self-service będzie miała te problemy. Nie każdy produkt korzystający z AI do generowania kodu będzie źle zaprojektowany. Nie każdy startup zignoruje enterprise.

Ale jeśli produkt od początku nie traktuje zarządzania, bezpieczeństwa i zgodności jako elementów architektury, a nie dodatków, ryzyko takiego długu jest ogromne.

I właśnie wtedy zaczyna się kosztowna próba przekształcenia narzędzia dla użytkownika w platformę dla przedsiębiorstwa.

8. Security, Governance, Compliance to nie dodatki premium

Chciałabym, żeby branża zaczęła traktować trzy obszary jako integralną część dojrzałości produktu:

Security. Czy potrafię kontrolować tożsamości, uwierzytelnianie, uprawnienia, integracje i dostęp do danych?

Governance. Czy potrafię zarządzać środowiskami, konfiguracją, cyklem życia, odpowiedzialnością i sposobem korzystania z produktu na poziomie całej organizacji?

Compliance. Czy potrafię wykazać, że wymagane kontrole rzeczywiście działają, a dane i operacje są odpowiednio chronione, monitorowane i audytowalne?

To trzy powiązane, ale odrębne obszary.

Produkt może mieć mocne Security, a słabe Governance. Może zapewniać centralne polityki, ale nie oferować wystarczających dowodów do audytu. Może posiadać rozbudowane logi, ale nie pozwalać ograniczyć niepożądanych konfiguracji.

Nie wystarczy więc sprawdzić listy funkcji.

Trzeba sprawdzić, czy całość pozwala zbudować działający model operacyjny.

I nie, sama etykieta Enterprise ani obecność SSO, SCIM czy RBAC nie stanowią dowodu, że produkt jest gotowy dla przedsiębiorstwa.

To dopiero początek rozmowy.

9. Jak powinien wyglądać prawdziwie dojrzały produkt SaaS?

Nie oczekuję, że każda aplikacja będzie miała tysiąc przełączników i panel administracyjny, który wymaga doktoratu z archeologii interfejsów.

Oczekuję natomiast, że dostawca rozumie, iż organizacja potrzebuje nie tylko korzystać z produktu, ale także zarządzać jego użyciem.

Dojrzała platforma powinna zapewniać co najmniej:

• Spójny model tożsamości, uwzględniający ludzi, administratorów, integracje i automatyzację.
• Centralne zarządzanie, pozwalające odkrywać, kontrolować i porządkować środowiska oraz zasoby.
• Przewidywalny model RBAC, z możliwością delegowania administracji, separacji obowiązków i egzekwowania zasady najmniejszych uprawnień.
• Kontrolę konfiguracji, w tym możliwość egzekwowania polityk i wykrywania odchyleń.
• Audytowalność, z odpowiednim zakresem zdarzeń, dostępem do logów i możliwościami ich integracji z systemami monitorowania.
• Kontrolę cyklu życia, obejmującą onboarding, zmiany uprawnień, offboarding, własność zasobów i odzyskiwanie dostępu.
• Mechanizmy zarządzania danymi, adekwatne do wymagań organizacji, w tym retencję, eksport, usuwanie i odpowiednie zabezpieczenia.
• Bezpieczne API i automatyzację, tak aby integracje nie musiały polegać na prywatnych kontach pracowników.
• Kontrolowane self-service, dzięki któremu użytkownicy mogą pracować samodzielnie w granicach ustalonych przez organizację.
• Dokumentację rzeczywistych ograniczeń, która pozwala architektowi ocenić produkt przed zakupem, zamiast odkrywać braki po wdrożeniu.

Nie każdy produkt potrzebuje każdej funkcji w identycznej postaci. Wymagania zależą od przeznaczenia, danych i ryzyka.

Ale dostawca powinien wiedzieć, które elementy są potrzebne jego klientom, i umieć wyjaśnić, jak można je zrealizować.

Na koniec

Najbardziej frustrujące jest to, że nie rozmawiamy o problemach, które pojawiły się wczoraj.

To nie są nieprzewidywalne zagrożenia. To nie są egzotyczne wymagania wielkich banków. To podstawowe konsekwencje projektowania oprogramowania dla środowisk, w których istnieją użytkownicy, administratorzy, dane, procesy biznesowe, obowiązki regulacyjne i odpowiedzialność za bezpieczeństwo.

Jeśli dostawca chce, żeby jego aplikacja była używana w przedsiębiorstwach, musi zrozumieć nie tylko to, jak użytkownik ma z niej korzystać, ale także to, jak organizacja ma nad nią panować.

Bo produkt, którego nie można właściwie kontrolować, nie staje się bezpieczny tylko dlatego, że wszyscy korzystają z niego w dobrej wierze.

A licencja Enterprise nie jest certyfikatem dojrzałości architektonicznej.

Jeżeli nie mogę odkryć własnych środowisk, kontrolować tożsamości, zarządzać uprawnieniami, egzekwować polityk i wykazać zgodności, to co właściwie kupuję?

Narzędzie dla użytkownika? Być może.

Platformę Enterprise? To już trzeba udowodnić.

I chciałabym, żebyśmy jako branża zaczęli wymagać tego dowodu znacznie wcześniej, niż w chwili, gdy pierwsze dane firmowe znajdą się w miejscu, nad którym nikt nie ma rzeczywistej kontroli.

LUSI.