Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Scrivere politiche in linguaggio naturale
Policy in AgentCore selezionerà automaticamente la regione ottimale all'interno della tua area geografica per elaborare le richieste di inferenza effettuate tramite il servizio di creazione delle policy. Ciò massimizza le risorse di elaborazione disponibili, la disponibilità dei modelli e offre la migliore esperienza al cliente. I dati rimarranno archiviati solo nella regione di origine della richiesta, tuttavia, i prompt 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 richieste di inferenza alle 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 consente di:
-
Scrivere i requisiti di autorizzazione in linguaggio naturale
-
Converti automaticamente nella sintassi Cedar
-
Verifica che le politiche generate corrispondano ai 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 policy Cedar valide. Per le istruzioni di configurazione, consulta Getting started with Policy in AgentCore.
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 mandante con nome utente «refund-agent» di elaborare i rimborsi quando l'importo del rimborso è inferiore a $500.
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 possibili effetti: consentire e vietare.
Politiche di autorizzazione
Le politiche di autorizzazione specificano cosa possono fare gli utenti:
-
«Consenti all'agente di rimborso utente di elaborare i rimborsi»
-
«Consenti agli utenti con responsabile del ruolo di approvare le decisioni»
-
«Autorizza gli utenti con ambito admin:write to update coverage»
Proibisci le politiche
Le politiche di divieto specificano cosa non possono fare gli utenti:
-
«Impedisci agli utenti di accedere ai modelli ad alta sensibilità»
-
«Impedire ai sottoscrittori junior di approvare le decisioni»
-
«Proibisci agli utenti di elaborare rimborsi quando la convalida del rischio è in sospeso»
Semantica dell'autorizzazione
Comprendere come Cedar valuta le politiche è fondamentale per scrivere regole di autorizzazione efficaci. Cedar segue tre principi fondamentali:
-
Per impostazione predefinita, tutto viene negato: se nessuna policy consente esplicitamente un'azione, questa viene automaticamente bloccata
-
Il divieto vince sempre: se una qualsiasi politica di divieto corrisponde, l'accesso viene negato anche se anche le politiche di autorizzazione corrispondono
-
È richiesto almeno un permesso - Affinché l'accesso sia concesso, almeno una politica di autorizzazione deve corrispondere E nessuna politica di divieto può corrispondere
Perché usare le politiche di divieto se tutto viene negato per impostazione predefinita?
Le politiche di divieto assicurano che azioni specifiche non possano essere erroneamente consentite. Anche se qualcuno redige 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à sono sempre bloccati (vietate le vincite).
Utilizza le politiche di proibizione per:
-
Restrizioni di sicurezza esplicite che non devono mai essere ignorate
-
Requisiti di conformità
-
Arresti di emergenza
-
Creare 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
Specifiche principali
Il principale identifica gli utenti, i ruoli o i gruppi a cui si applica la policy.
Espressioni flessibili:
-
«Consenti all'agente di rimborso dell'utente di...»
-
«Consenti agli utenti con nome utente refund-agent di...»
-
«Gli utenti con il 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 incaricato dei rimborsi di elaborare rimborsi inferiori a 500 USD»
Specifiche dell'azione
Il «cosa» identifica le operazioni, gli strumenti o le azioni controllati dalla politica.
Verbi d'azione flessibili:
-
«Consenti agli utenti di elaborare i rimborsi»
-
«Consenti l'elaborazione dei rimborsi»
-
«Gli utenti possono creare applicazioni»
-
«Autorizza la visualizzazione dei log 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 è Stati Uniti, California o Regno Unito»
-
«... solo se lo stato di approvazione è approvato dal responsabile»
-
«... a condizione che il punteggio di rischio sia stato inviato»
Sii preciso con le condizioni:
Vago: ❌ «Consenti i trasferimenti quando l'importo è ragionevole»
Preciso: ✓ «Consenti trasferimenti quando l'importo è inferiore a 10.000$»
Esempi di policy
Gli esempi seguenti dimostrano come strutturare le politiche in linguaggio naturale con principi, azioni e condizioni chiari.
Argomenti
Esempio 1: Politica semplice User-Based
Consenti all'agente di rimborso dell'utente di elaborare i rimborsi quando l'importo è inferiore a $500.
Elementi:
-
Chi: agente per il rimborso degli utenti
-
Cosa: elaborare i rimborsi
-
Quando: l'importo è inferiore a $500
Esempio 2: Role-Based con più condizioni
Consenti agli utenti con il 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
-
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 è UE e il prodotto è idoneo.
Elementi:
-
Chi: utenti con scope travel:book
-
Cosa: creare prenotazioni di voli
-
Quando: la regione non è 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 è un punteggio di rischio.
Elementi:
-
Chi: tutti gli utenti
-
Cosa: visualizza i risultati del modello
-
Quando: la sensibilità dei dati è bassa o media E il tipo di risultato è il punteggio di rischio
Sintassi delle condizioni
Le condizioni sono in cui le politiche diventano spesso 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 dei passeggeri è esattamente 2"
Evita termini vaghi:
-
❌ «quando l'importo è piccolo»
-
❌ «quando la copertura è elevata»
Corrispondenza delle
Corrispondenza esatta:
-
«quando la regione sono gli Stati Uniti»
-
«quando il metodo di pagamento è la carta di credito»
-
«quando lo status è approvato»
Opzioni multiple:
-
«quando la regione è Stati Uniti, CA o Regno Unito»
-
«quando il tipo di decisione è «approva o rinvia»
Corrispondenza dei modelli:
-
«quando l'email contiene @example .com»
-
«quando l'ambito contiene admin:write»
Negazione:
-
«quando la regione non è UE»
-
«quando la classificazione non è soggetta a restrizioni»
Condizioni booleane
Controlli diretti:
-
«quando il prodotto è idoneo»
-
«quando viene inviato il punteggio di rischio»
-
«quando viene richiesta la spedizione espressa»
Negazione:
-
«quando il prodotto non è idoneo»
-
«quando il punteggio di rischio non viene inviato»
Esistenza del campo
Campi richiesti:
-
«quando viene fornita una motivazione»
-
«quando esiste un ID dell'applicazione»
-
«quando viene specificata la data di ritorno»
Combinazione delle condizioni
Le politiche reali richiedono spesso più condizioni. Utilizzate connettori logici trasparenti.
E logica (tutto deve essere vero)
Usa parole come: «e», «anche», «in aggiunta», «mentre», «con»
Esempio:
Consenti le candidature quando la regione è gli Stati Uniti, il prodotto è idoneo e il territorio è attivo.
Logica OR (almeno una deve essere vera)
Usa parole come: «o», «alternativamente», «uno dei due»
Esempio:
Consenti l'approvazione quando la richiesta supera i 10.000.000 di dollari o il livello di rischio è elevato o critico.
Logica complessa
Per condizioni complesse, usa una struttura chiara:
Esempio:
Consenti la finalizzazione quando la fase del flusso di lavoro è completa o approvata, lo stato di conformità è stato superato e l'autorità è il manager o il direttore.
Le insidie più comuni
Evita questi errori comuni quando scrivi politiche in linguaggio naturale per assicurarti che vengano convertite correttamente nella sintassi Cedar.
Argomenti
Errore 1: Vague Princials
Cattivo: «Consenti l'accesso allo strumento di rimborso»
Buono: «Consenti all'agente di rimborso dell'utente di accedere allo strumento di rimborso»
Errore 2: azioni ambigue
Cattivo: «Consenti agli utenti di accedere ai dati»
Buono: «Consenti agli utenti di visualizzare le cartelle cliniche dei pazienti»
Errore 3: condizioni soggettive
Cattivo: «Consenti i trasferimenti quando l'importo è ragionevole»
Buono: «Consenti i trasferimenti quando l'importo è inferiore a 10.000 USD»
Errore 4: condizioni mancanti
Errore: «Consenti agli utenti con ambito admin:write di aggiornare la copertura»
Buono: «Consenti agli utenti con ambito admin:write di aggiornare la copertura quando la polizza è attiva e il tipo di copertura è responsabilità o collisione»
Errore 5: Unclear Logic
Cattivo: «Consenti quando A o B e C»
Buono: «Consenti quando (A o B) e C» o «Consenti quando A o (B e C)»
