Autoryzacja użytkowników Databricks Apps jest już ogólnie dostępna, ale granice tożsamości nadal mają znaczenie

Databricks 7 października udostępnił ogólnie autoryzację użytkowników Databricks Apps, po ponad 18 miesiącach publicznego podglądu. Funkcja pozwala aplikacji wywoływać obsługiwane usługi platformy przy użyciu tożsamości zalogowanego użytkownika. Zmienia to kluczową decyzję dotyczącą bezpieczeństwa aplikacji danych i agentów AI: czyje uprawnienia regulują każde żądanie?

Dotychczas deweloperzy często korzystali z service principal aplikacji, czyli nieosobowej tożsamości przypisanej do jednej instancji aplikacji. Każdy użytkownik mógł otrzymywać wyniki za pośrednictwem tej współdzielonej tożsamości, chyba że deweloperzy odtworzyli w aplikacji reguły dostępu na poziomie użytkownika. Nowy model pozwala istniejącym politykom Unity Catalog towarzyszyć użytkownikowi w żądaniu do aplikacji.

Ta obietnica wiąże się z istotnym zastrzeżeniem. Autoryzacja on-behalf-of-user, czyli OBO, nie sprawia automatycznie, że aplikacja jest bezpieczna. Deweloperzy muszą oddzielać działania inicjowane przez użytkownika od pracy w tle, żądać wąskich zakresów, chronić przekazywane tokeny i odrzucać żądania, gdy brakuje oczekiwanej tożsamości.

Ogłoszenie wpisuje Databricks w szerszą rywalizację między autoryzacją zarządzaną przez platformę a logiką uprawnień zarządzaną przez aplikację. Microsoft obsługuje delegowaną tożsamość przez własny przepływ OBO, podczas gdy inne platformy chmurowe oferują odrębne komponenty tożsamości i polityk. Databricks wiąże ten wzorzec bezpośrednio z zarządzanymi danymi korporacyjnymi, hurtowniami SQL, agentami i aplikacjami działającymi na swojej platformie.

Autoryzacja użytkowników Databricks Apps zmienia to, kto zarządza każdym żądaniem

Wydanie GA daje deweloperom obsługiwany sposób zachowania istniejących uprawnień użytkownika do danych przez cały przebieg żądania aplikacji.

Databricks Apps hostuje aplikacje danych, narzędzia operacyjne, pulpity i niestandardowych agentów w infrastrukturze bezserwerowej. Każda wdrożona aplikacja otrzymuje dedykowany service principal, który może uzyskiwać dostęp do zasobów przyznanych tej aplikacji. Ta autoryzacja aplikacji pozostaje dostępna i nadal sprawdza się w przypadku współdzielonych lub zautomatyzowanych operacji.

Autoryzacja użytkownika dodaje drugą ścieżkę tożsamości. Gdy zalogowana osoba inicjuje obsługiwaną akcję, Databricks przekazuje token dostępu do środowiska uruchomieniowego aplikacji. Aplikacja może następnie wywołać zatwierdzone API Databricks z użyciem tożsamości i uprawnień tej osoby.

Model autoryzacji platformy wykorzystuje OAuth 2.0, standardowy protokół dostępu delegowanego. Rozróżnia autoryzację użytkownik-maszyna od autoryzacji maszyna-maszyna. Pierwsza reprezentuje interaktywnego użytkownika, a druga aplikację lub zautomatyzowane obciążenie.

Unity Catalog ocenia następnie istniejące uprawnienia użytkownika, gdy aplikacja uzyskuje dostęp do zarządzanych danych. Filtry wierszy mogą ograniczać widoczne rekordy, a maski kolumn mogą ukrywać lub przekształcać wrażliwe pola. Uprawnienia do hurtowni również określają, czy użytkownik może wykonać żądane zapytanie.

Wynik zależy od osoby zgłaszającej żądanie. Regionalny kierownik sprzedaży może otrzymać dane dla jednego terytorium, podczas gdy lider krajowy widzi wszystkie regiony. Obie osoby mogą korzystać z tej samej aplikacji i ścieżki żądania, nie otrzymując identycznego dostępu.

