Ten sam asystent sprzedaży może odpowiadać kierownikowi regionalnemu i dyrektorowi krajowemu, nie pokazując im tych samych danych firmy. Trudność polega na zachowaniu różnicy, gdy żądanie opuszcza interfejs i staje się SQL, wywołaniem modelu lub narzędzia agenta.
Databricks udostępnił autoryzację użytkowników Apps ogólnie 7 października 2026 r., po ponad 18 miesiącach publicznego podglądu. OBO, czyli autoryzacja w imieniu użytkownika, pozwala wykonywać obsługiwane żądania z tożsamością zalogowanej osoby zamiast kierować wszystko przez service principal aplikacji. Istniejące kontrole Unity Catalog mogą podążać za osobą. Ogranicza to duplikowanie kodu polityk, lecz delegacja nie czyni aplikacji automatycznie bezpieczną.
Produkcyjne wydanie drugiej ścieżki tożsamości
Databricks Apps uruchamia aplikacje danych, pulpity, narzędzia operacyjne i własnych agentów w środowisku bezserwerowym. Każda wdrożona aplikacja otrzymuje osobny service principal: nieosobową tożsamość z prawami nadanymi tej instancji. Autoryzacja aplikacji nadal nadaje się do wspólnej konfiguracji, telemetrii, utrzymania i automatycznej pracy.
Autoryzacja użytkownika dodaje ścieżkę, zamiast ją zastępować. Dla obsługiwanej akcji uwierzytelnionej osoby Databricks przekazuje token do środowiska wykonawczego. Aplikacja wywołuje zatwierdzone API z prawami tej osoby. Model OAuth 2.0 rozróżnia delegację użytkownik–maszyna i pracę maszyna–maszyna.
Dla nadzorowanych danych Unity Catalog ocenia istniejące nadania, filtry wierszy i maski kolumn. Prawa do hurtowni osobno określają możliwość wykonania zapytania. Regionalny kierownik widzi jedno terytorium, a krajowy więcej, choć ścieżka aplikacji jest ta sama. Kolejne żądania podlegają aktualnej polityce katalogu, nie odrębnej kopii w aplikacji.
Unika się częstego rozjazdu. Wspólna tożsamość prezentuje backendowi jeden zestaw uprawnień, a programiści odtwarzają podział wyników przez role, mapowania, middleware lub inny serwis polityk. Takie kontrole mogą działać, ale zmiana katalogu bez aktualizacji mapowania grozi ujawnieniem informacji albo odmową legalnego dostępu.
Publiczny podgląd Apps OBO rozpoczął się 26 marca 2025 r., obejmując m.in. tabele Unity Catalog i endpointy udostępniania modeli. GA oznacza gotowość produkcyjną w udokumentowanych granicach, nie uniwersalną obsługę każdej chmury, regionu, przestrzeni roboczej, profilu zgodności i dalszego API. Źródło wspomina planowane rozszerzenie na przestrzenie z profilem bezpieczeństwa zgodności pod koniec września 2026 r.; klienci nadal muszą sprawdzić swoje środowisko.
Aplikacja może własną tożsamością odczytywać wspólne instrukcje i zapisywać metryki, a użytkownika używać do rekordów klientów i sprzedaży. Uwierzytelnianie ustala, kto jest obecny; autoryzacja decyduje o dozwolonych dalszych działaniach. Ich pomylenie pomija główny sens wydania.
Prawa użytkownika i zakresy aplikacji muszą się przecinać
Samo żądanie aplikacji nie daje osobie dostępu do tabeli czy hurtowni. Musi już mieć niezbędne prawa do zasobów. Programiści dodatkowo deklarują zakresy API ograniczające rodzaje operacji wykonywanych w jej imieniu.
To dwie granice. Zakres nie tworzy nowego nadania do danych, lecz ogranicza wykorzystanie istniejącego. Databricks dokumentuje sql:restricted-query dla analizy SQL tylko do odczytu: ograniczone zapytania jako bieżący użytkownik, bez szerokiego zarządzania hurtownią lub niezwiązanej administracji.
Ma to znaczenie zwłaszcza przy uprzywilejowanych osobach. Dyrektor lub administrator może legalnie widzieć wiele wrażliwych zbiorów, ale wąska aplikacja nie powinna dziedziczyć każdej jego możliwości. Zakresy ograniczają operacje nawet przy szerokich prawach samego użytkownika.
Administratorzy przestrzeni wyznaczają dodatkowy limit zakresów dodawanych przez programistów. Lista może dopuszczać wszystkie wspierane API, wybrane zakresy albo żadną autoryzację użytkownika. Według ogłoszenia ustawienie domyślne może obejmować wszystkie API. To wybór zarządczy, nie dowód restrykcyjnego punktu wyjścia.
Są ważne wyjątki. Administratorzy konta mogą dodawać zakresy wykluczone przez listę przestrzeni. Usunięcie wcześniej dozwolonego zakresu także nie zatrzymuje od razu istniejących aplikacji: mogą działać dalej. Nie mogą jednak później wystartować, zostać wdrożone ani zaktualizowane, dopóki niedozwolony zakres nie zostanie usunięty.
Zmiana listy nie jest więc natychmiastowym odwołaniem wszystkich trwających użyć. Inwentarz wdrożonych aplikacji, właścicieli zakresów i zależności biznesowych pozwala zarządzać okresem przejścia i uniknąć niespodziewanej blokady kolejnego wdrożenia. Ograniczona baza z udokumentowaną ścieżką wyjątków jest lepsza niż założenie, że konfiguracja rozstrzyga wszystko.
Token należy do żądania, nie całego agenta
Kod musi rozdzielać klientów użytkownika i aplikacji. Nadzorowane interaktywne zapytania należą do ścieżki użytkownika, wspólna konfiguracja i praca bez jego sesji do odpowiednio ograniczonej ścieżki aplikacji. Oddzielne zależności i procedury obsługi ułatwiają wykrycie błędnych poświadczeń bardziej niż ogólny klient ukrywający podmiot.
Gdy trasa wymaga autoryzacji użytkownika, a przekazanego tokena nie ma, powinna odrzucić żądanie. Cichy powrót do service principal może dać technicznie poprawną odpowiedź przy zupełnie innych, szerszych lub węższych prawach. Użytkownik może nie widzieć zmiany tożsamości.
Przekazywanych tokenów nie należy drukować, logować ani zapisywać trwale. Dla agentów w Apps Databricks wymaga inicjalizacji klienta przestrzeni użytkownika wewnątrz aktywnego invoke lub stream. Token istnieje tylko podczas żądania, nie w globalnym uruchamianiu aplikacji.
Jeden proces agenta obsługuje wiele osób. Globalny stan użytkownika grozi utratą lub mieszaniem kontekstu. Przepływ może pobierać wspólne instrukcje jako aplikacja, pytać o zarządzane finanse jako użytkownik i zapisywać telemetrię znów jako aplikacja, bez zachowywania jego poświadczeń. Każde przejście wymaga jawnego podmiotu i zakresu.
Długie i odroczone zadania tworzą kolejną granicę. Fakt, że użytkownik zaczął pracę trwającą dłużej niż żądanie, nie pozwala zachować tokena. Praca aplikacji potrzebuje wąsko uprawnionego service principal. Jeśli wymaga kontekstu osoby, trzeba zastosować inny udokumentowany wzorzec delegacji zamiast przechowywania poświadczeń.
OBO nie przechodzi automatycznie przez każdą integrację zewnętrzną. Dalsza usługa musi je obsługiwać i może wymagać oddzielnych poświadczeń, zgód, zakresów oraz audytu. Token ma konkretnego odbiorcę i cel; Microsoft również ostrzega przed przekazywaniem tokenów warstwy pośredniej niezamierzonym odbiorcom. To ograniczona delegacja, nie pełna impersonacja całego łańcucha.
Otwarcie aplikacji nie daje praw do jej danych
Databricks Apps nie jest modelem anonimowej aplikacji publicznej. Użytkownicy muszą się uwierzytelnić, a zewnętrzni współpracownicy dołączyć przez wspieraną federację tożsamości. Naturalnym odbiorcą są zarządzani pracownicy i partnerzy, nie nieograniczona anonimowa publiczność.
CAN USE i CAN MANAGE decydują o uruchamianiu i zarządzaniu aplikacją. Nie nadają dostępu do jej tabel, rekordów i hurtowni. Ktoś może otworzyć aplikację i dostać odmowę danych lub ograniczony wynik. Odwrotnie, prawo do tabeli nie musi pozwalać otworzyć aplikacji.
Kontrole te wymagają odrębnej oceny od nadań Unity Catalog. Prawidłowo delegowana odpowiedź SQL może zostać w interfejsie połączona z plikiem pobranym przypadkiem jako aplikacja. Platforma nie zagwarantuje, że programiści przypiszą właściwą tożsamość każdej ścieżce kodu.
Agenci zwiększają ryzyko przez interpretację otwartych pytań, dobór narzędzi i wieloetapowe zapytania. Prompt injection w pobranej treści może nakłonić do ujawnienia lub niewłaściwej akcji. OBO ogranicza dane do praw osoby, lecz prawidłowa tożsamość i zakres tylko do odczytu nie dowodzą zgodności każdego zapytania z jej intencją.
Zgoda również nie zastępuje przeglądu administracyjnego. Ludzie mogą zaakceptować zakresy bez zrozumienia łączenia usług i wyników. Potrzebne pozostają obsługa wejścia, ograniczenia narzędzi, kontrola wyjścia i monitoring: nietypowe zapytania, powtarzane odmowy, niespodziewane wolumeny oraz zmiany zachowania.
Testy wyłącznie jako administrator ukrywają błędy, bo konto rzadko doświadcza odmowy. Użytkownicy regionalni, szerzej uprawnieni i bez dostępu do tabeli pokazują różne wyniki; sprawdzić trzeba dane i odrzucenia. Databricks zaleca powtarzać testy po zmianach polityk. Logi powinny rozróżniać działania aplikacji i osoby, nie zapisując tokenów okaziciela ani wrażliwych odpowiedzi.
Mniej kopii polityk, większa zależność od platformy
Delegacja nie naprawia nadmiernych nadań u źródła. Grupy, prawa katalogu, hurtowni, filtry i maski nadal wymagają dokładnego utrzymania. Przeszukiwalna techniczna baza wiedzy może trzymać modele zagrożeń, decyzje autoryzacyjne i dowody przeglądów przy dokumentacji, ale sama nie egzekwuje praw.
Wyróżnikiem Databricks jest połączenie delegacji z własnymi danymi, SQL i środowiskiem wykonawczym, nie wynalezienie delegacji. Microsoft już dokumentuje OBO dla API. Google koncentruje dostęp świadomy tożsamości na hostowanych aplikacjach i kontekście, AWS dostarcza komponenty dla własnych systemów. Inaczej dzielą odpowiedzialność integracyjną.
Gdy dane są już zarządzane w Unity Catalog, Databricks może zmniejszyć przekład polityk między bezpieczeństwem a frameworkiem aplikacji. Ceną jest silniejsze powiązanie z własnymi zakresami i zachowaniem tożsamości. Zasoby wielochmurowe nadal mogą potrzebować innej warstwy autoryzacji.
Brak niezależnego benchmarku oszczędności czasu programowania czy unikania błędów uprawnień. Produkcyjne wzorce dla naprawdę różnych użytkowników, audytowalne mieszane usługi, drobniejsze zakresy i czytelniejsze zgody byłyby mocniejszym dowodem niż etykieta GA. Incydenty tokenów, rozrost zakresów i błędy przełączania tożsamości świadczyłyby przeciwnie.
Wydanie obniża barierę produkcyjną, lecz pozostawia centralny wybór: które operacje należą do aplikacji, a które do osoby? Jego wartość polega na utrzymaniu różnicy, gdy SQL, agenci, pliki i usługi zewnętrzne stają się jednym produktem, nie na traktowaniu zalogowanej osoby jako nieograniczonego poświadczenia.
Źródła i materiały powiązane
Ogłoszenie GA Databricks; model autoryzacji Apps; podgląd z marca 2025; wytyczne OBO Microsoft; materiał o technicznych bazach wiedzy; poziomy praw Apps; Google dostęp świadomy tożsamości.