Beveiligingsoverzicht voor Azure SRE-agent

Azure SRE Agent maakt gebruik van diepgaande beveiliging op vier gebieden: uitvoering-isolatie, geheimloze referenties, datalocatie en scheiding per klant. Elke laag werkt onafhankelijk, zodat een inbreuk op het ene gebied niet trapsgewijs naar andere gebieden gaat.

Zie Agentmachtigingen en Agentidentiteit voor machtigings- en identiteitsdetails.

Uitvoeringsisolatie

De redeneringsengine en uitvoering van hulpprogramma's van de agent worden uitgevoerd in afzonderlijke rekengrenzen.

Sandbox-architectuur

Elke agent heeft zijn eigen sandbox. Deze architectuur biedt elke agent een toegewijde rekenomgeving die draait in een micro-VM en gescheiden blijft van de redeneerlus.

Onderdeel Wordt uitgevoerd in Role
Redenering van agenten Hoofdruntime Berichten verwerken, hulpprogramma's selecteren, antwoorden bouwen
Uitvoering van hulpprogramma's Sandbox (micro-VM) Voert bestandsbewerkingen, bash-opdrachten, codeanalyse, MCP-hulpprogramma's uit
Identiteit sidecar Afzonderlijke service Beheert referenties en tokens, geïsoleerd van redenering en uitvoering
Netwerkproxy Afzonderlijke service Alle uitgaande aanvragen valideren en routeren

De agent communiceert uitsluitend met de sandbox via gestructureerde API-aanroepen en nooit via directe bestandssysteem- of procestoegang.

Levenscyclus van hulpprogrammaproces

Elke aanroep van het hulpprogramma start een nieuw proces in de sandbox:

  1. Een nieuw proces begint met een eigen omgeving.
  2. De netwerkproxy verwerkt in- en uitvoerstromen via WebSocket.
  3. Na voltooiing wordt de hele processtructuur beëindigd.

Het systeem gebruikt geen permanente procesgroepen. Omgevingsvariabelen en -referenties zijn per verbinding beperkt, zodat de ene aanroep van het hulpprogramma de omgeving van een andere toolaanroep niet kan zien.

Code-uitvoering

Python- en shellcommando's draaien binnen de sandbox via de code-interpreter:

  • De uitvoering wordt geïsoleerd van uw resources en de redeneringsengine van de agent.
  • De omgeving bevat meer dan 700 vooraf geïnstalleerde Python pakketten, maar biedt geen ondersteuning voor willekeurige pakketinstallatie.
  • Een uitgaande proxy beheert de netwerktoegang en beperkt deze tot bekende servicedomeinen.

Geheimloos referentiebeheer

De uitvoeringsomgeving bevat nooit rechtstreeks inloggegevens. In plaats daarvan beheert een geïsoleerde identity-sidecar alle tokens en biedt deze op aanvraag aan individuele toolprocessen.

Hoe inloggegevens worden doorgegeven

  1. De agent bepaalt dat er een hulpprogramma-aanroep nodig is.
  2. De aanvraag wordt naar de sandbox doorgestuurd.
  3. De identiteitssidecar geeft een token met een korte levensduur aan het hulpmiddelproces.
  4. Het hulpprogramma maakt de geverifieerde aanroep via de netwerkproxy.
  5. Resultaten worden naar de agent teruggestuurd. Inloggegevens komen nooit in de redeneringscontext.

Drie eigenschappen maken referentiediefstal structureel onmogelijk:

  • Identiteits-sidecar-isolatie: een losstaande service beheert alle inloggegevens buiten de operationele omgeving van de agent.
  • Bereik per aanroep: Tokens zijn gericht op afzonderlijke aanroepen van hulpprogramma's, niet gedeeld in de sandbox.
  • Geen overname van omgevingsvariabelen: alleen expliciet gedeclareerde variabelen worden doorgestuurd naar hulpprogrammaprocessen.

Levensduur van inloggegevens

Typ Levensduur Vernieuwen
Tokens voor beheerde identiteit ~1 uur (Azure platformstandaard) Automatisch via Azure SDK
OAuth tokens (GitHub, Azure DevOps) Verschilt per aanbieder Vernieuwd 20 minuten voordat de vervaldatum is verstreken
Actietokens (per hulpprogramma-aanroep) Eenmalig gebruik Bij elke nieuwe aanroep uitgegeven
SAS-tokens voor Blob Storage 1 uur 15 minuten voor de vervaldatum vernieuwd

Opslaglocatie van gegevens

Wanneer je makelaar een probleem onderzoekt, vraagt hij je gegevensbronnen op. De agent schrijft geen ruwe queryresultaten zoals logboeken, metrics en API-antwoorden naar een aparte datastore. Wanneer de agent een toolcall verwerkt, serialiseert hij de chat- en toolberichten, inclusief resultaatoverzichten, in de persistent conversationthread.

