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

Azure Boards

Azure DevOps

Azure Monitor

Azure Pipelines

Azure Policy

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. Alguns dos benefícios da segurança de construção nas práticas de DevOps incluem:

Tornando seus aplicativos e sistemas mais seguros, fornecendo visibilidade sobre ameaças à segurança e impedindo que vulnerabilidades atinjam ambientes implantados
Aumentando a conscientização de segurança com suas equipes de desenvolvimento e operação
Incorporando processos de segurança automatizados em seu ciclo de vida de desenvolvimento de software
Reduzindo o custo para corrigir encontrando problemas de segurança no início dos estágios de desenvolvimento e design

Quando DevSecOps é aplicado ao AKS (Serviço de Kubernetes do Azure), funções de organização diferentes podem ter considerações diferentes para implementar a segurança. Exemplos dessas diferentes funções de organização são:

Desenvolvedores criando aplicativos seguros em execução no AKS
Engenheiros de Nuvem criando infraestrutura segura do AKS
Várias equipes de operações que podem controlar clusters ou monitorar problemas de segurança

Este artigo é dividido em diferentes estágios do ciclo de vida do DevOps com considerações e recomendações para inserir controles de segurança e práticas recomendadas de segurança. Este guia inclui processos e ferramentas comuns para incorporar em pipelines de CI/CD (integração contínua e entrega contínua), optando por ferramentas internas fáceis de usar quando disponíveis.

Como pré-requisito para este artigo, recomendamos que você examine Compilar e implantar aplicativos no AKS usando DevOps e GitOps.

Fluxo de processo

Baixe um arquivo do Visio dessa arquitetura.

Observação

Embora este artigo faça referência ao AKS e ao GitHub, essas recomendações se aplicam a qualquer orquestração de contêiner ou plataforma CI/CD. Embora os detalhes da implementação possam variar, a maioria dos conceitos e práticas mencionadas em cada estágio ainda são relevantes e aplicáveis.

A ID do Microsoft Entra é configurada como o provedor de identidade do GitHub. Configure a MFA (autenticação multifator) para ajudar a fornecer segurança de autenticação extra.
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.
Os desenvolvedores confirmam o código do aplicativo em um repositório corporativo e controlado do GitHub Enterprise.
O GitHub Enterprise integra a verificação automática de dependência e segurança por meio da Segurança Avançada do GitHub.
As solicitações pull disparam builds de CI (integração contínua) e testes automatizados por meio do GitHub Actions.
O fluxo de trabalho de build de CI por meio do GitHub Actions gera uma imagem de contêiner do Docker armazenada no Registro de Contêiner do Azure.
Você pode introduzir aprovações manuais para implantações em ambientes específicos, como produção, como parte do fluxo de trabalho de CD (entrega contínua) no GitHub Actions.
O GitHub Actions habilita o CD para o 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.
O Microsoft Defender é usado para verificar o Registro de Contêiner do Azure, 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 ao carregá-la no Registro de Contêiner.
2. Você também pode usar o Defender para Contêineres para executar verificações do seu ambiente do AKS e fornece proteção contra ameaças em tempo de execução para seus clusters do AKS.
3. O Microsoft Defender para Key Vault detecta tentativas suspeitas e prejudiciais de acessar contas do cofre de chaves.
O Azure Policy pode ser aplicado ao Registro de Contêiner e ao AKS (Serviço de Kubernetes do Azure) para conformidade e imposição de políticas. As políticas de segurança comuns para o Registro de Contêiner e o AKS são internas para habilitação rápida.
O Azure Key Vault é usado para injetar segredos e credenciais com segurança em um aplicativo em runtime, separando informações confidenciais dos desenvolvedores.
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.
O monitoramento contínuo do cluster do AKS pode ser configurado usando os insights do Azure Monitor e do Contêiner para ingerir métricas de desempenho e analisar logs de aplicativo e segurança.
1. Os insights de contêiner recuperam métricas de desempenho e logs de aplicativos e clusters.
2. Os logs de diagnóstico e de aplicativo são extraídos para um workspace do Azure Log Analytics para executar consultas de log.
O Microsoft Sentinel, que é uma solução de SIEM (gerenciamento de eventos e informações de segurança), pode ser usado para ingerir e analisar ainda mais os logs de cluster do AKS para quaisquer ameaças de segurança com base em padrões e regras definidos.
Open-Source ferramentas como ZAP (Proxy de Ataque Zed) (ZAP) podem ser usadas para fazer testes de penetração para aplicativos e serviços Web.
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 de vários pipelines, incluindo o GitHub e o Azure DevOps.

