Autorização binária para Borg: como o Google verifica a procedência e implementa a identidade do código

O Google escreveu vários whitepapers explicando projetos desenvolvidos internamente para ajudar a melhorar a segurança, incluindo o BeyondCorp e o BeyondProd. Para uma visão geral da segurança do Google, consulte o whitepaper Design de infraestrutura de segurança.

Neste whitepaper, você verá o processo de análise de código do Google, sua procedência1 e a necessidade de mecanismos de aplicação. O foco é o desenvolvimento de uma verificação de aplicação específica: autorização binária para Borg (BAB, na sigla em inglês). O objetivo da BAB é reduzir o risco de pessoas com informações privilegiadas, garantindo que o software de produção implantado no Google seja devidamente analisado e autorizado, especialmente se ele tiver acesso a dados de usuários. Para todos os produtos do Google, valorizamos a proteção dos dados do usuário e nos esforçamos para ser o mais transparente possível sobre as medidas de segurança tomadas.

O conteúdo deste whitepaper é válido a partir de dezembro de 2019. Ele representa o estado no momento em que foi escrito. As políticas e os sistemas de segurança do Google Cloud podem mudar no futuro, à medida que a proteção dos clientes é aprimorada.

Resumo para CIOs

  • O risco de pessoas com informações privilegiadas representa uma ameaça à segurança dos dados do usuário. No Google, tentamos minimizar ao máximo a possibilidade de funcionários usarem o conhecimento organizacional ou o acesso a dados de usuários de maneira não autorizada, o que inclui executar um job não autorizado.
  • A autorização binária do Borg (BAB, na sigla em inglês) é uma verificação de aplicação interna no momento da implantação que minimiza o risco de pessoas com informações privilegiadas. Assim, ela garante que o software e a configuração de produção implantados no Google sejam analisados e autorizados da melhor maneira, especialmente se tiver acesso a dados do usuário.
  • A BAB garante que as implantações de código e de configuração atendam a determinados padrões mínimos.
  • Além da aplicação, ela também pode ser usada em um modo de auditoria não obrigatório para avisar quando determinados requisitos não forem atendidos.
  • Com a BAB, o Google reduz o risco de pessoas com informações privilegiadas, evita possíveis ataques e dá suporte à uniformidade dos próprios sistemas de produção.

Como minimizar riscos de pessoas com informações privilegiadas no Google

Como uma empresa em que a segurança é uma prioridade, adotamos medidas para limitar o risco de pessoas com informações privilegiadas – a possibilidade de colaboradores do Google (ou de qualquer outra pessoa na organização) usarem conhecimento ou acesso organizacional para realizar atos maliciosos. O risco de pessoas com informações privilegiadas também abrange a situação em que um invasor compromete as credenciais de alguém no Google para facilitar o ataque. Investimos bastante em inovação na área de proteção contra o risco de pessoas com informações privilegiadas. No Google, é fundamental proteger os dados dos usuários, e nos esforçamos para fazer isso de maneira completa. Nosso objetivo é impedir que um funcionário do Google acesse dados do usuário sem autorização.

Autorização para acesso aos dados do usuário

No Google, há momentos em que serviços e funcionários precisam acessar os dados do usuário. Interagimos com os dados do usuário das seguintes maneiras:

  1. Como usuário final: ao usar um serviço, um funcionário se autentica diretamente e recebe seus próprios dados. Por exemplo, um funcionário que fizer login na conta do Gmail verá os próprios e-mails.
  2. Como parte do papel deles: a maior parte do trabalho realizado pela equipe do Google pode ser concluída usando dados anônimos de usuários. No entanto, em casos raros, nossa equipe precisa de acesso aos dados do usuário como parte do trabalho, por exemplo, em suporte ou depuração. Nosso objetivo é fornecer o máximo de transparência possível sobre os acessos a dados do usuário. Uma maneira de fazer isso é com Transparência no acesso – um recurso que permite aos clientes do Google Cloud ver os acessos qualificados dos dados por meio de registros em tempo real.
  3. Como parte de um serviço, de maneira programática: para realizar uma tarefa, um serviço pode precisar acessar os dados do usuário programaticamente em grande escala. Por exemplo, um pipeline consultará milhares de dados de usuários ao mesmo tempo para gerar estatísticas de uso agregadas. Nesses casos, o acesso é concedido para um conjunto de dados em vez de para os dados de um usuário individual. Não se registra o acesso aos dados de cada usuário.

