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

Este conteúdo foi atualizado pela última vez em junho de 2023 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.
  • Nosso investimento para proteger nossa infraestrutura e operações. Temos muitos engenheiros dedicados à segurança e à privacidade em todo o Google, incluindo muitos que são autoridades reconhecidas do setor.
  • 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.

Também hospedamos alguns servidores em data centers de terceiros. Nesses data centers, garantimos que haja medidas de segurança física 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.

Desenho de hardware e proveniência

Um data center do Google consiste 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 correta. Usamos assinaturas criptográficas para componentes de baixo nível, como controlador de gerenciamento básico (BMC), BIOS, carregador de inicialização, kernel e imagem básica do sistema operacional. Essas assinaturas podem ser validadas em cada inicialização ou ciclo de atualização. A primeira verificação de integridade dos servidores do Google usa uma raiz de confiança de hardware. Os componentes são controlados, criados e protegidos pelo Google, com atestado de integridade. Com cada nova geração de hardware, buscamos melhorar continuamente a segurança. Por exemplo, dependendo da geração do design do servidor, a raiz de confiança da cadeia de inicialização está em uma das seguintes opções:

  • O chip de hardware Titan
  • Um chip de firmware bloqueável
  • Um microcontrolador executando nosso próprio código de segurança

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, na sigla em inglês) 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 realoque máquinas do serviço quando elas não forem mais necessárias.

Implantação de serviço segura

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. As cargas de trabalho Riskier incluem itens fornecidos pelo usuário que exigem processamento adicional. Por exemplo, cargas de trabalho mais arriscadas incluem a execução de conversores de arquivos complexos em dados fornecidos pelo usuário ou a execução de código fornecido pelo usuário para produtos como o App Engine ou 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 aos serviços de computação confidencial para VMs 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 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 pode restringir RPCs de entrada exclusivamente a uma lista de outros serviços permitidos. Esse serviço pode ser configurado com a lista de identidades de serviço permitidas, e a infraestrutura impõe automaticamente essa restrição de acesso. 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 serviços

A infraestrutura proporciona confidencialidade e integridade para dados de RPC na rede. Todo o tráfego de rede virtual do Google Cloud é criptografado. Toda a comunicação entre serviços de infraestrutura é autenticada e a maioria da comunicação entre serviços é criptografada, o que adiciona uma camada extra de segurança para ajudar a proteger a comunicação, mesmo que a rede seja tocada ou um dispositivo de rede seja comprometido. Exceções ao requisito de criptografia para a comunicação entre serviços são concedidas apenas para o tráfego com requisitos de baixa latência e que não deixa uma única malha de rede nas várias camadas de segurança física na nossa data center.

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 central de gerenciamento de chaves. 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. 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, o Google Cloud e o Google Workspace fornecem serviços de gerenciamento de chaves. Para o Google Cloud, o Cloud KMS é um serviço em nuvem que permite aos clientes gerenciar chaves criptográficas. 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 normalmente começa com a marcação de dados específicos como programados para exclusão, em vez de realmente excluir os dados. Essa abordagem nos permite recuperar exclusões não intencionais, sejam elas iniciadas pelo cliente, devido a um bug ou resultantes de um erro interno no processo. Após serem marcados para exclusão, os dados são excluídos de acordo com as políticas específicas do serviço.

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.

Comunicação segura na 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.

As VMs do cliente no Google Cloud não são registradas no GFE. Em vez disso, elas são registradas no Cloud Front End, que é uma configuração especial do GFE que usa a pilha de rede do Compute Engine. O Cloud Front End permite que as VMs do cliente acessem um serviço do Google diretamente pelo endereço IP público ou privado. Os endereços IP privados só estão disponíveis quando o Acesso privado do Google está ativado.

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.

Desenvolvimento de software seguro

Além das proteções do controle de origem e do processo de análise dupla descrito 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, na sigla em inglês) é 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 Atendimento ao cliente e a engenharia do Cloud 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.

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.

No Google Cloud, é possível usar o Google Cloud Threat Intelligence for Chronicle e o VirusTotal para monitorar e responder a muitos tipos de malware. O Google Cloud Threat Intelligence para Chronicle é uma equipe de pesquisadores de ameaças que desenvolve o uso de inteligência contra ameaças com o Chronicle. 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 Red Team para avaliar e aprimorar a eficácia de nossos mecanismos de detecção e resposta.

A seguir