Aplikacje AI zmieniają zaufanie do Google Workspace w nowoczesny łańcuch ataku

Bezpieczeństwo Google Workspace znalazło się w punkcie napięcia, mimo lat wzmacniania haseł, uwierzytelniania wieloskładnikowego i mechanizmów ochrony przed phishingiem. Najnowsze wiadomości Google istotne dla zespołów bezpieczeństwa dotyczą dostępu, którego atakujący nie muszą kraść bezpośrednio. Mogą go odziedziczyć za pośrednictwem zatwierdzonej aplikacji AI, przejętej sesji przeglądarki lub porzuconego tokena OAuth.

To rozróżnienie zmienia problem obrony. Programy bezpieczeństwa tradycyjnie koncentrują się na zatrzymaniu atakującego na ekranie logowania. Współczesne ataki coraz częściej zaczynają się od dostępu, który Google już uznaje za autoryzowany.

Narzędzia AI pogłębiają to napięcie, ponieważ potrzebują szerokich połączeń, aby udzielać użytecznych odpowiedzi i wykonywać działania. Asystent może czytać Gmail, przeszukiwać Drive, analizować Calendar i przekazywać ustalenia do innej usługi. Każde połączenie tworzy relację zaufania, która może przetrwać zmianę hasła i pozostać aktywna bez wyraźnej interakcji użytkownika.

Bezpośredni wniosek nie jest taki, że każde narzędzie AI jest złośliwe. Chodzi o to, że autoryzacja stała się częścią firmowego perymetru. Niedawna analiza Material Security, nagłośniona przez BleepingComputer, wskazuje, że wiele organizacji wciąż traktuje ją jako administracyjny szum w tle.

Incydent w Vercel z kwietnia 2026 roku pokazuje, dlaczego takie podejście przestało wystarczać. Według ujawnień dotyczących naruszenia atakujący najpierw przejęli zewnętrznego dostawcę AI. Następnie wykorzystali jego autoryzowane połączenie, aby uzyskać dostęp do konta Google Workspace pracownika Vercel.

Atak nie pasował do znanego schematu, w którym ktoś przełamuje zabezpieczenia logowania Vercel. Zaufanie przekroczyło granice organizacyjne za pośrednictwem integracji, którą użytkownik wcześniej zatwierdził.

Wiadomości Google przenoszą uwagę ze skradzionych haseł na odziedziczony dostęp

Istotną zmianą nie jest nowa podatność Google, lecz skuteczniejszy sposób wykorzystywania legalnego dostępu.

OAuth to mechanizm autoryzacji, który pozwala jednej aplikacji uzyskać dostęp do wybranych zasobów w innej usłudze. Umożliwia na przykład narzędziu do planowania odczyt kalendarza bez otrzymywania hasła użytkownika do Google.

Taki podział zapewnia rzeczywiste korzyści bezpieczeństwa. Użytkownicy nie muszą udostępniać danych logowania każdej podłączonej usłudze. Administratorzy mogą też ograniczać aplikacje, przeglądać żądane zakresy uprawnień i cofać zgody.

Ten sam model tworzy jednak cenny cel. Token OAuth reprezentuje uprawnienie, które już przeszło proces zatwierdzania. Każdy, kto ukradnie lub przejmie kontrolę nad takim tokenem, może działać za pośrednictwem zatwierdzonej aplikacji, w granicach przyznanych jej zakresów.

Raport Material Security dotyczący ryzyka OAuth przeanalizował produkcyjne środowiska Google Workspace i wykazał rozległą, rozproszoną powierzchnię autoryzacji. W publicznych ustaleniach podano medianę 1 807 połączeń aplikacji OAuth na firmę.

Raport wskazuje również, że 47,2 procent obserwowanych zgód nie było używanych od ponad 90 dni. Wśród tych nieaktywnych zgód 1 526 nadal zapewniało pełny dostęp do Gmaila.

