Detetar vulnerabilidades de um cluster regulado pelo AKS para PCI-DSS 3.2.1 (Parte 5 de 9)

Este artigo descreve as considerações para um cluster do Serviço Kubernetes do Azure (AKS) 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 se aproveitam da carga de trabalho e das vulnerabilidades do sistema são vírus ou atualizações de software que produzem resultados indesejáveis. Detete ameaças precocemente e responda com mitigação em tempo hábil. Crie alertas críticos para atividades de carga de trabalho e estenda esses alertas aos principais processos do sistema. As ferramentas antivírus ou de monitoramento da integridade de arquivos (FIM) devem estar sempre em execução. Tenha um plano de resposta responsável e uma equipa que investigue os alertas e tome medidas.

Manter um programa de gerenciamento de vulnerabilidades

Requisito 5 — Proteja todos os sistemas contra malware e atualize regularmente software ou programas antivírus

Suporte ao recurso AKS

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

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

As suas responsabilidades

Certifique-se de que o software é especializado em Kubernetes e contêineres. Existem várias opções de software de terceiros. As opções mais populares incluem o Prisma Cloud e o Aquasec. Há também opções de código aberto, como Falco. É da sua responsabilidade certificar-se de que existem processos em vigor para garantir que o software de terceiros está atualizado. Além disso, a monitorização e alerta das soluções é da sua responsabilidade.

Requisito 6 — desenvolver e manter sistemas e aplicativos seguros

Suporte ao recurso AKS

Assim como outros serviços do Azure, o AKS segue os processos Microsoft SDL (Security Development Lifecycle) para segurança durante as fases do processo de desenvolvimento. Vários componentes são digitalizados a partir dos estágios iniciais de desenvolvimento e as lacunas de segurança são cobertas o mais cedo possível.

As imagens 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 limpas por meio de um pipeline DevSecOps.

Semanalmente, o AKS fornece novas imagens para os pools de nós. É sua responsabilidade aplicá-los para garantir a aplicação de patches e a atualização dos nós de trabalho dos Conjuntos de Escala de Máquina Virtual. Para obter mais informações, consulte Atualização de imagem do nó do Serviço Kubernetes do Azure (AKS).

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

O plano de controle AKS e os nós de trabalho são fortalecidos usando os benchmarks do Center for Internet Security (CIS), especificamente AKS CIS, Ubuntu CIS e Windows CIS.

O AKS integra-se com o Azure Container Registry. Use o Registro de Contêiner do Azure com recursos de verificação contínua no Microsoft Defender for Cloud 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, consulte Microsoft Defender for Containers.

As suas responsabilidades

Requisito 5.1

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

As 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 às VMs do nó AKS é restrito, proteja o sistema em cada camada onde o malware pode ser injetado nas VMs do nó. Inclua deteção e prevenção em nós de cluster, imagens de contêiner e interações de tempo de execução com o servidor de API do Kubernetes. Além do cluster, proteja esses componentes que interagem com o cluster e podem ter um software antivírus instalado de forma tradicional:

• Caixas de salto
• Agentes de construção

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

Requisito 5.1.1

Certifique-se de que os programas antivírus são capazes de detetar, remover e proteger contra todos os tipos conhecidos de software mal-intencionado.

As 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. Certifique-se de que o software é regularmente atualizado, testado e substituído se for considerado inadequado. Considere o software desenvolvido por fornecedores respeitáveis.

• Ferramentas de monitoramento que detetam vulnerabilidades de cluster.

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

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

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

  O objetivo da execução do agente é detetar atividades de cluster incomuns. Por exemplo, um aplicativo está tentando chamar o servidor de API? Algumas soluções geram um log de chamadas de API entre pods, geram relatórios e geram alertas. Certifique-se de revisar esses logs e tomar as medidas necessárias.

  Instale 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 altos privilégios e verificam tudo o que é executado no cluster e não apenas a carga de trabalho. Não devem tornar-se uma fonte de exfiltração de dados. Além disso, os ataques à cadeia de suprimentos são comuns para contêineres. Use estratégias de defesa em profundidade e certifique-se de que 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 caixas de salto, agentes de compilação e imagens de contêiner que interagem com o cluster.

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

  Importante

  A implementação de referência fornece uma implantação de espaço reservado DaemonSet 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 dos contentores. Execute ferramentas de varredura de contêineres no pipeline para detetar ameaças que possam vir por meio de imagens de contêiner, como a verificação de vulnerabilidade de CI/CD no Microsoft Defender for Containers. As opções de terceiros incluem Trivy e Clair. Quando estiver a criar imagens, procure sempre obter imagens sem distração. Essas imagens contêm apenas os binários essenciais na imagem base do Linux e reduzem a área de superfície para ataques. Use uma solução de verificação contínua, como a avaliação de vulnerabilidades no Microsoft Defender for Containers , para a verificação contínua de imagens já inativas em seus repositórios.

