Teste de intrusão PCI DSS 11.4: interno, externo e segmentação

Porque é que o 11.4 chumba auditorias que "tinham pentest"

Quase todas as empresas que tratam dados de cartões sabem que precisam de um teste de intrusão. A surpresa surge na auditoria: o QSA abre o requisito 11.4 do PCI DSS 4.0.1 e não pergunta "fizeram um pentest?". Percorre uma lista de subrequisitos, cada um com a sua evidência: metodologia, teste interno, teste externo, correção e reteste, segmentação. É frequente um relatório cobrir quatro e deixar dois em aberto, e a empresa acaba por pagar duas vezes.

Este guia complementa o artigo sobre o que o auditor espera realmente do seu relatório. Aqui o foco é o próprio requisito: o que cada subrequisito diz, que evidência o QSA costuma pedir, como definir o âmbito do teste e onde as empresas tropeçam.

O 11.4 num relance

Item	O que exige	Evidência que o QSA costuma pedir
11.4.1	Metodologia de pentest definida, documentada e implementada	Documento da metodologia, referência ao NIST SP 800-115, PTES ou OWASP WSTG, registo de como foi aplicada
11.4.2	Pentest interno pelo menos de 12 em 12 meses e após alterações significativas, por testador qualificado e independente	Relatório com datas, âmbito, credenciais usadas e qualificação da equipa
11.4.3	Pentest externo com a mesma periodicidade e os mesmos gatilhos	Relatório separado do interno, a cobrir o perímetro e os sistemas expostos
11.4.4	Vulnerabilidades exploráveis corrigidas de acordo com o risco e teste repetido para confirmar	Estado por vulnerabilidade após o reteste, com data e evidência
11.4.5	Controlos de segmentação testados pelo menos de 12 em 12 meses e após alterações a esses controlos	Secção explícita com todos os segmentos testados e o resultado
11.4.6	Só para prestadores de serviços: segmentação testada de 6 em 6 meses e após alterações	Dois ciclos por ano, cada um com evidência
11.4.7	Só para prestadores de serviços multi-inquilino: apoiar os clientes no teste externo (11.4.3 e 11.4.4)	Evidência (mesmo que redigida) de que a infraestrutura do cliente foi testada, ou acesso para o cliente a testar

Confirme sempre o texto na versão em vigor publicada pelo PCI SSC. A numeração segue o PCI DSS 4.0.1, e o 11.4.7 passou de boa prática a obrigatório depois de 31 de março de 2025.

11.4.1: a metodologia tem de estar escrita

A norma pede uma abordagem aceite pela indústria. Na prática, o relatório cita o NIST SP 800-115, o PTES ou o OWASP WSTG e explica como foi aplicada. Deve abranger:

todo o perímetro do CDE e os sistemas críticos;
testes a partir de dentro e de fora da rede;
validação dos controlos de segmentação e de redução de âmbito;
testes na camada aplicacional (no mínimo as vulnerabilidades do requisito 6.2.4) e na camada de rede;
a análise das ameaças e vulnerabilidades dos últimos 12 meses;
uma abordagem documentada para tratar o risco do que for encontrado;
conservação dos resultados e da remediação durante, pelo menos, 12 meses.

Guarde a metodologia como documento da empresa, e não apenas como uma página do relatório do fornecedor. O QSA pode pedir o procedimento mesmo que o PDF já cite a norma.

Âmbito: o CDE e tudo o que comunica com ele

A maior causa de chumbo não é técnica, é de âmbito. O CDE inclui os sistemas que armazenam, processam ou transmitem dados de cartões e também os que se ligam a eles ou podem afetar a sua segurança. Tipicamente:

aplicações de pagamento, APIs e painéis de administração;
bases de dados e filas com PAN;
servidores de salto, VPN e contas de administração que chegam ao CDE;
ambientes cloud (VPC, security groups, contas) ligados ao CDE;
integrações com adquirentes, gateways e antifraude.

O âmbito do pentest tem de coincidir com o diagrama de rede e o fluxo de dados que entrega ao QSA. Se o diagrama mostra cinco sub-redes e o relatório testou duas, o requisito fica em aberto.

Exemplo de âmbito: uma loja online com checkout próprio