To zachowanie ma znaczenie, ponieważ aplikacja nie potrzebuje oddzielnej kopii każdej reguły zarządzania. Gdy administrator zmienia politykę Unity Catalog, kolejne żądania aplikacji są oceniane względem zaktualizowanej polityki. Deweloperzy unikają utrzymywania równoległego systemu autoryzacji, który może rozjechać się z mechanizmami kontroli platformy.

Databricks po raz pierwszy wprowadził autoryzację OBO dla Apps w publicznym podglądzie 26 marca 2025 r. Wersja podglądowa obejmowała zasoby takie jak tabele Unity Catalog i endpointy udostępniania modeli. Ogólna dostępność sygnalizuje, że Databricks uznaje obecnie ten wzorzec za gotowy do wdrożeń produkcyjnych w ramach udokumentowanych ograniczeń.

GA nie eliminuje autoryzacji aplikacji. Databricks wyraźnie przedstawia oba modele jako wzajemnie uzupełniające się. Aplikacja może używać własnej tożsamości do współdzielonej konfiguracji, telemetrii lub rutynowego utrzymania, a następnie używać tożsamości bieżącej osoby do zarządzanego zapytania.

Rozważmy asystenta analiz sprzedaży, który odpowiada na pytania o wyniki kont. Tożsamość aplikacji może odczytywać wspólną konfigurację i rejestrować metryki operacyjne. Ścieżka tożsamości użytkownika odpytywałaby dane klientów i sprzedaży dostępne dla pracownika składającego żądanie.

Ten podział stanowi fundament wydania. Aplikacja nadal ma tożsamość, ale nie musi już stawać się uniwersalną bramą dla każdej interaktywnej akcji. Deweloperzy mogą zdecydować, który podmiot zarządza każdą operacją.

Zmiana dotyczy więc czegoś więcej niż logowania. Uwierzytelnianie ustala, kto jest obecny, a autoryzacja określa, co dana tożsamość może zrobić. Autoryzacja użytkowników Databricks Apps przenosi tę drugą decyzję do dalszych wywołań danych i usług.

Prawdziwa presja spada na kontrolę dostępu zarządzaną przez aplikację

Databricks kwestionuje praktykę odtwarzania korporacyjnych uprawnień do danych w każdej aplikacji.

Aplikacja korzystająca wyłącznie ze współdzielonego service principal często dysponuje jednym, stałym zestawem uprawnień. Deweloperzy muszą wtedy zdecydować, które wyniki może otrzymać każdy pracownik. Zwykle wymaga to niestandardowych ról, mapowań polityk, logiki filtrowania lub innej usługi autoryzacji.

Takie mechanizmy kontroli mogą działać, ale wprowadzają drugie źródło prawdy. Zespół odpowiedzialny za zarządzanie może zaktualizować uprawnienie Unity Catalog, podczas gdy lokalne mapowanie ról aplikacji pozostanie niezmienione. Powstała rozbieżność może ujawnić informacje lub odmówić uprawnionego dostępu.

Autoryzacja użytkownika ogranicza tę duplikację w przypadku obsługiwanych zasobów Databricks. Ustalone uprawnienia osoby zgłaszającej żądanie stają się częścią kontekstu wykonania. Kod aplikacji może skupiać się na żądanym zadaniu, podczas gdy platforma ocenia zarządzany dostęp.

Ma to coraz większe znaczenie dla agentów AI. Tradycyjny pulpit udostępnia zdefiniowane wcześniej widoki i zapytania. Agent może interpretować otwarty język, wybierać narzędzia, tworzyć zapytania i pobierać informacje w kilku krokach.

Ta elastyczność zwiększa liczbę ścieżek, przez które można dotrzeć do chronionych danych. Deweloper nie może wiarygodnie przewidzieć każdego pytania, jakie może zadać pracownik. Zachowanie kontekstu autoryzacji pracownika daje dalszej platformie dodatkową granicę egzekwowania zasad.

