Sécurité de ChatGPT Work en local

ChatGPT Work peut utiliser des fichiers, des applications et des sessions de navigateur approuvés sur l’ordinateur de l’utilisateur pour effectuer des tâches locales. L’accès dépend des permissions de l’espace de travail, des droits dont l’utilisateur dispose déjà sur ses comptes, des permissions du système d’exploitation, des approbations accordées aux applications et des politiques prises en charge sur l’appareil.

Pour une vue d’ensemble des contrôles de sécurité, consultez le livre blanc sur la sécurité de ChatGPT Work en entreprise.

Les fonctionnalités locales disponibles dépendent de l’application de bureau prise en charge, du système d’exploitation, des fonctionnalités auxquelles l’espace de travail donne droit, des permissions du rôle, de la politique de l’appareil et du déploiement du produit.

La sécurité en bref

• Les étapes locales s’exécutent via l’application de bureau ChatGPT. Avec l’accès à l’ordinateur local depuis Work Cloud, le cloud d’OpenAI coordonne la tâche et l’ordinateur connecté exécute les étapes qui nécessitent son intervention.

• Les contrôles disponibles pour les versions locale et hébergée de Work dépendent de la configuration de l’espace de travail et du déploiement.

• L’accès aux fichiers, la fonctionnalité Utilisation de l’ordinateur, les navigateurs et les applications connectées ont chacun leurs propres permissions et approbations.

• Si un compte est déjà connecté à un système de l’entreprise dans un navigateur ou une application, une tâche peut y exercer les droits de ce compte.

• Les politiques prises en charge sur les appareils gérés peuvent restreindre les fonctionnalités locales. Les contrôles d’accès de l’espace de travail continuent de s’appliquer.

• Les services OpenAI couverts chiffrent les données des espaces de travail Business, Enterprise et Edu en transit et au repos. Par défaut, OpenAI n’utilise pas ces données pour entraîner ses modèles.

• Les fichiers locaux, le contexte de la tâche, les données du navigateur, les enregistrements des systèmes connectés et les événements d’audit peuvent être soumis à des règles de stockage et de conservation différentes.

Où s’exécutent les tâches locales ?

Lors de l’exécution locale, la tâche accède aux ressources approuvées via l’application de bureau installée sur l’ordinateur de l’utilisateur. Lorsque l’accès à l’ordinateur local depuis Work Cloud est activé, le cloud d’OpenAI coordonne la tâche et sollicite l’ordinateur connecté pour les étapes qui nécessitent une exécution locale. L’ordinateur doit être en ligne et connecté pour exécuter ces étapes.

Les exigences de l’appareil s’appliquent à l’exécution locale. Si un nouveau tour s’exécute dans un conteneur cloud alors que l’ordinateur est hors ligne, le conteneur applique ses propres politiques et ne peut accéder ni aux fichiers ni aux outils locaux. Consultez la section Poursuivre une tâche Work sur un autre appareil.

Les fichiers locaux peuvent rester sur l’appareil, mais les services OpenAI peuvent recevoir les extraits de fichiers, les prompts, les captures d’écran, les contenus du navigateur ou les résultats d’outils nécessaires à la tâche. L’exécution locale ne signifie pas que le modèle effectue l’inférence hors ligne ou uniquement sur l’appareil.

Accès aux fichiers et à l’appareil

Une tâche locale peut exploiter les informations que l’utilisateur lui fournit ou met à sa disposition, notamment les fichiers pris en charge, le contenu des applications, les sessions de navigateur et les systèmes connectés autorisés. L’accès dépend des droits dont l’utilisateur dispose déjà et des contrôles propres à chaque fonctionnalité.

Accorder à Work un accès local n’approuve pas automatiquement toutes les applications, ne confère pas de droits d’administrateur et ne permet pas de contourner les permissions du compte utilisé pour accéder à un autre système. Une connexion partagée approuvée peut disposer de droits différents de ceux du compte personnel de l’utilisateur.

La lecture directe de fichiers, leur modification et l’exécution de commandes shell obéissent aux paramètres du bac à sable et d’approbation de la tâche. La fonctionnalité Utilisation de l’ordinateur accède au contenu via une application native approuvée, avec les permissions de cette application. Une restriction de l’accès direct aux fichiers ne s’étend pas nécessairement aux fichiers que l’application peut ouvrir.

Utilisation de l’ordinateur et approbation des applications

Les permissions de l’espace de travail déterminent qui peut utiliser Work Local. Les administrateurs peuvent aussi limiter les applications natives que la fonctionnalité Utilisation de l’ordinateur peut piloter et décider si les approbations accordées aux applications peuvent être enregistrées pour les sessions futures. Les permissions du système d’exploitation et les approbations requises pour les applications restent nécessaires. Lorsqu’une tâche utilise une application ou un compte connecté, les permissions du compte déterminent les informations accessibles et les actions possibles.

