Acelere a adoção do PCI DSS com o MongoDB Atlas

Como é a aparência do PCI DSS e onde as camadas são divididas

O Conselho de Padrões de Segurança PCI mantém o PCI DSS e organiza um conjunto de requisitos agrupados sob objetivos de controle:

No modelo de responsabilidade compartilhada, esses requisitos divisão nessas camadas:

• Camada de infraestrutura (responsabilidade do provedor): compreende segurança física, controles de rede, aplicação de patches de plataforma e criptografia em descanso do armazenamento subjacente. O MongoDB Cloud é um provedor de serviços certificado PCI DSS, validado por um QSA, Coalfire Sistemas. Para o ambiente CRD no MongoDB Cloud, um QSA pode confiar no MongoDB Cloud AOC, disponível sob solicitação por meio do MongoDB Trust Center. Essa camada pré-validada elimina a necessidade de os clientes auditarem novamente a infraestrutura subjacente.

• Camada de aplicativo (responsabilidade do cliente): compreende como o produto armazena, protege, consultas, máscara e auditorias do CAD e quem tem permissão para ler as informações. Essa camada continua sendo a decisão de design do cliente.

figura 1. Modelo em camadas de responsabilidade compartilhada do PCI DSS

clique para ampliar

O projeto PSP preenche a camada do aplicação . É composto por uma arquitetura de referência e um conjunto de melhores práticas. Ele mostra como usar o MongoDB para alinhar a camada de aplicação com os objetivos de controle do PCI DSS para proteger os dados armazenados, restringir o acesso, monitorá-los e reduzir o escopo da auditar . Este projeto constitui um ponto de partida para acelerar a implantação do PCI DSS.

A proposta arquitetônica

O projeto PSP é uma plataforma PSP alinhada ao PCI DSS. Ele executa o ciclo de vida de pagamento no MongoDB Atlas: checkout e autorização de cartão , pontuação automatizada de fraudes e análise de analistas de vários níveis. Ele mostra como os analistas podem pesquisar dados criptografados com uma lógica de design clara:

Criptografe tudo. Faça uma query de qualquer coisa. As chaves são suas.

Com a camada de infraestrutura herdada do Atlas (consulte a figura 1), o trabalho restante acontece na camada de aplicação . O Atlas oferece diversas funcionalidades para dar suporte a esse trabalho, sendo a Queryable Encryption a principal funcionalidade. O conjunto completo de recursos é enumerado na seção Recursos do MongoDB .

Queryable Encryption em foco

Com uma abordagem convencional, um campo é mantido em texto simples para que possa ser pesquisado (legível por qualquer pessoa com acesso ao banco de dados ) ou criptografado para que fique protegido (mas não seja mais pesquisável). A Queryable Encryption remove esse problema para os tipos de query compatíveis.

figura 2. Arquitetura de criptografia do MongoDB : camadas de Queryable Encryption, gerenciamento de chaves e proteção de dados

clique para ampliar

Para um campo pesquisável de igualdade , o fluxo prossegue da seguinte forma:

• O driver criptografa o valor de pesquisa no lado do cliente , usando a DEK do campo.

• O servidor compara esse valor criptografado com um índice criptografado. Ele compara texto cifrado com texto cifrado e não descriptografa o campo.

• Quando os documentos correspondentes retornam ao processo do aplicação , o driver descriptografa os campos de destino na memória. O MongoDB Atlas armazena e processa somente texto cifrado, mantido como Subtipo Binário BSON 06; como resultado, um administrador de banco de dados com acesso completo ao cluster vê apenas bytes opacos.

O efeito concreto no projeto PSP : um analista de fraudes procura um cliente por e-mail, telefone ou referência de conta criptografados e obtém o registro de volta, enquanto o valor do texto simples não chega ao Atlas. Esse recurso mantém a PII sensível criptografada em repouso e disponível por valor, sem a descriptografia em massa que amplia o CDE.

Os campos que precisam de proteção, mas não de pesquisa, usam um modo não pesquisável , descriptografado apenas para uma solicitação autorizada e escalonada. A seção do modelo de dados abrange ambos os modos e os campos que eles protegem.

Recursos do MongoDB para a camada de aplicativos

O projeto PSP combina vários recursos do MongoDB e Atlas . Cada um mapeia para uma parte específica do trabalho da camada de aplicativo do PCI DSS:

Casos de uso adjacentes

Os princípios básicos desta solução, incluindo um limite de API estável, Queryable Encryption no nível do campo e um modelo de DEK por tier de acesso, podem ser aplicados a outros casos de uso:

• Financiamento aberto: acesso a dados com escopo de consenso que restringe um terceiro aos campos autorizados por um cliente , como SSD2 e direito aos dados do consumidor.

• Saúde: informações de saúde protegidas sob o HIPAA.

• Seguros e saúde: plataformas que lidam com identificadores governamentais e dados de contas financeiros de acordo com o GDPR.

Componentes da arquitetura

A arquitetura usa os seguintes componentes:

• Painel do PSP (Frontend): a camada de apresentação. Ele não fala diretamente com o banco de dados . No check-out, ele tokeniza o PAN para que o PAN completo não seja transmitido ou armazenado pelo núcleo do PSP.