Presja jest szczególnie wyraźna, gdy organizacje przenoszą prototypy do środowiska produkcyjnego. Wczesne demonstracje często działają na poświadczeniach dewelopera lub szeroko uprawnionym koncie usługi. Taki skrót trudno uzasadnić, gdy aplikacja trafia do pracowników o różnych rolach, terytoriach i wymaganiach dotyczących poufności.

Jedna aplikacja może obsługiwać sprzedaż, finanse, operacje i kadrę zarządzającą. Te grupy nie powinny automatycznie dziedziczyć tego samego widoku szczegółów klientów, prognoz czy informacji o pracownikach. Centralne polityki stają się cenniejsze wraz z rozszerzaniem się grona odbiorców.

Databricks zmniejsza także tarcie między administratorami zarządzania a zespołami aplikacyjnymi. Zespoły bezpieczeństwa mogą nadal zarządzać uprawnieniami do danych przez Unity Catalog. Deweloperzy nie muszą przekładać każdej polityki na middleware specyficzny dla danego frameworka.

Nie eliminuje to pracy programistycznej. Zespoły nadal muszą zdecydować, czy dana operacja należy do użytkownika, czy do aplikacji. Muszą też rozumieć, które API Databricks obsługują OBO i jakich zakresów autoryzacji wymaga każda akcja.

Platformy alternatywne nie są pozbawione delegowanej tożsamości. Przepływ OBO Microsoftu przekazuje tożsamość użytkownika i delegowane uprawnienia z nadrzędnego API do podrzędnego API. Google Cloud zapewnia dostęp do aplikacji świadomy tożsamości, a AWS oferuje szczegółowe komponenty autoryzacji dla aplikacji niestandardowych.

Databricks wyróżnia się integracją ze swoim środowiskiem zarządzania danymi. Decyzja autoryzacyjna jest powiązana z uprawnieniami Unity Catalog, dostępem SQL i obsługiwanymi usługami platformy. Może to ograniczyć pracę integracyjną dla aplikacji, których dane już znajdują się w Databricks.

Kompromisem jest większa zależność od platformy. Aplikacje zbudowane wokół reguł Unity Catalog i zakresów specyficznych dla Databricks dziedziczą użyteczne mechanizmy kontroli, ale stają się też ściśle powiązane z modelem tożsamości jednej platformy. Zespoły wielochmurowe mogą nadal potrzebować kolejnej warstwy autoryzacji dla zasobów poza Databricks.

Dla nabywców korporacyjnych pytanie nie brzmi więc, czy delegowana tożsamość istnieje gdzie indziej. Chodzi o to, czy Databricks może wystarczająco uprościć tworzenie zarządzanych aplikacji, aby więcej danych i obciążeń AI pozostało na jego platformie.

Jak autoryzacja on-behalf-of-user tworzy dwie granice uprawnień

Żądanie OBO powiedzie się tylko w granicach zarówno uprawnień użytkownika, jak i zatwierdzonego zakresu API aplikacji.

Pierwsza granica dotyczy danych i zasobów. Użytkownik nie może uzyskać dostępu do tabeli Unity Catalog, hurtowni SQL ani obsługiwanej usługi wyłącznie dlatego, że aplikacja o to prosi. Osoba musi już posiadać niezbędne uprawnienia.

Druga granica dotyczy aplikacji. Deweloperzy deklarują zakresy API, które określają klasy operacji, jakie aplikacja może wykonywać w imieniu użytkownika. Zakres nie przyznaje danej osobie nowego dostępu do danych, ale ogranicza sposób, w jaki aplikacja może korzystać z istniejącego dostępu.

W przypadku analizy SQL tylko do odczytu Databricks dokumentuje zakres sql:restricted-query. Aplikacja może przesyłać ograniczone zapytania jako bieżący użytkownik, nie otrzymując szerokich uprawnień do zarządzania hurtowniami ani wykonywania niezwiązanych z tym działań administracyjnych.

Te przecinające się granice wspierają zasadę najmniejszych uprawnień, czyli praktykę przyznawania wyłącznie dostępu wymaganego do jednego zadania. Użytkownik o wysokich uprawnieniach może mieć bezpośredni dostęp do wielu zbiorów danych. Aplikacja o wąskim zakresie nadal nie powinna móc wykorzystywać wszystkich uprawnień posiadanych przez tego użytkownika.