Autoriser une application dans une politique d’administration n’installe pas le plugin requis, n’accorde aucune permission du système d’exploitation et ne vaut pas approbation pour une action qui doit encore être examinée. Pour connaître les contrôles pris en charge et consulter des exemples de configuration, voir Contrôles gérés pour le navigateur et l’utilisation de l’ordinateur.

Sur macOS, la permission Enregistrement de l’écran permet à la fonctionnalité Utilisation de l’ordinateur de voir le contenu des applications. La permission Accessibilité lui permet de cliquer, de saisir du texte et de naviguer. Les tâches prises en charge sur macOS peuvent s’exécuter en arrière-plan. Sur Windows, la fonctionnalité Utilisation de l’ordinateur agit sur le bureau actif et visible. Elle ne peut pas s’exécuter en arrière-plan pendant que l’utilisateur continue d’utiliser la même session.

Les utilisateurs peuvent arrêter une tâche à tout moment. La fonctionnalité Utilisation de l’ordinateur ne peut pas approuver les demandes de sécurité du système d’exploitation, s’authentifier en tant qu’administrateur ni automatiser des applications de terminal ou ChatGPT lui-même.

Appareils verrouillés

Certaines configurations macOS permettent, en option, à une tâche approuvée qui utilise la fonctionnalité Utilisation de l’ordinateur de se poursuivre après le verrouillage du Mac. Cette possibilité dépend de la version de l’application, du déploiement de la fonctionnalité, des exigences applicables et de l’éligibilité au contrôle à distance.

L’activation de l’utilisation en mode verrouillé installe un plugin d’autorisation macOS. Celui-ci peut déverrouiller temporairement le Mac pendant un tour actif et approuvé de la fonctionnalité Utilisation de l’ordinateur. ChatGPT masque le contenu de tous les écrans pendant ce déverrouillage. S’il détecte une frappe au clavier ou une action du pointeur sur le Mac, il verrouille à nouveau le Mac et suspend le déverrouillage automatique jusqu’à ce que l’utilisateur le déverrouille manuellement. Voir Fonctionnement de l’utilisation en mode verrouillé.

Les administrateurs peuvent empêcher les utilisateurs d’activer l’utilisation en mode verrouillé sur les Mac gérés. Cette exigence ne désactive pas la fonctionnalité si elle est déjà activée. Sur Windows, la fonctionnalité Utilisation de l’ordinateur nécessite un bureau actif et déverrouillé. Voir Restrictions de l’utilisation en mode verrouillé.

Sessions de navigateur et comptes déjà connectés

Work Local n’accède pas automatiquement à tous les navigateurs ni à tous les comptes de l’entreprise. L’accès dépend du navigateur utilisé, du compte connecté et des approbations requises pour ce mode d’accès.

Les politiques prises en charge par la fonctionnalité Navigateur peuvent restreindre l’accès aux sites, les envois de fichiers, les téléchargements, l’accès à l’historique de navigation et l’accès complet au protocole Chrome DevTools Protocol (CDP) pour le débogage du navigateur. Les administrateurs peuvent également restreindre la révision automatique des demandes d’approbation, l’enregistrement des approbations et la durée de validité des approbations d’accès aux sites. L’approbation d’un utilisateur ne peut pas annuler un refus de l’administrateur. Voir Contrôles gérés du navigateur.

Un navigateur hébergé dans le cloud est distinct des navigateurs locaux de l’utilisateur et ne reprend pas automatiquement leurs sessions authentifiées. Dans les espaces de travail Enterprise et Edu, il n’est pas possible de se connecter à un site web depuis le navigateur cloud.

Applications, plugins et comptes connectés

Une application connectée peut donner accès à des informations ou permettre des actions dans un autre système. Un plugin peut s’appuyer sur une application pour effectuer ses opérations. Mettre un plugin à disposition n’active pas automatiquement l’application requise, n’autorise pas un compte et ne permet pas toutes les actions.

Les paramètres par défaut des plugins et des applications dépendent de l’offre et diffèrent selon que l’espace de travail est nouveau ou existant. Certaines applications sont activées dès la création d’un espace de travail Enterprise ou Edu. Ces paramètres par défaut ne modifient pas ceux des espaces de travail existants et ne s’appliquent pas aux espaces de travail Healthcare. En règle générale, les nouveaux plugins et les nouvelles applications sont désactivés par défaut dans les espaces de travail Enterprise et Edu. Dans les espaces de travail Business, les applications sont activées par défaut. Les administrateurs peuvent modifier leur disponibilité. Consultez les paramètres par défaut actuels des plugins et des applications et la présentation de ChatGPT Work.

