Detectar vulnerabilidades de um cluster regulamentado do AKS para PCI-DSS 3.2.1 (Parte 5 de 9)

AKS (Serviço de Kubernetes do Azure)
Gateway de Aplicativo do Azure
Microsoft Defender para Nuvem

Este artigo descreve as considerações para um cluster do AKS (Serviço de Kubernetes do Azure) configurado de acordo com o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI-DSS 3.2.1).

Este artigo faz parte de uma série. Leia a introdução.

Como qualquer solução de nuvem, uma carga de trabalho PCI está sujeita a ameaças de rede, identidade e dados. Exemplos comuns de fontes que aproveitam as vulnerabilidades da carga de trabalho e do sistema são vírus ou atualizações de software que produzem resultados indesejáveis. Detecte ameaças antecipadamente e responda com mitigação em tempo hábil. Crie alertas críticos para atividades de carga de trabalho e estenda esses alertas para os principais processos do sistema. As ferramentas FIM (monitoramento de integridade de arquivo) ou antivírus devem estar sempre em execução. Tenha um plano de resposta responsável e uma equipe que investigue os alertas e tome ação.

Importante

As diretrizes e a implementação se baseiam na arquitetura de linha de base do AKS. Essa arquitetura é baseada em uma topologia hub e spoke. A rede virtual do hub contém o firewall para controlar o tráfego de saída, o tráfego de gateway de redes locais e uma terceira rede para manutenção. A rede virtual spoke contém o cluster do AKS que fornece o CDE (ambiente de dados do titular do cartão) e hospeda a carga de trabalho do PCI DSS.

Logotipo do GitHubGitHub: cluster de linha de base do AKS (Serviço de Kubernetes do Azure) para cargas de trabalho regulamentadas demonstra uma infraestrutura regulamentada. A implementação ilustra a configuração de ferramentas de segurança em várias fases do ciclo de vida de arquitetura e desenvolvimento. Isso inclui exemplos de agentes de segurança no cluster do tipo traga seu próprio e ferramentas de segurança fornecidas pelo Azure, por exemplo, o Microsoft Defender para Nuvem.

Manter um Programa de Gerenciamento de Vulnerabilidades

Requisito 5: proteger todos os sistemas contra malware e atualizar regularmente softwares ou programas antivírus

Suporte ao recurso do AKS

O AKS não se comporta como um host de aplicativo tradicional. As VMs de nó em um cluster do AKS têm exposição limitada e foram projetadas para não serem acessadas diretamente. Como as VMs de nó não são equivalentes a VMs tradicionais, você não pode usar ferramentas comuns de VM. Portanto, as recomendações nesta seção são aplicadas por meio de constructos nativos do Kubernetes. Aplicar esses requisitos diretamente no nível da VM pode fazer com que o cluster fique sem suporte.

Você precisará implantar o software antimalware de sua escolha no DaemonSets que será executado em um pod em cada nó.

Suas responsabilidades

Verifique se o software é especializado em Kubernetes e contêineres. Há várias opções de software de terceiros. As opções mais conhecidas incluem Prisma Cloud e Aquasec. Há também opções de código aberto, como o Falco. É sua responsabilidade garantir que haja processos em vigor para garantir que o software de terceiros esteja atualizado. Além disso, monitorar e alertar sobre as soluções é sua responsabilidade.

Requisito Responsabilidade
Requisito 5.1 Implantar o software antivírus em todos os sistemas geralmente afetados por software mal-intencionado (particularmente computadores pessoais e servidores).
Requisito 5.2 Certificar-se de que todos os mecanismos antivírus sejam mantidos do seguinte modo:
Requisito 5.3 Verifique se os mecanismos antivírus estão em execução ativamente e não podem ser desabilitados ou alterados pelos usuários, a menos que especificamente autorizados pelo gerenciamento caso a caso por um período de tempo limitado.
Requisito 5.4 Garantir que políticas de segurança e procedimentos operacionais para proteção dos sistemas contra malware estejam documentados, em uso e sejam do conhecimento de todas as partes afetadas.

