As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Políticas temporais

A política no Amazon Bedrock AgentCore suporta políticas temporais: políticas cujas decisões dependem do histórico das ações de um agente em uma sessão, não apenas da solicitação atual. Com eles, você pode aplicar regras que abrangem várias ações, como exigir uma aprovação antes de uma ação, limitar quantas vezes uma ação é executada em uma janela de tempo ou manter um total em execução abaixo de um limite.

Uma política temporal é uma forbid regra permit or que contém um ou mais operadores temporais. Cada condição corresponde a um evento anterior registrado para a sessão por seus campos de ação, principal e de entrada ou saída da ação e considera somente eventos dentro de uma janela de tempo necessária. Uma condição pode correlacionar um evento correspondente com a solicitação atual, portanto, uma regra pode exigir, por exemplo, que a solicitação atual atue em um recurso que uma ação anterior já aprovou. O mecanismo de políticas registra os eventos de cada sessão e avalia essas condições em cada solicitação, para que você expresse as regras de reconhecimento de sessão como política, em vez de rastrear eventos no código do agente ou da ferramenta.

As políticas temporais são escritas em Dogwood, que é compatível com o Cedar e oferece suporte a todas as políticas existentes do Cedar. As políticas padrão do Cedar são apátridas e consideram apenas a solicitação atual. As políticas temporais seguem o mesmo modelo de negação por padrão: uma solicitação é permitida somente quando a permit se aplica e não forbid a substitui. As condições temporais são distintas das condições baseadas no tempo, que restringem o acesso com base na hora do relógio de parede (context.system.now) e não no histórico da sessão. Você também pode executar uma política temporal no LOG_ONLY modo para observar o que ela decidiria antes de promovê-laENFORCE; consulte Modos de aplicação de políticas.

Principais conceitos

As políticas temporais se baseiam em duas coisas: a linguagem política de Dogwood, que expressa regras com reconhecimento de sessão, e a sessão de política, que aborda o histórico que uma regra pode ver.

A linguagem política de Dogwood

As políticas temporais são escritas em Dogwood, uma linguagem de política de código aberto que a Policy in AgentCore usa para autorização com reconhecimento de sessões. O Dogwood se baseia no Cedar e usa o mesmo modelo de autorização: você escreve permit e forbid governa um principal, uma ação e um recurso, e uma solicitação é permitida somente quando a permit se aplica e não forbid a substitui. A Dogwood é compatível com a Cedar e suporta todas as políticas existentes da Cedar, portanto, toda política válida da Cedar também é uma política válida da Dogwood. Suas políticas de point-in-time existentes continuam funcionando sem alterações, e você adiciona condições temporais somente quando uma regra deve considerar mais do que a solicitação atual.

Com o Dogwood, você expressa regras com reconhecimento de sessão declarativamente como política, em vez de implementar a lógica de rastreamento de eventos em seu agente ou código de ferramenta. O mecanismo de políticas registra os eventos relevantes e avalia a condição em cada solicitação. Por exemplo, a política a seguir permite uma venda somente quando uma aprovação correspondente ocorreu na hora anterior:

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

O Dogwood fornece operadores temporais para os padrões comuns: formerly within (um evento correspondente ocorreu mais cedo na janela), since within (uma condição é mantida desde um evento âncora) e as agregações count e sum os eventos correspondentes na janela.

Para obter a sintaxe temporal completa, consulte o guia da linguagem Dogwood no site da Dogwood Policy.

Sessões de política e o ID da sessão

As políticas temporais são avaliadas em relação a uma sessão de política: uma sequência de invocações de Gateway relacionadas agrupadas em um ID de sessão. O histórico temporal tem como escopo a sessão, portanto, uma condição considera somente os eventos registrados para a mesma sessão da solicitação que está sendo autorizada. Você gera o ID da sessão e o envia em cada solicitação no x-amzn-bedrock-agentcore-policy-session-id cabeçalho, começando com sua primeira solicitação. O Gateway não gera um ID de sessão em seu nome. Se você omitir o cabeçalho ou enviar um valor vazio, o Gateway não estabelecerá uma sessão. Se o mecanismo de política associado contiver uma política temporal, as solicitações sem um ID de sessão falharão com um erro de validação.

Para obter detalhes sobre como transmitir o ID da sessão, o ciclo de vida da sessão e como a identidade se propaga em chamadas de vários saltos, consulte Sessões de políticas e propagação de identidade.

Invalidação da sessão

Uma política temporal decide se permite uma ação observando o que aconteceu anteriormente na mesma sessão. Esse histórico só é significativo em relação às políticas temporais que estavam em vigor quando a sessão começou. Se você alterar as políticas temporais do mecanismo enquanto uma sessão estiver aberta, o histórico registrado não corresponderá mais às regras atuais, então o serviço encerra a sessão em vez de tomar uma decisão contra dados inconsistentes.

Adicionar ou atualizar uma política temporal no mecanismo invalida as sessões ativas de política temporal do mecanismo. Após essa alteração, a próxima solicitação que reutiliza uma sessão invalidada falhará com um HTTP 409. ConflictException

Para se recuperar, inicie uma nova sessão e envie a solicitação novamente. A nova sessão começa com um histórico vazio e é avaliada de acordo com suas políticas atualizadas.

