Monitorar operações de um cluster de linha de base do AKS para um PCI-DSS 3.2.1 (Parte 7 de 9)

Este artigo descreve as considerações para um cluster do AKS (Serviço de Kubernetes do Azure) que executa uma carga de trabalho em conformidade 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.

Monitorar e testar redes regularmente

Requisito 10 – controlar e monitorar todo o acesso aos recursos da rede e aos dados do titular do cartão

Suporte ao recurso do AKS

O Azure oferece o recurso Insights de Contêiner, que monitora contêineres, incluindo clusters do AKS. Para obter mais informações, confira Visão geral dos Insights de Contêiner.

O AKS fornece logs de auditoria em vários níveis, que podem ser úteis para proteger o sistema e os dados proativamente. Os logs de atividades fornecem informações sobre operações relacionadas ao gerenciamento de conta e segredo, gerenciamento de configuração de diagnóstico, gerenciamento de servidor e outras operações de acesso a recursos. Todos os logs são registrados com data, hora, identidade e outras informações detalhadas. Você também pode acessar todos os registros cronológicos de todas as chamadas à API feitas no cluster do AKS. Os logs incluem informações sobre o chamador, a hora em que a chamada foi feita, a origem em que a chamada foi iniciada e assim por diante. Para obter mais informações, confira Habilitar e examinar os logs do painel de controle do Kubernetes no AKS (Serviço de Kubernetes do Azure).

O RBAC (controle de acesso baseado em função) pode ser usado para gerenciar a política de acesso a recursos como uma prática padrão no Azure.

Todos os logs devem ser armazenados em uma conta de armazenamento de propriedade do cliente ou logs do Azure Monitor. Dessa forma, você pode gerar insights rapidamente de um grande volume de dados. Todos os logs são mantidos com pelo menos três cópias em uma região. Você pode ter mais cópias habilitando o backup ou a replicação entre regiões. Todas as entradas de log estão disponíveis somente por meio de canais HTTP(s) protegidos.

A estrutura de alertas do Azure permite que você configure alertas para detectar acesso suspeito. Você pode definir quais alertas precisam ser acionados e os eventos. Os usuários também podem verificar manualmente o log completo usando o Log Analytics com a funcionalidade de filtragem com base no tipo de atividade, conteúdo da atividade ou chamador da atividade.

Suas responsabilidades

Requisito	Responsabilidade
Requisito 10.1	Implementar trilhas de auditoria para vincular todo o acesso aos componentes do sistema a cada usuário individual.
Requisito 10.2	Implementar trilhas de auditoria automatizadas para todos os componentes do sistema para reconstruir os seguintes eventos:
Requisito 10.3	Registrar pelo menos as seguintes entradas de trilha de auditoria para todos os componentes do sistema para cada evento:
Requisito 10.4	Usando a tecnologia de sincronização de tempo, sincronizar todos os relógios e horários críticos do sistema e certificar-se de que os itens a seguir sejam implementados para adquirir, distribuir e armazenar o tempo.
Requisito 10.5	Proteger as trilhas de auditoria para que elas não possam ser alteradas.
Requisito 10.6	Examinar os logs e os eventos de segurança de todos os componentes do sistema para identificar anomalias ou atividades suspeitas.
Requisito 10.7	Manter o histórico de trilha de auditoria por pelo menos um ano, com um mínimo de três meses imediatamente disponíveis para análise (por exemplo, online, arquivado ou restaurável do backup).
Requisito 10.8	Requisitos adicionais somente para provedores de serviço: responder a falhas de controles de segurança críticos de maneira oportuna. Os processos para responder a falhas de controles de segurança precisam incluir
Requisito 10.9	Verificar se as políticas de segurança e os procedimentos operacionais para monitorar todo o acesso aos recursos de rede e aos dados de titulares de cartões estão documentados, em uso e são conhecidos por todas as partes afetadas.

Requisito 11 – Testar regularmente os sistemas e processos de segurança

Suporte ao recurso do AKS

O AKS é integrado aos serviços de monitoramento do Azure:

• O Microsoft Defender para Contêineres fornece muitos recursos de verificação de segurança. Por exemplo, o Microsoft Defender para Contêineres examina imagens extraídas, enviadas por push e importadas para registros de contêiner e fornece recomendações. Para obter detalhes, confira Avaliação de vulnerabilidade.

