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 a son propre bac à sable. Cette architecture offre à chaque agent un environnement de calcul dédié qui s’exécute dans une micro VM et reste séparé 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 (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 shell s’exécutent dans le bac à sable via 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 |
| OAuth tokens (GitHub, Azure DevOps) | 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 enquête sur un problème, il interroge vos sources de données. L’agent n’écrit pas de résultats bruts de requête comme les entrées de journal, les métriques et les réponses API dans un magasin de données séparé. Lorsque l’agent traite un appel d’outil, il sérialise les messages de chat et d’outils, y compris les résumés des résultats, dans le fil de conversation persistant.
Les données suivantes sont conservées :
| Data | Stockage | Retention | Purpose |
|---|---|---|---|
| Threads de conversation | Base de données d’agents | Jusqu’à ce qu’elle soit supprimée manuellement | Historique des conversations, enregistrements d’investigation |
| Aperçus de session | Stockage de base de données et blobs d’agents | Persistante | Apprentissages synthétisés tels que les symptômes, les étapes de résolution et les causes racines |
| Fichiers mémoire | Stockage de blobs | Persistent entre les sessions | Connaissances synthétisées, contexte d’équipe, instructions de dépôt |
| Fichiers de threads | Stockage de blobs | 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 pas lui-même l’intégralité des résultats bruts de la requête. Il stocke des messages d’outils sérialisés, qui peuvent inclure des extraits de résultats ou des résumés, dans l’historique du fil de conversation.
Isolation par client
| Couche | Modèle d’isolation |
|---|---|
| Calcul | Bac à sable dédié par agent |
| Base de données | Base de données séparée par agent |
| Stockage Blob | Stockage des blobs distinct pour chaque 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 | Le chiffrement géré par Azure protège toutes les données au repos |
| En transit | Toute communication externe utilise HTTPS |
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 SRE Agent prend en charge les configurations de déploiement selon les besoins du 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 à VNet : Des bacs à sable dédiés peuvent être configurés pour l’exécution au sein de votre réseau virtuel.
- Accès aux identifiants sans secret : Le service d’identité fournit des identifiants de courte durée aux processus d’outils sans stocker ces identifiants dans le bac à sable.