Conceptos de cifrado
Flujo general
Controlas una clave maestra en tu nube que OpenAI nunca ve
Tu clave maestra se usa para cifrar las claves de cifrado de datos (DEK) que utiliza OpenAI
OpenAI usa las DEK para cifrar tus datos en reposo. Una DEK se cifra con tu clave maestra, lo que genera una eDEK (DEK cifrada), que se almacena junto con tus datos
Para leer los datos, OpenAI toma la eDEK, solicita a tu KMS que la descifre para convertirla en una DEK y, a continuación, descifra tus datos
¿Cómo funciona el cifrado EKM?
Consulta nuestro artículo para obtener información detallada: Descripción general de OpenAI Enterprise Key Management (EKM)
¿Almacena OpenAI mis DEK?
No: almacenamos las DEK cifradas (eDEK), que genera tu KMS. Para descifrar los datos, solicitamos a tu KMS que descifre la eDEK y la vuelva a convertir en la DEK.
¿Almacena OpenAI mis DEK en caché?
Sí, solo en memoria. Esto se hace por rendimiento, para evitar acceder a tu KMS en cada solicitud de cifrado o descifrado de datos. Las DEK nunca se escriben en almacenamiento.
Permisos en la nube
¿Qué permisos tendrá OpenAI en mi KMS?
Solo los permisos que nos concedas mediante la política que configures. Solo necesitamos, como mínimo, las operaciones Encrypt/Decrypt. Crea también una clave nueva en tu KMS en la nube para OpenAI, en lugar de reutilizar claves existentes que se usen en producción.
¿Cuándo obtiene OpenAI permisos para acceder a mi KMS?
Deben haberse realizado todos estos pasos:
Has reconocido la identidad de OpenAI (mediante una política de confianza, identidad de carga de trabajo, etc., según el proveedor de nube).
Has creado una política para acceder al KMS.
Has asignado a la identidad de OpenAI el permiso para acceder a la política.
Si solo creas el KMS sin realizar todos estos pasos, OpenAI no tendrá acceso.
¿Tengo que almacenar mi clave maestra en mi nube?
No: tú decides cómo gestionar tu clave maestra. Puedes tener una solución gestionada en la nube o una externa en la que tu clave se almacene por separado. OpenAI solo necesita invocar operaciones de cifrado y descifrado en tu KMS; la forma en que la clave maestra realiza realmente el cifrado o descifrado es un detalle de implementación que no vemos.
Ciclo de vida de las claves
Rotación de DEK/eDEK (controlada por OpenAI)
¿Con qué frecuencia se rotan las DEK/eDEK?
Cada 24 horas en la ruta de cifrado (al solicitar un par de claves DEK/eDEK)
Cada 1 hora en 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 tu clave maestra siga siendo válida, cualquier eDEK cifrada con tu clave maestra podrá seguir descifrándose en la DEK, que luego se usa para descifrar tus datos.
Rotación y revocación de la clave maestra (controladas por ti)
¿Con qué frecuencia se producen la rotación y la revocación de claves?
Esto lo determinas tú, ya que OpenAI no tiene visibilidad de tu clave maestra.
¿Cuál es la diferencia entre la rotación de claves y la revocación de claves?
La revocación de claves elimina el acceso a los datos cifrados con claves antiguas. La rotación de claves 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 eliminan permisos, el área de trabajo acabará dejando de funcionar cuando caduquen las claves en caché. En ese momento, OpenAI ya no podrá descifrar datos almacenados ni cifrar datos nuevos. En la práctica, los datos quedan «destruidos».
¿Con qué rapidez surte efecto la revocación?
OpenAI almacena las DEK en caché en memoria por rendimiento y resiliencia. La revocación suele surtir efecto en el plazo de una hora, cuando caducan las claves en caché y falla la revalidación.
¿Se puede probar la revocación de forma segura?
Probar la revocación en un área de trabajo de producción no se recomienda, 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 aislado para comprobar que el comportamiento es correcto y validar sus supuestos de confianza.
Si una clave se revoca permanentemente, ¿se puede recuperar el área de trabajo asociando una clave nueva?
No. Una vez que la clave se pierde, los datos son irrecuperables por diseño. La única solución es crear una nueva área de trabajo.
¿Qué debemos hacer si un área de trabajo queda inaccesible debido a cambios en la clave?
La solución prevista es crear una nueva área de trabajo. 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 ningún 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 una nueva área de trabajo: los datos cifrados existentes permanecerán inaccesibles de forma permanente.
¿Qué ocurre cuando roto mi clave maestra?
Se generará nuevo material criptográfico para el cifrado, por lo que las nuevas solicitudes de cifrado usarán la clave nueva. Sin embargo, el identificador de KMS (ARN o nombre de clave) sigue siendo el mismo y los datos antiguos aún pueden descifrarse. Muchos proveedores de nube ofrecen rotación automática de claves (AWS, GCP, Azure).
¿Vuelve OpenAI a cifrar los datos antiguos cuando roto mi clave maestra?
No. El nuevo material criptográfico solo se usará 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 tu KMS cada hora.
Cambiar el 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 con otra clave.
¿Puede OpenAI ayudarme a cambiar mi identificador de KMS para un área de trabajo de ChatGPT?
Si confirmas que la intención es revocar tu clave, podemos ayudarte a hacerlo para un área de trabajo de ChatGPT. Ten en cuenta que, cuando se actualice el ARN de KMS, los datos antiguos seguirán siendo inaccesibles, por lo que tras el cambio tendrás una mezcla de datos inaccesibles y accesibles.
¿Puede OpenAI ayudarme a cambiar mi identificador de KMS para un proyecto de API?
Si usas la API, esta facilita archivar y crear proyectos nuevos. Por tanto, archiva el proyecto cuyos datos no sean accesibles de todos modos, registra una nueva configuración de EKM con OpenAI y crea un nuevo proyecto de API con la nueva clave de KMS.
¿Qué ocurre si quiero cambiar periódicamente mi identificador de KMS por mi cuenta?
No se recomienda, ya que probablemente no quieras revocar tu clave periódicamente. No obstante, puedes hacerlo si utilizas un proveedor de nube que admita un alias de clave de KMS (ejemplo de AWS). Puedes registrar ese alias de clave de KMS con OpenAI y, después, en tu proveedor de nube, cambiar en cualquier momento el identificador de KMS subyacente al que apunta el alias para emitir una revocación de clave.
Comportamiento en 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 de casos límite aún no admitan contenido cifrado debido a rutas de código incompletas. Son casos poco frecuentes y se están resolviendo activamente. Los datos están completamente cifrados y protegidos con independencia de estos posibles problemas.
¿Habrá pasos de migración de beta a GA?
No. Las áreas de trabajo que usen la beta de cifrado serán compatibles automáticamente en GA sin ninguna acción por parte del usuario.
Detalles técnicos adicionales
Cifrado de sobre y permisos
¿Tenemos que conceder permisos GenerateDataKey a OpenAI para EKM?
No. OpenAI solo requiere permisos Encrypt y Decrypt sobre tu clave de KMS. El permiso GenerateDataKey no es necesario para la integración de EKM.
¿Usa OpenAI cifrado de sobre para los datos de clientes?
Sí. OpenAI usa 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 las claves de cifrado de datos (DEK). Cada DEK se cifra (se envuelve) con tu KEK antes de almacenarse.
Flujo de datos:
Los datos del cliente se cifran con una DEK.
Esa DEK se cifra con tu KEK, lo que produce una eDEK.
La eDEK se almacena junto con los datos cifrados.
Para descifrar datos, OpenAI solicita a tu KMS que descifre la eDEK, recupera la DEK y descifra el contenido.
¿Por qué eligió OpenAI este modelo en lugar de dejar que KMS gestione tanto las KEK como las DEK?
Existen dos enfoques habituales para el cifrado de sobre:
KEK y DEK gestionadas por KMS:
Ventajas: implementación más sencilla, sin necesidad de mantener infraestructura de cifrado.
Desventajas: cada solicitud de cifrado o descifrado pasa por el KMS, lo que aumenta la latencia y el coste, e introduce 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 continuado durante interrupciones parciales de KMS (hasta el TTL de la caché de DEK).
Desventajas: implementación ligeramente más compleja por parte de OpenAI.
Este diseño permite a OpenAI ofrecer sólidas garantías de seguridad a la vez 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 una DEK se viera comprometida de algún modo, el impacto se limitaría a los datos cifrados durante esa ventana de una hora.
Volumen de solicitudes de KMS y observabilidad
Vemos muchas menos solicitudes de KMS que mensajes de usuarios. ¿Deberían coincidir estas cifras?
No, no se correlacionarán directamente.
Como OpenAI almacena las DEK en caché en memoria por motivos de rendimiento, las llamadas a KMS solo se realizan cuando es necesario descifrar una DEK, no en cada operación de cifrado o descifrado. Por tanto, debes esperar:
Menos solicitudes de KMS que interacciones de usuarios.
Picos ocasionales cuando caducan las DEK en caché (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 larga y deben cargarse 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, por lo que no se correlacionará directamente con el volumen de mensajes.