Descripción general del diseño de seguridad de la infraestructura de Google

El contenido de este artículo corresponde a enero de 2017 y representa el statu quo en el momento de su redacción. Los sistemas y las políticas de seguridad de Google pueden cambiar en el futuro, ya que mejoramos la protección para nuestros clientes de manera continua.

Resumen a nivel del director de TI

  • Google tiene una infraestructura técnica de escala global diseñada para proporcionar seguridad en todo el ciclo de vida de procesamiento de la información en Google. Esta infraestructura, además de permitir que los administradores trabajen sin riesgos, brinda seguridad a los siguientes procesos: la implementación de los servicios, el almacenamiento de los datos con protección de la privacidad de los usuarios finales, la comunicación entre los servicios y la comunicación privada con los clientes en Internet.
  • Google usa esta infraestructura para crear sus servicios de Internet, incluidos los servicios para consumidores, como Búsqueda, Gmail y Fotos, y los servicios para empresas, como G Suite y Google Cloud Platform.
  • La seguridad de la infraestructura está diseñada en capas progresivas que comienzan con la seguridad física de los centros de datos, continúan con la seguridad del hardware y del software que sustentan la infraestructura, y finalizan con las restricciones técnicas y los procesos establecidos para admitir la seguridad operacional.
  • Google hace grandes inversiones para proteger su infraestructura con cientos de ingenieros dedicados a la seguridad y a la privacidad distribuidos en todas las divisiones de Google, y muchos son autoridades distinguidas en la industria.

Introducción

Este documento muestra una descripción general del diseño de seguridad de la infraestructura técnica de Google. Esta infraestructura de escala global está diseñada para proporcionar seguridad en todo el ciclo de vida de procesamiento de la información en Google. Esta infraestructura, además de permitir que los administradores trabajen sin riesgos, brinda seguridad a los siguientes procesos: la implementación de los servicios, el almacenamiento de los datos con protección de la privacidad de los usuarios finales, la comunicación entre los servicios y la comunicación privada con los clientes en Internet.

Google usa esta infraestructura para crear sus servicios de Internet, incluidos los servicios para consumidores, como Búsqueda, Gmail y Fotos, y los servicios para empresas, como G Suite y Google Cloud Platform.

Describiremos la seguridad de esta infraestructura en capas progresivas que comienzan con la seguridad física de los centros de datos, continúan con la seguridad del hardware y del software que sustentan la infraestructura, y finalizan con las restricciones técnicas y los procesos establecidos para admitir la seguridad operacional.

Capas de seguridad de la infraestructura de Google: las distintas capas de seguridad, desde la infraestructura de hardware en la capa inferior hasta la seguridad operacional en la capa superior. Los contenidos de cada capa se describen en detalle en el documento.

Infraestructura de bajo nivel segura

En esta sección, describimos cómo protegemos las capas inferiores de nuestra infraestructura, que incluyen las instalaciones físicas, el hardware para propósitos específicos en nuestros centros de datos y la pila de software de bajo nivel que se ejecuta en cada máquina.

Seguridad de las instalaciones físicas

Google diseña y construye sus propios centros de datos, que incorporan varias capas de protección de seguridad física. El acceso a estos centros de datos se limita a solo una pequeña fracción de los empleados de Google. Usamos varias capas de seguridad física para proteger los pisos de nuestros centros de datos y usamos tecnologías como la identificación biométrica, la detección de metales, cámaras, barreras para vehículos y sistemas de detección de intrusión con láser. Además, Google aloja varios servidores en centros de datos de terceros, donde nos aseguramos de que existan medidas de seguridad física controladas por Google además de las capas de seguridad que proporciona el operador del centro de datos. Por ejemplo, en esos sitios podemos usar sistemas de identificación biométrica independientes, cámaras y detectores de metales.

Diseño y origen del hardware

