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à.

Creazione di politiche temporali

Crei una politica temporale nel linguaggio delle politiche di Dogwood e la aggiungi a un motore di policy, nello stesso modo in cui crei qualsiasi altra politica per Policy in. AgentCore Una politica temporale è una forbid regola permit or le cui condizioni relative alla sessione sono inserite in un temporal blocco; il principio, l'azione e la risorsa a cui si applica la regola sono scritti utilizzando l'(principal, action, resource)ambito standard, lo stesso di qualsiasi altra politica. Le sezioni seguenti mostrano come creare una politica temporale e illustrare gli schemi comuni che è possibile esprimere.

Crea una politica temporale

Con l'create-policyoperazione si crea una politica temporale, la stessa operazione utilizzata per le altre politiche, e la si collega a un motore di policy. L'affermazione di una politica temporale rientra policy nella definizione, piuttosto che in quella di una polizza cedar Cedar per apolidi.

Il seguente esempio AWS CLI crea una politica temporale su un motore di policy:

aws bedrock-agentcore-control create-policy \
  --policy-engine-id my-policy-engine-id \
  --name TransferToLookedUpAccount \
  --validation-mode FAIL_ON_ANY_FINDINGS \
  --definition '{
    "policy": {
      "statement": "permit (principal, action == AgentCore::Action::\"FundsTarget___transfer_funds\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway\") when temporal { formerly within 1h AgentCore::Action::\"FundsTarget___get_account_balance\"::response{ eventResource: resource, output.accountId: context.input.toAccount } };"
    }
  }'

Puoi anche creare una politica temporale descrivendola in linguaggio naturale invece di scrivere tu stesso la dichiarazione di Dogwood.

Schema dell'evento: campi a cui puoi fare riferimento

Le condizioni all'interno di un temporal { } blocco utilizzano predicati temporali di eventi per abbinare eventi specifici registrati nella sessione fino a quel momento (fino all'azione attualmente autorizzata). Un predicato indica una finestra temporale, un'azione e un tipo di evento e un insieme di vincoli di campo sull'evento corrispondente. L'create-policyesempio nella sezione precedente utilizzava un predicatoformerly within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource, output.accountId: context.input.toAccount }, che corrisponde a un get_account_balance response record dell'ultima ora che è output.accountId uguale a quello della richiesta corrente. toAccount

Per scrivere un predicato, devi sapere quali eventi produce un'azione e quali campi contiene ogni evento, perché questi sono i campi a cui un predicato può vincolare e correlarsi. Questa sezione descrive lo schema di eventi.

Ogni azione produce fino a tre tipi di evento, denominati in base al tipo di evento nel predicato (::request,::response,::error):

Lo schema degli eventi temporali definisce questi eventi per ogni azione. A …​inputs(A)ed …​outputs(A) espandi fino ai campi di input e output dichiarati dell'azione:

// Recorded for each authorized request.
decision event <A>::request {
    ...inputs(A),
    eventPrincipal: principalType(A),
    eventResource:  resourceType(A),
    requestId:      String,
    pin sessionId:  String = context.sessionId,
}

// Recorded when the tool returns successfully; carries inputs and outputs.
event <A>::response {
    ...inputs(A),
    ...outputs(A),
    eventPrincipal: principalType(A),
    eventResource:  resourceType(A),
    requestId:      String,
    pin sessionId:  String = context.sessionId,
}

// Recorded when the request is denied or the tool returns an error; history-only.
event <A>::error {
    ...inputs(A),
    eventPrincipal: principalType(A),
    eventResource:  resourceType(A),
    requestId:      String,
    pin sessionId:  String = context.sessionId,
}

All'interno del corpo del predicato, puoi fare riferimento ai seguenti campi dell'evento corrispondente:

Per correlare un evento registrato con la richiesta corrente, confronta uno di questi campi con un valore della richiesta corrente, ad esempio. context.input.<name>

Casi d’uso

Di seguito sono riportati alcuni esempi di politiche temporali.

Strumenti disponibili

Gli esempi in questa sezione utilizzano un gateway target denominato FundsTarget che espone tre strumenti. In una policy, ogni strumento è referenziato dal nome dell'azione e dai campi di input e output elencati qui. FundsTarget___<tool-name>

