Autorização binária para o Borg

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 usamos revisões de código, infraestrutura de segurança e uma verificação de aplicação chamada Autorização binária para Borg (BAB, na sigla em inglês) para ajudar a proteger a cadeia de suprimentos de software do Google contra riscos de pessoas com informações privilegiadas. A BAB ajuda a reduzir o risco de pessoas com informações privilegiadas, porque garante que o software de produção seja revisado e aprovado antes de ser implantado, especialmente quando nosso código pode acessar dados confidenciais. A BAB se aplica a todos os serviços executados no Borg. Desde a publicação original deste documento, incluímos os principais conceitos da BAB em uma especificação aberta chamada Níveis de cadeia de suprimentos para artefatos de software (SLSA, na sigla em inglês).

Este documento faz parte de uma série de artigos técnicos que descrevem alguns projetos desenvolvidos pela equipe de segurança do Google para melhorar a segurança, incluindo BeyondCorp e BeyondProd. Para ter 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

O risco de pessoa com informações privilegiadas representa uma ameaça à segurança dos dados do usuário, que pode incluir dados de emprego, dados financeiros ou outros dados reservados ou comerciais. O risco de pessoas com informações privilegiadas é o potencial para um funcionário usar o conhecimento organizacional ou o acesso dele para realizar atos maliciosos. ou para que um invasor externo use as credenciais comprometidas de um funcionário para fazer o mesmo.

Para minimizar o risco de pessoas com informações privilegiadas na nossa cadeia de suprimentos de software, usamos a BAB. A BAB é uma verificação interna de aplicação que ocorre quando o software é implantado. A BAB garante que as implantações de código e configuração atendam a determinados padrões mínimos e ofereçam uniformidade nos nossos sistemas de produção.

Ajudamos a proteger os dados do usuário nos nossos sistemas de produção, evitando o acesso unilateral por nossos funcionários. A BAB ajuda a garantir que os funcionários, enquanto atuem sozinhos, não possam acessar direta ou indiretamente ou afetar os dados do usuário sem a devida autorização e justificativa. A BAB e os controles associados a ela nos ajudam a aplicar o menor privilégio, o que melhora nossa postura de segurança de maneira independente de um invasor específico. Em outras palavras, a BAB impede o acesso unilateral, independentemente de o ator ter intenções maliciosas, se a conta tiver sido comprometida ou de ter recebido acesso não intencional.

Benefícios da BAB

A adoção da BAB e de um modelo de implantação conteinerizada oferece muitos benefícios de segurança para a infraestrutura do Google. Os benefícios incluem:

  • A BAB ajuda a reduzir o risco geral de pessoas com informações privilegiadas: a BAB exige que o código atenda a determinados padrões e práticas de gestão da mudança antes que o código possa acessar os dados do usuário. Esse requisito reduz o potencial para um funcionário que atua sozinho (ou uma conta de funcionário comprometida) acesse dados do usuário de maneira programática.
  • A BAB oferece suporte à uniformidade nos sistemas de produção: ao usar sistemas em contêineres e verificar os requisitos da BAB antes da implantação, nossos sistemas fazem com que os processos de gestão de mudanças se tornem mais fáceis de depurar, mais confiáveis e bem definidos. Os requisitos da BAB fornecem uma linguagem comum para os requisitos do sistema de produção.
  • A BAB dita uma linguagem comum para a proteção de dados: ela acompanha a conformidade nos sistemas Google. Os dados sobre essa conformidade são publicados internamente e estão disponíveis para outras equipes. A publicação de dados da BAB permite que as equipes usem termos comuns ao se comunicarem sobre a proteção contra acesso a dados. Essa linguagem comum reduz o trabalho necessário ao lidar com dados entre as equipes.
  • A BAB permite o rastreamento programático dos requisitos de conformidade: ela simplifica as tarefas que antes eram de conformidade manual. Certos processos no Google exigem controles mais rígidos sobre o uso dos dados. Por exemplo, nossos sistemas de relatórios financeiros precisam estar em conformidade com a Lei Sarbanes-Oxley (SOX). Antes da BAB, tínhamos um sistema que nos ajudava a realizar verificações manualmente para garantir a conformidade. Com a introdução da BAB, muitas dessas verificações foram automatizadas com base nas políticas da BAB para os serviços. Com a automatização dessas verificações, a equipe de conformidade pode aumentar o escopo dos serviços cobertos e a adoção dos respectivos controles adequados.

A BAB faz parte do framework maior BeyondProd que usamos para mitigar o risco de pessoas com informações privilegiadas.