Un centro de datos de Google se compone de miles de máquinas de servidor conectadas a una red local. Tanto las placas de servidor como las herramientas de redes tienen diseños personalizados de Google. Evaluamos a los distribuidores de componentes con los que trabajamos y seleccionamos los componentes cuidadosamente, a la vez que trabajamos con proveedores que auditan y validan las propiedades de seguridad de los componentes. También diseñamos chips personalizados, incluido un chip de seguridad de hardware que actualmente se está implementando en servidores y periféricos. De manera segura, estos chips nos permiten identificar y autenticar los dispositivos legítimos de Google en el nivel de hardware.

Identidad de las máquinas y pila de inicio seguras

Las máquinas de servidor de Google usan una variedad de tecnologías para garantizar que inicien la pila de software correcta. Usamos firmas criptográficas sobre los componentes de bajo nivel, como el BIOS, el bootloader, el kernel y la imagen del sistema operativo base. Estas firmas se pueden validar durante cada inicio o actualización. Google controla, crea y fortalece todos los componentes. Con cada generación nueva de hardware, nos esforzamos por mejorar la seguridad de manera continua. Por ejemplo, según la generación del diseño del servidor, usamos como raíz de confianza de la cadena de inicio un chip de firmware bloqueable, un microcontrolador que ejecuta código de seguridad escrito por Google o el chip de seguridad diseñado por Google que mencionamos antes.

Cada máquina de servidor del centro de datos tiene su propia identidad específica que se puede vincular a la raíz de confianza del hardware y al software con el que se inicia la máquina. Esta identidad se usa para autenticar llamadas de la API desde los servicios de administración de bajo nivel de la máquina y hacia ellos.

Google creó sistemas automatizados para garantizar que los servidores ejecuten versiones actualizadas de sus pilas de software (incluidos los parches de seguridad), para detectar y diagnosticar problemas de hardware y software, y para quitar máquinas del servicio si es necesario.

Implementación segura del servicio

En esta sección, describiremos cómo garantizamos que un servicio se implemente de manera segura en nuestra infraestructura a partir del hardware y del software base. Con “servicio”, nos referimos a una aplicación ejecutable que un desarrollador programó y que desea ejecutar en nuestra infraestructura, por ejemplo, un servidor SMTP de Gmail, un servidor de almacenamiento de Bigtable, un transcodificador de video de YouTube o una zona de pruebas de App Engine que ejecuta la aplicación de un cliente. Pueden existir miles de máquinas ejecutando copias del mismo servicio para administrar la carga de trabajo en la escala necesaria. Los servicios que se ejecutan en la infraestructura se controlan mediante un servicio de organización de clústeres llamado Borg.

Como veremos en esta sección, la infraestructura no supone ninguna confianza entre los servicios que se ejecutan en la infraestructura. En otras palabras, la infraestructura está diseñada fundamentalmente para ser multiusuario.

Integridad, identidad y aislamiento del servicio

Usamos autenticación y autorización criptográficas en la capa de la aplicación para la comunicación entre servicios. Esto proporciona un control de acceso estricto en un nivel de abstracción, además de un nivel de detalle que los administradores y los servicios pueden comprender con naturalidad.

No confiamos en los firewalls ni en la segmentación de la red interna como mecanismos de seguridad principales, pese a que usamos filtros de entrada y salida en varios puntos de nuestra red para evitar la falsificación de IP como una capa de seguridad adicional. Este enfoque nos ayuda a maximizar el rendimiento y la disponibilidad de nuestra red.

Cada servicio que se ejecuta en la infraestructura tiene una identidad de cuenta de servicio asociada. Un sistema recibe credenciales criptográficas que puede usar para verificar su identidad cuando ejecuta llamadas de procedimiento remoto (RPC) a otros servicios o las recibe. Los clientes usan estas identidades para asegurarse de que se comuniquen con el servidor correcto, y los servidores las usan para limitar el acceso de clientes específicos a los métodos y a los datos.

