Auditing a PII exposure across a Java microservice stack Auditando uma exposição de PII em um stack Java de microsserviços

Começou com uma única observação: um campo de senha armazenado como VARCHAR(20) em plaintext no banco de dados. É uma prática conhecidamente ruim. O que tornou interessante foi rastrear cada lugar onde essa senha era lida, escrita, transmitida, logada e comparada — e descobrir que o problema não era uma coisa, eram nove coisas empilhadas.

A auditoria

O campo em questão é a senha de um portal do cliente. O plaintext no banco é o sintoma mais visível, mas a auditoria seguiu o dado pelo codebase para entender a superfície de exposição completa.

1. Armazenamento plaintext. O campo é VARCHAR(20) — sem hash, sem criptografia. Qualquer dump do banco expõe diretamente a senha de cada cliente.

2. Valor padrão previsível. Na criação da conta, a senha padrão é os últimos seis dígitos do CPF/CNPJ do cliente. A lógica de derivação é uma linha no ClienteService. O CPF é semi-público. Um atacante que conhece o CPF de um cliente pode adivinhar a senha do portal sem acessar o banco.

3. Transmissão em plaintext. Quando o serviço de autenticação precisa verificar a senha, ele a envia no corpo da requisição HTTP para um serviço de integração OAuth. A senha trafega pela rede interna em plaintext em cada tentativa de autenticação.

4. Logada como evento. Existe um sistema de eventos que registra ações do usuário. Mudanças de senha eram logadas como inserirEvento(customerId, "ATUALIZAR_SENHA", password) — o valor real da senha passado como descrição do evento e gravado na tabela de eventos.

5. Comparação não constant-time. A autenticação usava cliente.getSenhaSac().equals(dto.getOldPassword()) — comparação de string padrão. Comparação de string em Java faz short-circuit no primeiro caractere diferente, tornando-a vulnerável a timing attacks que podem sondar caractere por caractere.

6. Autenticação SQL. Um caminho de autenticação rodava WHERE senha_sac = ? diretamente em uma query SQL — comparando a senha plaintext na camada de banco em vez de no código da aplicação.

7. Exposta via REST. Os modelos Cliente e Lead não tinham @JsonIgnore no campo de senha. Qualquer endpoint que retornava um objeto cliente completo — detalhes de contrato, listagem de leads — estava retornando a senha na resposta JSON.

8. Exposta via integração externa. Um serviço de integração usado por um parceiro externo tinha o campo de senha em seu ClienteDTO. O mecanismo de auth da integração era HTTP Basic com um token estático codificado em Base64 — um não-segredo. Qualquer requisição a qualquer endpoint desse serviço retornava registros de cliente incluindo o campo de senha.

9. Vazamento cross-service. Sete microsserviços consumiam a API comercial e recebiam objetos cliente. A maioria não usava o campo de senha, mas o desserializava das respostas da API e o mantinha em memória. Serviços espelho — que nunca liam o campo — ainda o recebiam em cada chamada.

Por que BCrypt não é a resposta aqui

A recomendação padrão para armazenamento de senha é um hash unidirecional: BCrypt, Argon2 ou similar. Unidirecional significa que você verifica uma senha fazendo hash do input e comparando hashes, mas nunca recupera o original.

Esse é o design certo quando seu sistema é o único verificador. Não funciona aqui.

Vários serviços downstream — uma integração OAuth, um conector de plataforma terceiro, um sistema legado de provisionamento — precisam da senha real para autenticar com seus sistemas upstream. Eles recebem a senha do cliente e a passam para uma API externa. Um hash unidirecional quebraria todas essas integrações: você não pode desfazer o hash de um valor para enviá-lo a um sistema downstream.

Essa é uma restrição comum em plataformas legadas de ISP. A senha começou como credencial de provisionamento — necessária em plaintext para configurar hardware ou autenticar com sistemas de operadoras — e foi reutilizada como credencial do portal sem redesenhar o modelo de armazenamento.

A solução correta de longo prazo é migrar a autenticação inteiramente para OAuth/Keycloak (que já existe no stack) e deixar os sistemas externos migrarem para auth baseada em token ao longo do tempo. É um projeto de múltiplos trimestres. Não corrige a exposição imediata.

A solução prática de curto prazo é AES-256-GCM: criptografia reversível que protege o banco e os logs, enquanto ainda permite que a aplicação descriptografe e passe a credencial para sistemas downstream que precisam dela.

A implementação

PasswordEncryptionService — um Spring service que envolve javax.crypto, a API de criptografia padrão do Java disponível desde o Java 8. Sem dependências externas. Chave carregada de variável de ambiente.

@Service
public class PasswordEncryptionService {

    private final SecretKey key;

    public PasswordEncryptionService(@Value("${air.senha-sac.encryption-key}") String base64Key) {
        byte[] decoded = Base64.getDecoder().decode(base64Key);
        this.key = new SecretKeySpec(decoded, "AES");
    }

    public String encrypt(String plaintext) {
        byte[] iv = new byte[12];
        new SecureRandom().nextBytes(iv);
        // AES-256-GCM
        // retorna "v1:" + Base64(iv + ciphertext + tag)
    }

    public String decrypt(String ciphertext) {
        if (!ciphertext.startsWith("v1:")) {
            return ciphertext; // fallback para plaintext na janela de migração
        }
        // decodifica, extrai iv, descriptografa
    }
}

