BeyondProd

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

Este documento descreve como a Google implementa a segurança na nossa infraestrutura através de uma arquitetura nativa da nuvem denominada BeyondProd. BeyondProd refere-se a serviços e controlos na nossa infraestrutura que funcionam em conjunto para ajudar a proteger as cargas de trabalho. As cargas de trabalho são as tarefas únicas que uma aplicação conclui. O BeyondProd ajuda a proteger os microsserviços que executamos no nosso ambiente, incluindo a forma como alteramos o código e como acedemos aos dados do utilizador.

Este documento faz parte de uma série de documentos técnicos que descrevem as tecnologias, como o Chrome Enterprise Premium, que desenvolvemos para ajudar a defender as plataformas Google de ameaças sofisticadas. O Chrome Enterprise Premium implementa uma arquitetura de confiança zero concebida para fornecer acesso seguro às plataformas Google e aos serviços executados nas mesmas. Tal como o Chrome Enterprise Premium, o BeyondProd não depende de proteções tradicionais do perímetro de rede, como firewalls. Em alternativa, o BeyondProd ajuda a criar confiança entre microsserviços através de caraterísticas como a proveniência do código, as identidades de serviço e o hardware fidedigno. Esta confiança estende-se ao software que é executado no Google Cloud e ao software implementado e acedido pelos Google Cloud clientes.

Este documento descreve as vantagens do BeyondProd, os respetivos serviços e processos, e como migrámos para esta arquitetura. Para uma vista geral da nossa segurança da infraestrutura, consulte a vista geral do design de segurança da infraestrutura da Google.

Introdução

As arquiteturas de segurança modernas afastaram-se de um modelo de segurança tradicional baseado em perímetro, em que uma firewall protege o perímetro e todos os utilizadores ou serviços dentro do perímetro são considerados fidedignos.

Atualmente, os utilizadores são móveis e operam frequentemente fora do perímetro de segurança tradicional de uma organização, como a partir das suas casas, de uma cafetaria ou de um avião. Com o Chrome Enterprise Premium, concedemos acesso a recursos da empresa através de vários fatores, incluindo a identidade do utilizador, a identidade do dispositivo que está a ser usado para aceder ao recurso, o estado do dispositivo, sinais de fidedignidade, como o comportamento do utilizador, e listas de controlo de acesso.

O BeyondProd aborda a mesma preocupação para os serviços de produção que o Chrome Enterprise Premium para os utilizadores. Numa arquitetura nativa da nuvem, não podemos simplesmente confiar numa firewall para proteger a rede de produção. Os microsserviços movem-se e são implementados em diferentes ambientes, em hosts heterogéneos, e funcionam a vários níveis de confiança e sensibilidade. Enquanto o Chrome Enterprise Premium afirma que a confiança do utilizador deve depender de características como o estado sensível ao contexto dos dispositivos e não da capacidade de estabelecer ligação à rede empresarial, o BeyondProd afirma que a confiança do serviço deve depender de características como a proveniência do código, o hardware fidedigno e a identidade do serviço, em vez da localização na rede de produção, como o endereço IP ou o nome do anfitrião.

Infraestrutura contentorizada

A nossa infraestrutura implementa cargas de trabalho como microsserviços individuais em contentores. Os microsserviços separam as tarefas individuais que uma aplicação tem de realizar em diferentes serviços. Cada serviço pode ser desenvolvido e gerido de forma independente com a sua própria API, implementação, escalabilidade e gestão de quotas. Os microsserviços são independentes, modulares, dinâmicos e efémeros. Podem ser distribuídas por vários anfitriões, clusters ou até nuvens. Numa arquitetura de microsserviços, uma carga de trabalho pode ser um ou vários microsserviços.

Uma infraestrutura em contentores significa que cada microsserviço é implementado como o seu próprio conjunto de contentores móveis e agendáveis. Para gerir estes contentores internamente, desenvolvemos um sistema de orquestração de contentores denominado Borg,que implementa vários milhares de milhões de contentores por semana. O Borg é o sistema de gestão de contentores unificado da Google e a inspiração para o Kubernetes.

