DevSecOps no AKS (Serviço de Kubernetes do Azure)

O DevSecOps, também chamado de Secure DevOps, baseia-se na prática do DevOps incorporando a segurança em diferentes estágios de um ciclo de vida de DevOps tradicional. Crie segurança nas práticas do DevOps para:

  • Torne seus aplicativos e sistemas mais seguros, forneça visibilidade sobre ameaças à segurança e impeça que vulnerabilidades atinjam ambientes implantados.

  • Aumente a conscientização sobre segurança entre suas equipes de desenvolvimento e operação.

  • Incorpore processos de segurança automatizados em seu SDLC (ciclo de vida de desenvolvimento de software).

  • Reduza os custos de correção encontrando problemas de segurança no início dos estágios de desenvolvimento e design.

Quando você aplica o DevSecOps ao AKS (Serviço de Kubernetes do Azure), cada função da organização tem considerações de segurança específicas:

  • Os desenvolvedores criam aplicativos seguros que são executados no AKS.

  • Os engenheiros de nuvem criam uma infraestrutura segura do AKS.

  • As equipes de operações podem controlar clusters ou monitorar problemas de segurança.

Este artigo organiza as diretrizes da fase do ciclo de vida do DevOps e fornece recomendações para controles de segurança e práticas recomendadas. Ele aborda processos e ferramentas comuns para pipelines de CI/CD (integração contínua e entrega contínua), com foco em ferramentas internas.

Fluxo do processo

Diagrama de arquitetura que mostra como implementar práticas de DevSecOps em um ambiente do AKS.

Carrege um arquivo Visio desta arquitetura.

Note

Este artigo faz referência ao AKS e ao GitHub, mas você pode aplicar essas recomendações a qualquer orquestração de contêiner ou plataforma CI/CD. Os detalhes da implementação podem variar, mas a maioria dos conceitos e práticas para cada estágio ainda se aplicam.

  1. Microsoft Entra ID é configurado como o provedor de identidade para GitHub. Configure a MFA (autenticação multifator) para ajudar a fornecer segurança de autenticação extra.

  2. Os desenvolvedores usam o Visual Studio Code ou o Visual Studio com extensões de segurança habilitadas para analisar proativamente seu código em busca de vulnerabilidades de segurança.

  3. Os desenvolvedores fazem commit do código do aplicativo em um repositório do GitHub Enterprise de propriedade e governança da empresa.

  4. GitHub Enterprise integra a verificação automática de dependência e segurança por meio de GitHub Advanced Security.

  5. As solicitações pull disparam builds de CI (integração contínua) e testes automatizados por meio do GitHub Actions.

  6. O fluxo de trabalho de build de CI por meio do GitHub Actions gera uma imagem de contêiner do Docker e a armazena no Registro de Contêiner do Azure.

  7. Você pode adicionar aprovações manuais para implantações em ambientes específicos, como produção, como parte do fluxo de trabalho de entrega contínua (CD) no GitHub Actions.

  8. GitHub Actions permitem CD para AKS. Use a Segurança Avançada do GitHub para detectar segredos, credenciais e outras informações confidenciais nos arquivos de origem e configuração do aplicativo.

  9. O Microsoft Defender verifica o Registro de Contêiner, o cluster do AKS e o Azure Key Vault em busca de vulnerabilidades de segurança.

    1. O Microsoft Defender para Contêineres verifica a imagem de contêiner em busca de vulnerabilidades de segurança conhecidas quando o GitHub Actions a carrega no Registro de Contêiner.

    2. O Defender para Contêineres também pode verificar seu ambiente do AKS e fornecer proteção contra ameaças em tempo de execução para seus clusters do AKS.

    3. O Microsoft Defender para Key Vault detecta tentativas incomuns e suspeitas de acessar contas do cofre de chaves.

  10. Você pode aplicar o Azure Policy ao Registro de Contêiner e ao AKS para impor a conformidade da política. O Azure Policy inclui políticas de segurança internas para o Registro de Contêiner e o AKS.

  11. O Key Vault injeta segredos e credenciais com segurança em um aplicativo em runtime sem expô-los aos desenvolvedores.

  12. O mecanismo de política de rede do AKS é configurado para ajudar a proteger o tráfego entre pods de aplicativo usando políticas de rede do Kubernetes. Recomendamos o CNI do Azure alimentado pelo Cilium como o mecanismo de política de rede. Ele fornece imposição estendida baseada em Filtro de Pacotes de Berkeley (eBPF), política de camada 7 e filtragem de FQDN (nome de domínio totalmente qualificado).

  13. Você pode configurar o monitoramento contínuo do cluster do AKS usando o Azure Monitor para coletar métricas do Prometheus, logs de contêiner e eventos do Kubernetes. Use painéis do Grafana Gerenciado do Azure para visualização e o Log Analytics para alertas baseados em consultas.

    1. O Azure Monitor coleta métricas de desempenho por meio do Prometheus Gerenciado e logs de aplicativos e clusters por meio da coleção de logs de contêiner.

    2. Um workspace do Log Analytics armazena os logs de diagnóstico e de aplicativo para executar consultas de log.

  14. Use o Microsoft Sentinel como o SIEM (gerenciamento de eventos e informações de segurança centralizado) para correlacionar a telemetria do AKS com sinais do Microsoft Defender para Nuvem, da ID do Microsoft Entra e dos recursos de rede. O Microsoft Sentinel fornece detecção, investigação e resposta automatizada a incidentes de segurança em todo o ambiente do AKS.

  15. Ferramentas de software livre, como o ZAP (Proxy de Ataque Zed), podem fazer testes de penetração para aplicativos e serviços Web.

  16. O Defender para DevOps, um serviço disponível no Defender para Nuvem, capacita as equipes de segurança a gerenciar a segurança do DevOps em ambientes multipipeline, incluindo o GitHub e o Azure DevOps.