Imagine uma loja que recebe o cartão no seu próprio checkout. Tem uma rede corporativa, uma VPC de produção com a aplicação e uma VPC isolada com a base de dados que guarda o PAN cifrado, acessível apenas através de um servidor de salto. A empresa afirma que a rede corporativa e a VPC da aplicação estão "fora" do CDE por segmentação.

Um âmbito defensável para o pentest seria:

Externo (11.4.3): o site, as APIs, o painel de administração, a VPN, o DNS e qualquer serviço descoberto no inventário de IP públicos.
Interno (11.4.2): a partir da rede corporativa como utilizador comum, e a partir de dentro da VPC da aplicação, a tentar chegar à base de dados e ao servidor de salto.
Segmentação (11.4.5): a partir de cada segmento declarado "fora do CDE" (corporativo, aplicação, ambientes de teste e redes de terceiros) para o CDE, em todas as portas e caminhos.
Aplicação: testes autenticados no checkout e no painel, com perfis diferentes.

Repare que "fora do CDE por segmentação" só é válido se o teste de segmentação o demonstrar. Se um servidor da VPC da aplicação alcança a base de dados, esse servidor passa a estar no âmbito do PCI.

11.4.2 e 11.4.3: interno e externo são testes diferentes

O teste externo parte da internet contra aquilo que está exposto: sites, APIs, VPN, correio eletrónico, DNS, serviços esquecidos. O teste interno parte de dentro: da rede corporativa, de um segmento não confiável ou do próprio CDE, a simular um atacante que já passou o perímetro, um colaborador malicioso ou um dispositivo comprometido.

Uma análise de vulnerabilidades externa (ASV) não substitui nenhum dos dois. O ASV responde ao requisito 11.3.2; o pentest é conduzido por uma pessoa, prova a exploração e encadeia falhas. Os dois coexistem.

A alteração significativa é o gatilho que muitas empresas esquecem. Uma nova aplicação de pagamento, uma migração para a cloud, uma troca de adquirente ou uma mudança de topologia ou de firewall dentro do âmbito exigem novo teste, mesmo que o anual tenha sido feito em março. Defina internamente o que conta como alteração significativa e registe a decisão com data.

11.4.4: o reteste não é opcional

As vulnerabilidades exploráveis têm de ser corrigidas de acordo com o risco que lhes foi atribuído, e o teste repetido para confirmar. O relatório final mostra, por vulnerabilidade, o estado: corrigida e validada, pendente com prazo, ou risco aceite com justificação formal. Um PDF sem secção de reteste deixa o 11.4.4 sem evidência.

Planeie o calendário com folga: pentest em outubro, correção em novembro e reteste em dezembro cabem no ano. Um pentest em dezembro, não.

11.4.5 e 11.4.6: segmentação, o ponto mais chumbado

Segmentar a rede reduz o âmbito do PCI, mas só se alguém provar que a segmentação funciona. O teste tenta, a partir de redes fora do CDE, alcançar o CDE por todas as portas e caminhos que os controlos deviam bloquear: VLAN, firewalls, ACL, regras de security group e políticas de rede do Kubernetes.

Teste cada segmento fora do CDE em direção ao CDE, e não uma amostra.
Abranja todos os controlos de segmentação, incluindo os de cloud e de contentores.
Repita após qualquer alteração a esses controlos.
Os prestadores de serviços repetem de 6 em 6 meses (11.4.6), e não uma vez por ano.
O resultado tem de ser explícito: "nenhum caminho encontrado", com evidência, ou os caminhos encontrados.

Onde as empresas tropeçam

Segmentação declarada, nunca testada. O diagrama mostra isolamento, mas ninguém tentou atravessá-lo. É a observação de auditoria mais comum neste requisito.
Apenas testes sem autenticação. O pentest chega ao login e pára. O risco real está por detrás, com perfis comuns e de administração.
Reteste sem data ou sem evidência. A vulnerabilidade "desapareceu" do relatório novo, mas não há prova de que foi corrigida.
Âmbito menor do que o diagrama. O fornecedor testa os IP que o cliente indicou e o ambiente de testes com dados reais fica de fora.
Falta de independência. Quem opera o ambiente também o testa.
Alteração significativa ignorada. A migração para a cloud aconteceu depois do pentest anual e não originou novo teste.
Ferramenta em vez de pessoa. Um relatório que é a saída de um scanner não prova exploração nem metodologia.

