BeyondProd

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

Neste documento, descrevemos como o Google implementa a segurança na nossa infraestrutura usando uma arquitetura nativa da nuvem chamada BeyondProd. O BeyondProd se refere a serviços e controles em nossa infraestrutura que funcionam juntos para ajudar a proteger cargas de trabalho. As cargas de trabalho são as tarefas únicas que um aplicativo realiza. O BeyondProd ajuda a proteger os microsserviços em execução no nosso ambiente, incluindo a forma como mudamos o código e como acessamos os dados do usuário.

Este documento faz parte de uma série de artigos técnicos que descrevem as tecnologias, como Chrome Enterprise Premium, que desenvolvemos para ajudar a defender as plataformas do Google contra ameaças sofisticadas. O Chrome Enterprise Premium implementa uma arquitetura de confiança zero projetada para fornecer acesso seguro às plataformas do Google e aos serviços em execução nela. Assim como o Chrome Enterprise Premium, O BeyondProd não depende do perímetro de rede tradicional. proteções, como firewalls. Em vez disso, o BeyondProd ajuda a criar confiança entre microsserviços usando características como procedência do código, identidades de serviço e hardware confiável. Essa confiança se estende ao software que é executado no Google Cloud e ao software que é implantado e acessado pelos clientes do Google Cloud.

Este documento descreve os benefícios do BeyondProd, os serviços e processos dele e como migramos para essa arquitetura. Para uma visão geral da segurança da nossa infraestrutura, consulte a Visão geral do design de segurança da infraestrutura do Google.

Introdução

As arquiteturas de segurança modernas deixaram de ser um modelo de segurança tradicional baseado em perímetro, em que um firewall protege o perímetro e qualquer usuário ou serviço dentro dele é considerado confiável.

Atualmente, os usuários são móveis e geralmente operam fora do perímetro de segurança tradicional de uma organização, como em casa, em um café ou em um avião. Com o Chrome Enterprise Premium, concedemos acesso aos recursos da empresa usando vários fatores, incluindo a identidade do usuário, a identidade do dispositivo que está sendo usado para acessar o recurso, a integridade do dispositivo, sinais de confiança, como como comportamento do usuário e listas de controle de acesso.

O BeyondProd resolve a mesma preocupação com serviços de produção que o Chrome Enterprise Premium oferece aos usuários. Em uma arquitetura nativa da nuvem, não podemos simplesmente confiar em um firewall para proteger a rede de produção. Os microsserviços são movidos e implantados em diferentes ambientes e em hosts heterogêneos, além de operar em vários níveis de confiança e sensibilidade. De acordo com o Chrome Enterprise Premium, a confiança do usuário precisa depender de características como o estado dos dispositivos baseado no contexto e não da conexão com a rede corporativa, a BeyondProd afirma que A confiabilidade do serviço depende de características como procedência do código, hardware confiável e identidade do serviço, e não o local na rede de produção, como o endereço IP ou o nome do host.

Infraestrutura conteinerizada

Nossa infraestrutura implanta cargas de trabalho como microsserviços individuais em contêineres. Os microsserviços são separados das tarefas individuais que um aplicativo precisa executar em serviços diferentes. Cada serviço pode ser desenvolvido e gerenciado independentemente com sua própria API, lançamento, escalonamento e gerenciamento de cotas. Os microsserviços são independentes, modulares, dinâmicos e temporários. Eles podem ser distribuídos em vários hosts, clusters ou até mesmo nuvens. Em uma arquitetura de microsserviço, essa carga de trabalho pode ser um ou vários microsserviços.

Uma infraestrutura conteinerizada significa que cada microsserviço é implantado como o próprio conjunto de contêineres móveis e programáveis. Para gerenciar esses contêineres internamente, desenvolvemos um Sistema de orquestração de contêineres chamado Borg , que implanta vários bilhões de contêineres por semana. O Borg é o sistema unificado de gerenciamento de contêineres do Google e a inspiração para o Kubernetes.