Os contentores facilitam e tornam mais eficiente o agendamento de cargas de trabalho em várias máquinas. A criação de pacotes de microsserviços em contentores permite dividir as cargas de trabalho em unidades mais pequenas e mais fáceis de gerir para manutenção e deteção. Esta arquitetura dimensiona as cargas de trabalho conforme necessário: se houver uma elevada procura de uma carga de trabalho específica, podem existir várias máquinas a executar cópias do mesmo contentor para processar a escala necessária da carga de trabalho.

Na Google, a segurança desempenha um papel fundamental em todas as evoluções da nossa arquitetura. O nosso objetivo com esta arquitetura de microsserviços e processo de desenvolvimento é resolver problemas de segurança o mais cedo possível no ciclo de vida de desenvolvimento e implementação (quando a resolução de problemas é menos dispendiosa) e fazê-lo de forma padronizada e consistente. O resultado final é que os programadores dedicam menos tempo à segurança, mas continuam a alcançar resultados mais seguros.

Vantagens do BeyondProd

O BeyondProd oferece muitas vantagens de automatização e segurança à infraestrutura da Google. As vantagens incluem o seguinte:

  • Proteção do limite da rede: as cargas de trabalho estão isoladas de ataques de rede e tráfego não autorizado da Internet. Embora uma abordagem de perímetro não seja um conceito novo, continua a ser uma prática recomendada de segurança para arquiteturas na nuvem. Uma abordagem de perímetro ajuda a proteger o máximo de infraestrutura possível contra tráfego não autorizado e potenciais ataques da Internet, como ataques DoS baseados em volume.
  • Não existe confiança mútua inerente entre os serviços: apenas os autores de chamadas ou os serviços autenticados, fidedignos e especificamente autorizados podem aceder a qualquer outro serviço. Isto impede que os atacantes usem código não fidedigno para aceder a um serviço. Se um serviço for comprometido, esta vantagem ajuda a impedir que o atacante execute ações que lhe permitam expandir o alcance. Esta desconfiança mútua, combinada com o controlo de acesso detalhado, ajuda a limitar o raio de impacto de um comprometimento.
  • Máquinas fidedignas que executam código com proveniência conhecida: as identidades de serviço estão restritas à utilização apenas de código e configurações autorizados e são executadas apenas em ambientes autorizados e validados.
  • Aplicação de políticas consistente em todos os serviços: a aplicação de políticas consistente ajuda a garantir que as decisões de acesso são fiáveis em todos os serviços. Por exemplo, pode criar uma aplicação de políticas que valide os pedidos de acesso aos dados do utilizador. Para aceder ao serviço, um utilizador final autorizado tem de apresentar um pedido validado e um administrador tem de fornecer uma justificação empresarial.
  • Implementação de alterações simples, automatizadas e padronizadas: as alterações à infraestrutura podem ser facilmente revistas quanto ao respetivo impacto na segurança, e os patches de segurança podem ser implementados com pouco impacto na produção.
  • Isolamento entre cargas de trabalho que partilham um sistema operativo: se um serviço for comprometido, não pode afetar a segurança de outra carga de trabalho em execução no mesmo anfitrião. Este isolamento ajuda a limitar o raio de ação de um comprometimento.
  • Hardware fidedigno e atestação: uma raiz de confiança de hardware ajuda a garantir que apenas o código conhecido e autorizado (do firmware ao modo de utilizador) está a ser executado no anfitrião antes de quaisquer cargas de trabalho serem agendadas para execução no mesmo.

Estas vantagens significam que os contentores e os microsserviços que são executados na nossa arquitetura de nuvem podem ser implementados, comunicar entre si e ser executados lado a lado sem comprometer a segurança da nossa infraestrutura. Além disso, os programadores de microsserviços individuais não têm de se preocupar com os detalhes de segurança e implementação da infraestrutura subjacente.

Serviços de segurança BeyondProd

Concebemos e desenvolvemos vários serviços de segurança BeyondProd para criar as vantagens abordadas em Vantagens do BeyondProd. As secções seguintes descrevem estes serviços de segurança.

Front-end da Google para proteção de limites de rede

O Google Front End (GFE) oferece proteção de limite de rede. O GFE termina a ligação do utilizador final e fornece um ponto central para aplicar as práticas recomendadas de TLS.

