O que é hardening de segurança em BaaS?

O hardening de segurança em BaaS é um conjunto de controles em camadas — CLPs, ACLs e disciplina de chaves — que fecha as brechas com que um backend nasce. Backends nascem permissivos de propósito: classes abertas e schemas graváveis pelo cliente fazem o protótipo voar. O hardening é a passada deliberada que inverte esses defaults antes do lançamento — e é um checklist curto e conhecido, não um projeto de pesquisa.

Principais pontos

O default endurecido, em código

A metade por objeto da história — uma ACL restrita ao dono, em camada sob uma classe trancada:

// JavaScript / Node.js — Back4app JS SDK
// Per-object ACL: the owner reads and writes, a moderator role reads,
// the public gets nothing — layered under the class-level permissions
const note = new Parse.Object('Note');
note.set('body', 'quarterly numbers');

const acl = new Parse.ACL(Parse.User.current()); // owner: read + write
acl.setPublicReadAccess(false);
acl.setPublicWriteAccess(false);
acl.setRoleReadAccess('moderator', true);        // role: read only
note.setACL(acl);
await note.save();

// The class gate above it is schema config, set in the dashboard:
// find/get: requiresAuthentication · create: authenticated · addField: nobody

// Flutter / Dart — Back4app Flutter SDK
// Per-object ACL: owner read/write, moderator role read, public nothing
final note = ParseObject('Note')..set('body', 'quarterly numbers');

final acl = ParseACL(owner: await ParseUser.currentUser()); // owner: r+w
acl.setPublicReadAccess(allowed: false);
acl.setPublicWriteAccess(allowed: false);
acl.setReadAccess(userId: 'role:moderator', allowed: true); // role: read
note.setACL(acl);
await note.save();

// The class gate above it is schema config, set in the dashboard:
// find/get requiresAuthentication, create authenticated, addField off

// iOS / Swift — Back4app Swift SDK
// Per-object ACL: owner read/write, moderator role read, public nothing
var note = Note()
note.body = "quarterly numbers"

var acl = ParseACL()
acl.publicRead = false
acl.publicWrite = false
if let user = User.current {
    acl.setReadAccess(user: user, value: true)   // owner: read
    acl.setWriteAccess(user: user, value: true)  // owner: write
}
acl.setReadAccess(roleName: "moderator", value: true) // role: read only
note.ACL = acl
note.save { result in
    if case .failure(let error) = result { print(error) }
}

// Android / Kotlin — Back4app Android SDK
// Per-object ACL: owner read/write, moderator role read, public nothing
val note = ParseObject("Note").apply { put("body", "quarterly numbers") }

val acl = ParseACL(ParseUser.getCurrentUser()) // owner: read + write
acl.publicReadAccess = false
acl.publicWriteAccess = false
acl.setRoleReadAccess("moderator", true)       // role: read only
note.acl = acl
note.saveInBackground { e ->
    if (e != null) Log.w("ACL", "save failed: ${e.code}")
}

// The class gate above it is schema config, set in the dashboard:
// find/get requiresAuthentication, create authenticated, addField off

CLP vs. ACL vs. master key: qual controle faz o quê

Os três primeiros se compõem numa escada de permissões que toda requisição sobe. O quarto é a saída de emergência da escada — indispensável no servidor, catastrófica em qualquer outro lugar. E os identificadores que os apps de fato carregam — o app ID e as chaves de API de cliente — pertencem a uma categoria mental completamente diferente: são extraíveis de qualquer binário, então identificam o app em vez de protegê-lo. Assuma que são públicos e deixe a camada de dados fazer o enforcement.

Onde uma requisição hostil morre

O diagrama também é o roteiro de auditoria: em cada gate, pergunte o que acontece quando um atacante com as suas chaves públicas chega como usuário anônimo, como usuário logado e como usuário de outro tenant. Todo “permitido” que te surpreender é o achado.

Como fazer hardening de um backend BaaS

