Juurdepääsukontroll, identiteedi ja salajane haldus

Kasu:

• Võimalus eraldada autentimine ja autoriseerimine ning rakendada minimaalset autoriseerimist RBAC/ABAC-iga
• Võimalus vältida segatud puhverserveri riski, käivitades mudeli kasutaja kontekstis
• Võimalus salvestada ja pöörata API võtmeid salajase haldussüsteemiga

Märkimisväärne osa AI-süsteemi rünnakutest ei alga mitte mudeli "pettamisest", vaid varastatud API võtmest või ülevolitatud kontost. See turvakiht pärineb klassikalisest infoturbest, kuid lisab tehisintellekti kontekstis uusi riske: mudel kutsub kellegi teise nimel sõitma, teenusekonto pääseb juurde kõikidele andmetele, võti lekib GitHubisse. Selles üksuses õpime, kuidas piirata juurdepääsu AI-süsteemile autentimise, autoriseerimise (RBAC/ABAC), minimaalse autoriseerimise ja salajase halduse abil.

Erinevus autentimise ja autoriseerimise vahel

Neid kahte mõistet aetakse sageli segamini:

• Autentimine: "Kes sa oled?" — tõestada, et kasutaja/teenus on tõesti see, kes nad end väidetavalt peavad (parool, tunnus, sertifikaat, MFA).
• Volitus: "Mida saate teha?" — määrake kindlaks, millisele ressursile/toimingule on autentitud osapoolel juurdepääs.

Tehisintellektisüsteemide kriitiline peensus on järgmine: kui mudel teeb tööd kasutaja nimel, kas see töötab selle kasutaja volitustega või laia teenusekontoga? Viimane on ohtlik – kuna süstiga petetud mudel saab täieliku juurdepääsu teenusekontole.

Ettevaatust: "Segaduses asetäitja" probleem: madala autoriteetsusega kasutaja pääseb kaudselt juurde andmetele, millele ta juurde ei pääse, tellides kõrge autoriteediga mudeli väljast. Mudel peaks alati toimima kasutaja volituste, mitte tema enda laiaulatuslike volituste kontekstis.

RBAC ja ABAC

• RBAC (rollipõhine juurdepääsukontroll): juurdepääs sõltub kasutaja rollist. "Tugispetsialisti" roll saab lugeda kliendi märkmeid, kuid ei saa neid kustutada. Lihtne ja tavaline.
• ABAC (atribuutidepõhine juurdepääsukontroll): juurdepääs sõltub atribuutidest: kasutaja osakond, andmete privaatsusmärgis, kellaaeg, võrk, kust päring tuleb. Viimistletum, kuid keerulisem.

Enamik organisatsioone alustab RBAC-ga ja süvendab tundlike andmete jaoks ABAC-i. Tehisintellekti rusikareegel: mudel peaks päringu esitava kasutaja rolli/atribuutide alusel filtreerima iga agenti, millele ta helistab, ja kõiki andmeid, millele ta juurde pääseb.

Samm-sammult: minimaalse autoriteedi kasutamine

1. Tehke inventuur. Milliseid tööriistu mudel kutsub, millistele andmetele see ligi pääseb? Loetlege need kõik.
2. Põhjendage iga juurdepääsu. "Kas see assistent vajab tõesti kustutamisvolitust?" Vastasel juhul eemaldage see.
3. Vaikimisi kirjutuskaitstud. Mudel peaks suutma vaikimisi lugeda; Nõua eraldi, kitsa ulatusega märgi kirjutamist/kustutamist.
4. Liiguta kasutaja konteksti. Helistage sõidukile kasutaja volitustega, mitte teeninduskontoga.
5. Lühiajaline volikiri. Kasutage pikaealiste võtmete asemel lühiajalisi automaatselt uuenevaid märke.

Salajane juhtimine

Saladus on mandaadid, mis peavad jääma salajasteks, näiteks API võti, parool, luba või sertifikaat. Kõige tavalisem õnnetus AI-projektides on see, kui mudeli pakkuja API-võti on koodi manustatud ja lekib versioonikontrolli (Git).

Õige rakendus:

• Ärge kunagi manustage võtmeid koodi; Kasutage keskkonnamuutujat või salajast haldussüsteemi (teenus, mis salvestab võtmed krüpteeritult ja kontrollib juurdepääsu).
• Pööramine: uuendage võtmeid korrapäraste ajavahemike järel (nt iga 90 päeva järel); Kui kahtlustate leket, tühistage kohe.
• Ulatuse vähendamine: igal lülitil on ainult nõutav teenus ja nõutav luba.
• Audit: logige sisse, kes, millal ja kus võtit kasutas.

Neli kopeeritavat malli

Juurdepääsu ülevaatuse juhtviip:

Hinnake iga allolevas tööriistaloendis oleva tööriista puhul järgmist. Kas see tööriist ON selle assistendi töö tegemiseks VAJALIK? (jah/ei) – kas see on kirjutuskaitstud või kirjutatav/kustutav? - Kas seda tööriista kutsutakse välja kasutaja volituse või teenusekontoga? Märkige mittevajalikud või ülemäära volitatud elemendid märkega "EEMALDAMINE/REDAKTERIMINE".<tools>{{ tool_list }}</tools>

Salajase lekke skannimise viip:

Leidke järgmisest koodilõigust kõik, mis võib olla kõvasti kodeeritud saladus: API võti, parool, luba, ühenduse string, privaatvõti. Andke iga jaoks rida ja tüüp. COPY väärtus vastusesse;mask (esimesed 4 tähemärki + ***).<code>{{ allikas }}</code>

Vähima volituse otsuse reegel:

