Este contenido se actualizó por última vez en mayo de 2024 y representa el statu quo en el momento de su redacción. Es posible que en el futuro cambien las políticas y los sistemas de seguridad de Google, ya que mejoramos la protección de nuestros clientes de forma continua.
En Google, nuestra estrategia de seguridad integral incluye la encriptación en reposo, que ayuda a proteger de atacantes el datos del cliente. Encriptamos todo el contenido en reposo de clientes de Google mediante uno o más mecanismos de encriptación, sin que debas realizar ninguna acción. En este documento, se describe nuestro enfoque respecto a la encriptación en reposo predeterminada de la infraestructura de Google y Google Cloud, y cómo la usamos para proteger más el contenido de clientes.
Este documento está dirigido a arquitectos y equipos de seguridad que usan o piensan usar Google. En este documento, se supone que tienes conocimientos básicos sobre la encriptación y las primitivas criptográficas. Para obtener más información sobre la criptografía, consulta Introducción a la criptografía moderna.
La encriptación en reposo es una que se usa para proteger los datos almacenados en un disco (incluidas las unidades de estado sólido) o en medios de copia de seguridad. Todos los datos que Google almacena se encriptan en la capa de almacenamiento mediante el algoritmo del estándar de encriptación avanzada (AES), AES-256. Usamos Tink, una biblioteca criptográfica común, que incluye el módulo con validación del estándar FIPS 140-2 (llamado BoringCrypto) para implementar la encriptación de manera coherente en Google Cloud.
Somos propietarios y administramos las claves que se usan en la encriptación en reposo predeterminada. Si usas Google Cloud, Cloud Key Management Service te permite crear tus propias claves de encriptación que puedes usar para agregar encriptación de sobre a tus datos. Con Cloud KMS, puedes crear, rotar, seguir y borrar claves. Para obtener más información, consulta Análisis detallado de Cloud Key Management Service.
Cómo la encriptación en reposo ayuda a proteger los datos
La encriptación en reposo es una parte de una estrategia de seguridad más amplia. La encriptación tiene los siguientes beneficios:
- Ayuda a garantizar que, si los datos caen en manos de atacantes, estos no puedan leerlos sin tener acceso también a las claves de encriptación. Incluso si los atacantes obtienen los dispositivos de almacenamiento que contienen datos de clientes, no podrán leerlos ni desencriptarlos.
- Ayuda a reducir la superficie de ataque mediante la reducción de las capas inferiores del hardware y de la pila de software.
- Actúa como un cuello de botella porque las claves de encriptación administradas de forma central crean un lugar único en el que se aplica el acceso a los datos y se puede auditar.
- Ayuda a reducir la superficie de ataque porque, en lugar de tener que proteger todos los datos, las empresas pueden enfocar sus estrategias de protección en las claves de encriptación.
- Brinda un mecanismo de privacidad importante para nuestros clientes. Cuando los datos se encriptan en reposo, se limita el acceso de ingenieros y sistemas a los datos.
¿Qué son los datos de clientes?
Según se define en las Condiciones del Servicio de Google Cloud, los datos del cliente son los que clientes o usuarios finales proporcionan a Google a través de los servicios que se indican en sus.
El contenido de clientes corresponde a los datos que generas o nos proporcionas, como los datos almacenados en buckets de Cloud Storage, instantáneas de disco y volúmenes de Persistent Disk que usa Compute Engine. Este documento se centra en la encriptación en reposo predeterminada para este tipo de datos de clientes.
Los metadatos de clientes son datos sobre el contenido de tus clientes y, además, incluyen números de proyectos, marcas de tiempo, direcciones IP, tamaños de bytes de un objeto en Cloud Storage o el tipo de máquina en Compute Engine generados automáticamente. Los metadatos se protegen en un nivel razonable que permita mantener las operaciones y el rendimiento. Este documento no se centra en las protecciones de los metadatos.
En conjunto, el contenido y los metadatos de los clientes conforman los datos de los clientes.
Encriptación predeterminada de datos en reposo
Google encripta todo el contenido de clientes almacenado en reposo mediante uno o más mecanismos de encriptación, sin que debas realizar ninguna acción. En las siguientes secciones, se describen los mecanismos que usamos para encriptar el contenido de clientes.
Capas de encriptación
Google usa varias capas de encriptación para proteger los datos. Esto agrega una protección de datos redundante y nos permite seleccionar el enfoque óptimo según los requisitos de las aplicaciones.
En el siguiente diagrama, se muestran las distintas capas de encriptación que, en general, se usan para proteger los datos de usuarios en los centros de datos de producción de Google. Se aplica la encriptación de sistemas de archivos distribuidos o la encriptación de almacenamiento de archivos y bases de datos a todos los datos de usuarios. Además, la encriptación de dispositivos de almacenamiento se aplica a todos los datos en los centros de datos de producción de Google.
Encriptación en la capa de infraestructura y hardware
Todos los sistemas de almacenamiento de Google usan una arquitectura de encriptación similar, aunque los detalles de la implementación difieren de un sistema a otro. Los datos se dividen en fragmentos de subarchivos para almacenamiento, y cada uno puede tener varios gigabytes de tamaño. Cada fragmento se encripta en el nivel de almacenamiento con una clave de encriptación de datos (DEK) individual: dos fragmentos no tendrán la misma DEK, incluso si pertenecen al mismo cliente o están almacenados en el misma máquina. (Un fragmento de datos en Datastore, App Engine y Pub/Sub puede contener los datos de varios clientes).
Si un fragmento de datos se actualiza, se encripta con una clave nueva en lugar de volver a usar la clave existente. Esta partición de datos, cada una con una clave diferente, limita el riesgo de que una posible encriptación de claves de datos se vea comprometida.
Google encripta los datos antes de escribirlos en un sistema de almacenamiento de bases de datos o un disco de hardware. La encriptación es inherente a todos nuestros sistemas de almacenamiento; no es un proceso adicional que se realice luego.
Cada fragmento de datos tiene un identificador único. Las listas de control de acceso (LCA) ayudan a garantizar que cada fragmento solo pueda desencriptarse en los servicios de Google que operan con funciones autorizadas, a las que se les otorga acceso solo en ese momento. Esta limitación de acceso ayuda a evitar el acceso a los datos sin autorización, lo que fortalece la seguridad y la privacidad de los datos.
Cada fragmento se distribuye entre nuestros sistemas de almacenamiento y se repite en su forma encriptada en copias de seguridad y de recuperación ante desastres. Un atacante que quiere acceder a los datos de clientes tendría que conocer y poder acceder a dos elementos: todos los fragmentos de almacenamiento que corresponden a los datos que desean y todas las claves de encriptación que corresponden a los fragmentos.
En el siguiente diagrama, se muestra cómo se suben los datos a nuestra infraestructura y, luego, se los divide en fragmentos encriptados para su almacenamiento.
Usamos el algoritmo AES para encriptar los datos en reposo. Todos los datos en el nivel de almacenamiento se encriptan mediante DEK, que usan AES-256 de forma predeterminada, excepto una pequeña cantidad de discos persistentes que se crearon antes de 2015 que usan AES-128. El AES se usa mucho, ya que el Instituto Nacional de Normas y Tecnología (NIST) recomienda usar AES-256 y AES-128 para el almacenamiento a largo plazo. A menudo, AES se incluye como parte de los requisitos de cumplimiento de clientes.
Encriptación en la capa de dispositivos de almacenamiento
Además de la encriptación a nivel de sistema de almacenamiento, los datos también se encriptan a nivel de dispositivo de almacenamiento con AES-256 para unidades de disco duro (HDD) y unidades de estado sólido (SSD), mediante una clave de nivel de dispositivo independiente (que es diferente de la clave que se usa para encriptar los datos a nivel de almacenamiento). Una pequeña cantidad de discos duros heredados usa AES-128. Los SSD que usa Google implementan AES-256 exclusivamente para los datos de usuarios.
Encriptación de copias de seguridad
Nuestro sistema de copia de seguridad garantiza que los datos sigan encriptados durante la creación de copias de seguridad. Este enfoque evita la exposición innecesaria de los datos como texto simple.
Además, el sistema de copias de seguridad encripta la mayoría de los archivos de copia de seguridad de manera independiente, con su propia DEK. La DEK deriva de una clave que se almacena en el almacén de claves y de una semilla generada de forma aleatoria para cada archivo cuando se crean las copias de seguridad. Se usa otra DEK para todos los metadatos de las copias de seguridad, que también se almacena en el almacén de claves.
Cumplimiento del estándar FIPS para los datos en reposo
Google usa un módulo de encriptación que cuenta con la validación del estándar FIPS 140-2 (certificado 4407) en nuestro entorno de producción.
Administración de claves
Debido a la gran cantidad de claves que posee Google, y a la necesidad de bajar la latencia y aumentar la disponibilidad, las DEK se almacenan cerca de los datos que encriptan. Las DEK se encriptan (unidas) con una clave de encriptación de claves (KEK) mediante una técnica conocida como encriptación de sobre. Estas KEK no son específicas de los clientes. En su lugar, existen una o más KEK para cada servicio.
Estas KEK se almacenan de manera centralizada en el almacén de claves, un repositorio creado específicamente para almacenar claves. Tener menos KEK que DEK y usar un Keystore central facilita la administración del almacenamiento y la encriptación de datos a nuestra escala, y nos permite realizar un seguimiento del acceso a los datos y controlarlo desde un punto central.
En Google Cloud, cada cliente puede tener recursos compartidos y no compartidos. Un ejemplo de un recurso compartido es una imagen base compartida en Compute Engine. Para los recursos compartidos, varios clientes hacen referencia a una sola copia, que está encriptada por una sola DEK. Los recursos no compartidos se dividen en fragmentos y se encriptan con claves independientes de las que se usan para otros clientes. Estas claves son independientes de las que protegen otras partes de los mismos datos pertenecientes al mismo cliente. Hay excepciones (para por ejemplo, Datastore, App Engine o Pub/Sub) en la que los datos de más de un cliente se pueden encriptar con la misma DEK.
Genera DEK
El sistema de almacenamiento genera DEK con la biblioteca criptográfica común de Google. En general, las DEK se envían al almacén de claves para unirlas con las KEK del sistema de almacenamiento, y las DEK unidas se devuelven al sistema de almacenamiento para mantenerlas con los fragmentos de datos. Cuando un sistema de almacenamiento necesita recuperar datos encriptados, recupera las DEK unidas y las pasa al almacén de claves. El almacén de claves verifica que este servicio esté autorizado para usar esa KEK. De ser así, separa la DEK y la devuelve en texto simple al servicio. Luego, el servicio usa la DEK para desencriptar el fragmento de datos, transformarlo en texto simple y verificar su integridad.
Todos los sistemas de almacenamiento de Google Cloud cumplen con este modelo de administración de claves, pero la mayoría de los sistemas también implementan niveles adicionales de KEK en el almacenamiento para crear una jerarquía de claves. Esto permite que los sistemas proporcionen una latencia baja mientras usan la KEK de nivel más alto (guardada en el almacén de claves) como raíz de confianza.
Genera KEK
La mayoría de las KEK para encriptar fragmentos de datos se generan dentro del almacén de claves, y el resto se genera dentro de los servicios de almacenamiento. Para garantizar la coherencia, todas las KEK se generan con la biblioteca criptográfica común de Google mediante un generador de números al azar (RNG) que compiló Google. Este RNG se basa en NIST 800-90Ar1 CTR-DRBG y genera una KEK AES-256. (Antes se usaba AES-128, y algunas de estas claves siguen activas para desencriptar datos).
Para los procesadores Intel y AMD, el RNG se inicializa a partir de la instrucción RDRAND y del RNG del kernel de Linux. A su vez, el RNG del kernel de Linux se inicializa a partir de varias fuentes de entropía independientes, incluidos RDRAND y eventos de entropía del entorno del centro de datos (por ejemplo, mediciones detalladas de las búsquedas en discos y las horas de llegada entre paquetes). Para los procesadores de Arm, el RNG se inicializa a partir del RNG del kernel de Linux.
Las DEK se unen con KEK mediante AES-256 o AES-128, según el servicio de Google Cloud. Actualmente, estamos trabajando para actualizar todas las KEK de los servicios de Google Cloud a AES-256.
Administración de KEK
El almacén de claves se diseñó exclusivamente para administrar las KEK. Por diseño, las KEK que usan los sistemas de almacenamiento no se pueden exportar desde el almacén de claves. Toda encriptación y desencriptación con estas claves se debe realizar dentro del almacén de claves. Esto ayuda a evitar filtraciones y usos inadecuados, y permite que Keystore cree un registro de auditoría cuando se usan las claves.
El almacén de claves puede rotar las KEK de manera automática en intervalos regulares y generar claves nuevas mediante la biblioteca criptográfica común de Google. Si bien a menudo nos referimos a una sola clave, en realidad los datos están protegidos con un conjunto de claves: una clave está activa para la encriptación y un conjunto de claves históricas está activo para la desencriptación. La cantidad de claves históricas se determina mediante el programa de rotación de claves. Se crean copias de seguridad de las KEK para la recuperación ante desastres y se pueden recuperar de manera indefinida.
El uso de las KEK se administra con LCA en el almacén de claves para cada clave, con una política por clave. Solo los servicios y los usuarios autorizados de Google tienen permitido el acceso a una clave. Se realiza un seguimiento del uso de cada clave en el nivel de la operación individual que necesita esa clave, de manera que cada vez que un usuario usa una clave, se autentica y se registra. El acceso a los datos de los usuarios es auditable como parte de las políticas de seguridad y privacidad generales de Google.
Proceso para acceder a fragmentos de datos encriptados
Cuando un servicio de Google accede a un fragmento de datos encriptado, ocurre lo siguiente:
- El servicio hace una llamada al sistema de almacenamiento para solicitar los datos que necesita.
- El sistema de almacenamiento identifica los fragmentos que contienen esos datos (los ID de fragmento) y su ubicación.
- Para cada fragmento, el sistema de almacenamiento extrae la DEK unida y almacenada con ese fragmento (en algunos casos, esto lo hace el servicio) y la envía al KMS para separarla.
- El sistema de almacenamiento verifica que el trabajo identificado tenga permitido el acceso al fragmento de datos según un identificador de trabajo y el ID del fragmento. Keystore verifica que el sistema de almacenamiento esté autorizado para usar la KEK asociada con el servicio y separar esa DEK específica.
- El almacén de claves realiza una de las siguientes acciones:
- Devuelve la DEK separada al sistema de almacenamiento, que desencripta el fragmento de datos y lo pasa al servicio.
- En casos excepcionales, pasa la DEK separada al servicio. El sistema de almacenamiento pasa el fragmento de datos encriptados al servicio, que lo desencripta y usa.
Este proceso es diferente en los dispositivos de almacenamiento dedicados, en los que el dispositivo administra y protege la DEK de nivel del dispositivo.
En el diagrama a continuación, se muestra este proceso. Para desencriptar un fragmento de datos, el servicio de almacenamiento llama al almacén de claves a fin de recuperar la DEK separada para ese fragmento de datos.
Raíz de confianza y jerarquía de la clave de encriptación
El almacén de claves está protegido por una clave raíz llamada clave maestra de almacén de claves, que une todas las KEK del almacén de claves. Esta clave maestra es de tipo AES-256 y se almacena en otro servicio de administración de claves, llamado Root Keystore. (Antes, la clave maestra del almacén de claves era AES-128 y algunas de estas claves siguen activas para desencriptar datos). Para ofrecer seguridad adicional, el almacén de claves raíz no se ejecuta en máquinas de producción general, sino solo en máquinas dedicadas en cada centro de datos de Google.
El almacén de claves raíz, a su vez, tiene su propia clave raíz, llamada clave maestra del almacén de claves raíz, que también es AES-256 y se almacena en una infraestructura entre pares, que es la que se proporciona a continuación: llamado distribuidor de claves maestras del almacén de claves raíz, y que replica estas claves de manera global. (Antes, la clave maestra del almacén de claves raíz era AES-128 y algunas de estas claves permanecen activas para desencriptar datos). El distribuidor de claves maestras del almacén de claves raíz solo conserva las claves en la RAM en las mismas máquinas dedicadas que el almacén de claves raíz, y utiliza el registro para verificar el uso adecuado.
Cuando se inicia una instancia nueva del distribuidor de claves maestras del almacén de claves raíz, se configura con una lista de nombres de host que ya ejecutan instancias del distribuidor. Luego, las instancias del distribuidor pueden obtener la clave maestra del almacén de claves raíz de otras instancias en ejecución. Aparte de los mecanismos de recuperación ante desastres que se describen en Disponibilidad y replicación global, la clave maestra del almacén de claves raíz existe solo en la RAM en una cantidad limitada de máquinas especialmente protegidas.
Para abordar una situación hipotética en la que todas las instancias del distribuidor de claves maestras del almacén de claves raíz se reinicien de manera simultánea, también existe una copia de seguridad de la clave maestra del almacén de claves raíz en dispositivos de hardware seguros que se almacenan en cajas fuertes físicas en áreas altamente protegidas en varias ubicaciones distribuidas geográficamente. Esta copia de seguridad se necesitaría solo si todas las instancias del distribuidor en una región fallaran a la vez. Solo algunos empleados de Google pueden acceder a estas cajas fuertes.
En el siguiente diagrama, se muestra la jerarquía de las claves de encriptación. La jerarquía de claves de encriptación protege un fragmento de datos con una DEK, unida con una KEK en el almacén de claves, que, a su vez, está protegida por el almacén de claves raíz y el distribuidor de claves maestras del almacén de claves raíz.
Resumen de la administración de claves
En la siguiente lista, se resume la administración de claves en Google:
- Los datos se fragmentan y se encriptan con DEK.
- Las DEK se encriptan con KEK.
- Las KEK se almacenan en el almacén de claves.
- El almacén de claves se ejecuta en varias máquinas en centros de datos ubicados en todo el mundo.
- Las claves del almacén de claves se unen con la clave maestra del almacén de claves, que se almacena en el almacén de claves raíz.
- El almacén de claves raíz es mucho más pequeño que el almacén de claves y se ejecuta solo en máquinas exclusivas de cada centro de datos.
- Las claves del almacén de claves raíz se unen con la clave maestra del almacén de claves raíz, que se almacena en el distribuidor de claves maestras del almacén de claves raíz.
- El distribuidor de claves maestras del almacén de claves raíz es una infraestructura entre pares que se ejecuta de manera simultánea en la RAM de máquinas exclusivas a nivel global. Cada máquina obtiene su material de clave de otras instancias en ejecución en la región.
- En caso de que todas las instancias del distribuidor en una región fallaran, una clave maestra se almacena en hardware seguro diferente en cajas fuertes físicas en ubicaciones limitadas de Google.
Replicación y disponibilidad global
En todos los niveles, son fundamentales la alta disponibilidad, la baja latencia y el acceso global a las claves. Estas características son necesarias para usar los servicios de administración de claves en Google.
Por este motivo, Keystore es altamente escalable y se replica miles de veces en nuestros centros de datos a nivel global. Se ejecuta en máquinas comunes de nuestra flota de producción, y las instancias del almacén de claves se ejecutan de manera global para apoyar las operaciones de Google. Como resultado, todas las operaciones de claves tienen una latencia muy baja.
El almacén de claves raíz se ejecuta en varias máquinas que se usan para las operaciones de seguridad en cada centro de datos. El distribuidor de claves maestras del almacén de claves raíz se ejecuta en estas mismas máquinas, en relación uno a uno con el almacén de claves raíz. El distribuidor proporciona un mecanismo de distribución mediante un protocolo “gossip”. En un intervalo de tiempo fijo, cada instancia del distribuidor selecciona otra instancia de forma aleatoria para comparar sus claves y concilia todas las diferencias entre sus versiones. Con este modelo no existe un nodo central del que dependa toda nuestra infraestructura. Este método de distribución nos permite mantener y proteger el material de clave con alta disponibilidad.
Biblioteca criptográfica común de Google
La biblioteca criptográfica común de Google es Tink, que incorpora nuestro módulo con validación del estándar FIPS 140-2, BoringCrypto. Tink está disponible para todos los desarrolladores de Google. El uso coherente de una biblioteca común significa que solo se necesita un equipo pequeño de criptógrafos para implementar y mantener este código controlado y revisado de forma estricta, por lo que cada equipo de Google debe desarrollar su propia criptografía de forma independiente. Un equipo de seguridad especial de Google es responsable de mantener esta biblioteca criptográfica común en todos los productos.
La biblioteca de encriptación Tink admite una amplia variedad de tipos y modos de claves de encriptación, que se revisan con regularidad para garantizar que estén al día con los ataques más recientes.
En la actualidad, usamos los siguientes algoritmos de encriptación en reposo para las DEK y KEK. Están sujetos a cambios a medida que mejoramos nuestras capacidades y seguridad.
| Primitiva criptográfica | Protocolos preferidos | Otros protocolos compatibles |
|---|---|---|
| Encriptación simétrica | AES-GCM (256 bits) |
|
| Firmas simétricas (cuando se usan con los protocolos AES-CBC y AES-CTR antes mencionados para la autenticación) | HMAC‑SHA256 |
|
La biblioteca también incluye otros protocolos criptográficos que se admitieron antes, pero esta tabla abarca los usos principales en Google.
Innovación y estudios de criptografía
Para seguir el ritmo de la evolución de la encriptación, tenemos un equipo de ingeniería de seguridad de primer nivel que se encarga de seguir, desarrollar y mejorar la tecnología de encriptación. Nuestros ingenieros participan en el proceso de estandarización y realizan un mantenimiento de software de encriptación con mucho uso. A menudo, publicamos nuestras investigaciones en el campo de la encriptación para que todas las personas (incluido el público general) puedan beneficiarse de nuestro conocimiento.
Por ejemplo, en la investigación criptográfica poscuántica, trabajamos en las siguientes áreas:
Estandarización: Codiseñamos el esquema de firma digital basado en hash sin estado que se estandariza como FIPS 205. Somos editores del estándar de la Organización Internacional de Normalización (ISO) sobre firmas criptográficas poscuánticas basadas en hash y contribuimos a la orientación sobre el estado administración para firmas basadas en hash en IETF.
Enablement: Lanzamos la criptografía poscuántica en nuestro protocolo interno de seguridad de la capa de transporte. Habilitamos la compatibilidad con la criptografía poscuántica en Chrome. Agregamos varios algoritmos de criptografía poscuántica en nuestro repositorio Tink criptográfico biblioteca. Este código es experimental y está diseñado para ayudar a educar a la comunidad sobre cada enfoque.
Publicaciones: Hace poco publicamos Transición de organizaciones a criptografía poscuántica en Nature. En este informe, se proporciona una descripción general sobre los desafíos de la migración criptográfica poscuántica. También publicamos un artículo de investigación sobre la obtención de criptografía poscuántica en nuestras llaves de seguridad.
Ten en cuenta que la encriptación simétrica (con AES-128 o posterior) sigue siendo resistente a los ataques cuánticos.
¿Qué sigue?
Para obtener información sobre cómo usar tus propias claves de encriptación en Google Cloud, consulta Claves de encriptación administradas por el cliente (CMEK).
Para obtener información general sobre la seguridad de Google Cloud, consulta la sección Seguridad del sitio web de Google Cloud.
Para obtener información sobre el cumplimiento y las certificaciones relacionadas de Google Cloud, consulta la sección Cumplimiento del sitio web de Google Cloud, que incluye el informe público de la auditoría SOC3 de Google.
Para obtener información sobre la encriptación de Google Workspace y la administración de claves, consulta Cómo Google Workspace usa la encriptación para proteger tus datos, que abarca gran parte del contenido incluido aquí, pero se enfoca solo en Google Workspace.