Resumo: referência dos 12 requisitos PCI DSS 4.0.1
- Além dos 12: PCI DSS tem 12 requisitos de alto nível. Todos citam esse número e param. O dado interessante é que 4.0.1 agora tem mais de 400 subrequisitos, e os dois que mais falham são os mais novos, para os quais ninguém tinha evidência antes de 2025.
- Os dois que mais falham: PCI DSS 4.0.1 tornou-se obrigatório em março de 2025. Os requisitos 6.4.3 (inventário de scripts, justificativa de negócio, verificação de integridade, detecção de mudanças) e 11.6.1 (monitoramento de cabeçalhos HTTP em páginas de pagamento) são os dois menos preparados nas avaliações atuais. A cside produz ambos os artefatos continuamente.
- Por onde começar: Se você está escopando uma avaliação 4.0.1 sem inventário de scripts nem monitoramento de cabeçalhos, comece por aí antes de tocar nos Requisitos 3 ou 12. Se sua evidência 6.4.3 e 11.6.1 já flui, foque em seguida a revisão de scope creep e a implantação de MFA sob 8.4.2.
Sem tempo? Veja o cside PCI Shield. Cobre tudo o que se segue numa única implementação.
Os 12 requisitos PCI DSS são o núcleo da Payment Card Industry Data Security Standard. Todas as entidades que armazenam, processam ou transmitem dados de cartão têm de os cumprir. Esta é a referência prática sobre o que cada requisito abrange na PCI DSS 4.0.1, o que mudou face à 3.2.1 e onde a maioria dos ambientes tem falhas.
A estrutura: 6 objetivos, 12 requisitos
A PCI DSS organiza os seus controlos em torno de seis objetivos de segurança. Cada objetivo contém um ou mais dos 12 requisitos de topo. Cada requisito contém vários sub-requisitos e o total de sub-requisitos na 4.0.1 ultrapassa os 400.
Objetivo 1: Construir e manter uma rede e sistemas seguros
Requisito 1: Instalar e manter controlos de segurança de rede. As firewalls, as configurações de routers e a segmentação de rede têm de isolar o ambiente de dados do titular do cartão das redes não fidedignas. Cada regra precisa de uma justificação de negócio documentada.
Requisito 2: Aplicar configurações seguras a todos os componentes do sistema. Sem palavras-passe predefinidas, sem contas predefinidas, sem serviços desnecessários. As bases de referência de reforço (hardening) têm de ser documentadas e aplicadas a todos os sistemas.
Objetivo 2: Proteger os dados de conta
Requisito 3: Proteger os dados de conta armazenados. Os dados do titular do cartão têm de ser cifrados com criptografia forte em repouso. Os dados de autenticação sensíveis (CVV, PIN, pista completa) não podem ser armazenados após a autorização. Se não precisa de armazenar dados do titular do cartão, não o faça. O caminho mais rápido para a conformidade com o Requisito 3 é não ter os dados.
Requisito 4: Proteger os dados do titular do cartão com criptografia forte durante a transmissão. TLS 1.2 ou superior em todas as redes públicas. Os protocolos obsoletos e as cifras fracas têm de ser inventariados e removidos.
Objetivo 3: Manter um programa de gestão de vulnerabilidades
Requisito 5: Proteger todos os sistemas e redes contra software malicioso. Controlos anti-malware em todos os sistemas do CDE. Análises regulares e atualizações de definições.
Requisito 6: Desenvolver e manter sistemas e software seguros. Gestão de patches, práticas de programação segura, gestão de alterações. É aqui que vive o Requisito 6.4.3: o inventário de scripts no lado do cliente e o controlo de integridade que surgiram na 4.0. Consulte o nosso guia prático para cumprir os PCI 6.4.3 e 11.6.1 para a implementação específica.
Objetivo 4: Implementar medidas fortes de controlo de acessos
Requisito 7: Restringir o acesso aos componentes do sistema e aos dados do titular do cartão pela necessidade de conhecimento do negócio. Controlos de acesso baseados em funções, privilégio mínimo, aprovação de acessos documentada.
Requisito 8: Identificar os utilizadores e autenticar o acesso aos componentes do sistema. IDs únicos para cada utilizador, requisitos de palavra-passe fortes, MFA em todos os acessos administrativos ao CDE (reforçado na 4.0.1 no ponto 8.4.2).
Requisito 9: Restringir o acesso físico aos dados do titular do cartão. Controlos físicos nas instalações que armazenam dados do titular do cartão ou que alojam sistemas do CDE.
Objetivo 5: Monitorizar e testar as redes regularmente
Requisito 10: Registar e monitorizar todos os acessos aos componentes do sistema e aos dados do titular do cartão. Registo abrangente, integridade dos registos, revisão dos registos e sincronização horária entre sistemas.
Requisito 11: Testar regularmente a segurança dos sistemas e das redes. Análises de vulnerabilidades (internas e externas, trimestrais), testes de intrusão (anuais + após alterações significativas) e, crítico para a 4.0.1, o Requisito 11.6.1 que abrange a monitorização de cabeçalhos HTTP nas páginas de pagamento.
Objetivo 6: Manter uma política de segurança da informação
Requisito 12: Apoiar a segurança da informação com políticas e programas organizacionais. Política de segurança, avaliação de riscos, formação de sensibilização para a segurança, resposta a incidentes, gestão de fornecedores. O Requisito 12 é o requisito estruturante que liga todos os outros controlos a um compromisso organizacional.
O que há de novo na 4.0.1 face à 3.2.1
A PCI DSS 4.0.1 tornou-se obrigatória em março de 2025. As maiores mudanças desde a 3.2.1:
| Mudança | Requisito | Impacto |
|---|---|---|
| Inventário de scripts + integridade nas páginas de pagamento | 6.4.3 | A maioria dos ambientes tinha cobertura zero antes de 2025 |
| Monitorização de cabeçalhos HTTP nas páginas de pagamento | 11.6.1 | O mesmo, exige um novo artefacto |
| Regras de palavra-passe reforçadas | 8.3.6 | Mínimo de 12 caracteres |
| MFA no acesso administrativo ao CDE | 8.4.2 | Aplica-se à administração fora de consola, não apenas remota |
| Inventário criptográfico | 12.3.3 | Documentação de cifras e protocolos |
| Retenção e revisão de registos | 10.7.2/3 | Requisitos de revisão de registos alargados |
| Abordagem personalizada | Vários | Nova alternativa à abordagem definida para controlos |
A abordagem personalizada permite às organizações cumprir a intenção de um requisito com um controlo diferente do que a norma prescreve, desde que documentem formalmente a análise de risco e os controlos. É poderosa para programas de segurança maduros e perigosa para organizações que a usam para justificar controlos mais fracos.
Onde as auditorias encalham
Ao trabalhar com comerciantes que passam por avaliações da 4.0.1, três padrões surgem repetidamente:
- Requisitos 6.4.3 e 11.6.1: sem inventário de scripts, sem monitorização de integridade, sem monitorização de cabeçalhos HTTP. Consulte o guia para QSA para saber o que os auditores procuram especificamente.
- Alargamento do âmbito: o CDE inclui mais sistemas do que o diagrama de âmbito inicial mostrava, normalmente porque a segmentação é mais fraca do que se assumia
- Provas manuais: os QSA precisam de provas contínuas, não de capturas de ecrã tiradas durante a semana da avaliação
A lista completa de requisitos PCI DSS
O PCI DSS 4.0.1 está organizado em 6 objetivos e 12 requisitos. A lista completa de requisitos PCI DSS é:
- Instalar e manter controlos de segurança de rede.
- Aplicar configurações seguras a todos os componentes do sistema.
- Proteger os dados de conta armazenados.
- Proteger os dados do titular do cartão com criptografia forte durante a transmissão em redes públicas abertas.
- Proteger todos os sistemas e redes contra software malicioso.
- Desenvolver e manter sistemas e software seguros.
- Restringir o acesso aos componentes do sistema e aos dados do titular do cartão pela necessidade de conhecimento do negócio.
- Identificar os utilizadores e autenticar o acesso aos componentes do sistema.
- Restringir o acesso físico aos dados do titular do cartão.
- Registar e monitorizar todos os acessos aos componentes do sistema e aos dados do titular do cartão.
- Testar regularmente a segurança dos sistemas e das redes.
- Apoiar a segurança da informação com políticas e programas organizacionais.
Os requisitos 6.4.3 e 11.6.1, ambos sob o requisito 6 e o requisito 11 acima, são onde reside a segurança de scripts no lado do cliente: o 6.4.3 rege o inventário e a autorização dos scripts das páginas de pagamento, e o 11.6.1 exige a deteção de alterações e adulterações nesses scripts e nos cabeçalhos HTTP críticos.
Onde a cside se encaixa
Os requisitos 6.4.3 e 11.6.1 são o terreno de eleição da cside. O inventário contínuo de scripts, a marcação de justificação de negócio, a monitorização de integridade, a deteção de alterações a cabeçalhos HTTP e um histórico de alertas pronto para auditoria vêm da plataforma. O guia de conformidade com os requisitos 6.4.3 e 11.6.1 da PCI DSS 4.0.1 percorre o que o painel produz e como um QSA o lê.
Para uma visão mais ampla sobre como preparar uma avaliação completa, consulte o guia do Report on Compliance e o guia do SAQ D.
