Autorización: decidir sobre cada objeto

Un agente puede leer un pedido pero no reembolsarlo. Un cliente puede cambiar su dirección pero no la de otra persona. Estar conectado no expresa esas reglas.

Autorización de objetos: Decidir si un sujeto puede realizar una acción concreta sobre un recurso concreto.

Escribe la regla con claridad

La autorización relaciona un sujeto, una acción, un recurso y un contexto. Los roles agrupan capacidades por función. Las políticas por atributos pueden considerar propietario, organización, sensibilidad o estado del dispositivo. Las relaciones pueden representar pertenencia y delegación. Son herramientas de diseño, no una clasificación automática de seguridad.

Una regla como “un miembro actual del proyecto puede leer sus documentos no restringidos” obliga a comprobar cada dato con información fiable.

Los identificadores localizan; no autorizan

Un identificador impredecible reduce algunos descubrimientos accidentales, pero conocerlo no equivale a tener permiso. El servidor debe comprobar el objeto solicitado, no solo el menú o la ruta que llevó hasta él.

Una aplicación con varias organizaciones necesita separar sus datos también en consultas, tareas en segundo plano, exportaciones, cachés y búsquedas. Un control correcto en la página principal no protege todas las demás vías.

Deniega por defecto y prueba las relaciones

Define permisos explícitos sobre una base de denegación por defecto. Centraliza las decisiones cuando ayude, pero aplícalas en cada solicitud pertinente. No aceptes roles ni organizaciones enviados por el cliente sin validarlos.

Construye una matriz con propietario, compañero, persona ajena y usuario suspendido; luego cruza leer, editar, exportar y borrar. Prueba resultados permitidos y denegados con registros ficticios. Los cambios de pertenencia deben tener un efecto definido sobre sesiones y cachés.

Resuelve una política pequeña antes de revisar una aplicación grande

Imagina un archivo vecinal ficticio. Cada foto pertenece a un álbum. Su propietario activo puede leerlo, editarlo y exportarlo. Una persona invitada actualmente puede leer, pero no editar ni exportar. Retirarla termina el acceso futuro mediante el servicio; no borra copias guardadas fuera. Los álbumes son privados salvo que un proceso de publicación separado cambie expresamente ese estado.

Estas filas describen la política de este archivo, no reglas universales. Si el club quiere permitir descargas individuales a las personas invitadas, debe definir esa acción aparte. Llamar “acceso” a todo ocultaría la diferencia entre leer una descripción y exportar un álbum completo.

Identifica quién conoce cada hecho

El navegador puede indicar el álbum y la acción deseados. El servicio de confianza establece la cuenta mediante una sesión aceptada, consulta la propiedad almacenada y obtiene la pertenencia actual de quien administra las invitaciones. Una etiqueta “propietario” enviada por el cliente es una afirmación de la solicitud, no evidencia suficiente de esa relación.

La revisión sigue la decisión hasta el componente que entrega datos o confirma un cambio. Una función compartida de política solo ayuda si todas las vías pertinentes le pasan sujeto, acción y recurso correctos. Un trabajador de exportación también necesita una política definida cuando la pertenencia cambia entre programación y entrega. Quien creó el documento puede ser diferente de quien solicitó el trabajo.

PrediceBo solicita una exportación como propietario, pero pasa a lector antes de recibirla. El requisito exige permiso actual de propietario al entregar. ¿Basta la aprobación anterior?

No. Según este requisito, la entrega necesita permiso actual y debe retener el archivo tras el cambio. Otra política podría conservar deliberadamente un trabajo aprobado, pero esa excepción exigiría un requisito explícito y aceptar sus consecuencias de divulgación. Entregar más rápido no demuestra que se cumplió el requisito.

Revisa la denegación con el mismo cuidado que el éxito

Si el servicio de pertenencia no responde, la aplicación no puede interpretar esa ausencia de evidencia como una invitación vigente. Una exportación protegida puede quedar pendiente o denegarse con un mensaje útil para reintentar. La elección afecta a la disponibilidad, pero no debe ampliar permisos silenciosamente. Registra una referencia de operación no secreta y el motivo para que soporte explique el resultado sin guardar las fotos.

La evidencia de cada fila debe mostrar decisión y consecuencia: las lecturas denegadas no devuelven contenido protegido y las ediciones denegadas no alteran la descripción almacenada. Incluye un ejemplo permitido para distinguir una política funcional de una función que rechaza a todo el mundo. Revisa las respuestas en caché con los mismos supuestos sobre identidad y recurso; compartir una entrada no crea un permiso compartido.

EXPLORA EL CONCEPTO

Mismo documento, diferentes decisiones

El documento pertenece al Proyecto Azul. Compara tres situaciones.

Un miembro actual de Azul lo lee

Solo se permite si su pertenencia y la clasificación del documento autorizan la lectura.

Un miembro de Azul lo borra

Leer no concede permiso para borrar. La acción necesita su propia decisión.

Un miembro de Verde lo lee

Una cuenta válida de otro proyecto no basta. La relación con el recurso sigue siendo necesaria.

Modelo simplificado para aprender. No se conecta a sistemas ni usa datos reales.

Llévalo a una decisión

Una matriz convierte requisitos vagos en resultados comprobables. Incluye a una persona autenticada que no pertenece al proyecto.