BeyondProd: uma nova abordagem de segurança nativa da nuvem

O Google escreveu diversos whitepapers que explicam projetos desenvolvidos internamente para melhorar a segurança. O BeyondProd segue propositalmente os conceitos do BeyondCorp. Assim como um modelo de segurança de perímetro não funciona mais para usuários finais, o mesmo se aplica a microsserviços. Adaptando o whitepaper original do BeyondCorp, "as principais premissas desse modelo não são mais válidas: o perímetro não é mais apenas o local físico da empresa [data center], e o que está dentro dele não é mais um lugar totalmente seguro para hospedar dispositivos de computação pessoal e aplicativos empresariais [microsserviços]".

Neste whitepaper, fornecemos detalhes sobre como várias partes da infraestrutura do Google trabalham em conjunto para proteger cargas de trabalho em uma arquitetura que agora é conhecida como "nativa da nuvem". Para uma visão geral da segurança do Google, consulte o whitepaper sobre o esquema de segurança da infraestrutura.

O conteúdo apresentado aqui foi editado em dezembro de 2019. Este whitepaper representa o cenário corrente do momento em que foi escrito. As políticas e os sistemas de segurança do Google Cloud poderão mudar no futuro, à medida que melhoramos continuamente a proteção para os usuários.

Glossário

As definições a seguir são usadas neste documento:

  • Um microsserviço separa as tarefas individuais que um aplicativo precisa executar em serviços separados, que podem ser desenvolvidos e gerenciados independentemente, cada um com sua API, seu lançamento, dimensionamento e gerenciamento de cotas. Em uma arquitetura mais moderna, um aplicativo, como um site, pode ser executado como um conjunto de microsserviços em vez de como um único serviço monolítico. 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.

  • Uma carga de trabalho é uma tarefa exclusiva que um aplicativo executa. Em uma arquitetura de microsserviço, essa carga de trabalho pode ser um ou vários microsserviços.

  • Um job é uma instância única de um microsserviço que executa parte de um aplicativo.

  • Um microsserviço usa uma identidade de serviço para se autenticar em outros serviços em execução na infraestrutura.

  • Uma malha de serviço é uma camada de infraestrutura para comunicação de serviço a serviço capaz de controlar o tráfego, aplicar políticas e fornecer monitoramento centralizado para chamadas de serviço. Em uma arquitetura de microsserviço, ela acaba com a sobrecarga dos serviços individuais para implementar esses controles e permite um gerenciamento mais simples e centralizado em muitos microsserviços.

Resumo para CIOs

  • A infraestrutura do Google implementa cargas de trabalho como microsserviços individuais em contêineres e as gerencia usando o Borg, nosso sistema de orquestração de contêiner. Essa é uma inspiração e o modelo para o que hoje é amplamente conhecido como uma arquitetura "nativa da nuvem".

  • A infraestrutura do Google foi projetada com foco intencional na segurança, que não foi agregada posteriormente como algo secundário. Nossa infraestrutura parte do princípio de que não há confiança entre seus serviços.

  • O Google protege os microsserviços com uma iniciativa chamada BeyondProd. Essa proteção inclui a forma como o código é alterado e como os dados do usuário em microsserviços são acessados. O BeyondProd aplica conceitos como: endpoints de serviço mutuamente autenticados, segurança de transporte, terminação de borda com balanceamento de carga global e proteção contra negação de serviço, procedência do código de ponta a ponta e sandbox de ambiente de execução.

  • Passar de um modelo de segurança tradicional para um modelo nativo da nuvem exigiu mudanças em duas áreas principais: a infraestrutura e o processo de desenvolvimento. A criação de componentes compartilhados em uma malha compartilhada que envolve e conecta todos os microsserviços, também conhecida como malha de serviço, facilitou a implementação de alterações e a segurança consistente em todos os serviços.

Motivação

