Gerenciamento de vulnerabilidades para o Serviço Kubernetes do Azure (AKS)

A gestão de vulnerabilidades envolve detetar, avaliar, mitigar e reportar quaisquer vulnerabilidades de segurança que existam nos sistemas e no software de uma organização. A gestão de vulnerabilidades é uma responsabilidade partilhada entre si e a Microsoft.

Este artigo descreve como a Microsoft gerencia vulnerabilidades de segurança e atualizações de segurança (também chamadas de patches) para clusters do Serviço Azure Kubernetes (AKS).

Como as vulnerabilidades são descobertas

A Microsoft identifica e corrige vulnerabilidades e atualizações de segurança ausentes para os seguintes componentes:

• Imagens de contentor

• Nós de trabalho do sistema operacional Ubuntu 18.04 e 22.04: a Canonical fornece à Microsoft compilações do sistema operacional que têm todas as atualizações de segurança disponíveis aplicadas.

• Nós de trabalho do sistema operacional Windows Server 2022: o sistema operacional Windows Server é corrigido na segunda terça-feira de cada mês. Os SLAs devem ser os mesmos de acordo com seu contrato de suporte e gravidade.

• Azure Linux OS Nodes: O Azure Linux fornece ao AKS compilações do SO que têm todas as atualizações de segurança disponíveis aplicadas.

Imagens de contentor

Enquanto a Cloud Native Computing Foundation (CNCF) possui e mantém a maior parte do código que o AKS executa, a Microsoft assume a responsabilidade pela criação dos pacotes de código aberto que implantamos no AKS. Essa responsabilidade inclui ter a propriedade completa do processo de compilação, verificação, assinatura, validação e hotfix, bem como controle sobre os binários em imagens de contêiner. Ter a responsabilidade de construir os pacotes de código aberto implantados no AKS nos permite estabelecer uma cadeia de suprimentos de software sobre o binário e corrigir o software conforme necessário.  

A Microsoft está ativa no ecossistema Kubernetes mais amplo para ajudar a construir o futuro da computação nativa da nuvem na comunidade CNCF mais ampla. Este trabalho não só garante a qualidade de cada versão do Kubernetes para o mundo, mas também permite que o AKS coloque rapidamente novas versões do Kubernetes em produção por vários anos. Em alguns casos, à frente de outros provedores de nuvem em vários meses. A Microsoft colabora com outros parceiros do setor na organização de segurança do Kubernetes. Por exemplo, o Comitê de Resposta de Segurança (SRC) recebe, prioriza e corrige vulnerabilidades de segurança embargadas antes que elas sejam anunciadas ao público. Esse compromisso garante que o Kubernetes seja seguro para todos e permite que o AKS corrija e responda a vulnerabilidades mais rapidamente para manter nossos clientes seguros. Além do Kubernetes, a Microsoft se inscreveu para receber notificações de pré-lançamento de vulnerabilidades de software para produtos como Envoy, runtimes de contêiner e muitos outros projetos de código aberto.

A Microsoft verifica imagens de contêiner usando análise estática para descobrir vulnerabilidades e atualizações ausentes no Kubernetes e contêineres gerenciados pela Microsoft. Se houver correções disponíveis, o mecanismo de varredura inicia automaticamente o processo de atualização e lançamento.

Além da verificação automatizada, a Microsoft descobre e atualiza vulnerabilidades desconhecidas dos scanners das seguintes maneiras:

• A Microsoft realiza suas próprias auditorias, testes de penetração e descoberta de vulnerabilidades em todas as plataformas AKS. Equipes especializadas dentro da Microsoft e fornecedores de segurança terceirizados confiáveis conduzem suas próprias pesquisas de ataque.

• A Microsoft se envolve ativamente com a comunidade de pesquisa de segurança por meio de vários programas de recompensa de vulnerabilidade. Um programa dedicado do Microsoft Azure Bounty fornece recompensas significativas para a melhor vulnerabilidade na nuvem encontrada a cada ano.

• A Microsoft colabora com outros parceiros do setor e de software de código aberto que compartilham vulnerabilidades, pesquisas de segurança e atualizações antes do lançamento público da vulnerabilidade. O objetivo desta colaboração é atualizar grandes peças da infraestrutura da Internet antes que a vulnerabilidade seja anunciada ao público. Em alguns casos, a Microsoft contribui com vulnerabilidades encontradas para esta comunidade.

• A colaboração de segurança da Microsoft acontece em vários níveis. Às vezes, isso ocorre formalmente 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 Kubernetes e Docker. A colaboração também acontece informalmente devido ao nosso envolvimento com muitos projetos de código aberto, como o kernel Linux, tempos de execução de contêiner, tecnologia de virtualização e outros.

Nós de Trabalho

Nós Linux

As atualizações de segurança canônicas noturnas do sistema operacional são desativadas por padrão no AKS. Para habilitá-los explicitamente, use o unmanaged canal.

Se você estiver usando o unmanaged canal, as atualizações de segurança canônicas noturnas serão aplicadas ao sistema operacional no nó. A imagem do nó usada para criar nós para o cluster permanece inalterada. Se um novo nó Linux for adicionado ao cluster, a imagem original será usada para criar o nó. Este novo nó recebe todas as atualizações de segurança e kernel disponíveis durante a avaliação automática realizada todas as noites, mas permanece sem correção até que todas as verificações e reinicializações sejam concluídas. Você pode usar a atualização de imagem de nó para verificar e atualizar imagens de nó usadas pelo cluster. Para obter mais informações sobre a atualização da imagem do nó, consulte Atualização da imagem do nó do Serviço Kubernetes do Azure (AKS).

