Feature 01 / 04
Cimiento
Multi-tenant por diseño, no por retrofit
Helpdash fue construido tenant-first. Cada consulta lleva un límite de workspace en la capa de datos; cada workspace posee sus filas, su prefijo de almacenamiento, sus roles, su registro de auditoría. No hay ruta — autenticada o no — donde el ámbito de tenant sea opcional. Para equipos de ingeniería y seguridad: esta es la arquitectura que pedirías en una revisión de compras.
Resultados
Las garantías de aislamiento que sobreviven a una auditoría
Multi-tenant no es un feature flag que entregamos. Es el modelo de datos: ámbito a nivel de fila en cada lectura y escritura, RBAC consciente de equipo, almacenamiento delimitado, registro de auditoría firmado. Compras, SOC 2, ISO 27001 — las respuestas son las mismas en cada formulario.
Feature 02 / 04
RBAC delimitado al workspace
los roles viven dentro de un tenant, los permisos nunca se filtran a través del límite
Feature 03 / 04
Prefijo de almacenamiento por workspace con URLs de descarga firmadas y de corta duración — sin bucket compartido, sin path traversal entre tenants
Feature 04 / 04
Registro de auditoría a prueba de manipulación retenido más allá de la eliminación del workspace para cumplir ventanas regulatorias
Dentro del modelo
Cómo Helpdash hace que la multi-tenancia sea aburrida
Feature 01 / 03
Scope global de consulta
Un scope global en cada modelo auto-filtra por clave de tenant. Olvidar el límite en los call sites es estructuralmente imposible; el framework lo conecta en la capa de datos.
Feature 02 / 03
RBAC a nivel de equipo
Roles y permisos son tenant-aware — el rol de un agente en el workspace A es invisible en el workspace B. Sin transferencia accidental de privilegios entre mesas.
Feature 03 / 03
Almacenamiento por tenant
Los prefijos de sistema de archivos (tenants/{id}/) vinculan cada carga a su workspace. Las URLs de descarga son firmadas, de corta duración y verificadas por tenant en el momento de emisión.
FAQ
Frequently asked questions
¿Cuál es el modelo de datos?
Un esquema único compartido con una clave de tenant en cada registro de negocio. Los modelos usan un trait BelongsToTenant que instala un scope global de consulta; las lecturas y escrituras heredan el límite de workspace automáticamente. El acceso cruzado entre tenants requiere una sobrescritura explícita y auditada en la capa de aplicación.
¿Cómo se resuelve el tenant en cada petición?
Las rutas autenticadas ignoran las cabeceras X-Tenant-Slug y host — el claim de workspace dentro del JWT firmado es autoritativo, punto. Las rutas no autenticadas (login, docs públicas) resuelven vía cabecera → subdominio → query string, en esa prioridad, con una lista de nombres reservados (p.ej. www, api, admin) que previene colisiones.
¿Qué ve realmente un auditor?
Un registro de auditoría firmado, solo-append por workspace, retenido más allá de la eliminación del tenant, exportable a tu SIEM. Más el scope ORM: una prueba de una línea de que cada consulta está vinculada al tenant, lo que suele ser suficiente para SOC 2 CC6.1 e ISO 27001 A.9.4.1.
Mira el modelo de aislamiento en tu propio workspace
Levanta dos workspaces bajo un mismo login y mira cómo nunca se ven — en la API, la UI o la capa de almacenamiento. Plan gratis, sin tarjeta de crédito.