El código fuente de Google se almacena en un repositorio central donde se pueden examinar las versiones anteriores y actuales del servicio. Además, la infraestructura se puede configurar para que exija que los ejecutables de un servicio se compilen a partir de un código fuente específico revisado, verificado y probado. Para estas revisiones de código, se necesita la inspección y la aprobación de al menos un ingeniero distinto del autor, y el sistema exige que las modificaciones del código en cualquier sistema tengan la aprobación de los propietarios de ese sistema. Estos requisitos limitan la capacidad de un usuario infiltrado o de un miembro de la competencia para hacer modificaciones maliciosas en el código fuente y también proporcionan un rastro forense desde un servicio hacia su origen.

Tenemos una variedad de técnicas de aislamiento y de uso de la zona de pruebas para proteger un servicio de otros servicios que se ejecutan en la misma máquina. Estas técnicas incluyen la separación normal de usuarios de Linux, zonas de prueba según el lenguaje y el kernel, y la virtualización del hardware. En general, usamos más capas de aislamiento para las cargas de trabajo con mayor riesgo. Por ejemplo, cuando se ejecutan convertidores de formato de archivo complejos en datos proporcionados por el usuario o cuando se ejecuta un código proporcionado por el usuario para productos como Google App Engine o Google Compute Engine. Como una restricción de seguridad adicional, habilitamos servicios confidenciales, como el servicio de organización de clústeres y algunos servicios de administración de claves, para ejecutarlos exclusivamente en máquinas dedicadas.

Administración del acceso entre servicios

El propietario de un servicio puede usar las funciones de administración del acceso que proporciona la infraestructura para especificar exactamente qué otros servicios pueden comunicarse con él. Por ejemplo, es posible que un servicio quiera ofrecer algunas API únicamente a una lista blanca específica de otros servicios. Ese servicio se puede configurar con la lista blanca de identidades de cuenta de servicio permitidas, y la infraestructura aplicará la restricción de acceso automáticamente.

También se proporcionan identidades personales a los ingenieros de Google que acceden a los servicios, por lo que estos servicios se pueden configurar de manera similar para que permitan o rechacen el acceso. Todos estos tipos de identidades (máquina, servicio y empleado) se encuentran en un espacio de nombres global que mantiene la infraestructura. Las identidades de los usuarios finales se administran por separado, como se explicará más adelante en este documento.

La infraestructura proporciona un valioso sistema de flujo de trabajo de administración de identidades para estas identidades internas, incluidas las cadenas de aprobación, los registros y las notificaciones. Por ejemplo, estas identidades se pueden asignar a grupos de control de acceso a través de un sistema que permite el control de dos partes, en el que un ingeniero puede proponer un cambio en un grupo y otro ingeniero (que también es administrador del grupo) debe aprobarlo. Este sistema permite que los procesos de administración de acceso seguro escalen a miles de servicios que se ejecutan en la infraestructura.

Además del mecanismo automático de control de acceso en el nivel de la API, la infraestructura permite que los servicios lean bases de datos de grupos y LCA centrales, de manera que puedan implementar su propio control de acceso detallado y personalizado cuando lo necesiten.

Encriptación de la comunicación entre servicios

Aparte de las capacidades de autenticación y autorización de RPC analizadas en las secciones anteriores, la infraestructura también proporciona integridad y privacidad criptográfica para los datos de RPC en la red. Para proporcionar estos beneficios de seguridad a protocolos de otras capas de la aplicación, como HTTP, los encapsulamos dentro de los mecanismos de RPC de nuestra infraestructura. En esencia, esto posibilita el aislamiento de las capas de la aplicación y quita cualquier dependencia de la seguridad de la ruta de red. La comunicación encriptada entre servicios puede mantenerse segura incluso si se intervino la red o un dispositivo de red está en riesgo.

Los servicios pueden configurar el nivel de protección criptográfica que desean para cada RPC de infraestructura (p. ej., solo configurar protección en el nivel de integridad para los datos de valor bajo dentro de los centros de datos). Para protegerse contra los adversarios sofisticados que podrían intentar intervenir los vínculos de nuestra WAN privada, la infraestructura encripta automáticamente todo el tráfico de RPC de la infraestructura que pasa por la WAN entre los centros de datos, sin necesidad de una configuración explícita del servicio. Comenzamos a implementar aceleradores criptográficos de hardware que nos permitirán extender esta encriptación predeterminada a todo el tráfico de RPC de la infraestructura dentro de nuestros centros de datos.