Embora a nossa ênfase já não seja na segurança baseada no perímetro, o GFE continua a ser uma parte importante da nossa estratégia para proteger os serviços internos contra ataques DoS. O GFE é o primeiro ponto de entrada para um utilizador que se liga à infraestrutura da Google. Depois de um utilizador se ligar à nossa infraestrutura, o GFE também é responsável pelo equilíbrio de carga e pelo reencaminhamento do tráfego entre regiões, conforme necessário. O GFE é o proxy de limite que encaminha o tráfego para o microserviço correto.

As VMs do cliente em Google Cloud não se registam no GFE. Em alternativa, registam-se no Cloud Front End, que é uma configuração especial do GFE que usa a pilha de rede do Compute Engine. O front-end da nuvem permite que as VMs do cliente acedam diretamente a um serviço Google através do respetivo endereço IP público ou privado. (Os endereços IP privados só estão disponíveis quando o acesso privado à Google está ativado.)

Application Layer Transport Security para confiança entre serviços

A segurança de transporte da camada de aplicação (ALTS) ajuda a garantir que não existe confiança mútua inerente entre os serviços. O ALTS é usado para autenticação de chamadas de procedimentos remotos (RPC),, integridade, encriptação de tráfego e identidades de serviço. O ALTS é um sistema de autenticação mútua e encriptação de transporte para serviços na infraestrutura da Google. Em geral, as identidades estão associadas a serviços em vez de a um nome de servidor ou anfitrião específico. Esta associação ajuda na replicação, no equilíbrio de carga e no reagendamento de microsserviços sem problemas entre anfitriões.

Cada máquina tem uma credencial ALTS que é aprovisionada através do sistema de integridade do anfitrião e só pode ser desencriptada se o sistema de integridade do anfitrião tiver validado que o arranque seguro foi bem-sucedido. A maioria dos serviços Google é executada como microsserviços sobre o Borg, e estes microsserviços têm cada um a sua própria identidade ALTS. Borg Prime, O controlador centralizado do Borg concede estas credenciais do microsserviço ALTS a cargas de trabalho com base na identidade do microsserviço. As credenciais ALTS ao nível da máquina formam o canal seguro para o aprovisionamento de credenciais de microsserviços, para que apenas as máquinas que passaram com êxito no arranque verificado da integridade do anfitrião possam alojar cargas de trabalho de microsserviços. Para mais informações sobre as credenciais ALTS, consulte o artigo Certificados de carga de trabalho.

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

A autorização binária para o Borg (BAB) oferece validação da proveniência do código. O BAB é uma verificação de aplicação no momento da implementação que ajuda a garantir que o código cumpre os requisitos de segurança internos antes de ser implementado. Por exemplo, a verificação da aplicação da BAB inclui garantir que as alterações são revistas por um segundo engenheiro antes de o código ser enviado para o nosso repositório de código fonte e que os ficheiros binários são criados de forma verificável numa infraestrutura dedicada. Na nossa infraestrutura, a BAB restringe a implementação de microsserviços não autorizados.

Integridade do anfitrião para fidedignidade da máquina

Integridade do anfitrião valida a integridade do software do sistema anfitrião através de um processo de arranque seguro e é suportada por um chip de segurança de raiz de confiança de hardware (denominado Titan) onde for suportado. As verificações de integridade do anfitrião incluem a validação de assinaturas digitais no BIOS, no controlador de gestão da placa base (BMC),, no carregador de arranque e no kernel do SO. Quando suportadas, as verificações de integridade do anfitrião podem incluir código no modo de utilizador e firmware periférico (como NICs). Além da validação da assinatura digital, a integridade do anfitrião ajuda a garantir que cada anfitrião está a executar a versão pretendida destes componentes de software.

Gestão do acesso aos serviços e pedidos de contexto do utilizador final para a aplicação de políticas

A gestão do acesso ao serviço e os vales de contexto do utilizador final ajudam a fornecer uma aplicação de políticas consistente entre serviços.

A gestão do acesso aos serviços limita a forma como os dados são acedidos entre serviços. Quando um RPC é enviado de um serviço para outro, a gestão de acesso ao serviço define as políticas de autorização e auditoria que os serviços requerem para aceder aos dados do serviço de receção. Isto limita a forma como os dados são acedidos, concede o nível mínimo de acesso necessário e especifica como esse acesso pode ser auditado. Na infraestrutura da Google, a gestão de acesso aos serviços limita o acesso de um microsserviço aos dados de outro microsserviço e permite análises globais dos controlos de acesso.