Visão geral e responsabilidades dos membros da equipe

Considere gerenciar a complexidade de DevSecOps em implantações de solução baseadas em Kubernetes dividindo as responsabilidades entre as equipes. Esta seção descreve as funções e as responsabilidades dos desenvolvedores, operadores de aplicativos, como engenheiros de confiabilidade do site, operadores de cluster e equipes de segurança.

Developers

Os desenvolvedores gravam o código do aplicativo e o confirmam no repositório designado. Eles criam e executam scripts para testes automatizados para garantir que seu código funcione conforme o esperado e se integre ao restante do aplicativo. Os desenvolvedores também definem e criam scripts para a criação de imagens de contêiner como parte do pipeline de automação.

Operadores de aplicativo (engenheiros de confiabilidade do site)

A criação de aplicativos usando contêineres e Kubernetes pode simplificar o desenvolvimento, a implantação e a escalabilidade do aplicativo. Mas essas abordagens de desenvolvimento também criam ambientes cada vez mais distribuídos que complicam a administração.

Os engenheiros de confiabilidade do site criam soluções que automatizam como as equipes supervisionam grandes sistemas de software. Eles servem como uma ponte entre equipes de desenvolvimento e operadores de cluster. Eles ajudam a estabelecer e monitorar SLOs (objetivos de nível de serviço) e orçamentos de erro. Os engenheiros de confiabilidade do site também ajudam a gerenciar implantações de aplicativos e gravar arquivos yaml (manifesto do Kubernetes).

Operadores de cluster

Os operadores de cluster configuram e gerenciam a infraestrutura do cluster. Eles geralmente usam as melhores práticas e estruturas de IaC (infraestrutura como código), como o GitOps , para provisionar e manter seus clusters. Eles usam ferramentas de monitoramento como os serviços gerenciados Azure Monitor para Prometheus e Azure Managed Grafana para monitorar a integridade geral do cluster. Eles/Elas são responsáveis pela aplicação de patches, atualizações de cluster, permissões e controle de acesso baseado em função (RBAC) no cluster. Nas equipes do DevSecOps, os operadores de cluster colaboram com as equipes de segurança para estabelecer padrões de segurança e garantir que os clusters atendam a esses requisitos.