Administración del acceso a los datos del usuario final

Por lo general, los servicios de Google tienen una función para el usuario final. Por ejemplo, un usuario final puede almacenar su correo electrónico en Gmail. La interacción del usuario final con una aplicación como Gmail abarca otros servicios dentro de la infraestructura. Por ejemplo, el servicio de Gmail puede llamar a una API que proporciona el servicio Contactos para acceder a la libreta de direcciones del usuario final.

En la sección anterior, vimos que el servicio de Contactos se puede configurar de manera tal que solo se permitan solicitudes de RPC provenientes del servicio de Gmail (o de cualquier otro servicio en particular que quiera permitir el servicio de Contactos).

Sin embargo, esto sigue siendo un conjunto amplio de permisos. Dentro del alcance de este permiso, el servicio de Gmail podría solicitar los contactos de cualquier usuario en cualquier momento.

Dado que el servicio de Gmail envía una solicitud de RPC al servicio de Contactos en nombre de un usuario final en particular, la infraestructura permite que el servicio de Gmail presente una “etiqueta de permiso del usuario final” como parte de la RPC. Esta etiqueta prueba que el servicio de Gmail está ejecutando una solicitud en ese momento en nombre de ese usuario final en particular. Esto permite que el servicio de Contactos implemente una protección con la que solo se muestren datos para el usuario final que se nombra en la etiqueta.

La infraestructura proporciona un servicio central de identidad de usuarios que envía estas “etiquetas de permiso del usuario final”. El servicio central de identidad verifica el acceso de los usuarios finales y emite una credencial de usuario, como una cookie o un token de OAuth, al dispositivo cliente del usuario. Cada solicitud posterior que se realiza desde el dispositivo cliente hacia Google debe presentar esa credencial de usuario.

Cuando un servicio recibe una credencial de usuario final, la envía al servicio central de identidad para que la verifique. Si la credencial del usuario final se verifica correctamente, el servicio central de identidad muestra una “etiqueta de permiso del usuario final” de corta duración que se puede usar para las RPC relacionadas con la solicitud. En nuestro ejemplo, el servicio que obtiene la “etiqueta de permiso del usuario final” sería el servicio de Gmail, que la enviaría al servicio de Contactos. A partir de ese momento, para cualquier llamada en cascada, el servicio que ejecuta la llamada puede pasar la “etiqueta de permiso del usuario final” al que recibe la llamada, como parte de esa llamada RPC.

Administración de identidades de servicio y accesos: La infraestructura proporciona identidad de servicio, autenticación mutua automática, comunicación encriptada entre servicios y aplicación de las políticas de acceso que define el propietario del servicio.

Almacenamiento seguro de datos

Hasta este punto del análisis, describimos cómo implementamos servicios de manera segura. Ahora, analizaremos cómo implementamos el almacenamiento seguro de datos en la infraestructura.

Encriptación en reposo

La infraestructura de Google proporciona una variedad de servicios de almacenamiento, como Bigtable y Spanner, y un servicio central de administración de claves. La mayoría de las aplicaciones de Google acceden al almacenamiento físico de manera indirecta a través de estos servicios de almacenamiento. Los servicios de almacenamiento se pueden configurar para que usen claves del servicio central de administración de claves y encripten los datos antes de escribirlos en el almacenamiento físico. Este servicio de almacenamiento de claves admite la rotación de claves automática, proporciona registros de auditoría de gran alcance y se integra a las etiquetas de permiso del usuario final mencionadas antes para vincular claves con usuarios finales específicos.

