Autorización y permisos: mejores prácticas que evitan el acceso no autorizado

La mayoría de la gente confunde autenticación con autorización, y esta confusión resulta costosa. La autenticación consiste en demostrar quién es usted, inicio de sesión, contraseña, token y datos biométricos. Autorizar es decidir qué es lo que usted, ya identificado, tiene derecho a hacer. Estos son problemas diferentes, y el segundo es donde residen la mayoría de las filtraciones internas y el fraude.

Es común ver sistemas con inicio de sesión impecable y autorización laxa. La puerta de entrada tiene cerradura biométrica, pero una vez dentro, cualquiera puede abrir cualquier cajón. El atacante no necesita romper su autenticación si, después de iniciar sesión con una cuenta normal, puede acceder a datos que no debería.

Este texto reúne los pasos esenciales y las mejores prácticas de autorización. El objetivo es práctico: garantizar que cada usuario, sistema o servicio acceda exactamente a lo que necesita, ni más ni menos.

El principio que sustenta todo: privilegio mínimo

Si solo tomas una idea de este texto, toma esta: darle a cada usuario el acceso mínimo necesario para hacer su trabajo, y nada más. Es el principio de privilegio mínimo y resuelve, en la práctica, la mayoría de los problemas de autorización.

La tentación opuesta es fuerte. Es más fácil dar un acceso amplio "para no detener a nadie" y afrontar las consecuencias más tarde. Pero cada permiso adicional es una puerta más. Cuando una cuenta se ve comprometida, el daño es proporcional a lo que esa cuenta podría hacer. Las cuentas con demasiado poder convierten un pequeño incidente en una catástrofe.

Un privilegio menor no es desconfiar de la gente. Es reconocer que las cuentas están comprometidas, que se cometen errores y que el daño debe contenerse mediante el diseño.

Paso 1: Modelar roles antes de distribuir permisos

La distribución de permisos usuario por usuario no escala y se vuelve un desastre en poco tiempo. La práctica madura es organizar el acceso por roles, el modelo conocido como RBAC (control de acceso basado en roles).

En lugar de decir "John puede ver informes financieros", define el rol de "analista financiero" con un conjunto de permisos y asigna ese rol a John. Cuando John se va y Mary se une, simplemente intercambias quién ocupa el puesto. Los permisos se describen en un solo lugar, auditables y consistentes.

Para escenarios más complejos, existe el control basado en atributos (ABAC), donde la decisión considera el contexto, el tiempo, la ubicación y la sensibilidad de los datos. Pero empieza de forma sencilla. Un RBAC bien hecho resuelve la inmensa mayoría de los casos, y la complejidad prematura aquí solo genera errores.

Paso 2: Centralizar la decisión de autorización

Un error arquitectónico común es dispersar las reglas de permisos por todo el código, un "si" aquí, una marca allá. Con el tiempo, nadie sabe con certeza quién puede hacer qué y las reglas difieren entre las partes del sistema.

Una buena práctica es tratar la autorización como una responsabilidad central, con un punto claro donde se toman las decisiones. No importa si es una biblioteca, un servicio o un módulo, lo importante es que la pregunta "¿puede este usuario hacer esto?" ser respondida de manera consistente, en un lugar que pueda ser auditado y modificado.

Esto también facilita la vida a la hora de demostrar el cumplimiento. Cuando un auditor, o la propia LGPD](/post/lgpd-startups-compliance-protecao-dados), en el caso de datos personales, pregunta quién tiene acceso a qué, se puede responder mirando en un solo lugar, no buscando en todo el código.

Paso 3: nunca te fíes sólo de lo que dice el cliente

He aquí una de las averías más peligrosas y comunes. La interfaz oculta un botón que el usuario no debería ver y el equipo considera que el problema está resuelto. No lo es. Ocultar el botón es experiencia, no seguridad.

La autorización debe verificarse en el backend, en cada solicitud, en todo momento. Un atacante no usa su interfaz, llama directamente a la API. Si la única barrera es visual, no hay barrera. La regla es simple e innegociable: el cliente puede sugerir, el servidor decide.

Lo mismo ocurre con los identificadores. Si el sistema permite al usuario acceder a un recurso con sólo cambiar el número en la URL, sin comprobar si ese recurso le pertenece, se tiene una de las vulnerabilidades más explotadas que existen, el acceso indebido a un objeto por referencia directa, catalogada desde hace años por OWASP. Comprueba la posesión, no sólo la existencia.

Paso 4: Hacer que el acceso sea revocable y auditable

El acceso concedido debe poder retirarse y rápidamente. Cuando alguien abandona la organización, cambia de rol o su cuenta está comprometida, debe cortar el acceso inmediatamente, no en el siguiente sprint.

Esto supone dos cosas. Primero, saber quién tiene acceso a qué, lo que se remonta al punto de centralizar y modelar. En segundo lugar, registre quién accedió a qué y cuándo. El registro de acceso no previene el problema, pero es lo que le permite investigar, responder y aprender después de un incidente. Un sistema sin seguimiento de auditoría es un sistema que no sabe qué le pasó.

Reflexión crítica: la acumulación silenciosa de privilegios

Hay un problema que crece sin que nadie se dé cuenta: la acumulación de permisos en el tiempo. La persona cambia de área, obtiene nuevos accesos y conserva los antiguos. Años más tarde, acumula permisos de tres roles que alguna vez ocupó. Nadie lo revisó, porque revisar es trabajo y no te da trofeo.

Esta acumulación es una bomba de tiempo. Cuando una de estas cuentas se ve comprometida, el acceso es desproporcionado. La defensa es incómoda pero necesaria: revisión periódica del acceso. Mire de vez en cuando y pregunte "¿esta persona todavía necesita esto?" Casi siempre la respuesta, para algunos permisos, es no.

El otro desafío es cultural. La autorización restrictiva genera fricciones y las fricciones generan quejas. El usuario quiere un acceso amplio, el administrador quiere agilidad y la seguridad se convierte en el villano que detiene a todo el mundo. Mantener el menor privilegio requiere convicción de liderazgo y la claridad de que la fricción de hoy es más barata que la filtración de mañana.

Lo que queda

La autorización bien hecha es invisible cuando funciona y devastadora cuando falla. No aparece en una demostración de producto, no impresiona en una reunión y, sin embargo, es una de las decisiones más importantes de cualquier sistema que trate con datos confidenciales.

Los pasos son claros: privilegios mínimos como principio, roles en lugar de permisos flexibles, toma de decisiones centralizada, verificación del lado del servidor y acceso revocable y auditable. Ninguno de ellos es sofisticado. A menudo todos son ignorados.

Si su organización maneja datos confidenciales y no está seguro de quién puede acceder a qué, ahora es un buen momento para revisarlo. En el blog existen otros textos sobre seguridad, control de acceso y cumplimiento que profundizan en el tema.