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

Este artigo descreve as considerações para um cluster do Serviço Kubernetes do Azure (AKS) 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.

Monitore e teste redes regularmente

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

Suporte ao recurso AKS

O Azure fornece o recurso Container Insights que monitora contêineres, incluindo clusters AKS. Para obter mais informações, consulte Visão geral de insights de contêiner.

O AKS fornece logs de auditoria em vários níveis que podem ser úteis protegendo o sistema e os dados proativamente. Os logs de atividades fornecem informações sobre operações relacionadas ao gerenciamento de contas e segredos, gerenciamento de configurações de diagnóstico, gerenciamento de servidores 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 de API feitas no cluster AKS. Os logs incluem informações sobre o chamador, a hora em que a chamada foi feita e a origem onde a chamada foi iniciada. Para obter mais informações, consulte AKS control plane/resource logs.

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 rapidamente insights a partir 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 apenas através de canais HTTP(s) seguros.

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

As suas responsabilidades

Requisito 11 — testar regularmente sistemas e processos de segurança

Suporte ao recurso AKS

O AKS está integrado com os serviços de monitorização do Azure:

• O Microsoft Defender for Containers fornece muitos recursos de verificação de segurança. Por exemplo, o Defender for Containers verifica imagens extraídas, enviadas por push e importadas para registros de contêineres e fornece recomendações. Para obter detalhes, consulte 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á alguma falha de sistema esperada nos nós AKS, o AKS recupera automaticamente o recurso em tempo hábil, sem interrupção do processamento do sistema.

Os clusters AKS são protegidos pelo Gateway de Aplicativo do Azure com Firewall de Aplicativo Web (WAF) e podem ser configurados no modo de deteção para registrar alertas e ameaças. É melhor usar o modo de prevenção , que bloqueia ativamente intrusões e ataques detetados. Para obter detalhes, consulte Práticas recomendadas para conectividade de rede e segurança no Serviço Kubernetes do Azure (AKS).

As suas responsabilidades

Requisito 10.1

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

As suas responsabilidades

Recomendamos que você audite as operações 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 é ativado por padrão e as informações são coletadas assim que a operação do recurso é concluída. A pista de auditoria é imutável 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 do log de atividades para os Logs do Azure Monitor e configure uma política de retenção e arquivamento.

  

• Configurações de diagnóstico do Azure. As configurações de diagnóstico fornecem 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 o Armazenamento de Blobs do Azure e o Cofre de Chaves. Com base no tipo de recurso, você pode escolher o tipo de logs e dados métricos a serem enviados para um destino. O destino do diagnóstico deve atender aos períodos de retenção necessários.

  • A partir das categorias AKS fornecidas, 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 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 não modificativos, como solicitações de leitura), habilite kube-audit . Esses eventos podem ser prolíficos, criar ruído e aumentar o seu custo de consumo. Esses logs têm informações sobre o nome de acesso e identidade usado para fazer a solicitação.

    Habilite guard os logs para rastrear auditorias gerenciadas do Microsoft Entra ID e do controle de acesso baseado em função (RBAC) do Azure.

  • Além dos logs baseados no usuário, considere os logs do plano 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 feitas pelos usuários no sistema.

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

  Essa implementação de referência habilita cluster-autoscaler, kube-controller-manager, kube-audit-admine 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 Kubernetes do Azure (AKS) ajuda a detetar e solucionar problemas com o cluster, como falhas de nó. Também inclui dados de diagnóstico específicos da rede, que não incorrem em custos adicionais. Esses dados normalmente não estão associados à atividade do usuário, mas podem ajudar se você precisar entender os efeitos das alterações no sistema feitas pelos usuários. Para obter informações, consulte Diagnóstico do Serviço Kubernetes do Azure.

Os mecanismos de pista de auditoria anteriores devem ser implementados no momento da implantação dos recursos. A Política do Azure também deve estar ativa para garantir que essas configurações não sejam desabilitadas inadvertidamente ou maliciosamente em seu CDE.

Requisito 10.2

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

