Vista geral do design de segurança da infraestrutura da Google

Este conteúdo foi atualizado pela última vez em junho 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.

Introdução

Este documento oferece uma vista geral de como a segurança é incorporada na infraestrutura técnica da Google. Destina-se a executivos de segurança, arquitetos de segurança e auditores.

Este documento descreve o seguinte:

  • A infraestrutura técnica global da Google, concebida para oferecer segurança durante todo o ciclo de vida do processamento de informações na Google. Esta infraestrutura ajuda a oferecer o seguinte:
    • Implementação segura de serviços
    • Armazenamento seguro de dados com salvaguardas de privacidade do utilizador final
    • Comunicação segura entre serviços
    • Comunicação segura e privada com os clientes através da Internet
    • Funcionamento seguro por engenheiros da Google
  • Como utilizamos esta infraestrutura para criar serviços de Internet, incluindo serviços para consumidores, como a Pesquisa Google, o Gmail e o Google Fotos, e serviços empresariais, como o Google Workspace e oGoogle Cloud.
  • Os produtos e serviços de segurança que são o resultado de inovações que implementámos internamente para satisfazer as 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 é concebida em camadas progressivas. Estas camadas incluem o seguinte:

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

Infraestrutura de baixo nível segura

Esta secção descreve como protegemos as instalações físicas dos nossos centros de dados, o hardware nos nossos centros de dados e a pilha de software em execução no hardware.

Segurança das instalações físicas

Concebemos e construímos os nossos próprios centros de dados, que incorporam várias camadas de segurança física. O acesso a estes centros de dados é rigorosamente controlado. Usamos várias camadas de segurança física para proteger os pisos dos nossos centros de dados. Usamos identificação biométrica, deteção de metais, câmaras, barreiras para veículos e sistemas de deteção de intrusões baseados em laser. Para mais informações, consulte o artigo Segurança do centro de dados.

No interior do centro de dados, implementamos controlos adicionais para garantir que o acesso físico aos servidores está protegido e é monitorizado. Para mais informações, consulte o artigo Como a Google protege o espaço físico para o espaço lógico num centro de dados.

Também alojamos alguns servidores em centros de dados de terceiros. Nestes centros de dados, alinhamos com as mesmas normas regulamentares que nos nossos próprios centros de dados. Garantimos que existem medidas de segurança física controladas pela Google e conectividade controlada pela Google, além das camadas de segurança fornecidas pelo operador do centro de dados. Por exemplo, operamos sistemas de identificação biométrica, câmaras e detetores de metais que são independentes das camadas de segurança fornecidas pelo operador do centro de dados.

Salvo indicação específica, os controlos de segurança neste documento aplicam-se aos centros de dados pertencentes à Google e aos centros de dados de terceiros.

Design e proveniência do hardware

Os centros de dados da Google consistem em milhares de servidores ligados a uma rede local. Concebemos as placas de servidor e o equipamento de rede. Validamos os fornecedores de componentes com os quais trabalhamos e escolhemos os componentes com cuidado. Trabalhamos com fornecedores para auditar e validar as propriedades de segurança fornecidas pelos componentes. Também concebemos chips personalizados, incluindo um chip de segurança de hardware (denominado Titan), que implementamos em servidores, dispositivos e periféricos. Estes chips permitem-nos identificar e autenticar dispositivos Google legítimos ao nível do hardware e funcionam como raízes de confiança de hardware.

Stack de arranque seguro e identidade da máquina

Os servidores Google usam várias tecnologias para garantir que iniciam a pilha de software pretendida. Em cada passo do processo de arranque, a Google implementa controlos líderes da indústria para ajudar a aplicar o estado de arranque que esperamos e ajudar a manter os dados dos clientes seguros.

Esforçamo-nos por melhorar continuamente os nossos servidores com cada geração de hardware sucessiva e levar estas melhorias ao resto da indústria através da participação em processos de normas com o Trusted Computing Group e o DMTF.