Requisito 6: desenvolver e manter os aplicativos e sistemas protegidos

Suporte ao recurso do AKS

Assim como outros serviços do Azure, o AKS segue os processos do Microsoft SDL (Ciclo de Vida de Desenvolvimento de Segurança) para segurança durante as fases do processo de desenvolvimento. Vários componentes são verificados nos estágios iniciais de desenvolvimento e as lacunas de segurança são abordadas o mais cedo possível.

As imagens do AKS seguem uma abordagem de SLA do FedRAMP, que exige que as vulnerabilidades nas imagens sejam corrigidas dentro de 30 dias. Para impor esse requisito, todas as imagens são sanitizadas por meio de um pipeline de DevSecOps.

Semanalmente, o AKS fornece novas imagens para os pools de nós. É sua responsabilidade aplicá-los para garantir a aplicação de patch e atualização de nós de trabalho Conjuntos de Dimensionamento de Máquinas Virtuais. Para obter mais informações, confira Atualização de uma imagem de nó do AKS (Serviço de Kubernetes do Azure).

Para o plano de controle do AKS, o AKS instala ou atualiza os patches de segurança. Eles são atualizados a cada 24 horas.

O plano de controle do AKS e os nós de trabalho são protegidos contra o CIS (Center for Internet Security). Especificamente o CIS do AKS, o Ubuntu CIS e o CIS do Windows.

O AKS se integra com o ACR (Registro de Contêiner do Azure). Use o ACR com recursos de verificação contínua no Microsoft Defender para Nuvem para identificar imagens e aplicativos vulneráveis em vários níveis de risco. Para obter informações sobre verificação de imagem e controle de risco, confira o Microsoft Defender para Contêineres.

Suas responsabilidades

Requisito Responsabilidade
Requisito 6.1 Estabeleça um processo para identificar vulnerabilidades de segurança, usando fontes externas respeitáveis para informações de vulnerabilidade de segurança e atribua uma classificação de risco (por exemplo, como "alta", "média" ou "baixa") a vulnerabilidades de segurança recém-descobertas.
Requisito 6.2 Verificar se todos os componentes de sistema e software estão protegidos contra vulnerabilidades conhecidas instalando os patches de segurança aplicáveis distribuídos pelo fornecedor. Instale os patches de segurança essenciais no prazo de um mês a contar do lançamento.
Requisito 6.3 Desenvolver aplicativos internos e externos de software (incluindo acesso administrativo baseado na Web aos aplicativos) com segurança.
Requisito 6.4 Seguir processos e procedimentos de controle de alterações para todas as alterações de componentes do sistema.
Requisito 6.5 Lidar com vulnerabilidades de codificação comuns nos processos de desenvolvimento de software.
Requisito 6.6 Para aplicativos Web voltados ao público, tratar novas ameaças e vulnerabilidades de modo contínuo e verificar se esses aplicativos estão protegidos contra ataques conhecidos.
Requisito 6.7 Garantir que políticas de segurança e procedimentos operacionais para desenvolver e manter sistemas e aplicativos de segurança estejam documentados, em uso e sejam do conhecimento de todas as partes afetadas.

Requisito 5.1

Implante software antivírus em todos os sistemas comumente afetados por software mal-intencionado, em particular computadores e servidores pessoais.

Suas responsabilidades

É sua responsabilidade proteger a carga de trabalho, a infraestrutura e os pipelines de implantação escolhendo um software antimalware apropriado.

Como o acesso a VMs de nó do AKS é restrito, proteja o sistema em camadas que podem injetar malware em VMs de nó. Inclua detecção e prevenção em nós de cluster, imagens de contêiner e interações de runtime com o servidor de API do Kubernetes. Além do cluster, proteja esses componentes que interagem com o cluster e podem ter o software antivírus instalado de maneira tradicional:

  • Jump boxes
  • Agente de compilação

Alinhe suas atividades de verificação com o SDL ( Security Development Lifecycle ). Seguir o SDL garante que a verificação de vários componentes da arquitetura comece nos estágios iniciais de lacunas de desenvolvimento e segurança o mais cedo possível.

Requisito 5.1.1