Visão geral e responsabilidades dos membros da equipe

Considere gerenciar a complexidade do DevSecOps em implantações de solução baseadas em Kubernetes como uma separação de preocupações. Qual equipe em um ambiente empresarial deve se preocupar com cada aspecto da implantação? Quais ferramentas e processos uma equipe deve empregar para alcançar melhor seus objetivos? Nesta seção, vamos percorrer as funções comuns de desenvolvedores, operadores de aplicativos (engenheiros de confiabilidade do site), operadores de cluster e equipes de segurança.

Desenvolvedores

Os desenvolvedores são responsáveis por escrever o código do aplicativo. Eles também são responsáveis por confirmar o código no repositório designado. Uma das responsabilidades importantes dos desenvolvedores também inclui a criação e a execução de scripts para testes automatizados para garantir que seu código funcione conforme o esperado e se integre perfeitamente ao restante do aplicativo. Eles 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 na nuvem usando contêineres e o 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 para automatizar a supervisão de sistemas de software grandes. Eles servem como uma ponte entre as equipes de operadores de desenvolvimento e cluster e ajudam a estabelecer e monitorar os objetivos de nível de serviço e os orçamentos de erros. Dessa forma, eles ajudam a gerenciar implantações de aplicativos e geralmente gravam arquivos YAML (manifesto do Kubernetes).

Operadores de cluster

Os operadores de cluster são responsáveis por configurar e gerenciar 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 várias ferramentas de monitoramento, como insights de contêiner do Azure Monitor e Prometheus/Grafana para monitorar a integridade geral do cluster. Eles são responsáveis por aplicação de patch, atualizações de cluster, permissões e controle de acesso baseado em função no cluster. Nas equipes do DevSecOps, eles garantem que os clusters atendam aos requisitos de segurança da equipe e trabalhem com a equipe de segurança para criar esses padrões.

Equipe de segurança

A equipe de segurança é responsável por desenvolver padrões de segurança e aplicá-los. Algumas equipes podem ser responsáveis por criar e selecionar o Azure Policy que é imposto nas assinaturas e grupos de recursos que mantêm os clusters. Eles monitoram problemas de segurança e, juntamente com as outras equipes, garantem que a segurança seja trazida à vanguarda de cada etapa do processo de DevSecOps.

Estágios de ciclo de vida de DevSecOps

Os controles de segurança são implementados em cada fase do SDLC (ciclo de vida de desenvolvimento de software). Essa implementação é uma parte fundamental de uma estratégia de DevSecOps e da abordagem shift-left.

Baixe um arquivo do Visio dessa arquitetura.

Fase do plano

A fase do plano geralmente tem a menor quantidade de automação, mas tem implicações de segurança importantes que afetam significativamente os 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. Incluir os stakeholders de segurança nesta fase de design e planejamento garante que os requisitos de segurança e os problemas de segurança sejam devidamente contabilizados ou mitigados.

Prática recomendada – Criar uma plataforma de aplicativo mais segura