Administratorzy obszaru roboczego kontrolują dodatkowy górny limit. Mogą określić, które zakresy autoryzacji użytkownika deweloperzy mogą dodawać do aplikacji w obszarze roboczym. Lista dozwolonych może obejmować wszystkie obsługiwane API, wybrane zakresy lub brak autoryzacji użytkownika.

Ta struktura dzieli odpowiedzialność. Deweloper żąda minimalnych możliwości wymaganych przez produkt. Administrator decyduje, o jakie możliwości mogą wnioskować deweloperzy aplikacji w obszarze roboczym.

Administrator nie może jednak polegać wyłącznie na konfiguracji. Databricks wskazuje, że administratorzy konta mogą dodawać zakresy nawet wtedy, gdy lista dozwolonych obszaru roboczego je wyklucza. Istniejące aplikacje mogą też nadal działać po usunięciu dozwolonego zakresu.

Zgodnie z ogłoszeniem aplikacja, której to dotyczy, nie może później zostać uruchomiona, wdrożona ani zaktualizowana, dopóki niedozwolony zakres nie zostanie usunięty. Takie zachowanie pozwala uniknąć natychmiastowej awarii, ale tworzy okres, w którym bieżące wykonanie i aktualna polityka nie są w pełni zgodne.

Zespoły powinny zatem traktować zmiany zakresów jako zarządzane zdarzenia operacyjne. Administratorzy potrzebują inwentaryzacji wdrożonych aplikacji, żądanych zakresów, odpowiedzialnych właścicieli i zależności biznesowych. Usunięcie możliwości bez tego kontekstu może opóźnić naprawę problemu lub unieruchomić aplikację podczas kolejnego wdrożenia.

Kod aplikacji musi także rozdzielać obie tożsamości. Klient o zakresie użytkownika powinien obsługiwać zarządzane operacje interaktywne. Klient o zakresie aplikacji powinien obsługiwać współdzieloną konfigurację, metryki oraz pracę, która musi być kontynuowana bez sesji użytkownika.

To coś więcej niż kwestia nazewnictwa. Ogólny klient może ukrywać, która tożsamość wykonuje wrażliwą ścieżkę. Oddzielne zależności, testy i procedury obsługi żądań ułatwiają wykrywanie niezamierzonego użycia poświadczeń.

Najbardziej rygorystyczna zasada dotyczy braku tokenów użytkownika. Jeśli trasa wymaga autoryzacji użytkownika, ale nie ma przekazanego tokenu, aplikacja powinna działać w trybie fail closed. Powinna odrzucić żądanie zamiast po cichu przełączać się na własną tożsamość usługi.

Mechanizm awaryjny może zapewnić technicznie poprawną odpowiedź przy zupełnie innych uprawnieniach. Użytkownik miałby niewiele powodów, by podejrzewać, że aplikacja uzyskała dostęp do informacji szerszych lub węższych, niż oczekiwał. To sprawia, że ciche zmiany tożsamości są szczególnie niebezpieczne.

Przekazany token powinien istnieć wyłącznie na czas aktywnego żądania. Databricks zaleca programistom, aby nigdy go nie drukowali, nie rejestrowali w logach ani nie przechowywali. Zadania działające w tle powinny korzystać z autoryzacji aplikacji zamiast zachowywać token użytkownika po zakończeniu sesji interaktywnej.

Dla zespołów tworzących wewnętrzne narzędzia AI takie rozdzielenie tożsamości powinno stanowić element innych mechanizmów inżynieryjnych. Przeszukiwalna techniczna baza wiedzy może zachowywać decyzje dotyczące autoryzacji, modele zagrożeń i dowody z przeglądów obok dokumentacji implementacyjnej.

Agenci AI utrudniają utrzymanie granicy tożsamości

Agenci korzystają z uprawnień właściwych dla użytkownika, lecz ich wieloetapowe działanie sprawia, że błędy tożsamości mają poważniejsze konsekwencje.