La ejecución de la encriptación en la capa de la aplicación permite que la infraestructura se aísle a sí misma de las posibles amenazas en los niveles inferiores de almacenamiento, como el firmware de disco malicioso. Sin embargo, la infraestructura también implementa capas de protección adicionales. Habilitamos la compatibilidad con la encriptación de hardware en nuestros discos duros y SSD, y hacemos un seguimiento meticuloso de cada unidad durante su ciclo de vida. Antes de que un dispositivo de almacenamiento encriptado en desuso pueda abandonar físicamente nuestra custodia, se borra con un proceso de varios pasos que incluye dos verificaciones independientes. Los dispositivos que no pasan por este procedimiento de limpieza se destruyen físicamente (p. ej., se trituran) dentro de las instalaciones.

Eliminación de datos

En la mayoría de los casos, la eliminación de datos en Google comienza con la marcación de datos específicos como “programados para la eliminación” en lugar de quitar los datos por completo realmente. Esto nos permite recuperar datos que se borraron por accidente, ya sea debido a un error del cliente o a un error interno en el proceso. Después de marcar los datos como “programados para la eliminación”, se borran según las políticas específicas del servicio.

Cuando un usuario final borra su cuenta completa, la infraestructura notifica a los servicios que administran los datos del usuario final sobre la eliminación de la cuenta. Entonces, los servicios pueden programar la eliminación de los datos asociados con la cuenta de usuario final borrada. Esta función permite que el desarrollador de un servicio implemente el control de usuarios finales con facilidad.

Comunicación segura en Internet

Hasta el momento, en este documento, describimos cómo protegemos los servicios en nuestra infraestructura. En esta sección, abordaremos cómo protegemos la comunicación entre Internet y estos servicios.

Como se analizó antes, la infraestructura consta de un gran conjunto de máquinas físicas con interconexiones LAN y WAN, y la seguridad de la comunicación entre los servicios no depende de la seguridad de la red. Sin embargo, aislamos nuestra infraestructura de Internet en un espacio de IP privado para poder implementar protecciones adicionales con mayor facilidad, como las defensas contra los ataques de rechazo del servicio (DoS), mediante la exposición de solo un subconjunto de las máquinas directamente al tráfico externo de Internet.

Servicio de Google Frontend

Cuando se quiere publicar un servicio en Internet para que esté disponible, puede registrarse con un servicio de infraestructura llamado Google Frontend (GFE). GFE garantiza que todas las conexiones de TLS se cierren con los certificados correctos y según las recomendaciones, como cumplir con la confidencialidad directa perfecta. Además, GFE aplica protecciones contra los ataques de rechazo del servicio (que analizaremos con más detalles más adelante). Luego, GFE reenvía las solicitudes del servicio con el protocolo de seguridad de RPC que analizamos antes.

En efecto, todo servicio interno que se quiera publicar de manera externa usa GFE como una frontend de proxy inverso inteligente. Esta frontend proporciona hosting de IP público para el nombre público de DNS, protección contra el rechazo del servicio (DoS) y la rescisión de TLS. Ten en cuenta que GFE se ejecuta en la infraestructura como cualquier otro servicio, por lo que tiene la capacidad de escalar para coincidir con los volúmenes de solicitudes entrantes.

Protección contra el rechazo del servicio (DoS)

El escalamiento vertical de nuestra infraestructura permite que Google simplemente absorba muchos ataques de DoS. De todas formas, tenemos protecciones contra DoS de varios niveles y capas que reducen aún más el riesgo de cualquier impacto de DoS en un servicio que se ejecuta tras GFE.

Después de que nuestra red central envía una conexión externa a uno de nuestros centros de datos, pasa a través de varias capas de balanceo de cargas de hardware y software. Estos balanceadores de cargas entregan información sobre el tráfico de entrada a un servicio central de DoS que se ejecuta en la infraestructura. Cuando el servicio central de DoS detecta un ataque de DoS activo, puede configurar los balanceadores de cargas para que detengan o aceleren el tráfico asociado con el ataque.