O Google mudou para contêineres e orquestração de contêineres para alcançar maior utilização de recursos, criar aplicativos altamente disponíveis e simplificar o trabalho dos desenvolvedores do Google. Tivemos outra motivação para mudar para uma infraestrutura em contêineres, que é alinhar nossos controles de segurança com nossa arquitetura. Ficou claro para nós que um modelo de segurança baseado em perímetro não era seguro o suficiente. Se um invasor violasse o perímetro, ele teria livre circulação dentro da rede. Embora compreendêssemos que precisávamos de controles de segurança mais rigorosos em toda a infraestrutura, também queríamos que os desenvolvedores do Google pudessem criar e implantar aplicativos seguros sem ter que implementar recursos de segurança.

Migrar de aplicativos monolíticos para microsserviços distribuídos implantados de contêineres usando um sistema de orquestração tinha benefícios operacionais tangíveis: gerenciamento e escalabilidade mais simples. Essa arquitetura nativa da nuvem exigia um modelo de segurança diferente, com ferramentas distintas para proteger as implantações de maneira alinhada aos benefícios de gerenciamento e escalabilidade dos microsserviços.

Neste documento, você verá como a segurança nativa da nuvem é implementada no Google, aqui chamada de BeyondProd: o que significa ser "nativo da nuvem" em termos de segurança, princípios para a segurança nativa da nuvem, sistemas criados para atender a esses requisitos e algumas orientações sobre como lidar com uma mudança desse tipo.

Segurança nativa da nuvem no Google

Microsserviços em contêiner

Desde o início, o Google tomou a decisão consciente de basear a capacidade do data center em servidores tradicionais de baixo custo, em vez de investir em hardware altamente disponível mais caro. A filosofia orientadora da nossa confiabilidade era, e continua sendo, a seguinte: qualquer parte individual de um sistema precisa poder falhar sem afetar a disponibilidade de serviços visíveis para o usuário. Conseguir essa disponibilidade exigia a execução de instâncias redundantes de serviços para que falhas únicas não levassem a interrupções. Como resultado dessa filosofia, desenvolvemos contêineres, microsserviços e a orquestração de contêineres para gerenciar de forma escalonável a implantação desses sistemas altamente redundantes e distribuídos.

Uma infraestrutura em contêineres significa que cada carga de trabalho é implantada como seu próprio conjunto de contêineres imutáveis, móveis e programáveis. Para gerenciá-los internamente, desenvolvemos um sistema de orquestração chamado Borg 1 (em inglês), que ainda usamos atualmente para implantar vários bilhões de contêineres por semana.

Com os contêineres, ficou mais fácil agrupar e reprogramar as cargas de trabalho entre as máquinas. Os microsserviços facilitaram o desenvolvimento e a depuração de partes diferentes de um aplicativo. Usados em conjunto, os microsserviços e contêineres permitem que as cargas de trabalho sejam divididas em unidades menores e mais gerenciáveis para manutenção e descoberta. A infraestrutura em contêineres com uma arquitetura de microsserviço é chamada "nativa da nuvem" (em inglês). Os serviços são executados dentro de contêineres implantados pelo Borg. 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.

O diferencial do Google é que levamos a segurança em conta como parte de cada evolução da nossa arquitetura. O conceito mais recente de segurança nativa da nuvem é comparável ao que o Google usa há muitos anos para proteger nossa infraestrutura. 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.

Como migrar para uma arquitetura nativa da nuvem

As arquiteturas de segurança modernas foram além do modelo tradicional, em que um muro protege o perímetro e qualquer usuário ou serviço dentro dele é considerado totalmente confiável. O BeyondCorp foi uma resposta à mudança na forma como o usuário corporativo moderno trabalha. Hoje, os usuários são móveis e geralmente operam fora do perímetro de segurança tradicional de uma organização: em um café, no avião ou em qualquer outro lugar. No BeyondCorp, dispensamos a ideia de uma rede corporativa privilegiada e acesso autorizado com base apenas em credenciais e atributos do usuário e dispositivo, independentemente da localização da rede.

A segurança nativa da nuvem responde à mesma preocupação quanto a serviços e usuários: em um mundo nativo da nuvem, não podemos simplesmente confiar em um firewall para proteger a rede de produção, assim como não podemos confiar em um firewall para proteger a rede corporativa. Da mesma forma que os usuários não usam o mesmo local ou dispositivo físico, nem todos os desenvolvedores implantam código no mesmo ambiente. Com o BeyondProd, os microsserviços podem ser executados não só em um data center com firewall, mas em nuvens públicas e privadas ou serviços hospedados de terceiros e precisam estar protegidos em qualquer lugar.

