Visão geral do design de segurança da infraestrutura do Google

O conteúdo aqui apresentado foi corrigido em janeiro de 2017 e representa o estado de quando foi elaborado. Os sistemas e as políticas de segurança do Google podem mudar futuramente, conforme aprimorarmos a proteção para nossos clientes.

Resumo para diretores de TI

  • O Google tem uma infraestrutura técnica de nível internacional, que foi desenvolvida para garantir a segurança durante todo o ciclo de processamento das informações no Google. Essa infraestrutura oferece segurança para implementação de serviços, armazenamento de dados com garantia de privacidade do usuário final, comunicação entre serviços, comunicação privada com os clientes pela Internet e operações dos administradores.
  • O Google usa essa infraestrutura para criar seus serviços de Internet, que incluem serviços para clientes, como Pesquisa, Gmail e Fotos, e serviços para empresas, como G Suite e Google Cloud Platform.
  • A segurança da infraestrutura foi projetada em camadas progressivas, a partir da segurança física dos data centers até a segurança do hardware e software subjacentes à infraestrutura. Por fim, restrições e processos técnicos estabelecidos para garantir a segurança operacional.
  • O Google investe maciçamente na proteção da sua infraestrutura, com muitas centenas de engenheiros de todos os setores do Google dedicados à segurança e à privacidade. Muitos deles são autoridades reconhecidas no setor.

Introdução

Este documento contém uma visão geral do desenvolvimento da segurança na infraestrutura técnica do Google. É uma infraestrutura de nível internacional, que foi desenvolvida para garantir a segurança durante todo o ciclo de processamento das informações no Google. Essa infraestrutura oferece segurança para implementação de serviços, armazenamento de dados com garantia de privacidade do usuário final, comunicação entre serviços, comunicação privada com os clientes pela Internet e operações dos administradores.

O Google usa essa infraestrutura para criar seus serviços de Internet, que incluem serviços para clientes, como Pesquisa, Gmail e Fotos, e serviços para empresas, como G Suite e Google Cloud Platform.

Descreveremos a segurança dessa infraestrutura em camadas progressivas, a partir da segurança física de nossos data centers até a segurança do hardware e software subjacentes à infraestrutura. Por fim, abordaremos as restrições e os processos técnicos estabelecidos para garantir a segurança operacional.

Camadas de segurança da infraestrutura do Google, que vão da infraestrutura de hardware na base à camada superior de segurança operacional. O conteúdo de cada camada será descrito detalhadamente.

Nível básico de segurança da infraestrutura

Nesta seção, descreveremos como proteger as camadas mais básicas de nossa infraestrutura, do local físico ao hardware específico dos data centers à pilha de software em execução em cada máquina.

Segurança nos locais físicos

O Google desenvolve e cria seus próprios data centers, que incorporam várias camadas de segurança física. O acesso a esses data centers é permitido somente a um pequeno número de funcionários do Google. Usamos várias camadas de segurança física para proteger nossos data centers. Além disso, usamos tecnologias, como identificação biométrica, câmeras de detecção de metal, cancelas para veículos e sistemas de detecção de intrusão a laser. E o Google hospeda alguns servidores em data centers de terceiros, onde são aplicadas medidas de segurança física controladas pelo Google às camadas de segurança fornecidas pelo operador do data center. Por exemplo, nesses locais, podemos operar sistemas de identificação biométrica, câmeras e detectores de metal, todos independentes.

Design e objetivo do hardware

Um data center do Google consiste em milhares de servidores conectados a uma rede local. Tanto as placas de servidor quanto os equipamentos de rede têm design exclusivo do Google. Avaliamos os fornecedores de componentes com quem trabalhamos. Nessa parceria com os fornecedores, escolhemos os componentes cuidadosamente, além de inspecionarmos e validarmos suas propriedades de segurança. Também projetamos chips personalizados, inclusive um chip de segurança de hardware que atualmente é implementado em servidores e periféricos. Com esses chips, podemos identificar e autenticar a legitimidade dos dispositivos do Google no hardware.

Segurança na pilha de inicialização e identidade de máquina

