Jedinica 4 / 11

Kontrola pristupa, upravljanje identitetom i tajnom

Dobici:

  • Mogućnost odvajanja autentifikacije i autorizacije i primjene minimalne autorizacije s RBAC/ABAC
  • Sposobnost izbjegavanja mješovitog proxy rizika pokretanjem modela u korisničkom kontekstu
  • Mogućnost pohranjivanja i rotiranja API ključeva s tajnim sustavom upravljanja

Značajan dio napada na AI sustav ne počinje "prevarom" modela, već ukradenim API ključem ili prekomjerno autoriziranim računom. Ovaj sloj sigurnosti dolazi iz klasične informacijske sigurnosti, ali dodaje nove rizike u kontekstu umjetne inteligencije: model poziva vožnju u tuđe ime, servisni račun pristupa svim podacima, ključ curi na GitHub. U ovoj jedinici naučit ćemo kako suziti pristup AI sustavu s autentifikacijom, autorizacijom (RBAC/ABAC), minimalnom autorizacijom i tajnim upravljanjem.

Razlika između autentifikacije i autorizacije

Ta se dva pojma često brkaju:

  • Autentifikacija: "Tko ste vi?" — dokazivanje da je korisnik/usluga stvarno ono za što se predstavlja (lozinka, token, certifikat, MFA).
  • Autorizacija: "Što možete učiniti?" — odrediti kojem resursu/radnji autentificirana strana može pristupiti.

Kritična suptilnost u sustavima umjetne inteligencije je sljedeća: kada model obavlja posao u ime korisnika, radi li s ovlaštenjem tog korisnika ili s računom široke usluge? Potonje je opasno — jer model koji je prevaren injekcijom dobiva puni pristup računu usluge.

Oprez: problem "zbunjenog zamjenika": korisnik s niskim ovlastima neizravno pristupa podacima kojima ne može pristupiti tako što povjerava model s visokim ovlastima. Model uvijek treba djelovati unutar konteksta autoriteta korisnika, a ne njegovih vlastitih širokih ovlasti.

RBAC i ABAC

  • RBAC (Kontrola pristupa temeljena na ulogama): Pristup ovisi o ulozi korisnika. Uloga "stručnjaka za podršku" može čitati korisničke bilješke, ali ih ne može brisati. Jednostavno i uobičajeno.
  • ABAC (Attribute-Based Access Control): Pristup ovisi o atributima: korisnikov odjel, oznaka privatnosti podataka, doba dana, mreža s koje dolazi zahtjev. Finije podešen, ali složeniji.

Većina organizacija počinje s RBAC-om i produbljuje se na ABAC za osjetljive podatke. Osnovno pravilo za AI: model bi trebao filtrirati svakog agenta kojeg poziva i svaki podatak kojem pristupa na temelju uloge/atributa korisnika koji podnosi zahtjev.

Korak po korak: Primjena minimalnih ovlasti

  1. Provedite popis. Koje alate model poziva, kojim podacima pristupa? Navedite ih sve.
  2. Opravdajte svaki pristup. "Potrebno li je ovom pomoćniku stvarno ovlaštenje za brisanje?" U suprotnom, uklonite ga.
  3. Zadano samo za čitanje. Model bi trebao moći čitati prema zadanim postavkama; Zahtijeva pisanje/brisanje zasebnog tokena uskog opsega.
  4. Premjestite korisnički kontekst. Nazovite vozilo s ovlaštenjem korisnika, a ne s računom usluge.
  5. Kratkotrajna vjerodajnica. Koristite kratkotrajne tokene koji se automatski obnavljaju umjesto dugotrajnih ključeva.

Tajno upravljanje

Tajna su vjerodajnice koje moraju ostati tajne, poput API ključa, lozinke, tokena ili certifikata. Najčešća nesreća u projektima umjetne inteligencije 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 sustav upravljanja (usluga koja pohranjuje šifrirane ključeve i kontrolira pristup).
  • Rotacija: obnavljajte ključeve u redovitim 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 tko je koristio ključ, kada i gdje.

Četiri predloška za kopiranje

Kontrolni upit za pregled pristupa:

Za svaki alat na donjem popisu alata procijenite: - Je li ovaj alat POTREBAN za obavljanje posla ovog pomoćnika? (da/ne) - Je li samo za čitanje ili pisanje/brisanje? - Poziva li se ovaj alat s korisničkim ovlaštenjem ili računom usluge? Označite nepotrebne ili pretjerano ovlaštene kao "UKLONI/REDIGIRAJ".<tools>{{ tool_list }}</tools>

Upit za skeniranje tajnog 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č. Navedite redak i tip za svaki. COPY vrijednost u odgovor;maska (prva 4 znaka + ***).<code>{{ izvor }}</code>

Pravilo najmanjeg ovlaštenja za odlučivanje:

Kada stigne novi alat/zahtjev za pristup, pitajte:1. Može li se zadatak izvršiti bez ovog pristupa? -> Ako da: ODBITI2. Je li dovoljan samo za čitanje? -> Ako da: ODOBRITE dopuštenje za pisanje3. Može li se opseg suziti na jedan izvor? -> Ako da: daratZadani odgovor je "ne"; Pristup se dobiva razumom.