Equipe de segurança

A equipe de segurança desenvolve e impõe padrões de segurança. Algumas equipes podem criar e selecionar definições de política do Azure que você aplica às assinaturas e grupos de recursos que contêm os clusters. As equipes de segurança monitoram problemas de segurança e trabalham com outras equipes para priorizar a segurança em todo o processo de DevSecOps.

Estágios do ciclo de vida de DevSecOps

Cada fase do SDLC implementa controles de segurança. Esses controles de segurança são fundamentais para o DevSecOps e práticas de shift-left.

Um diagrama que mostra um ciclo de vida contínuo do DevOps que integra a segurança em todos os estágios.

Carrege um arquivo Visio desta arquitetura.

Fase de planejamento

A fase do plano geralmente tem a menor quantidade de automação, mas tem implicações de segurança importantes que afetam estágios posteriores do ciclo de vida do DevOps. Essa fase envolve a colaboração entre as equipes de segurança, desenvolvimento e operações. Para garantir que você considere ou mitigue os requisitos de segurança e problemas de segurança, inclua as partes interessadas de segurança nesta etapa.

Prática recomendada: criar uma plataforma de aplicativo segura

Para criar uma carga de trabalho segura hospedada pelo AKS, você deve incorporar a segurança ao sistema em cada camada, começando pela própria plataforma. A plataforma pode incluir componentes internos para o cluster, como agentes de segurança e política de runtime, e componentes externos ao AKS, como firewalls de rede e registros de contêiner.

Prática recomendada: criar modelagem de ameaças em seu processo

A modelagem de ameaças geralmente é uma atividade manual que envolve equipes de segurança e desenvolvimento. Você pode modelar e encontrar ameaças em um sistema para resolver vulnerabilidades antes de desenvolver código ou fazer alterações. As equipes realizam a modelagem de ameaças em resposta a alterações significativas de software, alterações de arquitetura de solução ou incidentes de segurança.

Recomendamos o modelo de ameaça STRIDE. Essa metodologia começa com um diagrama de fluxo de dados e categoriza ameaças usando o mnemônico STRIDE: Falsificação, Adulteração, Repúdio, Divulgação de Informações, Negação de Serviço e Elevação de Privilégio. As equipes usam essas categorias para identificar, atenuar e validar riscos. Uma ferramenta de modelagem ajuda a notar e visualizar componentes do sistema, fluxos de dados e limites de segurança.

A criação de modelagem de ameaças em seu SDLC adiciona sobrecarga de processo e exige que você mantenha modelos de ameaça atualizados. No entanto, ele aborda a segurança no início do desenvolvimento, o que reduz o custo de correção de problemas descobertos posteriormente.

Prática recomendada: aplicar o Azure Well-Architected Framework

  • Aplique as práticas recomendadas de segurança que fornecem diretrizes para gerenciamento de identidade, segurança do aplicativo, proteção de infraestrutura, segurança de dados e DevOps, conforme se aplica a ambientes nativos de nuvem.

  • Aplique as práticas recomendadas de Excelência Operacional conforme ela se aplica ao DevSecOps e ao monitoramento de seus ambientes de produção.

Fase de desenvolvimento

Mudar para a esquerda é um princípio fundamental da mentalidade de DevSecOps. Esse processo começa antes de você confirmar o código em um repositório e implantá-lo por meio de um pipeline. Para resolver problemas de segurança anteriormente no ciclo de vida de desenvolvimento, adote práticas recomendadas de codificação segura e use ferramentas e plug-ins do IDE (ambiente de desenvolvimento integrado) para análise de código durante a fase de desenvolvimento.

