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

Este conteúdo foi atualizado pela última vez em junho 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 a proteção dos clientes é aprimorada.

Introdução

Neste documento, você terá uma visão geral de como a segurança é projetada na infraestrutura técnica do Google. Ele é destinado a executivos, arquitetos e auditores de segurança.

Neste documento, descrevemos o seguinte:

  • Infraestrutura técnica global do Google, projetada para fornecer segurança em todo o ciclo de vida do processamento de informações no Google. Essa infraestrutura ajuda a fornecer o seguinte:
    • Implantação segura de serviços
    • Armazenamento seguro de dados com proteções de privacidade do usuário final
    • Comunicação segura entre serviços
    • Comunicação segura e particular com clientes na Internet
    • Operação segura feita por engenheiros do Google
  • Como usamos essa infraestrutura para criar serviços de Internet, incluindo serviços para consumidores, como Pesquisa Google, Gmail e Google Fotos, e serviços empresariais, como Google Workspace e Google Cloud.
  • Os produtos e serviços de segurança que são o resultado de inovações que implementamos internamente para atender às nossas necessidades de segurança. Por exemplo, o BeyondCorp é o resultado direto da nossa implementação interna do modelo de segurança de confiança zero.

  • Como a segurança da infraestrutura é projetada em camadas progressivas. Essas camadas incluem o seguinte:

As seções restantes deste documento descrevem as camadas de segurança.

Infraestrutura de baixo nível segura

Esta seção descreve como protegemos as instalações físicas dos nossos data centers, o hardware em nossos data centers e a pilha de software em execução no hardware.

Segurança das instalações físicas

Projetamos e criamos nossos próprios data centers, que incorporam várias camadas de segurança física. O acesso a esses data centers é rigorosamente controlado. Usamos várias camadas de segurança física para proteger nossos data centers. Usamos identificação biométrica, detecção de metais, câmeras, barreiras de veículos e sistemas de detecção de intrusões baseadas em laser. Para mais informações, consulte Segurança do data center.

No data center, implementamos controles adicionais para garantir que o acesso físico aos servidores seja protegido e monitorado. Para mais informações, consulte Como o Google protege o espaço físico-lógico em um data center.

Também hospedamos alguns servidores em data centers de terceiros. Nesses data centers, alinham-se aos mesmos padrões regulatórios que fazemos em nossos próprios data centers. Garantimos que haja medidas de segurança física e conectividade controladas pelo Google, além das camadas de segurança fornecidas pelo operador do data center. Por exemplo, operamos sistemas de identificação biométrica, câmeras e detectores de metal independentes das camadas de segurança fornecidas pelo operador do data center.

A menos que especificado de outra maneira, os controles de segurança neste documento se aplicam a data centers de terceiros e do Google.

Projeto e procedência do hardware

Os data centers do Google consistem em milhares de servidores conectados a uma rede local. Projetamos as placas de servidor e os equipamentos de rede. Analisamos os fornecedores de componentes com que trabalhamos e escolhemos os componentes com cuidado. Trabalhamos com fornecedores para auditar e validar as propriedades de segurança fornecidas pelos componentes. Também projetamos chips personalizados, incluindo um chip de segurança de hardware (chamado Titan), que implantamos em servidores, dispositivos e periféricos. Com eles, podemos identificar e autenticar dispositivos legítimos do Google no nível do hardware e servir como raízes de confiança de hardware.

.

Pilha de inicialização segura e identidade de máquina

Os servidores do Google usam várias tecnologias para garantir a inicialização da pilha de software devida. Em cada etapa do processo de inicialização, o Google implementa controles líderes do setor para ajudar a aplicar o estado de inicialização esperado e manter os dados do cliente seguros.

Nosso objetivo é melhorar continuamente nossos servidores com cada geração de hardware e levar essas melhorias para o restante do setor por meio de processos de engajamento com o Trusted Computing Group e o DMTF.

Cada servidor no data center tem a própria identidade única. Essa identidade pode estar vinculada à raiz de confiança do hardware e ao software com que a máquina é inicializada. Essa identidade serve para autenticar chamadas de API enviadas ou recebidas dos serviços de gerenciamento de nível baixo na máquina. Essa identidade também é usada para autenticação mútua de servidor e criptografia de transporte. Desenvolvemos o sistema Application Layer Transport Security (ALTS) para proteger as comunicações de chamada de procedimento remoto (RPC) dentro da nossa infraestrutura. Essas identidades de máquina podem ser revogadas centralmente para responder a um incidente de segurança. Além disso, os certificados e as chaves são alternados rotineiramente, e os antigos são revogados.

