Este conteúdo foi atualizado pela última vez em junho de 2024 e representa o status quo no momento em que foi escrito. As políticas e os sistemas de segurança da Google podem mudar no futuro, à medida que melhoramos continuamente a proteção dos nossos clientes.
A Google executa uma infraestrutura de computação distribuída, multi-inquilino e de escala global para fornecer produtos e serviços a milhares de milhões de pessoas em todo o mundo. Esta infraestrutura tem de equilibrar as prioridades concorrentes de segurança, fiabilidade, resiliência, eficiência, velocidade de desenvolvimento, capacidade de depuração e muito mais.
Este documento descreve alguns dos mecanismos que usamos para manter uma postura de segurança líder da indústria para serviços executados no ambiente de produção da Google. Estes serviços ocupam todo o espetro de sensibilidade de segurança, desde experiências de desenvolvimento que não têm acesso a dados confidenciais até infraestruturas de identidade críticas. Estes serviços concluem tarefas como o processamento de dados do utilizador, a gestão de implementações de software e o aprovisionamento e a gestão do ciclo de vida para máquinas físicas individuais.
Este documento descreve os controlos de segurança que ajudam a proteger as seguintes três camadas principais da nossa infraestrutura:
- Serviços de produção, que incluem os serviços mais críticos para a segurança (também conhecidos como serviços fundamentais)
- Máquinas de produção
- Cargas de trabalho de produção
Aplicamos estes controlos para que o pessoal da Google só possa aceder a serviços, máquinas e cargas de trabalho para fins empresariais legítimos (por exemplo, acesso de manutenção) e para se defender contra o risco interno e a violação de contas do pessoal. Estes controlos oferecem uma proteção em profundidade adicional que complementa os controlos de segurança da infraestrutura existentes que ajudam a evitar a comprometimento da conta.
Melhoria contínua
Os controlos descritos neste documento são usados em todo o ambiente de produção da Google. Muitos serviços, incluindo os serviços fundamentais, usam os níveis de controlo mais recentes que oferecemos. No entanto, devido ao âmbito e à complexidade da infraestrutura da Google, os serviços de produção individuais têm frequentemente requisitos únicos e podem precisar de tempo adicional para implementar as recomendações mais recentes. Através de uma cultura de melhoria contínua, as equipas de engenharia de fiabilidade do site (SRE) e de segurança da Google adaptam constantemente os controlos de segurança para fazer face ao panorama de ameaças em constante mudança.
Proteger serviços de produção
A Google ajuda a proteger a integridade dos serviços de produção para que o pessoal da Google só possa aceder aos serviços para fins empresariais legítimos, como manutenção. Existem duas formas principais de aceder a serviços executados no ambiente de produção: através do acesso administrativo e através da cadeia de fornecimento de software.
A lista seguinte descreve os controlos que ajudam a proteger cada caminho de acesso.
Controlos de acesso administrativo: os serviços de produção precisam de manutenção regular (por exemplo, implementações binárias ou de configuração). Na Google, o nosso objetivo é que essas operações sejam realizadas através da automatização, de proxies seguros ou do acesso de emergência auditado, seguindo a filosofia Zero Touch Prod. O conjunto de controlos que remove o acesso humano a recursos de produção chama-se No Persons (NoPe). O NoPe dá à Google a flexibilidade de implementar controlos de acesso baseados na sensibilidade de um serviço de produção e na respetiva prontidão para alcançar uma postura ainda mais forte através da melhoria contínua.
Por exemplo, a Google não permite o acesso unilateral aos serviços fundamentais. Mesmo o acesso de emergência requer a aprovação de outro pessoal da Google. Um acesso é unilateral se alguém puder realizar o acesso sem a aprovação de outro indivíduo autorizado.
Controlos da cadeia de fornecimento de software: a maioria das cargas de trabalho de produção na Google, incluindo os serviços fundamentais, executam ficheiros binários e configurações de tarefas que são criados de forma verificável a partir de código revisto por pares localizado numa origem fidedigna. Aplicamos este processo através da autorização binária para o Borg (BAB).
O diagrama seguinte mostra os controlos que ajudam a proteger um serviço de produção.
Quando aplicamos os níveis mais elevados de NoPe e BAB, ajudamos a garantir que nenhum funcionário tem acesso unilateral, mesmo em emergências, aos serviços fundamentais, e que qualquer acesso privilegiado que receba tem um âmbito e uma duração bem definidos. O acesso privilegiado é um nível de acesso elevado concedido ao pessoal para administrar serviços de produção críticos em circunstâncias únicas que não são abordadas pela automatização. Fazemos uma exceção a esta regra para garantir que a Google tem uma forma de sair de situações de bloqueio.
Muitos outros serviços de produção, incluindo produtos como o Filestore ou o Cloud SQL e produtos de infraestrutura internos como o Borg e o Spanner, estão configurados para usar os níveis mais elevados de NoPe e BAB, e estamos a trabalhar continuamente para facilitar a adoção do NoPe e do BAB ao longo do tempo por parte dos proprietários de serviços de produção.
Controlos de acesso administrativo
No Borg, os membros de uma função de produção podem ler, escrever ou eliminar os dados que a função de produção detém e podem executar código usando a autoridade da função. Uma função de produção é uma identidade que pode executar cargas de trabalho no ambiente de produção da Google.
A associação permanente a funções de produção acarreta o risco de consequências não intencionais para a produção e o risco de abuso destes privilégios. No entanto, a missão da SRE exige que as equipas tenham autonomia para manter os serviços pelos quais são responsáveis, pelo que a remoção completa do acesso pode não ser uma estratégia viável.
O conjunto NoPe oferece uma forma de configurar o acesso que equilibra as exigências concorrentes de capacitar as equipas e manter os sistemas de produção seguros. Com o NoPe, o pessoal da Google encontra restrições nos privilégios das respetivas contas quando tenta aceder aos serviços de produção. O NoPe permite as seguintes restrições:
- Os pedidos de acesso requerem um aprovador e uma justificação: um controlo denominado autorização de várias partes (MPA) ajuda a garantir que o pessoal da Google não consegue obter acesso aos serviços de produção sem uma justificação empresarial e uma aprovação de outra pessoa autorizada a validar o pedido de acesso.
- Sem acesso direto a funções de serviço de produção: o pessoal só pode aceder aos serviços de produção através de proxies seguros para NoPe. Os proxies seguros são concebidos para que apenas seja possível executar um conjunto de comandos bem definido. Quaisquer comandos que as organizações de segurança e SRE da Google considerem arriscados (por exemplo, desativar um serviço ou aceder ou eliminar dados) também requerem MPA.
- Nenhuma associação permanente à função de produção: um controlo denominado acesso a pedido (AoD) requer que o pessoal peça uma associação temporária, em vez de permitir que as contas do pessoal tenham sempre privilégios de acesso. Este controlo ajuda a garantir que os poderes elevados só são concedidos temporariamente e por motivos específicos.
- Monitorização de pedidos de acesso do pessoal a serviços de produção: a Google requer uma auditoria periódica dos padrões de acesso a funções de produção que executam um serviço de produção. O objetivo da auditoria é eliminar a necessidade de tais pedidos no futuro, através da 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 os serviços fundamentais, o número de situações em que o acesso é concedido é tão baixo que uma equipa de segurança realiza uma auditoria de cada acesso concedido para confirmar a respetiva validade.
As secções seguintes abordam cada controlo detalhadamente.
Autorização de várias partes para o NoPe
A MPA requer que outro membro autorizado do pessoal da Google aprove um pedido de acesso.
Para pedidos de acesso a serviços suficientemente sensíveis, o MPA também exige que o pessoal apresente uma justificação empresarial que faça referência a uma emergência de produção contínua com cada pedido.
Ambas as condições são barreiras contra o abuso de acesso.
Proxies seguros para o NoPe
Os proxies seguros são ferramentas que expõem um conjunto predefinido de comandos que o proxy seguro pode executar em nome de um autor da chamada. Os proxies seguros implementam políticas de autorização detalhadas baseadas em regras para fornecer restrições no acesso aos serviços de produção. Estas 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 fiabilidade (por exemplo, comandos que eliminam ficheiros). As políticas também podem permitir que determinados comandos seguros (por exemplo, comandos que listam a utilização de recursos) sejam executados sem necessidade de aprovação. Esta flexibilidade é fundamental para minimizar o esforço operacional.
Em casos de abuso de acesso, as contas continuam restritas às operações permitidas pelo proxy seguro. A conta só pode executar comandos seguros unilateralmente, enquanto as operações privilegiadas requerem 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 sem intervenção humana. A produção sem intervenção humana é um conjunto de princípios e ferramentas que garantem que todas as alterações na produção são realizadas por automatização (sem envolvimento de pessoas), pré-validadas por software ou feitas através de um mecanismo auditado capaz de lidar com emergências.
Aceda a pedido
O acesso a pedido (AoD) permite à Google reduzir os privilégios do pessoal substituindo a subscrição permanente pela subscrição elegível.
Os membros elegíveis de uma função não têm acesso aos respetivos privilégios. Em alternativa, se um membro com uma função elegível precisar de acesso, pode pedir uma adesão temporária, conhecida como concessão AoD. Se for aprovada por outra pessoa autorizada, uma concessão de AoD torna o requerente membro da função durante um período limitado, normalmente inferior a um dia.
O modelo de subscrição elegível permite que o pessoal peça apenas o subconjunto de acesso de que precisa durante o período de tempo de que precisa. Em termos conceptuais, pode considerar o AoD como uma produção com limite de tempo sudo, semelhante ao comando sudo -u no Unix, que lhe permite executar alguns comandos com as autorizações elevadas associadas a um utilizador especificado. No entanto, ao contrário do Unix sudo, a receção de uma concessão de AoD requer uma justificação empresarial e um MPA, e deixa uma trilha de auditoria. As concessões de AoD também têm um limite de tempo.
A proteção dos privilégios confidenciais através de subscrições elegíveis significa que, mesmo em casos improváveis de abuso de acesso, as contas só podem aceder a esses privilégios quando existe uma concessão ativa. A adoção de proxies seguros elimina em grande parte a necessidade de tais concessões.
Monitorização de pedidos de acesso
Embora muitas áreas de produção da Google usem o NoPe como uma prática de redução do acesso, as concessões de AoD são extremamente raras para as nossas funções de produção mais sensíveis e estão reservadas apenas para resposta a emergências. Além disso, cada evento aciona uma auditoria manual posterior. O objetivo da auditoria é reduzir a frequência de concessões de AoD no futuro (por exemplo, usando estes eventos para motivar melhorias nas APIs administrativas).
A Google monitoriza continuamente as concessões de AoD e as ações realizadas enquanto detém essas concessões em toda a empresa. Usamos os dados de monitorização em tempo real para detetar potenciais compromissos e identificar áreas para uma maior redução do acesso. Se ocorrer um incidente, a trilha de auditoria suporta uma resposta rápida.
Autorização binária para o Borg
Tal 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 fornecimento de software da Google. O BAB ajuda a garantir que o software de produção e as configurações de tarefas são revistos e aprovados antes de serem implementados, particularmente quando podem aceder a dados confidenciais. Originalmente concebidos para a infraestrutura de produção da Google, os principais conceitos da BAB estão agora incluídos numa especificação aberta denominada Níveis da cadeia de fornecimento para artefactos de software (SLSA).
A BAB ajuda a garantir que o pessoal não pode modificar o código-fonte, executar ficheiros binários nem configurar tarefas sem revisão por pares, e que qualquer artefacto binário ou configuração de software é criado de forma verificável a partir de código-fonte revisto por pares e registado.
Para mais informações, consulte o artigo Autorização binária para o Borg.
Proteger máquinas de produção
Além de reforçar os caminhos de acesso privilegiados e manter a integridade da cadeia de abastecimento de software, a Google protege as máquinas nas quais os serviços de produção são executados. Em particular, implementamos o seguinte:
Controlos de acesso à shell: a maioria dos funcionários da Google não tem acesso à shell (por exemplo, através de SSH) a máquinas de produção nem a cargas de trabalho em execução no Borg, o sistema de gestão de clusters da Google. Em alternativa, os indivíduos têm de usar proxies seguros que exigem que outra pessoa autorizada reveja e aprove cada comando antes de o comando ser executado.
Apenas algumas equipas que trabalham em infraestruturas de baixo nível mantêm o acesso à shell não unilateral para poderem depurar os problemas mais complexos em que os proxies seguros não são práticos de usar. Um acesso é não unilateral se exigir autorização de um ou mais funcionários autorizados adicionais. A Google faz uma exceção em que o acesso unilateral à shell é permitido: para garantir que a Google tem uma forma de sair de situações de bloqueio.
Controlos de acesso físico: as máquinas precisam de manutenção física regular para continuarem a funcionar bem. Para ajudar a garantir que os técnicos do centro de dados só acedem a máquinas físicas no contexto de um motivo comercial válido, a Google usa controlos físico-lógicos.
Controlos de firmware e software do sistema: a Google implementa um fluxo de segurança de arranque medido que se baseia numa raiz de confiança de hardware. A raiz de confiança de hardware ajuda a garantir a integridade do firmware de arranque e do software do sistema de cada máquina.
O diagrama seguinte mostra os controlos que ajudam a proteger uma máquina num centro de dados.
Controlos de acesso à shell
O SSH é uma ferramenta administrativa de código aberto popular que permite um acesso amplo a servidores baseados em Linux. Sem controlos no acesso SSH, as contas com as credenciais certas podem obter um shell que lhes permite executar código arbitrário de uma forma difícil de auditar.
Com o acesso à shell a um serviço de produção, a conta pode, por exemplo, alterar o comportamento de uma tarefa em execução, roubar credenciais ou usar credenciais para obter uma posição persistente no ambiente.
Para mitigar este risco, usamos o seguinte conjunto de controlos que substitui o acesso SSH às máquinas de produção por métodos alternativos seguros:
- APIs restritas: para equipas com fluxos de trabalho bem definidos que anteriormente requeriam SSH, substituímos o SSH por APIs auditáveis e definidas de forma restrita.
- Proxies seguros para SSH: para equipas que requerem um 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, a Google requer uma justificação empresarial e um indivíduo autorizado para aprovar o acesso. As transcrições completas das sessões de shell são registadas.
- Cenários de bloqueio: a única exceção em que o acesso SSH unilateral é permitido. As transcrições completas das sessões de shell são registadas.
Estes controlos equilibram a necessidade de acesso legítimo à shell com o risco associado a um acesso à shell demasiado amplo.
Contexto: SSH na Google
Anteriormente, a Google usava o SSH para administrar as suas máquinas. O desenvolvimento do Borg permitiu que a maioria dos funcionários da Google deixasse de necessitar de acesso direto às máquinas Linux que executam os respetivos ficheiros binários, mas o acesso à shell persistiu por vários motivos:
- Por vezes, o pessoal precisa de acesso direto a uma máquina para fins de depuração.
- O acesso SSH é uma ferramenta de ensino valiosa para compreender as várias camadas de abstração.
- Em cenários de recuperação de desastres inesperados, as ferramentas de nível superior podem não estar disponíveis.
Para equilibrar estas razões e o risco de segurança que acarretavam, a Google alcançou uma série de marcos para eliminar progressivamente o risco e, em seguida, a utilização do SSH.
Marco de controlo de acesso e monitorização centralizados
A Google investiu num sistema central de autorização e monitorização SSH conhecido como autorização de monitorização baseada na identidade do anfitrião (HIBA). A HIBA oferece visibilidade sobre qualquer utilização de SSH e permite a aplicação de políticas de autorização rigorosas. As tentativas de SSH são registadas não só pela máquina de destino, mas também pelo proxy BeyondCorp centralizado. Os comandos executados pela shell são registados e introduzidos em pipelines de deteção de comportamento malicioso. No entanto, a deteção é inerentemente reativa e vulnerável à evasão e à obfuscação.
Eliminar marco de acesso unilateral
Para a maioria dos funcionários, a Google removeu o acesso à shell (por exemplo, através de SSH) às máquinas de produção ou às cargas de trabalho em execução no Borg. No entanto, continua a estar acessível em máquinas de teste (por exemplo, máquinas usadas para qualificar novo hardware ou novo software de baixo nível, mas que não executam serviços de produção) para as equipas de desenvolvimento.
APIs restritas
Algumas equipas da Google que, historicamente, dependiam do SSH para executar um número limitado de comandos precisamente definidos (por exemplo, num manual de instruções) ou para obter dados cuja estrutura é previsível, usam agora APIs definidas de forma restrita que servem o exemplo de utilização específico e fornecem dados estruturados.
As APIs restritas têm um pequeno número de métodos alinhados com os percursos do utilizador comuns e abstraem os detalhes de acesso de baixo nível. Consequentemente, são a solução preferencial da Google porque oferecem a melhor segurança e capacidade de auditoria. Ao criá-los na infraestrutura de chamadas de procedimentos remotos (RPC) da Google, beneficiamos de décadas de investimento em segurança e auditoria.
Proxies seguros para SSH
Algumas equipas da Google não conseguem determinar os comandos de que podem precisar antecipadamente. Neste caso, a Google usa um daemon de execução de comandos que só aceita pedidos de execução de comandos arbitrários de um proxy fidedigno executado por uma equipa de segurança. Esta tecnologia é semelhante à tecnologia usada em proxies seguros para o NoPe.
Os proxies seguros para SSH são responsáveis pela autorização detalhada da execução de comandos e pela auditoria. A autorização baseia-se no argumento e no ambiente do comando, nos parâmetros de limitação de taxa, nas justificações empresariais e no MPA. Este processo de autorização permite restrições arbitrariamente precisas sobre os comandos que podem ser executados de acordo com os manuais de procedimentos e as práticas recomendadas da equipa. Em condições de falha inesperadas que não são captadas em manuais existentes, o pessoal pode continuar a executar os comandos de depuração necessários depois de outra pessoa autorizada os ter aprovado.
MPA para SSH
As poucas equipas restantes que trabalham em infraestrutura de baixo nível mantêm uma forma não unilateral de acesso à shell para depurar os problemas mais complexos.
SSH em cenários de bloqueio
A Google faz uma exceção quando o acesso unilateral à shell é permitido: para garantir que a Google pode corrigir situações de bloqueio. As chaves SSH usadas para este fim são geradas com um processo auditável distinto e armazenadas offline em hardware resistente a adulterações. Quando estas chaves são usadas, são registadas transcrições completas da sessão de shell.
Controlos de acesso físico
Os centros de dados da Google são um ambiente complexo de servidores, dispositivos de rede e sistemas de controlo que requerem uma vasta gama de funções e competências para gerir, manter e operar.
A Google implementa seis camadas de controlos físicos e muitos controlos lógicos nas próprias máquinas para ajudar a proteger as cargas de trabalho no centro de dados. Também defendemos um espaço entre as máquinas, que chamamos de espaço físico-lógico.
Os controlos físico-lógicos oferecem camadas adicionais de defesa através de controlos denominados reforço da máquina, controlo de acesso baseado em tarefas e autodefesa do sistema. Os controlos físico-lógicos defendem contra um adversário que procura explorar o acesso físico a uma máquina e escalar para um ataque lógico nas cargas de trabalho da máquina.
Para mais informações, consulte o artigo Como a Google protege o espaço físico para o espaço lógico num centro de dados.
Controlos de firmware e software do sistema
A postura de segurança de uma máquina do centro de dados é estabelecida no momento do arranque. O processo de arranque da máquina configura o hardware da máquina e inicializa o respetivo sistema operativo, ao mesmo tempo que mantém a máquina segura para execução no ambiente de produção da Google.
Em cada passo do processo de arranque, a Google implementa controlos líderes da indústria para ajudar a aplicar o estado de arranque esperado e ajudar a manter os dados dos clientes seguros. Estes controlos ajudam a garantir que as nossas máquinas são iniciadas no software pretendido, o que nos permite remover vulnerabilidades que possam comprometer a postura de segurança inicial da máquina.
Para mais informações, consulte o artigo Como a Google aplica a integridade de arranque em máquinas de produção.
Proteger cargas de trabalho
De acordo com a nossa filosofia de confiança zero, a Google também introduziu controlos que ajudam a defender contra ameaças de movimento lateral entre cargas de trabalho com diferentes requisitos de segurança. A infraestrutura da Google usa uma hierarquia de cargas de trabalho denominada anéis de segurança de cargas de trabalho (WSR). O WSR ajuda a garantir que as cargas de trabalho críticas não são agendadas nas mesmas máquinas que as cargas de trabalho menos seguras, evitando um 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 agendá-las em diferentes conjuntos de máquinas.
O diagrama seguinte mostra como o WSR agrupa e agenda cargas de trabalho em máquinas fundamentais, de produção e de desenvolvimento.
O WSR oferece uma camada adicional de defesa contra a elevação de privilégios local através de ataques de vulnerabilidade do kernel ou ataques de canal lateral da CPU. O WSR ajuda a garantir que apenas as cargas de trabalho com requisitos de segurança semelhantes são agendadas em conjunto nas mesmas máquinas. Para implementar a WSR, fazemos o seguinte:
- Classifique as cargas de trabalho de acordo com os respetivos requisitos de segurança. Cada classe é conhecida como um anel de carga de trabalho.
- Distribuir máquinas físicas por vários conjuntos de máquinas isolados entre si. Por outras palavras, eliminamos os caminhos de movimento lateral entre os conjuntos.
- Aplique restrições de agendamento para impedir que as cargas de trabalho com diferentes requisitos de segurança sejam executadas na mesma máquina. Estas restrições de agendamento mitigam o risco de comprometimento através do escalamento de privilégios locais.
Por exemplo, o WSR requer que as cargas de trabalho fundamentais sejam executadas em máquinas dedicadas e nunca sejam agendadas em conjunto com cargas de trabalho não fundamentais. Esta restrição oferece um forte isolamento de cargas de trabalho menos seguras.
Métodos para isolar cargas de trabalho
O software do sistema moderno é complexo e os investigadores de segurança descobrem periodicamente vulnerabilidades de escalada de privilégios locais, como exploits zero-day do kernel ou novos ataques de canal lateral da CPU. O WSR, introduzido pela primeira vez na USENIX ;login:, permite à Google reduzir o risco associado à colocação conjunta de cargas de trabalho, mantendo uma elevada utilização de recursos.
Por predefinição, o Borg usa limites de processos ao nível do SO para isolar contentores. Estes processos oferecem um limite de isolamento mais fraco do que as máquinas virtuais que usam a virtualização baseada em hardware. Normalmente, este isolamento mais fraco é uma boa compensação entre a eficiência e a segurança para ambientes multiinquilinos que executam cargas de trabalho fidedignas. Uma carga de trabalho fidedigna é uma carga de trabalho em que o binário e a configuração foram criados de forma verificável a partir de código revisto por pares de proveniência atestada. As cargas de trabalho fidedignas não processam dados não fidedignos arbitrários. Os exemplos de tratamento de dados não fidedignos incluem alojar código de terceiros ou codificar vídeos.
A Google alcança confiança nos respetivos ficheiros binários através da utilização de BAB. No entanto, a BAB não é suficiente para garantir a integridade das cargas de trabalho que processam dados não fidedignos. Além do BAB, estas cargas de trabalho também têm de ser executadas numa sandbox. Uma sandbox é um ambiente restrito, como o gVisor, que permite que um ficheiro binário seja executado em segurança. Tanto o BAB como as caixas de areia têm limitações.
A BAB é um controlo forte para produtos desenvolvidos, mas pode reduzir a velocidade durante as fases iniciais do desenvolvimento de novos sistemas e quando executa experiências sem dados confidenciais (por exemplo, otimizar a codificação de dados que já são públicos). Esta limitação significa que algumas cargas de trabalho têm de ser sempre executadas sem o BAB. Estas cargas de trabalho estão inerentemente sujeitas a um risco mais elevado de escalada de privilégios local (por exemplo, explorando uma vulnerabilidade do kernel para obter acesso root local numa máquina).
A execução de cargas de trabalho não fidedignas com sandbox também mitiga o risco de segurança, mas tem o custo de um aumento da utilização de computação e memória. A eficiência pode diminuir uma percentagem de dois dígitos, dependendo da carga de trabalho e do tipo de sandbox. Para ver um exemplo dos impactos no desempenho numa carga de trabalho em sandbox, consulte os testes de referência detalhados no guia de desempenho do gVisor. O WSR permite-nos resolver as limitações de eficiência resultantes do isolamento das cargas de trabalho.
Anéis de carga de trabalho
A Google define quatro classes de cargas de trabalho de acordo com os respetivos requisitos de segurança: fundamentais, confidenciais, reforçadas e não reforçadas. A tabela seguinte descreve-as mais detalhadamente.
| Anel de carga de trabalho | Descrição |
|---|---|
| Fundacional | Cargas de trabalho críticas para a segurança da Google, como os serviços de gestão de identidade e de acesso. As cargas de trabalho fundamentais têm os requisitos de segurança mais elevados e trocam rotineiramente a eficiência por uma maior segurança e fiabilidade. |
| Confidencial | Cargas de trabalho que podem causar interrupções generalizadas ou que têm acesso a dados confidenciais específicos do produto, como dados de utilizadores ou clientes. |
| Reforçado | Suportar cargas de trabalho que não sejam críticas para a segurança, mas que tenham adotado o BAB ou estejam em sandbox, para que representem pouco risco para as cargas de trabalho vizinhas. |
| Não reforçado | Todas as outras cargas de trabalho, incluindo as que executam código não fidedigno. |
Na Google, classificamos as cargas de trabalho críticas que suportam produtos específicos como sensíveis, enquanto as cargas de trabalho fundamentais são cargas de trabalho que podem afetar todos os produtos.
Ao contrário das cargas de trabalho fundamentais e confidenciais, podemos classificar qualquer carga de trabalho como protegida com base exclusivamente nos respetivos controlos adotados e no tipo de entrada que processa. Com as cargas de trabalho reforçadas, preocupamo-nos principalmente com o respetivo impacto noutras cargas de trabalho, pelo que as soluções de reforço podem incluir a utilização de caixas de areia.
Piscinas de máquinas
Para evitar a agendamento conjunto de serviços confidenciais com cargas de trabalho menos fidedignas (por exemplo, as que processam dados não fidedignos sem uma sandbox), temos de as executar em conjuntos isolados de máquinas. O isolamento de máquinas facilita a compreensão das invariantes de segurança, mas cada conjunto de máquinas adicional introduz compromissos na utilização de recursos e na capacidade de manutenção.
O isolamento de máquinas resulta numa menor utilização de recursos físicos, porque garantir que os conjuntos de máquinas são totalmente utilizados torna-se mais difícil à medida que adicionamos mais conjuntos. O custo de eficiência pode tornar-se significativo quando existem vários conjuntos de máquinas grandes e isolados.
À medida que a pegada de recursos das cargas de trabalho flutua em cada conjunto, o isolamento rigoroso adiciona sobrecarga de gestão para reequilibrar e reutilizar periodicamente as máquinas entre conjuntos. Este reequilíbrio requer a remoção de todas as cargas de trabalho de uma máquina, o reinício da máquina e a execução do nosso processo de limpeza da máquina mais pesado, que ajuda a garantir a autenticidade e a integridade do firmware.
Estas considerações significam que a implementação do isolamento de máquinas da Google tem de oferecer formas de otimizar a utilização de recursos físicos, ao mesmo tempo que defende cargas de trabalho fundamentais e confidenciais contra adversários.
No Kubernetes, esta abordagem é conhecida como isolamento de nós. Os nós do Kubernetes podem ser mapeados para máquinas físicas ou virtuais. Neste artigo, vamos focar-nos em máquinas físicas. Além disso, Google Cloud produtos como o Compute Engine oferecem arrendamento único para fornecer isolamento físico da máquina.
Restrições de agendamento de cargas de trabalho
A Google aprovisiona máquinas em três tipos de pools isolados: máquinas fundamentais, máquinas de produção e máquinas de desenvolvimento. A Google opera vários pools isolados que alojam cargas de trabalho fundamentais e confidenciais, mas este documento apresenta cada um como um pool para simplificar.
Para oferecer a proteção mais eficaz, implementamos as seguintes restrições de agendamento para a WSR:
- As cargas de trabalho fundamentais só podem ser executadas em máquinas fundamentais.
- As cargas de trabalho confidenciais só podem ser executadas em máquinas de produção.
- As cargas de trabalho não protegidas só podem ser executadas em máquinas de desenvolvimento.
- As cargas de trabalho fortalecidas podem ser executadas em máquinas de produção ou desenvolvimento, com preferência para máquinas de produção.
O diagrama seguinte mostra as restrições de agendamento.
Neste diagrama, os limites de isolamento separam diferentes classes de cargas de trabalho entre e dentro dos conjuntos de máquinas. As cargas de trabalho fundamentais são os únicos inquilinos de máquinas fundamentais dedicadas. A autorização binária ou a sandbox para cargas de trabalho executadas em máquinas de produção ajudam a impedir ataques de escalada de privilégios locais. Nas máquinas de desenvolvimento, existe um risco residual de que uma carga de trabalho não protegida possa comprometer outra carga de trabalho, mas o comprometimento está limitado às máquinas de desenvolvimento, porque as cargas de trabalho protegidas não podem criar novas tarefas.
As cargas de trabalho fortalecidas são agendadas em máquinas de produção ou máquinas de desenvolvimento com base na disponibilidade. Permitir o agendamento em vários conjuntos pode parecer contraproducente, mas é essencial para aliviar a diminuição da utilização causada pelas restrições de agendamento. As cargas de trabalho reforçadas preenchem as lacunas introduzidas pelo isolamento de tarefas sensíveis e não reforçadas. Além disso, quanto maior for a área de cobertura dos recursos protegidos, mais flutuações no uso de recursos das outras duas classes podem ser acomodadas sem a necessidade de movimentos dispendiosos de máquinas entre anéis.
O diagrama seguinte mostra as restrições de agendamento impostas a diferentes classes de cargas de trabalho. Uma carga de trabalho protegida pode estar localizada numa máquina de produção ou numa máquina de desenvolvimento.
Ao isolar as cargas de trabalho fundamentais em vários conjuntos fundamentais, a Google troca a eficiência dos recursos por uma maior segurança. Felizmente, as cargas de trabalho fundamentais tendem a ter uma pegada de recursos relativamente pequena, e os pequenos conjuntos isolados de máquinas dedicadas têm um impacto insignificante na utilização geral. No entanto, mesmo com uma automatização extensiva, a manutenção de vários conjuntos de máquinas tem um custo, pelo que estamos constantemente a desenvolver os nossos designs de máquinas para melhorar o isolamento.
O WSR oferece uma forte garantia de que as cargas de trabalho não fundamentais nunca são permitidas em máquinas fundamentais. As máquinas fundamentais estão protegidas contra o movimento lateral, uma vez que apenas as cargas de trabalho fundamentais podem ser executadas nessas máquinas.
Resumo dos controlos
A Google usa vários controlos em toda a sua infraestrutura para ajudar a proteger os serviços de produção, as máquinas de produção e as cargas de trabalho. Os controlos incluem o seguinte:
- Controlos de acesso administrativo e BAB para serviços de produção
- Controlos de acesso à shell, controlos de acesso físico e controlos de software de sistema e firmware para máquinas de produção
- WSR para diferentes classes de cargas de trabalho
Em conjunto, estes controlos aplicam restrições que ajudam a proteger os utilizadores e os clientes da Google, bem como os respetivos dados. O diagrama seguinte ilustra como os controlos funcionam em conjunto para suportar a postura de segurança da Google.
O que se segue?
- Para mais informações sobre os controlos de segurança na infraestrutura da Google, leia a vista geral do design de segurança da infraestrutura da Google.
- Para saber mais acerca da cultura de segurança da Google, leia o artigo Building secure and reliable systems (livro da O'Reilly).
- Para saber mais sobre a produção zero-touch, consulte a apresentação da SREcon.