• O Azure Monitor pode ser usado para definir alertas com base no tipo de evento para proteger a integridade e a segurança do sistema. Quando há falhas de sistema esperadas em nós do AKS, o AKS restaura automaticamente o recurso em tempo hábil, sem interrupção no processamento do sistema.

Os clusters do AKS são protegidos por Gateway de Aplicativo do Azure com Firewall de Aplicativo Web (WAF) e podem ser configurados no modo de detecção para registrar alertas e ameaças. Um modo mais forte é o preventivo, que bloqueia ativamente invasões e ataques detectados. Para mais detalhes, confira Melhores práticas para conectividade de rede e segurança no Serviço de Kubernetes do Azure (AKS).

Suas responsabilidades

Requisito	Responsabilidade
Requisito 11.1	Trimestralmente, implementar processos para testar a presença de pontos de acesso sem fio (802.11) e detectar e identificar todos os pontos de acesso sem fio autorizados e não autorizados.
Requisito 11.2	Executar verificações de vulnerabilidade de rede interna e externa pelo menos trimestralmente e após qualquer alteração significativa na rede (como novas instalações de componentes do sistema, alterações na topologia de rede, modificações de regra de firewall, atualizações de produtos).
Requisito 11.3	Implementar uma metodologia de teste de penetração que inclua o seguinte:
Requisito 11.4	Usar técnicas de detecção de intrusão e/ou prevenção contra intrusão para detectar e/ou evitar invasões na rede.
Requisito 11.5	Pelo menos semanalmente, implantar um mecanismo de detecção de alteração (por exemplo, ferramentas de monitoramento de integridade de arquivo) para alertar a equipe sobre a modificação não autorizada (incluindo alterações, inclusões e exclusões) de arquivos críticos do sistema, arquivos de configuração ou arquivos de conteúdo; e configurar o software para executar comparações de arquivos críticos.
Requisito 11.6	Verificar se as políticas de segurança e os procedimentos operacionais para monitoramento e teste de segurança estão documentados, em uso e conhecidos para todas as partes afetadas.

Requisito 10.1

Implementar trilhas de auditoria para vincular todo o acesso aos componentes do sistema a cada usuário individual.

Suas responsabilidades

Recomendamos que você use operações de auditoria executadas em cada componente usando os seguintes métodos:

• Log de atividades do Azure Monitor. O log de atividades fornece informações sobre o tipo e a hora das operações de recursos do Azure. Ele também registra a identidade que iniciou a operação. Ele é habilitado por padrão, e as informações são coletadas assim que a operação de recurso é feita. A trilha de auditoria é somente gravação e não pode ser excluída.

  Os dados são retidos por 90 dias. Para opções de retenção mais longas, considere enviar entradas de log de atividades para os Logs do Azure Monitor e configurar uma política de retenção e arquivo morto.

  

• Configurações de Diagnóstico do Azure. Fornece informações de diagnóstico e auditoria dos recursos do Azure e da plataforma à qual a configuração se aplica. Recomendamos que você habilite as configurações de diagnóstico para o AKS e outros componentes no sistema, como Armazenamento de Blobs do Azure e Key Vault. Com base no tipo de recurso, você pode escolher o tipo de logs e dados de métrica a serem enviados para um destino. Seu destino de diagnóstico deve atender aos períodos de retenção necessários.

  • Configuração de diagnóstico para AKS. Nas categorias fornecidas do AKS, habilite os logs de auditoria do Kubernetes. As configurações de diagnóstico incluem kube-audit ou kube-audit-admine guard.

    Habilite kube-audit-admin para ver chamadas de servidor de API baseadas em log que podem modificar o estado do cluster. Se você precisar de uma trilha de auditoria de todas as interações do servidor de API (incluindo eventos que não modificam tais solicitações de leitura), habilite kube-audit em vez disso. Esses eventos podem ser prolíficos, criar ruídos e aumentar o custo de consumo. Esses logs têm informações sobre o acesso e o nome de identidade usados para fazer a solicitação.

    Habilite os logs guard para acompanhar auditorias gerenciadas do Azure AD e de RBAC (controle de acesso baseado em função).

  Além dos logs baseados no usuário, considere os logs do painel de controle do Kubernetes, incluindo kube-apiserver e kube-controller-manager. Esses logs normalmente não são associados ao usuário, mas podem ajudar a correlacionar as alterações do sistema que os usuários fizeram.

  Para obter mais informações, confira Exibir os logs de componentes do painel de controle.

  Essa implementação de referência permite logs cluster-autoscaler, kube-controller-managerkube-audit-admin, e guard e encaminhamentos para um workspace do Log Analytics. O período de retenção do workspace é definido como 90 dias.

  

