Dobici:
- Mogućnost razdvajanja autentifikacije i autorizacije i primjene minimalne autorizacije sa RBAC/ABAC
- Sposobnost izbjegavanja miješanog proxy rizika pokretanjem modela u korisničkom kontekstu
- Mogućnost pohranjivanja i rotiranja API ključeva uz tajni sistem upravljanja
Značajan dio napada na AI sistem ne počinje “prevarivanjem” modela, već ukradenim API ključem ili prekomjerno ovlaštenim računom. Ovaj sloj sigurnosti dolazi od klasične informacione sigurnosti, ali dodaje nove rizike u kontekstu AI: model poziva vožnju u tuđe ime, servisni nalog pristupa svim podacima, ključ curi na GitHub. U ovoj cjelini naučit ćemo kako suziti pristup AI sistemu uz autentifikaciju, autorizaciju (RBAC/ABAC), minimalnu autorizaciju i tajno upravljanje.
Razlika između autentifikacije i autorizacije
Ova dva pojma se često brkaju:
- Autentifikacija: "Ko si ti?" — dokazivanje da je korisnik/usluga zaista ono za šta se predstavlja (lozinka, token, sertifikat, MFA).
- Ovlaštenje: "Šta možete učiniti?" — odrediti kojem resursu/radnji autentificirana strana može pristupiti.
Kritična suptilnost u sistemima veštačke inteligencije je sledeća: kada model obavlja posao u ime korisnika, da li radi sa autoritetom tog korisnika ili sa širokim nalogom usluge? Ovo posljednje je opasno — jer model koji je prevaren injekcijom dobija potpuni pristup servisnom računu.
Oprez: problem "zbunjenog zamjenika": korisnik s niskim ovlaštenjima indirektno pristupa podacima kojima ne može pristupiti korištenjem modela s visokim ovlaštenjima. Model bi uvijek trebao funkcionirati u kontekstu ovlaštenja korisnika, a ne njegovih vlastitih širokih ovlaštenja.
RBAC i ABAC
- RBAC (Kontrola pristupa zasnovana na ulozi): Pristup zavisi od uloge korisnika. Uloga "specijalista za podršku" može čitati bilješke korisnika, ali ih ne može izbrisati. Jednostavno i uobičajeno.
- ABAC (Kontrola pristupa zasnovana na atributima): Pristup zavisi od atributa: odeljenje korisnika, oznaka privatnosti podataka, doba dana, mreža iz koje dolazi zahtev. Finije podešeno, ali složenije.
Većina organizacija počinje s RBAC-om i produbljuje se na ABAC za osjetljive podatke. Pravilo za AI: model treba da filtrira svakog agenta kojeg pozove i sve podatke kojima pristupi na osnovu uloge/atributa korisnika koji postavlja zahtjev.
Korak po korak: Primjena minimalnih ovlaštenja
- Uradite inventar. Koje alate model naziva, kojim podacima pristupa? Navedite ih sve.
- Opravdajte svaki pristup. "Da li ovom pomoćniku zaista treba ovlaštenje za brisanje?" U suprotnom, uklonite ga.
- Zadana vrijednost samo za čitanje. Model bi trebao biti u mogućnosti čitati po defaultu; Zahtijeva odvojeni token za pisanje/brisanje uskog opsega.
- Premjestite korisnički kontekst. Pozovite vozilo s ovlaštenjem korisnika, a ne sa servisnim računom.
- Kratkotrajna akreditiva. Koristite kratkotrajne tokene koji se automatski obnavljaju umjesto dugotrajnih ključeva.
Tajno upravljanje
Tajna su vjerodajnice koje moraju ostati tajne, kao što su API ključ, lozinka, token ili certifikat. Najčešća nesreća u AI projektima je kada je API ključ dobavljača modela ugrađen u kod i procuri u kontrolu verzija (Git).
Ispravna primjena:
- Nikada nemojte ugrađivati ključeve u kod; Koristite varijablu okruženja ili tajni sistem upravljanja (usluga koja čuva šifrovane ključeve i kontroliše pristup).
- Rotacija: Obnavljajte ključeve u redovnim intervalima (npr. svakih 90 dana); Ako se sumnja na curenje, odmah otkažite.
- Smanjenje opsega: Svaki prekidač ima samo potrebnu uslugu i potrebnu autorizaciju.
- Revizija: Zabilježite ko je koristio ključ, kada i gdje.
Četiri predloška koji se mogu kopirati
Upit za kontrolu pregleda pristupa:
Za svaki alat na listi alata ispod, procijenite:- Da li je ovaj alat POTREBAN za obavljanje posla ovog pomoćnika? (da/ne) - Da li je samo za čitanje ili za pisanje/brisanje? - Da li se ovaj alat poziva s korisničkim ovlaštenjem ili računom usluge? Označite nepotrebne ili prekomjerno ovlaštene kao "UKLONI/REDAGIRAJ".<tools>{{ tool_list }}</tools>
Tajni upit za skeniranje curenja:
Pronađite sve što bi moglo biti tvrdo kodirana tajna u sljedećem isječku koda: API ključ, lozinka, token, niz veze, privatni ključ. Dajte red i tip za svaki. COPY vrijednost u odgovor;maska (prva 4 znaka + ***).<code>{{ izvor }}</code>
Pravilo odluke najmanjeg autoriteta:
Kada stigne novi zahtjev za alat/pristup, pitajte:1. Može li se zadatak izvršiti bez ovog pristupa? -> Ako da: ODBACI2. Je li dovoljno samo za čitanje? -> Ako da: DODAJTE dozvolu za pisanje3. Može li se opseg suziti na jedan izvor? -> Ako da: daratPodrazumevani odgovor je "ne"; Pristup se dobija razumom.
Podsjetnik za rotaciju kalendara:
Za svaku tajnu zapis: vlasnik, datum kreiranja, rok trajanja, opseg. Prijavite svaki ključ koji je premašio 90 dana ili nije korišten 30 dana kao "KANDIDAT ZA ROTACIJU/OTKAZIVANJE".
Slaba prompt / jaka prompt
loš pristup
Snažan pristup
Model pristupa svim podacima sa jednog servisnog naloga
Model pristupa s ovlaštenjem korisnika koji postavlja zahtjev
API ključ je ugrađen u kod, nikada se ne mijenja
Rotacija u ključnom tajnom menadžeru, 90 dana
Široka ovlaštenja za pomoćnika "uradi bilo šta".
Podrazumevano samo za čitanje, pišite usko
Pristupi se nikada ne pregledavaju
Redovni pregled i opoziv pristupa
Tri mini futrole
Slučaj 1 — Procureli mješoviti proxy podaci. Pomoćnik u kući radio je sa uslužnim računom koji je imao pristup svim evidencijama zaposlenih. Korisnik pripravnik pristupio je podacima koje inače ne bi vidio govoreći „sažmite tabelu plata izvršnog direktora“; jer ga je model doveo u pitanje u kontekstu vlastitog širokog autoriteta, a ne autoriteta korisnika. Nakon što je korisnički kontekst prilagođen da se pomjeri, pripravnik je mogao izvući snimke koje je samo on ili ona mogao vidjeti.
Slučaj 2 — Propušten ključ, račun od 190.000 TL za 2 sedmice. Programer je ugradio model API ključ u pomoćnu skriptu i gurnuo ga u javno spremište. Bot je pronašao ključ za 40 minuta i koristio ga dvije sedmice; Račun je dostigao 190.000 TL. Kada je ključ premješten u tajni upravitelj, povezan na rotaciju i dodano skeniranje spremišta, incident se nije ponovio.
Slučaj 3 — Zadani spriječeni prekid samo za čitanje. DevOps pomoćnik je primio komandu "resetuj proizvodnu bazu podataka" putem brze injekcije. Međutim, pomoćniku je dat samo token samo za čitanje; upisivanje/brisanje je bilo u zasebnom odobrenom toku. Komanda je odbijena sa greškom u autorizaciji i događaj je zaveden kao alarm; Nije bilo gubitka podataka.
Savjet: Neka "ne" bude vaš zadani odgovor na novi zahtjev za pristup. Pristup je nešto što se dobija kroz opravdanje; Davanje svima u širinu, a zatim smanjenje gotovo se nikada ne radi i rizik se akumulira.
Uobičajene greške
- Pokretanje modela s velikim uslužnim računom i gubljenje korisničkog konteksta (mješoviti proxy).
- Ugrađivanje API ključa u kod i njegovo propuštanje u kontrolu verzija.
- Uopšte se ne rotiraju tasteri ("radi, ne diraj").
- Podrazumevano davanje dozvole za pisanje/brisanje pomoćniku.
- Omogućavanje pristupa jednom i nikad ponovno razmatranje.
- Brkanje autentifikacije s autorizacijom i pretpostavkom da je "prijavljen, može pristupiti svemu".
Ukratko
- Autentifikacija je pitanje „ko si ti“, autorizacija je pitanje „šta možeš da uradiš“; U AI, oba moraju raditi u kontekstu korisnika.
- Model treba da radi sa autoritetom korisnika koji podnosi zahtev, a ne sa sopstvenim širokim ovlašćenjem (izbegavajući rizik od mešovite agencije).
- Počnite s RBAC-om, produbite s ABAC-om na osjetljivim podacima; Neka minimalno ovlaštenje bude zadano.
- Nemojte zakopavati tajne u kodu; pohranite ga u tajni menadžer, suzite ga i stavite u redovnu rotaciju.
- Zadana vrijednost samo za čitanje i usko pisanje uvelike ograničavaju utjecaj injekcije.
Zadatak aplikacije
Navedite sve alate i podatke kojima vaš AI asistent pristupa. Odgovorite na tri pitanja za svako: (1) Da li je zaista potrebno? (2) Da li je dovoljno samo za čitanje? (3) Da li radi u korisničkom kontekstu? Zatim potražite sve tvrdo kodirane tajne (preko gornjeg upita za skeniranje) i napišite plan rotacije za svaki ključ koji pronađete. Uklonite barem jednu nepotrebnu autorizaciju.
kontrolna lista
- [ ] Model se izvodi u kontekstu ovlaštenja korisnika koji postavlja zahtjev.
- [ ] Pristup alatima i podacima sužen je na princip najmanje privilegija.
- [ ] Upisivanje/brisanje je odvojeno od samo za čitanje, autentificirano i usko.
- [ ] Nijedna tajna nije zakopana u kodu; Čuva se u tajnom menadžeru.
- [ ] Postoji raspored rotacije i postupak otkazivanja za ključeve.
- [ ] Pristupi se redovno pregledavaju.