O foco deste whitepaper é o modelo de ameaças do terceiro cenário. Queremos ter certeza de que os administradores que executam os sistemas de acesso aos dados dos usuários não podem abusar dos próprios poderes.

Modelo de ameaça

Os controles discutidos neste artigo foram criados para proteger os dados do usuário, impedindo o acesso unilateral. Queremos impedir que os funcionários do Google, atuando sozinhos, acessem direta ou indiretamente ou comprometam os dados do usuário sem a devida autorização e justificativa. Nossos controles impedem essas ações, não importando se o agente está mal-intencionado, se a conta foi comprometida ou uma autorização concedida sem querer.

Infraestrutura em contêiner do Google

Nossa infraestrutura é em contêiner, usando um sistema de gerenciamento de cluster chamado Borg (em inglês). 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.

Além disso, ao usar contêineres, recebemos ótimos benefícios de segurança. Os contêineres precisam ser usados de forma imutável, com reimplantações frequentes de uma reconstrução completa da imagem. Com essa propriedade, é possível analisar uma mudança de código no contexto e fornecer um único ponto de estrangulamento para todas as alterações implantadas na infraestrutura.

Para entender como desenvolvemos uma solução que limita o acesso programático aos dados do usuário por um serviço, é importante compreender primeiro como um serviço é produzido no Google.

Passo 1: análise do código

Nosso código-fonte é armazenado em um repositório central monolítico (em inglês) que permite a verificação do código em um único local por milhares de funcionários. Usar uma única base do código simplifica o gerenciamento do código-fonte, especialmente as dependências de código de terceiros. 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 Google, as análises de código incluem inspeção e aprovação de, pelo menos, um engenheiro que não seja o autor. O processo de análise de código impõe uma regra que, no mínimo, as modificações no código de qualquer sistema precisam ser aprovadas pelos proprietários desse sistema. Depois de ser carregado, o código é criado.

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

Passo 2: compilações verificáveis

Usamos um sistema de compilação muito semelhante ao Bazel (em inglês), que cria e compila o código-fonte, criando um binário para a implantação. Nosso sistema de compilação é executado em um ambiente isolado e bloqueado, separado dos funcionários que executam as versões. Para cada compilação, o sistema produz um manifesto de compilação verificável – um certificado assinado descrevendo completamente as fontes inseridas, os hashes criptográficos de binários ou outros artefatos, além dos parâmetros completos da compilação. Esse manifesto permite rastrear um binário para o código-fonte usado na criação e, por extensão, para o processo de criação e envio do código-fonte descrito. Além disso, o manifesto permite verificar se o binário não foi modificado, já que quaisquer alterações no arquivo invalidariam sua assinatura automaticamente.

Como as ações de compilação podem, em teoria, 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 uma compilação influencie outras. O sistema impede que as compilações façam alterações que possam comprometer a integridade dos manifestos de compilação verificável ou do próprio sistema. Quando a compilação estiver concluída, a mudança será implantada usando o Borg.

Passo 3: jobs de implantação

Uma vez criado, um binário pode ser implantado em nossa infraestrutura em contêineres como um job do Borg. Esses jobs usam pacotes que podem conter binários ou dados. A instalação deles é gerenciada pelo Borg. Uma configuração de Borg especifica os requisitos para o job a ser implantado: os pacotes, os parâmetros de ambiente de execução, os argumentos e as sinalizações. O Borg programa o job levando em conta as restrições, a prioridade, a cota e quaisquer outros requisitos listados na configuração. Depois de implantado, o job do Borg pode interagir com outros jobs em produção.