Prática recomendada: impor padrões de codificação seguros

  • Use as melhores práticas e listas de verificação de codificação segura estabelecidas para ajudar a proteger seu código contra vulnerabilidades comuns, como injeção e design inseguro. A fundação Open Worldwide Application Security Project (OWASP) publica recomendações de codificação segura padrão do setor que você deve adotar ao escrever código. Essas diretrizes são especialmente importantes quando você desenvolve aplicativos ou serviços Web voltados para o público.

  • Examine as práticas de codificação segura para seus runtimes de linguagem de programação específicos, como Java e .NET.

  • Imponha padrões de registro em log para proteger informações confidenciais contra vazamento em logs de aplicativos. As estruturas de log mais populares, como Apache Log4j e Apache log4net, fornecem filtros e plug-ins para mascarar informações confidenciais, como números de conta ou dados pessoais.

Prática recomendada: usar as ferramentas e plug-ins do IDE para automatizar verificações de segurança

Os IDEs mais populares, como Visual Studio, VS Code, IntelliJ IDEA e Eclipse, dão suporte a extensões que você pode usar para obter comentários e recomendações imediatos para possíveis problemas de segurança que você apresenta ao escrever código do aplicativo.

  • O SonarQube para IDE é um plug-in IDE para os ambientes de desenvolvedor e idiomas mais populares. O SonarQube para IDE fornece comentários e verifica automaticamente seu código em busca de erros comuns de programação e possíveis problemas de segurança.

  • Outros plug-ins gratuitos e comerciais se concentram em itens específicos de segurança, como as 10 principais vulnerabilidades comuns do OWASP. O plug-in do Snyk também examina a origem do aplicativo e as dependências externas e alerta você se ele encontrar vulnerabilidades.

  • O plug-in SARIF (Formato de Intercâmbio de Resultados de Análise Estática) para Visual Studio e VS Code permite exibir facilmente vulnerabilidades de ferramentas sast (Teste de Segurança de Aplicativo Estático) populares em vez de interpretar resultados de arquivos de saída JSON brutos.

Prática recomendada: estabelecer controles em seus repositórios de código-fonte

  • Estabeleça uma metodologia de ramificação para consistência em toda a sua empresa. Metodologias como o fluxo de versão e o fluxo do GitHub estruturaram diretrizes sobre como usar branches para dar suporte ao desenvolvimento paralelo e de equipe. Essas metodologias podem ajudar as equipes a estabelecer padrões e controles para confirmações de código e mesclagens em seu fluxo de trabalho de CI/CD.

    Determinados branches, como o principal, são branches de longa duração que preservam a integridade do código-fonte do aplicativo. Estabeleça políticas de mesclagem para essas ramificações antes de confirmar ou mesclar alterações. Por exemplo, você pode:

    • Impedir que outros desenvolvedores façam commit de código diretamente no branch principal.

    • Estabeleça um processo de revisão por pares e exija um número mínimo de aprovações antes de mesclar alterações em um branch principal. Configure e imponha esses controles usando o GitHub. Use o GitHub para designar grupos de aprovadores autorizados, se necessário, para ambientes fechados.

  • Use precommit hooks para verificar se há informações confidenciais no código-fonte do aplicativo e bloquear commits ao identificar problemas de segurança.

    • Use os ganchos de pré-commit internos fornecidos pelo GitHub. Configure-os facilmente para projetos específicos. Por exemplo, alguns ganchos predefinidos verificam segredos, chaves privadas e credenciais e bloqueiam uma confirmação se encontrarem esses problemas.
  • Estabeleça o RBAC em seu sistema de controle de versão.

    • Crie funções bem definidas usando o princípio de privilégios mínimos. Um pipeline de CI/CD funciona como sua cadeia de suprimentos para implantações de produção.

    • Aplique funções de usuário ou grupo estabelecidas em sua organização. Para agrupar indivíduos com base em sua função e função específicas em seus fluxos de trabalho de CI/CD, crie funções como Administrador, Desenvolvedor, Administrador de Segurança e Operador.

  • Habilite a auditoria dos seus fluxos de trabalho para aumentar a transparência e a rastreabilidade nas configurações e em outras alterações dos pipelines de CI/CD.