Assim como os usuários estão em movimento, usam dispositivos diferentes e se conectam a partir de diversos locais, os microsserviços também estão em movimento e são implantados em ambientes distintos, em hosts heterogêneos. Enquanto o BeyondCorp afirma que "a confiança do usuário precisa se basear em características como o estado contextual dos dispositivos, e não na capacidade de conexão com a rede corporativa", o BeyondProd afirma que "a confiança no serviço precisa se basear em características como procedência do código e identidade do serviço, não do local na rede de produção, como identidade de IP ou nome do host".

Arquitetura nativa da nuvem e desenvolvimento de aplicativos

Um modelo de segurança mais tradicional, baseado em perímetro, não pode proteger sozinho uma arquitetura nativa da nuvem. Pense neste exemplo: um aplicativo monolítico que usa uma arquitetura de três níveis é implantado em um data center corporativo privado com capacidade suficiente para gerenciar o pico de carga em 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 são pouco frequentes, grandes e difíceis de coordenar, porque as alterações resultantes afetam 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 contêineres separam do sistema operacional de host subjacente, os binários de que o aplicativo precisa, tornando os aplicativos mais portáteis. Os contêineres precisam ser usados de forma imutável, o que significa que eles não são alterados depois de implantados. Por isso, são reconstruídos e reimplantados com frequência. 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. 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. Como resultado, considerações de segurança, como revisões de segurança, verificação de código e gerenciamento de vulnerabilidade, podem ocorrer mais cedo no ciclo de desenvolvimento.

Implicações para a segurança

Falamos muito sobre como o modelo de um interior não confiável, com usuários no BeyondCorp, também pode ser aplicado a microsserviços no BeyondProd. Mas como seria essa mudança? Veja na Tabela 1 uma comparação entre os aspectos de segurança da infraestrutura tradicional e seus contrapontos em uma arquitetura nativa da nuvem. Ela também mostra os requisitos necessários para migrar de uma para a outra. No restante desta seção, você verá mais detalhes sobre cada linha da tabela.

Segurança na infraestrutura tradicional Segurança nativa da nuvem Requisitos implícitos para a segurança nativa da nuvem
Segurança baseada em perímetro (firewall), com comunicações internas consideradas confiáveis. Segurança com confiança zero e comunicação de serviço a serviço verificada. Não há confiança implícita nos serviços do ambiente. Proteção da rede na borda (permanece aplicável), sem confiança mútua entre os serviços.
Correção de IPs e hardware para alguns aplicativos. Maior utilização, reutilização e compartilhamento de recursos, incluindo IPs e hardware. Máquinas confiáveis executando código de procedência conhecida.
Identidade baseada em endereço IP. Identidade baseada em serviços.
Os serviços são executados em um local conhecido e esperado. Os serviços podem ser executados em qualquer lugar do ambiente, incluindo implantações híbridas na nuvem pública e em data centers particulares.
Requisitos específicos de segurança incorporados a cada aplicativo e adotadas separadamente. Requisitos de segurança compartilhados, integrados em pilhas de serviços de acordo com uma política de aplicação centralizada. Pontos de estrangulamento para aplicação consistente de políticas em todos os serviços.
Restrições limitadas em como os serviços são criados e revisados. Requisitos de segurança aplicados de forma consistente a todos os serviços.
Supervisão limitada de componentes de segurança. Visualização centralizada das políticas de segurança e da adesão às políticas.
Lançamentos especializados e pouco frequentes. Processo de criação e implantação padronizado, com alterações mais frequentes em microsserviços individuais. Lançamento de mudanças simples, automatizado e padronizado.
As cargas de trabalho normalmente são implantadas como VMs ou hosts físicos e usam máquinas físicas ou hipervisores para fornecer isolamento. Cargas de trabalho agrupadas por classes e os respectivos processos são executados em um sistema operacional compartilhado, o que exige um mecanismo para isolar as cargas de trabalho. Isolamento entre cargas de trabalho que compartilham um sistema operacional.

Tabela 1: requisitos implícitos para a segurança na migração para uma arquitetura nativa da nuvem