Cada servidor no centro de dados tem a sua própria identidade exclusiva. Esta identidade pode ser associada às raízes de confiança de hardware e ao software com que a máquina é iniciada. Esta identidade é usada para autenticar chamadas de API para e a partir de serviços de gestão de baixo nível na máquina. Esta identidade também é usada para a autenticação mútua do servidor e a encriptação de transporte. Desenvolvemos o sistema Application Layer Transport Security (ALTS) para proteger as comunicações de chamadas de procedimentos remotos (RPC) na nossa infraestrutura. Estas identidades de máquinas podem ser revogadas centralmente para responder a um incidente de segurança. Além disso, os respetivos certificados e chaves são rotados rotineiramente e os antigos são revogados.

Desenvolvemos sistemas automatizados para fazer o seguinte:

  • Certifique-se de que os servidores executam versões atualizadas das respetivas pilhas de software (incluindo patches de segurança).
  • Detetar e diagnosticar problemas de hardware e software.
  • Garantir a integridade das máquinas e dos periféricos com o arranque validado e a atestação.
  • Certifique-se de que apenas as máquinas que executam o software e o firmware pretendidos podem aceder a credenciais que lhes permitam comunicar na rede de produção.
  • Remova ou repare máquinas se não passarem na verificação de integridade ou quando já não forem necessárias.

Para mais informações sobre como protegemos a nossa pilha de arranque e a integridade da máquina, consulte os artigos Como a Google aplica a integridade do arranque em máquinas de produção e Atestado remoto de máquinas desagregadas.

Implementação segura de serviços

Os serviços Google são os binários de aplicações que os nossos programadores escrevem e executam na nossa infraestrutura. Exemplos de serviços Google são os servidores do Gmail, as bases de dados do Spanner, os servidores do Cloud Storage, os transcodificadores de vídeo do YouTube e as MVs do Compute Engine que executam aplicações de clientes. Para processar a escala necessária da carga de trabalho, podem estar a ser executados binários do mesmo serviço em milhares de máquinas. Um serviço de orquestração de clusters, denominado Borg, controla os serviços que estão a ser executados diretamente na infraestrutura.

A infraestrutura não pressupõe qualquer confiança entre os serviços que estão a ser executados na infraestrutura. Este modelo de confiança é denominado modelo de segurança de confiança zero. Um modelo de segurança de confiança zero significa que nenhum dispositivo ou utilizador é fidedigno por predefinição, quer esteja dentro ou fora da rede.

Uma vez que a infraestrutura foi concebida para ser multi-inquilino, os dados dos nossos clientes (consumidores, empresas e até os nossos próprios dados) são distribuídos por uma infraestrutura partilhada. Esta infraestrutura é composta por dezenas de milhares de máquinas homogéneas. A infraestrutura não segrega os dados dos clientes numa única máquina ou num conjunto de máquinas, exceto em circunstâncias específicas, como quando está a usar o Google Cloud para aprovisionar VMs emnós de inquilino único para o Compute Engine.

Google Cloud e o Google Workspace suportam os requisitos regulamentares relativos à residência dos dados. Para mais informações sobre a residência de dados e Google Cloud, consulte Restringir localizações de recursos. Para mais informações sobre a residência de dados e o Google Workspace, consulte o artigo Regiões de dados: escolha uma localização geográfica para os seus dados.

Identidade, integridade e isolamento do serviço

Para ativar a comunicação entre serviços, as aplicações usam a autenticação e a autorização criptográficas. A autenticação e a autorização oferecem um controlo de acesso forte a um nível de abstração e granularidade que os administradores e os serviços podem compreender.

Os serviços não dependem da segmentação da rede interna nem de firewalls como o mecanismo de segurança principal. A filtragem de entrada e saída em vários pontos da nossa rede ajuda a evitar a falsificação de IP. Esta abordagem também nos ajuda a maximizar o desempenho e a disponibilidade da nossa rede. Para Google Cloud, pode adicionar mecanismos de segurança adicionais, como VPC Service Controls e Cloud Interconnect.