Prática recomendada: proteger suas imagens de contêiner

  • Use imagens leves que tenham um impacto mínimo do sistema operacional para reduzir a superfície de ataque. Considere imagens mínimas, como Alpine ou imagens sem distribuição que contêm apenas seu aplicativo e seu runtime associado.

  • Use apenas imagens base confiáveis ao criar seus contêineres. Recupere essas imagens base de um registro privado que você verifica frequentemente se há vulnerabilidades.

  • Use ferramentas de desenvolvedor para avaliar vulnerabilidades de imagem localmente. O Trivy é uma ferramenta de software livre que analisa vulnerabilidades de segurança em suas imagens de contêiner.

  • Impedir o acesso ou o contexto do usuário raiz para uma imagem. Por padrão, os contêineres são executados como raiz.

    Para contêineres que precisam de segurança aprimorada, considere usar um perfil AppArmor ou seccomp em seu cluster do Kubernetes para ajudar a impor ainda mais a segurança para seus contêineres em execução.

Fase de build

Durante a fase de build, os desenvolvedores trabalham com engenheiros de confiabilidade do site e equipes de segurança para integrar verificações automatizadas de sua fonte de aplicativo em seus pipelines de build de CI. As equipes configuram os pipelines para habilitar as práticas de segurança usando as ferramentas e extensões de segurança da plataforma CI/CD. Essas práticas incluem SAST, SCA (análise de composição de software) e verificação de segredos.

Prática recomendada: executar SAST para encontrar possíveis vulnerabilidades no código-fonte do aplicativo

  • Use os recursos do GitHub Advanced Security para escaneamento de código e CodeQL.

    • A verificação de código é um recurso que analisa o código em um repositório GitHub para localizar vulnerabilidades de segurança e erros de codificação. Ele exibe os problemas no GitHub Enterprise Cloud.

    • Se a verificação de código encontrar uma possível vulnerabilidade ou erro em seu código, GitHub exibirá um alerta no repositório.

    • Você pode configurar regras de branch para verificações de status necessárias. Por exemplo, você pode exigir que as ramificações de funcionalidades estejam atualizadas com a ramificação base antes de mesclar o novo código. Esse requisito garante que você teste o branch com o código mais atual.

    • Habilite o Copilot Autofix para receber sugestões de correção geradas por IA para alertas de análise de código. O Copilot Autofix propõe a correção diretamente em solicitações de pull, o que ajuda os desenvolvedores a resolver as descobertas de segurança rapidamente.

  • Use ferramentas como kube-score para analisar seus objetos de implantação Kubernetes. Essa ferramenta faz a análise de código estático das definições de objeto do Kubernetes. Ele gera uma lista de recomendações para tornar seu aplicativo mais seguro e resiliente.

Prática recomendada: usar a varredura de segredos para detectar segredos acidentalmente armazenados

  • Quando você habilita a verificação secreta de um repositório, o GitHub verifica o código em busca de padrões que correspondam aos segredos que muitos provedores de serviços usam.

  • O GitHub executa periodicamente uma verificação completa do histórico do git de conteúdo existente em repositórios e envia notificações de alerta.

    • Para o Azure DevOps, o Defender para Nuvem usa a verificação secreta para detectar credenciais, segredos, certificados e outros conteúdos confidenciais em seu código-fonte e saída de build.

    • Você pode executar a verificação secreta como parte da extensão DevOps de Segurança da Microsoft para Azure DevOps.

Prática recomendada: usar ferramentas SCA para acompanhar componentes de software livre na base de código e detectar vulnerabilidades em dependências

  • A revisão de dependência permite capturar dependências inseguras antes de apresentá-las ao seu ambiente. Ele também fornece informações sobre a licença, os dependentes e a idade das dependências. Ele exibe alterações de dependência por meio de um diff detalhado na guia Arquivos alterados de um pull request.

  • Dependabot executa uma verificação para detectar dependências inseguras e envia alertas do Dependabot quando um novo aviso é adicionado ao Banco de Dados de Avisos do GitHub ou quando o grafo de dependência de um repositório é alterado.