Para clusters AKS que usam um canal diferente do unmanaged, o processo de atualização autônoma está desabilitado.

Nós do Windows Server

Para nós do Windows Server, o Windows Update não executa e aplica automaticamente as atualizações mais recentes. Agende atualizações do pool de nós do Windows Server em seu cluster AKS em torno do ciclo de lançamento regular do Windows Update e seu próprio processo de gerenciamento de atualizações. Esse processo de atualização cria nós que executam a imagem e os patches mais recentes do Windows Server e, em seguida, remove os nós mais antigos. Para obter mais informações sobre esse processo, consulte Atualizar um pool de nós no AKS.

Como as vulnerabilidades são classificadas

A Microsoft faz grandes investimentos em segurança protegendo toda a pilha, incluindo o sistema operacional, contêiner, Kubernetes e camadas de rede, além de definir bons padrões e fornecer configurações reforçadas de segurança e componentes gerenciados. Combinados, esses esforços ajudam a reduzir o impacto e a probabilidade de vulnerabilidades.

A equipe do AKS 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 AKS e o fortalecimento da segurança. Como resultado dessa abordagem, e dos investimentos que a AKS faz em segurança, as classificações de vulnerabilidade da AKS podem diferir de outras fontes de classificação.

A tabela a seguir descreve as categorias de gravidade da vulnerabilidade:

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

Como as vulnerabilidades são atualizadas

O AKS corrige Vulnerabilidades e Exposições Comuns (CVEs) que têm uma correção de fornecedor todas as semanas. Qualquer CVE sem uma correção está a aguardar uma correção do fornecedor antes de poder ser remediado. As imagens de contêiner fixo são armazenadas em cache na próxima compilação de disco rígido virtual (VHD) correspondente, que também contém os CVEs corrigidos do Ubuntu/Azure Linux/Windows atualizados. Contanto que você esteja executando o VHD atualizado, não deve executar CVEs de imagem de contêiner com uma correção de fornecedor com mais de 30 dias.

Para as vulnerabilidades baseadas no SO no VHD, o AKS também depende de atualizações vhd de imagem de nó por padrão, portanto, todas as atualizações de segurança virão com lançamentos semanais de imagens de nós. As atualizações autônomas são desabilitadas, a menos que você alterne para não gerenciado, o que não é recomendado, pois seu lançamento é global.

Atualizar cronogramas de lançamento

O objetivo da Microsoft é mitigar as vulnerabilidades detetadas dentro de um período de tempo adequado aos riscos que representam. O Microsoft Azure FedRAMP High Provisional Authorization to Operate (P-ATO) inclui o AKS no âmbito da auditoria e foi autorizado. O Guia de Estratégia de Monitoramento Contínuo do FedRAMP e as linhas de base do Controle de Segurança Baixa, Moderada e Alta do FedRAMP exigem a correção de vulnerabilidades conhecidas dentro de um período de tempo específico de acordo com seu nível de gravidade. Conforme especificado no FedRAMP RA-5d.

Como as vulnerabilidades e atualizações são comunicadas

Em geral, a Microsoft não comunica amplamente o lançamento de novas versões de patch para o AKS. No entanto, a Microsoft monitora e valida constantemente os patches CVE disponíveis para suportá-los no AKS em tempo hábil. Se for encontrado um patch crítico ou for necessária uma ação do utilizador, a Microsoft publicará e atualizará os detalhes do problema CVE no GitHub.

Relatórios de segurança

Pode comunicar um problema de segurança ao Centro de Resposta de Segurança da Microsoft (MSRC) ao criar um relatório de vulnerabilidades.

Se preferir enviar uma denúncia sem fazer login na ferramenta, envie um e-mail para secure@microsoft.com. Se possível, criptografe sua mensagem com nossa chave PGP baixando-a da página Chave PGP do Microsoft Security Response Center.

Deverá receber uma resposta no prazo de 24 horas. Se, por algum motivo, não o fizer, envie um e-mail para garantir que recebemos a sua mensagem original. Para obter mais informações, vá para o Centro de Resposta de Segurança da Microsoft.

Inclua as seguintes informações solicitadas (tanto quanto você puder fornecer) para nos ajudar a entender melhor a natureza e o escopo do possível problema:

• Tipo de problema (por exemplo, estouro de buffer, injeção de SQL, scripts entre sites, etc.)
• Caminhos completos do(s) ficheiro(s) de origem relacionados à manifestação do problema
• A localização do código-fonte afetado (tag/ramo/consolidação ou URL direto)
• Qualquer configuração especial necessária para reproduzir o problema
• Instruções passo a passo para reproduzir o problema
• Prova de conceito ou código de exploração (se possível)
• Impacto do problema, incluindo como um invasor pode explorá-lo

Estas informações ajudam-nos a triar o seu problema de segurança reportado mais rapidamente.

Se você estiver relatando uma recompensa por bug, relatórios mais completos podem contribuir para um prêmio de recompensa mais alto. Para obter mais informações sobre nossos programas ativos, consulte Microsoft Bug Bounty Program.

Política

A Microsoft segue o princípio da Divulgação Coordenada de Vulnerabilidades.

Próximos passos

Consulte a visão geral sobre como atualizar clusters e pools de nós do Serviço Kubernetes do Azure.