Faça com que os programas antivírus sejam capazes de detectar, remover e proteger contra todos os tipos conhecidos de software mal-intencionado.

Suas responsabilidades

Saiba mais sobre o conjunto de recursos de cada oferta de software e a profundidade de verificação que ele pode fazer. O software deve bloquear ameaças comuns e monitorar novas ameaças. Verifique se o software está atualizado, foi testado e é substituído regularmente se ele considerado inadequado. Considere o software desenvolvido por fornecedores respeitáveis.

  • Ferramentas de monitoramento que detectam vulnerabilidades de cluster.

    No AKS, você não pode executar soluções de VM tradicionais baseadas em agente diretamente em VMs de nó. Você precisará implantar o software antimalware no DaemonSets que será executado em um pod em cada nó.

    Escolha o software especializado em Kubernetes e contêineres. Há várias opções de software de terceiros. As opções mais conhecidas incluem Prisma Cloud e Aquasec. Há também opções de código aberto, como o Falco.

    Quando implantados, eles são executados como agentes no cluster que verifica todos os pools de nós do usuário e do sistema. Embora o AKS use pools de nós do sistema para seus binários do sistema de runtime, a computação subjacente ainda é sua responsabilidade.

    A finalidade de executar o agente é detectar atividades incomuns de cluster. Por exemplo, um aplicativo está tentando chamar o servidor de API? Algumas soluções geram um log de chamadas à API entre pods, geram relatórios e geram alertas. Certifique-se de examinar esses logs e executar as ações necessárias.

    Instale os agentes de segurança imediatamente após a inicialização do cluster para minimizar lacunas não monitoradas entre o cluster e a implantação de recursos do AKS.

    Os agentes de segurança são executados com privilégios elevados e verificam tudo o que é executado no cluster e não apenas a carga de trabalho. Eles não devem se tornar uma fonte de exfiltração dos dados. Além disso, ataques da cadeia de fornecedores são comuns para contêineres. Use estratégias de defesa detalhadas e verifique se o software e todas as dependências são confiáveis.

    Execute também software antivírus em ativos externos que participam de operações de cluster. Alguns exemplos incluem jump boxes, agentes de build e imagens de contêiner que interagem com o cluster.

    Quando o agente examina, ele não deve bloquear ou interferir nas operações críticas do cluster, como bloqueando arquivos. A configuração incorreta pode causar problemas de estabilidade e pode renderizar o cluster sem suporte.

    Importante

    A implementação de referência fornece uma implantação DaemonSet de espaço reservado para executar um agente antimalware. O agente será executado em cada VM de nó no cluster. Coloque sua escolha de software antimalware nesta implantação.

  • Manter a segurança do contêiner. Execute ferramentas de verificação de contêiner no pipeline para detectar ameaças que podem vir por meio de imagens de contêiner, como a verificação de vulnerabilidades de CI/CD no Microsoft Defender para Contêineres. As opções de terceiros incluem Trivy e Clair. Quando você estiver criando imagens, sempre tente obter imagens sem intervalo. Essas imagens contêm apenas os binários essenciais na imagem base do Linux e reduzem a área da superfície para ataques. Use uma solução de verificação contínua como a avaliação de vulnerabilidade no Microsoft Defender para Contêineres para verificação contínua de imagens já em repouso em seus repositórios.

Requisito 5.1.2

Para sistemas normalmente não direcionados ou afetados por software mal-intencionado, execute avaliações periódicas para identificar e avaliar ameaças de malware em evolução para confirmar se eles continuam a não exigir software antivírus.

Suas responsabilidades

Vulnerabilidades comuns podem afetar componentes fora do cluster. Acompanhe as vulnerabilidades de segurança observando CVEs e outros alertas de segurança da plataforma do Azure. Verifique se há atualizações do Azure para novos recursos que podem detectar vulnerabilidades e executar soluções antivírus em serviços hospedados no Azure.

Por exemplo, o armazenamento de blobs deve ter uma triagem de reputação de malware para detectar uploads suspeitos. Um novo recurso, Microsoft Defender para Armazenamento, inclui a triagem de reputação de malware. Além disso, considere se uma solução antivírus é necessária para esse serviço.