Os pedidos de contexto do utilizador final são emitidos por um serviço de autenticação do utilizador final e fornecem aos serviços uma identidade do utilizador separada da respetiva identidade do serviço. Estes pedidos são credenciais protegidas pela integridade, emitidas centralmente e encaminháveis que atestam a identidade de um utilizador final que fez um pedido ao serviço. Estes pedidos reduzem a necessidade de confiança entre os serviços, uma vez que as identidades de pares que usam o ALTS podem ser insuficientes para conceder acesso, quando essas decisões de acesso também se baseiam normalmente na identidade do utilizador final.

Ferramentas Borg para implementação automática de alterações e escalabilidade

As ferramentas do Borg para implementações azul-verde oferecem uma implementação de alterações simples, automatizada e padronizada. Uma implementação azul-verde é uma forma de implementar uma alteração numa carga de trabalho sem afetar o tráfego recebido, para que os utilizadores finais não sofram nenhuma indisponibilidade ao aceder à aplicação.

Uma tarefa do Borg é uma única instância de um microsserviço que executa alguma parte de uma aplicação. As tarefas são dimensionadas para processar a carga, com novas tarefas implementadas quando a carga aumenta e as tarefas existentes terminadas quando a carga diminui.

As ferramentas do Borg são responsáveis pela migração das cargas de trabalho em execução quando realizamos tarefas de manutenção. Quando é implementada uma nova tarefa do Borg, um equilibrador de carga move gradualmente o tráfego de uma tarefa existente para a nova. Isto permite que um microsserviço seja atualizado sem tempo de inatividade e sem que o utilizador repare.

Também usamos esta ferramenta para aplicar atualizações de serviços quando adicionamos novas funcionalidades e para aplicar atualizações de segurança críticas sem tempo de inatividade. Para alterações que afetam a nossa infraestrutura, usamos a migração em direto das VMs dos clientes para ajudar a garantir que as cargas de trabalho não são afetadas.

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

Kernel do gVisor para isolamento de cargas de trabalho

O kernel do gVisor permite o isolamento entre cargas de trabalho que partilham um sistema operativo. O gVisor usa um kernel do espaço do utilizador para intercetar e processar chamadas de sistema, reduzindo a interação com o anfitrião e a potencial superfície de ataque. Este kernel fornece a maioria das funcionalidades necessárias para executar uma aplicação e limita a superfície do kernel do anfitrião acessível à aplicação. O gVisor é uma das várias ferramentas que usamos para isolar cargas de trabalho internas e cargas de trabalho de clientes que são executadas no mesmo anfitrião. Google Cloud Para mais informações sobre outras ferramentas de sandbox, consulte o artigo Sandbox de código.

Proteger os dados do utilizador com o BeyondProd

Esta secção descreve como os serviços BeyondProd funcionam em conjunto para ajudar a proteger os dados dos utilizadores na nossa infraestrutura. As secções abaixo descrevem dois exemplos:

  • Aceder a pedidos de dados do utilizador desde a respetiva criação até à entrega no destino.
  • Uma alteração de código do desenvolvimento para a produção.

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

Aceder aos dados do utilizador

O diagrama abaixo mostra o processo que a nossa infraestrutura usa para verificar se um utilizador tem permissão para aceder aos dados do utilizador.

Os controlos de segurança nativos da nuvem da Google que acedem aos dados do utilizador.