Os passos 1–4 são enforcement na camada de dados — declarativo, verificado em todo caminho. Os passos 5–8 são disciplina operacional. As duas metades são necessárias; nenhuma é suficiente sozinha.

Disciplina de master key e o caminho privilegiado

A master key existe porque alguém legítimo — migrações, ferramentas de admin, jobs agendados — precisa poder ignorar os gates. Disciplina significa tratá-la como a credencial de root que ela é: injetada nos ambientes de servidor como configuração, nunca commitada, nunca logada, jamais embarcada em qualquer coisa que um usuário baixe, e usada por operação em vez de mantida como default de sessão. A rotação é a metade subestimada — chaves vazam silenciosamente para logs de CI e notebooks antigos, então rotacionar por agenda (e na hora, a qualquer suspeita) limita o raio de explosão de um vazamento que você nunca detectou.

O Cloud Code é o padrão que torna regras estritas na camada de dados vivíveis. Tranque uma classe por completo — zero escritas de cliente — e exponha uma função serverless como única porta. A função valida a entrada, aplica as regras de negócio que o schema não expressa (“só antes de o pedido ser despachado”), escreve com privilégio elevado e deixa trilha de auditoria. O gate da classe garante que o chokepoint não pode ser contornado; o chokepoint mantém a lógica revisável em um só lugar.

Casos de uso comuns

• O lockdown pré-lançamento. O checklist completo acima, rodado uma vez antes de os usuários reais chegarem — a hora de segurança de maior alavancagem que um time pequeno gasta.
• Isolamento de dados multi-tenant. ACLs restritas ao dono mais CLPs que exigem autenticação, para que o tenant A jamais consulte o tenant B — com enforcement abaixo do código da aplicação.
• Pagamentos e estoque. Classes trancadas com zero escritas de cliente, e funções de Cloud Code como caminho auditado para qualquer coisa que toque dinheiro ou inventário.
• Resposta a incidentes. Uma chave vazada ou uma surpresa nos logs dispara rotação, auditoria de acesso e nova rodada do teste de permissões de fora para dentro.
• Evidência de compliance. Uma matriz de permissões versionada e logs de uso da master key transformam “levamos segurança a sério” em artefato que um auditor consegue ler.

Você deveria endurecer na camada de dados ou no código da aplicação? Matriz de decisão

Na prática a resposta é em camadas, não um ou outro: regras na camada de dados como o chão que sempre segura, funções na camada de aplicação para tudo que é condicional — a mesma requisição atravessa as duas.

Limitações e trade-offs

• Hardening é configuração, e configuração deriva. Classes novas chegam com defaults permissivos; sem o hábito de reauditar, o lockdown do ano passado se corrói em silêncio.
• Regras declarativas não expressam lógica. “Só os donos” é um toggle; “só reembolsável em 30 dias” é código — depender demais da camada de dados leva times a contorcer schemas em vez de escrever uma função.
• Rigor tem custo de experiência do desenvolvedor. Classes trancadas e schemas congelados atrasam a prototipação, e é por isso que a disciplina é faseada: aberto em desenvolvimento, trancado no lançamento.
• Rate limits e auditorias precisam de ajuste fino. Limites apertados demais estrangulam picos legítimos; logs que ninguém lê são decoração. Os dois precisam de dono, não só de um commit de setup.
• As camadas protegem dados, não tudo. Vulnerabilidades em dependências, senhas de usuário vazadas e engenharia social vivem fora deste modelo — endurecer a camada de dados é necessário, não suficiente, como o catálogo do OWASP API Security Top 10 deixa claro.

Hardening de segurança em BaaS 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 checklist deste artigo mapeia no dashboard quase um para um: permissões em nível de classe e campos protegidos são checkboxes por classe, ACLs são aplicadas no servidor em toda requisição — pelos SDKs, REST e GraphQL — e a master key fica na configuração do servidor, onde o Cloud Code, o caminho privilegiado, pode usá-la por operação. As diretrizes de segurança percorrem a mesma passada passo a passo, de modo que endurecer um backend é uma tarde de toggles e um teste honesto de fora para dentro.