Encriptado en reposo en Google Cloud

El contenido incluido en este documento es correcto con fecha de julio del 2020 y representa la situación en el momento en que se redactó. Las políticas y sistemas de seguridad de Google Cloud podrían cambiar en el futuro, ya que mejoramos constantemente la protección que ofrecemos a nuestros clientes.

Botón de reproducción

Encriptado en reposo de Google Cloud

Resumen para directores de sistemas de información

  • Google utiliza varios niveles de encriptado para proteger los datos en reposo de los clientes en los productos de Google Cloud.
  • Google Cloud encripta mediante uno o varios mecanismos el contenido de los clientes que se almacena en reposo, sin que estos tengan que realizar ninguna acción.
  • Los datos almacenados se dividen en fragmentos y cada fragmento se encripta con una clave única de encriptado de datos. Dichas claves de encriptado de datos se almacenan junto con los datos y se encriptan (o "encapsulan") con claves de encriptado de claves que se guardan y usan exclusivamente dentro del servicio de gestión de claves centralizado de Google, un servicio redundante distribuido por todo el mundo.
  • Todos los datos almacenados en Google Cloud se encriptan a nivel de almacenamiento mediante AES256, a excepción de un número reducido de discos persistentes creados antes del 2015 que utilizan AES128.
  • Google utiliza Tink, una biblioteca criptográfica común que incorpora BoringCrypto (nuestro módulo validado de nivel 1 FIPS 140-2) para implementar el encriptado de manera uniforme en casi todos los productos de Google Cloud. El uso coherente de una biblioteca común significa que solo hace falta un equipo reducido de criptógrafos para implementar y mantener este código estrictamente controlado y revisado.

Introducción

Para muchas personas y empresas, la seguridad es un factor decisivo a la hora de elegir un proveedor de nube pública. Para nosotros, es de máxima importancia: en Google nos tomamos muy en serio la seguridad y la privacidad, y trabajamos sin descanso para proteger tus datos en todo momento, tanto cuando circulan por Internet como cuando se transfieren entre nuestros centros de datos o se almacenan en nuestros servidores.

El encriptado en tránsito y el encriptado en reposo forman el núcleo de nuestra estrategia integral de seguridad: solo los roles y los servicios autorizados que tienen acceso controlado a las claves de encriptado pueden acceder a los datos. En este documento, describimos el enfoque que adoptamos en Google para implementar el encriptado en reposo en Google Cloud y explicamos cómo utilizamos dicho encriptado para proteger tu información.

Este documento está dirigido a directores de seguridad de la información y equipos de operaciones de seguridad que usen o se planteen utilizar Google Cloud. A excepción de la introducción, se presupone que el lector tiene conocimientos básicos sobre encriptado y primitivas criptográficas.

¿Qué es el encriptado?

El encriptado es un proceso que toma datos legibles como datos de entrada (que suelen denominarse "texto sin formato") y los transforma en datos de salida (o "texto encriptado") que revelan poca o ninguna información sobre el texto sin formato. El algoritmo de encriptado que se utiliza es público, como el estándar de encriptado avanzado (AES), pero la ejecución depende de una clave que se mantiene en secreto. Dicha clave es necesaria para desencriptar el texto encriptado y devolverlo a su forma original. En Google, al uso del encriptado para mantener la confidencialidad de los datos solemos añadirle la protección de la integridad. De este modo, aunque se tenga acceso al texto encriptado, este no se podrá entender ni modificar si no se tiene la clave. Para obtener más información sobre la criptografía, te recomendamos que consultes este recurso: Introduction to Modern Cryptography.

En este informe, nos centramos en el encriptado en reposo. Cuando hablamos del encriptado en reposo, nos referimos al que se utiliza para proteger los datos almacenados en un disco (como las unidades de estado sólido) o en una copia de seguridad. Si quieres ampliar tus conocimientos sobre el encriptado de datos en tránsito, lee el informe correspondiente.

¿Por qué ayuda el encriptado a proteger los datos de los clientes?

El encriptado es una de las piezas de una estrategia de seguridad más amplia. El encriptado añade una capa de defensa en profundidad para proteger los datos: si caen accidentalmente en manos de un atacante, el encriptado garantiza que este no pueda acceder a ellos si no cuenta también con las claves de encriptado. El atacante no podrá comprender ni desencriptar tus datos, aunque consiga los dispositivos en que están almacenados.

