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 da chamada 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 nos 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 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 AKS são protegidos pelo Gateway de Aplicativo do Azure com WAF (Web Application Firewall) 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 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. Este log de atividade fornece informações sobre o tipo e a hora das operações de recurso 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 arquivamento.

  

• Configurações do 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 para enviar para um destino. Seu destino de diagnóstico precisa 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-admin, e guard.

    Habilite kube-audit-admin para ver chamadas de servidor de API baseado 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ído e aumentar seu 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 Microsoft Entra ID 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. Normalmente, esses logs não são associadas 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 habilita cluster-autoscaler, kube-controller-manager, kube-audit-admin e guard registra e encaminha para um espaço de trabalho do Log Analytics. O período de retenção do espaço de trabalho é definido como 90 dias.

  

• O diagnóstico do Serviço de Kubernetes do Azure (AKS) 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 mais informações, confira Diagnósticos do Serviço de Kubernetes do Azure.

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 e alterações em mecanismos de autenticação e identificação, incluindo, dentre outros, a criação de contas e a elevação de privilégios, e todas as alterações, adições ou exclusões em contas raiz ou com privilégios de administrador
• 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 coleta de 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 em seu espaço de trabalho do Log Analytics. Esses registros também devem ser ingeridos em seu SIEM.
• Inclua o log de auditoria de SO e de uso para outros cálculos, como agentes de build e jump boxes. Desabilite o acesso aos sistemas diretamente como raiz. Certifique-se de que todas as ações sejam executadas sob uma identidade específica.
• Registre tentativas de acesso malsucedidas. Isso inclui solicitações de acesso a componentes como o Armazenamento do Microsoft 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.

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 certificar-se de que os itens a seguir sejam implementados 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 exige subsídios de tráfego de rede de saída para dar suporte a 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ê colocar em seu CDE deve usar explicitamente a origem NTP de sua escolha e deve ser documentada.

Requisito 10.5

Limitar a exibição de trilhas de auditoria a pessoas com uma necessidade relacionada a um trabalho.

• 10.5.1 Limitar a visualização das trilhas de auditoria para aqueles que tenham essa necessidade de 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 oferecem suporte a vários controles de acesso baseados 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 criado manualmente outros logs, considere emitir dados de uma forma 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, Azure Monitor e 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 revise 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, conteúdo da atividade ou 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 pertence ao requisito 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 ficam 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 Monitor Azure dão suporte a arquivamento de longo prazo, para que elas possam ser usadas para auditorias ou análises 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 verificar se o cluster do AKS é um cluster privado, para pontos de exposição de rede por meio de regras de NSG (Grupo de Segurança de Rede) ou para verificar se há IPs públicos inesperados. Inclua também alterações inesperadas no DNS, roteamento de rede, firewall e o Microsoft Entra ID.

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 as pessoas que fazem parte do processo de aprovação do ponto de vista da 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 de rede local ou corporativa 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 após quaisquer alterações significativas na rede, como:

• Novas instalações de componentes do sistema
• Alterações na topologia de rede.
• Modificações na 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 do NSG ou do Firewall do Azure
• Emparelhamentos de rede virtual
• Configurações DNS
• Configurações do Link Privado do Azure
• Outros componentes da 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 você 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 os 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 precisa de experiência sólida 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 participação para garantir que o acesso e a intenção não sejam usados indevidamente. 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. Pessoal alertado sobre suspeitas de comprometimento.

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 o Monitor da Conexão, log de fluxo para NSGs (grupos de segurança de rede) e a 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 arquivos) para alertar a equipe sobre modificações não autorizadas de arquivos críticos do sistema, arquivos de configuração ou arquivos de conteúdo. Configure o produto para realizar comparações de arquivos críticos pelo menos semanalmente.

Suas responsabilidades

Em seu cluster, execute uma solução fim (monitoramento de integridade de arquivo) juntamente com um agente de segurança com reconhecimento do 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 o 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 as pessoas que fazem parte do processo de aprovação do ponto de vista da política.

Próximas etapas

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