Os servidores do Google usam várias tecnologias para assegurar que inicializarão a pilha de software correta. Usamos assinaturas criptográficas nos componentes mais básicos, como BIOS, carregador de inicialização, kernel e imagem de base do sistema operacional. Essas assinaturas podem ser validadas em cada inicialização ou atualização. Os componentes são todos desenvolvidos, controlados e reforçados pelo Google. Procuramos sempre melhorar a segurança em cada nova geração de hardware. Por exemplo, dependendo da geração do design do servidor, criamos uma raiz de confiança para a cadeia de inicialização em um chip de firmware bloqueável, um microcontrolador que executa o código de segurança desenvolvido pelo Google ou o chip de segurança do Google anteriormente citado.

Todo servidor do data center tem uma identidade própria que pode ser associada à raiz de confiança do hardware e ao software usado para inicialização da máquina. Essa identidade serve para autenticar chamadas de API enviadas ou recebidas dos serviços de gerenciamento de nível inferior na máquina.

O Google tem sistemas automatizados autorais para garantir que os servidores executem versões atualizadas das suas pilhas de software (incluindo patches de segurança), a fim de detectar e diagnosticar problemas de hardware e software, e também interromper o serviço se necessário.

Segurança na implementação de serviços

Agora vamos descrever como usamos hardware e software de base para garantir que um serviço seja implementado com segurança em nossa infraestrutura. Consideramos "serviço" um aplicativo binário criado por um desenvolvedor para execução em nossa infraestrutura. Por exemplo, um servidor SMTP do Gmail, um servidor de armazenamento do BigTable, um transcodificador de vídeo do YouTube ou um conversor sandbox do App Engine que execute um aplicativo do cliente. Milhares de máquinas podem executar cópias do mesmo serviço para processar o volume necessário de carga de trabalho. Os serviços em execução na infraestrutura são controlados por um serviço de coordenação em cluster chamado Borg.

Como veremos nesta seção, a infraestrutura não pressupõe a existência de algum nível de confiança entre os serviços executados na infraestrutura. Em outras palavras, a infraestrutura é fundamentalmente projetada para ser multilocatária.

Identidade, integridade e isolamento de serviço

Usamos autenticação criptográfica e autorização na camada de aplicativo para a comunicação entre os serviços. Esse procedimento oferece um forte controle de acesso em um nível de abstração e a granularidade que administradores e serviços entendem naturalmente.

Não contamos com a segmentação da rede interna ou o uso de firewall como mecanismos primários de segurança, apesar de usarmos filtragem de entrada e saída em vários pontos da rede para evitar a falsificação (spoofing) de IP como uma camada adicional de segurança. Com essa abordagem, também conseguimos ampliar o desempenho e a disponibilidade da rede.

Todo dispositivo executado na infraestrutura tem uma identidade de conta de serviço associada. O serviço recebe credenciais criptográficas que usa para comprovar sua identidade ao realizar ou receber chamadas de procedimento remotas (RPCs) para/de outros serviços. Os clientes usam essas identidades para assegurar que estão se comunicando com o servidor certo. E os servidores as utilizam para limitar o acesso de determinados clientes a métodos e dados.

O código fonte do Google fica armazenado em um repositório central, onde as versões atuais e anteriores são passíveis de auditoria. A infraestrutura também pode ser configurada para exigir que os elementos binários de um serviço sejam desenvolvidos com um código fonte específico revisado, verificado e testado. As revisões do código requerem inspeção e aprovação de, pelo menos, um engenheiro, que não seja o autor. Além disso, o sistema determina que as modificações de código em um sistema têm que ser aprovadas pelos proprietários do sistema em questão. Esses requisitos limitam a possibilidade de uma pessoa com informações privilegiadas ou um adversário realizar modificações maliciosas no código fonte, e ainda oferecem uma trilha forênsica que remete o serviço a sua origem.

Temos várias técnicas de isolamento e sandbox para proteger um serviço de outros serviços em execução na mesma máquina. Essas técnicas incluem a separação normal do usuário de Linux, sandboxes de idioma e baseadas em kernel, e virtualização de hardware. Em geral, usamos mais camadas de isolamento para as cargas de trabalho que apresentam maior risco. Por exemplo, na execução de conversores de formatos de arquivo complexos em dados fornecidos pelo usuário ou na execução de código fornecido pelo usuário para produtos como Google App Engine ou Google Compute Engine. Como uma iniciativa extra de segurança, ativamos serviços muito confidenciais, como o serviço de coordenação em cluster e alguns serviços de gerenciamento de chaves, para serem executados com exclusividade em máquinas dedicadas.

Gerenciamento de acesso entre serviços