Nosso processo de desenvolvimento e produção

Por padrão, o processo de desenvolvimento e produção do Google inclui quatro etapas obrigatórias: revisão de código, builds verificáveis, implantação conteinerizada e identidade baseada em serviço. As seções a seguir descrevem essas etapas em mais detalhes.

Passo 1: análise do código

A maior parte do código-fonte é armazenada em um repositório monolítico central, e exige revisão e aprovação de pelo menos um engenheiro que não seja o autor. Com uma base do código monolítica, também é possível aplicar um único ponto de estrangulamento para análises de código.

No mínimo, nosso processo de revisão de código exige que os proprietários de um sistema aprovem as modificações de código.

Ao importar alterações de terceiros ou de código aberto, verificamos se elas são apropriadas. Por exemplo, analisamos a versão mais recente. No entanto, muitas vezes, não adotamos os mesmos controles de análise em cada alteração feita por desenvolvedores externos no código aberto ou de terceiros que usamos.

Passo 2: compilações verificáveis

Nosso sistema de build é semelhante ao Bazel, que cria e compila código-fonte para criar um binário para implantação. Nosso sistema de compilação é executado em um ambiente isolado e bloqueado , separado dos funcionários que executam os builds. Para cada build, o sistema produz procedência gerada por builds verificáveis . Essa procedência é um certificado assinado que descreve as origens e dependências incluídas no build, os hashes criptográficos de qualquer binário ou outros artefatos de build, além dos parâmetros completos de build. Essa procedência permite o seguinte:

  • Capacidade de rastrear um binário para o código-fonte usado na criação. Por extensão, a procedência também poderá rastrear o processo de criação e envio do código-fonte descrito.
  • Capacidade de verificar se o binário não foi modificado, já que qualquer alteração no arquivo invalidaria automaticamente a assinatura dele.

Como as ações de build podem ser um código arbitrário, nosso sistema de compilação foi fortalecido para multilocação. Em outras palavras, ele foi criado para evitar que um build influencie outros. O sistema impede que os builds façam alterações que comprometam a integridade dos manifestos de procedência do build ou do próprio sistema. Quando a build estiver concluído, a mudança será implantada usando o Borg.

Etapa 3: implantação em contêiner

Depois que o sistema de compilação cria o binário, ele é empacotado em uma imagem de contêiner e implantado como um Job do Borg em nosso sistema de orquestração de cluster, Borg. Executamos centenas de milhares de jobs a partir de vários aplicativos diferentes em vários clusters, cada um com até dezenas de milhares de máquinas.. Mesmo com essa escala, nosso ambiente de produção é bastante homogêneo. Como resultado, pode ser mais fácil auditar e controlar os pontos de contato para acesso aos dados do usuário.

Os contêineres oferecem benefícios de segurança importantes. Os contêineres precisam ser imutáveis, com reimplantações frequentes de uma recriação completa de imagens. Com a conteinerização, é possível analisar uma mudança de código no contexto e fornecer um único ponto de estrangulamento para as alterações implantadas na infraestrutura.

Uma configuração de um job do Borg especifica os requisitos para a implantação do job: imagens de contêiner, parâmetros de ambiente de execução, argumentos e sinalizações. O Borg programa o job, considerando as restrições, a prioridade, a cota e quaisquer outros requisitos do job que estejam listados na configuração. Depois de implantado, o job do Borg pode interagir com outros jobs em produção.

Etapa 4: identidade baseada em serviços

Um job do Borg é executado como uma identidade de serviço. Essa identidade é usada para acessar repositórios de dados ou métodos de chamada de procedimento remoto (RPC) de outros serviços. É possível executar vários jobs como a mesma identidade. Somente os funcionários responsáveis por executar o serviço , normalmente confiabilidade do site Engenheiros (SREs), podem implantar ou modificar jobs com uma identidade específica.

Ao iniciar um job, o Borg o provisiona com credenciais criptográficas. O job usa essas credenciais para comprovar a identidade ao fazer solicitações de outros serviços por meio do Application Layer Transport Security (ALTS). Para que um serviço acesse determinados dados ou outro serviço, a identidade dele precisa ter as permissões necessárias.

Nossas políticas exigem proteção da BAB para identidades de serviço que têm acesso a dados do usuário e qualquer outra informação confidencial. Os jobs de controle de qualidade e de desenvolvimento que não têm acesso a dados sensíveis podem ser executados com menos controles.

Como funciona a BAB