• Serviço de Kubernetes do Azure (AKS) diagnóstico ajuda a detectar e solucionar problemas com o cluster, como falhas de nó. Ele também inclui dados de diagnóstico específicos da rede que não custam mais. Esses dados normalmente não são associados ao usuário, mas podem ajudar a correlacionar as alterações do sistema que os usuários fizeram. Para obter informações, consulte Serviço de Kubernetes do Azure diagnóstico.

Os mecanismos de trilha de auditoria anteriores devem ser implementados no momento da implantação do recurso. O Azure Policy também deve estar ativo para garantir que essas configurações não sejam desabilitadas inadvertidamente ou intencionalmente em seu CDE.

Requisito 10.2

Implementar trilhas de auditoria automatizadas para todos os componentes do sistema para reconstruir os seguintes eventos:

• 10.2.1 Todos os acessos de usuário individual aos dados
• 10.2.2 Todas as ações realizadas por qualquer pessoa com privilégios de administrador ou raiz
• 10.2.3 Acesso a todos os registros de auditoria
• 10.2.4 Tentativas inválidas de acesso lógico
• 10.2.5 Uso de e alterações em mecanismos de identificação e autenticação, incluindo, mas não se limitando à criação de novas contas e elevação de privilégios, e todas as alterações, adições ou exclusões a contas com privilégios raiz ou administrativo
• 10.2.6 Inicialização, interrupção ou pausa dos logs de auditoria
• 10.2.7 Criação e exclusão de objetos no nível do sistema

Suas responsabilidades

O AKS fornece logs de auditoria em vários níveis, conforme descrito no Requisito 10.1. Estes são alguns pontos principais:

• Por padrão, os logs de atividades fornecem informações sobre operações críticas de recursos do Azure. Todos os logs incluem status, hora e a identidade que iniciou a operação.
• Habilite as configurações de diagnóstico para acessar todos os registros de todas as chamadas à API feitas no cluster do AKS. Os logs fornecem detalhes sobre o solicitante, o carimbo de data/hora, a origem da solicitação e o conteúdo da solicitação. Armazene os logs em um workspace do Log Analytics com um período de retenção apropriado. Habilite o log do workspace do Log Analytics para garantir que até mesmo o acesso à trilha de auditoria seja registrado.
• Habilite a coleção syslog com o Container Insights para capturar logs de eventos de integridade e segurança do sistema operacional no nível do nó do AKS no workspace do Log Analytics. Esses logs também devem ser ingeridos em seu SIEM.
• Inclua o log de auditoria do sistema operacional e de uso para outros recursos de computação, como agentes de build e jump boxes. Desabilite o acesso aos sistemas diretamente como raiz. Verifique se todas as ações estão sendo executadas em uma identidade específica.
• Registre tentativas de acesso malsucedidas. Isso inclui solicitações de acesso a componentes como o Armazenamento do Azure, o Azure Key Vault, o servidor de API do AKS e qualquer acesso RDP/SSH em outros sistemas.
• Aproveite os recursos, oferecidos por agentes de segurança de terceiros, para ajudar a analisar os padrões de usuário dentro do cluster do AKS. Esses recursos podem ser úteis para dados de auditoria de acesso do usuário.

Requisito 10.3

Registrar pelo menos as seguintes entradas de trilha de auditoria para todos os componentes do sistema para cada evento:

• 10.3.1 Identificação de usuário
• 10.3.2 Tipo de evento
• 10.3.3 Data e hora
• 10.3.4 Indicação de sucesso ou falha
• 10.3.5 Origem do evento
• 10.3.6 Identidade ou nome dos dados, do componente do sistema ou do recurso afetados.

Suas responsabilidades

Conforme descrito no Requisito 10.2, você pode obter logs de auditoria do cluster habilitando a configuração de diagnóstico para o AKS. Os logs contêm informações detalhadas sobre eventos POST, get, list, create, update, delete e patch. Os logs contêm informações na lista em Requisitos. Armazene os logs em uma conta de armazenamento para que você possa consultar as informações.

Por exemplo, você deseja exibir o conjunto anterior de informações para eventos kube-audit-admin executando esta consulta:

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

O conjunto de resultados mostra as informações como parte do campo log_s.