Desenvolvemos sistemas automatizados para fazer o seguinte:

  • Garanta que os servidores executem versões atualizadas das pilhas de software, incluindo patches de segurança.
  • Detectar e diagnosticar problemas de hardware e software.
  • Garantir a integridade das máquinas e dos periféricos com inicialização verificada e atestado implícito.
  • Verifique se apenas as máquinas que executam o software e o firmware pretendido podem acessar credenciais que permitam a comunicação na rede de produção.
  • Remova ou repare as máquinas se elas não passarem na verificação de integridade ou não forem mais necessárias.

Para mais informações sobre como protegemos a pilha de inicialização e a integridade da máquina, consulte Como o Google aplica a integridade da inicialização na produção da nuvem e Atestado remoto de máquinas desagregadas.

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

Os serviços do Google são os binários do aplicativo que nossos desenvolvedores criam e executam na nossa infraestrutura. Alguns exemplos de serviços do Google são: servidores do Gmail, bancos de dados do Spanner, servidores do Cloud Storage, transcodificadores de vídeo do YouTube e VMs do Compute Engine que executam aplicativos do cliente. Para processar a escala necessária da carga de trabalho, milhares de máquinas podem estar executando binários do mesmo serviço. Um serviço de orquestração de cluster, chamado Borg, controla os serviços que são executados diretamente na infraestrutura.

A infraestrutura não pressupõe confiança entre os serviços em execução. Esse modelo de confiança é chamado de modelo de segurança de confiança zero. Um modelo de segurança de confiança zero significa que nenhum dispositivo ou usuário é confiável, por padrão, dentro ou fora da rede.

Como a infraestrutura foi projetada para ser multilocatária, os dados de nossos clientes (consumidores, empresas e até mesmo nossos próprios dados) são distribuídos na infraestrutura compartilhada. Essa infraestrutura é composta por dezenas de milhares de máquinas homogêneas. A infraestrutura não separa os dados do cliente em uma única máquina ou conjunto de máquinas, exceto em circunstâncias específicas, como quando você usa o Google Cloud para provisionar VMs em nós de locatário individual para Compute Engine.

O Google Cloud e o Google Workspace atendem aos requisitos regulamentares da residência de dados. Para mais informações sobre a residência de dados e o Google Cloud, consulte Implementar requisitos de residência e soberania de dados. Para mais informações sobre a residência de dados e o Google Workspace, consulte Regiões de dados: escolher uma localização geográfica para seus dados.

Identidade, integridade e isolamento de serviço

Para permitir a comunicação entre serviços, os aplicativos usam autenticação e autorização criptográfica. A autenticação e a autorização fornecem um controle de acesso forte em nível de abstração e granularidade que os administradores e os serviços podem entender.

Os serviços não dependem da segmentação de rede interna ou do firewall como o mecanismo de segurança principal. A filtragem de entrada e saída em vários pontos da nossa rede ajuda a evitar o spoofing de IP. Com essa abordagem, também conseguimos ampliar o desempenho e a disponibilidade da rede. Para o Google Cloud, é possível adicionar outros mecanismos de segurança, como o VPC Service Controls e o Cloud Interconnect.

Todo dispositivo executado na infraestrutura tem uma identidade de conta de serviço associada. Um serviço recebe credenciais criptográficas que podem ser usadas para provar a identidade dele a outros serviços ao fazer ou receber RPCs. Essas identidades são usadas nas políticas de segurança. As políticas de segurança garantem que os clientes se comuniquem com o servidor pretendido e que os servidores limitem os métodos e os dados que clientes específicos podem acessar.

Usamos várias técnicas de isolamento e sandbox para ajudar a proteger um serviço de outros serviços em execução na mesma máquina. Essas técnicas incluem separação de usuários do Linux, baseado em linguagem (como a API no modo sandbox) e sandboxes com base em kernel, kernel de aplicativo para contêineres (como gVisor) e virtualização de hardware. Em geral, usamos mais camadas de isolamento para cargas de trabalho mais arriscadas. Cargas de trabalho mais arriscadas incluem aquelas que processam entradas não sanitizadas da internet. Por exemplo, cargas de trabalho mais arriscadas incluem a execução de conversores de arquivos complexos em entradas não confiáveis ou a execução de código arbitrário como serviço para produtos como o Compute Engine.