A criação de uma plataforma hospedada pelo AKS mais segura é uma etapa importante para ajudar a garantir que a segurança seja incorporada ao sistema em todas as camadas, começando pela própria plataforma. A plataforma pode incluir componentes internos para o cluster (como agentes de política e segurança de runtime) e componentes externos ao AKS (como firewalls de rede e registros de contêiner). Para obter mais informações, consulte o AKS em uma zona de destino do aplicativo, que inclui áreas de design críticas, como segurança, identidade e topologia de rede.

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. Ele é usado para modelar e encontrar ameaças em um sistema para que as vulnerabilidades possam ser resolvidas antes de qualquer desenvolvimento de código ou alterações em um sistema. A modelagem de ameaças pode ocorrer em momentos diferentes, disparados por eventos como uma alteração significativa de software, alteração de arquitetura de solução ou incidentes de segurança.
Recomendamos que você use o modelo de ameaça STRIDE. Essa metodologia começa com um diagrama de fluxo de dados e usa as categorias de ameaça STRIDE mnemonic (Falsificação, Adulteração, Divulgação de Informações, Repúdio, Negação de Serviço e Elevação de Privilégio) para capacitar as equipes a identificar, atenuar e validar riscos. Ele também inclui uma ferramenta de modelagem para notar e visualizar componentes do sistema, fluxos de dados e limites de segurança. A criação de modelagem de ameaças em seus processos do SDLC apresenta novos processos e mais trabalhos para manter modelos de ameaças atualizados. Mas ajuda a garantir que a segurança esteja em vigor antecipadamente, o que ajuda a reduzir o custo potencial de lidar com problemas de segurança encontrados em estágios SDLC posteriores.

Prática recomendada – aplicar o WAF (Azure Well Architect Framework)

Aplique as práticas recomendadas do pilar de segurança do WAF que fornecem diretrizes para itens como gerenciamento de identidade, segurança do aplicativo, proteção de infraestrutura, segurança de data e DevOps, conforme se aplica a ambientes nativos de nuvem.
Aplique as práticas recomendadas operacionais do WAF à medida que se aplica ao DevSecOps e ao monitoramento de seus ambientes de produção.

Fase de desenvolvimento

"Mudar para a esquerda" é um locatário chave da mentalidade de DevSecOps. Esse processo começa antes mesmo de o código ser confirmado em um repositório e implantado por meio de um pipeline. A adoção de práticas recomendadas de codificação segura e o uso de ferramentas e plug-ins do IDE para análise de código durante a fase de desenvolvimento podem ajudar a resolver problemas de segurança anteriormente no ciclo de vida de desenvolvimento quando forem mais fáceis de corrigir.

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

Usando as melhores práticas e listas de verificação de codificação segura estabelecidas, você pode ajudar a proteger seu código contra vulnerabilidades comuns, como injeção e design inseguro. A fundação 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 ao desenvolver aplicativos ou serviços Web voltados para o público.
Além das práticas recomendadas de segurança geral, você também deve examinar práticas de codificação seguras para seus runtimes específicos de linguagem de programação, como Java e .NET.
Você pode impor padrões de registro em log para proteger informações confidenciais contra vazamento em logs de aplicativos. As estruturas de log mais populares, como log4j e 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

IDEs mais populares, como Visual Studio, Visual Studio 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ê pode ter introduzido ao escrever o código do aplicativo.

O SonarLint é um plug-in IDE disponível para linguagens e ambientes de desenvolvedor mais populares. O SonarLint fornece comentários valiosos e examina 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 Synk , por exemplo, também examina a origem do aplicativo e as dependências de terceiros e alerta você se alguma vulnerabilidade for encontrada.
O plug-in SARIF (Formato de Intercâmbio de Resultados de Análise Estática) para Visual Studio e Visual Studio Code permite que você exiba facilmente vulnerabilidades de ferramentas de SAST (Teste de Segurança de Aplicativo Estático) populares de maneira intuitiva e fácil de ler 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 que haja um uso consistente de ramificação em toda a empresa. Metodologias como o fluxo de versão e o fluxo do GitHub têm diretrizes estruturadas sobre como os branches devem ser usados 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. Esses branches devem ter estabelecido políticas de mesclagem antes que as alterações possam ser mescladas ou confirmadas nelas. Algumas práticas recomendadas incluem:
- Impedir que outros desenvolvedores confirmem o código diretamente no branch principal.
- Estabeleça um processo de revisão de pares e exija um número mínimo de aprovações antes que as alterações possam ser mescladas a um branch principal. Você pode facilmente configurar e impor esses controles com o GitHub. O GitHub também permite designar grupos de aprovadores autorizados, se necessário, para ambientes fechados.
Use ganchos de pré-confirmação para verificar se há informações confidenciais no código-fonte do aplicativo e impedir que uma confirmação ocorra se um problema de segurança for encontrado.
- Use os ganchos de pré-confirmação internos fornecidos pelo GitHub que podem ser facilmente configurados para um projeto específico. Por exemplo, há ganchos pré-criados para verificar segredos, chaves privadas e credenciais e impedir uma confirmação se algum desses problemas for encontrado.
Estabeleça o controle de acesso baseado em função 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 é sua cadeia de suprimentos para implantações de produção.
- Aplique funções de usuário ou grupo estabelecidas em sua organização. Funções como Administrador, Desenvolvedor, Administrador de Segurança e Operador devem ser criadas para agrupar indivíduos com base em sua função e função específicas em relação aos fluxos de trabalho de CI/CD.
Habilite a auditoria de seus fluxos de trabalho para que haja transparência e rastreabilidade para configuração e outras alterações em relação aos pipelines de CI/CD.

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