El encriptado en reposo reduce la superficie de ataque al "eliminar", en la práctica, las capas inferiores de la pila de software y hardware. Incluso si se vulneran las capas inferiores (por ejemplo, a través del acceso físico a los dispositivos), los datos de dichos dispositivos seguirán protegidos si se ha desplegado el encriptado adecuado. El encriptado también actúa como un "cuello de botella": gracias a la gestión centralizada de las claves de encriptado, se crea un único lugar desde donde acceder a los datos y puede auditarse ese acceso.

El encriptado es uno de los principales mecanismos que utilizamos en Google para garantizar la privacidad de los datos del cliente. Gracias a esto, los sistemas pueden utilizar los datos (por ejemplo, para hacer copias de seguridad o permitir que los ingenieros gestionen la infraestructura) sin proporcionar acceso al contenido.

¿Qué consideramos "datos del cliente"?

Tal y como se definen en los términos del servicio de Google Cloud, los datos del cliente son el contenido que un cliente de Google Cloud (o un tercero que lo haga a petición suya) proporciona a Google, directa o indirectamente, a través de los servicios de Google Cloud utilizados por la cuenta de dicho cliente. Los datos del cliente abarcan tanto el contenido como los metadatos del cliente.

El contenido del cliente son los datos que el cliente genera por sí mismo o que le proporciona a Google, como datos almacenados en Cloud Storage, capturas de disco usadas por Compute Engine o políticas de Gestión de Identidades y Accesos. El presente informe se centra en el encriptado en reposo del contenido del cliente.

Los metadatos del cliente son el resto de los datos de este y constituyen todos los datos que no se pueden clasificar como "contenido del cliente". Algunos ejemplos de metadatos del cliente son los números de proyecto generados automáticamente, las marcas de tiempo y las direcciones IP, así como el tamaño en bytes de un objeto que se encuentra en Cloud Storage o el tipo de máquina de Compute Engine. Los metadatos cuentan con un grado de protección razonable que permite garantizar un buen rendimiento y la continuidad de las operaciones.

Encriptado predeterminado de Google

Encriptado de los datos en reposo

Google Cloud encripta mediante uno o varios mecanismos el contenido de los clientes que se almacena en reposo, sin que estos tengan que realizar ninguna acción.

Capas de encriptado

En Google utilizamos varias capas de encriptado para proteger los datos. El uso de varias capas de encriptado aporta una protección de datos redundante y nos permite elegir el enfoque más adecuado en función de los requisitos de cada aplicación.

Gráfico de capas de encriptado

Figura 1: Para proteger los datos almacenados en Google Cloud, se utilizan varias capas de encriptado. Se implementa o bien el encriptado de sistemas de archivos distribuidos, o bien el encriptado de almacenamiento en base de datos y archivos para casi todos los archivos. Además, se utiliza el encriptado de dispositivos de almacenamiento para casi todos los archivos.

Encriptado en la capa del sistema de almacenamiento

Para comprender cómo funciona el encriptado de Cloud Storage en concreto, es importante entender cómo almacena Google los datos de los clientes. Para poder almacenar los datos, se dividen en fragmentos de subarchivos; cada fragmento puede tener un tamaño de varios GB. Cada fragmento se encripta a nivel de almacenamiento con una clave de encriptado única. Por tanto, dos fragmentos diferentes nunca podrán tener la misma clave de encriptado aunque formen parte del mismo objeto de Cloud Storage, pertenezcan al mismo cliente o se almacenen en la misma máquina.1 Si un fragmento de datos se actualiza, en lugar de reutilizar la clave anterior, se encripta con una nueva. Gracias a esta partición de datos y a que cada fragmento tiene una clave diferente, si se llega a vulnerar alguna clave de encriptado de datos, las consecuencias se limitarán únicamente a ese fragmento de datos.

En Google, encriptamos los datos antes de que se escriban en el disco. El encriptado es una parte inherente a todos los sistemas de almacenamiento de Google, no un paso que se añade a posteriori.