Databricks twierdzi, że niestandardowi agenci wdrażani przez Apps mogą korzystać z tego samego modelu autoryzacji. Klient obszaru roboczego działający w zakresie użytkownika musi zostać zainicjalizowany wewnątrz aktywnej procedury obsługi invoke lub stream. Przekazany token jest dostępny wyłącznie podczas wykonywania żądania.

To ograniczenie czasowe uniemożliwia programistom traktowanie tożsamości użytkownika jako globalnego stanu aplikacji. Proces agenta może obsługiwać wiele osób, a uruchomienie aplikacji nie należy do żadnego konkretnego użytkownika. Zbyt wczesne utworzenie klienta działającego w zakresie użytkownika grozi pominięciem lub pomieszaniem kontekstu żądania.

Przepływy pracy agentów łączą także różne rodzaje zadań. Jeden etap może pobierać wspólne instrukcje za pośrednictwem tożsamości aplikacji. Inny może odpytywać zarządzane dane finansowe jako użytkownik. Trzeci może zapisywać ogólną telemetrię bez zachowywania poświadczeń użytkownika.

Każde przejście tworzy decyzję autoryzacyjną. Programiści muszą określić podmiot, zakres, zasób i oczekiwany tryb awarii dla każdego wywołania narzędzia. Jeden ogólny klient agenta może zacierać te rozróżnienia.

Wyzwanie rośnie, gdy agent wywołuje inną usługę. OBO może zachować kontekst użytkownika tylko wtedy, gdy integracja downstream obsługuje ten model. Zewnętrzne API mogą wymagać oddzielnych poświadczeń, zgody, zakresów i mechanizmów kontroli audytowej.

Agent nie może zakładać, że autoryzacja automatycznie przenosi się przez cały łańcuch narzędzi. Token jest wydawany dla określonego odbiorcy i celu. Wytyczne Microsoft dotyczące OBO podobnie ostrzegają przed przekazywaniem tokenów warstwy pośredniej niezamierzonym odbiorcom.

Oznacza to, że autoryzacji użytkownika nie należy opisywać jako pełnej impersonacji. Aplikacja działa w imieniu użytkownika wyłącznie w skonfigurowanych zakresach i obsługiwanych ścieżkach żądań. To sformułowanie ma znaczenie, ponieważ „działanie jako użytkownik” może w przeciwnym razie sugerować nieograniczony dostęp.

Prompt injection daje kolejny powód do ostrożności. Atakujący może umieścić instrukcje w treści pobieranej przez agenta, zachęcając go do wywoływania narzędzi lub ujawniania informacji. OBO ogranicza dostępne dane do danych bieżącego użytkownika, lecz nie rozstrzyga, czy żądane działanie ma sens.

Uprawnienia samego użytkownika mogą być również rozległe. Dyrektor, administrator lub analityk może mieć dostęp do wrażliwych zbiorów danych obejmujących wiele funkcji biznesowych. Przejęta aplikacja korzystająca z prawidłowej tożsamości takiej osoby nadal stwarza poważne ryzyko.

Zakresy stanowią w tej sytuacji ważną drugą granicę. Zakres zapytań tylko do odczytu może zapobiec niezwiązanej administracji, ale nie może rozstrzygnąć, czy każde dozwolone zapytanie realizuje intencję użytkownika. Aplikacje nadal potrzebują obsługi danych wejściowych, ograniczeń narzędzi, kontroli danych wyjściowych i monitorowania.

Zgoda również zasługuje na wnikliwą analizę. Użytkownicy mogą zatwierdzać żądane uprawnienia, nie rozumiejąc, jak agent połączy usługi lub przetworzy wyniki. Jasne nazwy zakresów pomagają, ale zgoda nie zastępuje przeglądu administracyjnego ani ograniczonego zachowania aplikacji.

Niezbędna staje się możliwość audytu. Zespoły bezpieczeństwa muszą odróżniać działania wykonywane przez tożsamość aplikacji od działań wykonywanych dla konkretnej osoby. Logi powinny identyfikować właściwy podmiot i operację bez zapisywania tokenów okaziciela ani wrażliwej treści odpowiedzi.