Kui saabub uus tööriist/juurdepääsutaotlus, küsige:1. Kas ülesannet saab täita ilma selle juurdepääsuta? -> Kui jah: REJECT2. Kas ainult lugemiseks piisab? -> Kui jah: ANNA kirjutamisluba3. Kas ulatust saab kitsendada ühele allikale? -> Kui jah: darat Vaikimisi vastus on "ei"; Juurdepääs saavutatakse põhjusega.

Kalendri pööramise meeldetuletus:

Iga saladuse kohta kirje: omanik, loomise kuupäev, kehtivusaeg, ulatus. Teatage igast võtmest, mis on ületanud 90 päeva või mida ei ole 30 päeva kasutatud, kui "ROTATION/TÜHISTAMISEKANDIDAATI".

Nõrk viip / Tugev viip

halb lähenemine

Tugev lähenemine

Mudel pääseb kõigile andmetele juurde ühe teenusekontoga

Mudel pääseb juurde päringu teinud kasutaja volitustega

API võti on koodi sisse manustatud, see ei muutu kunagi

Võtmesaladuse halduri rotatsioon, 90 päeva

Assistendi laialdane volitus "tee kõike".

Vaikimisi kirjutuskaitstud, kirjuta kitsalt

Juurdepääsu ei vaadata kunagi üle

Regulaarne juurdepääsu ülevaatus ja tühistamine

Kolm miniümbrist

Juhtum 1 – lekkisid segatud puhverserveri andmed. Ettevõttesisene assistent töötas teenusekontoga, millel oli juurdepääs kõikidele töötajate dokumentidele. Praktikakasutaja pääses juurde andmetele, mida ta tavaliselt ei näeks, öeldes "tehke kokkuvõte juhi palgatabelist"; sest mudel seadis selle kahtluse alla omaenda, mitte kasutaja autoriteedi kontekstis. Kui kasutaja kontekst oli teisaldamiseks kohandatud, sai praktikant tõmmata salvestisi, mida ainult tema nägi.

Juhtum 2 — Lekkinud võti, 190 000 TL arve 2 nädalaga. Arendaja manustas mudeli API võtme abiskripti ja lükkas selle avalikku hoidlasse. Bot leidis võtme 40 minutiga ja kasutas seda kaks nädalat; Arve ulatus 190 000 TL-i. Kui võti teisaldati salahaldurisse, ühendati rotatsiooniga ja lisati hoidla skannimine, juhtum ei kordunud.

Juhtum 3 – kirjutuskaitstud vaikimisi takistatud katkestus. DevOpsi assistent sai viipade kaudu käsu "lähtestage tootmisandmebaas". Assistendile anti aga ainult kirjutuskaitstud märk; kirjutamine/kustutamine oli eraldi heakskiidetud voos. Käsk lükati tagasi autoriseerimisveaga ja sündmus logiti häirena; Andmete kadumist ei toimunud.

Näpunäide: määrake uue juurdepääsutaotluse vaikevastuseks "ei". Juurdepääs on midagi, mis saadakse õigustamisega; Kõigile laiali andmist ja seejärel kärpimist ei tehta peaaegu kunagi ja risk koguneb.

Levinud vead

• Mudeli käitamine suure teenusekontoga ja kasutaja konteksti kaotamine (segapuhverserver).
• API võtme manustamine koodi ja selle lekitamine versioonikontrolli.
• Klahve ei pööra üldse ("töötab, ärge puudutage").
• Assistendile vaikimisi kirjutamis-/kustutusõiguste andmine.
• Juurdepääsu andmine üks kord ja seda mitte kunagi uuesti kaaluda.
• Autentimise ja autoriseerimise segi ajamine ja eeldus, et "ta on sisse logitud, pääseb kõigele juurde".

Kokkuvõttes

• Autentimine on küsimus "kes sa oled", autoriseerimine on küsimus "mida saate teha"; AI-s peavad mõlemad toimima kasutaja kontekstis.
• Mudel peaks toimima päringu esitava kasutaja volitustega, mitte oma laiaulatuslike volitustega (vältides segaagentuuri riski).
• Alustage RBAC-iga, süvendage tundlike andmete puhul ABAC-iga; Muutke vaikeväärtuseks minimaalne volitus.
• Ärge matke saladusi koodi; salvestage see salahaldurisse, kitsendage seda ja pange see regulaarsele pöörlemisele.
• Kirjutuskaitstud vaike- ja kitsas kirjutamine piiravad oluliselt süstimise mõju.

Rakenduse ülesanne

Loetlege kõik tööriistad ja andmed, millele teie AI-assistent juurde pääseb. Vastake igaühe kohta kolmele küsimusele: (1) Kas see on tõesti vajalik? (2) Kas kirjutuskaitstud on piisav? (3) Kas see töötab kasutaja kontekstis? Seejärel otsige üles kõik kõvasti kodeeritud saladused (ülaltoodud skannimisviiba kaudu) ja kirjutage iga leitud võtme jaoks pöörlemisplaan. Eemaldage vähemalt üks mittevajalik autoriseerimine.

kontrollnimekiri

• [ ] Mudel töötab päringu esitava kasutaja autoriteedi kontekstis.
• [ ] Juurdepääs tööriistadele ja andmetele on kitsendatud minimaalsete privileegide põhimõttele.
• [ ] Kirjutamine/kustutamine on kirjutuskaitstust eraldiseisev, autentitud ja kitsas.
• [ ] Koodisse pole maetud saladusi; Seda hoitakse salahalduris.
• [ ] Võtmete jaoks on rotatsioonigraafik ja tühistamise kord.
• [ ] Juurdepääsud vaadatakse regulaarselt üle.