Seguem-se os passos para aceder às contas de utilizador:

  1. Um utilizador envia um pedido ao GFE.
  2. O GFE termina a ligação TLS e encaminha o pedido para o frontend do serviço adequado através do ALTS.
  3. O frontend da aplicação autentica o pedido do utilizador através de um serviço de autenticação do utilizador final (EUA) central e, se for bem-sucedido, recebe um pedido de contexto do utilizador final criptográfico de curta duração.
  4. O front-end da aplicação faz uma RPC através do ALTS para um serviço de back-end de armazenamento, encaminhando o pedido no pedido de back-end.
  5. O serviço de back-end usa a gestão de acesso ao serviço para garantir que os seguintes critérios são verdadeiros:
    • A interface é autenticada através de um certificado válido e não revogado. Esta verificação implica que está a ser executado num anfitrião fidedigno e que as verificações de BAB foram bem-sucedidas.
    • A identidade ALTS do serviço de front-end está autorizada a fazer pedidos ao serviço de back-end e apresentar um pedido de EUC.
    • O pedido de contexto do utilizador final é válido.
    • O utilizador no pedido de utilizador final (EUC) está autorizado a aceder aos dados pedidos.

Se alguma destas verificações falhar, o pedido é recusado.

Se estas verificações forem aprovadas, os dados são devolvidos à interface da aplicação autorizada e publicados para o utilizador autorizado.

Em muitos casos, existe uma cadeia de chamadas de back-end e todos os serviços intermediários fazem uma verificação de acesso ao serviço em RPCs de entrada, e o pedido é encaminhado em RPCs de saída.

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

Fazer uma alteração ao código

O diagrama abaixo mostra como é implementada uma alteração de código.

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

Os passos para alterar o código são os seguintes:

  1. Um programador faz uma alteração a um microserviço protegido pela BAB. A alteração é enviada para o nosso repositório de código central,, que aplica a revisão de código. Após a aprovação, a alteração é enviada para o sistema de compilação central e fidedigno que produz um pacote com um certificado de manifesto de compilação validável assinado.

  2. No momento da implementação, o BAB verifica se este processo foi seguido validando o certificado assinado da pipeline de compilação.

  3. O Borg processa todas as atualizações de cargas de trabalho através de um modelo de fiabilidade que garante uma interrupção mínima dos serviços, quer se trate de uma implementação de rotina ou de uma correção de segurança de emergência.

  4. O GFE move o tráfego para a nova implementação através do equilíbrio de carga para ajudar a garantir a continuidade das operações.

Para mais informações acerca deste processo, consulte o artigo O nosso processo de desenvolvimento e produção.

Todas as cargas de trabalho requerem isolamento. Se a carga de trabalho for menos fidedigna porque o código fonte tem origem fora da Google, a carga de trabalho é implementada com camadas de isolamento mais fortes, como a implementação num ambiente protegido pelo gVisor. Este isolamento ajuda a conter um adversário que consiga comprometer uma aplicação.

Implicações de segurança nativas da nuvem

As secções seguintes oferecem uma comparação entre aspetos da segurança da infraestrutura tradicional e os respetivos contrapontos numa arquitetura nativa da nuvem.

Arquitetura de aplicações

Um modelo de segurança mais tradicional, focado na segurança baseada no perímetro, não consegue proteger uma arquitetura nativa da nuvem por si só. Tradicionalmente, as aplicações monolíticas usavam uma arquitetura de três camadas e eram implementadas em centros de dados corporativos privados que tinham capacidade suficiente para processar o pico de carga para eventos críticos. As aplicações com requisitos de hardware ou de rede específicos foram implementadas intencionalmente em máquinas específicas que, normalmente, mantêm endereços IP fixos. As implementações eram pouco frequentes, grandes e difíceis de coordenar, uma vez que as alterações resultantes afetavam simultaneamente muitas partes da aplicação. Isto levou a aplicações com um ciclo de vida muito longo, que são atualizadas com menos frequência e onde os patches de segurança são normalmente aplicados com menos frequência.

No entanto, num modelo nativo da nuvem, as aplicações têm de ser portáteis entre diferentes ambientes, porque podem ser executadas em nuvens públicas, centros de dados privados ou serviços alojados de terceiros. Por conseguinte, em vez de uma aplicação monolítica, uma aplicação contentorizada dividida em microsserviços torna-se ideal para ambientes de nuvem. Os contentores desassociam os ficheiros binários de que a sua aplicação precisa do sistema operativo anfitrião subjacente e tornam as aplicações mais portáteis. Os nossos contentores são imutáveis, o que significa que não são alterados após a implementação. Em vez disso, são reconstruídos e reimplementados com frequência.