Cada serviço executado na infraestrutura tem uma identidade de conta de serviço associada. Um serviço é fornecido com credenciais criptográficas que pode usar para provar a sua identidade a outros serviços quando faz ou recebe RPCs. Estas identidades são usadas em políticas de segurança. As políticas de segurança garantem que os clientes estão a comunicar com o servidor pretendido e que os servidores estão a limitar os métodos e os dados aos quais clientes específicos podem aceder.

Usamos várias técnicas de isolamento e sandbox para ajudar a proteger um serviço de outros serviços executados na mesma máquina. Estas técnicas incluem a separação de utilizadores do Linux, caixas de areia baseadas em linguagem (como a API Sandboxed) e caixas de areia baseadas em kernel, kernel de aplicações para contentores (como o gVisor) e virtualização baseada em hardware. Em geral, usamos mais camadas de isolamento para cargas de trabalho mais arriscadas. As cargas de trabalho mais arriscadas incluem cargas de trabalho que processam entradas não higienizadas da Internet. Por exemplo, as cargas de trabalho mais arriscadas incluem a execução de conversores de ficheiros complexos em entradas não fidedignas ou a execução de código arbitrário como um serviço para produtos como o Compute Engine.

Para maior segurança, os serviços sensíveis, como o serviço de orquestração de clusters e alguns serviços de gestão de chaves, são executados exclusivamente em máquinas dedicadas.

No Google Cloud, para oferecer um isolamento criptográfico mais forte para as suas cargas de trabalho e proteger os dados em utilização, suportamos os serviços de computação confidencial para instâncias de máquinas virtuais (VMs) do Compute Engine e nós do Google Kubernetes Engine (GKE).

Gestão do acesso entre serviços

O proprietário de um serviço pode gerir o acesso criando uma lista de outros serviços que podem comunicar com o serviço. Esta funcionalidade de gestão de acesso é fornecida pela infraestrutura da Google. Por exemplo, um serviço pode restringir os RPCs recebidos apenas a uma lista permitida de outros serviços. O proprietário também pode configurar o serviço com uma lista permitida de identidades de serviço, que a infraestrutura aplica automaticamente. A aplicação inclui o registo de auditoria, as justificações e a restrição de acesso unilateral (por exemplo, para pedidos de engenheiros).

Os engenheiros da Google que precisam de acesso aos serviços também recebem identidades individuais. Os serviços podem ser configurados para permitir ou negar o respetivo acesso com base nas respetivas identidades. Todas estas identidades (máquina, serviço e funcionário) estão num espaço de nomes global que a infraestrutura mantém.

Para gerir estas identidades, a infraestrutura fornece um sistema de fluxo de trabalho que inclui cadeias de aprovação, registo e notificação. Por exemplo, a política de segurança pode aplicar a autorização de várias partes. Este sistema usa a regra de duas pessoas para garantir que um engenheiro a atuar sozinho não pode realizar operações confidenciais sem primeiro receber a aprovação de outro engenheiro autorizado. Este sistema permite que os processos de gestão de acesso seguros sejam dimensionados para milhares de serviços em execução na infraestrutura.

A infraestrutura também fornece serviços com o serviço canónico para a gestão de utilizadores, grupos e membros, para que possam implementar um controlo de acesso personalizado e detalhado, quando necessário.

As identidades dos utilizadores finais são geridas separadamente, conforme descrito no artigo Gestão do acesso aos dados dos utilizadores finais no Google Workspace.

Encriptação da comunicação entre cargas de trabalho

A infraestrutura oferece confidencialidade e integridade para os dados RPC na rede. Todo o tráfego de rede virtual Google Cloud está encriptado. A comunicação entre as cargas de trabalho da infraestrutura é encriptada, com isenções concedidas apenas para cargas de trabalho de alto desempenho em que o tráfego não atravessa as várias camadas de segurança física no limite de um centro de dados da Google. Google Cloud A comunicação entre os serviços de infraestrutura tem proteção de integridade criptográfica. Google Cloud

