Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure Agent SRE utilise la sécurité multicouche de défense dans quatre domaines : isolation de l’exécution, informations d’identification sans secrets, résidence des données et séparation pour chaque client. Chaque couche fonctionne indépendamment afin qu’une compromission dans une zone ne se cascade pas à d’autres.
Pour plus d’informations sur les autorisations et l’identité d’identité, consultez Autorisations de l’agent et identité de l’agent.
Isolation de l’exécution
Le moteur de raisonnement et l’exécution de l’outil de l’agent s’exécutent dans des limites de calcul distinctes.
Architecture de bac à sable
Chaque agent obtient son propre groupe sandbox, une micro machine virtuelle isolée alimentée par Azure Calcul dédié (ADC), séparée de la boucle de raisonnement.
| Composant | S’exécute dans | Role |
|---|---|---|
| Raisonnement de l’agent | Environnement d'exécution principal | Traite les messages, sélectionne les outils, génère des réponses |
| Exécution de l’outil | Bac à sable ADC (micro VM) | Exécute les opérations de fichier, les commandes bash, l’analyse du code, les outils MCP |
| Side-car d’identité | Service distinct | Gère les informations d’identification et les jetons, isolés du raisonnement et de l’exécution |
| Proxy réseau | Service distinct | Valide et route toutes les demandes sortantes |
L’agent communique avec son bac à sable exclusivement par le biais d’appels d’API structurés et jamais par le biais d’un système de fichiers direct ou d’un accès au processus.
Cycle de vie des processus de l’outil
Chaque appel d’outil lance un nouveau processus à l’intérieur du bac à sable :
- Un nouveau processus commence par son propre environnement.
- Le proxy réseau transfère les flux d'entrée et de sortie via WebSocket.
- À la fin, l’arborescence de processus entière se termine.
Le système n’utilise pas de pools de processus persistants. Les variables d’environnement et les informations d’identification sont limitées par connexion. Un appel d’outil ne peut donc pas voir l’environnement d’un autre appel d’outil.
Exécution du code
Les commandes Python et du shell s’exécutent dans le bac à sable ADC à travers l’interpréteur de code.
- L’exécution est séparée de vos ressources ainsi que du moteur de raisonnement de l’agent.
- L'environnement inclut plus de 700 packages Python préinstallés, mais il ne prend pas en charge l'installation arbitraire des packages.
- Un proxy de sortie contrôle l’accès réseau et le limite aux domaines de service connus.
Gestion des informations d’identification sans secret
L’environnement d’exécution ne contient jamais d’informations d’identification directement. Au lieu de cela, un sidecar d’identité isolé gère tous les jetons et les fournit à la demande aux processus des outils individuels.
Flux des informations d’identification
- L’agent détermine qu’un appel d’outil est nécessaire.
- La requête est acheminée vers l'environnement de test.
- Le side-car d’identité émet un jeton de courte durée au processus de l’outil.
- L’outil effectue l’appel authentifié via le proxy réseau.
- Les résultats retournent à l’agent. Les informations d’identification n’entrent jamais dans le contexte de raisonnement.
Trois propriétés rendent le vol d’informations d’identification structurellement impossible :
- Sidecar d’isolation d’identité : un service distinct gère toutes les informations d’identification en dehors de l’environnement d’exécution de l’agent.
- Étendue par appel : les jetons sont limités aux appels d’outils individuels, et non partagés sur le bac à sable.
- Aucun héritage de variable d’environnement : seules les variables déclarées explicitement sont transférées aux processus outil.
Durée de vie des informations d’identification
| Catégorie | Durée de vie | Refresh |
|---|---|---|
| Jetons d’identité managée | ~1 heure (standard de plateforme Azure) | Automatisé via Kit de développement logiciel (SDK) Azure |
| jetons OAuth (GitHub, ADO) | Varie selon le fournisseur | Actualisé 20 minutes avant l’expiration |
| Jetons d’action (par appel d’outil) | Utilisation unique | Émis frais par appel |
| Jetons SAS de stockage Blob | 1 heure | Actualisé 15 minutes avant l’expiration |
Résidence des données
Lorsque votre agent examine un problème, il interroge Kusto, Azure Monitor, ARM et d’autres sources de données. L’agent conserve des résultats bruts de requête en mémoire uniquement pendant la conversation et les supprime lorsque la conversation se termine ou que la fenêtre de contexte se compacte. L’agent n’écrit jamais de résultats de requête bruts dans le stockage persistant.
Les données suivantes sont conservées :
| Data | Stockage | Retention | Purpose |
|---|---|---|---|
| Threads de conversation | Cosmos DB (par client) | Jusqu’à ce qu’elle soit supprimée manuellement | Historique des conversations, enregistrements d’investigation |
| Aperçus de session | Cosmos DB + stockage Blob pour agent | Persistante | Apprentissages synthétisés tels que les symptômes, les étapes de résolution et les causes racines |
| Fichiers mémoire | Stockage d’objets blob de l’agent (memories/) |
Persistent entre les sessions | Connaissances synthétisées, contexte d’équipe, instructions de dépôt |
| Fichiers de threads | Stockage d’objets blob de l’agent (threadfiles/) |
Lié à la durée de vie du thread | Téléversements d’utilisateurs, rapports générés |
Les insights de session sont des résumés synthétisés, et non des copies de données brutes. L’agent extrait des modèles (quels symptômes sont apparus, quelle résolution a fonctionné, et ce à éviter) et stocke ceux-ci en tant que connaissances. L’agent ne conserve jamais les résultats de requête bruts de Kusto ou d'Azure Monitor.
Isolation par client
| Couche | Modèle d’isolation |
|---|---|
| Calcul | Groupe d'environnement de tests ADC dédié par agent |
| Base de données | Séparer Cosmos DB par client |
| Stockage Blob | Compte de stockage par agent |
| Network | Instance de proxy par agent pour toutes les demandes sortantes |
| Credentials | Identité managée par agent avec RBAC limité aux groupes de ressources sélectionnés par le client |
Aucune donnée, calcul ou informations d’identification n’est partagée entre les agents ou les clients.
Journalisation et observabilité
Votre agent envoie des données de télémétrie opérationnelles à l’instance Application Insights que vous configurez lors de l’installation, ce qui vous donne une visibilité complète sur les opérations de l’agent.
| Telemetry | Détails |
|---|---|
| Traces de conversation | Corrélé par ID de trace et identifiant de segment pour le suivi des demandes de bout en bout |
| Dépendances d’appel d’outil | Méthode, URL, durée et code d’état pour chaque appel sortant |
| Erreurs et exceptions | Détails complets de l’exception |
| Événements personnalisés | Activations de hook, événements d’incident et autres opérations spécifiques à l’agent |
Les données de télémétrie provenant de l'exécution de l'outil sandbox transitent par le même pipeline.
Encryption
| Couche | Protection |
|---|---|
| Au repos | Cosmos DB et stockage d’objets blob utilisent le chiffrement géré par Azure |
| En transit | HTTPS pour toutes les communications externes ; HTTP/2 dans la limite de confiance du bac à sable |
Proxy réseau et stratégies
Tous les accès réseau sortants à partir de l’environnement d’exécution transitent par une couche proxy qui applique les stratégies suivantes :
- Validation de la demande : chaque connexion sortante est validée avant d’atteindre un service externe.
- Injection d’informations d’identification : le proxy attache des jetons délimités à partir du side-car d’identité ; le code outil ne gère jamais directement les jetons.
- Étendue de l’environnement : seules les variables d’environnement déclarées explicitement sont transférées aux processus d’outil.
- Cycle de vie des processus : les processus d'outils sont arrêtés à leur achèvement ou à expiration.
Remplacement par défaut
Lorsque l’identité managée de l’agent ne dispose pas d’autorisations pour une opération, le système revient à agir en votre nom :
- L’agent tente l’opération avec son identité managée.
- Les autorisations sont insuffisantes et vous voyez une invite à l'action Approuver comprenant les détails de l’opération.
- Vous approuvez et l’opération s’exécute avec vos informations d’identification.
- Vos informations d’identification ne sont pas mises en cache après l’achèvement.
Les modes d’exécution contrôlent ce comportement : le mode révision nécessite une approbation pour les opérations d’écriture, tandis que le mode autonome utilise directement l’identité managée. Pour plus d’informations, consultez Autorisations de l’agent.
Accès réseau privé
Azure Calcul dédié prend en charge les configurations de déploiement pour les exigences de réseau privé :
- Isolation régionale : le placement des bacs à sable respecte les limites régionales (par exemple, les bacs à sable USA Est 2 restent dans les régions du Centre des États-Unis, du Nord des États-Unis ou du Canada Central).
- Exécution intégrée au VNET - Les groupes de sandbox provisionnés par ARM permettent l'exécution au sein de votre réseau virtuel.
- Accès aux informations d’identification en fonction du volume : les montages de volumes MSI fournissent un accès aux informations d’identification sans traversée réseau.