Liczby te pochodzą ze zbioru danych klientów dostawcy zabezpieczeń, a nie z reprezentatywnego spisu wszystkich tenantów Workspace. Na wyniki mogą wpływać wielkość firmy, branża i obecny poziom dojrzałości bezpieczeństwa. Ustalenia nadal ujawniają problem strukturalny: stare autoryzacje często pozostają ważne, gdy ich cel biznesowy już znika.

Adopcja AI przyspiesza to nagromadzenie. Material sklasyfikował 356 publicznych aplikacji w kategorii AI i automatyzacji. Według firmy 325 z nich pojawiło się po raz pierwszy w analizowanych środowiskach po 1 stycznia 2024 roku.

Oznacza to, że 91 procent obserwowanej populacji aplikacji AI pojawiło się w ciągu 16 miesięcy. Ponad połowa tych aplikacji miała podobno wrażliwe lub ograniczone zakresy uprawnień.

Zakres określa, do czego aplikacja może uzyskać dostęp lub co może zmieniać. Szerokie zakresy mogą zezwalać aplikacji na odczytywanie poczty e-mail, przeglądanie zawartości Drive, wysyłanie wiadomości lub usuwanie informacji.

Organizacje stają więc przed trudnym problemem klasyfikacji. Prośba o dostęp do Drive może wspierać użytecznego asystenta badawczego. To samo uprawnienie może ujawnić umowy, dokumenty strategiczne, dane uwierzytelniające i rejestry klientów, jeśli aplikacja zostanie przejęta.

Zagrożenie nie wymaga, aby aplikacja od początku była złośliwa. Legalny dostawca może stać się punktem wejścia po naruszeniu urządzenia pracownika, konta programisty, klucza podpisującego lub środowiska chmurowego.

Taka możliwość zmienia rutynowe zatwierdzanie aplikacji w decyzję dotyczącą łańcucha dostaw. Użytkownik widzi ekran zgody, lecz organizacja dziedziczy przyszłe błędy bezpieczeństwa dostawcy.

Jedno przejęte narzędzie AI może przekroczyć dwie granice bezpieczeństwa

Incydent Vercel pokazuje, jak atakujący może przejść przez dostawcę AI zamiast bezpośrednio atakować ostateczny cel.

Vercel ujawnił incydent bezpieczeństwa w kwietniu 2026 roku, obejmujący przejęte zewnętrzne narzędzie AI i konto Google Workspace pracownika. Publiczne doniesienia wskazywały na Context.ai jako tego dostawcę.

Według dostępnych ujawnień pracownik Vercel połączył AI Office Suite firmy Context.ai, używając tożsamości firmowej. Połączenie otrzymało szerokie uprawnienia Google Workspace.

Podmiot zagrażający później przejął kontrolę nad istotnym dostępem posiadanym przez Context.ai. Dostęp ten miał zapewnić ścieżkę do konta Workspace pracownika, a następnie do wewnętrznych systemów Vercel.

Sekwencja stworzyła dwa połączone ryzyka związane z łańcuchem dostaw. Context.ai zależało od własnych tożsamości pracowników i infrastruktury. Vercel z kolei zależał od integralności aplikacji OAuth Context.ai.

Niezależni badacze przypisali początkowe przejęcie Context.ai infekcji infostealerem. Infostealer to złośliwe oprogramowanie zaprojektowane do zbierania haseł, plików cookie przeglądarki, tokenów i innych materiałów uwierzytelniających.

Doniesienia łączyły tę infekcję z oprogramowaniem przedstawianym jako exploit do Roblox. Jednak nie każdy szczegół początkowego przejęcia uzyskał niezależne potwierdzenie ze strony Vercel.

To, co potwierdził Vercel, ma większe znaczenie dla planowania w przedsiębiorstwach. Istniejąca autoryzacja zewnętrznej aplikacji pomogła atakującemu dotrzeć do firmowego konta Workspace pracownika.

Atakujący miał uzyskać dostęp do zmiennych środowiskowych, które nie zostały oznaczone jako wrażliwe. Vercel zalecił dotkniętym klientom audyt aktywności i rotację ujawnionych danych uwierzytelniających.