Cada fragmento de datos tiene un identificador único. Las listas de control de acceso (LCA) garantizan que cada fragmento se pueda desencriptar únicamente mediante los servicios de Google que operan bajo roles autorizados, a los que se concede acceso en ese momento. De este modo, se impide el acceso no autorizado a los datos, lo que refuerza su seguridad y privacidad.

Cada fragmento se distribuye a través de los sistemas de almacenamiento de Google y se replica en su forma encriptada para la realización de copias de seguridad y la recuperación tras fallos. Cualquier persona malintencionada que quiera acceder a los datos de los clientes deberá conocer y tener acceso a (1) todos los fragmentos de almacenamiento correspondientes a los datos que quiere obtener y a (2) las claves de encriptado de dichos fragmentos.

Diagrama de datos almacenados en fragmentos encriptados

Figura 2: Para almacenar los datos, Google los divide en fragmentos encriptados.

En Google utilizamos el algoritmo estándar de encriptado avanzado (AES) para encriptar los datos en reposo. Todos los datos del nivel de almacenamiento se encriptan con AES256 de forma predeterminada, a excepción de un número reducido de discos persistentes creados antes del 2015 que usan AES128. AES está muy extendido porque (1) el instituto nacional de estándares y tecnología de Estados Unidos (NIST) recomienda AES256 y AES128 para su uso en el almacenamiento a largo plazo (a fecha de marzo del 2019), y (2) AES a menudo forma parte de los requisitos de cumplimiento de los clientes.

Los datos almacenados en Cloud Storage se encriptan a nivel de almacenamiento mediante AES, en Modo Galois/Counter (GCM) en casi todos los casos. En determinados casos, AES se utiliza en el modo de encadenamiento de bloques de encriptado (CBC) con un código de autenticación de mensajes en clave‑hash (HMAC) para la autenticación. En algunos archivos replicados, AES se usa en el modo Counter (CTR) con HMAC. Puedes obtener más información sobre los algoritmos más adelante en este documento. En otros productos de Google Cloud, AES se usa en diversos modos.

Encriptado en la capa del dispositivo de almacenamiento

Además del encriptado a nivel del sistema de almacenamiento descrito más arriba, en la mayoría de los casos los datos también se encriptan a nivel de dispositivo de almacenamiento. Para ello, se utiliza AES256 para los discos duros (HDD) y las unidades de estado sólido (SSD), con una clave a nivel de dispositivo diferente a la utilizada para encriptar los datos a nivel de almacenamiento. Un número reducido de HDD antiguos usan AES128. Las SSD que utiliza Google Cloud implementan AES256 únicamente para los datos de usuario.

Encriptado de las copias de seguridad

El sistema de copias de seguridad de Google garantiza que los datos permanezcan encriptados durante todo el proceso de copia de seguridad. Este enfoque evita que los datos de texto sin formato se expongan de forma innecesaria.

Además, el sistema de copias de seguridad encripta cada uno de los archivos de forma independiente con su propia clave de encriptado de datos (DEK), la cual se crea a partir de una clave almacenada en el servicio de gestión de claves (KMS) de Google y de una semilla generada de forma aleatoria para cada archivo al crear la copia de seguridad. Para todos los metadatos de las copias de seguridad se utiliza otra DEK, que también se almacena en el KMS de Google. Puedes obtener más información sobre la gestión de claves en una sección posterior.

Cumplimiento del estándar FIPS para los datos en reposo

Google Cloud utiliza un módulo de encriptado de nivel 1 FIPS 140-2 (certificado 3318) en nuestro entorno de producción.

Gestión de claves

Claves de encriptado de datos, claves de encriptado de claves y servicio de gestión de claves de Google

La clave que se utiliza para encriptar los datos de un fragmento se denomina clave de encriptado de datos (DEK). Estas claves se almacenan cerca de los datos que encriptan debido al gran volumen de claves que tenemos en Google y a la necesidad de ofrecer una latencia baja y una disponibilidad alta. Las DEK se encriptan (o se "encapsulan") con una clave de encriptado de claves (KEK). Cada servicio de Google Cloud tiene una o varias KEK. Estas KEK se almacenan de forma centralizada en el KMS de Google, un repositorio creado específicamente para almacenar claves. La existencia de un menor número de KEK que de DEK y el uso de un servicio central de gestión de claves posibilita el almacenamiento y encriptado de datos a la escala de Google, y nos permite monitorizar y controlar el acceso a los datos desde un punto central.

