Encriptación en reposo en Google Cloud Platform

El contenido de este artículo corresponde a abril de 2017 y representa el statu quo en el momento de su redacción. Es posible que las políticas y los sistemas de seguridad de Google Cloud Platform cambien, ya que mejoramos la protección de nuestros clientes de forma continua.

Botón para reproducir

Encriptación en reposo de Google Cloud

Resumen a nivel del director de sistemas de información

  • Google usa varias capas de encriptación para proteger los datos de los clientes que se encuentran en reposo en los productos de Google Cloud Platform.
  • Google Cloud Platform encripta el contenido de los clientes almacenado en reposo, sin que los clientes deban realizar ninguna acción, mediante uno o más mecanismos de encriptación. Existen algunas modificaciones menores que puedes encontrar en este documento.
  • Los datos para almacenar se dividen en fragmentos que se encriptan individualmente con una clave única. Estas claves de encriptación se almacenan con los datos, encriptadas (o “unidas”) con claves de encriptación de claves que se almacenan y se usan exclusivamente dentro del servicio central Key Management Service de Google. Este servicio es redundante y está distribuido en todo el mundo.
  • Los datos almacenados en Google Cloud Platform se encriptan en el nivel de almacenamiento con AES256 o AES128.
  • Google usa Tink, una biblioteca criptográfica común, para implementar la encriptación de manera coherente en casi todos los productos de Google Cloud Platform. Dado que esta biblioteca común es de acceso fácil, solo se necesita un equipo pequeño de criptógrafos para implementar y mantener este código estrictamente controlado y revisado.

Introducción

Para muchos usuarios y empresas, la seguridad es un factor decisivo en la elección de un proveedor de servicios de nube pública. En Google, la seguridad es lo más importante. Nos tomamos en serio la seguridad y la privacidad, y trabajamos sin descanso para proteger tus datos, ya sea que estén en tránsito en Internet, transfiriéndose entre nuestros centros de datos o almacenados en nuestros servidores.

Una de las herramientas centrales de nuestra estrategia de seguridad integral es la encriptación en tránsito y en reposo, que garantiza que solo las funciones autorizadas y los servicios con acceso auditado a las claves de encriptación puedan acceder a los datos. En este documento, se describe el enfoque de Google para la encriptación en reposo en Google Cloud Platform y cómo Google la usa a fin de proteger mejor tu información.

Este documento está dirigido a los equipos de operaciones de seguridad y CISO que actualmente usan o piensan usar Google Cloud Platform. Con la excepción de la introducción, en este documento se da por hecho que tienes conocimientos básicos sobre la encriptación y las primitivas criptográficas.

¿Qué es la encriptación?

La encriptación es un proceso que recibe datos legibles como entrada (a menudo llamados "texto sin formato") y los transforma en una salida (a menudo llamada "texto cifrado") que revela poco o nada acerca del texto sin formato. El algoritmo de encriptación que se usa es público, como el Estándar de encriptación avanzada (AES), pero la ejecución depende de una clave secreta. Para desencriptar el texto cifrado y devolverlo a su forma original, es necesario usar la clave. En Google, el uso de la encriptación para proteger la confidencialidad de los datos suele combinarse con la protección de la integridad; un usuario con acceso al texto cifrado no puede leerlo ni modificarlo sin conocer la clave. Para obtener más información sobre la criptografía, te recomendamos consultar Introduction to Modern Cryptography.

En este informe, nos enfocamos en la encriptación en reposo, que se usa para proteger los datos cuando están almacenados en un disco (incluidas las unidades de estado sólido) o en soportes para copias de seguridad.

¿Por qué la encriptación ayuda a proteger los datos de los clientes?

La encriptación es uno de los elementos que integran una estrategia de seguridad más amplia. La encriptación agrega una capa de defensa en profundidad para proteger los datos, pues garantiza que, si los datos caen en las manos de un atacante por accidente, este no pueda acceder a ellos, salvo que también cuente con las claves de encriptación correspondientes. Incluso si un atacante obtiene los dispositivos de almacenamiento que contienen tus datos, no podrá leerlos ni desencriptarlos.

La encriptación en reposo reduce la superficie de ataque, ya que, en la práctica, hace inútil cualquier ataque contra las capas inferiores de la pila de hardware y software. Incluso si estas capas inferiores se ven vulneradas (por ejemplo, si un atacante obtiene acceso a los dispositivos), los datos almacenados allí no quedarán expuestos si se implementó una encriptación adecuada. La encriptación también actúa como un "cuello de botella", ya que las claves correspondientes se administran en un único punto central, en el que se controla el acceso de manera auditable.

La encriptación proporciona un mecanismo importante que le permite a Google garantizar la privacidad de los datos de los clientes: los sistemas pueden manipular los datos (p. ej., para la generación de copias de seguridad o para actividades de mantenimiento de la insfraestructura por parte de los ingenieros) sin que se les otorgue acceso al contenido.

¿Qué entendemos por “datos de clientes”?

Según se define en las Condiciones del Servicio de Google Cloud Platform, los datos de los clientes son el contenido que Google recibe de un cliente de Google Cloud Platform (o por instrucción de él), de manera directa o indirecta, mediante los servicios de Google Cloud Platform que se usan con su cuenta. Los datos de los clientes pueden subdividirse en el contenido y los metadatos.

El contenido de los clientes son los datos que los clientes de Google Cloud Platform generan o proporcionan a Google, como los datos almacenados en Google Cloud Storage, las instantáneas de discos que usa Google Compute Engine y las políticas de Cloud IAM. Este informe se enfoca en la encriptación en reposo del contenido de los clientes.

Los metadatos de los clientes son el resto de los datos de los clientes. Esta categoría abarca todo lo que no se puede clasificar como contenido de los clientes. Esto podría incluir marcas de tiempo, direcciones IP y números de proyectos generados automáticamente, como también el tamaño en bytes de un objeto de Google Cloud Storage o el tipo de máquina en Google Compute Engine. Los metadatos se protegen en un nivel razonable que permita mantener las operaciones y el rendimiento.

Encriptación predeterminada de Google

Encriptación de datos en reposo

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.

Gráfico de las capas de encriptación

Figura 1: En Google Cloud Platform, usamos varias capas de encriptación para proteger los datos almacenados. Se aplica la encriptación de sistemas de archivos distribuidos o la encriptación de almacenamiento de archivos y bases de datos a casi todos los archivos. Además, la encriptación de dispositivos de almacenamiento se aplica a casi todos los archivos.

Encriptación en la capa del sistema de almacenamiento

Para entender cómo funciona la encriptación de Google Cloud Storage de manera específica, es importante comprender la forma en la que Google almacena los datos de los clientes. Los datos se dividen en fragmentos de subarchivos para almacenar, y cada uno puede tener varios GB de tamaño. Cada fragmento se encripta en el nivel de almacenamiento con una clave de encriptación individual, es decir, no habrán dos fragmentos con la misma clave de encriptación, incluso si son parte del mismo objeto de Google Cloud Storage, pertenecen al mismo cliente o están almacenados en la misma máquina1. Si un fragmento de datos se actualiza, se encripta con una clave nueva en lugar de reutilizar la clave existente. El uso de distintas claves para cada partición de los datos significa que el "área afectada" en caso de que se vulnere una clave de encriptación se limita solo al fragmento de datos correspondiente.

Google encripta los datos antes de escribirlos en los discos. La encriptación es inherente a todos los sistemas de almacenamiento de Google; no es un proceso adicional que se realice posteriormente.

Cada fragmento de datos tiene un identificador único. Las listas de control de acceso (LCA) garantizan que solo los servicios de Google que actúen con funciones autorizadas reciban acceso a cada fragmento para desencriptarlo en momentos específicos. De esta manera, se impide que alguien acceda a los datos sin autorización, lo cual refuerza la seguridad y la privacidad de los datos.

Cada fragmento se distribuye entre los sistemas de almacenamiento de Google y se replica en su forma encriptada para las copias de seguridad y la recuperación ante desastres. Si un usuario malintencionado quisiera acceder a los datos de los clientes, necesitaría conocer y obtener (1) todos los fragmentos de almacenamiento correspondientes a los datos que le interesan y (2) las claves de encriptación de esos fragmentos.

Diagrama de los datos que se almacenan en fragmentos encriptados

Figura 2: En Google, los datos se dividen en fragmentos encriptados para su almacenamiento.

Google usa el algoritmo del Estándar de encriptación avanzada (AES) para encriptar datos en reposo. AES se usa ampliamente, ya que (1) el Instituto Nacional de Estándares y Tecnología (NIST) de los EE.UU. recomienda usar AES256 y AES128 para el almacenamiento a largo plazo (desde noviembre de 2015) y (2) AES suele incluirse como parte de los requisitos de cumplimiento de los clientes.

Los datos almacenados en Google Cloud Storage se encriptan en el nivel de almacenamiento con AES, en modo Galois/contador (GCM) en la mayoría de los casos. Esto se implementa en la biblioteca BoringSSL que Google mantiene. Esta biblioteca se desprendió de OpenSSL para uso interno, después de que se descubrieran numerosas fallas en OpenSSL. En ciertos casos, AES se usa en el modo de cadena de bloques de cifrado (CBC) con un código de autenticación de mensajes con hash (HMAC) para su autenticación. En algunos archivos repetidos, AES se usa en modo contador (CTR) con HMAC.Para obtener más información sobre los algoritmos, consulta la sección correspondiente de este documento. En otros productos de Google Cloud Platform, AES se usa en diversos modos.

Encriptación en la capa de dispositivos de almacenamiento

Además de la encriptación en el nivel del sistema de almacenamiento que se describió antes, en la mayoría de los casos los datos también se encriptan en el nivel de los dispositivos de almacenamiento con al menos AES128 para discos duros (HDD) y AES256 para unidades de estado sólido (SSD) nuevas, y una clave de nivel del dispositivo independiente (diferente de la clave que se usa para encriptar los datos en el nivel de almacenamiento). A medida que se reemplacen los dispositivos más antiguos, solo se usará AES256 para la encriptación en el nivel de los dispositivos.

Encriptación de copias de seguridad

El sistema de copias de seguridad de Google 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 sin formato.

Además, el sistema de copias de seguridad encripta cada archivo de las copias de seguridad de manera independiente, con su propia clave de encriptación de datos (DEK), derivada de una clave almacenada en el servicio Key Management Service (KMS) de Google, junto con 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 servicio KMS de Google. Para obtener información adicional sobre la administración de claves, consulta la sección correspondiente de este documento.

¿Hay casos en los que los datos no se encripten en reposo?

Google Cloud Platform encripta el contenido de los clientes almacenado en reposo, sin que los clientes deban realizar ninguna acción, mediante uno o más mecanismos de encriptación, con las siguientes excepciones:

  • Registros de consola en serie de las máquinas virtuales de Google Compute Engine; estamos trabajando para implementar una solución
  • Volcados de memoria escritos en discos locales cuando un proceso falla de manera inesperada; estamos trabajando para implementar una solución
  • Registros de depuración escritos en discos locales; estamos trabajando para implementar una solución
  • Archivos temporales usados por sistemas de almacenamiento; estamos trabajando para implementar una solución
  • Algunos registros que pueden incluir contenido y metadatos de clientes; tenemos pensado solucionar esto

De todas maneras, estos datos cuentan con un alto nivel de protección gracias al resto de la infraestructura de seguridad de Google y, en casi todos los casos, al uso de encriptación en el nivel de almacenamiento.

Administración de claves

Claves de encriptación de datos, claves de encriptación de claves y Key Management Service de Google

La clave que se usa para encriptar los datos de un fragmento se denomina clave de encriptación de datos (DEK). Debido a la gran cantidad de claves que se usan en Google y a la necesidad de contar con baja latencia y alta disponibilidad, estas claves se almacenan cerca de los datos que encriptan. Las DEK se encriptan (o “unen”) con una clave de encriptación de claves (KEK). Cada servicio de Google Cloud Platform cuenta con una o más KEK. Estas se almacenan de manera centralizada en el servicio Key Management Service (KMS) de Google, un repositorio creado específicamente para almacenar claves. Tener menos KEK que DEK y usar un servicio central de administración de claves facilita la administración del almacenamiento y la encriptación de datos a la escala de Google, y nos permite realizar un seguimiento del acceso a los datos y controlarlo desde un punto central.

Para cada cliente de Google Cloud Platform, todos los recursos2 no compartidos se dividen en fragmentos y se encriptan con claves independientes de las que se usaron para otros clientes3. Estas DEK incluso son independientes de las que protegen otras partes de los mismos datos pertenecientes al mismo cliente.

El sistema de almacenamiento genera las DEK con la biblioteca criptográfica común de Google. Luego, se envían a KMS 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 la DEK unida y la pasa al servicio KMS, que verifica que este servicio esté autorizado para usar esa KEK. De ser así, separa la DEK y la muestra en texto sin formato al servicio. Luego, el servicio usa la DEK para desencriptar el fragmento de datos, transformarlo a texto sin formato y verificar su integridad.

La mayoría de las KEK para encriptar fragmentos de datos se generan dentro de KMS, 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 aleatorios (RNG) que compiló Google. Este RNG se basa en el generador CTR-DRBG de las recomendaciones 800-90Ar1 del NIST y genera una KEK4 de tipo AES256. Este RNG obtiene su semilla del RNG del kernel de Linux que, a su vez, obtiene la suya de varias fuentes de entropía independientes. Estas incluyen eventos de entropía del entorno del centro de datos, como mediciones detalladas de las búsquedas en discos y tiempos de llegada entre paquetes, y la instrucción RDRAND de Intel en el hardware compatible (CPU Ivy Bridge o más recientes).

Los datos almacenados en Google Cloud Platform se encriptan con DEK mediante AES256 o AES128, como se describió antes. Todos los datos nuevos encriptados en discos persistentes en Google Compute Engine se encriptan con AES256. Las DEK se unen con KEK mediante AES256 o AES128, según el servicio de Google Cloud Platform. Actualmente, estamos trabajando para actualizar todas las KEK de los servicios de Cloud a AES256.

El servicio KMS de Google se creó con el propósito exclusivo de administrar las KEK. Se creó teniendo en mente la seguridad. El diseño de KMS no permite exportar las KEK; toda encriptación y desencriptación con estas claves se debe realizar dentro del servicio. Esto ayuda a evitar filtraciones y usos inadecuados, y permite que KMS genere un rastro de auditoría cuando se usan las claves.

KMS puede rotar las KEK automáticamente 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 significa que los datos están protegidos con un conjunto de claves: una clave activa para la encriptación y un conjunto de claves históricas para la desencriptación, cuya cantidad depende del programa de rotación de claves. El programa de rotación real de una KEK varía según el servicio, pero el período de rotación estándar es de 90 días. En particular, Google Cloud Storage rota sus KEK cada 90 días y puede almacenar hasta 20 versiones, por lo que necesita volver a encriptar los datos al menos una vez cada 5 años (aunque, en la práctica, la reencriptación de los datos es mucho más frecuente). Las claves que conserva KMS tienen copias de seguridad para la recuperación ante desastres y se pueden recuperar de manera indefinida.

El uso de las KEK se administra con listas de control de acceso (LCA) en KMS 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 alguien usa una clave, se autentica y se registra. Todos los accesos a los datos por parte de personas son auditables, conforme a las políticas de privacidad y seguridad generales de Google.

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 solicitar los datos que necesita.
  2. El sistema de almacenamiento identifica los fragmentos que contienen esos datos (los ID de fragmento) y su ubicación.
  3. Para cada fragmento, el sistema de almacenamiento extrae la DEK unida y almacenada con ese fragmento (en algunos casos, el servicio realiza esto) y la envía a KMS para separarla.
  4. 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. Luego, KMS verifica que el sistema de almacenamiento tenga autorización para usar la KEK asociada al servicio y separar la DEK específica.
  5. KMS 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. Esta es la operación más común.
    • 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, como las unidades SSD locales, en las que el dispositivo administra y protege la DEK de nivel del dispositivo.

Diagrama de la desencriptación de los fragmentos de datos

Figura 3: Para desencriptar un fragmento de datos, el servicio de almacenamiento llama al servicio Key Management Service (KMS) de Google a fin de recuperar la clave de encriptación de datos (DEK) separada que le corresponde a ese fragmento de datos.

Raíz de confianza y jerarquía de la clave de encriptación

El servicio KMS de Google está protegido por una clave raíz llamada clave maestra de KMS, que une todas las KEK de KMS. Esta clave maestra es de tipo AES2564 y se almacena en otro servicio de administración de claves, llamado Root KMS. Este servicio almacena una cantidad mucho menor de claves (aproximadamente una docena). Para ofrecer seguridad adicional, Root KMS no se ejecuta en máquinas de producción general, sino solo en máquinas dedicadas 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 es de tipo AES2564 y se almacena en una infraestructura entre pares, el distribuidor de claves maestras de Root KMS, que repite estas claves de manera global. El distribuidor de claves maestras de Root KMS solo conserva las claves en la RAM de las mismas máquinas dedicadas que Root KMS y usa registros para verificar su uso adecuado. Se ejecuta una instancia del distribuidor de claves maestras de Root KMS en cada instancia de Root KMS. Este distribuidor todavía está en etapa de incorporación para reemplazar un sistema anterior que funcionaba de manera similar, pero no usaba almacenamiento entre pares.

Cuando se inicia una instancia nueva del distribuidor de claves maestras de Root KMS, se configura con una lista de nombres de host que ya se ejecutan en instancias del distribuidor. Luego, las instancias del distribuidor pueden obtener la clave maestra de Root KMS de otras instancias en ejecución. Aparte de los mecanismos de recuperación ante desastres que se describen a continuación, la clave maestra de Root KMS solo existe 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 de Root KMS se reinician de manera simultánea, también existe una copia de seguridad de la clave maestra de Root KMS en dispositivos de hardware seguros que se almacenan en cajas fuertes físicas ubicadas en áreas altamente protegidas de dos instalaciones de Google independientes en distintas partes del mundo. Esta copia de seguridad se necesitaría solo si todas las instancias del distribuidor fallaran a la vez, por ejemplo, en un reinicio mundial. Menos de 20 empleados de Google tienen acceso a estas cajas fuertes.

Diagrama de la jerarquía de encriptación de Google

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

En síntesis:

  • Los datos se fragmentan y se encriptan con DEK.
  • Las DEK se encriptan con KEK.
  • Las KEK se almacenan en KMS.
  • KMS se ejecuta en varias máquinas en centros de datos ubicados en todo el mundo.
    • Las claves de KMS se unen con la clave maestra de KMS, que se almacena en Root KMS.
  • Root KMS es mucho más pequeño que KMS y se ejecuta solo en máquinas dedicadas de cada centro de datos.
    • Las claves de Root KMS se unen 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 de manera simultánea en la RAM de máquinas dedicadas ubicadas en distintas partes del mundo, cada una de las cuales obtiene su material de claves de otras instancias en ejecución.
    • En el supuesto de que todas las instancias del distribuidor fallaran (interrupción total), existe una clave maestra almacenada en (distintos) dispositivos guardados en cajas fuertes (físicas) dentro de áreas seguras en las instalaciones de Google.
    • Este distribuidor está en etapa de incorporación para reemplazar un sistema anterior que funcionaba de manera similar, pero que no usaba almacenamiento entre pares.

Replicación y disponibilidad global

La disponibilidad alta, la latencia baja y el acceso global a las claves son fundamentales en todos los niveles. Estas características son necesarias para usar los servicios de administración de claves en Google.

Por este motivo, 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 de la flota de producción de Google, y las instancias de KMS se ejecutan de manera global para apoyar las operaciones de Google Cloud Platform. Como resultado de esto, todas las operaciones de claves tienen latencia muy baja.

Root KMS se ejecuta en varias máquinas que se usan exclusivamente para las 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 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 intervalos de tiempo determinados, cada instancia del distribuidor selecciona otra instancia al azar para comparar sus claves y concilia todas las diferencias entre sus versiones. Con este modelo, no existe un nodo central del que dependa toda la infraestructura de Google. Esto permite que se mantenga y proteja el material de las claves con una alta disponibilidad.

Biblioteca criptográfica común de Google

La biblioteca criptográfica común de Google es Tink5, que implementa algoritmos criptográficos con BoringSSL6. Tink está disponible para todos los desarrolladores de Google. Dado que esta biblioteca común es de fácil acceso, solo se necesita un equipo pequeño de criptógrafos para implementar este código estrictamente revisado y controlado: no es necesario que cada equipo de Google implemente su propia criptografía. Un equipo de seguridad especial de Google es responsable de mantener esta biblioteca criptográfica común para 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.

A la fecha de publicación de este documento, Google usa los siguientes algoritmos de encriptación en reposo para las DEK y KEK. Están sujetos a cambios a medida que seguimos mejorando nuestras capacidades y nuestra seguridad.

Primitiva criptográfica Protocolos preferidos Otros protocolos compatibles7
Encriptación simétrica
  • 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 protocolos AES-CBC y AES-CTR mencionados para la autenticación)
  • HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

Nivel de detalle de la encriptación en cada producto de Google Cloud Platform

Cada servicio de Google Cloud Platform divide los datos en un nivel de detalle diferente para la encriptación.

  Servicio de Google Cloud Platform Nivel de detalle de la encriptación de datos de clientes8 (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 (por lo general, de 256 KB a 8 MB)
Procesamiento App Engine10 Por fragmento de datos9
Cloud Functions11 Por fragmento de datos9
Compute Engine
  • Varios por disco
  • Por grupo de instantáneas, con rangos de instantáneas individuales derivados de la clave maestra del grupo de instantáneas
  • Por imagen
Kubernetes Engine Varios por disco, para discos persistentes
Container Registry Almacenados en Google Cloud Storage, por fragmento de datos
Macrodatos 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 notebook
Cloud Dataproc Almacenados en Google Cloud Storage, por fragmento de datos
Cloud Pub/Sub Por una hora, para un máximo de 1,000,000 de mensajes12

Opciones adicionales de encriptación para clientes de Cloud

Además de proporcionar encriptación en la configuración predeterminada de Google Cloud Platform, estamos trabajando para ofrecer a los clientes más opciones de encriptación y administración de claves, a fin de que obtengan un mayor control.

Queremos que los clientes de Google Cloud Platform logren lo siguiente:

  • Seguir siendo los principales responsables de sus datos y poder controlar el acceso a ellos y su uso con el mayor nivel de detalle a fin de garantizar la seguridad y la privacidad de los datos.
  • Administrar la encriptación de sus datos alojados en la nube de la misma manera que lo hacen en sus instalaciones actualmente o, idealmente, de una manera mejor.
  • Tener una raíz de confianza comprobable y auditable para sus recursos.
  • Poder segregar y separar aún más sus datos, más allá de lo que permite el uso de LCA.

Los clientes pueden usar claves de encriptación existentes que administran con Google Cloud Platform, con la característica "Claves de encriptación proporcionadas por el cliente". Esta función está disponible en Google Cloud Storage y en Google Compute Engine para la encriptación de capas de almacenamiento.

Además, los clientes pueden administrar sus propias claves de encriptación en Google Cloud Platform con Google Cloud Key Management Service (Cloud KMS). Este producto permite que el cliente administre la encriptación de las capas de la aplicación.

Innovación y estudios de criptografía

Para mantenernos al día con la evolución de la encriptación, Google tiene un equipo de ingenieros de seguridad de primer nivel con una tecnología de encriptación en constante mejora, desarrollo y seguimiento. Nuestros ingenieros participan en el proceso de estandarización y en el mantenimiento del software de encriptación usado ampliamente. A menudo, publicamos nuestras investigaciones en el campo de la encriptación para que todos los miembros de la industria, incluido el público general, puedan beneficiarse de nuestro conocimiento. Por ejemplo, en 2014 revelamos una vulnerabilidad importante en la encriptación de SSL 3.0 (conocida como POODLE) y en 2015 identificamos una vulnerabilidad de alto riesgo en OpenSSL.

Google pretende seguir siendo el líder de la industria en encriptación para servicios en la nube. En términos de investigación, implementación y desarrollo de nuevas técnicas criptográficas, tenemos equipos que trabajan en lo siguiente:

  • Criptografía parcialmente homomórfica, que permite realizar ciertas operaciones con los datos mientras se encriptan, de manera que la nube nunca vea los datos en texto sin formato, ni siquiera en la memoria. Un caso en el que se usa esta tecnología es en nuestro cliente encriptado de BigQuery experimental, que está disponible para todos.
  • Criptografía con preservación del orden y el formato, que permite realizar ciertas operaciones de comparación y clasificación de datos incluso cuando están encriptados.
  • Criptografía poscuántica, que nos permite reemplazar primitivas criptográficas vulnerables a los ataques cuánticos eficientes con candidatas poscuánticas que supuestamente son más sólidas contra estos ataques. El enfoque principal de esto es la investigación y el prototipado de criptografía de claves públicas basadas en cuadrículas, incluidas las recomendaciones del NIST sobre los algoritmos poscuánticos. Actualmente, se cree que la criptografía basada en cuadrículas es una de las técnicas de encriptación con más probabilidades de usarse en un mundo poscuántico, pese a que recién estamos comenzando en la búsqueda de los mejores algoritmos, parámetros concretos y criptoanálisis para aplicar este tipo de criptografía. Si bien la encriptación de claves simétricas y los MAC son vulnerables a algoritmos cuánticos conocidos, aún se pueden actualizar a bits de seguridad similares en un mundo poscuántico mediante la duplicación de los tamaños de las claves.

Referencias adicionales

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 las certificaciones de cumplimiento de Google Cloud Platform, consulta la sección Cumplimiento del sitio web de Google Cloud Platform, que incluye el informe público de la auditoría SOC 3 de Google.

Seguridad de G Suite

Para obtener información sobre la administración de claves y la encriptación en G Suite, consulta el informe de encriptación de G Suite. Ese informe abarca gran parte del contenido incluido aquí, pero se enfoca solamente en G Suite. En todas las soluciones de G Suite, trabajamos para mantener protegidos los datos de los clientes y ser lo más transparentes posible sobre nuestros métodos de protección. Para obtener más información sobre la seguridad general de G Suite, consulta el informe Seguridad y cumplimiento de G Suite.

Pies de página

1 Los fragmentos de datos de Cloud Datastore, App Engine y Cloud Pub/Sub pueden contener los datos de dos clientes. Consulta la sección sobre el nivel de detalle de la encriptación 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 de Google Compute Engine. Por supuesto, varios clientes consultan una misma copia que se encripta con una misma DEK.
3 Excepto los datos almacenados en Cloud Datastore, App Engine, y Cloud Pub/Sub, en los que se puede encriptar los datos de más de un cliente con el mismo DEK. Consulta la sección sobre el nivel de detalle de la encriptación de datos por servicio.
4 Ten en cuenta que antes solía usarse el estándar AES128 y que algunas de estas claves siguen activas para desencriptar datos.
5 Google también usa dos bibliotecas: Keymaster y CrunchyCrypt. Keymaster comparte un código criptográfico más actual en común con Tink, pero usa una implementación diferente del control de versiones de claves y admite una variedad más amplia de algoritmos antiguos. CrunchyCrypt está en proceso de fusionarse con Tink.
6 Algunas partes de Google Cloud Storage también usan OpenSSL.
7 En la biblioteca existen otros protocolos criptográficos que se admitieron anteriormente, pero esta lista abarca los usos principales en Google Cloud Platform.
8 Se refiere al nivel de detalle de la encriptación para el contenido de los clientes. Esto no incluye los metadatos de clientes, como los nombres de recursos. En algunos servicios, todos los metadatos se encriptan con una misma DEK.
9 No es único para un solo cliente.
10 Incluye el código y la configuración de la aplicación. Los datos usados en App Engine se almacenan en Cloud Datastore, Cloud SQL o Cloud Storage, dependiendo de las configuraciones de los clientes.
11 Incluye el código de la función, la configuración y los datos de eventos. Los datos de eventos se almacenan en Cloud Pub/Sub.
12 Cloud Pub/Sub rota las DEK que se usan para encriptar mensajes cada hora, o antes si se encriptan 1,000,000 de mensajes. No es único para un solo cliente.
¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…