Este conteúdo foi atualizado pela última vez em dezembro de 2022 e representa o estado do momento em que foi escrito. Os sistemas e as políticas de segurança do Google podem mudar no futuro, à medida que a proteção dos clientes é aprimorada.
Este documento descreve a abordagem do Google para atestado de máquina de data center. A arquitetura descrita neste documento foi projetada para ser integrada a padrões abertos, como o Módulo de plataforma confiável (TPM, na sigla em inglês), Protocolo de segurança e modelo de dados (SPDM, na sigla em inglês) e Redfish. Para ver os novos padrões ou implementações de referência propostos pelo Google e relacionados ao atestado de máquina de data center, consulte nosso projeto de Integridade da plataforma (PINT, na sigla em inglês) no GitHub. Este documento é destinado a executivos de segurança, arquitetos de segurança e auditores.
Visão geral
Cada vez mais, o Google projeta e implanta máquinas de data center desagregadas. Em vez de uma única raiz de confiança, muitas máquinas contêm raízes de confiança diferentes, incluindo raízes de confiança para medição (RTM, na sigla em inglês), armazenamento, atualização e recuperação. Cada RTM atende uma subseção de toda a máquina. Por exemplo, uma máquina pode ter um RTM que mede e atesta o que foi inicializado na CPU principal e outro que mede e atesta o que foi inicializado em um SmartNIC conectado a um slot PCIe. O diagrama a seguir mostra um exemplo de máquina.
A complexidade de vários RTMs em uma máquina aumenta a enorme escala e as expectativas das máquinas de data center, além de muitas complicações que podem ocorrer devido a falhas humanas, de hardware ou de software. Em resumo, garantir a integridade do firmware da nossa frota é um esforço não trivial.
O sistema descrito neste documento foi projetado para facilitar o gerenciamento do problema do atestado remoto para máquinas desagregadas. Essa infraestrutura de atestado é extensível, permitindo que ela se adapte para atender máquinas cada vez mais complexas que aparecem no data center.
Ao compartilhar esse trabalho, temos como objetivo fornecer nossa perspectiva de como o atestado de máquina desagregado pode ser feito em escala. Por meio da colaboração com parceiros do setor e contribuições para órgãos de normalização, como o Distributed Management Task Force (DMTF), o Trusted Computing Group (TCG) e o Open Compute Project (OCP), pretendemos continuar oferecendo suporte a inovações de segurança nesse campo.
Propriedades de RTM recomendadas
Esta seção apresenta algumas propriedades recomendadas para RTMs.
Integração de hardware RTM
Quando um processador é pareado com um RTM, o RTM precisa capturar medições no primeiro código mutável executado nesse processador. O código mutável subsequente precisa ter as medições capturadas e relatadas a uma raiz de confiança antes da execução do código. Essa disposição produz uma cadeia de inicialização medida que permite um atestado robusto do estado crítico de segurança do processador.
Atestado de identidade de hardware e firmware RTM
Cada RTM precisa ter um par de chaves de assinatura usado para emitir atestados para validação externa. A cadeia de certificados desse par de chaves precisa incluir evidências criptográficas da identidade do hardware exclusiva do RTM e a identidade do firmware para qualquer código mutável executado no RTM. A cadeia de certificados precisa ter acesso root no fabricante RTM. Essa abordagem permite que as máquinas se recuperem de vulnerabilidades críticas de firmware do RTM.
A especificação do Mecanismo de composição de identificador de dispositivo (DICE, na sigla em inglês) é uma formalização do padrão usado em nossa solução de atestado. O fabricante do RTM certifica um par de chaves de dispositivo exclusivo, que certifica um par de chaves de alias específico para a identidade de hardware e a imagem de firmware do RTM. A cadeia de certificados de chave de alias contém uma medição do firmware do RTM e o número de série do RTM. Os verificadores podem ter 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áficos incorporadas na cadeia de certificados dessa chave de alias.
Operações de atestado remoto
O esquema de atestado é projetado para garantir que os dados do usuário e os jobs sejam emitidos somente para máquinas que executam a pilha de inicialização pretendida, enquanto ainda permitem a automação de manutenção da frota em escala para corrigir problemas. O serviço de programador de jobs, hospedado na nossa nuvem interna, pode desafiar a coleta de RTMs na máquina e comparar as medições atestadas resultantes com uma política exclusiva dessa máquina. O programador só emite jobs e dados do usuário para as máquinas se as medições atestadas estiverem em conformidade com a política da máquina.
O atestado remoto inclui as duas operações a seguir:
Geração de políticas de atestado, que ocorre sempre que o hardware ou software pretendido de uma máquina é alterado.
Verificação de atestado, que ocorre em pontos definidos nos fluxos de gerenciamento de máquinas. Um desses pontos ocorre pouco antes do trabalho ser programado em uma máquina. A máquina só recebe acesso a jobs e dados do usuário após a aprovação da verificação de atestado.
A política de atestado
O Google usa um documento assinado legível por máquina, conhecido como política, para descrever o hardware e o software que se espera que sejam executados em uma máquina. Essa política pode ser atestada pela coleção de RTMs da máquina. Os detalhes a seguir para cada RTM são representados na política:
- O certificado raiz de identidade confiável que pode validar atestados emitidos pelo RTM.
- A identidade de hardware globalmente exclusiva que identifica de forma exclusiva o RTM.
- A identidade do firmware que descreve a versão esperada que o RTM deve estar executando.
- As expectativas de medição para cada estágio de inicialização que é relatado pelo RTM.
- Um identificador do RTM, semelhante a um nome de recurso do Redfish.
- Um identificador que vincula o RTM ao local físico em uma máquina. Esse identificador é análogo a um nome de recurso do Redfish e é usado por sistemas automatizados de reparo de máquina.
Além disso, a política também contém um número de série de revogação globalmente exclusivo que ajuda a evitar a reversão não autorizada de políticas. O diagrama a seguir 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 uma atualização da política para ajudar a evitar a reversão.
- As expectativas de RTM enumeram os detalhes de cada RTM na máquina.
As seções a seguir descrevem esses itens em mais detalhes.
Montagem da política
Quando o hardware de uma máquina é montado ou consertado, é criado um modelo de hardware que define todos os RTMs esperados nela. Nosso plano de controle ajuda a garantir que essas informações permaneçam atualizadas em eventos, como reparos que envolvem trocas de peças ou upgrades de hardware.
Além disso, o plano de controle mantém um conjunto de expectativas sobre o software a ser instalado em uma máquina, junto com as expectativas sobre quais RTMs precisam medir qual software. O plano de controle usa essas expectativas, junto com o modelo de hardware, para gerar uma política de atestado assinada e revogável que descreve o estado esperado da máquina.
A política assinada é, então, gravada no armazenamento permanente na máquina que descreve. Essa abordagem ajuda a reduzir o número de dependências de rede e serviço que são exigidas pelo verificador remoto ao atestar uma máquina. Em vez de consultar a política em um banco de dados, o verificador pode buscar a política na própria máquina. Essa abordagem é um recurso de design importante porque os programadores de jobs têm requisitos rigorosos de SLO e precisam permanecer altamente disponíveis. Reduzir as dependências de rede dessas máquinas em outros serviços ajuda a reduzir o risco de interrupções. No diagrama a seguir, mostramos esse fluxo de eventos.
O diagrama descreve as seguintes etapas que o plano de controle conclui no processo de montagem da política:
- Deriva a política de atestado da atribuição de pacotes de software e do modelo de hardware da máquina.
- Assina a política.
- Armazena a política na máquina do data center.
Revogação de políticas
A intent de hardware e software de uma determinada máquina muda com o tempo. Quando a intent muda, as políticas antigas precisam ser revogadas. Cada política de atestado assinada inclui um número de série de revogação exclusivo. Os verificadores recebem a chave pública apropriada para autenticar uma política assinada e a lista de revogação de certificado apropriada para garantir que a política ainda seja válida.
Consultar interativamente um servidor de chaves ou um banco de dados de revogação afeta a disponibilidade dos programadores de jobs. Em vez disso, o Google usa um modelo assíncrono. O conjunto de chaves públicas usadas para autenticar políticas de atestado assinadas é enviado como parte da imagem básica do sistema operacional de cada máquina. A CRL é enviada de maneira assíncrona usando o mesmo sistema de implantação de revogação centralizado que o Google usa para outros tipos de credenciais. Esse sistema já é projetado para uma operação confiável durante condições normais, com a capacidade de realizar envio rápido de emergência durante condições de resposta a incidentes.
Ao usar chaves públicas de verificação e arquivos CRL armazenados localmente na máquina do verificador, os verificadores podem validar as instruções de atestado das máquinas remotas sem ter nenhum serviço externo no caminho crítico.
Como recuperar políticas de atestado e validar medições
O processo de atestar uma máquina remotamente consiste nas seguintes etapas:
- recuperar e validar a política de atestado;
- receber medições atestadas dos RTMs da máquina;
- avaliar as medições atestadas em relação à política.
O diagrama e as seções a seguir descrevem esses estágios com mais detalhes.
Recuperar e validar a política de atestado
O verificador remoto recupera a política de atestado assinada para a máquina. Como mencionado na Montagem da política, por motivos de disponibilidade, a política é armazenada como um documento assinado na máquina de destino.
Para verificar se a política retornada é autêntica, o verificador remoto consulta a cópia local do verificador da CRL relevante. Essa ação ajuda a garantir que a política recuperada foi assinada criptograficamente por uma entidade confiável e que a política não foi revogada.
Conseguir medições atestadas
O verificador remoto desafia a máquina, solicitando medições de cada RTM. O verificador garante a atualização incluindo valores de uso único criptográficos nessas solicitações. Uma entidade na máquina, como um controlador de gerenciamento de referência (BMC, na sigla em inglês), encaminha cada solicitação ao respectivo RTM, coleta as respostas assinadas e as envia de volta ao verificador remoto. Essa entidade na máquina não é privilegiada de uma perspectiva de atestado, porque serve apenas como um transporte para as medições assinadas do RTM.
O Google usa APIs internas para atestar as medições. Também contribuímos com melhorias para o Redfish para permitir que verificadores fora da máquina desafiem uma BMC para as medições de um RTM usando o SPDM. O roteamento de máquina interno é feito em canais e protocolos específicos da implementação, incluindo:
- Redfish sobre a sub-rede
- Interface de gerenciamento de plataforma inteligente (IPMI, na sigla em inglês)
- Protocolo de transporte de componente de gerenciamento (MCTP, na sigla em inglês) por i2c/i3c
- PCIe
- Interface Periférica Serial (SPI, na sigla em inglês)
- USB
Avaliação de avaliações atestadas
O verificador remoto do Google valida as assinaturas emitidas por cada RTM, garantindo que elas retornem à identidade do RTM incluída na política de atestado da máquina. Todas as identidades de hardware e firmware presentes na cadeia de certificados do RTM são validadas em relação à política, garantindo que cada RTM seja a instância correta e execute o firmware correto. Para garantir a atualização, o valor de uso único criptográfico assinado é verificado. Por fim, as medidas atestadas são avaliadas para garantir que correspondem às expectativas da política para esse dispositivo.
Como reagir a resultados de atestados remotos
Depois que o atestado for concluído, os resultados precisarão ser usados para determinar o destino da máquina que está sendo atestada. Conforme mostrado no diagrama, há dois resultados possíveis: o atestado é bem-sucedido e a máquina recebe credenciais de tarefas e dados do usuário ou o atestado falha e alertas são enviados para a infraestrutura de reparos.
Confira mais informações sobre esses processos nas seções a seguir.
Falha no atestado
Se o atestado de uma máquina não for bem-sucedido, o Google não a usará para atender aos jobs do cliente. Em vez disso, um alerta é enviado para a infraestrutura de reparos, que tenta restaurar a imagem da máquina automaticamente. Embora as falhas de atestado possam ser causadas por intents maliciosas, a maioria das falhas de atestado é causada por bugs nos lançamentos de software. Portanto, os lançamentos com falhas de atestados crescentes são interrompidos automaticamente para evitar que mais máquinas falhem no atestado. Quando esse evento ocorre, um alerta é enviado aos SREs. Para máquinas que não são corrigidas pela recriação automática, o lançamento é revertido ou há uma implantação de software fixo. Até que uma máquina seja aprovada novamente pelo atestado remoto, ela não será usada para exibir os jobs dos clientes.
Atestado bem-sucedido
Se o atestado remoto de uma máquina for bem-sucedido, o Google vai usá-la para atender jobs de produção, como VMs para clientes do Google Cloud ou processamento de imagens para o Google Fotos. O Google exige que todas as ações de job significativas que envolvem serviços em rede sejam controladas por credenciais de tarefa de LOAS de curta duração. Essas credenciais são concedidas por uma conexão segura após um desafio de atestado bem-sucedido e fornecem privilégios exigidos pelo job. Para mais informações sobre essas credenciais, consulte Segurança de transporte da camada de aplicativo.
O atestado do software é tão bom quanto a infraestrutura que o desenvolve. Para ajudar a garantir que os artefatos resultantes sejam um reflexo preciso da nossa intent, investimos significativamente na integridade do pipeline de criação. Para mais informações sobre um padrão proposto pelo Google para abordar a integridade e a autenticidade da cadeia de suprimentos de software, consulte Integridade da cadeia de suprimentos de software.
A seguir
Saiba como a BeyondProd ajuda as máquinas de data center do Google a estabelecer conexões seguras.