Prática recomendada: gerar um SBOM para suas imagens de contêiner

  • Uma lista de materiais de software (SBOM) fornece um inventário completo dos componentes, bibliotecas e dependências que compõem as suas imagens de contêiner. Utilize ferramentas de geração do SBOM, como Microsoft SBOM Tool ou o Syft durante o build de CI, para produzir um manifesto SPDX ou CycloneDX.

  • Anexe um SBOM às imagens de contêiner armazenadas no Registro de Contêiner para habilitar a verificação de vulnerabilidades downstream e o acompanhamento de conformidade de licenças em toda a cadeia de suprimentos.

Prática recomendada: verificar modelos de IaC para detectar configurações incorretas antes da implantação

  • Monitore proativamente as configurações de recursos de nuvem em todo o ciclo de vida de desenvolvimento.

  • O Microsoft Defender para DevOps dá suporte a repositórios GitHub e Azure DevOps e pode verificar modelos de IaC para identificar vulnerabilidades de IaC.

Prática recomendada: examine suas imagens de carga de trabalho em registros de contêiner para identificar vulnerabilidades conhecidas

  • O Defender para Contêineres verifica os contêineres no Registro de Contêiner e no ECR (Registro de Contêiner Elástico do Amazon) para notificar você sobre vulnerabilidades conhecidas em suas imagens.

  • Você pode habilitar o Azure Policy para fazer uma avaliação de vulnerabilidade em imagens armazenadas no Registro de Contêiner e fornecer informações detalhadas sobre cada descoberta.

Prática recomendada: criar novas imagens em atualizações de imagem base automaticamente

  • As Tarefas do Registro de Contêiner descobrem dinamicamente as dependências de imagem base ao criar uma imagem de contêiner. Quando ele detecta uma atualização para a imagem base de uma imagem de aplicativo, você pode configurar uma tarefa de build para recompilar automaticamente as imagens do aplicativo que fazem referência a essa imagem base.

Prática recomendada: usar o Registro de Contêiner, o Key Vault e a notação para assinar digitalmente suas imagens de contêiner e configurar o cluster do AKS para permitir apenas imagens validadas

  • O Key Vault armazena chaves de assinatura que a ferramenta de notação usa. O plugin de notação do Key Vault (azure-kv) acessa essas chaves para assinar e verificar imagens de containers e outros artefatos. Você pode anexar essas assinaturas a imagens do Registro de Contêiner usando os comandos da CLI do Azure.

  • Os contêineres assinados garantem que as implantações sejam provenientes de uma fonte confiável e que os artefatos não sejam adulterados após a criação. O artefato assinado garante a integridade e autenticidade antes que o usuário faça o download de um artefato em qualquer ambiente, o que ajuda a prevenir ataques.

    • O Ratify verifica os metadados de segurança do artefato e impõe políticas de admissão antes da implantação em clusters do Kubernetes. A Integridade da Imagem do AKS usa o Ratify como um verificador interno para validar assinaturas de imagem e atestados SBOM antes que os pods sejam admitidos no cluster.

Fase de implantação

Durante a fase de implantação, desenvolvedores, operadores de aplicativos e equipes de operadores de cluster trabalham juntos para estabelecer os controles de segurança corretos para os pipelines de CD. Esses controles ajudam a implantar código em um ambiente de produção de maneira segura e automatizada.

Prática recomendada: controlar o acesso e o fluxo de trabalho do pipeline de implantação

  • Você pode proteger ramos importantes definindo regras de proteção de ramos. Essas regras definem se os colaboradores podem excluir ou forçar o envio por push para o branch. Eles também definem requisitos para pushes para o branch, como passar verificações de status ou um histórico de confirmação linear.

  • Use ambientes de implantação para configurar regras de proteção e valores confidenciais.

  • Use o recurso de aprovações e portões para controlar o fluxo de trabalho do pipeline de implantação. Por exemplo, você pode exigir aprovações manuais de uma equipe de segurança ou operações antes de implantar em um ambiente de produção.