Para cada cliente de Google Cloud, los recursos que no son compartidos2 se dividen en fragmentos de datos y se encriptan con claves distintas a las que se utilizan con otros clientes.3 Estas DEK son incluso independientes de las que protegen otras partes de los mismos datos que pertenecen al mismo cliente.

El sistema de almacenamiento genera las DEK mediante la biblioteca criptográfica común de Google. A continuación, se envían al KMS para encapsularlas con la KEK de dicho sistema de almacenamiento y, luego, las DEK encapsuladas se reenvían al sistema de almacenamiento para guardarlas con los fragmentos de datos. Cuando un sistema de almacenamiento necesita acceder a datos encriptados, este obtiene la DEK encapsulada y la envía al KMS. Entonces, el KMS verifica que el servicio tiene autorización para usar la KEK y, si es así, desencapsula la DEK y se la devuelve al servicio en forma de texto sin formato. A continuación, el servicio usa la DEK para desencriptar el fragmento de datos convirtiéndolo en texto sin formato y verificar su integridad.

La mayoría de las KEK que se utilizan para encriptar fragmentos de datos se generan dentro del KMS, y el resto, dentro de los servicios de almacenamiento. Por motivos de coherencia, todas las KEK se crean a través de la biblioteca criptográfica común de Google, mediante un generador de números aleatorios (RNG) diseñado por Google. Este RNG se basa en NIST 800‑90Ar1 CTR‑DRBG y genera una KEK en AES2564. Dicho RNG se deriva del RNG del kernel de Linux, que a su vez se origina en varias fuentes de entropía independientes. Entre dichas fuentes de entropía, están los eventos entrópicos del entorno del centro de datos (como las mediciones detalladas de búsqueda de discos y los tiempos de llegada entre paquetes) y la instrucción RDRAND de Intel (disponible en Ivy Bridge y en CPUs más modernas).

Los datos almacenados en Google Cloud se encriptan con DEKs mediante los algoritmos AES256 o AES128, tal y como se ha explicado más arriba; y todos los nuevos datos encriptados en discos persistentes en Compute Engine se encriptan mediante AES256. Las DEK se encapsulan con KEKs mediante AES256 o AES128, en función del servicio de Google Cloud. Actualmente, estamos actualizando todas las KEK para servicios de Cloud al algoritmo AES256.

El KMS de Google se creó exclusivamente con el objetivo de gestionar las KEK. Al fin y al cabo, fue diseñado para mejorar la seguridad. Por la forma en que están diseñadas, las KEK no se pueden exportar desde el KMS de Google; todo el encriptado y desencriptado con estas claves se debe realizar dentro del KMS. Esto ayuda a evitar que se produzcan filtraciones y que se haga un uso inadecuado de ellas, y permite que el KMS proporcione un registro de auditoría cuando se utilizan claves.

El KMS puede rotar KEKs automáticamente en intervalos de tiempo periódicos a través de la biblioteca criptográfica común de Google para generar nuevas claves. Aunque a menudo hacemos alusión a una sola clave, lo que realmente queremos decir es que los datos se protegen mediante el uso de un conjunto de claves: una clave activa para el encriptado y un conjunto de claves históricas para el desencriptado, cuyo número está determinado por la programación de rotación de claves. La programación de rotación real de una KEK varía según el servicio, pero el periodo de rotación estándar es de 90 días. Cloud Storage, en concreto, rota sus KEK cada 90 días y puede almacenar un máximo de 20 versiones; para ello, debe volver a encriptar los datos al menos una vez cada 5 años (aunque, en la práctica, los datos se vuelven a encriptar con mucha más frecuencia). Con fines de recuperación tras fallos, se crea una copia de seguridad de las claves almacenadas en el KMS. De este modo, pueden recuperarse indefinidamente.