Os contêineres tornam as cargas de trabalho mais fáceis e eficientes de acordo com o tipo de programação. O empacotamento de microsserviços em contêineres permite que as cargas de trabalho sejam divididas em unidades menores e mais gerenciáveis para manutenção e descoberta. Essa arquitetura faz o escalonamento das cargas de trabalho conforme necessário. Se houver alta demanda por uma carga de trabalho específica, pode haver várias máquinas executando cópias do mesmo serviço para lidar com a escala necessária da carga de trabalho.

No Google, a segurança desempenha um papel fundamental em cada evolução da nossa arquitetura. Nosso objetivo com a arquitetura de microsserviço e o processo de desenvolvimento é resolver problemas de segurança o mais rápido possível no ciclo de desenvolvimento e implantação, quando ainda é mais barato fazer isso, e de maneira padronizada e consistente. Como resultado, os desenvolvedores passam menos tempo resolvendo problemas de segurança e ainda têm resultados mais seguros.

Benefícios da BeyondProd

O BeyondProd oferece muitos benefícios de automação e segurança para a infraestrutura do Google. Os benefícios incluem:

  • Proteção de borda da rede: as cargas de trabalho são isoladas de ataques à rede e de tráfego não autorizado da Internet. Embora uma abordagem de perímetro não seja um novo conceito, ela continua sendo uma prática recomendada de segurança para arquiteturas de nuvem. Uma abordagem de perímetro ajuda a proteger o máximo de infraestrutura possível contra tráfego não autorizado e possíveis ataques da Internet, como ataques DoS baseados em volume.
  • Nenhuma confiança mútua inerente entre os serviços: somente os autores de chamadas ou serviços autenticados, confiáveis e especificamente autorizados podem acessar qualquer outro serviço. Isso impede que invasores usem código não confiável para acessar um serviço. Se um serviço for comprometido, esse benefício ajudará a impedir que o invasor execute ações que permitam expandir o alcance dele. Essa desconfiança mútua, combinada com o controle de acesso granular, ajuda a limitar o raio de impacto de um comprometimento.
  • Máquinas confiáveis que executam código com procedência conhecida: as identidades de serviço são limitadas a usar apenas códigos e configurações autorizados e são executadas apenas em ambientes autorizados e verificados.
  • Aplicação consistente da política em todos os serviços: a aplicação consistente da política ajuda a garantir que as decisões de acesso sejam confiáveis em todos os serviços. Por exemplo, é possível criar uma aplicação de política que verifique as solicitações de acesso aos dados do usuário. Para acessar o serviço, um usuário final autorizado precisa apresentar uma solicitação validada, e um administrador precisa fornecer uma justificativa comercial.
  • Implementação simples, automatizada e padronizada de alterações, para que as mudanças de infraestrutura possam ser facilmente analisadas quanto ao impacto, e os patches de segurança possam ser implementados com pouco impacto na produção.
  • Isolamento entre cargas de trabalho que compartilham um sistema operacional: se um serviço for comprometido, isso não afetará a segurança de outra carga de trabalho em execução no mesmo host. Esse isolamento ajuda a limitar o raio de impacto de um comprometimento.
  • Hardware confiável e atestado: uma raiz de confiança do hardware ajuda a garantir que apenas o código conhecido e autorizado (do firmware para o modo de usuário) seja executado no host antes da programação de cargas de trabalho nele.

Esses benefícios significam que os contêineres e os microsserviços executados na nossa arquitetura de nuvem podem ser implantados, comunicar-se entre si e ser executados lado a lado sem enfraquecer a segurança da nossa infraestrutura. Além disso, desenvolvedores de microsserviços individuais não são sobrecarregados com os detalhes de segurança e implementação da infraestrutura subjacente.

Serviços de segurança do BeyondProd

Projetamos e desenvolvemos vários serviços de segurança do BeyondProd para criar os benefícios discutidos em Benefícios do BeyondProd. As seções a seguir descrevem esses serviços de segurança.

Google Front End para proteção da borda da rede

Google Front End (GFE) fornece proteção de borda da rede. O GFE encerra a conexão do usuário final e fornece um ponto central para aplicar as práticas recomendadas de TLS.

