Concepts de chiffrement
Vue d'ensemble du flux
Vous contrôlez une clé principale dans votre cloud qu'OpenAI ne voit jamais.
Votre clé maîtresse sert à chiffrer les clés de chiffrement des données (DEK) utilisées par OpenAI
OpenAI utilise les DEKs pour chiffrer vos données au repos. Une DEK est chiffrée par votre clé maître, générant une eDEK (DEK chiffrée), qui est stockée avec vos données.
Pour lire les données, OpenAI récupère l'eDEK, demande à votre KMS de le déchiffrer en un DEK, puis déchiffre vos données.
Comment fonctionne le chiffrement EKM ?
Pour de plus amples informations, veuillez consulter notre article : Présentation générale de la gestion des clés d'entreprise (EKM) d'OpenAI
OpenAI stocke-t-il mes DEKs ?
Non : nous stockons les DEKs chiffrés (eDEKs), qui sont générés par votre KMS. Pour déchiffrer les données, nous demandons à votre KMS de déchiffrer l'eDEK pour le reconvertir en DEK.
OpenAI met-elle en cache mes DEKs ?
Oui - en mémoire uniquement. Ceci vise à améliorer les performances afin d'éviter de solliciter votre KMS à chaque demande de chiffrement/déchiffrement des données. Les DEKs ne sont jamais enregistrées dans le stockage.
Autorisations cloud
Quelles autorisations OpenAI aura-t-il sur mon KMS ?
Uniquement les autorisations que vous nous accordez via la politique que vous définissez. Nous avons simplement besoin, au minimum, d'opérations de chiffrement/déchiffrement. Veuillez également créer une nouvelle clé dans votre cloud KMS pour OpenAI au lieu de réutiliser des clés existantes à des fins de production.
Quand OpenAI obtient-elle l'autorisation d'accéder à mon KMS ?
Toutes ces étapes doivent avoir été effectuées : 1. vous avez reconnu l'identité d'OpenAI (via une politique d'approbation, une identité de charge de travail, etc. selon le fournisseur de cloud), 2. vous avez créé une politique pour accéder au KMS, et 3. vous avez accordé à l'identité d'OpenAI l'autorisation d'accéder à cette politique. Si vous créez simplement le KMS sans suivre toutes ces étapes, OpenAI n'aura pas accès.
Dois-je stocker ma clé principale dans mon cloud ?
Non, c'est à vous de gérer votre clé maîtresse. Vous pouvez opter pour une solution gérée dans le cloud ou une solution externe, où votre clé est stockée séparément. OpenAI a simplement besoin d'appeler des opérations de chiffrement/déchiffrement sur votre KMS ; la manière dont la clé maître effectue réellement le chiffrement/déchiffrement est un détail d'implémentation qui nous est opaque.
Cycle de vie des clés
Rotation DEK/eDEK (contrôlée par OpenAI)
À quelle fréquence les DEKs/eDEKs sont-ils renouvelés ?
Toutes les 24 heures sur le parcours de chiffrement (demande d'une paire de clés DEK/eDEK)
Toutes les heures pour le chemin de la clé de déchiffrement (DEK → eDEK)
Dois-je intervenir lorsque la DEK change ?
Non : la rotation des DEK/eDEK est effectuée au sein d'OpenAI. Tant que votre clé principale reste valide, toutes les eDEKs chiffrées par votre clé principale peuvent continuer à être déchiffrées en DEK, qui est ensuite utilisée pour déchiffrer vos données.
Rotation et révocation de la clé maître (sous votre contrôle)
À quelle fréquence les rotations et les révocations de clés ont-elles lieu ?
Cela est déterminé par vous, car OpenAI n'a pas accès à votre clé principale.
Quelle est la différence entre la rotation des clés et la révocation de clés ?
La révocation de clé supprime l'accès aux données chiffrées à l'aide de clés plus anciennes. Le renouvellement des clés chiffre les données à l'aide d'une nouvelle clé, tout en conservant l'accès en lecture aux anciennes données.
Que se passe-t-il si je révoque ma clé maîtresse ?
Si une clé est révoquée ou si des autorisations sont supprimées, l'espace de travail finira par ne plus fonctionner une fois que les clés en cache auront expiré. À ce moment-là, OpenAI ne peut plus déchiffrer les données stockées ni chiffrer de nouvelles données. En pratique, les données sont « fragmentées ».
Combien de temps faut-il pour que la révocation prenne effet ?
OpenAI met en cache les DEK en mémoire pour des raisons de performance et de résilience. La révocation prend généralement effet dans un délai d'une heure, une fois que les clés mises en cache expirent et que la revalidation échoue.
La révocation peut-elle être testée sans risque ?
Tester la révocation dans un espace de travail de production n'est pas recommandé, car ceci rendra définitivement les données existantes inaccessibles. Cependant, les clients peuvent (et devraient) tester la révocation dans un environnement de test afin de vérifier le bon fonctionnement et de valider leurs hypothèses de confiance.
Si une clé est révoquée définitivement, l'espace de travail peut-il être récupéré en y associant une nouvelle clé ?
Non. Une fois la clé perdue, les données sont irrécupérables par conception. La seule solution consiste à créer un nouvel espace de travail.
Que devons-nous faire si un espace de travail devient inaccessible en raison de changements de clé ?
La mesure corrective attendue consiste à créer un nouvel espace de travail. La mise à jour du KMS ne permettra pas de récupérer les données existantes.
Quel est le plan de repli si nous décidons de cesser d'utiliser CMEK ?
Actuellement, il n'existe aucun plan de retour arrière. Une fois qu'un espace de travail est créé avec CMEK, toutes les données associées sont chiffrées à l'aide de clés gérées par le client et ne sont pas accessibles sans elles. La seule façon de cesser d'utiliser CMEK est de créer un nouvel espace de travail — les données chiffrées existantes resteront définitivement inaccessibles.
Que se passe-t-il lorsque je fais tourner ma clé maîtresse ?
De nouveaux éléments cryptographiques seront générés pour le chiffrement afin que les nouvelles demandes de chiffrement utilisent la nouvelle clé. Néanmoins, l'identifiant KMS (ARN ou nom de clé) reste le même et les anciennes données peuvent toujours être déchiffrées. De nombreux fournisseurs cloud proposent le renouvellement automatique des clés (AWS, GCP, Azure).
OpenAI rechiffre-t-il les anciennes données lorsque je renouvelle ma clé principale ?
Non. Les nouveaux éléments cryptographiques serviront uniquement à chiffrer les nouvelles données.
Combien de temps faut-il pour qu'un renouvellement de clé ou une révocation de clé prenne effet ?
1 heure. Ceci s'explique par le fait que les DEK/eDEKs sont mises en cache en mémoire et que nous revalidons ces entrées auprès de votre KMS toutes les heures.
Changement de l'identifiant KMS
Le changement de l'identifiant KMS constitue-t-il une révocation de clé ou une rotation de clé ?
Révocation de clé. Une clé ne peut pas déchiffrer des données chiffrées par une autre clé.
OpenAI peut-il m'aider à changer mon identifiant KMS pour un espace de travail ChatGPT ?
Si vous confirmez que l'objectif est de révoquer votre clé, nous pouvons vous aider à le faire pour un espace de travail ChatGPT. Notez que lorsque le KMS ARN est mis à jour, les anciennes données resteront inaccessibles, de sorte qu'après la modification, vous vous retrouverez avec un mélange de données accessibles et inaccessibles.
OpenAI peut-il m'aider à modifier mon identifiant KMS pour un projet API ?
Si vous utilisez l'API, celle-ci permet facilement d'archiver des projets et d'en créer de nouveaux. Veuillez donc plutôt archiver le projet dont les données ne sont de toute façon pas accessibles, enregistrer une nouvelle configuration EKM auprès d'OpenAI, puis créer un nouveau projet API avec la nouvelle clé KMS.
Que faire si je souhaite changer régulièrement mon identifiant KMS moi-même ?
Cela n'est pas recommandé, car vous ne souhaitez probablement pas révoquer régulièrement votre clé. Cependant, vous pouvez toujours le faire si vous utilisez un fournisseur de services cloud qui prend en charge un alias de clé KMS (exemple AWS). Vous pouvez enregistrer cet alias de clé KMS auprès d'OpenAI, puis, chez votre fournisseur cloud, remplacer à tout moment l'identifiant KMS sous-jacent vers lequel pointe l'alias afin d'effectuer une révocation de clé.
Comportement de la bêta par rapport à la disponibilité générale
Existe-t-il des risques connus ou des modifications au niveau du système lors de l'utilisation de la version bêta du chiffrement en production ?
L'environnement bêta est fonctionnellement équivalent à la version GA, et aucune étape de migration n'est prévue. Le principal risque est que certaines fonctionnalités marginales ne prennent pas encore en charge le contenu chiffré en raison de chemins de code incomplets. Ces problèmes sont rares et en cours de résolution. Les données sont entièrement chiffrées et protégées, quels que soient ces problèmes potentiels.
Y aura-t-il des étapes de migration de la bêta à la version GA ?
Non. Les espaces de travail utilisant la version bêta du chiffrement seront automatiquement pris en charge en GA sans aucune action de la part de l'utilisateur.
Détails techniques supplémentaires
Chiffrement en enveloppe & autorisations
Devons-nous accorder à OpenAI les autorisations GenerateDataKey pour EKM ?
Non. OpenAI requiert uniquement les autorisations Chiffrer et Déchiffrer sur votre clé KMS. L'autorisation GenerateDataKey n'est pas nécessaire pour l'intégration EKM.
OpenAI utilise-t-il le chiffrement par enveloppe pour les données des clients ?
Oui. OpenAI utilise un modèle de chiffrement par enveloppe :
Customer KMS : gère les clés de chiffrement de clés (KEKs). OpenAI ne voit jamais ni ne stocke les KEKs.
Infrastructure OpenAI : génère et gère les clés de chiffrement des données (DEK). Chaque DEK est chiffré (encapsulé) avec votre KEK avant le stockage.
Flux de données :
Les données des clients sont chiffrées avec une DEK.
Cette DEK est chiffrée avec votre KEK, ce qui génère une eDEK.
La eDEK est stockée avec les données chiffrées.
Pour déchiffrer les données, OpenAI demande à votre KMS de déchiffrer l'eDEK, puis récupère la DEK et déchiffre le contenu.
Pourquoi OpenAI a-t-elle choisi ce modèle plutôt que de laisser KMS gérer à la fois les KEKs et les DEKs ?
Il existe deux approches courantes du chiffrement d'enveloppe :
KEK et DEK gérées par KMS :
Avantages : mise en œuvre plus simple, pas besoin de maintenir une infrastructure de chiffrement.
Inconvénients : chaque requête de chiffrement/déchiffrement transite par le KMS, ce qui augmente la latence et les coûts et introduit un point de défaillance unique.
KEKs gérées par KMS / DEKs gérées par OpenAI (notre approche) :
Avantages : latence et coût nettement inférieurs, meilleure évolutivité et fiabilité, et maintien du fonctionnement pendant des pannes partielles du KMS (jusqu'au TTL du cache DEK).
Inconvénients : mise en œuvre légèrement plus complexe du côté d'OpenAI.
Cette conception permet à OpenAI d'offrir de solides garanties de sécurité tout en réduisant au minimum les risques opérationnels et les coûts pour les clients.
À quelle fréquence les DEKs sont-elles renouvelées ?
Chaque DEK est renouvelé environ toutes les 60 minutes. Cela fournit une isolation temporelle — même si un DEK était compromis d'une manière ou d'une autre, l'impact serait limité aux données chiffrées au cours de cette fenêtre d'une heure.
Volume de requêtes KMS et observabilité
Nous observons beaucoup moins de requêtes KMS que de messages utilisateur. Ces chiffres doivent-ils correspondre ?
Non, ils ne seront pas corrélés de manière directe.
Comme OpenAI met en cache les DEK en mémoire pour des raisons de performance, les appels à KMS ne sont effectués que lorsqu'un DEK doit être déchiffré, et non à chaque opération de chiffrement ou de déchiffrement. Par conséquent, vous pouvez vous attendre à :
Moins de requêtes KMS que d'interactions utilisateur.
Fluctuations occasionnelles lorsque les DEK mis en cache expirent (environ toutes les heures) ou lorsque des données chiffrées plus anciennes doivent être consultées.
Appels supplémentaires lors de la récupération de données historiques, par exemple lorsqu'un utilisateur poursuit une conversation de longue durée et que d'anciennes DEK doivent être chargées.
Le nombre exact de requêtes KMS dépend de l'état du cache, du comportement des utilisateurs, des modèles d'accès aux données et de la longueur des conversations, et ne sera donc pas directement corrélé au volume de messages.