Criptografia de dados para empresas: guia para chats

Cada pedido no WhatsApp, cada DM no Instagram e cada atendimento no Telegram deixa dados de clientes para trás: telefones, endereços de entrega, históricos de conversa e os tokens de acesso que conectam seus canais. A criptografia de dados para empresas transforma esses dados em texto cifrado, ilegível para quem não tem a chave, enquanto eles trafegam pela rede e enquanto ficam parados em bancos de dados e backups.

Principais pontos

A criptografia de dados para empresas tem duas camadas: a criptografia em trânsito (TLS) protege os dados em movimento e a criptografia em repouso (normalmente AES) protege os dados armazenados.
Tokens de acesso de canais, chaves de API e segredos de webhook são credenciais. Um token vazado permite que um invasor aja como se fosse a sua empresa, então criptografe esses valores em nível de campo.
A criptografia de disco protege um disco roubado, não um servidor em execução. A criptografia em nível de campo, com as chaves guardadas fora do banco de dados, continua protegendo esses campos em um dump vazado.
O AES-256-GCM é criptografia autenticada: esconde os dados e detecta adulteração, e depende de nunca reutilizar um nonce com a mesma chave.
A criptografia não barra quem tem permissão para descriptografar. Uma plataforma de resposta automática com IA precisa ler as mensagens para respondê-las, então controle de acesso e retenção pesam tanto quanto as cifras.

O que a criptografia de dados para empresas deve cobrir em um negócio que vende por chat

Uma empresa que vende por chat, por exemplo com uma caixa de entrada com IA para WhatsApp, tem o próprio inventário de dados:

Credenciais e segredos. Tokens de acesso de Página do Facebook e do WhatsApp Business, tokens de bot do Telegram, chaves de provedores de IA, chaves de provedores de pagamento e segredos de webhook.
Dados pessoais dos clientes. Telefones, e-mails, endereços de entrega e IDs de clientes. No comércio por chat, o telefone costuma ser a identidade do cliente.
Históricos de conversa e mídias. Transcrições, áudios, fotos e faturas que os clientes enviam.
Senhas da equipe. Elas devem passar por hash, não por criptografia (mais sobre isso abaixo).
Dispositivos da equipe. Notebooks e celulares que abrem a caixa de entrada ou guardam exportações. Ative o FileVault ou o BitLocker, senha de bloqueio e apagamento remoto.
Cópias. Backups, exportações em CSV, logs e bancos de homologação, quase sempre menos protegidos do que a produção.

Uma regra simples para proteger dados de clientes: proteja em nível de campo tudo o que dá acesso ou identifica uma pessoa, e dê a cada cópia a mesma proteção do original.

Criptografia em repouso e em trânsito

A criptografia em trânsito protege os dados enquanto eles se movem entre um navegador, o seu servidor e APIs de terceiros. A criptografia em repouso protege os dados guardados em discos, em bancos de dados e em backups.

Aspecto	Criptografia em trânsito	Criptografia em repouso
Protege contra	Escuta, adulteração, servidores falsos	Discos roubados, dumps vazados, backups expostos
Padrão típico	TLS 1.2 ou TLS 1.3	AES-256, muitas vezes AES-256-GCM
Onde se aplica	Navegador para aplicação, webhooks, chamadas de API	Disco, banco de dados, campos isolados, backups
Não cobre	Dados depois de chegarem e serem descriptografados	Dados em uso por uma aplicação em execução

A NIST SP 800-52 Rev. 2 exige que servidores TLS do governo dos Estados Unidos suportem TLS 1.2 e passem a suportar TLS 1.3 até janeiro de 2024. Essa é uma linha de base sensata para qualquer empresa: aceite TLS 1.2 e 1.3 e desative tudo o que for mais antigo.

O TLS protege apenas o trajeto. A WhatsApp Cloud API entrega webhooks por HTTPS, e a documentação da Meta explica que a Cloud API descriptografa as mensagens recebidas e as encaminha para a empresa, guardando-as por no máximo 30 dias. Daí em diante, quem assume são o armazenamento e os controles de acesso.

Criptografia de disco, de banco de dados e em nível de campo

