PCI DSS: níveis e conformidade

1) O que é o PCI DSS e quem precisa dele

• aceita pagamentos com cartões (direto ou via PSP/gateway),
• processando/armazenando/transmitindo dados de cartão (PAN, prazo, CVV) ou seus formulários encriptados/encriptados,
• é um provedor de serviços para outros merchants (hospedagem, processamento, anti-frod, orquestração de pagamento, etc.), se você pode afetar a segurança dos cartões.

Versão e prazo: versão atual - PCI DSS v4. 0. Exigências v3. 2. 1 fora de uso; «futura-dated» itens v4. 0 agora estão a funcionar. Novo no v4. 0: MFA reforçada, «Customized Approach», análise de risco alvo de frequência de procedimentos, clarificação por segmentação e criptografia.

2) Níveis de conformidade: merchantes e provedores de serviços

2. 1 Mercantes (comerciantes)

• Level 1:> 6 milhões de transações/ano ou comprometimento. É necessário um ROC (Relatório on Compliance) anual do QSA ou ISA interno na negociação, + scans ASV trimestrais.
• Level 2: £1-6 milhões/ano. Normalmente SAQ (autoestima) + ASV scan; alguns esquemas/equeiros podem exigir ROC.
• Level 3: £20k-1 milhões de e-commerce/ano. Normalmente SAQ + ASV scan.
• Level 4: abaixo das liminares L3. SAQ; os requisitos podem variar pelo banco equeiro.

2. 2 Provedores de Serviços (Service Providers)

Normalmente nível 2; para Level 1 (grande volume/papel crítico na cadeia) é obrigatório ROC da QSA, para Level 2 é SAQ-D SP (às vezes ROC por exigência de contêineres/circuitos). No iGaming, muitos PSP/gateways/associados de hospedagem são SP Level 1.

3) SAQ vs ROC: como escolher

• SAQ A - apenas redirect/iframe/hosted fields; não tem processamento/transferência/armazenamento de cartões.
• O SAQ A-EP é um e-commerce onde o seu site afeta a segurança da página de pagamento (por exemplo, a hospedagem de script), mas o PAN é introduzido no meio do provedor.
• SAQ B/B-IP - terminais/importadores sem armazenamento eletrônico; Os terminais B-IP estão ligados.
• SAQ C-VT/C - terminais virtuais/pequenos ambientes de processamento, sem armazenamento.
• O SAQ P2PE é apenas uma solução P2PE PCI certificada.
• O SAQ D (Merchant/Service Provider) é uma opção «ampla» para qualquer processamento/transferência/armazenamento, integração de custom, orquestradores, etc.

O caminho-alvo é SAQ A/A-EP através dos fluxos PAN-safe, toquenização e campos de hospedagem. Se você tiver seus próprios serviços de pagamento/valt - normalmente SAQ D ou ROC.

4) Copiar: o que entra no CDE e como encurtá-lo

O CDE (Cardholder Data Organizonment) é um sistema onde são processados/armazenados/transmitidos dados de cartas e todos os segmentos ligados/influentes.

• Hosted fields/iframe/TSP: digitar PAN fora do seu domínio.
• Toquenização e rede de tokens: seus serviços operam em Tóquio, não em PAN.
• P2PE: criptografia fim-final com solução certificada.
• Segmentação de rede: LCA rígida, isolamento CDE do resto do ambiente.
• DLP obrigatório e camuflagem de logs, proibição de dampos com PAN/CVV.

No v4. 0 foi adicionada a flexibilidade dos métodos de realização de metas, mas as provas de eficácia e a análise de risco meta são obrigatórias.

5) «12 requisitos» PCI DSS v4. 0 (blocos de sentido)

1. Proteção de rede e segmentação (firewalls, LCA, isolamento CDE).
2. Configuração segura de hosts/dispositivos (hardning, linhas básicas).
3. Proteja os dados dos portadores de cartões (armazenamento PAN - somente se necessário, criptografia forte).
4. Proteção de dados de transferência (TLS 1. 2 + e equivalentes).
5. Antivírus/anti-malware e controle de integridade.
6. Desenvolvimento seguro e alteração (SDLC, SAST/DAST, controle de bibliotecas).
7. Acesso por necessidade (least privege, RBAC).
8. Identificação e autenticação (MFA para acesso admin e remoto, senhas v4. 0).
9. Segurança física (centros de dados, escritórios, terminais).
10. Logação e monitoramento (centralização de logs, imutabilidade, alertas).
11. Teste de segurança (scan ASV trimestral, pentestes anuais e após alterações, teste de segmentação).
12. Gerenciamento de políticas e riscos (procedimentos, treinamento, incidente-respeito, avaliações de risco, documentos «Customized Approach»).

6) Atividade e periodicidade obrigatórias

Os scans ASV (externos) são trimestrais e após alterações significativas.
Vulnerabilidades/patchings - ciclos regulares (frequências baseadas em TRA - targeted risk analisis).
Pentestais (interior/fundo) - todos os anos e depois de mudanças significativas; a verificação de segmentação é obrigatória.
Registros e monitoramento - contínuo, com retenção e proteção contra modificações.
Treinamento de pessoal - na contratação e seguindo regularmente.
MFA - para todo o acesso à CDE de Admin e remoto.
Inventário de sistemas/fluxos de dados - Atualizar constantemente.