Passo 4: identidade do job

Um job do Borg é executado como uma identidade que é usada para acessar armazenamentos de dados ou métodos de chamada de procedimento remoto (RPC, na sigla em inglês) de outros serviços. Uma identidade pode ser uma conta de papel (como um serviço) ou uma conta de usuário (como a conta individual de um funcionário). É possível executar vários jobs como a mesma identidade. Restringimos a capacidade de implantar ou modificar jobs com uma identidade específica para os responsáveis pela execução do serviço, geralmente nossos engenheiros de confiabilidade do site (SREs, na sigla em inglês) [link em inglês].

Ao iniciar um job, o Borg o provisiona com credenciais criptográficas. Esse job usa essas credenciais para provar sua identidade ao fazer solicitações de outros serviços, usando o Application Layer Transport Security. Para que um serviço acesse determinados dados ou outro serviço, sua identidade precisa ter as permissões necessárias. Veja o exemplo de um serviço como a API Cloud Data Loss Prevention (DLP) do Google Cloud. Para que a API DLP acesse dados para verificação, ela precisa de duas coisas. Primeiro, ela precisa ser configurada para ser executada com uma identidade distinta, neste caso, uma conta de papel. Segundo, as permissões nos dados que a API DLP está verificando precisam incluir essa conta de papel. Sem uma identidade válida e com as permissões corretas, o serviço não poderá realizar a verificação.

Nossas políticas exigem que qualquer conta de papel com acesso aos dados do usuário ou quaisquer outras informações confidenciais seja rigorosamente controlada pela BAB e por outros sistemas de segurança. Os jobs de controle de qualidade e de desenvolvimento sem acesso a dados ou recursos confidenciais podem ser executadas com menos controles.

Juntando tudo: a vida de um job

Em resumo, as etapas para executar um job em nossa infraestrutura são as seguintes:

  1. Um desenvolvedor do Google faz uma alteração no código. Em seguida, ele o envia a um ou mais engenheiros do Google para análise. Ela inclui verificações de autorização e de geração de registros. Depois de aprovado, o código é carregado.
  2. Acionado pelo desenvolvedor, o sistema de compilação cria e empacota os binários de maneira verificável em um ambiente de sandbox. Essa operação de compilação produz um pacote que o sistema assina para verificação.
  3. O job é implantado no Borg por um engenheiro com autorização específica para gerenciar jobs executados com a identidade segura adequada.
  4. Quando um job do Borg tenta acessar recursos privilegiados, como dados do usuário, a identidade do job é verificada para autorização.

Agora que você sabe como os jobs são executados no ambiente de produção, vamos examinar o modelo de ameaça que a BAB aborda, impedindo que uma pessoa com informações privilegiadas e más intenções execute um job não autorizado. Para isso, a BAB confere se todas as verificações de segurança necessárias ocorreram antes da implantação de um binário.

Nesta seção, você teve uma visão geral da infraestrutura em contêiner. Uma compreensão básica do ambiente de produção é um pré-requisito necessário para você entender os controles que temos disponíveis para o acesso de usuários programáticos aos dados. Você verá esses controles mais detalhadamente na próxima seção.

Autorização binária para Borg (BAB, na sigla em inglês)

Durante vários anos, nos esforçamos muito para impedir que os dados dos usuários fossem acessados manualmente. Esses esforços incluem limitar o acesso aos dados e ao gerenciamento de jobs para o conjunto de funcionários do Google que precisa dessas informações para trabalhar.

A missão da BAB é garantir que todos os software e configurações de produção implantados no Google sejam devidamente analisados e autorizados, em especial se for possível acessar dados do usuário com esse código. Para cumprir sua missão, a BAB fornece um serviço de aplicação no momento de implantação para impedir que jobs não autorizados sejam iniciados, bem como uma trilha de auditoria do código e da configuração usados em jobs ativados pela BAB.