Da segurança baseada em perímetro à segurança com confiança zero

Em um modelo de segurança tradicional, os aplicativos de uma organização podem depender de um firewall externo em seu data center particular para proteção contra o tráfego de entrada. Em um ambiente nativo da nuvem, o perímetro de rede ainda precisa ser protegido, mas assim como no BeyondCorp, um modelo de segurança baseado em perímetro não é mais suficiente. Não se trata de um novo problema de segurança, e sim de reconhecer que se um firewall não pode proteger totalmente a rede corporativa, ele não poderá proteger totalmente a rede de produção. Com um modelo de segurança de confiança zero, não se pode mais confiar implicitamente no tráfego interno. Esse modelo requer outros controles de segurança, como autenticação e criptografia. Ao mesmo tempo, a mudança para microsserviços é uma oportunidade para repensar o modelo de segurança tradicional. Quando removemos a dependência de um perímetro de rede único (por exemplo, um firewall), é possível segmentar ainda mais a rede por serviços. Ou ainda, é possível implementar a segmentação no nível do microsserviço, sem a confiança inerente entre os serviços. Com os microsserviços, o tráfego pode ter diferentes níveis de confiança com controles diferentes. Não se trata mais de comparar apenas o tráfego interno e o externo.

De IPs e hardware fixos a recursos compartilhados maiores

Em um modelo de segurança tradicional, os aplicativos de uma organização eram implantados em máquinas específicas, e os endereços IP dessas máquinas não eram alterados com frequência. Ou seja, as ferramentas de segurança podiam confiar em um mapa de arquitetura relativamente estático que vinculava aplicativos de maneira previsível. Políticas de segurança em ferramentas como firewalls podiam usar endereços IP como identificadores.

No entanto, no mundo nativo da nuvem, com hosts compartilhados e jobs que mudam frequentemente, o uso de um firewall para controlar o acesso entre microsserviços não funciona. Não é possível confiar no fato de que um endereço IP específico está vinculado a um serviço específico. Como resultado, em vez de basear a identidade em um endereço IP ou nome de host, você a baseia em um serviço.

De implementações de segurança específicas de aplicativos a requisitos de segurança compartilhados integrados em 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 incluíam gerenciamento de identidade, terminação SSL/TLS e gerenciamento de acesso a dados. Isso muitas vezes levava a implementações inconsistentes ou problemas de segurança não resolvidos, porque esses problemas precisavam ser corrigidos em muitos lugares, o que dificultava a aplicação das correções.

No mundo nativo da nuvem, os componentes são reutilizados com muito mais frequência entre os serviços, e existem pontos de estrangulamento que permitem que as políticas sejam aplicadas de forma consistente entre eles. É possível aplicar políticas diferentes usando diversos serviços de segurança. Em vez de exigir que cada aplicativo implemente serviços de segurança essenciais separadamente, divida as várias políticas em microsserviços separados. Por exemplo, uma política para garantir acesso autorizado aos dados do usuário e outra para garantir o uso de conjuntos de criptografia TLS atualizados.

De processos de implantação especializados e raros a processos padronizados com lançamentos mais frequentes

Em um modelo de segurança tradicional, havia poucos serviços compartilhados. O código mais distribuído, em conjunto com o desenvolvimento local, significava que era difícil determinar o impacto de uma alteração que afetava muitas partes de um aplicativo. Como resultado, os lançamentos eram pouco frequentes e difíceis de coordenar. Para fazer uma alteração, os desenvolvedores às vezes precisavam atualizar cada componente diretamente. Por exemplo, conectar-se por SSH em uma máquina virtual para atualizar uma configuração. Em geral, isso levava a aplicativos de longuíssima duração. Do ponto de vista da segurança, como o código era mais distribuído, era mais difícil analisá-lo e mais ainda garantir que, ao corrigir uma vulnerabilidade, ela fosse corrigida em todos os lugares. Mudar para a arquitetura nativa da nuvem, em que os lançamentos são frequentes e padronizados, permite que a segurança se desloque à esquerda2 no ciclo de desenvolvimento de software. Isso permite uma aplicação mais simples e consistente da higiene da segurança, incluindo a aplicação regular de patches de segurança.