En la siguiente capa, las instancias de GFE también entregan información sobre las solicitudes que reciben al servicio central de DoS, incluida la información sobre la capa de la aplicación que los balanceadores de cargas no tienen. Luego, el servicio central de DoS también puede configurar las instancias de GFE para que detengan o aceleren el tráfico del ataque.

Autenticación de los usuarios

Después de la protección contra DoS, la siguiente capa de defensa proviene de nuestro servicio central de identidad. Por lo general, este servicio se manifiesta a los usuarios finales como la página de acceso de Google. Aparte de pedir un nombre de usuario y una contraseña simples, el servicio desafía a los usuarios de forma inteligente para obtener información adicional según los factores de riesgo, por ejemplo, si ya accedieron desde el mismo dispositivo o una ubicación similar. Después de autenticar al usuario, el servicio de identidad envía credenciales, como cookies y tokens de OAuth, que se pueden usar en las llamadas siguientes.

Los usuarios también tienen la opción de usar segundos factores cuando acceden, como OTP o llaves de seguridad que impiden la suplantación de identidad. Para garantizar que los beneficios se reflejen más allá de Google, trabajamos en la Alianza FIDO con varios proveedores de dispositivos para desarrollar el estándar abierto Universal 2nd Factor (U2F). Actualmente, estos dispositivos están disponibles en el mercado. Otros servicios web importantes siguieron nuestra iniciativa y también implementaron la compatibilidad con U2F.

Seguridad operacional

Hasta este punto, describimos el diseño de la seguridad en nuestra infraestructura y algunos de los mecanismos necesarios para lograr un procedimiento seguro, como los controles de acceso en las RPC.

Ahora, describiremos cómo usamos realmente la infraestructura de manera segura: creamos el software de infraestructura de forma segura, protegemos las credenciales y las máquinas de nuestros empleados y nos defendemos de las amenazas a la infraestructura por parte de actores internos y externos.

Desarrollo de software seguro

Aparte de las características de control central de código fuente y de revisión de dos partes ya descritas, también proporcionamos bibliotecas para evitar que los desarrolladores incorporen ciertas clases de errores de seguridad. Por ejemplo, tenemos bibliotecas y marcos de trabajo que eliminan vulnerabilidades de XSS en aplicaciones web. También tenemos herramientas automatizadas para detectar los errores de seguridad, incluidas las pruebas de fuzzing, las herramientas de análisis estático y los escáneres de seguridad web.

A modo de verificación final, usamos revisiones de seguridad manuales que varían desde las evaluaciones rápidas para las características con menor riesgo hasta las revisiones exhaustivas de diseño y de implementación para las características con mayor riesgo. Un equipo de expertos de seguridad web, criptografía y seguridad de sistemas operativos ejecuta estas revisiones. Estas revisiones también pueden dar como resultado nuevas características de bibliotecas de seguridad y nuevas pruebas de fuzzing que se pueden aplicar a otros productos futuros.

Además, tenemos un programa de recompensas de vulnerabilidad en el que le pagamos a cualquiera que pueda descubrir errores en nuestra infraestructura o en nuestras aplicaciones y notificarnos sobre ellos. Con este programa, pagamos varios millones de dólares en recompensas.

Google hace un gran esfuerzo para detectar ataques del día cero y otros problemas de seguridad en todo el software de código abierto que usamos y para corregirlos de manera ascendente. Por ejemplo, el error Heartbleed de OpenSSL se detectó en Google, y enviamos la mayor cantidad de CVE y de correcciones de errores de seguridad para el hipervisor KVM de Linux.

Protección continua de los dispositivos y credenciales de los empleados

Hacemos una gran inversión en proteger los dispositivos y credenciales de nuestros empleados contra el riesgo y también en supervisar la actividad para descubrir posibles riesgos o actividad ilícita de infiltrados. Esta es una parte fundamental de nuestra inversión para garantizar que nuestra infraestructura funcione de manera segura.

Las técnicas sofisticadas de suplantación de identidad se usan constantemente para atacar a nuestros empleados. Para protegernos contra esta amenaza, reemplazamos los segundos factores de OTP suplantables por el uso obligatorio de llaves de seguridad compatibles con U2F para las cuentas de nuestros empleados.