El uso de las KEK de cada clave se gestiona mediante LCAs, y se aplica una política a cada clave. Solo los usuarios y servicios de Google autorizados tienen acceso a las claves. El uso de cada clave se supervisa a nivel de la operación concreta que requiere dicha clave. Así, cada vez que una persona utiliza una clave, esta se autentica y registra. Para cumplir las políticas de seguridad y privacidad generales de Google, todos los accesos humanos a los datos son auditables.

Cuando un servicio de Google Cloud accede a un fragmento de datos encriptado, ocurre lo siguiente:

  1. El servicio hace una llamada al sistema de almacenamiento para obtener los datos que necesita.
  2. El sistema de almacenamiento identifica los fragmentos en los que se almacenan dichos datos (los ID de los fragmentos) y el lugar en que se almacenan.
  3. A continuación, el sistema de almacenamiento extrae la DEK encapsulada que se ha almacenado con cada fragmento (en algunos casos, el propio servicio se encarga de realizar esta operación) y la envía al KMS para desencapsularla.
  4. El sistema de almacenamiento verifica que la tarea identificada tiene permiso para acceder al fragmento de datos; para ello, comprueba el identificador de la tarea y el ID del fragmento. Acto seguido, el KMS verifica que el sistema de almacenamiento está autorizado para usar la KEK asociada al servicio y para desencapsular esa DEK en particular.
  5. El KMS realiza una de las siguientes acciones:
    • Devuelve la DEK desencapsulada al sistema de almacenamiento, el cual desencripta el fragmento de datos y lo envía al servicio. En raras ocasiones,
    • envía la DEK desencapsulada al servicio y el sistema de almacenamiento envía el fragmento de datos encriptado al servicio, el cual desencripta el fragmento de datos y lo utiliza.

Este proceso es distinto en los dispositivos de almacenamiento especializados, como las SSD locales; en estas unidades, el dispositivo gestiona y protege la DEK de nivel de dispositivo.

Diagrama de desencriptado de fragmentos de datos

Figura 3: Para desencriptar un fragmento de datos, el servicio de almacenamiento llama al KMS de Google para acceder a la DEK desencapsulada de dicho fragmento de datos.

Jerarquía de las claves de encriptado y raíz de confianza

El KMS de Google está protegido por una clave raíz llamada clave maestra del KMS, que encapsula todas las KEK del KMS. Esta clave maestra del KMS utiliza el estándar AES2564 y se almacena en otro servicio de gestión de claves, denominado Root KMS, que almacena muchas menos claves: doce, aproximadamente. Para ofrecer una mayor seguridad, Root KMS no se ejecuta en máquinas de producción general, sino que lo hace únicamente en máquinas especializadas de cada centro de datos de Google.

A su vez, Root KMS tiene su propia clave raíz (llamada clave maestra de Root KMS), que también utiliza el estándar AES2564 y se almacena en una infraestructura entre pares (denominada distribuidor de claves maestras de Root KMS), que replica estas claves en todo el mundo. El distribuidor de claves maestras de Root KMS solo tiene las claves en la RAM de las mismas máquinas especializadas que Root KMS y utiliza registros para verificar que se hace un uso adecuado. Por cada instancia de Root KMS, se ejecuta una instancia del distribuidor de claves maestras de Root KMS. El distribuidor de claves maestras de Root KMS aún se encuentra en la fase de implementación, y el objetivo es reemplazar un sistema que funcionaba de forma semejante, pero no entre pares.

Cuando se inicia una nueva instancia del distribuidor de claves maestras de Root KMS, se configura con una lista de nombres de host que ya están ejecutando instancias de distribuidor. De este modo, las instancias de distribuidor pueden obtener la clave maestra de Root KMS a partir de otras instancias en ejecución. Aparte de los mecanismos de recuperación tras fallos que se describen más abajo, la clave maestra de Root KMS solo existe en la RAM en un número limitado de máquinas especialmente protegidas.

Para abordar una situación en la que todas las instancias del distribuidor de claves maestras del KMS se reinicien simultáneamente, se crea una copia de seguridad de la clave maestra de Root KMS en los dispositivos de hardware seguros almacenados en cajas fuertes físicas, situados en zonas altamente protegidas de dos ubicaciones de Google separadas físicamente, ubicadas en diferentes lugares del mundo. Esta copia de seguridad solo sería necesaria si todas las instancias de distribuidor se desactivaran a la vez; por ejemplo, si se produjera un reinicio mundial. Menos de veinte empleados de Google tienen acceso a estas cajas fuertes.

