Sécurité des agents

Dans la console d’administration, utilisez la section Sécurité des agents pour gérer les politiques et la configuration. Elle remplace la section Politiques et configuration. Son déploiement est indépendant de celui de l’accès à l’ordinateur local pour Work et les dots.

Lors de la migration des anciennes politiques cloud éligibles, leurs paramètres sont repris dans Global. Les affectations et l’ordre des politiques sont conservés. Vérifiez les politiques migrées dans Sécurité des agents. L’accès à l’ordinateur local s’active séparément pour Work et pour les dots.

Portée des paramètres

Chaque politique définit des paramètres de base dans Global. Vous pouvez remplacer les paramètres d’exécution pris en charge pour l’environnement Local ou Codex Cloud. Pour chaque paramètre sans valeur propre à l’environnement, celui-ci hérite de la valeur applicable définie dans Global pour cette politique.

• Global : définissez les contrôles de l’orchestrateur, notamment pour les approbations et la recherche web, ainsi que les paramètres d’exécution communs.

• Local : ajustez les paramètres d’exécution pris en charge pour les tâches qui s’exécutent sur un ordinateur connecté.

• Codex Cloud : ajustez les paramètres d’exécution pris en charge pour les tâches Codex dans le cloud. Vous pouvez configurer ces politiques avant d’activer Codex Cloud, mais elles ne s’appliquent qu’une fois Codex Cloud activé sur la page des autorisations. Work Cloud dispose d’autorisations distinctes pour ses fonctionnalités, décrites dans la section Application des politiques de sécurité des agents à Work Cloud.

Définir les paramètres de base et ajouter des paramètres par environnement

1. Ouvrez Sécurité des agents et examinez vos politiques globales existantes, leurs affectations et leur ordre. Vérifiez qu’elles correspondent aux contrôles prévus par votre organisation. Cette vérification n’active pas l’accès à l’ordinateur local avec Work Cloud.

2. Examinez séparément les sections Exigences et Valeurs par défaut. Les exigences fixent des limites que les utilisateurs ne peuvent pas outrepasser. Les valeurs par défaut définissent les valeurs initiales dans ces limites.

3. Conservez les contrôles de l’orchestrateur dans Global. Ils comprennent les exigences d’approbation, les modes de recherche web autorisés et les contrôles des outils gérés.

4. Ajoutez des paramètres propres à Local ou à Codex Cloud pour les contrôles d’exécution pris en charge, comme le bac à sable, les autorisations du système de fichiers et la gestion de l’accès réseau pendant l’exécution. Si un paramètre doit s’appliquer à un seul système d’exploitation, définissez une valeur de remplacement propre à ce système.

5. Enregistrez la politique et examinez les éventuels messages de validation concernant les paramètres saisis.

Choisir les contrôles et les champs de configuration

L’orchestrateur coordonne la tâche. L’exécuteur est l’ordinateur ou le conteneur cloud qui exécute une étape de la tâche. Configurez les contrôles de l’orchestrateur dans Global. Les paramètres du fichier requirements.toml d’un environnement ne prennent en charge que les contrôles d’exécution. Les paramètres de l’orchestrateur, comme la politique d’approbation et la recherche web, restent dans Global. Aucun environnement ne peut les remplacer.

Contrôles de l’orchestrateur

Configurez ces contrôles dans Global. Pour Work avec accès local et pour les dots, l’orchestrateur cloud partagé applique les paramètres pris en charge de la politique globale lorsque la gestion des politiques est activée. Un environnement peut remplacer les paramètres d’exécution pris en charge, mais pas les contrôles de l’orchestrateur. Parmi les exigences relatives aux approbations, à la recherche web, aux applications, à MCP, aux plugins et aux règles présentées ci-dessous, seules Politiques d’approbation autorisées et Modes de recherche web autorisés disposent de contrôles dédiés dans l’interface Sécurité des agents. Configurez les autres champs en TOML.

Hooks pour l’accès à l’ordinateur local avec Work Cloud

Dans Global, utilisez Modifier au format TOML pour configurer les gestionnaires mcp_tool pour Work avec accès à l’ordinateur local et pour les dots. Avant de vous appuyer sur un hook pour bloquer un outil, testez son comportement en cas d’échec d’une fonction de rappel et en cas de refus explicite. Consultez la section Hooks avec orchestration cloud pour connaître les gestionnaires et les événements pris en charge.

Global contient également des paramètres pour l’application de bureau et les clients. Certains s’appliquent uniquement à l’application de bureau. Un paramètre défini dans Global ne s’applique donc pas nécessairement partout. Consultez la référence de configuration pour connaître les usages pris en charge pour chaque champ.

Contrôles d’exécution (exécuteur)

