Gerenciamento de vulnerabilidades para o SERVIÇO DE KUBERNETES DO AZURE (AKS)

O gerenciamento de vulnerabilidades envolve a detecção, a avaliação, a mitigação e a emissão de relatórios sobre as vulnerabilidades de segurança existentes em sistemas e software da organização. O gerenciamento de vulnerabilidades é uma responsabilidade compartilhada entre você e a Microsoft.

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

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 contêiner do AKS

• Nós de trabalho do sistema operacional Ubuntu 18.04 e 22.04: A Canonical fornece à Microsoft builds 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 o contrato de suporte e a gravidade.

• Nós do SO do Azure Linux: o Azure Linux fornece ao AKS builds do SO que têm todas as atualizações de segurança disponíveis aplicadas.

Imagens de contêiner do AKS

Embora a CNCF (Cloud Native Computing Foundation ) possua e mantenha 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 a propriedade total do processo de compilação, verificação, assinatura, validação e correção, bem como o controle sobre os binários nas imagens de contêineres. Ter a responsabilidade de compilar os pacotes de código aberto implementados 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 desenvolver o futuro da computação nativa de nuvem na comunidade CNCF mais vasta. Esse trabalho não apenas garante a qualidade de todas as versões do Kubernetes para o mundo, mas também permite que o AKS obtenha rapidamente novas versões do Kubernetes para produção por vários anos. Em alguns casos, à frente de outros provedores de nuvem por vários meses. A Microsoft colabora com outros parceiros do setor na organização de segurança do Kubernetes. Por exemplo, o SRC (Comitê de Resposta à Segurança) recebe, prioriza e corrige vulnerabilidades de segurança embargadas antes de anunciar 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 para vulnerabilidades de software em produtos como Envoy, runtimes de contêiner e muitos outros projetos de software livre.

A Microsoft examina imagens de contêiner usando a análise estática para descobrir vulnerabilidades e atualizações ausentes no Kubernetes e em contêineres gerenciados pela Microsoft. Se houver correções disponíveis, o verificador iniciará automaticamente o processo de atualização e liberação.

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

• A Microsoft executa suas próprias auditorias, testes de penetração e descoberta de vulnerabilidades em todas as plataformas do AKS. Equipes especializadas dentro da Microsoft e fornecedores de segurança de terceiros confiáveis realizam 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 de recompensas do Azure fornece recompensas significativas para a maior vulnerabilidade de nuvem encontrada a cada ano.

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

• A colaboração de segurança da Microsoft ocorre em muitos 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 ocorre informalmente devido ao nosso envolvimento com muitos projetos de código aberto, como o kernel do Linux, runtimes de contêiner, tecnologia de virtualização e outros.

Nós de trabalho

Nós do Linux

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

Se 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ó do 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 do nó para verificar e atualizar as imagens de nó usadas pelo cluster. Para obter mais informações sobre a atualização de imagem de nó, confira Atualização da imagem do nó do AKS (Serviço de Kubernetes do Azure).

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

Nós do Windows Server

Para os nós do Windows Server, o Windows Update não executa e aplica automaticamente as atualizações mais recentes. Agende as atualizações do pool de nós do Windows Server no cluster AKS em relação ao 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, confira Atualizar um pool de nós no AKS.

Como as vulnerabilidades são classificadas

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

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

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

Severidade	Descrição
Crítico	Uma vulnerabilidade facilmente explorável em todos os clusters por um invasor remoto não autenticado que leva a um 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 semanalmente as Vulnerabilidades e Exposições Comuns (CVEs) que têm uma correção de fornecedor. As CVEs sem correção estão aguardando uma correção de fornecedor antes de serem corrigidas. As imagens corrigidas do contêiner 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. Enquanto você estiver executando o VHD atualizado, não deverá executar nenhuma CVE de imagem de contêiner com uma correção de fornecedor com mais de 30 dias.

Para as vulnerabilidades baseadas no sistema operacional no VHD, o AKS também conta com as atualizações de imagem de nó do VHD por padrão, portanto, todas as atualizações de segurança virão com versões semanais de imagem de nó. Atualizações autônomas são desabilitadas, a menos que você altere para não gerenciado, o que não é recomendado, pois sua versão é global.

Atualizar linhas do tempo de lançamento

A meta da Microsoft é atenuar as vulnerabilidades detectadas dentro de um período apropriado para os riscos que elas representam. A P-ATO (Autorização Provisória para Operar) do Microsoft Azure FedRAMP inclui o AKS no escopo de auditoria e foi autorizada. O Guia de Estratégia de Monitoramento Contínuo do FedRAMP e as linhas de base de 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 de maneira ampla o lançamento das novas versões de patch para o AKS. No entanto, a Microsoft monitora e valida constantemente os patches de CVE disponíveis para dar suporte a eles em AKS em tempo hábil. Se um patch crítico for encontrado ou a ação do usuário for necessária, a Microsoft publica e atualiza os detalhes do problema do CVE no GitHub.

Relatório de segurança

Você pode relatar um problema de segurança para o MSRC (Microsoft Security Response Center), criando um relatório de vulnerabilidade.

Se preferir fazer um registro sem fazer logon na ferramenta, envie um email para secure@microsoft.com. Se possível, criptografe sua mensagem com nossa chave PGP; baixe-a na página de chave PGP do Microsoft Security Response Center.

Você deverá receber uma resposta em até 24 horas. Se por alguma razão você não fizer isso, faça um contato posterior por email para garantir que tenhamos recebido sua mensagem original. Para obter mais informações, consulte Microsoft Security Response Center.

Inclua as seguintes informações solicitadas (o máximo que for possível 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, script entre sites etc.)
• Caminhos completos de arquivos de origem relacionados à manifestação do problema
• O local do código-fonte afetado (marcação/ramificação/confirmação ou URL direta)
• 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 explorar o problema

Essas informações nos ajudam a fazer a triagem mais rápida do problema de segurança relatado.

Se você relatar um problema para receber recompensa por detecção de bugs, relatórios mais completos poderão contribuir para uma recompensa mais alta. Para obter mais informações sobre nossos programas ativos, consulte Programa de Recompensas por Bugs da Microsoft.

Política

A Microsoft segue o princípio de Divulgação de vulnerabilidade coordenada.

Próximas etapas

Confira a visão geral sobre Atualização de clusters e pools de nós do Serviço de Kubernetes do Azure.