¿Qué es el hardening de seguridad en BaaS?

El hardening de seguridad en BaaS es un conjunto de controles en capas — CLPs, ACLs y disciplina de claves — que cierra las brechas con que nace un backend. Los backends nacen permisivos a propósito: las clases abiertas y los esquemas escribibles por el cliente hacen volar los prototipos. El hardening es la pasada deliberada que invierte esos defaults antes del lanzamiento — y es un checklist corto y conocido, no un proyecto de investigación.

Puntos clave

El default endurecido, en código

La mitad por objeto de la historia — una ACL acotada al dueño, en capa bajo una clase bloqueada:

// 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: qué controla cada uno

Los tres primeros se componen en una escalera de permisos que toda solicitud sube. El cuarto es la salida de emergencia de la escalera — indispensable del lado del servidor, catastrófica en cualquier otro lugar. Y los identificadores que las apps sí llevan a bordo — el app ID y las claves de API de cliente — pertenecen a una categoría mental completamente distinta: son extraíbles de cualquier binario, así que identifican la app en lugar de protegerla. Asume que son públicos y deja que la capa de datos haga el enforcement.

Dónde muere una solicitud hostil

El diagrama es también el guion de auditoría: en cada gate, pregunta qué pasa cuando un atacante con tus claves públicas llega como usuario anónimo, como usuario con sesión iniciada y como usuario de otro tenant. Cada “permitido” que te sorprenda es el hallazgo.

Cómo endurecer un backend BaaS

Los pasos 1–4 son enforcement en la capa de datos — declarativo, verificado en cada camino. Los pasos 5–8 son disciplina operativa. Ambas mitades son necesarias; ninguna es suficiente.

Disciplina de master key y el camino privilegiado

La master key existe porque alguien legítimo — migraciones, herramientas de admin, jobs programados — debe poder ignorar los gates. La disciplina consiste en tratarla como la credencial de root que es: inyectada en los entornos de servidor como configuración, nunca commiteada, nunca logueada, jamás embebida en nada que un usuario descargue, y usada por operación en lugar de mantenida como default de sesión. La rotación es la mitad subestimada — las claves se fugan en silencio a los logs de CI y las laptops viejas, así que rotarlas por calendario (y al instante ante cualquier sospecha) acota el radio de daño de una fuga que nunca detectaste.

Cloud Code es el patrón que hace vivibles las reglas estrictas de la capa de datos. Bloquea una clase por completo — cero escrituras de cliente — y expone una función serverless como única puerta. La función valida la entrada, aplica las reglas de negocio que el esquema no puede expresar (“solo antes de que el pedido se envíe”), escribe con privilegios elevados y deja rastro de auditoría. El gate de la clase garantiza que el chokepoint no puede rodearse; el chokepoint mantiene la lógica revisable en un solo lugar.

Casos de uso comunes

• El lockdown previo al lanzamiento. El checklist completo de arriba, ejecutado una vez antes de que lleguen usuarios reales — la hora de seguridad de mayor apalancamiento que un equipo pequeño invierte.
• Aislamiento de datos multi-tenant. ACLs acotadas al dueño más CLPs de solo autenticados, para que el tenant A jamás pueda consultar al tenant B — con enforcement por debajo del código de la aplicación.
• Pagos e inventario. Clases bloqueadas a cero escrituras de cliente, con funciones de Cloud Code como el camino auditado para todo lo que toque dinero o stock.
• Respuesta a incidentes. Una clave filtrada o una sorpresa en los logs dispara la rotación, una auditoría de accesos y una nueva ronda del test de permisos de afuera hacia adentro.
• Evidencia de compliance. Una matriz de permisos versionada y logs de uso de la master key convierten “nos tomamos la seguridad en serio” en un artefacto que un auditor puede leer.

¿Deberías endurecer en la capa de datos o en el código de la aplicación? Matriz de decisión

En la práctica la respuesta es en capas, no una u otra: reglas en la capa de datos como el piso que siempre sostiene, funciones en la capa de aplicación para todo lo condicional — la misma solicitud atraviesa ambas.

Limitaciones y trade-offs

• El hardening es configuración, y la configuración deriva. Las clases nuevas llegan con defaults permisivos; sin el hábito de reauditar, el lockdown del año pasado se erosiona en silencio.
• Las reglas declarativas no pueden expresar lógica. “Solo los dueños” es un toggle; “solo reembolsable dentro de 30 días” es código — depender demasiado de la capa de datos empuja a los equipos a contorsionar esquemas en vez de escribir una función.
• La rigidez tiene un costo de experiencia de desarrollo. Las clases bloqueadas y los esquemas congelados frenan el prototipado, y por eso la disciplina se escalona: abierto en desarrollo, bloqueado en el lanzamiento.
• Los rate limits y las auditorías necesitan ajuste. Los límites demasiado apretados estrangulan picos legítimos; los logs que nadie lee son decoración. Ambos necesitan un dueño, no solo un commit de setup.
• Las capas protegen los datos, no todo. Las vulnerabilidades en dependencias, las contraseñas de usuario filtradas y la ingeniería social viven fuera de este modelo — endurecer la capa de datos es necesario, no suficiente, como deja claro el catálogo del OWASP API Security Top 10.

Hardening de seguridad en BaaS en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. El checklist de este artículo se mapea a su dashboard casi uno a uno: los permisos a nivel de clase y los campos protegidos son checkboxes por clase, las ACLs se aplican del lado del servidor en cada solicitud — por SDKs, REST y GraphQL — y la master key se queda en la configuración del servidor, donde Cloud Code — el camino privilegiado — puede usarla por operación. Las guías de seguridad recorren la misma pasada paso a paso, así que endurecer un backend es una tarde de toggles y un test honesto de afuera hacia adentro.