Para segurança extra, serviços confidenciais, como o de orquestração de clusters e alguns serviços de gerenciamento de chaves, são executados exclusivamente em máquinas dedicadas.

No Google Cloud, para fornecer maior isolamento criptográfico para suas cargas de trabalho e proteger os dados em uso, oferecemos suporte a serviços de computação confidencial para instâncias de máquina virtual (VM) do Compute Engine e nós do Google Kubernetes Engine (GKE).

Gerenciamento de acesso entre serviços

O proprietário de um serviço pode gerenciar o acesso criando uma lista com outros serviços que podem se comunicar com o serviço. Esse recurso de gerenciamento de acesso é fornecidos pela infraestrutura do Google. Por exemplo, um serviço pode restringir RPCs de entrada exclusivamente a uma lista de outros serviços permitidos. O proprietário também pode configurar o serviço com uma lista de identidades de serviço permitidas, que a infraestrutura aplica automaticamente. Isso inclui registro de auditoria, justificativas e restrição de acesso unilateral (por exemplo, para solicitações de engenheiro).

Os engenheiros do Google que precisam de acesso aos serviços também recebem identidades individuais. Os serviços podem ser configurados para permitir ou negar o acesso deles com base nas identidades. Todas essas identidades (máquina, serviço e funcionário) estão em um namespace global mantido pela infraestrutura.

Para gerenciar essas identidades, a infraestrutura fornece um sistema de fluxo de trabalho que inclui cadeias de aprovação, geração de registros e notificações. Por exemplo, a política de segurança pode impor a autorização de várias partes. Esse sistema usa a regra de duas pessoas para garantir que um engenheiro que atue sozinho não possa executar operações confidenciais sem antes receber aprovação de outro, engenheiro autorizado. Esse sistema permite que processos seguros de gerenciamento de acesso sejam dimensionados para milhares de serviços em execução na infraestrutura.

A infraestrutura também fornece serviços canônicos para gerenciamento de usuários, grupos e assinaturas a fim de que eles possam implementar o controle de acesso personalizado e refinado quando necessário.

As identidades de usuários finais são gerenciadas separadamente, conforme descrito em Gerenciamento de acesso dos dados do usuário final no Google Workspace.

Criptografia da comunicação entre as cargas de trabalho

A infraestrutura proporciona confidencialidade e integridade para dados de RPC na rede. Todo o tráfego de rede virtual do Google Cloud é criptografado. Comunicação entre as cargas de trabalho da infraestrutura do Google Cloud é criptografada, com isenções concedidas apenas para cargas de trabalho de alto desempenho em que o tráfego não passa pelas várias camadas de segurança física na borda de um data center do Google. Comunicação entre os serviços de infraestrutura do Google Cloud tem proteção de integridade criptográfica.

A infraestrutura de maneira automática e eficiente (com ajuda da transferência de hardware) fornece criptografia de ponta a ponta para o tráfego da RPC da infraestrutura que passa pela rede entre data centers.

Acessar o gerenciamento de dados do usuário final no Google Workspace

Um serviço típico do Google Workspace é 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 pode abranger outros serviços dentro da infraestrutura. Por exemplo, o Gmail pode chamar uma API People para acessar a lista de endereços do usuário final.

A seção Criptografia de comunicação entre serviços descreve como um serviço (como o Contatos do Google) é projetado para proteger solicitações de RPC de outro serviço (como o Gmail). No entanto, esse nível de controle de acesso ainda é um amplo conjunto de permissões porque o Gmail pode solicitar os contatos de qualquer usuário a qualquer momento.

Quando o Gmail faz uma solicitação de RPC para o Contatos do Google em nome de um usuário final, a infraestrutura permite que o Gmail apresente um tíquete de permissão de usuário final na solicitação de RPC. Esse tíquete prova que o Gmail está fazendo a solicitação de RPC em nome desse usuário final específico. O tíquete permite que o Contatos do Google implemente uma proteção para retornar apenas os dados do usuário final nomeado no tíquete.