• 10.2.1 Todos os utilizadores individuais acedem aos dados do titular do cartão
• 10.2.2 Todas as ações tomadas por qualquer indivíduo com privilégios de raiz ou administrativos
• 10.2.3 Acesso a todas as pistas de auditoria
• 10.2.4 Tentativas de acesso lógico inválidas
• 10.2.5 Uso e alterações nos mecanismos de identificação e autenticação — incluindo, entre outros, a criação de novas contas e a elevação de privilégios — e todas as alterações, adições ou exclusões de contas com privilégios raiz ou administrativos
• 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

As suas responsabilidades

O AKS fornece logs de auditoria em vários níveis, conforme descrito no Requisito 10.1. Aqui estão alguns pontos-chave:

• Por padrão, os logs de atividade 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 de API feitas no cluster 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 espaço de trabalho do Log Analytics com um período de retenção apropriado. Habilite o registro do espaço de trabalho 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ó AKS em seu espaço de trabalho do Log Analytics. Esses logs também devem ser ingeridos em seu SIEM.
• Inclua o log de auditoria de uso e do sistema operacional para outros cálculos, como agentes de compilação e caixas de salto. Desative o acesso aos sistemas diretamente como root. Verifique se todas as ações estão sendo executadas sob uma identidade específica.
• Registre tentativas de acesso malsucedidas. Isso inclui solicitações de acesso a componentes como o Armazenamento do Azure, o Cofre de Chaves do Azure, o servidor de API 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 do usuário dentro do cluster AKS. Esses recursos podem ser úteis para dados de auditoria de acesso do usuário.

Requisito 10.3

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

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

As 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 obter, listar, criar, atualizar, excluir, corrigir e postar eventos. Os logs contêm as informações especificadas no requisito. 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 os logs do plano de controle, consulte Logs de plano/recurso de controle AKS.

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 foi implementado para adquirir, distribuir e armazenar tempo.

• 10.4.1 Os sistemas críticos têm o tempo correto e consistente.
• 10.4.2 Os dados de tempo estão protegidos.
• 10.4.3 As configurações de tempo são recebidas de fontes de tempo aceitas pelo setor.

Nota: Um exemplo de tecnologia de sincronização de tempo é o Network Time Protocol (NTP).

As suas responsabilidades

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

Requisito 10.5

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

• 10.5.1 Limitar a visualização das pistas de auditoria a pessoas com necessidades relacionadas com o trabalho.
• 10.5.2 Proteja os arquivos da trilha de auditoria contra modificações não autorizadas.
• 10.5.3 Faça backup imediato dos arquivos da trilha de auditoria em um servidor de log centralizado ou mídia difícil de alterar.
• 10.5.4 Escreva logs para tecnologias externas em um servidor de log interno seguro e centralizado ou dispositivo de mídia.
• 10.5.5 Use software de monitoramento de integridade de arquivos ou deteção de alterações em logs para garantir que os dados de log existentes não possam ser alterados sem gerar alertas (embora novos dados adicionados não devam causar um alerta).

As suas responsabilidades

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

Sempre que possível, integre logs. A vantagem é a capacidade de revisar, analisar e consultar dados de forma eficiente. O Azure fornece várias opções de tecnologia. Você pode usar as informações de contêiner do Azure Monitor para gravar logs em um espaço de trabalho do Log Analytics. Outra opção é integrar dados em soluções de gerenciamento de eventos e informações de segurança (SIEM), como o Microsoft Sentinel. Outras opções populares de terceiros são Splunk, QRadar e ArcSight. O Microsoft Defender for Cloud e o Azure Monitor oferecem suporte a todas essas soluções. Essas soluções são coletores de dados somente de apêndice para garantir que a trilha não possa ser alterada.

O Defender for Cloud 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 apenas através de canais HTTP(s) seguros.

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. Certifique-se de que as funções estão mapeadas para as funções e responsabilidades da organização.

Verifique se o espaço de trabalho do Log Analytics suporta as necessidades de operações e conformidade. Considere um espaço de trabalho dedicado para seus clusters no escopo, que encaminha para sua solução SIEM.

A maioria dos logons no AKS virá do stdout/stderr e será coletada pelos insights do Contêiner do Azure Monitor. Se você tiver outros logs criados manualmente, 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

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

• 10.6.1 Analise o seguinte, pelo menos diariamente:
  • 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 críticos do sistema
  • Registos de todos os servidores e componentes do sistema que executam funções de segurança (por exemplo, firewalls, sistemas de deteção de intrusão/sistemas de prevenção de intrusões (IDS/IPS), servidores de autenticação, servidores de redirecionamento de comércio eletrónico, etc.)."