Ces champs déterminent comment les tâches s’exécutent sur un ordinateur ou dans un conteneur cloud. Définissez les valeurs communes dans Global. Si un paramètre pris en charge doit avoir une valeur différente dans Local ou Codex Cloud, définissez une valeur de remplacement dans cet environnement.

Le tableau indique les groupes de champs dont les valeurs peuvent être remplacées par environnement. Les options prises en charge dans chaque groupe peuvent varier selon la plateforme. Certaines exigences de politiques différentes se combinent au lieu de se remplacer. Consultez la référence de configuration pour connaître les valeurs prises en charge et le guide de la configuration gérée pour les exceptions réseau.

Pour les modes d’exécution gérés pris en charge par Codex Cloud, autoriser un domaine dans Sécurité des agents ne lève pas une restriction imposée par l’environnement. Si une élévation complète des privilèges du bac à sable est approuvée, la commande peut s’exécuter sans passer par le proxy de commandes géré. Consultez la section Isolation réseau pour connaître la portée du proxy.

Configurer le réseau dans l’interface

1. Ouvrez Console d’administration > Sécurité des agents. Sélectionnez une politique, puis choisissez Global, Local ou Codex Cloud. Utilisez Global pour les paramètres de base communs et définissez dans l’environnement les valeurs de remplacement prises en charge.
2. Ouvrez Exigences et activez Gérer l’accès réseau. Ajoutez les domaines nécessaires et choisissez Autoriser ou Refuser pour chacun. Activez Autoriser uniquement les domaines ajoutés par les administrateurs si la configuration utilisateur ordinaire et les approbations accordées domaine par domaine ne doivent pas étendre la liste d’autorisation du proxy géré.
3. Avant d’enregistrer, vérifiez les paramètres effectifs et les règles héritées. Lorsqu’un paramètre d’environnement est vide, l’environnement hérite de la valeur définie dans Global au lieu de l’effacer. Pour Codex Cloud, vérifiez séparément la connectivité aux réseaux locaux ou privés. Désactiver la gestion de l’accès réseau et désactiver l’accès à Internet de l’environnement Cloud sont deux opérations distinctes.
4. Pour Codex Cloud, vérifiez également les paramètres d’accès à Internet, de destination et de méthode de l’environnement. Enregistrez, puis testez une requête censée être autorisée et une autre censée être bloquée. Testez séparément toute élévation complète des privilèges du bac à sable permise par la politique.

Aucune destination effectivement autorisée

Lorsque Gérer l’accès réseau et Autoriser uniquement les domaines ajoutés par les administrateurs sont activés, les commandes gérées ordinaires ne peuvent accéder qu’aux destinations effectivement autorisées. Si aucune entrée Autoriser n’est définie ni héritée, ces commandes ne peuvent accéder à aucune destination. Une politique qui contient uniquement des refus n’autorise pas implicitement le reste d’Internet. Ajoutez les entrées Autoriser nécessaires et vérifiez les règles héritées avant d’enregistrer. Cette restriction concerne le proxy de commandes géré. Elle ne s’étend pas à tous les outils ni aux exécutions ayant obtenu une élévation complète des privilèges du bac à sable.

Connectivité de Codex Cloud aux réseaux locaux ou privés

Désactiver explicitement la connectivité aux réseaux locaux ou privés peut empêcher Codex Cloud de joindre son proxy en amont, même si le domaine de destination est autorisé. Vérifiez la valeur effective de allow_local_binding et identifiez la politique ou le paramètre qui la définit. Lorsque Codex Cloud utilise le proxy pris en charge, cette valeur est true par défaut uniquement si aucune exigence applicable, aucun profil réseau sélectionné et aucun paramètre de la fonctionnalité de proxy ne fournit de valeur. Une valeur false héritée compte comme une valeur explicite. Si l’exécuteur le permet, définissez dans Cloud une valeur de remplacement plus prioritaire pour modifier ce paramètre dans Codex Cloud sans changer la valeur de Global utilisée par Local. Cette opération n’ajoute aucune entrée Autoriser pour les domaines. Vérifiez que l’exécuteur prend en charge ce remplacement avant de vous y fier. N’appliquez pas cette valeur par défaut de Cloud à Local.

Valeurs par défaut des environnements

L’éditeur de valeurs par défaut utilise les champs de config.toml, qui diffèrent des contraintes de requirements.toml. Les environnements prennent en charge les valeurs par défaut de premier niveau suivantes :

• Comportement du shell : allow_login_shell et shell_environment_policy.

• Bac à sable et autorisations : sandbox_mode, sandbox_workspace_write, default_permissions et permissions.

• Exécution sur Windows : windows.

Une valeur par défaut ne remplace pas une exigence obligatoire. Conservez dans Global les valeurs par défaut de l’orchestrateur, notamment les paramètres d’approbation et de recherche web.

