Requisito 8 do PCI DSS 4.0: MFA obrigatório

Com a chegada da nova versão do PCI DSS, a 4.0, um dos pontos que mais chamou atenção foi a atualização do Requisito 8, que trata da autenticação de usuários. A partir de agora, a exigência de MFA PCI DSS 4.0 (autenticação multifator) ganhou mais abrangência e detalhes, impactando todas as empresas que buscam a conformidade com o padrão. 

Neste artigo, vamos explicar o que mudou no Requisito 8 do PCI DSS, detalhar os novos subitens 8.4 a 8.6, falar sobre a escolha de métodos como FIDO2 e mostrar como planejar uma implantação corporativa eficiente. 

O Requisito 8 tem como foco principal garantir que apenas pessoas autorizadas possam acessar os sistemas que armazenam, processam ou transmitem dados de cartões de pagamento. 

Com a atualização para o PCI DSS 4.0, o requisito ficou mais rigoroso em relação à autenticação multifator (MFA), que agora é obrigatória para: 

• Todos os acessos administrativos; 

• Todos os acessos de usuários com privilégios elevados; 

• Todos os acessos remotos ao ambiente PCI, mesmo para usuários comuns. 

Os novos subitens do Requisito 8 PCI DSS 4.0 trazem especificações claras sobre como a autenticação multifator deve ser implementada. 

✅ 8.4 – MFA obrigatória para todos os acessos ao ambiente PCI por usuários com privilégios administrativos 

Antes da versão 4.0, a MFA era exigida principalmente para acessos remotos. Agora, o escopo ampliou: qualquer acesso administrativo ao ambiente PCI DSS requer MFA, mesmo em conexões locais. 

 

✅ 8.5 – MFA obrigatória para todos os acessos remotos ao ambiente PCI 

Esse item reforça a exigência já existente, mas agora inclui todos os tipos de acesso remoto, independentemente do nível de privilégio do usuário. 

Exemplos de acessos remotos que precisam de MFA: 

• VPN; 

• Acesso remoto via desktop virtual (VDI); 

• Conexões RDP; 

• Ferramentas de suporte remoto. 

 

✅ 8.6 – Independência dos fatores de autenticação 

Aqui está uma mudança importante: os fatores de autenticação devem ser independentes entre si. Isso significa que um fator não pode ser comprometido como consequência da violação de outro. 

• Exemplo errado: Usar uma senha e um token enviado por e-mail para o mesmo usuário. 
• Exemplo correto: Combinar senha + aplicativo autenticador (Google Authenticator, Microsoft Authenticator) ou senha + biometria, garantindo que os fatores sejam de diferentes categorias. 

A MFA PCI DSS 4.0 exige que o usuário comprove sua identidade utilizando pelo menos dois dos três fatores abaixo: 

1. Algo que você sabe: Exemplo: senha ou PIN. 

2. Algo que você tem: Exemplo: token físico, aplicativo autenticador. 

3. Algo que você é: Exemplo: impressão digital, reconhecimento facial. 

Importante: As implementações devem ser comprovadas com evidências durante a auditoria, como capturas de tela, configurações de sistema e logs de autenticação. 

Com o aumento das exigências do Requisito 8 PCI DSS, muitas empresas estão avaliando opções modernas de MFA. Uma das mais recomendadas atualmente é a autenticação baseada em FIDO2. 

O que é FIDO2? 

O FIDO2 é um padrão de autenticação sem senha, baseado em criptografia de chave pública. Ele permite que os usuários façam login com biometria, tokens físicos (como YubiKeys) ou dispositivos móveis. 

• Redução de riscos de phishing; 

• Eliminação de senhas fracas; 

• Melhor experiência para o usuário final; 

• Atende aos requisitos de independência de fatores (exigido no item 8.6); 

• Fácil integração com soluções de IAM (Identity and Access Management). 

• Aplicativos autenticadores (ex: Google Authenticator, Microsoft Authenticator); 

• Tokens físicos de hardware; 

• SMS (não recomendado, mas ainda aceito com ressalvas); 

• Biometria (com cuidado para proteger os dados biométricos). 

Dica: Avalie o custo-benefício de cada solução, considerando o número de usuários e o tipo de acesso. 

Implementar MFA PCI DSS 4.0 exige mais do que instalar uma ferramenta. É necessário um plano de implantação estruturado, que contemple: 

1. Levantamento de usuários impactados 

Identifique: 

• Quem são os usuários com privilégios administrativos; 

• Quem realiza acessos remotos; 

• Quais sistemas fazem parte do ambiente PCI. 

 

2. Escolha da solução tecnológica 

Avalie: 

• Compatibilidade com sua infraestrutura atual (Active Directory, VPN, etc.); 

• Suporte a múltiplos fatores (FIDO2, aplicativos autenticadores, etc.); 

• Capacidade de gerar logs e relatórios de autenticação (importante para a auditoria PCI). 

 

3. Planejamento de rollout por fases 

Evite implementar de uma vez para todos os usuários. Siga etapas: 

1. Piloto com equipe de TI; 

2. Expansão para administradores; 

3. Implementação em usuários remotos; 

4. Ampliação gradual conforme necessidade. 

 

4. Treinamento e comunicação interna 

Prepare materiais de apoio para os usuários: 

• Manuais de uso; 

• Perguntas frequentes; 

• Suporte técnico para dúvidas. 

 

5. Testes de conformidade antes da auditoria 

Antes da próxima auditoria PCI, garanta que: 

• Todos os usuários impactados estão utilizando MFA; 

• As configurações estão alinhadas com os requisitos 8.4 a 8.6; 

• Logs de autenticação estão disponíveis para verificação. 

A Cipher oferece consultoria e serviços gerenciados para atender ao Requisito 8 PCI DSS, incluindo: 

✅ Análise de gaps na autenticação de usuários; 
✅ Recomendação da solução de MFA mais adequada (inclusive FIDO2); 
✅ Apoio na configuração e rollout corporativo; 
✅ Treinamento de equipes técnicas e usuários finais; 
✅ Suporte na coleta de evidências para a auditoria; 
✅ Monitoramento contínuo da eficácia do MFA. 

O Requisito 8 do PCI DSS 4.0 elevou o nível de exigência para autenticação de usuários. A partir de agora, a autenticação multifator PCI não é mais opcional nem limitada ao acesso remoto: ela é uma exigência corporativa. 

Com planejamento adequado, escolha das tecnologias certas e o suporte de especialistas como a Cipher, sua empresa pode atender aos novos requisitos com segurança e eficiência. 

Entre em contato com a Cipher e garanta a conformidade do seu ambiente antes da próxima auditoria PCI DSS