Współczesna relacja podawała, że atakujący żądał zapłaty za skradzione dane. Vercel zaangażował Mandiant, powiadomił organy ścigania i skontaktował się z ograniczoną grupą dotkniętych klientów.

Vercel poinformował również, że wrażliwe zmienne środowiskowe były szyfrowane w spoczynku i nie uzyskano do nich dostępu. Jego projekty open source, w tym Next.js i Turbopack, miały pozostać nienaruszone.

Incydentu nie należy upraszczać do twierdzenia, że OAuth samo w sobie zawiodło. OAuth wykonało autoryzację, na którą zezwolili użytkownicy i administratorzy.

Awaria wynikała z całego łańcucha zaufania. Dostawca został przejęty, aplikacja miała szeroki dostęp, a ten dostęp prowadził do cennej tożsamości firmowej.

Tradycyjne zabezpieczenia logowania obejmowały tylko jedną część tej sekwencji. Atakujący nie musiał ponawiać pierwotnej decyzji o wyrażeniu zgody, gdy istniała już użyteczna autoryzacja.

Zmiana hasła może również pozostawić niektóre autoryzacje aplikacji nienaruszone. To sprawia, że reakcja jest bardziej skomplikowana niż zresetowanie danych uwierzytelniających i zamknięcie aktywnych sesji przeglądarki.

Zespoły muszą ustalić, które tokeny istnieją, jakie zakresy uprawnień mają i które podłączone aplikacje nadal mogą działać. Następnie muszą cofnąć dostęp bez zakłócania niezbędnych procesów biznesowych.

To centralne odwrócenie nowoczesnego łańcucha ataku. Aplikacja zaprojektowana, by ograniczyć udostępnianie haseł, może stać się trwałą drogą obejścia zabezpieczeń skupionych na hasłach.

Agenci AI sprawiają, że znane rejestry OAuth są mniej informacyjne

Agenci AI mogą wyglądać zwyczajnie w dziennikach autoryzacji, a jednocześnie zachowywać się znacznie mniej przewidywalnie niż konwencjonalne integracje.

Tradycyjna aplikacja zwykle wykonuje wąski zestaw funkcji. Usługa podpisywania dokumentów może pobrać plik, zebrać podpisy i zwrócić ukończoną kopię.

Jej zachowanie może się zmieniać, ale administratorzy nadal mogą porównywać żądane uprawnienia ze stosunkowo stabilnym celem. Nadmierny dostęp do Gmaila lub Calendar powinien wyglądać podejrzanie w przypadku takiej usługi.

Agent AI nie działa według tego samego modelu zachowania. Jego kolejne działanie może zależeć od polecenia użytkownika, pobranych treści, dostępnych narzędzi, wyniku modelu i instrukcji dostarczonych przez system zewnętrzny.

Na poziomie autoryzacji te różnice mogą zniknąć. Uprawnienie Drive tylko do odczytu przyznane asystentowi AI może przypominać uprawnienie przyznane stałemu narzędziu do obsługi dokumentów.

Analiza agentów Material twierdzi, że sygnały bezpieczeństwa przesuwają się od zgód w stronę zachowań po autoryzacji. Tożsamość dostawcy i zakres pozostają użyteczne, ale nie mogą w pełni opisać, co zrobi agent ogólnego przeznaczenia.

Model Context Protocol, powszechnie nazywany MCP, może zwiększać tę niepewność. MCP to standard łączenia systemów AI z narzędziami i zewnętrznymi źródłami danych.

Agent połączony przez MCP może przeszukać Workspace, przekazać wybrane treści do innego narzędzia, je podsumować i uruchomić działanie następcze. Proces może obejmować wiele usług w ramach jednego żądania użytkownika.

Powstaje przez to kilka pytań dotyczących bezpieczeństwa, na które ekran zgody nie jest w stanie odpowiedzieć. Administratorzy muszą wiedzieć, do jakich informacji agent faktycznie uzyskał dostęp, dokąd je wysłał i czy jego aktywność odpowiadała intencji użytkownika.

