Entender el control de acceso: autenticación, autorización y gestión de recursos

El control de acceso es uno de esos temas que parecen obvios hasta que se analizan de cerca. Además, año tras año, es la categoría número uno del OWASP Top 10 (Broken Access Control), y con diferencia la debilidad más habitual que observamos, tanto en el sector como en nuestros propios análisis. La buena noticia es que, una vez que se tienen presentes las preguntas correctas, el tema se vuelve mucho más sencillo.

Entonces, ¿qué es exactamente el control de acceso?

El control de acceso es lo que determina quién puede hacer qué, sobre qué recurso. Cuando una aplicación recibe una solicitud, debe responder a tres preguntas, y las tres importan.

1. ¿Sé quién es el usuario? (autenticación)

Este es el paso de identidad: ¿es el usuario realmente quien dice ser? Las contraseñas, la MFA y el SSO responden todos a esta primera pregunta.

2. ¿Está este usuario autorizado a realizar esta acción? (autorización)

Saber quién es el usuario no revela nada sobre lo que se le permite hacer. Un usuario autenticado no es necesariamente un usuario autorizado para eliminar, editar o administrar.

3. ¿Tiene derecho a este recurso concreto? (autorización a nivel de objeto)

Esta es la pregunta que más se suele olvidar. Tener derecho a ver “una” entrada no significa tener derecho a ver “todas” las entradas. Cuando falta esta comprobación, lo denominamos IDOR (Insecure Direct Object Reference, referencia directa a objetos insegura): basta con cambiar un identificador en la solicitud para acceder a los datos de otra persona.

Para recordar: basta con olvidar una sola de estas tres preguntas para crear una vulnerabilidad. Las tres forman un todo.

La pregunta que se olvida: ¿dónde se realiza la comprobación?

No basta con responder correctamente a las tres preguntas. También hay que preguntarse dónde se aplican esas comprobaciones. Y es precisamente ahí donde se marca la diferencia entre una medida de seguridad real y una simple convención de interfaz.

Lado del cliente

Los controles del lado del cliente los aplica la interfaz: un botón “Eliminar” que se oculta, una opción en gris, un menú que no aparece. Esto es útil y perfectamente normal. Es lo que hace que una aplicación resulte agradable de usar y aleja a los usuarios de opciones que, en cualquier caso, serían rechazadas. Pero no es lo que impide la acción: cuando el control de acceso se hace correctamente, el servidor rechaza la operación independientemente de lo que muestre la interfaz.

Estos controles residen del lado del usuario, y cualquiera que manipule las solicitudes directamente puede eludirlos, ya que la interfaz es solo una puerta más entre otras para llegar a los datos.

Lado del servidor

Los controles del lado del servidor los aplica la propia aplicación, allí donde residen los datos. No dependen de la interfaz utilizada y no se pueden eludir manipulando una solicitud.

Esta capa, y solo esta capa, es lo que realmente protege los datos confidenciales: verlos, editarlos, eliminarlos, revelar una contraseña, acceder a los adjuntos, etc.

Una comprobación del lado del cliente es una convención de experiencia de usuario, no una medida de seguridad. La regla es sencilla: cualquier permiso que proteja datos confidenciales o un flujo crítico debe aplicarse en el servidor. Una comprobación del lado del cliente puede acompañarla, pero nunca sustituirla.

Qué significa esto en la práctica para sus datos

Tomemos el ejemplo de Remote Desktop Manager (RDM), nuestra aplicación de escritorio para gestionar conexiones remotas y credenciales. RDM ofrece una experiencia completa: permisos, roles, opciones que se muestran u ocultan según el usuario. Pero, ¿dónde se aplican esos permisos realmente? La respuesta depende por completo de la arquitectura del espacio de trabajo al que se conecta.

• Un espacio de trabajo de SQL Server (conexión directa a la base de datos). En este caso, no hay ningún servidor de aplicaciones entre RDM y la base de datos. RDM se comunica directamente con SQL Server. Los permisos existen, pero los aplica el cliente. Es decir, residen por completo en el lado del cliente. La capa del lado del servidor, la que resiste la manipulación directa, sencillamente no está presente.
• Un espacio de trabajo recomendado, respaldado por un servidor de aplicaciones. Existe en dos variantes: Devolutions Server (DVLS), el espacio de trabajo autoalojado que se implementa en su propia infraestructura, y Devolutions Cloud, el espacio de trabajo totalmente gestionado y alojado en la nube. En ambos casos, RDM sigue siendo el cliente, pero es el servidor el que valida cada acceso: quién es usted, qué se le permite hacer y sobre qué recurso concreto. Las tres preguntas encuentran su respuesta donde realmente importa, en el servidor.

No se trata de buenas intenciones ni de una configuración cuidadosa. Es una cuestión de arquitectura. Sin un servidor de aplicaciones, no existe un lugar físico donde aplicar los controles del lado del servidor. Esta es la razón fundamental por la que recomendamos combinar RDM con un Devolutions Password Manager, no por preferencia de producto, sino porque la arquitectura lo exige.

En resumen

• Un buen control de acceso responde a tres preguntas: quién (autenticación), qué (autorización) y sobre qué recurso (autorización a nivel de objeto).
• Una comprobación del lado del cliente mejora la experiencia, pero no protege nada por sí sola, ya que se puede eludir.
• Solo una comprobación del lado del servidor protege realmente los datos confidenciales.
• Para que exista esa capa del lado del servidor, necesita un Devolutions Password Manager detrás de RDM: Devolutions Server (DVLS) si desea autoalojarlo, o Devolutions Cloud si prefiere un servicio totalmente gestionado.

Si RDM se conecta actualmente de forma directa a una base de datos SQL Server, vale la pena preguntarse: ¿dónde se aplican realmente mis controles de acceso? La arquitectura, no la configuración, le dará la respuesta honesta. Puede explorar los espacios de trabajo disponibles para ver cuál se ajusta a su entorno.

El coste rara vez es el obstáculo que se espera: tanto Devolutions Server como Devolutions Cloud ofrecen una opción gratuita para empezar. Usar Devolutions Server como backend solo requiere una licencia activa de Remote Desktop Manager Enterprise, y dado que conectar RDM a una base de datos SQL Server ya requiere esa misma licencia Enterprise, es muy probable que ya disponga de todo lo necesario para hacer el cambio. (Acceder al espacio de trabajo desde un navegador web, sin RDM, utiliza una licencia de acceso de cliente independiente).