Verificação

A BAB verifica se os binários atendem a determinados requisitos ao serem implantados. Por exemplo, um proprietário de serviço pode exigir que o binário do serviço seja criado a partir de um código analisado, carregado, testado e autorizado. Nós nos referimos a esses tipos de verificações como verificações no momento da implantação. A BAB também pode executar verificações depois da implantação de um binário, elas são chamadas de verificações pós-implantação. Para mais informações sobre essas verificações pós-implantação, consulte a seção modos de aplicação.

Uma mudança de código cria um novo binário. Para que as alterações no novo binário entrem em vigor, ele precisa ser implantado. A BAB permite vários tipos de verificações no momento da implantação. Alguns exemplos dessas verificações incluem os seguintes:

  • O binário foi criado a partir do código carregado?

    O código foi enviado e carregado no repositório de código-fonte do Google? Para que o código seja enviado, ele geralmente precisa ser analisado por um segundo engenheiro do Google.

  • O binário foi construído de forma verificável?

    Esse binário pode ser rastreado até fontes auditáveis e foi criado por um sistema de compilação aprovado?

  • O binário foi criado a partir do código testado?

    O binário atende aos requisitos de teste?

  • O binário foi criado a partir do código para ser usado na implantação?

    O código foi enviado para a área apropriada do repositório de código-fonte correspondente ao projeto ou à respectiva equipe para esse job específico do Borg?

Embora sejam específicos para nosso ambiente de produção, requisitos semelhantes podem ser aplicados nos ambientes de integração contínua/implantação contínua (CI/CD, na sigla em inglês) com base nos seus próprios requisitos de segurança, conformidade ou confiabilidade.

Política específica do serviço

Os jobs que acessam dados confidenciais costumam exigir que o código seja enviado, com algumas exceções por motivos comerciais válidos. Os dados confidenciais incluem dados do usuário, dados financeiros e de emprego e qualquer outro dado reservado ou da empresa. Todos os jobs no Google são obrigados a ter uma política. Mesmo um job do Borg que não precisa de acesso aos dados do usuário terá uma política definida, mas nenhum requisito específico listado.

Quando os proprietários de serviços integram a BAB, eles definem uma política com os requisitos de segurança para esses serviços. Todas as contas de papel usadas para implementar esse serviço precisam especificar uma política da BAB. Para cada conta de papel, a política da BAB define os jobs a serem lançados e os requisitos de configuração e código desse job. Definir ou mudar uma política é uma alteração de código que precisa ser analisada.

Os requisitos que podem ser aplicados em uma política da BAB incluem os seguintes:

  • O código é criado de forma verificável: é possível conferir o código criado de modo verificável, mas isso não significa que ele foi submetido a uma análise de código. Há casos em que o código não foi enviado. O código usado em compilações verificáveis é auditável por, pelo menos, 18 meses, mesmo que não seja enviado.

  • O código é enviado: o código é criado a partir de um local determinado e especificado no repositório de origem. Isso geralmente significa que ele passou por uma análise de código.

  • Configurações são enviadas: qualquer configuração fornecida durante a implantação passa pelo mesmo processo de análise e envio que o código normal. Consequentemente, os valores, argumentos e parâmetros de sinalização da linha de comando não podem ser modificados sem análise.

Os sistemas e componentes que impõem a BAB precisam ser rigidamente controlados. Isso é alcançado por meio da implementação dos requisitos mais rigorosos possíveis, além de outros controles manuais.

Modos de aplicação

A BAB realiza ações diferentes com base na política especificada pelo job do Borg. Chamamos essas ações de modos de aplicação e existem três tipos: aplicação no momento da implantação, auditoria no momento da implantação e verificação contínua. Ao definir uma política, o proprietário do serviço precisa escolher a aplicação ou a auditoria no momento da implantação. O modo de verificação contínua é ativado por padrão. Você verá cada modo mais detalhadamente nas próximas seções.

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

