Este contenido se actualizó por última vez en mayo de 2024 y representa el statu quo en el momento de su redacción. Es posible que cambien las políticas y los sistemas de seguridad de Google de ahora en adelante, ya que mejoramos la protección de nuestros clientes de forma continua.
En este documento se describe el enfoque de Google para la certificación de la máquina del centro de datos. La arquitectura que se describe en este documento está diseñada para integrarse a estándares abiertos como Módulo de plataforma segura (TPM), Protocolo de seguridad y modelo de datos (SPDM) yRedfish. Para conocer los estándares nuevos o las implementaciones de referencia que sugiere Google y se relacionan con la certificación de la máquina del centro de datos, consulta nuestro proyecto Integridad de la plataforma (PINT) en GitHub. Este documento está dirigido a ejecutivos de seguridad, arquitectos de seguridad y auditores.
Descripción general
Cada vez más, Google diseña y, además, implementa máquinas de centros de datos desagregadas. En lugar de una sola raíz de confianza, muchas máquinas tienen 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 entrega una subsección de toda la máquina. Por ejemplo, una máquina puede tener una RTM que mide y certifica lo que se inició en la CPU principal, y otra RTM que mide y certifica lo que se inició en una SmartNIC que está conectada a una ranura PCIe. En el siguiente diagrama, se muestra una máquina de ejemplo.
La complejidad de varias RTM en una máquina se agrega a la enorme escala y a las expectativas de las máquinas de los centros de datos, así como a muchas complicaciones que pueden ocurrir debido a fallas humanas, de hardware o de software. En resumen, garantizar la integridad del firmware de nuestra flota es una tarea importante.
El sistema descrito en este documento está diseñado para facilitar la administración del problema de la certificación remota de las máquinas desagregadas. Esta infraestructura de certificación es extensible, lo que le permite adaptarse para entregar máquinas cada vez más complejas como aparecen en el centro de datos.
Cuando compartimos este trabajo, buscamos proporcionar nuestra perspectiva sobre cómo se puede realizar la certificación desagregada de la máquina a gran escala. Queremos seguir brindando asistencia a la innovación en seguridad en este espacio mediante la colaboración con socios de la industria y contribuciones a cuerpos de estándares como Distributed Management Task Force (DMTF), Trusted Computing Group (TCG) y Open Compute Project (OCP).
Propiedades de RTM recomendadas
En esta sección, se presentan algunas propiedades que recomendamos para los RTM.
Integración de hardware de RTM
Cuando un procesador se vincula con una RTM, esta debe capturar las medidas en el primer código mutable que se ejecuta en ese procesador. Las medidas del código mutable posterior deberían capturarse y, además, informarse a una raíz de confianza antes de que se ejecute el código. Esta disposición produce una cadena de inicio medido que permite una certificación sólida del estado crítico de seguridad del procesador.
Certificación de identidad de firmware y hardware de RTM
Cada RTM debe tener un par de claves de firma que se use para emitir certificaciones para la validación externa. La cadena de certificados de este par de claves debe incluir evidencia criptográfica de la identidad de hardware única de la RTM y la identidad del firmware para cualquier código mutable que se ejecute dentro de la RTM. La cadena de certificados debe tener permisos de administrador en el fabricante de RTM. Este enfoque permite que las máquinas se recuperen de las vulnerabilidades críticas del firmware de RTM.
La especificación Device Identifier Composition Engine (DICE) es una formalización del patrón que se usa en nuestra solución de certificación. El fabricante de RTM certifica un par de claves de dispositivo único, que certifica un par de claves de alias que es específico de la identidad de hardware y la imagen del firmware de RTM. La cadena de certificados de claves de alias contiene una medida del firmware RTM y el número de serie de la RTM. Los verificadores pueden estar seguros de que los datos firmados por una clave de alias determinada se emitieron desde una RTM descrita por las mediciones de identidad de firmware y hardware criptográfico que están incorporadas en la cadena de certificados de esa clave de alias.
Operaciones de certificación remota
El esquema de certificación está diseñado para garantizar que los datos y trabajos del usuario solo se emitan a las máquinas que ejecutan la pila de inicio prevista y, al mismo tiempo, permite que la automatización del mantenimiento de la flota se realice a gran escala para solucionar problemas. El servicio de programador de trabajos, alojado en nuestra nube interna, puede desafiar la recopilación de RTM dentro de la máquina y comparar las mediciones certificadas resultantes con una política que es exclusiva de esa máquina. El programador solo emite trabajos y datos del usuario a las máquinas si las mediciones certificadas cumplen con la política de la máquina.
La certificación remota incluye las siguientes dos operaciones:
La generación de políticas de certificación, que ocurre cada vez que se cambia el hardware o software previsto de una máquina.
La verificación de la certificación, que se realiza en puntos definidos de nuestros flujos de administración de máquinas. Uno de estos puntos se encuentra justo antes de que el trabajo se programe en una máquina. La máquina solo obtiene acceso a trabajos y datos del usuario después de que se aprueba la verificación de certificación.
La política de certificación
Google usa un documento legible por máquina, denominado política, para describir el hardware y el software que se espera que se ejecuten en una máquina. La colección de RTM de la máquina puede certificar esta política. Los siguientes detalles para cada RTM se representan en la política:
- El certificado raíz de identidad de confianza que puede validar las certificaciones que emite la RTM.
- La identidad de hardware única a nivel global que identifica la RTM de forma única.
- La identidad de firmware que describe la versión esperada que debe ejecutarse en la RTM.
- Las expectativas de medición para cada etapa de inicio que informa la RTM.
- Un identificador para la RTM, análogo a un nombre de recurso de Redfish.
- Un identificador que vincula la RTM a su ubicación física dentro de una máquina. Este identificador es análogo a un nombre de recurso de Redfish y lo usan los sistemas automatizados de reparación de máquinas.
Además, la política contiene un número de serie de revocación único a nivel global que ayuda a evitar la reversión de políticas no autorizada. 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 política.
- El número de serie de revocación proporciona actualización de la política para ayudar a evitar la reversión.
- Las expectativas de RTM enumeran detalles para cada RTM en la máquina.
En las siguientes secciones, se describen esos pasos con más detalle.
Ensamble de políticas
Cuando se ensambla o repara el hardware de una máquina, se crea un modelo de hardware que define las RTM esperadas en esa máquina. Nuestro plano de control ayuda a garantizar que esta información permanezca actualizada en todos los eventos, como las reparaciones que implican intercambios de piezas o actualizaciones de hardware.
Además, el plano de control mantiene un conjunto de expectativas sobre el software que se debe instalar en una máquina, junto con las expectativas sobre qué RTM 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 describa el estado esperado de la máquina.
Luego, la política firmada se escribe en el almacenamiento persistente en la máquina que describe. Este enfoque ayuda a reducir la cantidad de dependencias de red y servicio que necesita el verificador remoto cuando certifica una máquina. En lugar de consultar una base de datos para conocer la política, el verificador puede recuperar la política desde la 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 seguir teniendo alta disponibilidad. Reducir las dependencias de red de estas máquinas en otros servicios ayuda a reducir el riesgo de interrupciones. En el diagrama siguiente, se muestra este flujo de eventos.
En el diagrama, se describen los siguientes pasos que se completan en el plano de control en el proceso de ensamble de políticas:
- Deriva la política de certificación de la asignación del paquete de software y el modelo de hardware de la máquina.
- Firma la política.
- Almacena la política en la máquina del centro de datos.
Revocación de políticas
El intent de hardware y software de una máquina determinada cambia con el tiempo. Cuando el intent cambia, las políticas anteriores 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 garantizar que la política aún sea válida.
Consultar de forma interactiva un servidor de claves o una base de datos de revocación afecta la disponibilidad de los programadores de trabajos. En cambio, Google usa un modelo asíncrono. El conjunto de claves públicas que se usan para autenticar las políticas de certificación firmadas se envía como parte de la imagen del sistema operativo base de cada máquina. La CRL se envía de forma asíncrona a través del mismo sistema de implementación de revocación centralizado que Google usa para otros tipos de credenciales. Este sistema ya está diseñado para una operación confiable durante las condiciones normales, con la capacidad de realizar envíos de emergencia rápida durante las condiciones de respuesta ante incidentes.
A través de las claves públicas de verificación y los archivos CRL que se almacenan de forma local en la máquina del verificador, los verificadores pueden validar las declaraciones de certificación de máquinas remotas sin tener ningún servicio externo en la ruta crítica.
Recupera políticas de certificación y valida mediciones
El proceso de certificación remota de una máquina consta de las siguientes etapas:
- Recuperar y validar la política de certificación.
- Obtener medidas certificadas de las RTM de la máquina.
- Evaluar las mediciones certificadas en función de la política.
En el diagrama y las secciones siguientes, se describen con más detalle estas etapas.
Recupera y valida la política de certificación
El verificador remoto recupera la política de certificación firmada de la máquina. Como se mencionó en Ensamble de políticas, por motivos de disponibilidad, la política se almacena como un documento firmado en la máquina de destino.
Para verificar que la política que se muestra sea auténtica, el verificador remoto consulta la copia local del verificador de la CRL relevante. Esta acción ayuda a garantizar que una entidad de confianza firme la política recuperada de forma criptográfica y que la política no se haya revocado.
Obtén medidas certificadas
El verificador remoto desafía a la máquina y solicita mediciones de cada RTM. Para garantizar la actualización, el verificador incluye los nonces criptográficos en estas solicitudes. Una entidad en la máquina, como un controlador de administración de placa base (BMC), enruta cada solicitud a su RTM respectiva, recopila las respuestas firmadas y las envía de vuelta al verificador remoto. Esta entidad en la máquina no tiene privilegios desde la perspectiva de la certificación, ya que solo sirve como transporte para las mediciones firmadas de RTM.
Google utiliza APIs internas para certificar mediciones. También contribuimos con mejoras a Redfish para permitir que los verificadores fuera de la máquina desafíen a un BMC para las medidas de una 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 mediante subred
- Interfaz de administración de plataforma inteligente (IPMI)
- Protocolo de transporte de componentes de administración (MCTP) a través de i2c/i3c
- PCIe
- Interfaz de periférico en serie (SPI)
- USB
Evalúa las mediciones certificadas
El verificador remoto de Google valida las firmas que emite cada RTM, lo que garantiza que establezcan la raíz en la identidad de la RTM que se incluye 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 de RTM se validan con la política, lo que garantiza que cada RTM sea la instancia correcta y ejecute el firmware correcto. Para garantizar la actualización, se verifica el nonce criptográfico firmado. Por último, las mediciones certificadas se evalúan para garantizar que correspondan con las expectativas de la política respecto de ese dispositivo.
Reacciona a los resultados de la certificación remota
Una vez que se completa la certificación, los resultados deben usarse para determinar el destino de la máquina que se certifica. Como se muestra en el diagrama, hay dos resultados posibles: la certificación es correcta y la máquina recibe credenciales de tareas y datos del usuario, o la certificación falla y las alertas se envían a la infraestructura de reparaciones.
En las siguientes secciones, se proporciona más información sobre estos procesos.
Certificación con errores
Si la certificación de una máquina no se realiza de forma correcta, Google no la usa para entregar trabajos de cliente. En su lugar, se envía una alerta a la infraestructura de reparaciones, que intenta volver a crear la imagen automáticamente. Aunque las fallas de certificación pueden deberse a una intención maliciosa, la mayoría de las fallas de certificación se deben a errores en los lanzamientos de software. Por lo tanto, los lanzamientos con fallas de certificación crecientes 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 SRE. En el caso de las máquinas que no se corrigen mediante la reutilización automatizada, el lanzamiento se revierte o hay un lanzamiento de software fijo. No se usa para entregar trabajos del cliente, hasta que una máquina no se someta a una certificación remota exitosa.
La certificación se realizó correctamente
Si la certificación remota de una máquina se realiza de forma correcta, Google usa la máquina para entregar trabajos de producción, como VMs para clientes de Google Cloud o procesamiento de imágenes para Google Fotos. Google requiere que las acciones de trabajo significativas que requieran servicios conectados en red estén protegidas detrás de las credenciales de tareas LOAS de corta duración. Estas credenciales se otorgan a través de una conexión segura después de un desafío de certificación correcto y proporcionan los privilegios que requiere el trabajo. Para obtener más información sobre estas credenciales, consulta Seguridad de transporte de la capa de la aplicación.
La certificación de software es tan buena como la infraestructura que compila ese software. Para garantizar que los artefactos resultantes sean una reflexión precisa de nuestro intent, invertimos significativamente en la integridad de nuestra canalización de compilación. Si deseas obtener más información acerca de 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.
¿Qué sigue?
Descubre cómo BeyondProd ayuda a las máquinas de los centros de datos de Google a establecer conexiones seguras.