Patches de segurança
Neste documento, descrevemos como o Google gerencia vulnerabilidades e patches de segurança no Google Kubernetes Engine (GKE) e no GKE Enterprise. Exceto quando indicado de outra forma, o GKE Enterprise inclui as plataformas GKE e GKE Enterprise.
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 Enterprise.
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 Enterprise é uma camada de sistema operacional (SO) com contêineres sendo executados na parte superior. 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 Enterprise são executados como contêineres sobre as imagens de base.
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 as próprias auditorias, testes de penetração e descoberta de vulnerabilidades em todas as plataformas do GKE Enterprise. 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 deles, dedicado ao Google Cloud, oferece recompensas significativas, incluindo US$ 133.337 para a menor 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 do Google Cloud Security 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 Kubernetes 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 Enterprise, 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 Enterprise 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 do GKE Enterprise 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 e do GKE Enterprise 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
A correção de uma vulnerabilidade envolve o upgrade para um novo número de versão do GKE ou do GKE Enterprise. As versões do GKE e do GKE Enterprise incluem componentes com controle de versões do sistema operacional, componentes do Kubernetes e outros contêineres que compõem a plataforma GKE Enterprise. 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 do GKE Enterprise, o Google recomenda fazer upgrade dos componentes do GKE Enterprise pelo menos uma vez por mês.
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 do FedRAMP do Google Cloud, que exige que as vulnerabilidades conhecidas sejam corrigidas em períodos específicos de acordo com o nível de gravidade, conforme especificado no controle RA-5(d) da tabela Resumo das entregas e atividades de monitoramento contínuo no guia da estratégia de monitoramento contínuo do FedRAMP. A ATO provisória do FedRAMP do Google Cloud não inclui o Google Distributed Cloud e GKE na AWS, mas visamos os mesmos prazos de correção nesses produtos.
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 do Google Cloud comum e estão vinculados à página principal de boletins no 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 Enterprise publica boletins de segurança sobre 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.