Scrivere politiche in linguaggio naturale
Policy in AgentCore selezionerà automaticamente l'area geografica ottimale per elaborare le richieste di inferenza effettuate tramite il servizio di creazione delle politiche. Ciò ottimizza le risorse di elaborazione disponibili, la disponibilità dei modelli e offre la migliore esperienza del cliente. I dati rimarranno archiviati solo nella regione in cui ha avuto origine la richiesta, tuttavia, le richieste di input e i risultati di output potrebbero essere elaborati al di fuori di tale regione. Tutti i dati verranno trasmessi in modalità crittografata attraverso la rete sicura di Amazon.
Policy in AgentCore indirizzerà in modo sicuro le tue richieste di inferenza verso le risorse di calcolo disponibili all'interno dell'area geografica in cui ha avuto origine la richiesta, come segue:
-
Le richieste di inferenza provenienti dall'Unione Europea verranno elaborate all'interno dell'Unione Europea.
-
Le richieste di inferenza provenienti dagli Stati Uniti verranno elaborate all'interno degli Stati Uniti.
-
Le richieste di inferenza provenienti dall'APAC verranno elaborate all'interno dell'APAC.
Argomenti
Panoramica di
Cedar fornisce un controllo preciso degli accessi, ma richiede l'apprendimento della sintassi formale. NL2Cedar ti consente di:
-
Requisiti di autorizzazione alla scrittura in linguaggio naturale
-
Converti automaticamente nella sintassi Cedar
-
Verifica che le politiche generate soddisfino i tuoi requisiti
Nota
La generazione di policy in linguaggio naturale richiede un AgentCore gateway e un motore di policy implementati. Il servizio utilizza lo schema AgentCore Gateway per generare politiche Cedar valide. Vedi Guida introduttiva a Policy in AgentCore per le istruzioni di configurazione.
Nota
Il linguaggio naturale è flessibile, ma la precisione è essenziale per la sicurezza. Le politiche devono essere chiare e inequivocabili.
Esempio
La politica di rimborso della sezione precedente può essere espressa in linguaggio naturale:
Linguaggio naturale:
Consenti al gestore con nome utente «refund-agent» di elaborare i rimborsi quando l'importo del rimborso è inferiore a 500 USD.
Converte in cedro:
permit( principal is AgentCore::OAuthUser, action == AgentCore::Action::"RefundTool___process_refund", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/refund-gateway" ) when { principal.hasTag("username") && principal.getTag("username") == "refund-agent" && context.input.amount < 500 };
Effetti politici
Le politiche di autorizzazione hanno due effetti possibili: autorizzare e vietare.
Politiche di autorizzazione
Le politiche di autorizzazione specificano cosa possono fare gli utenti:
-
«Consenti all'utente refund-agent di elaborare i rimborsi»
-
«Consenti agli utenti con ruolo di direttore di approvare le decisioni»
-
«Autorizza gli utenti con scope admin:write ad aggiornare la copertura»
Polizze proibite
Le politiche di divieto specificano cosa non possono fare gli utenti:
-
«Impedisci agli utenti di accedere a modelli ad alta sensibilità»
-
«Impedire ai sottoscrittori junior di approvare le decisioni»
-
«Impedisci agli utenti di elaborare i rimborsi quando è in sospeso la convalida del rischio»
Semantica delle autorizzazioni
Comprendere come Cedar valuta le politiche è fondamentale per scrivere regole di autorizzazione efficaci. Cedar segue tre principi fondamentali:
-
Per impostazione predefinita, tutto è negato. Se nessuna politica consente esplicitamente un'azione, questa viene automaticamente bloccata
-
Proibisci vince sempre: se una politica di divieto corrisponde, l'accesso viene negato anche se anche le politiche di autorizzazione corrispondono
-
È richiesta almeno un'autorizzazione - Affinché l'accesso sia concesso, almeno una politica di autorizzazione deve corrispondere E nessuna politica di divieto può corrispondere
Perché utilizzare le politiche di divieto se tutto è negato per impostazione predefinita?
Le politiche di proibizione assicurano che azioni specifiche non possano essere consentite erroneamente. Anche se qualcuno scrive una politica di autorizzazione più ampia, la politica di divieto ha la precedenza e blocca l'accesso.
Scenario di esempio:
// Broad permit policy - allows all users to view model results permit( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ModelAPI___view_results", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model" ); // Forbid policy - blocks access to high-sensitivity results forbid( principal is AgentCore::OAuthUser, action == AgentCore::Action::"ModelAPI___view_results", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model" ) when { context.input.sensitivity == "high" };
Risultato: gli utenti possono visualizzare i risultati a bassa e media sensibilità (si applica l'autorizzazione), ma i risultati ad alta sensibilità vengono sempre bloccati (vietate le vittorie).
Utilizza le politiche di divieto per:
-
Restrizioni di sicurezza esplicite che non devono mai essere ignorate
-
Requisiti di conformità
-
Arresti di emergenza
-
Creazione di eccezioni a politiche di autorizzazione più ampie
Elementi delle policy
Le politiche di autorizzazione richiedono tre elementi chiave:
-
Chi: quali utenti o ruoli possono eseguire l'azione
-
Cosa: quali operazioni o strumenti possono utilizzare
-
Quando: in quali condizioni o vincoli
Specificazione principale
Il principale identifica gli utenti, i ruoli o i gruppi a cui si applica la politica.
Espressioni flessibili:
-
«Consenti all'utente refund-agent di...»
-
«Consenti agli utenti con nome utente refund-agent di...»
-
«Gli utenti con ruolo di agente assicurativo possono...»
-
«Chiunque disponga dell'ambito refund:write è autorizzato a...»
-
«Tutti gli utenti possono...»
Sii specifico sull'identità:
Incompleto: ❌ «Consenti l'elaborazione di rimborsi inferiori a 500 USD»
Completo: ✓ «Consenti all'agente addetto ai rimborsi di elaborare rimborsi inferiori a 500 USD»
Specificazione dell'azione
Il «cosa» identifica le operazioni, gli strumenti o le azioni controllate dalla politica.
Verbi d'azione flessibili:
-
«Consenti agli utenti di elaborare i rimborsi»
-
«Autorizza l'elaborazione dei rimborsi»
-
«Gli utenti possono creare applicazioni»
-
«Autorizza la visualizzazione dei registri di controllo»
Sii specifico sullo strumento:
Vago: ❌ «Consenti agli utenti di accedere ai modelli»
Chiaro: ✓ «Consenti al team di data science di accedere al modello di analisi»
Specificazione delle condizioni
Il «quando» specifica in quali circostanze si applica la politica.
Espressioni condizionali flessibili:
-
«... quando l'importo è inferiore a 500$»
-
«... se la regione è USA, CA o Regno Unito»
-
«... solo quando lo stato di approvazione è approvato dal responsabile»
-
«... a condizione che sia stato presentato il punteggio di rischio»
Sii preciso con le condizioni:
Vago: ❌ «Consenti i trasferimenti quando l'importo è ragionevole»
Preciso: ✓ «Consenti i trasferimenti quando l'importo è inferiore a 10.000$»
Esempi di policy
Gli esempi seguenti mostrano come strutturare le politiche del linguaggio naturale con principi, azioni e condizioni chiari.
Argomenti
Esempio 1: politica semplice User-Based
Consenti all'utente refund-agent di elaborare i rimborsi quando l'importo è inferiore a 500 USD.
Elementi:
-
Chi: user refund-agent
-
Che cosa: elaborare i rimborsi
-
Quando: l'importo è inferiore a 500$
Esempio 2: Role-Based con più condizioni
Consenti agli utenti con ruolo di agente assicurativo di aggiornare la copertura quando il tipo di copertura è responsabilità civile o collisione e la polizza è attiva.
Elementi:
-
Chi: utenti con ruolo di agente assicurativo
-
Che cosa: aggiornare la copertura
-
Quando: il tipo di copertura è responsabilità o collisione E la polizza è attiva
Esempio 3: accesso Scope-Based
Consenti agli utenti con scope travel:book di creare prenotazioni di voli quando la regione non è dell'UE e il prodotto è idoneo.
Elementi:
-
Chi: utenti con scope travel:book
-
Cosa: creare prenotazioni di voli
-
Quando: la regione non è dell'UE E il prodotto è idoneo
Esempio 4: chiunque abbia dei vincoli
Consenti a tutti gli utenti di visualizzare i risultati del modello quando la sensibilità dei dati è bassa o media e il tipo di risultato è rischio-punteggio.
Elementi:
-
Chi: tutti gli utenti
-
Cosa: visualizza i risultati del modello
-
Quando: la sensibilità dei dati è bassa o media E il tipo di risultato è un punteggio di rischio
Sintassi delle condizioni
Le condizioni sono quelle in cui le politiche spesso diventano ambigue. Ecco come scrivere condizioni chiare e verificabili.
Confronti numerici
Buoni esempi:
-
«quando l'importo è inferiore a 500$»
-
«quando l'importo della copertura è inferiore a 5 milioni»
-
«quando il reclamo supera i 10.000.000 di dollari»
-
«quando il numero di passeggeri è esattamente 2"
Evita termini vaghi:
-
❌ «quando l'importo è piccolo»
-
❌ «quando la copertura è elevata»
Abbinamento di stringhe
Corrispondenza esatta:
-
«quando la regione sono gli Stati Uniti»
-
«quando il metodo di pagamento è la carta di credito»
-
«quando lo stato è approvato»
Molteplici opzioni:
-
«quando la regione è USA o CA o Regno Unito»
-
«quando il tipo di decisione è approvare o rinviare»
Corrispondenza del modello:
-
«quando l'e-mail contiene @example .com»
-
«quando l'ambito contiene admin:write»
Negazione:
-
«quando la regione non è l'UE»
-
«quando la classificazione non è limitata»
Condizioni booleane
Controlli diretti:
-
«quando il prodotto è idoneo»
-
«quando viene inviato il punteggio di rischio»
-
«quando è richiesta la spedizione espressa»
Negazione:
-
«quando il prodotto non è idoneo»
-
«quando il punteggio di rischio non viene inviato»
Esistenza del campo
Campi obbligatori:
-
«quando viene fornito un motivo»
-
«quando esiste un ID dell'applicazione»
-
«quando viene specificata la data di ritorno»
Combinazione delle condizioni
Le politiche reali spesso richiedono più condizioni. Usa connettori logici chiari.
AND Logic (tutto deve essere vero)
Usa parole come: «e», «anche», «inoltre», «mentre», «con»
Esempio:
Consenti le candidature quando la regione è gli Stati Uniti, il prodotto è idoneo e il territorio è attivo.
O logica (almeno una deve essere vera)
Usa parole come: «o», «alternativamente», «entrambi»
Esempio:
Consenti l'approvazione quando il reclamo supera i 10.000.000 di dollari o se il livello di rischio è elevato o critico.
Logica complessa
Per condizioni complesse, usa una struttura chiara:
Esempio:
Consenti la finalizzazione quando la fase di revisione o approvazione del flusso di lavoro è completata o approvata, lo stato di conformità viene superato e l'autorità è responsabile o direttore.
Insidie comuni
Evita questi errori comuni quando scrivi politiche in linguaggio naturale per assicurarti che vengano convertite correttamente nella sintassi Cedar.
Argomenti
Errore 1: Principi vaghi
Sbagliato: «Consenti l'accesso allo strumento di rimborso»
Buono: «Consenti all'utente refund-agent di accedere allo strumento di rimborso»
Errore 2: azioni ambigue
Scorretto: «Consenti agli utenti di accedere ai dati»
Buono: «Consenti agli utenti di visualizzare le cartelle cliniche dei pazienti»
Errore 3: condizioni soggettive
Sbagliato: «Consenti i trasferimenti quando l'importo è ragionevole»
Buono: «Consenti i trasferimenti quando l'importo è inferiore a 10.000 USD»
Errore 4: condizioni mancanti
Scorretto: «Consenti agli utenti con scope admin:write di aggiornare la copertura»
Buono: «Consenti agli utenti con scope admin:write di aggiornare la copertura quando la polizza è attiva e il tipo di copertura è responsabilità o collisione»
Errore 5: logica poco chiara
Sbagliato: «Consenti quando A o B e C»
Buono: «Consenti quando (A o B) e C» o «Consenti quando A o (B e C)»