Quando um novo job é enviado, o Borgmaster2 consulta a BAB para verificar se ele atende aos requisitos necessários, conforme estabelecido na Política da BAB. Essa verificação atua como um controlador de admissão. Se os requisitos forem atendidos, então o Borgmaster iniciará o job. Caso contrário, ele rejeitará a solicitação mesmo se o usuário que a fez for autorizado de outra maneira.

No modo de aplicação, a BAB bloqueará a implantação de um job do Borg se ele não atender aos requisitos estabelecidos na política da BAB para o job do Borg. Os serviços novos para a BAB normalmente começam no modo de auditoria (descrito na próxima seção) e passam para o modo de aplicação.

Procedimentos de resposta a emergências

No caso de incidente ou interrupção, a prioridade é restaurar o serviço afetado o mais rápido possível. Em uma situação de emergência, pode ser necessário executar um código não revisado ou carregado. Como resultado, o modo de aplicação pode ser modificado usando uma sinalização de resposta a emergências. Procedimentos de resposta a emergências também atuam como um backup caso haja uma falha da BAB que, de outra forma, bloquearia uma implantação. Um desenvolvedor que implantar um job usando o procedimento de resposta a emergências precisa enviar uma justificativa como parte da solicitação.

Poucos segundos após esse procedimento ser usado, a BAB registra detalhes sobre o job associado do Borg. O registro inclui o código usado e a justificativa fornecida pelo usuário. Alguns segundos depois, uma trilha de auditoria é enviada para nossa equipe de segurança centralizada. Em poucas horas, a trilha de auditoria é enviada para a equipe com a conta de papel. Os procedimentos de resposta a emergências são usados apenas como último recurso.

Modo de auditoria no momento da implantação

No modo de auditoria, a BAB registra quando um job do Borg não atende aos requisitos da política, mas não bloqueia a implantação. Essa violação de política aciona um alerta para a equipe com a conta de papel.

No Google, exigimos que determinados serviços, como os que acessam dados do usuário, usem o modo de aplicação. Recomendamos que todos os proprietários de serviços usem o modo de aplicação. O modo de auditoria é utilizado apenas ao integrar um novo serviço. Para usar o modo de auditoria, os proprietários de serviços precisam fornecer uma justificativa para receber uma exceção. Por exemplo, um serviço com a confiabilidade do objetivo de nível de serviço (SLO, na sigla em inglês) significativamente maior do que a BAB fornece usaria o modo de auditoria.

Embora seja útil ao ajustar uma política inicial, ele não é um estado estável prático para a maioria dos serviços. Ao usar o modo de auditoria, o proprietário do serviço não é notificado sobre violações da política até várias horas após a ocorrência da violação. Isso pode gerar um ruído no fluxo de notificações, escondendo problemas reais de segurança por causa de erros ou configurações incorretas da política introduzidas pelo proprietário do serviço. Com o modo de aplicação, o proprietário do serviço recebe um feedback imediato ao tentar iniciar um job que não adere à política. Como resultado, o fluxo de notificações é muito mais limpo. Além disso, o modo de aplicação na BAB detecta erros involuntários, como iniciar acidentalmente um job em um papel diferente do designado.

Verificação contínua

Depois que um job é implantado, independentemente de sua aplicação no momento da implantação, ele é verificado continuamente durante todo o ciclo de vida. 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 busca constantemente jobs em execução com políticas desatualizadas ou com uma identidade implantada usando procedimentos de resposta a emergências. Se for encontrado um job que não esteja de acordo com a política atualizada, a BAB notificará os proprietários do serviço para que eles possam reduzir o risco.

Pacotes globalmente permitidos