Embora nossa ênfase não esteja mais na segurança baseada em perímetro, o GFE ainda é uma parte importante da nossa estratégia para proteger serviços internos contra ataques de negação de serviço. O GFE é o primeiro ponto de entrada para um usuário que se conecta à infraestrutura do Google. Depois que um usuário se conecta à nossa infraestrutura, o GFE também é responsável pelo balanceamento de carga e redirecionamento do tráfego entre regiões, conforme necessário. O GFE é o proxy de borda que encaminha o tráfego para o microsserviço correto.

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.

Segurança de transporte do nível de aplicativo para confiança entre serviços

O Application Layer Transport Security (ALTS) ajuda a garantir que haja sem confiança mútua entre os serviços. O Hilt é usado para a autenticação de chamada de procedimento remoto (RPC), integridade, criptografia de tráfego e identidades de serviço. O ALTS é um sistema de criptografia mútua de autenticação e transporte para serviços na infraestrutura do Google. Em geral, as identidades estão vinculadas a serviços, e não a um nome ou servidor de servidor específico. Essa vinculação ajuda a replicação contínua de microsserviços, ao balanceamento de carga e à reprogramação entre hosts.

Cada máquina tem uma credencial ALTS que é provisionada usando o sistema de integridade do host e só poderá ser descriptografada se o sistema de integridade do host verificar que a inicialização segura foi bem-sucedida. A maioria dos serviços do Google são executados como microsserviços sobre o Borg, e cada microsserviço têm sua própria identidade ALTS. Borg Prime O controlador centralizado do Borg concede essas credenciais do microsserviço microsserviço às cargas de trabalho com base na identidade do microsserviço. As credenciais do Pub/Sub no nível da máquina formam o canal seguro para o provisionamento de credenciais de microsserviços. Assim, somente as máquinas que foram aprovadas na inicialização verificada da integridade do host podem hospedar cargas de trabalho de microsserviços. Para mais informações sobre as credenciais do ALTS, consulte Certificados de cargas de trabalho.

Autorização binária para o Borg para procedência do código

A autorização binária para Borg (BAB, na sigla em inglês) fornece a verificação de procedência do código. A BAB é uma verificação de aplicação no momento da implantação que ajuda a garantir que o código atenda aos requisitos de segurança internos antes da implantação do código. Por exemplo, a verificação de aplicação da BAB inclui garantir que as alterações sejam analisadas por um segundo engenheiro antes do envio do código para nosso repositório de código-fonte, e que os binários sejam comprovadamente criados em uma infraestrutura dedicada. Na nossa infraestrutura, a BAB restringe a implantação de microsserviços não autorizados.

Integridade do host para confiança da máquina

Integridade do host verifica a integridade do software do sistema host por meio de um processo de inicialização seguro e tem suporte de uma raiz de hardware do chip de segurança confiável (chamada Titan), quando compatível. As verificações de integridade do host incluem a verificação de assinaturas digitais no BIOS, controlador de gerenciamento de placa de base (BMC). carregador de inicialização e o kernel do SO. Quando compatível, as verificações de integridade do host podem incluir código de modo de usuário e firmware de periféricos (como NICs). Além da verificação da assinatura digital, a integridade do host ajuda a garantir que cada host esteja executando a versão pretendida desses componentes de software.

Gerenciamento do acesso a serviços e tíquetes de contexto do usuário final para a aplicação de políticas

Gerenciamento de acesso ao serviço e end- tíquetes de contexto do usuário ajudam a fornecer uma aplicação consistente de políticas em todos os serviços.

Política de acesso a serviços: limita a forma como os dados são acessados entre os serviços. Quando uma RPC é enviada de um serviço para outro, o gerenciamento de acesso ao serviço define as políticas de autorização e de auditoria que os serviços exigem para acessar os dados do serviço de recebimento. Isso limita como os dados são acessados, concede o nível mínimo de acesso necessário e especifica como esse acesso pode ser auditado. Na infraestrutura do Google, o gerenciamento de acesso ao serviço limita o acesso de um microsserviço aos dados de outro microsserviço e permite análises globais de controles de acesso.

