Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O gerenciamento de vulnerabilidades envolve a deteção, avaliação, mitigação e emissão de relatórios sobre quaisquer vulnerabilidades de segurança existentes nos sistemas e software de uma organização. A gestão de vulnerabilidades é uma responsabilidade partilhada entre si e a Microsoft.
Para a maioria das cargas de trabalho de produção, o AKS Automatic é a experiência de cluster padrão recomendada. O AKS Automatic reduz a sobrecarga operacional ao disponibilizar pools de nós de sistema geridos, atualizações automáticas das imagens do cluster e dos nós, mecanismos de proteção de segurança incorporados e configurações predefinidas prontas para produção. Se precisar de mais controlo direto sobre a configuração do cluster, o AKS Standard continua disponível para cenários especializados.
Este artigo descreve como a Microsoft gere vulnerabilidades de segurança e atualizações de segurança, também referidas como patches, para clusters AKS. Para uma visão geral da experiência do AKS Automatic, consulte Introdução ao Azure Kubernetes Service (AKS) Automatic.
Importante
A partir de 30 de novembro de 2025, o Azure Kubernetes Service (AKS) deixou de suportar nem fornecer atualizações de segurança para o Azure Linux 2.0. A imagem da máquina virtual do Azure Linux 2.0 está congelada na versão 202512.06.0. A partir de 31 de março de 2026, as imagens dos nós serão removidas e não poderá ajustar o tamanho dos seus pools de nós. Migre para uma versão Azure Linux suportada atualizando os seus pools de nós para uma versão Kubernetes suportada ou migrando para o osSku AzureLinux3. Para mais informações, consulte a edição do Retirement GitHub e o anúncio de reforma do Azure Updates. Para se manter informado sobre anúncios e atualizações, siga as notas de lançamento do AKS.
AKS Gestão automática e de vulnerabilidades
O AKS Automatic foi concebido para ser a predefinição pronta para produção para novas cargas de trabalho do AKS. Inclui predefinições que reforçam a segurança do cluster e reduzem o volume de trabalho manual necessário para manter as cargas de trabalho atualizadas, tais como:
- Conjuntos de nós de sistema geridos que o AKS cria, dimensiona e atualiza.
- Azure Linux para o pool de nós do sistema.
- Atualizações automáticas das imagens do cluster e dos nós.
- Controlo de acesso baseado em funções do Azure (RBAC) para autorização do Kubernetes.
- Identidade de carga de trabalho e suporte ao emissor OIDC.
- Salvaguardas de implementação e normas de base de segurança dos Pods.
- Limpador de imagens para remover imagens não utilizadas.
- Padrões de rede gerida que reduzem a necessidade de configuração personalizada da infraestrutura.
Estes valores por defeito ajudam a Microsoft e aos clientes a reduzir os períodos de exposição a vulnerabilidades conhecidas e a simplificar o processo de manter os clusters atualizados. O AKS Standard ainda está disponível quando precisa de um modelo de funcionamento mais manual ou personalizável.
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 contentores AKS: A Microsoft constrói e mantém as imagens de contentores usadas no AKS, que incluem componentes Kubernetes e outro software de código aberto. A Microsoft analisa estas imagens à procura de vulnerabilidades e aplica correções conforme necessário.
- Nós de trabalho do sistema operativo Ubuntu 18.04 e 22.04: A Canonical fornece à Microsoft versões do sistema operativo com todas as atualizações de segurança disponíveis aplicadas.
- Nós de trabalho do SO Windows Server 2022: O sistema operativo Windows Server recebe atualizações na segunda terça-feira de cada mês. Os SLAs devem ser os mesmos de acordo com os seus contratos de suporte e o nível de severidade.
- Nós do Azure Linux OS: O Azure Linux fornece ao AKS compilações do sistema operativo que têm todas as atualizações de segurança disponíveis aplicadas.
Para clusters automáticos do AKS, o conjunto de nós do sistema gerido utiliza o Azure Linux por defeito, o que coloca o cluster em conformidade com o modelo de sistema operativo protegido e gerido da plataforma. Essa predefinição reduz a quantidade de gestão de correções ao nível do nó que tem de fazer por si próprio.
Imagens de Contêiner AKS
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 assumir plena responsabilidade pelo processo de compilação, análise, assinatura, validação e aplicação de hotfixes, bem como o controlo sobre os binários contidos nas imagens de contentor. 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. Para além do Kubernetes, a Microsoft registou-se para receber notificações antecipadas sobre vulnerabilidades em software de produtos como o Envoy, ambientes de execução de contentores 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 scanner inicia automaticamente o processo de actualização e distribuição.
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. Por vezes, ocorre formalmente através de programas onde as organizações se inscrevem para receber notificações 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 unmanagedcanal.
Se estiveres a usar o unmanagedcanal, são aplicadas todas as noites atualizações de segurança da Canonical ao sistema operativo do nó. A imagem do nó usada para criar nós do seu cluster permanece inalterada. Se um novo nó Linux for adicionado ao seu 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 patches até que todas as verificações e reinícios estejam concluídos. 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.
Para o AKS Automatic, o pool de nós padrão do sistema é gerido pelo AKS e utiliza o modelo de atualização NodeImage para manter os nós atualizados sem necessidade de intervenção manual rotineira.
Nós do Windows Server
Para os nós do Windows Server, o Windows Update não executa nem aplica automaticamente as atualizações mais recentes. Agende as atualizações do pool de nós do Windows Server no seu cluster AKS em torno do ciclo normal de atualização do Windows e do seu próprio processo de gestão 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.
Os nós do Windows Server são, sobretudo, um cluster Standard ou uma opção de carga de trabalho especializada. O AKS Automatic utiliza o Azure Linux para o pool de nós do sistema.
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 | Descrição |
|---|---|
| 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 serviço AKS corrige as Vulnerabilidades e Exposições Comuns (CVEs) para as quais existe uma correção disponibilizada pelo fornecedor todas as semanas. Qualquer CVE sem uma correção está aguardando uma solução por parte do fornecedor antes de poder ser corrigido. 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 estejas a executar o VHD atualizado, não deverás estar a executar CVEs de imagem de contêiner com uma correção de fornecedor há mais de 30 dias.
Para as vulnerabilidades baseadas no sistema operativo no VHD, o AKS também depende por defeito das atualizações de imagem dos nós no VHD, pelo que quaisquer atualizações de segurança vêm acompanhadas de lançamentos semanais de imagens de nós. As atualizações automáticas estão desativadas, a menos que mude para o modo não gerido, o que não é recomendado, uma vez que a sua disponibilização é global.
O AKS Automatic reduz a quantidade de gestão de patches que precisa de fazer manualmente ao usar pools de nós do sistema geridos e canais automáticos de atualização do cluster. Isto significa que a plataforma é responsável por manter o cluster atualizado para versões atuais e suportadas, sem exigir que tenha de orquestrar, por si, cada atualização dos nós e do plano de controlo.
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. A Autorização Provisória de Operação (P-ATO) Microsoft Azure FedRAMP High inclui o AKS no âmbito da auditoria e está autorizada. 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.
No caso do AKS Automatic, estas atualizações devem ocorrer com menos intervenção por parte do cliente, porque o cluster segue um processo de atualização gerido e predefinições prontas para produção. No caso do AKS Standard, é mais provável que os utilizadores precisem de monitorizar e aplicar as atualizações eles próprios.
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 Centro de Resposta de Segurança da Microsoft.
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 dos ficheiros fonte associados à manifestação do problema
- A localização do código-fonte afetado (tag/branch/commit 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 estiver a relatar um erro para um programa de recompensa, relatórios mais completos podem contribuir para uma recompensa mais alta. Para obter mais informações sobre nossos programas ativos, consulte Microsoft Bug Bounty Program.
Policy
A Microsoft segue o princípio da Divulgação Coordenada de Vulnerabilidades.
Próximos passos
Para a maioria das cargas de trabalho de produção, comece por AKS Automatic.