O proprietário de um serviço pode usar os recursos do gerenciamento de acesso da infraestrutura a fim de especificar exatamente com quais outros serviços ele pode se comunicar. Por exemplo, um serviço talvez queira oferecer algumas APIs somente a uma lista de permissões específica de outros serviços. Esse serviço pode ser configurado com a lista de permissões das identidades de conta do serviço permitido. Em seguida, essa restrição de acesso é automaticamente aplicada pela infraestrutura.

Os engenheiros do Google que acessam os serviços também recebem identidades individuais. Sendo assim, os serviços podem ser igualmente configurados para permitir ou negar o acesso desses engenheiros. Todos esses tipos de identidade (máquina, serviço e funcionário) ficam em um namespace global mantido pela infraestrutura. Como será explicado posteriormente neste documento, as identidades de usuários finais são processadas separadamente.

A infraestrutura oferece um avançado sistema de fluxo de gerenciamento para essas identidades internas, que inclui cadeias de aprovação, registro e notificação. Por exemplo, essas identidades podem acessar grupos de controle por meio de um sistema que aceita controle duplo. Ou seja, um engenheiro pode propor uma alteração a um grupo que deve ser aprovada por outro engenheiro (que também é administrador do grupo). Esse sistema aceita processos seguros de gerenciamento de acesso para lidar com os milhares de serviços em execução na infraestrutura.

Além do mecanismo de controle de acesso automático no nível da API, a infraestrutura também permite que os serviços leiam a ACL central e os bancos de dados de grupos, para que possam implementar seu próprio controle de acesso personalizado e detalhado onde necessário.

Criptografia da comunicação entre serviços

Além dos recursos de autenticação e autorização de RPC abordados nas seções anteriores, a infraestrutura oferece privacidade criptográfica e integridade aos dados de RPC na rede. Para oferecer esses benefícios de segurança a outros protocolos de camada de aplicativo, como o HTTP, eles são encapsulados nos mecanismos de RPC de nossa infraestrutura. Em essência, o procedimento isola a camada de aplicativo e remove dependências na segurança do caminho da rede. A comunicação criptografada entre serviços pode permanecer segura mesmo em caso de violação da rede ou comprometimento de um dispositivo da rede.

Os serviços podem configurar o nível de proteção criptográfica desejado para cada RPC da infraestrutura. Por exemplo, somente configurar proteção à integridade dos dados de pouco valor existentes nos data centers. Para proteção contra adversários sofisticados que podem tentar violar os links de nossa WAN privada, a infraestrutura criptografa automaticamente todo o tráfego de RPC que percorre a WAN entre os data centers, sem necessidade de uma configuração explícita do serviço. Começamos a implementar aceleradores criptográficos de hardware que permitirão estender essa criptografia padrão a todo o tráfego de RPC da infraestrutura em nossos data centers.

Gerenciamento de acesso a dados do usuário final

Um serviço típico do Google é desenvolvido para executar algo para o usuário final. Por exemplo, um usuário final pode armazenar e-mail no Gmail. A interação do usuário final com um aplicativo como o Gmail engloba outros serviços existentes na infraestrutura. Por exemplo, o serviço Gmail pode chamar uma API fornecida pelo serviço Contatos para acessar o catálogo de endereços do usuário final.

Vimos na seção anterior que o serviço Contatos pode ser configurado para que sejam permitidas somente as solicitações de RPC provenientes do serviço Gmail (ou de outros serviços específicos que o serviço Contatos queira permitir).

Contudo, esse ainda é um conjunto muito amplo de permissões. No escopo dessa permissão, o serviço Gmail poderia solicitar os contatos de qualquer usuário a qualquer momento.

Como o serviço Gmail faz uma solicitação de RPC ao serviço Contatos em nome de determinado usuário final, a infraestrutura oferece um recurso para que o Gmail apresente um "tíquete de permissão de usuário final" como parte da RPC. Esse tíquete comprova que o Gmail está atendendo a uma solicitação desse usuário final específico. Dessa forma, o serviço Contatos pode implementar uma salvaguarda em que ele só retorna dados ao usuário final indicado no tíquete.

A infraestrutura fornece um serviço central de identidade de usuário que emite os "tíquetes de permissão". O login do usuário final é verificado pelo serviço de identidade central que, em seguida, emite uma credencial de usuário, como um cookie ou token OAuth, para o dispositivo cliente do usuário. As solicitações subsequentes do dispositivo cliente no Google precisarão apresentar essa credencial de usuário.

