Concepts de chiffrement
Flux de haut niveau
Vous contrôlez une clé maîtresse dans votre nuage 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 DEK pour chiffrer vos données au repos. Une DEK est chiffrée par votre clé maîtresse, ce qui génère une eDEK (DEK chiffrée), qui est stockée avec vos données
Pour lire les données, OpenAI prend l’eDEK, demande à votre KMS de la déchiffrer en DEK, puis déchiffre vos données
Comment fonctionne le chiffrement EKM?
Veuillez consulter notre article pour des renseignements détaillés : Aperçu d’OpenAI Enterprise Key Management (EKM)
OpenAI stocke-t-elle mes DEK?
Non — nous stockons les DEK chiffrées (eDEK), qui sont générées par votre KMS. Pour déchiffrer les données, nous demandons à votre KMS de déchiffrer l’eDEK pour la reconvertir en DEK.
OpenAI met-elle mes DEK en cache?
Oui — en mémoire seulement. C’est pour des raisons de performance afin d’éviter d’interroger votre KMS à chaque demande de chiffrement/déchiffrement des données. Les DEK ne sont jamais écrites dans le stockage.
Autorisations du nuage
Quelles autorisations OpenAI aura-t-elle sur mon KMS?
Seulement les autorisations que vous nous accordez au moyen de la politique que vous définissez. Nous avons simplement besoin, au minimum, des opérations Encrypt/Decrypt. Veuillez aussi créer une nouvelle clé dans votre KMS infonuagique pour OpenAI au lieu de réutiliser des clés existantes qui servent à la production.
Quand OpenAI obtient-elle les autorisations d’accès à mon KMS?
Toutes ces étapes doivent avoir été effectuées : 1. vous avez reconnu l’identité d’OpenAI (par politique d’approbation, identité de charge de travail, etc. selon le fournisseur infonuagique), 2. vous avez créé une politique pour accéder au KMS, et 3. vous avez attribué à l’identité d’OpenAI l’autorisation d’accéder à la politique. Si vous créez simplement le KMS sans effectuer toutes ces étapes, OpenAI n’y a pas accès.
Dois-je stocker ma clé maîtresse dans mon nuage?
Non — c’est à vous de décider comment gérer votre clé maîtresse. Vous pouvez avoir une solution gérée par le nuage ou une solution externe où votre clé est stockée séparément. OpenAI a seulement besoin d’appeler les opérations de chiffrement/déchiffrement sur votre KMS — la façon dont la clé maîtresse effectue réellement le chiffrement/déchiffrement est un détail d’implémentation opaque pour nous.
Cycle de vie des clés
Rotation des DEK/eDEK (contrôlée par OpenAI)
À quelle fréquence les DEK/eDEK sont-elles renouvelées?
Toutes les 24 heures sur le chemin de chiffrement (demande d’une paire de clés DEK/eDEK)
Toutes les 1 heure pour le chemin de clé de déchiffrement (DEK -> eDEK)
Dois-je faire quelque chose lorsque la DEK change?
Non — la rotation des DEK/eDEK est effectuée au sein d’OpenAI. Tant que votre clé maîtresse demeure valide, toute eDEK chiffrée par votre clé maîtresse peut continuer d’être déchiffrée en DEK, qui sert ensuite à déchiffrer vos données.
Rotation et révocation de la clé maîtresse (contrôlées par vous)
À quelle fréquence la rotation et la révocation des clés ont-elles lieu?
C’est vous qui le déterminez, puisque OpenAI n’a aucune visibilité sur votre clé maîtresse.
Quelle est la différence entre la rotation de clé et la révocation de clé?
La révocation de clé supprime l’accès aux données chiffrées au moyen d’anciennes clés. La rotation de clé chiffre les données à l’aide d’une nouvelle clé, mais maintient 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 cesser de fonctionner une fois les clés mises en cache expirées. À 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 « détruites ».
Dans quel délai la révocation prend-elle effet?
OpenAI met les DEK en cache 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 les clés mises en cache expirées et l’échec de la revalidation survenu.
La révocation peut-elle être testée de façon sûre?
Il est déconseillé de tester la révocation dans un espace de travail de production, car cela rendra définitivement les données existantes inaccessibles. Toutefois, les clients peuvent (et devraient) tester la révocation dans un environnement bac à sable pour vérifier le bon fonctionnement et valider leurs hypothèses de confiance.
Si une clé est révoquée de façon permanente, l’espace de travail peut-il être récupéré en y rattachant une nouvelle clé?
Non. Une fois la clé perdue, les données sont irrécupérables par conception. La seule mesure corrective 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 prévue est de 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?
À l’heure actuelle, il n’existe aucun plan de repli. 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 celles-ci. 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 la rotation de ma clé maîtresse?
Du nouveau matériel cryptographique sera généré pour le chiffrement, de sorte que les nouvelles demandes de chiffrement utiliseront la nouvelle clé. Toutefois, l’identifiant KMS (ARN ou nom de clé) demeure le même et les anciennes données peuvent toujours être déchiffrées. De nombreux fournisseurs infonuagiques offrent la rotation automatique des clés (AWS, GCP, Azure).
OpenAI rechiffre-t-elle les anciennes données lorsque je fais la rotation de ma clé maîtresse?
Non. Le nouveau matériel cryptographique servira uniquement à chiffrer les nouvelles données.
Combien de temps faut-il pour qu’une rotation de clé ou une révocation de clé prenne effet?
1 heure. En effet, les DEK/eDEK sont mises en cache en mémoire et 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é?
Une révocation de clé. Une clé ne peut pas déchiffrer des données chiffrées par une autre clé.
OpenAI peut-elle m’aider à changer mon identifiant KMS pour un espace de travail ChatGPT?
Si vous confirmez que l’intention est de révoquer votre clé, nous pouvons vous aider à le faire pour un espace de travail ChatGPT. Notez que lorsque l’ARN KMS est mis à jour, les anciennes données demeurent inaccessibles; vous vous retrouverez donc avec un mélange de données inaccessibles et accessibles après le changement.
OpenAI peut-elle m’aider à changer mon identifiant KMS pour un projet API?
Si vous utilisez l’API, l’API permet facilement d’archiver et de créer de nouveaux projets; 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 et créer un nouveau projet API avec la nouvelle clé KMS.
Que faire si je veux changer régulièrement moi-même mon identifiant KMS?
Ce n’est pas recommandé, puisque vous ne voulez probablement pas révoquer régulièrement votre clé. Toutefois, vous pouvez quand même le faire si vous utilisez un fournisseur infonuagique 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 infonuagique, vous pouvez remplacer à tout moment l’identifiant KMS sous-jacent pointé par l’alias afin d’émettre une révocation de clé.
Comportement bêta c. disponibilité générale
Y a-t-il des risques connus ou des changements au niveau du système lorsque la version bêta du chiffrement est utilisée en production?
L’environnement bêta est fonctionnellement équivalent à la disponibilité générale, et aucune étape de migration n’est prévue. Le principal risque est que certaines fonctionnalités de cas limites ne prennent pas encore en charge le contenu chiffré en raison de chemins de code incomplets. Ces cas sont rares et sont activement en cours de résolution. Les données sont entièrement chiffrées et protégées malgré ces problèmes potentiels.
Y aura-t-il des étapes de migration de la bêta à la disponibilité générale?
Non. Les espaces de travail utilisant la version bêta du chiffrement seront automatiquement pris en charge dans la disponibilité générale sans aucune action de l’utilisateur.
Détails techniques supplémentaires
Chiffrement en enveloppe et autorisations
Devons-nous accorder à OpenAI les autorisations GenerateDataKey pour EKM?
Non. OpenAI n’exige que les autorisations Encrypt et Decrypt sur votre clé KMS. L’autorisation GenerateDataKey n’est pas nécessaire pour l’intégration EKM.
OpenAI utilise-t-elle le chiffrement en enveloppe pour les données client?
Oui. OpenAI utilise un modèle de chiffrement en enveloppe :
KMS client : gère les clés de chiffrement de clés (KEK). OpenAI ne voit ni ne stocke jamais les KEK.
Infrastructure OpenAI : génère et gère les clés de chiffrement des données (DEK). Chaque DEK est chiffrée (encapsulée) avec votre KEK avant le stockage.
Flux de données :
Les données client sont chiffrées avec une DEK.
Cette DEK est chiffrée avec votre KEK, ce qui produit une eDEK.
L’eDEK est stockée avec les données chiffrées.
Pour déchiffrer des données, OpenAI demande à votre KMS de déchiffrer l’eDEK, récupère la DEK et déchiffre le contenu.
Pourquoi OpenAI a-t-elle choisi ce modèle au lieu de laisser le KMS gérer à la fois les KEK et les DEK?
Il existe deux approches courantes du chiffrement en enveloppe :
KEK et DEK gérées par KMS :
Avantages : implémentation plus simple, pas besoin de maintenir une infrastructure de chiffrement.
Inconvénients : chaque demande de chiffrement/déchiffrement sollicite le KMS, ce qui augmente la latence et les coûts, et introduit un point de défaillance unique.
KEK gérées par KMS / DEK gérées par OpenAI (notre approche) :
Avantages : latence et coûts nettement réduits, meilleure évolutivité et fiabilité, et continuité des opérations pendant des pannes partielles du KMS (jusqu’au TTL du cache DEK).
Inconvénients : implémentation légèrement plus complexe du côté d’OpenAI.
Cette conception permet à OpenAI d’offrir de solides garanties de sécurité tout en minimisant les risques opérationnels et les coûts pour les clients.
À quelle fréquence les DEK sont-elles renouvelées?
Chaque DEK est renouvelée environ toutes les 60 minutes. Cela procure un isolement temporel — même si une DEK était d’une façon ou d’une autre compromise, l’impact serait limité aux données chiffrées pendant cette fenêtre d’une heure.
Volume des demandes KMS et observabilité
Nous voyons beaucoup moins de demandes KMS que le nombre de messages des utilisateurs. Ces chiffres devraient-ils correspondre?
Non, ils ne seront pas directement corrélés.
Parce qu’OpenAI met les DEK en cache en mémoire pour des raisons de performance, les appels au KMS ne sont effectués que lorsqu’une DEK doit être déchiffrée — et non à chaque opération de chiffrement ou de déchiffrement. Par conséquent, vous devriez vous attendre à ce qui suit :
Moins de demandes KMS que d’interactions utilisateur.
Des pics occasionnels lorsque les DEK mises en cache expirent (environ toutes les heures) ou lorsque des données chiffrées plus anciennes doivent être consultées.
Des 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 demandes 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; il ne sera donc pas directement corrélé au volume de messages.