Requisito 5.2

Verifique se todos os mecanismos antivírus são mantidos da seguinte maneira:

  • Estejam sempre atualizados.
  • Executem verificações periódicas
  • Gere logs de auditoria, que são retidos de acordo com o Requisito 10.7 do PCI DSS.

Suas responsabilidades

  • Verifique se o cluster está protegido contra novos ataques usando a versão mais recente do software antivírus. Há dois tipos de atualizações que devem ser considerados:
    • O software antivírus deve acompanhar as atualizações de recursos mais recentes. Um modo é agendar atualizações como parte das atualizações da plataforma.
    • As atualizações de inteligência de segurança devem ser aplicadas assim que estiverem disponíveis para detectar e identificar as ameaças mais recentes. Optar por atualizações automáticas.
  • Valide se as verificações de vulnerabilidade estão em execução, conforme agendado.
  • Retenha logs gerados como resultado da verificação que indica componentes íntegros e não íntegros. O período de retenção recomendado é dado no Requisito 10.7, que é um ano.
  • Tenha um processo em vigor que faça a triagem e corrija os problemas detectados.

Para obter informações sobre como as atualizações de antivírus do Microsoft Defender são aplicadas, confira Gerenciar atualizações de antivírus do Microsoft Defender e aplicar linhas de base.

Requisito 5.3

Os recursos antivírus devem estar em execução ativa e não podem ser desabilitados ou alterados pelos usuários. Exceto quando autorizado pelo gerenciamento caso a caso por um período de tempo limitado.

Suas responsabilidades

Você é responsável por configurar o monitoramento e o alerta do agente de segurança. Crie alertas críticos não apenas para a carga de trabalho, mas também para os principais processos do sistema. O agente deve estar sempre em execução. Responda aos alertas gerados pelo software antimalware.

  • Mantenha um rastro de log das atividades de verificação. Verifique se o processo de verificação não registra nenhum dado do titular do cartão extraídos do disco ou da memória.
  • Defina alertas para atividades que podem causar um lapso inesperado de conformidade. Os alertas não devem ser desativados inadvertidamente.
  • Restrinja as permissões para modificar a implantação do agente (e outras ferramentas de segurança críticas). Mantenha essas permissões separadas das permissões de implantação de carga de trabalho.
  • Não implante cargas de trabalho se os agentes de segurança não estiverem em execução conforme o esperado.

Requisito 5.4

Verifique se as políticas de segurança e os procedimentos operacionais para proteger sistemas contra malware estão documentados, usados e comunicados a todas as partes afetadas.

Suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre o processo e as políticas, especialmente detalhes sobre a solução antivírus usada para proteger o sistema. Inclua informações como onde, no ciclo do produto, as atualizações de inteligência de segurança são mantidas, a frequência das verificações e informações sobre os recursos de verificação em tempo real.

Tenha políticas de retenção para armazenar logs. Talvez você queira ter armazenamento de longo prazo para fins de conformidade.

Mantenha a documentação sobre procedimentos operacionais padrão para avaliar e corrigir problemas. As pessoas que operam ambientes regulamentados devem ser instruídas, informadas e incentivadas para dar suporte às garantias de segurança. Isso é importante para as pessoas que fazem parte do processo de aprovação do ponto de vista da política.

Requisito 6.1

Estabeleça um processo para identificar vulnerabilidades de segurança, usando fontes externas respeitáveis para informações de vulnerabilidade de segurança e atribua uma classificação de risco (por exemplo, alta, média ou baixa) a vulnerabilidades de segurança recém-descobertas.

Suas responsabilidades

Tenha processos que verificam as vulnerabilidades detectadas e sejam classificados adequadamente. O Microsoft Defender para Nuvem mostra recomendações e alertas, tipo de recurso baseado e sua gravidade, ambiente. A maioria dos alertas tem táticas MITRE ATT&CK® que podem ajudar você a entender a intenção de encerramento de cadeia. Verifique se você tem um plano de correção para investigar e atenuar o problema.