De cargas de trabalho isoladas usando máquinas físicas ou hipervisores até cargas de trabalho agrupadas por classes em execução na mesma máquina que exigem maior isolamento

Em um modelo de segurança tradicional, as cargas de trabalho eram programadas em suas próprias instâncias, sem recursos compartilhados. Um aplicativo era efetivamente delimitado por seus limites de máquina e rede, e o isolamento de carga de trabalho era imposto exclusivamente pela confiança na separação de hosts físicos, hipervisores e firewalls tradicionais.

Em um mundo nativo da nuvem, as cargas de trabalho são separadas em contêineres, agrupadas por classes e enviadas a hosts e recursos compartilhados. Como resultado, é necessário um isolamento mais forte entre elas. As cargas de trabalho podem ser separadas em microsserviços, que são isolados uns dos outros em parte por meio de controles de rede e tecnologias de sandbox.

Princípios de segurança

Ao desenvolver uma arquitetura nativa da nuvem, queríamos, ao mesmo tempo, fortalecer nossa segurança. Por isso, desenvolvemos e otimizamos os seguintes princípios de segurança:

  • Proteção da rede na borda, para que as cargas de trabalho sejam isoladas de ataques à rede e tráfego não autorizado da Internet. Embora uma abordagem baseada em firewall não seja um conceito novo para a nuvem nativa, ela continua sendo uma prática recomendada de segurança. Em um mundo nativo da nuvem, uma abordagem de perímetro é usada para proteger o máximo de infraestrutura possível contra tráfego não autorizado e possíveis ataques da Internet, como ataques de negação de serviço com base em volume.

  • Nenhuma confiança mútua inerente entre os serviços, de modo que somente autores de chamadas conhecidos, confiáveis e especificamente autorizados possam utilizar um serviço. Isso impede que invasores usem código não confiável para acessar um serviço. Se um serviço for comprometido, o invasor é impedido de realizar outras ações que aumentem seu alcance. Essa desconfiança mútua ajuda a limitar o impacto em caso de invasão.

  • Máquinas confiáveis que executam código de procedência conhecida, para que as identidades de serviço se restrinjam a usar configurações e códigos autorizados e sejam executadas somente em ambientes autorizados e verificados.

  • Pontos de estrangulamento para aplicação consistente de políticas em todos os serviços. Por exemplo, um ponto de estrangulamento para verificar solicitações de acesso a dados de usuários, de modo que o acesso ao serviço seja derivado de uma solicitação validada de um usuário final autorizado e o acesso do administrador exija uma justificativa de negócios.

  • 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, de maneira que, se um serviço for comprometido, isso não afete a segurança de outra carga de trabalho em execução no mesmo host. Isso limita o impacto de um possível comprometimento.

Em toda a nossa infraestrutura, nosso objetivo é ter segurança automatizada que não dependa de indivíduos. A segurança precisa ser escalonada da mesma forma que os serviços. Os serviços precisam ser seguros por padrão e inseguros por exceção. As ações humanas têm que ser exceções, não rotina, e, quando necessárias, precisam ser auditáveis. Assim, podemos autenticar um serviço com base no código e na configuração implantados, não nas pessoas que implantaram o serviço.

Em conjunto, a implementação desses princípios de segurança significa que contêineres e microsserviços podem ser implantados, se comunicar e ser executados lado a lado sem enfraquecer as propriedades de uma arquitetura nativa da nuvem. Por exemplo, gerenciamento de carga de trabalho simples, dimensionamento de ambiente autônomo e empacotamento eficaz. Tudo isso pode ser feito sem sobrecarregar os desenvolvedores individuais de microsserviços com detalhes de segurança e implementação da infraestrutura subjacente.

Serviços de segurança internos do Google

