Ieguvumi:
- Spēja atdalīt autentifikāciju un autorizāciju un piemērot minimālo autorizāciju ar RBAC/ABAC
- Spēja izvairīties no jaukta starpniekservera riska, palaižot modeli lietotāja kontekstā
- Iespēja uzglabāt un pagriezt API atslēgas ar slepeno pārvaldības sistēmu
Ievērojama daļa uzbrukumu AI sistēmai sākas nevis ar modeļa “mānīšanu”, bet gan ar nozagtu API atslēgu vai pārmērīgi autorizētu kontu. Šis drošības līmenis nāk no klasiskās informācijas drošības, taču AI kontekstā tas rada jaunus riskus: modelis izsauc braucienu kāda cita vārdā, pakalpojuma konts piekļūst visiem datiem, atslēga noplūst GitHub. Šajā nodaļā mēs uzzināsim, kā sašaurināt piekļuvi AI sistēmai, izmantojot autentifikāciju, autorizāciju (RBAC/ABAC), minimālo autorizāciju un slepeno pārvaldību.
Atšķirība starp autentifikāciju un autorizāciju
Abi termini bieži tiek sajaukti:
- Autentifikācija: "Kas jūs esat?" — pierādīt, ka lietotājs/pakalpojums patiešām ir tas, par ko viņi uzdodas (parole, marķieris, sertifikāts, MFA).
- Autorizācija: "Ko jūs varat darīt?" — noteikt, kuram resursam/darbībai autentificētā puse var piekļūt.
AI sistēmu kritiskais smalkums ir šāds: ja modelis veic darbu lietotāja vārdā, vai tas darbojas ar šī lietotāja pilnvarām vai ar plašu pakalpojuma kontu? Pēdējais ir bīstams, jo modelis, ko piemānīja injekcija, iegūst pilnu piekļuvi pakalpojuma kontam.
Uzmanību! Problēma "Apjukušais vietnieks": zemas pilnvaras lietotājs netieši piekļūst datiem, kuriem viņš nevar piekļūt, izmantojot ārpakalpojumus augstas autoritātes modelim. Modelim vienmēr jādarbojas lietotāja autoritātes kontekstā, nevis viņa paša plašās autoritātes kontekstā.
RBAC un ABAC
- RBAC (uz lomu balstīta piekļuves kontrole): piekļuve ir atkarīga no lietotāja lomas. "Atbalsta speciālista" loma var lasīt klientu piezīmes, bet nevar tās izdzēst. Vienkāršs un izplatīts.
- ABAC (uz atribūtiem balstīta piekļuves kontrole): piekļuve ir atkarīga no atribūtiem: lietotāja nodaļas, datu konfidencialitātes etiķetes, diennakts laika, tīkla, no kura tiek saņemts pieprasījums. Smalkāks, bet sarežģītāks.
Lielākā daļa organizāciju sāk ar RBAC un padziļinās uz ABAC, lai iegūtu sensitīvus datus. AI īkšķis: modelim ir jāfiltrē katrs aģents, ko tas izsauc, un visi dati, kuriem tas piekļūst, pamatojoties uz pieprasījumu veicošā lietotāja lomu/atribūtiem.
Soli pa solim: minimālas autoritātes izmantošana
- Veikt inventarizāciju. Kādus rīkus modelis izsauc, kādiem datiem tas piekļūst? Uzskaitiet tos visus.
- Pamatojiet katru piekļuvi. "Vai šim palīgam tiešām ir nepieciešama dzēšanas atļauja?" Pretējā gadījumā noņemiet to.
- Tikai lasāms noklusējums. Pēc noklusējuma modelim jāspēj lasīt; Nepieciešams rakstīt/dzēst atsevišķu šauras darbības jomas pilnvaru.
- Pārvietot lietotāja kontekstu. Zvaniet uz transportlīdzekli, izmantojot lietotāja pilnvaras, nevis pakalpojuma kontu.
- Īslaicīgs akreditācijas sertifikāts. Izmantojiet īslaicīgus, automātiski atjaunojamus marķierus, nevis ilgstošas atslēgas.
Slepenā vadība
Noslēpums ir akreditācijas dati, kuriem jāpaliek slepeniem, piemēram, API atslēga, parole, marķieris vai sertifikāts. Visizplatītākais negadījums AI projektos ir tad, kad modeļa nodrošinātāja API atslēga ir iegulta kodā un noplūst versiju kontrolē (Git).
Pareiza pielietošana:
- Nekad neiegult atslēgas kodā; Izmantojiet vides mainīgo vai slepeno pārvaldības sistēmu (pakalpojumu, kas saglabā atslēgas šifrētas un kontrolē piekļuvi).
- Rotācija: regulāri atjaunojiet atslēgas (piemēram, ik pēc 90 dienām); Ja ir aizdomas par noplūdi, nekavējoties atceliet.
- Darbības jomas samazināšana: katram slēdzim ir tikai nepieciešamais pakalpojums un nepieciešamā atļauja.
- Audits: reģistrējiet, kurš, kad un kur izmantoja atslēgu.
Četras kopējamas veidnes
Piekļuves pārskatīšanas kontroles uzvedne:
Katram rīkam tālāk esošajā rīku sarakstā novērtējiet:- Vai šis rīks ir OBLIGĀTS, lai veiktu šī asistenta darbu? (jā/nē) — Vai tas ir tikai lasāms vai rakstāms/dzēšams? - Vai šis rīks tiek izsaukts, izmantojot lietotāja pilnvaras vai pakalpojuma kontu? Nevajadzīgos vai pārmērīgi autorizētos atzīmējiet ar atzīmi "NOŅEMT/REDAKTĒT".<tools>{{ tool_list }}</tools>
Slepenas noplūdes skenēšanas uzvedne:
Šajā koda fragmentā atrodiet jebko, kas varētu būt iekodēts noslēpums: API atslēga, parole, marķieris, savienojuma virkne, privātā atslēga. Katram norādiet rindu un veidu. COPY vērtību atbildē;mask (pirmās 4 rakstzīmes + ***).<code>{{ avots }}</code>
Mazākās pilnvaras lēmuma noteikums:
Kad tiek saņemts jauns rīka/piekļuves pieprasījums, jautājiet:1. Vai uzdevumu var veikt bez šīs piekļuves? -> Ja jā: NORAIDĪT2. Vai pietiek tikai lasīšanai? -> Ja jā: PIEŠĶIRT rakstīšanas atļauju3. Vai darbības jomu var sašaurināt līdz vienam avotam? -> Ja jā: daratNoklusējuma atbilde ir "nē"; Piekļuve tiek iegūta saprāta dēļ.
Rotācijas kalendāra atgādinājums:
Katram noslēpumam ierakstiet: īpašnieks, izveides datums, derīguma termiņš, darbības joma. Ziņojiet par jebkuru atslēgu, kas ir pārsniegusi 90 dienas vai nav izmantota 30 dienas kā "ROTĀCIJAS/ANCULĒŠANAS KANDIDĀTU".
Vāja uzvedne / spēcīga uzvedne
slikta pieeja
Spēcīga pieeja
Modelis piekļūst visiem datiem, izmantojot vienu pakalpojuma kontu
Modelis piekļūst ar pieprasījuma iesniedzēja lietotāja pilnvarām
API atslēga ir iegulta kodā, tā nekad nemainās
Rotācija atslēgas noslēpumu pārvaldniekā, 90 dienas
Plašas pilnvaras "darīt jebko" asistentam
Tikai lasāms pēc noklusējuma, rakstiet šauri
Piekļuves nekad netiek pārskatītas
Regulāra piekļuves pārskatīšana un atsaukšana
Trīs mini futrāļi
1. gadījums — noplūda jaukti starpniekservera dati. Uzņēmuma iekšējais palīgs strādāja ar pakalpojuma kontu, kuram bija piekļuve visiem darbinieku ierakstiem. Praktizēts lietotājs piekļuva datiem, kurus viņš parasti neredzētu, sakot "apkopojiet vadītāju algu tabulu"; jo modelis to apšaubīja savas plašās autoritātes kontekstā, nevis lietotāja. Kad lietotāja konteksts tika pielāgots pārvietošanai, praktikants varēja izvilkt ierakstus, ko varēja redzēt tikai viņš vai viņa.
2. gadījums — noplūda atslēga, 190 000 TL rēķins 2 nedēļu laikā. Izstrādātājs modeļa API atslēgu iegulst palīgskriptā un nosūtīja to publiskajā repozitorijā. Bots atrada atslēgu 40 minūtēs un izmantoja to divas nedēļas; Rēķins sasniedza 190 000 TL. Kad atslēga tika pārvietota uz slepeno pārvaldnieku, savienota ar rotāciju un pievienota repozitorija skenēšana, incidents neatkārtojās.
3. gadījums — tikai lasāms noklusējuma traucējums. DevOps palīgs saņēma komandu "atiestatīt ražošanas datu bāzi", izmantojot tūlītēju injekciju. Tomēr palīgam tika piešķirts tikai lasāms marķieris; rakstīšana/dzēšana bija atsevišķā apstiprinātā plūsmā. Komanda tika noraidīta ar autorizācijas kļūdu, un notikums tika reģistrēts kā trauksme; Datu zudumu nebija.
Padoms. Iestatiet “nē” kā noklusējuma atbildi jaunam piekļuves pieprasījumam. Piekļuve ir kaut kas iegūts ar pamatojumu; Ikvienam plaši dot un pēc tam samazināt gandrīz nekad netiek darīts, un risks uzkrājas.
Biežas kļūdas
- Modeļa palaišana ar lielu pakalpojuma kontu un lietotāja konteksta zaudēšana (jaukts starpniekserveris).
- API atslēgas iegulšana kodā un tās noplūde versijas kontrolē.
- Taustiņus nemaz negriežot ("strādā, neaiztiec").
- Pēc noklusējuma asistentam piešķirot rakstīšanas/dzēšanas atļaujas.
- Piešķirt piekļuvi vienreiz un nekad to nepārdomāt.
- Jaukt autentifikāciju ar autorizāciju un pieņemot, ka "viņš ir pieteicies, viņš var piekļūt visam".
Rezumējot
- Autentifikācija ir jautājums par “kas tu esi”, autorizācija ir jautājums par “ko tu vari darīt”; AI gadījumā abiem ir jādarbojas lietotāja kontekstā.
- Modelim jādarbojas ar pieprasījuma iesniedzēja lietotāja pilnvarām, nevis ar savu plašo pilnvaru (izvairoties no jauktas aģentūras riska).
- Sāciet ar RBAC, padziļiniet ar ABAC par sensitīviem datiem; Iestatiet minimālo autoritāti par noklusējuma vērtību.
- Neapglabājiet noslēpumus kodā; saglabājiet to slepenajā pārvaldniekā, sašauriniet to un ievietojiet to regulārā rotācijā.
- Tikai lasāmā noklusējuma un šaura rakstīšana ievērojami ierobežo injekcijas ietekmi.
Lietojumprogrammas uzdevums
Uzskaitiet visus rīkus un datus, kuriem piekļūst jūsu AI palīgs. Katram atbildiet uz trim jautājumiem: (1) Vai tas tiešām ir nepieciešams? (2) Vai pietiek ar tikai lasāmu? (3) Vai tas darbojas lietotāja kontekstā? Pēc tam meklējiet visus iekodētos noslēpumus (izmantojot iepriekš esošo skenēšanas uzvedni) un uzrakstiet katras atrastās atslēgas rotācijas plānu. Noņemiet vismaz vienu nevajadzīgu autorizāciju.
kontrolsaraksts
- [ ] Modelis darbojas pieprasījuma iesniedzēja lietotāja autoritātes kontekstā.
- [ ] Piekļuve rīkiem un datiem ir sašaurināta līdz mazāko privilēģiju principam.
- [ ] Rakstīšana/dzēšana ir nošķirta no tikai lasīšanas, autentificēta un šaura.
- [ ] Kodā nav apglabāti noslēpumi; Tas tiek glabāts slepenajā pārvaldniekā.
- [ ] Atslēgām ir rotācijas grafiks un atcelšanas procedūra.
- [ ] Piekļuves regulāri pārskata.