View a markdown version of this page

AWS DevOps Segurança do agente - AWS DevOps Agente

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

AWS DevOps Segurança do agente

Este documento fornece informações sobre considerações de segurança, proteção de dados, controles de acesso e recursos de conformidade do AWS DevOps Agent. Use essas informações para entender como o AWS DevOps Agent foi projetado para atender aos seus requisitos de segurança e conformidade.

Segurança em várias camadas

AWS DevOps O agente implementa a segurança em várias camadas. Mesmo que permissões mais amplas sejam concedidas à função de IAM do agente, o agente aplica seus próprios controles de acesso internos para limitar o escopo de suas ações. Por exemplo, se um cliente adicionar uma política IAM de acesso completa ao Amazon S3 à função IAM do agente, AWS DevOps o agente garantirá que somente os registros após o AWSLogs prefixo sejam lidos para fins de solução de problemas.

Recomendamos seguir o princípio do menor privilégio ao configurar as permissões do IAM para o AWS DevOps Agente e implementar a segurança em várias camadas. A defesa profunda garante que nenhuma configuração incorreta possa comprometer a segurança do seu ambiente.

Espaços para agentes

Os Agent Spaces servem como o principal limite de segurança no AWS DevOps Agent. Cada espaço de agente:

  • Opera de forma independente com suas próprias configurações e permissões

  • Define quais AWS contas e recursos o agente pode acessar

  • Estabelece conexões com plataformas de terceiros

Os Agent Spaces mantêm um isolamento estrito para garantir a segurança e impedir o acesso não intencional em diferentes ambientes ou equipes.

Processamento regional e fluxo de dados

AWS DevOps O agente opera globalmente com recursos de processamento regionais. O agente recupera dados operacionais de AWS regiões em todas as AWS contas com acesso concedido no Espaço do Agente configurado. Essa coleta de dados multirregional entre contas garante uma análise abrangente de incidentes, respeitando os limites geográficos para o processamento de inferências.

Uso do Amazon Bedrock e inferência entre regiões

AWS DevOps O agente selecionará automaticamente a região ideal em sua geografia para processar suas solicitações de inferência. 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 em que seu Espaço do Agente foi criado, no entanto, as solicitações de entrada e os resultados de saída podem ser processados fora dessa região, conforme descrito na lista a seguir. Todos os dados serão transmitidos criptografados pela rede segura da Amazon.

AWS DevOps O agente encaminhará com segurança suas solicitações de inferência para os recursos computacionais disponíveis na área geográfica em que a solicitação foi originada, 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 Austrália serão processadas na Austrália.

  • Solicitações de inferência originadas no Japão serão processadas no Japão.

  • Se uma solicitação de inferência for originada em uma área não listada, ela será processada por padrão nos Estados Unidos da América.

  • DevOps Agent e Bedrock não são afetados pelas políticas do cliente nas Políticas de Controle de Serviços (SCPs) ou na Control Tower que restringem o conteúdo do cliente a regiões específicas

  • A Bedrock pode usar regiões diferentes da região de origem em sua geografia para realizar inferências sem estado para otimizar o desempenho e a disponibilidade.

Gerenciamento de identidade e acesso

Métodos de autenticação

AWS DevOps O agente fornece dois métodos de autenticação para fazer login no aplicativo web do AWS DevOps Agent Space:

  • AWS Integração com o Identity Center — O método de autenticação principal usa OAuth 2.0 com autenticação baseada em sessão usando cookies somente HTTP. AWS O Identity Center pode se federar com provedores de identidade externos por meio de protocolos OIDC e SAML padrão, incluindo provedores como Okta, Ping Identity e Microsoft Entra ID. Esse método oferece suporte à autenticação multifatorial por meio do seu provedor de identidade. AWS O Identity Center usa como padrão uma duração de sessão de até 12 horas e pode ser configurado para a duração desejada.

  • Link de autenticação do IAM — Um método alternativo fornece acesso direto ao aplicativo web a partir do AWS Management Console usando tokens baseados em JWT derivados de uma sessão existente do AWS Management Console. Essa opção é útil para avaliar o AWS DevOps Agente antes de implementar a integração completa do Identity Center, bem como para obter acesso administrativo se o aplicativo web do AWS DevOps Agent ficar inacessível por meio da autenticação baseada no Identity Center. As sessões são limitadas a 10 minutos.

Perfis do IAM