Informações necessárias	Esquema
Identificação do usuário	SourceIPs
Tipo de evento	verbo
Data e Hora	requestReceivedTimestamp
Êxito ou indicação de falha	responseStatus
Origem do evento	usuário
Identidade ou nome dos dados, do componente do sistema ou do recurso afetados	objectRef

Para obter informações sobre o log mestre, confira Exibir os logs de componentes do painel de controle.

Requisito 10.4

Use a tecnologia de sincronização de tempo para sincronizar todos os relógios e horários críticos do sistema e verifique se o seguinte é implementado para adquirir, distribuir e armazenar o tempo.

• 10.4.1 Os sistemas críticos estão com a hora correta e consistente.
• 10.4.2 Os dados de hora estão protegidos.
• 10.4.3 As configurações de hora são recebidas de fontes de horário aceitas pelo setor.

Observação: um exemplo de tecnologia de sincronização de hora é o protocolo NTP (Network Time).

Suas responsabilidades

O AKS usa o NTP dos hosts subjacentes do Azure e não requer nenhuma concessão de tráfego de rede de saída para dar suporte ao NTP. Outras VMs adicionadas ao seu CDE podem usar servidores NTP externos, como ntp.ubuntu.org (e o respectivo pool) como a origem de sincronização temporal. A computação adicional que você traz para o CDE deve usar explicitamente a origem NTP de sua escolha e deve ser documentada.

Requisito 10.5

Limite a exibição de trilhas de auditoria apenas para pessoas com uma necessidade relacionada ao trabalho.

• 10.5.1 Limitar a exibição de trilhas de auditoria para pessoas com uma necessidade relacionada ao trabalho.
• 10.5.2 Proteger arquivos de trilha de auditoria de modificações não autorizadas.
• 10.5.3 Fazer backup de arquivos de trilha de auditoria imediatamente para um servidor de registro centralizado ou mídia que seja difícil de alterar.
• 10.5.4 Gravar logs para tecnologias externas em um dispositivo de mídia ou servidor de log seguro, centralizado e interno.
• 10.5.5 Usar software de monitoramento de integridade de arquivos ou detecção de mudanças em logs para fazer com que os dados de log existentes não possam ser alterados sem gerar alertas (embora a adição de novos dados não deva causar um alerta).

Suas responsabilidades

Ter várias sincronizações de log adiciona sobrecarga à proteção, revisão, análise e consulta de dados de trilha de auditoria. Planejar suas topologias de trilha de auditoria para equilibrar as compensações entre o isolamento completo da trilha de auditoria e as preocupações de gerenciamento.

Quando possível, integrar logs. A vantagem é a capacidade de examinar, analisar e consultar dados com eficiência. O Azure fornece várias opções de tecnologia. Você pode usar os Insights de Contêiner do Azure Monitor para gravar logs em um workspace do Log Analytics. Outra opção é integrar dados a soluções SIEM (gerenciamento de eventos e informações de segurança), como o Microsoft Sentinel. Outras opções populares de terceiros são Splunk, QRadar e ArcSight. O Microsoft Defender para Nuvem e o Azure Monitor dão suporte a todas essas soluções. Essas soluções são coletores de dados somente de acréscimo, para garantir que a trilha não possa ser alterada.

O Defender para Nuvem pode exportar resultados em intervalos configurados. Para obter mais informações, consulte Exportação contínua.

Todos os logs são mantidos com pelo menos três cópias em uma região. Como estratégia de backup, você pode ter mais cópias habilitando o backup ou a replicação entre regiões. Todas as entradas de log estão disponíveis somente por meio de canais HTTP/S protegidos.

O Log Analytics e o Microsoft Sentinel dão suporte a vários controles de acesso baseado em função para gerenciar o acesso à trilha de auditoria. Verifique se as funções estão mapeadas para as funções e responsabilidades da organização.

Verifique se o workspace do Log Analytics dá suporte às operações e às necessidades de conformidade. Considere um workspace dedicado para seus clusters no escopo, que encaminhe para a sua solução SIEM.

A maioria dos logs no AKS virá de stdout/stderr e será coletada pelos Insights de Contêiner do Azure Monitor. Se você tiver outros logs criados manualmente, considere emitir dados de uma maneira que seja enviada para um fluxo de encaminhamento confiável e não esteja sujeita a adulteração.

Requisito 10.6

Examinar os logs e os eventos de segurança de todos os componentes do sistema para identificar anomalias ou atividades suspeitas.