No Google, existem alguns pacotes amplamente utilizados por muitos de nossos serviços. Em vez de forçar cada serviço a manter sua própria versão, eles são permitidos centralmente. Nós os chamamos de pacotes globalmente gerenciados. Ao criar a política da BAB, um proprietário de serviço pode especificar um pacote globalmente permitido para um determinado job. Há também um mecanismo padrão global para pacotes muito utilizados. Assim, eles não precisam ser listados individualmente como parte da política de cada serviço. Isso permite que o Google mantenha controle explícito dos componentes comuns do sistema usados em toda a organização e garante que eles sejam devidamente analisados e atualizados sem envolver equipes individuais. Embora um proprietário de serviço individual possa permitir esses pacotes explicitamente como parte da política da BAB do serviço, isso facilita o uso do caminho recomendado e suportado.

Casos extremos

O Google implementa controles de segurança rígidos para o código implantado na produção, incluindo análises de código e compilações verificáveis. A BAB funciona como um ponto de controle e de aplicação extra para garantir que esses controles de segurança sejam, de fato, implementados de maneira adequada.

No entanto, ela não pode ser usada efetivamente em todos os casos. A BAB não oferece suporte aos seguintes casos extremos: código criado usando sistemas de compilação não padrão, código implantado em ambientes diferentes do Borg e análise de dados e código de machine learning, o que não é compatível com análises de código manuais antes da escolha dos parâmetros finais de produção. Nesses casos, existem várias outras mitigações de segurança, incluindo outros sistemas de procedência de código. No entanto, esse código ainda está sujeito aos controles gerais de segurança do Google.

Como implementar a autorização binária para Borg

Para implementar a BAB, a equipe dela desenvolveu vários recursos novos, incluindo procedimentos de resposta a emergências e o modo de auditoria. Essas ferramentas facilitaram ao máximo que os proprietários de serviço testassem a BAB. Se você estiver pensando em implantar a BAB ou algo parecido em sua organização, talvez seja necessário trabalhar mais para facilitar essa transição. Nesta seção, você verá o trabalho de gestão organizacional e de mudança que fizemos como parte do plano de implementação.

Vantagens

A BAB tem três vantagens que ajudaram a desenvolver o caso de negócios para desenvolvimento e adoção no Google. São elas: redução do risco de pessoas com informações privilegiadas, identidade de código avançada e conformidade simplificada.

Risco reduzido de pessoas com informações privilegiadas

A BAB foi desenvolvida principalmente para impedir que qualquer indivíduo consiga acesso programático não autorizado aos dados do usuário. Ela dificulta o trabalho de um único engenheiro ou de um invasor que consegue as credenciais de um engenheiro para acessar dados confidenciais de maneira inadequada e sem detecção.

Identidade de código avançada

Conforme descrito na seção infraestrutura em contêineres, os jobs do Borg são executados como uma identidade, normalmente uma conta de papel. Essa identidade é usada por outros serviços para verificar a autorização adequada antes de conceder acesso a quaisquer dados. No entanto, outros serviços não podem impor o uso desses dados. Por isso, precisam confiar que a identidade do job não está abusando dos dados recebidos. A BAB vincula a identidade de um job a um código específico, garantindo que somente esse código possa ser usado para exercer os privilégios da identidade desse job. Isso permite uma transição da identidade do job, que confia temporariamente em uma identidade e em qualquer um dos usuários humanos privilegiados, para uma identidade do código, que confia em uma parte específica do código que foi analisada para ter uma semântica própria e não pode ser modificada sem processos de aprovação.

Conformidade simplificada

A BAB simplificou as tarefas que, antes, eram executadas manualmente. 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. Depois dela, muitas dessas verificações foram automatizadas com base nas Políticas da BAB de 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.

Como integrar um serviço

A equipe da BAB precisou garantir que o processo de integração fosse simples e direto. Inicialmente, os proprietários de serviço no Google tinham duas preocupações principais sobre a adoção da BAB:

  • Se a BAB não fosse suficientemente confiável, sua implementação poderia bloquear mudanças em situações críticas.
  • A BAB pode retardar o desenvolvimento de um serviço com verificações de código frequentes e processos iterativos.

