c1.2 Limitar o acesso de rede de e para o CDE
Restringir explicitamente o tráfego de entrada e saída do ambiente de dados do portador do cartão ao mínimo necessário para as funções de negócio, aplicando o princípio de negação por padrão.
Requisito 1
Instalar e Manter Controles de Segurança de Rede
Sub-requisitos PCI cobertosCobertura mostrada por sub-controle do PCI DSS v4.0.1. “Coberto” = atendido por esta recomendação da AWS. “No roadmap” = técnico, planejado. “Sua responsabilidade” = controle organizacional/de processo. “Fora do escopo” = controle físico ou de terceiros não implementado na AWS.
1.3 O acesso de rede de e para o CDE é restringido
- 1.3.1 Inbound traffic to the CDE is restricted to what is necessary Coberto
- 1.3.2 Outbound traffic from the CDE is restricted to what is necessary Coberto
- 1.3.3 NSCs installed between all wireless networks and the CDE Coberto
1.4 As conexões de rede entre redes confiáveis e não confiáveis são controladas
- 1.4.1 NSCs between trusted and untrusted networks Coberto
- 1.4.2 Inbound traffic from untrusted networks to trusted is restricted Coberto
- 1.4.3 Anti-spoofing measures detect and block forged source IPs Coberto
- 1.4.4 System components storing CHD not directly reachable from untrusted networks Coberto
- 1.4.5 Disclosure of internal IP/routing information is limited Coberto
Como implementar na AWS
Projetar sub-redes dedicadas para o CDE com Network ACLs restritivas além dos security groups. Documentar e justificar cada regra permitida. Usar security groups com referências entre grupos em vez de faixas de IP amplas. Restringir o tráfego de saída do CDE a destinos aprovados.
Implementação prática
Como este controle é implementado em cada arquitetura de referência:
Envolva as camadas do CDE em uma postura de negação por padrão: security groups para a lista de permitidos, NACLs como reforço no nível da sub-rede e saída privada apenas para serviços da AWS.
- Coloque a camada de dados em suas próprias sub-redes privadas e anexe uma Network ACL que permita apenas a porta de banco de dados a partir das sub-redes de app e negue todo o resto (negação por padrão no limite da sub-rede).Camada de dados (CDE)
Amazon VPC - Mantenha uma matriz de fluxos autorizados (origem, destino, porta, justificativa de negócio) que corresponda exatamente às suas regras de security group e NACL; trate-a como o artefato de evidência para 1.3/1.4.Todas as camadas do CDE Amazon VPC
- Restrinja o tráfego de saída do CDE apenas aos serviços da AWS de que ele precisa (por exemplo, Secrets Manager, KMS) usando VPC endpoints, de modo que esse tráfego nunca passe pela internet pública.Camada de app (CDE) / Camada de dados (CDE) Amazon VPC
Secrets Manager 
AWS KMS
Como validar: As exportações de NACL e security groups correspondem linha por linha à matriz de fluxos autorizados, e um teste de conectividade da camada de dados para qualquer destino não aprovado é negado.
Evite: Usar faixas CIDR amplas (por exemplo, 10.0.0.0/8) nas regras «para simplificar». Referencie security groups de origem em vez disso, para que a lista de permitidos permaneça restrita à medida que a rede cresce.
Force todo o tráfego do CDE pela rota central de entrada/inspeção, reforce a negação por padrão com SCPs e mantenha o tráfego para serviços da AWS privado com VPC endpoints compartilhados.
- Roteie a entrada nas contas de carga do CDE apenas pela rota de entrada da conta de rede central; bloqueie a entrada direta da internet nas VPCs das contas.Conta de rede/inspeção → OU de PCI
Transit Gateway Amazon VPC - Force o tráfego leste-oeste e de saída de cada conta do CDE pela VPC de inspeção central para que uma única política governe todos eles.Conta de rede/inspeção Transit Gateway
Network Firewall - Reforce a negação por padrão com SCPs na OU de PCI (por exemplo, negar criar internet gateways ou recursos públicos nas contas do CDE).OU de PCI (guarda-corpo)
AWS Organizations - Forneça VPC endpoints centralizados (na conta de rede compartilhada) para que o tráfego do CDE para serviços da AWS não passe pela internet pública em nenhuma conta.Conta de rede/inspeção Amazon VPC
Como validar: As tabelas de rotas do Transit Gateway mostram que as contas do CDE só alcançam a rota de inspeção, e uma tentativa de anexar um internet gateway em uma conta do CDE é negada pela SCP.
Evite: Fazer peering das contas do CDE diretamente entre si por conveniência. Mantenha todas as rotas pela VPC de inspeção para que a segmentação e o registro permaneçam centralizados e comprováveis.
Validação PCI
Procedimentos de teste
- Examinar os padrões e as configurações dos NSCs para verificar que o tráfego de entrada ao CDE é restringido ao mínimo necessário, negando especificamente todo o demais tráfego (1.3.1.a, 1.3.1.b).
- Examinar as configurações dos NSCs para verificar que o tráfego de saída do CDE é restringido ao mínimo necessário (1.3.2.a, 1.3.2.b).
- Examinar os padrões de configuração e os diagramas de rede para verificar que há NSCs entre as redes confiáveis e não confiáveis (1.4.1.a, 1.4.1.b).
Evidência na AWS
- Diagrama de rede e matriz de fluxos autorizados que corresponde às regras de security group e NACLs implementadas.
- Exportação das Network ACLs das sub-redes do CDE mostrando regras de negação por padrão.
- Registros de justificativa de negócio para cada regra permitida.
Abordagem personalizada
Requer uma análise de risco direcionada (Req 12.3.2).
Objetivo da abordagem personalizada
- 1.3 — O tráfego não autorizado não pode entrar no CDE.
- 1.4 — O tráfego não autorizado não pode atravessar os limites de rede entre redes confiáveis e não confiáveis.
Serviços AWS
Amazon VPC Network ACLs Security Groups Recursos de aprendizado
Referências
- AWS Security Maturity Model: Limit Network Access