Saltar al contenido

Desarrollo seguro / Guía + matriz

Autorización en aplicaciones multiempresa

Una matriz de roles y recursos para discutir la separación entre organizaciones y preparar pruebas de regresión.

Redacción: Shark Offensive · Publicado: 15 de octubre de 2026 · Revisado: 15 de octubre de 2026 · 3 min

Separar identidad, organización y operación

Una identidad autenticada puede pertenecer a una organización, tener un rol y actuar sobre un recurso. Esas relaciones necesitan evaluarse juntas. Saber quién inició sesión no responde si puede descargar un documento concreto o administrar usuarios de otro cliente.

Antes de implementar la política, escribí las acciones permitidas. En un ejemplo ficticio, un operador consulta documentos de su organización y un administrador también invita usuarios. Ninguno debería actuar sobre recursos de otra organización.

Construir una matriz pequeña

La siguiente matriz es ilustrativa. Cada producto necesita sus propias reglas, especialmente cuando hay recursos compartidos o administradores que operan sobre varias organizaciones.

Identidad de pruebaRecurso de ARecurso de BInvitar usuarios en A
Operador de ALectura permitidaDenegadoDenegado
Administrador de ASegún política de ADenegadoPermitido
Operador de BDenegadoLectura permitidaDenegado

Prepará datos sintéticos para cada combinación. El resultado esperado tiene que incluir tanto los accesos permitidos como los denegados. Una corrección que bloquea todas las operaciones puede ocultar un problema a costa de romper la función.

Seguir cada acceso al recurso

Un documento puede aparecer en una vista individual, un listado, una búsqueda y una exportación. También puede tener una ruta de descarga diferente. Enumerar esos recorridos ayuda a identificar dónde se aplica la política y qué rutas quedan fuera de la comprobación.

El contexto de organización debe relacionarse con la identidad en el servidor. Si el cliente envía un identificador, el sistema necesita comprobar que esa identidad puede utilizarlo. El nombre de un campo o la ubicación del parámetro no constituyen una autorización.

Revisar cambios de rol y tareas diferidas

La autorización puede cambiar mientras existe una sesión. Conviene definir qué sucede al retirar permisos o desactivar una membresía. Si una exportación se procesa en segundo plano, también hace falta decidir qué contexto conserva y qué permiso se comprueba al descargar su resultado.

Estas decisiones merecen casos propios. Registrá identidad, organización, acción, recurso y resultado esperado. Así la prueba comunica la política, además de detectar una respuesta inesperada.

Preparar una evaluación

Para una evaluación de APIs, aportá el modelo de roles, cuentas de organizaciones distintas y recursos de prueba. Indicá las excepciones legítimas, como compartir un documento entre organizaciones, para que puedan evaluarse con su propio contexto.

La muestra de informe muestra cómo documentar una falla de separación con evidencia sintética y una recomendación sobre el control del servidor.

Referencias

La guía de autorización de OWASP desarrolla principios de control de acceso. OWASP API Security reúne categorías relevantes para la evaluación de APIs.

Los ejemplos describen sistemas ficticios y comportamientos a revisar. Una evaluación se realiza sobre activos y condiciones autorizados.

Otras lecturas.

Volver a los recursos