Os tíquetes de contexto do usuário final são emitidos por um serviço de autenticação de usuários finais e fornecem aos serviços uma identidade separada da identidade do serviço. Essas credenciais atestam a identidade do usuário final que solicitou o serviço. Elas são protegidas quanto à integridade, emitidas centralmente e podem ser encaminhadas. Esses tíquetes reduzem a necessidade de confiança entre os serviços, já que identidades de pares usando o ALTS podem ser insuficientes para conceder acesso, quando essas decisões de acesso normalmente também são baseadas na identidade do usuário final.

Ferramentas do Borg para lançamento automático de alterações e escalonabilidade

As ferramentas do Borg para implantações azul-verde fornecem um lançamento de mudança simples, automatizado e padrão. Uma implantação azul-verde é uma maneira de lançar uma alteração em uma carga de trabalho sem afetar o tráfego de entrada, para que os usuários finais não tenham tempo de inatividade ao acessar o aplicativo.

Um job do Borg é uma única instância de um microsserviço que executa parte de um aplicativo. Os jobs são escalonados de acordo com a carga. Assim, novos jobs são implantados quando ela aumenta e jobs atuais são eliminados quando ela diminui.

As ferramentas do Borg são responsáveis por migrar cargas de trabalho em execução quando realizamos tarefas de manutenção. Quando um novo job do Borg é implantado, um balanceador de carga move gradualmente o tráfego de um job atual para o novo. Isso permite que um microsserviço seja atualizado sem tempo de inatividade e sem que o usuário perceba.

Ela também é usada para aplicar upgrades de serviço quando novos recursos são adicionados e atualizações de segurança críticas sem inatividade. Para as alterações que afetam nossa infraestrutura, usamos a migração em tempo real das VMs do cliente para ajudar a garantir que as cargas de trabalho não sejam afetadas.

Para mais informações, consulte Autorização binária para Borg.

Kernel do gVisor para isolamento de cargas de trabalho

O kernel gVisor permite o isolamento entre cargas de trabalho que compartilham um sistema operacional. O gVisor usa um kernel de espaço do usuário para interceptar e processar syscalls, reduzindo a interação com o host e a possível superfície de ataque. Esse kernel fornece a maior parte da funcionalidade necessária para executar um aplicativo e limita a superfície do kernel de host que é acessível ao aplicativo. O gVisor é uma das várias ferramentas que usamos para isolar cargas de trabalho internas e de clientes do Google Cloud que são executadas no mesmo host. Para ver mais informações sobre outras ferramentas de sandbox, consulte Sandbox de código.

Proteção de dados do usuário com o BeyondProd

Nesta seção, descrevemos como os serviços do BeyondProd funcionam em conjunto para ajudar a proteger os dados do usuário em nossa infraestrutura. As seções abaixo descrevem dois exemplos:

  • Acessar as solicitações de dados do usuário desde a criação até a entrega no destino
  • Uma mudança de código de desenvolvimento para produção.

Nem todas as tecnologias listadas são usadas em todas as partes da nossa infraestrutura. Depende dos serviços e das cargas de trabalho.

Como acessar dados do usuário

O diagrama abaixo mostra o processo que nossa infraestrutura usa para verificar se um usuário tem permissão para acessar os dados dele.

Os controles de segurança nativos da nuvem do Google acessam os dados dos usuários.

Para acessar as contas de usuário, siga estas etapas:

  1. Um usuário envia uma solicitação para o Dialogflow.
  2. O GFE encerra a conexão TLS e encaminha a solicitação ao front-end do serviço apropriado por meio do ALTS.
  3. O front-end do aplicativo autentica a solicitação do usuário usando um serviço central de autenticação do usuário final (EUA) e, se bem-sucedido, recebe um tíquete de contexto criptográfico de usuário final de curta duração.
  4. O front-end do aplicativo faz uma RPC por ALTS para um serviço de back-end de armazenamento, encaminhando o tíquete na solicitação de back-end.
  5. O serviço de back-end usa o gerenciamento de acesso a serviços para garantir que estes critérios sejam verdadeiros:
    • O front-end é autenticado usando um certificado válido e não revogado. Essa verificação implica que está em execução em um host confiável e que as verificações da BAB foram bem-sucedidas.
    • A identidade ALTS do serviço de front-end está autorizada a fazer solicitações ao serviço de back-end e a apresentar um tíquete de EUC;
    • O tíquete de contexto do usuário final é válido.
    • O usuário no tíquete de EUC está autorizado a acessar os dados solicitados.