De volgende gegevens blijven behouden:

Data Storage Retention Purpose
Gespreksthreads Agentendatabase Totdat het handmatig wordt verwijderd Chatgeschiedenis, onderzoeksverslagen
Sessie-inzichten Agentendatabase en blobopslag Hardnekkig Gesynthetiseerde leer, zoals symptomen, oplossingsstappen en hoofdoorzaken
Geheugenbestanden Blob-opslag Permanent tussen sessies Gesynthetiseerde kennis, teamcontext, instructies voor opslagplaatsen
Thread-bestanden Blob-opslag Gekoppeld aan de levensduur van draden Gebruikers uploaden, gegenereerde rapporten

Sessieinzichten zijn gesynthetiseerde samenvattingen, niet onbewerkte gegevenskopieën. De agent extraheert patronen (welke symptomen verschenen, welke resolutie werkte en wat vermeden moet worden) en slaat die als kennis op. De agent bewaart niet zelfstandig volledige ruwe zoekresultaten. Het slaat geserialiseerde toolberichten op, die mogelijk uitslagfragmenten of samenvattingen bevatten, als onderdeel van de gespreksgeschiedenis.

Isolatie per klant

Laag Isolatiemodel
Computeren Afzonderlijke sandbox per agent
Database Afzonderlijke database per agent
Blob-opslag Aparte blobopslag per agent
Network Proxy-exemplaar per agent voor alle uitgaande aanvragen
Credentials Beheerde identiteit per agent met RBAC-bereik voor door de klant geselecteerde resourcegroepen

Er worden geen gegevens, berekeningen of referenties gedeeld tussen agents of klanten.

Logboekregistratie en waarneembaarheid

Uw agent verzendt operationele telemetrie naar het Application Insights-exemplaar dat u tijdens de installatie configureert, zodat u volledig inzicht krijgt in agentbewerkingen.

Telemetrie Bijzonderheden
Gespreksgeschiedenis Gecorreleerd door trace-ID en span-ID voor het bijhouden van verzoeken van begin tot eind.
Hulpprogramma-aanroepafhankelijkheden Methode, URL, duur en statuscode voor elke uitgaande aanroep
Fouten en uitzonderingen Details van volledige uitzondering
Aangepaste gebeurtenissen Hook-activeringen, incidenten en andere agent-specifieke bewerkingen

Telemetrie van de uitvoering van sandbox-tools loopt door dezelfde pijplijn.

Encryption

Laag Beveiliging
Inactief Door Azure beheerde versleuteling beschermt alle opgeslagen data
Onderweg Alle externe communicatie gebruikt HTTPS

Netwerkproxy en beleidsregels

Alle uitgaande netwerktoegang vanuit de uitvoeringsomgeving loopt via een proxylaag die het volgende beleid afdwingt:

  • Aanvraagvalidatie: elke uitgaande verbinding wordt gevalideerd voordat een externe service wordt bereikt.
  • Referentie-injectie: de proxy koppelt scoped tokens uit de identity-sidecar; met programmacode worden tokens nooit rechtstreeks verwerkt.
  • Bereik van omgeving: Alleen expliciet gedeclareerde omgevingsvariabelen worden doorgestuurd naar hulpprogrammaprocessen.
  • Proceslevenscyclus: toolprocessen worden beëindigd na voltooiing of time-out.

Namens terugval

Wanneer de beheerde identiteit van de agent geen machtigingen voor een bewerking heeft, valt het systeem terug om namens u te handelen:

  1. De agent probeert de bewerking met de beheerde identiteit uit te voeren.
  2. Machtigingen zijn onvoldoende en u ziet een actieprompt Goedkeuren met bewerkingsgegevens.
  3. U keurt goed, en de bewerking wordt uitgevoerd met uw inloggegevens.
  4. Uw referenties worden na voltooiing niet in de cache opgeslagen.

Voermodi bepalen dit gedrag: voor de controlemodus is goedkeuring vereist voor schrijfbewerkingen, terwijl de autonome modus de beheerde identiteit rechtstreeks gebruikt. Zie Agentmachtigingen voor meer informatie.

Toegang tot privénetwerk

Azure SRE Agent ondersteunt deploymentconfiguraties voor private netwerkvereisten:

  • Regionale isolatie: Sandboxplaatsing respecteert regionale grenzen (bijvoorbeeld, sandboxes in Oost VS 2 blijven binnen Centraal VS, Noord-Centraal VS of Centraal Canada).
  • VNet-geïntegreerde uitvoering: Dedicated sandboxes kunnen worden geconfigureerd voor uitvoering binnen je virtuele netwerk.
  • Toegang tot inloggegevens zonder opgeslagen geheimen: De identiteitsdienst verstrekt tijdelijke inloggegevens aan toolprocessen zonder inloggegevens in de sandbox op te slaan.