Patches de segurança

Neste documento, descrevemos como o Google gerencia vulnerabilidades e patches de segurança no Google Kubernetes Engine (GKE).

Esta página é destinada a especialistas em segurança que oferecem suporte à resolução de problemas ou vulnerabilidades de segurança que precisam de assistência estratégica, como incidentes e problemas encaminhados pelo suporte. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.

Como corrigir responsabilidade compartilhada

A aplicação de patches é uma responsabilidade compartilhada entre o Google e o cliente. Diferentes plataformas têm diferentes responsabilidades. Consulte os tópicos a seguir sobre cada plataforma para mais detalhes:

Como descobrimos vulnerabilidades

O Google investiu grandes investimentos em um projeto de segurança proativo e maior proteção, mas até mesmo os sistemas de software mais projetados podem ter vulnerabilidades. Para encontrar essas vulnerabilidades e corrigi-las antes de serem exploradas, o Google fez investimentos significativos em várias frentes.

Para fins de patch, o GKE é uma camada de sistema operacional (SO) com contêineres sendo executados na parte de cima. Os sistemas operacionais, Container-Optimized OS ou Ubuntu, são reforçados e contêm a quantidade mínima de software necessária para executar contêineres. Os recursos do GKE são executados como contêineres sobre as imagens de base. O GKE trabalha de forma consistente para reduzir o número de dependências que os componentes do sistema têm, o que ajuda a reduzir a superfície de ataque e melhorar a eficiência do gerenciamento de vulnerabilidades. Por exemplo, os componentes do sistema do GKE podem usar imagens de base mínimas quando possível.

O Google identifica e corrige vulnerabilidades e patches ausentes das seguintes maneiras:

  • Container-Optimized OS: o Google verifica as imagens para identificar possíveis vulnerabilidades e patches ausentes. A equipe do Container-Optimized OS revisa e resolve problemas.

  • Ubuntu: o Canonical fornece ao Google versões do sistema operacional que têm todos os patches de segurança disponíveis.

O Google verifica os contêineres usando o Artifact Registry Container Analysis para descobrir vulnerabilidades e patches ausentes no Kubernetes e nos contêineres gerenciados pelo Google. Se houver correções disponíveis, o scanner começará automaticamente o processo de patch e liberação.

Além da verificação automatizada, o Google descobre e corrige vulnerabilidades desconhecido aos scanners das seguintes maneiras.

O Google realiza auditorias, testes de penetração e descoberta de vulnerabilidades em todas as plataformas. Para conferir uma lista de plataformas, consulte a seção anterior Responsabilidade compartilhada de aplicação de patch.

Equipes especializadas do Google e fornecedores confiáveis de terceiros conduzem suas próprias pesquisas de ataque. O Google também trabalhou com o CNCF para oferecer a maior parte da organização e experiência com consultoria técnica para a auditoria de segurança do Kubernetes.

O Google envolve ativamente a comunidade de pesquisa de segurança por meio de vários programas de recompensa por vulnerabilidade. Um programa dedicado de recompensas de vulnerabilidade do Google Cloud oferece recompensas significativas, incluindo US $133.337 para a melhor vulnerabilidade de nuvem encontrada a cada ano. No GKE, há um programa que recompensa os pesquisadores de segurança caso eles possam interromper nossos controles de segurança. O programa abrange todas as dependências de software do GKE.

O Google colabora com outros parceiros de software de código aberto e do setor que compartilham vulnerabilidades, pesquisa de segurança e patches antes do lançamento público da vulnerabilidade. O objetivo desta colaboração é aplicar patches às principais partes da infraestrutura da Internet antes que a vulnerabilidade seja anunciada para o público. Em alguns casos, o Google contribui com as vulnerabilidades encontradas para essa comunidade. Por exemplo, o Projeto Zero do Google descobriu e divulgava as vulnerabilidades do Spectre e Meltdown. A equipe de segurança do Google Cloud também encontra e corrige regularmente as vulnerabilidades na máquina virtual (KVM, na sigla em inglês) baseada em kernel.

A colaboração de segurança do Google acontece em muitos níveis. Às vezes, ocorre por meio de programas em que as organizações se inscrevem para receber notificações de pré-lançamento sobre vulnerabilidades de software para produtos como o Kubernetes e Envoy. A colaboração também acontece de maneira informal devido ao nosso engajamento com muitos projetos de código aberto, como o kernel do Linux, ambientes de execução de contêiner, tecnologia de virtualização e outros.

No Kubernetes, o Google é um membro ativo e fundador do Comitê de Resposta de Segurança (SRC, na sigla em inglês) e escreveu grande parte do Processo de liberação de segurança. O Google é membro da lista de distribuidores do Kubernetes (em inglês) que recebe uma notificação prévia de vulnerabilidades e está envolvido na triagem, na aplicação de patches, no desenvolvimento de mitigação e na comunicação de quase {101. }todas as vulnerabilidades graves de segurança do Kubernetes. O Google também descobriu vários problemas de vulnerabilidade do Kubernetes.

Embora vulnerabilidades menos graves sejam descobertas e corrigidas fora desses processos, as vulnerabilidades de segurança mais graves são informadas de modo privado por meio de um dos canais listados anteriormente. Os relatórios antecipados dão ao Google tempo antes que a vulnerabilidade se torne pública para pesquisar como ela afeta o GKE, desenvolver patches ou mitigações e preparar orientações e comunicações para os clientes. Quando possível, o Google corrige todos os clusters antes da versão pública da vulnerabilidade.

Como as vulnerabilidades são classificadas

