Controllo accessi, gestione identità e segreti

Guadagni:

• Possibilità di separare l'autenticazione e l'autorizzazione e di applicare l'autorizzazione minima con RBAC/ABAC
• Capacità di evitare il rischio proxy misto eseguendo il modello nel contesto utente
• Possibilità di archiviare e ruotare le chiavi API con il sistema di gestione dei segreti

Una parte significativa degli attacchi a un sistema di intelligenza artificiale non inizia con l’”inganno” del modello, ma con una chiave API rubata o un account eccessivamente autorizzato. Questo livello di sicurezza deriva dalla classica sicurezza informatica, ma aggiunge nuovi rischi nel contesto dell'intelligenza artificiale: un modello chiede un passaggio per conto di qualcun altro, un account di servizio accede a tutti i dati, una chiave trapela su GitHub. In questa unità impareremo come restringere l'accesso al sistema AI con autenticazione, autorizzazione (RBAC/ABAC), autorizzazione minima e gestione dei segreti.

Differenza tra autenticazione e autorizzazione

I due termini vengono spesso confusi:

• Autenticazione: "Chi sei?" — dimostrare che l'utente/servizio è realmente chi dichiara di essere (password, token, certificato, MFA).
• Autorizzazione: "Cosa puoi fare?" — determinare a quale risorsa/azione può accedere la parte autenticata.

La sottigliezza fondamentale nei sistemi di intelligenza artificiale è questa: quando il modello esegue un lavoro per conto di un utente, opera con l’autorità di quell’utente o con un ampio account di servizio? Quest’ultima cosa è pericolosa perché il modello ingannato dall’iniezione ottiene pieno accesso al conto del servizio.

Attenzione: problema del "vice confuso": un utente con autorità bassa accede indirettamente ai dati a cui non può accedere esternalizzando un modello con autorità alta. Il modello dovrebbe sempre operare nel contesto dell'autorità dell'utente, non della sua ampia autorità.

RBAC e ABAC