A infraestrutura fornece automaticamente e de forma eficiente (com a ajuda da transferência de hardware) a encriptação ponto a ponto para o tráfego RPC da infraestrutura que passa pela rede entre centros de dados.

Gestão do acesso aos dados do utilizador final no Google Workspace

Um serviço típico do Google Workspace é escrito para fazer algo por um utilizador final. Por exemplo, um utilizador final pode armazenar o respetivo email no Gmail. A interação do utilizador final com uma aplicação como o Gmail pode abranger outros serviços na infraestrutura. Por exemplo, o Gmail pode chamar uma API People para aceder ao livro de endereços do utilizador final.

A secção Encriptação da comunicação entre serviços descreve como um serviço (como o Google Contactos) foi concebido para proteger pedidos RPC de outro serviço (como o Gmail). No entanto, este nível de controlo de acesso continua a ser um conjunto amplo de autorizações, uma vez que o Gmail pode pedir os contactos de qualquer utilizador em qualquer altura.

Quando o Gmail faz um pedido RPC aos Contactos Google em nome de um utilizador final, a infraestrutura permite que o Gmail apresente um pedido de autorização do utilizador final no pedido RPC. Este pedido prova que o Gmail está a fazer o pedido RPC em nome desse utilizador final específico. O pedido permite que o Google Contacts implemente uma salvaguarda para que só devolva dados para o utilizador final indicado no pedido.

A infraestrutura fornece um serviço de identidade do utilizador central que emite estes vales de contexto do utilizador final. O serviço de identidade valida o início de sessão do utilizador final e, em seguida, emite uma credencial do utilizador, como um cookie ou um símbolo OAuth, para o dispositivo do utilizador. Todos os pedidos subsequentes do dispositivo à nossa infraestrutura têm de apresentar essa credencial do utilizador final.

Quando um serviço recebe uma credencial de utilizador final, o serviço passa a credencial para o serviço de identidade para validação. Se a credencial do utilizador final for validada, o serviço de identidade devolve um token de contexto do utilizador final de curta duração que pode ser usado para RPCs relacionadas com o pedido do utilizador. No nosso exemplo, o serviço que recebe a autorização de contexto do utilizador final é o Gmail, que passa a autorização para o Google Contacts. A partir desse momento, para todas as chamadas em cascata, o serviço de chamadas pode enviar o pedido de contexto do utilizador final para o destinatário da chamada como parte do RPC.

O diagrama seguinte mostra como o Serviço A e o Serviço B comunicam. A infraestrutura fornece identidade de serviço, autenticação mútua automática, comunicação encriptada 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 do serviço, que o proprietário do serviço cria. Para a comunicação encriptada entre serviços, a autenticação mútua automática usa as identidades do autor da chamada e do destinatário. A comunicação só é possível quando uma configuração de regra de acesso o permite.

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

Para obter informações sobre a gestão de acessos no Google Cloud, consulte a vista geral do IAM.

Gestão do acesso aos dados do utilizador final no Google Cloud

Semelhante à gestão de acesso aos dados de utilizadores finais no Google Workspace, a infraestrutura fornece um serviço de identidade do utilizador central que autentica contas de serviço e emite pedidos de contexto do utilizador final depois de uma conta de serviço ser autenticada. A gestão de acesso entre Google Cloud serviços é normalmente feita com agentes de serviço em vez de usar pedidos de contexto do utilizador final.

Google Cloud usa a gestão de identidade e de acesso (IAM) e produtos sensíveis ao contexto, como o Identity-Aware Proxy, para lhe permitir gerir o acesso aos recursos na sua Google Cloud organização. Os pedidos aos serviços Google Cloud passam pelo IAM para validar as autorizações.