Quem pode testar: qualificação e independência

A norma exige que o testador seja qualificado e organizacionalmente independente de quem gere o ambiente testado. Não tem de ser QSA nem ASV. A equipa de infraestrutura que opera o CDE não deve ser a que o testa. Uma equipa interna de segurança separada pode cumprir, se a independência organizacional for real, e um fornecedor externo costuma simplificar a conversa com o QSA.

Peça ao fornecedor os currículos e as certificações dos testadores e inclua a identificação no relatório. Veja também as 10 perguntas a fazer antes de contratar um pentest.

Como escolher o fornecedor para o 11.4

Peça um relatório de exemplo anonimizado e verifique se tem metodologia, evidência reproduzível, secção de segmentação e reteste.
Pergunte se o reteste está incluído e quantas rondas.
Confirme que a mesma equipa cobre rede e aplicação, ou que há coordenação entre elas.
Verifique se o fornecedor aceita testar segmento a segmento e entregar o resultado da segmentação em separado.
Combine o formato de entrega com o QSA antes de contratar, para evitar retrabalho.

Lista de verificação antes de contratar

[ ] Diagrama de rede e fluxo de dados de cartões atualizados
[ ] Lista de todos os segmentos "fora do CDE" que dependem de segmentação
[ ] Inventário de IP, domínios e APIs expostos
[ ] Contas de teste para cada perfil (utilizador comum, administrador, parceiro)
[ ] Definição interna de "alteração significativa" e histórico do último ano
[ ] Janelas de teste combinadas com as operações e o NOC
[ ] Contactos de emergência durante a execução
[ ] Data prevista do reteste e responsável pelas correções

Como organizar o ano

Trimestre 1: âmbito e diagrama de rede atualizados; contratação.
Trimestre 2: pentest externo, interno e de segmentação.
Trimestre 3: correções e reteste; arquivo das evidências.
Contínuo: gatilho de alteração significativa e, para prestadores de serviços, segmentação de 6 em 6 meses.

Para saber o que esperar em preço e prazo, veja quanto custa um teste de intrusão.

Perguntas frequentes

Uma análise de vulnerabilidades substitui o pentest do 11.4?

Não. A análise automatizada responde a outros requisitos, como o 11.3. O 11.4 exige um teste conduzido por uma pessoa qualificada, com metodologia e prova de exploração.

Com que frequência é preciso fazer o pentest PCI?

No mínimo de 12 em 12 meses, interno e externo, e também após qualquer alteração significativa na infraestrutura ou nas aplicações abrangidas.

Quando é obrigatório o teste de segmentação?

Se utiliza a segmentação para reduzir o âmbito do PCI, esta tem de ser testada pelo menos de 12 em 12 meses e após alterações aos controlos. Os prestadores de serviços testam de 6 em 6 meses.

A equipa interna pode fazer o pentest?

Pode, desde que seja qualificada e organizacionalmente independente de quem opera o ambiente testado. Muitas empresas contratam um fornecedor externo para simplificar a avaliação do QSA.

O reteste tem de constar do relatório?

Sim. O requisito pede que as vulnerabilidades exploráveis sejam corrigidas e o teste repetido, e o relatório deve mostrar o estado de cada uma após o reteste.

O pentest tem de ser feito por um QSA ou ASV?

Não. A norma exige um testador qualificado e independente, e não que seja QSA ou ASV. O QSA é quem avalia a evidência na auditoria.

É preciso testar os ambientes de testes?

Se estiverem ligados ao CDE ou usarem dados reais de cartões, sim, estão no âmbito. Ambientes isolados e sem dados reais podem ficar de fora, desde que a segmentação seja demonstrada.

Sou prestador de serviços multi-inquilino. O que muda?

Além do 11.4.6, o 11.4.7 pede que apoie os clientes no teste externo, com evidência de que a infraestrutura deles foi testada ou com acesso para que testem por conta própria.

Próximo passo

Se a sua auditoria PCI está no calendário, o melhor momento para alinhar âmbito e diagrama é antes do teste. Peça um orçamento e receba uma proposta com âmbito, segmentação e reteste incluídos.