Cómo está construida la seguridad de Arka, capa por capa.

Aislamiento por negocio

Todas las tablas de dominio (ventas, clientes, facturas, inventario…) llevan negocio_id, y ese negocio_id participa en las llaves foráneas compuestas que Postgres exige en cada relación — no es una validación que el código pueda olvidar, es la forma que tienen las tablas mismas.

Row-Level Security en la base de datos

Además de filtrar por negocio_id en cada consulta, cada tabla tiene una política de Row-Level Security en Postgres que compara el negocio_id de la fila contra el negocio activo en la sesión. Es una segunda barrera independiente: si alguna consulta de la aplicación llegara a fallar en filtrar, la base de datos igual rechaza la fila.

Contraseñas con scrypt

Las contraseñas nunca se guardan en texto plano ni con un hash rápido. Usamos scrypt con los parámetros de costo recomendados por OWASP, y cada contraseña lleva su propio salt — dos contraseñas iguales nunca producen el mismo valor guardado.

Permisos verificados en el servidor

Cada acción — ver un reporte, borrar una venta, cambiar un rol — se revisa del lado del servidor contra el rol real del usuario en ese negocio, en cada solicitud. Ocultar un botón en la pantalla no es, ni pretende ser, la barrera de seguridad.

Bitácora transaccional

Las acciones críticas se registran en la misma transacción de base de datos que las origina: si la acción se guarda, el registro de auditoría también se guarda — nunca puede pasar una sin la otra.

Papelera real, no borrado inmediato

Eliminar no es un DELETE inmediato en la mayoría de los flujos: los registros se marcan como eliminados y quedan disponibles en papelera para restaurarse, con quién y cuándo los eliminó.

Idempotencia en integraciones

Los eventos que llegan de terminales de pago (Clip, Mercado Pago) usan una llave de idempotencia única por transacción — un reintento del proveedor (algo que ambos hacen de forma agresiva) nunca puede duplicar una venta.

Verificación en dos pasos (TOTP)

Opcional, activable por cada usuario: un código de un solo uso (RFC 6238, el mismo estándar detrás de Google Authenticator/Authy) además de la contraseña, con códigos de respaldo de un solo uso y límite de intentos con retraso progresivo contra fuerza bruta.