Diagrama de la jerarquía de encriptado de Google

Figura 4: La jerarquía de las claves de encriptado protege un fragmento de datos con una DEK, encapsulada con una KEK en el KMS, que a su vez está protegida por Root KMS y el distribuidor de claves maestras de Root KMS.

En resumen:

  • Los datos se fragmentan y se encriptan con DEKs.
  • Las DEK se encriptan con KEKs.
  • Las KEK se almacenan en el KMS.
  • El KMS se ejecuta en varias máquinas en centros de datos de todo el mundo.
    • Las claves del KMS se encapsulan con la clave maestra del KMS, que se almacena en Root KMS.
  • Root KMS tiene un tamaño mucho más reducido que el KMS y solo se ejecuta en máquinas especializadas de cada centro de datos.
    • Las claves de Root KMS se encapsulan con la clave maestra de Root KMS, que se almacena en el distribuidor de claves maestras de Root KMS.
  • El distribuidor de claves maestras de Root KMS es una infraestructura entre pares que se ejecuta simultáneamente en la memoria RAM de máquinas especializadas situadas en distintos lugares del mundo; cada una de ellas obtiene su material de claves de otras instancias en ejecución.
    • Por si todas las instancias del distribuidor se desactivaran (apagón completo), hay una clave maestra almacenada en un hardware seguro (diferente), en cajas fuertes (físicas) de unos pocos centros de Google.
    • El distribuidor de claves maestras de Root KMS aún se encuentra en la fase de implementación, y su objetivo es reemplazar a un sistema que funcionaba de forma semejante, pero no entre pares.

Disponibilidad mundial y replicación

La alta disponibilidad, la baja latencia y el acceso mundial a las claves son fundamentales en todos los niveles. Estas características son esenciales para que los servicios de gestión de claves se puedan usar en Google.

Por este motivo, el KMS es muy escalable y se replica miles de veces en los centros de datos de Google de todo el mundo. Se ejecuta en máquinas normales del equipo de producción de Google, y hay instancias del KMS ejecutándose en diferentes lugares del planeta para posibilitar las operaciones de Google Cloud. Por tanto, la latencia de todas las operaciones de claves es muy baja.

En cada centro de datos, Root KMS se ejecuta en varias máquinas especializadas en realizar operaciones de seguridad. El distribuidor de claves maestras de Root KMS se ejecuta en estas mismas máquinas, en relación de uno a uno con Root KMS. El distribuidor de claves maestras de Root KMS proporciona un mecanismo de distribución a través de un protocolo Gossip: en un intervalo de tiempo fijo, cada instancia de distribuidor elige una instancia de forma aleatoria para comparar las claves y conciliar las diferencias con las versiones de claves. En este modelo, la infraestructura de Google no depende de un nodo central, lo cual nos permite mantener y proteger el material de claves con alta disponibilidad.

Biblioteca criptográfica común de Google

La biblioteca criptográfica común de Google se llama Tink5 e implementa algoritmos criptográficos mediante BoringCrypto, nuestro módulo validado de nivel 1 FIPS 140-2.

Todos los desarrolladores de Google pueden utilizar Tink. El uso coherente de una biblioteca común significa que solo hace falta un equipo reducido de criptógrafos para implementar y mantener este código estrictamente controlado y revisado. En otras palabras: no hace falta que cada equipo de Google despliegue su propia criptografía. Un equipo especial de seguridad de Google es responsable de mantener esta biblioteca criptográfica común para todos los productos.

La biblioteca de encriptado Tink es compatible con una amplia gama de modos y tipos de claves de encriptado que se revisan periódicamente para garantizar que estén protegidos contra los ataques más recientes.

A fecha de la publicación del presente documento, Google utiliza los algoritmos que se indican a continuación para el encriptado en reposo de DEKs y KEKs. Dichos algoritmos de encriptado pueden cambiar a medida que mejoramos nuestras funcionalidades y la seguridad.

Primitiva criptográfica Protocolos preferidos Otros protocolos compatibles6
Encriptado simétrico
  • AES‑GCM (256 bits)
  • AES‑CBC y AES‑CTR (128 y 256 bits)
  • AES‑EAX (128 y 256 bits)