Para abordar essas preocupações iniciais, a equipe da BAB desenvolveu o modo de auditoria. Ao usar esse modo, a equipe conseguiu provar para alguns dos principais usuários iniciais que a BAB funcionou. Para reforçar ainda mais sua confiabilidade, a equipe desenvolveu um SLO de disponibilidade e introduziu procedimentos de resposta a emergências para o modo de aplicação.

Ao integrar um serviço atual à BAB, o proprietário normalmente ativa o modo somente auditoria. Isso o ajuda a identificar e resolver problemas antes de ativar o modo de aplicação. A política padrão para qualquer job que use a BAB na produção é o modo de aplicação. Para implantar o job, o proprietário do serviço precisa enviar uma política que, no mínimo, exija que o código seja enviado e criado de forma verificável. Um proprietário de serviço pode implantar o job sem atender a esse padrão mínimo, mas precisa receber uma exceção. Se o serviço precisar de acesso a dados e/ou serviços mais confidenciais, o proprietário poderá usar requisitos mais rigorosos. Definir uma política inicial pode ser difícil, por isso a equipe da BAB criou ferramentas automatizadas para ajudar os proprietários de serviços a desenvolverem suas políticas. As ferramentas analisam quais partes do repositório de origem são usadas para um job atual e sugerem uma política adequada.

Ao integrar um novo serviço à BAB, o proprietário ativa o modo de aplicação desde o início. O proprietário do serviço elabora uma política inicial e rapidamente itera para adicionar outros requisitos. As próprias políticas são gerenciadas como mudanças de código e, assim, exigem que um segundo engenheiro do Google analise as atualizações.

Impacto

A adoção da BAB e de um modelo de implantação em contêiner oferece muitos benefícios ao Google em termos de segurança e suporte:

  • A BAB ajuda a reduzir o risco de pessoas com informações privilegiadas: ela exige que o código atenda a determinados padrões e práticas de gestão da mudança antes de acessar os dados do usuário. Assim, a possibilidade de um funcionário do Google (ou alguém que tenha conseguido as informações da conta dele) acessar dados do usuário de maneira programática diminui.
  • A BAB oferece suporte à uniformidade dos sistemas de produção: ao usar sistemas em contêineres e verificar os requisitos da BAB antes da implantação, nossos sistemas são mais fáceis de depurar, mais confiáveis e têm uma gestão da mudança mais clara. 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 em nossos sistemas. Os dados sobre essa conformidade são publicados internamente e podem ser consultados por outras equipes. Assim, a publicação de dados da BAB permite que as equipes usem termos comuns ao se comunicarem sobre a proteção de dados. Essa linguagem comum reduz o trabalho necessário ao lidar com dados entre equipes.
  • A BAB permite o rastreamento programático dos requisitos de conformidade: certos processos, como os de geração de relatórios financeiros, precisam atender a determinados requisitos de gestão da mudança para conformidade. Usando a BAB, essas verificações podem ser automatizadas, economizando tempo e aumentando o escopo da cobertura.

A BAB é uma das várias tecnologias usadas no Google para reduzir riscos de pessoas com informações privilegiadas.

Como adotar controles semelhantes na sua organização

Aprendemos muitas lições importantes ao implementar a BAB no Google. Fazer uma mudança tão grande pode parecer assustador. Nesta seção, você verá as lições que aprendemos ao longo do caminho, na esperança de que possa aplicar os princípios da BAB à sua organização.

Tenha um pipeline de CI/CD em contêineres mais homogêneo.

A adoção da BAB no Google foi possível graças à consistência e à integração das ferramentas que usamos no desenvolvimento do código. Esse trabalho incluiu análises de código, compilações verificáveis, implantações em contêiner e identidade baseada em serviço para controle de acesso. As compilações verificáveis permitem que você confira como os binários são criados. Os contêineres permitem que você separe os binários dos dados e fornecem um ponto de estrangulamento de aplicação para garantir o atendimento aos requisitos de uso. Essa abordagem simplificou a adoção da BAB e fortaleceu as garantias que essa solução pode oferecer.