Quando um serviço recebe a credencial de um usuário final, ele transfere a credencial para verificação do serviço de identidade central. Se a credencial do usuário final estiver correta, o serviço de identidade central retornará um "tíquete de permissão de usuário final" de curta duração para ser usado com as RPCs relacionadas à solicitação. No exemplo, o serviço a receber o "tíquete de permissão de usuário final" é o Gmail, que então o transmitirá ao serviço Contatos. A partir daí, no caso de chamadas em cascata, o "tíquete de permissão de usuário final" poderá ser repassado pelo serviço de chamada àquele que efetuou a chamada, como parte da chamada de RPC.

Identidade de serviço e gerenciamento de acesso: a infraestrutura oferece identidade de serviço, autenticação mútua automática, comunicação criptografada entre serviços e aplicação de políticas de acesso definidas pelo proprietário do serviço.

Segurança no armazenamento de dados

Até o momento, descrevemos como implementar os serviços com segurança. Agora veremos como implementar um armazenamento de dados seguro na infraestrutura.

Criptografia em repouso

A infraestrutura do Google oferece vários serviços de armazenamento, como BigTable e Spanner, e um serviço central de gerenciamento de chaves. A maioria dos aplicativos no Google acessa o armazenamento físico indiretamente por meio desses serviços de armazenamento. Os serviços de armazenamento podem ser configurados para usar as chaves do serviço central de gerenciamento de chaves a fim de descriptografar os dados antes que eles sejam gravados no armazenamento físico. O serviço de gerenciamento de chaves aceita a troca automática de chaves, oferece registros de auditoria extensos e integra-se aos tíquetes de permissão de usuário final citados anteriormente, de modo a vincular as chaves a determinados usuários finais.

A realização da criptografia na camada de aplicativo possibilita à infraestrutura isolar-se de possíveis ameaças nos níveis mais baixos de armazenamento, como o firmware de disco malicioso. Isso quer dizer que a infraestrutura também implementa camadas adicionais de proteção. Ativamos suporte à criptografia de hardware em discos rígidos e SSDs, e rastreamos meticulosamente cada unidade durante seu ciclo de vida. Para que um dispositivo de armazenamento criptografado desativado possa sair fisicamente da sua custódia, ele passa por um processo de limpeza de várias etapas que inclui duas verificações independentes. Os dispositivos que não passarem por esse procedimento de limpeza serão fisicamente destruídos (ou seja, picotados) no local.

Exclusão de dados

O processo de exclusão de dados no Google geralmente começa com dados específicos sendo "programados para exclusão", em vez de serem removidos completamente. Com isso, podemos recuperar dados de exclusões acidentais, sejam as executadas pelo cliente ou causadas por um bug ou um erro de processamento interno. Depois de receberem a marcação de "programados para exclusão", os dados são excluídos de acordo com políticas específicas do serviço.

Quando o usuário final exclui a conta inteira, a infraestrutura notifica o serviço que processa os dados do usuário de que a conta foi excluída. Os serviços podem programar a exclusão dos dados associados à conta de usuário final que foi excluída. Com esse recurso, o desenvolvedor do serviço pode facilmente implementar o controle de usuário final.

Segurança na comunicação na Internet

Anteriormente neste documento, descrevemos como é feita a proteção dos serviços em nossa infraestrutura. Nesta seção, descreveremos como proteger a comunicação entre a Internet e esses serviços.

Como abordado antes, a infraestrutura consiste em um grande número de máquinas físicas que são interconectadas pela LAN e pela WAN. A segurança da comunicação entre os serviços independe da segurança da rede. Entretanto, isolamos a infraestrutura da Internet em um espaço IP privado para facilitar a implementação de proteções adicionais, como as defesas contra ataques de negação de serviço (DoS). Dessa forma, expomos somente um subconjunto das máquinas diretamente ao tráfego externo da Internet.

Serviço Google Front End

Para se disponibilizar na Internet, um serviço pode se registrar com um serviço de infraestrutura chamado Google Front End (GFE). O GFE verifica se as conexões TLS usam os certificados corretos e se seguem as práticas recomendadas, como dar suporte ao protocolo PFS. Além disso, o GFE aplica proteções contra ataques de negação de serviço. Esse tópico será abordado posteriormente em maior detalhe. Em seguida, o GFE encaminha as solicitações para o serviço usando o protocolo de segurança RPC explicado anteriormente.