O GKE faz grandes investimentos em fortalecimento da segurança de toda a pilha, incluindo o SO, o contêiner, o Kubernetes e as camadas de rede, além de definir bons padrões, configurações com segurança reforçada e componentes gerenciados. Combinados, esses esforços ajudam a reduzir o impacto e a probabilidade das vulnerabilidades.

A equipe de segurança do GKE classifica as vulnerabilidades de acordo com o sistema de pontuação de vulnerabilidades do Kubernetes. As classificações consideram muitos fatores, incluindo a configuração do GKE e o aumento da proteção de segurança. Devido a esses fatores e aos investimentos que o GKE faz na segurança, as classificações de vulnerabilidade do GKE podem ser diferentes de outras fontes de classificação.

Veja na tabela a seguir as categorias de gravidade de vulnerabilidade:

Gravidade Descrição
Crítico Uma vulnerabilidade facilmente explorada em todos os clusters por um invasor remoto não autenticado que leva ao comprometimento total do sistema.
Alta Uma vulnerabilidade fácil de explorar para muitos clusters que levam à perda de confidencialidade, integridade ou disponibilidade.
Média Uma vulnerabilidade que pode ser explorada para alguns clusters em que a perda de confidencialidade, integridade ou disponibilidade é limitada por configurações comuns, dificuldade de exploração, acesso necessário ou interação do usuário.
Baixa Todas as outras vulnerabilidades. A exploração é improvável ou as consequências da exploração são limitadas.

Consulte os boletins de segurança para ver exemplos de vulnerabilidades, correções e mitigações, além das respectivas classificações.

Como as vulnerabilidades são corrigidas para clusters do GKE

A correção de uma vulnerabilidade envolve o upgrade para um novo número de versão do GKE. As versões do GKE incluem componentes com controle de versão para o sistema operacional, componentes do Kubernetes e outros contêineres que compõem a plataforma do GKE. A correção de algumas vulnerabilidades exige apenas um upgrade do plano de controle, executado automaticamente pelo Google no GKE, enquanto outras requerem o plano de controle e os upgrades do nó.

Para manter os clusters corrigidos e reforçados com vulnerabilidades de todas as gravidades, recomendamos usar o upgrade automático de nós no GKE (ativado por padrão). Para clusters inscritos em canais de lançamento, as versões de patch são promovidas à medida que atendem aos requisitos de qualificação de cada canal. Se você precisar de uma versão de patch do GKE antes que ela chegue ao canal do cluster, é possível fazer upgrade manualmente para a versão de patch se ela estiver na mesma versão secundária de uma disponível no canal de lançamento do cluster.

Em outras plataformas em que os clusters são executados, o Google recomenda fazer upgrade pelo menos uma vez por mês. Para conferir uma lista de plataformas, consulte a seção anterior Responsabilidade compartilhada de aplicação de patch.

Alguns verificadores de segurança ou verificações manuais de versões podem presumir incorretamente que um componente como runc ou containerd não tem um patch de segurança upstream específico. O GKE aplica patches aos componentes regularmente e executa apenas upgrades de versão quando necessário, ou seja, os componentes do GKE são funcionalmente semelhantes a seus equivalentes upstream, mesmo se a versão do componente GKE não corresponde à versão upstream número. Para detalhes sobre uma CVE específica, consulte Boletins de segurança do GKE.

Cronogramas de aplicação de patches

O objetivo do Google é reduzir as vulnerabilidades detectadas em um período apropriado para os riscos que elas representam. O GKE está incluído na ATO provisória FedRAMP doGoogle Cloud, que exige que as vulnerabilidades conhecidas sejam corrigidas em períodos específicos de acordo com o nível de gravidade delas, conforme especificado no controle RA-5(d) da tabela "Resumo das atividades e entregas de monitoramento contínuo" no Guia de estratégia de monitoramento contínuo do FedRAMP (em inglês).

Para cada vulnerabilidade conhecida, o objetivo do GKE é lançar versões de patch que a corrijam dentro do período correspondente. A Google Cloud ATO provisória do FedRAMP não inclui o Google Distributed Cloud, o GKE na AWS ou o GKE no Azure, mas buscamos os mesmos prazos de correção nesses produtos. Depois que o GKE disponibilizar versões de patch para corrigir uma vulnerabilidade conhecida, faça upgrade dos clusters para essas versões e atenda aos cronogramas de aplicação de patch da sua organização.

Como as vulnerabilidades e os patches são comunicados

A melhor fonte para informações atuais sobre vulnerabilidades e patches de segurança é no feed de boletins de segurança dos seguintes produtos:

  • GKE
  • Google Distributed Cloud
  • GKE na AWS
  • GKE no Azure
  • Google Distributed Cloud

Esses boletins seguem um esquema de numeração de vulnerabilidade Google Cloud comum e estão vinculados à página principal de boletins Google Cloud e às notas da versão do GKE. Cada página de boletins de segurança tem um feed RSS no qual os usuários podem se inscrever para receber atualizações.

Vs vezes, as vulnerabilidades são mantidas privadas sob os embargos por tempo limitado. Embargos ajuda a evitar a publicação precoce de vulnerabilidades que possam levar a tentativas de exploração generalizadas antes que as etapas possam ser tomadas para solucioná-las. Em situações de embargo, as notas da versão se referem a "atualizações de segurança" até que a suspensão seja liberada. Depois que o embargo é levantado, o Google atualiza as notas da versão para incluir as vulnerabilidades específicas.

A equipe de segurança do GKE publica boletins de segurança para vulnerabilidades de gravidade alta e crítica. Quando a ação do cliente for necessária para resolver essas vulnerabilidades desse tipo, o Google entrará em contato com os clientes por e-mail. Além disso, o Google também pode entrar em contato com os clientes por meio de contratos de suporte por meio de canais de suporte.