Se alguma dessas verificações falhar, a solicitação será negada.

Se essas verificações forem aprovadas, os dados serão retornados ao front-end do aplicativo autorizado e exibidos para o usuário autorizado.

Em muitos casos, há uma cadeia de chamadas de back-end, cada serviço de intermediário faz uma verificação da Política de acesso a serviços em RPCs de entrada e o tíquete é encaminhado em RPCs de saída.

Para mais informações sobre como o tráfego é encaminhado dentro da nossa infraestrutura, consulte Como o tráfego é encaminhado.

Como fazer uma mudança no código

O diagrama abaixo mostra como uma mudança de código é implantada.

Como as alterações no código são feitas.

Veja abaixo as etapas para fazer uma mudança no código:

  1. Um desenvolvedor faz uma mudança em um microsserviço protegido pela BAB. A mudança é enviada ao nosso repositório de código central, , que aplica a revisão de código. Após a aprovação, a alteração é enviada ao sistema de compilação central e confiável , que produz um pacote com um certificado de manifesto de build verificável assinado.

  2. No momento da implantação, a BAB valida o certificado assinado do pipeline de compilação para verificar se esse processo foi seguido (etapa 2).

  3. O Borg processa todas as atualizações das cargas de trabalho usando um modelo de confiabilidade que garante interrupção mínima aos serviços, seja um lançamento de rotina ou um patch de segurança de emergência.

  4. O GFE move o tráfego para a nova implantação usando o balanceamento de carga para ajudar a garantir a continuidade das operações.

Para ver mais informações sobre esse processo, consulte Nosso processo de desenvolvimento e produção.

Todas as cargas de trabalho exigem isolamento. Se a carga de trabalho for menos confiável porque o código-fonte se origina fora do Google, ela pode ser implantada em um ambiente protegido pelo gVisor ou usar outras camadas de isolamento. Esse isolamento ajuda a conter um adversário que consegue comprometer um aplicativo.

Implicações de segurança nativas da nuvem

As seções a seguir mostram uma comparação entre os aspectos da segurança tradicional da infraestrutura e os pontos de referência em uma arquitetura nativa da nuvem.

Arquitetura do aplicativo

Um modelo de segurança mais tradicional, focado na segurança baseado em perímetro, não pode proteger uma arquitetura nativa da nuvem por si só. Tradicionalmente, os aplicativos monolíticos usavam uma arquitetura de três níveis e eram implantados em data centers corporativos particulares que tinham capacidade suficiente para lidar com a carga de pico para eventos críticos. Aplicativos com requisitos próprios de rede ou hardware são propositadamente implantados em máquinas específicas que normalmente mantêm endereços IP fixos. Os lançamentos eram pouco frequentes, grandes e difíceis de coordenar, porque as mudanças resultantes afetaram simultaneamente muitas partes do aplicativo. Isso leva a aplicativos de longa duração que são atualizados menos vezes e que não necessitam da aplicação de patches de segurança com frequência.

No entanto, em um modelo nativo da nuvem, os aplicativos precisam ser portáteis entre diferentes ambientes, porque podem ser executados em nuvens públicas, data centers particulares ou serviços hospedados de terceiros. Portanto, em vez de um aplicativo monolítico, um aplicativo conteinerizado dividido em microsserviços se torna ideal para ambientes em nuvem. Os contêineres separam os binários necessários para seu aplicativo do sistema operacional host subjacente e tornam os aplicativos mais portáteis. Nossos contêineres são imutáveis. Ou seja, eles não mudam depois da implantação. Em vez disso, eles são recriados e reimplantados com frequência.