Prompt injection dodaje kolejną warstwę. Prompt injection występuje wtedy, gdy niezaufana treść manipuluje instrukcjami lub użyciem narzędzi przez system AI.

Agent może napotkać wrogie polecenia w wiadomości e-mail, udostępnionym dokumencie, wpisie kalendarza lub na stronie internetowej. Jeśli potraktuje tę treść jako instrukcję, jego legalne uprawnienia mogą stać się mechanizmem szkodliwego działania.

Ryzyko to różni się od klasycznego malware. Niekoniecznie dochodzi do zapisania pliku wykonywalnego na urządzeniu użytkownika, a dostawca AI może pozostać nieprzejęty.

Zamiast tego system może niewłaściwie wykorzystywać prawidłowe narzędzia podczas przetwarzania treści przeciwnika. Kontrole bezpieczeństwa muszą odróżniać autoryzowaną automatyzację od autoryzowanej automatyzacji zachowującej się niebezpiecznie.

Nie oznacza to, że każdy podłączony agent potrzebuje nieograniczonego monitorowania promptów lub prywatnych treści. Nadmierna inwigilacja tworzy własne zagrożenia dla prywatności, zgodności i ładu organizacyjnego.

Oznacza to, że organizacje potrzebują dowodów na poziomie aktywności. Użyteczne sygnały obejmują nietypowy wolumen pobierania, nowe zachowania związane z przekazywaniem wiadomości, szybkie wyliczanie zawartości skrzynek pocztowych, nieoczekiwane kombinacje usług oraz dostęp wykraczający poza zwykły wzorzec użytkownika.

AI zwiększa również liczbę połączeń wymagających przeglądu. Pracownicy mogą wdrażać asystentów bezpośrednio, często zanim zespoły zakupowe lub bezpieczeństwa je ocenią.

Rozpoznawalna nazwa marki nie gwarantuje, że aplikacja widoczna na ekranie zgody należy do tej marki. Raport Material opisuje aplikację o nazwie „gamma.com.ai”, która przypominała legalną usługę prezentacyjną Gamma.

Material twierdzi, że wydawca nie był powiązany z Gamma i dążył do uzyskania dostępu w wielu środowiskach klientów. Raport przedstawia ten przypadek jako podszywanie się pod OAuth, w którym wizualna znajomość zachęca do zatwierdzenia.

Ekran autoryzacji nadal pokazywał domenę i żądane uprawnienia. Ludzka decyzja zawiodła, ponieważ znajoma nazwa ograniczyła kontrolę.

Ta ścieżka ataku nie wymaga sfałszowanej strony z hasłem. Nakłania użytkownika do udzielenia prawidłowej autoryzacji niewłaściwej stronie.

MFA Chroni Logowanie, Nie Każdą Decyzję Podejmowaną Później

Uwierzytelnianie wieloskładnikowe pozostaje niezbędne, lecz nie może zweryfikować każdego tokenu, aplikacji i działania w przeglądarce po udanym logowaniu.

MFA blokuje wiele ataków opartych na hasłach, ponieważ samo skradzione hasło nie wystarcza. Metody odporne na phishing, w tym passkeys i sprzętowe klucze bezpieczeństwa, zapewniają silniejszą ochronę przed przekazywaniem poświadczeń w czasie rzeczywistym.

Google rozszerzył obsługę passkeys i mechanizmy administracyjne w całym Workspace. Środki te ograniczają narażenie na konwencjonalne przejęcia kont.

Jednak zgoda OAuth jest często udzielana po uwierzytelnieniu. Użytkownik loguje się poprawnie, przechodzi MFA, a następnie zatwierdza aplikację.

Wynikowy token rejestruje autoryzowaną decyzję. Ponowne użycie tego tokenu może nie wywołać ponownie tego samego wyzwania uwierzytelniającego.

Kradzież sesji przeglądarki tworzy powiązaną lukę. Plik cookie sesji to dane, które pozwalają usłudze rozpoznać wcześniej uwierzytelnioną przeglądarkę.