A infraestrutura fornece um serviço central de identidade de usuário que emite os tíquetes de contexto do usuário final. O serviço de identidade verifica o login do usuário final e emite uma credencial do usuário, como um cookie ou token OAuth, para o dispositivo do usuário. Todas as solicitações subsequentes do dispositivo para nossa infraestrutura precisam apresentar essa credencial de usuário final.

Quando um serviço recebe uma credencial de usuário final, ele passa a credencial para o serviço de identidade para verificação. Se a credencial do usuário final for verificada, o serviço de identidade retornará um tíquete de contexto de usuário final de curta duração que pode ser usado para RPCs relacionadas à solicitação do usuário. Em nosso exemplo, o serviço que recebe o tíquete de contexto do usuário final é o Gmail, que transmite o tíquete para o Contatos do Google. A partir desse ponto, para qualquer chamada em cascata, o serviço de chamadas pode enviar o tíquete de contexto do usuário final para o recebedor da chamada como parte da RPC.

O diagrama a seguir mostra como o Serviço A e o Serviço B se comunicam. A infraestrutura oferece identidade de serviço, autenticação mútua automática, comunicação criptografada entre serviços e aplicação das políticas de acesso definidas pelo proprietário do serviço. Cada serviço tem uma configuração, criada pelo proprietário do serviço. Para a comunicação criptografada entre serviços, a autenticação mútua automática usa as identidades do autor da chamada e do recebedor da chamada. A comunicação só é possível quando uma configuração de regra de acesso permite.

Diagrama que mostra como o Serviço A e o Serviço B se comunicam.

Para informações sobre o gerenciamento de acesso no Google Cloud, consulte Visão geral do IAM.

Acessar o gerenciamento de dados do usuário final no Google Cloud

Semelhante ao gerenciamento de acesso de dados do usuário final no Google Workspace, a infraestrutura fornece um serviço central de identidade do usuário que autentica contas de serviço e emite tíquetes de contexto do usuário final após um conta de serviço é autenticada. O gerenciamento de acesso entre os serviços do Google Cloud é feito normalmente com agentes de serviços em vez de usar tíquetes de contexto do usuário final.

O Google Cloud usa o Identity and Access Management (IAM) e produtos contextuais, como o Identity-Aware Proxy, para permitir que você gerencie o acesso aos recursos na sua organização do Google Cloud. Todas as solicitações para os serviços do Google Cloud passam pelo IAM para verificar as permissões.

O processo de gerenciamento de acesso é o seguinte:

  1. Uma solicitação é feita por meio do serviço do Google Front End ou do Cloud Front End para VMs do cliente.
  2. A solicitação é encaminhada para o serviço central de identidade do usuário que conclui a verificação de autenticação e emite os tíquetes de contexto do usuário final.
  3. A solicitação também é encaminhada para verificar itens como estes:
  4. Depois que todas essas verificações forem aprovadas, os serviços de back-end do Google Cloud serão chamados.

Para informações sobre o gerenciamento de acesso no Google Cloud, consulte Visão geral do IAM.

Armazenamento de dados seguro

Esta seção descreve como implementamos a segurança de dados armazenados na infraestrutura.

Criptografia em repouso

A infraestrutura do Google fornece vários serviços de armazenamento e sistemas de arquivos distribuídos (por exemplo, Spanner e Colossus), e um serviço de gerenciamento de chaves central. Os aplicativos do Google acessam o armazenamento físico usando uma infraestrutura de armazenamento. Usamos várias camadas de criptografia para proteger os dados em repouso. Por padrão, a infraestrutura de armazenamento criptografa todos os dados do usuário antes que eles sejam gravados no armazenamento físico.

A infraestrutura realiza criptografia na camada de infraestrutura de aplicativos ou armazenamento. As chaves dessa criptografia são gerenciadas e de propriedade do Google. A criptografia permite que a infraestrutura se isole das possíveis ameaças nos níveis mais baixos de armazenamento, como firmware de disco malicioso. Quando aplicável, também habilitamos a compatibilidade com criptografia de hardware em nossos discos rígidos e SSDs, e acompanhamos cada unidade de forma meticulosa ao longo do ciclo de vida. Antes que um dispositivo de armazenamento criptografado e desativado possa sair fisicamente da nossa custódia, o dispositivo é limpo usando um processo de várias etapas que inclui duas verificações independentes. Os dispositivos que não passam por esse processo de limpeza são destruídos fisicamente (ou seja, fragmentados) no local.