No AKS, você pode usar o Registro de Contêiner do Azure em combinação com a verificação contínua para identificar imagens e aplicativos vulneráveis em vários níveis de risco. É possível exibir resultados no Microsoft Defender para Nuvem.

Para obter mais informações, confira Registro de Contêiner.

Requisito 6.2

Verificar se todos os componentes de sistema e software estão protegidos contra vulnerabilidades conhecidas instalando os patches de segurança aplicáveis distribuídos pelo fornecedor. Instale os patches de segurança essenciais no prazo de um mês a contar do lançamento.

Suas responsabilidades

  • Para evitar ataques da cadeia de fornecedores de terceiros, verifique se todas as dependências são confiáveis. É importante que você escolha um fornecedor confiável e respeitável.

  • Semanalmente, o AKS fornece novas imagens para os pools de nós. Essas imagens não são aplicadas automaticamente. Aplique-as assim que estiverem disponíveis. Você pode atualizar manual ou automaticamente por meio da Atualização de Imagem do Nó. Para obter mais informações, confira Atualização de uma imagem de nó do AKS (Serviço de Kubernetes do Azure)

    Para o plano de controle do AKS, o AKS instala ou atualiza os patches de segurança.

  • A cada 24 horas, os nós do AKS baixam e instalam automaticamente patches de segurança e do sistema operacional, individualmente. Seu firewall não deverá bloquear esse tráfego se você quiser receber essas atualizações.

    Considere habilitar recursos de relatório no agente de segurança para obter informações sobre as atualizações aplicadas. Algumas atualizações de segurança exigem reinicialização. Examine os alertas e tome medidas para garantir o tempo mínimo ou zero de inatividade do aplicativo com essas reinicializações. Uma opção de código aberto para executar reinicializações de maneira controlada é o Kured (daemon de reinicialização do Kubernetes).

  • Estenda o processo de aplicação de patch para recursos fora do cluster que você provisiona, como jump boxes e agentes de build.

  • Mantenha-se atualizado com as versões do AKS com suporte. Se o design usar uma versão que tenha atingido o fim da vida útil, atualize para uma versão atual. Para mais informações, confira Versões do AKS com suporte.

Requisito 6.3

Desenvolver aplicativos de software internos e externos (incluindo acesso administrativo baseado na Web aos aplicativos) com segurança, da seguinte maneira:

  • De acordo com o PCI DSS (por exemplo, autenticação de segurança e registro em log)
  • Com base em padrões e/ou melhores práticas do setor.
  • Incorporação da segurança da informação em todo o ciclo de vida de desenvolvimento de software que se aplica a todos os softwares desenvolvidos internamente, incluindo software personalizado ou sob medida desenvolvido por terceiros.

Suas responsabilidades

Integre e priorize as opções de segurança como parte do ciclo de vida da carga de trabalho e das operações.

Várias estruturas do setor são mapeadas para o ciclo de vida, como a estrutura NIST. As funções NIST (Identificar, Proteger, Detectar, Responder e Recuperar) fornecem estratégias para controles preventivos em cada fase.

O SDL (Ciclo de Vida de Desenvolvimento de Segurança) da Microsoft fornece as melhores práticas, ferramentas e processos de segurança em todas as fases do processo de desenvolvimento. As práticas de SDL da Microsoft são seguidas para todos os serviços do Azure, incluindo o AKS. Também seguimos a estrutura do OSA (Garantia de Segurança Operacional) para serviços de nuvem operacionais. Verifique se você tem um processo semelhante. Essas práticas são publicadas para ajudar você a proteger seus aplicativos.

Requisito 6.3.1

Remover o desenvolvimento, o teste e/ou as contas de aplicativo personalizado, as IDs de usuário e as senhas antes que os aplicativos fiquem ativos ou sejam disponibilizados para os clientes.

Suas responsabilidades

Como parte da criação do cluster, vários usuários locais do Kubernetes são criados por padrão. Esses usuários não podem ser auditados porque não representam uma identidade exclusiva. Alguns deles têm privilégios altos. Desabilite esses usuários usando o recurso Desabilitar contas locais do AKS.

