Modelo de Maturidade de Segurança PCI DSS para AWS

O eixo vertical são os 12 requisitos do PCI DSS (agrupados em 6 objetivos de controle). O eixo horizontal são 4 fases de maturidade priorizadas por facilidade/custo versus impacto: Quick Wins, Foundational, Efficient e Optimized. Cada célula contém uma ou mais recomendações de controle na AWS. As fases são um roteiro, não uma nota de maturidade: comece pelos Quick Wins (alto impacto, baixo esforço) e avance para Optimized (conformidade contínua e automatizada). As recomendações estão alinhadas ao PCI DSS v4.0.1; consulte o Histórico de alterações para ver a versão do modelo e as atualizações futuras.

Cada recomendação indica o que é o controle e por que importa (resumo), como implementá-lo na AWS (guia de implementação e serviços AWS), como seria validado (métodos de comprovação PCI e procedimentos de teste) e que evidência você pode apresentar na AWS. Cada recomendação também é etiquetada com sua fase de maturidade, seu domínio de segurança AWS, os sub-requisitos PCI que cobre, o esforço/impacto, se se aplica ao CDE e sua classificação de responsabilidade compartilhada.

O modelo oferece dois caminhos de arquitetura de referência para hospedar um ambiente de dados do portador do cartão (CDE) na AWS: um desenho de conta única e três camadas para ambientes menores ou iniciais, e um desenho multi-conta com uma unidade organizacional (OU) dedicada ao PCI para escala, segregação de funções e redução de escopo.

Não são apenas diagramas de contexto. Na página de detalhe de cada recomendação, uma seção de Implementação prática mostra como esse controle específico é aplicado em cada arquitetura, para que você veja a diferença entre, por exemplo, isolar o CDE com sub-redes em uma única conta e isolá-lo em uma conta dedicada sob uma OU de PCI. Comece na página de Arquiteturas de referência para entender os dois caminhos e depois use a matriz e o guia prático de cada controle para planejar sua implementação.

Na AWS, a conformidade com o PCI DSS é uma responsabilidade compartilhada. Cada recomendação é classificada como 'cliente' (você a implementa e a evidencia), 'aws' (a AWS opera o controle; você o herda e o evidencia com o Attestation of Compliance PCI DSS da AWS obtido no AWS Artifact) ou 'compartilhada' (ambas as partes têm obrigações). Essa classificação é derivada do System Security Plan da AWS em formato OSCAL. A segurança física (Requisito 9.2, 9.3) é um exemplo típico de 'aws'; as políticas e a gestão de riscos (Requisito 12) costumam ser de 'cliente'.

O PCI DSS v4.0.1 permite duas formas de cumprir a maioria dos requisitos.

• Abordagem definida (Defined Approach): você implementa o requisito exatamente como está escrito e ele é validado contra os procedimentos de teste definidos pelo padrão. É o que descrevem os campos de 'procedimentos de teste' e 'evidência na AWS' de cada recomendação, e é o caminho que a maioria das organizações segue.

• Abordagem personalizada (Customized Approach): em vez de seguir o método prescrito, você projeta seus próprios controles que cumprem o Objetivo da Abordagem Personalizada do requisito. Este caminho é para organizações maduras com uma função robusta de gestão de riscos. Exige uma análise de risco direcionada documentada (Requisito 12.3.2), e o avaliador deriva procedimentos de teste sob medida para confirmar que seus controles cumprem o objetivo.

Por isso, cada recomendação elegível inclui o Objetivo da Abordagem Personalizada do(s) sub-requisito(s) que cobre, para que uma equipe que escolha o caminho personalizado saiba qual resultado seus controles sob medida devem alcançar. Nem todo controle é elegível: alguns são apenas de abordagem definida (por exemplo, não armazenar dados sensíveis de autenticação sob o Requisito 3.3). As abordagens personalizadas costumam aparecer na fase Optimized, onde as organizações otimizam como cumprem os objetivos em vez de como o requisito está escrito.

Como cada recomendação carrega etiquetas estruturadas, o mesmo conteúdo pode ser visto por requisito PCI (a matriz padrão), por fase de maturidade (um roteiro), por domínio de segurança AWS (uma visão transversal) ou por responsabilidade compartilhada (cliente vs herdado da AWS). Você também pode filtrar por se um controle se aplica ao CDE e por esforço/impacto.

O modelo está disponível em inglês (idioma fonte), espanhol e português. O texto dos requisitos e os procedimentos de teste estão alinhados com o padrão oficial PCI DSS v4.0.1; a classificação de responsabilidade compartilhada e o catálogo de controles provêm do pacote OSCAL do PCI DSS da AWS; e o guia da AWS baseia-se no guia de PCI DSS na AWS, na AWS Security Reference Architecture e no AWS Security Maturity Model.