• 10.6.1 Examinar diariamente pelo menos o seguinte:
  • Todos os eventos de segurança
  • Logs de todos os componentes do sistema que armazenam, processam ou transmitem CHD e/ou SAD
  • Logs de todos os componentes essenciais do sistema
  • Logs de todos os servidores e componentes do sistema que executam funções de segurança (por exemplo, firewalls, IDS/IPS (sistemas de detecção de invasão/sistemas de prevenção de invasão), servidores de autenticação, servidores de redirecionamento de comércio eletrônico e assim por diante).
• 10.6.2 Examinar os logs de todos os outros componentes do sistema periodicamente com base nas políticas da organização e na estratégia de gerenciamento de riscos, conforme determinado pela avaliação de risco anual da organização.
• 10.6.3 Acompanhar exceções e anomalias identificadas durante o processo de revisão.

Suas responsabilidades

Os serviços de monitoramento do Azure, o Azure Monitor e o Microsoft Defender para Nuvem podem gerar notificações ou alertas quando detectam atividades anormais. Esses alertas incluem informações de contexto, como gravidade, status e tempo de atividade.

À medida que os alertas são gerados, tenha uma estratégia de correção e examine o progresso. Uma maneira é acompanhar a pontuação de segurança no Microsoft Defender para Nuvem e compará-la com os resultados históricos.

Centralize dados em apenas uma exibição usando soluções SIEM, como o Microsoft Sentinel. A integração de dados pode fornecer um contexto de alerta avançado.

Como alternativa, verifique manualmente o log completo em seu armazenamento. Por exemplo, nos Logs do Azure Monitor, você pode usar uma funcionalidade de filtragem com base no tipo de atividade, no conteúdo da atividade ou no chamador da atividade.

Tenha políticas organizacionais para examinar alertas e eventos em uma cadência regular e planejar iniciativas com metas de aprimoramento específicas. Use consultas salvas personalizadas no Log Analytics para documentar consultas de log pretendidas e facilitar a consulta. Isso garante que a equipe saiba o que é importante examinar, pois se refere à versão 10.6 e que todos os esforços manuais envolvidos nesse processo sigam um fluxo de trabalho consistente.

Requisito 10.7

Manter o histórico de trilha de auditoria por pelo menos um ano, com um mínimo de três meses imediatamente disponíveis para análise (por exemplo, online, arquivado ou restaurável do backup).

Suas responsabilidades

Os logs não estão disponíveis indefinidamente. Verifique se os logs de atividade do Azure e as configurações de diagnóstico são mantidos e podem ser consultados. Especifique um período de retenção de três meses ao habilitar a configuração de diagnóstico para seus recursos. Os Logs do Azure Monitor dão suporte ao arquivamento de longo prazo, para que possam ser usados para auditorias ou análise offline. Implemente sua solução de arquivamento de longo prazo para se alinhar ao princípio de gravar uma vez, ler muitas.

Requisito 10.8

• 10.8.1 Requisitos adicionais somente para provedores de serviço: responder a falhas de controles de segurança críticos de maneira oportuna. Os processos para responder a falhas de controles de segurança devem incluir:

• Restauração de funções de segurança

• Identificação e documentação da duração (data e hora do início ao fim) da falha de segurança

• Identificação e documentação das causas da falha, incluindo a causa raiz, e documentação das atualizações necessárias para tratar da causa raiz

• Identificação e tratamento de problemas de segurança ocorridos durante a falha

• Execução de uma avaliação de risco para determinar se outras ações são necessárias como resultado da falha de segurança

• Implementação de controles para impedir a ocorrência da causa da falha; retomada do monitoramento dos controles de segurança

Suas responsabilidades

Quando for prático, tenha alertas que indiquem a existência de controles de segurança críticos. Caso contrário, verifique se o processo de auditoria pode detectar em tempo hábil a falta de um controle de segurança esperado. Considere controles como agentes de segurança em execução no cluster do AKS e controles de acesso (IAM e rede) em recursos do Azure. Inclua configurações para marcar se o cluster do AKS for um cluster privado, para pontos de exposição de rede por meio de regras de NSG (Grupo de Segurança de Rede) ou marcar para IPs públicos inesperados. Inclua também alterações inesperadas no DNS, roteamento de rede, firewall e Azure AD.

Requisito 10.9