Com os contentores a serem reiniciados, parados ou reagendados com frequência, existe uma reutilização e partilha mais frequentes de hardware e rede. Com um processo de compilação e distribuição padronizado comum, o processo de desenvolvimento é mais consistente e uniforme entre as equipas, mesmo que estas façam a gestão independente do desenvolvimento dos respetivos microsserviços. Como resultado, as considerações de segurança (como revisões de segurança, análise de código e gestão de vulnerabilidades) podem ser abordadas numa fase inicial dos ciclos de desenvolvimento.

Malha de serviço

Ao criar uma infraestrutura partilhada e concebida em segurança que todos os programadores usam, a responsabilidade dos programadores de conhecer e implementar requisitos de segurança comuns é minimizada. A funcionalidade de segurança deve exigir pouca ou nenhuma integração em cada aplicação e, em vez disso, é fornecida como uma estrutura que envolve e liga todos os microsserviços. Isto é normalmente denominado malha de serviços. Isto também significa que a segurança pode ser gerida e implementada separadamente das atividades de desenvolvimento ou implementação normais.

Uma malha de serviços é uma estrutura partilhada na camada de infraestrutura que envolve e liga todos os microsserviços. Uma malha de serviços permite a comunicação entre serviços, que pode controlar o tráfego, aplicar políticas e fornecer monitorização centralizada para chamadas de serviço.

Segurança de confiança zero

Num modelo de segurança tradicional que usa centros de dados privados, as aplicações de uma organização dependem de uma firewall para ajudar a proteger as cargas de trabalho de ameaças externas baseadas na rede.

Com um modelo de segurança de confiança zero, as decisões de autorização não dependem de firewalls. Em alternativa, outros controlos, como a identidade da carga de trabalho, a autenticação e a autorização, ajudam a proteger os microsserviços, garantindo que as ligações internas ou externas são validadas antes de poderem realizar transações. Quando remove a sua dependência de firewalls ou controlos baseados na rede, pode implementar a segmentação ao nível do microsserviço, sem confiança inerente entre os serviços. Com a segmentação ao nível do microsserviço, o tráfego pode ter níveis de confiança variáveis com controlos diferentes e já não está apenas a comparar o tráfego interno com o externo.

Requisitos de segurança partilhados que estão integrados em conjuntos de serviços

Num modelo de segurança tradicional, as aplicações individuais são responsáveis por cumprir os seus próprios requisitos de segurança independentemente de outros serviços. Estes requisitos incluem a gestão de identidades, a terminação de TLS e a gestão do acesso aos dados. Isto pode levar a implementações inconsistentes ou problemas de segurança não resolvidos, uma vez que estes problemas têm de ser corrigidos em muitos locais, o que dificulta a aplicação de correções.

Numa arquitetura nativa da nuvem, os componentes são reutilizados com muito mais frequência entre os serviços. Os pontos de estrangulamento permitem que as políticas sejam aplicadas de forma consistente em todos os serviços. Podem ser aplicadas diferentes políticas através de diferentes serviços de segurança. Em vez de exigir que cada aplicação implemente serviços de segurança críticos separadamente, pode dividir as várias políticas em microsserviços separados. Por exemplo, pode criar uma política para garantir o acesso autorizado aos dados do utilizador e criar outra política para garantir a utilização de conjuntos de cifras TLS atualizados.

Processos padronizados com implementações mais frequentes

Num modelo de segurança tradicional, existem serviços partilhados limitados e o código é frequentemente duplicado e associado ao desenvolvimento local. A partilha limitada torna mais difícil determinar o impacto de uma alteração e como a alteração pode afetar muitas partes de uma aplicação. Como resultado, as implementações são pouco frequentes e difíceis de coordenar. Para fazer uma alteração, os programadores podem ter de atualizar cada componente diretamente (por exemplo, abrir ligações SSH a cada máquina virtual para atualizar uma configuração). Em geral, isto pode levar a aplicações com uma duração extremamente longa.

Do ponto de vista da segurança, como o código é frequentemente duplicado, é mais difícil de rever e ainda mais difícil garantir que, quando uma vulnerabilidade é corrigida, é corrigida em todos os locais.