Para outras considerações, consulte as diretrizes no padrão oficial PCI-DSS 3.2.1.

Requisito 6.3.2

Examine o código personalizado antes do lançamento para produção ou clientes para identificar qualquer possível vulnerabilidade de codificação (usando processos manuais ou automatizados) para incluir o seguinte:

  • As alterações de código são examinadas por indivíduos que não sejam o autor do código original e por indivíduos que tenham conhecimento sobre técnicas de revisão de código e práticas de codificação seguras.
  • As revisões de código fazem com que o código seja desenvolvido de acordo com diretrizes de codificação seguras
  • As correções apropriadas são implementadas antes do lançamento.
  • Os resultados da revisão de código são analisados e aprovados pela gerência antes do lançamento.
Suas responsabilidades

Todos os softwares instalados no cluster são provenientes do Registro de contêiner. Semelhante ao código do aplicativo, ter processos e pessoas examinando o Azure e imagens de terceiros (DockerFile e OCI). Também:

  • Inicie a verificação de imagens de contêiner dos estágios iniciais quando o cluster for criado. Torne o processo de verificação uma parte dos pipelines de integração contínua/implantação contínua.

    Verifique se os pipelines de implantação estão fechados de modo que as imagens de inicialização de cluster e sua carga de trabalho tenham passado por uma revisão e/ou portão de quarentena. Mantenha o histórico sobre como e quais processos foram usados antes de terem pull efetuado para o cluster.

  • Reduza o tamanho da imagem. Normalmente, as imagens contêm mais binários do que o necessário. Reduzir o tamanho da imagem não só tem benefícios de desempenho, mas também limita a superfície de ataque. Por exemplo, não usar intervalos minimizará as imagens de base do Linux.

  • Use ferramentas de análise estática que verificam a integridade do Dockerfile e dos manifestos. As opções de terceiros incluem Dockle e Trivy.

  • Use apenas imagens assinadas.

  • Entenda (e aceite) a imagem base fornecida pelo Azure e como ela está em conformidade com os parâmetros de comparação do CIS. Para obter mais informações, confira Parâmetros de comparação do CIS (Center for Internet Security).

O Registro de Contêiner do Azure com a verificação contínua no Microsoft Defender para Nuvem ajudará a identificar imagens vulneráveis e vários riscos que isso pode representar para a carga de trabalho. Para obter mais informações sobre verificação de imagem e controle de risco, confira Segurança do contêiner.

Requisito 6.4

Seguir processos e procedimentos de controle de alterações para todas as alterações de componentes do sistema.

Suas responsabilidades

Certifique-se de documentar os processos de controle de alterações do documento e projetar os pipelines de implantação de acordo com esses processos. Inclua outros processos para detectar situações em que os processos e os pipelines reais não se alinham.

Requisito 6.4.1, 6.4.2

  • Separar ambientes de desenvolvimento/teste dos ambientes de produção e impor a separação com controles de acesso.
  • Separação de funções entre ambientes de desenvolvimento/teste e produção.
Suas responsabilidades

Mantenha ambientes e funções de produção e pré-produção separados que operam nesses ambientes.

  • Não use seu cluster de produção para fins de desenvolvimento/teste. Por exemplo, não instale a ponte para o Kubernetes em seus clusters de produção. Use clusters dedicados para cargas de trabalho que não são de produção.

  • Verifique se os ambientes de produção não permitem acesso à rede a ambientes de pré-produção e vice-versa.

  • Não reutilize identidades do sistema em ambientes de pré-produção e produção.

    Use grupos do Azure AD para grupos como administradores de cluster ou entidades de pipeline. Não use grupos generalizados ou comuns como controles de acesso. Não reutilize esses grupos entre clusters de pré-produção e produção. Um modo é usar o nome do cluster (ou outro identificador opaco) no nome do grupo, para ser explícito em associações.

    Use as funções de RBAC (controle de acesso baseado em função) do Azure adequadamente entre ambientes. Normalmente, mais funções e direitos são atribuídos a ambientes de pré-produção.

    Identidades somente na pré-produção (concedidas a pipelines ou equipes de engenharia de software) não devem receber acesso na produção. Por outro lado, todas as identidades somente de produção (como pipelines) não devem receber acesso em clusters de pré-produção.

    Não use a mesma identidade gerenciada pelo usuário para qualquer recurso em pré-produção e em produção. Essa recomendação se aplica a todos os recursos que dão suporte à identidade gerenciada pelo usuário, não apenas ao recurso implantado em seu cluster. Como regra, os recursos do Azure que exigem identidades devem ter sua própria identidade distinta em vez de compartilhá-la com outros recursos.

  • Use o acesso JIT (just-in-time) para acesso de alto privilégio, inclusive em clusters de pré-produção, se possível. Use políticas de acesso condicional em clusters de pré-produção e produção.

