Concepts de chiffrement
Flux général
Vous contrôlez dans votre nuage une clé principale qu’OpenAI ne voit jamais
Votre clé principale 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é principale, 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?
Pour obtenir des renseignements détaillés, veuillez consulter notre article : 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 afin de retrouver la DEK.
OpenAI met-elle mes DEK en cache?
Oui — uniquement en mémoire. Cela vise à améliorer la performance en évitant de solliciter votre KMS à chaque demande de chiffrement ou de déchiffrement de données. Les DEK ne sont jamais écrites dans le stockage.
Autorisations infonuagiques
Quelles autorisations OpenAI aura-t-elle sur mon KMS?
Uniquement les autorisations que vous nous accordez au moyen de la stratégie que vous définissez. Nous avons seulement 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 servant à des usages de production.
Quand OpenAI obtient-elle les autorisations d’accès à mon KMS?
Toutes les étapes suivantes doivent avoir été effectuées :
Vous avez reconnu l’identité d’OpenAI (au moyen d’une stratégie de confiance, d’une identité de charge de travail, etc., selon le fournisseur infonuagique).
Vous avez créé une stratégie d’accès au KMS.
Vous avez attribué à l’identité d’OpenAI l’autorisation d’accéder à la stratégie.
Si vous créez simplement le KMS sans effectuer toutes ces étapes, OpenAI n’a pas accès.
Dois-je stocker ma clé principale dans mon nuage?
Non — c’est à vous de choisir comment gérer votre clé principale. Vous pouvez utiliser une solution gérée dans le nuage ou une solution externe où votre clé est stockée séparément. OpenAI doit simplement pouvoir appeler les opérations de chiffrement et de déchiffrement sur votre KMS; la façon dont la clé principale effectue réellement ces opérations est un détail de mise en œuvre qui nous est opaque.
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 heures 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é principale demeure valide, toutes les eDEK chiffrées par votre clé principale peuvent continuer d’être déchiffrées en DEK, qui sert ensuite à déchiffrer vos données.
Rotation et révocation de la clé principale (contrôlées par vous)
À quelle fréquence la rotation et la révocation de clé ont-elles lieu?
C’est vous qui le déterminez, puisque OpenAI n’a aucune visibilité sur votre clé principale.
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 avec une nouvelle clé, tout en conservant l’accès en lecture aux données plus anciennes.
Que se passe-t-il si je révoque ma clé principale?
Si une clé est révoquée ou si des autorisations sont retirées, l’espace de travail finira par ne plus fonctionner lorsque les clés mises en cache expireront. À ce moment-là, OpenAI ne pourra plus déchiffrer les données stockées ni chiffrer de nouvelles données. En pratique, les données sont « déchiquetées ».
À quelle vitesse 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 l’heure, lorsque les clés mises en cache expirent et que la revalidation échoue.
La révocation peut-elle être testée de façon sécuritaire?
Tester la révocation dans un espace de travail de production n’est pas recommandé, 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 afin de vérifier le bon comportement et de 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 associant 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és?
La mesure corrective prévue 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 retrait si nous décidons de cesser d’utiliser CMEK?
Actuellement, il n’existe aucun plan de retrait. 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 peuvent pas être consultées 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 demeureront définitivement inaccessibles.
Que se passe-t-il lorsque je fais la rotation de ma clé principale?
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é) reste le même et les anciennes données peuvent toujours être déchiffrées. De nombreux fournisseurs de services 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é principale?
Non. Le nouveau matériel cryptographique servira uniquement à chiffrer les nouvelles données.
Combien de temps faut-il pour qu’une rotation ou une révocation de clé prenne effet?
1 heure. C’est parce que les DEK/eDEK 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 correspond-il à une révocation 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’objectif 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; après le changement, vous aurez donc un mélange de données inaccessibles et accessibles.
OpenAI peut-elle m’aider à changer mon identifiant KMS pour un projet API?
Si vous utilisez l’API, celle-ci facilite l’archivage et la création 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, puis créer un nouveau projet API avec la nouvelle clé KMS.
Que faire si je veux changer régulièrement mon identifiant KMS moi-même?
Ce n’est pas recommandé, car vous ne souhaitez 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, remplacer à tout moment l’identifiant KMS sous-jacent vers lequel pointe l’alias afin d’émettre une révocation de clé.
Comportement bêta et GA
Y a-t-il des risques connus ou des changements 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 à GA, 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 corrigés. Les données sont entièrement chiffrées et protégées, indépendamment de ces problèmes potentiels.
Y aura-t-il des étapes de migration de la version bêta vers GA?
Non. Les espaces de travail utilisant la version bêta du chiffrement seront automatiquement pris en charge en GA, sans aucune action de l’utilisateur.
Détails techniques supplémentaires
Chiffrement par enveloppe et autorisations
Devons-nous accorder à OpenAI les autorisations GenerateDataKey pour EKM?
Non. OpenAI a seulement besoin des 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 par enveloppe pour les données client?
Oui. OpenAI utilise un modèle de chiffrement par enveloppe :
KMS du 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 (enveloppée) avec votre KEK avant d’être stockée.
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, puis déchiffre le contenu.
Pourquoi OpenAI a-t-elle choisi ce modèle plutôt que de laisser KMS gérer à la fois les KEK et les DEK?
Il existe deux approches courantes du chiffrement par enveloppe :
KEK et DEK gérées par KMS :
Avantages : mise en œuvre plus simple, aucune infrastructure de chiffrement à maintenir.
Inconvénients : chaque demande de chiffrement ou de déchiffrement passe par le KMS, ce qui augmente la latence et les coûts, et crée 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 inférieurs, meilleure extensibilité et fiabilité, et fonctionnement continu pendant les pannes partielles du KMS (jusqu’au TTL du cache des 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 DEK sont-elles renouvelées?
Chaque DEK est renouvelée environ toutes les 60 minutes. Cela assure une isolation temporelle : même si une DEK était compromise d’une façon ou d’une autre, l’impact serait limité aux données chiffrées pendant cette fenêtre d’une heure.
Volume des demandes KMS et observabilité
Nous observons beaucoup moins de demandes KMS que de messages d’utilisateurs. Ces nombres devraient-ils correspondre?
Non, ils ne seront pas directement corrélés.
Comme OpenAI met les DEK en cache en mémoire pour des raisons de performance, les appels 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 devez vous attendre à ce qui suit :
Moins de demandes KMS que d’interactions utilisateur.
Des pics occasionnels lorsque les DEK mises en cache expirent (environ chaque heure) 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 schémas d’accès aux données et de la longueur des conversations; il ne sera donc pas directement corrélé au volume de messages.