Combinaison des politiques

• Entre plusieurs politiques, la plus prioritaire l’emporte, même si une politique moins prioritaire est plus spécifique.

• Au sein d’une même politique, l’ordre de priorité des paramètres d’exécution pris en charge est le suivant : la valeur de remplacement de l’environnement propre au système d’exploitation, puis celle de l’environnement commune à tous les systèmes d’exploitation, puis celle de Global.

• Pour l’exécution locale, les exigences MDM et les anciennes exigences relatives aux appareils gérés priment sur celles de Sécurité des agents. Sécurité des agents prime à son tour sur le fichier d’exigences système de l’appareil.

Pour une même règle de domaine au sein d’une politique, un administrateur peut définir une valeur de remplacement dans un environnement pour autoriser un domaine refusé dans Global ou refuser un domaine autorisé dans Global. En l’absence de valeur de remplacement, l’environnement hérite de la règle de Global. D’autres règles de refus ou contrôles d’accès en vigueur peuvent toujours bloquer une requête.

Ces résultats concernent une même clé de domaine au sein d’une politique, à condition qu’aucune politique plus prioritaire ne modifie le résultat. Une valeur plus prioritaire remplace celle de la même clé. Les autres clés héritées sont conservées. Une règle Autoriser ne permet pas de contourner une autre règle Refuser qui correspond à la requête, par exemple une règle héritée contenant un caractère générique. Une table de règles vide dans l’environnement n’efface pas les règles héritées.

Application des politiques de sécurité des agents à Work Cloud

Configurez Navigateur cloud et Accès réseau cloud sous Console d’administration > Autorisations et rôles > Fonctionnalités de l’espace de travail > Fonctionnalités des ordinateurs cloud. Work Cloud et les dots disposent de ces fonctionnalités partagées, que vous pouvez configurer indépendamment de l’accès à Work Cloud. Une tâche Work nécessite toujours l’accès à Work et l’autorisation d’utiliser chacune des fonctionnalités dont elle a besoin. Vérifiez séparément l’accès au navigateur et l’accès réseau du code ou du shell. Désactiver l’un ne désactive pas automatiquement l’autre.

Les conteneurs de Work Cloud et les ordinateurs cloud des dots utilisent leur propre configuration d’exécution et leurs propres exigences. Les autres types d’exécuteurs utilisent un ensemble de paramètres d’environnement gérés. Les restrictions locales relatives aux fichiers et au réseau ne s’appliquent pas automatiquement à ces ordinateurs cloud. Les paramètres pris en charge de la politique globale de l’orchestrateur ont une portée distincte. Ni une politique globale ni une valeur de remplacement de Codex Cloud ne permettent de configurer les autorisations des fonctionnalités cloud partagées. Vérifiez ces autorisations séparément.

Pour vérifier les accès effectifs d’un membre, examinez les paramètres par défaut de l’espace de travail, tous les rôles attribués directement ou via un groupe, ainsi que les restrictions appliquées séparément, comme le mode de verrouillage.

Avant d’activer Autoriser l’accès à l’ordinateur local dans Work Cloud, examinez les paramètres de base de Global et vérifiez leur compatibilité avec les contrôles sur lesquels s’appuie votre organisation. Il n’est pas nécessaire d’activer Utiliser Codex localement dans l’application de bureau ChatGPT. Si enforce_residency est activé dans au moins une politique cloud, Autoriser l’accès à l’ordinateur local est désactivé pour Work comme pour les dots. Cette mesure de protection ne configure pas la résidence des données de l’espace de travail et ne désactive pas à elle seule Work Cloud ou les dots. Consultez le guide Accès à l’ordinateur local pour Work Cloud et les dots pour connaître les étapes de configuration propres à chacun, les conditions d’éligibilité et le fonctionnement de la connexion.

API de gestion des politiques et Terraform

Utilisez l’API de gestion des politiques pour gérer les paramètres de Global. Pour gérer les paramètres de Local ou de Codex Cloud, utilisez l’interface Sécurité des agents. Les workflows existants qui utilisent l’API pour Global restent disponibles après la migration. Testez vos scripts et vos intégrations Terraform, puis vérifiez que les affectations et l’ordre des politiques ont été conservés.

La migration des politiques ne modifie ni la synchronisation des appartenances via SCIM ni les rôles RBAC.

Guides associés

• Configuration gérée : distribution des politiques, ordre de priorité et règles de fusion propres à chaque champ.

• Référence de configuration : définition des champs et compatibilité avec Work.

• Accès à l’ordinateur local pour Work Cloud et les dots : prérequis et étapes de configuration.

• Rôles et autorisations de l’espace de travail : accès aux fonctionnalités de Work et de Codex.