Por Nicho Agencia Digital · Publicado el
Distingue pertenencia de permiso
Un pedido puede pertenecer a una sede aunque otra participe en su despacho. Un asesor puede trabajar temporalmente en dos sucursales sin tener acceso general a las demás. Si el sistema guarda una sola etiqueta de sede para resolver ambas situaciones, termina confundiendo el lugar de la operación con la autoridad de la persona.
Como ejercicio de alcance, lista las entidades principales: clientes, pedidos, inventario, cajas, documentos y reportes. Define cuáles son globales, cuáles pertenecen a una sucursal y cuáles pueden compartirse bajo una condición. No presupongas que dos sedes necesitan copias aisladas de todos los datos ni que compartir base de datos obliga a compartir acceso.
Una sucursal de la misma empresa tampoco equivale necesariamente a un cliente independiente de una plataforma. Si el software atiende varias empresas, el límite entre organizaciones requiere una decisión de aislamiento adicional; no debe reducirse al filtro visual que usa una tienda para escoger sede.
Construye una matriz con acciones concretas
Evita perfiles como “operador” con permisos indefinidos. Para cada función escribe si puede consultar, crear, modificar, aprobar, exportar o reasignar cada tipo de registro. Añade el alcance: sede propia, sedes asignadas o consolidado de la empresa. Especifica también qué sucede cuando alguien cambia de función.
- Asesor: consultar y actualizar los casos que le correspondan.
- Responsable de sede: revisar operación local dentro del alcance acordado.
- Coordinación: consultar un consolidado sin asumir permiso para editar cada registro.
- Soporte temporal: acceso con motivo, alcance y fecha de finalización.
Estos perfiles son ejemplos de diseño, no una configuración universal. Un negocio pequeño puede necesitar menos roles. El objetivo es describir responsabilidades comprobables, no multiplicar casillas de configuración que nadie pueda mantener.
Aplica el alcance fuera de la pantalla
La guía de autorización de OWASP recomienda validar permisos en cada solicitud. El selector de sucursal ayuda al usuario, pero el servidor debe comprobar que tiene derecho a operar en la sede elegida. Cambiar un identificador en una URL o una petición no debería abrir un registro ajeno.
La guía de seguridad multicliente de OWASP desarrolla el aislamiento entre organizaciones. Sus controles son relevantes cuando la solución aloja empresas distintas; no convierten por sí solos un diseño multisede en seguro. La arquitectura concreta exige revisión técnica de datos, sesiones y componentes compartidos.
Incluye en el alcance exportaciones, búsquedas, archivos descargables, reportes y tareas programadas. Una pantalla bien filtrada no compensa un archivo exportado con registros de todas las sedes. Define qué contexto usa una tarea cuando ya no hay una persona frente a la aplicación.
Ejemplo hipotético: apoyo entre dos sucursales
En una empresa ficticia, una asesora de la sede Norte cubre dos días de trabajo en la sede Centro. La responsable asigna acceso temporal a los pedidos necesarios de Centro, con fecha de cierre. El sistema registra esa asignación; no cambia silenciosamente la propiedad de todos los pedidos de la asesora.
Al terminar la cobertura, se retira el acceso temporal. Los casos pendientes se reasignan mediante el procedimiento acordado y conservan su historial. Si un pedido necesita despacho desde Norte, se registra esa participación sin copiar todo el expediente a una segunda cuenta. El ejemplo no describe una empresa real ni garantiza cumplimiento de requisitos específicos.
Pide pruebas que crucen los límites
Antes de aceptar el desarrollo, prepara cuentas de prueba de dos sedes y, si corresponde, dos empresas. Intenta consultar un registro por enlace directo, modificarlo, exportarlo y abrir sus documentos desde una cuenta sin permiso. Repite las pruebas después de retirar un acceso temporal y al ejecutar un reporte consolidado.
Comprueba tanto lo permitido como lo denegado: que una persona no pueda ver otra sede no sirve si tampoco puede completar su trabajo autorizado. Documenta el resultado esperado y real, con datos ficticios. Para organizar esta revisión utiliza una prueba de aceptación con criterios observables.
Una entrega útil incluye la matriz vigente, responsables de aprobar cambios y un procedimiento para altas, traslados y retiros. El beneficio esperado es reducir ambigüedad operativa y facilitar la comprobación de accesos. No sustituye una evaluación de seguridad ni demuestra por sí mismo una reducción de incidentes.
El siguiente paso
Podemos delimitar entidades compartidas, permisos por sede y pruebas de aceptación antes de cotizar un sistema para tu operación.
Software a medida para empresas · Conversar sobre tu proyecto ↗
Fuentes y alcance
Fuentes consultadas el 4 de noviembre de 2026. Las recomendaciones de proceso son propuestas editoriales de Nicho; los ejemplos identificados como hipotéticos no representan resultados de clientes.
Contenido preparado con asistencia de IA y comprobaciones automáticas. No sustituye una evaluación de tu implementación ni garantiza resultados. Escríbenos si encuentras algo que debamos corregir.