Hacemos una gran inversión en supervisar los dispositivos cliente que usan nuestros empleados para trabajar con la infraestructura. Nos aseguramos de que las imágenes de sistema operativo de estos dispositivos cliente estén actualizadas con los parches de seguridad y controlamos las aplicaciones que se pueden instalar. Además, tenemos sistemas para analizar las apps que instalan los usuarios, las descargas, las extensiones del navegador y el contenido que buscan en la Web para verificar que son pertinentes para los clientes corporativos.

Estar en la LAN corporativa no es nuestro mecanismo principal para otorgar privilegios de acceso. En cambio, usamos controles de administración de acceso en el nivel de la aplicación que nos permiten exponer aplicaciones internas solo a usuarios específicos cuando provienen de un dispositivo administrado correctamente y de las redes y las ubicaciones geográficas esperadas. (Para obtener más detalles, consulta nuestra lectura adicional sobre “BeyondCorp”).

Reducción del riesgo de infiltración

Limitamos, con contundencia, las actividades de los empleados que tienen acceso administrativo a la infraestructura y las supervisamos activamente. Trabajamos sin interrupciones para eliminar la necesidad de acceso privilegiado a ciertas tareas mediante una automatización que puede completar las mismas tareas de manera segura y controlada. Esto exige la aprobación de dos partes para algunas acciones y la incorporación de API limitadas que permiten la depuración sin exponer la información confidencial.

El acceso a la información de los usuarios finales por parte de los empleados de Google se puede registrar mediante hooks de infraestructura de bajo nivel. El equipo de seguridad de Google supervisa los patrones de acceso activamente y también investiga los eventos inusuales.

Detección de intrusiones

Google tiene canalizaciones sofisticadas para el procesamiento de datos que integran señales basadas en el host en dispositivos individuales, señales basadas en la red desde varios puntos de supervisión en la infraestructura y señales desde los servicios de la infraestructura. Las reglas y la inteligencia artificial creadas a partir de estas canalizaciones envían advertencias a los ingenieros de seguridad operacional sobre los posibles incidentes. Nuestros equipos de investigación y de respuesta ante incidentes evalúan, investigan y responden a estos posibles incidentes las 24 horas del día, los 365 días del año. Realizamos ejercicios de Red Team para medir y mejorar la eficacia de nuestros mecanismos de detección y respuesta.

Protección de Google Cloud Platform (GCP)

En esta sección, destacamos cómo nuestra infraestructura de nube pública, GCP, se beneficia de la seguridad de la infraestructura subyacente. Además, usaremos Google Compute Engine como un servicio de ejemplo y describiremos en detalle las mejoras en la seguridad específicas del servicio que posibilitamos a partir de la infraestructura.

Compute Engine permite que los clientes ejecuten sus propias máquinas virtuales en la infraestructura de Google. La implementación de Compute Engine consta de varios componentes lógicos, en particular el plano de control de administración y las máquinas virtuales en sí.

El plano de control de administración expone la superficie externa de la API y organiza tareas como la creación y la migración de máquinas virtuales. Se ejecuta como una variedad de servicios en la infraestructura, por lo que obtiene automáticamente características de integridad fundamentales, como una cadena de inicio seguro. Los servicios individuales se ejecutan bajo distintas cuentas de servicio internas, por lo que a cada servicio se le puede otorgar solo los permisos que necesita cuando ejecuta llamadas de procedimiento remoto (RPC) al resto del plano del control. Como se analizó antes, el código de todos estos servicios se almacena en el repositorio central de código fuente de Google, y existe un rastro de auditoría entre este código y los ejecutables que se implementan finalmente.

El plano de control de Compute Engine expone su API a través de GFE, por lo que aprovecha las características de seguridad de la infraestructura, como la protección contra el rechazo del servicio (DoS) y la compatibilidad con SSL/TLS administrada de manera central. Para obtener protecciones similares para las aplicaciones que se ejecutan en sus VM de Compute Engine, los clientes pueden usar el servicio opcional del balanceador de cargas de Google Cloud, que se creó a partir de GFE y puede mitigar muchos tipos de ataques de DoS.

