As credenciais e o mascaramento

Senhas, chaves e certificados passam pelo suporte o tempo todo: na configuração do sistema, na conexão com o banco, nas integrações e nos logs. Uma credencial que aparece em um chamado, em uma captura de tela ou em um grupo de mensagens dá o mesmo acesso a qualquer pessoa que a encontre, e o mascaramento esconde esses valores sem impedir o diagnóstico.

As credenciais da loja

Credencial é qualquer informação que comprova a identidade de uma pessoa ou de um sistema. Na loja, as mais comuns são:

• Senhas de usuários: as contas do Windows, do sistema da loja e do e-mail;
• Usuários do banco: o root do MySQL e os usuários criados para o sistema e para as integrações;
• Chaves e tokens: os valores que identificam a loja nos serviços das integrações;
• Certificado digital: o arquivo do certificado A1 e a senha dele, que permitem assinar documentos fiscais em nome da empresa;
• CSC: o código de segurança do contribuinte, usado no QR Code da NFC-e;
• Senhas de equipamentos: o roteador, as impressoras de rede e as câmeras.

Onde as credenciais vazam

Muitas credenciais vazam em lugares comuns, sem nenhum ataque:

• arquivos de configuração e de conexão copiados inteiros para um chamado;
• logs que gravam a string de conexão com a senha ou o cabeçalho de autorização das requisições;
• capturas de tela feitas com a tela de configuração aberta;
• comandos com a senha escrita, que ficam no histórico do prompt de comando e do PowerShell;
• senhas gravadas em texto puro em arquivos de configuração sem permissão restrita, como a seção [client] de um arquivo de opções do MySQL;
• senhas anotadas em planilhas, em papéis colados no monitor e em conversas;
• senhas de fábrica dos equipamentos, que nunca foram trocadas.

O mascaramento

Mascarar é trocar parte de um valor, ou o valor inteiro, por caracteres que não revelam o conteúdo, como asteriscos, antes de mostrar, copiar ou registrar a informação. Cada tipo de dado pede uma forma:

• Senhas: o valor inteiro trocado por um número fixo de asteriscos, como em ********, que também esconde o tamanho;
• Chaves e tokens: só os últimos caracteres visíveis, o bastante para saber qual chave está em uso, como em ****9f3a;
• CPF: só a parte do meio visível, como em ***.456.789-**;
• Telefone: só os últimos dígitos visíveis, como em (11) *****-4321;
• Cartão: no máximo os últimos dígitos, como nos comprovantes de pagamento.

Um bom mascaramento preserva o que ajuda no diagnóstico. Uma senha vazia, uma senha com espaço no fim e uma senha errada são falhas diferentes, e a anotação de que o campo estava vazio ou preenchido ajuda mais que o próprio valor. Os últimos caracteres de uma chave também mostram se a integração usa a chave nova ou a antiga.

O mascaramento protege a exibição e não transforma o dado: o CPF mascarado na tela continua inteiro no banco. Uma base de testes precisa de dados substituídos de fato, e não só escondidos na tela.

As senhas e o segundo fator

Nas recomendações atuais, o tamanho da senha pesa mais que a mistura de símbolos. A orientação do NIST, o instituto de padrões dos Estados Unidos, pede pelo menos 15 caracteres para uma senha usada sozinha e 8 para uma senha usada com um segundo fator. Ela orienta a não exigir regras de composição, como a mistura obrigatória de tipos de caracteres, nem a troca periódica, a exigir a troca quando há indício de que a senha foi comprometida e a comparar cada senha nova com listas de senhas comuns e vazadas. Uma frase longa, sem relação com dados pessoais e diferente em cada conta, atende a essas regras.

A verificação em duas etapas pede algo além da senha, como um código gerado por um aplicativo no celular ou uma chave física, e barra quem descobriu só a senha. As ferramentas de acesso remoto, os serviços de e-mail e os painéis das integrações costumam oferecer essa opção. Na equipe de suporte, um gerenciador de senhas guarda as credenciais compartilhadas, com controle de quem acessa cada uma, no lugar de planilhas e mensagens.

Usuários com o mínimo de permissões limitam o estrago de um vazamento. Cada integração com um usuário próprio do banco, com acesso só às tabelas e às operações de que precisa, faz com que a senha vazada de uma integração que só lê preços não consiga alterar vendas, e o root fica reservado à administração do banco.

Quando uma credencial vaza

Uma credencial exposta é trocada, e não só apagada do lugar onde apareceu, porque a mensagem apagada já pode ter sido lida ou copiada. A troca inclui atualizar os programas e as integrações que usam a credencial e revogar a antiga, o que vale também para o certificado A1 exposto junto com a senha. Depois da troca, os registros de acesso do período mostram se alguém usou a credencial antiga.