Use imagens leves com um volume mínimo do sistema operacional para reduzir a área de ataque de superfície geral. Considere imagens mínimas, como Alpine ou até mesmo imagens sem distribuição que contêm apenas seu aplicativo e seu runtime associado. Mariner, a distribuição do Linux de software livre da Microsoft, é uma distribuição leve e protegida projetada para o AKS hospedar cargas de trabalho em contêineres.
Use apenas imagens base confiáveis ao compilar seus contêineres. Essas imagens base devem ser recuperadas de um registro privado que é frequentemente verificado quanto a vulnerabilidades.
Use ferramentas de desenvolvedor para avaliar vulnerabilidades de imagem localmente.
- Trivy é um exemplo de uma ferramenta de software livre que você pode usar para analisar vulnerabilidades de segurança em suas imagens de contêiner.
Impedir o acesso/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 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 os engenheiros de confiabilidade do site e as equipes de segurança para integrar verificações automatizadas de sua fonte de aplicativo em seus pipelines de build de CI. Os pipelines são configurados para habilitar práticas de segurança, como SAST, SCA e verificação de segredos usando as ferramentas e extensões de segurança da plataforma CI/CD.

Prática recomendada – executar a SAST (Análise de Código Estático) para encontrar possíveis vulnerabilidades no código-fonte do aplicativo

Use os recursos de verificação de Segurança Avançada do GitHub para verificação de código e CodeQL.
- A verificação de código é um recurso que você usa para analisar o código em um repositório GitHub para encontrar vulnerabilidades de segurança e erros de codificação. Todos os problemas identificados pela análise são mostrados no GitHub Enterprise Cloud.
- Se a verificação de código encontrar uma possível vulnerabilidade ou erro em seu código, o GitHub exibirá um alerta no repositório.
- Você também pode configurar regras de branch para verificações de status necessárias, por exemplo, para impor que um branch de recursos esteja atualizado com o branch base antes de mesclar qualquer novo código. Essa prática garante que seu branch sempre tenha sido testado com o código mais recente.
Use ferramentas como pontuação de kube para analisar seus objetos de implantação do Kubernetes.
- kube-score é uma ferramenta que faz a análise de código estático das definições de objeto do Kubernetes.
- A saída é uma lista de recomendações do que você pode melhorar para ajudar a tornar seu aplicativo mais seguro e resiliente.

Prática recomendada – executar a verificação secreta para impedir o uso fraudulento de segredos que foram confirmados acidentalmente em um repositório

Quando a verificação secreta é habilitada para um repositório, o GitHub verifica o código em busca de padrões que correspondam a segredos usados por muitos provedores de serviços.
O GitHub também 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 no código-fonte e na saída do build.
- A verificação secreta pode ser executada como parte da extensão DevOps de Segurança da Microsoft para Azure DevOps.

Prática recomendada – Usar ferramentas de SCA (análise de composição de software) para rastrear componentes de software livre na base de código e detectar quaisquer vulnerabilidades nas dependências

A revisão de dependência permite capturar dependências inseguras antes de apresentá-las ao seu ambiente e fornece informações sobre licença, dependentes e idade das dependências. Ele fornece uma visualização facilmente compreensível de alterações de dependência com uma diferença avançada na guia "Arquivos Alterados" de uma solicitação de pull.
O Dependabot executa uma verificação para detectar dependências inseguras e envia alertas dependabot quando um novo aviso é adicionado ao Banco de Dados de Consultoria do GitHub ou quando o grafo de dependência de um repositório é alterado.