A criptografia em repouso vem em camadas:

A criptografia de disco ou de volume protege um disco roubado ou descartado. Enquanto o servidor está em execução, o sistema operacional descriptografa os dados automaticamente, então um invasor dentro do servidor vê os dados em texto claro.
A criptografia do arquivo do banco de dados tem o mesmo limite: quem consegue consultar o banco recebe texto claro de volta.
A criptografia em nível de campo criptografa colunas específicas, como um token ou um telefone, dentro da aplicação, antes de chegarem ao banco. A chave fica em outro lugar, então um dump vazado ou um backup copiado mostra texto cifrado nesses campos.

O custo disso é a busca: não dá para rodar um filtro SQL comum em uma coluna criptografada. Uma abordagem prática é reservar a criptografia em nível de campo para segredos e dados de contato de alto risco. Times que precisam localizar clientes por telefone ou e-mail podem guardar um hash com chave (um blind index) ao lado do texto cifrado e buscar por ele.

AES-256-GCM: tamanho da chave e modo de operação

O AES é definido na FIPS 197 com chaves de 128, 192 e 256 bits. O AES-256 usa a maior das três.

O modo importa tanto quanto o tamanho da chave. O GCM (NIST SP 800-38D) é criptografia autenticada: mantém os dados confidenciais e detecta se alguém alterou o texto cifrado. Nunca reutilize um nonce com a mesma chave: a reutilização de nonce quebra as garantias do GCM, então deixe uma biblioteca mantida gerar os nonces e nunca escreva a sua própria criptografia.

Como armazenar chaves de API e tokens de acesso com segurança

Escolha conforme a necessidade de recuperar o valor original:

Criptografe os segredos que você precisa enviar a terceiros: tokens de acesso do WhatsApp e do Instagram, tokens de bot do Telegram, chaves de provedores de IA e chaves de pagamento. Use AES-GCM em nível de campo, com a chave guardada fora do banco de dados.
Faça hash dos segredos que você só precisa verificar: senhas, chaves de API de parceiros e códigos de uso único. Um hash não pode ser revertido ao valor original, mas valores curtos ou previsíveis cedem à força bruta, então use um hash lento como Argon2id ou bcrypt para senhas e um HMAC com chave para códigos.
Mantenha-os fora dos logs, das mensagens de erro, das ferramentas de analytics e das URLs.
Limite o escopo e faça rotação. Peça apenas as permissões de que o token precisa e troque os tokens quando alguém com acesso sair da empresa.

A criptografia em repouso não protege um token enquanto ele fica descriptografado na memória durante uma chamada de API. Hardening do servidor e privilégio mínimo reduzem esse risco.

Fundamentos do gerenciamento de chaves criptográficas

A criptografia é tão forte quanto o lugar onde a chave é guardada. A falha clássica é a chave guardada ao lado dos dados, no mesmo banco de dados ou em um arquivo de configuração versionado.

Separe as chaves dos dados. Guarde as chaves em um gerenciador de segredos, em um KMS ou na configuração do servidor, fora do alcance do banco de dados.
Use criptografia em envelope em escala. Uma chave mestra criptografa as chaves de dados, então girar a chave mestra não obriga a recriptografar tudo.
Derive chaves por finalidade com uma função de derivação de chaves como o HKDF.
Planeje rotação e recuperação. Uma chave perdida significa dados perdidos, inclusive nos backups.

Controle de acesso e privilégio mínimo: só a criptografia não basta

A criptografia barra quem não tem a chave, não as pessoas ou os sistemas autorizados a descriptografar. Uma plataforma de resposta automática com IA precisa ler a mensagem do cliente para escrever a resposta, então os servidores dela processam mensagens legíveis.

A mesma lógica vale mais acima na cadeia. O whitepaper de segurança do WhatsApp não considera criptografadas de ponta a ponta as conversas com empresas que usam a Cloud API, porque as mensagens não são entregues diretamente a um endpoint controlado pela empresa. Veja WhatsApp Business Cloud API x aplicativo Business antes de escolher a sua configuração.

A camada seguinte, portanto, é sobre quem consegue chegar aos dados:

Controle de acesso com privilégio mínimo: dê a cada pessoa do time o menor papel que resolve. Quem responde conversas não precisa de faturamento.
Login forte: acrescente uma segunda etapa de verificação e revogue as sessões no logout.
Isolamento entre empresas: toda requisição deve provar que quem chama pertence àquela empresa.
Logs de auditoria e retenção: registre ações privilegiadas e guarde os históricos de conversa só pelo tempo necessário.

Backups, exportações e retenção

Backups são cópias completas dos dados dos clientes, muitas vezes guardadas por mais tempo e vigiadas com menos atenção do que a produção. Criptografe os arquivos de backup, restrinja quem pode baixá-los, teste as restaurações, inclusive a recuperação das chaves, e apague exportações CSV antigas compartilhadas por e-mail ou chat.

A criptografia também tem peso jurídico. O Artigo 32 do GDPR cita a criptografia como medida de segurança, e o Artigo 34(3)(a) permite que o controlador deixe de comunicar o incidente às pessoas afetadas quando a criptografia tornou os dados ininteligíveis para quem não tinha autorização. O dever do Artigo 33, de notificar a autoridade supervisora em até 72 horas após tomar conhecimento do incidente, é separado. A PDPL da Arábia Saudita e a KVKK da Turquia também fixam prazos de 72 horas para o regulador.

Isto é informação geral, não aconselhamento jurídico. Se o GDPR ou outra lei se aplica ao seu caso, e se alguma exceção cabe em um incidente específico, depende da sua situação, então consulte um advogado qualificado.

O que perguntar a qualquer fornecedor de chat ou CRM

Antes de conectar seus canais, use estas perguntas de segurança para fornecedores de chatbot como um questionário por escrito:

Quais versões de TLS os seus endpoints aceitam?
Quais dados são criptografados em repouso, e em qual camada? O conteúdo das mensagens está incluído?
Os tokens de canais e as chaves de API são criptografados em nível de campo, e onde a chave fica guardada?
Os backups são criptografados, e quem tem acesso a eles?
A equipe de vocês consegue ler as nossas conversas, e esse acesso fica registrado em log?
Quais papéis e permissões podemos definir para o nosso time?
Como os nossos dados são isolados dos de outros clientes?
As nossas conversas são usadas para treinar modelos de IA, por vocês ou pelos seus provedores de IA?
Quem são os seus suboperadores, e onde os dados ficam armazenados?
Vocês assinam um DPA, e em quanto tempo os dados são apagados depois que sairmos?

Desconfie de respostas como "criptografia de nível militar" ou "todos os dados totalmente criptografados". Um fornecedor confiável nomeia o algoritmo, a camada e as lacunas.

O que a Raabt criptografa e protege hoje

Cada item abaixo reflete o código da Raabt em setembro de 2026.

Criptografia em nível de campo: campos sensíveis são criptografados no nível da aplicação com AES-256-GCM. As novas gravações usam uma chave derivada via HKDF-SHA256, e os valores antigos são recriptografados com ela no próximo salvamento. A aplicação se recusa a iniciar sem uma chave de pelo menos 32 caracteres.
O que é criptografado: credenciais e tokens (tokens de acesso de canais do Facebook, Instagram, WhatsApp e Telegram, chaves de API de provedores de IA e de pagamento, segredos de webhook) e dados de contato selecionados (telefones, e-mails e endereços de pedido dos clientes).
Hash: as senhas usam Argon2id (19 MiB de memória, 2 iterações), e hashes bcrypt antigos são atualizados no login. Os segredos das chaves de API de parceiros são guardados apenas como hashes SHA-256.
Login: os logins por e-mail e senha exigem um código de uso único enviado ao e-mail do usuário antes de qualquer sessão ser emitida (o login com Google não usa esse código). Os códigos são guardados apenas como hashes HMAC-SHA256, expiram e funcionam uma única vez.
Acesso da equipe: quatro papéis (owner, admin, agent, viewer) com permissões por seção. O acesso ao faturamento não pode ser delegado a quem não é owner.
Isolamento: os endpoints de negócio confirmam que quem chama é membro ativo daquela empresa e retornam "not found" caso contrário.
Webhooks e mídias: webhooks da Meta são rejeitados sem uma assinatura X-Hub-Signature-256 válida, webhooks do Telegram exigem um token secreto e os anexos são servidos apenas por URLs assinadas e com expiração.
Infraestrutura: a aplicação não fica exposta diretamente à internet; o tráfego público chega até ela por um Cloudflare Tunnel. Os logs de erro do banco de dados nunca incluem parâmetros de consulta, então telefones e e-mails ficam fora desses logs.
Log de auditoria do admin da plataforma: as ações do admin da plataforma são gravadas em um log de auditoria somente de acréscimo (quem, o quê, quando, IP, com snapshots de antes e depois e segredos ocultados). Este não é um log das mensagens dos clientes.

