Nyereség:
- Lehetőség a hitelesítés és az engedélyezés szétválasztására, valamint az RBAC/ABAC minimális engedélyezésének alkalmazására
- Képes elkerülni a vegyes proxykockázatot a modell felhasználói környezetben való futtatásával
- Képes API-kulcsok tárolására és forgatására a titkos felügyeleti rendszerrel
Az AI-rendszerek elleni támadások jelentős része nem a modell „becsapásával”, hanem egy ellopott API-kulccsal vagy egy túlengedélyezett fiókkal kezdődik. Ez a biztonsági réteg a klasszikus információbiztonságból származik, de a mesterséges intelligencia kontextusában új kockázatokkal jár: a modell valaki más nevében hív le egy fuvart, egy szolgáltatási fiók hozzáfér az összes adathoz, a kulcs pedig kiszivárog a GitHubba. Ebben a részben megtanuljuk, hogyan szűkítsük le az AI-rendszerhez való hozzáférést hitelesítéssel, engedélyezéssel (RBAC/ABAC), minimális jogosultsággal és titkos kezeléssel.
Különbség a hitelesítés és az engedélyezés között
A két kifejezést gyakran összekeverik:
- Hitelesítés: "Ki vagy?" — annak bizonyítása, hogy a felhasználó/szolgáltatás valóban az, akinek vallják magukat (jelszó, token, tanúsítvány, MFA).
- Engedélyezés: "Mit tehetsz?" — meghatározza, hogy a hitelesített fél mely erőforráshoz/művelethez férhet hozzá.
A mesterséges intelligencia rendszerek kritikus finomsága a következő: amikor a modell egy felhasználó nevében végez munkát, akkor az adott felhasználó jogosultságával vagy széles körű szolgáltatási fiókkal működik? Ez utóbbi veszélyes – mert a befecskendezéssel átvert modell teljes hozzáférést kap a szolgáltatási fiókhoz.
Vigyázat: "Zavart helyettes" probléma: egy alacsony jogosultságú felhasználó közvetetten olyan adatokhoz fér hozzá, amelyekhez nem férhet hozzá egy magas hatósági modell kiszervezésével. A modellnek mindig a felhasználó jogosultságai keretein belül kell működnie, nem pedig a saját széles jogkörében.
RBAC és ABAC
- RBAC (szerepalapú hozzáférés-vezérlés): A hozzáférés a felhasználó szerepkörétől függ. A „támogatási szakértő” szerepkör elolvashatja az ügyfelek megjegyzéseit, de nem törölheti azokat. Egyszerű és általános.
- ABAC (Attribute-Based Access Control): A hozzáférés attribútumoktól függ: a felhasználó részlegétől, az adatok adatvédelmi címkéjétől, a napszaktól, a hálózattól, ahonnan a kérés érkezik. Finomabb, de összetettebb.
A legtöbb szervezet az RBAC-ból indul ki, és az érzékeny adatok esetében az ABAC-ra mélyül. A mesterséges intelligencia alapszabálya: a modellnek szűrnie kell minden általa meghívott ügynököt és minden hozzáfért adatot a kérelmet benyújtó felhasználó szerepe/attribútumai alapján.
Lépésről lépésre: Minimális tekintély gyakorlása
- Készítsen leltárt. Milyen eszközöket hív meg a modell, milyen adatokhoz fér hozzá? Sorolja fel őket.
- Minden hozzáférést indokoljon. "Valóban törlési jogosultságra van szüksége ennek az asszisztensnek?" Ellenkező esetben távolítsa el.
- Csak olvasható alapértelmezett. A modellnek alapértelmezés szerint képesnek kell lennie olvasni; Külön, szűk hatókörű token írása/törlése szükséges.
- Felhasználói kontextus áthelyezése. A járművet a felhasználó jogosultságával hívja, nem a szervizfiókkal.
- Rövid életű igazolvány. Használjon rövid élettartamú, automatikusan megújuló tokeneket a hosszú élettartamú kulcsok helyett.
Titkos Menedzsment
A titok olyan hitelesítő adatok, amelyeknek titkosnak kell maradniuk, például API-kulcs, jelszó, token vagy tanúsítvány. Az AI-projektekben a leggyakoribb baleset az, amikor a modellszolgáltató API-kulcsa beágyazódik a kódba, és kiszivárog a verziókezelésbe (Git).
Helyes alkalmazás:
- Soha ne ágyazzon be kulcsokat a kódba; Használjon környezeti változót vagy titkos felügyeleti rendszert (olyan szolgáltatás, amely titkosítva tárolja a kulcsokat és szabályozza a hozzáférést).
- Forgatás: Rendszeres időközönként (például 90 naponta) cserélje ki a kulcsokat; Ha szivárgás gyanúja merül fel, azonnal törölje.
- Hatáskör csökkentése: Minden kapcsolónak csak a szükséges szolgáltatása és jogosultsága van.
- Audit: naplózza, hogy ki, mikor és hol használta a kulcsot.
Négy másolható sablon
Hozzáférés-ellenőrzési parancssor:
Az alábbi eszközlistában szereplő minden egyes eszköznél értékelje:- SZÜKSÉGES ez az eszköz az asszisztensi feladat elvégzéséhez? (igen/nem) - Csak olvasható vagy írható/törölhető? - Ezt az eszközt a felhasználó jogosultságával vagy szolgáltatási fiókjával hívják meg? A szükségtelen vagy túlzottan engedélyezett elemeket jelölje meg "ELVÁGÍTÁS/TÖRLÉS"-ként.<tools>{{ tool_list }}</tools>
Titkos szivárgásvizsgálati üzenet:
Keressen bármit, ami kemény kódolt titok lehet a következő kódrészletben: API-kulcs, jelszó, token, kapcsolati karakterlánc, privát kulcs. Mindegyikhez adjon sort és típust. COPY értéket válaszba;maszk (első 4 karakter + ***).<code>{{ forrás }}</code>
Legkisebb hatósági döntés szabálya:
Amikor új eszköz/hozzáférési kérelem érkezik, kérdezze meg:1. Elvégezhető a feladat e hozzáférés nélkül? -> Ha igen: ELUTASÍTÁS2. Elég a csak olvasható? -> Ha igen: GRANT írási engedélyt3. Leszűkíthető-e a hatókör egyetlen forrásra? -> Ha igen: daratAz alapértelmezett válasz "nem"; A hozzáférést az ész éri.
Forgatási naptár emlékeztető:
Minden titokhoz rögzítse: tulajdonos, létrehozás dátuma, lejárata, hatálya. Jelenítsen minden olyan kulcsot, amely túllépte a 90 napot, vagy 30 napig nem használta, mint "FORGATÁS/TÖRLÉS JELÖLT".
Gyenge felszólítás / Erős felszólítás
rossz megközelítés
Erős megközelítés
A modell egyetlen szolgáltatásfiókkal éri el az összes adatot
A modell a kérést benyújtó felhasználó jogosultságával fér hozzá
Az API kulcs be van ágyazva a kódba, soha nem változik
Rotáció a kulcstitokkezelőben, 90 nap
Az asszisztens számára széleskörű „tegyen bármit” jogkör
Csak olvasható alapértelmezett, szűken írható
A hozzáféréseket soha nem vizsgálják felül
Rendszeres hozzáférés felülvizsgálata és visszavonása
Három mini tok
1. eset – Kiszivárgott vegyes proxyadatok. Egy házon belüli asszisztens olyan szolgáltatási fiókkal dolgozott, amely hozzáfért az összes alkalmazotti nyilvántartáshoz. Egy gyakornok olyan adatokhoz férhetett hozzá, amelyeket általában nem látna, amikor azt mondta, hogy "összefoglalja a vezetői fizetési táblázatot"; mert a modell a saját széles tekintélyének kontextusában kérdőjelezte meg, nem a felhasználóéban. Miután a felhasználói környezetet áthelyezték, a gyakornok olyan felvételeket tudott levonni, amelyeket csak ő láthatott.
2. eset – Kiszivárgott kulcs, 190 000 TL számla 2 hét alatt. Egy fejlesztő beágyazta a modell API-kulcsot egy segédszkriptbe, és egy nyilvános adattárba küldte. Egy bot 40 perc alatt megtalálta a kulcsot, és két hétig használta; A számla elérte a 190 000 TL-t. Amikor a kulcsot áthelyezték a titkos kezelőbe, összekapcsolták a forgatással, és hozzáadták a lerakatvizsgálatot, az incidens nem ismétlődött meg.
3. eset – Csak olvasható, alapértelmezett, megakadályozott megszakítás. Egy DevOps-asszisztens "gyári adatbázis visszaállítása" parancsot kapott azonnali befecskendezéssel. Az asszisztens azonban csak olvasható tokent kapott; az írás/törlés külön jóváhagyott folyamatban volt. A parancsot engedélyezési hibával utasították el, és az eseményt riasztásként naplózták; Nem volt adatvesztés.
Tipp: Legyen „nem” az alapértelmezett válasz egy új hozzáférési kérelemre. A hozzáférés az indokláson keresztül nyert dolog; Szinte soha nem történik meg az, hogy mindenkinek széleset adunk, majd visszavágunk, és a kockázat felhalmozódik.
Gyakori hibák
- A modell futtatása nagy szolgáltatásfiókkal és a felhasználói kontextus elvesztése (vegyes proxy).
- Az API kulcs beágyazása a kódba és kiszivárogtatása a verzióvezérlésbe.
- Egyáltalán nem forgatja a billentyűket ("működik, ne érintse").
- Alapértelmezés szerint írási/törlési engedélyek megadása az asszisztensnek.
- Egyszer megadja a hozzáférést, és soha nem gondolja újra.
- A hitelesítést összetéveszti az engedélyezéssel, és feltételezi, hogy "be van jelentkezve, mindenhez hozzáfér".
Összefoglalva
- A hitelesítés a „ki vagy te”, a felhatalmazás a „mit tehetsz” kérdése; Az AI-ban mindkettőnek a felhasználó kontextusában kell működnie.
- A modellnek a kérelmező felhasználó jogosultságával kell működnie, nem pedig a saját széles jogkörével (elkerülve a vegyes ügynökség kockázatát).
- Kezdje az RBAC-val, mélyítse el az ABAC-cal az érzékeny adatokon; Minimális jogosultság legyen az alapértelmezett.
- Ne temesse el a titkokat a kódban; tárolja a titkos menedzserben, szűkítse le és helyezze rendszeres forgatásba.
- A csak olvasható alapértelmezett és szűk írás nagyban korlátozza az injekció hatását.
Pályázati feladat
Sorolja fel az összes eszközt és adatot, amelyhez az AI-asszisztens hozzáfér. Mindegyikhez válaszoljon három kérdésre: (1) Valóban szükséges? (2) Elég a csak olvasható? (3) Felhasználói környezetben fut? Ezután keresse meg az összes keményen kódolt titkot (a fenti szkennelési prompt segítségével), és írjon egy forgatási tervet minden megtalált kulcshoz. Távolítson el legalább egy szükségtelen engedélyt.
ellenőrző lista
- [ ] A modell a kérést benyújtó felhasználó jogosultsági kontextusában fut.
- [ ] Az eszköz- és adathozzáférés a legkisebb jogosultság elvére szűkült.
- [ ] Az írás/törlés elkülönül a csak olvashatótól, hitelesített és szűk.
- [ ] A kódexben nincsenek eltemetve titkok; A titkos menedzserben őrzik.
- [ ] A kulcsokhoz rotációs ütemezés és törlési eljárás tartozik.
- [ ] A hozzáféréseket rendszeresen felülvizsgálják.