Este conteúdo foi atualizado pela última vez em junho de 2024 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.
O Google executa uma infraestrutura de computação distribuída, com vários locatários e em escala global para fornecer produtos e serviços a bilhões de pessoas em todo o mundo. Essa infraestrutura precisa equilibrar as prioridades concorrentes de segurança, confiabilidade, resiliência, eficiência, velocidade de desenvolvimento, capacidade de depuração e mais.
Este documento descreve alguns dos mecanismos que usamos para manter uma postura de segurança líder do setor para serviços executados no ambiente de produção do Google. Esses serviços ocupam todo o espectro de sensibilidade de segurança, desde tecnologias experimentais de desenvolvimento que não têm acesso a dados sensíveis até infraestruturas de identidades críticas. Esses serviços realizam tarefas como processamento de dados do usuário, gerenciamento de lançamentos de software e provisionamento e gerenciamento do ciclo de vida de máquinas físicas individuais.
Este documento descreve os controles de segurança que ajudam a proteger as três camadas principais da nossa infraestrutura:
- Serviços de produção: incluem os serviços mais críticos para a segurança, também conhecidos como serviços básicos.
- Máquinas de produção
- Cargas de trabalho de produção
Aplicamos esses controles para que a equipe do Google só possa acessar serviços, máquinas e cargas de trabalho para fins comerciais legítimos (por exemplo, acesso de manutenção) e para se defender contra riscos internos e comprometimento de contas da equipe. Esses controles fornecem uma proteção adicional de defesa em profundidade que complementa os controles de segurança da infraestrutura atuais que ajudam a evitar o comprometimento de contas.
Melhoria contínua
Os controles descritos neste documento são usados em todo o ambiente de produção do Google. Muitos serviços, incluindo os serviços básicos, usam os níveis mais recentes de controles que oferecemos. No entanto, devido ao escopo e à complexidade da infraestrutura do Google, os serviços de produção individuais costumam ter requisitos exclusivos e exigir mais tempo para implementar as recomendações mais recentes. Graças a uma cultura de melhoria contínua, a engenharia de confiabilidade do site (SRE, na sigla em inglês) e as equipes de segurança do Google adaptam constantemente os controles de segurança para atender ao cenário de ameaças em constante mudança.
Como proteger os serviços de produção
O Google ajuda a proteger a integridade dos serviços de produção para que sua equipe só possa acessar os serviços para fins comerciais legítimos, como manutenção. Há duas maneiras principais de ter acesso aos serviços em execução no ambiente de produção: por acesso administrativo e pela cadeia de suprimentos de software.
A lista a seguir descreve os controles que ajudam a proteger cada caminho de acesso.
Controles de acesso administrativo: os serviços de produção precisam de manutenção regular (por exemplo, lançamentos de configuração ou binários). No Google, nosso objetivo é que essas operações sejam feitas por automação, proxies seguros ou acesso emergencial auditado, seguindo a filosofia de produção de contato zero. O pacote de controles que remove o acesso humano aos recursos de produção é chamado de Nenhuma pessoa (NoPe, na sigla em inglês). O NoPe oferece ao Google a flexibilidade de implantar controles de acesso baseados na sensibilidade de um serviço de produção e na prontidão dele para alcançar uma postura ainda mais forte com melhoria contínua.
Por exemplo, o Google não permite o acesso unilateral a serviços básicos. Até mesmo o acesso de emergência requer a aprovação de outra equipe do Google. Um acesso é unilateral quando alguém pode realizá-lo sem a aprovação de outra pessoa autorizada.
Controles da cadeia de suprimentos de software: a maioria das cargas de trabalho de produção no Google, incluindo serviços básicos, executa binários e configurações de job que são criados de forma verificável com base em código revisado por pares e localizado em uma fonte confiável. Aplicamos esse processo usando a autorização binária para o Borg (BAB, na sigla em inglês).
O diagrama a seguir mostra os controles que ajudam a proteger um serviço de produção.
Quando aplicamos os níveis mais altos de NoPe e BAB, ajudamos a garantir que nenhum funcionário tenha acesso unilateral a serviços básicos, mesmo em emergências, e que qualquer acesso privilegiado recebido tenha uma duração e um escopo bem definido. O acesso privilegiado é um nível elevado de acesso concedido pessoal para administrar serviços de produção essenciais durante circunstâncias únicas que não são tratadas pela automação. Fazemos uma exceção a essa regra para garantir que o Google consiga evitar situações de bloqueio.
Muitos outros serviços de produção, incluindo produtos como o Filestore ou Cloud SQL e produtos de infraestrutura interna, como o Borg e o Spanner, são configurados para usarem os níveis mais altos de NoPe e BAB, e trabalhamos continuamente para facilitar a adoção gradual de NoPe e BAB por parte dos proprietários de serviços de produção.
Controles de acesso administrativo
No Borg, os membros com o papel de produção podem ler, gravar ou excluir os dados do papel de produção e executar o código usando a autoridade do papel. Um papel de produção é uma identidade que pode executar cargas de trabalho no ambiente de produção do Google.
A associação permanente em papéis de produção apresenta o risco de consequências não intencionais para a produção e de que esses privilégios possam ser usados indevidamente. No entanto, a missão da SRE é capacitar as equipes para que consigam manter os serviços pelos quais são responsáveis. Portanto, a remoção completa do acesso pode não ser uma estratégia viável.
O pacote NoPe oferece uma maneira de configurar o acesso que equilibra as demandas contínuas de capacitar equipes e manter os sistemas de produção seguros. Com o NoPe, os funcionários do Google encontram restrições nos privilégios das contas quando tentam acessar os serviços de produção. O NoPe permite as seguintes restrições:
- As solicitações de acesso exigem um aprovador e uma justificativa: um controle chamado de autorização de várias partes (MPA, na sigla em inglês) ajuda a garantir que a equipe do Google não possa ter acesso aos serviços de produção sem uma justificativa comercial e a aprovação de outro indivíduo que esteja autorizado a verificar a solicitação de acesso.
- Sem acesso direto aos papéis de serviço de produção: a equipe só pode acessar os serviços de produção por proxies seguros do NoPe. Os proxies seguros são projetados para que apenas um conjunto bem definido de comandos possa ser executado. Todos os comandos que as organizações de segurança e SRE do Google consideram arriscados (por exemplo, desativar um serviço ou acessar ou excluir dados) também exigem MPA.
- Sem associação permanente do papel de produção: um controle chamado acesso por demanda (AoD, na sigla em inglês) exige que a equipe solicite a associação temporária em vez de permitir que as contas de equipe sempre tenham privilégios de acesso. Esse controle ajuda a garantir que poderes elevados sejam concedidos apenas temporariamente e por motivos específicos.
- Monitoramento de solicitações de acesso da equipe aos serviços de produção: o Google exige uma auditoria periódica dos padrões de acesso aos papéis de produção que executam um serviço de produção. O objetivo da auditoria é eliminar a necessidade dessas solicitações no futuro, com a melhoria contínua das APIs administrativas. O acesso aos serviços de produção deve ser reservado apenas para situações de resposta a emergências. Para serviços básicos, o número de situações em que o acesso é concedido é tão baixo que uma equipe de segurança realiza uma auditoria de cada acesso concedido para confirmar a validade dele.
As próximas seções discutem cada controle em detalhes.
Autorização de várias partes do NoPe
A MPA exige que outra equipe autorizada do Google aprove uma solicitação de acesso.
Para solicitações de acesso a serviços suficientemente sensíveis, a MPA também exige que a equipe forneça uma justificativa comercial referente a uma emergência de produção em andamento com cada solicitação.
Essas duas condições são barreiras contra o abuso de acesso.
Proxies seguros do NoPe
Os proxies seguros são ferramentas que expõem um conjunto predefinido de comandos que esses proxies podem executar em nome do autor da chamada. Os proxies seguros implementam políticas de autorização refinadas e baseadas em regras para aplicar restrições ao acesso a serviços de produção. Essas políticas podem, por exemplo, exigir a aprovação de outro indivíduo autorizado para executar comandos que possam afetar negativamente a segurança ou a confiabilidade (por exemplo, comandos que excluem arquivos). As políticas também podem permitir que determinados comandos seguros (por exemplo, comandos que listam a utilização de recursos) sejam executados sem exigir aprovação. Essa flexibilidade é essencial para minimizar o trabalho operacional.
Em casos de abuso de acesso, as contas ainda ficam restritas às operações permitidas pelo proxy seguro. A conta só pode executar comandos seguros unilateralmente, enquanto as operações privilegiadas exigem a aprovação de outro indivíduo autorizado. Todas as operações deixam uma trilha de auditoria clara.
Para mais informações sobre proxies seguros, consulte a apresentação da SREcon sobre a produção de contato zero. A produção de contato zero é um conjunto de princípios e ferramentas que estabelece que toda mudança na produção seja realizada por automação (sem pessoas envolvidas), pré-validada por software ou feita usando um mecanismo de emergência auditado.
Acesso por demanda
O acesso por demanda (AoD) permite que o Google reduza os privilégios da equipe substituindo a associação permanente por uma associação qualificada.
Os membros qualificados de um papel não têm acesso aos respectivos privilégios. Em vez disso, se um membro do papel qualificado precisar de acesso, ele poderá solicitar uma associação temporária, conhecida como concessão de AoD. Se aprovada por outro indivíduo autorizado, uma concessão de AoD torna o solicitante um membro do papel por um período limitado, normalmente menos de um dia.
O modelo de associação qualificada permite que a equipe solicite apenas o subconjunto de acesso necessário durante o tempo necessário. Conceitualmente, pense na AoD como um sudo de produção com limite de tempo, semelhante ao comando sudo -u no Unix, que permite executar alguns comandos com as permissões elevadas que estão associadas a um usuário específico. No entanto, ao contrário do sudo do Unix, receber uma concessão de AoD requer uma justificativa comercial e uma MPA, além de deixar uma trilha de auditoria. As concessões de AoD também têm limite de tempo.
Proteger os privilégios sensíveis por trás das associações qualificadas significa que, mesmo em casos improváveis de abuso de acesso, as contas só poderão acessar esses privilégios quando houver uma concessão ativa. A adoção de proxies seguros elimina em grande parte a necessidade dessas concessões.
Monitoramento de solicitações de acesso
Embora muitas áreas de produção do Google usem o NoPe como uma prática de redução de acesso, as concessões de AoD são extremamente raras para nossos papéis de produção mais sensíveis e são reservadas apenas para resposta a emergências. Além disso, cada evento aciona uma auditoria manual após o fato. O objetivo da auditoria é diminuir a frequência de concessões de AoD no futuro, por exemplo, usando esses eventos para motivar melhorias nas APIs administrativas.
O Google monitora continuamente as concessões de AoD e as ações realizadas durante o período dessas concessões em toda a empresa. Usamos os dados de monitoramento em tempo real para detectar possíveis comprometimentos e identificar áreas para redução adicional do acesso. Em caso de incidente, a trilha de auditoria permite respostas rápidas.
Autorização binária para o Borg
Assim como o NoPe ajuda a proteger os caminhos de acesso privilegiados, a autorização binária para o Borg (BAB) ajuda a proteger a cadeia de suprimentos de software do Google. A BAB ajuda a garantir que as configurações de job e o software de produção sejam revisados e aprovados antes da implantação, principalmente quando podem acessar dados sensíveis. Originalmente desenvolvida para a infraestrutura de produção do Google, os principais conceitos da BAB agora estão incluídos em uma especificação aberta chamada Níveis da cadeia de suprimentos para artefatos de software (SLSA, na sigla em inglês).
A BAB ajuda a garantir que a equipe não possa modificar o código-fonte, executar binários ou configurar jobs sem revisão por pares e que qualquer artefato binário ou configuração de software seja criado de forma verificável a partir do código-fonte verificado e revisado por pares.
Para mais informações, consulte Autorização binária para o Borg.
Como proteger máquinas de produção
Além de aumentar a proteção dos caminhos de acesso privilegiados e manter a integridade da cadeia de suprimentos de software, o Google protege as máquinas em que os serviços de produção são executados. Especificamente, implementamos isto:
Controles de acesso via shell: a maioria das equipes do Google não tem acesso via shell (por exemplo, por SSH) a máquinas de produção ou a cargas de trabalho em execução no Borg, sistema de gerenciamento de clusters do Google. Em vez disso, os indivíduos precisam usar proxies seguros que exigem que outra pessoa autorizada revise e aprove cada comando antes que ele seja executado.
Apenas algumas equipes que trabalham em infraestrutura de nível inferior retêm acesso via shell não unilateral para depurar os problemas mais complexos quando não é viável usar proxies seguros. Um acesso é não unilateral quando requer autorização de uma ou mais pessoas autorizadas. O Google faz uma exceção em que o acesso via shell unilateral é permitido: garantir que o Google consiga evitar situações de bloqueio.
Controles de acesso físico: as máquinas precisam de manutenção física regular para manter o bom funcionamento. Para garantir que os técnicos do data center acessem máquinas físicas somente no contexto de um motivo comercial válido, o Google usa controles físicos–lógicos.
Controles de firmware e software de sistema: o Google implementa um fluxo de segurança de inicialização medida com base em uma raiz de confiança de hardware. A raiz de confiança de hardware ajuda a garantir a integridade do firmware de inicialização e do software de sistema de cada máquina.
O diagrama a seguir mostra os controles que ajudam a proteger uma máquina em um data center.
Controles de acesso via shell
O SSH é uma ferramenta administrativa de código aberto conhecida por permitir amplo acesso a servidores baseados no Linux. Sem controles sobre o acesso SSH, as contas com as credenciais corretas podem conseguir um shell que permite executar código arbitrário difícil de auditar.
Com o acesso via shell a um serviço de produção, a conta pode, por exemplo, alterar o comportamento de uma tarefa em execução, exfiltrar credenciais ou usar credenciais para conseguir uma presença permanente no ambiente.
Para reduzir esse risco, usamos o seguinte conjunto de controles que substitui o acesso SSH a máquinas de produção por métodos alternativos e seguros:
- APIs estritas: para equipes com fluxos de trabalho bem definidos que exigiam SSH, substituímos o SSH por APIs estritamente definidas e auditáveis.
- Proxies seguros para SSH: para equipes que exigem acesso mais flexível, os proxies seguros permitem que os comandos sejam autorizados e auditados individualmente.
- MPA: quando os SREs precisam de acesso SSH de emergência a uma máquina, o Google exige uma justificativa comercial e que um indivíduo autorizado aprove o acesso. As transcrições completas da sessão do shell são registradas.
- Cenários de bloqueio: a única exceção quando o acesso SSH unilateral é permitido. As transcrições completas da sessão do shell são registradas.
Esses controles equilibram a necessidade de acesso legítimo via shell em relação ao risco associado ao acesso excessivamente amplo via shell.
Histórico: SSH no Google
No passado, o Google usava SSH para administrar as máquinas. O desenvolvimento do Borg permitiu que a maioria das equipes do Google deixasse de exigir acesso direto às máquinas Linux que executavam os binários, mas o acesso via shell persistiu por vários motivos:
- Às vezes, os funcionários exigem acesso direto a uma máquina para fins de depuração.
- O acesso SSH é uma ferramenta de ensino valiosa para entender as várias camadas de abstração.
- Em cenários de recuperação de desastres imprevistos, ferramentas de nível mais alto podem não estar disponíveis.
Para equilibrar esses motivos e o risco à segurança que eles geram, o Google buscou uma série de marcos para eliminar gradualmente o risco e uso do SSH.
Monitoramento centralizado e marco de controle de acesso
O Google investiu em um sistema central de monitoramento e autorização SSH conhecido como autorização de monitoramento baseado em identidade do host (HIBA, na sigla em inglês). A HIBA fornece visibilidade sobre qualquer uso do SSH e permite a aplicação obrigatória de políticas de autorização rígidas. As tentativas de SSH são registradas não apenas pela máquina de destino, mas também pelo proxy centralizado do BeyondCorp. Os comandos executados pelo shell são registrados e alimentados em pipelines de detecção de comportamento malicioso. No entanto, a detecção é inerentemente reativa e vulnerável a evasão e ofuscação.
Como eliminar o marco de acesso unilateral
Para a maioria das equipes, o Google removeu o acesso via shell (por exemplo, por SSH) às máquinas de produção ou às cargas de trabalho em execução no Borg. No entanto, para as equipes de desenvolvimento, ele permanece acessível em máquinas de teste (por exemplo, máquinas usadas para qualificar novo hardware ou novo software de nível baixo, mas não executar serviços de produção).
APIs estritas
Algumas equipes do Google que historicamente dependiam do SSH para executar um número limitado de comandos definidos com precisão (por exemplo, em um playbook) ou para conseguir dados com estrutura previsível agora usam APIs definidas de maneira estrita que atendem ao caso de uso específico e fornecem dados estruturados.
As APIs estritas têm um pequeno número de métodos alinhados a jornadas comuns do usuário e abstraem detalhes de acesso de nível baixo. Por consequência, elas são a solução preferida do Google porque oferecem melhor segurança e auditabilidade. Ao criá-las na infraestrutura de chamada de procedimento remoto (RPC) do Google, nós nos beneficiamos de décadas de investimento em segurança e auditoria.
Proxies seguros do SSH
Algumas equipes do Google não conseguem determinar com antecedência os comandos que elas podem precisar. Nesse caso, o Google usa um daemon de execução de comando que só aceita solicitações de execução de comando arbitrário de um proxy confiável executado por uma equipe de segurança. Essa tecnologia é semelhante àquela usada em proxies seguros do NoPe.
Os proxies seguros do SSH são responsáveis pela autorização refinada da execução de comandos e pela auditoria. A autorização é baseada no argumento e ambiente do comando, nos parâmetros de limitação de taxa, nas justificativas comerciais e na MPA. Esse processo de autorização permite restrições arbitrariamente precisas sobre quais comandos podem ser executados seguindo os playbooks e as práticas recomendadas da equipe. Em condições de falhas inesperadas que não estão registradas nos playbooks atuais, a equipe ainda pode executar os comandos de depuração necessários depois que outro indivíduo autorizado aprová-los.
MPA do SSH
As poucas equipes que trabalham em infraestrutura de nível baixo mantêm uma forma não unilateral de acesso via shell para depurar os problemas mais complexos.
SSH em cenários de bloqueio
O Google faz uma exceção em que o acesso unilateral via shell é permitido para garantir que o Google possa resolver situações de bloqueio. As chaves SSH usadas para essa finalidade são geradas com um processo auditável distinto e armazenadas off-line em um hardware resistente a adulterações. Quando essas chaves são usadas, transcrições completas da sessão do shell são registradas.
Controles de acesso físico
Os data centers do Google são um ambiente complexo de servidores, dispositivos de rede e sistemas de controle que exigem uma ampla gama de papéis e habilidades para serem gerenciados, mantidos e operados.
O Google implementa seis camadas de controles físicos e muitos controles lógicos nas máquinas para ajudar a proteger as cargas de trabalho no data center. Também defendemos um espaço entre as máquinas, que chamamos de espaço físico–lógico.
Os controles físicos–lógicos fornecem camadas adicionais de defesa via controles chamados de aumento da proteção da máquina, controle de acesso baseado em tarefas e autodefesa do sistema. Os controles físicos–lógicos protegem contra invasores que buscam explorar o acesso físico a uma máquina e encaminhar um ataque lógico às cargas de trabalho da máquina.
Para mais informações, consulte Como o Google protege o espaço físico–lógico em um data center.
Controles de firmware e software do sistema
A postura de segurança de uma máquina de data center é estabelecida no momento da inicialização. O processo de inicialização configura o hardware da máquina e inicializa o sistema operacional dela, mantendo a máquina segura para ser executada no ambiente de produção do Google.
Em cada etapa do processo de inicialização, o Google implementa controles líderes do setor para ajudar a aplicar o estado de inicialização esperado e manter os dados do cliente seguros. Esses controles ajudam a garantir que nossas máquinas sejam inicializadas no software pretendido, permitindo a remoção de vulnerabilidades que possam comprometer a postura inicial de segurança da máquina.
Para mais informações, consulte Como o Google garante a integridade da inicialização em máquinas de produção.
Como proteger cargas de trabalho
De acordo com nossa filosofia de confiança zero, o Google também lançou controles que ajudam a proteger contra ameaças de movimentação lateral entre cargas de trabalho com diferentes requisitos de segurança. A infraestrutura do Google usa uma hierarquia de carga de trabalho chamada anéis de segurança da carga de trabalho (WSR, na sigla em inglês). O WSR ajuda a garantir que cargas de trabalho críticas não sejam programadas nas mesmas máquinas que cargas de trabalho menos seguras, evitando o impacto negativo na utilização de recursos. O WSR agrupa as cargas de trabalho em quatro classes de sensibilidade (fundamental, sensível, reforçada e não reforçada) e tenta programá-las em diferentes pools de máquinas.
O diagrama a seguir mostra como o WSR agrupa e programa cargas de trabalho em máquinas básicas de produção e de desenvolvimento.
A WSR fornece mais uma camada de defesa contra o escalonamento de privilégios locais usando ataques de vulnerabilidade do kernel ou ataques de canal lateral da CPU. A WSR ajuda a garantir que apenas cargas de trabalho com requisitos de segurança semelhantes sejam coprogramadas nas mesmas máquinas. Para implementar o WSR, fazemos isto:
- Classificamos as cargas de trabalho de acordo com os requisitos de segurança. Cada classe é conhecida como anel de carga de trabalho.
- Distribuímos máquinas físicas em vários pools de máquinas isolados uns dos outros. Em outras palavras, eliminamos os caminhos de movimentação lateral entre pools.
- Aplicamos restrições de programação para impedir que cargas de trabalho com requisitos de segurança diferentes sejam executadas na mesma máquina. Essas restrições de programação reduzem o risco de comprometimento via escalonamento de privilégios locais.
Por exemplo, o WSR exige que as cargas de trabalho fundamentais sejam executadas em máquinas dedicadas e nunca sejam coprogramadas com cargas de trabalho não fundamentais. Essa restrição faz um isolamento forte das cargas de trabalho menos seguras.
Métodos para isolar cargas de trabalho
Softwares de sistemas modernos são complexos, e pesquisadores de segurança descobrem periodicamente vulnerabilidades de escalonamento de privilégios locais, como exploits de dia zero do kernel ou novos ataques de canal lateral da CPU. O WSR, apresentado pela primeira vez na USENIX ;login:, permite que o Google reduza o risco associado à colocation de carga de trabalho, mantendo a alta utilização de recursos.
Por padrão, o Borg usa limites de processo no nível do SO para isolar contêineres. Esses processos oferecem um limite de isolamento mais fraco do que as máquinas virtuais que usam virtualização baseada em hardware. Esse isolamento mais fraco é normalmente uma boa compensação entre eficiência e segurança em ambientes multilocatários que executam cargas de trabalho confiáveis. Uma carga de trabalho confiável é uma carga de trabalho em que o binário e a configuração foram criados com base em um código de procedência atestado e revisado por pares. Cargas de trabalho confiáveis não processam dados arbitrários não confiáveis. Exemplos de processamento de dados não confiáveis incluem hospedagem de código de terceiros ou codificação de vídeos.
O Google confia nos nossos binários ao usar a BAB. No entanto, a BAB não é suficiente para garantir a integridade das cargas de trabalho que processam dados não confiáveis. Além da BAB, essas cargas de trabalho também precisam ser executadas em um sandbox. Um sandbox é um ambiente restrito, como o gVisor, que permite que um binário seja executado com segurança. A BAB e os sandboxes têm limitações.
A BAB é um controle forte para produtos maduros, mas pode reduzir a velocidade durante os estágios iniciais do desenvolvimento de novos sistemas e ao executar experimentos sem dados sensíveis (por exemplo, otimizar a codificação de dados que já são públicos). Essa limitação significa que algumas cargas de trabalho precisam ser sempre executadas sem a BAB. Essas cargas de trabalho costumam apresentar um risco maior de escalonamento de privilégios locais, por exemplo, ao explorar uma vulnerabilidade do kernel para acessar a raiz local em uma máquina.
Usar sandbox com cargas de trabalho não confiáveis também reduz o risco à segurança, mas tem um custo maior de computação e memória. A eficiência pode cair em uma porcentagem de dois dígitos, dependendo da carga de trabalho e do tipo de sandbox. Para ver um exemplo dos impactos no desempenho de uma carga de trabalho usando sandbox, consulte os comparativos de mercado detalhados no Guia de desempenho do gVisor. A WSR permite lidar com as limitações de eficiência resultantes do isolamento de cargas de trabalho.
Anéis de carga de trabalho
O Google define quatro classes de cargas de trabalho de acordo com os requisitos de segurança: fundamental, sensível, reforçada e não reforçada. A tabela a seguir as descreve em mais detalhes.
| Anel de carga de trabalho | Descrição |
|---|---|
| Básica | Cargas de trabalho que são críticas para a segurança do Google, como serviços de gerenciamento de identidade e acesso. As cargas de trabalho fundamentais têm os requisitos de segurança mais altos e trocam regularmente a eficiência por maior segurança e confiabilidade. |
| Sensível | Cargas de trabalho que podem causar interrupções generalizadas dos serviços ou que têm acesso a dados sensíveis específicos de produtos, como dados do usuário ou do cliente. |
| Mais proteção | Permitem cargas de trabalho não críticas para a segurança, mas que adotam a BAB ou usam sandbox, para que representem pouco risco às cargas de trabalho vizinhas. |
| Não reforçado | Todas as outras cargas de trabalho, incluindo aquelas que executam código não confiável. |
No Google, classificamos as cargas de trabalho críticas que aceitam produtos específicos como sensíveis, enquanto as cargas de trabalho fundamentais são aquelas que podem afetar todos os produtos.
Ao contrário de fundamental e sensível, podemos classificar qualquer carga de trabalho como reforçada com base exclusivamente nos controles adotados e no tipo de entrada que ela processa. Com cargas de trabalho reforçadas, nossa principal preocupação é o impacto delas em outras cargas de trabalho. Por isso, soluções com aumento da proteção podem incluir o uso de sandbox.
Pools de máquinas
Para evitar a coprogramação de serviços sensíveis com cargas de trabalho menos confiáveis (por exemplo, aquelas que processam dados não confiáveis sem um sandbox), precisamos executá-los em pools isolados de máquinas. O isolamento de máquinas facilita a compreensão das invariantes de segurança, mas cada pool de máquinas extra traz compensações em termos de utilização de recursos e manutenção.
O isolamento de máquinas resulta em menor utilização de recursos físicos, porque garantir que os pools de máquinas sejam totalmente utilizados fica mais difícil à medida que adicionamos mais pools. O custo da eficiência pode se tornar significativo quando há vários pools de máquinas grandes e isolados.
Como o consumo de recursos das cargas de trabalho varia em cada pool, o isolamento estrito adiciona overhead de gerenciamento para rebalancear e redirecionar periodicamente as máquinas entre os pools. Esse rebalanceamento requer a drenagem de todas as cargas de trabalho de uma máquina, a reinicialização dela e a execução do nosso processo de limpeza de máquina mais pesado, que ajuda a garantir a autenticidade e a integridade do firmware.
Essas considerações significam que a implementação do isolamento de máquinas do Google precisa fornecer maneiras de otimizar a utilização de recursos físicos e, ao mesmo tempo, proteger cargas de trabalho fundamentais e sensíveis contra invasores.
No Kubernetes, essa abordagem é conhecida como isolamento de nós. Os nós do Kubernetes podem ser mapeados com máquinas físicas ou virtuais. Neste artigo, vamos nos concentrar nas máquinas físicas. Além disso, produtos do Google Cloud, como o Compute Engine, oferecem locatário único para fornecer isolamento de máquinas físicas.
Restrições de programação de cargas de trabalho
O Google provisiona máquinas em três tipos de pools isolados: máquinas fundamentais, máquinas de produção e máquinas de desenvolvimento. O Google opera vários pools isolados que hospedam cargas de trabalho fundamentais e sensíveis, mas este documento apresenta cada um como um único pool para simplificação.
Para oferecer a proteção mais eficaz, implantamos as seguintes restrições de programação do WSR:
- As cargas de trabalho fundamentais só podem ser executadas em máquinas fundamentais.
- As cargas de trabalho sensíveis só podem ser executadas em máquinas de produção.
- As cargas de trabalho reforçadas só podem ser executadas em máquinas de desenvolvimento.
- As cargas de trabalho reforçadas podem ser executadas em máquinas de produção ou desenvolvimento, preferencialmente em máquinas de produção.
O diagrama a seguir mostra as restrições de programação.
Neste diagrama, os limites de isolamento separam diferentes classes de cargas de trabalho entre e dentro dos pools de máquinas. As cargas de trabalho fundamentais são os locatários únicos de máquinas fundamentais dedicadas. A autorização binária ou o uso de sandbox para cargas de trabalho em execução em máquinas de produção ajudam a evitar ataques de escalonamento de privilégios locais. Nas máquinas de desenvolvimento, há um risco residual de que uma carga de trabalho não reforçada comprometa outra, mas o comprometimento está limitado às máquinas de desenvolvimento porque as cargas de trabalho reforçadas não podem criar novos jobs.
As cargas de trabalho reforçadas são programadas em máquinas de produção ou máquinas de desenvolvimento com base na disponibilidade. Permitir a programação em vários pools pode parecer contraintuitivo, mas é essencial aliviar a queda de utilização causada pelas restrições de programação. As cargas de trabalho reforçadas preenchem as lacunas geradas ao isolar jobs sensíveis e não reforçados. Além disso, quanto maior for o consumo de recursos reforçados, mais variações no uso de recursos das outras duas classes poderão ser acomodadas sem a necessidade de movimentos caros da máquina entre os anéis.
O diagrama a seguir mostra as restrições de programação impostas a diferentes classes de cargas de trabalho. Uma carga de trabalho reforçada pode estar localizada em uma máquina de produção ou máquina de desenvolvimento.
Ao isolar cargas de trabalho fundamentais em vários pools fundamentais, o Google troca a eficiência dos recursos por maior segurança. Felizmente, as cargas de trabalho fundamentais costumam ter um consumo de recursos relativamente pequeno, e pools isolados pequenos de máquinas dedicadas têm um impacto insignificante sobre a utilização geral. No entanto, mesmo com uma ampla automação implementada, a manutenção de vários pools de máquinas não ocorre sem um custo. Por isso, estamos sempre evoluindo nossos projetos de máquinas para melhorar o isolamento.
O WSR oferece uma garantia forte de que cargas de trabalho não fundamentais nunca possam ser executadas em máquinas fundamentais. As máquinas fundamentais são protegidas contra movimentação lateral, já que apenas cargas de trabalho fundamentais podem ser executadas nessas máquinas.
Resumo dos controles
O Google usa uma série de controles em toda a infraestrutura para ajudar a proteger os serviços de produção, as máquinas de produção e as cargas de trabalho. Os controles incluem isto:
- Controles de acesso administrativo e BAB para serviços de produção
- Controles de acesso via shell, controles de acesso físico e controles de firmware e software de sistema para máquinas de produção
- WSR para diferentes classes de cargas de trabalho
Juntos, esses controles aplicam restrições que ajudam a proteger os usuários e clientes do Google e os dados deles. O diagrama a seguir ilustra como os controles funcionam em conjunto para apoiar a postura de segurança do Google.
A seguir
- Para mais informações sobre controles de segurança na infraestrutura do Google, leia Visão geral do design de segurança da infraestrutura do Google.
- Para saber mais sobre a cultura de segurança do Google, leia este livro da O'Reilly sobre como criar sistemas seguros e confiáveis (em inglês).
- Para saber mais sobre a produção de contato zero, consulte a apresentação da SREcon.
Autores: Michael Czapiszski e Kevin Plybon