A introdução de microsserviços permitiu a adoção de identidade baseada em serviço (como uma conta de serviço), em vez de identidade baseada em host (como um endereço IP). Ao fazer a mudança para uma identidade baseada em serviço, será possível alterar a maneira de gerenciamento da autenticação e da autorização entre os serviços. Por exemplo, se você estiver usando um token de identidade preparado em uma imagem de contêiner para atestar a identidade, as garantias fornecidas pela procedência do código não serão tão fortes. Se você não conseguir adotar diretamente uma identidade de serviço, tente proteger melhor os tokens de identidade como uma etapa provisória.

Determine metas e defina 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 grande motivador para um processo de liberação 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.

Aplique 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á. É por isso que a aplicação da política da BAB é feita quando o código é implantado e quando ele acessa os dados, e não quando eles são criados. Uma política da BAB é definida em termos de identidade de ambiente de execução, de modo que o mesmo código pode ser executado em diferentes ambientes e estar sujeito a políticas diferentes.

Usamos a BAB, além de outros mecanismos de acesso, para limitar o acesso aos dados do usuário. Dessa maneira, os proprietários de serviço podem garantir o acesso aos dados apenas por um job que atenda a requisitos específicos da BAB, realmente tratando o código como identidade.

Determine como incorporar proprietários de serviços atuais.

Identifique alguns proprietários de serviços que receberão benefícios imediatos da aplicação e que estejam dispostos a fornecer feedback. Uma maneira de fazer isso é pedir aos proprietários que se voluntariem antes de tornar qualquer alteração obrigatória.

Se possível, exija o modo de aplicação em vez do modo de auditoria, ou limite o período de carência para o modo de auditoria. Com o modo de auditoria, os proprietários podem se integrar rapidamente e entender melhor o risco de pessoas com informações privilegiadas. A desvantagem do modo de auditoria é que pode levar tempo para perceber uma redução no risco de pessoas com informações privilegiadas. Esse atraso pode dificultar a exibição de valor e convencer outras pessoas a adotar a aplicação. Quando a equipe da BAB forneceu procedimentos de resposta a emergências para a aplicação, os proprietários de serviços estavam mais dispostos a adotar a aplicação, oferecendo uma saída de emergência se necessário.

Inscreva agentes de mudança entre as equipes.

Quando criamos uma autorização para implantação da BAB em todo o Google, o que mais afetou nossa taxa de sucesso foi encontrar os proprietários para impulsionar a mudança em cada grupo de produtos. 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.

Descubra como gerenciar código de terceiros.

Muitos dos controles de CI/CD descritos neste artigo estão no lugar em que seu código é desenvolvido, analisado e mantido por uma organização. Se você estiver nessa situação, pense em como incluir o código de terceiros como parte dos requisitos da política. Por exemplo, a princípio, é possível isentar o código enquanto você caminha para um estado ideal de manter um repositório de todos os códigos de terceiros usados e verificar regularmente esse código em relação aos requisitos de segurança.

Conclusão

Com a implementação da verificação de aplicação no momento da implantação como parte da infraestrutura em contêiner do Google e do processo de CI/CD, pudemos verificar se o código e a configuração implementados atendiam a determinados padrões mínimos de segurança. Esse é um controle crítico usado para limitar a capacidade de uma pessoa com informações privilegiadas e possíveis más intenções de executar um job não autorizado com acesso aos dados do usuário. A adoção da BAB permitiu que o Google reduzisse o risco de pessoas com informações privilegiadas, evitasse possíveis ataques e também suportasse a uniformidade dos sistemas de produção.

Outras referências

Para mais informações sobre a segurança geral e a infraestrutura em contêiner do Google, confira estes recursos:

Observações

1 A procedência descreve os componentes, as mudanças feitas nos componentes e a origem deles. Veja https://csrc.nist.gov/glossary/term/Provenance (em inglês).

2 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.