Fitimet:
- Aftësia për të ndarë vërtetimin dhe autorizimin dhe për të aplikuar autorizimin minimal me RBAC/ABAC
- Aftësia për të shmangur rrezikun e përzier të përfaqësuesit duke ekzekutuar modelin në kontekstin e përdoruesit
- Aftësia për të ruajtur dhe rrotulluar çelësat API me sistemin e menaxhimit sekret
Një pjesë e konsiderueshme e sulmeve në një sistem AI nuk fillojnë me "mashtrimin" e modelit, por me një çelës të vjedhur API ose një llogari të mbi-autorizuar. Kjo shtresë sigurie vjen nga siguria klasike e informacionit, por shton rreziqe të reja në kontekstin e AI: një model thërret një udhëtim në emër të dikujt tjetër, një llogari shërbimi akseson të gjitha të dhënat, një çelës rrjedh në GitHub. Në këtë njësi, ne do të mësojmë se si të kufizojmë aksesin në sistemin e AI me vërtetimin, autorizimin (RBAC/ABAC), autorizimin minimal dhe menaxhimin sekret.
Dallimi midis Autentifikimit dhe Autorizimit
Dy termat shpesh ngatërrohen:
- Vërtetimi: "Kush je ti?" — duke vërtetuar se përdoruesi/shërbimi është me të vërtetë ai që pretendojnë se janë (fjalëkalimi, token, certifikatë, MPJ).
- Autorizimi: "Çfarë mund të bësh?" — përcaktoni se cilit burim/veprim mund të ketë akses pala e vërtetuar.
Hollësia kritike në sistemet e AI është kjo: kur modeli po kryen punë në emër të një përdoruesi, a funksionon me autoritetin e atij përdoruesi apo me një llogari të gjerë shërbimi? Kjo e fundit është e rrezikshme - sepse modeli i mashtruar nga injeksioni fiton akses të plotë në llogarinë e shërbimit.
Kujdes: Problemi i "deputetit të hutuar": një përdorues me autoritet të ulët akseson në mënyrë indirekte të dhëna që nuk mund t'i aksesojë duke kontraktuar një model me autoritet të lartë. Modeli duhet të funksionojë gjithmonë brenda kontekstit të autoritetit të përdoruesit, jo autoritetit të tij të gjerë.
RBAC dhe ABAC
- RBAC (Role-Based Access Control): Qasja varet nga roli i përdoruesit. Roli "specialist mbështetës" mund të lexojë shënimet e klientit, por nuk mund t'i fshijë ato. E thjeshtë dhe e zakonshme.
- ABAC (Attribute-Based Access Control): Qasja varet nga atributet: departamenti i përdoruesit, etiketa e privatësisë së të dhënave, ora e ditës, rrjeti nga vjen kërkesa. Më e rregulluar mirë, por më komplekse.
Shumica e organizatave fillojnë me RBAC dhe thellohen në ABAC për të dhëna të ndjeshme. Rregulli i përgjithshëm për AI: modeli duhet të filtrojë çdo agjent që thërret dhe çdo të dhënë që akseson bazuar në rolin/atributet e përdoruesit që bën kërkesën.
Hap pas hapi: Ushtrimi i autoritetit minimal
- Merrni inventar. Çfarë mjetesh thërret modeli, çfarë të dhënash ka? Rendisni të gjitha.
- Arsyetoni çdo akses. "A ka vërtet nevojë ky asistent autoriteti për fshirje?" Përndryshe, hiqeni atë.
- Parazgjedhja vetëm për lexim. Modeli duhet të jetë në gjendje të lexojë si parazgjedhje; Kërkoni të shkruani/fshini një shenjë të veçantë, me shtrirje të ngushtë.
- Zhvendos kontekstin e përdoruesit. Telefononi automjetin me autoritetin e përdoruesit, jo me llogarinë e shërbimit.
- Kredenciale jetëshkurtër. Përdorni argumente jetëshkurtër, të rinovuar automatikisht në vend të çelësave jetëgjatë.
Menaxhimi Sekret
Një sekret janë kredencialet që duhet të mbeten sekrete, të tilla si një çelës API, fjalëkalim, token ose certifikatë. Aksidenti më i zakonshëm në projektet e AI është kur çelësi API i ofruesit të modelit është i ngulitur në kod dhe rrjedh në kontrollin e versionit (Git).
Aplikimi i duhur:
- Asnjëherë mos i futni çelësat në kod; Përdorni një variabël mjedisi ose një sistem menaxhimi sekret (një shërbim që ruan çelësat të koduar dhe kontrollon aksesin).
- Rrotullimi: Rinovoni çelësat në intervale të rregullta (p.sh. çdo 90 ditë); Nëse dyshohet për rrjedhje, anuloni menjëherë.
- Zvogëlimi i fushëveprimit: Çdo ndërprerës ka vetëm shërbimin e kërkuar dhe autorizimin e kërkuar.
- Auditimi: Regjistroni kush e përdori çelësin, kur dhe ku.
Katër modele të kopjueshme
Kërkesa e kontrollit të rishikimit të qasjes:
Për secilin mjet në listën e mjeteve më poshtë, vlerësoni:- A KËRKOHET ky mjet për të kryer punën e këtij asistenti? (po/jo) - A është vetëm për lexim apo shkrim/fshirje? - A thirret ky mjet me autoritetin e përdoruesit ose llogarinë e shërbimit? Shënoni ato të panevojshme ose tepër të autorizuara si "HEQ/REDACT".<tools>{{ tool_list }}</tools>
Kërkesa për skanimin e rrjedhjeve sekrete:
Gjeni çdo gjë që mund të jetë një sekret i koduar në pjesën e mëposhtme të kodit: çelësi API, fjalëkalimi, token, vargu i lidhjes, çelësi privat. Jepni rreshtin dhe shkruani për secilën. COPY vlera në përgjigje;maskë (4 karakteret e para + ***).<code>{{ burimi }}</code>
Rregulli i vendimit të autoritetit më të vogël:
Kur vjen një mjet/kërkesë e re për akses, pyetni:1. A mund të kryhet detyra pa këtë akses? -> Nëse po: REFUZO 2. A mjafton vetëm lexim? -> Nëse po: GRANT shkruaj lejen3. A mund të ngushtohet fushëveprimi në një burim të vetëm? -> Nëse po: daratPërgjigja e paracaktuar është "jo"; Qasja fitohet nga arsyeja.
Kujtesa e kalendarit të rrotullimit:
Për çdo sekret, regjistroni: pronarin, datën e krijimit, skadimin, shtrirjen. Raportoni çdo çelës që ka tejkaluar 90 ditë ose nuk është përdorur për 30 ditë si "KANDIDAT PËR ROTACION/ANULIM".
Prompt i dobët / Prompt i fortë
qasje e dobët
Qasje e fortë
Modeli akseson të gjitha të dhënat me një llogari të vetme shërbimi
Modeli hyn me autoritetin e përdoruesit që bën kërkesën
Çelësi API është i ngulitur në kod, ai nuk ndryshon kurrë
Rrotullimi në menaxherin kryesor sekret, 90 ditë
Autoriteti i gjerë "bëj asgjë" për asistentin
Parazgjedhja vetëm për lexim, shkruani ngushtë
Akseset nuk shqyrtohen kurrë
Rishikimi dhe anulimi i rregullt i aksesit
Tre Mini Rastet
Rasti 1 - Rrjedhin të dhëna të përziera përfaqësuese. Një asistent i brendshëm po punonte me një llogari shërbimi që kishte akses në të gjitha të dhënat e punonjësve. Një përdorues praktikant ka akses në të dhëna që normalisht nuk do t'i shihte duke thënë "përmbledh tabelën e pagave të ekzekutivit"; sepse modeli e vuri në dyshim atë në kontekstin e autoritetit të tij të gjerë, jo të përdoruesit. Pasi konteksti i përdoruesit u rregullua për t'u zhvendosur, praktikanti ishte në gjendje të bënte regjistrime që vetëm ai ose ajo mund t'i shihte.
Rasti 2 — Çelësi i rrjedhur, faturë 190,000 TL në 2 javë. Një zhvillues nguliti çelësin e modelit API në një skript ndihmës dhe e shtyu atë në një depo publike. Një robot e gjeti çelësin në 40 minuta dhe e përdori atë për dy javë; Fatura arriti në 190 000 TL. Kur çelësi u zhvendos te menaxheri sekret, u lidh me rrotullimin dhe u shtua skanimi i depove, incidenti nuk u përsërit.
Rasti 3 — Ndërprerja e paracaktuar e parandaluar vetëm për lexim. Një asistent DevOps mori një komandë "rivendosja e bazës së të dhënave të prodhimit" nëpërmjet injektimit të shpejtë. Megjithatë, asistentit iu dha vetëm një shenjë vetëm për lexim; shkrimi/fshirja ishte në një rrjedhë të veçantë të miratuar. Komanda u refuzua me gabim autorizimi dhe ngjarja u regjistrua si alarm; Nuk pati humbje të të dhënave.
Këshillë: Bëni "jo" përgjigjen tuaj të paracaktuar ndaj një kërkese të re aksesi. Qasja është diçka që fitohet nëpërmjet justifikimit; Dhënia e të gjithëve gjerësisht dhe më pas shkurtimi pothuajse nuk bëhet kurrë dhe rreziku grumbullohet.
Gabimet e zakonshme
- Ekzekutimi i modelit me një llogari të madhe shërbimi dhe humbja e kontekstit të përdoruesit (proxy i përzier).
- Futja e çelësit API në kod dhe rrjedhja e tij në kontrollin e versionit.
- Nuk i rrotullon fare tastet ("punon, mos i prek").
- Duke i dhënë asistentit lejet e shkrimit/fshirjes si parazgjedhje.
- Dhënia e aksesit një herë dhe asnjëherë rishqyrtimi i saj.
- Ngatërrimi i vërtetimit me autorizimin dhe supozimi "ai është i identifikuar, ai mund të ketë akses në gjithçka".
Në përmbledhje
- Autentifikimi është një çështje e "kush je ti", autorizimi është një çështje e "çfarë mund të bësh"; Në AI, të dyja duhet të funksionojnë në kontekstin e përdoruesit.
- Modeli duhet të funksionojë me autoritetin e përdoruesit që bën kërkesën, jo me autoritetin e tij të gjerë (duke shmangur rrezikun e agjencive të përziera).
- Filloni me RBAC, thelloni me ABAC në të dhëna të ndjeshme; Bëje autoritetin minimal të paracaktuar.
- Mos i varros sekretet në kod; ruajeni atë në menaxherin sekret, ngushtojeni dhe vendoseni në rotacion të rregullt.
- Parazgjedhja vetëm për lexim dhe shkrimi i ngushtë kufizojnë shumë ndikimin e injektimit.
Detyra e aplikimit
Rendisni të gjitha mjetet dhe të dhënat në të cilat ka akses asistenti juaj i AI. Përgjigjuni tre pyetjeve për secilën: (1) A është vërtet e nevojshme? (2) A mjafton vetëm për lexim? (3) A funksionon në kontekstin e përdoruesit? Më pas kërkoni për të gjitha sekretet e koduara (nëpërmjet kërkesës së skanimit më lart) dhe shkruani një plan rrotullimi për çdo çelës që gjeni. Hiqni të paktën një autorizim të panevojshëm.
listë kontrolli
- [ ] Modeli funksionon në kontekstin e autoritetit të përdoruesit që bën kërkesën.
- [ ] Aksesi i mjeteve dhe i të dhënave është ngushtuar në parimin e privilegjit më të vogël.
- [ ] Shkrimi/fshirja është i ndarë nga vetëm për lexim, i vërtetuar dhe i ngushtë.
- [ ] Asnjë sekret nuk është i varrosur në kod; Ajo ruhet në menaxherin sekret.
- [ ] Ekziston një orar rrotullimi dhe një procedurë anulimi për çelësat.
- [ ] Akseset rishikohen rregullisht.