Como os contêineres são reiniciados, eliminados ou reprogramados muitas vezes, a reutilização e o compartilhamento de hardware e rede ocorre com mais frequência. Com um processo de criação e distribuição padronizado comum, o desenvolvimento é mais consistente e uniforme entre as equipes, mesmo que elas gerenciem independentemente o desenvolvimento dos próprios microsserviços. Assim, considerações de segurança, como revisões de segurança, verificação de código e gerenciamento de vulnerabilidades, podem ser resolvidas no início dos ciclos de desenvolvimento.

Malha de serviço

Ao criar uma infraestrutura compartilhada e projetada de maneira segura que todos os desenvolvedores usam, o ônus sobre os desenvolvedores de saber e implementar requisitos comuns de segurança é minimizado. O ideal é que a funcionalidade de segurança exija pouca ou nenhuma integração em cada aplicativo e, em vez disso, seja fornecida como uma malha envolvendo e conectando todos os microsserviços. Isso é comumente chamado de malha de serviço. Isso também significa que a segurança pode ser gerenciada e implementada separadamente das atividades normais de desenvolvimento ou implantação.

Uma malha de serviço é um tecido compartilhado na camada da infraestrutura que envolve e conecta todos os microsserviços. Uma malha de serviço permite comunicação de serviço para serviço, que pode controlar o tráfego, aplicar políticas e fornecer monitoramento centralizado para chamadas de serviço.

Segurança de confiança zero

Em um modelo de segurança tradicional que usa data centers particulares, os aplicativos de uma organização dependem de um firewall para ajudar a proteger cargas de trabalho contra ameaças externas baseadas em rede.

Com um modelo de segurança de confiança zero, as decisões de autorização não dependem de firewalls. Em vez disso, outros controles, como identidade, carga de trabalho e autenticação da carga de trabalho, ajudam a proteger os microsserviço garantindo que as conexões internas ou externas sejam validadas antes de realizar transações. Ao remover a dependência de firewalls ou controles baseados em rede, é possível implementar a segmentação no nível do microsserviço, sem confiança inerente entre os serviços. Com a segmentação no nível do microsserviço, o tráfego pode ter diferentes níveis de confiança com controles diferentes, e você não está mais apenas comparando o tráfego interno com o externo.

Requisitos de segurança compartilhados integrados às pilhas de serviços

Em um modelo de segurança tradicional, os aplicativos individuais eram responsáveis por atender aos próprios requisitos de segurança, independentemente de outros serviços. Esses requisitos incluem gerenciamento de identidade, encerramento de TLS e gerenciamento de acesso a dados. Isso pode levar a implementações inconsistentes ou problemas de segurança não resolvidos, já que precisam ser corrigidos em muitos lugares, o que dificulta a aplicação.

Em uma arquitetura nativa da nuvem, os componentes são usados com mais frequência entre serviços. Os pontos de estrangulamento permitem que as políticas sejam aplicadas de forma consistente em todos os serviços. É possível aplicar políticas diferentes usando diversos serviços de segurança. Em vez de exigir que todos os aplicativos implementem serviços de segurança essencialmente separadamente, é possível dividir as várias políticas em microsserviços separados. Por exemplo, é possível criar uma política para garantir o acesso autorizado aos dados do usuário e outra para garantir o uso de pacotes de criptografia TLS atualizados.

Processos padronizados com lançamentos mais frequentes

Em um modelo de segurança tradicional, há serviços compartilhados limitados, e o código geralmente é duplicado e acoplado ao desenvolvimento local. O compartilhamento limitado dificulta a determinação do impacto de uma mudança e de como ela pode afetar muitas partes de um aplicativo. Como resultado, os lançamentos são pouco frequentes e difíceis de coordenar. Para fazer uma alteração, os desenvolvedores talvez precisem atualizar cada componente diretamente (por exemplo, abrir conexões SSH para cada máquina virtual para atualizar uma configuração). No geral, isso pode levar a aplicativos extremamente longos.

Do ponto de vista da segurança, como o código geralmente é duplicado, é mais difícil analisar e é ainda mais desafiador garantir que, quando uma vulnerabilidade for corrigida, ela seja corrigida em todos os lugares.

