Rôles et autorisations de l’espace de travail

Différents paramètres couvrent différentes parties de l’expérience ChatGPT de votre organisation. Accorder à une personne un accès dans un domaine ne lui donne pas automatiquement accès à un autre. Utilisez cette page pour comprendre comment les six périmètres de contrôle fonctionnent ensemble, puis suivez les instructions accessibles par les liens pour connaître les étapes de configuration actuelles.

Dans les paramètres de l’espace de travail, Codex et Work en local regroupe l’accès local à Codex et à Work sous Autoriser les membres à utiliser Codex et Work localement. D’autres espaces de travail séparent Codex Local et Work Local en sections indépendantes. Dans cette disposition, Autoriser les membres à utiliser Codex localement accorde l’accès local à Codex, tandis que Utiliser Work localement accorde l’accès local à Work. L’activation de l’un n’accorde pas l’accès à l’autre. Ces libellés désignent des autorisations de l’espace de travail, et non des produits ou clients distincts. Les autorisations relatives aux jetons et les limites de durée de vie des identifiants apparaissent soit dans une section Jetons d’accès, soit dans la section consacrée à l’accès local, selon l’espace de travail. La configuration gérée constitue une couche distincte qui limite le comportement d’exécution pris en charge pour les fonctionnalités concernées dans ces clients. Les fonctionnalités et les exigences effectives peuvent varier selon le client et la version.

Comprendre les périmètres de contrôle

Une requête doit franchir chaque périmètre qui lui est applicable. Par exemple, l’accès à l’espace de travail peut rendre un plugin disponible, mais le service connecté détermine toujours les données que le compte connecté peut lire. Un profil d’autorisation local peut restreindre une exécution dans un client local pris en charge, mais il ne peut pas accorder l’accès à une fonctionnalité de l’espace de travail ni à un modèle.

Attribuer l’accès à l’espace de travail

L’administration de l’espace de travail ChatGPT sépare l’accès aux produits de l’autorité administrative.

Comprendre la différence entre une licence, un rôle d’administrateur et un rôle personnalisé

Une licence détermine les surfaces produit auxquelles un membre peut accéder. Selon l’offre de l’espace de travail, les types de licences disponibles peuvent inclure des licences ChatGPT et Codex.

Les rôles intégrés à l’espace de travail déterminent l’autorité administrative. Le rôle Propriétaire gère les paramètres qui s’appliquent à l’ensemble de l’espace de travail, le rôle Administrateur gère les opérations prises en charge et les groupes, le rôle Membre ne dispose d’aucun droit d’administration, et le rôle Lecteur des analyses permet d’accéder aux analyses de l’espace de travail.

Les rôles personnalisés définissent les fonctionnalités prises en charge qu’un membre peut utiliser. Ils ne remplacent pas l’éligibilité liée à la licence ou à l’offre, n’accordent pas d’autorisations dans un système connecté et ne modifient pas les exigences d’exécution locale.

Définir les paramètres par défaut de l’espace de travail, puis créer des rôles personnalisés ciblés

Seuls les propriétaires de l’espace de travail peuvent configurer le contrôle d’accès basé sur les rôles (RBAC) et créer des rôles personnalisés. Les paramètres de l’espace de travail établissent la base de référence pour les autorisations éligibles. Les propriétaires de l’espace de travail peuvent attribuer des rôles personnalisés par l’intermédiaire de groupes ou directement à des membres individuels lorsque cette fonctionnalité est prise en charge. Les groupes peuvent être gérés manuellement ou synchronisés par SCIM, et un membre peut recevoir plusieurs rôles personnalisés.

Pour les autorisations concernées, Par défaut hérite du paramètre de l’espace de travail, Activé accorde l’accès par l’intermédiaire de ce rôle et Désactivé n’accorde pas l’accès par l’intermédiaire de ce rôle. Les autorisations ordinaires des rôles se cumulent : un autre rôle attribué peut toujours accorder l’accès. Vérifiez les attributions directes et les rôles obtenus via des groupes. Lockdown Mode et l’éligibilité au produit s’appliquent séparément. Les états disponibles pour les autorisations peuvent varier selon la fonctionnalité.

Examiner les autorisations Work Local et Work Cloud