7) matriz de seleção SAQ (curta)

Apenas iframe/redirect, sem PAN você tem SAQ A.
E-commerce, seu site afeta a página de pagamento → SAQ A-EP.
Terminais/importadores → SAQ B/B-IP.
Terminal virtual → SAQ C-VT.
Uma pequena rede de cartas sem armazenamento → SAQ C.
Solução P2PE → SAQ P2PE.
Diferente/complexo/armazenamento/processamento → SAQ D (ou ROC).

8) Artefatos e provas para auditoria

• Diagramas de rede e fluxo de dados, registro de ativos, registro de fornecedores, registro de dados/acessibilidade.
• Políticas/procedimentos: desenvolvimento seguro, gerenciamento de alterações, loging, incidentes, vulnerabilidades, chaves/cripto, acesso remoto, cópias de segurança.
• Relatórios: ASV, pentestais (segmentação incluída), canos de vulnerabilidade, resultados de alterações.
• Revistas/alertas, sistema centralizado, imutável, anistia de incidentes.
• KMS/HSM procedimentos, rotações, inventário de chaves/certificados.
• Provas de «Customized Approach» (se aplicadas): objetivos de controle, método, métricas de eficiência, TRA.
• Contornos de responsabilidade de terceiros: AoC associados (PSP, hospedagem, CDN, anti-frod), matriz Shared Respondability.

9) Projeto de conformidade (passo a passo)

1. Coping e análise GAP: identifique CDE, segmentos adjacentes, quebras atuais.
2. Ganhos rápidos: fluxo PAN-safe (iframe/hosted fields), toquenização, proibição do PAN em logs, encerrar vulnerabilidades critas «externas».
3. Segmentação e rede: isolar CDE, mTLS, firewall-LCA, acessíveis por least-privege, MFA.
4. Observabilidade: Logação centralizada, retenção/cadeia de segurança, alertas.
5. Gerenciamento de vulnerabilidades e código: SAST/DAST, patches, SBOM, controle de dependências.
6. Testes: scans ASV, pentestais internos/externos, verificação de segmentação.
7. Documentos e treinamento: procedimentos, playbooks IR, treinamentos, registros de treinamento.
8. Selecione SAQ (tipo) ou ROC; concordar com o equador/marcas.
9. Ciclo anual: suporte, provas, revisão de risco/frequência, sobreposição.

10) Integração com a arquitetura iGaming

O orquestrador de pagamento funciona apenas com os tokens; O PAN não vê.
Multi-PSP: health-checks, smart-routing, idempotency, ретраи; AoC de cada PSP.
Pneu Event-driven/DWH: nada de PAN/CVV; camuflar os últimos 4 dígitos; DLP-gates em CI/CD.
Cheques 3DS/SCA: armazenar apenas os artefactos necessários (identificadores de transações), sem dados sensíveis.

11) Erros frequentes

Loging PAN/CVV e máscaras de nevalida.
«Temporização» do PAN através de API/pneus internos.
Não há teste de segmentação na pentesta.
Frequência indevida de procedimentos (nenhum TRA v4. 0).
Dependência de um PSP sem AoC e sem fallback.
Segmentos «influentes» não contabilizados (admin-jump-hosts, monitoramento, bacapes).

12) Folha de cheque de partida rápida (iGaming)

• Ir para hosted fields/iframe; remover a entrada do PAN dos seus formulários.
• Incluir toquenização/tokens de rede; excluir o PAN dos eventos/logs.
• Copiar CDE e isolar o segmento (MFA, RBAC, mTLS).
• Ajustar logs e alertas centralizados (imutável, retoma).
• Iniciar scans ASV, eliminar críticos/altos.
• Realizar pentestais (intra/oblíquo) + teste de segmentação.
• Preparar políticas/procedimentos e provas de execução.
• Alinhar o formulário de avaliação com o equador (SAQ tipo/ROC).
• Obter e armazenar AoC de todos os fornecedores de creme.
• Incorporar controles PCI no ciclo de lançamento (SDLC, IaC hardning, DLP em CI/CD).

13) FAQ curta

A QSA é necessária? Para a ROC, sim. A SAQ muitas vezes é bastante auto-processada, mas muitos equeiros/marcas podem exigir QSA/ASV parceiro.
Se não guardarmos o PAN? Ainda está sujeito ao PCI DSS se aceitar cartões. Tente alcançar o SAQ A/A-EP.
O 3DS resolve o PCI? Não. 3DS - sobre autenticação; O PCI é sobre proteção de dados.
O TLS é suficiente? Não. Precisamos de todas as exigências válidas v4. 0, incluindo processos e provas.

14) Resumos

Para iGaming, a melhor estratégia é minimizar o acervo (PAN-safe, tocenização, hosted fields, P2PE onde possível), segmentar severamente a CDE, automatizar o loging/vulnerabilidade/pentestes, montar um pacote completo de artefatos e escolher uma forma correta de confirmação (SAQ ou ROC) em seu nível. Isso reduz o risco, acelera a integração com o PSP e mantém a conversão e a monetização estáveis, atendendo às exigências das marcas de cartões.