Encriptado en reposo en Google Cloud Platform

El contenido incluido en este documento es correcto en abril del 2017 y representa la situación en el momento en que se redactó. Es posible que los sistemas y las políticas de seguridad de Google Cloud Platform cambien a medida que mejoramos la protección de nuestros clientes.

Botón de reproducción

Encriptado en reposo en Google Cloud

Resumen para directores de información

  • Google utiliza varias capas de encriptado para proteger los datos en reposo de los clientes dentro de los productos de Google Cloud Platform.
  • Google Cloud Platform encripta mediante uno o varios mecanismos el contenido en reposo almacenado por los clientes, sin que estos tengan que realizar ninguna acción. Existen pequeñas excepciones, que se mencionan más adelante en este documento.
  • 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 almacenan y usan exclusivamente dentro del servicio de gestión de claves centralizado de Google, un servicio redundante distribuido por todo el mundo.
  • Los datos almacenados en Google Cloud Platform se encriptan a nivel de almacenamiento mediante AES256 o AES128.
  • Google utiliza una biblioteca criptográfica común (Tink) para implementar el encriptado de manera uniforme en la gran mayoría de los productos de Google Cloud Platform. Dado que esta biblioteca común es ampliamente accesible, solo se necesita un pequeño equipo de criptógrafos para implementar y mantener de forma adecuada 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 Platform y explicamos cómo utilizamos dicho encriptado para proteger tu información.