Verificar se as políticas de segurança e os procedimentos operacionais para monitorar todo o acesso aos recursos de rede e aos dados de titulares de cartões estão documentados, em uso e são conhecidos por todas as partes afetadas.

Suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre os processos e as políticas. Mantenha a documentação sobre as políticas impostas. Como parte de seus esforços de monitoramento, pessoas precisam ser treinadas para habilitar e exibir logs de auditoria e identificar e corrigir os riscos comuns. Isso é importante para pessoas que fazem parte do processo de aprovação de uma perspectiva de política.

Requisito 11.1

Trimestralmente, implementar processos para testar a presença de pontos de acesso sem fio (802.11) e detectar e identificar todos os pontos de acesso sem fio autorizados e não autorizados.

As redes externas estão fora do escopo dessa documentação e precisam ser avaliadas separadamente.

Suas responsabilidades

Essa arquitetura e sua implementação não foram projetadas para dar suporte a transações locais ou corporativas de rede para nuvem em conexões sem fio. Para ver outras considerações, confira as diretrizes no padrão oficial PCI-DSS 3.2.1.

Requisito 11.2

Execute verificações de vulnerabilidade de rede interna e externa pelo menos trimestralmente e depois de alterações significativas na rede, como:

• Novas instalações de componente do sistema
• Alterações na topologia de rede
• Modificações de regra de firewall
• Atualizações de produtos

Para obter mais informações, confira Fornecedores de verificação aprovados segundo o PCI DSS (Padrão de Segurança de Dados do Setor de Cartões de Pagamento).

Suas responsabilidades

Tenha um processo que verifica se há alterações no cluster do AKS, configuração de rede, registros de contêiner e outros componentes da arquitetura.

Se houver alterações na rede, o processo deverá avaliar se uma verificação é necessária. Por exemplo, o cluster agora está exposto à Internet pública? As novas regras de firewall são excessivamente permissivas? Dentro do cluster, há lacunas de segurança no fluxo entre os pods?

Tenha uma definição clara e acordada de alterações significativas em relação à sua infraestrutura. Alguns exemplos são:

• Configuração de regras de NSG ou Firewall do Azure
• Emparelhamentos de rede virtual
• Configurações DNS
• configurações de Link Privado do Azure
• Outros componentes de rede

APLICA-SE A 11.2.1

A verificação trimestral de vulnerabilidades precisa ser executada por funcionários qualificados com profunda compreensão dos conceitos de rede do Azure e do Kubernetes. Mapeie os resultados para o Requisito 6.1 com níveis de gravidade e resolva itens de alta prioridade. Se houver alterações significativas, execute as verificações antes da verificação trimestral agendada. Isso ajuda a detectar novas vulnerabilidades para que você possa corrigir problemas proativamente.

Essa verificação também precisa incluir as redes no cluster (pod para pod).

APLICA-SE A 11.2.2 Selecione um ASV (Fornecedor de Verificação Aprovado) que tenha ampla experiência com rede do Azure e Kubernetes. Isso fornece profundidade e especificidade na correção sugerida.

Requisito 11.3

Implementar uma metodologia de teste de penetração que inclua o seguinte:

• Baseada em abordagens de teste de penetração aceitas pelo setor (por exemplo, NIST SP800-115)
• Inclui a abordagem de todo o perímetro do CDE e sistemas críticos
• Inclui teste interno e fora da rede
• Inclui testes para validar controles de segmentação e de redução de escopo
• Define testes de penetração de camada de aplicativo para incluir, no mínimo, as vulnerabilidades relacionadas no Requisito 6.5
• Define testes de penetração de camada de rede para incluir componentes que dão suporte a funções de rede e sistemas operacionais
• Inclui a revisão e a consideração de ameaças e vulnerabilidades ocorridas nos últimos 12 meses
• Especifica a retenção dos resultados dos testes e dos resultados das atividades de correção.

Suas responsabilidades

Executar testes de penetração para encontrar falhas de segurança com coleta de informações, análise de vulnerabilidades e relatórios. Recomendamos que você siga as diretrizes do setor fornecidas no PTES (Padrão de Execução de Testes de Penetração) para saber como lidar com cenários comuns e conhecer as atividades necessárias para estabelecer uma linha de base.

O profissional de teste de penetração deve ter uma compreensão profunda da rede local e do Azure para garantir que os testes de segmentação anual sejam amplamente abordados. Estenda a metodologia de teste para redes no cluster. Essa pessoa requer uma experiência forte com os conceitos de rede do Kubernetes.