Além da criptografia feita pela infraestrutura com chaves gerenciadas e de propriedade do Google, Google Cloud e Google Workspace, oferece serviços de gerenciamento de chaves que você tem e gerencia. Para Google Cloud, Cloud KMS é um serviço em nuvem que permite criar chaves criptográficas próprias, incluindo chaves com certificação FIPS 140-3 L3 baseadas em hardware. Essas chaves são específicas para você, não para o serviço do Google Cloud, e você pode gerenciá-las de acordo com suas políticas e procedimentos. No Google Workspace, é possível usar a criptografia do lado do cliente. Para mais informações, consulte Criptografia do lado do cliente e colaboração reforçada no Google Workspace.

Exclusão de dados

A exclusão de dados ou materiais criptográficos geralmente começa com marcação de chaves ou dados específicos conforme programado para exclusão. O processo de marcação de dados para exclusão considera as políticas específicas do serviço e do cliente.

Ao programar a exclusão dos dados ou desativar as chaves primeiro, podemos recuperar exclusões não intencionais, sejam elas iniciadas pelo cliente, devido a um bug, ou resultantes de um erro interno no processo.

Quando um usuário final exclui a conta, a infraestrutura notifica os serviços que estão processando os dados do usuário final de que a conta foi excluída. Os serviços podem programar a exclusão dos dados associados à conta de usuário final excluída. Esse recurso permite que um usuário final controle os próprios dados.

Para mais informações, consulte Exclusão de dados no Google Cloud. Para informações sobre como usar o Cloud Key Management Service para desativar suas próprias chaves, consulte Destruir e restaurar versões principais.

Segurança na comunicação com a Internet

Nesta seção, você verá como protegemos a comunicação entre a Internet e os serviços executados na infraestrutura do Google.

Conforme discutido em Design e procedência do hardware, a infraestrutura consiste em muitas máquinas físicas interconectadas pela LAN e pela WAN. A segurança da comunicação entre serviços não depende da segurança da rede. No entanto, isolamos nossa infraestrutura da Internet em um espaço de endereço IP particular. Somente exporemos um subconjunto das máquinas diretamente ao tráfego externo da Internet, para podermos implementar outras proteções, como defesas contra ataques de negação de serviço (DoS).

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. O GFE também aplica proteções contra ataques de DoS. Em seguida, o GFE encaminha as solicitações para o serviço usando o protocolo de segurança RPC discutido em Gerenciamento de acesso dos dados do usuário final no Google Workspace.

Na verdade, qualquer serviço interno que precise se publicar externamente usa o GFE como um front-end de proxy reverso inteligente. O GFE fornece hospedagem de endereço IP público do nome DNS público, proteção DoS e encerramento de TLS. Os GFEs são executados na infraestrutura como qualquer outro serviço e podem ser escalonados para corresponder aos volumes de solicitação recebidos.

Quando as VMs de clientes nas redes VPC do Google Cloud acessam as APIs e os serviços do Google hospedados diretamente no Borg, as VMs do cliente se comunicam com GFEs específicos chamados de Cloud Front Ends. Para minimizar a latência, os Cloud Front Ends estão localizados na mesma região de nuvem que a VM do cliente. O roteamento de rede entre VMs do cliente e o Cloud Front End não exige que as VMs do cliente tenham endereços IP externos. Quando o acesso privado do Google está ativado, as VMs do cliente com apenas endereços IP internos podem se comunicar com endereços IP externos para APIs e serviços do Google que usam o Cloud Front Ends. Todo o roteamento de rede entre VMs de clientes, APIs do Google e serviços depende dos próximos saltos na rede de produção do Google, mesmo para VMs de clientes usando endereços IP externos.

Proteção contra DoS

O escalonamento da nossa infraestrutura permite a absorção de muitos ataques de DoS. Para reduzir ainda mais o risco de impacto do DoS nos serviços, temos proteções de DoS de multiníveis e multicamadas.

Quando nosso backbone de fibra óptica entrega uma conexão externa a um dos nossos data centers, a conexão passa por várias camadas de balanceadores 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. Quando o serviço de DoS central detecta um ataque de DoS, o serviço pode configurar os balanceadores de carga para descartar ou limitar o tráfego associado ao ataque.