Testy muszą obejmować użytkowników o różnych uprawnieniach. Test przeprowadzony wyłącznie na koncie administratora może ukryć błędy, ponieważ takie konto rzadko napotyka odmowy dostępu. Databricks zaleca powtarzanie testów po zmianie zasad zarządzania.

Przydatne przypadki testowe obejmują użytkownika z dostępem regionalnym, użytkownika z szerszym dostępem oraz osobę, która w ogóle nie ma dostępu do odpytywanej tabeli. Zespoły powinny weryfikować zarówno zwracane dane, jak i zachowanie przy odrzuceniu żądania. Powinny też potwierdzić, że brakujące tokeny nigdy nie uruchamiają awaryjnego użycia tożsamości aplikacji.

Centralne ograniczenie jest zatem jasne. Autoryzacja użytkowników Databricks Apps może egzekwować istniejące uprawnienia platformy, ale nie naprawi zbyt szerokich przydziałów. Organizacje nadal muszą utrzymywać dokładne grupy, uprawnienia katalogu, dostęp do warehouse'ów, filtry wierszy i maski kolumn.

Obietnica bezpieczeństwa zależy od dyscypliny operacyjnej

Najsilniejszą częścią projektu jest jego warstwowy model kontroli, podczas gdy najsłabszą pozostają implementacja i zarządzanie wokół tego modelu.

Databricks może przekazywać odpowiednią tożsamość i egzekwować zadeklarowane zakresy. Nie może zapewnić, że każdy zespół programistyczny przypisze właściwą tożsamość do każdej ścieżki kodu. Ta decyzja pozostaje częścią architektury aplikacji.

Zespół może poprawnie użyć OBO dla zapytania SQL, ale przypadkowo wykorzystać tożsamość aplikacji do powiązanego żądania pliku. Interfejs użytkownika może połączyć obie odpowiedzi bez ujawnienia odmiennych kontekstów autoryzacji.

Przetwarzanie w tle tworzy kolejną granicę. Użytkownik może zainicjować długotrwałe zadanie, które jest kontynuowane po zakończeniu żądania. Ponieważ przekazany token należy do aktywnego żądania, programiści nie mogą po prostu zachować go do późniejszego wykonania.

Bezpieczniejszy projekt polega na ustaleniu, czy opóźnione działanie należy do aplikacji, czy wymaga innego obsługiwanego wzorca delegowanego. Jeśli należy do aplikacji, service principal potrzebuje starannie ograniczonych uprawnień. Jeśli wymaga kontekstu użytkownika, programiści muszą stosować udokumentowane zachowanie platformy zamiast zachowywać token.

Dostępność w różnych środowiskach również wymaga potwierdzenia. Dokumentacja Databricks zmienia się wraz z rozszerzaniem usług i konfiguracji zgodności. Zespoły powinny zweryfikować obsługę chmury, regionu, obszaru roboczego i profilu bezpieczeństwa, zanim uznają GA za uniwersalną dostępność.

Same Apps nie mogą być anonimowymi aplikacjami publicznymi. Databricks twierdzi, że użytkownicy muszą się uwierzytelnić, a zewnętrzni współpracownicy wymagają wdrożenia za pośrednictwem obsługiwanej federacji tożsamości. To sprawia, że model jest najbardziej naturalny w scenariuszach pracowniczych i partnerskich z zarządzanymi tożsamościami.

Rozdzielenie uprawnień aplikacji i autoryzacji danych może dezorientować recenzentów. CAN USE i CAN MANAGE określają, kto może uruchamiać lub administrować aplikacją. Nie określają, do których tabel lub rekordów dana osoba może uzyskać dostęp za jej pośrednictwem.

Osoba może mieć uprawnienie do używania aplikacji, a jednocześnie nie mieć uprawnienia do odpytywania jej danych źródłowych. Takie żądanie powinno zakończyć się niepowodzeniem lub zwrócić ograniczone wyniki. Odwrotnie, sam dostęp do danych nie musi przyznawać uprawnienia do otwarcia aplikacji.

