Este conteúdo foi atualizado pela última vez em setembro de 2024 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 melhoramos continuamente a proteção dos clientes.
A arquitetura de segurança do hardware Titanium serve como base para os serviços do Google e para muitas das contramedidas de segurança na infraestrutura do Google. O hardware Titanium inclui microcontroladores de segurança, adaptadores de hardware e processadores de transferência que foram desenvolvidos especificamente para lidar com vetores de ataque específicos da infraestrutura do Google.
O hardware Titanium é o avanço mais recente na segurança de infraestrutura abrangente e em constante evolução do Google. Ele ajuda a proteger a integridade, a confidencialidade e a disponibilidade dos dados do usuário. O hardware Titanium é baseado em infraestrutura, como cartões de transferência de hardware criptográfico que oferecem criptografia em trânsito e microsserviços internos que oferecem criptografia de dados em repouso.
Este documento descreve como os componentes do hardware Titanium trabalham juntos para criar uma arquitetura de segurança que ajuda a proteger a superfície de ataque física dos sistemas do Google e reduzir as ameaças aos dados do cliente. Este documento também descreve como o hardware Titanium oferece controles de segurança específicos na camada de software, a evolução da arquitetura além das primeiras descargas de hardware criptográfico e as ameaças reais que a arquitetura de segurança do hardware Titanium foi projetada para minimizar na base de clientes e de implantações do Google.
Arquitetura de segurança de hardware do Titanium
A arquitetura de segurança do hardware Titanium foi projetada para a proteção contra uma variedade de cenários e agentes de ameaças. O diagrama de arquitetura a seguir mostra os componentes independentes, mas interligados, do Titanium.
A arquitetura de segurança do hardware Titanium inclui os seguintes componentes:
- Raiz de confiança para medição (RTM) do Caliptra: ajuda a aplicar um perímetro de segurança a cada pacote de silício. A RTM do Caliptra fornece atestados e um ID exclusivo para serviços criptográficos de raiz.
- RoT do chip Titan: interpõe-se entre o flash de inicialização de uma plataforma e os principais dispositivos de inicialização, como o controlador de gerenciamento de baseboard (BMC), o hub de controle da plataforma (PCH) e a CPU. Os chips Titan oferecem uma RoT baseada em hardware com resistência a adulterações físicas que ajuda a estabelecer uma identidade forte. Os chips Titan também ajudam na autorização e revogação de códigos para máquinas, cartões ou periféricos.
- Processador de descarga Titanium (TOPS): oferece controles criptográficos para ajudar a proteger a confidencialidade e a integridade dos dados em repouso e em trânsito.
- Placas-mãe personalizadas: oferecem resiliência em escala contra ataques DoS de softwares defeituosos ou maliciosos, além de proteção contra ataques físicos. No diagrama, por exemplo, o pacote de chip e a RoT do Titan estão em uma placa-mãe personalizada e separada daquelas para os TOPs do Titanium ou outras infraestruturas.
- Enclaves de computação confidencial: ajudam a impor o isolamento contra os privilégios administrativos do Google, melhoram o isolamento de outros locatários e permitem a realização de verificações com atestados. Com atestados, é possível garantir que um ambiente não tenha sido alterado.
- Serviços regionalizados de back-end tolerantes a falhas: ajudam a evitar a escalada de privilégios em serviços, zonas ou acessos administrativos.
No diagrama, Outra infraestrutura se refere a estruturas de rede e armazenamento de backend replicado.
Princípios de design da arquitetura de segurança de hardware do Titanium
Os componentes do hardware Titanium e as interações deles são desenvolvidos com base nos seguintes princípios fundamentais:
Nenhum ponto único de falha: a arquitetura do Google foi projetada para evitar pontos únicos de falha, como componentes de carga únicos com várias responsabilidades. Como criar sistemas seguros e confiáveis discute a importância de evitar pontos únicos de falha. Esse princípio é aplicado em toda a infraestrutura física, em todas as regiões e até mesmo no silício dos chips. Essa resiliência em toda a infraestrutura global ajuda a manter os dados dos clientes seguros e disponíveis.
Por exemplo, a migração em tempo real com a computação confidencial ajuda a preservar a memória criptografada em máquinas host compatíveis. A migração em tempo real ajuda a garantir que uma VM de longa duração não seja um ponto único de falha devido a eventos de manutenção ou resposta a vulnerabilidades.
O perímetro é o pacote de silício: como um sistema de servidor contém vários system on chips interconectados e separados, a arquitetura não confia por padrão em nenhum conector, estrutura, placa de circuito impresso (PCBA), trilha de PCBA ou cabo. Embora a separação de componentes seja útil para a modularidade, ela também pode se tornar uma fraqueza quando oferece alvos bem definidos para os invasores, de onde eles podem espionar dados de texto simples. Os dados no pacote de silício são criptografados e autenticados por recursos criptográficos privados contidos no pacote.
Mover o perímetro para o próprio silício ajuda a minimizar a confiança implícita. Esse princípio lida com ameaças à confidencialidade de dados que ocorrem à medida que as condições de disponibilização do data center se tornam cada vez mais diversas. Por exemplo, definir o perímetro no pacote de silício ajuda a lidar com ameaças de operações de hardware maliciosas.
Confiança zero e risco de compartimentalização: os controles de várias partes em ações administrativas ajudam a garantir que nenhuma conta de equipe (incluindo aquelas comprometidas) possa causar unilateralmente as ameaças discutidas neste documento. A arquitetura separa os serviços em camadas e zonas para compartimentalização e contenção dos riscos. Mesmo com enclaves, que geralmente são baseados em hardware, a arquitetura considera a descoberta de vulnerabilidades de hardware e a necessidade de remediação enquanto os componentes permanecem em operação.
Por exemplo, se um invasor comprometer maliciosamente o comportamento de um chip em um sistema ativo que está executando cargas de trabalho do cliente nos nossos data centers, a arquitetura será projetada para identificar e isolar esse chip comprometido. Essa máquina pode ser retirada de serviço. Mesmo que a máquina não seja retirada de serviço, o invasor precisa derrotar outros limites de confiança e comprometer várias credenciais para se mover lateralmente e ganhar influência sobre outros sistemas, usuários ou regiões.
Os domínios de falha independentes e as tecnologias de isolamento ajudam a limitar a área afetada por um comprometimento. Esses domínios e tecnologias adicionam pontos de controle naturais para detecção e limitam a quantidade de complexidade adicional que precisa ser introduzida.
Para saber mais sobre nossa implementação de confiança zero, consulte BeyondProd.
Segurança transparente: o Google investe em vários esforços de transparência, incluindo código aberto, divulgação responsável de pesquisas e descobertas e parcerias com o ecossistema de fabricantes de hardware. A infraestrutura global do Google aplica o princípio de Kerckhoffs, que determina que um sistema criptográfico precisa ser seguro, mesmo que tudo sobre ele, exceto a chave, seja de conhecimento público.
Por exemplo, contribuímos com projetos de código aberto e os usamos nos nossos designs de hardware e software de segurança. A tabela a seguir descreve alguns dos projetos de código aberto que usamos e que tiveram nossa contribuição.
Projeto de código aberto Descrição Componente do Titanium Usado em bibliotecas de criptografia FIPS 140-3 de nível 1
BoringSSL
Usado em raízes de confiança (RoT) no nível do silício
RTM do Caliptra
Usado na RoT para um chip em uma arquitetura de sistema
Chips Titan
Usado para fuzzing de kernel guiado por cobertura
Distribuições de VMs do usuário e VMs host ring0
Usado em bibliotecas de criptografia FIPS 140-3 de nível 1
Processador de descargas do Titanium
Defesa em profundidade física e lógica: o Google usa a segurança física de data centers para ajudar a proteger os investimentos de capital e sistemas da empresa. Esses controles de segurança são uma camada inicial de defesa. Por isso, investimos deliberadamente em controles lógicos adicionais para reforçar os sistemas contra ameaças físicas. O Titanium aumenta nossa defesa em profundidade ao adicionar compartimentalização ao hardware, o que oferece defesas adicionais contra ameaças específicas de infraestrutura.
Por exemplo, nossos data centers têm detectores de metal que podem detectar com precisão tentativas de exfiltração de mídias de armazenamento. No entanto, nossa estratégia de criptografia de dados em repouso é projetada deliberadamente para não depender da custódia de mídias físicas. Esses controles lógicos e físicos são camadas independentes e complementares.
Nossos controles combinados de segurança física e lógica nos ajudam a manter a atenção em ameaças internas e a proteger a confidencialidade dos dados dos nossos usuários.
Benefícios de segurança dos componentes de arquitetura do Titanium
A tabela a seguir destaca alguns benefícios de segurança importantes fornecidos pelos componentes da arquitetura de segurança do Titanium, tanto na camada de hardware quanto na de software. Esses benefícios de segurança são descritos em mais detalhes nas seções a seguir.
| Benefícios de segurança | Componente da arquitetura |
|---|---|
Perímetro de confiança no nível do silício em system on chips (SoCs), como CPUs ou GPUs |
RTM do Caliptra |
Capacidade de verificação no nível do silício |
RTM do Caliptra |
Identidade criptográfica no nível do hardware |
RTM do Caliptra, RoT do Titan |
Verificação da execução dos binários esperados |
RTM do Caliptra, RoT do Titan |
Minimização de ameaças persistentes em inicializações |
RTM do Caliptra, RoT do Titan |
Proteção da confidencialidade dos dados em repouso e em trânsito |
TOPs para criptografia |
Descarga da proteção no nível do processador (além de um cartão físico) |
TOPs para criptografia |
Segurança incorporada ao design, resistência a ataques físicos e recursos de resiliência com suporte à recuperação completa do firmware do sistema com base em uma única RoT do Titan |
Placas-mãe personalizadas |
Placas desenvolvidas especificamente para conter apenas conectores essenciais, o que ajuda a minimizar as tentativas de adulteração física |
Placas-mãe personalizadas |
Isolamento criptográfico de cargas de trabalho do software do sistema em toda a máquina e acesso administrativo humano |
Enclaves de computação confidencial |
Resistência a adulterações com criptografia DRAM (para ativar a criptografia de dados em uso) |
Enclaves de computação confidencial |
Minimização da área afetada e barreira para um invasor com acesso local |
Serviços regionalizados com tolerância a falhas de back-end |
Vários níveis de compartimentalização |
Serviços regionalizados com tolerância a falhas de back-end |
Raiz de confiança do Caliptra para medição
A RTM do Caliptra ajuda a criar confiança e transparência para o firmware no nosso ecossistema que é executado em system on chips (SoCs), como CPUs, GPUs e TPUs.
A RTM do Caliptra tem os seguintes benefícios:
- Fornece um serviço criptográfico raiz: a RTM do Caliptra ajuda a detectar códigos e configurações críticas corrompidos com uma verificação criptográfica de integridade avançada e de ponta a ponta. A RTM do Caliptra pode medir criptograficamente o código e a configuração, assinar as medições com uma chave de atestado exclusiva e protegida por hardware e informar as medições que atestam a autenticidade e a integridade do dispositivo. A RTM do Caliptra fornece uma identidade de dispositivo criptográfico e um conjunto de medições de integridade de firmware e configuração para a placa-mãe.
- Aprimora a segurança da cadeia de suprimentos física: a RTM do Caliptra ajuda a garantir que o hardware seja autêntico e esteja executando os firmwares e softwares pretendidos. Em combinação com a segurança da cadeia de suprimentos de software, a RTM do Caliptra permite que o sistema verifique a autenticidade e a integridade dos firmwares e softwares criados pelo Google ou por terceiros. Esse processo de verificação permite que a RTM do Caliptra mantenha a autenticidade e a integridade em atualizações autorizadas e ajuda a garantir que as configurações permaneçam como previsto e sejam certificadas.
- Proteção contra invasões físicas que exigem acesso direto ao hardware em execução: como a RTM do Caliptra é integrada às camadas de silício do chip, um interpositor de PCBA ou um chip malicioso que tenta entregar o firmware errado a um circuito integrado específico para aplicativos (ASIC) não pode atacar a RoT. Por exemplo, os invasores podem contornar os recursos de detecção de uma RoT externa adulterando o barramento SPI de velocidade relativamente baixa. No entanto, é mais difícil para um invasor comprometer uma RoT incorporada em um SoC ou ASIC.
Raiz de confiança do chip Titan
O Titan foi projetado para manter criptograficamente a identidade do dispositivo, oferecer proteção contra softwares maliciosos e aplicar a autenticidade do código usando a revogação.
Uma identidade criptográfica de dispositivo avançada ajuda a garantir que a frota seja composta exclusivamente de máquinas validadas que estejam executando os binários esperados e possam identificar e autenticar acessos legítimos. Os acessos legítimos estão enraizados no nível do hardware.
Por padrão, as máquinas de produção usam a inicialização confiável para garantir que apenas softwares autenticados possam ser executados. A inicialização confiável verifica a assinatura digital de todos os componentes de inicialização e não permite que uma máquina participe do ambiente de produção em caso de falha na autenticação.
Como um controle preventivo adicional, a revogação de código de máquina impede que mudanças de software que não estejam mais autorizadas sejam aplicadas. A capacidade de revogação em chips Titan ajuda a minimizar não apenas ataques maliciosos, como ataques de reversão ou repetição, mas também bugs de estabilidade ou resiliência não maliciosos (por exemplo, impedindo a reinstalação acidental de firmwares antigos com bugs).
Para mais informações, consulte Como o Google garante a integridade da inicialização em máquinas de produção.
Processadores de descarga Titanium para criptografia
Os processadores de descarga Titanium (TOPs) para criptografia ajudam a fornecer segurança durante a descarga de E/S. Esses TOPs são protegidos com o Titan ou a RTM do Caliptra. Os TOPs implantam a criptografia autenticada de dados em trânsito e a criptografia autenticada de dados em repouso a baixo custo e de maneira abrangente. Com a criptografia autenticada, os dados do cliente têm a confidencialidade e a integridade garantidas criptograficamente. Como os TOPs gerenciam a criptografia, eles removem privilégios de muitos componentes do sistema. Os TOPs permitem propriedades arquitetônicas aprimoradas, como disponibilidade, minimizando o potencial de perda de dados.
Placas-mãe personalizadas
As placas-mãe personalizadas na infraestrutura do Google foram projetadas para fornecer origem de hardware. As placas-mãe aceitam atestação em várias camadas. Os designs de placa-mãe protegem os dados dos clientes, mesmo no caso altamente improvável de um invasor conectar fisicamente um dispositivo malicioso a uma máquina. Os designs de placa-mãe do Titanium permitem a implantação confiável de outros mecanismos de proteção, como portas de depuração despovoadas, consoles seriais somente leitura, intrusão de conector de barramento e sinalização de extrusão.
O TLS e o ALTS são os únicos protocolos aceitos expostos pela pilha de rede do BMC quando uma máquina está ativada. Para máquinas que usam um design COTS de terceiros, como nossas instâncias X4, os TOPs encaminham qualquer tráfego de gerenciamento exclusivo para esse design de terceiros. Com o encaminhamento do tráfego de gerenciamento, nossa infraestrutura não depende de designs de terceiros para autenticação, autorização, segurança de transporte ou segurança de rede.
As placas-mãe personalizadas Titanium foram projetadas para ter mecanismos integrados de recuperação e backup e garantir a disponibilidade e a capacidade de recuperação. Elas podem ser restauradas da maioria das falhas ou da corrupção do firmware. Nossos designs mais recentes permitem recriar toda a máquina com base em uma única RoT do Titan funcional. Essas placas-mãe usam componentes de energia dedicados a recursos e restauração de sinalização para ajudar a garantir a independência elétrica das RoTs do Titan em relação ao restante da plataforma e proteger o controle delas sobre os payloads do firmware da plataforma para fins de autenticação e recuperação.
Enclaves de computação confidencial
A computação confidencial cria um ambiente de execução confiável (TEE) ou um enclave para ajudar a isolar as cargas de trabalho sensíveis dos clientes do acesso administrativo do Google. Quando os dados são processados pela CPU ou GPU, a computação confidencial oferece um controle preventivo técnico por meio do isolamento da computação e da criptografia na memória. A computação confidencial ajuda a garantir que nem mesmo um hipervisor malicioso possa acessar uma VM. Para cargas de trabalho dos clientes, a computação confidencial oferece uma camada de isolamento de segredo de dados contra a possibilidade de acesso não intencional de equipes do Google ou ações automatizadas de software do sistema em grande escala.
Um exemplo de segurança avançada possibilitada pela arquitetura Titanium é o modo confidencial para Hyperdisk Balanced. O modo confidencial para Hyperdisk Balanced combina descargas de armazenamento em blocos baseadas no Titanium, computação confidencial e HSM em nuvem para criar um TEE baseado em hardware. Em outras palavras, o modo confidencial para Hyperdisk Balanced é uma oferta com balanceamento de hiperdisco. O modo confidencial para Hyperdisk Balance isola a infraestrutura para que chaves sensíveis sejam processadas exclusivamente em um TEE baseado em hardware. Para informações sobre a análise de terceiros das operações criptográficas, consulte Relatório público: modo confidencial para Hyperdisk – Análise de proteção de DEK.
Serviços regionalizados com tolerância a falhas de back-end
Os serviços regionalizados de back-end tolerantes a falhas ajudam a minimizar a área afetada por um invasor com acesso local. A infraestrutura do Google foi projetada para compartimentalizar serviços, sistemas e zonas a fim de impedir movimentos laterais de usuários internos privilegiados ou serviços comprometidos.
Estamos trabalhando para incluir informações regionais em um conjunto cada vez mais amplo de nossos sistemas internos de gerenciamento de identidade e acesso. As informações regionais fortalecem o isolamento criptográfico para que um invasor com acesso local precise comprometer várias credenciais de serviços de infraestrutura diferentes para continuar se movendo lateralmente.
Se um ataque acionar um controle preventivo que retira uma máquina de produção do ambiente (por exemplo, fazendo com que o sistema seja desligado), nossa infraestrutura de back-end tolerante a falhas vai ajudar a garantir a disponibilidade contínua dos dados e serviços do cliente em máquinas próximas. Para mais informações sobre nossos controles de infraestrutura, consulte BeyondProd e Como o Google protege serviços de produção.
Vetores de ataque para a infraestrutura do Google Cloud
Esta seção descreve ameaças físicas e lógicas específicas que compõem parte da superfície de ataque do Google Cloud. A arquitetura de segurança do hardware Titanium foi projetada especificamente para lidar com um conjunto exclusivo de ameaças à infraestrutura do Google e aos dados do usuário que armazenamos.
Ameaças à infraestrutura
A arquitetura do Titanium foi projetada para proteção contra as seguintes categorias de ameaças:
- Pessoas mal-intencionadas com informações privilegiadas e acesso físico: nossa equipe precisa de acesso a dispositivos físicos em data centers para implantar, manter e reparar hardwares. Esse acesso representa um possível vetor de ataque porque equipes ou prestadores de serviços mal-intencionados têm um motivo comercial legítimo para reparar fisicamente algumas das máquinas nos nossos data centers.
Pessoas mal-intencionadas com informações privilegiadas e acesso lógico: semelhante ao acesso físico ao data center, nossa equipe precisa desenvolver, manter, testar, depurar, ajustar e dar suporte a vários níveis da pilha de software do Google. Essa equipe inclui desenvolvedores, SREs e engenheiros de nuvem que lidam com clientes.
Para conhecer nossas defesas contra essa ameaça, consulte Como o Google protege os próprios serviços de produção.
Invasores externos com acesso lógico: invasores externos podem conseguir acesso a um ambiente do Google Cloud e tentar movimentar-se lateralmente para outras máquinas para ter acesso a dados sensíveis. Uma tática comum usada por invasores externos é começar comprometendo uma conta legítima de algum prestador de serviços ou funcionário.
O diagrama a seguir mostra qual parte do ambiente de nuvem é mais vulnerável a essas ameaças.
Superfície de ataque dos servidores de data center
A tabela a seguir descreve as superfícies de ataque que são aspectos típicos dos servidores de data center. A arquitetura de segurança do hardware Titanium foi projetada para oferecer defesas avançadas contra essas ameaças.
| invasor | Alvo | Superfície de ataque | Risco |
|---|---|---|---|
Pessoas mal-intencionadas com informações privilegiadas e acesso físico |
Mídias de armazenamento (SSDs, HDDs ou unidades de inicialização) |
Conectores e unidades físicas |
Um invasor pode realizar esse ataque para roubar uma unidade e usar ferramentas para tentar acessá-la. |
Módulo de memória em linha dupla (DIMM) |
Conectores de memória física |
Um invasor pode realizar esse ataque para congelar o DIMM, retirá-lo do data center e usar ferramentas para tentar acessar os dados contidos nele. Essa ameaça também é conhecida como inicialização a frio. |
|
Servidor |
Conectores USB ou PCIe |
Um invasor pode realizar esse ataque para conectar um hardware malicioso a um servidor. Com esse hardware malicioso, ele pode tentar conseguir acesso à execução de código ou exfiltrar os dados armazenados. |
|
Placa-mãe |
Porta de depuração estendida (XDP) do grupo de acesso de teste conjunto (JTAG) |
Um invasor pode realizar esse ataque para conectar uma ferramenta de depuração de hardware e conseguir acesso à execução de código ou aos dados processados na CPU. |
|
Rede |
Cabos Ethernet |
Um invasor pode realizar esse ataque usando um cabo Ethernet para conseguir acesso a todos os dados transferidos entre dispositivos. Qualquer tráfego de texto não criptografado pode ser observado. |
|
Placa-mãe |
Firmware |
Um invasor pode realizar esse ataque para introduzir um firmware malicioso persistente. Esse firmware pode ser pré-instalado por um fabricante comprometido, interceptado em trânsito ou atualizado por uma pessoa com acesso privilegiado. Essa ameaça pode levar a hardwares pré-hackeados com rootkits que fornecem acesso backdoor ao servidor. |
|
Pessoas mal-intencionadas com informações privilegiadas e acesso lógico |
Carga de trabalho de computação (por exemplo, VMs) |
Pontos de login |
Um invasor pode realizar esse ataque usando credenciais internas para acessar diretamente VMs, hosts ou os dados contidos neles. |
Roteador de fibra |
Acesso físico ou administrativo |
Um invasor pode realizar esse ataque para ter controle raiz sobre um roteador de fibra, observar todo o tráfego e exfiltrar ou adulterar dados de texto não criptografado em trânsito na fibra. |
|
Placa-mãe |
Firmware |
Um invasor pode realizar esse ataque para enviar imagens de firmware defeituosas para placas-mãe, tornando-as permanentemente inoperáveis e tornando os dados irrecuperáveis. Um invasor pode enviar firmwares vulneráveis conhecidos para máquinas e recuperar o controle usando exploits que permitem a execução remota de códigos. |
|
Invasor externo com acesso lógico |
Servidor |
VMs |
Um invasor pode realizar esse ataque para iniciar padrões de ataque de canal lateral público em VMs. Esse tipo de ataque podem vazar dados de instâncias em execução no mesmo hardware ou do software do sistema host. |
SSDs |
VMs |
Um invasor pode realizar esse ataque para tentar inferir dados de colocatários usando o acesso direto a SSDs PCIe. |
|
Memória |
VMs |
Um invasor pode realizar esse vetor de ataque para procurar chaves de criptografia valiosas na memória usando canais secundários. |
|
Servidor |
VMs bare metal |
Um invasor pode realizar esse vetor de ataque usando instâncias bare metal para verificar todos os periféricos e encontrar um componente vulnerável que permita a permanência na máquina e o ataque aos locatários. |
Associar componentes de hardware do Titanium para proteção contra ameaças
A arquitetura de segurança do hardware Titanium usa uma abordagem de várias camadas para ajudar a resolver ameaças à infraestrutura específicas e evitar pontos únicos de falha. Essas ameaças podem ter origem em erros ou em agentes mal-intencionados. As ameaças abrangem operações de hardware e podem explorar vulnerabilidades em servidores, redes e no plano de controle. Não existe uma única solução que possa resolver todos esses vetores de ataque, mas os recursos combinados do Titanium ajudam a proteger os dados dos usuários e as instâncias de computação em nuvem.
Cenário: operações de hardware maliciosas
As operações de hardware maliciosas representam uma ameaça à segurança dos dados, porque podem levar à exfiltração de dados de data centers e à modificação de hardwares e firmwares. A arquitetura de segurança do hardware Titanium do Google oferece proteção contra essas ameaças através de várias medidas de segurança, incluindo RoTs criptográficas, placas-mãe personalizadas e processadores de E/S. Esses componentes trabalham juntos para fornecer uma defesa em camadas resistente a uma ampla variedade de ataques.
A tabela a seguir descreve algumas ameaças de hardware maliciosas e como a arquitetura do Titanium pode minimizá-las.
| Ameaça | Minimização de ataques do Titanium |
|---|---|
Um invasor exfiltra unidades de dados individuais dos data centers para acessar os dados contidos nelas. |
As chaves de criptografia de dados em repouso para produtos e serviços de armazenamento nunca são armazenadas de maneira persistente nas máquinas anexadas à mídia de armazenamento. Os recursos de autocriptografia integrados da mídia de armazenamento também são ativados para oferecer defesa em profundidade e usam chaves que nunca são armazenadas de maneira persistente na própria mídia. As RTMs do Caliptra permitem que o Google inclua a identidade de hardware de raiz de confiança e a integridade do firmware entre as condições de autorização necessárias para liberar chaves de um serviço de gerenciamento de chaves para instâncias de serviço de armazenamento. Máquinas configuradas de maneira maliciosa com firmwares não autorizados não podem acessar as chaves necessárias para descriptografar os dados armazenados. As RoTs incorporadas nos pacotes de silício definem as identidades criptográficas relevantes no pacote do chip. Os interpositores de função única são a parte principal da segurança do plano de dados e criptografam os dados em cada etapa de processamento. Os TOPs oferecem os seguintes benefícios:
Soluções de software comprovadas, como o dm-crypt, são usadas para unidades de menor desempenho em que a redução da superfície de ataque é fundamental, como em alguns casos de uso de unidades de inicialização. |
Um invasor intercepta um cabo de rede e lê bytes no fio ou na fibra. |
Os TOPs criptografam dados em trânsito, o que impede que uma ameaça detecte dados valiosos na rede. Nossas placas de rede (NICs) usam o padrão de descarga de hardware do PSP. Ele oferece criptografia econômica com uma redução mínima no desempenho. Essas implementações são compatíveis com o FIPS. Os dados do cliente são criptografados quando transitam por switches ToR ou de fibra. Algumas infraestruturas de machine learning usam mecanismos de segurança de transporte próprios. |
Um invasor substitui chips flash que contêm códigos mutáveis no data center ou na cadeia de suprimentos para executar códigos maliciosos nos servidores. |
Os chips Titan foram criados para rejeitar o ataque e não fornecem acesso às credenciais armazenadas. Mesmo que um invasor reescreva o conteúdo de chips flash não voláteis, a RoT do Titan informa com segurança uma medição do código para o plano de controle do Google, que foi projetado para bloquear o dispositivo. O Google revoga rotineiramente códigos descontinuados ou com vulnerabilidades conhecidas em escala global na nossa frota usando chips Titan. |
Um invasor insere dispositivos hostis em interfaces físicas de servidores ou cartões de data center para executar códigos maliciosos ou exfiltrar dados. |
Os designs de placa-mãe personalizada removem as interfaces que são usadas para inserir dispositivos adversários. As configurações da unidade de gerenciamento de memória de entrada/saída (IOMMU) estão em vigor para evitar PCIe screamers em todos os nossos firmwares. PCIe screamers são projetados para ler e gravar pacotes arbitrários na fibra PCIe. À medida que o setor amadurece, estamos complementando essa proteção com o IDE PCI para minimizar ainda mais os interpositores PCI mais sofisticados. ALTS e TLS são as únicas conexões de rede de autenticação e autorização aceitas para funções de controle e gerenciamento em TOPs e BMCs. As RTMs do Caliptra bloqueiam qualquer firmware não aprovado. Nossos periféricos confiáveis atestam a identidade do hardware e a integridade do código para nosso plano de controle, e nenhum servidor é admitido na produção quando o registro do atestado não corresponde à intenção do hardware e do software. |
Um invasor usa um ataque de inicialização a frio no data center para acessar dados na RAM. |
A criptografia na memória da computação confidencial protege todos os dados sensíveis ou chaves de criptografia na RAM. A criptografia DRAM também é ativada em máquinas implantadas sem a computação confidencial em data centers de borda de menor garantia. |
Cenário: usuários mal-intencionados exploram servidores ou redes
Os invasores podem usar a nuvem pública para hospedar cargas de trabalho maliciosas na nossa infraestrutura compartilhada e depositar dados nos nossos serviços públicos. Adversários externos, de indivíduos a nações, também podem tentar conseguir acesso privilegiado remoto.
Para minimizar essas ações, a arquitetura de segurança do hardware Titanium usa chips Titan e RTMs do Caliptra, provisionando credenciais de execução de maneira segura e limitando os privilégios em hardwares e sistemas operacionais. A computação confidencial oferece proteção contra a manipulação da memória do sistema, seja fisicamente ou usando ataques de hipervisor, e os chips Titan rejeitam ou detectam upgrades de software não autorizados.
A tabela a seguir descreve algumas das ameaças de exploração de servidores e redes e como a arquitetura do Titanium pode minimizá-las.
| Ameaça | Minimização de ataques do Titanium |
|---|---|
Um invasor explora uma vulnerabilidade para escapar da VM e ter acesso a dados e outras VMs em execução na mesma máquina. |
Os enclaves da computação confidencial restringem a exfiltração dos dados do carga de trabalho, seja em processo ou em repouso. Essa minimização impede que um invasor que tenha escapado da VM acesse dados em uso. Os chips Titan e as RTMs do Caliptra bloqueiam o acesso persistente do invasor. É muito provável que qualquer tentativa de acesso persistente seja detectada porque a configuração da máquina não corresponde à configuração e à política de código do servidor. Essa correspondência é necessária para que a máquina possa hospedar cargas de trabalho de produção após uma reinicialização. |
Um invasor lança padrões de ataque de canal lateral públicos em VMs. |
Nosso sistema de gerenciamento de frota, que usa chips Titan, pode revogar softwares com vulnerabilidades conhecidas. A revogação pode bloquear ataques que visam essas vulnerabilidades conhecidas. As medições de integridade baseadas no Titan também oferecem alta confiança de que as minimizações, que podem precisar ser implantadas com urgência, foram implantadas nas máquinas de destino. Reforçamos essa abordagem permanecendo na vanguarda da investigação e minimização de canais laterais, com técnicas como retpoline e programação de núcleo, além de pesquisas avançadas sobre Meltdown, Spectre, Zenbleed, Downfall, entre outros. |
Um invasor usa o acesso direto a SSDs que fornecem armazenamento a vários locatários para tentar inferir dados de colocatários. |
A criptografia de dados em repouso oferece proteção contra ataques lógicos e físicos com vários tipos de interpositores. No caso de recursos não compartilhados, os dados de cada locatário são criptografados com chaves diferentes, o que reduz a possibilidade de ataques de acesso direto contra o SSD. |
Um invasor verifica a memória e usa canais laterais para pesquisar chaves de criptografia de dados ou credenciais. |
Os chips Titan permitem o provisionamento de credenciais seladas por máquina. Mesmo que um invasor consiga acesso raiz a uma máquina, as credenciais dela são vinculadas apenas à identidade privada do chip Titan local. |
Um invasor compra instâncias bare metal e verifica todos os periféricos para tentar conseguir acesso persistente. |
Os chips Titan rejeitam qualquer upgrade de software não autorizado, incluindo pushs maliciosos para controle persistente. Nosso fluxo de trabalho de máquina confirma positivamente as medições de integridade esperadas em uma reinicialização completa comprovada pelo sistema entre clientes bare metal. |
Cenário: exploração de servidores ou redes por comportamento indevido do plano de controle
Pessoas mal-intencionadas com informações privilegiadas e acesso ao plano de controle podem tentar explorar os sistemas do Google de várias maneiras, incluindo a tentativa de conseguir controle raiz sobre um roteador de fibra, enviar imagens de firmware defeituosas para placas-mãe e observar o tráfego de rede. A arquitetura de segurança do hardware Titanium oferece proteção contra essas ameaças usando vários mecanismos, incluindo chips Titan, RTMs do Caliptra, placas-mãe personalizadas e serviços isolados de back-end tolerantes a falhas.
A tabela a seguir descreve algumas ameaças ao plano de controle e como a arquitetura Titanium pode minimizá-las.
| Ameaça | Minimização de ataques do Titanium |
|---|---|
Um invasor usa credenciais internas para acessar as VMs do Compute Engine que atuam como camada de base para ambientes de clientes. |
Os TOPs ajudam a garantir que os administradores não tenham acesso aos ambientes dos clientes. Sem acesso, a equipe do Google não pode usar as credenciais para acessar a camada de hardware e software privilegiada que está protegida pelas VMs dos nossos clientes. O acesso de equipes do Google aos dados do cliente é bloqueado porque esses dados só podem ser acessados por APIs definidas. |
Um invasor envia imagens de firmware defeituosas em grande escala para placas-mãe, bloqueando-as permanentemente. |
As RoTs dos chips Titan rejeitam qualquer upgrade de software não autorizado, incluindo envios maliciosos para controle persistente. Os designs de placa-mãe personalizada usam uma rede alternativa de sinais que interconecta todas as nossas RoTs à RoT da plataforma. A RoT da plataforma contém o firmware de backup de dispositivos críticos. Mesmo que a rede e o PCI tenham sido danificados por um invasor, a rede fora de banda (OOB) pode recuperar o sistema. |
Um invasor envia um firmware de produção descontinuado e conhecido por ser vulnerável para máquinas com o objetivo de recuperar o controle usando vulnerabilidades públicas. |
Os chips Titan rejeitam envios inválidos e ajudam a aplicar a revogação de códigos com vulnerabilidades conhecidas. Eles atestam a versão do firmware implantada na máquina e a rejeitam no plano de controle. Essa minimização ajuda a impedir que jobs sejam executados em uma máquina com problemas e aciona a investigação ou o reparo, conforme necessário. |
Um invasor abusa dos recursos de depuração de silício necessários para a continuidade dos negócios, que fornecem o maior nível concebível de acesso a dados em sistemas de servidor. |
A RTM do Caliptra ajuda a garantir que todos os parâmetros que ativam interfaces de depuração invasivas, conectadas de maneira lógica ou por inserção física direta, sejam configurados com segurança, medidos criptograficamente e informados ao plano de controle por um protocolo de atestado. Somente as máquinas no estado pretendido têm acesso para atender às cargas de trabalho de produção. |
Um invasor consegue controlar um serviço de back-end para acessar os ambientes dos clientes. |
Os serviços regionalizados de back-end tolerantes a falhas são infraestruturas de credenciais regionalizadas que não permitem acesso humano unilateral. Além de impedir o login do operador nos nós de computação, eles também não permitem o login do operador no plano de controle para a recuperação de materiais. Os enclaves da computação confidencial na arquitetura do Titanium isolam nossos serviços de provisionamento de chaves e autorização de back-end dos privilégios raiz da máquina. As hierarquias de chaves oferecem proteção às chaves de assinatura e de autorização da maioria dos serviços. Com hierarquias de chaves, as chaves raiz estão em chaves com isolamento físico e são mantidas em HSMs e em cofres ou em chaves mantidas em produção por um quórum Paxos de armazenamentos de dados na memória. |
A seguir
- Confira a Visão geral do design de segurança da infraestrutura.
- Implemente a computação confidencial.
Autores: Andrés Lagar-Cavilla, Erlander Lo, Jon McCune e Chris Perry