Para proteger a infraestrutura nativa da nuvem do Google, desenvolvemos diversas ferramentas e serviços internos. Os serviços de segurança listados abaixo trabalham em conjunto para atender aos Princípios de segurança:

  • Google Front End (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 uma conexão de usuário com o Google. Uma vez em nossa infraestrutura, o GFE também é responsável pelo balanceamento de carga e por redirecionar o tráfego entre regiões, conforme necessário. Em nossa infraestrutura, o GFE é o proxy de borda, que direciona o tráfego para o microsserviço certo.

  • Application Layer Transport Security (ALTS): usado para autenticação RPC, integridade e criptografia. O ALTS é um sistema de criptografia mútua de autenticação e transporte para serviços na infraestrutura do Google. Em geral, as identidades são vinculadas aos serviços, não a um nome de servidor ou host específico. Isso facilita a replicação de microsserviços, o balanceamento de carga e a reprogramação de hosts. Tudo de modo perfeito e sem interrupções.

  • Autorização binária para Borg e Integridade de host são usados para verificação da integridade de microsserviços e da máquina, respectivamente:

    • Autorização binária para Borg (BAB, na sigla em inglês): uma verificação de aplicação do tempo de implantação que garante que o código atenda aos requisitos de segurança interna antes de ser implantado. As verificações BAB incluem a revisão de mudanças por um segundo engenheiro, o envio do código ao nosso repositório de código-fonte e a criação verificada de binários na infraestrutura dedicada. Na nossa infraestrutura, a BAB restringe a implantação de microsserviços não autorizados.
    • Integridade de host (HINT, na sigla em inglês): verifica a integridade do software do sistema host por meio de um processo de inicialização segura. Quando compatível, tem o suporte do hardware seguro do microcontrolador. As verificações de HINT incluem a verificação de assinaturas digitais no BIOS, BMC, carregador de inicialização e kernel do SO.
  • A Política de acesso a serviços e os tíquetes de contexto do usuário final são usados para restringir o acesso aos dados:

    • 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, a Política de acesso a serviços define as políticas de autenticação, autorização e auditoria necessárias 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, a Política de acesso a serviços limita o acesso de dados de um microsserviço a outro e permite análises globais dos controles de acesso.
    • Tíquetes de contexto do usuário final (EUC, na sigla em inglês): esses tíquetes são emitidos por um serviço de autenticação de usuários finais e fornecem uma identidade de usuário 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. Isso reduz a necessidade de confiança entre os serviços, porque a identidade de mesmo nível via ALTS muitas vezes é insuficiente para conceder acesso e as decisões de autorização normalmente também se baseiam na identidade do usuário final.
  • Ferramentas Borg para implantações azul-verde 3: esse conjunto de ferramentas é responsável por migrar cargas de trabalho durante tarefas de manutenção. Além do job atual, um novo job do Borg é implantado, e um balanceador de carga transfere gradualmente o tráfego de um para o outro. Isso permite que um microsserviço seja atualizado sem tempo de inatividade e sem que o usuário perceba. Esse conjunto de ferramentas é usado para aplicar upgrades de serviço quando novos recursos são adicionados, além de aplicar atualizações de segurança críticas sem tempo de inatividade. Por exemplo, Heartbleed e Spectre/Meltdown (em inglês). Para as alterações que afetam a infraestrutura do Google Cloud, usamos a migração em tempo real para garantir que as cargas de trabalho da VM não sejam afetadas.

  • gVisor (em inglês), para isolamento de cargas de trabalho. O gVisor usa um kernel de espaço do usuário para interceptar e manipular syscalls, reduzindo a interação com o host e a potencial 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 do host que é acessível ao aplicativo. Na infraestrutura do Google, o gVisor é uma das várias ferramentas importantes usadas para isolar cargas de trabalho internas e do Google Cloud executadas no mesmo host.

A Tabela 2 mapeia cada princípio descrito na seção Princípios de segurança para uma ferramenta correspondente usada pelo Google para implementar esse princípio.

Princípio de segurança Ferramenta/serviço de segurança interna do Google
Proteção da rede na borda Google Front End (GFE), para gerenciar a terminação TLS e as políticas de tráfego de entrada
Nenhuma confiança mútua inerente entre os serviços Application Layer Transport Security (ALTS), para autenticação de RPC, integridade, criptografia e identidades de serviço
Máquinas confiáveis executando código com procedência conhecida Autorização binária para Borg (BAB, na sigla em inglês), para verificação da procedência do código

Integridade de host (HINT, na sigla em inglês), para verificação da integridade da máquina

Pontos de estrangulamento para aplicação consistente de políticas em todos os serviços Política de acesso a serviços, para limitar a forma como os dados são acessados entre os serviços

Tíquete de contexto do usuário final (EUC, na sigla em inglês), para atestar a identidade do solicitante original

Lançamento de mudanças simples, automatizado e padronizado Ferramentas Borg, para implantações azul-verde
Isolamento entre cargas de trabalho que compartilham um sistema operacional gVisor, para isolamento de cargas de trabalho

Tabela 2: princípios e ferramentas de segurança para implementar a segurança nativa da nuvem no Google

Funcionamento em conjunto

Nesta seção, você verá como os componentes discutidos até agora se encaixam para atender às solicitações dos usuários em um mundo nativo da nuvem. Usamos dois exemplos: primeiro, rastreamos uma solicitação de dados do usuário comum desde a criação até a entrega no destino. Depois, rastreamos uma mudança de código de desenvolvimento para produção. Nem todas as tecnologias listadas aqui são usadas em todas as partes da infraestrutura do Google. Isso depende dos serviços e das cargas de trabalho.

Como acessar dados do usuário

Como mostrado na Figura 1, quando o GFE recebe uma solicitação de usuário (etapa 1), ele encerra a conexão TLS e encaminha a solicitação ao front-end do serviço apropriado por ALTS4 (etapa 2). O front-end do aplicativo autentica a solicitação do usuário usando um serviço central de autenticação de usuários finais (EUA, na sigla em inglês). Se a autenticação for concluída, ele receberá um tíquete de curta duração de contexto do usuário final (EUC, na sigla em inglês) criptografado (etapa 3).

diagrama

Figura 1: controles de segurança da arquitetura nativa do Google – como acessar dados do usuário

O front-end do aplicativo cria uma RPC por ALTS para um serviço de back-end de armazenamento, encaminhando o tíquete de EUC na solicitação de back-end (etapa 4). O serviço de back-end usa a Política de acesso a serviços para verificar se:

  1. 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;
  2. a identidade do front-end está protegida pela autorização binária para Borg (BAB, na sigla em inglês);
  3. o tíquete de EUC é válido.

Em seguida, o serviço de back-end verifica se 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. 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 de EUC é encaminhado em RPCs de saída. Se essas verificações forem aprovadas, os dados serão retornados ao front-end do aplicativo autorizado e exibidos para o usuário autorizado.

Cada máquina tem uma credencial ALTS provisionada por meio do sistema HINT e só pode ser descriptografada se o HINT tiver verificado se a inicialização da máquina 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. O Borgmaster 5 concede essas credenciais de microsserviço ALTS a cargas de trabalho com base na identidade do microsserviço, conforme descrito na Figura 1. As credenciais ALTS no nível da máquina formam o canal de segurança para provisionamento de credenciais de microsserviço, de modo que somente máquinas que concluam a Inicialização verificada HINT podem hospedar cargas de trabalho de microsserviços.

Como fazer uma mudança no código

Como mostrado na Figura 2, quando um Googler faz uma alteração em um microsserviço protegido por uma BAB adequadamente forte, a alteração precisa ser enviada ao nosso repositório de código central que impõe uma revisão do código. Depois de aprovada, a alteração é enviada ao sistema de compilação central confiável, que produz um pacote com um certificado assinado de manifesto de compilação verificável (etapa 1). 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).