O prefixo v1: serve a dois propósitos: identifica valores criptografados durante a janela de migração (nem todos os registros são criptografados imediatamente — a migração roda como job em background), e fornece um handle de versão para rotação futura de chave. Quando a chave precisar mudar, registros criptografados com a chave antiga começam com v1:, registros com a nova chave começam com v2:. A aplicação consegue descriptografar qualquer um lendo o prefixo.

Pontos de escrita — qualquer lugar onde a senha é definida recebe encrypt():

• Criação de conta: setSenhaSac(encrypt(derived))
• Atualização de senha: updateCustomerPassword(encrypt(newPassword))
• Serviço de migração: setSenhaSac(encrypt(legacyValue))

Pontos de leitura — qualquer lugar onde a senha é consumida recebe decrypt():

• Integração OAuth: decrypt(cliente.getSenhaSac()) antes de enviar
• Conector de plataforma externa: decrypt(...) antes de enviar
• Comparação de autenticação: decrypt(...).equals(input)

Serviços espelho — serviços que recebem objetos cliente mas nunca leem o campo de senha recebem @JsonIgnore no campo no modelo. Param de receber e desserializar o campo completamente.

Redação no log — a chamada ao logger de eventos vira inserirEvento(customerId, "ATUALIZAR_SENHA", "****").

Migration de schema — VARCHAR(20) para VARCHAR(100) para acomodar o ciphertext codificado em Base64. ALGORITHM=INPLACE para evitar lock da tabela durante a migração em banco de dados live.

O job de migração

554.000 registros existentes precisam ser criptografados. Rodar um único UPDATE em toda a tabela não é seguro em um sistema live — bloqueia linhas, pica I/O e trava leituras por minutos.

O job de migração roda em lotes de 500. Lê registros não criptografados (aqueles sem o prefixo v1:), criptografa em memória e escreve de volta. O tamanho do lote é pequeno o suficiente para manter a contenção de lock baixa. O job é retomável — se for interrompido, continua de onde parou porque seleciona registros pela ausência do prefixo.

Três endpoints gerenciam o job:

POST /admin/migration/senha-sac/run    — criptografa próximo lote
GET  /admin/migration/senha-sac/status — relatório de progresso
POST /admin/migration/senha-sac/commit — troca colunas quando concluído

O endpoint commit troca a coluna criptografada para a coluna principal e descarta a coluna de staging. Isso torna o cutover atômico do ponto de vista da aplicação.

A restrição do Java 8

O serviço roda Java 8 e Spring Boot 1.5 — ambos end-of-life. AES-256-GCM está disponível em javax.crypto desde o Java 6, então funciona. O que não funciona é criptografia pós-quântica.

ML-KEM (CRYSTALS-Kyber, FIPS 203) e ML-DSA (CRYSTALS-Dilithium, FIPS 204) requerem Bouncy Castle 1.78+, que requer Java 11+. A migração para Java 17 e Spring Boot 3.x está planejada — documentada em uma avaliação arquitetural que mapeia 301 arquivos, identifica os blockers críticos (migração de namespace de javax.* para jakarta.*, mudanças na API do Spring Security, remoção do Springfox), e delineia um rollout de quatro fases ao longo de dois a quatro meses.

O fix atual é o fix correto para a restrição atual. Proteção pós-quântica — envolver a chave AES com ML-KEM — fica disponível após a migração de Java. O prefixo de versão v1: no ciphertext significa que a transição para v2: (chave com ML-KEM) pode acontecer sem descriptografar e recriptografar os dados: apenas o gerenciamento de chave muda.

A ordem importa

Um instinto quando você encontra uma exposição como essa é fazer deploy de @JsonIgnore imediatamente — estancar o sangramento, fechar o endpoint. Isso é errado aqui.

@JsonIgnore no campo de senha quebra a integração OAuth, o conector de provisionamento e qualquer outro serviço que lia o campo da resposta da API. Esses serviços quebram silenciosamente: passam a receber null em vez de uma senha, e as integrações falham.

A ordem correta é:

1. Adicionar criptografia nos pontos de escrita (novos registros são criptografados imediatamente)
2. Adicionar descriptografia nos pontos de leitura (registros plaintext existentes ainda funcionam via fallback)
3. Rodar job de migração (registros existentes são criptografados)
4. Validar todas as integrações com dados criptografados em staging
5. Aplicar @JsonIgnore por último — só depois que todos os consumidores foram atualizados para usar decrypt()

Fechar a exposição antes de corrigir os consumidores quebra o sistema. Corrigir os consumidores antes de fechar a exposição deixa uma janela, mas uma janela conhecida e delimitada.

O que esse padrão de auditoria produz

Começar de uma observação e seguir o dado — onde é escrito, lido, transmitido, logado, comparado — consistentemente revela mais do que você espera. Os nove vetores aqui não foram nove decisões de design separadas. Foram uma decisão (armazenar uma credencial de provisionamento como senha de usuário) tomada uma vez, e então seis anos de features construídas em cima dela sem revisitar o pressuposto.

O valor do rastreamento sistemático não é encontrar vulnerabilidades exóticas. É encontrar as mundanas que se acumulam invisivelmente — o log statement que alguém adicionou há três anos, o @JsonIgnore que nunca foi adicionado, o equals() que nunca foi tornado timing-safe. Cada um é um pequeno descuido. Juntos são uma exposição significativa.