Firmas simétricas (cuando se usan con los AES‑CBC y AES‑CTR anteriores para la autenticación)
  • HMAC‑SHA256
  • HMAC‑SHA512
  • HMAC‑SHA1

Granularidad del encriptado para cada producto de Google Cloud

Cada servicio de Google Cloud divide los datos a un nivel diferente de granularidad para el encriptado.

  Servicios de Google Cloud Granularidad del encriptado de datos del cliente7 (tamaño de los datos encriptados con una sola DEK)
Almacenamiento Cloud Bigtable Por fragmento de datos (varios por tabla)
Datastore Por fragmento de datos8
Firestore Por fragmento de datos8
Cloud Spanner Por fragmento de datos (varios por tabla)
Cloud SQL
  • Segunda generación: por instancia, como en Compute Engine (cada instancia podría contener varias bases de datos)
  • Primera generación: por instancia
Cloud Storage Por fragmento de datos (normalmente entre 256 kB y 8 MB)
Computación App Engine9 Por fragmento de datos8
Cloud Functions10 Por fragmento de datos8
Compute Engine
  • Varios, por disco
  • Por grupo de capturas, con intervalos de capturas concretos generados a partir de la clave maestra del grupo de capturas
  • Por imagen
Google Kubernetes Engine Varios por disco, para discos persistentes
Container Registry Almacenados en Cloud Storage, por fragmento de datos
Big Data BigQuery Varios por conjunto de datos
Dataflow Almacenados en Cloud Storage, por fragmento de datos
Datalab Almacenados en Cloud Bigtable, por archivo de cuaderno
Dataproc Almacenados en Cloud Storage, por fragmento de datos
Pub/Sub Rotan cada 30 días8

Otras opciones de encriptado para los clientes de Cloud

Aparte de poner a disposición de nuestros clientes de Google Cloud la opción predeterminada de encriptado, estamos desarrollando otras alternativas de encriptado y gestión de claves para que puedan tener un mayor control.

Queremos que los clientes de Google Cloud puedan hacer lo siguiente:

  • Ser los propietarios finales de sus datos, y ser capaces de controlar el acceso y el uso de estos al máximo nivel de granularidad, con el objetivo de asegurar tanto la seguridad como la privacidad de sus datos.
  • Gestionar el encriptado de los datos que alojan en la nube del mismo modo que lo hacen on-premise o incluso de forma más eficaz.
  • Tener una raíz de confianza demostrable y auditable para sus recursos.
  • Ser capaces de separar y segregar aún más sus datos, no solo mediante las LCA.

Los clientes pueden usar las claves de encriptado que gestionan con Google Cloud mediante la función de claves de encriptado proporcionadas por el cliente. Esta función está disponible en Cloud Storage y en Compute Engine para el encriptado en la capa de almacenamiento.

Nuestros clientes también pueden gestionar sus propias claves de encriptado en Google Cloud con Cloud Key Management Service. Con este producto, el cliente puede gestionar el encriptado a nivel de aplicación.

Investigación e innovación en criptografía

Para mantenerse al día en materia de avances del encriptado, Google cuenta con un equipo de ingenieros de seguridad de primer orden dedicados a analizar, desarrollar y mejorar la tecnología de encriptado. Nuestros ingenieros se encargan de los procesos de estandarización y del mantenimiento del software de encriptado de uso más generalizado. Realizamos publicaciones periódicas sobre nuestras investigaciones en el campo del encriptado para que todo el sector, incluido el público en general, pueda beneficiarse de nuestros conocimientos. Por ejemplo, en el 2014 sacamos a la luz una vulnerabilidad significativa en el encriptado SSL 3.0 (conocida como POODLE) y en el 2015 identificamos una vulnerabilidad de alto riesgo en OpenSSL.