Requisito 5.1.2

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

As 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 Azure. Verifique se há atualizações do Azure para novos recursos que podem detetar vulnerabilidades e executar soluções antivírus em serviços hospedados no Azure.

Por exemplo, o armazenamento de blob deve ter triagem de reputação de malware para detetar uploads suspeitos. O Microsoft Defender for Storage inclui a verificação da reputação de malware. Além disso, considere se uma solução antivírus é necessária para tal serviço.

Requisito 5.2

Certifique-se de que todos os mecanismos antivírus são mantidos da seguinte forma:

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

As 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 a considerar:
  • O software antivírus deve acompanhar as atualizações de recursos mais recentes. Uma maneira é agendar atualizações como parte das atualizações da sua plataforma.
  • As atualizações de inteligência de segurança devem ser aplicadas assim que estiverem disponíveis para detetar e identificar as ameaças mais recentes. Opte por atualizações automáticas.
• Valide se as verificações de vulnerabilidade estão em execução, conforme programado.
• Retenha todos os logs gerados como resultado da verificação, que indicam componentes íntegros e não íntegros. O período de retenção recomendado é indicado no requisito 10.7, que é de um ano.
• Tenha um processo em vigor que faça a triagem e corrija os problemas detetados.

Para obter informações sobre como as atualizações antivírus do Microsoft Defender for Endpoint são aplicadas, consulte Inteligência de segurança e atualizações de produto do Microsoft Defender Antivírus.

Requisito 5.3

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

As suas responsabilidades

Você é responsável por configurar, monitorar e alertar o 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 registro das atividades de varredura. Certifique-se de que o processo de digitalização não registra nenhum dado do titular do cartão raspado do disco ou da memória.
• Defina alertas para atividades que possam causar um lapso inesperado na conformidade. Os alertas não devem ser desativados inadvertidamente.
• Restrinja as permissões para modificar a implantação do agente e todas as outras ferramentas de segurança críticas. Mantenha essas permissões separadas das permissões de implantação da carga de trabalho.
• Não implante cargas de trabalho se os agentes de segurança não estiverem sendo executados conforme o esperado.

Requisito 5.4

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

As 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.

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

Manter documentação sobre procedimentos operacionais padrão para avaliar e remediar problemas. As pessoas que operam ambientes regulamentados devem ser educadas, informadas e incentivadas a apoiar as garantias de segurança. Isto é importante para as pessoas que fazem parte do processo de aprovação do ponto de vista político.

Requisito 6.1

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

As suas responsabilidades

Ter processos que verifiquem as vulnerabilidades detetadas e sejam classificados adequadamente. O Microsoft Defender for Cloud mostra recomendações e alertas, com base no tipo de recurso e na sua gravidade e ambiente. A maioria dos alertas tem táticas MITRE ATT&CK® que podem ajudá-lo a entender a intenção da cadeia de matar. Certifique-se de ter um plano de correção para investigar e mitigar 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. Você pode visualizar os resultados no Microsoft Defender for Cloud.

Para obter mais informações, consulte Proteção de contêiner no Defender for Cloud.

Requisito 6.2

Certifique-se de que todos os componentes do sistema e software estão protegidos contra vulnerabilidades conhecidas instalando patches de segurança fornecidos pelo fornecedor aplicáveis. Instale patches de segurança críticos dentro de um mês após o lançamento.

As suas responsabilidades

• Para evitar ataques à cadeia de suprimentos de fornecedores terceirizados, certifique-se de que todas as dependências sejam confiáveis. É importante que você escolha fornecedores que sejam respeitáveis e confiáveis.

• Semanalmente, o AKS fornece novas imagens para os pools de nós. Essas imagens não são aplicadas automaticamente. Aplique-os assim que estiverem disponíveis. Você pode atualizar manual ou automaticamente através do Node Image Update. Para obter mais informações, consulte Atualização de imagem do nó do Serviço Kubernetes do Azure (AKS)

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

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

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

• Estenda o processo de aplicação de patches para recursos fora do cluster que você provisiona, como caixas de salto e agentes de compilação.