Atakujący, który ukradnie prawidłowy plik cookie, może przejąć ten uwierzytelniony stan. Google dokumentuje procedury reakcji na pliki cookie sesji służące badaniu podejrzanych sesji i wymuszaniu wylogowania.

Tokeny aplikacji i sesje przeglądarki nie są tym samym. Oba przypadki pokazują, dlaczego zdarzenie logowania nie może wyznaczać całej granicy bezpieczeństwa.

Atakujący wykorzystują także phishing typu adversary-in-the-middle, znany jako AiTM, aby przekazywać poświadczenia i drugie czynniki przez aktywną fałszywą sesję. Technika ta może przechwycić uwierzytelnioną sesję utworzoną po pomyślnym MFA.

Uwierzytelnianie odporne na phishing podnosi trudność ataku, ponieważ poświadczenia są kryptograficznie powiązane z prawidłową witryną. Organizacje powinny jednak nadal zakładać, że malware, skompromitowane aplikacje i skradzione tokeny mogą tworzyć inne ścieżki.

Microsoft udokumentował nadużycia przekierowań OAuth z udziałem zaufanych adresów URL dostawców tożsamości. Kampanie manipulują parametrami protokołu lub połączonymi aplikacjami, aby kierować ofiary do miejsc kontrolowanych przez atakujących.

Szerszy wzorzec dotyczy nie tylko Google. Microsoft 365, Salesforce, platformy rozwoju chmurowego i usługi danych wszystkie opierają się na tokenach oraz integracjach zewnętrznych.

Kilka dużych kampanii wymierzyło się w te relacje. Incydenty związane z Salesloft Drift pokazały, jak skradzione tokeny integracyjne mogą zapewniać dalszy dostęp do środowisk klientów.

To porównanie jest istotne, ponieważ wyklucza wyjaśnienie ograniczone wyłącznie do Google. Oprogramowanie dla przedsiębiorstw coraz częściej działa jako graf delegowanego zaufania.

Obrońcy muszą zachować MFA, jednocześnie rozszerzając swój model. Uwierzytelnianie odpowiada na pytanie, czy dana tożsamość spełniła wymóg logowania. Autoryzacja odpowiada na pytanie, co ta tożsamość lub połączona z nią aplikacja może zrobić później.

Zespoły bezpieczeństwa muszą także uwzględniać trwałość dostępu. Unieważnienie jednej sesji przeglądarki niekoniecznie unieważnia uprawnienia aplikacji. Zawieszenie użytkownika może pozostawić połączony dostęp wymagający odrębnego dochodzenia.

Plany reagowania na incydenty powinny wyraźnie wymieniać te działania. W przeciwnym razie zespół może zresetować hasła, zamknąć sesje i błędnie uznać, że dostęp został zakończony.

Tak rozszerzona reakcja jest wymagająca operacyjnie. Duże organizacje mogą mieć tysiące uprawnień, kont usługowych, delegowanych zezwoleń i zautomatyzowanych przepływów pracy.

Unieważnienie wszystkiego nie jest wiarygodną polityką długoterminową. Zakłóciłoby produktywność i zachęciło pracowników do szukania mniej widocznych alternatyw.

Możliwym do obrony celem jest selektywne zaufanie. Zespoły powinny identyfikować aplikacje, weryfikować wydawców, ograniczać zakresy, monitorować zachowanie i usuwać dostęp, gdy jego cel wygasa.

Kompromis Dotyczy Użytecznej AI i Niemierzonego Zaufania

Zablokowanie każdej integracji ograniczyłoby jedno ryzyko kosztem zniszczenia połączonych przepływów pracy, które czynią AI dla przedsiębiorstw użyteczną.

Asystenci AI potrzebują kontekstu, aby wyjść poza ogólne odpowiedzi. Asystent przygotowujący aktualizację dla klienta może potrzebować poczty e-mail, notatek ze spotkań, historii konta i dokumentów projektowych.

Ograniczenie go do pustego okna czatu zmniejsza narażenie. Usuwa jednak także dużą część wartości, której pracownicy oczekują od AI dla przedsiębiorstw.

