Câștiguri:
- Abilitatea de a separa autentificarea și autorizarea și de a aplica autorizarea minimă cu RBAC/ABAC
- Abilitatea de a evita riscul mixt de proxy prin rularea modelului în contextul utilizatorului
- Abilitatea de a stoca și roti cheile API cu sistemul de management secret
O parte semnificativă a atacurilor asupra unui sistem AI nu începe cu „păcălirea” modelului, ci cu o cheie API furată sau un cont supraautorizat. Acest nivel de securitate provine din securitatea clasică a informațiilor, dar adaugă noi riscuri în contextul AI: un model apelează la o plimbare în numele altcuiva, un cont de serviciu accesează toate datele, o scurgere cheie la GitHub. În această unitate, vom învăța cum să restrângem accesul la sistemul AI cu autentificare, autorizare (RBAC/ABAC), autorizare minimă și management secret.
Diferența dintre autentificare și autorizare
Cei doi termeni sunt adesea confundați:
- Autentificare: „Cine ești?” — demonstrarea faptului că utilizatorul/serviciul este cu adevărat cine pretinde a fi (parolă, simbol, certificat, MFA).
- Autorizare: „Ce poți face?” — determinați ce resursă/acțiune poate accesa partea autentificată.
Subtilitatea critică în sistemele AI este următoarea: atunci când modelul lucrează în numele unui utilizator, funcționează cu autoritatea utilizatorului respectiv sau cu un cont de serviciu larg? Acesta din urmă este periculos — deoarece modelul păcălit de injecție obține acces deplin la contul de serviciu.
Atenție: problemă „adjunct confuz”: un utilizator cu autoritate scăzută accesează indirect date pe care nu le poate accesa prin externalizarea unui model cu autoritate ridicată. Modelul ar trebui să funcționeze întotdeauna în contextul autorității utilizatorului, nu al propriei sale autorități generale.
RBAC și ABAC
- RBAC (Role-Based Access Control): Accesul depinde de rolul utilizatorului. Rolul „specialist asistență” poate citi notele clienților, dar nu le poate șterge. Simplu și comun.
- ABAC (Attribute-Based Access Control): Accesul depinde de atribute: departamentul utilizatorului, eticheta de confidențialitate a datelor, ora din zi, rețeaua din care provine solicitarea. Mai bine reglat, dar mai complex.
Majoritatea organizațiilor încep cu RBAC și aprofundează la ABAC pentru date sensibile. Regula generală pentru AI: modelul ar trebui să filtreze fiecare agent pe care îl apelează și toate datele pe care le accesează în funcție de rolul/atributele utilizatorului care face cererea.
Pas cu pas: exercitarea autorității minime
- Faceți inventarul. Ce instrumente apelează modelul, ce date accesează? Enumeră-le pe toate.
- Justificați fiecare acces. „Acest asistent chiar are nevoie de autorizare de ștergere?” În caz contrar, îndepărtați-l.
- Implicit numai pentru citire. Modelul ar trebui să poată citi în mod implicit; Necesită scrierea/ștergerea unui simbol separat, cu domeniu îngust.
- Mutați contextul utilizatorului. Apelați vehiculul cu autoritatea utilizatorului, nu cu contul de service.
- Acreditare de scurtă durată. Folosiți jetoane de scurtă durată, cu reînnoire automată, în loc de chei cu durată lungă de viață.
Management secret
Un secret este acreditările care trebuie să rămână secrete, cum ar fi o cheie API, o parolă, un simbol sau un certificat. Cel mai frecvent accident în proiectele AI este atunci când cheia API a furnizorului de model este încorporată în cod și se scurge în controlul versiunii (Git).
Aplicare corecta:
- Nu încorporați niciodată cheile în cod; Utilizați o variabilă de mediu sau un sistem de management secret (un serviciu care stochează cheile criptate și controlează accesul).
- Rotire: reînnoiți cheile la intervale regulate (de exemplu, la fiecare 90 de zile); Dacă se suspectează o scurgere, anulați imediat.
- Reducerea domeniului de aplicare: Fiecare comutator are doar serviciul necesar și autorizația necesară.
- Audit: Înregistrați cine a folosit cheia, când și unde.
Patru șabloane copiabile
Solicitare de control al examinării accesului:
Pentru fiecare unealtă din lista de instrumente de mai jos, evaluați:- Este NECESAR acest instrument pentru a îndeplini munca acestui asistent? (da/nu) - Este doar citire sau scrie/sterge? - Acest instrument este apelat cu autoritatea sau contul de serviciu al utilizatorului? Marcați-le pe cele inutile sau excesiv de autorizate ca „ELIMINARE/REDACTARE”.<tools>{{ tool_list }}</tools>
Prompt de scanare secretă a scurgerilor:
Găsiți orice ar putea fi un secret codificat în următorul fragment de cod: cheie API, parolă, indicativ, șir de conexiune, cheie privată. Dați rând și tip pentru fiecare. COPIEAZĂ valoarea în răspuns;mască (primele 4 caractere + ***).<cod>{{ sursă }}</code>
Regula de decizie cu cea mai mică autoritate:
Când sosește un nou instrument/cerere de acces, întrebați:1. Sarcina poate fi efectuată fără acest acces? -> Dacă da: RESPING2. Este suficient doar citirea? -> Dacă da: Acordați permisiunea de scriere3. Se poate restrânge domeniul de aplicare la o singură sursă? -> Dacă da: darat Răspunsul implicit este „nu”; Accesul se obține prin rațiune.
Memento calendar de rotație:
Pentru fiecare secret, înregistrați: proprietar, data creării, expirare, domeniul de aplicare. Raportați orice cheie care a depășit 90 de zile sau nu a fost folosită timp de 30 de zile ca „CANDIDAT DE ROTARE/ANULARE”.
Solicitare slabă / Solicitare puternică
abordare slabă
Abordare puternică
Modelul accesează toate datele cu un singur cont de serviciu
Modelul accesează cu autoritatea utilizatorului care face cererea
Cheia API este încorporată în cod, nu se modifică niciodată
Rotație în key secret manager, 90 de zile
Autoritate largă de „a face orice” pentru asistent
Implicit numai pentru citire, scrieți restrâns
Accesurile nu sunt niciodată revizuite
Revizuirea și revocarea regulată a accesului
Trei mini carcase
Cazul 1 – Scurgere de date proxy mixte. Un asistent intern lucra cu un cont de serviciu care avea acces la toate evidențele angajaților. Un utilizator stagiar a accesat date pe care în mod normal nu le-ar vedea spunând „rezumați tabelul de salarii ale executivului”; deoarece modelul l-a pus sub semnul întrebării în contextul propriei sale autorităţi largi, nu al utilizatorului. Odată ce contextul utilizatorului a fost ajustat pentru a fi mutat, stagiarul a putut extrage înregistrări pe care doar el sau ea le putea vedea.
Cazul 2 – Cheie scursă, factură de 190.000 TL în 2 săptămâni. Un dezvoltator a încorporat cheia API model într-un script de ajutor și a trimis-o într-un depozit public. Un bot a găsit cheia în 40 de minute și a folosit-o timp de două săptămâni; Factura a ajuns la 190.000 TL. Când cheia a fost mutată în managerul secret, conectată la rotație și a fost adăugată scanarea depozitului, incidentul nu s-a mai repetat.
Cazul 3 — Întreruperea prevenită implicită numai pentru citire. Un asistent DevOps a primit o comandă „resetează baza de date de producție” prin injectare promptă. Cu toate acestea, asistentului i s-a dat doar un simbol numai pentru citire; scrierea/stergerea a fost într-un flux separat aprobat. Comanda a fost respinsă cu eroare de autorizare și evenimentul a fost înregistrat ca alarmă; Nu a existat nicio pierdere de date.
Sfat: faceți „nu” răspunsul implicit la o nouă solicitare de acces. Accesul este ceva câștigat prin justificare; A oferi tuturor lat și apoi tăierea nu se face aproape niciodată și riscul se acumulează.
Greșeli comune
- Rularea modelului cu un cont de serviciu mare și pierderea contextului utilizatorului (proxy mixt).
- Încorporarea cheii API în cod și scurgerea acesteia în controlul versiunilor.
- Nu rotiți deloc tastele ("funcționează, nu atingeți").
- Acordarea implicită a permisiunilor de scriere/ștergere asistentului.
- Acordarea accesului o singură dată și niciodată reconsiderarea acestuia.
- Confundând autentificarea cu autorizarea și presupunând că „s-a autentificat, poate accesa totul”.
Pe scurt
- Autentificarea este o chestiune de „cine ești tu”, autorizarea este o chestiune de „ce poți face”; În AI, ambele trebuie să funcționeze în contextul utilizatorului.
- Modelul ar trebui să funcționeze cu autoritatea utilizatorului care face cererea, nu cu propria sa autoritate largă (evitând riscul unei agenții mixte).
- Începeți cu RBAC, aprofundați cu ABAC asupra datelor sensibile; Setați autoritatea minimă ca implicită.
- Nu îngropa secretele în cod; depozitați-l în managerul secret, restrângeți-l și puneți-l în rotație regulată.
- Valoarea implicită numai pentru citire și scrierea îngustă limitează foarte mult impactul injecției.
Sarcina de aplicare
Enumerați toate instrumentele și datele pe care le accesează asistentul dvs. AI. Răspunde la trei întrebări pentru fiecare: (1) Este cu adevărat necesar? (2) Este suficient doar citirea? (3) Se rulează în contextul utilizatorului? Apoi căutați toate secretele codificate (prin intermediul promptului de scanare de mai sus) și scrieți un plan de rotație pentru fiecare cheie pe care o găsiți. Eliminați cel puțin o autorizație inutilă.
lista de verificare
- [ ] Modelul rulează în contextul de autoritate al utilizatorului care face cererea.
- [ ] Accesul la instrumente și date a fost restrâns la principiul cel mai mic privilegiu.
- [ ] Scrierea/ștergerea este separată de numai citire, autentificată și restrânsă.
- [ ] Niciun secret nu este îngropat în cod; Este păstrat în managerul secret.
- [ ] Există un program de rotație și o procedură de anulare pentru chei.
- [ ] Accesurile sunt revizuite în mod regulat.