diagrama

Figura 2: controles de segurança da arquitetura nativa da nuvem do Google – como fazer uma mudança no código

Todas as atualizações na carga de trabalho são gerenciadas por implantações azul-verde, seja um lançamento de rotina ou um patch de segurança de emergência (etapa 3). O GFE faz o balanceamento de carga do tráfego para a nova implantação, garantindo a continuidade das operações.

Todas as cargas de trabalho exigem isolamento. Se a carga de trabalho for menos confiável, por exemplo, com vários locatários, ou se o código-fonte for externo ao Google, ela poderá ser implantada em um ambiente protegido pelo gVisor ou usar outras camadas de isolamento. Esse isolamento garante que, se uma instância do aplicativo for comprometida, nenhuma das outras instâncias seja afetada.

Como aplicar o BeyondProd

Aproveitando ao máximo

Ao migrar para a arquitetura nativa da nuvem e proteger adequadamente essa infraestrutura, o Google pode oferecer propriedades de segurança muito fortes para suas cargas de trabalho internas e externas (Google Cloud).

Com a criação de componentes compartilhados, a responsabilidade individual dos desenvolvedores em atender a requisitos comuns de segurança é mínima. 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.

Mudança para a arquitetura nativa da nuvem

A transição do Google para a arquitetura nativa da nuvem exigiu mudanças em duas áreas principais: em nossa infraestrutura e em nosso processo de desenvolvimento. Fizemos essas mudanças simultaneamente, mas elas podem ser dissociadas e abordadas de forma independente.