Em uma arquitetura nativa da nuvem, os lançamentos são frequentes e padronizados. Esse processo permite que a segurança mude para a esquerda no ciclo de vida de desenvolvimento de software. Mover para a esquerda refere-se à movimentação anterior de etapas no ciclo de vida de desenvolvimento de software, que pode incluir etapas como código, criação, teste, validação e implantação. Deslocar para a esquerda permite uma aplicação de segurança mais simples e consistente, incluindo a aplicação regular de patches de segurança.

Como mudar para o BeyondProd

A transição do Google para o BeyondProd exige mudanças em duas áreas principais: na infraestrutura e no processo de desenvolvimento. Nós processamos essas mudanças simultaneamente, mas elas podem ser resolvidas de maneira independente, se você quiser configurar algo semelhante no seu ambiente.

Como alteramos nossa infraestrutura

Nosso objetivo é automatizar a segurança em toda a infraestrutura porque acreditamos que a segurança precisa ser dimensionada da mesma forma que os serviços. Os serviços precisam ser seguros por padrão e inseguros somente após uma decisão explícita de aceitar os riscos. A intervenção humana direta para nossa infraestrutura precisa ser uma exceção, não a rotina, e as intervenções precisam ser auditáveis quando ocorrerem. Assim, podemos autenticar um serviço com base no código e na configuração implantados, e não com base nas pessoas que implantaram o serviço.

Começamos criando uma base sólida de identidade, autenticação e autorização de serviços. Um microsserviço usa uma identidade de serviço para: autenticar-se em outros serviços em execução na infraestrutura Com uma base de identidades de serviço confiáveis, conseguimos implementar recursos de segurança de nível superior que dependem da validação dessas identidades de serviço, como o gerenciamento de acesso ao serviço e os tíquetes de contexto do usuário final. Para tornar essa transição simples para serviços novos e atuais, o ALTS foi fornecido primeiro como uma biblioteca com um único daemon auxiliar. Esse daemon foi executado no host chamado por todos os serviços e evoluiu ao longo do tempo para se tornar uma biblioteca que usa credenciais de serviço. A biblioteca ALTS foi integrada perfeitamente à biblioteca principal de RPC. Essa integração facilitou a adoção ampla, sem sobrecarregar significativamente as equipes de desenvolvimento individuais. O lançamento do ALTS foi um pré-requisito para o lançamento do gerenciamento de acesso ao serviço e dos tíquetes de contexto do usuário final.

Como alteramos nossos processos de desenvolvimento

era fundamental que o Google estabelecesse um processo robusto de compilação e revisão de código para garantir a integridade dos serviços em execução. Criamos um processo de compilação central em que podemos começar a aplicar requisitos como uma revisão de código por duas pessoas e testes automatizados no tempo de compilação e implantação. Consulte Autorização binária para o Borg para mais detalhes sobre a implantação.

Depois que implementamos os princípios básicos, começamos a lidar com a necessidade de executar códigos externos e não confiáveis em nossos ambientes. Para atingir essa meta, iniciamos o uso do sandbox, primeiro com o ptrace e depois usando o gVisor. Da mesma forma, as implantações azul-verde forneceram benefícios significativos em termos de segurança (por exemplo, a aplicação de patches) e confiabilidade.

Descobrimos rapidamente que era mais fácil se um serviço começasse registrando violações da política em vez de bloqueando violações. O benefício dessa abordagem foi duplo.

  • Primeiro, ela deu aos proprietários de serviços a oportunidade de testar a mudança e avaliar o impacto nos seus serviços, caso migrassem para um ambiente nativo da nuvem.
  • Ele nos permitiu corrigir bugs e identificar outras funcionalidades que podemos fornecer às equipes de serviço.

Por exemplo, quando um serviço é integrado à BAB, os proprietários do serviço ativam o modo "somente auditoria". Isso ajuda a identificar códigos ou fluxos de trabalho que não atendem aos requisitos. Depois de resolver os problemas sinalizados pelo modo "somente auditoria", os proprietários do serviço mudam para o "modo de aplicação". No gVisor, fizemos isso primeiro colocando as cargas de trabalho no sandbox, mesmo com lacunas de compatibilidade nesses recursos, e resolvemos essas falhas sistematicamente para melhorar o sandbox.

A seguir