Udokumentowane poziomy uprawnień wymagają zatem oddzielnych przeglądów od przydziałów Unity Catalog. Traktowanie ich jako jednej kontroli może tworzyć fałszywe poczucie pewności podczas audytów.

Administracyjne listy dozwolonych zakresów wprowadzają kolejne zadanie związane z zarządzaniem. Zgodnie z ogłoszeniem domyślna lista może obejmować wszystkie obsługiwane API. Organizacje dbające o bezpieczeństwo powinny zdecydować, czy ten domyślny stan odpowiada ich modelowi rozwoju, zanim szeroko wdrożą aplikacje.

Zawężenie listy dozwolonych elementów może zmniejszyć ryzyko, ale może też blokować uzasadnione produkty. Właściwy proces łączy ograniczoną bazę z udokumentowaną ścieżką wyjątków. W przeciwnym razie zespoły mogą szukać szerszych tożsamości aplikacji, aby uniknąć ograniczeń zakresów.

Istnieje także wyzwanie związane z wykrywaniem. Aplikacja może żądać wyłącznie zatwierdzonych zakresów, a mimo to zachowywać się w ich obrębie nieprawidłowo. Monitorowanie w czasie działania powinno analizować nietypowe wzorce zapytań, powtarzające się odmowy, nieoczekiwane wolumeny danych i zmiany w zachowaniu aplikacji.

Obecnie żaden niezależny benchmark nie określa, ile czasu rozwoju oszczędza ta funkcja ani jak skutecznie przedsiębiorstwa unikają wad związanych z uprawnieniami. Ogłoszenie GA wyjaśnia mechanizm i zalecane praktyki, lecz wyniki wdrożeń pozostają do wykazania.

Databricks ma również interes w tym, by jego warstwa zarządzania stała się domyślną podstawą dla aplikacji wewnętrznych i agentów. Nabywcy powinni ocenić tę strategiczną korzyść obok przenośności, wysiłku integracyjnego i dojrzałości swoich obecnych systemów autoryzacji.

Istotne porównanie nie jest uproszczonym pojedynkiem Databricks z Microsoft. Wzorzec tożsamości delegowanej Microsoft jest dojrzały i szeroko stosowany w API. Databricks pakuje pokrewną zasadę wokół własnych danych, obliczeń, zarządzania i środowiska uruchomieniowego aplikacji.

Google identity-aware access koncentruje się na kontrolowaniu dostępu do hostowanych aplikacji i politykach kontekstowych. AWS oferuje komponenty autoryzacyjne, które programiści mogą łączyć z dostawcami tożsamości i zasobami aplikacji. Każde podejście przypisuje inną część pracy platformie i zespołowi aplikacyjnemu.

Organizacje powinny porównać, gdzie znajdują się polityki, które zasoby obejmują, jak tożsamości przekraczają granice usług oraz jak odmowy są prezentowane użytkownikom. Powinny też testować, czy zapisy audytowe wyraźnie łączą działanie zarówno z aplikacją, jak i osobą, która je zainicjowała.

Etykieta GA obniża jedną barierę wdrożeniową, lecz nie rozstrzyga tych kwestii architektonicznych. Funkcja jest najbardziej przekonująca, gdy zarządzanie danymi już znajduje się w Unity Catalog, a aplikacja przede wszystkim wywołuje obsługiwane usługi Databricks.

Trzy sygnały pokażą, czy wydanie GA spełnia obietnice

Kolejnym sprawdzianem będzie to, czy przedsiębiorstwa mogą wdrażać aplikacje świadome użytkownika bez zwiększania ryzyka związanego z tokenami, złożoności polityk lub uzależnienia od platformy.

Pierwszym sygnałem jest wdrożenie produkcyjne wśród wewnętrznych agentów i aplikacji operacyjnych. Databricks opisał jasny scenariusz analizy sprzedaży, lecz rzeczywiste wdrożenia będą obejmować bardziej złożone połączenia SQL, modeli, plików, dashboardów i usług zewnętrznych.

Dowody dojrzałego wdrożenia obejmowałyby powtarzalne wzorce architektoniczne, implementacje referencyjne i jasne przepływy audytowe. Obejmowałyby również aplikacje obsługujące użytkowników o znacząco różnych uprawnieniach bez powielania tych reguł w kodzie.

