Este conteúdo foi atualizado pela última vez em maio de 2024 e representa o status quo no momento em que foi escrito. As políticas e os sistemas de segurança da Google podem mudar no futuro, à medida que melhoramos continuamente a proteção dos nossos clientes.
Este documento descreve a abordagem da Google à atestação de máquinas de centros de dados. A arquitetura descrita neste documento foi concebida para ser integrada com normas abertas, como o Trusted Platform Module (TPM), o Security Protocol and Data Model (SPDM) e o Redfish. Para novas normas ou implementações de referência propostas pela Google e relacionadas com a atestação de máquinas de centros de dados, consulte o nosso projeto Platform Integrity (PINT) no GitHub. Este documento destina-se a executivos de segurança, arquitetos de segurança e auditores.
Vista geral
Cada vez mais, a Google concebe e implementa máquinas de centros de dados desagregadas. Em vez de uma única raiz de fidedignidade, muitas máquinas contêm raízes de fidedignidade separadas, incluindo raízes de fidedignidade para medição (RTM), armazenamento, atualização e recuperação. Cada RTM serve uma subsecção de toda a máquina. Por exemplo, uma máquina pode ter um RTM que mede e atesta o que foi iniciado na CPU principal e outro RTM que mede e atesta o que foi iniciado numa SmartNIC ligada a um slot PCIe. O diagrama seguinte mostra um exemplo de uma máquina.
A complexidade de vários RTMs numa máquina aumenta a enorme escala e as expectativas das máquinas dos centros de dados, bem como as várias complicações que podem ocorrer devido a falhas humanas, de hardware ou de software. Em resumo, garantir a integridade do firmware da nossa frota é uma tarefa não trivial.
O sistema descrito neste documento foi concebido para tornar o problema da atestação remota para máquinas desagregadas mais gerível. Esta infraestrutura de atestação é extensível, o que lhe permite adaptar-se para servir máquinas cada vez mais complexas à medida que aparecem no centro de dados.
Ao partilhar este trabalho, pretendemos dar a nossa perspetiva sobre como a atestação de máquinas desagregada pode ser feita em grande escala. Através da colaboração com parceiros da indústria e contribuições para organismos de normas, como a Distributed Management Task Force (DMTF), o Trusted Computing Group (TCG) e o Open Compute Project (OCP), pretendemos continuar a apoiar a inovação em segurança neste espaço.
Propriedades RTM recomendadas
Esta secção apresenta algumas propriedades que recomendamos para RTMs.
Integração de hardware RTM
Quando um processador é sincronizado com um RTM, o RTM deve captar as medições sobre o primeiro código mutável que é executado nesse processador. O código mutável subsequente deve ter as respetivas medições capturadas e comunicadas a uma raiz de confiança antes de o código ser executado. Esta disposição produz uma cadeia de arranque medida que permite uma atestação robusta do estado crítico para a segurança do processador.
Atestação de identidade de hardware e firmware da RTM
Cada RTM deve ter um par de chaves de assinatura que é usado para emitir atestações para validação externa. A cadeia de certificados deste par de chaves deve incluir provas criptográficas da identidade de hardware exclusiva do RTM e da identidade de firmware para qualquer código mutável que seja executado no RTM. A cadeia de certificados deve ter origem no fabricante do RTM. Esta abordagem permite que as máquinas recuperem de vulnerabilidades críticas do firmware RTM.
A especificação Device Identifier Composition Engine (DICE) é uma formalização do padrão usado na nossa solução de atestação. O fabricante do RTM certifica um par de chaves do dispositivo exclusivo, que certifica um par de chaves de alias específico da identidade do hardware e da imagem do firmware do RTM. A cadeia de certificados da chave de alias contém uma medição do firmware RTM e o número de série do RTM. Os validadores podem ter a certeza de que todos os dados assinados por uma determinada chave de alias foram emitidos por um RTM descrito pelas medições de identidade de hardware e firmware criptográficas incorporadas na cadeia de certificados dessa chave de alias.
Operações de atestação remota
O esquema de atestação foi concebido para garantir que os dados e as tarefas do utilizador só são emitidos para máquinas que estão a executar a respetiva pilha de arranque pretendida, ao mesmo tempo que permite que a automatização da manutenção da frota ocorra em grande escala para corrigir problemas. O serviço de agendamento de tarefas, alojado na nossa nuvem interna, pode desafiar a recolha de RTMs na máquina e comparar as medições atestadas resultantes com uma política exclusiva dessa máquina. O agendador só emite tarefas e dados do utilizador para máquinas se as medições atestadas estiverem em conformidade com a política da máquina.
A atestação remota inclui as duas operações seguintes:
Geração de políticas de atestação, que ocorre sempre que o hardware ou o software pretendido de um computador é alterado.
Validação da atestação, que ocorre em pontos definidos nos nossos fluxos de gestão de máquinas. Um destes pontos é imediatamente antes de o trabalho ser agendado numa máquina. A máquina só ganha acesso a tarefas e dados do utilizador depois de a validação da atestação ser aprovada.
A política de atestação
A Google usa um documento legível por máquina assinado, denominado política, para descrever o hardware e o software que se espera que estejam em execução numa máquina. Esta política pode ser atestada pela recolha de RTMs da máquina. Os seguintes detalhes de cada RTM estão representados na política:
- O certificado de raiz de identidade fidedigno que pode validar as atestações emitidas pelo RTM.
- A identidade do hardware globalmente exclusiva que identifica exclusivamente o RTM.
- A identidade do firmware que descreve a versão esperada que o RTM deve estar a executar.
- As expectativas de medição para cada fase de arranque comunicada pelo RTM.
- Um identificador para o RTM, análogo a um nome de recurso do Redfish.
- Um identificador que associa o RTM à respetiva localização física numa máquina. Este identificador é análogo ao nome de um recurso do Redfish e é usado por sistemas de reparação de máquinas automatizados.
Além disso, a política também contém um número de série de revogação globalmente único que ajuda a evitar a reversão não autorizada de políticas. O diagrama seguinte mostra uma política.
O diagrama mostra os seguintes itens na política:
- A assinatura fornece autenticação de políticas.
- O número de série da revogação fornece atualidade à política para ajudar a evitar a reversão.
- As expetativas de RTM enumeram detalhes para cada RTM na máquina.
As secções seguintes descrevem estes itens mais detalhadamente.
Compilação de políticas
Quando o hardware de uma máquina é montado ou reparado, é criado um modelo de hardware que define os RTMs esperados nessa máquina. O nosso plano de controlo ajuda a garantir que estas informações permanecem atualizadas em eventos como reparações que envolvem trocas de peças ou atualizações de hardware.
Além disso, o plano de controlo mantém um conjunto de expetativas sobre o software que se destina a ser instalado numa máquina, juntamente com expetativas sobre quais os RTMs que devem medir que software. O plano de controlo usa estas expetativas, juntamente com o modelo de hardware, para gerar uma política de atestação assinada e revogável que descreve o estado esperado da máquina.
A política assinada é, em seguida, escrita no armazenamento persistente na máquina que descreve. Esta abordagem ajuda a reduzir o número de dependências de rede e de serviços necessárias pelo validador remoto ao atestar uma máquina. Em vez de consultar uma base de dados para a política, o validador pode obter a política da própria máquina. Esta abordagem é uma funcionalidade de design importante, uma vez que os programadores de tarefas têm requisitos de SLO rigorosos e têm de permanecer altamente disponíveis. A redução das dependências de rede destas máquinas noutros serviços ajuda a reduzir o risco de indisponibilidades. O diagrama seguinte mostra este fluxo de eventos.
O diagrama descreve os seguintes passos que o plano de controlo conclui no processo de montagem de políticas:
- Deriva a política de atestação da atribuição do pacote de software e do modelo de hardware do computador.
- Assina a política.
- Armazena a política na máquina do centro de dados.
Revogação de políticas
A intenção de hardware e software de uma determinada máquina muda ao longo do tempo. Quando a intenção muda, as políticas antigas têm de ser revogadas. Cada política de atestação assinada inclui um número de série de revogação exclusivo. Os validadores obtêm a chave pública adequada para autenticar uma política assinada e a lista de revogação de certificados adequada para garantir que a política ainda é válida.
Consultar interativamente um servidor de chaves ou uma base de dados de revogação afeta a disponibilidade dos programadores de tarefas. Em alternativa, a Google usa um modelo assíncrono. O conjunto de chaves públicas usadas para autenticar políticas de atestação assinadas é enviado por push como parte da imagem do sistema operativo base de cada máquina. A CRL é enviada de forma assíncrona através do mesmo sistema de implementação de revogação centralizado que a Google usa para outros tipos de credenciais. Este sistema já foi concebido para um funcionamento fiável em condições normais, com a capacidade de realizar envios rápidos de emergência em condições de resposta a incidentes.
Ao usar chaves públicas de validação e ficheiros CRL armazenados localmente na máquina do validador, os validadores podem validar declarações de atestação de máquinas remotas sem ter serviços externos no caminho crítico.
Obter políticas de atestação e validar medições
O processo de atestação remota de uma máquina consiste nas seguintes fases:
- Obter e validar a política de atestação.
- Obter medições atestadas das RTMs da máquina.
- Avaliar as medições atestadas em função da política.
O diagrama e as secções seguintes descrevem estas fases mais detalhadamente.
Obter e validar a política de atestação
O validador remoto obtém a política de atestação assinada para a máquina. Conforme mencionado na compilação de políticas, por motivos de disponibilidade, a política é armazenada como um documento assinado na máquina de destino.
Para verificar se a política devolvida é autêntica, o validador remoto consulta a cópia local do validador da CRL relevante. Esta ação ajuda a garantir que a política obtida foi assinada criptograficamente por uma entidade fidedigna e que a política não foi revogada.
Obtenção de medições atestadas
O validador remoto desafia a máquina, pedindo medições a cada RTM. O validador garante a atualidade incluindo números aleatórios criptográficos nestes pedidos. Uma entidade no dispositivo, como um controlador de gestão da placa base (BMC), encaminha cada pedido para o respetivo RTM, recolhe as respostas assinadas e envia-as de volta para o validador remoto. Esta entidade no dispositivo não tem privilégios do ponto de vista da atestação, uma vez que serve apenas como um transporte para as medições assinadas da RTM.
A Google usa APIs internas para atestar as medições. Também contribuímos com melhorias para o Redfish, de modo a permitir que os validadores externos desafiem um BMC para as medições de um RTM através do SPDM. O encaminhamento interno da máquina é feito através de protocolos e canais específicos da implementação, incluindo o seguinte:
- Redfish sobre sub-rede
- Intelligent Platform Management Interface (IPMI)
- Management Component Transport Protocol (MCTP) over i2c/i3c
- PCIe
- Serial Peripheral Interface (SPI)
- USB
Avaliação das medições atestadas
O validador remoto da Google valida as assinaturas emitidas por cada RTM, garantindo que têm origem na identidade do RTM incluída na política de atestação da máquina. As identidades de hardware e firmware presentes na cadeia de certificados do RTM são validadas em função da política, o que garante que cada RTM é a instância correta e executa o firmware correto. Para garantir a atualidade, o nonce criptográfico assinado é verificado. Por último, as medições atestadas são avaliadas para garantir que correspondem às expetativas da política para esse dispositivo.
Reagir aos resultados da atestação remota
Após a atestação estar concluída, os resultados têm de ser usados para determinar o destino da máquina que está a ser atestada. Conforme mostrado no diagrama, existem dois resultados possíveis: a atestação é bem-sucedida e são emitidas credenciais de tarefas e dados do utilizador para a máquina, ou a atestação falha e são enviados alertas para a infraestrutura de reparações.
As secções seguintes fornecem mais informações sobre estes processos.
Falha na atestação
Se a atestação de uma máquina não for bem-sucedida, a Google não usa a máquina para servir tarefas de clientes. Em alternativa, é enviado um alerta para a infraestrutura de reparações, que tenta repor automaticamente a imagem da máquina. Embora as falhas de atestação possam dever-se a intenções maliciosas, a maioria das falhas de atestação deve-se a erros nas implementações de software. Por conseguinte, as implementações com falhas de atestação crescentes são interrompidas automaticamente para ajudar a evitar que mais máquinas falhem a atestação. Quando este evento ocorre, é enviado um alerta aos SREs. Para máquinas que não são corrigidas pela reformatação automática, a implementação é revertida ou é feita uma implementação de software corrigido. Até que uma máquina seja novamente submetida a uma atestação remota bem-sucedida, não é usada para processar tarefas de clientes.
Atestação bem-sucedida
Se a atestação remota de uma máquina for bem-sucedida, a Google usa a máquina para publicar tarefas de produção, como VMs para clientes ou processamento de imagens para o Google Fotos. Google Cloud A Google requer ações de tarefas significativas que envolvam serviços em rede para serem protegidas por credenciais de tarefas LOAS de curta duração. Estas credenciais são concedidas através de uma ligação segura após um desafio de atestação bem-sucedido e fornecem privilégios exigidos pela tarefa. Para mais informações acerca destas credenciais, consulte o artigo Segurança da camada de transporte da aplicação.
A atestação de software só é tão boa quanto a infraestrutura que cria esse software. Para ajudar a garantir que os artefactos resultantes são um reflexo preciso da nossa intenção, investimos significativamente na integridade do nosso pipeline de compilação. Para mais informações acerca de uma norma proposta pela Google para abordar a integridade e a autenticidade da cadeia de abastecimento de software, consulte o artigo Integridade da cadeia de abastecimento de software.
O que se segue?
Saiba como o BeyondProd ajuda as máquinas do centro de dados da Google a estabelecer ligações seguras.