Avant qu’une tâche n’utilise un système connecté, vérifiez que l’espace de travail autorise l’application et tout plugin requis, que la connexion est autorisée et que le compte connecté peut accéder aux informations demandées ou effectuer l’action souhaitée. Les paramètres d’accès en lecture seule, les actions autorisées et les exigences de confirmation varient selon l’intégration.

Pour les plugins qui donnent accès au navigateur ou à la fonctionnalité Utilisation de l’ordinateur, examinez séparément les conditions de mise à disposition et d’installation. Mettre un plugin à disposition ne permet pas de contourner les politiques gérées du navigateur ou des applications natives, les permissions du système d’exploitation ni les approbations requises. Les plugins réservés à l’application de bureau et les outils fournis localement peuvent s’installer différemment. Voir Contrôles des plugins.

Connexions personnelles et partagées

Une connexion personnelle utilise les permissions de l’utilisateur connecté dans le système source. Une connexion partagée ou appartenant à un agent utilise les permissions du compte connecté, qui peuvent être plus étendues que les droits propres de l’utilisateur.

Limitez les droits des comptes partagés aux données et aux actions nécessaires, restreignez l’accès à ces comptes aux seules personnes autorisées et appliquez les contrôles d’action ou de confirmation pris en charge. Les enregistrements du système connecté restent soumis aux permissions et aux politiques de conservation de ce système.

Accès administrateur et politiques des appareils gérés

Pour l’accès à l’ordinateur local depuis Work Cloud, vérifiez à la fois la permission de synchronisation de l’espace de travail et les exigences d’Agent Security relatives à l’exécution locale.

Pour l’exécution locale, les exigences MDM et les exigences héritées relatives aux appareils gérés ont priorité sur celles d’Agent Security. Les exigences définies dans le fichier système de l’appareil ont une priorité inférieure à celles d’Agent Security. Au sein d’une même politique, les paramètres d’environnement dérogatoires propres à un système d’exploitation ont priorité sur ceux qui s’appliquent à tous les systèmes d’exploitation. Les paramètres Global viennent en dernier. La politique de priorité supérieure l’emporte même si une politique de priorité inférieure est plus spécifique. Certaines exigences suivent des règles de fusion propres à chaque champ.

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. Après la migration, les workflows existants qui gèrent les paramètres Global via l’API restent disponibles. Testez vos scripts et vos intégrations Terraform, puis vérifiez que l’attribution des politiques et leur ordre de priorité n’ont pas changé.

Pour Work avec accès local et pour les dots, la politique Global prise en charge s’applique via l’orchestrateur cloud partagé lorsque la gestion des politiques est activée. Sur un ordinateur connecté, les exigences locales applicables définies dans requirements.toml régissent l’exécution. Les conteneurs cloud de Work 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 d’exécution locale ne s’appliquent pas automatiquement à ces ordinateurs cloud. Vérifiez les permissions des fonctionnalités cloud et testez séparément l’exécution locale et l’exécution dans le cloud.

Avant d’activer la synchronisation, examinez les exigences suivantes :

• Politiques distribuées uniquement via MDM. La solution MDM distribue les politiques aux appareils. Avant d’activer la synchronisation, définissez dans Agent Security un socle d’exigences pour l’exécution locale, en utilisant les exigences prises en charge.

• Hooks d’entreprise. Si un workflow exclusivement local dépend de scripts ou de hooks de plugins, vérifiez quels hooks l’orchestrateur cloud prend en charge avant d’activer l’accès à l’ordinateur local. Testez les événements requis et vérifiez quels événements sont couverts par l’audit.

Examinez les contrôles Work disponibles dans Paramètres de l’espace de travail > Permissions et rôles. Selon la configuration de l’espace de travail et le déploiement, les versions locale et hébergée de Work peuvent apparaître comme deux permissions distinctes. Pour en savoir plus, consultez la FAQ Work pour les administrateurs.

Pour chaque utilisateur ou groupe, activez uniquement les environnements d’exécution approuvés et vérifiez les droits d’accès effectifs après toute modification.

Les permissions de l’espace de travail déterminent qui peut utiliser Work. Les administrateurs peuvent également restreindre les fonctionnalités de bureau prises en charge en définissant des exigences obligatoires dans requirements.toml. Selon le déploiement, ces exigences peuvent être distribuées via la configuration gérée de l’espace de travail, un fichier de configuration au niveau du système ou des outils MDM pris en charge sur macOS.