Na verdade, todo serviço interno que queira se autopublicar externamente utiliza o GFE como um front-end inteligente com proxy reverso. Esse front-end proporciona hospedagem de IP público do seu nome DNS público, proteção contra negação de serviço (DoS) e terminação TLS. Note que os GFEs são executados na infraestrutura como qualquer outro serviço. Portanto, eles têm a capacidade de se ajustar para atender aos volumes de solicitações recebidos.

Proteção contra negação de serviço (DoS)

O grande porte de nossa infraestrutura permite que o Google absorva muitos ataques de DoS. Temos proteções contra DoS em vários níveis e camadas que reduzem ainda mais o risco de impacto causado por um ataque de DoS em um serviço em execução por trás de um GFE.

Depois que nosso backbone entrega uma conexão externa a um de nossos data centers, ela passa por várias camadas de balanceamento de carga de hardware e software. Esses balanceadores de carga fornecem informações sobre o tráfego de entrada a um serviço de DoS central executado na infraestrutura. Ao detectar qualquer ataque de DoS, o serviço de DoS central pode configurar os balanceadores de carga para descartar ou acelerar o tráfego associado ao ataque.

Na camada seguinte, as instâncias do GFE também fornecem informações sobre as solicitações recebidas ao serviço de DoS central, incluindo informações que os balanceadores de carga não têm sobre a camada de aplicativo. O serviço de DoS central também pode configurar as instâncias do GFE para descartar ou acelerar o tráfego de ataque.

Autenticação de usuário

Depois da proteção contra DoS, a próxima camada de defesa é proveniente do serviço de identidade central. Normalmente, esse serviço aparece para os usuários finais como a página de login do Google. Além de solicitar um nome de usuário e uma senha, o serviço também solicita aos usuários informações adicionais e inteligentes, com base em fatores de risco. Por exemplo, se eles se conectaram no mesmo dispositivo ou em local semelhante anteriormente. Após a autenticação do usuário, o serviço de identidade emite credenciais, como cookies e tokens OAuth, que podem ser usadas para chamadas subsequentes.

No login, os usuários também têm a opção de empregar um segundo fator, como OTPs ou chaves de segurança antiphishing. Para garantir mais benefícios além do Google, participamos da FIDO Alliance com vários fornecedores de dispositivos, a fim de desenvolver o padrão aberto Universal 2nd Factor (U2F). Esses dispositivos agora estão disponíveis no mercado. Outros importantes serviços da Web também nos acompanharam e implementaram o suporte a U2F.

Segurança operacional

Nas seções anteriores, descrevemos como a segurança é desenvolvida em nossa infraestrutura e também alguns dos mecanismos que garantem a segurança operacional, como os controles de acesso em RPCs.

Agora vamos descrever como de fato operamos a segurança da infraestrutura. Criamos um software de infraestrutura com segurança, protegemos as máquinas e as credenciais dos funcionários e defendemos a infraestrutura de ameaças provenientes de pessoas com informações privilegiadas e agentes externos.

Segurança no desenvolvimento de software

Além dos recursos de controle da origem e revisão dupla descritos anteriormente, fornecemos bibliotecas que evitam que os desenvolvedores introduzam certas classes de bugs de segurança. Por exemplo, temos bibliotecas que eliminam vulnerabilidades de XSS de aplicativos da Web. Também contamos com ferramentas automatizadas para a detecção automática de bugs de segurança, como fuzzers, ferramentas de análise estática e scanners de segurança na Web.

Como procedimento de verificação final, realizamos revisões manuais de segurança, que incluem desde triagens rápidas em recursos de menor risco a revisões mais detalhadas de design e implementação em recursos de maior risco. Essas revisões são realizadas por uma equipe que conta com especialistas nas áreas de segurança na Web, criptografia e segurança do sistema operacional. As revisões também podem resultar em novos recursos da biblioteca de segurança e em novos fuzzers que podem ser aplicados a futuros produtos.

Além disso, executamos um Vulnerability Rewards Program (programa de recompensas por vulnerabilidade), que paga a quem conseguir descobrir e nos informar da presença de bugs em nossa infraestrutura ou aplicativos. Nesse programa, já pagamos recompensas de vários milhões de dólares.

