Gevinster:
- Evne til å skille autentisering og autorisasjon og anvende minimumsautorisasjon med RBAC/ABAC
- Evne til å unngå blandet proxy-risiko ved å kjøre modellen i brukerkontekst
- Evne til å lagre og rotere API-nøkler med det hemmelige styringssystemet
En betydelig del av angrepene på et AI-system begynner ikke med å "lure" modellen, men med en stjålet API-nøkkel eller en overautorisert konto. Dette sikkerhetslaget kommer fra klassisk informasjonssikkerhet, men legger til nye risikoer i sammenheng med AI: en modell kaller en tur på andres vegne, en tjenestekonto får tilgang til alle data, en nøkkel lekker til GitHub. I denne enheten vil vi lære hvordan du begrenser tilgangen til AI-systemet med autentisering, autorisasjon (RBAC/ABAC), minimumsautorisasjon og hemmelig administrasjon.
Forskjellen mellom autentisering og autorisasjon
De to begrepene forveksles ofte:
- Autentisering: "Hvem er du?" — bevise at brukeren/tjenesten virkelig er den de utgir seg for å være (passord, token, sertifikat, MFA).
- Autorisasjon: "Hva kan du gjøre?" — bestemme hvilken ressurs/handling den autentiserte parten har tilgang til.
Den kritiske subtiliteten i AI-systemer er dette: når modellen utfører arbeid på vegne av en bruker, opererer den med autoriteten til denne brukeren eller med en bred tjenestekonto? Sistnevnte er farlig — fordi modellen lurt av injeksjonen får full tilgang til tjenestekontoen.
Forsiktig: "Forvirret stedfortreder"-problem: en bruker med lav autoritet får indirekte tilgang til data som han ikke kan få tilgang til ved å sette ut en modell med høy autoritet. Modellen skal alltid operere innenfor konteksten av brukerens autoritet, ikke hans egen brede autoritet.
RBAC og ABAC
- RBAC (Role-Based Access Control): Tilgang avhenger av brukerens rolle. Rollen "støttespesialist" kan lese kundenotater, men kan ikke slette dem. Enkelt og vanlig.
- ABAC (Attributtbasert tilgangskontroll): Tilgang avhenger av attributter: brukerens avdeling, personvernetiketten til dataene, tidspunktet på dagen, nettverket som forespørselen kommer fra. Mer finjustert, men mer kompleks.
De fleste organisasjoner starter med RBAC og utdyper til ABAC for sensitive data. Tommelfingerregel for AI: modellen skal filtrere hver agent den kaller og alle data den får tilgang til basert på rollen/attributtene til brukeren som sender forespørselen.
Trinn for trinn: Utøve minimal autoritet
- Ta inventar. Hvilke verktøy kaller modellen, hvilke data får den tilgang til? List dem alle.
- Begrunn hver tilgang. "Trenger denne assistenten virkelig sletteautoritet?" Ellers fjern den.
- Skrivebeskyttet standard. Modellen skal kunne lese som standard; Krev skriv/slett separat token med smalt omfang.
- Flytt brukerkontekst. Ring kjøretøyet med brukerens fullmakt, ikke med servicekontoen.
- Kortvarig legitimasjon. Bruk kortlivede, automatisk fornyende tokens i stedet for nøkler med lang levetid.
Hemmelig ledelse
En hemmelighet er legitimasjon som må forbli hemmelig, for eksempel en API-nøkkel, passord, token eller sertifikat. Den vanligste ulykken i AI-prosjekter er når modellleverandørens API-nøkkel er innebygd i koden og lekker inn i versjonskontroll (Git).
Riktig søknad:
- Legg aldri inn nøkler i kode; Bruk en miljøvariabel eller et hemmelig styringssystem (en tjeneste som lagrer nøkler kryptert og kontrollerer tilgang).
- Rotasjon: Forny nøkler med jevne mellomrom (f.eks. hver 90. dag); Hvis det er mistanke om lekkasje, avbryt umiddelbart.
- Omfangsreduksjon: Hver bryter har kun nødvendig service og nødvendig autorisasjon.
- Revisjon: Logg hvem som brukte nøkkelen, når og hvor.
Fire kopierbare maler
Forespørsel om kontroll av tilgangskontroll:
For hvert verktøy i verktøylisten nedenfor, evaluer:- Er dette verktøyet PÅHOV for å utføre denne assistentens jobb? (ja/nei) - Er det skrivebeskyttet eller skriv/slett? – Kalles dette verktøyet med brukerens autoritet eller tjenestekonto? Merk unødvendige eller overdrevent autoriserte som "FJERN/REDAKTERE".<tools>{{ tool_list }}</tools>
Hemmelig lekkasjeskanning:
Finn alt som kan være en hardkodet hemmelighet i følgende kodebit: API-nøkkel, passord, token, tilkoblingsstreng, privat nøkkel. Oppgi rad og type for hver. COPY verdi inn i respons;maske (første 4 tegn + ***).<code>{{ source }}</code>
Regel for minste myndighetsvedtak:
Når et nytt verktøy/tilgangsforespørsel kommer, spør:1. Kan oppgaven utføres uten denne tilgangen? -> Hvis ja: AVVIS2. Er skrivebeskyttet nok? -> Hvis ja: GIR skrivetillatelse3. Kan omfanget begrenses til én enkelt kilde? -> Hvis ja: daratStandardsvaret er "nei"; Tilgang oppnås av grunn.
Rotasjonskalenderpåminnelse:
For hver hemmelighet, noter: eier, opprettelsesdato, utløp, omfang. Rapporter enhver nøkkel som har overskredet 90 dager eller ikke har vært brukt på 30 dager som en "ROTASJON/KANSELLERINGSKANDIDAT".
Svak forespørsel / sterk forespørsel
dårlig tilnærming
Sterk tilnærming
Modellen får tilgang til alle data med én enkelt tjenestekonto
Modellen får tilgang med autoriteten til brukeren som sender forespørselen
API-nøkkel er innebygd i koden, den endres aldri
Rotasjon i nøkkelhemmelig leder, 90 dager
Bred «gjør hva som helst»-myndighet til assistenten
Skrivebeskyttet standard, skriv smalt
Tilganger blir aldri vurdert
Regelmessig tilgangsgjennomgang og tilbakekall
Tre minivesker
Tilfelle 1 — Lekkede blandede proxy-data. En intern assistent jobbet med en tjenestekonto som hadde tilgang til alle ansattes journaler. En intern bruker fikk tilgang til data som han normalt ikke ville se ved å si "oppsummer lønnstabellen for ledere"; fordi modellen stilte spørsmål ved den i sammenheng med sin egen brede autoritet, ikke brukerens. Når brukerkonteksten var justert for å bli flyttet, kunne praktikanten trekke opptak som bare han eller hun kunne se.
Sak 2 — Lekk nøkkel, 190 000 TL regning på 2 uker. En utvikler innebygde modell-API-nøkkelen i et hjelpeskript og presset den til et offentlig depot. En bot fant nøkkelen på 40 minutter og brukte den i to uker; Regningen nådde 190 000 TL. Da nøkkelen ble flyttet til den hemmelige lederen, koblet til rotasjon, og depotskanning ble lagt til, gjentok ikke hendelsen seg.
Tilfelle 3 — Skrivebeskyttet standard forhindret avbrudd. En DevOps-assistent mottok en "tilbakestill produksjonsdatabase"-kommando via ledetekstinjeksjon. Assistenten fikk imidlertid bare et skrivebeskyttet tegn; skriv/slett var i en egen godkjent flyt. Kommandoen ble avvist med autorisasjonsfeil og hendelsen ble logget som en alarm; Det var ingen tap av data.
Tips: Gjør "nei" til ditt standardsvar på en ny tilgangsforespørsel. Tilgang er noe som oppnås gjennom begrunnelse; Å gi alle brede og deretter kutte ned er nesten aldri gjort, og risikoen hoper seg opp.
Vanlige feil
- Kjører modellen med en stor tjenestekonto og mister brukerkonteksten (mixed proxy).
- Bygge inn API-nøkkelen i koden og lekke den inn i versjonskontroll.
- Roterer ikke tastene i det hele tatt ("jobber, ikke rør").
- Gir assistenten skrive-/slettetillatelser som standard.
- Gi tilgang én gang og aldri revurdere den.
- Forveksler autentisering med autorisasjon og antar at "han er pålogget, han har tilgang til alt".
Oppsummert
- Autentisering er et spørsmål om "hvem er du", autorisasjon er et spørsmål om "hva kan du gjøre"; I AI må begge operere i konteksten til brukeren.
- Modellen bør operere med autoriteten til brukeren som sender forespørselen, ikke med sin egen brede myndighet (unngå risikoen for blandet byrå).
- Start med RBAC, utdyp med ABAC på sensitive data; Gjør minimal autoritet til standard.
- Ikke begrav hemmeligheter i kode; lagre den i den hemmelige lederen, avgrens den og sett den i vanlig rotasjon.
- Den skrivebeskyttede standarden og den smale skrivingen begrenser i stor grad virkningen av injeksjon.
Søknadsoppgave
List opp alle verktøyene og dataene AI-assistenten din får tilgang til. Svar på tre spørsmål for hver: (1) Er det virkelig nødvendig? (2) Er skrivebeskyttet nok? (3) Kjører det i brukersammenheng? Søk deretter etter alle hardkodede hemmeligheter (via skanneprompten ovenfor) og skriv en rotasjonsplan for hver nøkkel du finner. Fjern minst én unødvendig autorisasjon.
sjekkliste
- [ ] Modellen kjører i autoritetskonteksten til brukeren som sender forespørselen.
- [ ] Verktøy- og datatilgang er blitt begrenset til prinsippet om minste privilegium.
- [ ] Skriv/slett er atskilt fra skrivebeskyttet, autentisert og smal.
- [ ] Ingen hemmeligheter er begravet i koden; Det oppbevares i den hemmelige lederen.
- [ ] Det er en rotasjonsplan og kanselleringsprosedyre for nøkler.
- [ ] Tilganger gjennomgås jevnlig.