← Lumbre

Desarrollo de Software con IA Roles y permisos: admin no es un botón, es una matriz

Portada de Roles y permisos: admin no es un botón, es una matriz

Roles y permisos: admin no es un botón, es una matriz

✦ Que el admin pueda con todo no es un diseño: es una invitación al desastre · Desarrollo de Software con IA · en 9 minutos

Roadwise Consulting

Contenido modificado tras su publicación

Objetivo: Construir una matriz rol-permiso-acción y exigírsela a la IA como criterio de aceptación.

9 min Desarrollo de Software con IA 15–99 años
Modo PPTX
Más
Roles y permisos: admin no es un botón, es una matriz

Herramientas de la lección

Sorpréndeme

Sobre este contenido

Ir a

Volver a Módulo 10 · Autenticación y usuarios Cursos Explorar Mi cuenta Salir del modo estudio

El poder se diseña en una tabla, no en un botón

Cuando solo hay «usuario» y «admin», el admin puede con todo y cualquier error de uno es un desastre total. La forma profesional es una matriz de roles y permisos: filas = roles, columnas = acciones, y en cada casilla decides sí o no. Esa matriz, y no una sensación, es lo que le pides a la IA que implemente.

Una matriz para un gestor de tareas

Cada casilla es una decisión tuya. La IA implementa EXACTAMENTE esta tabla, ni una fila más de poder.
RolVer tareaCrearEditar la suyaEditar la ajenaBorrarVer a todos
InvitadoSí (asignadas)NoNoNoNoNo
MiembroSí (proyecto)SíSíNoSolo la suyaNo
ManagerSíSíSíSíSíSí
AdminSíSíSíSíSíSí (y gestiona roles)

Tres principios que evitan el abuso de poder

La matriz hace visible dónde puede colarse un abuso

  • Principios
    • Mínima autoridad
      • Cada rol, solo lo que necesita
    • En el servidor
      • El permiso se comprueba en el backend
    • Verificable
      • Cada casilla es un criterio de prueba

Prompt con la matriz

La matriz como criterio de aceptación

texto
Implementa control por roles con esta matriz EXACTA (ningun rol obtiene permiso extra sin que lo diga):\n- Invitado: solo VER tareas asignadas.\n- Miembro: ver/crear/editar SUS tareas; borrar solo las suyas.\n- Manager: ademas editar/ver tareas ajenas y del proyecto.\n- Admin: todo lo anterior + gestionar roles.\n\nReglas:\n- la comprobacion se hace en el SERVIDOR en cada endpoint, leyendo el rol del token\n- si un endpoint pide permiso que el rol no tiene, responde 403\n- al final, generame la lista de endpoints y que rol necesita cada uno para que yo la audite.
Le entregas el poder máximo permitido por rol y le pides que te devuelva la lista para auditarla casilla por casilla.

Prueba

Un «Invitado» logra borrar una tarea llamando directo al endpoint DELETE aunque su rol no lo permite. ¿Qué falló en la implementación?

Dar al rol «admin» el mayor número posible de permisos es una buena práctica.

Detecta el diseño de permisos defectuoso

Revisas una matriz de roles que propuso una IA. Señala la decisión que rompe el principio de mínima autoridad:

Marca la línea o las líneas con error y pulsa Comprobar.

Dibuja la matriz de roles y permisos de tu proyecto (3-4 roles, tus acciones reales). Conviértela en criterio de aceptación y pide a la IA que la aplique en el servidor y te la devuelva para auditar.

Si no escribiste la matriz, la IA decidirá quién puede hacer qué… y no consultó contigo.

Tu texto se guarda sólo en este dispositivo.

Las respuestas y tu progreso se guardan sólo en este dispositivo. Contenido firmado por su autoría mediante Lumbre.
Más sobre esta lección

Comentarios

Inicia sesión para comentar.

Todavía no hay comentarios. Sé la primera persona en opinar.