• Mantenha-se atualizado com as versões AKS suportadas. Se o seu desenho ou modelo utilizar uma versão que tenha chegado ao fim da sua vida útil, atualize para uma versão atual. Para obter mais informações, consulte Versões compatíveis do AKS.

Requisito 6.3

Desenvolva aplicações de software internas e externas (incluindo acesso administrativo baseado na Web a aplicações) de forma segura, da seguinte forma:

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

As suas responsabilidades

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

Várias estruturas da indústria mapeiam o ciclo de vida, como a estrutura NIST . As funções NIST — Identificar, Proteger, Detetar, Responder e Recuperar — fornecem estratégias para controles preventivos em cada fase.

O Microsoft SDL (Security Development Lifecycle) fornece práticas recomendadas, ferramentas e processos de segurança durante as fases do processo de desenvolvimento. As práticas do Microsoft SDL são seguidas para todos os serviços do Azure, incluindo o AKS. Também seguimos a estrutura de Garantia de Segurança Operacional (OSA) para operar serviços em nuvem. Certifique-se de que tem um processo semelhante. Essas práticas são publicadas para ajudá-lo a proteger seus aplicativos.

• Microsoft SDL
• Microsoft OSA

Requisito 6.3.1

Remova contas de aplicativos de desenvolvimento, teste e/ou personalizadas, IDs de usuário e senhas antes que os aplicativos fiquem ativos ou sejam liberados para os clientes.

As 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 única. Alguns deles têm altos privilégios. Desative esses usuários usando o recurso Desativar contas locais do AKS.

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

Requisito 6.3.2

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

• As alterações de código são revisadas por indivíduos diferentes do autor do código de origem e por indivíduos com conhecimento sobre técnicas de revisão de código e práticas de codificação seguras.
• As revisões de código garantem que o código seja desenvolvido de acordo com as diretrizes de codificação segura
• As correções apropriadas são implementadas antes da liberação.
• Os resultados da revisão de código são revisados e aprovados pela gerência antes do lançamento.

As suas responsabilidades

Todo o software instalado no cluster é originado do seu registro de contêiner. Semelhante ao código do aplicativo, tem processos e pessoas examinando imagens do Azure e de terceiros (Dockerfile e OCI). Além disso:

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

  Certifique-se de que seus pipelines de implantação estejam fechados de tal forma que as imagens de inicialização do cluster e sua carga de trabalho tenham passado por uma revisão e/ou porta de quarentena. Mantenha o histórico sobre como e quais processos foram usados antes de serem puxados 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, o uso de imagens sem distribuição minimizará a superfície de ataque das imagens 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 benchmarks do CIS. Para obter mais informações, consulte Benchmarks do Center for Internet Security (CIS).

O Registro de Contêiner do Azure com verificação contínua no Microsoft Defender for Cloud 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, consulte Segurança de contêiner.

Requisito 6.4

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

As suas responsabilidades

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

Requisitos 6.4.1 e 6.4.2

• Separe os ambientes de desenvolvimento/teste dos ambientes de produção e imponha a separação com controles de acesso.
• Separação de tarefas entre ambientes de desenvolvimento/teste e produção.

As 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 o Bridge to Kubernetes em seus clusters de produção. Use clusters dedicados para cargas de trabalho que não sejam de produção.

• Certifique-se de que seus ambientes de produção não permitam o acesso à rede a ambientes de pré-produção e vice-versa.

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

  Use grupos do Microsoft Entra 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 de produção. Uma maneira é usar o nome do cluster (ou outro identificador opaco) no nome do grupo, para ser explícito nas associações.

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

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

  Não use a mesma identidade gerenciada atribuída pelo usuário para nenhum recurso na pré-produção e na produção. Esta recomendação aplica-se a todos os recursos que suportam identidades geridas atribuídas pelo utilizador, não apenas ao recurso implementado no 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 just-in-time (JIT) 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 em tempo real) não são usados para testes ou desenvolvimento.

As suas responsabilidades

Certifique-se de que os dados CHD não fluam para o ambiente de desenvolvimento/teste. Tenha 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 pelas partes responsáveis.

Requisito 6.4.4

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

As suas responsabilidades

Remova dados de configuração padrão, dados de exemplo e dados de teste conhecidos no sistema antes de implantar na produção. Não utilize os dados do 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 de alteração documentada pelas partes autorizadas.
• 6.4.5.3 Testes de funcionalidade para verificar se a alteração não afeta negativamente a segurança do sistema.
• 6.4.5.4 Procedimentos de back-out.