O Google também empenha um grande esforço na detecção de explorações de dia zero e outros problemas de segurança em todo software de código aberto que usamos, e no encaminhamento desses problemas. Por exemplo, depois que o bug OpenSSL Heartbleed foi encontrado no Google, fomos quem mais enviou CVEs e correções de bug de segurança ao hipervisor Linux KVM.

Manter a segurança de dispositivos e credenciais de funcionários

Fizemos um grande investimento na proteção de dispositivos e credenciais de nossos funcionários e também no monitoramento de atividades para detectar possíveis comprometimentos ou atividades internas ilícitas. Esse é um aspecto crítico de nosso investimento para garantir a operação segura de nossa infraestrutura.

O phishing sofisticado tem sido um meio persistente, direcionado aos nossos funcionários. Para nos protegermos dessa ameaça, substituímos o segundo fator de OTP, passível de phishing, pelo uso obrigatório de chaves de segurança compatíveis com U2F nas contas de nossos funcionários.

Fazemos um alto investimento no monitoramento dos dispositivos cliente que nossos funcionários usam para operar a infraestrutura. Mantemos as imagens do sistema operacional desses dispositivos cliente com patches de segurança atualizados, e controlamos os aplicativos que podem ser instalados. Além disso, utilizamos sistemas para verificar se os apps instalados pelo usuário, as extensões de navegador e todo o conteúdo pesquisado na Web estão em conformidade com o padrão de clientes corporativos.

A inclusão na LAN corporativa não é nosso principal mecanismo de concessão de privilégios de acesso. Preferimos usar controles de gerenciamento de acesso por aplicativo para liberarmos os aplicativos internos somente a usuários específicos, provenientes de um dispositivo gerenciado corretamente e de redes e localidades esperadas. Para saber mais, consulte as informações adicionais sobre "BeyondCorp".

Reduzir o risco de pessoas com informações privilegiadas

Adotamos uma postura agressiva e ativa para limitar e monitorar as atividades dos funcionários que têm acesso administrativo à infraestrutura. Trabalhamos incessantemente para eliminar a necessidade de acesso privilegiado a determinadas tarefas. Para isso, implementamos a automação para executar as mesmas tarefas, de maneira segura e controlada. Isso inclui exigir aprovações duplas para algumas ações e introduzir APIs limitadas que possibilitam a depuração sem expor informações confidenciais.

O acesso do funcionário do Google a informações do usuário final pode ser registrado por meio de ganchos em nível inferior na infraestrutura. A equipe de segurança do Google monitora ativamente padrões de acesso e investiga eventos incomuns.

Detecção de intrusões

O Google tem pipelines sofisticados de processamento de dados, que integram sinais do host a dispositivos individuais, sinais de rede de vários pontos de monitoramento na infraestrutura e sinais de serviços da infraestrutura. Regras e inteligência de máquina dispostos sobre esses pipelines fornecem avisos de possíveis incidentes aos engenheiros de segurança operacional. Nossas equipes de investigação e resposta a incidentes se dedicam 24 horas do dia, 365 dias do ano a filtrar, investigar e responder a esses possíveis incidentes. Realizamos exercícios da Red Team para avaliar e aprimorar a eficácia de nossos mecanismos de detecção e resposta.

Segurança no Google Cloud Platform (GCP)

Nesta seção, destacamos como nossa infraestrutura de nuvem pública, GCP, se beneficia da segurança da infraestrutura subjacente. Nesta seção, usaremos o Google Compute Engine como um exemplo de serviço e descreveremos detalhadamente os aprimoramentos de segurança específicos ao serviço que desenvolvemos na infraestrutura.

Com o Google Compute Engine, os clientes podem executar suas máquinas virtuais na infraestrutura do Google. A implementação do Google Compute Engine consiste em vários componentes lógicos, principalmente o painel de controle de gerenciamento e as próprias máquinas virtuais.

O painel de controle de gerenciamento exibe a superfície externa da API e coordena tarefas como a criação e a migração de máquinas virtuais. Ele executa vários serviços na infraestrutura, o que possibilita a aquisição de recursos de integridade fundamentais, como a cadeia de inicialização segura. Os serviços individuais são executados em diferentes contas de serviço internas, para que cada serviço tenha somente as permissões necessárias para realizar chamadas de procedimento remoto (RPCs) para o resto do painel de controle. Como abordado anteriormente, o código de todos esses serviços fica armazenado no repositório central de código fonte do Google. Há também uma trilha de auditoria entre o código e os elementos binários que são finalmente implementados.