La autenticación del usuario final en la API del plano de control de Compute Engine se ejecuta a través del servicio centralizado de identidad de Google, que proporciona características de seguridad como la detección de la usurpación de cuentas. La autorización se ejecuta con el servicio central de Cloud IAM.

La infraestructura autentica el tráfico de red para el plano de control automáticamente, tanto desde GFE hacia el primer servicio tras él como entre otros servicios del plano de control, y lo encripta cada vez que viaja de un centro de datos a otro. Además, la infraestructura se configuró también para encriptar parte del tráfico del plano de control dentro del centro de datos.

Cada máquina virtual (VM) se ejecuta con una instancia del servicio del administrador de máquina virtual (VMM) asociado. La infraestructura proporciona a estos servicios dos identidades. La instancia del servicio del VMM usa una identidad para sus propias llamadas, y la otra identidad se usa para las llamadas que el VMM hace en nombre de la VM del cliente. Esto nos permite hacer una mayor segmentación de la confianza que tenemos en las llamadas provenientes del VMM.

Los discos persistentes de Compute Engine se encriptan en reposo con claves protegidas por el sistema central de administración de claves de infraestructura. Esto permite hacer una rotación automatizada y una auditoría central del acceso a estas claves.

Actualmente, los clientes pueden decidir si envían el tráfico de sus VM a otras VM o a Internet sin riesgos, o si implementan alguna encriptación que elijan para este tráfico. Comenzamos a implementar la encriptación automática para el salto transversal de WAN del tráfico de VM a VM del cliente. Como se describió antes, todo el tráfico de WAN del plano de control dentro de la infraestructura ya está encriptado. En el futuro, pensamos aprovechar la encriptación de red con aceleración de hardware que analizamos antes para encriptar también el tráfico de LAN entre VM dentro del centro de datos.

El aislamiento proporcionado a las VM se basa en la virtualización de hardware mediante la pila de KVM de código abierto. Fortalecimos aún más nuestra implementación particular de KVM a través del traslado de parte de la pila de emulación de hardware y control a un proceso sin privilegios fuera del kernel. También probamos extensamente el núcleo de KVM con técnicas como el fuzzing, el análisis estático y la revisión manual del código. Como se mencionó antes, la mayoría de las vulnerabilidades divulgadas recientemente de manera pública que tuvieron una corrección ascendente a KVM provinieron de Google.

Por último, nuestros controles de seguridad operacional son un factor clave para garantizar que el acceso a los datos sigue nuestras políticas. Como parte de Google Cloud Platform, el uso de datos de clientes por parte de Compute Engine sigue la política de uso de datos de clientes de GCP, lo que significa que Google no accederá a los datos de clientes ni los usará, excepto si es necesario para proporcionar servicios a los clientes.

Conclusión

Describimos cómo se diseñó la infraestructura de Google para crear, implementar y utilizar servicios de manera segura a escala de Internet. Esto incluye los servicios para consumidores, como Gmail, y los servicios para empresas. Además, nuestras ofertas de Google Cloud se diseñaron a partir de esta misma infraestructura.

Hacemos una gran inversión en proteger nuestra infraestructura. Tenemos cientos de ingenieros dedicados a la seguridad y a la privacidad, distribuidos en todas las divisiones de Google, y muchos son autoridades distinguidas en la industria.

Como pudimos ver, la seguridad de la infraestructura está diseñada en capas que incluyen los componentes físicos y los centros de datos, el origen del hardware, el inicio seguro, la comunicación segura entre servicios, la protección de datos en reposo, el acceso protegido a los servicios desde Internet y, por último, las tecnologías y los procesos humanos que implementamos para la seguridad operacional.

Lecturas adicionales

Consulta los siguientes documentos para obtener más detalles sobre las áreas específicas:

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…