Mga nadagdag:
- Kakayahang paghiwalayin ang pagpapatunay at awtorisasyon at ilapat ang pinakamababang awtorisasyon sa RBAC/ABAC
- Kakayahang maiwasan ang magkahalong panganib sa proxy sa pamamagitan ng pagpapatakbo ng modelo sa konteksto ng user
- Kakayahang mag-imbak at mag-rotate ng mga API key gamit ang lihim na sistema ng pamamahala
Ang isang makabuluhang bahagi ng mga pag-atake sa isang AI system ay nagsisimula hindi sa "panlinlang" sa modelo, ngunit sa isang ninakaw na API key o isang over-authorized na account. Ang layer ng seguridad na ito ay nagmumula sa klasikal na seguridad ng impormasyon, ngunit nagdaragdag ng mga bagong panganib sa konteksto ng AI: ang isang modelo ay tumatawag ng pagsakay sa ngalan ng ibang tao, isang account ng serbisyo ang nag-a-access sa lahat ng data, isang susi ang tumagas sa GitHub. Sa unit na ito, matututunan natin kung paano paliitin ang access sa AI system na may authentication, authorization (RBAC/ABAC), minimum authorization at secret management.
Pagkakaiba sa Pagitan ng Authentication at Authorization
Ang dalawang termino ay madalas na nalilito:
- Pagpapatunay: "Sino ka?" — na nagpapatunay na ang gumagamit/serbisyo ay talagang kung sino sila (password, token, certificate, MFA).
- Awtorisasyon: "Ano ang maaari mong gawin?" — tukuyin kung aling mapagkukunan/aksyon ang maa-access ng na-authenticate na partido.
Ang kritikal na subtlety sa mga AI system ay ito: kapag ang modelo ay gumaganap ng trabaho sa ngalan ng isang user, ito ba ay gumagana nang may awtoridad ng user na iyon o sa isang malawak na account ng serbisyo? Ang huli ay mapanganib — dahil ang modelong nalinlang ng iniksyon ay nakakakuha ng ganap na access sa account ng serbisyo.
Babala: Problema sa "Nalilitong kinatawan": hindi direktang ina-access ng isang user na may mababang awtoridad ang data na hindi niya ma-access sa pamamagitan ng pag-outsourcing ng modelong may mataas na awtoridad. Ang modelo ay dapat palaging gumana sa loob ng konteksto ng awtoridad ng gumagamit, hindi ng kanyang sariling malawak na awtoridad.
RBAC at ABAC
- RBAC (Role-Based Access Control): Nakadepende ang access sa tungkulin ng user. Ang papel na "espesyalista sa suporta" ay maaaring magbasa ng mga tala ng customer, ngunit hindi ito matatanggal. Simple at karaniwan.
- ABAC (Attribute-Based Access Control): Ang pag-access ay nakasalalay sa mga katangian: ang departamento ng user, ang label ng privacy ng data, ang oras ng araw, ang network kung saan nagmumula ang kahilingan. Mas pino ngunit mas kumplikado.
Karamihan sa mga organisasyon ay nagsisimula sa RBAC at lumalalim sa ABAC para sa sensitibong data. Rule of thumb para sa AI: dapat i-filter ng modelo ang bawat ahente na tinatawag nito at ang bawat data na ina-access nito batay sa tungkulin/attribute ng user na gumagawa ng kahilingan.
Hakbang sa Hakbang: Paggamit ng Minimal Authority
- Mag-imbentaryo. Anong mga tool ang tinatawag ng modelo, anong data ang ina-access nito? Ilista silang lahat.
- Bigyang-katwiran ang bawat pag-access. "Kailangan ba talaga ng assistant na ito na tanggalin ang awtoridad?" Kung hindi, alisin ito.
- Read-only na default. Dapat na mabasa ng modelo bilang default; Kailangang magsulat/magtanggal ng hiwalay, makitid na saklaw na token.
- Ilipat ang konteksto ng user. Tawagan ang sasakyan gamit ang awtoridad ng user, hindi gamit ang service account.
- Panandaliang kredensyal. Gumamit ng panandaliang, awtomatikong pag-renew ng mga token sa halip na mga pangmatagalang key.
Lihim na Pamamahala
Ang sikreto ay mga kredensyal na dapat manatiling lihim, gaya ng API key, password, token, o certificate. Ang pinakakaraniwang aksidente sa mga proyekto ng AI ay kapag ang API key ng provider ng modelo ay naka-embed sa code at tumagas sa version control (Git).
Tamang aplikasyon:
- Huwag kailanman i-embed ang mga key sa code; Gumamit ng environment variable o secret management system (isang serbisyong nag-iimbak ng mga key na naka-encrypt at kinokontrol ang access).
- Pag-ikot: I-renew ang mga key sa mga regular na pagitan (hal. tuwing 90 araw); Kung pinaghihinalaan ang pagtagas, kanselahin kaagad.
- Pagbabawas ng saklaw: Ang bawat switch ay mayroon lamang kinakailangang serbisyo at kinakailangang awtorisasyon.
- Audit: Mag-log kung sino ang gumamit ng susi, kailan, at saan.
Apat na Nakokopyang Template
I-access ang prompt ng kontrol sa pagsusuri:
Para sa bawat tool sa listahan ng tool sa ibaba, suriin:- KINAKAILANGAN ba ang tool na ito upang maisagawa ang trabaho ng assistant na ito? (oo/hindi) - Read-only ba ito o write/erase? - Tinatawag ba ang tool na ito gamit ang awtoridad o account ng serbisyo ng user? Markahan ang mga hindi kailangan o labis na pinahintulutan bilang "REMOVE/REDACT".<tools>{{ tool_list }}</tools>
Lihim na pag-scan ng leak prompt:
Maghanap ng anumang bagay na maaaring isang hardcoded na lihim sa sumusunod na snippet ng code: API key, password, token, string ng koneksyon, pribadong key. Magbigay ng hilera at uri para sa bawat isa. Kopyahin ang halaga sa tugon;mask (unang 4 na character + ***).<code>{{ source }}</code>
Pinakamababang panuntunan sa pagpapasya ng awtoridad:
Kapag may dumating na bagong tool/paghiling ng access, itanong:1. Magagawa ba ang gawain nang walang access na ito? -> Kung oo: REJECT2. Sapat ba ang read-only? -> Kung oo: MAGBIGAY ng pahintulot sa pagsulat3. Maaari bang paliitin ang saklaw sa iisang pinagmulan? -> Kung oo: daratAng default na sagot ay "hindi"; Ang pag-access ay nakuha sa pamamagitan ng dahilan.
Paalala sa pag-ikot ng kalendaryo:
Para sa bawat lihim, itala: may-ari, petsa ng paggawa, expiration, saklaw. Iulat ang anumang key na lumampas sa 90 araw o hindi nagamit sa loob ng 30 araw bilang isang "ROTATION/CANCELLATION CANDIDATE".
Mahina Prompt / Malakas na Prompt
mahinang diskarte
Malakas na diskarte
Ina-access ng modelo ang lahat ng data gamit ang isang account ng serbisyo
Ang modelo ay nag-a-access nang may awtoridad ng user na gumagawa ng kahilingan
Ang API key ay naka-embed sa code, hindi ito nagbabago
Pag-ikot sa key secret manager, 90 araw
Malawak na "gawin ang anumang bagay" na awtoridad sa katulong
Read-only default, magsulat nang makitid
Ang mga pag-access ay hindi kailanman sinusuri
Regular na pagsusuri sa pag-access at pagbawi
Tatlong Mini Case
Case 1 — Nag-leak na pinaghalong proxy data. Ang isang in-house assistant ay nagtatrabaho sa isang account ng serbisyo na may access sa lahat ng mga talaan ng empleyado. Isang intern user ang nag-access ng data na hindi niya karaniwang makikita sa pamamagitan ng pagsasabi ng "summarize the executive salary table"; dahil kinuwestiyon ito ng modelo sa konteksto ng sarili nitong malawak na awtoridad, hindi ng gumagamit. Kapag naayos na ang konteksto ng user para ilipat, nagawa ng intern na kumuha ng mga recording na siya lang ang nakakakita.
Case 2 — Leak key, 190,000 TL bill sa loob ng 2 linggo. Na-embed ng developer ang modelong API key sa isang helper script at itinulak ito sa isang pampublikong repositoryo. Nahanap ng bot ang susi sa loob ng 40 minuto at ginamit ito sa loob ng dalawang linggo; Umabot sa 190,000 TL ang bill. Kapag ang susi ay inilipat sa lihim na tagapamahala, konektado sa pag-ikot, at idinagdag ang pag-scan ng repositoryo, hindi na naulit ang insidente.
Case 3 — Ang default na read-only ay pinigilan ang pagkagambala. Nakatanggap ang isang assistant ng DevOps ng command na "reset production database" sa pamamagitan ng prompt injection. Gayunpaman, ang katulong ay binigyan lamang ng isang read-only na token; write/erase ay nasa isang hiwalay na naaprubahang daloy. Ang utos ay tinanggihan nang may error sa pahintulot at ang kaganapan ay na-log bilang isang alarma; Walang pagkawala ng data.
Tip: Gawing "hindi" ang iyong default na sagot sa isang bagong kahilingan sa pag-access. Ang pag-access ay isang bagay na nakuha sa pamamagitan ng pagbibigay-katwiran; Ang pagbibigay sa lahat ng malawak at pagkatapos ay ang pagbabawas ay halos hindi na tapos at ang panganib ay naiipon.
Mga karaniwang pagkakamali
- Pagpapatakbo ng modelo na may malaking account ng serbisyo at nawawala ang konteksto ng user (halo-halong proxy).
- I-embed ang API key sa code at i-leak ito sa version control.
- Hindi umiikot ang mga susi sa lahat ("gumagana, huwag hawakan").
- Ang pagbibigay sa assistant ng mga pahintulot na magsulat/magtanggal bilang default.
- Pagbibigay ng access nang isang beses at hindi na muling isasaalang-alang.
- Nakakalito ang pagpapatotoo sa awtorisasyon at ipagpalagay na "naka-log in siya, maa-access niya ang lahat."
Sa buod
- Ang pagpapatotoo ay isang tanong ng "sino ka", ang awtorisasyon ay isang tanong ng "ano ang maaari mong gawin"; Sa AI, pareho dapat gumana sa konteksto ng user.
- Ang modelo ay dapat gumana nang may awtoridad ng user na gumagawa ng kahilingan, hindi sa sarili nitong malawak na awtoridad (pag-iwas sa panganib ng magkahalong ahensya).
- Magsimula sa RBAC, palalimin gamit ang ABAC sa sensitibong data; Gawing default ang kaunting awtoridad.
- Huwag ilibing ang mga lihim sa code; itabi ito sa lihim na tagapamahala, paliitin ito at ilagay ito sa regular na pag-ikot.
- Ang read-only na default at makitid na pagsulat ay lubos na naglilimita sa epekto ng iniksyon.
Gawain ng aplikasyon
Ilista ang lahat ng tool at data na ina-access ng iyong AI assistant. Sagutin ang tatlong tanong para sa bawat isa: (1) Kailangan ba talaga? (2) Sapat ba ang read-only? (3) Tumatakbo ba ito sa konteksto ng gumagamit? Pagkatapos ay hanapin ang lahat ng mga hard-code na sikreto (sa pamamagitan ng scan prompt sa itaas) at magsulat ng plano sa pag-ikot para sa bawat key na makikita mo. Alisin ang hindi bababa sa isang hindi kinakailangang pahintulot.
checklist
- [ ] Gumagana ang modelo sa konteksto ng awtoridad ng gumagamit na gumagawa ng kahilingan.
- [ ] Ang pag-access ng tool at data ay pinaliit sa prinsipyo ng hindi bababa sa pribilehiyo.
- [ ] Ang write/erase ay hiwalay sa read-only, authenticated at makitid.
- [ ] Walang mga lihim na nakabaon sa code; Ito ay itinatago sa sikretong tagapamahala.
- [ ] Mayroong iskedyul ng pag-ikot at pamamaraan ng pagkansela para sa mga susi.
- [ ] Regular na sinusuri ang mga access.