Podsjetnik na rotacijski kalendar:

Za svaku tajnu zabilježite: vlasnika, datum stvaranja, isteka, opseg. Prijavite svaki ključ koji je premašio 90 dana ili nije korišten 30 dana kao "KANDIDAT ZA ROTACIJU/OTKAZ".

Slab upit / Jak upit

loš pristup

Snažan pristup

Model pristupa svim podacima s jednim računom usluge

Model pristupa s ovlaštenjem korisnika koji podnosi zahtjev

API ključ je ugrađen u kod, nikada se ne mijenja

Rotacija u upravitelju tajnih ključeva, 90 dana

Široka ovlast "učini bilo što" pomoćniku

Zadana postavka samo za čitanje, pišite usko

Pristupi se nikada ne pregledavaju

Redoviti pregled pristupa i opoziv

Tri mini kućišta

Slučaj 1 — Procurili mješoviti proxy podaci. Interni pomoćnik radio je s računom usluge koji je imao pristup svim evidencijama zaposlenika. Pripravnik je pristupio podacima koje inače ne bi vidio tako što je rekao "sažeti tablicu plaća rukovoditelja"; jer ga je model propitivao u kontekstu vlastite široke ovlasti, a ne korisnikove. Nakon što je korisnički kontekst prilagođen za pomicanje, pripravnik je mogao povući snimke koje je samo on ili ona mogao vidjeti.

Slučaj 2 — Ključ je procurio, račun od 190.000 TL u 2 tjedna. Programer je ugradio API ključ modela u pomoćnu skriptu i gurnuo ga u javno spremište. Bot je pronašao ključ u 40 minuta i koristio ga dva tjedna; Račun je dosegao 190.000 TL. Kad je ključ premješten u tajni upravitelj, povezan s rotacijom i dodano skeniranje repozitorija, incident se nije ponovio.

Slučaj 3 — Zadani spriječeni prekid samo za čitanje. DevOps pomoćnik primio je naredbu "reset proizvodne baze podataka" putem brzog ubacivanja. Međutim, pomoćnik je dobio samo token samo za čitanje; pisanje/brisanje bilo je u zasebnom odobrenom toku. Naredba je odbijena s pogreškom autorizacije i događaj je zabilježen kao alarm; Nije bilo gubitka podataka.

Savjet: Neka "ne" bude vaš zadani odgovor na novi zahtjev za pristup. Pristup je nešto što se dobiva kroz opravdanje; Gotovo se nikad ne radi davanje svima široke ruke, a zatim smanjenje, a rizik se gomila.

Uobičajene greške

  • Pokretanje modela s velikim računom usluge i gubitak korisničkog konteksta (mješoviti proxy).
  • Ugrađivanje API ključa u kod i njegovo propuštanje u kontrolu verzija.
  • Uopće se ne okreću tipke ("radi, ne diraj").
  • Davanje dopuštenja za pisanje/brisanje pomoćniku prema zadanim postavkama.
  • Odobravanje pristupa jednom i nikad ponovno razmatranje.
  • Brkati autentifikaciju s autorizacijom i pretpostaviti da je "prijavljen, može pristupiti svemu".

Ukratko

  • Autentifikacija je pitanje "tko ste vi", autorizacija je pitanje "što možete učiniti"; U umjetnoj inteligenciji oboje moraju djelovati u kontekstu korisnika.
  • Model bi trebao funkcionirati s ovlastima korisnika koji podnosi zahtjev, a ne s vlastitim širokim ovlastima (izbjegavajući rizik mješovite agencije).
  • Počnite s RBAC-om, produbite s ABAC-om na osjetljivim podacima; Neka minimalne ovlasti budu zadane.
  • Ne zakopavajte tajne u šifru; pohranite ga u tajni upravitelj, suzite ga i stavite u redovitu rotaciju.
  • Zadana postavka samo za čitanje i usko pisanje uvelike ograničavaju učinak ubrizgavanja.

Zadatak aplikacije

Navedite sve alate i podatke kojima vaš AI pomoćnik pristupa. Odgovorite na tri pitanja za svako: (1) Je li stvarno potrebno? (2) Je li dovoljno samo za čitanje? (3) Radi li u korisničkom kontekstu? Zatim potražite sve tvrdo kodirane tajne (putem gornjeg upita za skeniranje) i napišite plan rotacije za svaki ključ koji pronađete. Uklonite barem jednu nepotrebnu autorizaciju.

popis za provjeru

  • [ ] Model se izvodi u kontekstu ovlaštenja korisnika koji podnosi zahtjev.
  • [ ] Pristup alatima i podacima sužen je na načelo najmanje privilegije.
  • [ ] Pisanje/brisanje je odvojeno od samo za čitanje, autentificirano i usko.
  • [ ] Nikakve tajne nisu zakopane u kodu; Čuva se u tajnom upravitelju.
  • [ ] Postoji raspored rotacije i postupak otkazivanja ključeva.
  • [ ] Pristupi se redovito pregledavaju.