Prática recomendada: proteger credenciais de implantação

  • OpenID Connect (OIDC) permite que seus fluxos de trabalho GitHub Action acessem recursos em Azure sem a necessidade de armazenar as credenciais de Azure como segredos de GitHub de longa duração.

  • Use uma abordagem baseada em pull para CI/CD com GitOps para transferir credenciais de segurança para o cluster do Kubernetes. Essa abordagem reduz a superfície de segurança e risco removendo credenciais de suas ferramentas de CI externas. Você também pode reduzir as conexões de entrada permitidas e limitar o acesso no nível do administrador aos clusters do Kubernetes.

Prática recomendada: executar o DAST para encontrar vulnerabilidades em seu aplicativo em execução

  • Use o GitHub Actions em fluxos de trabalho de implantação para executar testes de DAST (teste de segurança de aplicativo dinâmico).

  • Use ferramentas de software livre, como o ZAP , para fazer testes de penetração para vulnerabilidades comuns de aplicativos Web.

Prática recomendada: implantar imagens de contêiner somente de registros confiáveis

  • Use o Defender para Contêineres para habilitar o complemento do Azure Policy para Kubernetes.

  • Configure o Azure Policy para Kubernetes para restringir implantações de imagem de contêiner a registros confiáveis.

Fase de operação

Durante essa fase, execute tarefas de monitoramento de operação e monitoramento de segurança para monitorar, analisar e alertar proativamente sobre possíveis incidentes de segurança. Use ferramentas de observabilidade de produção como o Azure Monitor e o Microsoft Sentinel para monitorar e garantir a conformidade com os padrões de segurança da empresa.

Prática recomendada: usar o Defender para Nuvem para verificar e monitorar automaticamente as configurações de produção

  • Verifique continuamente para detectar alterações no estado de vulnerabilidades do seu aplicativo e implemente um processo para corrigir e substituir as imagens vulneráveis.

  • Implemente o monitoramento de configuração automatizado para sistemas operacionais.

    • Use as recomendações de contêiner no Defender para Nuvem (em Computação e aplicativos) para executar verificações de linha de base para seus clusters do AKS. O Defender para Nuvem exibe quaisquer problemas de configuração ou vulnerabilidades em seu painel.

    • Use o Defender para Nuvem e siga suas recomendações de proteção de rede para ajudar a proteger os recursos de rede do cluster do AKS.

  • Realize uma avaliação de vulnerabilidade para imagens armazenadas no Registro de Contêiner.

Prática recomendada: manter seus clusters do Kubernetes atualizados

  • O Kubernetes lança com frequência novas versões. Mantenha uma estratégia de gerenciamento de ciclo de vida para manter seus clusters suportados e atualizados. O AKS fornece ferramentas para gerenciar atualizações de cluster. Use os recursos de manutenção planejada do AKS para controlar quando ocorrem atualizações e janelas de manutenção.

  • Atualize os nós de trabalho do AKS com frequência. O Azure libera atualizações semanais de sistema operacional e tempo de execução. Aplique essas atualizações automaticamente por meio do modo autônomo ou manualmente por meio da CLI do Azure para obter mais controle.

Prática recomendada: usar o Azure Policy para proteger e governar seus clusters do AKS

  • Depois de instalar o complemento do Azure Policy para AKS, você pode aplicar definições de políticas individuais ou grupos de definições de política, chamadas de iniciativas ou conjuntos de políticas, ao cluster.

  • Use políticas internas do Azure para cenários comuns, como impedir a execução de contêineres privilegiados ou restringir endereços IP externos a uma lista de permissões. Você também pode criar políticas personalizadas para casos de uso específicos.

  • Aplique definições de política ao cluster e verifique se o Azure Policy impõe essas atribuições.

  • Use o Gatekeeper para configurar um controlador de admissão que permite ou nega implantações com base nas regras especificadas. Azure Policy estende o Gatekeeper.

  • Proteja o tráfego entre pods de carga de trabalho usando políticas de rede no AKS.

    • Use o CNI do Azure alimentado pelo Cilium como o mecanismo de política de rede. O Cilium usa um plano de dados baseado em eBPF e dá suporte a políticas nativas do Kubernetes, à política de camada 7 e à filtragem FQDN.