Esempio: integrità da uscita a ingresso

Questo esempio consente a un agente di trasferire fondi solo su un conto consultato in precedenza nella stessa sessione, impedendogli di trasferirli su un conto creato da lui. La politica lo consente transfer_funds solo quando una get_account_balance risposta all'inizio della sessione ha restituito lo stesso account:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{
        eventResource: resource,
        output.accountId: context.input.toAccount
    }
};

Il ::response predicato corrisponde alla risposta registrata di un precedente. get_account_balance output.accountIdè un campo restituito dallo strumento ed context.input.toAccount è l'account di destinazione della transfer_funds richiesta corrente; se si richiede che siano uguali, il trasferimento è associato a una ricerca preventiva.

Poiché un motore di policy lo nega per impostazione predefinita e poiché un'azione viene registrata response solo se è stata consentita, concedi anche un valore semplice permit get_account_balance in modo che la ricerca sia consentita e registrata come risposta nella sessione:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
);

Con entrambe le politiche in atto, le richieste in una sessione vengono decise come segue:

Esempio: sequenziamento degli utensili

Questo esempio consente un'azione solo dopo un'azione prerequisita eseguita in precedenza nella stessa sessione. La seguente politica lo consente get_account_balance solo se è avvenuta una transfer_funds richiesta negli ultimi cinque minuti:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___transfer_funds"::request{
        eventResource: resource
    }
};

Il ::request predicato corrisponde a una transfer_funds richiesta precedente nella sessione. Associalo a un permit for transfer_funds in modo che l'azione sia consentita e registrata. Con entrambe le politiche in atto, get_account_balance viene negato fino a quando non viene eseguito un transfer_funds nella sessione:

Esempio: aggiornamento dei dati

Questo esempio consente un'azione solo se un prerequisito è stato completato correttamente entro una finestra ristretta, in modo che i risultati obsoleti facciano scadere l'autorizzazione. Permette get_account_balance solo se è transfer_funds stata completata entro gli ultimi cinque minuti:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___transfer_funds"::response{
        eventResource: resource
    }
};

La differenza rispetto al sequenziamento degli strumenti ::request è la corrispondenza ::response anziché la sequenza degli strumenti: un response evento viene registrato solo quando l'azione viene completata con successo, quindi questa politica richiede un completamento recente con successo, non una semplice richiesta preventiva. La lunghezza della finestra determina la freschezza del completamento; una volta superata la finestra, l'autorizzazione decade fino alla ripetizione del prerequisito.

Esempio: limitazione della velocità basata sulla sessione

Questo esempio limita uno strumento a un numero fisso di chiamate all'interno di una sessione. La seguente politica vieta transfer_funds una chiamata dopo che è stata chiamata più di tre volte nell'arco di cinque minuti durante la sessione:

forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource } && tp(t)))) == n
        && n > 3
};

L'countespressione conta le transfer_funds richieste registrate nella sessione negli ultimi cinque minuti, inclusa la richiesta corrente; quando il conteggio supera le tre, si applica il divieto. Abbinala a un permit for transfer_funds in modo che le chiamate siano consentite fino al limite. Con entrambe le politiche in vigore, sono consentite le prime tre transfer_funds chiamate entro una finestra di cinque minuti e la quarta (o successiva) chiamata in tale finestra viene negata.

Esempio: approvazione una tantum

Questo esempio rende ogni approvazione valida per un uso singolo. A transfer_funds è consentito solo se nessuna transfer_funds è stata completata dopo l'ultima get_account_balance (l'approvazione) della sessione. Una volta completato, un trasferimento consuma l'approvazione e il trasferimento successivo viene negato fino a quando non viene effettuata una nuova approvazione:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    !AgentCore::Action::"FundsTarget___transfer_funds"::response{ eventResource: resource }
    since within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource }
};