Este documento está dirigido a los directores de seguridad de la información y equipos de operaciones de seguridad que usan o se plantean utilizar Google Cloud Platform. 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 (comúnmente denominados "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, solemos combinar el uso del encriptado con la protección de la integridad para mantener la confidencialidad de los datos. 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: Introducción a la criptografía moderna.

En este informe, nos centramos en el encriptado en reposo. Cuando hablamos de encriptado en reposo, nos referimos al que se utiliza para proteger los datos almacenados en un disco (incluidas las unidades de estado sólido) o en un soporte para copias de seguridad.

¿Por qué el encriptado ayuda 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, ni siquiera con los dispositivos en que están almacenados.

El encriptado en reposo reduce la superficie de ataque al "eliminar" de forma efectiva las capas inferiores de la pila de software y hardware. Incluso si las capas inferiores se ven comprometidas (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": las claves de encriptado gestionadas de manera central crean un único lugar desde donde acceder a los datos, que además es auditable.

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

¿Qué consideramos "datos del cliente"?

Tal y como se definen en las condiciones del servicio de Google Cloud Platform, por datos del cliente nos referimos al contenido que un cliente de Google Cloud Platform (o un tercero que lo haga a petición suya) proporciona directa o indirectamente a Google mediante los servicios de Google Cloud Platform utilizados a través de 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 los clientes de Google Cloud Platform generan por su cuenta o proporcionan a Google, tales como los datos almacenados en Google Cloud Storage, las capturas de disco utilizadas por Google Compute Engine y las políticas de Cloud IAM. 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 de Google Cloud Storage o el tipo de máquina de Google Compute Engine. Los metadatos cuentan con un grado de protección razonable que permita garantizar un buen rendimiento y la continuidad de las operaciones.

Encriptado predeterminado de Google

Encriptado de los datos en reposo

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: Se utilizan varias capas de encriptado para proteger los datos almacenados en Google Cloud Platform. 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 Google Cloud Storage en concreto, es importante entender la forma en que Google almacena 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. Los fragmentos se encriptan a nivel de almacenamiento a través de una clave de encriptado única. Por tanto, dos fragmentos diferentes nunca podrán tener la misma clave de encriptado, incluso si forman parte del mismo objeto de Google Cloud Storage, pertenecen al mismo cliente o se almacenan en la misma máquina.1 Si se actualiza un fragmento de datos, en lugar de reutilizar la clave anterior, se encripta con una nueva clave. Gracias a esta partición de datos, cada fragmento utiliza una clave diferente; por tanto, si una clave de encriptado de datos se ve comprometida, 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 integral de 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 correspondientes a 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. AES está muy extendido porque (1) el instituto nacional de estándares y tecnología de Estados Unidos (NIST) recomienda AES256 y AES128 para el uso de almacenamiento a largo plazo (a fecha de noviembre del 2015), y (2) AES a menudo forma parte de los requisitos de cumplimiento de los clientes.

Los datos almacenados en Google Cloud Storage se encriptan a nivel de almacenamiento mediante AES, en Modo Galois/Counter (GCM) en casi todos los casos. Este proceso se ha implementado en la biblioteca BoringSSL que mantenemos en Google. Esta biblioteca se creó a partir de OpenSSL y estaba destinada a uso interno, después de que se revelara un gran número de defectos en OpenSSL. 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 Platform, 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 del dispositivo de almacenamiento. Para ello, se utiliza como mínimo AES128 para los discos duros (HDD) y AES256 para las nuevas unidades de estado sólido (SSD), con una clave a nivel de dispositivo diferente a la clave utilizada para encriptar los datos a nivel de almacenamiento. Con el paso del tiempo, los dispositivos más antiguos acabarán desapareciendo y únicamente se utilizará el algoritmo AES256 para el encriptado a nivel del dispositivo.

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 sus archivos de forma independiente con una clave de encriptado de datos (DEK) propia, la cual se crea a partir de una clave almacenada en el KMS de Google y de una semilla por archivo generada de forma aleatoria 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.

¿Existen casos en los que los datos no están encriptados en reposo?

Google Cloud Platform encripta mediante uno o varios mecanismos el contenido en reposo almacenado por los usuarios, sin que estos tengan que realizar ninguna acción. No obstante, hay algunas excepciones:

  • Los registros de consola en serie de las máquinas virtuales de Google Compute Engine. Estamos trabajando en una solución para remediarlo.
  • Los volcados de memoria escritos en las unidades locales cuando se produce un error inesperado en un proceso. Estamos trabajando en una solución para remediarlo.
  • Los registros de depuración escritos en el disco local. Estamos trabajando en una solución para remediarlo.
  • Los archivos temporales utilizados por los sistemas de almacenamiento. Estamos trabajando en una solución para remediarlo.
  • Algunos registros que pueden incluir contenido y metadatos del cliente. Tenemos previsto buscar una solución a este problema.

En cualquier caso, estos datos siguen gozando de la amplia protección que les brinda el resto de la infraestructura de seguridad de Google y, en casi todos los casos, también están protegidos por el encriptado a nivel de almacenamiento.

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 contar con 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 Platform tiene una o más KEK. Estas KEK se almacenan de forma centralizada en el servicio de gestión de claves (KMS) de Google, un repositorio creado exclusivamente 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 supervisar y controlar el acceso a los datos desde un punto central.

Para cada cliente de Google Cloud Platform, los recursos que no son compartidos2 se dividen en fragmentos de datos y se encriptan con claves distintas a las que utilizan 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 texto sin formato. A continuación, el servicio usa la DEK para desencriptar el fragmento de datos convirtiéndolo en texto sin formato y así 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 se genera dentro de los servicios de almacenamiento. Por motivos de coherencia, todas las KEK se generan 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 AES256.4 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 CPU más modernas).

Los datos almacenados en Google Cloud Platform están encriptados 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 Google Compute Engine se encriptan mediante AES256. Las DEK se encapsulan con KEKs mediante AES256 o AES128, en función del servicio de Google Cloud Platform. 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. Google 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.

Las listas de control de acceso (LCA) del KMS administran el uso de las KEK para cada clave, cada una de las cuales tiene su propia política. 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 con 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 Platform 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 acceso al fragmento de datos en función de un identificador de tarea y mediante el ID de dicho fragmento. Acto seguido, el KMS verifica que el sistema de almacenamiento está autorizado tanto para usar la KEK asociada con el servicio como para desencapsular dicha DEK.
  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 para 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 de KMS, la cual se encarga de encapsular todas las KEK en el 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. Root KMS almacena muchas menos claves: doce, aproximadamente. Para ofrecer mayor seguridad, Root KMS no se ejecuta en máquinas de producción general, sino que se ejecuta únicamente en máquinas especializadas en 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 en 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 su objetivo es reemplazar a 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 debidamente protegidas.

Para abordar una situación en la que todas las instancias del distribuidor de claves maestras de KMS se reinician 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.

Resumen

  • Los datos se fragmentan y se encriptan con DEKs.
  • Las DEK están encriptadas 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 de KMS están encapsuladas con la clave maestra de KMS, que se almacena en Root KMS.
  • Root KMS es mucho más pequeño que KMS y solo se ejecuta en máquinas especializadas en cada centro de datos.
    • Las claves de Root KMS están encapsuladas 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 de 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.
    • Si todas las instancias del distribuidor se desactivaran (cierre total), se almacenaría una clave maestra en un hardware seguro (diferente), en cajas fuertes (físicas) de ubicaciones limitadas 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. Los servicios de gestión de claves de Google dependen de estas características.

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

Root KMS se ejecuta en varias máquinas especializadas en operaciones de seguridad en cada centro de datos. 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 denomina Tink5 e implementa algoritmos criptográficos mediante BoringSSL.6 Todos los desarrolladores de Google pueden utilizar Tink. Dado que esta biblioteca común es ampliamente accesible, solo se necesita un pequeño equipo de criptógrafos para implementar y mantener de forma adecuada este código estrictamente controlado y revisado. De este modo, no es necesario que cada equipo de Google "desarrolle" 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 compatibles7
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 Platform

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

  Servicio de Google Cloud Platform Granularidad del encriptado de datos del cliente8 (tamaño de los datos encriptados con una sola DEK)
Almacenamiento Cloud Bigtable Por fragmento de datos (varios por tabla)
Cloud Datastore Por fragmento de datos9
Cloud Spanner Por fragmento de datos (varios por tabla)
Cloud SQL
  • Segunda generación: por instancia, como en Google Compute Engine (cada instancia podría contener varias bases de datos)
  • Primera generación: por instancia
Cloud Storage Por fragmento de datos (normalmente 256 KB‑8 MB)
Recursos informáticos App Engine10 Por fragmento de datos9
Cloud Functions11 Por fragmento de datos9
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
Kubernetes Engine Varios por disco, para discos persistentes
Container Registry Almacenados en Google Cloud Storage, por fragmento de datos
Big Data BigQuery Varios por conjunto de datos
Cloud Dataflow Almacenados en Google Cloud Storage, por fragmento de datos
Cloud Datalab Almacenados en Cloud Bigtable, por archivo de bloc de notas
Cloud Dataproc Almacenados en Google Cloud Storage, por fragmento de datos
Cloud Pub/Sub Por una hora, para un máximo de un millón de mensajes12

Otras opciones de encriptado para los clientes de Cloud

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

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

  • Ser los propietarios finales de sus datos, capaces de controlar el acceso y el uso de los mismos al máximo nivel de granularidad, con el objetivo de garantizar 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 in situ 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 Platform mediante la función de claves de encriptado proporcionadas por el cliente. Esta función está disponible en Google Cloud Storage y en Google Compute Engine para el encriptado en la capa de almacenamiento.

Los clientes también pueden gestionar sus propias claves de encriptado en Google Cloud Platform a través de Google Cloud KMS. 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 nuestra investigación en el campo del encriptado para que todos los miembros del sector, incluido el público en general, puedan beneficiarse de nuestros conocimientos. En el 2014, por ejemplo, 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 con 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 al público.
  • Criptografía con preservación del formato y del orden: permite realizar algunas operaciones de comparación y clasificación con 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 Platform

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

Cumplimiento de Google Cloud Platform

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

Seguridad de G Suite

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

Notas a pie de página

1 Los fragmentos de datos de Cloud Datastore, App Engine y Cloud Pub/Sub pueden contener datos de dos 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 Google Compute Engine. Evidentemente, varios clientes se remiten a una sola copia encriptada por una única DEK.
3 Los datos almacenados en Cloud Datastore, App Engine y Cloud Pub/Sub son una excepción, ya que en estos servicios se pueden encriptar los datos de más de un cliente con la misma DEK. Consulta la sección sobre la granularidad del encriptado de datos por servicio.
4 Cabe señalar que, hace varios años, era el algoritmo AES128 y que 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 OpenSSL también sigue usándose en algunos lugares de Google Cloud Storage.
7 En la biblioteca hay otros protocolos criptográficos que fueron compatibles en su momento, pero en esta lista se cubren los principales usos en Google Cloud Platform.
8 Se refiere a la granularidad del encriptado para el 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.
9 No es exclusivo de un solo cliente.
10 Incluye el código y la configuración de la aplicación. En función de las configuraciones del cliente, los datos utilizados en App Engine se almacenan en Cloud Datastore, Cloud SQL o Cloud Storage.
11 Incluye el código de las funciones, los ajustes y los datos de eventos. Los datos de eventos se almacenan en Cloud Pub/Sub.
12 Cloud Pub/Sub rota la DEK utilizada para encriptar mensajes cada hora (o incluso más a menudo, en el caso de que se encripte un millón de mensajes). No es exclusiva de un solo cliente.
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...