Dobički:
- Možnost ločevanja avtentikacije in avtorizacije ter uporabe minimalne avtorizacije z RBAC/ABAC
- Zmožnost izogibanja mešanemu tveganju posrednika z izvajanjem modela v uporabniškem kontekstu
- Sposobnost shranjevanja in rotiranja ključev API s sistemom tajnega upravljanja
Pomemben del napadov na sistem AI se ne začne z "pretentanjem" modela, ampak z ukradenim ključem API ali prekomerno pooblaščenim računom. Ta plast varnosti izvira iz klasične varnosti informacij, vendar dodaja nova tveganja v kontekstu AI: model pokliče vožnjo v imenu nekoga drugega, račun storitve dostopa do vseh podatkov, ključ uhaja v GitHub. V tej enoti se bomo naučili, kako zožiti dostop do sistema AI z avtentikacijo, avtorizacijo (RBAC/ABAC), minimalno avtorizacijo in tajnim upravljanjem.
Razlika med avtentikacijo in avtorizacijo
Oba izraza se pogosto zamenjujeta:
- Preverjanje pristnosti: "Kdo si?" — dokazovanje, da je uporabnik/storitev res tisti, za katerega se predstavlja (geslo, žeton, potrdilo, MFA).
- Pooblastilo: "Kaj lahko storite?" — določite, do katerega vira/dejanja lahko dostopa overjena stranka.
Kritična subtilnost v sistemih AI je naslednja: ko model opravlja delo v imenu uporabnika, ali deluje s pooblastilom tega uporabnika ali s širokim računom storitve? Slednje je nevarno — ker model, ki ga je vbrizgavanje pretentalo, pridobi popoln dostop do storitvenega računa.
Pozor: Težava »zmedenega namestnika«: uporabnik z nizkimi pooblastili posredno dostopa do podatkov, do katerih ne more dostopati, tako da odda model z visokimi pooblastili zunanjemu izvajalcu. Model bi moral vedno delovati v kontekstu avtoritete uporabnika, ne njegove lastne široke avtoritete.
RBAC in ABAC
- RBAC (nadzor dostopa na podlagi vlog): dostop je odvisen od vloge uporabnika. Vloga "strokovnjak za podporo" lahko bere opombe strank, ne more pa jih izbrisati. Enostavno in običajno.
- ABAC (Attribute-Based Access Control): Dostop je odvisen od atributov: uporabnikov oddelek, oznaka zasebnosti podatkov, čas v dnevu, omrežje, iz katerega prihaja zahteva. Bolj natančna, a bolj zapletena.
Večina organizacij začne z RBAC in se poglobi v ABAC za občutljive podatke. Osnovno pravilo za AI: model mora filtrirati vsakega agenta, ki ga pokliče, in vse podatke, do katerih dostopa, glede na vlogo/atribute uporabnika, ki poda zahtevo.
Korak za korakom: Izvajanje minimalnih pooblastil
- Naredi inventar. Katera orodja kliče model, do katerih podatkov dostopa? Naštej jih vse.
- Vsak dostop utemeljite. »Ali ta pomočnik res potrebuje pooblastilo za brisanje?« V nasprotnem primeru ga odstranite.
- Privzeto samo za branje. Model bi moral imeti privzeto možnost branja; Zahtevaj ločen žeton ozkega obsega za pisanje/brisanje.
- Premakni uporabniški kontekst. Pokličite vozilo s pooblastilom uporabnika, ne s servisnim računom.
- Kratkotrajna poverilnica. Namesto dolgoživih ključev uporabite kratkotrajne žetone, ki se samodejno obnavljajo.
Skrivno upravljanje
Skrivnost so poverilnice, ki morajo ostati tajne, na primer ključ API, geslo, žeton ali potrdilo. Najpogostejša nesreča v projektih AI je, ko je ključ API ponudnika modela vdelan v kodo in uhaja v nadzor različic (Git).
Pravilna uporaba:
- Nikoli ne vdelajte ključev v kodo; Uporabite spremenljivko okolja ali sistem tajnega upravljanja (storitev, ki shranjuje šifrirane ključe in nadzoruje dostop).
- Rotacija: ključe obnavljajte v rednih intervalih (npr. vsakih 90 dni); Če sumite na puščanje, takoj prekličite.
- Zmanjšanje obsega: Vsako stikalo ima samo zahtevano storitev in zahtevano avtorizacijo.
- Revizija: zabeležite, kdo je uporabil ključ, kdaj in kje.
Štiri kopirane predloge
Poziv za nadzor dostopa do pregleda:
Za vsako orodje na spodnjem seznamu orodij ocenite: - Ali je to orodje OBVEZNO za opravljanje nalog tega pomočnika? (da/ne) - Je samo za branje ali pisanje/brisanje? – Ali se to orodje kliče z uporabniškim pooblastilom ali računom storitve? Označite nepotrebne ali preveč avtorizirane kot "ODSTRANI/REDIGIRAJ".<tools>{{ tool_list }}</tools>
Poziv za skeniranje skrivnega uhajanja:
V tem izrezku kode poiščite vse, kar bi lahko bilo trdo kodirana skrivnost: ključ API, geslo, žeton, povezovalni niz, zasebni ključ. Navedite vrstico in tip za vsako. KOPIRAJ vrednost v odgovor;maska (prvi 4 znaki + ***).<code>{{ source }}</code>
Odločitveno pravilo najmanjše avtoritete:
Ko prispe novo orodje/zahteva za dostop, vprašajte:1. Ali je nalogo mogoče izvesti brez tega dostopa? -> Če da: ZAVRNI2. Je dovolj samo za branje? -> Če da: DODELITE dovoljenje za pisanje3. Ali je mogoče obseg zožiti na en sam vir? -> Če da: daratPrivzeti odgovor je "ne"; Dostop se pridobi z razumom.
Opomnik za rotacijski koledar:
Za vsako skrivnost zabeležite: lastnika, datum nastanka, potek, obseg. Prijavite kateri koli ključ, ki je presegel 90 dni ali ni bil uporabljen 30 dni, kot "KANDIDAT ZA ROTACIJO/PREKLIC".
Šibek poziv / močan poziv
slab pristop
Močan pristop
Model dostopa do vseh podatkov z enim računom storitve
Model dostopa s pooblastilom uporabnika, ki poda zahtevo
Ključ API je vdelan v kodo in se nikoli ne spremeni
Rotacija v upravitelju ključnih skrivnosti, 90 dni
Široko pooblastilo "naredi karkoli" pomočniku
Privzeto samo za branje, pišite ozko
Dostopi niso nikoli pregledani
Redni pregled dostopa in preklic
Trije mini kovčki
1. primer – uhajanje mešanih podatkov posrednika. Notranji pomočnik je delal s servisnim računom, ki je imel dostop do vseh evidenc zaposlenih. Uporabnik pripravnik je dostopal do podatkov, ki jih običajno ne bi videl, tako da je rekel "povzeti tabelo plač vodilnih"; ker ga je model spraševal v kontekstu lastne široke avtoritete, ne uporabnikove. Ko je bil uporabniški kontekst prilagojen za premikanje, je pripravnik lahko posnel posnetke, ki jih je lahko videl samo on.
Primer 2 – ključ, ki je ušel, račun za 190.000 TL v 2 tednih. Razvijalec je ključ API modela vdelal v pomožni skript in ga potisnil v javno skladišče. Bot je našel ključ v 40 minutah in ga uporabljal dva tedna; Račun je dosegel 190.000 TL. Ko je bil ključ premaknjen v tajnega upravitelja, povezan z rotacijo in dodano skeniranje repozitorija, se incident ni ponovil.
Primer 3 — Privzeto preprečena prekinitev samo za branje. Pomočnik DevOps je prejel ukaz "ponastavi produkcijsko bazo podatkov" prek hitrega vbrizgavanja. Vendar pa je pomočnik dobil le žeton samo za branje; pisanje/brisanje je bilo v ločenem odobrenem toku. Ukaz je bil zavrnjen z avtorizacijsko napako in dogodek je bil zabeležen kot alarm; Izgube podatkov ni bilo.
Nasvet: Nastavite "ne" kot privzeti odgovor na novo zahtevo za dostop. Dostop je nekaj, kar se pridobi z utemeljitvijo; Skoraj nikoli se ne naredi, da bi vsem dali široko in nato zmanjšali, tveganje pa se kopiči.
Pogoste napake
- Izvajanje modela z velikim storitvenim računom in izguba uporabniškega konteksta (mešani proxy).
- Vdelava ključa API v kodo in njegovo uhajanje v nadzor različic.
- Sploh ne vrti tipk ("deluje, ne dotikaj se").
- Pomočniku privzeto dodelite dovoljenja za pisanje/brisanje.
- Enkratna odobritev dostopa in nikoli več o tem.
- Mešanje avtentikacije z avtorizacijo in domneva, da "je prijavljen, lahko dostopa do vsega".
Če povzamem
- Avtentikacija je vprašanje "kdo si", avtorizacija je vprašanje "kaj lahko narediš"; V AI morata oba delovati v kontekstu uporabnika.
- Model bi moral delovati s pooblastilom uporabnika, ki vloži zahtevo, ne s svojim širokim pooblastilom (izogibanje tveganju mešane agencije).
- Začnite z RBAC, poglobite z ABAC na občutljivih podatkih; Nastavite minimalno pooblastilo za privzeto.
- Ne zakopajte skrivnosti v kodo; shranite v skrivnem upravitelju, zožite in postavite v redno kroženje.
- Privzeta nastavitev samo za branje in ozko pisanje močno omejujeta učinek vbrizgavanja.
Aplikacijska naloga
Navedite vsa orodja in podatke, do katerih dostopa vaš pomočnik AI. Za vsako odgovorite na tri vprašanja: (1) Ali je res potrebno? (2) Je dovolj samo za branje? (3) Ali deluje v uporabniškem kontekstu? Nato poiščite vse trdo kodirane skrivnosti (prek zgornjega poziva za skeniranje) in napišite načrt rotacije za vsak ključ, ki ga najdete. Odstranite vsaj eno nepotrebno avtorizacijo.
kontrolni seznam
- [ ] Model se izvaja v pooblastilnem kontekstu uporabnika, ki poda zahtevo.
- [ ] Dostop do orodij in podatkov je zožen na načelo najmanjših privilegijev.
- [ ] Pisanje/brisanje je ločeno od samo za branje, overjeno in ozko.
- [ ] V kodi niso zakopane nobene skrivnosti; Hrani se v tajnem upravitelju.
- [ ] Obstaja urnik menjave in postopek preklica za ključe.
- [ ] Dostopi se redno pregledujejo.