AWS DevOps O agente usa funções do IAM para definir as permissões de acesso:

  • Função da conta principal — concede ao agente acesso aos recursos na AWS conta em que você criou o Espaço do Agente, bem como acesso às funções secundárias da conta.

  • Funções secundárias da conta — concede ao agente acesso aos recursos em AWS contas adicionais conectadas ao Espaço do Agente.

  • Função do aplicativo Web — Concede aos usuários acesso aos dados e descobertas da investigação do AWS DevOps Agente no aplicativo web.

Essas funções devem ser configuradas seguindo o princípio do privilégio mínimo, concedendo somente as permissões de leitura necessárias para investigações.

Proteção de dados

Criptografia de dados

AWS DevOps O agente criptografa todos os dados do cliente:

  • Criptografia em repouso — Todos os dados são criptografados com chaves AWS gerenciadas.

  • Criptografia em trânsito — Todos os registros, métricas, itens de conhecimento, metadados de tickets e outros dados recuperados são criptografados em trânsito dentro da rede privada do agente e para redes externas.

Armazenamento e retenção de dados

Os dados são armazenados na região em que seu Espaço do Agente é criado, enquanto o processamento de inferência pode ocorrer dentro da sua geografia, conforme descrito na seção de uso do Amazon Bedrock acima.

Informações pessoais identificáveis (PII)

AWS DevOps O agente não filtra as informações de PII ao resumir os dados coletados durante investigações, avaliações de recomendações ou respostas de bate-papo. É recomendável que os dados de PII sejam editados antes de serem armazenados nos registros de observabilidade.

Diário do agente e registro de auditoria

Diário do agente

Tanto os recursos de Investigação quanto de Prevenção de Incidentes mantêm diários detalhados que:

  • Registre todas as etapas de raciocínio e ações tomadas

  • Crie transparência total nos processos de tomada de decisão dos agentes

  • Não pode ser modificado pelos agentes depois de registrados, evitando que ataques, como injeção imediata, ocultem ações importantes

  • Inclua todas as mensagens de bate-papo da página Investigação

AWS CloudTrail integração

Todas as chamadas da API do AWS DevOps agente são capturadas AWS CloudTrail automaticamente pela AWS conta de hospedagem. Usando as informações coletadas por CloudTrail, você pode determinar:

  • A solicitação que foi feita ao agente

  • O endereço IP do qual a solicitação foi feita.

  • Quem fez a solicitação.

  • Quando ela foi feita

Proteção imediata de injeção

Um ataque de injeção imediata ocorre quando um invasor incorpora instruções maliciosas em dados externos, como uma página da Web ou documento, que um sistema generativo de IA processará posteriormente. AWS DevOps O agente consome nativamente muitas fontes de dados como parte de suas operações normais, incluindo registros, tags de recursos e outros dados operacionais. AWS DevOps O agente protege contra ataques de injeção imediata por meio das proteções abaixo, mas é importante garantir que todas as fontes de dados conectadas e o acesso do usuário a essas fontes de dados sejam confiáveis. Consulte a seção Modelo de responsabilidade compartilhada para obter mais informações.

Proteções de injeção rápida:

  • Capacidades de gravação limitadas — As ferramentas disponíveis para o agente não são capazes de alterar recursos, com exceção da abertura de tickets e casos de suporte. Isso evita que instruções maliciosas modifiquem sua infraestrutura ou seus aplicativos.

  • Aplicação do limite da conta — O AWS DevOps agente opera somente dentro do limite permitido pelas funções atribuídas ao agente nas contas primária e secundária AWS conectada. O agente não pode acessar ou modificar recursos fora do escopo configurado.

  • Proteções de segurança de IA — O AWS DevOps agente usa modelos com proteções de segurança de IA de nível 3 (ASL-3). Essas proteções incluem classificadores que detectam e previnem ataques imediatos de injeção antes que eles possam afetar o comportamento do agente.

  • Trilha de auditoria imutável — O diário do agente registra todas as etapas de raciocínio e ações tomadas. As entradas do diário não podem ser modificadas pelo agente depois de registradas, evitando que ataques de injeção imediata ocultem ações maliciosas.