Prática recomendada – habilitar verificações de segurança de modelos de IaC (Infraestrutura como Código) para minimizar configurações incorretas de nuvem que atingem ambientes de produçã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.

Prática recomendada – verificar 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 AWS para notificá-lo se houver vulnerabilidades conhecidas em suas imagens.
O Azure Policy pode ser habilitado para fazer uma avaliação de vulnerabilidade em todas as imagens armazenadas no Registro de Contêiner e fornecer informações detalhadas sobre cada descoberta.

Prática recomendada – criar automaticamente novas imagens na atualização de imagem base

As Tarefas do Registro de Contêiner do Azure descobrem dinamicamente as dependências de imagem base ao criar uma imagem de contêiner. Como resultado, ele pode detectar quando a imagem base de uma imagem de aplicativo é atualizada. Com uma tarefa de build pré-configurada, as tarefas do Registro de Contêiner podem recompilar automaticamente cada imagem de aplicativo que referencia a imagem base.

Prática recomendada – Use o Registro de Contêiner, o Azure 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 Azure Key Vault armazena uma chave de assinatura que pode ser usada por notação com o plug-in do Key Vault de notação (azure-kv) para assinar e verificar imagens de contêiner e outros artefatos. O Registro de Contêiner permite anexar essas assinaturas usando os comandos da CLI do Azure.
Os contêineres assinados permitem que os usuários verifiquem se as implantações foram criadas a partir de uma entidade confiável e verificam se um artefato não foi adulterado desde sua criação. O artefato assinado garante integridade e autenticidade antes que o usuário efetue pull de um artefato em qualquer ambiente, o que ajuda a evitar ataques.
- O Ratify permite que os clusters do Kubernetes verifiquem os metadados de segurança do artefato antes da implantação e admitam a implantação somente aqueles que estão em conformidade com uma política de admissão criada.

Fase de implantação

Durante a fase de implantação, desenvolvedores, operadores de aplicativos e equipes de operadores de cluster trabalham juntos no estabelecimento dos controles de segurança corretos para os pipelines de CD (implantação contínua) implantarem código em um ambiente de produção de maneira mais segura e automatizada.

Prática recomendada – Controlar o acesso e o fluxo de trabalho do pipeline de implantação

Você pode proteger branches importantes definindo regras de proteção de branch. Essas regras definem se os colaboradores podem excluir ou forçar o envio por push para o branch. Eles também definem requisitos para quaisquer pushes para o branch, como passar verificações de status ou um histórico de confirmação linear.
Usando ambientes para implantação, você pode configurar ambientes com regras de proteção e segredos.
Você pode aproveitar o recurso 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 uma implantação em um ambiente de produção.

Prática recomendada – Credenciais de implantação seguras

O OIDC (OpenID Connect) permite que seus fluxos de trabalho do GitHub Action acessem recursos no Azure sem a necessidade de armazenar as credenciais do Azure como segredos do GitHub de longa duração.
Usando ambientes para implantação, você pode configurar ambientes com regras de proteção e segredos.
- Uma abordagem baseada em pull para CI/CD com GitOps permite que você mude as credenciais de segurança para o cluster do Kubernetes, o que reduz a superfície de segurança e risco removendo as credenciais de serem armazenadas em 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 DAST (testes dinâmicos de segurança de aplicativo) 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.
Habilite o Azure Policy para que as imagens de contêiner só possam ser implantadas de registros confiáveis.

Fase de operação

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

Prática recomendada – Usar o Microsoft Defender para nuvem para habilitar a verificação automatizada e o monitoramento de suas configurações de produção

Execute a verificação contínua para detectar o descompasso no estado de vulnerabilidade do aplicativo e implementar 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 do Microsoft Defender para Nuvem (na seção Computação e aplicativos ) para executar verificações de linha de base para seus clusters do AKS. Seja notificado no painel do Microsoft Defender para Nuvem quando forem encontrados problemas de configuração ou vulnerabilidades.
- Use o Microsoft Defender para Nuvem e siga suas recomendações de proteção de rede para ajudar a proteger os recursos de rede que estão sendo usados pelos clusters do AKS.
Realize uma avaliação de vulnerabilidade para imagens armazenadas no Registro de Contêiner.
- Implemente verificações contínuas para executar imagens no Registro de Contêiner habilitando o Defender para Contêineres.

