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 prueba | Recurso de A | Recurso de B | Invitar usuarios en A |
|---|---|---|---|
| Operador de A | Lectura permitida | Denegado | Denegado |
| Administrador de A | Según política de A | Denegado | Permitido |
| Operador de B | Denegado | Lectura permitida | Denegado |
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.
Otras lecturas.
- Preparar una integración para una revisión de seguridad
- Revisión de dependencias: de la alerta al contexto
- Revocación de sesiones y cambios de privilegios