Armazenamento de Dados Confidenciais: Análise de um Caso Real
Um estudo de caso sobre os desafios e soluções para o armazenamento seguro de dados confidenciais, abordando desde a criptografia até a escolha de HSMs e a conformidade com regulamentações como PCI DSS e GDPR. Explore as complexidades de proteger dados contra roubo e acesso não autorizado, com foco em backups e privilégios de administrador.
MundiX News·13 de abril de 2026·15 min de leitura·👁 2 views
Olá a todos!
Tenho um projeto público chamado Arquitetural Etudes, onde a comunidade resolve problemas de arquitetura reais. Pensei em criar uma série de artigos apresentando a análise dos problemas apresentados, considerando as discussões dos participantes, e mostrando como as soluções podem ser vistas sob uma perspectiva arquitetural abrangente. O primeiro caso que escolhi é "Armazenamento de Dados Confidenciais". Não é complexo e é relevante para muitos, por isso a escolha.
Fonte da Solicitação
A solicitação em si era a seguinte, e foi assim que tudo começou.
Armazenamento de Dados Confidenciais
Introdução
Nos últimos anos, houve vários vazamentos de bancos de dados de grandes serviços russos e não russos, nos quais milhões de registros de usuários foram armazenados em texto não criptografado. Em geral, esta é uma história clássica que se repete dezenas de vezes por ano em todo o mundo. No entanto, o que nos interessa é a razão técnica específica por trás disso – aparentemente, os dados no banco de dados foram armazenados em texto não criptografado. Estaremos interessados em um contexto muito específico – um vazamento por meio de um backup de banco de dados e acesso de administrador (não necessariamente interno).
Em resumo: "proteção contra roubo de backups e acesso de usuários privilegiados". No decorrer da discussão que se seguiu, três questões se mostraram as mais difíceis (embora parecesse...):
Como armazenar dados criptografados em um banco de dados?
Como pesquisar por eles?
Onde manter as chaves?
Planejo guiá-lo pela discussão, pelo chat, por assim dizer, complementando-o em alguns lugares, e tirar algumas conclusões desta história no final. Claro, tive que adicionar algo de mim mesmo, pois as discussões nos chats às vezes são fragmentadas, às vezes algumas suposições estão ocultas nelas, então o artigo acabou sendo mais longo do que a própria discussão (link no final). Não há imagens no artigo, porque não consegui pensar no que poderia ser inserido, e inserir imagens por causa das imagens parece um mau tom :)
Vamos começar.
Análise do Problema
Como parte do esclarecimento da essência do problema, ele foi imediatamente dividido em dois fluxos independentes:
PCI DSS e números de cartão
152-FZ, GDPR e dados pessoais
Por quê? Afinal, ambos precisam ser criptografados e, em geral, a abordagem parece unificada para ambas as tarefas. No decorrer da discussão, chegamos à conclusão de que os requisitos e as consequências de sua não conformidade são muito diferentes.
PCI-DSS é um requisito explícito, um padrão de 12 seções, cuja não conformidade pode levar a multas e, como resultado, o direito de aceitar pagamentos pode ser revogado completamente. E esses padrões rígidos não atendem totalmente aos requisitos do 152-FZ e ao trabalho com dados pessoais em princípio, para os quais, por exemplo, existe um requisito para exclusão completa de dados mediante solicitação. No decorrer da discussão, chegamos à conclusão de que o trabalho com dados pessoais vai muito além da mera criptografia.
Vamos nos concentrar nas questões de criptografia, pois era isso que a solicitação original do autor do caso envolvia.
Texto Oculto
Aqui, outra observação interessante e não óbvia foi feita, que pode ser resumida em uma frase - "o número do seu cartão, em geral, não é um segredo". Mais precisamente, "a maioria dos bancos tem faixas de PAN quase totalmente esgotadas, então, ao apontar para qualquer PAN, você pode ter certeza com alguma probabilidade de que ele exista" :)
O número do cartão tem 16 dígitos. Os primeiros 6-8 dígitos são o BIN (banco e tipo de cartão). O último dígito é um checksum. Assim, restam 7-9 dígitos para iteração, o que dá 10–1000 milhões de opções por BIN.
Isso é para o fato de que, se você fizer hash do PAN e colocar o salt próximo aos dados, um invasor que recebeu um dump pode iterar sobre todos os números existentes em horas em uma GPU comum. E esta é uma das razões pelas quais armazenar hashes de PAN em um banco de dados sem um segredo externo não é adequado. Hashes de cartão simples são inúteis, pois são facilmente iterados. O salt para fazer hash do PAN deve vir de fora (de um HSM de hardware ou software) e nunca ficar próximo aos dados.
Criptografia e HSM de Software
HSM, módulo de segurança de hardware - um dispositivo de computação físico especializado projetado para criar, armazenar e gerenciar com segurança chaves criptográficas e também realizar operações de criptografia.
É importante aqui fornecer as diferenças entre um HSM de hardware e um de software. Em um hardware, a chave não é fisicamente extraível (e fisicamente destruída ao tentar abrir), enquanto em um software, não é extraível organizacionalmente, ou seja, é regulada por meio de direitos de acesso.
Para uma geração de chave segura ao usar um HSM de software, você pode usar o esquema de Adi Shamir (um dos autores do RSA, o S em RSA é ele), que consiste em dividir o segredo (chave) em N partes de forma que pelo menos K de N partes sejam necessárias para restaurá-lo (onde K < N). Quaisquer K-1 partes não fornecem nenhuma informação sobre o segredo.
E aqui podemos observar o primeiro compromisso arquitetônico entre o custo de implementação e a complexidade organizacional. Especificamente: a chave mestra é dividida em 5 partes. Essas cinco partes são distribuídas para cinco pessoas responsáveis. Para iniciar o serviço, são necessários 3 de 5. Nenhuma pessoa sozinha pode comprometer a chave. Na verdade, transferimos parte do problema técnico para o organizacional e, se a solução organizacional agradar a todos, economizamos seriamente na solução técnica.
Como Pesquisar Algo que Está Criptografado?
Às vezes, esta é uma tarefa ainda mais difícil do que criptografar. Uma transação de cartão chegou... o sistema deve encontrar uma entrada no banco de dados pelo número do cartão. Mas o número está criptografado.
Três opções foram propostas:
TDE (Transparent Data Encryption)
O banco de dados criptografa arquivos no disco, mas funciona com dados em texto não criptografado. Índice por PAN como está. Citando uma das mensagens: "Isso é geralmente sobre teatro de segurança, mas sim, os fornecedores fazem isso". TDE, é claro, protege contra roubo de disco, mas não de um DBA com um cliente SQL :)
Hash com Salt
Calculamos o hash do PAN com um salt secreto, colocamos em uma coluna separada, construímos um índice no hash. Ao pesquisar, calculamos o hash do PAN de entrada e pesquisamos no índice. Já foi dito acima por que armazenar o salt lá não é uma opção, e como tal: "Funciona apenas se o salt não for armazenado no banco de dados, mas for obtido de um (soft)HSM na inicialização" (caso contrário, a iteração se torna trivial).
Criptografia Determinística (sem vetor de inicialização)
Criptografamos o PAN sem um vetor de inicialização aleatório, os mesmos PANs fornecem o mesmo texto cifrado. Você pode construir um índice. Veredicto: "É como o método 2, só que pior", pois em caso de vazamento de texto cifrado + chave, a descriptografia é instantânea, enquanto o hash é pelo menos irreversível.
A arquitetura de destino formada na discussão: o banco de dados armazena o PAN criptografado, o hash do PAN e o identificador da chave usada (necessário para suportar a rotação de chaves). O índice é construído no hash.
Todos os serviços internos operam apenas com o hash (não o PAN).
Na última edição do PCI-DSS, o hash não pode deixar os limites do contorno do PAN, mas você pode usar um token (valor aleatório) vinculado ao PAN em um armazenamento de token separado.
Onde Armazenar as Chaves?
No Vault! HashiCorp Vault, Azure Key Vault, AWS Secrets Manager. Isso é o que estava na superfície e soou literalmente imediatamente. E como geralmente acontece, houve discordâncias, e com razão: "Esta abordagem dá uma ilusão de segurança. Todos os armazenamentos de chaves são vulneráveis a um administrador de sistema, o que destrói a ideia de segurança na raiz".
A modelagem de ameaças entra na sala. Do que o Vault protege?
De um desenvolvedor que acidentalmente commitou um segredo no git
De vazamentos de variáveis de ambiente
De leitura não autorizada de segredos
E não protege de:
Administrador do Vault (ele tem acesso total a todos os segredos)
Administrador do servidor onde o Vault está sendo executado (memory dump)
Titular do certificado usado para mTLS entre o serviço e o Vault
Na discussão posterior, eles tocaram em mTLS entre o Vault e o serviço e que você pode pegar chaves de hardware para mTLS, limitar o número de solicitações de chave, introduzir uma auditoria de cada solicitação, mas tudo isso é complexo, caro e raramente encontrado.
Neste ponto, houve outro insight, se posso dizer assim. O Vault não pode ser inútil, bem, funciona, é usado, é apenas que o Vault é uma ferramenta de gerenciamento de segredos, não uma ferramenta de segurança de chaves criptográficas. É ótimo para o primeiro, mas para o segundo você precisa de um HSM.
Texto Oculto
Aqui você pode fazer uma pequena nota de um participante que usa o Azure Key Vault - "No Azure, posso criar um vault com uma chave não exportada que armazenará meus dados em um HSM. E há uma API para operações criptográficas". O Azure Key Vault Premium é na verdade uma interface para um HSM de hardware hospedado nos data centers da Microsoft. Ou seja, os administradores não podem acessar a chave.
Kubernetes
A discussão mencionou a ideia de usar Kubernetes Secrets e vault-integration no k8s e foi analisada literalmente até os ossos :)
Kubernetes Secrets são objetos que armazenam dados confidenciais transmitidos para pods por meio de volumes montados ou variáveis de ambiente. Por padrão, os Secrets são armazenados em etcd em base64 (não criptografados). Qualquer pessoa que tenha acesso ao servidor de API Kubernetes com direitos de leitura de Secrets pode obter todos os segredos do cluster.
O problema dos contêineres é um pouco mais profundo. Um contêiner Docker é um processo com isolamento no nível do namespace e cgroups. O usuário root no host pode:
Ler o sistema de arquivos do contêiner
Conectar-se ao processo do contêiner via nsenter
Fazer um dump da memória do processo
Interceptar o tráfego de rede do contêiner
Para serviços comuns, este é um nível aceitável de isolamento. Para um serviço criptográfico que armazena chaves na memória, não é mais adequado.
Texto Oculto
Para ser justo, existem soluções para fortalecer o isolamento: gVisor (do Google, virtualização de syscalls), Kata Containers (contêineres dentro de VMs leves), Confidential Computing (criptografia de memória de processo por hardware via Intel SGX / AMD SEV). Mas eles não foram discutidos no contexto deste caso.
E Quanto às Nuvens?
Muitas nuvens escrevem que são certificadas PCI DSS. Mas há uma nuance. O provedor certifica sua infraestrutura: data center, isolamento de rede, criptografia de disco. No entanto, a responsabilidade pela criptografia de dados, gerenciamento de chaves e controle de acesso ainda recai sobre o cliente.
O modelo de responsabilidade compartilhada é a base da segurança na nuvem. Na prática, isso significa que uma nuvem certificada PCI DSS é uma nuvem na qual você pode construir uma solução compatível com PCI DSS, não uma nuvem que é compatível com PCI DSS para seus dados.
Uma das citações da discussão: "O serviço de trabalho com PAN deve ser conectado ao HSM por um cabo de rede fisicamente separado. Isso pode ser feito em um data center, mas não na nuvem. E sem isso, o problema de proteção contra o administrador não é resolvido normalmente". Na nuvem, todo o tráfego passa por uma rede virtual "comum", que, teoricamente, pode ser interceptada pelo administrador da infraestrutura do provedor.
Vale ressaltar que são possíveis opções com o uso de um HSM isolado na nuvem, mas aqui a disponibilidade de tal serviço e o grau de confiança no provedor entram em jogo.
Resultado Prático
Perto do final da discussão, surgiu uma arquitetura que pode ser considerada consensual (lembramos que arquitetura são decisões tomadas):
Um crypto-serviço dedicado, isolado do restante da infraestrutura, não em contêineres, com um mínimo de interfaces de rede
Chave não extraível em um HSM de hardware (ideal), em um HSM de software (compromisso) ou em um Vault na nuvem com um backend HSM (compromisso na nuvem)
Geração de chave usando o esquema Shamir, se não houver HSM de hardware
Crypto-hash para pesquisa com um salt do HSM, armazenado separadamente dos dados
Separação de PAN e dados pessoais devido a diferentes requisitos regulatórios
Auditoria de todas as solicitações para o crypto-serviço
Suporte para várias chaves para rotação e recriptografia
Pós-escrito
Sim, discutimos e resolvemos o problema no momento, mas constantemente, tacitamente, atingimos um nível mais alto de abstração, um nível de estratégia.
Nesse nível, a tarefa técnica típica "como criptografar um PAN" é transformada em "qual é a posição da empresa em relação aos riscos, requisitos regulatórios e dinheiro". Observe que ao longo de toda a discussão acima, passamos por essa estrutura, as decisões e a própria formulação do problema original mudaram por meio desses conceitos mais amplos.
Portanto, a escolha estratégica do ponto de vista da arquitetura:
Duas soluções arquitetônicas diferentes para dados pessoais e para PAN
A proteção não é necessária apenas contra um invasor externo, mas também contra administradores privilegiados (ameaças internas se conectam)
Com base no modelo de ameaças e no orçamento, existem opções desde "crypto-serviço barato + HSM de software" até "HSM de hardware + infraestrutura dedicada"
E para determinar no final para onde ir e o que é viável, precisaremos envolver muitas pessoas com diferentes competências, no mínimo:
Arquiteto, formando o modelo de destino e o equilíbrio de compromissos
Especialista em segurança, definindo o nível da barra por meio de um modelo de ameaças
Engenheiros DevOps/Cloud, determinando o que pode ser feito na infraestrutura atual
Advogados e compliance, determinando o mínimo obrigatório com base nos requisitos regulatórios
E é esse ambiente, composto por especialistas de diferentes perfis, que estou tentando formar, para que possamos ajudar uns aos outros, aprender uns com os outros, nos desenvolver, resolvendo problemas aplicados complexos e expandindo o círculo de conhecimentos úteis e interessantes.
Se você tiver dificuldades com soluções arquitetônicas, escreva, publicaremos e buscaremos uma solução juntos, você pode postar anonimamente, você pode especificar o autor - não é fundamental.
Obrigado pela sua atenção!
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Olá a todos!
Tenho um projeto público chamado Arquitetural Etudes, onde a comunidade resolve problemas de arquitetura reais. Pensei em criar uma série de artigos apresentando a análise dos problemas apresentados, considerando as discussões dos participantes, e mostrando como as soluções podem ser vistas sob uma perspectiva arquitetural abrangente. O primeiro caso que escolhi é "Armazenamento de Dados Confidenciais". Não é complexo e é relevante para muitos, por isso a escolha.
Fonte da Solicitação
A solicitação em si era a seguinte, e foi assim que tudo começou.
Armazenamento de Dados Confidenciais
Introdução
Nos últimos anos, houve vários vazamentos de bancos de dados de grandes serviços russos e não russos, nos quais milhões de registros de usuários foram armazenados em texto não criptografado. Em geral, esta é uma história clássica que se repete dezenas de vezes por ano em todo o mundo. No entanto, o que nos interessa é a razão técnica específica por trás disso – aparentemente, os dados no banco de dados foram armazenados em texto não criptografado. Estaremos interessados em um contexto muito específico – um vazamento por meio de um backup de banco de dados e acesso de administrador (não necessariamente interno).
Em resumo: "proteção contra roubo de backups e acesso de usuários privilegiados". No decorrer da discussão que se seguiu, três questões se mostraram as mais difíceis (embora parecesse...):
Como armazenar dados criptografados em um banco de dados?
Como pesquisar por eles?
Onde manter as chaves?
Planejo guiá-lo pela discussão, pelo chat, por assim dizer, complementando-o em alguns lugares, e tirar algumas conclusões desta história no final. Claro, tive que adicionar algo de mim mesmo, pois as discussões nos chats às vezes são fragmentadas, às vezes algumas suposições estão ocultas nelas, então o artigo acabou sendo mais longo do que a própria discussão (link no final). Não há imagens no artigo, porque não consegui pensar no que poderia ser inserido, e inserir imagens por causa das imagens parece um mau tom :)
Vamos começar.
Análise do Problema
Como parte do esclarecimento da essência do problema, ele foi imediatamente dividido em dois fluxos independentes:
PCI DSS e números de cartão
152-FZ, GDPR e dados pessoais
Por quê? Afinal, ambos precisam ser criptografados e, em geral, a abordagem parece unificada para ambas as tarefas. No decorrer da discussão, chegamos à conclusão de que os requisitos e as consequências de sua não conformidade são muito diferentes.
PCI-DSS é um requisito explícito, um padrão de 12 seções, cuja não conformidade pode levar a multas e, como resultado, o direito de aceitar pagamentos pode ser revogado completamente. E esses padrões rígidos não atendem totalmente aos requisitos do 152-FZ e ao trabalho com dados pessoais em princípio, para os quais, por exemplo, existe um requisito para exclusão completa de dados mediante solicitação. No decorrer da discussão, chegamos à conclusão de que o trabalho com dados pessoais vai muito além da mera criptografia.
Vamos nos concentrar nas questões de criptografia, pois era isso que a solicitação original do autor do caso envolvia.
Texto Oculto
Aqui, outra observação interessante e não óbvia foi feita, que pode ser resumida em uma frase - "o número do seu cartão, em geral, não é um segredo". Mais precisamente, "a maioria dos bancos tem faixas de PAN quase totalmente esgotadas, então, ao apontar para qualquer PAN, você pode ter certeza com alguma probabilidade de que ele exista" :)
O número do cartão tem 16 dígitos. Os primeiros 6-8 dígitos são o BIN (banco e tipo de cartão). O último dígito é um checksum. Assim, restam 7-9 dígitos para iteração, o que dá 10–1000 milhões de opções por BIN.
Isso é para o fato de que, se você fizer hash do PAN e colocar o salt próximo aos dados, um invasor que recebeu um dump pode iterar sobre todos os números existentes em horas em uma GPU comum. E esta é uma das razões pelas quais armazenar hashes de PAN em um banco de dados sem um segredo externo não é adequado. Hashes de cartão simples são inúteis, pois são facilmente iterados. O salt para fazer hash do PAN deve vir de fora (de um HSM de hardware ou software) e nunca ficar próximo aos dados.
Criptografia e HSM de Software
HSM, módulo de segurança de hardware - um dispositivo de computação físico especializado projetado para criar, armazenar e gerenciar com segurança chaves criptográficas e também realizar operações de criptografia.
É importante aqui fornecer as diferenças entre um HSM de hardware e um de software. Em um hardware, a chave não é fisicamente extraível (e fisicamente destruída ao tentar abrir), enquanto em um software, não é extraível organizacionalmente, ou seja, é regulada por meio de direitos de acesso.
Para uma geração de chave segura ao usar um HSM de software, você pode usar o esquema de Adi Shamir (um dos autores do RSA, o S em RSA é ele), que consiste em dividir o segredo (chave) em N partes de forma que pelo menos K de N partes sejam necessárias para restaurá-lo (onde K < N). Quaisquer K-1 partes não fornecem nenhuma informação sobre o segredo.
E aqui podemos observar o primeiro compromisso arquitetônico entre o custo de implementação e a complexidade organizacional. Especificamente: a chave mestra é dividida em 5 partes. Essas cinco partes são distribuídas para cinco pessoas responsáveis. Para iniciar o serviço, são necessários 3 de 5. Nenhuma pessoa sozinha pode comprometer a chave. Na verdade, transferimos parte do problema técnico para o organizacional e, se a solução organizacional agradar a todos, economizamos seriamente na solução técnica.
Como Pesquisar Algo que Está Criptografado?
Às vezes, esta é uma tarefa ainda mais difícil do que criptografar. Uma transação de cartão chegou... o sistema deve encontrar uma entrada no banco de dados pelo número do cartão. Mas o número está criptografado.
Três opções foram propostas:
TDE (Transparent Data Encryption)
O banco de dados criptografa arquivos no disco, mas funciona com dados em texto não criptografado. Índice por PAN como está. Citando uma das mensagens: "Isso é geralmente sobre teatro de segurança, mas sim, os fornecedores fazem isso". TDE, é claro, protege contra roubo de disco, mas não de um DBA com um cliente SQL :)
Hash com Salt
Calculamos o hash do PAN com um salt secreto, colocamos em uma coluna separada, construímos um índice no hash. Ao pesquisar, calculamos o hash do PAN de entrada e pesquisamos no índice. Já foi dito acima por que armazenar o salt lá não é uma opção, e como tal: "Funciona apenas se o salt não for armazenado no banco de dados, mas for obtido de um (soft)HSM na inicialização" (caso contrário, a iteração se torna trivial).
Criptografia Determinística (sem vetor de inicialização)
Criptografamos o PAN sem um vetor de inicialização aleatório, os mesmos PANs fornecem o mesmo texto cifrado. Você pode construir um índice. Veredicto: "É como o método 2, só que pior", pois em caso de vazamento de texto cifrado + chave, a descriptografia é instantânea, enquanto o hash é pelo menos irreversível.
A arquitetura de destino formada na discussão: o banco de dados armazena o PAN criptografado, o hash do PAN e o identificador da chave usada (necessário para suportar a rotação de chaves). O índice é construído no hash.
Todos os serviços internos operam apenas com o hash (não o PAN).
Na última edição do PCI-DSS, o hash não pode deixar os limites do contorno do PAN, mas você pode usar um token (valor aleatório) vinculado ao PAN em um armazenamento de token separado.
Onde Armazenar as Chaves?
No Vault! HashiCorp Vault, Azure Key Vault, AWS Secrets Manager. Isso é o que estava na superfície e soou literalmente imediatamente. E como geralmente acontece, houve discordâncias, e com razão: "Esta abordagem dá uma ilusão de segurança. Todos os armazenamentos de chaves são vulneráveis a um administrador de sistema, o que destrói a ideia de segurança na raiz".
A modelagem de ameaças entra na sala. Do que o Vault protege?
De um desenvolvedor que acidentalmente commitou um segredo no git
De vazamentos de variáveis de ambiente
De leitura não autorizada de segredos
E não protege de:
Administrador do Vault (ele tem acesso total a todos os segredos)
Administrador do servidor onde o Vault está sendo executado (memory dump)
Titular do certificado usado para mTLS entre o serviço e o Vault
Na discussão posterior, eles tocaram em mTLS entre o Vault e o serviço e que você pode pegar chaves de hardware para mTLS, limitar o número de solicitações de chave, introduzir uma auditoria de cada solicitação, mas tudo isso é complexo, caro e raramente encontrado.
Neste ponto, houve outro insight, se posso dizer assim. O Vault não pode ser inútil, bem, funciona, é usado, é apenas que o Vault é uma ferramenta de gerenciamento de segredos, não uma ferramenta de segurança de chaves criptográficas. É ótimo para o primeiro, mas para o segundo você precisa de um HSM.
Texto Oculto
Aqui você pode fazer uma pequena nota de um participante que usa o Azure Key Vault - "No Azure, posso criar um vault com uma chave não exportada que armazenará meus dados em um HSM. E há uma API para operações criptográficas". O Azure Key Vault Premium é na verdade uma interface para um HSM de hardware hospedado nos data centers da Microsoft. Ou seja, os administradores não podem acessar a chave.
Kubernetes
A discussão mencionou a ideia de usar Kubernetes Secrets e vault-integration no k8s e foi analisada literalmente até os ossos :)
Kubernetes Secrets são objetos que armazenam dados confidenciais transmitidos para pods por meio de volumes montados ou variáveis de ambiente. Por padrão, os Secrets são armazenados em etcd em base64 (não criptografados). Qualquer pessoa que tenha acesso ao servidor de API Kubernetes com direitos de leitura de Secrets pode obter todos os segredos do cluster.
O problema dos contêineres é um pouco mais profundo. Um contêiner Docker é um processo com isolamento no nível do namespace e cgroups. O usuário root no host pode:
Ler o sistema de arquivos do contêiner
Conectar-se ao processo do contêiner via nsenter
Fazer um dump da memória do processo
Interceptar o tráfego de rede do contêiner
Para serviços comuns, este é um nível aceitável de isolamento. Para um serviço criptográfico que armazena chaves na memória, não é mais adequado.
Texto Oculto
Para ser justo, existem soluções para fortalecer o isolamento: gVisor (do Google, virtualização de syscalls), Kata Containers (contêineres dentro de VMs leves), Confidential Computing (criptografia de memória de processo por hardware via Intel SGX / AMD SEV). Mas eles não foram discutidos no contexto deste caso.
E Quanto às Nuvens?
Muitas nuvens escrevem que são certificadas PCI DSS. Mas há uma nuance. O provedor certifica sua infraestrutura: data center, isolamento de rede, criptografia de disco. No entanto, a responsabilidade pela criptografia de dados, gerenciamento de chaves e controle de acesso ainda recai sobre o cliente.
O modelo de responsabilidade compartilhada é a base da segurança na nuvem. Na prática, isso significa que uma nuvem certificada PCI DSS é uma nuvem na qual você pode construir uma solução compatível com PCI DSS, não uma nuvem que é compatível com PCI DSS para seus dados.
Uma das citações da discussão: "O serviço de trabalho com PAN deve ser conectado ao HSM por um cabo de rede fisicamente separado. Isso pode ser feito em um data center, mas não na nuvem. E sem isso, o problema de proteção contra o administrador não é resolvido normalmente". Na nuvem, todo o tráfego passa por uma rede virtual "comum", que, teoricamente, pode ser interceptada pelo administrador da infraestrutura do provedor.
Vale ressaltar que são possíveis opções com o uso de um HSM isolado na nuvem, mas aqui a disponibilidade de tal serviço e o grau de confiança no provedor entram em jogo.
Resultado Prático
Perto do final da discussão, surgiu uma arquitetura que pode ser considerada consensual (lembramos que arquitetura são decisões tomadas):
Um crypto-serviço dedicado, isolado do restante da infraestrutura, não em contêineres, com um mínimo de interfaces de rede
Chave não extraível em um HSM de hardware (ideal), em um HSM de software (compromisso) ou em um Vault na nuvem com um backend HSM (compromisso na nuvem)
Geração de chave usando o esquema Shamir, se não houver HSM de hardware
Crypto-hash para pesquisa com um salt do HSM, armazenado separadamente dos dados
Separação de PAN e dados pessoais devido a diferentes requisitos regulatórios
Auditoria de todas as solicitações para o crypto-serviço
Suporte para várias chaves para rotação e recriptografia
Pós-escrito
Sim, discutimos e resolvemos o problema no momento, mas constantemente, tacitamente, atingimos um nível mais alto de abstração, um nível de estratégia.
Nesse nível, a tarefa técnica típica "como criptografar um PAN" é transformada em "qual é a posição da empresa em relação aos riscos, requisitos regulatórios e dinheiro". Observe que ao longo de toda a discussão acima, passamos por essa estrutura, as decisões e a própria formulação do problema original mudaram por meio desses conceitos mais amplos.
Portanto, a escolha estratégica do ponto de vista da arquitetura:
Duas soluções arquitetônicas diferentes para dados pessoais e para PAN
A proteção não é necessária apenas contra um invasor externo, mas também contra administradores privilegiados (ameaças internas se conectam)
Com base no modelo de ameaças e no orçamento, existem opções desde "crypto-serviço barato + HSM de software" até "HSM de hardware + infraestrutura dedicada"
E para determinar no final para onde ir e o que é viável, precisaremos envolver muitas pessoas com diferentes competências, no mínimo:
Arquiteto, formando o modelo de destino e o equilíbrio de compromissos
Especialista em segurança, definindo o nível da barra por meio de um modelo de ameaças
Engenheiros DevOps/Cloud, determinando o que pode ser feito na infraestrutura atual
Advogados e compliance, determinando o mínimo obrigatório com base nos requisitos regulatórios
E é esse ambiente, composto por especialistas de diferentes perfis, que estou tentando formar, para que possamos ajudar uns aos outros, aprender uns com os outros, nos desenvolver, resolvendo problemas aplicados complexos e expandindo o círculo de conhecimentos úteis e interessantes.
Se você tiver dificuldades com soluções arquitetônicas, escreva, publicaremos e buscaremos uma solução juntos, você pode postar anonimamente, você pode especificar o autor - não é fundamental.
Obrigado pela sua atenção!
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
