Este contenido se actualizó por última vez en septiembre del 2024 y representa la situación en el momento en que se redactó. Las políticas y los sistemas de seguridad de Google pueden cambiar en el futuro, ya que mejoramos constantemente la protección que proporcionamos a nuestros clientes.
La arquitectura de seguridad de hardware Titanium es la base de los servicios de Google y sustenta muchas de las contramedidas de seguridad de la infraestructura de Google. El hardware de Titanium incluye microcontroladores de seguridad, adaptadores de hardware y procesadores de descarga que se han desarrollado específicamente para abordar vectores de ataque concretos de la infraestructura de Google.
El hardware Titanium es el último avance de la infraestructura de seguridad integral y en constante evolución de Google, y ayuda a proteger la integridad, la confidencialidad y la disponibilidad de los datos de los usuarios. El hardware de Titanium se basa en una infraestructura como las tarjetas de descarga de hardware criptográfico, que proporcionan cifrado en tránsito, y en microservicios internos que ofrecen cifrado de datos en reposo.
En este documento se describe cómo funcionan conjuntamente los componentes de hardware de Titanium para crear una arquitectura de seguridad que ayude a proteger la superficie de ataque física de los sistemas de Google y a mitigar las amenazas a los datos de los clientes. En este documento también se describe cómo el hardware Titanium habilita controles de seguridad específicos en la capa de software, la evolución de la arquitectura más allá de las descargas iniciales de hardware criptográfico y las amenazas reales que la arquitectura de seguridad de hardware Titanium está diseñada para mitigar en la base de clientes y de implementaciones de Google.
Arquitectura de seguridad de hardware Titanium
La arquitectura de seguridad de hardware Titanium se ha diseñado para protegerse frente a un amplio abanico de situaciones y atacantes. En el siguiente diagrama de arquitectura se muestran los componentes independientes, pero interconectados, de Titanium.
La arquitectura de seguridad de hardware Titanium incluye los siguientes componentes:
- Raíz de confianza de Caliptra para la medición (RTM): ayuda a aplicar un perímetro de seguridad para cada paquete de silicio. Caliptra RTM proporciona atestación y un ID único a los servicios criptográficos raíz.
- Chip Titan RoT: se interpone entre la memoria flash de arranque de una plataforma y sus principales dispositivos de arranque, como el controlador de gestión de la placa base (BMC), el centro de control de la plataforma (PCH) y la CPU. Los chips Titan proporcionan una raíz de confianza basada en hardware y resistente a manipulaciones físicas que ayuda a establecer una identidad sólida. Los chips Titan también ayudan con la autorización y la revocación de código para máquinas, tarjetas o periféricos.
- Procesador de descarga Titanium (TOPs): proporciona controles criptográficos para proteger la confidencialidad y la integridad de los datos en reposo y en tránsito.
- Placas base personalizadas: proporcionan resiliencia a gran escala frente a ataques DoS de software defectuoso o malicioso, así como protección frente a ataques físicos. En el diagrama, por ejemplo, el paquete del chip y Titan RoT están en una placa base personalizada que es independiente de las placas base personalizadas de Titanium TOP o de las placas base de otra infraestructura.
- Enclaves de computación confidencial: ayudan a reforzar el aislamiento frente a los privilegios administrativos de Google, mejoran el aislamiento con otros inquilinos y añaden verificabilidad mediante la certificación. La certificación puede asegurar que el entorno no se ha alterado.
- Servicios regionales tolerantes a fallos de backend: ayudan a evitar la escalada de privilegios entre servicios, zonas o desde el acceso administrativo.
En el diagrama, Otra infraestructura hace referencia a las estructuras de red y al almacenamiento backend replicado.
Principios de diseño de la arquitectura de seguridad de hardware Titanium
Nuestros componentes de hardware de Titanium y sus interacciones se desarrollan siguiendo los siguientes principios fundamentales:
Sin puntos únicos de fallo: la arquitectura de Google se ha diseñado para evitar puntos únicos de fallo, como componentes únicos que soportan la carga y que tienen varias responsabilidades. En Building Secure and Reliable Systems se habla de la importancia de evitar los puntos únicos de fallo. Este principio se aplica en toda nuestra infraestructura física, en todas las regiones e incluso en el silicio de los chips. Esta resiliencia en toda nuestra infraestructura global ayuda a mantener los datos de los clientes protegidos y disponibles.
Por ejemplo, la migración en tiempo real con Confidential Computing ayuda a conservar la memoria cifrada en las máquinas host compatibles. La migración activa ayuda a asegurar que una VM que se ejecuta durante mucho tiempo no sea un punto único de fallo debido a eventos de mantenimiento o a vulnerabilidades.
El perímetro es el paquete de silicio: como un sistema de servidor contiene varios sistemas en chip interconectados e independientes, nuestra arquitectura desconfía fundamentalmente de todos los conectores, las estructuras, los ensamblajes de placas de circuito impreso (PCBA), los rastros de PCBA y los cables. Aunque la separación de componentes es útil para la modularidad, también puede convertirse en un punto débil si ofrece a los adversarios objetivos bien definidos desde los que espiar datos en texto sin cifrar. Los datos del propio paquete de silicio se cifran y autentican mediante recursos criptográficos privados del paquete.
Mover el perímetro al propio silicio ayuda a minimizar la confianza implícita. Este principio aborda las amenazas contra la confidencialidad de los datos que se producen a medida que las condiciones de servicio de los centros de datos son cada vez más diversas. Por ejemplo, definir el perímetro en el paquete de silicio ayuda a hacer frente a las amenazas de operaciones de hardware no autorizadas.
Confianza cero y compartimentación de riesgos: los controles multiparte de las acciones administrativas ayudan a asegurar que ninguna cuenta de personal (ni ninguna cuenta de personal vulnerada) pueda provocar unilateralmente las amenazas que se analizan en este documento. La arquitectura separa los servicios en capas y zonas para compartimentar y contener los riesgos. Incluso con los enclaves, que suelen estar basados en hardware, la arquitectura tiene en cuenta el descubrimiento de vulnerabilidades de hardware y la necesidad de corregirlas mientras los componentes siguen funcionando.
Por ejemplo, si un atacante pone en peligro de forma malintencionada el comportamiento de un chip dentro de un sistema activo que ejecuta cargas de trabajo de clientes en nuestros centros de datos, la arquitectura está diseñada para identificar y aislar ese chip. Esa máquina se puede retirar del servicio. Aunque la máquina no se ponga fuera de servicio, el atacante debe superar límites de confianza adicionales y vulnerar varias credenciales para moverse lateralmente y obtener influencia sobre otros sistemas, usuarios o regiones.
Los dominios de errores independientes y las tecnologías de aislamiento ayudan a limitar el área afectada de una vulneración. Estos dominios y tecnologías añaden puntos de control naturales para la detección y limitan la cantidad de complejidad adicional que se debe introducir.
Para obtener más información sobre nuestra implementación de la confianza cero, consulta BeyondProd.
Seguridad transparente: Google invierte en varias iniciativas de transparencia, como el código abierto, la divulgación responsable de investigaciones y resultados, y la colaboración con el ecosistema de fabricantes de hardware. La infraestructura global de Google aplica el principio de Kerckhoffs, que establece que un criptosistema debe ser seguro aunque se conozca públicamente todo sobre el sistema, excepto la clave.
Por ejemplo, contribuimos a proyectos de código abierto y los usamos en nuestros diseños de hardware de seguridad y en nuestro software de seguridad. En la siguiente tabla se describen algunos de los proyectos de código abierto en los que contribuimos y que utilizamos.
Proyecto de software libre Descripción Componente de titanio Se usa en bibliotecas de cifrado FIPS 140-3 de nivel 1.
BoringSSL
Se usa en raíces de confianza (RoT) a nivel de silicio.
Caliptra RTM
Se usa en RoT para un chip en una arquitectura de sistema.
Chips Titan
Se usa para el fuzzing del kernel guiado por la cobertura.
Distribuciones de VM de usuario y de host ring0
Se usa en bibliotecas de cifrado FIPS 140-3 de nivel 1.
Procesador de descarga Titanium
Defensa física y lógica en profundidad: Google se basa en la seguridad física de los centros de datos para proteger nuestras inversiones de capital y nuestros sistemas. Estos controles de seguridad son una capa inicial de defensa, por lo que invertimos deliberadamente en controles lógicos adicionales para reforzar nuestros sistemas frente a las amenazas físicas. Titanium se suma a nuestra defensa en profundidad añadiendo compartimentación en nuestro hardware, lo que proporciona defensas adicionales contra amenazas específicas de la infraestructura.
Por ejemplo, nuestros centros de datos tienen detectores de metales que pueden detectar con precisión los intentos de exfiltración de medios de almacenamiento. Sin embargo, nuestra estrategia de encriptado de datos en reposo se ha diseñado deliberadamente para que no dependa de la custodia de medios físicos. Estos controles lógicos y físicos son capas independientes y complementarias.
Nuestros controles de seguridad físicos y lógicos combinados nos ayudan a mantenernos alerta frente a las amenazas internas y a proteger la confidencialidad de los datos de nuestros usuarios.
Ventajas de seguridad de los componentes de la arquitectura Titanium
En la siguiente tabla se destacan algunas ventajas de seguridad importantes que se consiguen con los componentes de la arquitectura de seguridad Titanium, tanto en la capa de hardware como en la de software. En las próximas secciones se describen con más detalle estas ventajas de seguridad.
| Ventajas para la seguridad | Componente de arquitectura |
|---|---|
Perímetro de confianza a nivel de silicio en sistemas en chip (SoCs), como CPUs o GPUs |
Caliptra RTM |
Verificabilidad a nivel de silicio |
Caliptra RTM |
Identidad criptográfica a nivel de hardware |
Caliptra RTM y Titan RoT |
Verificación de que se están ejecutando los archivos binarios esperados |
Caliptra RTM y Titan RoT |
Mitigación de amenazas persistentes en los arranques |
Caliptra RTM y Titan RoT |
Protección de la confidencialidad de los datos en reposo y en tránsito |
TOPs para criptografía |
Descarga de la protección a nivel de procesador (más allá de una tarjeta física) |
TOPs para criptografía |
Seguridad desde el diseño, resistencia a ataques físicos y funciones de recuperación de firmware del sistema completo a partir de un único Titan RoT |
Placas base personalizadas |
Placas diseñadas específicamente con solo los conectores esenciales, lo que ayuda a mitigar los intentos de manipulación física |
Placas base personalizadas |
Aislamiento de las cargas de trabajo criptográficas del software del sistema de toda la máquina y del acceso humano administrativo |
Enclaves de Confidential Computing |
Resistencia a manipulaciones mediante el cifrado de DRAM (para habilitar el cifrado de datos en uso) |
Enclaves de Confidential Computing |
Se ha minimizado la zona afectada y el mamparo para un atacante con acceso local |
Servicios regionales de backend tolerantes a fallos |
Varios niveles de compartimentación |
Servicios regionales de backend tolerantes a fallos |
Raíz de confianza de Caliptra para la medición
Caliptra RTM ayuda a generar confianza y transparencia en el firmware de nuestro ecosistema que se ejecuta en sistemas en chip (SoCs) como CPUs, GPUs y TPUs.
Caliptra RTM ofrece las siguientes ventajas:
- Proporciona un servicio criptográfico raíz: Caliptra RTM ayuda a detectar código y configuración críticos dañados mediante una verificación de integridad criptográfica de extremo a extremo segura. Caliptra RTM puede medir criptográficamente su código y su configuración, firmar estas mediciones con una clave de certificación única y protegida por hardware, e informar de las mediciones que certifican la autenticidad y la integridad del dispositivo. Caliptra RTM proporciona una identidad de dispositivo criptográfica y un conjunto de mediciones de integridad de firmware y configuración para la placa base.
- Mitiga la seguridad de la cadena de suministro física: Caliptra RTM ayuda a asegurar que el hardware sea auténtico y que ejecute el firmware y el software previstos. En combinación con la seguridad de la cadena de suministro de software, la función RTM de Caliptra permite que el sistema verifique la autenticidad y la integridad del firmware y del software, tanto si los ha creado Google como si los ha creado un tercero. Este proceso de verificación permite que Caliptra RTM mantenga la autenticidad y la integridad en las actualizaciones autorizadas, y ayuda a asegurar que las configuraciones se mantengan como se pretende y se certifiquen.
- Protege frente a intrusiones físicas que requieren acceso directo al hardware en funcionamiento: como el RTM de Caliptra está integrado en las capas de silicio del chip, un interpositor de PCBA o un chip no autorizado que intente enviar el firmware incorrecto a un circuito integrado específico de una aplicación (ASIC) no podrá atacar el RoT. Por ejemplo, los atacantes pueden eludir las funciones de detección de un RoT externo manipulando el bus SPI, que tiene una velocidad relativamente baja. Sin embargo, si se inserta un RoT en un SoC o un ASIC, será más difícil que un atacante lo ponga en peligro.
Raíz de confianza del chip Titan
Titan se ha diseñado para mantener la identidad del dispositivo de forma criptográfica, protegerlo frente a las actualizaciones de software dañinas y aplicar la autenticidad del código mediante la revocación.
Una identidad de dispositivo criptográfica segura ayuda a asegurar que la flota se compone exclusivamente de máquinas validadas que ejecutan los archivos binarios esperados y que pueden identificar y autenticar el acceso legítimo. El acceso legítimo se basa en el nivel de hardware.
De forma predeterminada, las máquinas de producción usan el inicio de confianza para asegurarse de que solo se pueda ejecutar software autenticado. El inicio de confianza verifica la firma digital de todos los componentes del arranque y no permite que una máquina participe en el entorno de producción si falla la autenticación.
Como control preventivo adicional, la revocación de código de máquina evita que se apliquen cambios de software que ya no estén autorizados. La capacidad de revocación de los chips Titan ayuda a mitigar no solo los ataques maliciosos (por ejemplo, los ataques de reversión o de repetición), sino también los errores de estabilidad o de resiliencia no maliciosos (por ejemplo, al evitar la reinstalación accidental de firmware antiguo con errores).
Para obtener más información, consulta el artículo Cómo aplica Google la integridad del arranque en máquinas de producción.
Procesadores de descarga Titanium para criptografía
Los procesadores de descarga Titanium (TOPs) para criptografía ayudan a proporcionar seguridad durante la descarga de E/S. Estos TOPs están protegidos con Titan o Caliptra RTM. Los TOPs implementan un cifrado autenticado generalizado de los datos en tránsito y de los datos en reposo a un coste bajo. La encriptación autenticada significa que los datos de los clientes tienen una garantía criptográfica de confidencialidad e integridad. Como los TOPs gestionan la criptografía, privan de privilegios a muchos componentes del sistema. Los TOPs permiten mejorar las propiedades de la arquitectura, como la disponibilidad, al tiempo que minimizan la posibilidad de que se pierda la confidencialidad de los datos.
Placas base personalizadas
Las placas base personalizadas de la infraestructura de Google se han diseñado para proporcionar procedencia de hardware. Las placas base admiten la certificación en varias capas. Los diseños de las placas base protegen los datos de los clientes, incluso en el caso muy improbable de que un atacante conecte físicamente un dispositivo malicioso a una máquina. Los diseños de la placa base Titanium ayudan a habilitar la implementación fiable de mecanismos de protección adicionales, como puertos de depuración despoblados, consolas serie de solo lectura, intrusión en conectores de bus y señalización de extrusión.
TLS y ALTS son los únicos protocolos aceptados que expone nuestra pila de red BMC cuando se enciende una máquina. En las máquinas que usan un diseño COTS de terceros, como nuestras instancias X4, TOPs proxyiza cualquier tráfico de gestión que sea único para ese diseño de terceros. Gestionar el tráfico de proxy significa que nuestra infraestructura no depende de diseños de terceros para la autenticación, la autorización, la seguridad del transporte o la seguridad de la red.
Las placas base personalizadas de Titanium se han diseñado para incluir mecanismos de recuperación y copia de seguridad que garanticen la disponibilidad y la capacidad de recuperación. Pueden restaurarse por sí mismos en la mayoría de los fallos o en caso de corrupción del firmware. Nuestros diseños más recientes permiten reconstruir toda la máquina a partir de una única raíz de confianza de Titan que funcione. Estas placas base usan componentes de alimentación específicos y señalización de reinicio para ayudar a asegurar la independencia eléctrica de los RoTs de Titan del resto de la plataforma y proteger su control sobre las cargas útiles de firmware de la plataforma con fines de autenticación y recuperación.
Enclaves de Confidential Computing
La computación confidencial crea un entorno de ejecución de confianza (TEE) o un enclave para aislar las cargas de trabajo sensibles de los clientes del acceso administrativo de Google. Cuando la CPU o la GPU gestionan los datos, Confidential Computing proporciona un control preventivo técnico mediante el aislamiento de los cálculos y el cifrado en memoria. Confidential Computing ayuda a garantizar que ni siquiera un hipervisor malicioso pueda acceder a una VM. En el caso de las cargas de trabajo de los clientes, la computación confidencial proporciona una capa de aislamiento de la confidencialidad de los datos frente a la posibilidad de que el personal de Google acceda a ellos por error o de que el software del sistema automatizado realice acciones erróneas a gran escala.
Un ejemplo de seguridad avanzada que habilita la arquitectura de Titanium es el modo Confidencial de Hyperdisk Balanced. El modo confidencial de Hyperdisk Balanced combina descargas de almacenamiento en bloques basadas en Titanium, Confidential Computing y Cloud HSM para crear un TEE basado en hardware. En otras palabras, el modo Confidencial para Hyperdisk Balanced es una oferta de Hyperdisk Balanced. El modo confidencial de Hyperdisk Balanced aísla la infraestructura para que las claves sensibles se procesen exclusivamente en un TEE basado en hardware. Para obtener información sobre la revisión de terceros de las operaciones criptográficas, consulta el informe público sobre el análisis de la protección de DEK del modo Confidencial de Hyperdisk.
Servicios regionales de backend tolerantes a fallos
Los servicios regionales tolerantes a fallos del backend ayudan a minimizar la zona afectada por un atacante con acceso local. La infraestructura de Google está diseñada para compartimentar servicios, sistemas y zonas para evitar el movimiento lateral de personas internas con privilegios o servicios vulnerados.
Estamos trabajando para incluir información regional en un conjunto cada vez más amplio de nuestros sistemas internos de gestión de identidades y accesos. La información regional refuerza el aislamiento criptográfico para que un atacante que obtenga acceso local tenga que poner en peligro varias credenciales de distintos servicios de infraestructura para seguir moviéndose lateralmente.
Si un ataque activa un control preventivo que retiraría una máquina de producción del entorno (por ejemplo, provocaría que el sistema se apagara), nuestra infraestructura backend tolerante a fallos ayuda a garantizar la disponibilidad continua de los datos y servicios de los clientes en máquinas cercanas. Para obtener más información sobre nuestros controles de infraestructura, consulta BeyondProd y Cómo protege Google sus servicios de producción.
Vectores de ataque para la infraestructura de Google Cloud
En esta sección se describen las amenazas físicas y lógicas específicas que conforman parte de la superficie de ataque de Google Cloud. La arquitectura de seguridad de hardware de Titanium se ha diseñado específicamente para hacer frente a un conjunto único de amenazas a la infraestructura de Google y a los datos de los usuarios que almacenamos.
Amenazas a la infraestructura
La arquitectura de Titanium se ha diseñado para defenderse de las siguientes categorías de amenazas:
- Empleado interno no autorizado con acceso físico: nuestro personal necesita acceder a dispositivos físicos en los centros de datos para implementar, mantener y reparar hardware. Este acceso representa un vector de ataque potencial, ya que el personal o los contratistas no autorizados tienen un motivo empresarial legítimo para reparar físicamente algunas de las máquinas de nuestros centros de datos.
Empleado interno desleal con acceso lógico: al igual que ocurre con el acceso físico al centro de datos, el personal debe desarrollar, mantener, probar, depurar, ajustar y ofrecer asistencia para varios niveles de la pila de software de Google. Entre este personal se incluyen desarrolladores, ingenieros de fiabilidad de sitios (SRE) e ingenieros de la nube que trabajan de cara al cliente.
Para obtener más información sobre nuestras defensas contra esta amenaza, consulta el artículo Cómo protege Google sus servicios de producción.
Atacante externo con acceso lógico: los atacantes externos pueden acceder a un entorno de Google Cloud y tratar de moverse lateralmente a otras máquinas para obtener acceso a datos sensibles. Una táctica habitual que utilizan los atacantes externos es empezar vulnerando la cuenta de un empleado o contratista legítimo.
En el siguiente diagrama se muestra qué parte del entorno de nube es más vulnerable a estas amenazas.
Superficie de ataque a servidores de centros de datos
En la siguiente tabla se describen las superficies de ataque que son aspectos típicos de los servidores de centros de datos. La arquitectura de seguridad de hardware Titanium se ha diseñado para ofrecer una protección sólida frente a este tipo de amenazas.
| Atacante | Objetivo | Superficie de ataque | Riesgo |
|---|---|---|---|
Empleado desleal con acceso físico |
Medios de almacenamiento (SSD, HDD o unidades de arranque) |
Unidades y conectores físicos |
Este ataque podría robar una unidad e intentar acceder a ella con las herramientas del atacante. |
DIMM |
Conectores de memoria física |
Con este ataque, se podría congelar el DIMM, sacarlo del centro de datos e intentar acceder a los datos que contiene con las herramientas del atacante. Esta amenaza se denomina a veces ataque de arranque en frío. |
|
Servidor |
Conectores USB o PCIe |
Este ataque podría conectar hardware malicioso al servidor. Con el hardware malicioso, el atacante podría intentar ejecutar código o extraer datos residentes. |
|
Placa base |
Grupo de acceso a pruebas conjuntas (JTAG) y puerto de depuración extendido (XDP) |
Este ataque podría conectar una herramienta de depuración de hardware para obtener la ejecución de código o acceder a los datos que se procesan en la CPU. |
|
Red |
Cables Ethernet |
Con este ataque, se podría pinchar un cable Ethernet para acceder a todos los datos que se transfieren entre dispositivos. De esta forma, se podría observar cualquier tráfico de texto no cifrado. |
|
Placa base |
Firmware |
Este ataque podría introducir firmware malicioso persistente. Este firmware podría estar preinstalado por un fabricante que haya sufrido una brecha de seguridad, interceptado durante el transporte o actualizado por un usuario interno. Esta amenaza puede provocar que el hardware se hackee previamente con rootkits que proporcionen acceso a la puerta trasera del servidor. |
|
Empleado interno no autorizado con acceso lógico |
Carga de trabajo de computación (por ejemplo, máquinas virtuales) |
Puntos de acceso |
En este ataque se podrían usar credenciales de empleados para acceder directamente a las máquinas virtuales o a los hosts, así como a los datos que contienen. |
Router de tejido |
Acceso físico o administrativo |
Con este ataque, se podría obtener el control de superusuario de un router de la estructura para espiar todo el tráfico y extraer o manipular cualquier dato en texto sin formato que esté en tránsito en la estructura. |
|
Placa base |
Firmware |
Este ataque podría enviar imágenes de firmware defectuosas a las placas base, lo que haría que dejaran de funcionar permanentemente y que los datos no se pudieran recuperar. Un atacante podría enviar firmware con vulnerabilidades conocidas a las máquinas para recuperar el control mediante exploits que permitan la ejecución de código remoto. |
|
Atacante externo con acceso lógico |
Servidor |
VMs |
Este ataque podría lanzar patrones de ataques de canal lateral públicos en las VMs. Estos ataques podrían filtrar datos de instancias que se ejecutan en el mismo hardware o del software del sistema host. |
SSDs |
VMs |
Este ataque podría usar el acceso directo a las unidades SSD PCIe para intentar inferir datos de los coarrendatarios. |
|
Memoria |
VMs |
Este vector de ataque podría usar canales laterales para buscar claves de cifrado valiosas en la memoria. |
|
Servidor |
Máquinas virtuales Bare Metal |
Este vector de ataque podría usar instancias de hardware para analizar todos los periféricos en busca de un componente vulnerable que les permitiera permanecer en la máquina y atacar a los inquilinos posteriores. |
Asignación de componentes de hardware de Titanium a amenazas
La arquitectura de seguridad de hardware Titanium usa un enfoque multicapa para ayudar a abordar amenazas de infraestructura específicas y evitar puntos únicos de fallo. Estas amenazas pueden deberse a errores o a agentes malintencionados. Las amenazas abarcan las operaciones de hardware y pueden aprovechar vulnerabilidades en servidores, redes y el plano de control. No existe una única solución que pueda hacer frente a todos estos vectores de ataque, pero las funciones combinadas de Titanium ayudan a proteger los datos de nuestros usuarios y nuestras instancias de computación en la nube.
Situación: operaciones de hardware no autorizadas
Las operaciones de hardware no autorizadas suponen una amenaza para la seguridad de los datos, ya que pueden provocar la filtración de datos de los centros de datos y la modificación del hardware y del firmware. La arquitectura de seguridad de hardware Titanium de Google ayuda a protegerse frente a estas amenazas mediante una serie de medidas de seguridad, como las raíces de confianza criptográficas, las placas base personalizadas y los procesadores de E/S. Estos componentes trabajan conjuntamente para proporcionar una defensa por capas resistente a una amplia gama de ataques.
En la siguiente tabla se describen algunas de las amenazas de hardware no autorizado y cómo puede mitigarlas la arquitectura de Titanium.
| Amenaza | Mitigación de Titanium |
|---|---|
Un atacante extrae unidades de datos individuales de los centros de datos para acceder a los datos que contienen. |
Las claves de cifrado de datos en reposo de los productos y servicios de almacenamiento nunca se almacenan de forma persistente en las máquinas a las que se conectan los medios de almacenamiento. Las funciones de cifrado automático integradas en los medios de almacenamiento también están habilitadas para la defensa en profundidad y usan claves que nunca se almacenan de forma persistente en el propio medio. Los RTMs de Caliptra permiten a Google incluir la identidad de hardware de raíz de confianza y la integridad del firmware entre las condiciones de autorización que se requieren para liberar claves de un servicio de gestión de claves a instancias de un servicio de almacenamiento. Las máquinas que se hayan configurado de forma malintencionada con un firmware no deseado no pueden acceder a las claves necesarias para descifrar los datos almacenados. Las RoTs insertadas en los paquetes de silicio anclan las identidades criptográficas relevantes en el paquete del chip. Los interposers de función única son la parte principal de nuestra seguridad de plano de datos y cifran los datos en cada paso de procesamiento. Los TOPs ofrecen las siguientes ventajas:
Se utilizan soluciones de software probadas, como dm-crypt, para unidades de menor rendimiento en las que es fundamental reducir la superficie de ataque, como en algunos casos de uso de unidades de arranque. |
Un atacante pincha un cable de red y lee los bytes del cable de cobre o de fibra. |
Los TOPs cifran los datos en tránsito, lo que elimina la posibilidad de que una amenaza pueda rastrear datos valiosos en la red. Nuestras NICs usan el estándar de descarga de hardware PSP. Este estándar proporciona un cifrado rentable con una disminución mínima del rendimiento. Estas implementaciones cumplen los estándares FIPS. Los datos de los clientes se cifran cuando se transfieren a través de los switches Top of Rack (ToR) o de la estructura. Parte de la infraestructura de aprendizaje automático usa mecanismos de seguridad de transporte propietarios. |
Un atacante sustituye los chips flash que contienen código mutable en el centro de datos o en la cadena de suministro para ejecutar código malicioso en los servidores. |
Los chips Titan se han diseñado para rechazar el ataque y no proporcionan acceso a las credenciales almacenadas en su interior. Aunque un atacante reescriba el contenido de los chips flash no volátiles, la raíz de confianza de Titan informa de forma segura a la capa de control de Google sobre una medición del código, que está diseñada para bloquear el dispositivo. Google revoca de forma rutinaria el código obsoleto o con vulnerabilidades conocidas a escala global en nuestra flota mediante el uso de chips Titan. |
Un atacante inserta dispositivos adversarios en las interfaces físicas de los servidores o tarjetas de un centro de datos para ejecutar código malicioso o extraer datos. |
Los diseños de placa base personalizados eliminan las interfaces que se usan para insertar dispositivos adversarios. Las configuraciones de la unidad de gestión de memoria de entrada/salida (IOMMU) se han implementado para evitar los errores de PCIe en todo nuestro firmware. Los screamers de PCIe están diseñados para leer y escribir paquetes arbitrarios en la estructura de PCIe. A medida que el sector madura, complementamos esta protección con PCI IDE para mitigar los efectos de los interponedores de PCI más sofisticados. ALTS y TLS son las únicas conexiones de red de autenticación y autorización aceptadas para las funciones de control y gestión en los TOPs y los BMCs. Los RTMs de Caliptra bloquean cualquier firmware no aprobado. Nuestros periféricos de confianza certifican su identidad de hardware y la integridad del código en nuestro plano de control, y ningún servidor se admite en producción si el registro de certificación no coincide con la intención del hardware y el software. |
Un atacante usa un ataque de arranque en frío en el centro de datos para acceder a los datos de la RAM. |
El cifrado en memoria de Confidential Computing protege cualquier dato sensible o clave de cifrado en la RAM. El cifrado de DRAM también está habilitado en las máquinas que se implementan sin Confidential Computing en centros de datos perimetrales con un nivel de garantía inferior. |
Situación: explotación de servidores o redes por parte de usuarios no autorizados
Los atacantes pueden usar la nube pública para alojar sus cargas de trabajo maliciosas en nuestra infraestructura compartida y para depositar datos en nuestros servicios públicos. Los adversarios externos, desde personas individuales hasta Estados-nación, también pueden intentar obtener acceso privilegiado remoto.
Para mitigar estas acciones, la arquitectura de seguridad de hardware de Titanium usa chips Titan y Caliptra RTM para aprovisionar credenciales de tiempo de ejecución de forma segura y limitar los privilegios en el hardware y los sistemas operativos. Confidential Computing ayuda a proteger frente a la manipulación de la memoria del sistema, ya sea física o mediante ataques de hipervisor, y los chips Titan rechazan o detectan las actualizaciones de software no autorizadas.
En la siguiente tabla se describen algunas de las amenazas de explotación de servidores y redes, así como la forma en que la arquitectura de Titanium puede mitigarlas.
| Amenaza | Mitigación de Titanium |
|---|---|
Un atacante aprovecha una vulnerabilidad para escapar de su máquina virtual y obtener acceso a los datos y a otras máquinas virtuales que se ejecutan en la misma máquina. |
Los enclaves de Confidential Computing reducen la filtración externa de datos de cargas de trabajo, ya estén en proceso o en reposo. Esta mitigación impide que un atacante que haya eludido la VM acceda a los datos en uso. Los chips Titan y los módulos RTM de Caliptra impiden que el atacante tenga acceso persistente. Es probable que se detecte cualquier intento de acceso persistente, ya que la configuración de la máquina no coincidirá con la configuración ni con la política de código de ese servidor. Este paso es obligatorio para que la máquina pueda alojar cargas de trabajo de producción después de un reinicio. |
Un atacante lanza patrones de ataque de canal lateral públicos en las VMs. |
Nuestro sistema de gestión de flotas, que utiliza chips Titan, puede revocar software con vulnerabilidades conocidas. La revocación puede bloquear cualquier ataque posterior dirigido a estas vulnerabilidades conocidas. Las mediciones de integridad basadas en Titan también ofrecen una alta confianza en que las mitigaciones, que pueden necesitar desplegarse urgentemente, se han desplegado en las máquinas de destino. Reforzamos este enfoque manteniéndonos a la vanguardia de la investigación y la mitigación de los canales laterales mediante técnicas como retpoline y la programación de núcleos, así como con investigaciones avanzadas sobre Meltdown, Spectre, Zenbleed y Downfall, entre otros. |
Un atacante usa el acceso directo a SSDs que proporcionan almacenamiento a varios arrendatarios para intentar inferir datos de otros arrendatarios. |
El cifrado de datos en reposo ayuda a proteger frente a ataques lógicos y físicos con una variedad de intermediarios. En el caso de los recursos que no se comparten, los datos de cada inquilino se cifran con claves diferentes, lo que reduce la posibilidad de que se produzcan ataques de acceso directo contra la unidad SSD. |
Un atacante analiza la memoria y usa canales laterales para buscar claves de cifrado de datos o credenciales. |
Los chips Titan permiten aprovisionar credenciales selladas por máquina. Aunque un atacante obtenga acceso de superusuario en una máquina, sus credenciales solo se vinculan a la identidad privada del chip Titan local. |
Un atacante compra instancias de hardware y analiza todos los periféricos para intentar obtener acceso persistente. |
Los chips Titan rechazan cualquier actualización de software no autorizada, incluidas las inserciones maliciosas para obtener un control persistente. Nuestro flujo de trabajo de la máquina confirma de forma positiva las mediciones de integridad esperadas en un ciclo de encendido completo del sistema certificado entre clientes de metal desnudo. |
Situación: explotación de servidores o redes por un comportamiento inadecuado del plano de control
Los insiders del plano de control no autorizados pueden intentar aprovecharse de los sistemas de Google de varias formas, como intentar obtener el control raíz de un router de la estructura, enviar imágenes de firmware defectuosas a las placas base y espiar el tráfico de la red. La arquitectura de seguridad de hardware de Titanium se defiende de estas amenazas mediante diversos mecanismos, como los chips Titan, los módulos RTM de Caliptra, las placas base personalizadas y los servicios aislados tolerantes a fallos del backend.
En la siguiente tabla se describen algunas de las amenazas del plano de control y cómo puede mitigarlas la arquitectura de Titanium.
| Amenaza | Mitigación de Titanium |
|---|---|
Un atacante usa credenciales de empleado para acceder a las VMs de Compute Engine que sirven de capa fundamental para los entornos de los clientes. |
Los TOPs ayudan a asegurar que los administradores no tengan acceso a los entornos de los clientes. Sin acceso, el personal de Google no puede usar sus credenciales para acceder a la capa de hardware y software privilegiada que se encuentra debajo de las máquinas virtuales de nuestros clientes. Se ha bloqueado el acceso interno de Google a los datos de los clientes porque solo se puede acceder a los datos a través de APIs definidas. |
Un atacante envía imágenes de firmware defectuosas a gran escala a las placas base, lo que las inutiliza de forma permanente. |
Los RoTs de los chips Titan rechazan cualquier actualización de software no autorizada, incluidas las inserciones maliciosas para obtener un control persistente. Los diseños de placa base personalizados usan una red alternativa de señales que interconectan todos nuestros RoTs con el RoT de la plataforma. La RoT de la plataforma contiene firmware de copia de seguridad para dispositivos críticos. Aunque un atacante inutilizara la red y la PCI, la red fuera de banda (OOB) puede restaurar el sistema. |
Un atacante envía firmware de producción obsoleto y con vulnerabilidades conocidas a las máquinas para recuperar el control mediante vulnerabilidades públicas. |
Los chips Titan rechazan los pases incorrectos y ayudan a aplicar la revocación del código con vulnerabilidades conocidas. Certifican la versión de firmware que se ha implementado en la máquina y rechazan la máquina en el plano de control. Esta medida de mitigación ayuda a evitar que se ejecuten tareas en una máquina que no funciona correctamente y activa una investigación o una reparación según sea necesario. |
Un atacante abusa de las funciones de depuración de silicio necesarias para la continuidad del negocio, que proporcionan el nivel más alto concebible de acceso a los datos en los sistemas de servidores. |
Caliptra RTM ayuda a asegurar que todos los parámetros que habilitan interfaces de depuración invasivas, ya estén conectadas lógicamente o mediante inserción física directa, se configuren de forma fiable, se midan criptográficamente y se comuniquen a nuestro plano de control mediante un protocolo de certificación. Solo las máquinas que se encuentran en el estado previsto pueden acceder para servir cargas de trabajo de producción. |
Un atacante obtiene el control de un servicio de backend para poder acceder a los entornos de los clientes. |
Los servicios regionalizados tolerantes a fallos del backend son una infraestructura de credenciales regionalizada que no permite el acceso humano unilateral. Además de impedir que los operadores inicien sesión en los nodos de computación, tampoco pueden iniciar sesión en el plano de control para obtener material de claves. Los enclaves de computación confidencial de la arquitectura Titanium aíslan nuestros servicios de autorización y aprovisionamiento de claves de backend de los privilegios de superusuario de la máquina. Las jerarquías de claves ayudan a proteger las claves de firma y autorización de la mayoría de los servicios. Con las jerarquías de claves, las claves raíz se encuentran en claves aisladas que se almacenan en HSMs y cajas fuertes, o bien en claves que se almacenan en producción mediante un cuórum de Paxos de almacenes de datos en memoria. |
Siguientes pasos
- Consulta la información general sobre el diseño de seguridad de la infraestructura.
- Implementa Confidential Computing.