• Gateway de API PSP (backend): o ponto de entrada único e o único componente que pode descriptografar campos protegidos. Ele contém o cliente Queryable Encryption , resolve a função do chamador e seleciona o nível de chave correto por solicitação. Todos os chamadores, incluindo a interface do usuário, contas de serviço e integrações, passam pela mesma API e estão sujeitos ao mesmo RBAC e regras principais.

• MongoDB Atlas (M10 ou superior) com Queryable Encryption: armazena apenas texto cifrado (subtipo binário 06) para cada campo protegido. Um administrador de banco de dados com acesso completo ao cluster vê bytes opacos. O TLS 1.3 protege todos os dados em trânsito. O projeto PSP depende da pesquisa de igualdade, que é suportada em produção.

• AWS KMS: contém a chave mestra do cliente que envolve e desembrulhou as chaves de criptografia de dados. A CMK permanece no KMS e o MongoDB não tem acesso a ela. Um provedor de chaves local está disponível como um fallback offline para demos.

Tipos de query e como o projeto os aplica

A Queryable Encryption do MongoDB mantém um campo criptografado no lado do cliente, permitindo que o servidor faça queries no texto cifrado. O projeto PSP usa estes tipos de query:

• Igualdade (produção): o modo pesquisável para as chaves de pesquisa com escopo PCI DSS. O driver criptografa o valor da query e o compara com um índice criptografado, para que o servidor não descriptografe o campo. Esse recurso permite que um analista de fraudes encontre um registro por e-mail, telefone ou referência de conta sem expor o texto simples.

• Sem query (somente recuperação): o modo não pesquisável para os campos de maior sensibilidade, incluindo endereço residencial, identificador do governo e payloads brutos do gateway. Um cliente autorizado descriptografa esses campos apenas just-in-time.

• Intervalo (produção): usado para pesquisas de faixa de valor, como filtragem por uma faixa de quantidade. Ele mantém o valor criptografado.

• Prefixo, sufixo e substring (visualização pública): demonstrado para pesquisas de correspondência parcial no estilo KYC em campos de identidade criptografados.

Para os campos de cartão e PII com escopo PCI DSS abaixo, o design de acesso é reduzido às seguintes categorias:

As opções de design que mantêm os dados do titular do cartão fora do escopo sempre que possível incluem:

• Tokenização do pan: o aplicação substitui o pan completo por um tok_<uuid> token substituto do e retém apenas os últimos quatro dígitos para fins de exibição.

• Captura zero SAD: os endpoints nunca capturam SAD, como CVV ou Pin.

Reduzir o escopo por meio de segmentação e tokenização

Uma prática comum do PCI DSS mantém os dados do titular do cartão fora dos sistemas que não precisam deles, de modo que a maior parte da plataforma fique fora do CDE. Essas técnicas aplicam segmentação, que isola o CDE do restante do sistema, e tokenização, que substitui o número da conta primária por um token substituto mantido em um cofre de tokenização dedicado. A segmentação não é um requisito do PCI DSS, mas tira os sistemas do escopo e reduz o custo de avaliação; quando usado, deve ser documentado, justificado e validado.

O projeto PSP aplica estas técnicas na camada de dados:

• O PAN completo nunca reside no núcleo do PSP: o núcleo armazena apenas o token substituto, o BIN e os últimos quatro dígitos. A maior parte da plataforma não contém dados do titular do cartão e permanece fora do escopo. O PAN completo pertence ao subsistema do emissor do cartão, que é externo na produção. Na demonstração, um módulo emissor embutido substituível fica e armazena o PAN em seu próprio cofre isolado, criptografado com QE:equality. Esse campo pode ser correspondido para pesquisa exata e detecção duplicada sem ser descriptografado.

• A PII é centralizada: os campos de identidade, como e-mail ou telefone, residem em uma única coleção de partes Bian SD-13 que o contrato, o cartão e os registros de transações fazem referência. Um lugar para proteger e processar uma solicitação de apagamento do assunto dos dados.

• Os campos sensíveis ficam atrás de uma camada de chave separada: QE:none os campos usam um tier de chave de criptografia de dados diferente dos campos QE:equality pesquisáveis, portanto, o limite entre dados confidenciais e não confidenciais é imposto pelas chaves.

Este é um padrão de referência, não uma certificação. A definição de CDE e sua validação permanecem de responsabilidade do cliente e do avaliador para confirmar.

Chaves forçadas de controle de acesso, não código de aplicativo

Separe o DEK dos níveis de criptografia:

• Nível de pesquisa: QE:equality as chaves estão disponíveis para todas as funções de analista autenticadas para pesquisa.

• Nível sensível: QE:none as chaves estão disponíveis apenas para um Investigador de nível 2 que possui um token de escalonamento válido de curta duração e para um Auditor de segurança somente para leitura.

• O núcleo do design: o 1 mapa de campos criptografados de um cliente de nível omite as chaves sensíveis, portanto o driver não pode descriptografar esses campos e os retorna como texto cifrado. O controle de acesso em nível de campo aqui é criptográfico em vez de uma projeção no código do aplicação , o que reduz o risco de um vazamento acidental por meio de um bug de query. Quando um analista escala um caso e um Investigador de nível 2 aprova, o Investigador recebe um token de escalonamento que ativa o pool de cliente de nível sensível para essa solicitação.