Embora o AWS DevOps Agent forneça várias camadas de proteção contra ataques imediatos de injeção, certas configurações podem aumentar o risco:

  • Ferramentas personalizadas do servidor MCP — O recurso bring-your-own MCP permite que você introduza ferramentas personalizadas ao agente, o que pode apresentar oportunidades adicionais para injeção imediata. As ferramentas personalizadas podem não ter os mesmos controles de segurança que as ferramentas nativas do AWS DevOps Agente, e instruções maliciosas podem potencialmente utilizar essas ferramentas de maneiras não intencionais. Consulte a seção Modelo de responsabilidade compartilhada para obter mais informações.

  • Ataques de usuários autorizados — Usuários autorizados a operar dentro dos limites da AWS conta ou das ferramentas conectadas têm uma chance maior de tentar um ataque contra o agente. Esses usuários podem modificar as fontes de dados que o agente consome, como registros ou tags de recursos, facilitando a incorporação de instruções maliciosas que o agente processará.

Para mitigar esses riscos:

  1. Analise e teste cuidadosamente os servidores MCP personalizados antes de implantá-los nos Agent Spaces.

    1. Certifique-se de que eles só tenham permissão para realizar ações somente para leitura

    2. Verifique se os usuários de ferramentas externas acessadas pelos servidores MCP são entidades confiáveis, pois os AWS DevOps agentes que fazem interface com o MCP dependem da relação de confiança implícita estabelecida entre esses usuários da ferramenta e o agente AWS DevOps

  2. Aplique o princípio do menor privilégio ao conceder aos usuários acesso a sistemas que fornecem dados ao agente

  3. Audite regularmente quais servidores MCP estão conectados aos seus Agent Spaces

  4. Como qualquer conteúdo recuperado da lista de permissões URLs pode tentar manipular o comportamento do agente, inclua somente fontes confiáveis em sua lista de permissões.

Segurança de integração

AWS DevOps O agente oferece suporte a vários tipos de integração, cada um com seu próprio modelo de segurança:

  • Integrações bidirecionais nativas — integrações integradas que podem enviar dados ao agente e receber atualizações do agente. Isso usa os métodos de autenticação do fornecedor

  • Servidores MCP — servidores Remote Model Context Protocol que utilizam fluxos de autenticação OAuth 2.0 e chaves de API para se comunicar com segurança com sistemas externos.

  • Acionadores de webhook — gatilhos de investigação de serviços remotos, como tickets ou sistemas de observabilidade. Os webhooks usam o Código de Autenticação de Mensagens (HMAC) baseado em Hash para fins de segurança.

  • Comunicação externa — Integrações como o Slack e os sistemas de emissão de bilhetes recebem atualizações do agente, mas ainda não oferecem suporte à comunicação bidirecional.

Provedores de registro

Algumas ferramentas externas são autenticadas no nível da conta e compartilhadas entre todos os Agent Spaces na conta. Ao registrar essas ferramentas, você se autentica uma vez no nível da conta e, em seguida, cada Espaço do Agente pode se conectar a recursos específicos dentro dessa conexão registrada.

As ferramentas a seguir usam o registro em nível de conta:

  • GitHub— Usa OAuth fluxo para autenticação. Depois de se registrar GitHub no nível da conta, cada Espaço do Agente pode se conectar a repositórios específicos em sua GitHub organização.

  • Dynatrace — usa autenticação de OAuth token. Depois de registrar o Dynatrace no nível da conta, cada Agent Space pode se conectar a ambientes específicos do Dynatrace ou configurações de monitoramento.

  • Slack — usa autenticação por OAuth token. Depois de registrar o Slack no nível da conta, cada espaço do agente pode se conectar a canais específicos do Slack.

  • Datadog — usa MCP com OAuth fluxo para autenticação. Depois de registrar o Datadog no nível da conta, cada Espaço do Agente pode se conectar a recursos específicos de monitoramento do Datadog.

  • New Relic — usa autenticação por chave de API. Depois de registrar a New Relic no nível da conta, cada Espaço do Agente pode se conectar a configurações específicas de monitoramento da New Relic.

  • Splunk — Usa a autenticação do token do portador. Depois de registrar o Splunk no nível da conta, cada Espaço do Agente pode se conectar a fontes de dados específicas do Splunk.

  • GitLab— Usa autenticação por token de acesso. Depois de se registrar GitLab no nível da conta, cada Espaço do Agente pode se conectar a GitLab repositórios específicos.

  • ServiceNow— Usa key/token autenticação OAuth do cliente. Depois de se registrar ServiceNow no nível da conta, cada espaço do agente pode se conectar a ServiceNow instâncias específicas ou filas de tickets.

  • Servidores MCP remotos acessíveis ao público em geral — Use o OAuth fluxo para autenticação. Depois de registrar um servidor MCP remoto no nível da conta, cada Espaço do Agente pode se conectar a recursos específicos expostos por esse servidor.