Os testes precisam abranger o aplicativo e as camadas de dados em execução no CDE.

Em um exercício de penetração, os profissionais podem precisar acessar dados confidenciais de toda a organização. Siga as regras de envolvimento para garantir que o acesso e a intenção não sejam usados incorretamente. Para obter orientação sobre como planejar e executar ataques simulados, consulte Regras de Participação em Testes de Penetração.

Requisito 11.4

Usar técnicas de detecção de intrusão e/ou prevenção contra intrusão para detectar e/ou evitar invasões na rede. Monitore todo o tráfego no perímetro do ambiente de dados do titular do cartão e em pontos críticos no ambiente de dados do titular do cartão. Alertar a equipe sobre suspeitas de comprometimentos.

Suas responsabilidades

Proteja o cluster do AKS inspecionando o tráfego de entrada usando um WAF (firewall do aplicativo Web). Nesta arquitetura, o Gateway de Aplicativo do Azure com WAF integrado impede a invasão. Use o modo de prevenção para bloquear ativamente as invasões e ataques detectados. Não use apenas o modo de detecção. Para obter mais informações, confira Melhores práticas para conectividade de rede e segurança no Serviço de Kubernetes do Azure (AKS).

Uma opção alternativa é usar as funcionalidades de detecção de intrusão e/ou prevenção de intrusão no Firewall do Azure Premium. Para obter mais informações, confira IDPS.

Outra opção é habilitar o Azure Monitor Network Insights, que fornece acesso a recursos de monitoramento de rede, como Monitor da Conexão, registro em log de fluxo para NSGs (grupos de segurança de rede) e Análise de Tráfego.

Habilite os planos do Microsoft Defender, pois eles se aplicam a vários componentes do CDE. Por exemplo, se SQL do Azure for usado para armazenar o CHD, o Microsoft Defender para SQL garantirá que invasões de camada de dados sejam detectadas.

Além disso, detecte anomalias nos padrões de tráfego conectando logs de fluxo de NSG a uma solução SIEM centralizada, como o Microsoft Sentinel. Nesta implementação de referência, os logs estão no modo somente acréscimo, o que minimiza o controle de alterações nos logs de auditoria. No entanto, todos os logs enviados para coletores externos para armazenamento de longo prazo não podem ser modificados. Eles devem seguir a abordagem gravar uma vez/ler muitas. Verifique se a solução FIM (monitoramento de integridade do arquivo) abrange essas entidades externas para detectar alterações.

Requisito 11.5

Implante uma solução de controle de alterações (por exemplo, uma solução de monitoramento de integridade de arquivo) para alertar a equipe sobre a modificação não autorizada de arquivos críticos do sistema, arquivos de configuração ou arquivos de conteúdo. Configure o produto para executar comparações de arquivos críticas pelo menos semanalmente.

Suas responsabilidades

No cluster, execute uma solução fim (monitoramento de integridade de arquivo) em conjunto com um agente de segurança com reconhecimento de Kubernetes para detectar o acesso no nível do arquivo e do sistema que pode resultar em alterações no nível do nó. Ao escolher uma solução de FIM, tenha uma compreensão clara dos recursos e da profundidade de detecção que ela oferece. Considere usar software desenvolvido por fornecedores respeitáveis.

Verifique todas as configurações padrão da ferramenta FIM para garantir que os valores detectem os cenários que você deseja cobrir e ajuste essas configurações adequadamente.

Habilite a solução para enviar logs para sua solução de monitoramento ou de SIEM para que elas possam gerar alertas. Esteja ciente das alterações de esquema de log, caso contrário, você poderá ignorar alertas críticos.

Qualquer outra computação no CDE deve ter o controle de alterações habilitado.

Requisito 11.6

Verificar se as políticas de segurança e os procedimentos operacionais para monitoramento e teste de segurança estão documentados, em uso e conhecidos para todas as partes afetadas.

Suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre os processos e as políticas. Mantenha a documentação sobre as políticas impostas. Como parte de seus esforços de teste, inclua a cadência das revisões e os critérios de revisão. Verifique se a equipe entende os aspectos do teste de penetração. Tenha um plano de correção documentado para atenuar os riscos encontrados.

Isso é importante para pessoas que fazem parte do processo de aprovação de uma perspectiva de política.

Próximas etapas

Manter uma política direcionada à segurança de informações para todos os funcionários.