O processo de gestão de acesso é o seguinte:

  1. É recebido um pedido através do serviço Google Front End ou do serviço Cloud Front End para VMs de clientes.
  2. O pedido é encaminhado para o serviço de identidade do utilizador central que conclui a verificação de autenticação e emite os pedidos de contexto do utilizador final.
  3. O pedido também é encaminhado para verificar itens como os seguintes:
  4. Depois de todas estas verificações serem aprovadas, os Google Cloud serviços de back-end são chamados.

Para obter informações sobre a gestão de acessos no Google Cloud, consulte a vista geral do IAM.

Armazenamento de dados seguro

Esta secção descreve como implementamos a segurança para os dados armazenados na infraestrutura.

Encriptação em repouso

A infraestrutura da Google oferece vários serviços de armazenamento e sistemas de ficheiros distribuídos (por exemplo, o Spanner e o Colossus), bem como um serviço de gestão de chaves central. As aplicações na Google acedem ao armazenamento físico através da infraestrutura de armazenamento. Usamos várias camadas de encriptação para proteger os dados em repouso. Por predefinição, a infraestrutura de armazenamento encripta os dados do utilizador antes de os dados do utilizador serem escritos no armazenamento físico.

A infraestrutura realiza a encriptação na camada de infraestrutura de armazenamento ou de aplicação. As chaves desta encriptação são geridas e pertencem à Google. A encriptação permite que a infraestrutura se isole de potenciais ameaças nos níveis inferiores de armazenamento, como firmware de disco malicioso. Quando aplicável, também ativamos o suporte de encriptação de hardware nos nossos discos rígidos e SSDs, e monitorizamos meticulosamente cada unidade durante o respetivo ciclo de vida. Antes de um dispositivo de armazenamento encriptado desativado poder sair fisicamente sob a nossa custódia, o dispositivo é limpo através de um processo de vários passos que inclui duas validações independentes. Os dispositivos que não passam neste processo de limpeza são destruídos fisicamente (ou seja, triturados) no local.

Além da encriptação feita pela infraestrutura com chaves de encriptação pertencentes e geridas pela Google, Google Cloud e o Google Workspace oferece serviços de gestão de chaves para chaves que pode possuir e gerir. Para Google Cloud, o Cloud KMS é um serviço na nuvem que lhe permite criar as suas próprias chaves criptográficas, incluindo chaves certificadas FIPS 140-3 L3 baseadas em hardware. Estas chaves são específicas para si e não para o Google Cloud serviço, e pode gerir as chaves de acordo com as suas políticas e procedimentos. Para o Google Workspace, pode usar a encriptação por parte do cliente. Para mais informações, consulte o artigo Encriptação por parte do cliente e colaboração reforçada no Google Workspace.

Eliminação de dados

Normalmente, a eliminação de material ou dados criptográficos começa com a marcação de chaves ou dados específicos como agendados para eliminação. O processo de marcação de dados para eliminação tem em conta as políticas específicas do serviço e as políticas específicas do cliente.

Ao agendar os dados para eliminação ou desativar primeiro as chaves, podemos recuperar de eliminações não intencionais, quer sejam iniciadas pelo cliente, devidas a um erro ou resultado de um erro de processo interno.

Quando um utilizador final elimina a respetiva conta, a infraestrutura notifica os serviços que estão a processar os dados do utilizador final de que a conta foi eliminada. Os serviços podem, então, agendar a eliminação dos dados associados à conta do utilizador final eliminada. Esta funcionalidade permite que um utilizador final controle os seus próprios dados.

Para mais informações, consulte o artigo Eliminação de dados no Google Cloud. Para obter informações sobre como usar o Serviço de gestão de chaves na nuvem para desativar as suas próprias chaves, consulte o artigo Destrua e restaure versões de chaves.

Comunicação segura na Internet

Esta secção descreve como protegemos a comunicação entre a Internet e os serviços executados na infraestrutura da Google.