• RBAC (controllo dell'accesso basato sul ruolo): l'accesso dipende dal ruolo dell'utente. Il ruolo di "specialista dell'assistenza" può leggere le note del cliente, ma non può eliminarle. Semplice e comune.
• ABAC (Attribute-Based Access Control): L'accesso dipende dagli attributi: il dipartimento dell'utente, l'etichetta di privacy dei dati, l'ora del giorno, la rete da cui proviene la richiesta. Più raffinato ma più complesso.

La maggior parte delle organizzazioni inizia con RBAC e approfondisce ABAC per i dati sensibili. Regola pratica per l'intelligenza artificiale: il modello dovrebbe filtrare ogni agente che chiama e tutti i dati a cui accede in base al ruolo/attributi dell'utente che effettua la richiesta.

Passo dopo passo: esercitare un'autorità minima

1. Fai l'inventario. Quali strumenti chiama il modello, a quali dati accede? Elencarli tutti.
2. Giustificare ogni accesso. "Questo assistente ha davvero bisogno dell'autorizzazione all'eliminazione?" Altrimenti rimuovilo.
3. Impostazione predefinita di sola lettura. Il modello dovrebbe essere in grado di leggere per impostazione predefinita; Richiede scrittura/eliminazione token separato e con ambito ristretto.
4. Sposta il contesto utente. Chiama il veicolo con l'autorità dell'utente, non con l'account del servizio.
5. Credenziale di breve durata. Utilizza token di breve durata e con rinnovo automatico invece di chiavi di lunga durata.

Gestione segreta

Un segreto è costituito da credenziali che devono rimanere segrete, ad esempio una chiave API, una password, un token o un certificato. L'incidente più comune nei progetti di intelligenza artificiale è quando la chiave API del fornitore del modello è incorporata nel codice e penetra nel controllo della versione (Git).

Applicazione corretta:

• Non incorporare mai chiavi nel codice; Utilizza una variabile di ambiente o un sistema di gestione dei segreti (un servizio che archivia le chiavi crittografate e controlla l'accesso).
• Rotazione: rinnovare le chiavi a intervalli regolari (ad esempio ogni 90 giorni); Se si sospetta una perdita, annullare immediatamente.
• Riduzione della portata: ogni switch ha solo il servizio richiesto e l'autorizzazione richiesta.
• Audit: registra chi ha utilizzato la chiave, quando e dove.

Quattro modelli copiabili

Accedere alla richiesta di controllo della revisione:

Per ciascuno strumento nell'elenco degli strumenti riportato di seguito, valuta:- Questo strumento è NECESSARIO per eseguire il lavoro di questo assistente? (sì/no) - È di sola lettura o di scrittura/cancellazione? - Questo strumento viene chiamato con l'autorità dell'utente o con l'account di servizio? Contrassegna quelli non necessari o eccessivamente autorizzati come "RIMUOVI/REDACT".<tools>{{ tool_list }}</tools>

Richiesta di scansione delle perdite segrete:

Trova tutto ciò che potrebbe essere un segreto hardcoded nel seguente frammento di codice: chiave API, password, token, stringa di connessione, chiave privata. Fornisci riga e tipo per ciascuno. COPIA il valore nella risposta;maschera (primi 4 caratteri + ***).<codice>{{ source }}</code>

Regola decisionale con autorità minima:

Quando arriva un nuovo strumento/richiesta di accesso, chiedi:1. L'attività può essere eseguita senza questo accesso? -> Se sì: RIFIUTO2. La sola lettura è sufficiente? -> Se sì: CONCEDI il permesso di scrittura3. È possibile restringere il campo a un’unica fonte? -> Se sì: daratLa risposta predefinita è "no"; L'accesso avviene attraverso la ragione.

Promemoria del calendario di rotazione:

Per ogni segreto, registra: proprietario, data di creazione, scadenza, ambito. Segnalare come "CANDIDATO ROTAZIONE/CANCELLAZIONE" qualsiasi chiave che abbia superato i 90 giorni o che non sia stata utilizzata per 30 giorni.

Prompt debole / Prompt forte

approccio scadente

Approccio forte

Il modello accede a tutti i dati con un unico account di servizio

Il modello accede con l'autorità dell'utente che effettua la richiesta

La chiave API è incorporata nel codice e non cambia mai

Rotazione in chiave secret manager, 90 giorni

Ampia autorità di "fare qualsiasi cosa" conferita all'assistente

Impostazione predefinita di sola lettura, scrittura in senso stretto

Gli accessi non vengono mai controllati

Revisione e revoca periodica dell'accesso

Tre mini custodie

Caso 1: dati proxy misti trapelati. Un assistente interno lavorava con un account di servizio che aveva accesso a tutti i record dei dipendenti. Un utente stagista ha avuto accesso a dati che normalmente non avrebbe visto dicendo "riepiloga la tabella degli stipendi dei dirigenti"; perché il modello lo metteva in discussione nel contesto della sua ampia autorità, non di quella dell'utente. Una volta adattato il contesto dell'utente per lo spostamento, il tirocinante è stato in grado di estrarre registrazioni che solo lui o lei poteva vedere.

Caso 2: chiave smarrita, fattura da 190.000 TL in 2 settimane. Uno sviluppatore ha incorporato la chiave API del modello in uno script di supporto e l'ha inviata a un repository pubblico. Un bot ha trovato la chiave in 40 minuti e l'ha utilizzata per due settimane; Il conto ha raggiunto 190.000 TL. Quando la chiave è stata spostata nel gestore dei segreti, connessa alla rotazione ed è stata aggiunta la scansione del repository, l'incidente non si è ripetuto.

Caso 3: interruzione predefinita di sola lettura impedita. Un assistente DevOps ha ricevuto un comando di "reimpostazione del database di produzione" tramite prompt injection. Tuttavia, all'assistente è stato assegnato solo un token di sola lettura; la scrittura/cancellazione era in un flusso approvato separato. Il comando è stato rifiutato con errore di autorizzazione e l'evento è stato registrato come allarme; Non c'è stata alcuna perdita di dati.

Suggerimento: imposta "no" come risposta predefinita a una nuova richiesta di accesso. L'accesso è qualcosa che si ottiene attraverso la giustificazione; Dare a tutti e poi tagliare non è quasi mai fatto e il rischio si accumula.

Errori comuni

• Esecuzione del modello con un account di servizio di grandi dimensioni e perdita del contesto utente (proxy misto).
• Incorporando la chiave API nel codice e inserendola nel controllo della versione.
• Non ruotare affatto i tasti ("funzionante, non toccare").
• Fornire all'assistente le autorizzazioni di scrittura/eliminazione per impostazione predefinita.
• Concedere l'accesso una volta e non riconsiderarlo mai.
• Confondere l'autenticazione con l'autorizzazione e supporre che "ha effettuato l'accesso, può accedere a tutto".

In sintesi

• L'autenticazione è una questione di “chi sei”, l'autorizzazione è una questione di “cosa puoi fare”; Nell’intelligenza artificiale, entrambi devono operare nel contesto dell’utente.
• Il modello dovrebbe operare con l’autorità dell’utente che presenta la richiesta, non con la propria ampia autorità (evitando il rischio di un’agenzia mista).
• Iniziare con RBAC, approfondire con ABAC sui dati sensibili; Imposta l'autorità minima come predefinita.
• Non seppellire i segreti nel codice; memorizzalo nel gestore segreto, restringilo e mettilo in rotazione regolare.
• L'impostazione predefinita di sola lettura e la scrittura ristretta limitano notevolmente l'impatto dell'iniezione.

Compito dell'applicazione

Elenca tutti gli strumenti e i dati a cui accede il tuo assistente AI. Rispondi a tre domande per ciascuna: (1) È davvero necessario? (2) La sola lettura è sufficiente? (3) Viene eseguito nel contesto utente? Quindi cerca tutti i segreti codificati (tramite il prompt di scansione sopra) e scrivi un piano di rotazione per ogni chiave che trovi. Rimuovere almeno un'autorizzazione non necessaria.

lista di controllo

• [ ] Il modello viene eseguito nel contesto di autorità dell'utente che effettua la richiesta.
• [] L'accesso agli strumenti e ai dati è stato ristretto al principio del privilegio minimo.
• [ ] La scrittura/cancellazione è separata da quella di sola lettura, autenticata e limitata.
• [] Nessun segreto è sepolto nel codice; È conservato nel gestore segreto.
• [ ] Esiste un programma di rotazione e una procedura di cancellazione delle chiavi.
• [ ] Gli accessi vengono controllati regolarmente.