La importancia de la gramática en IAM (AKA: Un permiso es un verbo)

 Image by Brett Jordan <https://unsplash.com/@brett_jordan> via <https://unsplash.com/photos/POMpXtcVYHo>

Existen dos decisiones aparentemente irrelevantes que tendemos a tomar muy a la ligera al crear permisos, lo cual destrozará nuestro modelo de autorización a largo plazo y lo hará totalmente inmanejable.

El primero es un poco más conocido: "Evitar permisos demasiado amplios" o "Hacer nuestros permisos tan específicos como sea posible". Abordaremos este concepto en detalle en posteriores artículos. 

Sin embargo, el alcance de este artículo es el segundo principio, que de primeras parece un poco más arbitrario y que, por lo general, genera bastante malestar entre los propietarios de las aplicaciones cuando lo señalamos. Se trata de "Definir los permisos como verbos" o "Nombrar los permisos correctamente". Los propietarios de aplicaciones normalmente encuentran que esta es una inquiteud exagerada. ¡Qué más dará el nombre de los permisos! ¿no?

Usemos un sencillo ejemplo simple para ilustrar los problemas que pueden surgir si no le prestamos a esto la atención debida.

Digamos que tenemos una aplicación CRM (Customer Relationship Management). En ella almacenamos y mantenemos toda la información de nuestra interacción con nuestros clientes, gran parte de la cual es confidencial. Por supuesto, creamos para ello un conjunto de permisos que nuestros empleados necesitan para obtener acceso a leer y modificar esta información.

Sin embargo, dado que dicha información sólo puede ser leída por los operadores de Atención al Cliente y modificada por los operadores senior, decidimos que nuestros permisos serán:

  • "Atención al Cliente básico"
  • "Atención al Cliente senior"

En realidad, estos no son permisos en absoluto. Al menos, no son permisos correctamente definidos. No definen las acciones que los usuarios pueden realizar con ellos. No especifican el qué, sino que van directamente al quién. Esto crea tres grandes problemas a largo plazo.

  1. Cuando un operador de Atención al Cliente vea este permiso, pensará "Tengo que pedir este permiso", pero no sabrá por qué ni para qué sirve. Pronto tendremos empleados que solicitan este permiso "por si acaso", incluso si los criterios para acceder al CRM cambian en el futuro. Después de todo, estos permisos se llaman "Atención al Cliente" (Nota: "por si acaso" es una muy mala idea desde la perspectiva de la seguridad y el cumplimiento normativo).
  2. A partir de este momento, cada vez que nuestra organización cree o compre una nueva aplicación para el departamento de Atención al Cliente (o un nuevo módulo para la aplicación CRM existente), los propietarios de la aplicación tendrán que decidir si crean un nuevo permiso específico para ella... o si reutilizan un permiso que, al fin y al cabo, se llama "Atención al Cliente básico". Y cuando digo "reutilizarlo", me refiero a aprovechar una asignación ya existente que, al menos en teoría, parece estar dirigida a la misma población que quiero autorizar. Entonces, ¿por qué no? La razón por la que es una muy mala idea es que eventualmente este permiso proporcionará acceso a tanta funcionalidad que será imposible administrarlo. Llegará un momento en que proporcione acceso a mucho más que el modo de "sólo-lectura" para nuestro CRM. En ese punto, cuando examinemos este permiso tan crítico, otorgado a todo nuestro departamento de Atención al Cliente y preguntemos "¿qué acceso otorga este permiso?" la respuesta que obtendremos será "nadie lo sabe". Y lo que es peor, cuando hablemos con el "dueño teórico" de este permiso para tratar de averiguarlo, su respuesta será algo así como: "Mira: yo solía ser el dueño de esto. Pero ha evolucionado tanto y ahora está dando acceso a tanto que no sé ni como empezar a investigar a qué da acceso, o a quién debería asignársele". Y esto es un gran problema.
  3. Por si esto no fuera suficiente, debemos entender (y este es el punto crítico) que quién debería tener acceso es, y siempre será, un criterio cambiante. Ahora es Atención al Cliente. Pero dentro de un año, recibimos una solicitud del equipo de marketing. Por motivos comerciales, necesitan acceso de sólo-lectura a la aplicación CRM. Su solicitud tiene sentido, no hay problema con eso. Pero ahora tenemos dos opciones:
    • Les damos acceso a nuestro permiso, que ya existe y que se llama "Atención al Cliente básico" (aunque el equipo de Marketing no es Atención al Cliente). He visto permisos de "Gerente" otorgados a personas que nada tienen que ver con la gerencia, simplemente porque necesitaban acceder a algunas de las herramientas que los gerentes utilizan. Llegados a este punto, este modelo de autorización contradice a nuestra solución de Recursos Humanos, lo cual es una muy mala idea. ¿A cuál de los dos hay que creer?
    • Creamos un nuevo permiso (que hace lo mismo que "Atención al Cliente básico") llamado "Equipo de Marketing básico". Ahora tenemos dos permisos que hacen exactamente lo mismo y, por supuesto, el nuevo permiso también está sujeto a los problemas descritos en los puntos 1. y 2. Además, aún tenemos que ir al código (o a la configuración) de la aplicación CRM para que este nuevo permiso también se utilice para proporcionar acceso de sólo-lectura al sistema. En este punto, dar acceso a un nuevo perfil que no estaba contemplado antes requiere un nuevo despliegue de la aplicación, lo cual ... efectivamente: es una muy mala idea.

Todos estos problemas podrían haberse evitado si tan sólo hubiéramos entendido inicialmente una sencilla idea: lo que hace un permiso rara vez debería cambiar. A quién se le otorga un permiso, sin embargo, puede cambiar de manera muy dinámica. Por lo tanto, es lógico que los permisos se definan en el contexto de sus propiedades más inmutables. Un permiso siempre debe definirse, crearse y nombrarse en función de lo que hace, no en función de quién creamos que debería obtenerlo.

Algunas personas cuestionarán que "Atención al Cliente básico" no es un permiso, sino un Rol y que, por lo tanto, el nombre está perfectamente elegido. Pero esto no es cierto. En un artículo futuro, discutiré la diferencia entre Permisos, Roles y Perfiles con más detalle, pero por ahora simplemente quedémonos con los problemas ya expuestos. Aunque los Roles sí se definen en función de a quién les será otorgados, no son más que meras formas de agrupar permisos. Constituyen una capa adicional que está por ecima de su modelo de permisos. Siempre deberíamos poder crear, reasignar y modificar Roles sobre la marcha, sin la necesidad de desplegar la aplicación en absoluto. Si la aplicación lo conoce, si requiere cambios de software para modificar o introducir nuevos "Roles"... entonces esos no son Roles, son permisos. Permisos con nombres incorrectos, además. Porque un permiso es un verbo.

Comentarios

Entradas populares de este blog

Cómo establecer un ancla de confianza (O: Incorporación digital para empleados remotos)

Entidades, Identidades y Cuentas de Usuario (O: Quién es quién en IAM)

No hay que preocuparse por los usuarios privilegiados (O: Controlando acciones, no personas)