Configurez Utilisation du navigateur cloud et Accès réseau cloud sous Console d’administration > Autorisations et rôles > Capacités de l’espace de travail > Capacités de l’ordinateur cloud. Ces capacités partagées sont disponibles pour Work Cloud et dots et peuvent être configurées 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 capacités dont elle a besoin. Examinez séparément l’accès au navigateur et l’accès réseau du code ou du shell. La désactivation de l’un ne désactive pas automatiquement l’autre.

Lorsque votre espace de travail propose Work Local et Work Cloud, vérifiez à la fois les paramètres par défaut de l’espace de travail et chaque rôle personnalisé applicable. Work n’est disponible que pour les espaces de travail éligibles, et les contrôles disponibles peuvent varier selon l’offre, la configuration de l’espace de travail et le déploiement progressif. Un rôle ne peut pas étendre l’accès autorisé par la licence d’un membre.

Work Cloud régit les tâches ChatGPT Work prises en charge dans le cloud. Lorsque les contrôles sont indépendants, Work Local sans Work Cloud autorise le travail local dans l’application de bureau ChatGPT, mais ne permet pas aux membres de démarrer des tâches dans le cloud. L’accès local à Codex utilise Autoriser les membres à utiliser Codex localement dans Codex Local. La modification de Utiliser Work localement ne modifie pas l’accès local à Codex et ne remplace pas les exigences d’exécution locale.

Certains espaces de travail affichent à la place la section combinée Codex et Work en local. Dans cette disposition, Autoriser les membres à utiliser Codex et Work localement contrôle les deux produits.

Pour connaître les critères d’éligibilité et les paramètres actuels, consultez ChatGPT Work et Codex.

Étant donné que les licences, rôles et autorisations disponibles évoluent au gré des mises à jour du produit et des offres, consultez le Centre d’aide pour obtenir la liste actuelle des autorisations et la procédure de configuration :

• Gérer les membres, les types de licences, les rôles et les accès
• Configurer le contrôle d’accès basé sur les rôles
• Gérer les groupes

Vérifiez l’accès à Codex Cloud et l’administration des environnements

Examinez ces autorisations séparément :

Gérer les environnements de l’espace de travail se trouve sous Utiliser Codex dans le cloud, nécessite l’accès au cloud et est désactivé par défaut. Vérifiez les accès accordés avant le déploiement. Les membres disposant d’un accès au cloud peuvent créer et modifier leurs propres environnements personnels sans l’autorisation de gestion. L’accès à un environnement partagé ne confère pas à lui seul le droit de modifier sa configuration.

Vérifiez les deux workflows avec des identités représentatives : un membre utilisant un environnement et la personne chargée de le gérer. Chacun doit également disposer des accès appropriés aux dépôts et services connectés. Consultez Environnements cloud pour la configuration et le partage, et le guide de déploiement pour les administrateurs pour la planification des politiques cloud.

Accès à l’ordinateur local avec Work Cloud

Un propriétaire de l’espace de travail peut activer Autoriser l’accès à l’ordinateur local pour les utilisateurs éligibles. Activez Work Cloud pour les utilisateurs concernés. Autoriser l’accès à l’ordinateur local se trouve sous Work Cloud. Vous n’avez pas besoin d’activer Utiliser Codex localement dans l’application de bureau ChatGPT. Les membres doivent se connecter avec ChatGPT à l’espace de travail prévu. Si enforce_residency est activé dans une politique cloud quelconque, Autoriser l’accès à l’ordinateur local est désactivé pour Work comme pour dots. Cette 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 dots.

Avant d’activer la synchronisation, examinez les exigences d’Agent Security pour l’exécution locale. Si vous distribuez actuellement les politiques uniquement via MDM, vérifiez l’ordre de priorité des politiques locales applicable avant de configurer Agent Security. Pour l’exécution locale, les exigences MDM et les anciennes exigences des appareils gérés sont prioritaires sur Agent Security, tandis que le fichier d’exigences système est moins prioritaire. La politique Global prise en charge régit l’orchestration cloud lorsque la politique gérée est activée ; les exigences d’exécution locale régissent l’ordinateur connecté. Les conteneurs cloud de Work conservent les politiques Work Cloud existantes.