Conectividade de rede

AWS DevOps O agente se conecta a seus sistemas de terceiros e servidores MCP remotos para realizar investigações e outras operações.

Tráfego de entrada do AWS DevOps Agente para seus sistemas

AWS DevOps O agente inicia conexões de saída com seus sistemas de terceiros e servidores MCP remotos, que chegam como tráfego de entrada à sua infraestrutura. A forma como você protege esse tráfego depende de como suas ferramentas são hospedadas:

  • Ferramentas hospedadas de forma privada — Se suas ferramentas puderem ser acessadas de dentro de uma AWS VPC, você poderá usar as conexões privadas do AWS DevOps Agente para manter o tráfego isolado AWS das redes e fora da Internet pública. Para obter mais informações, consulte Conectando-se a ferramentas hospedadas de forma privada.

  • Ferramentas hospedadas publicamente — Se suas ferramentas puderem ser acessadas pela Internet pública e usarem listas de permissões de IP ou regras de firewall, você deverá permitir o tráfego de entrada dos seguintes endereços IP de origem do AWS DevOps agente:

    • Ásia-Pacífico (Sydney) (ap-southeast-2)

      • 13.237.95.197

      • 13.238.84.102

    • Ásia Pacific (Tóquio) (ap-northeast-1)

      • 13.192.12.233

      • 35.74.181.230

      • 57.183.50.158

    • Europa (Frankfurt) (eu-central-1)

      • 18.158.110.140

      • 52.57.96.160

      • 52.59.55.56

    • Europa (Irlanda) (eu-west-1)

      • 34.251.85.24

      • 52.30.157.157

      • 52.51.192.222

    • Leste dos EUA (Norte da Virgínia) (us-east-1)

      • 34.228.181.128

      • 44.219.176.187

      • 54.226.244.221

    • Oeste dos EUA (Oregon) (us-west-2)

      • 34.212.16.133

      • 52.89.67.212

      • 54.187.135.61

Tráfego de saída da sua VPC para o agente AWS DevOps

Para tráfego de saída da sua AWS VPC AWS DevOps para o agente (por exemplo, Invocando o DevOps Agente por meio do Webhook usando), você pode usar VPC Endpoints para manter esse tráfego de rede isolado das redes. AWS Para obter mais informações, consulte VPC endpoints (AWS PrivateLink).

Modelo de responsabilidade compartilhada

AWS responsabilidades

AWS é responsável por:

  • Manter a segurança dos dados recuperados pelo agente

  • Protegendo as ferramentas nativas disponíveis para uso pelo agente

  • Protegendo a infraestrutura que executa o AWS DevOps Agent

Responsabilidades do cliente

Os clientes são responsáveis por:

  • Gerenciando o acesso do usuário ao espaço do agente

  • Limitar o acesso a usuários confiáveis de sistemas externos que fornecem informações ao agente, como serviços e recursos que produzem registros, CloudTrail eventos, tickets e muito mais, que podem ser usados para tentar uma injeção maliciosa imediata.

  • Garanta que todas as fontes de dados conectadas tenham dados confiáveis que provavelmente não serão usados para tentar ataques de injeção imediata

  • Garantindo que as integrações de servidores bring-your-own MCP operem com segurança

  • Garantir que as funções do IAM atribuídas ao agente tenham um escopo adequado

  • Editando dados de PII antes de armazená-los em registros de observabilidade e outras fontes de dados do agente

  • Seguindo a prática recomendada de conceder somente permissões de leitura às fontes de dados conectadas, incluindo servidores MCP bring-your-own

Uso de dados

AWS não usa dados de agentes, mensagens de bate-papo ou dados de fontes de dados integradas para treinar modelos ou melhorar o produto. O Espaço do AWS DevOps Agente usa o feedback do cliente no produto para melhorar as respostas e investigações do agente, mas AWS não o usa para melhorar o serviço em si.

Compliance

Na versão prévia, o AWS DevOps Agente não está em conformidade com os padrões, incluindo SOC 2, PCI-DSS, ISO 27001 ou FedRAMP. AWS anunciará quais certificações de conformidade estarão disponíveis posteriormente.