As instâncias do GFE também geram informações sobre as solicitações que recebem no serviço de DoS central, incluindo informações da camada de aplicativos a que os balanceadores de carga não têm acesso. O serviço de DoS central pode então configurar as instâncias do GFE para descartar ou limitar o tráfego de ataque.

Autenticação do usuário

Após a proteção contra DoS, a próxima camada de defesa para comunicação segura vem do serviço de identidade central. Os usuários finais interagem com esse serviço por meio da página de login do Google. O serviço solicita um nome de usuário e uma senha e também pode desafiar os usuários com informações adicionais com base em fatores de risco. Alguns exemplos de fatores de risco são se os usuários fizeram login no mesmo dispositivo ou em um local semelhante no passado. 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.

Quando os usuários fazem login, eles podem usar segundos fatores, como OTPs ou chaves de segurança resistentes a phishing, como a chave de segurança Titan. A chave de segurança Titan é um token físico compatível com o FIDO Universal 2nd Factor (U2F). Ajudamos a desenvolver o padrão aberto U2F com a FIDO Alliance. A maioria das plataformas e navegadores da Web adotou esse padrão de autenticação aberto.

Segurança operacional

Esta seção descreve como desenvolvemos software de infraestrutura, protegemos máquinas e credenciais de nossos funcionários e nos protegemos contra ameaças à infraestrutura provenientes de pessoas com informações privilegiadas e agentes externos.

Segurança no desenvolvimento de software

Além das proteções do controle de origem e do processo de análise dupla descritos anteriormente, usamos bibliotecas que impedem que os desenvolvedores introduzam determinadas classes de bugs de segurança. Por exemplo, temos bibliotecas e frameworks que ajudam a eliminar vulnerabilidades de XSS de aplicativos da Web. Também usamos ferramentas automatizadas, como fuzzers, ferramentas de análise estática e scanners de segurança na Web, para detectar bugs de segurança automaticamente.

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 concepção e implementação em recursos de maior risco. A equipe que realiza essas revisões inclui especialistas em segurança da Web, criptografia e segurança de sistemas operacionais. As avaliações podem levar ao desenvolvimento de novos recursos da biblioteca de segurança e de novos fuzzers que podemos usar para produtos futuros.

Além disso, executamos um Programa de recompensa por vulnerabilidade que recompensa quem descobre e nos informa sobre bugs na infraestrutura ou nos aplicativos. Para ver mais informações sobre esse programa, incluindo as recompensas que fornecemos, consulte Estatísticas importantes de caçadores de bugs.

Também investimos na descoberta de explorações de dia zero e outros problemas de segurança no software de código aberto que usamos. Executamos o Project Zero, que é uma equipe de pesquisadores do Google dedicada a pesquisar vulnerabilidades de dia zero, incluindo Spectre e Meltdown. Além disso, somos o maior remetente de CVEs e correções de bugs de segurança para o hipervisor Linux KVM.

Proteções do código-fonte

Nosso código-fonte é armazenado em repositórios com integridade e governança de origem integradas, em que as versões atuais e anteriores do serviço podem ser auditadas. A infraestrutura exige que os binários de um serviço sejam criados a partir de código-fonte específico, depois de ser revisado, verificado e testado. Autorização binária para Borg (BAB) é uma verificação de aplicação interna que ocorre quando um serviço é implantado. A BAB faz o seguinte:

  • garante que o software e a configuração de produção implantados no Google sejam revisados e autorizados, especialmente quando o código acessa dados do usuário;
  • garante que as implantações de código e de configuração atendam a determinados padrões mínimos.
  • limita a capacidade de um invasor ou adversário de fazer modificações mal-intencionadas no código-fonte, além de fornecer uma trilha forense de um serviço de volta à sua origem.

Como manter a segurança de dispositivos e credenciais de funcionários

Implementamos proteções para ajudar a impedir que dispositivos e credenciais dos nossos funcionários sejam comprometidos. Para ajudar a proteger nossos funcionários contra tentativas sofisticadas de phishing, substituímos a autenticação de dois fatores de OTP pelo uso obrigatório de chaves de segurança compatíveis com U2F.