Como alteramos nossa infraestrutura

Começamos criando uma base sólida de identidade, autenticação e autorização de serviços. Ter uma base de identidades de serviço confiáveis permitiu a implementação de recursos de segurança de nível superior, que dependem da validação dessas identidades de serviço, como as Políticas de acesso a serviços e os tíquetes de EUC. 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. Isso facilitou a adoção ampla, sem sobrecarga significativa para as equipes de desenvolvimento individuais. O lançamento do ALTS foi um pré-requisito para o lançamento das Políticas de acesso a serviços e dos tíquetes de EUC.

Como alteramos nossos processos de desenvolvimento

Era essencial que o Google estabelecesse um processo robusto de criação e revisão de código. Isso nos permitiu garantir a integridade dos serviços que estão em execução e que as identidades usadas pelo ALTS sejam significativas. Estabelecemos um processo de criação central em que pudemos aplicar requisitos, como uma análise de código por duas pessoas e testes automatizados no momento da criação e implantação. Consulte o whitepaper Autorização binária para 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 proporcionaram benefícios significativos em termos de segurança (por exemplo, a aplicação de patches), bem como 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, ele 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. Segundo, ele nos permitiu corrigir bugs e identificar outras funcionalidades que talvez precisássemos 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.

Benefícios da alteração

Assim como o BeyondCorp nos ajudou a evoluir para além de um modelo de segurança baseado em perímetro, o BeyondProd representa um salto semelhante em nossa abordagem de segurança de produção. A abordagem do BeyondProd descreve uma arquitetura de segurança nativa da nuvem que pressupõe a ausência de confiança entre serviços, cria o isolamento entre cargas de trabalho, garante que apenas aplicativos desenvolvidos centralmente sejam implantados, automatiza o gerenciamento de vulnerabilidades e impõe fortes controles de acesso a dados críticos. A arquitetura BeyondProd levou o Google a inovar em vários novos sistemas para atender a esses requisitos.

Muitas vezes, a segurança é a última consideração, quando a decisão de migrar para uma nova arquitetura já foi tomada. Com o envolvimento da equipe de segurança desde o início e foco nos benefícios do novo modelo de segurança, como gerenciamento de patches mais simples e controles de acesso mais rigorosos, a arquitetura nativa da nuvem pode proporcionar benefícios significativos para as equipes de segurança e desenvolvimento de aplicativos. Ao aplicar os princípios de segurança descritos neste documento à sua infraestrutura nativa da nuvem, você reforça a implantação de cargas de trabalho, como as comunicações entre elas são protegidas e como elas afetam umas às outras.

Observações

1 O Borg (em inglês) é o sistema de gerenciamento de clusters do Google para programar e executar cargas de trabalho em escala. Ele foi o primeiro sistema de gerenciamento de contêineres unificado do Google e a inspiração para o Kubernetes (links em inglês).

2 "Deslocar-se à esquerda" refere-se às etapas anteriores no ciclo de desenvolvimento de software, que podem incluir a escrita do código, criação, teste, validação e implantação. Os diagramas de ciclo de vida são frequentemente desenhados da esquerda para a direita, ou seja, a esquerda significa em uma etapa anterior.

3 Uma implantação azul-verde é uma maneira de implementar 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.

4 Para entender melhor como o tráfego é encaminhado dentro da infraestrutura do Google do GFE para um serviço, consulte a seção Como o tráfego é encaminhado do nosso whitepaper sobre criptografia em trânsito.

5 O Borgmaster é o controlador centralizado do Borg (em inglês). Ele gerencia a programação de jobs e se comunica com jobs em execução nos seus status.