Conforme abordado em Conceção e proveniência de hardware, a infraestrutura consiste em muitas máquinas físicas interligadas através da LAN e da WAN. A segurança da comunicação entre serviços não depende da segurança da rede. No entanto, isolamos a nossa infraestrutura da Internet num espaço de endereços IP privados. Expomos apenas um subconjunto das máquinas diretamente ao tráfego externo da Internet para podermos implementar proteções adicionais, como defesas contra ataques de negação de serviço (DoS).

Serviço Google Front End

Quando um serviço tem de se disponibilizar na Internet, pode registar-se num serviço de infraestrutura denominado Google Front End (GFE). O GFE garante que todas as ligações TLS são terminadas com certificados corretos e seguindo as práticas recomendadas, como o suporte da confidencialidade antecipada perfeita. O GFE também aplica proteções contra ataques DoS. Em seguida, o GFE encaminha os pedidos para o serviço através do protocolo de segurança RPC abordado no artigo Gestão do acesso aos dados do utilizador final no Google Workspace.

Na prática, qualquer serviço interno que tenha de se publicar externamente usa o GFE como um front-end de proxy inverso inteligente. O GFE fornece alojamento de endereços IP públicos do respetivo nome DNS público, proteção contra DoS e terminação de TLS. Os GFEs são executados na infraestrutura como qualquer outro serviço e podem ser dimensionados para corresponder aos volumes de pedidos recebidos.

Quando as VMs do cliente nas Google Cloud redes VPC acedem às APIs e aos serviços Google alojados diretamente no Borg, as VMs do cliente comunicam com GFEs específicos denominados Cloud Front Ends. Para minimizar a latência, os front-ends da nuvem estão localizados na mesma região da nuvem que a VM do cliente. O encaminhamento de rede entre as VMs do cliente e os front-ends da nuvem não requer que as VMs do cliente tenham endereços IP externos. Quando o acesso privado à Google está ativado, as VMs dos clientes com apenas endereços IP internos podem comunicar com os endereços IP externos das APIs e dos serviços Google através dos front-ends da nuvem. Todo o encaminhamento de rede entre as VMs do cliente, as APIs Google e os serviços depende dos próximos saltos na rede de produção da Google, mesmo para as VMs do cliente que têm endereços IP externos.

Proteção contra DoS

A escala da nossa infraestrutura permite-lhe absorver muitos ataques DoS. Para reduzir ainda mais o risco de impacto de DoS nos serviços, temos proteções de DoS de várias camadas e vários níveis.

Quando a nossa espinha dorsal de fibra ótica fornece uma ligação externa a um dos nossos centros de dados, a ligação passa por várias camadas de balanceadores de carga de hardware e software. Estes balanceadores de carga comunicam informações sobre o tráfego recebido a um serviço de DoS central em execução na infraestrutura. Quando o serviço central de DoS deteta um ataque DoS, o serviço pode configurar os equilibradores de carga para ignorar ou limitar o tráfego associado ao ataque.

As instâncias da GFE também comunicam informações sobre os pedidos que estão a receber ao serviço central de DoS, incluindo informações da camada de aplicação às quais os equilibradores de carga não têm acesso. O serviço central de DoS pode, em seguida, configurar as instâncias do GFE para rejeitar ou limitar o tráfego de ataque.

Autenticação do utilizador

Após a proteção contra DoS, a camada de defesa seguinte para uma comunicação segura provém do serviço de identidade central. Os utilizadores finais interagem com este serviço através da página de início de sessão da Google. O serviço pede um nome de utilizador e uma palavra-passe e também pode pedir aos utilizadores informações adicionais com base em fatores de risco. Os fatores de risco incluem se os utilizadores iniciaram sessão a partir do mesmo dispositivo ou de uma localização semelhante no passado. Após a autenticação do utilizador, o serviço de identidade emite credenciais, como cookies e tokens OAuth, que podem ser usados para chamadas subsequentes.