Organizacje stoją więc przed kompromisem, a nie binarną decyzją dotyczącą bezpieczeństwa. Muszą zezwalać na użyteczny dostęp, nie dopuszczając do bezterminowego narastania autoryzacji.

Pierwszym krokiem jest widoczność. Administratorzy potrzebują obejmującego całą domenę rejestru aplikacji, uprawnień, użytkowników, zakresów, wydawców i niedawnej aktywności.

Rejestr powinien odróżniać publiczne aplikacje zewnętrzne od narzędzi wewnętrznych. Powinien także identyfikować uprawnienia powiązane z byłymi pracownikami, kontraktorami, kontami testowymi i nieaktywnymi projektami.

Samo przeglądanie nazw nie wystarcza. Zespoły powinny weryfikować tożsamość wydawcy, domeny aplikacji, lokalizacje przekierowań, żądane zakresy oraz to, czy narzędzie przeszło odpowiednią weryfikację platformy.

Weryfikacja nie jest trwałą gwarancją. Legalny dostawca może zostać naruszony, przejęty lub zmieniony po zatwierdzeniu.

Kontrola zakresów zapewnia kolejną warstwę. Aplikacje powinny otrzymywać minimalne uprawnienia niezbędne dla zdefiniowanego przepływu pracy.

Usługa transkrypcji nie powinna otrzymywać pełnego dostępu do Gmail bez wyraźnego uzasadnienia. Asystent, który przeszukuje wyłącznie wybrane foldery Drive, nie powinien automatycznie otrzymywać dostępu do każdego pliku.

Czas również ma znaczenie. Dostęp przyznany na potrzeby oceny powinien wygasać po jej zakończeniu. Organizacje powinny unikać przekształcania tymczasowych eksperymentów w trwałe poświadczenia.

Administratorzy Google mogą ograniczać dostęp aplikacji zewnętrznych i klasyfikować usługi jako zaufane, ograniczone lub zablokowane. Mechanizmy te działają najlepiej, gdy wspiera je proces zatwierdzania, który dotrzymuje tempa pracownikom.

System przeglądu trwający tygodniami zepchnie wdrażanie do podziemia. System zatwierdzający rozpoznawalne nazwy bez badania uprawnień doprowadzi do rozrostu autoryzacji.

Monitorowanie zachowania obejmuje to, czego zatwierdzenie nie potrafi przewidzieć. Zespoły powinny wykrywać sytuacje, w których aplikacja nagle odczytuje znacznie więcej danych, uzyskuje dostęp do nietypowych użytkowników lub zaczyna wykonywać nowe działania.

Jest to szczególnie ważne dla agentów AI. Ich możliwości ogólnego przeznaczenia sprawiają, że statyczne opisy są słabszymi wskaźnikami oczekiwanego zachowania.

Badania Cloud Security Alliance przedstawiają łańcuchy OAuth AI SaaS jako systemową powierzchnię ataku na przedsiębiorstwa. Ich analiza łańcucha zaufania łączy incydent Context.ai z innymi dalszymi kompromitacjami tokenów.

Raport argumentuje, że przedsiębiorstwa powinny traktować zarządzanie cyklem życia OAuth jako podstawową funkcję bezpieczeństwa. Obejmuje to wydawanie, rejestrację, monitorowanie, rotację, unieważnianie i reagowanie na incydenty.

Zespoły bezpieczeństwa powinny nadal ostrożnie traktować statystyki dostawców. Material sprzedaje produkty bezpieczeństwa Workspace, a jego badania wspierają problem, którym zajmuje się jego platforma.

Jego zbiór danych oferuje jednak pytania, które każda organizacja może sprawdzić. Administratorzy mogą mierzyć własną liczbę uprawnień, udział nieaktywnych uprawnień, wrażliwe zakresy, wzrost liczby aplikacji AI i luki w unieważnianiu dostępu.

Najsilniejszą odpowiedzią są dowody zebrane z własnego środowiska organizacji. Lokalny audyt może potwierdzić, czy opisywany wzorzec ma zastosowanie, oraz wskazać połączenia o najwyższym ryzyku.

