Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O Azure SRE Agent utiliza segurança de defesa aprofundada em quatro áreas: isolamento de execução, credenciais sem segredo, residência de dados e separação por cliente. Cada camada opera de forma independente para que um comprometimento em uma área não se propague para outras.
Para permissões e detalhes de identidade, consulte permissões do Agente e Identidade do Agente.
Isolamento de execução
O motor de raciocínio do agente e a execução da ferramenta executam-se em limites de computação separados.
Arquitetura de caixa de areia
Cada agente tem a sua própria caixa de areia. Esta arquitetura fornece a cada agente um ambiente de computação dedicado que corre numa micro VM e permanece separado do ciclo de raciocínio.
| Componente | Funciona em | Função |
|---|---|---|
| Raciocínio do agente | Duração principal | Processa mensagens, seleciona ferramentas, constrói respostas |
| Execução de ferramentas | Sandbox (micro VM) | Executa operações de ficheiros, comandos bash, análise de código, ferramentas MCP |
| Sidecar de identidade | Serviço separado | Garante a gestão de credenciais e tokens, isolados do raciocínio e execução |
| Proxy de rede | Serviço separado | Valida e encaminha todos os pedidos de saída |
O agente comunica com o seu sandbox exclusivamente através de chamadas estruturadas à API e nunca através de acesso direto ao sistema de ficheiros ou processos.
Ciclo de vida do processo da ferramenta
Cada invocação de ferramenta lança um novo processo dentro do sandbox:
- Um novo processo começa com o seu próprio ambiente.
- O proxy de rede proxia os fluxos de entrada e saída através do WebSocket.
- Após a conclusão, toda a árvore de processos termina.
O sistema não utiliza pools de processos persistentes. As variáveis de ambiente e credenciais são definidas por cada ligação, por isso uma chamada de ferramenta não consegue ver o ambiente de outra chamada de ferramenta.
Execução do código
Comandos em Python e shell executam-se dentro do sandbox através do interpretador de código:
- A execução está isolada dos recursos disponíveis e do motor de raciocínio do agente.
- O ambiente inclui mais de 700 pacotes Python pré-instalados, mas não suporta a instalação arbitrária de pacotes.
- Um proxy de saída controla o acesso à rede e limita-o a domínios de serviço conhecidos.
Gestão de credenciais sem segredo
O ambiente de execução nunca mantém diretamente credenciais. Em vez disso, um sidecar de identidade isolado gere todos os tokens e fornece-os sob demanda a processos individuais das ferramentas.
Fluxo das credenciais
- O agente conclui que é necessário invocar uma ferramenta.
- O pedido é encaminhado para o sandbox.
- O sidecar de identidade emite um token de curta duração para o processo da ferramenta.
- A ferramenta faz a chamada autenticada através do proxy da rede.
- Os resultados são devolvidos ao agente. As credenciais nunca entram no contexto de raciocínio.
Três propriedades tornam o roubo de credenciais estruturalmente impossível:
- Isolamento de sidecar de identidade: Um serviço separado gere e armazena todas as credenciais fora do ambiente de execução do agente.
- Âmbito por chamada: Os tokens são atribuídos a invocações individuais de ferramentas, não partilhados no sandbox.
- Sem herança de variáveis de ambiente: Apenas variáveis explicitamente declaradas são encaminhadas para os processos da ferramenta.
Vida útil da credencial
| Tipo | Lifetime | Atualizar |
|---|---|---|
| Tokens de identidade geridos | ~1 hora (padrão da plataforma Azure) | Automático via SDK do Azure |
| OAuth tokens (GitHub, Azure DevOps) | Varia consoante o prestador | Atualizado 20 minutos antes da expiração |
| Tokens de ação (por cada chamada de ferramenta) | Utilização única | Emitido novo a cada invocação |
| Tokens SAS de armazenamento de blobs | Uma hora | Atualizado 15 minutos antes da expiração |
Residência dos dados
Quando o seu agente investiga um problema, consulta as suas fontes de dados. O agente não escreve resultados brutos de consultas, como entradas de log, métricas e respostas da API, num armazenamento de dados separado. Quando o agente processa uma invocação de ferramenta, serializa as mensagens da conversa e da ferramenta, incluindo os resumos dos resultados, na conversa persistente.
Os seguintes dados são mantidos:
| Data | Armazenamento | Retention | Purpose |
|---|---|---|---|
| Tópicos de conversa | Base de dados de agentes | Até ser eliminado manualmente | Histórico de chat, registos de investigação |
| Perspetivas da sessão | Base de dados do agente e armazenamento de blobs | Persistente | Aprendizados sintetizados, como sintomas, passos de resolução e causas profundas |
| Ficheiros de memória | Armazenamento de blobs | Persistente ao longo das sessões | Conhecimento sintetizado, contexto da equipa, instruções de repositório |
| Ficheiros de thread | Armazenamento de blobs | Ligado à vida útil do fio | Uploads de utilizadores, relatórios gerados |
Os insights das sessões são resumos sintetizados, não cópias brutas de dados. O agente extrai padrões (que sintomas apareceram, que resolução funcionou e o que evitar) e armazena-os como conhecimento. O agente não persiste autonomamente os resultados brutos completos da consulta. Armazena mensagens serializadas de ferramentas, que podem incluir excertos de resultados ou resumos, como parte do histórico do tópico da conversa.
Isolamento para cada cliente
| Camada | Modelo de isolamento |
|---|---|
| Computação | Sandbox dedicado para cada agente |
| Database | Base de dados separada por agente |
| Blob Storage | Armazenamento de blobs separado para cada agente |
| Network | Instância de proxy por agente para todas as solicitações destinadas a fora |
| Credentials | Identidade gerida por agente com RBAC atribuída a grupos de recursos selecionados pelo cliente |
Nenhum dado, computação ou credencial é partilhado entre agentes ou clientes.
Registo e observabilidade
O seu agente envia telemetria operacional para a instância Application Insights que configura durante a configuração, dando-lhe visibilidade total sobre as operações do agente.
| Telemetry | Detalhes |
|---|---|
| Registros de mensagens | Correlacionado por ID de traço e ID de span para rastreamento de solicitações de ponta a ponta |
| Dependências de chamadas de ferramenta | Método, URL, duração e código de estado para cada chamada de saída |
| Erros e exceções | Detalhes das exceções completas |
| Eventos personalizados | Ativações de ganchos, eventos de incidentes e outras operações específicas de agentes |
A telemetria da execução da ferramenta sandbox flui através do mesmo pipeline.
Encriptação
| Camada | Proteção |
|---|---|
| Em repouso | A encriptação gerida pelo Azure protege todos os dados em repouso |
| Em trânsito | Toda a comunicação externa utiliza HTTPS |
Proxy de rede e políticas de rede
Todo o acesso à rede de saída a partir do ambiente de execução passa por uma camada proxy que aplica as seguintes políticas:
- Validação do pedido: Toda a ligação de saída é validada antes de chegar a um serviço externo.
- Injeção de credenciais: O proxy anexa tokens com escopo a partir do sidecar de identidade; o código das ferramentas nunca lida diretamente com os tokens.
- Âmbito do ambiente: Apenas variáveis de ambiente explicitamente declaradas são encaminhadas para os processos da ferramenta.
- Ciclo de vida do processo: Os processos da ferramenta são terminados após a conclusão ou o timeout.
Em nome do Fallback
Quando a identidade gerida do agente não tem permissões para uma operação, o sistema volta a agir em seu nome:
- O agente tenta a operação com a sua identidade gerida.
- As permissões são insuficientes e vês um prompt de Aprovar ação com detalhes da operação.
- Tu aprovas, e a operação executa-se com as tuas credenciais.
- As tuas credenciais não são armazenadas em cache após a conclusão.
Os modos de execução controlam este comportamento: o modo de revisão requer aprovação para operações de escrita, enquanto o modo autónomo utiliza diretamente a identidade gerida. Para mais informações, consulte permissões do Agente.
Acesso à rede privada
O Azure SRE Agent suporta configurações de implementação para requisitos de rede privada:
- Isolamento regional - A colocação dos sandboxes respeita as fronteiras regionais (por exemplo, os sandboxes da East US 2 permanecem dentro do Centro dos EUA, Norte Central dos EUA ou Canadá Central).
- Execução integrada com VNet: Sandboxes dedicados podem ser configurados para execução dentro da sua rede virtual.
- Acesso a credenciais sem segredo: O serviço de identidade fornece credenciais de curta duração para os processos das ferramentas sem armazenar credenciais no sandbox.