Escrevendo políticas em linguagem natural
O Policy in AgentCore selecionará automaticamente a região ideal em sua geografia para processar suas solicitações de inferência feitas por meio do serviço de criação de políticas. Isso maximiza os recursos computacionais disponíveis, a disponibilidade do modelo e oferece a melhor experiência ao cliente. Seus dados permanecerão armazenados somente na região de origem da solicitação. No entanto, as solicitações de entrada e os resultados de saída podem ser processados fora dessa região. Todos os dados serão transmitidos criptografados pela rede segura da Amazon.
O Policy in AgentCore encaminhará com segurança suas solicitações de inferência para os recursos computacionais disponíveis na área geográfica de origem da solicitação, da seguinte forma:
-
Solicitações de inferência originadas na União Europeia serão processadas dentro da União Europeia.
-
Solicitações de inferência originadas nos Estados Unidos da América serão processadas nos Estados Unidos.
-
Solicitações de inferência originadas na APAC serão processadas dentro da APAC.
Tópicos
Visão geral do
O Cedar fornece controle de acesso preciso, mas requer o aprendizado da sintaxe formal. O NL2Cedar permite que você:
-
Escreva os requisitos de autorização em linguagem natural
-
Converta automaticamente para a sintaxe Cedar
-
Verifique se as políticas geradas atendem aos seus requisitos
nota
A geração de políticas de linguagem natural requer um AgentCore gateway e um mecanismo de políticas implantados. O serviço usa o esquema AgentCore Gateway para gerar políticas válidas do Cedar. Consulte Introdução à política em AgentCore para obter instruções de configuração.
nota
A linguagem natural é flexível, mas a precisão é essencial para a segurança. As políticas devem ser claras e inequívocas.
Exemplo
A política de reembolso da seção anterior pode ser expressa em linguagem natural:
Linguagem natural:
Permita que o diretor com o nome de usuário “agente de reembolso” processe reembolsos quando o valor do reembolso for inferior a $500.
Converte em 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 };
Efeitos políticos
As políticas de autorização têm dois efeitos possíveis: permitir e proibir.
Políticas de permissão
As políticas de permissão especificam o que os usuários podem fazer:
-
“Permitir que o agente de reembolso do usuário processe reembolsos”
-
“Permita que usuários com função de diretor aprovem decisões”
-
“Autorize usuários com o escopo admin:write a atualizar a cobertura”
Proibir políticas
As políticas de proibição especificam o que os usuários não podem fazer:
-
“Impeça que usuários acessem modelos de alta sensibilidade”
-
“Impeça que subscritores juniores aprovem decisões”
-
“Proibir os usuários de processar reembolsos quando a validação de risco estiver pendente”
Semântica de autorização
Entender como a Cedar avalia as políticas é crucial para redigir regras de autorização eficazes. O cedro segue três princípios fundamentais:
-
Por padrão, tudo é negado. Se nenhuma política permitir explicitamente uma ação, ela será automaticamente bloqueada
-
Proibir sempre vence - Se alguma política de proibição corresponder, o acesso será negado, mesmo que as políticas de permissão também correspondam
-
É necessária pelo menos uma permissão - Para que o acesso seja concedido, pelo menos uma política de permissão deve corresponder e nenhuma política de proibição pode corresponder
Por que usar políticas de proibição se tudo é negado por padrão?
As políticas de proibição garantem que ações específicas não possam ser permitidas por engano. Mesmo que alguém escreva uma política de permissão mais ampla, a política de proibição tem precedência e bloqueia o acesso.
Exemplo de cenário:
// 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" };
Resultado: os usuários podem visualizar resultados de sensibilidade baixa e média (a permissão se aplica), mas os resultados de alta sensibilidade são sempre bloqueados (proíbe vitórias).
Use políticas de proibição para:
-
Restrições de segurança explícitas que nunca devem ser substituídas
-
Requisitos de conformidade
-
Desligamentos de emergência
-
Criação de exceções para políticas de licenciamento mais amplas
Elementos da política
As políticas de autorização exigem três elementos principais:
-
Quem - Quais usuários ou funções podem realizar a ação
-
O que - Quais operações ou ferramentas eles podem usar
-
Quando - Sob quais condições ou restrições
Especificação principal
O principal identifica a quais usuários, funções ou grupos a política se aplica.
Expressões flexíveis:
-
“Permitir que o agente de reembolso do usuário...”
-
“Permita que usuários com agente de reembolso de nome de usuário...”
-
“Usuários com função de agente de seguros podem...”
-
“Qualquer pessoa com o escopo refund:write está autorizada a...”
-
“Todos os usuários podem...”
Seja específico sobre identidade:
Incompleto: ❌ “Permitir o processamento de reembolsos abaixo de $500"
Completo: ✓ “Permitir que o agente de reembolso processe reembolsos abaixo de $500"
Especificação da ação
O “o quê” identifica quais operações, ferramentas ou ações a política controla.
Verbos de ação flexíveis:
-
“Permitir que os usuários processem reembolsos”
-
“Permitir processamento de reembolso”
-
“Os usuários podem criar aplicativos”
-
“Autorizar a visualização dos registros de auditoria”
Seja específico sobre a ferramenta:
Vago: ❌ “Permitir que os usuários acessem modelos”
Claro: ✓ “Permita que a equipe de ciência de dados acesse o modelo de análise”
Especificação da condição
O “quando” especifica sob quais circunstâncias a política se aplica.
Expressões condicionais flexíveis:
-
“... quando o valor for inferior a $500"
-
“... se a região for EUA, CA ou Reino Unido”
-
“... somente quando o status de aprovação é aprovado pelo gerente”
-
“... desde que a pontuação de risco tenha sido enviada”
Seja preciso com as condições:
Vago: ❌ “Permitir transferências quando o valor for razoável”
Preciso: ✓ “Permitir transferências quando o valor for inferior a $10.000"
Exemplos de políticas
Os exemplos a seguir demonstram como estruturar políticas de linguagem natural com princípios, ações e condições claras.
Tópicos
Exemplo 1: User-Based Política simples
Permita que o agente de reembolso do usuário processe reembolsos quando o valor for inferior a $500.
Elementos:
-
Quem: agente de reembolso do usuário
-
O que: processar reembolsos
-
Quando: o valor é inferior a $500
Exemplo 2: Role-Based com várias condições
Permita que usuários com função de agente de seguros atualizem a cobertura quando o tipo de cobertura for responsabilidade civil ou colisão e a apólice estiver ativa.
Elementos:
-
Quem: usuários com função de agente de seguros
-
O que: atualizar a cobertura
-
Quando: o tipo de cobertura é responsabilidade ou colisão E a apólice está ativa
Exemplo 3: Scope-Based Acesso
Permita que usuários com escopo travel:book criem reservas de voos quando a região não for da UE e o produto for elegível.
Elementos:
-
Quem: usuários com escopo travel:book
-
O que: criar reservas de voos
-
Quando: a região não é da UE E o produto é elegível
Exemplo 4: Todos com restrições
Permita que todos os usuários visualizem os resultados do modelo quando a sensibilidade dos dados for baixa ou média e o tipo de resultado for pontuação de risco.
Elementos:
-
Quem: todos os usuários
-
O que: ver os resultados do modelo
-
Quando: a sensibilidade dos dados é baixa ou média E o tipo de resultado é a pontuação de risco
Sintaxe da condição
As condições são onde as políticas geralmente se tornam ambíguas. Veja como escrever condições claras e testáveis.
Comparações numéricas
Bons exemplos:
-
“quando o valor for inferior a $500"
-
“quando o valor da cobertura for inferior a 5 milhões”
-
“quando a reclamação exceder $10.000.000"
-
“quando a contagem de passageiros é exatamente 2"
Evite termos vagos:
-
❌ “quando a quantidade é pequena”
-
❌ “quando a cobertura é alta”
Correspondência de
Correspondência exata:
-
“quando a região é EUA”
-
“quando o método de pagamento é cartão de crédito”
-
“quando o status for aprovado”
Várias opções:
-
“quando a região é EUA, CA ou Reino Unido”
-
“quando o tipo de decisão é aprovar ou encaminhar”
Correspondência de padrões:
-
“quando o e-mail contém @example .com”
-
“quando o escopo contém admin:write”
Negação:
-
“quando a região não é a UE”
-
“quando a classificação não é restrita”
Condições boolianas
Verificações diretas:
-
“quando o produto é elegível”
-
“quando a pontuação de risco é enviada”
-
“quando o envio expresso é solicitado”
Negação:
-
“quando o produto não é elegível”
-
“quando a pontuação de risco não é enviada”
Existência do campo
Campos obrigatórios:
-
“quando um motivo é fornecido”
-
“quando existe um ID de aplicativo”
-
“quando a data de devolução é especificada”
Combinando condições
Políticas reais geralmente precisam de várias condições. Use conectores lógicos claros.
Tópicos
E lógica (tudo deve ser verdade)
Use palavras como: “e”, “também”, “adicionalmente”, “enquanto”, “com”
Exemplo:
Permita inscrições quando a região for os EUA e o produto estiver qualificado e o território estiver ativo.
OU Lógica (pelo menos uma deve ser verdadeira)
Use palavras como: “ou”, “alternativamente”, “ou”
Exemplo:
Permita a aprovação quando a reclamação exceder $10.000.000 ou o nível de risco for alto ou crítico.
Lógica complexa
Para condições complexas, use uma estrutura clara:
Exemplo:
Permita a finalização quando o estágio do fluxo de trabalho estiver concluído ou aprovado, o status de conformidade for aprovado e a autoridade for gerente ou diretora.
Armadilhas comuns
Evite esses erros comuns ao escrever políticas de linguagem natural para garantir que elas sejam convertidas corretamente para a sintaxe do Cedar.
Tópicos
Erro 1: princípios vagos
Ruim: “Permitir acesso à ferramenta de reembolso”
Bom: “Permitir que o agente de reembolso do usuário acesse a ferramenta de reembolso”
Erro 2: ações ambíguas
Ruim: “Permitir que os usuários acessem os dados”
Bom: “Permitir que os usuários visualizem os registros dos pacientes”
Erro 3: condições subjetivas
Ruim: “Permitir transferências quando o valor for razoável”
Bom: “Permitir transferências quando o valor for inferior a $10.000"
Erro 4: condições ausentes
Ruim: “Permitir que usuários com escopo admin:write atualizem a cobertura”
Bom: “Permita que usuários com escopo admin:write atualizem a cobertura quando a apólice estiver ativa e o tipo de cobertura for responsabilidade ou colisão”
Erro 5: lógica pouco clara
Ruim: “Permitir quando A ou B e C”
Bom: “Permitir quando (A ou B) e C” ou “Permitir quando A ou (B e C)”