Les utilisateurs ne peuvent pas déroger aux exigences obligatoires. Les valeurs par défaut gérées définissent des paramètres initiaux que les utilisateurs peuvent parfois modifier. Ni les exigences ni les valeurs par défaut ne remplacent les rôles de l’espace de travail ou les permissions du système d’exploitation.

Les clients locaux qui utilisent le mécanisme de configuration locale existant chargent les exigences gérées en même temps que leur configuration. Une actualisation en arrière-plan peut préparer les exigences cloud en vue d’un chargement ultérieur. Sur macOS, le client lit les modifications MDM au démarrage suivant. Après une modification de politique locale, redémarrez le client local concerné et vérifiez sa configuration.

Ce mécanisme de chargement local ne permet pas de déterminer quand une modification de politique cloud prend effet dans une tâche en cours qui utilise l’accès à l’ordinateur local depuis Work Cloud. Vérifiez les contrôles effectivement appliqués à la tâche avant de vous appuyer sur la modification.

Ce tableau présente des exemples de restrictions. Il ne répertorie pas les fonctionnalités activées par défaut. En l’absence d’exigence pour une fonctionnalité, les paramètres habituels du client, de la plateforme, du déploiement et de l’utilisateur restent en vigueur. Les paramètres d’activation de la fonctionnalité Navigateur, le volet du navigateur intégré et la fonctionnalité native Utilisation de l’ordinateur disposent de contrôles distincts. Vérifiez séparément chaque mode d’accès au navigateur.

Les paramètres et les modes de distribution disponibles dépendent du client, du système d’exploitation, de l’espace de travail et de la configuration du déploiement. Vérifiez les restrictions sur un appareil géré représentatif de votre parc. Pour connaître les paramètres de politique pris en charge et consulter des exemples de configuration et les instructions de mise en place du MDM, voir Configuration gérée.

Accès au réseau local et aux ressources privées

Work Local peut accéder aux informations de l’entreprise via un navigateur, une application native, une application connectée ou un autre outil pris en charge. Les contrôles réseau s’appliquent différemment selon le mode d’accès. L’accès au VPN de l’entreprise ne suffit pas à autoriser une tâche à utiliser une ressource interne.

Les exigences réseau gérées et les politiques de la fonctionnalité Navigateur relatives aux origines font l’objet de vérifications distinctes. Vérifiez les deux sur les versions d’application et les systèmes d’exploitation de votre déploiement avant de compter sur une restriction réseau pour limiter la fonctionnalité Navigateur. Le contrôle des politiques du navigateur ne signifie pas que le trafic du navigateur transite par le proxy réseau des commandes. Les politiques de la fonctionnalité Navigateur ne régissent pas le trafic des applications natives.

Les exigences réseau gérées sous [experimental_network] sont expérimentales et peuvent évoluer. Leur prise en charge sur Windows est limitée. Testez-les avec le client et l’environnement exacts de vos utilisateurs Windows avant de les leur appliquer. Les règles de domaine seules n’activent pas le proxy géré. Le paramètre experimental_network.enabled = true est requis et ne peut pas réactiver le réseau si le bac à sable le désactive.

Vérifiez la connexion, le compte connecté, la destination et l’action nécessaires au workflow. Pour connaître les détails de configuration et les limites propres à chaque plateforme, voir Exigences relatives à l’accès réseau.

Traitement et conservation des données

Avec l’accès à l’ordinateur local depuis Work Cloud, le cloud coordonne le workflow même lorsqu’une étape s’exécute sur l’ordinateur. Examinez les données de conversation et le contexte de la tâche séparément des fichiers locaux utilisés par un outil. Ne présumez pas que l’exécution locale implique un stockage exclusivement sur l’appareil ni que tous les fichiers d’un dossier sont envoyés dans le cloud.

L’accès à l’ordinateur local depuis Work Cloud ne garantit pas une politique de non-conservation des données stricte. La résidence des données et la résidence de l’inférence couvrent uniquement les contenus éligibles ainsi que les charges de travail, les régions et les configurations prises en charge. La gestion des clés d’entreprise (EKM) couvre les contenus stockés pris en charge dans les espaces de travail éligibles. Work ne prend pas en charge la résidence de l’inférence aux Émirats arabes unis. Avant le déploiement, vérifiez les conditions de stockage et de conservation de l’espace de travail, ainsi que le périmètre de l’audit. Si votre organisation exige une politique de non-conservation des données (ZDR), n’activez pas cette fonctionnalité. Si enforce_residency est activé dans au moins une politique cloud, l’option Autoriser l’accès à l’ordinateur local est désactivée pour Work comme pour les dots. Cette mesure de protection ne configure pas la résidence de l’espace de travail et ne désactive pas à elle seule Work Cloud ou les dots.