Questa since condizione è valida quando il completamento get_account_balance (l'approvazione) è avvenuto entro l'ultima ora e non transfer_funds è stato completato dopo tale approvazione. La corrispondenza ::response è fondamentale: un trasferimento viene considerato completato solo dopo l'esito positivo, quindi la richiesta autorizzata non si blocca da sola. Abbinalo a un modulo in get_account_balance modo che permit le approvazioni vengano registrate.

Le richieste in una sessione vengono decise come segue:

Esempio: budget cumulativo

Questo esempio limita il valore totale di un'azione all'interno di una finestra. La seguente politica vieta transfer_funds che la somma dei amount dati inseriti nei trasferimenti della sessione negli ultimi cinque minuti raggiunga 3000:

forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    exists (total: Long).
        (sum amt for (amt: Long), (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource, input.amount: amt } && tp(t)))) == total
        && total >= 3000
};

L'sumespressione somma il campo amount di input tra le transfer_funds richieste corrispondenti nella finestra, inclusa la richiesta corrente; quando il totale raggiunge la soglia, si applica il divieto. Il campo sommato è un campo di input dell'azione. Associa la politica a un modulopermit. transfer_funds Ad esempio, con una soglia di 3000 e trasferimenti di 1000, i primi due sono consentiti e il terzo, che raggiungerebbe i 3000, viene negato.

Come per la limitazione della velocità, la somma è limitata alla sessione corrente e non viene aggregata tra le sessioni.

Esempio: raffreddamento

Questo esempio impone un tempo di recupero: un'azione non può essere ripetuta entro un determinato periodo dall'ultimo completamento. Vieta che un'operazione transfer_funds venga transfer_funds completata entro l'ultimo minuto:

forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1m AgentCore::Action::"FundsTarget___transfer_funds"::response{
        eventResource: resource
    }
};

Questa condizione è autoreferenziale: corrisponde alla stessa azione autorizzata. La corrispondenza ::response è ciò che la fa funzionare, perché la richiesta autorizzata non ha ancora prodotto una risposta, quindi non corrisponde a se stessa. Se la risposta è ::request qui, la richiesta corrente corrisponderebbe al proprio evento e l'azione sarebbe permanentemente vietata. Trascorsa la finestra senza un nuovo completamento, l'azione è nuovamente consentita.

Esempio: precondizione continua

Questo esempio consente un'azione solo se è valida una precondizione: una conferma positiva è avvenuta di recente e da allora nulla l'ha invalidata. È consentita transfer_funds solo se una get_account_balance (la conferma) è stata completata negli ultimi cinque minuti e nessuna get_transaction_history (l'invalidazione) è stata completata dopo:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    !AgentCore::Action::"FundsTarget___get_transaction_history"::response{ eventResource: resource }
    since within 5m AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource }
};

Questa since condizione è valida quando si get_account_balance è verificato un completamento negli ultimi cinque minuti e da allora non si get_transaction_history è verificato alcun completamento. Il completamento get_account_balance conferma la condizione preliminare e, richiedendo che non si sia verificata alcuna condizione, si garantisce che in seguito non sia get_transaction_history stata invalidata. Concedi i permessi per entrambi get_account_balance e get_transaction_history quindi vengono registrati.

Esempio: catena multi-hop

È possibile comporre diverse politiche di sequenziamento per richiedere una catena di azioni, ciascuna consentita solo dopo il completamento della precedente. Questo esempio richiede la catena get_account_balance → get_transaction_history →transfer_funds, utilizzando due politiche (una per link):

// Link 1: permit get_transaction_history only after get_account_balance completed
permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_transaction_history",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource }
};

// Link 2: permit transfer_funds only after get_transaction_history completed
permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___get_transaction_history"::response{ eventResource: resource }
};

Ogni policy impone un collegamento e la catena emerge dalla loro composizione: transfer_funds richiedeget_transaction_history, quale richiede. get_account_balance Assegna un permit per la prima azione della catena in modo che possa iniziare. Un passaggio che viene eseguito in modo anomalo viene negato fino al completamento del prerequisito.

Esempio: esclusione reciproca

Questo esempio fa sì che due azioni si escludano a vicenda all'interno di una finestra: quella che viene eseguita per prima blocca l'altra. Utilizza due politiche di divieto simmetriche in modo che l'esclusione si applichi in entrambe le direzioni. Ecco, transfer_funds e get_transaction_history non possono avvenire entrambe entro due minuti:

// Forbid get_transaction_history if a transfer_funds was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___get_transaction_history",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 2m AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource }
};

// Forbid transfer_funds if a get_transaction_history was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 2m AgentCore::Action::"FundsTarget___get_transaction_history"::request{ eventResource: resource }
};

Poiché ogni criterio corrisponde::request, anche solo la richiesta di un'azione blocca l'altra: il blocco non attende il completamento della prima azione. Sono necessarie due forbid politiche simmetriche, una per direzione: una vieta get_transaction_history dopo una richiesta e l'altra vieta dopo una transfer_funds richiesta. transfer_funds get_transaction_history Una singola proibizione bloccherebbe un solo ordine. Associa entrambi i permessi per le due azioni.

Esempio: combinazione di condizioni temporali, guardrail e Cedar

Una singola politica può combinare una condizione temporale con le condizioni di guardrail e le condizioni standard Cedar; tutte devono essere soddisfatte affinché la politica possa essere applicata. Questo esempio lo consente transfer_funds solo quando l'importo cumulativo del trasferimento rimane al di sotto di un limite (temporale), la richiesta non contiene informazioni sensibili (guardrail) e il chiamante non è in un gruppo bloccato (Cedar):

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    exists (total: Long).
        (sum amt for (amt: Long), (t: Timepoint).
            where (formerly within 24h (AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource, input.amount: amt } && tp(t)))) == total
        && total < 60000
}
when {
    BedrockGuardrails::SensitiveInformation(["ACCOUNT_NUMBER"], [context.input.body]).count() == 0
}
unless {
    principal in Group::"blocked_users"
};

Il blocco temporale impone il limite cumulativo, il blocco guardrail blocca le richieste che contengono le informazioni sensibili elencate e il blocco Cedar esclude i principali bloccati. unless Ogni tipo di condizione viene valutato in modo indipendente e l'autorizzazione si applica solo se tutte sono valide. Per la sintassi della condizione guardrail, vedi Guardrails nelle policy; il blocco temporale si comporta come descritto negli esempi precedenti.

Esempio: prerequisiti paralleli

Questo esempio richiede il completamento di due prerequisiti, in qualsiasi ordine, prima che un'azione sia autorizzata. È consentito get_account_balance solo se entrambi sono get_transaction_history stati transfer_funds completati entro l'ultima ora, combinando due formerly condizioni con: &&

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1h AgentCore::Action::"FundsTarget___transfer_funds"::response{ eventResource: resource }
    && formerly within 1h AgentCore::Action::"FundsTarget___get_transaction_history"::response{ eventResource: resource }
};

Entrambi i prerequisiti devono essere stati completati (::response) all'interno della finestra e l'ordine non ha importanza. Concedi i permessi per entrambe le azioni prerequisite in modo che vengano registrate. Il completamento di una sola azione lascia l'azione negata fino al completamento anche dell'altra.

Esempio: soglia di approvazione

Questo esempio consente un'azione solo dopo un numero limite di eventi qualificanti. È consentito get_account_balance a un cliente solo se ne sono transfer_funds stati completati almeno due sul conto di quel cliente, correlando il trasferimento toAccount con la richiesta di saldo: customerId

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"FundsTarget___transfer_funds"::response{ eventResource: resource, input.toAccount: context.input.customerId } && tp(t)))) == n
        && n >= 2
};

L'countespressione conta gli eventi completati corrispondenti nella finestra e l'azione è consentita una volta che il conteggio raggiunge la soglia.

Esempio: bloccare un'azione dopo un precedente rifiuto

Questo esempio blocca un'azione sensibile quando una precedente chiamata allo strumento nella stessa sessione è stata negata. Una richiesta rifiutata viene registrata come error evento e il ::error predicato corrisponde a tale evento. La seguente politica vieta transfer_funds ogni volta che una get_account_balance sessione è stata negata negli ultimi tre minuti:

forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 3m AgentCore::Action::"FundsTarget___get_account_balance"::error{
        eventResource: resource
    }
};

Una forbid regola ha la precedenza su qualsiasi regolapermit, quindi abbinala a una permit che lo transfer_funds consenta in condizioni normali:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
);

Con entrambe le politiche in vigore, le richieste in una sessione vengono decise come segue: