Encriptado en tránsito en Google Cloud

En este tercer informe, hablaremos de la forma en que Google encripta los datos para protegerlos. También hemos publicado el artículo Encriptado en reposo en Google Cloud Platform y un informe sobre el sistema de encriptado de G Suite. Si te interesa obtener más información sobre el uso que damos al encriptado en Google, te recomendamos que los leas. En este informe en concreto, hablaremos sobre el encriptado en tránsito de las soluciones de Google Cloud, incluidas Google Cloud Platform y G Suite.

En Google, nos esforzamos por proteger los datos de los clientes de todos nuestros productos y por actuar con transparencia en todo momento.

El contenido incluido en este documento es correcto en diciembre 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 cambien a medida que mejoremos la protección de nuestros clientes.

Encriptado en tránsito de Google Cloud

Resumen para directores de información

  • Google cuenta con diversos sistemas de seguridad para preservar la autenticidad, la integridad y la privacidad de los datos en tránsito.
  • En Google se encriptan y autentican todos los datos en tránsito en una o más capas de la red cuando estos salen fuera de los límites físicos controlados por Google o en nombre de Google. Los datos en tránsito que se encuentren dentro de un límite físico controlado por Google o en su nombre suelen estar autenticados, pero no necesariamente encriptados.
  • En función del tipo de conexión establecida, Google aplica una serie de protecciones predeterminadas a los datos en tránsito. Por ejemplo, para proteger las comunicaciones entre los usuarios y el frontend de Google (GFE), se utiliza el protocolo TLS.
  • Los clientes de Google Cloud que tengan otros requisitos relacionados con el encriptado de datos a través de una red WAN pueden implementar otras soluciones para proteger los datos mientras se transfieren entre los usuarios y las aplicaciones, o entre máquinas virtuales. Por ejemplo: túneles IPsec, la API Gmail S/MIME, certificados SSL gestionados e Istio.
  • En Google estamos haciendo todo lo posible para encriptar los datos en tránsito de todos los usuarios, independientemente de dónde se encuentren. Para ello, colaboramos estrechamente con los especialistas del sector. En concreto, tenemos en marcha varios proyectos de software libre para fomentar el encriptado de datos en tránsito y salvaguardarlos en Internet a gran escala, como la iniciativa de transparencia en los certificados, las API de Chrome y el protocolo SMTP seguro.
  • Google se propone seguir siendo el líder del sector en el encriptado de los datos en tránsito. Para ello, contamos con recursos dedicados a desarrollar y mejorar tecnologías de este tipo, y contamos con planes de innovación en áreas tales como la transparencia de claves y la criptografía poscuántica.

Introducción

A la hora de decantarse por un proveedor de nube pública, la seguridad suele ser un factor clave, algo que para Google es de suma importancia. Trabajamos sin descanso para que tus datos estén protegidos en todo momento, tanto cuando se transfieren por Internet como cuando circulan a lo largo y ancho de nuestra infraestructura o se almacenan en nuestros servidores.

Los cimientos de nuestra estrategia de seguridad son la autenticación, la integridad y el encriptado de los datos, independientemente de si están en reposo o en tránsito. En este informe, hablaremos del modelo de encriptado de datos en tránsito que utilizamos en Google Cloud.

Si te interesan más los datos en reposo, consulta el informe Encriptado en reposo en Google Cloud Platform. O bien, si prefieres hacerte una idea general de cómo funcionan nuestros sistemas de seguridad, puedes leer Resumen del diseño de la seguridad en infraestructuras de Google.

Audiencia: este documento está dirigido a los directores de seguridad de la información (o CISO) y a los equipos de operaciones de seguridad que estén utilizando o planteándose utilizar Google Cloud.

Requisitos previos: además de leer esta introducción, se presupone que el lector tiene conocimientos básicos sobre el encriptado y las primitivas criptográficas.

Autenticación, integridad y encriptado

Google cuenta con diversos sistemas de seguridad para preservar la autenticidad, la integridad y la privacidad de los datos en tránsito.

  • Autenticación: verificamos la fuente de datos (es decir, si procede de un sistema manual o automático) y el destino.
  • Integridad: nos aseguramos de que los datos llegan a su destino sin sufrir ningún cambio.
  • Encriptado: tus datos serán ininteligibles (y, por tanto, privados) durante toda la fase de tránsito. Al utilizar el encriptado, los datos legibles (texto sin formato) se transforman en ininteligibles (algoritmo de encriptado), con lo que nos aseguramos de que solo pueden acceder a ellos los usuarios que haya autorizado el propietario. Los algoritmos que utilizamos en el proceso de encriptado son públicos, pero la clave usada para desencriptar los algoritmos de cifrado, no. Para el encriptado de datos en tránsito solemos utilizar claves simétricas compartidas. Para ello, recurrimos a un proceso llamado "intercambio de claves asimétricas", como es el caso del protocolo Diffie-Hellman, que está basado en curvas elípticas. Si quieres obtener más información sobre el encriptado, te recomendamos que leas este libro a modo de introducción a la criptografía moderna.

Puedes recurrir al encriptado para proteger datos mientras están en estos tres estados:

  • En reposo: los datos se protegen frente a intrusiones en el sistema o a filtraciones externas, ya que se encriptan mientras están almacenados. El estándar que más se suele utilizar para encriptar datos de este tipo es el estándar de encriptado avanzado (AES, por sus siglas en inglés).
  • En tránsito: tiene lugar si se intercepta algún tipo de comunicación mientras se transfieren datos entre tu sitio web y el proveedor de servicios en la nube, o entre dos servicios. Para proteger dichos datos, se encriptan antes de que tenga lugar la transmisión. A continuación, se autentican los puntos de conexión y, por último, se verifican los datos cuando llegan a su destino. Por ejemplo, se utiliza el protocolo de seguridad en la capa de transporte (TLS) para preservar la seguridad de los datos mientras se transportan, y las extensiones seguras multipropósito de correo de Internet (S/MIME) sirven para proteger los correos electrónicos.
  • En uso: los datos se protegen mientras se utilizan en servidores para ejecutar cálculos. Un proceso de este tipo sería el encriptado homomórfico.

El encriptado debe entenderse como un elemento más de los que componen cualquier estrategia de seguridad más amplia. Al implementar este proceso en los datos en tránsito, es posible protegerlos frente a posibles atacantes en el momento en el que se establece y autentica una conexión. Gracias al encriptado, se consigue lo siguiente:

  • Evitar tener que depender de las capas inferiores de la red, que habitualmente suministran otras empresas.
  • Reducir la superficie de ataques potenciales.
  • Impedir que los atacantes puedan acceder a los datos, en caso de que se interceptaran las comunicaciones.

Para proteger los datos que circulan entre usuarios, dispositivos o procesos en entornos hostiles, te recomendamos poner en marcha las estrategias de autenticación, integridad y encriptado más adecuadas. En el resto de este documento te explicaremos en qué consiste nuestro sistema de encriptado de datos en tránsito y en qué casos se implementa.

Infraestructura de red de Google

Límites físicos de la red de Google

Cuando los datos en tránsito se transmiten fuera de la red controlada por nosotros o en nuestro nombre, ponemos en marcha distintos sistemas de protección. Cuando hablamos de "límites físicos", nos referimos a la frontera del espacio físico que conforma dicha red. En este espacio, sabemos con total seguridad que se están aplicando unas medidas de seguridad más que estrictas. El acceso físico a dichas ubicaciones está restringido o monitorizado de cerca. De hecho, el número de empleados de Google que tienen acceso a este hardware es bastante reducido. Por lo general, los datos en tránsito que circulan dentro de este espacio físico se autentican, pero no se encriptan de forma predeterminada. Tú eres quien decide las medidas de seguridad que quieres adoptar, en función de cuál sea tu modelo de protección contra amenazas.

Internet es una red de enorme magnitud, y no podemos fijar estos mismos controles en los enlaces de fibra óptica de nuestra WAN ni en ninguna otra ubicación que esté más allá de los confines de nuestra infraestructura física. Lo que sí hacemos es imponer medidas de seguridad adicionales fuera de nuestra zona física de confianza, como el encriptado de datos en tránsito.

¿Cómo se enruta el tráfico?

En la sección anterior hemos visto qué son los límites físicos de la red de Google y qué medidas de seguridad aplicamos a los datos que salen de sus fronteras. Para entender mejor en qué consiste nuestro sistema de encriptado de datos en tránsito, es necesario saber cómo se enruta el tráfico por Internet. En esta sección, descubrirás cómo se transfieren las solicitudes de los usuarios finales al servicio de Google Cloud o aplicación de cliente correspondiente, y cómo se enruta el tráfico entre servicios.

Un servicio de Google Cloud es un servicio modular en la nube que ofrecemos a nuestros clientes: soluciones informáticas, de almacenamiento de datos, de análisis de datos y de aprendizaje automático. Por ejemplo, tanto Google Cloud Storage como Gmail son servicios de Google Cloud. Las aplicaciones de clientes están alojadas en Google Cloud. Son aplicaciones que nuestros clientes pueden crear y desplegar mediante los servicios de Google Cloud. Las aplicaciones de clientes o soluciones de partners que estén alojadas en Google Cloud no se considerarán servicios de Google Cloud.1 Ejemplos de aplicaciones que sí son de cliente: aplicaciones creadas en Google App Engine o Google Kubernetes Engine, o máquinas virtuales creadas en Google Compute Engine.

En la figura 1 aparecen representados los cinco tipos de solicitudes de enrutamiento que trataremos a continuación, así como las interacciones entre los diversos componentes de red y las medidas de seguridad aplicadas a cada conexión.

Entre el usuario final (Internet) y un servicio de Google Cloud

Los servicios de Google Cloud aceptan solicitudes de todo el mundo mediante el sistema de frontend de Google (GFE), distribuido globalmente. GFE termina el tráfico de proxy HTTPS, TCP y TLS entrante, proporciona medidas de respuesta a los ataques DDoS, y enruta y equilibra la carga de tráfico a los propios servicios de Google Cloud. Hay puntos de presencia de GFE en todo el mundo, y las rutas se anuncian mediante unicast o anycast.

Los GFE dirigen el tráfico de proxy a los servicios de Google Cloud. Para ello, enrutan la solicitud del usuario por nuestra red troncal hasta un servicio de Google Cloud. Cuando los datos se transmiten fuera de los límites físicos controlados por nosotros o en nuestro nombre, esta conexión se autentica y encripta desde el GFE hasta el frontend del servicio de Google Cloud o de la aplicación del cliente. En la figura 1 se muestra esta interacción (conexión A).

Entre el usuario final (Internet) y una aplicación de cliente alojada en Google Cloud

El tráfico de Internet se puede enrutar a la aplicación de cliente alojada en Google Cloud de varias formas según la configuración, como se explica más adelante. En la figura 1 se muestra esta interacción (conexión B).

  • Usar un balanceador de carga externo de proxy TCP/SSL o HTTPS de Google Cloud: las aplicaciones de cliente alojadas en las máquinas virtuales de Google Compute Engine pueden usar el servicio del balanceador de carga de Google Cloud (GCLB) para terminar las conexiones TCP, TLS o HTTPS, así como para dirigir, enrutar y distribuir este tráfico a sus máquinas virtuales. Si el GCLB enruta el tráfico entre varios GFE, las conexiones se autentican y encriptan cuando el tráfico abandona la infraestructura física controlada por nosotros o en nuestro nombre, lo mismo que sucede cuando el GCLB enruta el tráfico entre un GFE y una máquina física que aloja una máquina virtual de un cliente. Con los balanceadores de carga HTTPS, las conexiones entre los usuarios finales y el GFE se encriptan y autentican con TLS o QUIC mediante certificados que proporcionan los clientes, mientras que, con los balanceadores de carga HTTP, las conexiones entre los usuarios finales y el GFE no se encriptan ni autentican. Con los balanceadores de carga SSL, en cambio, las conexiones entre los usuarios finales y el GFE se encriptan con TLS, del mismo modo que al usar certificados proporcionados por el usuario. Con los balanceadores de carga TCP, por último, no se aplica el encriptado entre el usuario final y el GFE, aunque la aplicación del cliente puede usar su propio encriptado entre el usuario final y las máquinas virtuales.
  • Usar una conexión directa a una máquina virtual mediante una IP externa o mediante la IP del balanceador de carga de red: al establecer la conexión mediante la IP externa de la máquina virtual, o mediante una IP con balanceo de carga de red, la conexión no pasa por el GFE ni se encripta de forma predeterminada, por lo que la seguridad queda en manos del usuario.
  • Usar la VPN de Cloud: las conexiones desde un host in situ a una máquina virtual de Google Cloud mediante una VPN se establecen desde o hacia el host in situ hasta la VPN in situ, de ahí a la VPN de Google y, en última instancia, a la máquina virtual de Google Cloud, pero sin pasar por el GFE. La conexión está protegida desde la VPN in situ hasta la VPN de Google con IPsec, mientras que, desde la VPN de Google hasta la máquina virtual de Google Cloud, se autentica y encripta cuando abandona la infraestructura física controlada por nosotros o en nuestro nombre.
  • Usar la interconexión dedicada de Cloud: en este caso, la conexión se establece directamente desde el host in situ, sin pasar por el GFE. Puesto que la conexión no se encripta de forma predeterminada, la seguridad queda en manos del usuario.

Entre máquinas virtuales

En el caso del enrutamiento entre máquinas virtuales en nuestra red troncal mediante direcciones IP privadas RFC 1918, puede ser necesario enrutar el tráfico fuera de los límites físicos controlados por Google o en nombre de Google. Estos son algunos ejemplos de enrutamiento entre máquinas virtuales:

  • Máquinas virtuales de Compute Engine que se envían solicitudes entre ellas.
  • Una máquina virtual de cliente que se conecta a una máquina virtual administrada por Google, como Cloud SQL.

Las conexiones entre máquinas virtuales se encriptan si abandonan la infraestructura física, y se autentican dentro de esta. El tráfico entre estas máquinas mediante direcciones IP públicas no se encripta de forma predeterminada, por lo que la seguridad queda en manos del usuario. En la figura 1 se muestra esta interacción (conexión C).

Entre una máquina virtual y un servicio de Google Cloud

Excepto en los casos en los que se está ejecutando un servicio de Google Cloud en una máquina virtual administrada por Google, como hemos visto anteriormente, si una máquina virtual enruta una solicitud a un servicio de Google Cloud. lo hace a un GFE. El GFE recibe la solicitud y la enruta del mismo modo que si fueran solicitudes de Internet: el tráfico de una máquina virtual a un servicio de Google Cloud se enruta mediante rutas privadas de Google a las mismas IP públicas para los GFE. Gracias al acceso privado de Google, las máquinas virtuales sin IP públicas pueden acceder a algunos servicios de Google Cloud y a las aplicaciones de cliente alojadas en Google App Engine. Ten en cuenta que, si una máquina virtual se conecta a una aplicación de cliente alojada en Google Compute Engine o Google Kubernetes Engine, ese tráfico se enruta igual que las solicitudes procedentes de Internet, es decir, a través de rutas externas. En la figura 1 se muestra esta interacción (conexión D). Las solicitudes desde una máquina virtual de Compute Engine a Google Cloud Storage o a una API de aprendizaje automático son ejemplos de este tipo de solicitud de enrutamiento.2 Los servicios de Google Cloud utilizan el protocolo TLS de forma predeterminada para proteger estas conexiones. Esta protección se aplica desde la máquina virtual hasta el GFE. La conexión se autentica desde el GFE hasta el servicio y se encripta si abandona nuestra infraestructura física.

Entre servicios de Google Cloud

El enrutamiento de un servicio de producción a otro tiene lugar en nuestra red troncal y puede ser necesario enrutar el tráfico fuera de los límites físicos controlados por Google o en nombre de Google. En la figura 1 se muestra esta interacción (conexión E). La activación de Google Cloud Functions mediante un evento de Google Cloud Storage es un ejemplo de este tipo de tráfico. Las conexiones entre los servicios de producción se encriptan si abandonan la infraestructura física, y se autentican dentro de esta.

Figura 1: Protección predeterminada y opciones superpuestas en la red de Google

Encriptado en tránsito de forma predeterminada

Para los datos en tránsito, Google usa varios métodos de encriptado, tanto predeterminados como personalizables. El tipo de encriptado depende de la capa OSI, el tipo de servicio y el componente físico de la infraestructura. En las figuras 2 y 3, a continuación, se muestran las protecciones opcionales y predeterminadas que aplica Google Cloud para las capas 3, 4 y 7.

Figura 2: Protección predeterminada y opcional en las capas 3 y 4 en Google Cloud

Figura 3: Protección predeterminada y opcional en la capa 7 en Google Cloud3

En el resto de esta sección se describen las protecciones predeterminadas que usamos en Google para proteger los datos en tránsito.

Encriptado entre el usuario y el frontend de Google

En muchos sistemas actuales se usa el protocolo HTTPS para las comunicaciones a través de Internet. Se trata de una opción segura, ya que se dirige el protocolo a través de una conexión TLS, lo que garantiza la autenticidad, integridad y privacidad de las solicitudes y respuestas. Para aceptar solicitudes HTTPS, el receptor necesita un par de claves pública/privada y un certificado X.509, emitido por una autoridad de certificación (CA), para autenticar el servidor. El par de claves y el certificado ayudan a proteger las solicitudes del usuario en la capa de aplicación (capa 7) al demostrar que el receptor es propietario del nombre de dominio para el que están destinadas las solicitudes. En las siguientes subsecciones se abordan los componentes del encriptado desde el usuario al GFE: TLS, BoringSSL y la autoridad de certificación de Google. Recuerda que no todas las rutas del cliente pasan por el GFE: en concreto, el GFE se usa para el tráfico desde un usuario hasta un servicio de Google Cloud o hasta una aplicación de cliente alojada en Google Cloud que utilice Google Cloud Load Balancing.

Seguridad en la capa de transporte (TLS)

Cuando el usuario envía una solicitud a un servicio de Google Cloud, protegemos los datos en tránsito y ofrecemos autenticación, integridad y encriptado mediante el protocolo HTTPS con un certificado de una autoridad de certificación web pública. Todos los datos que el usuario envía al GFE se encriptan en tránsito con Seguridad en la capa de transporte (TLS) o QUIC. El GFE negocia un protocolo de encriptado concreto con el cliente según las compatibilidades de este, aunque, en la medida de lo posible, intenta utilizar protocolos de encriptado más modernos.

El encriptado TLS escalado de GFE no solo se aplica a las interacciones del usuario final con Google, sino que también facilita las interacciones de la API con Google mediante TLS, como en el caso de Google Cloud. Además, nuestro encriptado TLS se utiliza en Gmail para intercambiar correos electrónicos con servidores de correo externos (para obtener más información, consulta Exigir TLS en Gmail).

Google es una empresa líder del sector tanto en la adopción de TLS como en el refuerzo de su implementación. Para ello, hemos habilitado de forma predeterminada muchas de las funciones de seguridad de TLS; desde 2011, por ejemplo, estamos usando la confidencialidad directa en nuestra implementación de TLS. Este protocolo evita que se persista en la clave que protege una conexión, de modo que el atacante que intercepta y lee un mensaje no puede leer los anteriores.

BoringSSL

BoringSSL es una implementación de software libre del protocolo TLS, mantenida por Google, cuya interfaz es altamente compatible con OpenSSL. Google creó BoringSSL a partir de OpenSSL para simplificar este último, tanto para uso interno como para ofrecer una mejor compatibilidad con los Proyectos de Software Libre de Android y Chromium. BoringCrypto, el núcleo de BoringSSL, se ha validado según el estándar FIPS 140-2 de nivel 1.

TLS se implementa en GFE mediante BoringSSL. En la tabla 1 se muestran los protocolos de encriptado compatibles con GFE durante la comunicación con los clientes.

Protocolos Autenticación Intercambio de claves Cifrado Funciones hash
TLS 1.34 RSA 2048 Curve25519 AES-128-GCM SHA384
TLS 1.2 ECDSA P-256 P-256 (NIST secp256r1) AES-256-GCM SHA256
TLS 1.1     AES-128-CBC SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

Tabla 1: Encriptado implementado en el frontend de Google para los servicios de Google Cloud y en la biblioteca criptográfica de BoringSSL

Autoridad de certificación de Google

Como parte de TLS, los servidores tienen que demostrar su identidad al usuario al recibir una solicitud de conexión, por lo que deben presentar un certificado con la identidad que reclaman. Cuando se presenta el certificado, que incluye el nombre del host de DNS y la clave pública del servidor, lo firma la autoridad de certificación (CA) emisora, en la que confía el usuario que solicita la conexión.10 Como resultado, los usuarios que solicitan las conexiones al servidor solo tienen que confiar en la CA raíz. Si el servidor requiere un acceso ubicuo, los dispositivos del cliente de todo el mundo deben conocer la CA raíz. En la actualidad, la mayoría de navegadores y otras implementaciones de clientes de TLS tienen su propio conjunto de CA raíces, que se configuran y almacenan como autoridades de certificación de confianza.

En el caso de Google, aunque antes contábamos con nuestra propia CA emisora, que se utilizaba para firmar certificados de dominios de Google, hasta ahora no disponíamos de nuestra propia CA raíz. Hoy, nuestros certificados los firman varias CA raíces, distribuidas de forma ubicua, como Symantec ("GeoTrust") y raíces utilizadas previamente por GlobalSign ("GS Root R2" y "GS Root R4").

En junio de 2017, anunciamos que empezaríamos a usar nuestras propias CA raíces. Con el tiempo, queremos utilizar una CA raíz ubicua que emita certificados para dominios de Google y para nuestros clientes.

Migración de clave raíz y rotación de claves

Las claves de CA raíz no se modifican con frecuencia, ya que migrar a una nueva CA raíz requiere que todos los navegadores y dispositivos incorporen la confianza de ese certificado, lo que conlleva mucho tiempo. Como resultado, aunque Google ahora utiliza sus propias CA raíces, seguiremos confiando en varias CA raíces de terceros durante un periodo de transición para cubrir los dispositivos antiguos mientras migramos a las nuestras.

Para crear una nueva CA raíz se requiere una ceremonia de claves. En Google, la ceremonia exige que, como mínimo, tres de las seis personas autorizadas accedan físicamente a las claves de hardware almacenadas en un lugar seguro. Estas personas se reúnen en una sala específica, protegida frente a interferencias electromagnéticas y con un módulo de seguridad de hardware (HSM) con tecnología de aislamiento físico, para generar un conjunto de claves y certificados. Esta sala se encuentra en un lugar seguro en los centros de datos de Google. Para garantizar que el proceso marcha según lo previsto, se aplican controles adicionales, como medidas de seguridad física, cámaras y observadores humanos. Si la ceremonia se realiza de forma correcta, el certificado generado es idéntico a un certificado de muestra, excepto por el nombre del emisor, la clave pública y la firma. A continuación, el certificado de CA raíz resultante se envía al navegador y a los programas raíces del dispositivo para su inclusión. Este proceso se ha diseñado para garantizar la seguridad y privacidad de las claves privadas asociadas y que, de este modo, sigan siendo fiables durante una década o incluso más.

Como vimos anteriormente, las CA usan sus claves privadas para firmar certificados, y estos verifican las identidades al iniciar un handshake TLS como parte de la sesión del usuario. Los certificados del servidor, que están firmados con CA intermedias, se crean del mismo modo que si se tratara de un CA raíz. Los certificados de CA intermedias se distribuyen como parte de la sesión TLS, de modo que migrar a una nueva resulta sencillo. Este método de distribución también permite que el operador de la CA conserve el material de la clave de la CA raíz en modo sin conexión.

La seguridad de una sesión TLS depende de lo bien que esté protegida la clave del servidor. Para mitigar aún más los riesgos que corre la clave, la duración de un certificado de TLS de Google está limitada a unos tres meses y los certificados van rotando cada dos semanas aproximadamente.

Un cliente que se haya conectado previamente a un servidor puede usar una clave de entrada privada11 para reanudar una sesión anterior con un handshake TLS abreviado, por lo que estas entradas son muy valiosas para cualquier atacante. Google rota las claves de entrada al menos una vez al día, y las claves de todas las propiedades caducan cada tres días. Para obtener más información sobre la rotación de entradas de claves de sesión, consulta este artículo sobre los riesgos de seguridad en los accesos directos con criptografía TLS.

Entre el frontend de Google y el de una aplicación

Algunas veces, como hemos visto en el apartado ¿Cómo se enruta el tráfico?, el usuario se conecta a un GFE dentro de un límite físico distinto del servicio deseado y, por tanto, del frontend de la aplicación asociada. En estos casos, la solicitud del usuario y todos los protocolos de capa 7, como HTTP, están protegidos por TLS o encapsulados en una RPC, que está protegida mediante la seguridad del transporte en la capa de aplicaciones (ALTS), como veremos en Autenticación, integridad y encriptado entre servicios. Estas RPC están autenticadas y encriptadas.

Para los servicios de Google Cloud, las RPC están protegidas mediante ALTS de forma predeterminada. En el caso de las aplicaciones de cliente alojadas en Google Cloud, si el tráfico se enruta mediante el frontend de Google, por ejemplo, si se usa el balanceador de carga de Google Cloud, el tráfico a la máquina virtual está protegido por el encriptado de red virtual de Google Cloud, como se describe en la siguiente sección.

Encriptado y autenticación de la red virtual de Google Cloud

La infraestructura de red virtual de Google Cloud habilita el encriptado cuando el tráfico abandona nuestra infraestructura física. El encriptado se realiza en la capa de red y se aplica al tráfico de IP privada en la misma nube privada virtual (VPC) o en redes VPC emparejadas.

Damos por supuesto que cualquier red que cruce un límite físico no controlado por nosotros o en nuestro nombre corre el riesgo de que un usuario malintencionado espíe, inserte o altere el tráfico durante la transmisión. Cuando los datos salen de los límites físicos que podemos controlar, garantizamos la integridad y la privacidad de las comunicaciones a través del encriptado.

Para implementar el encriptado en la capa de red, usamos el estándar de encriptado avanzado (AES) en el Galois/Counter Mode (GCM) con una clave de 128 bits (AES-128-GCM). Cada par de hosts de comunicación establece una clave de sesión mediante un canal de control protegido por ALTS para las comunicaciones autenticadas y encriptadas. La clave de sesión se utiliza para encriptar todas las comunicaciones de máquina virtual a máquina virtual entre estos hosts, y las claves de sesión se rotan de forma periódica.

En la capa de red (capa 3), la red virtual de Google Cloud autentica todo el tráfico entre máquinas virtuales mediante tokens de seguridad para proteger los hosts comprometidos frente a paquetes de spoofing en la red.

Durante la autenticación, los tokens de seguridad se encapsulan en un encabezado de túnel que incluye información de autenticación sobre el emisor y el receptor. El plano de control12 del lado de envío configura el token, mientras que el host de recepción lo valida. Los tokens de seguridad, compuestos por una clave de token con la información del emisor y por el secreto del host, se generan previamente para cada flujo. Hay un secreto para cada par de origen y receptor de límites físicos controlados por Google o en su nombre. En la figura 4 se muestra cómo se crean las claves de token, los secretos de host y los tokens de seguridad.

Figura 4: Tokens de seguridad

El secreto de límite físico es un número seudoaleatorio de 128 bits desde el que se derivan los secretos de host mediante un HMAC-SHA1. El secreto de límite físico se negocia con un handshake entre los planos de control de red de un par de límites físicos, y se vuelve a negociar cada pocas horas. Los tokens de seguridad utilizados para la autenticación individual entre máquinas virtuales, derivados de estas y de otras entradas, son HMACs y se negocian para un par concreto de emisor y receptor.

Autenticación, integridad y encriptado entre servicios

En la capa de aplicaciones (capa 7) de la infraestructura de Google, usamos la seguridad del transporte en la capa de aplicaciones (ALTS) para la autenticación, la integridad y el encriptado de las llamadas RPC de Google desde el GFE a un servicio, o entre servicios.

ALTS usa cuentas de servicio para la autenticación. Cada servicio que se ejecuta en la infraestructura de Google lo hace como una identidad de cuenta de servicio con credenciales criptográficas asociadas. Al hacer o recibir una RPC de otros servicios, el servicio utiliza sus credenciales para autenticarse. Para verificar estas credenciales, ALTS usa una autoridad de certificación interna.

Dentro de la infraestructura física controlada por Google o en su nombre, ALTS proporciona tanto la autenticación como la integridad para las RPC en el modo de "autenticación e integridad". Para el tráfico a través de la red WAN fuera de los límites físicos controlados por nosotros o en nuestro nombre, ALTS aplica automáticamente el encriptado del tráfico de RPC de la infraestructura en el modo de "autenticación, integridad y privacidad". En este momento, todo el tráfico a los servicios de Google, incluidos los servicios de Google Cloud, disfrutan de esta protección.

ALTS también se utiliza para encapsular otros protocolos de capa 7, como HTTP, en los mecanismos de RPC de la infraestructura para el tráfico desde el frontend de Google hasta el frontend de la aplicación. Esta protección aísla la capa de aplicaciones y elimina cualquier dependencia en la seguridad de la ruta de red.

Los servicios se pueden configurar para aceptar y enviar comunicaciones ALTS solo en el modo de "autenticación, integridad y privacidad", incluso dentro de la infraestructura física de Google o en su nombre. Un ejemplo de esto es el servicio de administración de claves internas de Google, que almacena y administra las claves de encriptado utilizadas para proteger los datos almacenados en reposo en la infraestructura de Google.

Protocolo ALTS

ALTS tiene un protocolo de handshake seguro, similar a un protocolo TLS mutuo, que se usa en la comunicación entre dos servicios para autenticar y negociar los parámetros de comunicación antes de enviar información sensible. El protocolo consta de dos pasos:

  • Paso 1: handshake El cliente inicia un handshake de protocolo Diffie‑Hellman de curva elíptica (ECDH) con el servidor mediante Curve25519. Tanto el cliente como el servidor tienen parámetros públicos ECDH certificados como parte de su certificado, que se utiliza durante el intercambio de claves Diffie‑Hellman. El handshake da como resultado una clave de tráfico común, disponible en el cliente y en el servidor. Las identidades del par de los certificados se utilizan en la placa de aplicaciones para tomar decisiones de autorización.
  • Paso 2: encriptado del registro Los datos se transmiten del cliente al servidor de forma segura utilizando la clave de tráfico común del paso 1. El encriptado en ALTS se implementa mediante BoringSSL y otras bibliotecas de encriptado. El encriptado más común es AES-128-GCM y la integridad se suministra mediante el GMAC de AES-GCM.

En la figura 5, a continuación, se muestra el handshake ALTS en detalle. En implementaciones más recientes, un asistente de procesos se encarga del handshake, aunque sigue habiendo casos en los que lo hacen las aplicaciones directamente.

Figura 5: Handshake ALTS

Como se describe al inicio de la sección Autenticación, integridad y encriptado entre servicios, ALTS usa las cuentas de servicio para la autenticación, y cada servicio que se ejecuta en la infraestructura de Google lo hace como una identidad de servicio con credenciales criptográficas asociadas. Durante el handshake ALTS, el asistente de procesos accede a las claves privadas y a los certificados correspondientes que cada par de cliente‑servidor utiliza en sus comunicaciones. La identidad de cuenta de servicio de ese servicio suministra la clave privada y el certificado correspondiente (búfer de protocolo firmado).

Certificados ALTS Hay varios tipos de certificados ALTS:

  • Certificados de máquinas: proporcionan una identidad para los servicios principales de una máquina específica. Se rotan cada 6 horas aproximadamente.
  • Certificados de usuario: proporcionan una identidad de usuario final para los ingenieros de Google que desarrollan código. Se rotan cada 20 horas aproximadamente.
  • Certificados de trabajos de Borg: proporcionan una identidad para los trabajos que se ejecutan en la infraestructura de Google. Se rotan cada 48 horas aproximadamente.

Una autoridad de certificación (CA) interna de Google, independiente de nuestra CA externa y sin ninguna relación con ella, almacena la clave de firma del certificado raíz.

Encriptado en ALTS

Según las máquinas que se utilicen, se pueden usar diversos algoritmos para implementar el encriptado en ALTS. Por ejemplo, la mayoría de servicios utilizan AES-128-GCM.13 Consulta la tabla 2 para obtener más información sobre el encriptado ALTS.

Máquinas Encriptado de mensajes utilizado  
Más común AES-128-GCM  
Sandy Bridge o anterior AES-128-VCM Usa un VMAC, en lugar de un GMAC, y es algo más eficiente en las máquinas más antiguas.

Tabla 2: Encriptado en ALTS

Casi todos los servicios de Google usan ALTS o la encapsulación de RPC que usa ALTS. En los casos en los que no es así, se emplean otras protecciones. Por ejemplo:

  • Algunos servicios de arranque y administración de máquinas de nivel inferior utilizan SSH.
  • Algunos servicios de registro de infraestructuras de bajo nivel usan TLS o Datagram TLS (DTLS).14
  • Algunos servicios que usan protocolos de transporte que no son TCP emplean otros protocolos criptográficos o protecciones de nivel de red dentro de los límites físicos controlados por Google o en nombre de Google.

Para las comunicaciones entre las máquinas virtuales y los servicios de Google Cloud Platform se emplea TLS, y no ALTS, para la comunicación con el frontend de Google. Consulta Encriptado entre una máquina virtual y el frontend de Google para obtener más información.

Encriptado entre una máquina virtual y el frontend de Google

El tráfico de una máquina virtual a GFE usa IP externas para llegar a los servicios de Google, aunque puedes configurar la función de acceso privado de Google para usar solo direcciones IP de Google para las solicitudes.

Igual que sucede con otras solicitudes de usuarios externos a Google, admitimos el tráfico TLS de forma predeterminada de una máquina virtual al GFE. La conexión se establece de la misma forma que cualquier otra conexión externa. Para obtener más información sobre TLS, consulta Seguridad en la capa de transporte (TLS).

Opciones personalizables por el usuario para el encriptado en tránsito

En la sección Encriptado en tránsito, hemos visto las protecciones predeterminadas que usamos en Google para los datos en tránsito. En esta sección se describe cómo se pueden configurar estas protecciones predeterminadas.

Entre el centro de datos in situ y Google Cloud

TLS mediante balanceadores de carga externos GCLB

Si el servicio en la nube utiliza un balanceador de carga externo de proxy SSL o HTTPS de Google, el GFE termina las conexiones TLS de los usuarios mediante los certificados SSL que el usuario aprovisiona y controla. Para obtener más información sobre cómo personalizar el certificado, consulta nuestra documentación sobre certificados SSL.

Túnel IPsec con Google Cloud VPN

Como cliente de Google Cloud, puedes usar Google Cloud VPN para conectar de forma segura tu red in situ a la red de nube privada virtual (VPC) de Google Cloud Platform a través de una conexión VPN IPsec (capa 3). El tráfico entre ambas redes lo encripta la pasarela VPN de una de las redes y lo desencripta la pasarela de la otra. De esta forma, tus datos están a buen recaudo en Internet. Además, puedes configurar varios túneles con balanceo de carga a través de diversas pasarelas VPN. Google Cloud VPN protege tus datos de las siguientes formas:

  • Los paquetes desde las máquinas virtuales hasta Cloud VPN no abandonan la red de Google. Estos paquetes están encriptados por la red virtual de Google Cloud si salen de los límites físicos controlados por nosotros o en nuestro nombre.
  • Los paquetes desde Cloud VPN hasta la VPN in situ se encriptan y autentican mediante un túnel IPsec.
  • Los paquetes desde la VPN in situ hasta los hosts in situ están protegidos por los controles que el usuario haya implantado en la red.

Para configurar una VPN, crea una pasarela de Cloud VPN y un túnel en la red de VPC del servicio alojado, y habilita después el tráfico entre las redes. También puedes configurar una VPN entre dos VPC.

Si quieres personalizar aún más tu red, puedes especificar la versión del protocolo de intercambio de claves de Internet15 (IKE) que quieres usar para tu túnel VPN. Puedes elegir entre dos versiones de IKE, IKEv1 e IKEv2, cada una de las cuales admite diferentes algoritmos de cifrado. Si especificas IKEv1, Google encripta los paquetes mediante AES-128-CBC y proporciona la integridad a través de SHA-1 HMAC.16 Si optas por IKEv2, hay una gran variedad de algoritmos de cifrado compatibles. En cualquier caso, Google Cloud VPN negociará el protocolo común más seguro que sea compatible con los dispositivos del par. Para ver las instrucciones completas sobre cómo configurar una VPN, consulta nuestra documentación sobre cómo elegir una opción de enrutamiento de VPN.

La interconexión dedicada de Google Cloud ofrece una alternativa a un túnel IPsec, ya que proporciona conexiones físicas directas y comunicación RFC 1918 entre tu red in situ y la red de Google. Los datos que se transmiten mediante esta conexión no están encriptados de forma predeterminada y, por tanto, se deben proteger en la capa de aplicaciones, por ejemplo, con TLS. Google Cloud VPN y Google Cloud Interconnect usan el mismo punto de conexión, por lo que puedes usar el encriptado VPN IPsec con la interconexión dedicada, aunque necesitarás una solución de terceros. Por el momento, MACsec (protección de capa 2) no es compatible.

Entre el usuario y el frontend de Google

Certificados SSL administrados: certificados gratuitos y automatizados

Al crear una aplicación en Google Cloud, puedes configurar el certificado SSL que utilizas para aprovechar la compatibilidad de GFE con TLS. Por ejemplo, puedes terminar la sesión TLS en tu aplicación, aunque de forma diferente a la terminación de TLS que se explica en TLS mediante balanceadores de carga externos GCLB.

Google también proporciona certificados SSL gratuitos y automatizados en los dominios personalizados de Firebase Hosting y Google App Engine. Estos certificados solo están disponibles para las propiedades alojadas en Google. Con los dominios personalizados de Google App Engine, también puedes proporcionar tus propios certificados SSL y utilizar un encabezado de protocolo de seguridad de transporte estricta de HTTPS (HSTS).

Cuando se señala a tu dominio en la infraestructura de Google, solicitamos y obtenemos un certificado para ese dominio para habilitar comunicaciones seguras y administramos las claves privadas del servidor TLS, que pueden ser RSA de 2048 bits o ECC secp256r1, y renovamos los certificados en nombre de nuestros clientes.

Exigir TLS en Gmail

Como hemos visto en Seguridad en la capa de transporte, Gmail usa TLS de forma predeterminada y registra y muestra si el último salto de un correo electrónico se produjo durante una sesión de TLS.17 Cuando dos usuarios de Gmail intercambian correos electrónicos, estos están protegidos por TLS o, en algunos casos, se envían directamente dentro de la aplicación. En estos casos, los RPC utilizados por la aplicación de Gmail están protegidos con ALTS, tal y como se describe en Autenticación, integridad y encriptado entre servicios. Aunque Gmail no aplica TLS a los mensajes entrantes que proceden de otros proveedores de correo electrónico, los administradores pueden configurar como requisito el uso de una conexión TLS segura para todos los mensajes entrantes y salientes.

Gmail S/MIME

Las extensiones seguras multipropósito de correo de Internet (S/MIME) son un estándar de seguridad de correo electrónico que proporciona autenticación, integridad y encriptado. La implementación del estándar S/MIME establece que todos los certificados asociados a los usuarios que mandan los correos electrónicos se alojen en una CA pública.

Como administrador, puedes configurar Gmail para habilitar S/MIME para correos electrónicos entrantes, configurar políticas para el cumplimiento de normas de contenido y de archivos adjuntos, y crear reglas de enrutamiento para los correos electrónicos entrantes y salientes. El siguiente paso consiste en cargar los certificados públicos de los usuarios en Gmail mediante la API de Gmail. En el caso de los usuarios externos, se debe intercambiar un mensaje inicial firmado con S/MIME para establecer S/MIME de forma predeterminada.

Encriptado entre servicios y entre máquinas virtuales

Istio es una malla de servicios de código abierto desarrollada, entre otros, por Google, IBM y Lyft para simplificar el descubrimiento y la conectividad de los servicios. La autenticación de Istio proporciona el encriptado automático de los datos en tránsito entre los servicios, y la administración de las claves y los certificados relacionados. Istio se puede utilizar en Google Kubernetes Engine y Google Compute Engine.

Si quieres implementar la autenticación y el encriptado mutuos para las cargas de trabajo, puedes utilizar la autenticación de Istio, que, especialmente para las cargas de trabajo en Kubernetes, permite que una CA de nivel de clúster genere y distribuya certificados, que después se usan para la seguridad en la capa de transporte mutua (mTLS) entre pods.

¿Cómo ayuda Google a encriptar los datos en tránsito en Internet?

En las secciones Encriptado en tránsito de forma predeterminada y Opciones personalizables por el usuario para el encriptado en tránsito, hemos visto las protecciones predeterminadas y personalizables que usamos en Google para los datos en tránsito de los clientes. Además, tenemos en marcha varios proyectos de software libre y otras iniciativas para fomentar el encriptado de datos en tránsito y la seguridad de los datos en Internet a gran escala.

Transparencia en los certificados

Para ofrecer HTTPS, como hemos visto en Encriptado entre el usuario y el frontend de Google, cualquier sitio web debe solicitar primero un certificado de una autoridad de certificación (CA) pública de una web de confianza. La autoridad de certificación se encarga de verificar que el solicitante está autorizado por el titular del dominio, así como de garantizar que el resto de información incluida en el certificado sea precisa. A continuación, se envía este certificado al navegador para autenticar el sitio web al que intenta acceder el usuario. Para garantizar la correcta autenticación de HTTPS, es importante cerciorarse de que las CA solo emiten certificados autorizados por el titular del dominio.

La transparencia en los certificados (CT) es una iniciativa lanzada por Google en marzo de 2013 para que los operadores de sitios web y los titulares de dominios puedan detectar si una CA ha emitido certificados incorrectos o sin autorización. Este sistema proporciona un mecanismo para que los titulares de dominios, las CA y los usuarios registren los certificados de confianza que ven o, en el caso de las CA, los certificados que emiten, en registros de solo anexión y a prueba de manipulaciones que se pueden verificar públicamente. Todo el mundo puede consultar los certificados de estos registros para asegurarse de que la información está autorizada y es correcta y precisa.

La primera versión de la transparencia en los certificados se especificó en un RFC experimental de IETF, RFC 6962. Durante el desarrollo de este sistema, Google creó numerosas herramientas de código abierto, como un servidor de registros para los certificados, así como herramientas para crear los registros de transparencia en los certificados. Además, Google Chrome requiere que algunos certificados se revelen públicamente, como aquellos de validación extendida (EV) o los emitidos por CA que emitieron certificados inadecuados en el pasado. A partir de 2018, Chrome exigirá que se revelen todos los nuevos certificados públicos de confianza.

Los operadores de sitios web pueden usar la transparencia en los certificados para detectar si se ha emitido algún certificado no autorizado para sus sitios web. Hay varios recursos gratuitos que facilitan esta tarea, como el Informe de transparencia en los certificados o la búsqueda de certificados de Google, así como las herramientas de Facebook. Además, aunque no uses la transparencia en los certificados, muchos navegadores la examinan con frecuencia para asegurarse de que las CA en las que confían los usuarios para acceder a tu sitio web cumplen los requisitos y las prácticas recomendadas del sector, de modo que se reduce el riesgo de que se emitan certificados fraudulentos.

Aumentar el uso de HTTPS

Tal y como se describe en la sección Encriptado entre el usuario y el frontend de Google, nos esforzamos mucho por garantizar que nuestros sitios web y servicios proporcionen HTTPS moderno de forma predeterminada. Nuestro objetivo es llegar al 100 % de encriptado en todos nuestros productos y servicios, por lo que todos los años publicamos un Informe de transparencia de HTTPS para llevar un seguimiento del progreso hasta alcanzar nuestro objetivo en todas las propiedades, como Google Cloud. Seguimos trabajando para superar las barreras técnicas que dificultan el encriptado en algunos de nuestros productos, como soluciones para navegadores u otros clientes que no son compatibles con el protocolo de seguridad de transporte estricta de HTTPS (HSTS).18 Usamos HSTS para algunos de nuestros sitios web, como la página principal de Google, para que los usuarios solo se conecten a un servidor a través de HTTPS.

Como sabemos que todo Internet está trabajando para migrar a HTTPS, intentamos facilitar esta transición de estas formas:

En 2016, empezamos a publicar métricas sobre el uso de HTTPS en Internet para los 100 sitios web principales que no son de Google con el objetivo de fomentar la concienciación y ayudar a convertir Internet en un lugar más seguro para todos los usuarios. En octubre de 2017, Chrome renovó formalmente la ayuda financiera a Let’s Encrypt como patrocinador de nivel Platino.

Aumentar el uso del protocolo SMTP seguro: indicadores de Gmail

Casi todos los correos electrónicos se intercambian mediante el protocolo simple de transferencia de correo (SMTP), que, de forma predeterminada, envía correos electrónicos sin encriptado. Para encriptar un correo electrónico, el proveedor de correo electrónico debe implementar controles de seguridad, como TLS.

Como hemos visto en Encriptado entre el usuario y el frontend de Google, Gmail usa TLS de forma predeterminada. En la sección Exigir TLS en Gmail, además, se describe cómo implementar de forma obligatoria el uso de una conexión TLS segura para todos los mensajes entrantes y salientes en Gmail. Al igual que las iniciativas de Google por la transparencia de HTTPS, Gmail proporciona datos sobre el uso de TLS para los correos electrónicos entrantes de Gmail. Estos datos se pueden consultar en nuestro Informe de transparencia para la seguridad del correo electrónico.

Google, en colaboración con IETF y otros importantes actores del sector, lidera el desarrollo de SMTP STS, que es similar a HSTS para HTTPS y fuerza el uso de SMTP solo en canales encriptados.

APIs de Chrome

En febrero de 2015, Chrome anunció la disponibilidad de nuevas y potentes funciones solo para orígenes seguros19, como la gestión de información privada y el acceso a sensores en el dispositivo del usuario, y hemos empezado a desactivar estas funciones cuando tienen orígenes inseguros, empezando por la geolocalización en Chrome 50.

Innovación continua en el encriptado en tránsito

Experiencia de usuario de Chrome en materia de seguridad

Google Chrome es líder del sector en el uso de la interfaz de usuario para mostrar información de seguridad con el objetivo de que los usuarios sepan enseguida cuál es el nivel de seguridad de la conexión a un sitio web. Con esta información, los usuarios pueden tomar decisiones informadas sobre cuándo y cómo comparten sus datos. Chrome realiza minuciosos estudios de usuarios y comparte los resultados en artículos revisados por expertos.

Para ayudar a proteger aún más a sus usuarios, Chrome ha anunciado que para finales de 2017 marcará todas las conexiones HTTP como no seguras. A partir de Chrome 56, los usuarios verán una advertencia de forma predeterminada en caso de que una página HTTP incluya un formulario con contraseña u otros campos de tarjeta de crédito. En Chrome 62, se mostrará una advertencia cuando un usuario introduzca sus datos en una página HTTP, así como en todas las páginas HTTP visitadas en modo de incógnito. Con el paso del tiempo, Chrome acabará mostrando una advertencia para todas las páginas servidas a través de HTTP.

Si quieres ver cómo se muestran determinadas configuraciones a los usuarios de Chrome, puedes usar la herramienta BadSSL.

Transparencia de claves

Un obstáculo significativo para la adopción generalizada del encriptado de mensajes es la dificultad del intercambio de claves públicas: ¿cómo podemos encontrar la clave pública para comunicarnos con un nuevo usuario de forma segura? En enero de 2017, para ayudar a solucionar este problema, Google anunció la transparencia de claves, un framework abierto que proporciona un método general, seguro y auditable para distribuir claves públicas. Gracias a este framework, los usuarios no tienen que verificar manualmente las claves. La transparencia de claves está orientada principalmente a la distribución de claves públicas de los usuarios durante las comunicaciones, como, por ejemplo, el encriptado de correo electrónico OpenPGP y de extremo a extremo. Su diseño, que constituye un nuevo enfoque de la recuperación y distribución de claves, se basa en la información obtenida mediante la transparencia en los certificados y CONIKS.

La transparencia de claves se ha desarrollado con software libre y se ha implementado mediante un árbol de Merkle a gran escala. Con la verificación de la transparencia de claves, los propietarios de las cuentas pueden ver qué claves se han asociado a sus cuentas y durante cuánto tiempo ha estado la cuenta activa y estable. El objetivo de Google a largo plazo es permitir que todo el mundo pueda ejecutar un servidor de transparencia de claves, así como facilitar su integración en cualquier número de aplicaciones.

Criptografía poscuántica

Google se propone seguir siendo el líder del sector en el encriptado de los datos en tránsito. Para ello, hemos empezado a trabajar en el área de la criptografía poscuántica, un tipo de criptografía que permite sustituir primitivas criptográficas vulnerables a ataques cuánticos eficientes por candidatos poscuánticos que parecen oponer mayor resistencia. En julio de 2016, anunciamos un experimento sobre la viabilidad de desplegar un algoritmo de este tipo mediante el algoritmo criptográfico poscuántico New Hope en la versión para desarrolladores de Chrome. Además, los investigadores de Google han trabajado en otras publicaciones sobre distintos protocolos prácticos de intercambio de claves de tipo poscuántico.

Apéndice

Obtén más información sobre la seguridad de Google Cloud, como un resumen del diseño de la seguridad de la infraestructura, y sobre el cumplimiento de Google Cloud, como este informe de auditoría SOC 3.

Notas a pie de página

1 Entre las soluciones de partners se incluyen tanto las soluciones ofrecidas en Cloud Launcher como los productos creados en colaboración con los partners, como Cloud Dataprep.
2 Todavía puedes deshabilitar este encriptado, por ejemplo, para el acceso HTTP a segmentos de Google Cloud Storage.
3 Las comunicaciones de una máquina virtual a un servicio que no están protegidas en la capa 7 siguen estando protegidas en las capas 3 y 4.
4 TLS 1.3 no está terminado aún. La versión de borrador se ha implementado solo en ciertos dominios de Google para hacer pruebas, como Gmail.
5 Google admite TLS 1.0 en los navegadores que todavía usan esta versión del protocolo. Ten en cuenta que todos los sitios web de Google que procesan datos de tarjetas de crédito han dejado de admitir TLS 1.0 desde que en julio de 2018 se pidiera su desactivación para cumplir las normativas del sector de las tarjetas de pago (PCI).
6 Para obtener más información sobre QUIC, consulta https://www.chromium.org/quic.
7, 8, 9 Ofrecemos compatibilidad con algunos sistemas operativos anteriores, como 3DES, SHA1 y MD5.
10 En lo que respecta a los certificados en cadena, la CA tiene una confianza transitiva.
11 Podría ser una entrada de sesión (RFC 5077) o un ID de sesión (RFC 5246).
12 El plano de control es la parte de la red que se encarga del tráfico de señalización, y es responsable del enrutamiento.
13 Antes se usaban otros protocolos, pero ahora se han quedado obsoletos y menos del 1 % de las tareas los usan.
14 Datagram TLS (DTLS) proporciona seguridad para las aplicaciones basadas en datagramas al permitir la comunicación de forma que se evitan las manipulaciones y las intrusiones.
15 El protocolo de intercambio de claves en Internet (IKE) se usa para configurar una asociación de seguridad en el paquete de protocolos IPsec.
16 HMAC-SHA-1 no se rompe por una colisión de SHA-1, como la colisión SHAttered descubierta por los investigadores de Google.
17 Para G Suite Enterprise, esto no se muestra en la interfaz de usuario. Los administradores del dominio pueden examinar los datos de su dominio mediante la búsqueda en el registro de correo electrónico.
18 El protocolo de seguridad de transporte estricta de HTTPS es un mecanismo que permite a los sitios web declararse accesibles solo mediante conexiones seguras o que los usuarios dirijan sus user‑agents para interactuar con estos sitios web solo mediante conexiones seguras.
19 Los orígenes seguros son conexiones que cumplen determinados patrones de esquema, host o puerto.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...