Este conteúdo foi atualizado pela última vez em setembro 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.
A arquitetura de segurança de hardware Titanium serve de base aos serviços da Google e sustenta muitas das contramedidas de segurança na infraestrutura da Google. O hardware Titanium inclui microcontroladores de segurança, adaptadores de hardware e processadores de descarregamento que foram desenvolvidos especificamente para abordar vetores de ataque específicos para a infraestrutura da Google.
O hardware Titanium é o mais recente avanço na segurança da infraestrutura abrangente e em constante evolução da Google e ajuda a proteger a integridade, a confidencialidade e a disponibilidade dos dados do utilizador. O hardware Titanium baseia-se em infraestruturas, como cartões de descarregamento de hardware criptográfico, que fornecem encriptação em trânsito e microsserviços internos que fornecem encriptação de dados em repouso.
Este documento descreve como os componentes de hardware do Titanium funcionam em conjunto para criar uma arquitetura de segurança que ajuda a proteger a superfície de ataque físico dos sistemas Google e mitigar as ameaças aos dados de clientes. Este documento também descreve como o hardware Titanium permite controlos de segurança específicos na camada de software, a evolução da arquitetura além das transferências de hardware criptográficas iniciais e as ameaças reais que a arquitetura de segurança de hardware Titanium foi concebida para mitigar na base de clientes e implementações da Google.
Arquitetura de segurança de hardware Titanium
A arquitetura de segurança de hardware Titanium foi concebida para se defender contra um espetro de cenários e agentes de ameaças. O diagrama de arquitetura seguinte mostra os componentes independentes, mas interligados, do Titanium.
A arquitetura de segurança de hardware Titanium inclui os seguintes componentes:
- Raiz de confiança Caliptra para medição (RTM): ajuda a aplicar um perímetro de segurança para cada pacote de silício. O RTM do Caliptra fornece atestação e um ID exclusivo aos serviços criptográficos de raiz.
- Chip Titan RoT: interpõe-se entre o flash de arranque de uma plataforma e os respetivos dispositivos de arranque principais, como o controlador de gestão da placa base (BMC), o hub do controlador da plataforma (PCH) e a CPU. Os chips Titan oferecem uma RoT baseada em hardware fisicamente resistente a adulterações que ajuda a estabelecer uma identidade forte. Os chips Titan também ajudam na autorização e revogação de código para máquinas, cartões ou periféricos.
- Processador de desvio de carga do Titanium (TOPS): oferece controlos 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 grande escala contra ataques DoS de software defeituoso ou malicioso, bem como proteção contra ataques físicos. No diagrama, por exemplo, o pacote de chips e o RoT do Titan estão numa placa-mãe personalizada que é separada das placas-mãe personalizadas para o TOP do Titanium ou das placas-mãe para outra infraestrutura.
- Enclaves de computação confidencial: ajudam a aplicar o isolamento contra os privilégios administrativos da Google, melhoram o isolamento com outros inquilinos e adicionam a capacidade de validação através da atestação. A atestação pode garantir que o ambiente não foi alterado.
- Serviços regionalizados com tolerância a falhas de back-end: ajudam a evitar a escalada de privilégios entre serviços, zonas ou a partir do acesso administrativo.
No diagrama, a Outra infraestrutura refere-se a tecidos de rede e armazenamento de back-end replicado.
Princípios de design da arquitetura de segurança de hardware Titanium
Os nossos componentes de hardware Titanium e as respetivas interações são desenvolvidos com base nos seguintes princípios fundamentais:
Sem pontos únicos de falha: a arquitetura da Google foi concebida para evitar pontos únicos de falha, como componentes de suporte de carga únicos com várias responsabilidades. Criar sistemas seguros e fiáveis aborda a importância de evitar pontos únicos de falha. Este princípio é aplicado em toda a nossa infraestrutura física, em todas as regiões e até ao silício nos chips. Esta resiliência em toda a nossa infraestrutura global ajuda a manter os dados dos clientes seguros e disponíveis.
Por exemplo, a migração em direto com a computação confidencial ajuda a preservar a memória encriptada em máquinas anfitriãs suportadas. A migração em direto ajuda a garantir que uma VM de execução prolongada não é um ponto único de falha devido a eventos de manutenção ou em resposta a vulnerabilidades.
O perímetro é o pacote de silício: uma vez que um sistema de servidor contém vários sistemas no chip interligados e separados, a nossa arquitetura desconfia fundamentalmente de todos os conetores, tecidos, conjuntos de placas de circuito impresso (PCBAs), rastreios de PCBAs e cabos. Embora a separação de componentes seja útil para a modularidade, a separação também pode tornar-se uma fraqueza quando oferece aos adversários alvos bem definidos a partir dos quais podem espiar dados de texto simples. Os dados no próprio pacote de silício são encriptados e autenticados por recursos criptográficos privados no pacote.
Mover o perímetro para o próprio silício ajuda a minimizar a confiança implícita. Este princípio aborda as ameaças contra a confidencialidade dos dados que ocorrem à medida que as condições de publicação do centro de dados se tornam cada vez mais diversas. Por exemplo, a definição do perímetro no pacote de silício ajuda a resolver ameaças de operações de hardware não autorizadas.
Confiança zero e compartimentação do risco: os controlos multipartidários nas ações administrativas ajudam a garantir que nenhuma conta de pessoal (ou conta de pessoal comprometida) pode causar unilateralmente as ameaças abordadas neste documento. A arquitetura separa os serviços em camadas e zonas para compartimentar e conter o risco. Mesmo com enclaves, que são normalmente baseados em hardware, a arquitetura tem em conta a deteção de vulnerabilidades de hardware e a necessidade de remediação enquanto os componentes permanecem em funcionamento.
Por exemplo, se um atacante comprometer maliciosamente o comportamento de um chip num sistema ativo que esteja a executar cargas de trabalho de clientes nos nossos centros de dados, a arquitetura é concebida para identificar e isolar esse chip comprometido. Essa máquina pode ser desativada. Mesmo que a máquina não seja desativada, o atacante tem de ultrapassar limites de confiança adicionais e comprometer várias credenciais para se mover lateralmente e ganhar influência sobre mais sistemas, utilizadores ou regiões.
Os domínios de falha independentes e as tecnologias de isolamento ajudam a limitar a área afetada de uma violação. Estes domínios e tecnologias adicionam pontos de controlo naturais para a deteção e limitam a quantidade de complexidade adicional que tem de ser introduzida.
Para mais informações sobre a nossa implementação de confiança zero, consulte o artigo BeyondProd.
Segurança transparente: a Google investe em vários esforços de transparência, incluindo código aberto, divulgação responsável de investigação e conclusões, e parcerias com o ecossistema de fabricantes de hardware. A infraestrutura global da Google aplica o princípio de Kerckhoffs, que afirma que um criptosistema deve ser seguro, mesmo que tudo sobre o sistema, exceto a chave, seja de conhecimento público.
Por exemplo, contribuímos para projetos de código aberto e usamos estes projetos nos nossos designs de hardware de segurança e no nosso software de segurança. A tabela seguinte descreve alguns dos projetos de código aberto com os quais contribuímos e que utilizamos.
Projeto de código aberto Descrição Componente de titânio Usado em bibliotecas de encriptação FIPS 140-3 nível 1
BoringSSL
Usado em raízes de confiança (RoT) ao nível do silício
Caliptra RTM
Usado na RoT para um chip numa arquitetura de sistema
Chips Titan
Usado para testes de fuzzing do kernel orientados pela cobertura
Distribuições de VMs de utilizador e anfitrião ring0
Usado em bibliotecas de encriptação FIPS 140-3 nível 1
Processador de desvio de carga Titanium
Defesa física e lógica em profundidade: a Google confia na segurança física dos centros de dados para ajudar a proteger os nossos investimentos de capital e sistemas. Estes controlos de segurança são uma camada inicial de defesa, pelo que investimos deliberadamente em controlos lógicos adicionais para reforçar os nossos sistemas contra ameaças físicas. O Titanium adiciona à nossa defesa em profundidade a compartimentalização no nosso hardware que oferece defesas adicionais contra ameaças específicas à infraestrutura.
Por exemplo, os nossos centros de dados têm detetores de metais que podem detetar com precisão tentativas de exfiltração de suportes de armazenamento. No entanto, a nossa estratégia de encriptação de dados em repouso foi deliberadamente concebida para não depender da custódia de suportes físicos. Estes controlos lógicos e físicos são camadas independentes e complementares.
Os nossos controlos de segurança físicos e lógicos combinados ajudam-nos a manter-nos vigilantes contra ameaças internas e a proteger a confidencialidade dos dados dos nossos utilizadores.
Vantagens de segurança dos componentes de arquitetura Titanium
A tabela seguinte realça algumas vantagens importantes de segurança que são alcançadas com os componentes da arquitetura de segurança Titanium, tanto na camada de hardware como na de software. Estas vantagens de segurança são descritas com mais detalhe nas secções seguintes.
| Vantagens de segurança | Componente de arquitetura |
|---|---|
Perímetro de confiança ao nível do silício em sistemas no chip (SoCs), como CPUs ou GPUs |
Caliptra RTM |
Verificabilidade ao nível do silício |
Caliptra RTM |
Identidade criptográfica ao nível do hardware |
Caliptra RTM, Titan RoT |
Validação de que os ficheiros binários esperados estão em execução |
Caliptra RTM, Titan RoT |
Mitigação de ameaças persistentes em todos os arranques |
Caliptra RTM, Titan RoT |
Proteção da confidencialidade dos dados inativos e dos dados em trânsito |
TOPs para criptografia |
Transferir a proteção ao nível do processador (além de um cartão físico) |
TOPs para criptografia |
Segurança por conceção, resistência a ataques físicos e capacidades de resiliência que suportam a recuperação completa do firmware do sistema a partir de uma única RoT Titan |
Motherboards personalizadas |
Placas concebidas especificamente com apenas os conetores essenciais, o que ajuda a mitigar as tentativas de adulteração física |
Motherboards personalizadas |
Isolamento da carga de trabalho criptográfica do software do sistema ao nível da máquina e acesso humano administrativo |
Enclaves de computação confidencial |
Resistência a adulterações através da encriptação DRAM (para ativar a encriptação de dados em utilização) |
Enclaves de computação confidencial |
Área afetada e antepara minimizadas para um atacante com acesso local |
Serviços regionalizados de back-end com tolerância a falhas |
Vários níveis de compartimentalização |
Serviços regionalizados de back-end com tolerância a falhas |
Raiz de fidedignidade da Caliptra para medição
Caliptra RTM ajuda a criar confiança e transparência para o firmware no nosso ecossistema que é executado em sistemas em chip (SoCs), como CPUs, GPUs e TPUs.
O Caliptra RTM tem as seguintes vantagens:
- Fornece um serviço criptográfico de raiz: o RTM do Caliptra ajuda a detetar código e configuração críticos danificados através de uma validação de integridade criptográfica ponto a ponto forte. O RTM do Caliptra pode medir criptograficamente a sua configuração e código, assinar estas medições com uma chave de atestação única e protegida por hardware, e comunicar medições que atestam a autenticidade e a integridade do dispositivo. O RTM do Caliptra fornece uma identidade do dispositivo criptográfica e um conjunto de medições de integridade do firmware e da configuração para a placa-mãe.
- Mitiga a segurança da cadeia de aprovisionamento física: o RTM do Caliptra ajuda a garantir que o hardware é autêntico e está a executar o firmware e o software pretendidos. Em combinação com a segurança da cadeia de fornecimento de software, o RTM do Caliptra permite que o sistema valide a autenticidade e a integridade do firmware e do software, quer tenham sido criados pela Google ou por terceiros. Este processo de validação permite que o RTM do Caliptra mantenha a autenticidade e a integridade nas atualizações autorizadas e ajuda a garantir que as configurações permanecem como pretendido e são atestadas.
- Protege contra intrusões físicas que requerem acesso direto ao hardware em execução: uma vez que o RTM do Caliptra está incorporado nas camadas de silício do chip, um interposer de PCBA ou um chip fraudulento que tente fornecer o firmware errado a um circuito integrado específico da aplicação (ASIC) não consegue atacar com êxito a RoT. Por exemplo, os atacantes podem ignorar as capacidades de deteção de uma RoT externa adulterando o barramento SPI relativamente de baixa velocidade. No entanto, um RoT incorporado num SoC ou ASIC torna-se mais difícil de comprometer para um atacante.
Raiz de fidedignidade do chip Titan
O Titan foi concebido para manter criptograficamente a identidade do dispositivo, defender-se contra envios de software incorretos e aplicar a autenticidade do código através da revogação.
Uma identidade do dispositivo criptográfica forte ajuda a garantir que a frota é composta exclusivamente por máquinas validadas que estão a executar os ficheiros binários esperados e que podem identificar e autenticar o acesso legítimo. O acesso legítimo tem origem ao nível do hardware.
Por predefinição, as máquinas de produção usam o arranque fidedigno para ajudar a garantir que apenas o software autenticado pode ser executado. O arranque fiavel valida a assinatura digital de todos os componentes de arranque e não permite que uma máquina participe no ambiente de produção se a autenticação falhar.
Como um controlo preventivo adicional, a revogação do código de máquina impede que sejam aplicadas alterações de software que já não estão autorizadas. A capacidade de revogação nos chips Titan ajuda a mitigar não só ataques maliciosos (por exemplo, ataques de reversão ou repetição), mas também erros de estabilidade ou resiliência não maliciosos (por exemplo, impedindo a reinstalação acidental de firmware antigo com erros).
Para mais informações, consulte o artigo Como a Google aplica a integridade do arranque em máquinas de produção.
Processadores de desvio de carga Titanium para criptografia
Os processadores de desvio de titânio (TOPs) para criptografia ajudam a fornecer segurança durante o desvio de E/S. Estes TOPs estão protegidos com o Titan ou o Caliptra RTM. Os TOPs implementam a encriptação autenticada generalizada de dados em trânsito e a encriptação autenticada de dados inativos a baixo custo. A encriptação autenticada significa que os dados do cliente têm garantia criptográfica de confidencialidade e integridade. Uma vez que os TOPs gerem a criptografia, estes retiram privilégios a muitos componentes do sistema. As TOPs permitem propriedades arquitetónicas melhoradas, como a disponibilidade, ao mesmo tempo que minimizam o potencial de perda de sigilo dos dados.
Motherboards personalizadas
As placas-mãe personalizadas na infraestrutura da Google foram concebidas para fornecer a proveniência do hardware. As placas-mãe suportam a atestação em várias camadas. Os designs da placa-mãe protegem os dados dos clientes, mesmo no caso altamente improvável de um atacante anexar fisicamente um dispositivo malicioso a uma máquina. Os designs da placa-mãe de titânio ajudam a permitir a implementação fiável de mecanismos de reforço adicionais, como portas de depuração desativadas, consolas de série só de leitura, intrusão no conetor do barramento e sinalização de extrusão.
O TLS e o ALTS são os únicos protocolos aceites expostos pela nossa pilha de rede BMC quando uma máquina está ligada. Para máquinas que usam um design COTS de terceiros, como as nossas instâncias X4, o TOP encaminha todo o tráfego de gestão exclusivo desse design de terceiros. A gestão de proxy do tráfego significa que a 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 de titânio foram concebidas com mecanismos de recuperação e cópia de segurança incorporados para garantir a disponibilidade e a capacidade de recuperação. Podem restaurar-se a partir da maioria das falhas de sistema ou da corrupção do firmware. Os nossos designs mais recentes permitem a reconstrução de toda a máquina a partir de uma única RoT do Titan funcional. Estas placas mãe usam componentes de alimentação dedicados a funcionalidades e sinalização de reposição para ajudar a garantir a independência elétrica dos RoTs do Titan do resto da plataforma e ajudar a proteger o respetivo controlo sobre as cargas úteis de 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 fidedigno (TEE) ou um enclave para ajudar a isolar as cargas de trabalho confidenciais dos clientes do acesso administrativo da Google. Quando os dados são processados pela CPU ou pela GPU, a computação confidencial fornece um controlo preventivo técnico através do isolamento de computação e da encriptação na memória. A computação confidencial ajuda a garantir que mesmo um hipervisor malicioso não consegue aceder a uma VM. Para cargas de trabalho de clientes, a computação confidencial oferece uma camada de isolamento de sigilo de dados da possibilidade de acesso não intencional por parte do pessoal da Google ou ações de software do sistema automatizadas defeituosas em grande escala.
Um exemplo de segurança avançada ativada pela arquitetura Titanium é o modo confidencial para o Hyperdisk Balanced. O modo confidencial para o Hyperdisk Balanced combina descarregamentos de armazenamento de blocos baseados em titânio, computação confidencial e HSM na nuvem para criar um AEF baseado em hardware. Por outras palavras, o modo confidencial para o Hyperdisk Balanced é uma oferta de hyperdisk-balanced. O modo confidencial para o Hyperdisk Balance isola a infraestrutura para que as chaves confidenciais sejam processadas exclusivamente num AEF baseado em hardware. Para informações acerca da revisão de terceiros das operações criptográficas, consulte o relatório público – Modo confidencial para análise da proteção DEK do Hyperdisk.
Serviços regionalizados de back-end com tolerância a falhas
Os serviços regionalizados tolerantes a falhas de back-end ajudam a minimizar a área afetada por um atacante com acesso local. A infraestrutura da Google foi concebida para compartimentalizar serviços, sistemas e zonas do movimento lateral de utilizadores privilegiados ou serviços comprometidos.
Estamos a trabalhar para incluir informações regionais num conjunto cada vez mais vasto dos nossos sistemas internos de gestão de identidades e acessos. As informações regionais reforçam o isolamento criptográfico para que um atacante que obtenha acesso local tenha de comprometer várias credenciais de serviços de infraestrutura distintos para continuar a mover-se lateralmente.
Se um ataque acionar um controlo preventivo que retire uma máquina de produção do ambiente (por exemplo, fazer com que o sistema seja desligado), a nossa infraestrutura de back-end tolerante a falhas ajuda a garantir a disponibilidade contínua dos dados e serviços dos clientes em máquinas próximas. Para mais informações acerca dos nossos controlos de infraestrutura, consulte os artigos BeyondProd e Como a Google protege os respetivos serviços de produção.
Vetores de ataque para Google Cloud infraestrutura
Esta secção descreve ameaças físicas e lógicas específicas que constituem parte da superfície de ataque do Google Cloud. A arquitetura de segurança de hardware do Titanium foi especificamente concebida para fazer face a um conjunto único de ameaças à infraestrutura da Google e aos dados do utilizador que armazenamos.
Ameaças à infraestrutura
A arquitetura Titanium foi concebida para se defender contra as seguintes várias categorias de ameaças:
- Ameaça interna com acesso físico: o nosso pessoal precisa de acesso a dispositivos físicos nos centros de dados para implementar, manter e reparar hardware. Este acesso representa um potencial vetor de ataque porque o pessoal ou os contratantes desonestos têm um motivo empresarial legítimo para reparar fisicamente algumas das máquinas nos nossos centros de dados.
Funcionário interno desonesto com acesso lógico: semelhante ao acesso físico ao centro de dados, o pessoal tem de desenvolver, manter, testar, depurar, ajustar e apoiar vários níveis da pilha de software da Google. Este pessoal inclui programadores, EFSs e engenheiros da nuvem que interagem com os clientes.
Para mais informações sobre as nossas defesas contra esta ameaça, consulte o artigo Como a Google protege os respetivos serviços de produção.
Atacante externo com acesso lógico: os atacantes externos podem ganhar uma posição dentro de um ambiente do Google Cloud e tentar transferir-se lateralmente para outras máquinas para obter acesso a dados confidenciais. Uma tática comum usada por atacantes externos é começar por comprometer a conta de um funcionário ou um contratante legítimo.
O diagrama seguinte mostra que parte do ambiente de nuvem é mais vulnerável a estas ameaças.
Vetores de ataque a servidores de centros de dados
A tabela seguinte descreve as superfícies de ataque que são aspetos típicos dos servidores do centro de dados. A arquitetura de segurança de hardware Titanium foi concebida para oferecer defesas fortes contra essas ameaças.
| Atacante | Destino | Vetores de ataque | Risco |
|---|---|---|---|
Ameaça interna com acesso físico |
Suportes de armazenamento (SSDs, HDDs ou unidades de arranque) |
Unidades físicas e conetores |
Este ataque pode roubar uma unidade e tentar aceder à mesma com as ferramentas do atacante. |
DIMM |
Conetores de memória física |
Este ataque pode bloquear o DIMM, retirá-lo do centro de dados e tentar aceder aos dados no mesmo através das ferramentas do atacante. Por vezes, esta ameaça é denominada ataque de arranque a frio. |
|
Servidor |
Conetores USB ou PCIe |
Este ataque pode ligar hardware malicioso ao servidor. Através do hardware malicioso, o atacante pode tentar obter a execução de código ou exfiltrar dados residentes. |
|
Placa principal |
Grupo de acesso de teste conjunto (JTAG) e porta de depuração alargada (XDP) |
Este ataque pode ligar uma ferramenta de depuração de hardware para obter a execução de código ou o acesso a dados processados na CPU. |
|
Rede |
Cabos Ethernet |
Este ataque pode usar um cabo Ethernet para obter acesso a todos os dados que estão a ser transferidos entre dispositivos. Em seguida, é possível observar qualquer tráfego de texto desencriptado. |
|
Placa principal |
Firmware |
Este ataque pode introduzir firmware malicioso persistente. Este firmware pode estar pré-instalado por um fabricante comprometido, ter sido interceptado em trânsito ou ter sido atualizado por uma pessoa com acesso privilegiado. Esta ameaça pode levar a hardware pré-pirateado com rootkits que fornecem acesso de porta traseira ao servidor. |
|
Ameaça interna com acesso lógico |
Carga de trabalho de computação (por exemplo, VMs) |
Pontos de início de sessão |
Este ataque pode usar credenciais de utilizadores internos para aceder diretamente a VMs ou hosts e aos dados nos mesmos. |
Router de tecido |
Acesso físico ou administrativo |
Este ataque pode obter o controlo de raiz sobre um router de tecido para intercetar todo o tráfego e exfiltrar ou adulterar quaisquer dados de texto não cifrado que estejam em trânsito no tecido. |
|
Placa principal |
Firmware |
Este ataque pode enviar imagens de firmware defeituosas para as placas-mãe, tornando-as permanentemente inoperáveis e impossibilitando a recuperação de dados. Um atacante pode enviar firmware conhecido como vulnerável para máquinas para recuperar o controlo através de explorações que permitem a execução de código remoto. |
|
Atacante externo com acesso lógico |
Servidor |
VMs |
Este ataque pode iniciar padrões de ataque de side-channel públicos em VMs. Estes ataques podem provocar fugas de dados de instâncias em execução no mesmo hardware ou do software do sistema anfitrião. |
SSDs |
VMs |
Este ataque pode usar o acesso direto a SSDs PCIe para tentar inferir dados de co-inquilinos. |
|
Memória |
VMs |
Este vetor de ataque pode usar canais laterais para pesquisar chaves de encriptação valiosas na memória. |
|
Servidor |
VMs bare metal |
Este vetor de ataque pode usar instâncias de metal nu para analisar todos os periféricos para encontrar um componente vulnerável que lhe permita persistir na máquina e atacar inquilinos subsequentes. |
Mapeamento de componentes de hardware do Titânio para ameaças
A arquitetura de segurança de hardware Titanium usa uma abordagem de várias camadas para ajudar a resolver ameaças de infraestrutura específicas e para evitar pontos únicos de falha. Estas ameaças podem ter origem em erros ou em atores maliciosos. As ameaças abrangem as operações de hardware e podem explorar vulnerabilidades nos servidores, nas redes e no plano de controlo. Não existe uma única solução que possa resolver todos estes vetores de ataque, mas as funcionalidades combinadas do Titanium ajudam a proteger os dados dos nossos utilizadores e as nossas instâncias de computação na nuvem.
Cenário: operações de hardware não autorizadas
As operações de hardware não autorizadas representam uma ameaça à segurança dos dados, uma vez que podem levar à exfiltração de dados dos centros de dados e à modificação do hardware e do firmware. A arquitetura de segurança de hardware Titanium da Google ajuda a defender-se contra estas ameaças através de várias medidas de segurança, incluindo RoTs criptográficos, placas-mãe personalizadas e processadores de E/S. Estes componentes funcionam em conjunto para oferecer uma defesa em camadas resistente a uma vasta gama de ataques.
A tabela seguinte descreve algumas das ameaças de hardware não autorizadas e como a arquitetura Titanium pode mitigá-las.
| Ameaça | Mitigação de titânio |
|---|---|
Um atacante extrai unidades de dados individuais dos centros de dados para aceder aos dados nelas. |
As chaves de encriptação de dados em repouso para produtos e serviços de armazenamento nunca são armazenadas persistentemente nas máquinas às quais o suporte de armazenamento está anexado. As capacidades de autoencriptação incorporadas dos suportes de armazenamento também estão ativadas para defesa em profundidade e usam chaves que nunca são armazenadas persistentemente no próprio suporte. As RTMs Caliptra permitem que a 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 libertar chaves de um serviço de gestão de chaves para instâncias do serviço de armazenamento. As máquinas que estão de alguma forma configuradas de forma maliciosa com firmware não intencional não podem aceder às chaves necessárias para desencriptar os dados armazenados. As RoTs incorporadas nos pacotes de silício ancoram as identidades criptográficas relevantes no pacote de chip. Os interpositores de função única são a parte principal da nossa segurança do plano de dados e encriptam os dados em cada passo de processamento. Os TOPs oferecem as seguintes vantagens:
São usadas soluções de software comprovadas, como o dm-crypt, para unidades de menor desempenho, onde a redução da superfície de ataque é fundamental, como alguns exemplos de utilização de unidades de arranque. |
Um atacante toca num cabo de rede e lê bytes no fio ou na fibra. |
Os TOPs encriptam os dados em trânsito, o que elimina a oportunidade de uma ameaça detetar dados valiosos na rede. As nossas NICs usam a norma de descarregamento de hardware PSP. Esta norma oferece uma encriptação rentável com uma diminuição mínima no desempenho. Estas implementações são compatíveis com a norma FIPS. Os dados de clientes são encriptados quando transitam por switches Top of Rack (ToR) ou de tecido. Algumas infraestruturas de aprendizagem automática usam mecanismos de segurança de transporte proprietários. |
Um atacante substitui os chips de memória flash que contêm código mutável no centro de dados ou na cadeia de fornecimento para executar código malicioso nos servidores. |
Os chips Titan são concebidos para rejeitar o ataque e não concedem acesso às credenciais armazenadas no interior. Mesmo que um atacante reescreva o conteúdo dos chips flash não voláteis, o RoT do Titan comunica de forma segura uma medição do código ao plano de controlo da Google, que foi concebido para bloquear o dispositivo. A Google revoga rotineiramente código descontinuado ou conhecido como vulnerável à escala global na nossa frota através da utilização de chips Titan. |
Um atacante insere dispositivos adversariais em interfaces físicas de servidores ou cartões de centros de dados para executar código malicioso ou roubar dados. |
Os designs personalizados da placa-mãe removem as interfaces usadas para inserir dispositivos adversariais. As configurações da unidade de gestão de memória de entrada/saída (IOMMU) estão implementadas para impedir os screamers de PCIe em todo o nosso firmware. (Os screamers PCIe são concebidos para ler e escrever pacotes arbitrários na estrutura PCIe.) À medida que a indústria amadurece, estamos a complementar esta proteção com o PCI IDE para mitigar ainda mais os interpositores de PCI mais sofisticados. ALTS e TLS são as únicas ligações de rede de autenticação e autorização aceites para funções de controlo e gestão em TOPs e BMCs. Os RTMs do Caliptra bloqueiam qualquer firmware não aprovado. Os nossos periféricos fidedignos atestam a respetiva identidade de hardware e integridade do código ao nosso plano de controlo, e nenhum servidor é admitido na produção se o registo de atestação não corresponder à intenção de hardware e software. |
Um atacante usa um ataque de arranque a frio no centro de dados para aceder aos dados na RAM. |
A encriptação na memória da computação confidencial protege todos os dados confidenciais ou chaves de encriptação na RAM. A encriptação de DRAM também está ativada em máquinas implementadas sem computação confidencial em centros de dados periféricos de garantia inferior. |
Cenário: exploração de servidores ou redes por utilizadores não autorizados
Os atacantes podem usar a nuvem pública para alojar as respetivas cargas de trabalho maliciosas na nossa infraestrutura partilhada e depositar dados nos nossos serviços públicos. Os adversários externos, desde indivíduos isolados a estados-nações, também podem tentar obter acesso privilegiado remoto.
Para mitigar estas ações, a arquitetura de segurança de hardware Titanium usa chips Titan e Caliptra RTM para aprovisionar credenciais de tempo de execução de forma segura e limitar privilégios no hardware e nos sistemas operativos. A computação confidencial ajuda a proteger contra a manipulação da memória do sistema, quer seja física ou através de ataques de hipervisor, e os chips Titan rejeitam ou detetam atualizações de software não autorizadas.
A tabela seguinte descreve algumas das ameaças de exploração de servidores e redes e como a arquitetura Titanium as pode mitigar.
| Ameaça | Mitigação de titânio |
|---|---|
Um atacante explora uma vulnerabilidade para escapar à respetiva VM e obter acesso a dados e outras VMs em execução na mesma máquina. |
Os enclaves de computação confidencial restringem a exfiltração de dados de carga de trabalho, quer estejam em processamento ou inativos. Esta mitigação impede que um atacante que escapou da VM aceda aos dados em utilização. Os chips Titan e os RTMs Caliptra impedem que o atacante tenha acesso persistente. É provável que sejam detetadas tentativas de acesso persistente, uma vez que a configuração da máquina não corresponde à configuração e à política de código desse servidor. Esta correspondência é necessária antes de a máquina poder alojar cargas de trabalho de produção após um reinício. |
Um atacante lança padrões de ataque de side-channel públicos em VMs. |
O nosso sistema de gestão de frotas, que usa chips Titan, pode revogar software conhecido por ser vulnerável. A revogação pode bloquear quaisquer ataques subsequentes que tenham como alvo estas vulnerabilidades conhecidas. As medições de integridade baseadas no Titan também oferecem uma elevada confiança de que as mitigações, que podem ter de ser implementadas urgentemente, foram implementadas nas máquinas de destino. Reforçamos esta abordagem mantendo-nos na vanguarda da investigação e mitigação de canais laterais, através de técnicas como retpoline e agendamento de núcleos, e investigação avançada sobre Meltdown, Spectre, Zenbleed, Downfall e outros. |
Um atacante usa o acesso direto a SSDs que fornecem armazenamento a vários inquilinos para tentar inferir dados de co-inquilinos. |
A encriptação de dados em repouso ajuda a proteger contra ataques lógicos e físicos com uma variedade de interpositores. Para recursos que não são partilhados, os dados de cada inquilino são encriptados com chaves diferentes, o que mitiga a oportunidade de ataques de acesso direto contra o SSD. |
Um atacante analisa a memória e usa canais laterais para pesquisar chaves de encriptação de dados ou credenciais. |
Os chips Titan permitem o aprovisionamento de credenciais seladas por máquina. Mesmo que um atacante obtenha acesso de raiz numa máquina, as respetivas credenciais estão associadas exclusivamente à identidade privada do chip Titan local. |
Um atacante compra instâncias bare-metal e analisa todos os periféricos para tentar obter acesso persistente. |
Os chips Titan rejeitam qualquer atualização de software não autorizada, incluindo envios maliciosos para controlo persistente. O nosso fluxo de trabalho de máquina confirma positivamente as medições de integridade esperadas num ciclo de energia atestado do sistema completo entre clientes de hardware sem sistema operativo. |
Cenário: exploração de servidores ou redes por comportamento do plano de controlo não autorizado
Os insiders do plano de controlo desonestos podem tentar explorar os sistemas da Google de várias formas, incluindo tentar obter o controlo de raiz sobre um router de estrutura, enviar imagens de firmware defeituosas para as placas-mãe e intercetar o tráfego de rede. A arquitetura de segurança de hardware Titanium defende-se contra estas ameaças através da utilização de vários mecanismos, incluindo chips Titan, RTMs Caliptra, placas-mãe personalizadas e serviços isolados tolerantes a falhas de back-end.
A tabela seguinte descreve algumas das ameaças do plano de controlo e como a arquitetura do Titanium as pode mitigar.
| Ameaça | Mitigação de titânio |
|---|---|
Um atacante usa credenciais de insider para aceder a VMs do Compute Engine que estão a servir como a camada fundamental para os ambientes dos clientes. |
Os TOPs ajudam a garantir que os administradores não têm acesso aos ambientes dos clientes. Sem acesso, o pessoal da Google não pode usar as respetivas credenciais para aceder à camada de hardware e software privilegiada que está abaixo das VMs dos nossos clientes. O acesso privilegiado da Google aos dados de clientes está bloqueado porque os dados só estão acessíveis através de APIs definidas. |
Um atacante envia imagens de firmware defeituosas em grande escala para as placas-mãe, tornando-as permanentemente inutilizáveis. |
Os RoTs dos chips Titan rejeitam qualquer atualização de software não autorizada, incluindo envios maliciosos para controlo persistente. Os designs personalizados da placa-mãe usam uma rede alternativa de sinais que interligam todas as nossas RoTs à RoT da plataforma. A RoT da plataforma contém firmware de cópia de segurança para dispositivos críticos. Mesmo que a rede e o PCI tenham sido danificados por um atacante, a rede fora da banda (OOB) pode reparar o sistema. |
Um atacante envia firmware de produção obsoleto conhecido como vulnerável para máquinas para recuperar o controlo através de vulnerabilidades públicas. |
Os chips Titan rejeitam envios incorretos e ajudam a aplicar a revogação de código conhecido como vulnerável. Atestam a versão de firmware implementada na máquina e rejeitam a máquina no plano de controlo. Esta mitigação ajuda a impedir a execução de trabalhos numa máquina em mau estado e aciona a investigação ou a reparação, conforme necessário. |
Um atacante abusa das capacidades de depuração de silício necessárias para a continuidade da empresa, que oferecem o nível mais elevado concebível de acesso aos dados em sistemas de servidores. |
O Caliptra RTM ajuda a garantir que todos os parâmetros que ativam as interfaces de depuração invasivas, quer estejam ligados logicamente ou através de inserção física direta, estão configurados de forma fiável, medidos criptograficamente e comunicados ao nosso plano de controlo através de um protocolo de atestação. Apenas as máquinas no estado pretendido obtêm acesso para publicar cargas de trabalho de produção. |
Um atacante ganha o controlo de um serviço de back-end para poder aceder aos ambientes dos clientes. |
Os serviços regionalizados tolerantes a falhas de back-end são uma infraestrutura de credenciais regionalizada que não permite o acesso humano unilateral. Além de impedir o início de sessão do operador nos nós de computação, os operadores também não podem iniciar sessão no plano de controlo para obter material de chaves. Os enclaves de computação confidencial na arquitetura Titanium isolam os nossos serviços de autorização e aprovisionamento de chaves de back-end dos privilégios de raiz da máquina. As hierarquias de chaves ajudam a proteger as chaves de assinatura e autorização da maioria dos serviços. Com as hierarquias de chaves, as chaves raiz estão em chaves isoladas que são mantidas em HSMs e cofres, ou chaves que são mantidas em produção por um quorum Paxos de armazenamentos de dados na memória. |
O que se segue?
- Leia a vista geral do design de segurança da infraestrutura.
- Implemente a computação confidencial.