Conceptos de cifrado
Flujo de alto nivel
Usted controla una clave maestra en su nube que OpenAI nunca ve
Su clave maestra se utiliza para cifrar claves de cifrado de datos (DEK) utilizadas por OpenAI
OpenAI utiliza las DEK para cifrar sus datos en reposo. Una DEK se cifra con su clave maestra, generando una eDEK (DEK cifrada), que se almacena junto con sus datos
Para leer los datos, OpenAI toma la eDEK, solicita a su KMS que la descifre en una DEK y, a continuación, descifra sus datos
¿Cómo funciona el cifrado EKM?
Consulte nuestro artículo para obtener información detallada: Descripción general de OpenAI Enterprise Key Management (EKM)
¿OpenAI almacena mis DEK?
No; almacenamos las DEK cifradas (eDEK), que genera su KMS. Para descifrar los datos, pedimos a su KMS que descifre la eDEK de nuevo en la DEK.
¿OpenAI almacena en caché mis DEK?
Sí, solo en memoria. Esto es por rendimiento, para evitar acudir a su KMS en cada solicitud de cifrado/descifrado de datos. Las DEK nunca se escriben en almacenamiento.
Permisos de la nube
¿Qué permisos tendrá OpenAI sobre mi KMS?
Solo los permisos que nos conceda mediante la política que configure. Solo necesitamos, como mínimo, operaciones de cifrado/descifrado. Cree también una clave nueva en su KMS en la nube para OpenAI en lugar de reutilizar claves existentes que tengan fines de producción.
¿Cuándo obtiene OpenAI permisos para acceder a mi KMS?
Se deben haber realizado todos estos pasos: 1. ha reconocido la identidad de OpenAI (mediante política de confianza, identidad de carga de trabajo, etc., según el proveedor de nube), 2. ha creado una política para acceder al KMS y 3. ha asignado a la identidad de OpenAI el permiso para acceder a la política. Si solo crea el KMS sin realizar todos estos pasos, OpenAI no tiene acceso.
¿Tengo que almacenar mi clave maestra en mi nube?
No; depende de usted cómo gestionar su clave maestra. Puede contar con una solución gestionada por la nube o con una externa en la que la clave se almacene por separado. OpenAI solo necesita llamar a operaciones de cifrado/descifrado en su KMS; la forma en que la clave maestra realiza realmente el cifrado/descifrado es un detalle de implementación opaco para nosotros.
Ciclo de vida de la clave
Rotación de DEK/eDEK (controlada por OpenAI)
¿Con qué frecuencia se rotan las DEK/eDEK?
Cada 24 horas en la ruta de cifrado (solicitud de un par de claves DEK/eDEK)
Cada 1 hora para la ruta de clave de descifrado (DEK -> eDEK)
¿Tengo que hacer algo cuando cambia la DEK?
No; la rotación de DEK/eDEK se realiza dentro de OpenAI. Mientras su clave maestra siga siendo válida, cualquier eDEK cifrada con su clave maestra puede seguir descifrándose en la DEK, que luego se utiliza para descifrar sus datos.
Rotación y revocación de clave maestra (controladas por usted)
¿Con qué frecuencia se producen la rotación y la revocación de claves?
Esto lo determina usted, ya que OpenAI no tiene visibilidad de su clave maestra.
¿Cuál es la diferencia entre rotación de clave y revocación de clave?
La revocación de clave elimina el acceso a los datos cifrados con claves antiguas. La rotación de clave cifra los datos con una clave nueva, pero mantiene el acceso de lectura a los datos antiguos.
¿Qué ocurre si revoco mi clave maestra?
Si se revoca una clave o se retiran permisos, el Área de trabajo acabará dejando de funcionar cuando caduquen las claves almacenadas en caché. En ese momento, OpenAI ya no podrá descifrar los datos almacenados ni cifrar datos nuevos. En la práctica, los datos quedan «destruidos».
¿Con qué rapidez entra en vigor la revocación?
OpenAI almacena DEK en caché en memoria por rendimiento y resiliencia. La revocación suele entrar en vigor en el plazo de una hora, una vez que caducan las claves en caché y falla la revalidación.
¿Puede probarse la revocación de forma segura?
No se recomienda probar la revocación en un Área de trabajo de producción porque hará que los datos existentes queden inaccesibles de forma permanente. No obstante, los clientes pueden (y deben) probar la revocación en un entorno sandbox para verificar el comportamiento correcto y validar sus supuestos de confianza.
Si una clave se revoca de forma permanente, ¿puede recuperarse el Área de trabajo asociando una clave nueva?
No. Una vez que se pierde la clave, los datos son irrecuperables por diseño. La única solución es poner en marcha un Área de trabajo nuevo.
¿Qué debemos hacer si un Área de trabajo queda inaccesible debido a cambios en la clave?
La solución prevista es crear un Área de trabajo nuevo. Actualizar el KMS no recuperará los datos existentes.
¿Cuál es el plan de reversión si decidimos dejar de usar CMEK?
Actualmente, no hay un plan de reversión. Una vez que se crea un Área de trabajo con CMEK, todos los datos asociados se cifran con claves gestionadas por el cliente y no se puede acceder a ellos sin esas claves. La única forma de dejar de usar CMEK es crear un Área de trabajo nuevo; los datos cifrados existentes seguirán siendo permanentemente inaccesibles.
¿Qué ocurre cuando roto mi clave maestra?
Se generará nuevo material criptográfico para el cifrado, de modo que las nuevas solicitudes de cifrado usarán la clave nueva. Sin embargo, el identificador del KMS (ARN o nombre de clave) sigue siendo el mismo y los datos antiguos siguen pudiendo descifrarse. Muchos proveedores de nube ofrecen rotación automática de claves (AWS, GCP, Azure).
¿OpenAI vuelve a cifrar los datos antiguos cuando roto mi clave maestra?
No. El nuevo material criptográfico solo se utilizará para cifrar datos nuevos.
¿Cuánto tarda en surtir efecto una rotación o una revocación de clave?
1 hora. Esto se debe a que las DEK/eDEK se almacenan en caché en memoria y revalidamos estas entradas con su KMS cada hora.
Cambio del identificador de KMS
¿Cambiar el identificador de KMS es una revocación de clave o una rotación de clave?
Revocación de clave. Una clave no puede descifrar datos cifrados por otra clave.
¿Puede OpenAI ayudarme a cambiar mi identificador de KMS para un Área de trabajo de ChatGPT?
Si confirma que la intención es revocar su clave, podemos ayudarle a hacerlo para un Área de trabajo de ChatGPT. Tenga en cuenta que, cuando se actualiza el ARN del KMS, los datos antiguos seguirán siendo inaccesibles, por lo que acabará con una combinación de datos inaccesibles y accesibles después del cambio.
¿Puede OpenAI ayudarme a cambiar mi identificador de KMS para un proyecto de API?
Si utiliza la API, la API permite archivar y crear proyectos nuevos fácilmente, así que archive el proyecto cuyos datos ya no sean accesibles, registre una nueva configuración de EKM con OpenAI y cree un proyecto de API nuevo con la nueva clave de KMS.
¿Qué ocurre si quiero cambiar regularmente mi identificador de KMS por mi cuenta?
No se recomienda, ya que probablemente no quiera revocar su clave con regularidad. No obstante, aún puede hacerlo si utiliza un proveedor de nube que admita un alias de clave de KMS (ejemplo de AWS). Puede registrar ese alias de clave de KMS con OpenAI y, a continuación, en su proveedor de nube puede intercambiar en cualquier momento el identificador de KMS subyacente al que apunta el alias para emitir una revocación de clave.
Comportamiento beta frente a GA
¿Existe algún riesgo conocido o cambio a nivel de sistema al usar la beta de cifrado en producción?
El entorno beta es funcionalmente equivalente a GA y no se prevén pasos de migración. El riesgo principal es que algunas funciones en casos límite aún no admitan contenido cifrado debido a rutas de código incompletas. Estos casos son poco frecuentes y se están resolviendo activamente. Los datos están totalmente cifrados y protegidos independientemente de estos posibles problemas.
¿Habrá pasos de migración de beta a GA?
No. Los Áreas de trabajo que utilicen la beta de cifrado pasarán a ser compatibles con GA automáticamente sin ninguna acción por parte del usuario.
Detalles técnicos adicionales
Cifrado de sobre y permisos
¿Necesitamos conceder a OpenAI permisos de GenerateDataKey para EKM?
No. OpenAI solo requiere permisos de Encrypt y Decrypt sobre su clave de KMS. El permiso GenerateDataKey no es necesario para la integración de EKM.
¿OpenAI utiliza cifrado de sobre para los datos de clientes?
Sí. OpenAI utiliza un modelo de cifrado de sobre:
KMS del cliente: gestiona las claves de cifrado de claves (KEK). OpenAI nunca ve ni almacena las KEK.
Infraestructura de OpenAI: genera y gestiona claves de cifrado de datos (DEK). Cada DEK se cifra (se encapsula) con su KEK antes del almacenamiento.
Flujo de datos:
Los datos del cliente se cifran con una DEK.
Esa DEK se cifra con su KEK, lo que produce una eDEK.
La eDEK se almacena junto con los datos cifrados.
Para descifrar los datos, OpenAI solicita a su KMS que descifre la eDEK, recupera la DEK y descifra el contenido.
¿Por qué eligió OpenAI este modelo en lugar de dejar que el KMS gestionara tanto las KEK como las DEK?
Hay dos enfoques habituales de cifrado de sobre:
KEK y DEK gestionadas por KMS:
Ventajas: implementación más sencilla, sin necesidad de mantener una infraestructura de cifrado.
Inconvenientes: cada solicitud de cifrado/descifrado llega al KMS, lo que aumenta la latencia, el coste y añade un punto único de fallo.
KEK gestionadas por KMS / DEK gestionadas por OpenAI (nuestro enfoque):
Ventajas: latencia y coste significativamente menores, mejor escalabilidad y fiabilidad, y funcionamiento continuo durante interrupciones parciales del KMS (hasta el TTL de la caché de DEK).
Inconvenientes: implementación ligeramente más compleja por parte de OpenAI.
Este diseño permite a OpenAI ofrecer sólidas garantías de seguridad al tiempo que minimiza el riesgo operativo y el coste para los clientes.
¿Con qué frecuencia se rotan las DEK?
Cada DEK se rota aproximadamente cada 60 minutos. Esto proporciona aislamiento temporal: incluso si de algún modo una DEK se viera comprometida, el impacto se limitaría a los datos cifrados dentro de esa ventana de una hora.
Volumen de solicitudes de KMS y observabilidad
Vemos muchas menos solicitudes de KMS que el número de mensajes de usuario. ¿Deberían coincidir estas cifras?
No, no se correlacionarán directamente.
Dado que OpenAI almacena DEK en caché en memoria por motivos de rendimiento, las llamadas al KMS solo se realizan cuando es necesario descifrar una DEK, no en cada operación de cifrado o descifrado. Como resultado, debe esperar:
Menos solicitudes de KMS que interacciones de usuario.
Picos ocasionales cuando las DEK almacenadas en caché caducan (aproximadamente cada hora) o cuando es necesario acceder a datos cifrados antiguos.
Llamadas adicionales al recuperar datos históricos, por ejemplo, cuando un usuario continúa una conversación de larga duración y es necesario cargar DEK antiguas.
El número exacto de solicitudes de KMS depende del estado de la caché, del comportamiento del usuario, de los patrones de acceso a los datos y de la longitud de la conversación, y por tanto no se correlacionará directamente con el volumen de mensajes.