Słabe wdrożenie sugerowałoby, że obsługiwane zakresy, usługi downstream lub procesy organizacyjne pozostają zbyt ograniczone. Zespoły mogą nadal korzystać z service principals o szerokich uprawnieniach lub odrębnych produktów autoryzacyjnych mimo opcji GA.

Drugim sygnałem jest rozszerzanie i dopracowywanie obsługiwanych zakresów API. Wąskie zakresy ułatwiają projektowanie zgodne z zasadą najmniejszych uprawnień, ponieważ programiści mogą zażądać jednej możliwości bez otrzymywania niezwiązanej z nią władzy.

Szersze, lecz zgrubne zakresy osłabiłyby drugą granicę uprawnień. Bardziej szczegółowe zakresy, lepsze kontrole administracyjne i wyraźniejsze doświadczenia związane ze zgodą wzmocniłyby twierdzenie Databricks, że aplikacje mogą działać dla użytkowników bez przekraczania swoich uprawnień.

Zmiany dotyczące obsługi profili zgodności również mają znaczenie. Databricks wskazał, że autoryzacja użytkowników obejmie przestrzenie robocze z profilem bezpieczeństwa zgodności pod koniec września 2026 roku. Klienci powinni potwierdzić dostępność i ograniczenia we własnych środowiskach.

Trzeci sygnał dotyczy sposobu, w jaki konkurenci integrują delegowaną tożsamość ze swoimi platformami agentowymi. Microsoft już dokumentuje OBO dla tradycyjnych API oraz nowszych scenariuszy hostowanych agentów. Inne platformy również łączą tożsamość użytkownika, użycie narzędzi, silniki polityk i zarządzane środowiska uruchomieniowe aplikacji.

Jeśli te alternatywy wymagają rozległej integracji niestandardowej, Databricks zyskuje przewagę w aplikacjach opartych na nadzorowanych danych przedsiębiorstwa. Jeśli konkurenci zapewnią równie bezpośrednie dziedziczenie polityk w narzędziach danych i agentów, kupujący będą mocniej koncentrować się na przenośności i zasięgu ekosystemu.

Deweloperzy powinni obserwować dowody operacyjne, a nie język zapowiedzi. Incydenty związane z obsługą tokenów, niejasne przepływy zgody, nadmierne rozszerzanie zakresów i błędy awaryjnego przełączania tożsamości osłabiłyby tę argumentację. Jasne audyty i mniejsze nakłady na utrzymanie autoryzacji przemawiałyby na jej korzyść.

Bezpośrednie zadanie inżynieryjne jest łatwe do opisania, nawet jeśli jego realizacja wymaga dyscypliny. Przypisz każdą operację aplikacji albo do tożsamości aplikacji, albo do tożsamości bieżącego użytkownika. Nadaj możliwie najwęższy zakres, odrzucaj brakujące poświadczenia i testuj z użytkownikami, którzy faktycznie się od siebie różnią.

Zespoły powinny również przejrzeć istniejące uprawnienia Unity Catalog przed udostępnieniem ich za pośrednictwem agenta. OBO wiernie egzekwuje te uprawnienia, również te, które już są szersze, niż zamierzano. Delegowanie nie może poprawić słabej polityki źródłowej.

Autoryzacja użytkowników w Databricks Apps ma więc znaczenie, ponieważ przybliża zarządzanie uwzględniające tożsamość do danych i środowiska uruchomieniowego aplikacji. Zastępuje część powielonej logiki uprawnień egzekwowaniem na poziomie platformy, zachowując jednocześnie tożsamość aplikacji dla wspólnej pracy.

Jej powodzenie będzie zależeć od tego, czy deweloperzy utrzymają tę granicę, gdy aplikacje staną się złożone. Przed wdrożeniem kolejnego wewnętrznego asystenta zadaj jedno pytanie dla każdej ścieżki żądania: czy ta operacja powinna być wykonywana jako aplikacja, czy jako osoba, która z niej korzysta?