Autorización y Permisos en Aplicaciones: Control de Acceso Seguro

La autorización define lo que puede hacer un usuario autenticado. Mientras que la autenticación confirma la identidad, la autorización controla el acceso a recursos y acciones. Esta guía presenta plantillas, implementaciones y mejores prácticas para crear sistemas de permisos sólidos.

Autenticación versus autorización

Autenticación

Respuesta: "¿Quién eres?" Verifica la identidad a través de credenciales.

Autorización

Respuesta: "¿Qué puedes hacer?". Determina los permisos después de confirmar la identidad.

Ejemplo práctico

El usuario inicia sesión (autenticación). El sistema comprueba si puede acceder al panel de administración (autorización).

Por qué es importante la autorización

Sin un control de acceso adecuado, cualquier usuario autenticado puede acceder a cualquier recurso. Se exponen datos confidenciales y se ponen a disposición acciones destructivas. La autorización protege los datos y las operaciones críticas.

Modelos de control de acceso

ACL (Lista de control de acceso)

Lista que define quién puede acceder a cada recurso. Simple, pero no se adapta bien a sistemas complejos.

RBAC (control de acceso basado en roles)

Permisos asignados a roles, roles asignados a usuarios. Estructura jerárquica. Modelo más común.

ABAC (Control de acceso basado en atributos)

Decisiones basadas en atributos: usuario, recurso, entorno. Flexible pero complejo.

ReBAC (Control de acceso basado en relaciones)

Basado en relaciones entre entidades. "Puedes editarlo si lo posees". Utilizado por Zanzíbar (Google).

RBAC en detalles

Componentes

Usuarios: Personas o sistemas que acceden.
Roles: Conjuntos de permisos (Administrador, Editor, Visor).
Permisos: Acciones permitidas (crear, leer, actualizar, eliminar).
Características: Objetos protegidos (publicaciones, usuarios, configuraciones).

Jerarquía de roles

Los roles pueden heredar de otros. El administrador hereda del Editor, que hereda del Visor. Reduce la duplicación.

Ejemplo de estructura

Desplazarse	Permisos	Alcance
Administrador	crear, leer, actualizar, eliminar	Todos los recursos
Redactor	crear, leer, actualizar	Contenido
Visor	leer	Contenido público

Implementación de RBAC

Base de datos

Tablas de usuarios, roles, permisos y relaciones (user_roles, role_permissions).

Middleware de verificación

Antes de actuar, el middleware comprueba si el usuario ha requerido el permiso.

Decoradores/Guardias

En marcos modernos, anotaciones que protegen rutas o métodos.

Almacenamiento en caché de permisos

Evite consultar al banco para cada solicitud. Permisos de usuario en caché en Token o Redis.

ABAC: Flexibilidad avanzada

Cuándo utilizar

Cuando RBAC no es lo suficientemente expresivo. Las reglas dependen del contexto dinámico.

Ejemplos de políticas

Puedes editar si eres el autor del documento.
Puedes acceder a él si estás en el mismo departamento.
Puedes aprobar si el monto es menor que tu límite.

###XACML

Estándar para expresar políticas ABAC. Basado en XML, utilizado en entornos empresariales.

Permisos de nivel de recursos

Seguridad a nivel de fila

Control por registro. El usuario solo ve sus propios datos. PostgreSQL es compatible de forma nativa.

Seguridad a nivel de columna

Control de campo. Ciertos campos solo son visibles para ciertos roles.

Multi-inquilino

Aislamiento entre inquilinos. Cada organización sólo accede a sus datos.

Permisos del sistema operativo

iOS

El acceso a la cámara, la ubicación y las fotografías requiere un permiso explícito del usuario. Info.plist define descripciones.

###Androide

Permisos declarados en el Manifiesto. Los permisos peligrosos requieren consentimiento en tiempo de ejecución.

Buenas prácticas

Realizar el pedido en el momento de su uso, no por adelantado.
Explique por qué lo necesita.
Corre con gracia si se te niega.

Fichas y Reclamaciones

Reclamaciones de JWT

El token puede contener reclamaciones de permiso. El servidor valida sin consultar al banco.

Ámbitos en OAuth

Definen a qué recursos puede acceder el token. leer: usuarios, escribir: publicaciones.

Cuidado

Los tokens grandes afectan el rendimiento. Equilibrio entre reclamaciones en línea y consultas.

Autorización en API

Verificación por punto final

Cada punto final verifica un permiso específico antes de ejecutarse.

Servidores de recursos

El servidor API valida tokens y autoriza según alcances y reclamos.

Punto de decisión de políticas (PDP)

Servicio centralizado que decide las autorizaciones. El Agente de Política Abierta (OPA) es un ejemplo.

Patrones de implementación

Denegar por defecto

Denegar el acceso a menos que se permita explícitamente. A prueba de fallos.

Mínimo privilegio

Subvención mínima necesaria. El usuario solo puede lo que necesita.

Separación de deberes

Las tareas críticas requieren varias personas. Nadie hace todo solo.

Auditoría y registro

Registrar decisiones

Registro de quién intentó acceder a qué y si se permitió o denegó.

Detección de anomalías

Patrones sospechosos: muchas denegaciones, acceso fuera de horario, escalada de privilegios.

Cumplimiento

Las regulaciones requieren una pista de auditoría. RGPD, SOX, HIPAA.

Errores comunes

Verificación solo en la interfaz

El backend siempre debe comprobarlo. La interfaz es manipulable.

Roles codificados

Dificulta la evolución. Utilice una configuración flexible.

Permisos excesivos

Por conveniencia, dé más acceso del necesario. Principio de privilegio mínimo.

Falta de pruebas

Los permisos mal probados crean lagunas. Escenarios de acceso a pruebas.

Herramientas y bibliotecas

Cabina

Biblioteca de autorizaciones con soporte para múltiples modelos (RBAC, ABAC, ACL).

Agente de políticas abiertas (OPA)

Motor de políticas. Decisiones de autorización como código.

Autenticación0 FGA

Autorización detallada. Modelo similar al Zanzíbar de Google.

Ory Keto

Implementación de código abierto inspirada en Zanzíbar.

Multiinquilino y autorización

Aislamiento

Los inquilinos no acceden a los datos de los demás. Comprobando todas las consultas.

Roles por inquilino

El usuario puede tener diferentes roles en diferentes organizaciones.

Súper administrador

Acceso entre inquilinos para operaciones de plataforma. Úselo con extrema precaución.

Conclusión

La autorización bien implementada protege los datos y garantiza que los usuarios solo hagan lo que se supone que deben hacer. Elija el modelo adecuado (RBAC para la mayoría), implemente con denegación de forma predeterminada, pruebe minuciosamente y audite el acceso. La seguridad es un proceso continuo, no una configuración única.

##Preguntas frecuentes

1) ¿Es suficiente RBAC para la mayoría de los casos? Sí. RBAC sirve bien para la mayoría de las aplicaciones. ABAC es para escenarios más complejos.

2) ¿Dónde almacenar los permisos? Base de datos para fuente de verdad. Caché (reclamaciones JWT, Redis) para rendimiento.

3) ¿Cómo lidiar con el permiso denegado? Devuelve 403 Prohibido con mensaje genérico. No revele detalles de la política.

4) ¿Necesito un servicio de autorización independiente? Para sistemas grandes, puede que valga la pena. Para aplicaciones más pequeñas, la biblioteca integrada es suficiente.

5) ¿Cómo probar la autorización? Pruebas automatizadas que verifican el acceso permitido y denegado por rol/permiso.