Åtkomstkontroll, identitets- och hemlighetshantering

Vinster:

• Möjlighet att separera autentisering och auktorisering och tillämpa minimibehörighet med RBAC/ABAC
• Möjlighet att undvika blandad proxyrisk genom att köra modellen i användarsammanhang
• Möjlighet att lagra och rotera API-nycklar med det hemliga hanteringssystemet

En betydande del av attackerna på ett AI-system börjar inte med att "lura" modellen, utan med en stulen API-nyckel eller ett överauktoriserat konto. Det här säkerhetsskiktet kommer från klassisk informationssäkerhet, men lägger till nya risker i AI-sammanhang: en modell ringer en åktur för någon annans räkning, ett tjänstekonto får tillgång till all data, en nyckel läcker till GitHub. I den här enheten kommer vi att lära oss hur man begränsar åtkomsten till AI-systemet med autentisering, auktorisering (RBAC/ABAC), minimibehörighet och hemlig hantering.

Skillnaden mellan autentisering och auktorisering

De två termerna blandas ofta ihop:

• Autentisering: "Vem är du?" — bevisa att användaren/tjänsten verkligen är den de utger sig för att vara (lösenord, token, certifikat, MFA).
• Auktorisering: "Vad kan du göra?" — bestämma vilken resurs/åtgärd den autentiserade parten kan komma åt.

Den kritiska subtiliteten i AI-system är denna: när modellen utför arbete på uppdrag av en användare, fungerar den med den användarens auktoritet eller med ett brett tjänstkonto? Det senare är farligt — eftersom modellen som luras av injektionen får full tillgång till tjänstekontot.

Varning: "Förvirrad ställföreträdare"-problem: en användare med låg auktoritet får indirekt tillgång till data som han inte kan komma åt genom att lägga ut en modell med hög auktoritet. Modellen ska alltid verka inom ramen för användarens auktoritet, inte hans egen breda auktoritet.

RBAC och ABAC

• RBAC (Role-Based Access Control): Åtkomst beror på användarens roll. Rollen "supportspecialist" kan läsa kundanteckningar, men kan inte ta bort dem. Enkelt och vanligt.
• ABAC (Attribut-Based Access Control): Åtkomst beror på attribut: användarens avdelning, sekretessetiketten för data, tid på dygnet, nätverket från vilket förfrågan kommer. Mer finstämd men mer komplex.

De flesta organisationer börjar med RBAC och fördjupar sig till ABAC för känsliga uppgifter. Tumregel för AI: modellen bör filtrera varje agent den anropar och alla data den kommer åt baserat på rollen/attributen för användaren som gör begäran.

Steg för steg: Utöva minimal auktoritet

1. Inventera. Vilka verktyg kallar modellen, vilken data har den åtkomst till? Lista dem alla.
2. Motivera varje åtkomst. "Behöver den här assistenten verkligen ta bort behörighet?" Annars, ta bort den.
3. Skrivskyddad standard. Modellen ska kunna läsa som standard; Kräv skriv/ta bort separat token med smalt omfång.
4. Flytta användarkontext. Ring fordonet med användarens behörighet, inte med servicekontot.
5. Kortlivad legitimation. Använd kortlivade, automatiskt förnyande tokens istället för långlivade nycklar.

Hemlig hantering

En hemlighet är autentiseringsuppgifter som måste förbli hemliga, till exempel en API-nyckel, lösenord, token eller certifikat. Den vanligaste olyckan i AI-projekt är när modellleverantörens API-nyckel är inbäddad i koden och läcker in i versionskontroll (Git).

Rätt tillämpning:

• Bädda aldrig in nycklar i kod; Använd en miljövariabel eller ett hemligt hanteringssystem (en tjänst som lagrar nycklar krypterade och kontrollerar åtkomst).
• Rotation: Förnya nycklar med jämna mellanrum (t.ex. var 90:e dag); Om läckage misstänks, avbryt omedelbart.
• Omfattningsminskning: Varje växel har endast den nödvändiga servicen och erforderliga auktoriseringen.
• Granskning: Logga vem som använde nyckeln, när och var.

Fyra kopieringsbara mallar

Kontrollprompt för åtkomstgranskning:

För varje verktyg i verktygslistan nedan, utvärdera:- Behövs detta verktyg för att utföra denna assistents jobb? (ja/nej) - Är det skrivskyddat eller skriv/radera? - Anropas det här verktyget med användarens behörighet eller tjänstekonto? Markera onödiga eller överdrivet auktoriserade som "TA BORT/REDIGERA".<tools>{{ tool_list }}</tools>

Uppmaning om hemlig läckagescanning:

Hitta allt som kan vara en hårdkodad hemlighet i följande kodavsnitt: API-nyckel, lösenord, token, anslutningssträng, privat nyckel. Ange rad och typ för varje. COPY value into response;mask (första 4 tecknen + ***).<code>{{ source }}</code>

