Winst:
- Mogelijkheid om authenticatie en autorisatie te scheiden en minimale autorisatie toe te passen met RBAC/ABAC
- Mogelijkheid om gemengd proxyrisico te vermijden door het model in de gebruikerscontext uit te voeren
- Mogelijkheid om API-sleutels op te slaan en te roteren met het geheimbeheersysteem
Een aanzienlijk deel van de aanvallen op een AI-systeem begint niet met het ‘misleiden’ van het model, maar met een gestolen API-sleutel of een overmatig geautoriseerd account. Deze beveiligingslaag komt voort uit de klassieke informatiebeveiliging, maar voegt nieuwe risico's toe in de context van AI: een model roept een rit aan namens iemand anders, een serviceaccount heeft toegang tot alle gegevens, een sleutel lekt naar GitHub. In deze unit leren we hoe we de toegang tot het AI-systeem kunnen beperken met authenticatie, autorisatie (RBAC/ABAC), minimale autorisatie en geheimbeheer.
Verschil tussen authenticatie en autorisatie
De twee termen worden vaak verward:
- Authenticatie: "Wie ben jij?" — bewijzen dat de gebruiker/dienst werkelijk is wie hij beweert te zijn (wachtwoord, token, certificaat, MFA).
- Machtiging: "Wat kunt u doen?" — bepalen tot welke bron/actie de geauthenticeerde partij toegang heeft.
De cruciale subtiliteit van AI-systemen is deze: wanneer het model werk uitvoert namens een gebruiker, werkt het dan met de autoriteit van die gebruiker of met een breed serviceaccount? Dit laatste is gevaarlijk – omdat het model dat door de injectie wordt misleid volledige toegang krijgt tot het serviceaccount.
Let op: "Verward plaatsvervanger"-probleem: een gebruiker met lage autoriteit heeft indirect toegang tot gegevens waartoe hij geen toegang heeft door een model met hoge autoriteit uit te besteden. Het model moet altijd opereren binnen de context van de autoriteit van de gebruiker, niet zijn eigen brede autoriteit.
RBAC en ABAC
- RBAC (Role-Based Access Control): Toegang is afhankelijk van de rol van de gebruiker. De rol 'ondersteuningsspecialist' kan klantnotities lezen, maar kan deze niet verwijderen. Eenvoudig en gebruikelijk.
- ABAC (Attribute-Based Access Control): Toegang is afhankelijk van attributen: de afdeling van de gebruiker, het privacylabel van de gegevens, het tijdstip van de dag, het netwerk waarvan het verzoek afkomstig is. Verfijnder, maar complexer.
De meeste organisaties beginnen met RBAC en verdiepen zich naar ABAC voor gevoelige gegevens. Vuistregel voor AI: het model moet elke agent die het oproept en alle gegevens waartoe het toegang heeft, filteren op basis van de rol/kenmerken van de gebruiker die het verzoek doet.
Stap voor stap: minimale autoriteit uitoefenen
- Inventariseer. Welke tools roept het model op, tot welke gegevens heeft het toegang? Maak een lijst van ze allemaal.
- Motiveer elke toegang. "Heeft deze assistent echt verwijderbevoegdheid nodig?" Verwijder het anders.
- Standaard alleen-lezen. Het model zou standaard moeten kunnen lezen; Vereist een afzonderlijk token met beperkte reikwijdte om te schrijven/verwijderen.
- Verplaats gebruikerscontext. Bel het voertuig met de bevoegdheid van de gebruiker, niet met het serviceaccount.
- Diploma van korte duur. Gebruik kortstondige, automatisch vernieuwende tokens in plaats van sleutels met een lange levensduur.
Geheim beheer
Een geheim zijn inloggegevens die geheim moeten blijven, zoals een API-sleutel, wachtwoord, token of certificaat. Het meest voorkomende ongeluk bij AI-projecten is wanneer de API-sleutel van de modelaanbieder in de code is ingebed en in versiebeheer (Git) lekt.
Juiste toepassing:
- Sluit nooit sleutels in code in; Gebruik een omgevingsvariabele of een geheimbeheersysteem (een service die sleutels gecodeerd opslaat en de toegang controleert).
- Rotatie: Vernieuw sleutels met regelmatige tussenpozen (bijvoorbeeld elke 90 dagen); Als er een lek wordt vermoed, annuleer dan onmiddellijk.
- Reikwijdtereductie: Elke schakelaar heeft alleen de benodigde service en benodigde autorisatie.
- Audit: log wie de sleutel heeft gebruikt, wanneer en waar.
Vier kopieerbare sjablonen
Toegangscontrolecontroleprompt:
Evalueer voor elk gereedschap in de onderstaande gereedschapslijst: - Is dit gereedschap VEREIST om de taak van deze assistent uit te voeren? (ja/nee) - Is het alleen-lezen of schrijven/wissen? - Wordt deze tool aangeroepen met de autoriteit of het serviceaccount van de gebruiker? Markeer onnodige of overdreven geautoriseerde bestanden als "VERWIJDEREN/REDACTEREN".<tools>{{ tool_list }}</tools>
Geheime lekscanprompt:
Zoek alles wat een hardgecodeerd geheim zou kunnen zijn in het volgende codefragment: API-sleutel, wachtwoord, token, verbindingsreeks, privésleutel. Geef voor elk rij en type op. KOPIEER waarde naar antwoord;masker (eerste 4 tekens + ***).<code>{{ source }}</code>
Beslisregel met de minste autoriteit:
Wanneer er een nieuw hulpmiddel/toegangsverzoek binnenkomt, vraagt u het volgende: 1. Kan de taak worden uitgevoerd zonder deze toegang? -> Zo ja: WEIGEREN2. Is alleen-lezen voldoende? -> Indien ja: VERLEEN schrijftoestemming3. Kan de reikwijdte worden beperkt tot één enkele bron? -> Indien ja: daratHet standaardantwoord is "nee"; Toegang wordt verkregen door de rede.
Herinnering rotatiekalender:
Leg voor elk geheim vast: eigenaar, aanmaakdatum, vervaldatum, reikwijdte. Rapporteer elke sleutel die de 90 dagen heeft overschreden of 30 dagen niet is gebruikt als "ROTATIE/ANNULATIEKANDIDAAT".
Zwakke prompt/sterke prompt
slechte aanpak
Sterke aanpak
Model heeft toegang tot alle gegevens met één serviceaccount
Het model heeft toegang met de autoriteit van de gebruiker die het verzoek doet
De API-sleutel is ingebed in de code en verandert nooit
Rotatie in sleutelgeheimmanager, 90 dagen
Brede "doe alles"-bevoegdheid voor de assistent
Alleen-lezen standaard, schrijf nauw
Toegangen worden nooit beoordeeld
Regelmatige toegangscontrole en intrekking
Drie mini-hoesjes
Geval 1 – Gelekte gemengde proxygegevens. Een interne assistent werkte met een serviceaccount die toegang had tot alle werknemersgegevens. Een stagiaire-gebruiker kreeg toegang tot gegevens die hij normaal niet zou zien door te zeggen "vat de salaristabel van managers samen"; omdat het model dit in twijfel trok in de context van zijn eigen brede autoriteit, en niet die van de gebruiker. Nadat de gebruikerscontext was aangepast om te worden verplaatst, kon de stagiair opnames maken die alleen hij of zij kon zien.
Geval 2 – Gelekte sleutel, factuur van 190.000 TL in 2 weken. Een ontwikkelaar heeft de model-API-sleutel in een helperscript ingebed en naar een openbare opslagplaats gepusht. Een bot vond de sleutel in 40 minuten en gebruikte hem twee weken; De rekening bereikte 190.000 TL. Toen de sleutel werd verplaatst naar de geheime manager, verbonden met rotatie, en het scannen van de repository werd toegevoegd, deed het incident zich niet meer voor.
Geval 3 — Alleen-lezen standaard voorkomen interrupt. Een DevOps-assistent ontving via promptinjectie de opdracht "reset production database". De assistent kreeg echter alleen een alleen-lezen-token; schrijven/wissen bevond zich in een afzonderlijke goedgekeurde stroom. Het commando werd afgewezen vanwege een autorisatiefout en de gebeurtenis werd geregistreerd als alarm; Er was geen gegevensverlies.
Tip: Maak van 'nee' uw standaardantwoord op een nieuw toegangsverzoek. Toegang is iets dat wordt verkregen door rechtvaardiging; Iedereen de ruimte geven en dan bezuinigen is bijna nooit gedaan en het risico stapelt zich op.
Veel voorkomende fouten
- Het model uitvoeren met een groot serviceaccount en de gebruikerscontext verliezen (gemengde proxy).
- Het inbedden van de API-sleutel in de code en het lekken ervan in versiebeheer.
- De toetsen helemaal niet draaien ("werken, niet aanraken").
- De assistent standaard schrijf-/verwijderrechten geven.
- Eén keer toegang verlenen en er nooit meer over nadenken.
- Authenticatie verwarren met autorisatie en aannemen dat "hij ingelogd is, hij heeft toegang tot alles".
Samengevat
- Authenticatie is een kwestie van “wie ben je”, autorisatie is een kwestie van “wat kun je doen”; Bij AI moeten beide opereren in de context van de gebruiker.
- Het model moet werken met de autoriteit van de gebruiker die het verzoek doet, en niet met zijn eigen brede autoriteit (waarmee het risico van gemengd handelen wordt vermeden).
- Begin met RBAC, verdiep je met ABAC op gevoelige data; Maak van minimale autoriteit de standaard.
- Begraaf geheimen niet in code; bewaar het in de geheime manager, beperk het en zorg ervoor dat het regelmatig wordt gerouleerd.
- De alleen-lezen standaard en smalle schrijfwijze beperken de impact van injectie aanzienlijk.
Applicatie taak
Maak een lijst van alle tools en gegevens waartoe uw AI-assistent toegang heeft. Beantwoord voor elk drie vragen: (1) Is het echt nodig? (2) Is alleen-lezen voldoende? (3) Wordt het uitgevoerd in gebruikerscontext? Zoek vervolgens naar alle hardgecodeerde geheimen (via de scanprompt hierboven) en schrijf een rotatieplan voor elke sleutel die je vindt. Verwijder ten minste één onnodige autorisatie.
controlelijst
- [ ] Het model draait in de autoriteitscontext van de gebruiker die het verzoek doet.
- [ ] Toegang tot tools en gegevens is beperkt tot het principe van de minste privileges.
- [ ] Schrijven/wissen staat los van alleen-lezen, geverifieerd en smal.
- [ ] Er liggen geen geheimen verborgen in de code; Het wordt bewaard in de geheime manager.
- [ ] Er is een roulatieschema en annuleringsprocedure voor sleutels.
- [ ] Toegangen worden regelmatig beoordeeld.