Gevinster:
- Evne til at adskille autentificering og autorisation og anvende minimumsautorisation med RBAC/ABAC
- Mulighed for at undgå blandet proxy-risiko ved at køre modellen i brugerkonteksten
- Mulighed for at gemme og rotere API-nøgler med det hemmelige administrationssystem
En betydelig del af angrebene på et AI-system begynder ikke med at "tricke" modellen, men med en stjålet API-nøgle eller en overautoriseret konto. Dette lag af sikkerhed kommer fra klassisk informationssikkerhed, men tilføjer nye risici i forbindelse med AI: en model kalder en tur på en andens vegne, en servicekonto får adgang til alle data, en nøgle lækker til GitHub. I denne enhed lærer vi at indsnævre adgangen til AI-systemet med autentificering, autorisation (RBAC/ABAC), minimumsautorisation og hemmelig styring.
Forskellen mellem godkendelse og autorisation
De to udtryk forveksles ofte:
- Autentificering: "Hvem er du?" — bevise, at brugeren/tjenesten virkelig er den, de hævder at være (adgangskode, token, certifikat, MFA).
- Autorisation: "Hvad kan du gøre?" — bestemme, hvilken ressource/handling den godkendte part har adgang til.
Den kritiske subtilitet i AI-systemer er denne: Når modellen udfører arbejde på vegne af en bruger, fungerer den så med denne brugers autoritet eller med en bred servicekonto? Sidstnævnte er farligt - fordi den model, der bliver snydt af injektionen, får fuld adgang til servicekontoen.
Advarsel: "Forvirret stedfortræder"-problem: en bruger med lav autoritet får indirekte adgang til data, som han ikke kan få adgang til, ved at outsource en model med høj autoritet. Modellen bør altid fungere inden for rammerne af brugerens autoritet, ikke hans egen brede autoritet.
RBAC og ABAC
- RBAC (Role-Based Access Control): Adgang afhænger af brugerens rolle. Rollen "supportspecialist" kan læse kundenoter, men kan ikke slette dem. Enkelt og almindeligt.
- ABAC (Attribut-Based Access Control): Adgang afhænger af attributter: brugerens afdeling, databeskyttelsesmærket, tidspunktet på dagen, netværket, som anmodningen kommer fra. Mere finjusteret, men mere kompleks.
De fleste organisationer starter med RBAC og uddyber til ABAC for følsomme data. Tommelfingerregel for AI: Modellen skal filtrere hver agent, den kalder, og alle data, den får adgang til, baseret på rollen/attributterne for den bruger, der fremsætter anmodningen.
Trin for trin: Udøvelse af minimal autoritet
- Tag opgørelse. Hvilke værktøjer kalder modellen, hvilke data får den adgang til? Liste dem alle sammen.
- Begrund hver adgang. "Har denne assistent virkelig brug for sletteautoritet?" Ellers fjern den.
- Skrivebeskyttet standard. Modellen skal kunne læse som standard; Kræv skriv/slet separat token med snævert omfang.
- Flyt brugerkontekst. Ring til køretøjet med brugerens tilladelse, ikke med servicekontoen.
- Kortvarig legitimation. Brug kortlivede, automatisk fornyende tokens i stedet for nøgler med lang levetid.
Hemmelig ledelse
En hemmelighed er legitimationsoplysninger, der skal forblive hemmelige, såsom en API-nøgle, adgangskode, token eller certifikat. Den mest almindelige ulykke i AI-projekter er, når modeludbyderens API-nøgle er indlejret i koden og lækker ind i versionskontrol (Git).
Korrekt anvendelse:
- Indlejr aldrig nøgler i kode; Brug en miljøvariabel eller et hemmeligt administrationssystem (en tjeneste, der gemmer nøgler krypteret og kontrollerer adgangen).
- Rotation: Forny nøgler med regelmæssige intervaller (f.eks. hver 90. dag); Hvis der er mistanke om lækage, annuller straks.
- Omfangsreduktion: Hver switch har kun den nødvendige service og påkrævede autorisation.
- Revision: Log hvem der brugte nøglen, hvornår og hvor.
Fire kopierbare skabeloner
Adgangskontrolprompt for gennemgang:
For hvert værktøj i værktøjslisten nedenfor, evaluer:- Er dette værktøj PÅKRÆVET for at udføre denne assistents job? (ja/nej) - Er det skrivebeskyttet eller skriv/slet? - Kaldes dette værktøj med brugerens autoritet eller servicekonto? Markér unødvendige eller overdrevent godkendte som "FJERN/REDAKTØR".<tools>{{ tool_list }}</tools>
Hemmelig lækage scanning prompt:
Find alt, der kunne være en hårdkodet hemmelighed, i følgende kodestykke: API-nøgle, adgangskode, token, forbindelsesstreng, privat nøgle. Angiv række og type for hver. COPY værdi ind i respons;maske (første 4 tegn + ***).<code>{{ source }}</code>
Reglen om mindst myndighedsbeslutning:
Når der kommer et nyt værktøj/adgangsanmodning, spørg:1. Kan opgaven udføres uden denne adgang? -> Hvis ja: AFVIS2. Er skrivebeskyttet nok? -> Hvis ja: GIV skrivetilladelse3. Kan omfanget indsnævres til en enkelt kilde? -> Hvis ja: daratStandardsvaret er "nej"; Adgang opnås af fornuft.
Påmindelse om rotationskalender:
For hver hemmelighed skal du registrere: ejer, oprettelsesdato, udløb, omfang. Rapporter enhver nøgle, der har overskredet 90 dage eller ikke har været brugt i 30 dage som en "ROTATION/ANNULLERINGSKANDIDAT".
Svag prompt / stærk prompt
dårlig tilgang
Stærk tilgang
Model får adgang til alle data med en enkelt servicekonto
Modellen får adgang med autoriteten af den bruger, der foretager anmodningen
API-nøgle er indlejret i koden, den ændres aldrig
Rotation i nøglehemmelighedschef, 90 dage
Bred "gør hvad som helst"-autoritet til assistenten
Skrivebeskyttet standard, skriv snævert
Adgange bliver aldrig gennemgået
Regelmæssig adgangsgennemgang og tilbagekaldelse
Tre mini etuier
Tilfælde 1 — Lækkede blandede proxydata. En intern assistent arbejdede med en servicekonto, der havde adgang til alle medarbejderregistre. En praktikantbruger fik adgang til data, som han normalt ikke ville se ved at sige "opsummer direktørløntabellen"; fordi modellen stillede spørgsmålstegn ved den i sammenhæng med sin egen brede autoritet, ikke brugerens. Når brugerkonteksten var justeret til at blive flyttet, var praktikanten i stand til at trække optagelser, som kun han eller hun kunne se.
Sag 2 — Lækket nøgle, 190.000 TL regning på 2 uger. En udvikler indlejrede model-API-nøglen i et hjælpescript og skubbede den til et offentligt lager. En bot fandt nøglen på 40 minutter og brugte den i to uger; Regningen nåede 190.000 TL. Da nøglen blev flyttet til den hemmelige manager, forbundet til rotation, og lagerscanning blev tilføjet, opstod hændelsen ikke igen.
Tilfælde 3 — Skrivebeskyttet standard forhindret afbrydelse. En DevOps-assistent modtog en "nulstil produktionsdatabase"-kommando via prompt-injektion. Assistenten fik dog kun et skrivebeskyttet token; skriv/slet var i et separat godkendt flow. Kommandoen blev afvist med godkendelsesfejl, og hændelsen blev logget som en alarm; Der var intet datatab.
Tip: Gør "nej" til dit standardsvar på en ny adgangsanmodning. Adgang er noget, der opnås gennem retfærdiggørelse; At give alle brede og derefter skære ned er næsten aldrig gjort, og risikoen akkumuleres.
Almindelige fejl
- Kører modellen med en stor servicekonto og mister brugerkonteksten (blandet proxy).
- Indlejring af API-nøglen i koden og læk den til versionskontrol.
- Drejer slet ikke tasterne ("arbejder, rør ikke").
- Giver assistenten skrive-/slettetilladelser som standard.
- Give adgang én gang og aldrig genoverveje det.
- Forveksler godkendelse med autorisation og antager "han er logget ind, han kan få adgang til alt".
Sammenfattende
- Autentificering er et spørgsmål om "hvem er du", autorisation er et spørgsmål om "hvad kan du gøre"; I AI skal begge fungere i brugersammenhæng.
- Modellen bør fungere med autoriteten hos den bruger, der fremsætter anmodningen, ikke med sin egen brede autoritet (for at undgå risikoen for blandet agentur).
- Start med RBAC, uddyb med ABAC om følsomme data; Gør minimal autoritet til standard.
- Begrav ikke hemmeligheder i kode; gem det i den hemmelige manager, indsnæv det og sæt det i almindelig rotation.
- Den skrivebeskyttede standard og den smalle skrivning begrænser i høj grad virkningen af injektion.
Ansøgningsopgave
Liste over alle de værktøjer og data, din AI-assistent får adgang til. Besvar tre spørgsmål for hver: (1) Er det virkelig nødvendigt? (2) Er skrivebeskyttet nok? (3) Kører det i brugersammenhæng? Søg derefter efter alle hårdkodede hemmeligheder (via scanningsprompten ovenfor) og skriv en rotationsplan for hver nøgle, du finder. Fjern mindst én unødvendig godkendelse.
tjekliste
- [ ] Modellen kører i myndighedskonteksten for den bruger, der fremsætter anmodningen.
- [ ] Værktøjs- og dataadgang er blevet indsnævret til princippet om mindste privilegium.
- [ ] Skriv/slet er adskilt fra skrivebeskyttet, godkendt og smalt.
- [ ] Ingen hemmeligheder er begravet i koden; Det opbevares i den hemmelige manager.
- [ ] Der er en rotationsplan og annulleringsprocedure for nøgler.
- [ ] Adgange gennemgås regelmæssigt.