As suas responsabilidades

Estes pontos de orientação correspondem aos requisitos anteriores:

• 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 infraestrutura como código (IaC). Por exemplo, com um arquivo Bicep ou um modelo do Azure Resource Manager (modelo ARM), você pode visualizar as alterações da implantação usando a operação hipotética. Para obter mais informações, consulte Implantação do bíceps Operações hipotéticas para suas alterações de infraestrutura.

• Implemente portas em seus pipelines de implantação que validem a aprovação de alterações para implantações regulares. Documente a justificação para destacamentos de emergência em que os portões possam ter sido contornados.

  Defina os níveis e a profundidade das alterações. Certifique-se de que a equipe concorda com a definição de mudanças 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, da infraestrutura e do pipeline devem ter uma compreensão clara dos níveis e validar em relação a esses critérios.

• Teste os recursos de segurança. Certifique-se de que as transações sintéticas estão testando as preocupações de segurança (permitir e negar). Certifique-se também de que esses testes sintéticos estão sendo executados em ambientes de pré-produção.

• Tenha um processo de back-out caso uma correção de segurança tenha resultados inesperados. Uma estratégia comum é implantar mantendo o 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 escopo para suas unidades de implantação.

Requisito 6.5

Resolva as vulnerabilidades de codificação comuns nos processos de desenvolvimento de software da seguinte forma:

• Treine os desenvolvedores pelo menos anualmente em técnicas de codificação seguras atualizadas, incluindo como evitar vulnerabilidades comuns de codificação.
• Desenvolva aplicações baseadas em diretrizes de codificação segura.

As suas responsabilidades

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

• Diretrizes de codificação segura
• DevOps seguro
• Recursos seguros do ciclo de vida do desenvolvimento

Requisito 6.6

Para aplicações Web voltadas para o público, aborde novas ameaças e vulnerabilidades de forma contínua. Verifique se esses aplicativos estão protegidos contra ataques conhecidos por um dos seguintes métodos:

• Analise aplicativos da Web voltados para o público usando ferramentas ou métodos manuais ou automatizados de avaliação de segurança de vulnerabilidades de aplicativos. Realizar uma avaliação de vulnerabilidade pelo menos anualmente e após quaisquer alterações.

  Nota

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

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

As suas responsabilidades

Tenha verificações para detetar o tráfego proveniente da Internet pública usando um firewall de aplicativo da Web (WAF). Nessa arquitetura, o Gateway de Aplicativo do Azure verifica todo o tráfego de entrada usando seu WAF integrado. O WAF é baseado no Core Rule set (CRS) do Open Web Application Security Project (OWASP). Se os controles técnicos não estiverem em vigor, tenha controles compensadores. Uma maneira é através da inspeção manual do código.

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

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

Realizar testes de penetração focados no código da aplicação. Dessa forma, os profissionais que não fazem parte da equipe do aplicativo encontrarão lacunas de segurança (como injeção de SQL e travessia de diretório) coletando informações, analisando vulnerabilidades e relatando. Neste exercício, os profissionais podem precisar de acesso a dados sensíveis. Para garantir que a intenção não seja usada indevidamente, siga as orientações fornecidas nas Regras de Engajamento de Testes de Penetração.

Requisito 6.7

Certifique-se de que as políticas de segurança e os procedimentos operacionais para desenvolver e manter sistemas e aplicativos seguros estejam documentados, em uso e conhecidos por todas as partes afetadas.

As suas responsabilidades

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

O Microsoft SDL fornece práticas recomendadas, ferramentas e processos para segurança durante as fases do processo de desenvolvimento. As práticas de SDL da Microsoft são seguidas rigorosamente quando criamos software na Microsoft. Também seguimos a estrutura de Garantia de Segurança Operacional (OSA) para operar serviços em nuvem. Essas práticas são publicadas para ajudá-lo a proteger seus aplicativos.

• Microsoft SDL
• Microsoft OSA

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

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

As pessoas que operam em ambientes regulamentados devem ser educadas, informadas e incentivadas a apoiar as garantias de segurança. É importante para as pessoas que fazem parte do processo de aprovação do ponto de vista político.

Próximos passos

Restrinja o acesso aos dados do titular do cartão por necessidade de conhecimento da empresa. Identifique e autentique o acesso aos componentes do sistema. Restrinja o acesso físico aos dados do titular do cartão.