Utilisez l’API de gestion des politiques pour gérer les paramètres Global. Pour gérer les paramètres Local ou Codex Cloud, utilisez l’interface d’Agent Security. Les workflows API Global existants restent disponibles après la migration. Testez vos scripts et vos intégrations Terraform, et confirmez que les attributions et l’ordre de priorité des politiques restent inchangés.

Configurez et vérifiez l’accès :

• Veillez à ce que le paramètre par défaut de l’espace de travail convienne à l’ensemble de l’organisation.

• Attribuez les rôles personnalisés pris en charge aux utilisateurs ou aux groupes qui ont besoin d’un accès.

• Examinez chaque rôle applicable. Désactiver une autorisation dans un rôle ordinaire ne supprime pas l’accès accordé par un autre.

• Testez l’accès avec un membre disposant des autorisations prévues.

Les tâches utilisant l’accès à l’ordinateur local avec Work Cloud sont coordonnées dans le cloud et peuvent toujours exécuter des étapes locales sur un ordinateur connecté. Pour les entreprises, le sélecteur Local/Cloud de l’application et son réglage par défaut restent inchangés au lancement. L’autorisation de synchronisation n’accorde ni licence utilisateur, ni accès aux applications connectées, ni autorisations du système d’exploitation, ni accès illimité à l’appareil. Les autorisations et le comportement de Codex en local restent distincts. Consultez Configuration gérée pour connaître le périmètre des politiques et la FAQ pour les administrateurs de Work pour les exigences de compatibilité.

La désactivation de l’accès à l’ordinateur local avec Work Cloud interrompt les tours en cours. Les utilisateurs peuvent démarrer un nouveau tour dans une conversation cloud existante. Ce tour utilise automatiquement Work Cloud sans accès aux fichiers locaux. La désactivation de la synchronisation ne supprime pas à elle seule l’accès du membre à l’espace de travail.

Contrôler l’accès à Computer History

Historique de l’ordinateur est désactivé par défaut pour les espaces de travail Business et Enterprise. Les membres ne peuvent pas l’activer tant qu’un propriétaire de l’espace de travail n’a pas explicitement accordé l’accès. Les propriétaires d’un espace de travail Enterprise peuvent accorder l’accès par rôle :

1. Ouvrez Paramètres de l’espace de travail > Autorisations et rôles.
2. Recherchez Computer History et choisissez le rôle de l’espace de travail qui doit y avoir accès.
3. Activez Activer Computer History pour ce rôle.

Cette autorisation permet uniquement aux membres concernés d’activer Computer History ; elle n’active pas la fonctionnalité à leur place. Chaque membre doit choisir de l’activer depuis l’application de bureau ChatGPT sur macOS et peut sélectionner les applications et sites web qui y contribuent. Les membres qui ne disposent pas de l’autorisation requise dans l’espace de travail ne peuvent pas activer la fonctionnalité dans les paramètres locaux.

Appliquer une stratégie d’exécution locale

La stratégie d’exécution locale restreint les fonctionnalités concernées dans l’application de bureau ChatGPT, Codex CLI et l’extension IDE. Les exigences gérées dans le cloud dépendent également de la prise en charge de la connexion à ChatGPT et de l’éligibilité de l’offre. Les profils d’autorisation et les exigences gérées peuvent restreindre les commandes, l’accès au système de fichiers, l’accès au réseau, les approbations et d’autres comportements d’exécution locale. Ils ne modifient pas la licence de l’utilisateur, son rôle dans l’espace de travail, son accès aux modèles ni ses autorisations dans un système externe.

Les utilisateurs peuvent sélectionner un profil d’autorisation intégré ou personnalisé lorsque la stratégie locale l’autorise. Les administrateurs peuvent distribuer des valeurs par défaut et des exigences par l’intermédiaire des canaux de configuration gérée pris en charge. Consultez Autorisations pour le comportement des profils et Configuration gérée pour les exigences, leur distribution et leur ordre de priorité.

Documentation associée

• Guide de déploiement pour les administrateurs
• Groupes et provisionnement
• Gestion du cycle de vie des utilisateurs
• Disponibilité des modèles dans l’espace de travail
• Jetons d’accès
• Configuration gérée
• Authentification