Requisito 6.4.3

Os dados de produção (PANs dinâmicos) não são usados para teste ou desenvolvimento.

Suas responsabilidades

Verifique se os dados CHD não fluem para o ambiente de desenvolvimento/teste. Tenha uma documentação clara que forneça o procedimento para mover dados da produção para o desenvolvimento/teste. A remoção de dados reais deve ser incluída nesse procedimento e aprovada por partes responsável.

Requisito 6.4.4

Remoção de dados de teste e contas de componentes do sistema antes que o sistema se torne ativo ou entre em produção.

Suas responsabilidades

Remova dados de configuração padrão, dados de exemplo e dados de teste conhecidos no sistema antes de implantar em produção. Não use dados de titular do cartão para fins de teste.

Requisito 6.4.5

Os procedimentos de controle de alterações para a implementação de patches de segurança e modificações de software devem incluir o seguinte:

  • 6.4.5.1 Documentação do impacto.
  • 6.4.5.2 Aprovação da alteração documentada por pessoas autorizadas.
  • 6.4.5.3 Testar a funcionalidade para verificar que a alteração não afeta negativamente a segurança do sistema.
  • 6.4.5.4 Procedimentos de recuo.
Suas responsabilidades

Esses pontos das diretrizes são mapeados para os requisitos vistos acima:

  • Documente as alterações de infraestrutura esperadas como resultado dos patches de segurança e modificações de software. Esse processo é mais fácil com a abordagem de IaC (infraestrutura como código). Por exemplo, com um modelo do ARM (Azure Resource Manager) para implantação, você pode visualizar as alterações com uma operação de teste de hipóteses. Para obter mais informações, confira a Operação de teste de hipóteses de implantação de modelo do ARM para suas alterações de infraestrutura.

  • Implemente portões em seus pipelines de implantação que validem a aprovação de alterações para implantações regulares. Documente a justificativa para implantações de emergência em que os portões podem ter sido ignorados.

    Defina os níveis e a profundidade das alterações. Verifique se a equipe concorda com a definição de alterações significativas, em vez de pequenas alterações. Se for prático, automatize a descoberta de algumas dessas alterações. Os revisores da carga de trabalho, infraestrutura e pipeline devem ter uma compreensão clara dos níveis e validar esses critérios.

  • Teste as funcionalidades de segurança. Verifique se as transações sintéticas estão testando as preocupações de segurança (permissão e negação). Verifique também se esses testes sintéticos estão em execução em ambientes de pré-produção.

  • Tenha um processo de recuo caso uma correção de segurança tenha resultados inesperados. Uma estratégia comum é implantar um estado anterior usando implantações azul-verde. Para cargas de trabalho, incluindo bancos de dados, tenha uma estratégia que funcione para sua topologia específica e tenha o escopo de suas unidades de implantação.

Requisito 6.5

Lidar com vulnerabilidades de codificação comuns nos processos de desenvolvimento de software da seguinte maneira:

  • Treinar os desenvolvedores pelo menos anualmente em técnicas de codificação seguras atualizadas, incluindo como evitar vulnerabilidades de codificação comuns.
  • Desenvolver aplicativos com base em diretrizes de codificação seguras.

Suas responsabilidades