O painel de controle do Google Compute Engine exibe sua API por meio do GFE. Com isso, tira proveito dos recursos de segurança da infraestrutura, como proteção contra negação de serviço (DoS) e suporte a SSL/TLS com gerenciamento centralizado. Os clientes podem ter proteções semelhantes para aplicativos em execução nas suas máquinas virtuais com Google Compute Engine. Basta que escolham o serviço opcional Google Cloud Load Balancer, desenvolvido a partir do GFE e capaz de minimizar vários tipos de ataques de DoS.

A autenticação do usuário final na API do painel de controle do Google Compute Engine é realizada por meio do serviço de identidade centralizado do Google, que contém recursos de segurança, como detecção de invasão. A autorização é realizada com o serviço central Cloud IAM.

O tráfego de rede do painel de controle, dos GFEs para o primeiro serviço na retaguarda e entre outros serviços do painel de controle, é automaticamente autenticado pela infraestrutura e criptografado toda vez que se desloca de um data center para outro. Além disso, a infraestrutura foi configurada para criptografar parte do tráfego do painel de controle no data center também.

Toda máquina virtual (VM) é executada com uma instância de serviço de gerenciador de máquina virtual (VMM) associada. A infraestrutura oferece esses serviços com duas identidades. Uma é usada pela instância do serviço VMM para suas próprias chamadas, e outra é usada para as chamadas do VMM em nome da VM do cliente. Com isso, podemos segmentar ainda mais a confiança inserida nas chamadas enviadas pelo VMM.

Os discos persistentes do Google Compute Engine são criptografados em descanso com chaves protegidas pelo sistema central gerenciamento de chaves da infraestrutura. Esse procedimento possibilita a troca automática e a auditoria central do acesso a essas chaves.

Atualmente, os clientes têm a opção de enviar o tráfego das suas VMs para outras VMs ou para a Internet com segurança, ou de implementar qualquer tipo de criptografia para esse tráfego. Começamos a distribuir a criptografia automática no salto transversal da WAN do tráfego entre VMs do cliente. Como descrito anteriormente, todo o tráfego da WAN no painel de controle dentro da infraestrutura já está criptografado. Pretendemos futuramente aproveitar a criptografia de rede acelerada por hardware, abordada anteriormente, para também criptografar o tráfego de LAN entre VMs dentro do data center.

O isolamento fornecido para as VMs baseia-se em virtualização de hardware com o uso da pilha de KVM de código aberto. Aumentamos ainda mais nossa implementação particular de KVM. Para isso, movemos parte da pilha de emulação de hardware e controle para um processo sem privilégios fora do kernel. Também testamos exaustivamente o núcleo de KVM com técnicas como fuzzing, análise estática e revisão manual de código. Conforme mencionado anteriormente, a maioria das vulnerabilidades recentemente divulgadas que foram encaminhadas para o KVM são provenientes do Google.

Por fim, os controles de segurança operacional são um elemento importante para assegurar que os acessos aos dados estejam de acordo com nossas políticas. Como parte do Google Cloud Platform, o uso de dados do cliente pelo Google Compute Engine segue a política de dados do cliente do GCP. Ou seja, o Google não acessará nem usará dados do cliente, exceto quando necessário para fornecer serviços aos clientes.

Conclusão

Descrevemos como a infraestrutura do Google foi desenvolvida para criar, implementar e operar serviços com segurança na Internet. Isso inclui serviços para clientes, como o Gmail, e serviços para empresas. Além disso, nossas ofertas do Google Cloud são desenvolvidas nessa mesma infraestrutura.

Fazemos um grande investimento na segurança de nossa infraestrutura. Temos centenas de engenheiros dedicados à segurança e privacidade em todos os setores do Google. Muitos deles são inclusive autoridades reconhecidas no setor.

Como visto, a segurança da infraestrutura é elaborada em camadas, a partir dos componentes físicos e do data center, ao hardware e à inicialização, incluindo também comunicação entre serviços, dados estáticos, acesso protegido a serviços da Internet, e, por fim, processos tecnológicos e humanos que implementamos para a segurança operacional.

Informações adicionais

Consulte os seguintes documentos para saber mais sobre áreas específicas:

Monitore seus recursos de onde você estiver

Instale o app do Google Cloud Console para ajudar você a gerenciar seus projetos.

Enviar comentários sobre…