Regel för minst myndighetsbeslut:

När ett nytt verktyg/åtkomstbegäran kommer, fråga:1. Kan uppgiften utföras utan denna åtkomst? -> Om ja: AVVISA2. Räcker det med skrivskydd? -> Om ja: GE skrivbehörighet3. Kan omfattningen begränsas till en enda källa? -> Om ja: daratStandardsvaret är "nej"; Tillgång erhålls av skäl.

Påminnelse om rotationskalender:

För varje hemlighet, post: ägare, skapelsedatum, utgångsdatum, omfattning. Rapportera vilken nyckel som helst som har överskridit 90 dagar eller inte har använts på 30 dagar som en "ROTATION/AVBOKNINGSKANDIDAT".

Svag prompt / Stark prompt

dåligt tillvägagångssätt

Starkt förhållningssätt

Modellen kommer åt all data med ett enda tjänstkonto

Modellen får åtkomst med behörighet hos användaren som gör begäran

API-nyckeln är inbäddad i koden, den ändras aldrig

Rotation i nyckelhemlig chef, 90 dagar

Bred "gör vad som helst"-befogenhet till assistenten

Skrivskyddad standard, skriv smalt

Åtkomster granskas aldrig

Regelbunden åtkomstgranskning och återkallelse

Tre minifodral

Fall 1 — Läckta blandade proxydata. En intern assistent arbetade med ett servicekonto som hade tillgång till alla anställdas register. En praktikantanvändare fick tillgång till data som han normalt inte skulle se genom att säga "sammanfatta chefslönetabellen"; eftersom modellen ifrågasatte den inom ramen för sin egen breda auktoritet, inte användarens. När användarkontexten justerades för att flyttas kunde praktikanten dra inspelningar som bara han eller hon kunde se.

Fall 2 — Läckt nyckel, 190 000 TL räkning på 2 veckor. En utvecklare bäddade in modellens API-nyckel i ett hjälpskript och skickade den till ett offentligt arkiv. En bot hittade nyckeln på 40 minuter och använde den i två veckor; Notan nådde 190 000 TL. När nyckeln flyttades till den hemliga hanteraren, kopplades till rotation och förvarsskanning lades till, återkom inte incidenten.

Fall 3 — Skrivskyddad standard förhindrat avbrott. En DevOps-assistent fick kommandot "återställ produktionsdatabas" via snabbinjektion. Assistenten fick dock endast en skrivskyddad token; skriv/radering var i ett separat godkänt flöde. Kommandot avvisades med auktoriseringsfel och händelsen loggades som ett larm; Det var ingen dataförlust.

Tips: Gör "nej" till ditt standardsvar på en ny åtkomstförfrågan. Tillgång är något som uppnås genom motivering; Att ge alla breda och sedan skära ner görs nästan aldrig och risken ackumuleras.

Vanliga misstag

• Kör modellen med ett stort tjänstekonto och förlorar användarkontexten (mixed proxy).
• Bädda in API-nyckeln i koden och läcker den till versionskontroll.
• Roterar inte tangenterna alls ("arbetar, rör inte").
• Ge assistenten skriv-/raderingsbehörigheter som standard.
• Bevilja åtkomst en gång och aldrig ompröva det.
• Blandar ihop autentisering med auktorisering och antar att "han är inloggad, han kan komma åt allt".

Sammanfattningsvis

• Autentisering är en fråga om "vem är du", auktorisation är en fråga om "vad kan du göra"; I AI måste båda fungera i användarens sammanhang.
• Modellen bör fungera med auktoriteten hos användaren som gör begäran, inte med sin egen breda auktoritet (för att undvika risken för blandad byrå).
• Börja med RBAC, fördjupa med ABAC på känsliga uppgifter; Gör minimal auktoritet till standard.
• Begrav inte hemligheter i kod; lagra den i den hemliga hanteraren, begränsa den och lägg den i regelbunden rotation.
• Den skrivskyddade standardinställningen och den smala skrivningen begränsar kraftigt effekten av injektion.

Applikationsuppgift

Lista alla verktyg och data som din AI-assistent har åtkomst till. Svara på tre frågor för varje: (1) Är det verkligen nödvändigt? (2) Är skrivskyddad nog? (3) Körs det i användarsammanhang? Sök sedan efter alla hårdkodade hemligheter (via skanningsprompten ovan) och skriv en rotationsplan för varje nyckel du hittar. Ta bort minst en onödig auktorisering.

checklista

• [ ] Modellen körs i auktoritetssammanhang för användaren som gör begäran.
• [ ] Verktygs- och dataåtkomst har begränsats till principen om minsta privilegium.
• [ ] Skriv/radera är separat från skrivskyddat, autentiserat och smalt.
• [ ] Inga hemligheter är begravda i koden; Den förvaras i den hemliga chefen.
• [ ] Det finns ett rotationsschema och avbokningsprocedur för nycklar.
• [ ] Åtkomster ses över regelbundet.