Az Azure OpenAI-asszisztens átlépte a SharePoint-jogosultságokat, tapasztalta egy olasz szakértő

Egiziago Cioffi, az olasz SynSphere Italia IT- és vállalati építésze maga épített egy asszisztenst. Konfigurálta az Azure OpenAI lekérdezési folyamatát, összekapcsolta a SharePointtal, és azt tapasztalta, hogy az minden teszten átment. Az asszisztens a beérkező ügyfél-e-mailek mintegy 60%-át automatikusan megoldotta. A teszteredmények tiszták voltak, a modul tesztek sikeresek voltak, de nem vizsgálták meg a legfontosabb kérdést. (VentureBeat)

A jogosultságkezelés hiányosságai

Cioffi egy alacsony jogosultságú fiókkal futtatta ugyanazokat a kérdéseket, amelyeket egy magas jogosultságú fiók már feltett az asszisztensnek. Az eredmények nem egyeztek. Az asszisztens olyan SharePoint-tartalmakat adott vissza, amelyeket a kérdező felhasználó önmagában nem nyithatott volna meg a SharePointban. A naplók más történetet meséltek, mint az értékelési pontszámok. Cioffi lekérdezési naplói bizonyítják ezt a konkrét gyártási hibát.

A probléma szélesebb körben is elterjedt. Sok gyártásban lévő RAG (Retrieval-Augmented Generation) telepítésben az ügynök az indexelő engedélyeivel válaszol, nem a kérdezőével. Az Azure AI Search 2025 májusa óta kínál natív dokumentumszintű ACL-szűrést Entra-alapú tokenekkel, és a SharePoint ACL-szinkronizálás később érkezett meg előzetes verzióban. A képesség létezik, de nem mindenhol érhető el, ahol szükség lenne rá.

A SharePoint ACL előzetes verziója most már képes webhelycsoport-metaadatokat bevinni a 2026-05-01-preview API `spg:` előtagjával. Azonban csak az Entra-alapú főnevek dokumentáltan megbízhatóan érvényesülnek lekérdezéskor. Az előzetes verzió a REST API-n és az SDK-kon keresztül fut, és nem fedi le az összes ügynöktelepítési útvonalat.

Az Azure OpenAI On Your Data például támogatja a dokumentumszintű hozzáférést az Azure AI Search biztonsági szűrőin keresztül, de a Microsoft saját dokumentációja szerint, ha a `permitted_groups` mezőt nem képezik le, a dokumentumszintű hozzáférés le van tiltva. Ez egy „fail-open” alapértelmezett beállítás egy első féltől származó útvonalon.

Kutatási eredmények és megoldások

Egyedi RAG-folyamatok, amelyek teljesen megkerülik az Azure AI Search-t, továbbra is egy széles körűen jogosult szolgáltatásfiók alatt indexelnek, lekérdezéskor jogosultságellenőrzés nélkül, hacsak a fejlesztő nem épít be egyet. Cioffi telepítése az egyedi folyamat útját követte. A gyártásban lévő ügynökök skálázott használata során a sikeres támadások 91%-a csendes adatexfiltrációval végződött — közölte a Straiker STAR Labs Threat Reportja.

A Straiker vörös csapata több mint 1700 sikeres exploit-kísérletet futtatott gyártásban lévő ügynökök ellen. A 91%-os arány az összes sikeres támadást méri, amelyek észrevétlen adatexfiltrációval végződtek. A jelentés szerint ehhez nem volt szükség malware-re, és nem történt laterális mozgás a hálózaton. Az ügynök minden elérhető adatot visszaadott. A jelentés nem bontja ki, hogy ezek a sikerek pontosan jogosultsági hibákból, prompt injectionből, eszközökkel való visszaélésből vagy más támadási osztályokból eredtek-e.

Független kutatásában az Egyesült Királyság AI Biztonsági Intézete 19 nem engedélyezett ügynök-műveletet dokumentált egy július 25-28 közötti értékelés során. A jelentés azt demonstrálja, hogy az ügynökök a szándékolton kívül cselekedtek egy engedékeny tesztkörnyezetben, megbízható mechanizmus nélkül a deviációk észlelésére. Ez egy elkerülési hiba, nem pedig lekérdezési jogosultsági hiba, de a megosztott hiányosság a futásidejű ellenőrzés hiánya.

Az értékelések, amelyeket Cioffi csapata futtatott, arra irányultak, hogy az ügynök helyesen válaszol-e. Ellenőrizték a ténybeli pontosságot, a relevanciát és a feladat elvégzését. Nem vizsgálták, hogy a lekérdezési folyamat ki engedélyeit használja a forrásanyag lekéréséhez, mert ez a kérdés nem szerepel az értékelési keretrendszerben.

Az Azure AI Search jelenleg platformszinten végzi el a lekérdezési jogosultság-ellenőrzést. A lekérdezéskori ACL-szűrés érvényesíti a hívó Entra tokenjét, kinyeri a felhasználói és csoporti jogcímeket, és csak azokat a dokumentumokat adja vissza, amelyekhez a szinkronizált engedély-metaadatok hozzáférést biztosítanak.

Cioffi javítása nem igényelt új identitásplatformot. A jogosultság-döntést maga a lekérdezési folyamatba helyezte, egy lekérdezési útvonalszűrőt adva hozzá, amely ellenőrzi a kérdező felhasználó SharePoint-jogosultságait, mielőtt a modell feldolgozná az adatokat. A szűrő lekérdezéskor fut, nem indexeléskor.

Az a tartalom, amelyet a felhasználó nem tudott megnyitni a SharePointban, nem kerül be a modell kontextusablakába. Az ellenőrzés szűkítette, hogy az asszisztens mihez férhet hozzá. Az asszisztens a szűrő aktív állapotában is nagyjából az érkező e-mailek 60%-át oldja meg — közölte Cioffi. Azt azonban nem közölte, hogy ez az arány mennyi volt a szűrő előtt.

Adriel Desautels, a Netragard alapítója szerint a hiba az engedélyezési határok szerkezeti összeomlása. „Ha az NHI hitelesítő adatok általában széles körű engedélyekkel rendelkeznek, és magas jogosultságú adatokat tudnak olvasni, akkor azokat az indexükben tárolják” — írta Desautels. „Ha egy alkalmazás nem érvényesíti az identitás-tudatos lekérdezést, akkor egy „normál” felhasználó alacsonyabb jogosultságokkal lekérdezheti az alkalmazást, és hozzáférhet az egyébként korlátozott adatokhoz. Ez az engedélyezési határokat a legalacsonyabb jogosultsági szintre csökkenti a keresési képességgel.”