A Databricks Apps mostantól a felhasználók jogosultságaival is működhet

Kétféle identitással működhetnek az alkalmazások

A Databricks Apps segítségével a fejlesztők közvetlenül a Databricks platformon készíthetnek és telepíthetnek adat- és AI-alkalmazásokat. Ezek között lehetnek interaktív irányítópultok, operatív eszközök és egyedi AI-ügynökök. Az új, általánosan elérhető OBO-engedélyezés lehetővé teszi, hogy az alkalmazások személyre szabott, jogosultságtudatos működést kínáljanak anélkül, hogy a fejlesztőknek az adatirányítási szabályokat újra meg kellene valósítaniuk az alkalmazás kódjában.

A Databricks két kiegészítő engedélyezési modellt különít el. Az alkalmazásengedélyezés az app dedikált szolgáltatásazonosítóját használja, és olyan műveletekre való, amelyek magához az alkalmazáshoz tartoznak, vagy minden felhasználónak azonos eredményt adnak. Ilyen lehet a megosztott konfiguráció beolvasása, az alkalmazás metrikáinak írása, illetve a háttérfeladatok és karbantartási műveletek futtatása.

A felhasználói engedélyezés ezzel szemben a bejelentkezett felhasználó identitását használja. Ez akkor indokolt, amikor az adott műveletet a felhasználó jogosultságainak kell szabályozniuk. A Databricks szerint a legtöbb éles alkalmazás mindkét modellt használhatja, és minden kérési útvonalhoz a megfelelő identitást választhatja.

A Unity Catalog szabályai érvényben maradnak

OBO használatakor a támogatott Databricks API-k a bejelentkezett felhasználó nevében működnek. A Unity Catalog ilyenkor érvényesíti a felhasználó meglévő adathozzáféréseit, köztük a sorokra vonatkozó szűrőket és az oszlopmaszkokat. Az API-hatókörök azt szabják meg, hogy az alkalmazás milyen műveleteket végezhet a felhasználó nevében, a felhasználó saját jogosultságai pedig azt, hogy ténylegesen mely erőforrásokhoz és adatokhoz férhet hozzá.

A Databricks egy értékesítési elemzőasszisztenst hoz példaként. Az alkalmazás a kérdést feltevő értékesítő jogosultságaival kérdezhet le értékesítési és ügyféladatokat, és csak azokat a számlákat, sorokat vagy oszlopokat adhatja vissza, amelyekhez az adott felhasználónak hozzáférése van. Így egy regionális vezető csak a saját régiójához tartozó ügyfeleket láthatja, míg egy országos vezető minden régió adataihoz hozzáférhet, ha ezt a meglévő engedélyei lehetővé teszik. Az Unity Catalog szabályainak módosításai a későbbi alkalmazáskérésekben is megjelennek.

Az ilyen, kizárólag olvasásra szánt használathoz a Databricks a sql:restricted-query API-hatókört említi. Ez lehetővé teszi olvasási SQL-lekérdezések futtatását, de nem ad lehetőséget más SQL-műveletekre vagy erőforrások kezelésére. Ha az alkalmazás a Genie vagy a Unity Gateway szolgáltatást is a felhasználó nevében hívja, csak az ezekhez szükséges hatókört kell kérnie, például a genie vagy az ai-gateway hatókört.

A hatókörök képességkorlátot jelentenek, nem automatikus adathozzáférést. Az alkalmazásnak rendelkeznie kell a megfelelő API-hatókörrel, a felhasználónak pedig továbbra is engedéllyel kell bírnia a célként megadott SQL-raktár és a lekérdezett Unity Catalog-adatok használatához.

A munkaterület rendszergazdája szabhat felső korlátot

A fejlesztők az alkalmazás konfigurációjában adhatják meg a szükséges felhasználói API-hatóköröket. A munkaterület rendszergazdái eközben meghatározhatják, hogy a fejlesztők egyáltalán mely hatóköröket adhatják hozzá az alkalmazásokhoz. Az engedélyezési lista a Settings > Development > Apps menüpontban állítható be.

Az alapértelmezés szerint az összes támogatott API engedélyezhető, a lista szűkíthető kiválasztott hatókörökre, vagy a felhasználói engedélyezés teljesen letiltható a None beállítással. Ez két szintű kontrollt ad a szervezeteknek: az alkalmazás deklarálja a működéséhez szükséges minimumot, a munkaterület rendszergazdája pedig meghatározza az elérhető maximumot. A Databricks szerint a fiókrendszergazdák olyan hatóköröket is hozzáadhatnak, amelyek nem szerepelnek a munkaterület engedélyezési listáján.

Ha egy rendszergazda később eltávolít egy korábban engedélyezett hatókört, az azzal már futó alkalmazások tovább működhetnek. Újraindítani, telepíteni vagy frissíteni azonban csak akkor lehet őket, ha az érintett, már nem engedélyezett hatókört eltávolítják a konfigurációból.

Külön kell választani az app és a felhasználó jogosultságait

A Databricks azt javasolja, hogy az alkalmazások kódjában jól látható legyen az identitások határa. Egy értékesítési asszisztens például használhat alkalmazásszintű klienst a közös konfiguráció beolvasására és a metrikák írására, valamint felhasználói klienst a bejelentkezett személy által engedélyezett adatok lekérdezésére.

A felhasználó továbbított hozzáférési tokenjét a Databricks az x-forwarded-access-token HTTP-fejlécben adja át. Az alkalmazásnak ezt csak ahhoz a kéréshez kell kiolvasnia, amely felhasználói környezetben végrehajtott műveletet igényel, majd továbbítania kell az SQL-összekötőnek. A token rövid élettartamú és kérésenkénti, ezért a Databricks szerint nem szabad kérések között vagy munkamenetben tárolni.

Az OBO-engedélyezés 2026. október 7-i bejelentése a Databricks Apps fejlesztőinek olyan felépítést ad, amelyben az alkalmazás saját feladatai és a felhasználó által kezdeményezett, szabályozott adatműveletek elkülöníthetők. Ez az adat-hozzáférési szabályok alkalmazáskódba másolása helyett a meglévő Unity Catalog-jogosultságokra és az API-hatókörökre támaszkodik.