Appliquez à l’appareil et au workflow concernés les contrôles de votre organisation en matière de sécurité des terminaux, d’accès aux fichiers, de proxy et de prévention des pertes de données. Avant tout traitement, vérifiez si ces contrôles peuvent empêcher que des informations sensibles soient transmises à la tâche. Les journaux d’audit et les exports de conformité facilitent la surveillance et les investigations, mais ne bloquent pas à eux seuls le traitement.

Le stockage et la conservation dépendent de la catégorie d’informations et de leur emplacement de stockage.

Dans les espaces de travail Business, Enterprise et Edu pris en charge, les services OpenAI couverts chiffrent les données professionnelles en transit et au repos. Par défaut, OpenAI n’utilise pas ces données pour entraîner ou améliorer ses modèles. Ces protections ne signifient pas qu’OpenAI régit tous les fichiers des appareils, les applications tierces, les profils de navigateur ou les enregistrements des systèmes sources.

Avant d’appliquer aux enregistrements locaux une durée de conservation prévue pour les conversations hébergées, les fichiers envoyés temporairement ou les journaux de conformité, vérifiez qu’elle s’applique bien à la catégorie de données concernée.

Événements disponibles pour l’audit et la conformité

L’activation de l’accès à l’ordinateur local depuis Work Cloud modifie les événements que reçoit votre collecteur OpenTelemetry (OTel) existant. Votre exécuteur local peut toujours exporter les événements d’exécution pris en charge. Votre collecteur OpenTelemetry existant ne reçoit pas les événements d’orchestration cloud.

Utilisez l’API de conformité pour accéder aux enregistrements cloud pris en charge. Changer le point de terminaison du collecteur ne rétablit pas la réception des événements d’orchestration cloud. Les enregistrements de l’API de conformité ne remplacent pas tous les événements de l’ancien flux OpenTelemetry. Voir Vérifier la couverture d’OpenTelemetry et de l’audit.

Les rapports disponibles dépendent de l’offre de l’espace de travail, de l’interface du produit utilisée, de l’événement, de l’application connectée et de la configuration déployée. Avant de vous appuyer sur un export de l’espace de travail pour répondre à un incident ou mener un examen réglementaire, vérifiez quels événements Work Local il couvre.

Dans les versions prises en charge, la fonctionnalité Navigateur peut émettre des événements OpenTelemetry lorsqu’elle vérifie si une action est autorisée, notamment l’accès à un site, l’envoi d’un fichier ou son téléchargement. Ces événements consignent la décision, son origine et, lorsqu’ils sont disponibles, les détails de la politique appliquée. L’origine de la décision peut être inconnue. Si l’export est configuré, ces événements sont envoyés au point de terminaison OpenTelemetry du client avec les autres données de télémétrie de l’environnement d’exécution local.

Configurez l’export OpenTelemetry séparément des enregistrements de l’API de conformité. Ces événements ne constituent pas un historique exhaustif des actions effectuées dans le navigateur ou les applications natives. Voir Configuration d’OpenTelemetry.

Vérifiez si les systèmes concernés consignent l’identité de la tâche, les prompts et les réponses pris en charge, les appels aux applications connectées, les approbations du navigateur, les actions dans les applications, les opérations sur les fichiers locaux ou les événements des terminaux. Les systèmes sources et les appareils peuvent consigner des informations différentes de celles que vous trouverez dans les enregistrements de l’espace de travail ChatGPT.

OpenAI ne conserve pas d’historique exhaustif distinct des actions effectuées dans Chrome via l’extension. Ne présumez pas que l’API de conformité consigne toutes les opérations sur les fichiers locaux, les captures d’écran, les actions dans le navigateur, les approbations ou les mises à jour de systèmes externes.

Commencez par une tâche approuvée

Testez Work en local sur les appareils gérés qu’utilisent vos équipes. Exécutez une tâche approuvée, par exemple la comparaison de classeurs financiers que vous avez sélectionnés. Vérifiez les droits d’accès à Work de chaque utilisateur et mettez à disposition uniquement les fichiers, les applications, les sessions de navigateur ou les comptes connectés nécessaires à la tâche.

Vérifiez que les actions approuvées aboutissent, que les actions soumises à restriction sont bloquées et que les enregistrements disponibles répondent à vos besoins de surveillance. Demandez à l’utilisateur d’examiner les résultats et de vérifier que les éventuelles modifications apportées aux fichiers ou aux systèmes connectés correspondent à sa demande.