A BAB se integra ao Borg para garantir que apenas jobs autorizados possam ser executados com a identidade de cada serviço. A BAB também cria uma trilha de auditoria do código e da configuração usados em jobs ativados para a BAB para permitir o monitoramento e resposta a incidentes.

A BAB foi projetada para garantir que todo software e configuração de produção seja devidamente revisado, verificado, criado de maneira verificável e autorizado, especialmente quando esse código puder acessar os dados do usuário.

Política específica do serviço

Quando os proprietários de serviços fazem a integração com a BAB, eles criam uma política BAB que define os requisitos de segurança para o serviço. Esta política é chamada de política específica do serviço. Definir ou mudar uma política é uma alteração de código que precisa ser analisada.

A política específica do serviço define qual código e configuração podem ser executados como a identidade do serviço, bem como as propriedades necessárias desse código e configuração. Todos os jobs executados como a identidade do serviço precisam atender à política específica do serviço.

Todos os serviços do Borg no Google precisam configurar uma política específica.

Por padrão, essa prática reforça os seguintes requisitos:

  • O código precisa ser auditável: Podemos rastrear a imagem do contêiner de volta para as origens legíveis por meio de procedência gerada por builds verificáveis. Uma política de retenção mantém as origens legíveis do código por pelo menos 18 meses, mesmo que o código não seja enviado.
  • O código precisa ser enviado: O código é criado com base em um local especificado e definido em nosso repositório de origem. Isso geralmente significa que o código passou por uma análise.
  • As configurações precisam ser enviadas: Todas as configurações fornecidas durante a implantação passam pelo mesmo processo de revisão e envio que o código normal. Portanto, os valores, os argumentos e os parâmetros da flag de linha de comando não podem ser modificados sem revisão.

Serviços que não têm acesso a dados sensíveis ou, em casos raros circunstâncias, os serviços que têm uma exceção válida e aprovada, podem têm uma política mais abrangente, como uma que exige apenas a auditoria ou até mesmo um que desative totalmente a BAB.

Os sistemas e componentes que aplicam a BAB são rigorosamente controlados requisitos automatizados e controles manuais adicionais.

Modos de aplicação

A BAB usa dois modos de aplicação para garantir que todos os jobs obedeçam à política específica do serviço:

  • Imposição do tempo de implantação, que bloqueia a implantação de jobs que não estão em conformidade.
  • Validação contínua, que monitora e alerta em jobs que não estão em conformidade e foram implantados.

Além disso, em caso de emergência, os procedimentos de resposta a emergências podem ignorar a aplicação no momento da implantação.

Modo de aplicação no momento da implantação

O Borg Prime é o controlador centralizado do Borg, que funciona como a autoridade certificadora do Pub/Sub. Quando um novo job é enviado, o Borg Prime consulta a BAB para verificar se ele cumpre os requisitos da política específica do serviço antes que o Borg Prime conceda o certificado do ALTS ao job. Essa verificação funciona como um controlador de admissão: o Borg só iniciará o job se ele atender à política específica do serviço. Essa verificação ocorre mesmo quando o funcionário ou serviço que faz a solicitação de implantação tem autorização.

Em casos raros, os serviços podem desativar a aplicação no momento da implantação com uma justificativa adequada.

Modo de verificação contínua

Depois que um job é implantado, ele é verificado continuamente durante todo o ciclo de vida, independentemente do modo de aplicação no momento da implantação. Um processo da BAB é executado pelo menos uma vez por dia para verificar se os jobs iniciados e em execução obedecem às atualizações das políticas. Por exemplo, o modo de verificação contínua verifica constantemente se há jobs em execução com políticas desatualizadas ou que foram implantadas usando procedimentos de resposta a emergências. Se for encontrado um job que não adere à política mais recente, a BAB notifica os proprietários do serviço para que eles possam reduzir o risco.

Procedimentos de resposta a emergências

Quando um incidente ou interrupção ocorre, nossa prioridade é restaurar o serviço afetado o mais rápido possível. Em uma emergência, pode ser necessário executar um código não revisado ou aprovado. Como resultado, o modo de restrição pode ser substituído usando uma flag de resposta de emergência. Os procedimentos de resposta a emergências também funcionam como um backup caso caso haja uma falha da BAB que, de outra forma, bloquearia a implantação. Quando um desenvolvedor que implanta um job usando o procedimento de resposta a emergências, ele precisa enviar uma justificativa como parte da solicitação.

Durante uma resposta de emergência, a BAB registra detalhes sobre o job do Borg associado e envia uma notificação para a equipe de segurança centralizada do Google e a equipe que é proprietária da identidade do serviço. A entrada de registro inclui uma referência a um instantâneo do código que foi implantado e a justificativa fornecida pelo usuário. Os procedimentos de resposta a emergências são usados apenas como último recurso.

