Este contenido se actualizó por última vez en mayo 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.
En este documento se describe el enfoque de Google para la atestación de máquinas de centros de datos. La arquitectura descrita en este documento se ha diseñado para integrarse con estándares abiertos, como Trusted Platform Module (TPM), Security Protocol and Data Model (SPDM) y Redfish. Para consultar los nuevos estándares o las implementaciones de referencia que propone Google y que están relacionados con la certificación de máquinas de centros de datos, consulta nuestro proyecto Integridad de la plataforma (PINT) en GitHub. Este documento está dirigido a ejecutivos, arquitectos y auditores de seguridad.
Información general
Cada vez más, Google diseña y despliega máquinas de centros de datos desagregadas. En lugar de una única raíz de confianza, muchas máquinas contienen raíces de confianza independientes, incluidas las raíces de confianza para la medición (RTM), el almacenamiento, la actualización y la recuperación. Cada RTM sirve a una subsección de toda la máquina. Por ejemplo, una máquina puede tener un RTM que mida y certifique lo que se ha iniciado en la CPU principal, y otro RTM que mida y certifique lo que se ha iniciado en una SmartNIC conectada a una ranura PCIe. En el siguiente diagrama se muestra un ejemplo de máquina.
La complejidad de tener varios RTMs en una máquina se suma a la enorme escala y las expectativas de las máquinas de los centros de datos, así como a las numerosas complicaciones que pueden surgir debido a fallos humanos, de hardware o de software. En resumen, asegurar la integridad del firmware de nuestra flota es una tarea compleja.
El sistema descrito en este documento se ha diseñado para que el problema de la atestación remota de máquinas desagregadas sea más fácil de gestionar. Esta infraestructura de atestación es extensible, lo que le permite adaptarse para dar servicio a máquinas cada vez más complejas a medida que aparecen en el centro de datos.
Al compartir este trabajo, nuestro objetivo es ofrecer nuestra perspectiva sobre cómo se puede llevar a cabo la atestación de máquinas desglosada a gran escala. A través de la colaboración con partners del sector y de las contribuciones a organismos de normalización como Distributed Management Task Force (DMTF), Trusted Computing Group (TCG) y Open Compute Project (OCP), tenemos la intención de seguir apoyando la innovación en seguridad en este ámbito.
Propiedades de RTM recomendadas
En esta sección se presentan algunas propiedades que recomendamos para las RTMs.
Integración de hardware de RTM
Cuando un procesador se empareja con un RTM, el RTM debe registrar las mediciones del primer código mutable que se ejecute en ese procesador. El código mutable posterior debe medirse y notificarse a una raíz de confianza antes de que se ejecute. Esta disposición produce una cadena de arranque medida que permite una atestación sólida del estado crítico para la seguridad del procesador.
Atestación de identidad de hardware y firmware de RTM
Cada RTM debe tener un par de claves de firma que se utilice para emitir atestaciones para la validación externa. La cadena de certificados de este par de claves debe incluir pruebas criptográficas de la identidad de hardware única del RTM y de la identidad de firmware de cualquier código mutable que se ejecute en el RTM. La cadena de certificados debe tener como raíz al fabricante de RTM. Este enfoque permite que las máquinas se recuperen de vulnerabilidades críticas del firmware RTM.
La especificación del motor de composición de identificadores de dispositivo (DICE) es una formalización del patrón que se usa en nuestra solución de atestación. El fabricante de RTM certifica un par de claves de dispositivo único, que certifica un par de claves de alias específico de la identidad de hardware y la imagen de firmware de RTM. La cadena de certificados de la clave de alias contiene una medición del firmware RTM y el número de serie del RTM. Los verificadores pueden tener la certeza de que los datos firmados por una clave de alias determinada se han emitido desde un RTM descrito por las mediciones de identidad del hardware y el firmware criptográficos que están insertadas en la cadena de certificados de esa clave de alias.
Operaciones de atestación remota
El esquema de certificación está diseñado para asegurar que los datos y los trabajos de los usuarios solo se emitan a máquinas que ejecuten su pila de arranque prevista, al tiempo que se permite que la automatización del mantenimiento de la flota se produzca a gran escala para solucionar los problemas. El servicio de programación de trabajos, alojado en nuestra nube interna, puede cuestionar la recogida de RTMs en la máquina y comparar las mediciones certificadas resultantes con una política única para esa máquina. El programador solo envía trabajos y datos de usuario a las máquinas si las mediciones atestiguadas se ajustan a la política de la máquina.
La certificación remota incluye las dos operaciones siguientes:
Generación de políticas de certificación, que se produce cada vez que se cambia el hardware o el software previsto de una máquina.
Verificación de la certificación, que se produce en puntos definidos de nuestros flujos de gestión de máquinas. Uno de estos puntos es justo antes de que se programe el trabajo en una máquina. La máquina solo obtiene acceso a las tareas y a los datos de usuario después de que se haya verificado la certificación.
La política de certificación
Google usa un documento firmado legible por máquina, denominado política, para describir el hardware y el software que se espera que se ejecuten en una máquina. Esta política se puede atestiguar mediante la recogida de RTMs del equipo. En la política se incluyen los siguientes detalles de cada RTM:
- El certificado raíz de identidad de confianza que puede validar las certificaciones emitidas por el RTM.
- El identificador de hardware único a nivel mundial que identifica de forma exclusiva el RTM.
- La identidad del firmware que describe la versión esperada que debe ejecutar el RTM.
- Las expectativas de medición de cada fase de arranque que comunica el RTM.
- Un identificador del RTM, análogo a un nombre de recurso de Redfish.
- Un identificador que vincula el RTM con su ubicación física en una máquina. Este identificador es análogo al nombre de un recurso de Redfish y lo usan los sistemas de reparación automática de máquinas.
Además, la política también contiene un número de serie de revocación único a nivel mundial que ayuda a evitar la restauración no autorizada de la política. En el siguiente diagrama se muestra una política.
En el diagrama se muestran los siguientes elementos de la política:
- La firma proporciona autenticación de la política.
- El número de serie de revocación proporciona la actualización de la política para evitar la reversión.
- Las expectativas de RTM enumeran los detalles de cada RTM de la máquina.
En las siguientes secciones se describen estos elementos con más detalle.
Ensamblaje de políticas
Cuando se ensambla o se repara el hardware de una máquina, se crea un modelo de hardware que define los RTMs esperados en esa máquina. Nuestro plano de control ayuda a garantizar que esta información se mantenga actualizada en eventos como las reparaciones que implican cambios de piezas o actualizaciones de hardware.
Además, el plano de control mantiene un conjunto de expectativas sobre el software que se va a instalar en una máquina, así como sobre qué RTMs deben medir qué software. El plano de control usa estas expectativas, junto con el modelo de hardware, para generar una política de certificación firmada y revocable que describe el estado esperado de la máquina.
La política firmada se escribe en el almacenamiento persistente del equipo al que hace referencia. Este enfoque ayuda a reducir el número de dependencias de red y de servicio que necesita el verificador remoto al certificar una máquina. En lugar de consultar una base de datos para obtener la política, el verificador puede obtenerla de la propia máquina. Este enfoque es una característica de diseño importante, ya que los programadores de trabajos tienen requisitos de SLO estrictos y deben mantener una alta disponibilidad. Reducir las dependencias de red de estas máquinas en otros servicios ayuda a reducir el riesgo de interrupciones. En el siguiente diagrama se muestra este flujo de eventos.
En el diagrama se describen los siguientes pasos que completa el plano de control en el proceso de ensamblaje de políticas:
- Deriva la política de atestación de la asignación del paquete de software y del modelo de hardware del dispositivo.
- Firma la política.
- Almacena la política en el equipo del centro de datos.
Revocación de políticas
La intención de hardware y software de una máquina determinada cambia con el tiempo. Cuando cambia la intención, las políticas antiguas deben revocarse. Cada política de certificación firmada incluye un número de serie de revocación único. Los verificadores obtienen la clave pública adecuada para autenticar una política firmada y la lista de revocación de certificados adecuada para asegurarse de que la política sigue siendo válida.
Consultar de forma interactiva un servidor de claves o una base de datos de revocación afecta a la disponibilidad de los programadores de trabajos. En su lugar, Google usa un modelo asíncrono. El conjunto de claves públicas que se utilizan para autenticar las políticas de certificación firmadas se inserta como parte de la imagen del sistema operativo base de cada máquina. La CRL se envía de forma asíncrona mediante el mismo sistema de implementación de revocación centralizado que usa Google para otros tipos de credenciales. Este sistema ya está diseñado para funcionar de forma fiable en condiciones normales, con la capacidad de realizar notificaciones de emergencia rápidas en caso de incidente.
Al usar claves públicas de verificación y archivos CRL almacenados localmente en el equipo del verificador, los verificadores pueden validar las instrucciones de certificación de equipos remotos sin tener ningún servicio externo en la ruta crítica.
Obtener políticas de certificación y validar mediciones
El proceso de certificación remota de una máquina consta de las siguientes fases:
- Recuperando y validando la política de certificación.
- Obtener mediciones atestadas de los RTMs de la máquina.
- Evaluar las mediciones atestadas en comparación con la política.
En el siguiente diagrama y en las secciones posteriores se describen estas fases con más detalle.
Obtener y validar la política de certificación
El verificador remoto obtiene la política de atestación firmada de la máquina. Como se menciona en Ensamblaje de políticas, por motivos de disponibilidad, la política se almacena como un documento firmado en el equipo de destino.
Para verificar que la política devuelta es auténtica, el verificador remoto consulta la copia local de la CRL pertinente del verificador. Esta acción ayuda a asegurarse de que la política obtenida se haya firmado criptográficamente por una entidad de confianza y de que no se haya revocado.
Obtener mediciones certificadas
El verificador remoto reta a la máquina y solicita mediciones de cada RTM. El verificador asegura la actualización incluyendo nonces criptográficos en estas solicitudes. Una entidad en la máquina, como un controlador de gestión de placa base (BMC), ruta cada solicitud a su RTM correspondiente, recoge las respuestas firmadas y las envía de vuelta al verificador remoto. Esta entidad en la máquina no tiene privilegios desde el punto de vista de la certificación, ya que solo sirve como transporte para las mediciones firmadas de RTM.
Google usa APIs internas para certificar las mediciones. También contribuimos a mejorar Redfish para que los verificadores externos puedan desafiar a un BMC para obtener las mediciones de un RTM mediante SPDM. El enrutamiento interno de la máquina se realiza a través de protocolos y canales específicos de la implementación, incluidos los siguientes:
- Redfish a través de una subred
- Interfaz de gestión inteligente de plataforma (IPMI)
- Protocolo de transporte de componentes de gestión (MCTP) a través de i2c/i3c
- PCIe
- Interfaz periférica serie (SPI)
- USB
Evaluar mediciones certificadas
El verificador remoto de Google valida las firmas emitidas por cada RTM, lo que asegura que se remonten a la identidad del RTM incluida en la política de certificación de la máquina. Las identidades de hardware y firmware que están presentes en la cadena de certificados del RTM se validan con la política, lo que asegura que cada RTM sea la instancia correcta y ejecute el firmware correcto. Para asegurar la actualización, se comprueba el nonce criptográfico firmado. Por último, las mediciones atestadas se evalúan para comprobar que se corresponden con las expectativas de la política para ese dispositivo.
Reaccionar a los resultados de la confirmación remota
Una vez completada la certificación, los resultados deben usarse para determinar el estado de la máquina certificada. Como se muestra en el diagrama, hay dos resultados posibles: la certificación se realiza correctamente y la máquina recibe credenciales de tarea y datos de usuario, o la certificación falla y se envían alertas a la infraestructura de reparaciones.
En las siguientes secciones se ofrece más información sobre estos procesos.
Error en la atestación
Si la certificación de una máquina no se realiza correctamente, Google no la utiliza para procesar los trabajos de los clientes. En su lugar, se envía una alerta a la infraestructura de reparaciones, que intenta volver a crear la imagen de la máquina automáticamente. Aunque los errores de certificación pueden deberse a intenciones maliciosas, la mayoría se deben a errores en las implementaciones de software. Por lo tanto, las implementaciones con un número creciente de errores de certificación se detienen automáticamente para evitar que más máquinas fallen en la certificación. Cuando se produce este evento, se envía una alerta a los ingenieros de fiabilidad del sitio. En el caso de las máquinas que no se hayan corregido con la creación de imágenes automatizada, se revertirá el lanzamiento o se lanzará el software corregido. Hasta que una máquina vuelva a someterse a una atestación remota correcta, no se utilizará para atender los trabajos de los clientes.
Atestación correcta
Si la certificación remota de una máquina se realiza correctamente, Google usa la máquina para ofrecer trabajos de producción, como máquinas virtuales para clientes o procesamiento de imágenes para Google Fotos. Google Cloud Google requiere que las acciones de trabajo significativas que impliquen servicios en red estén protegidas con credenciales de tareas LOAS de corta duración. Estas credenciales se conceden a través de una conexión segura tras una prueba de certificación satisfactoria y proporcionan los privilegios necesarios para el trabajo. Para obtener más información sobre estas credenciales, consulta Seguridad en la capa de transporte de aplicaciones.
La atestación de software solo es tan buena como la infraestructura que lo crea. Para asegurarnos de que los artefactos resultantes reflejen con precisión nuestra intención, hemos invertido mucho en la integridad de nuestra canalización de compilación. Para obtener más información sobre un estándar que propuso Google para abordar la integridad y la autenticidad de la cadena de suministro de software, consulta Integridad de la cadena de suministro de software.
Siguientes pasos
Descubre cómo BeyondProd ayuda a las máquinas de los centros de datos de Google a establecer conexiones seguras.