Quando os utilizadores iniciam sessão, podem utilizar segundos fatores, como códigos únicos ou chaves de segurança resistentes a phishing, como a Titan Security Key. A chave de segurança Titan é um token físico que suporta o FIDO Universal 2nd Factor (U2F). Ajudámos a desenvolver a norma aberta U2F com a FIDO Alliance. A maioria das plataformas Web e dos navegadores adotou esta norma de autenticação aberta.

Segurança operacional

Esta secção descreve como desenvolvemos software de infraestrutura, protegemos as máquinas e as credenciais dos nossos funcionários e nos defendemos contra ameaças à infraestrutura de insiders e atores externos.

Programação de software segura

Além das proteções de controlo de origem e do processo de revisão de duas partes descritos anteriormente, usamos bibliotecas que impedem os programadores de introduzir determinadas classes de erros de segurança. Por exemplo, temos bibliotecas e frameworks que ajudam a eliminar vulnerabilidades de XSS em apps Web. Também usamos ferramentas automáticas, como fuzzers, ferramentas de análise estática e scanners de segurança Web, para detetar automaticamente erros de segurança.

Como verificação final, usamos revisões de segurança manuais que variam entre triagens rápidas para funcionalidades menos arriscadas e revisões detalhadas de design e implementação para as funcionalidades mais arriscadas. A equipa que realiza estas revisões inclui especialistas em segurança Web, criptografia e segurança do sistema operativo. As revisões podem levar ao desenvolvimento de novas funcionalidades da biblioteca de segurança e novos fuzzers que podemos usar para produtos futuros.

Além disso, temos um Programa de recompensas por vulnerabilidades que recompensa qualquer pessoa que descubra e nos informe sobre erros na nossa infraestrutura ou aplicações. Para mais informações sobre este programa, incluindo as recompensas que atribuímos, consulte as estatísticas principais do programa Bug Hunters.

Também investimos na deteção 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 equipa de investigadores da Google dedicada à investigação de vulnerabilidades de dia zero, incluindo o Spectre e o Meltdown. Além disso, somos o maior remetente de CVEs e correções de erros de segurança para o hipervisor Linux KVM.

Proteções do código-fonte

O nosso código fonte é armazenado em repositórios com integridade e governança de origem incorporadas, onde as versões atuais e anteriores do serviço podem ser auditadas. A infraestrutura requer que os ficheiros binários de um serviço sejam criados a partir de um código fonte específico, após a respetiva revisão, registo e teste. A autorização binária para o Borg (BAB) é uma verificação de aplicação interna que ocorre quando um serviço é implementado. O BAB faz o seguinte:

  • Garante que o software e a configuração de produção implementados na Google são revistos e autorizados, especialmente quando esse código pode aceder aos dados do utilizador.
  • Garante que as implementações de código e configuração cumprem determinadas normas mínimas.
  • Limita a capacidade de um agente interno ou um adversário fazer modificações maliciosas ao código-fonte e também fornece um rasto forense de um serviço de volta à respetiva origem.

Manter os dispositivos e as credenciais dos funcionários seguros

Implementamos salvaguardas para ajudar a proteger os dispositivos e as credenciais dos nossos funcionários contra comprometimento. Para ajudar a proteger os nossos funcionários contra tentativas de phishing sofisticadas, substituímos a autenticação de dois fatores por OTP pela utilização obrigatória de chaves de segurança compatíveis com U2F.

Monitorizamos os dispositivos cliente que os nossos funcionários usam para operar a nossa infraestrutura. Garantimos que as imagens do sistema operativo destes dispositivos estão atualizadas com patches de segurança e controlamos as aplicações que os funcionários podem instalar nos respetivos dispositivos. Também temos sistemas que analisam as aplicações, as transferências, as extensões do navegador e o conteúdo do navegador Web instalados pelo utilizador para determinar se são adequados para dispositivos empresariais.