Como estender a BAB para outros ambientes

Inicialmente, a BAB era compatível apenas com a proteção de jobs do Borg e exigia o desenvolvimento do software usando o pipeline de controle de origem, criação e empacotamento tradicional do Google. Agora, a BAB adicionou suporte para proteger outros ambientes de entrega e implantação de software, além de suporte para sistemas de controle de origem, build e pacotes alternativos. Os detalhes da implementação desses vários ambientes são diferentes, mas os benefícios da BAB permanecem.

Existem alguns casos que não são eficazes para revisões de código humanas antes da implantação, como o desenvolvimento iterativo de códigos de machine learning e a análise de dados de alta frequência. Nesses casos, temos controles alternativos que compensam a revisão humana.

Como adotar controles semelhantes na sua organização

Nesta seção, descrevemos as práticas recomendadas que aprendemos ao implementar a BAB para que você possa adotar controles semelhantes na sua organização.

Criar um pipeline de CI/CD homogêneo e conteinerizado

A adoção da BAB ficou mais fácil porque a maioria das equipes usou um único sistema de controle de origem, processo de revisão de código, sistema de compilação e sistema de implantação. As avaliações de código já faziam parte da nossa cultura, então pudemos fazer mudanças sem muitas mudanças significativas visíveis ao usuário. Para adotar a BAB, focamos em revisões de código, builds verificáveis, implantações em contêineres e identidades baseadas em serviço para controle de acesso. Essa abordagem simplificou a adoção da BAB e fortaleceu as garantias que essa solução pode oferecer.

O uso generalizado de microsserviços e identidades baseadas em serviços (como contas de serviço) em vez de identidades baseadas em hosts (como endereços IP) nos permite criar um controle refinado sobre o software que tem permissão para executar cada serviço.

Se a organização não puder adotar uma identidade de serviço diretamente, tente proteger os tokens de identidade usando outras medidas como uma etapa provisória.

Determinar metas e definir políticas com base nos requisitos

Crie um processo de liberação orientado por políticas, uma parte por vez. Talvez seja necessário implementar algumas mudanças antes de outras no pipeline de CI/CD. Por exemplo, talvez você precise começar a realizar análises formais de código antes de aplicá-las no momento da implantação.

Um ótimo motivador para um processo de lançamento orientado por políticas é a conformidade. Se você puder codificar pelo menos alguns dos requisitos de conformidade em uma política, isso pode ajudar a automatizar os testes e garantir que eles tenham sempre efeito. Comece com um conjunto básico de requisitos e codifique os mais avançados à medida que você avança.

Aplicar políticas no início do desenvolvimento

É difícil definir políticas abrangentes em um software sem primeiro saber onde ele será executado e quais dados ele acessará. Portanto, a aplicação da política específica do serviço é feita quando o código é implantado e acessa os dados, não quando ele é criado. Uma política é definida em termos de uma identidade de ambiente de execução, de modo que o mesmo código pode ser executado em ambientes diferentes e estar sujeito a políticas distintas.

Usamos a BAB, além de outros mecanismos de acesso, para limitar o acesso aos dados do usuário. Os proprietários de serviços podem garantir que os dados sejam acessados apenas por um job que atenda a determinados requisitos da BAB.

Inscrever agentes de mudança entre as equipes

Quando decretamos a implantação da BAB em todo o Google, o que mais afetou nossa taxa de sucesso foi encontrar proprietários para impulsionar a mudança em cada grupo de produtos. Identificamos alguns proprietários de serviços que viram benefícios imediatos da aplicação e estavam dispostos a fornecer feedback. Pedimos a esses proprietários para se voluntariarem antes de tornar as alterações obrigatórias. Depois que recebemos a ajuda, criamos uma equipe formal de gestão da mudança para acompanhar as alterações em andamento. Em seguida, identificamos os proprietários responsáveis em cada equipe de produto para implementar as modificações.

Determinar como gerenciar o código de terceiros

Se você precisa gerenciar código de terceiros, pense em como introduzir os requisitos da política na base de código de terceiros. Por exemplo, é possível comece mantendo uma repositório de todo o código de terceiros usado. Recomendamos que você verifique esse código regularmente com base nos seus requisitos de segurança.

Para mais informações sobre como gerenciar código de terceiros, consulte Sucesso compartilhado na criação de uma comunidade de código aberto mais segura.

A seguir