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á.
Acesse AgentCore a memória por meio de um gateway
Por padrão, um aplicativo chama diretamente o plano de dados da Amazon Bedrock AgentCore Memory, e cada solicitação é autenticada com o AWS Signature Version 4 (SigV4). Você pode controlar esse acesso com políticas baseadas em identidade e em recursos do IAM. Isso funciona bem quando seu serviço de back-end chama a Memória em nome de todos os usuários e não precisa impor o isolamento por usuário na camada de memória.
Quando seu back-end chama a memória para muitos usuários, a memória vê apenas a função IAM do seu back-end. Ele não pode verificar para qual usuário final se destina uma solicitação. O código do seu aplicativo deve definir o namespace correto actorId em cada solicitação para isolar os dados de um usuário dos de outro.
Com um AgentCore gateway na frente da AgentCore memória, você pode mover essa imposição do código do seu aplicativo para a infraestrutura. O gateway se torna um ponto de entrada único e seguro para o tráfego de memória. Ele autentica cada chamador, avalia as políticas de controle de acesso e encaminha as solicitações permitidas para a Memória. A memória frontal com um gateway oferece dois recursos que o acesso direto não oferece:
- Autenticação OAuth para usuários finais
-
O plano de dados da memória é SigV4-only. Com um gateway configurado para autenticação de entrada OAuth (JWT), seus usuários finais podem se autenticar com um provedor padrão do OpenID Connect, e seu aplicativo não distribui credenciais para eles. AWS Para obter mais informações, consulte Autenticar usuários finais na memória com OAuth.
- Fine-grained controle de acesso
-
Um gateway pode avaliar políticas que restringem os chamadores a seu próprio ator, a seu próprio namespace ou a um conjunto específico de operações de memória, inclusive para chamadores autenticados com OAuth. Para obter mais informações, consulte controle de Fine-grained acesso para memória.
nota
Fine-grained o controle de acesso não é suportado para as operações de lote de memória (
BatchCreateMemoryRecordsBatchUpdateMemoryRecords, eBatchDeleteMemoryRecords). Cada uma dessas operações carrega vários registros em uma única solicitação, que o mecanismo de políticas não pode avaliar individualmente.
Ambos os recursos são baseados no conector de AgentCore memória descrito nesta página. Configurar o conector é um pré-requisito para qualquer um deles.
O conector AgentCore de memória
O conector de AgentCore memória (agentcore-memory) é um conector de gateway gerenciado que conecta um destino de gateway ao plano de dados da AgentCore memória. Os conectores são um tipo de alvo incorporado: em vez de criar um esquema de API e gerenciar você mesmo a fiação do endpoint, você cria um destino do tipo de conector e fornece somente o ID do conector e os parâmetros de destino.
Ao criar um destino de conector de memória, você fornece:
-
o id do conector (
agentcore-memory) e -
os parâmetros de destino, notadamente o recurso
memoryIdde memória que o alvo enfrenta.
O conector então:
- Resolve o endpoint de memória
-
Ele determina o endpoint correto do plano de dados de memória para o recurso de memória do alvo.
- Disponibiliza as operações de memória suportadas como ações do Cedar
-
O conector disponibiliza as seguintes operações do plano de dados de memória como ações do Cedar, cada uma com os campos de solicitação que aceita:
ListEventsCreateEventGetEventDeleteEvent,ListSessions,ListActors,,RetrieveMemoryRecords,ListMemoryRecords,GetMemoryRecordDeleteMemoryRecord, e.ListMemoryExtractionJobsStartMemoryExtractionJobÉ isso que permite que políticas de controle de acesso refinadas permitam ou neguem operações e condições específicas de memória em seus atributos de solicitação. Para os IDs de ação e os atributos de solicitação, consulte controle de Fine-grained acesso para memória.nota
As operações de lote de memória (
BatchCreateMemoryRecordsBatchUpdateMemoryRecords, eBatchDeleteMemoryRecords) não são suportadas para controle de acesso refinado. Cada uma dessas operações carrega vários registros em uma única solicitação, que o mecanismo de políticas não pode avaliar individualmente. - Encaminha solicitações
-
Ele encaminha cada solicitação permitida para o plano de dados da memória usando o modo de credencial de saída configurado do alvo.
Como o conector fornece o modelo de memória pronto para uso, você não cria manualmente um esquema nem gerencia a fiação do terminal.
Como uma solicitação flui pelo gateway
Quando um cliente chama a Memória pelo gateway, o gateway processa a solicitação em quatro etapas:
-
Autenticação de entrada — o gateway valida o chamador de acordo com seu tipo de autorizador de entrada: um token portador do OAuth (JWT), SigV4 ou uma solicitação não autenticada. AWS Consulte Modos de autenticação de entrada e saída.
-
Resolução de ação — o gateway mapeia a solicitação HTTP recebida (método e caminho) para a ação Cedar para a operação de memória que o chamador está tentando realizar. Os parâmetros do caminho e os campos do corpo da solicitação são extraídos em um objeto de contexto da solicitação.
-
Avaliação da política — se o gateway tiver um mecanismo de política conectado, ele avalia as políticas de controle de acesso configuradas em relação à solicitação. A avaliação é negada por padrão. Consulte controle de Fine-grained acesso para memória.
-
Autenticação de saída — se a solicitação for permitida, o gateway a encaminha para o plano de dados da memória usando o modo de credencial de saída do alvo. Consulte Modo de credencial de saída.
Modos de autenticação de entrada e saída
Um gateway tem um tipo de autorizador de entrada que controla como ele autentica os chamadores, e cada destino do conector de memória tem um modo de credencial de saída que controla a identidade que o gateway usa para chamar a memória. A maioria das implantações usa uma das duas combinações:
- Usuários finais do OAuth (o principal caminho de controle de acesso refinado)
-
CUSTOM_JWTentrada comGATEWAY_IAM_ROLEsaída. Seus usuários ou agentes se autenticam com um provedor OpenID Connect, e o gateway chama a Memória sob sua própria função de execução de gateway. Essa é a combinação a ser usada quando você deseja isolamento por usuário para chamadores que não são diretores do IAM. Para obter mais informações, consulte Autenticar usuários finais na memória com OAuth. - Serviços de back-end do IAM com passagem de identidade
-
AWS_IAMentrada comCALLER_IAM_CREDENTIALSsaída. O gateway encaminha a identidade IAM de cada chamador para a Memory, então a Memory avalia as permissões de IAM do chamador e você pode obter o tráfego encaminhado pelo gateway do pino de origem. Use isso quando seus chamadores já forem diretores do IAM e você quiser que a Memory os autorize diretamente.
Outras combinações, como AWS_IAM NONE entrada e GATEWAY_IAM_ROLE saída, são suportadas em cenários especializados, como a aplicação centralizada do Cedar para chamadores do IAM ou desenvolvimento e testes. Veja a matriz de compatibilidade para ver o conjunto completo.
Tipos de autorizadores de entrada
Você escolhe o autorizador de entrada ao criar o gateway. O conector de memória suporta todos os tipos de autorizadores de entrada suportados pelo AgentCore Gateway. Para obter mais informações, consulte Conceitos básicos do Amazon Bedrock AgentCore Gateway.
-
CUSTOM_JWT(OAuth/JWT) — o caminho principal para controle de acesso refinado. Disponibiliza as declarações de JWT do chamador para políticas de controle de acesso e permite a autenticação OAuth para usuários finais. Consulte Autenticar usuários finais na memória com OAuth. -
AWS_IAM(SigV4) — disponibiliza a identidade IAM do chamador para políticas de controle de acesso. Use-o para chamadas de IAM-authenticated back-end, fiscalização centralizada do Cedar ou fixar a fonte. -
AUTHENTICATE_ONLY— exige uma solicitação assinada válida, mas não expõe uma identidade de chamador digitada para regras de política baseadas em identidade. -
NONE— sem autorização. Destinado somente para desenvolvimento e teste; não o use para acesso à memória de produção.
Modo de credencial de saída
O modo de credencial de saída determina a identidade que o plano de dados da memória vê. A regra é simples:
-
Se sua autenticação de entrada for
CUSTOM_JWTouNONE, o gateway sempre usaGATEWAY_IAM_ROLE— ele chama a Memória sob sua função de execução de gateway. Não há outra opção válida e nada para escolher. -
Se sua autenticação de entrada for
AWS_IAMouAUTHENTICATE_ONLY, você também pode optar por encaminharCALLER_IAM_CREDENTIALSa própria identidade IAM do chamador para a Memory, em vez de usar a função de execução do gateway.
| Modo de saída | Como o gateway chama a memória |
|---|---|
|
|
O gateway chama a Memória sob sua função de execução de gateway (uma chamada primária). Funciona com todos os tipos de entrada. |
|
|
O gateway encaminha a identidade IAM do próprio chamador para a Memory (acesso delegado). Requer |
Matriz de compatibilidade
A tabela a seguir lista todas as combinações suportadas de autorizador de entrada e modo de credencial de saída no destino do conector de memória.
| Entrada |
GATEWAY_IAM_ROLE
|
CALLER_IAM_CREDENTIALS
|
|---|---|---|
|
|
Compatível |
Rejeitado na criação do alvo |
|
|
Compatível |
Compatível |
|
|
Compatível |
Rejeitado na criação do alvo |
|
|
Compatível |
Compatível |
Como o modo de credencial de saída afeta o controle de acesso à memória
O modo de credencial de saída determina qual identidade a Memória autoriza, portanto, as políticas do IAM que têm o escopo do chamador se comportam de maneira diferente em cada modo. Ele também determina como você pode restringir o tráfego encaminhado pelo gateway com uma política baseada em recursos de memória. Resource-based políticas para Amazon Bedrock AgentCore
-
GATEWAY_IAM_ROLE -
O gateway chama a Memória sob sua função de execução de gateway, então a Memória autoriza a solicitação como essa função. Para restringir o acesso a esse gateway, você pode usar a
aws:PrincipalArncondição no ARN da função de execução do gateway e definir o escopo da política de identidade dessa função apenas para as ações de memória de que o gateway precisa. As solicitações encaminhadas pelo gateway também carregam a chave deaws:SourceArncondição definida para o ARN do gateway (consulte o modo a seguir). -
CALLER_IAM_CREDENTIALS -
O gateway encaminha a identidade IAM do chamador para a Memória, então a Memória autoriza a solicitação como chamadora. Como o principal é o chamador e não o gateway, use a
aws:SourceArncondição para restringir o acesso ao tráfego encaminhado pelo gateway.
Em ambos os modos de saída, o gateway carimba a chave de aws:SourceArn condição com o ARN do gateway que encaminhou a solicitação. Uma política baseada em recursos de memória pode, portanto, restringir o acesso a um gateway específico aws:SourceArn comparando com o ARN do gateway, independentemente do modo de credencial de saída.
Importante
Como o modo de credencial de saída altera qual identidade a Memory autoriza, as políticas do IAM com escopo para o chamador se comportam de maneira diferente:
-
Com
CALLER_IAM_CREDENTIALS, Memory vê a identidade IAM do próprio chamador. As políticas do IAM baseadas em identidade e recursos que fazem referência ao chamador, incluindo uma chave específica ou chaves de condição de memóriaactorId, comobedrock-agentcore:namespaceebedrock-agentcore:namespacePath, são avaliadasDenyem relação a esse chamador. -
Com
GATEWAY_IAM_ROLE, Memory vê somente a função de execução do gateway. Cada solicitação do chamador chega à Memória sob essa única função, portanto, as políticas do IAM com escopo de acordo com a identidade de um chamador individual (como a de um chamador específicoactorId) não são avaliadasDenyem relação ao chamador original e não entram em vigor. Não confie nas políticas de IAM com escopo de chamada para impor o acesso por chamador nesse modo.
Se você usa GATEWAY_IAM_ROLE e precisa de controle de acesso por chamador (por exemplo, restringindo um chamador ao seu próprio espaço actorId ou ao namespace), aplique-o com controle de acesso refinado (políticas Cedar) no gateway, em vez de com políticas de IAM com escopo de chamada. Esse é o principal caminho de controle de acesso refinado. Para obter mais informações, consulte controle de Fine-grained acesso para memória.
Para ver as chaves de condição de política baseadas em recursos e exemplos de políticas JSON, consulte Resource-based as políticas do Amazon Bedrock. AgentCore