A ligação à LAN corporativa não é o nosso mecanismo principal para conceder privilégios de acesso. Em alternativa, usamos a segurança de confiança zero para ajudar a proteger o acesso dos funcionários aos nossos recursos. Os controlos de gestão de acessos ao nível da aplicação expõem as aplicações internas aos funcionários apenas quando estes usam um dispositivo gerido e se ligam a partir de redes e localizações geográficas esperadas. Um dispositivo cliente é fidedigno com base num certificado emitido para a máquina individual e com base em afirmações sobre a respetiva configuração (como software atualizado). Para mais informações, consulte o artigo BeyondCorp.

Reduzir o risco de atos internos

O risco interno é o potencial de um funcionário, um contratante ou outro parceiro empresarial atual ou antigo que tenha ou teve acesso autorizado à nossa rede, sistema ou dados usar indevidamente esse acesso para prejudicar a confidencialidade, a integridade ou a disponibilidade das nossas informações ou sistemas de informação.

Para ajudar a reduzir o risco interno, limitamos e monitorizamos ativamente as atividades dos funcionários que receberam acesso administrativo à infraestrutura. Trabalhamos continuamente para eliminar a necessidade de acesso privilegiado para tarefas específicas através da utilização da automatização que pode realizar as mesmas tarefas de forma segura e controlada. Expomos APIs limitadas que permitem a depuração sem expor dados confidenciais e exigimos aprovações de duas partes para determinadas ações confidenciais realizadas por operadores humanos.

O acesso dos funcionários da Google às informações do utilizador final pode ser registado através de hooks de infraestrutura de baixo nível. A nossa equipa de segurança monitoriza os padrões de acesso e investiga eventos invulgares. Para mais informações, consulte o artigo Acesso privilegiado no Google Cloud.

Usamos a autorização binária para o Borg para ajudar a proteger a nossa cadeia de fornecimento contra o risco interno. Além disso, o nosso investimento em BeyondProd ajuda a proteger os dados dos utilizadores na infraestrutura da Google e a estabelecer confiança nos nossos serviços.

No Google Cloud, pode monitorizar o acesso aos seus dados através da Transparência de acesso. Os registos da Transparência de acesso permitem-lhe verificar se o pessoal da Google está a aceder ao seu conteúdo apenas por motivos empresariais válidos, como corrigir uma indisponibilidade ou responder aos seus pedidos de apoio técnico. A aprovação de acesso garante que o apoio técnico ao cliente e a engenharia do Google Cloud requerem a sua aprovação explícita quando precisam de aceder aos seus dados. A aprovação é validada criptograficamente para garantir a integridade da aprovação de acesso.

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

Monitorização de ameaças

O grupo de análise de ameaças da Google monitoriza os autores de ameaças e a evolução das respetivas táticas e técnicas. Os objetivos deste grupo são ajudar a melhorar a segurança dos produtos Google e partilhar estas informações para benefício da comunidade online.

Para Google Cloud, pode usar a Google Cloud Threat Intelligence para o Google Security Operations e o VirusTotal para monitorizar e responder a muitos tipos de software malicioso. Google Cloud A Threat Intelligence para o Google Security Operations é uma equipa de investigadores de ameaças que desenvolve informações sobre ameaças para utilização com o Google Security Operations. O VirusTotal é uma base de dados de software malicioso e uma solução de visualização que pode usar para compreender melhor como o software malicioso opera na sua empresa.

Para mais informações acerca das nossas atividades de monitorização de ameaças, consulte o relatório Threat Horizons.

Deteção de intrusões

Usamos pipelines de tratamento de dados sofisticados para integrar sinais baseados no anfitrião em dispositivos individuais, sinais baseados na rede de vários pontos de monitorização na infraestrutura e sinais de serviços de infraestrutura. As regras e a inteligência artificial criadas com base nestes pipelines dão aos engenheiros de segurança operacional avisos de possíveis incidentes. As nossas equipas de investigação e resposta a incidentes analisam, investigam e respondem a estes potenciais incidentes 24 horas por dia, 365 dias por ano. Realizamos exercícios de equipa vermelha para medir e melhorar a eficácia dos nossos mecanismos de deteção e resposta.

O que se segue?