Numa arquitetura nativa da nuvem, as implementações são frequentes e padronizadas. Este processo permite que a segurança seja testada numa fase inicial do processo (shift left testing) no ciclo de vida de desenvolvimento de software. A mudança para a esquerda refere-se à antecipação de passos no ciclo de vida do desenvolvimento de software, que pode incluir passos como codificar, criar, testar, validar e implementar. A mudança para a esquerda permite uma aplicação mais simples e consistente da segurança, incluindo a aplicação regular de patches de segurança.

Fazer a alteração para o BeyondProd

A transição da Google para o BeyondProd exigiu alterações em duas áreas principais: na nossa infraestrutura e no nosso processo de desenvolvimento. Abordámos estas alterações em simultâneo, mas pode abordá-las de forma independente se quiser configurar algo semelhante no seu ambiente.

Alterar a nossa infraestrutura

O nosso objetivo é automatizar a segurança em toda a nossa infraestrutura porque acreditamos que a segurança deve ser dimensionada da mesma forma que os serviços são dimensionados. Os serviços têm de ser seguros por predefinição e inseguros apenas após uma decisão explícita de aceitar os riscos. A intervenção humana direta na nossa infraestrutura deve ser uma exceção e não uma rotina, e as intervenções devem ser auditáveis quando ocorrem. Em seguida, podemos autenticar um serviço com base no código e na configuração implementados para o serviço, em vez de com base nas pessoas que implementaram o serviço.

Começámos por criar uma base sólida de identidade, autenticação e autorização de serviços. Um microsserviço usa uma identidade de serviço para se autenticar noutros serviços em execução na infraestrutura. Ter uma base de identidades de serviços fidedignas permitiu-nos implementar capacidades de segurança de nível superior dependentes da validação destas identidades de serviços, como a gestão do acesso aos serviços e os pedidos de contexto do utilizador final. Para simplificar esta transição para os serviços novos e existentes, o ALTS foi fornecido primeiro como uma biblioteca com um único daemon auxiliar. Este daemon era executado no anfitrião chamado por todos os serviços e evoluiu ao longo do tempo para uma biblioteca que usa credenciais de serviço. A biblioteca ALTS foi integrada na perfeição na biblioteca RPC principal. Esta integração facilitou a ampla adoção, sem um encargo significativo para as equipas de desenvolvimento individuais. A implementação do ALTS foi um pré-requisito para a implementação da gestão de acesso aos serviços e dos pedidos de contexto do utilizador final.

Alterar os nossos processos de desenvolvimento

Foi fundamental para a Google estabelecer um processo de revisão de código e compilação robusto para garantir a integridade dos serviços em execução. Criámos um processo de compilação central onde podíamos começar a aplicar requisitos, como uma revisão de código por duas pessoas e testes automatizados no momento da compilação e implementação. (Consulte o artigo Autorização binária para o Borg para ver mais detalhes sobre a implementação.)

Depois de termos os princípios básicos implementados, começámos a abordar a necessidade de executar código externo não fidedigno nos nossos ambientes. Para atingir este objetivo, começámos a usar a sandbox, primeiro com o ptrace e, mais tarde, com o gVisor. Da mesma forma, as implementações azul-verde proporcionaram vantagens significativas em termos de segurança (por exemplo, aplicação de patches) e fiabilidade.

Descobrimos rapidamente que era mais fácil se um serviço começasse por registar violações de políticas em vez de as bloquear. A vantagem desta abordagem foi dupla:

  • Deu aos proprietários dos serviços a oportunidade de testar a alteração e avaliar o impacto (se existir) que a mudança para um ambiente nativo da nuvem teria no respetivo serviço.
  • Permitiu-nos corrigir erros e identificar funcionalidades adicionais que poderíamos ter de fornecer às equipas de serviços.

Por exemplo, quando um serviço é integrado no BAB, os proprietários do serviço ativam o modo de apenas auditoria. Isto ajuda-os a identificar código ou fluxos de trabalho que não cumprem os respetivos requisitos. Depois de resolverem os problemas denunciados pelo modo de apenas auditoria, os proprietários dos serviços mudam para o modo de aplicação. No gVisor, fizemos isto primeiro isolando as cargas de trabalho, mesmo com lacunas de compatibilidade nas capacidades de isolamento, e, em seguida, resolvendo estas lacunas sistematicamente para melhorar o isolamento.

O que se segue?