Un área de clientes es privada cuando el servidor comprueba qué recursos y acciones puede utilizar cada usuario. Pedir una contraseña solo demuestra una identidad según el mecanismo de acceso. No garantiza que esa persona deba ver una factura, un presupuesto o un archivo concreto.

Antes de construir el panel, define relaciones: usuario, empresa, recurso y operación. Ese mapa determina el acceso y evita que la privacidad dependa de ocultar botones. La interfaz ayuda a orientarse; la decisión de permitir o denegar debe sostenerse en el límite técnico apropiado.

Identidad y permiso responden a preguntas distintas

Una sesión puede corresponder a una persona válida y seguir intentando una operación que no le pertenece. También puede conservar una relación antigua con una empresa después de un cambio de puesto. El acceso necesita representar la situación vigente, no solo la existencia de una cuenta.

La guía de autorización de OWASP distingue estos conceptos y recomienda mínimo privilegio, denegación por defecto y comprobación de permisos en las solicitudes. Es una base de diseño y revisión; no certifica que una aplicación concreta sea segura.

Pregunta quién puede asignar una persona a una empresa y cómo se verifica esa relación. Permitir que alguien escriba un nombre comercial al registrarse no prueba que deba acceder a sus documentos. Diseña ese paso antes de prometer alta automática en un portal privado.

Qué debe quedar separado entre clientes

No limites la revisión a la portada del panel. Incluye archivos, enlaces de descarga, resultados de búsqueda, exportaciones, avisos y vistas compartidas. Una factura puede estar correctamente escondida en el menú y seguir disponible desde una dirección sin control adecuado.

  • Lectura: qué información puede consultar cada perfil.
  • Escritura: qué datos puede modificar y con qué límites.
  • Descarga: cómo se autoriza el acceso al archivo.
  • Administración: quién invita, revoca o cambia relaciones.

Define el acceso por recurso y operación. «Usuario de cliente» es demasiado general si una persona consulta documentación técnica y otra gestiona facturación. Evita copiar permisos amplios porque el primer prototipo tenga pocos usuarios.

El identificador no es una protección

Una dirección difícil de adivinar no sustituye la autorización. El servidor debe decidir si el solicitante puede usar el recurso, incluso cuando conoce su referencia. No uses documentos reales para experimentar con este comportamiento: prepara datos ficticios y pruebas autorizadas en un entorno controlado.

Recurso práctico: matriz de fronteras del portal

Propongo una matriz de fronteras con filas de recursos y columnas de operaciones. Añade perfil, empresa vinculada, condición de acceso y resultado esperado al denegar. Su propósito es concretar qué debe proteger el sistema antes de elegir componentes de interfaz.

Ejemplo: «factura ficticia de empresa A», operación «descargar», perfil «gestor de A», condición «relación activa», resultado «permitido». La misma operación para un usuario de B debe denegarse sin entregar contenido del documento. La prueba utiliza recursos preparados, sin datos de clientes.

Incluye situaciones de transición: invitación no aceptada, relación revocada, empresa inactiva y cambio de perfil. Si solo pruebas una cuenta que acaba de crearse, no compruebas el mantenimiento de permisos durante la vida del portal.

Revocar acceso forma parte del producto

Decide qué ocurre cuando una persona deja de pertenecer al cliente. Deben revisarse sesiones, permisos y enlaces emitidos según la arquitectura utilizada. Un botón «desactivar» no demuestra que todas las vías de acceso hayan dejado de funcionar.

La comunicación también necesita precisión. Puedes confirmar que la cuenta se desactivó cuando ese estado está comprobado, sin afirmar que una descarga anterior haya desaparecido del dispositivo del usuario. La revocación controla el sistema; no borra copias ya entregadas.

Los registros operativos deben permitir revisar accesos y denegaciones con información proporcionada. Evita volcar el contenido de documentos, secretos o datos personales innecesarios en logs. La necesidad de trazabilidad no justifica registrar todo lo que el navegador envía.

Caso hipotético: un proveedor comparte presupuestos

Un proveedor ficticio crea un portal para que cada cliente descargue presupuestos. La primera versión filtra la lista visible por empresa, pero el equipo no ha documentado cómo se autoriza la descarga del archivo. La interfaz parece privada y queda una pregunta técnica sin resolver.

Antes de abrir el servicio, prepara dos empresas y cuentas ficticias. Define las operaciones permitidas, revisa el servidor y comprueba que cada recurso se entrega solo con la relación adecuada. Después repite la comprobación tras revocar una cuenta y documenta sus límites.

Este caso hipotético no describe una vulnerabilidad de SantuarioWeb ni una auditoría ejecutada. Ilustra por qué una aceptación debe cubrir el recurso real y la revocación. Una revisión completa necesita profesionales competentes y pruebas acordes con el alcance autorizado.

Cuando un asistente opere por una empresa

Mi hipótesis es que los portales necesitarán expresar mejor quién actúa, en nombre de quién y para qué operación si incorporan asistentes automáticos. Una identidad técnica válida no debería heredar sin criterio todo lo que puede hacer una persona administradora.

La apoyarían integraciones que solicitan acciones específicas y necesitan permisos limitados y trazabilidad. La debilitaría un portal únicamente documental, sin automatizaciones ni delegación. No es una razón para añadir agentes; es una condición a estudiar cuando exista esa necesidad.

Diseña el límite antes del escritorio

Enumera recursos, relaciones y operaciones antes de aprobar las pantallas del área privada. Comprueba el acceso permitido, el denegado y el revocado con datos ficticios. Un portal convincente necesita que su promesa de privacidad corresponda al comportamiento del servidor.

Para completar esta decisión, consulta Cómo definir permisos mínimos para editar la web.