Google se propone seguir siendo el líder del sector en el encriptado de servicios en la nube. Para lograr dicho objetivo, tenemos a varios equipos trabajando en el desarrollo, la implementación y la investigación de nuevas técnicas criptográficas, más concretamente en los siguientes campos:

  • Criptografía parcialmente homomórfica: posibilita la realización de algunas operaciones en los datos encriptados. De este modo, la nube nunca ve los datos en texto sin formato, ni siquiera en la memoria. Utilizamos esta tecnología, por ejemplo, como parte de nuestro cliente BigQuery encriptado experimental, que está disponible para el público.
  • Criptografía con preservación del formato y del orden: permite realizar algunas operaciones de comparación y clasificación en los datos encriptados.
  • Criptografía poscuántica: permite sustituir primitivas criptográficas vulnerables a ataques cuánticos eficientes por candidatos poscuánticos que parecen oponer mayor resistencia a este tipo de ataques. Nuestro objetivo principal consiste en investigar y crear prototipos de criptografía de clave pública basada en rejilla, incluidas las recomendaciones del NIST sobre los algoritmos poscuánticos. Hoy en día, se cree que la criptografía basada en rejilla es una de las técnicas de encriptado con más probabilidad de usarse en la era poscuántica. No obstante, todavía nos queda bastante para desarrollar algoritmos, parámetros concretos y criptoanálisis lo suficientemente avanzados como para aplicar la criptografía basada en rejilla. Si bien los algoritmos cuánticos que conocemos actualmente debilitan el encriptado de claves simétricas y los códigos de autenticación de mensajes (MAC), es posible actualizarlos a bits de seguridad similares a los de una posible era poscuántica mediante la duplicación de los tamaños de las claves.

Otras referencias

Seguridad de Google Cloud

Para obtener información general sobre la seguridad de Google Cloud, consulta la sección "Seguridad" del sitio web de Google Cloud.

Cumplimiento de Google Cloud

Para informarte sobre el cumplimiento y los certificados correspondientes de Google Cloud, consulta la sección "Cumplimiento" del sitio web de Google Cloud, donde se incluye el informe público de auditoría SOC3 de Google.

Seguridad de Google Workspace

Para obtener más información sobre el encriptado y la gestión de claves de Google Workspace, consulta el informe correspondiente. Si bien dicho informe abarca parte del contenido expuesto en el presente documento, aquel se centra exclusivamente en Google Workspace. En Google, nos esforzamos en proteger los datos de los clientes de todas las soluciones de Google Workspace y en demostrar transparencia en todo momento. Para obtener más información sobre la seguridad general de Google Workspace, consulta el informe sobre la seguridad y el cumplimiento de Google Workspace.

Notas a pie de página

1 Un fragmento de datos de Cloud Datastore, App Engine y Cloud Pub/Sub pueden contener datos de varios clientes. Consulta la sección sobre la granularidad del encriptado de datos por servicio.
2 Un ejemplo de un recurso compartido (en el que no se aplica esta segregación) sería una imagen base compartida en Compute Engine. Evidentemente, varios clientes se remiten a una sola copia encriptada por una única DEK.
3 A excepción de los datos almacenados en Datastore, App Engine y Pub/Sub, donde más de una fracción de los datos de los clientes puede estar encriptada con la misma DEK. Consulta la sección sobre la granularidad del encriptado de datos por servicio.
4 Cabe señalar que, hace años, era el algoritmo AES128 y algunas de estas claves permanecen activas para desencriptar datos.
5 Google también usa otras dos bibliotecas: Keymaster y CrunchyCrypt. Keymaster comparte código de criptografía más reciente con Tink, pero utiliza una implementación de versiones de clave diferente y es compatible con una gama más amplia de algoritmos antiguos. Actualmente, CrunchyCrypt se está fusionando con Tink.
6 En la biblioteca hay otros protocolos criptográficos que fueron compatibles anteriormente, pero en esta lista se tratan los principales usos en Google Cloud.
7 Se refiere a la granularidad del encriptado del contenido del cliente. No se incluyen los metadatos del cliente (por ejemplo, los nombres de los recursos). En algunos servicios, se utiliza una única DEK para encriptar todos los metadatos.
8 No son exclusivos de un solo cliente.
9 Incluye el código y la configuración de la aplicación. Según las configuraciones del cliente, los datos utilizados en App Engine se almacenan en Datastore, Cloud SQL o Cloud Storage.
10 Incluye el código de las funciones, los ajustes y los datos de eventos. Los datos de eventos se almacenan en Pub/Sub.