O que a criptografia não resolve aqui: uma caixa de entrada com IA precisa ler o texto das mensagens para escrever a resposta, então o conteúdo das conversas é processado de forma legível no servidor. É exatamente por isso que os pontos acima sobre controle de acesso, retenção e backup pesam tanto quanto a cifra escolhida.

As solicitações de exclusão de dados da Meta retornam um código de confirmação com link de status na nossa página de exclusão de dados. A exclusão da conta exige a sua senha mais um código de uso único enviado por e-mail, e a conta é desativada e o e-mail dela é anonimizado.

Checklist de criptografia de dados para empresas: ordem de implantação para times pequenos

A criptografia de dados para pequenas empresas funciona melhor em uma ordem fixa, começando pelo que causa mais estrago quando vaza:

Sirva tudo por HTTPS, apenas com TLS 1.2 ou 1.3.
Ative a criptografia de disco completa e o bloqueio de tela em todo dispositivo que abre conversas de clientes.
Leve tokens e chaves de API para criptografia em nível de campo, com chaves separadas.
Faça hash das senhas com Argon2id ou bcrypt e acrescente uma segunda etapa no login.
Criptografe telefones, e-mails e endereços dos clientes.
Criptografe os backups, defina papéis com privilégio mínimo e estabeleça prazos de retenção das conversas.
Envie esse questionário a todo fornecedor de chat, CRM e IA que você usa.

Perguntas frequentes

Quais dados a empresa deve criptografar?

Comece por tudo o que dá acesso ou identifica uma pessoa: tokens de canais, chaves de API, segredos de webhook e telefones, e-mails e endereços dos clientes. Depois cubra os históricos de conversa, os dispositivos da equipe e cada backup ou exportação.

Qual a diferença entre criptografia em repouso e em trânsito?

A criptografia em trânsito, normalmente TLS, protege os dados em movimento entre dispositivos, servidores e APIs. A criptografia em repouso, normalmente AES, protege os dados armazenados.

A criptografia AES-256 basta para proteger os dados dos clientes?

O AES-256 é forte, mas o algoritmo raramente é o ponto fraco. As falhas comuns são guardar mal as chaves, reutilizar nonces, dar acesso amplo à equipe e deixar backups desprotegidos.

Como armazenar chaves de API e tokens de acesso com segurança?

Criptografe com AES-GCM em nível de campo os tokens que você precisa reutilizar e mantenha a chave fora do banco de dados. Faça hash dos segredos que você só verifica, como senhas e chaves de API de parceiros.

Se eu uso HTTPS, meus dados estão protegidos no servidor?

Não. O HTTPS protege os dados apenas em trânsito. No servidor, a segurança depende da criptografia em repouso, do controle de acesso e do cuidado com os backups.

O que perguntar a um fornecedor de chatbot ou CRM sobre segurança?

Pergunte quais versões de TLS ele aceita, o que é criptografado em repouso e em qual camada, onde as chaves ficam guardadas, se o acesso da equipe dele às conversas fica registrado em log, quem são os suboperadores e onde os dados ficam, se as conversas treinam modelos de IA e se ele assina um DPA com prazo de exclusão.

Quer atender pelos seus chats em uma caixa de entrada com IA que criptografa os tokens de canais e dados de contato selecionados? Comece grátis.