Na Co Zespoły Bezpieczeństwa Powinny Zwracać Uwagę Dalej

Trzy sygnały pokażą, czy ochrona Workspace dostosowuje się do autoryzacji w erze AI, czy jedynie dodaje kolejny pulpit.

Pierwszym sygnałem będzie lepsza widoczność po przyznaniu uprawnień ze strony Google i dostawców bezpieczeństwa. Administratorzy potrzebują czegoś więcej niż zapisu wskazującego, że aplikacja otrzymała określony zakres.

Potrzebują użytecznych odpowiedzi dotyczących późniejszej aktywności aplikacji. Obejmuje to zasoby, do których uzyskała dostęp, zmiany jej wzorca działania oraz to, czy dane przemieszczały się między połączonymi usługami.

Google już zapewnia możliwości dochodzeniowe i kontroli dostępu, lecz zakres ich działania zależy od edycji, konfiguracji i dostępnej telemetrii. Kluczowym testem jest to, czy zespoły potrafią prześledzić działania agenta AI bez składania dowodów z kilku niepowiązanych konsol.

Jeśli dochodzenia na poziomie aktywności staną się bardziej przejrzyste, opisany tu model bezpieczeństwa zyska praktyczne wsparcie. Jeśli logi nadal będą koncentrować się na początkowej zgodzie, obrońcy będą nadal oceniać dynamicznych agentów na podstawie statycznych metadanych.

Drugim sygnałem będzie sposób, w jaki dostawcy AI zawężają uprawnienia i nimi zarządzają. Dojrzałe produkty powinny wyjaśniać, dlaczego każdy zakres jest konieczny, oraz oferować użyteczne przepływy pracy z mniejszym zakresem autoryzacji.

Powinny obsługiwać selektywne źródła danych, krótkotrwały dostęp tam, gdzie jest to praktyczne, szybkie unieważnianie oraz przejrzyste zapisy aktywności narzędzi. Powinny też oddzielać automatyzację skierowaną do użytkownika od wysokiego ryzyka działań administracyjnych.

Szerokie domyślne zakresy osłabiłyby twierdzenia, że rynek wyciąga wnioski z niedawnych incydentów. Bardziej granularne mechanizmy kontroli pokazałyby, że dostawcy uznają autoryzację za problem projektowania produktu.

Trzecim sygnałem będzie to, czy organizacje mierzą ekspozycję OAuth w ramach rutynowych działań bezpieczeństwa. Jeden coroczny przegląd nie może dorównać tempu, w jakim pracownicy wdrażają narzędzia AI.

Zespoły powinny śledzić nieaktywne uprawnienia, nowych wydawców, wrażliwe zakresy, odchodzących użytkowników i nagłe zmiany zachowania aplikacji. Te miary powinny pojawiać się w cyklicznych przeglądach tożsamości i bezpieczeństwa chmurowego.

Ćwiczenia dotyczące incydentów powinny także testować kompromitację tokenu strony trzeciej. Osoby reagujące muszą wiedzieć, jak zidentyfikować dotkniętych użytkowników, unieważnić uprawnienia, zamknąć sesje, rotować dalsze sekrety i zachować dowody.

Najnowsze wiadomości dotyczące Google nie dowodzą, że Workspace stał się z natury niebezpieczny. Pokazują, że założenia bezpieczeństwa oparte na ochronie logowania nie obejmują już całej ścieżki do danych przedsiębiorstwa.

Hasła i MFA pozostają konieczne. Po prostu nie są końcową kontrolą, gdy pracownicy autoryzują aplikacje do działania w obrębie poczty e-mail, plików, kalendarzy i połączonych systemów.

Trudniejsze pytanie brzmi, czy organizacje mogą widzieć i zarządzać tą delegowaną aktywnością bez blokowania użytecznej pracy. Liderzy bezpieczeństwa powinni zacząć od bezpośredniego pomiaru: ile połączonych aplikacji może obecnie uzyskać dostęp do danych firmy i kto nadal odpowiada za każdą z tych decyzji?