• 10.6.2 Revisar periodicamente os logs de todos os outros componentes do sistema com base nas políticas e na estratégia de gerenciamento de riscos da organização, conforme determinado pela avaliação anual de riscos da organização.
• 10.6.3 Acompanhar exceções e anomalias identificadas durante o processo de revisão.

As suas responsabilidades

Os serviços de monitoramento do Azure, Azure Monitor e Microsoft Defender for Cloud, podem gerar notificações ou alertas quando detetam atividades anômalas. 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 analise o progresso. Uma maneira é acompanhar a pontuação de segurança no Microsoft Defender for Cloud e compará-la com os resultados históricos.

Centralize os dados em uma única exibição usando soluções SIEM, como o Microsoft Sentinel. A integração de dados pode fornecer um contexto de alerta rico.

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

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

Requisito 10.7

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

As suas responsabilidades

Por padrão, os logs não são retidos indefinidamente. Certifique-se de configurar seus logs de atividade do Azure e configurações de diagnóstico para serem retidos de uma forma que possa ser consultada. Especifique um período de retenção de três meses ao habilitar as configurações 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álises offline. Implemente sua solução de arquivamento de longo prazo para se alinhar com o princípio de escrever uma vez, leia muitos.

Requisito 10.8

10.8.1 Requisito adicional apenas para prestadores de serviços: Responder a falhas de quaisquer controlos de segurança críticos em tempo útil. Os processos de resposta a falhas nos controlos de segurança devem incluir:

• Restaurando funções de segurança
• Identificar e documentar a duração (data e hora do início ao fim) da falha de segurança
• Identificar e documentar a(s) causa(s) da falha, incluindo a causa raiz, e documentar a correção necessária para abordar a causa raiz
• Identificar e resolver quaisquer problemas de segurança que tenham surgido durante a falha
• Realizar uma avaliação de risco para determinar se são necessárias ações adicionais como resultado da falha de segurança
• Implementação de controlos para evitar que a causa da falha volte a ocorrer
• Retomar a monitorização dos controlos de segurança

As suas responsabilidades

Quando for prático, tenha alertas que indiquem a existência de controles críticos de segurança. Caso contrário, certifique-se de que seu processo de auditoria possa detetar a falta de um controle de segurança esperado em tempo hábil. Considere controles como agentes de segurança em execução no cluster AKS e controles de acesso (IAM e rede) nos recursos do Azure. Inclua configurações para verificar se o cluster AKS é um cluster privado, para pontos de exposição de rede por meio de regras NSG (Network Security Group) ou verifique se há IPs públicos inesperados. Também incluem alterações inesperadas no DNS, roteamento de rede, firewall e ID do Microsoft Entra.

Requisito 10.9

Certifique-se de que as políticas de segurança e os procedimentos operacionais para monitorar todo o acesso aos recursos da rede e aos dados do titular do cartão 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. Manter a documentação sobre as políticas aplicadas. Como parte de seus esforços de monitoramento, as pessoas devem ser treinadas para habilitar e visualizar logs de auditoria e identificar e remediar os riscos comuns. Isto é importante para as pessoas que fazem parte do processo de aprovação do ponto de vista político.

Requisito 11.1

Implementar processos para testar a presença de pontos de acesso sem fio (802.11) e detetar e identificar todos os pontos de acesso sem fio autorizados e não autorizados trimestralmente.

As redes externas estão fora do âmbito desta documentação e devem ser avaliadas separadamente.

As suas responsabilidades

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

Requisito 11.2

Execute verificações de vulnerabilidades de rede internas e externas 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 nas regras de firewall
• Atualizações de produtos

Para obter mais informações, consulte Fornecedores de verificação aprovados pelo padrão de segurança de dados PCI (Payment Card Industry).

As suas responsabilidades

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

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

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

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

APLICA-SE AO PONTO 11.2.1

A verificação trimestral de vulnerabilidades deve ser executada por pessoal qualificado com profundo conhecimento dos conceitos de rede do Azure e 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 detetar novas vulnerabilidades para que você possa corrigir problemas proativamente.

Essa verificação também deve incluir redes em cluster (pod-to-pod).