Prática recomendada – manter seus clusters do Kubernetes atualizados

As versões do Kubernetes são distribuídas com frequência. É importante ter uma estratégia de gerenciamento de ciclo de vida em vigor para garantir que você não fique para trás e sem suporte. O AKS é uma oferta gerenciada que fornece ferramentas e flexibilidade para gerenciar esse processo de atualização. Você pode usar os recursos de manutenção planejada da plataforma AKS para ter mais controle sobre as janelas e atualizações de manutenção.
Os nós de trabalho do AKS devem ser atualizados com mais frequência. Fornecemos atualizações semanais de so e runtime, que podem ser aplicadas automaticamente por meio do modo autônomo ou por meio da CLI do Azure para obter mais controle e atualizações abrangentes.

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ítica individuais ou grupos de definições de política chamadas iniciativas (também chamadas de conjuntos de políticas) ao cluster.
Use políticas internas do Azure para cenários comuns, como impedir que contêineres privilegiados sejam executados ou apenas aprovar IPs externos com 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 essas atribuições estão sendo impostas.
Use o Gatekeeper para configurar um controlador de admissão que permite ou nega implantações com base nas regras especificadas. O Azure Policy estende o Gatekeeper.
Proteja o tráfego entre pods de carga de trabalho usando políticas de rede no AKS.
- Instale o mecanismo de política de rede e crie políticas de rede do Kubernetes para controlar o fluxo de tráfego entre pods no AKS. A política de rede pode ser usada para nós e pods baseados em Linux ou windows no AKS.

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. Você obtém insights sobre a disponibilidade e o desempenho de seu aplicativo e infraestrutura. Ele também fornece acesso a sinais para monitorar a integridade da solução e detectar atividade anormal antecipadamente.
- O monitoramento contínuo com o Azure Monitor se estende para liberar pipelines para versões de porta ou reversão com base nos dados de monitoramento. O Azure Monitor também ingere logs de segurança e pode alertar sobre atividades suspeitas.
- Integre suas instâncias do AKS ao Azure Monitor e defina as configurações de diagnóstico para o cluster.
  - Consulte a linha de base de segurança do Azure para o Serviço de Kubernetes do Azure.

Prática recomendada – Usar o Microsoft Defender para Nuvem para monitoramento ativo de ameaças

O Microsoft Defender para Nuvem fornece monitoramento ativo de ameaças no AKS no nível do nó (ameaças de VM) e para internos.
O Defender para DevOps deve ser usado para visibilidade abrangente e fornece equipes de segurança e operador com um painel centralizado para todos os pipelines de CI/CD. Essa funcionalidade é especialmente útil se você estiver usando plataformas de vários pipelines, como o Azure DevOps e o GitHub, ou estiver executando pipelines em nuvens públicas.
O Defender para Key Vault pode ser usado para detectar tentativas suspeitas incomuns de acessar contas do cofre de chaves e pode alertar os 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 à 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 Sentinel habilita esse acesso perfeitamente por meio de conectores de dados.

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

Use logs de atividades para monitorar ações em recursos do AKS para exibir todas as atividades e seus status. Determine quais operações foram executadas nos recursos e por quem.
Habilite o log de consultas DNS aplicando a configuração documentada em seu ConfigMap personalizado do CoreDNS.
Monitore as tentativas de acessar credenciais desativadas.
- Integre a autenticação de usuário para AKS com a ID do Microsoft Entra. Crie configurações de diagnóstico para a ID do Microsoft Entra, enviando os logs de auditoria e entrada para um workspace do Azure Log Analytics. Configure alertas desejados (como quando uma conta desativada tenta entrar) em um workspace do Azure Log Analytics.

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

Ao habilitar o diagnóstico do Azure em todos os recursos da carga de trabalho, você tem acesso a logs de plataforma que fornecem informações detalhadas de diagnóstico e auditoria para seus recursos do Azure. Esses logs podem ser ingeridos no Log Analytics ou em uma solução SIEM como o Microsoft Sentinel para monitoramento e alertas de segurança.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.

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