Prática recomendada: usar o Azure Monitor para monitoramento e alertas contínuos

  • Use o Azure Monitor para coletar logs e métricas do AKS. Colete métricas do Prometheus por meio do serviço gerenciado do Azure Monitor para Prometheus, consulte os logs de contêineres e de plataforma no Log Analytics e visualize a integridade do cluster por meio dos painéis do Azure Grafana Gerenciado.

    • O Azure Monitor estende o monitoramento contínuo para pipelines de lançamento. Use dados de monitoramento para aprovar ou reverter versões. O Azure Monitor também ingere logs de segurança e alertas sobre atividades suspeitas.

    • Integre suas instâncias do AKS ao Azure Monitor e defina as configurações de diagnóstico para o cluster.

      Para obter mais informações, consulte a linha de base de segurança do Azure para AKS.

Prática recomendada: usar o Defender para Nuvem para monitoramento ativo de ameaças

  • O Microsoft Defender para Nuvem oferece monitoramento ativo de ameaças para o AKS no nível do nó (ameaças de VM) e das cargas de trabalho do cluster.

  • Use o Defender para DevOps para obter visibilidade abrangente em todos os pipelines de CI/CD. Ele fornece às equipes de segurança e operação um painel centralizado. Você se beneficia especialmente dessa visibilidade centralizada ao usar plataformas de vários pipelines, como o Azure DevOps e o GitHub, ou executar pipelines em nuvens públicas.

  • O Defender para Key Vault detecta tentativas incomuns e suspeitas de acessar contas do cofre de chaves e pode enviar alertas aos administradores com base na configuração.

  • O Defender para Contêineres pode alertar sobre as vulnerabilidades encontradas em suas imagens de contêiner armazenadas no Registro de Contêiner.

Prática recomendada: habilitar o monitoramento de log centralizado e usar produtos SIEM para monitorar ameaças de segurança em tempo real

  • Conecte logs de diagnóstico do AKS ao Microsoft Sentinel para monitoramento de segurança centralizado com base em padrões e regras. O Microsoft Sentinel habilita esse acesso por meio de conectores de dados.

Prática recomendada: habilitar o log de auditoria para monitorar a atividade em seus clusters de produção

  • Use logs de atividade para monitorar ações em recursos do AKS e visualizar todas as atividades e seus status. Determine quem executou quais operações nos recursos.

  • Habilite o log de consultas do DNS (Sistema de Nomes de Domínio) aplicando a configuração documentada em seu ConfigMap personalizado do CoreDNS.

  • Monitore as tentativas de acessar credenciais desativadas.

    Integre a autenticação do usuário para o AKS com Microsoft Entra ID. Crie configurações de diagnóstico para o Microsoft Entra ID e envie os registros de auditoria e de entrada para um Log Analytics workspace. No workspace do Log Analytics, configure alertas para eventos de segurança, como tentativas de entrada de contas desativadas.

Prática recomendada: habilitar o diagnóstico em seus recursos do Azure

  • Habilite o diagnóstico do Azure em todos os recursos da sua carga de trabalho para acessar logs de plataforma que fornecem informações detalhadas de diagnóstico e auditoria. Você pode ingerir esses logs no Log Analytics ou em uma solução SIEM como o Microsoft Sentinel para monitoramento e alertas de segurança.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

  • Adnan Khan | Sr. Arquiteto de Soluções na Nuvem

Outros colaboradores:

  • Ayobami Ayodeji | Gerenciador de Programas 2
  • Ahmed Bham | Sr. Arquiteto de Soluções na Nuvem
  • Chad Kittel | Engenheiro de Software Principal – Padrões e Práticas do Azure
  • John Poole | Sr. Arquiteto de Soluções na Nuvem
  • Bahram Rushenas | Sr. Arquiteto de Soluções
  • Abed Sau | Sr. Arquiteto de Soluções na Nuvem

Para ver perfis de LinkedIn não públicos, entre em LinkedIn.

Próximas Etapas