APLICA-SE AO PONTO 11.2.2

Selecione um ASV (Approved Scanning Vendor) que tenha ampla experiência com redes do Azure e Kubernetes. Isso fornece profundidade e especificidade na remediação sugerida.

Requisito 11.3

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

• Baseia-se em abordagens de teste de penetração aceitas pela indústria (por exemplo, NIST SP800-115)
• Inclui cobertura para todo o perímetro CDE e sistemas críticos
• Inclui testes dentro e fora da rede
• Inclui testes para validar quaisquer controles de segmentação e redução de escopo
• Define os testes de penetração da camada de aplicativo para incluir, no mínimo, as vulnerabilidades listadas no Requisito 6.5
• Define testes de penetração de camada de rede para incluir componentes que suportam funções de rede e sistemas operacionais
• Inclui revisão e consideração de ameaças e vulnerabilidades experimentadas nos últimos 12 meses
• Especifica a retenção dos resultados dos testes de penetração e dos resultados das atividades de correção.

As suas responsabilidades

Execute testes de penetração para encontrar lacunas de segurança coletando informações, analisando vulnerabilidades e relatando. Recomendamos que você siga as diretrizes do setor fornecidas no Penetration Testing Execution Standard (PTES) para abordar cenários comuns e as atividades necessárias para estabelecer uma linha de base.

O profissional de teste de penetração deve ter um conhecimento profundo da rede local e do Azure para garantir que os testes de segmentação anuais sejam cobertos extensivamente. Estenda a metodologia de teste para redes em cluster. Essa pessoa requer uma forte experiência com conceitos de rede Kubernetes.

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

Em um exercício de teste de penetração, os profissionais podem precisar de acesso a dados confidenciais para toda a organização. Siga as regras de engajamento 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 engajamento de testes de penetração.

Requisito 11.4

Utilizar técnicas de deteção e/ou prevenção de intrusões para detetar e/ou prevenir intrusõ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 o pessoal para suspeitas de comprometimento.

As suas responsabilidades

Proteja o cluster AKS inspecionando o tráfego de entrada usando um firewall de aplicativo da Web (WAF). Nessa arquitetura, o Gateway de Aplicativo do Azure com WAF integrado evita invasões. Use o modo de prevenção para bloquear ativamente as invasões e ataques detetados. Não use apenas o modo de deteção . Para obter mais informações, consulte Práticas recomendadas para conectividade de rede e segurança no Serviço Kubernetes do Azure (AKS).

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

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

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

Além disso, detete anomalias nos padrões de tráfego conectando logs de fluxo NSG em uma solução SIEM centralizada, como o Microsoft Sentinel. Nessa 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 devem ser modificados. Eles devem seguir a abordagem write-once/read-many. Verifique se a solução de monitoramento de integridade de arquivos (FIM) abrange essas entidades externas para detetar 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 o pessoal 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 realizar comparações de arquivos críticos pelo menos semanalmente.

As suas responsabilidades

Em seu cluster, execute uma solução de monitoramento de integridade de arquivos (FIM) em conjunto com um agente de segurança compatível com Kubernetes para detetar acesso no nível de arquivo e sistema que possa resultar em alterações no nível do nó. Ao escolher uma solução FIM, tenha uma compreensão clara de suas características e da profundidade de deteção. Considere o software desenvolvido por fornecedores respeitáveis.

Verifique todas as configurações padrão da ferramenta FIM para garantir que os valores detetem 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 SIEM para que eles possam gerar alertas. Esteja ciente das alterações no esquema de log ou você pode perder alertas críticos.

Qualquer outro cálculo no CDE deve ter o controle de alterações habilitado.

Requisito 11.6

Certifique-se de que as políticas de segurança e os procedimentos operacionais para monitoramento e testes de segurança 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. Manter a documentação sobre as políticas aplicadas. Como parte de seus esforços de teste, inclua a cadência das avaliações e os critérios de avaliação. Certifique-se de que a equipe entenda os aspetos dos testes de penetração. Tenha um plano de remediação documentado para mitigar os riscos encontrados.

Isto é importante para as pessoas que fazem parte do processo de aprovação do ponto de vista político.

Próximos passos

Mantenha uma política que aborde a segurança das informações para todos os funcionários.