Compatível AWS Regiões

As políticas temporais estão disponíveis nas AWS regiões marcadas na tabela a seguir.

Considerações

Cross-account e solicitações entre regiões

As sessões de política temporal não oferecem suporte à propagação entre regiões ou contas. As políticas temporais não controlam as solicitações entre os AgentCore gateways e seus alvos de tempo de execução quando esses recursos residem em contas diferentes ou AWS regiões diferentes. Para que as políticas temporais controlem as ações do seu agente, o gateway e todos os seus alvos devem residir na mesma AWS conta e AWS região.

As políticas temporais impõem acesso somente quando o Workload Access Token (WAT) percorre a cadeia de solicitações (consulte Sessões de políticas e propagação de identidade). Quando sua cadeia de solicitações consiste inteiramente em componentes de AgentCore Gateway e Runtime, AgentCore propaga o cabeçalho WAT automaticamente de um salto para o outro. Essa propagação ocorre em uma única AWS região e conta. As políticas temporais se aplicam em toda a cadeia. Uma cadeia como Gateway to Runtime to Gateway to Runtime carrega o token de ponta a ponta, sem nenhum trabalho adicional de sua parte.

As cadeias que incluem componentes não Gateway ou Runtime se comportam de maneira diferente. Uma solicitação pode passar pela infraestrutura que você mesmo opera, como um gateway de API de terceiros ou um cluster Kubernetes. Esse componente deve encaminhar o cabeçalho WAT e você deve adicionar uma lógica personalizada para propagar o WAT por meio desses saltos. A localização física desses não AgentCore componentes não afeta o escopo regional e da conta. Eles podem ser executados em qualquer lugar, desde que os AgentCore componentes de ambos os lados retornem à mesma AWS conta e AWS região onde as políticas temporais se aplicam.

Permissões obrigatórias do IAM

As políticas temporais também têm um pré-requisito do IAM. A função do IAM configurada para o Gateway deve permitir a bedrock-agentcore:GetWorkloadAccessToken ação. Esse requisito é válido mesmo quando você usa o IAM para sua autorização de saída. O WAT permite que políticas temporais correlacionem as ações de um agente em uma sessão. O Gateway deve ser capaz de obter o WAT, independentemente de como você autentica as chamadas de saída. Se a função não tiver essa permissão, a aplicação da política temporal falhará. Conceda bedrock-agentcore:GetWorkloadAccessToken ao papel Gateway ao configurar políticas temporais. Para ver a política de permissão completa, incluindo os ARNs de recursos e o escopo do diretório de identidade da carga de trabalho, consulte Permissões do IAM para políticas temporais.

Self-referential as condições incluem a solicitação atual

Quando uma condição temporal faz referência à mesma ação que está sendo autorizada, o próprio evento da solicitação atual é incluído na avaliação. Por exemplo, uma condição que conta quantas vezes uma ação ocorreu em uma janela também conta a invocação atual.

É necessário permitir que uma ação anterior seja registrada como uma resposta

O histórico da sessão registra cada ação como um evento cujo tipo reflete o resultado: uma ação permitida que é concluída é registrada como um response evento e uma ação que uma política nega é registrada como um error evento. Uma condição temporal corresponde somente aos eventos do tipo que ela nomeia, portanto, uma condição que corresponde a um response evento considera somente as ações anteriores que foram permitidas. Certifique-se de que a ação anterior na qual uma política temporal se baseia seja permitida por uma política; se for negada, ela será registrada como uma error em vez de aresponse, e uma response condição nunca corresponderá a ela.

Ações de sequenciamento que dependem de uma resposta anterior

O histórico da sessão registra o response evento de cada ação quando a ação é concluída. Quando uma política depende da resposta de uma ação anterior na mesma sessão, como um campo de saída ou uma since condição, emita a solicitação dependente depois de receber a resposta da ação anterior. A conclusão de cada ação antes de iniciar a que depende dela mantém a sequência do fluxo de trabalho alinhada com o histórico que a política avalia.

Cotas

As cotas a seguir se aplicam às políticas temporais:

Observabilidade

O Amazon Bedrock AgentCore publica métricas e abrange dados que permitem observar a avaliação de políticas temporais. As métricas são publicadas no AWS/Bedrock-AgentCore CloudWatch namespace por padrão. Os dados de abrangência ficam disponíveis após você habilitar rastreamentos para o recurso de AgentCore gateway anexado e podem ser encontrados no grupo de CloudWatch aws/spans registros.

Os seguintes sinais são específicos das políticas temporais:

Para obter a lista completa de métricas, dimensões e atributos de abrangência de políticas e como ativar a observabilidade, consulte Política em dados de AgentCore observabilidade.

Considerações sobre segurança

A limitação de taxa com políticas temporais se aplica em uma única sessão. Como o histórico temporal tem como escopo uma sessão e o ID da sessão é fornecido pelo chamador, um limite count baseado, como “no máximo N chamadas por sessão”, conta somente os eventos registrados para essa sessão. O início de uma nova sessão inicia uma nova contagem, portanto, um limite de taxa temporal restringe a atividade dentro de uma sessão, em vez de em todas as sessões do chamador.