Monitoramos os dispositivos clientes que nossos funcionários usam para operar nossa infraestrutura. Garantimos que as imagens do sistema operacional desses dispositivos estejam atualizadas com patches de segurança e controlamos os aplicativos que os funcionários podem instalar nos dispositivos. Também temos sistemas que verificam aplicativos, downloads, extensões e conteúdo de navegadores da Web instalados pelo usuário para determinar se eles são adequados para dispositivos corporativos.

Conectar-se à LAN corporativa não é nosso mecanismo principal para conceder privilégios de acesso. Em vez disso, usamos segurança de confiança zero para ajudar a proteger o acesso dos nossos recursos aos funcionários. Os controles de gerenciamento de acesso no nível do aplicativo expõem os aplicativos internos aos funcionários somente quando eles usam um dispositivo gerenciado e se conectam de redes e locais geográficos esperados. Um dispositivo cliente é confiável com base em um certificado emitido para a máquina individual e com base em declarações sobre a configuração dele, como software atualizado. Para mais informações, consulte BeyondCorp.

Reduzir o risco de pessoas com informações privilegiadas

O risco de pessoas com informações privilegiadas é o potencial de um atual ou ex-funcionário, contratado ou outro parceiro de negócios que tem ou teve acesso autorizado à nossa rede, sistema ou dados para fazer uso indevido desse acesso para minar a confidencialidade, integridade ou disponibilidade de nossas informações ou sistemas de informação.

Para ajudar a reduzir o risco de pessoas com informações privilegiadas, limitamos e monitoramos ativamente as atividades dos funcionários que receberam acesso administrativo à infraestrutura. Trabalhamos continuamente para eliminar a necessidade de acesso privilegiado para tarefas específicas usando a automação que pode realizar as mesmas tarefas de maneira segura e controlada. Expomos APIs limitadas que permitem a depuração sem expor dados confidenciais. Além disso, exigimos aprovações de duas partes para determinadas ações confidenciais realizadas por operadores humanos.

O acesso do funcionário do Google a informações do usuário final pode ser registrado por meio de hooks em nível baixo na infraestrutura. Nossa equipe de segurança monitora padrões de acesso e investiga eventos incomuns. Para mais informações, consulte Gerenciamento de acesso privilegiado no Google Cloud (PDF).

Usamos autorização binária para o Borg para ajudar a proteger nossa cadeia de suprimentos contra riscos internos. Além disso, nosso investimento na BeyondProd ajuda a proteger os dados do usuário na infraestrutura do Google e a estabelecer confiança nos nossos serviços.

No Google Cloud, é possível monitorar o acesso aos seus dados usando a transparência no acesso. Os registros de transparência no acesso permitem verificar se a equipe do Google está acessando seu conteúdo somente por motivos comerciais válidos, como corrigir uma interrupção ou atender às solicitações de suporte. A aprovação de acesso garante que o Cloud Customer Care e a engenharia exijam sua aprovação explícita sempre que eles precisarem acessar seus dados. A aprovação é verificada criptograficamente para garantir a integridade da aprovação de acesso.

Para mais informações sobre as proteções de serviços de produção, consulte Como o Google protege os serviços de produção.

Monitoramento de ameaças

O Grupo de análise de ameaças do Google monitora os agentes de ameaças e a evolução das táticas e técnicas deles. Os objetivos deste grupo são ajudar a melhorar a segurança dos produtos do Google e compartilhar essa inteligência para o benefício da comunidade on-line.

Para o Google Cloud, é possível usar Inteligência contra ameaças do Google Cloud para Google Security Operations e VirusTotal para monitorar e responder a vários tipos de malware. O Google Cloud Threat Intelligence para Google Security Operations é uma equipe de pesquisadores de ameaças que desenvolve inteligência contra ameaças para uso com o Google Security Operations. O VirusTotal é uma solução de banco de dados e visualização de malware que pode ser usado para entender melhor como o malware opera na sua empresa.

Para mais informações sobre nossas atividades de monitoramento de ameaças, consulte o relatório Horizons de ameaças.

Detecção de intrusões

Usamos pipelines de processamento de dados sofisticados para integrar sinais baseados em host em dispositivos individuais, sinais baseados na rede de vários pontos de monitoramento na infraestrutura e sinais de serviços de 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 por dia, 365 dias por ano a filtrar, investigar e responder a esses possíveis incidentes. Realizamos exercícios da equipe vermelha para avaliar e aprimorar a eficácia de nossos mecanismos de detecção e resposta.

A seguir