O que é criptografia de dados em repouso e em trânsito?

Criptografia em repouso é um controle que torna dados armazenados ilegíveis sem as chaves; a criptografia em trânsito protege os dados que cruzam a rede. Dados vivem em três estados — em repouso no armazenamento, em trânsito no fio e em uso na memória — e os dois primeiros são a obrigação de base de toda aplicação: AES-256 para o que fica parado, TLS para o que se move. O terceiro estado (protegido por ambientes de execução confiáveis e, na fronteira, por criptografia homomórfica) é real, mas, para a maioria dos times de aplicação, é a camada de outra pessoa.

Principais pontos

As duas proteções — e o que cada uma barra de fato

A tabela honesta que as páginas do ranking omitem — incluindo a coluna que mais importa:

              Padrão            Cobre                    Barra                     NÃO barra
Em trânsito   TLS 1.2+/HTTPS    todo trecho de rede      grampos, MITM,            endpoints comprometidos —
                                                         bisbilhotice de wi-fi     o servidor lê numa boa
Em repouso    AES-256 (GCM)     discos, BDs, backups     drives roubados, backups  credenciais roubadas,
                                                         vazados, buckets abertos  SQL injection, bugs do app
Em uso        TEEs              RAM durante o            raspagem de memória       — preocupação de plataforma,
                                processamento                                        na maior parte

Nenhuma barra um atacante em quem o próprio app confia. O app guarda as chaves e
descriptografa sob demanda — criptografia complementa controle de acesso, nunca o substitui.

Como os padrões seguros aparecem no código da aplicação:

// JavaScript / Node.js — Back4app JS SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret });
// On the wire: TLS 1.2+ (the https serverURL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Flutter / Dart — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// iOS / Swift — Back4app Swift SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
var user = User()
user.username = "ada"
user.password = secret
let signedUp = try await user.signup()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Android / Kotlin — Back4app Android SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.signUp()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

Como o TLS funciona, em um parágrafo

O truque elegante: a criptografia assimétrica é lenta, mas não precisa de segredo compartilhado; a simétrica é rápida, mas precisa de um. Então o handshake do TLS usa a primeira para estabelecer a segunda — o cliente verifica o certificado do servidor (a checagem de identidade que torna a interceptação detectável), os dois lados combinam uma chave de sessão nova via troca de chaves assimétrica, e tudo dali em diante viaja em criptografia simétrica rápida. O TLS 1.3 apertou tudo isso: uma ida e volta em vez de duas, cifras legadas e troca de chaves RSA removidas, forward secrecy obrigatório — assim, tráfego gravado não pode ser descriptografado depois, mesmo que a chave de longo prazo do servidor vaze. Adendo mobile que as páginas do ranking pulam: apps podem adicionalmente fazer pinning dos certificados esperados, trocando resiliência contra autoridades certificadoras desonestas por cuidado operacional na hora da rotação.

As camadas em repouso: disco vs. banco vs. campo vs. aplicação

“Criptografado em repouso” abrange quatro promessas bem diferentes — cada uma derrotando um atacante diferente:

A regra que atravessa a tabela inteira: camadas mais altas protegem contra mais, custam mais. Criptografia em nível de campo é a troca honesta — colunas criptografadas não podem ser indexadas nem pesquisadas normalmente (criptografia determinística devolve buscas por igualdade ao custo de algum vazamento) — e por isso fica reservada ao genuinamente sensível: dados de saúde, documentos de identidade, segredos. E a falha clássica de auditoria mora aqui: o banco criptografado cujos backups saem sem criptografia.

Criptografia de ponta a ponta é outra promessa

TLS em todo lugar ainda significa que o servidor lê tudo — ele descriptografa cada conexão por design. A criptografia de ponta a ponta move as chaves para os usuários: só remetente e destinatário conseguem descriptografar, e o operador serve um ciphertext que não consegue abrir. Isso é uma decisão de produto diferente, não uma configuração mais forte: E2EE significa nenhuma busca no servidor, nenhuma moderação de conteúdo, nenhuma recuperação se os usuários perderem as chaves. Os modelos de ameaça se encaixam de forma limpa — TLS defende o caminho, em repouso defende o armazenamento, E2EE defende contra o próprio serviço — e a maioria das aplicações corretamente para nas duas primeiras, enquanto mensageiros e cofres de senhas justificam a terceira.

Hashing vs. criptografia

Um destaque aposenta uma confusão disseminada: senhas recebem hash, nunca criptografia. Ninguém — incluindo o servidor — deveria conseguir recuperar uma senha; o login compara hashes. Criptografar senhas significa que existe uma chave que descriptografa todas — exatamente a catástrofe que o hashing existe para impedir.

Casos de uso comuns

• Todo app web e mobile — TLS em todas as conexões e armazenamento criptografado são o piso, não features.
• Dados regulados — a GDPR nomeia a criptografia como medida técnica apropriada (com alívio na notificação de violações), regras de saúde a exigem para dados de pacientes, e padrões de pagamento exigem números de cartão ilegíveis em repouso e criptografia forte em trânsito.
• Backups e descomissionamento — backups criptografados e crypto-shredding (destrua a chave, o dado morre em todo lugar) encerram o capítulo da cópia roubada.
• Proteção de campos com PII — criptografia em nível de aplicação para as colunas cujo vazamento é manchete, não incidente.
• Clientes mobile em redes hostis — TLS mais validação de certificado como a defesa que viaja com o usuário.

De qual camada você precisa? Matriz de decisão

Limitações e trade-offs

• Criptografia não é controle de acesso. O argumento da segurança em camadas em uma linha: a criptografia em repouso é transparente para o app em execução, então as permissões — ACLs, CLPs, políticas de linha — continuam sendo a defesa contra todo atacante com credenciais.
• Gestão de chaves é o projeto de verdade. A orientação do NIST existe porque geração, separação, rotação e revogação — não a escolha do algoritmo — são onde as implantações falham.
• Criptografia em nível de campo briga com o banco. Sem índices, sem consultas LIKE, migrações cuidadosas; criptografe os campos que precisam, não o schema.
• O TLS termina no terminador. Proxies e load balancers que descriptografam no meio do caminho recriam trechos em texto claro; o tráfego interno precisa da mesma disciplina da borda.
• Compliance ≠ segurança. Criptografia de checkbox com as chaves ao lado dos dados satisfaz auditores e mais ninguém; a coluna do modelo de ameaça é a que se projeta contra.

Criptografia no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. O piso vem da plataforma: toda conexão REST, GraphQL e Live Query viaja sobre TLS, e dados e backups são criptografados em repouso — as duas camadas de base chegam como padrão, não como projeto. A parte que sobra para o desenvolvedor é exatamente o que as abas de código esboçam: senhas recebem hash bcrypt do Back4app de fábrica (nunca armazenadas, nunca recuperáveis — a regra do hashing imposta estruturalmente); campos genuinamente sensíveis ganham criptografia em nível de aplicação em um beforeSave do Cloud Code, com a chave na configuração do servidor e não no código, para que o texto claro nunca chegue ao armazenamento; e segredos ficam fora de logs, URLs e bundles de cliente — a disciplina de chaves de API aplicada aos dados. E então a peça que a criptografia não faz: ACLs e permissões em nível de classe governam quem lê o quê, porque o controle que barra um atacante com credenciais nunca foi a criptografia — sempre foi a autorização.