É fundamental que as equipes de aplicativos e as equipes de operações sejam instruídas, informadas e incentivadas para dar suporte às atividades de verificação da carga de trabalho e da infraestrutura. Aqui estão alguns recursos:

Requisito 6.6

Para aplicativos Web voltados para o público, resolva novas ameaças e vulnerabilidades continuamente. Verifique se esses aplicativos estão protegidos contra ataques conhecidos por qualquer um dos seguintes métodos:

  • Examine os aplicativos Web voltados para o público usando ferramentas ou métodos de avaliação de segurança de vulnerabilidade de aplicativos manuais ou automatizados. Execute uma avaliação de vulnerabilidade pelo menos anualmente e depois de qualquer alteração.

    Observação

    Essa avaliação não é a mesma que as verificações de vulnerabilidade executadas como parte do Requisito 11.2.

  • Instale uma solução automatizada que detecta e impede ataques baseados na Web. Por exemplo, um firewall de aplicativo Web. Implante na frente de aplicativos Web voltados para o público e avalie ativamente todo o tráfego.

Suas responsabilidades

Faça verificações para detectar o tráfego proveniente da Internet pública usando um WAF (Firewall de Aplicativo Web). Nesta arquitetura, o Gateway de Aplicativo do Azure verifica todo o tráfego de entrada usando seu WAF integrado. O WAF é baseado em CRS (conjuntos de regras principais) do OWASP (Open Web Application Security Project). Se os controles técnicos não estiverem em vigor, tenha controles de compensação. Um modo é por meio da inspeção manual de código.

Verifique se você está usando as versões mais recentes do conjunto de regras e aplique regras relevantes à sua carga de trabalho. As regras devem ser executadas no modo Prevenção. Você pode impor esse requisito adicionando uma instância do Azure Policy que verifica se o WAF está habilitado e está operando nesse modo.

Mantenha os logs gerados pelo WAF do Gateway de Aplicativo para obter detalhes sobre as ameaças detectadas. Ajuste as regras conforme necessário.

Realize testes de penetração focados no código do aplicativo. Dessa forma, os profissionais que não fazem parte da equipe de aplicativos encontrarão lacunas de segurança (como injeção de SQL e passagem de diretório) coletando informações, analisando vulnerabilidades e relatando. Neste exercício, os praticantes podem precisar de acesso a dados confidenciais. Para garantir que a intenção não seja usada incorretamente, siga as diretrizes fornecidas em Regras de Participação de Teste de Penetração.

Requisito 6.7

Verifique se as políticas de segurança e os procedimentos operacionais para desenvolver e manter sistemas e aplicativos seguros estão documentados, em uso e conhecidos por todas as partes afetadas.

Suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre os processos e as políticas. Suas equipes devem ser treinadas para priorizar as opções de segurança como parte do ciclo de vida da carga de trabalho e das operações.

O SDL da Microsoft fornece as melhores práticas, ferramentas e processos de segurança em todas as fases do processo de desenvolvimento. As práticas de SDL da Microsoft são seguidas estritamente de modo interno na forma como criamos software na Microsoft. Também seguimos a estrutura do OSA (Garantia de Segurança Operacional) para serviços de nuvem operacionais. Essas práticas são publicadas para ajudar você a proteger seus aplicativos.

Mantenha uma documentação completa para testes de penetração que descrevem o escopo do teste, os processos de triagem e a estratégia de correção para os problemas detectados. Se ocorrer um incidente, incorpore a avaliação do Requisito 6 como parte da análise de causa-raiz. Se forem detectadas lacunas (por exemplo, uma violação de regra OWASP será detectada), feche essas lacunas.

Na documentação, tenha diretrizes claras sobre o status de proteção de WAF esperado.

As pessoas que operam ambientes regulamentados devem ser instruídas, informadas e incentivadas para dar suporte às garantias de segurança. É importante para as pessoas que fazem parte do processo de aprovação do ponto de vista da política.

Próximas etapas

Restringir o acesso aos dados do titular do cartão segundo a necessidade de conhecimento da empresa. Identificar e autenticar o acesso aos componentes do sistema. Restringir o acesso físico aos dados do titular do cartão.