¿Esta aplicación autoalojada otorga a las personas solo el acceso que necesitan? Lista de verificación para evaluar RBAC
Utilice esta lista de verificación práctica para evaluar roles, permisos, límites de administración, acceso a API y procesos del ciclo de vida de los usuarios antes de trasladar usuarios y datos a una aplicación autoalojada.
Por qué el diseño de control de acceso debe abordarse antes del despliegue
Una migración puede hacer que una aplicación esté disponible técnicamente y, aun así, dejar a la organización con un modelo poco adecuado para la forma en que realmente se divide el trabajo. Si finanzas, ventas, operaciones, atención al cliente y contratistas necesitan realizar acciones distintas sobre registros diferentes, valide ese modelo antes de importar datos de producción o invitar a usuarios.
El control de acceso basado en roles (RBAC) se basa en identificar las operaciones que requieren determinados puestos, asignar personas a roles y asignar privilegios a esos roles. Por tanto, la pregunta importante para quien evalúa una compra no es «¿Dice que tiene RBAC?», sino «¿Podemos expresar y operar en esta aplicación las decisiones de acceso que necesitamos?».
Considere el principio de mínimo privilegio como un criterio de diseño: cada persona debe recibir los privilegios mínimos necesarios para su trabajo. Personas con un nivel de antigüedad similar pueden seguir requiriendo accesos muy distintos porque sus responsabilidades difieren. OWASP también recomienda una autorización con denegación predeterminada, lo que significa que el acceso debe permitirse explícitamente en lugar de darse por supuesto.
- Evalúe los permisos durante la selección, no después de que un despliegue en producción haya dificultado revertir un acceso amplio.
- No equipare el uso de la palabra «RBAC» por parte de una aplicación con capacidades avanzadas. NIST distingue la asignación básica de roles de las jerarquías de roles y funciones de separación de funciones opcionales.
- Convierta el ajuste del modelo de acceso en un criterio de aprobación para la migración, junto con la importación de datos, las integraciones, la autenticación y los requisitos de copias de seguridad.
Empiece por los grupos de usuarios reales y las acciones que debe realizar cada grupo
Empiece por el trabajo, no por los nombres de roles predeterminados de la aplicación. Entreviste a las personas responsables de cada proceso de negocio y registre el conjunto más reducido y práctico de acciones que deben completar. Incluya el trabajo habitual, las excepciones, las aprobaciones, las exportaciones, la eliminación, la administración de usuarios y los cambios de configuración.
Evite etiquetas de roles que oculten privilegios amplios. «Gerente», «editor» o «miembro» no es un requisito de permisos. Un requisito útil establece un verbo, un objeto y un alcance; por ejemplo: «crear registros en el espacio de trabajo asignado», «ver proyectos propiedad del cliente» o «exportar únicamente informes agregados».
Incluya requisitos negativos. Son las acciones o los datos a los que un grupo no debe poder acceder, modificar, divulgar ni aprobar. Con frecuencia revelan carencias que una lista de acciones permitidas no detecta.
- Enumere las poblaciones de usuarios: empleados, responsables de equipo, directivos, personal temporal, contratistas, clientes, socios, auditores y administradores técnicos.
- Para cada población, enumere las acciones: ver, crear, editar, comentar, asignar, aprobar, eliminar, exportar, compartir, configurar y administrar.
- Defina el alcance de cada acción: registros propios, registros asignados, registros del equipo, un espacio de trabajo, una cuenta de cliente, todos los registros o ningún registro.
- Identifique los campos sensibles y las acciones de alto impacto por separado del acceso a contenido ordinario.
Identifique el modelo de acceso de la aplicación: roles, grupos, objetos y límites
Pida al proveedor o a la documentación del proyecto que muestre el modelo de acceso exacto de la versión que planea desplegar. Registre qué está documentado, qué se puede demostrar en una instancia de prueba y qué sigue siendo incierto. No cubra las lagunas con supuestos basados en otra aplicación o en una etiqueta de rol conocida.
Como mínimo, determine si los permisos se asignan mediante roles fijos, roles personalizados, grupos, concesiones directas a usuarios o una combinación de ellos. A continuación, determine el alcance en el que se aplican esos permisos: toda la instancia, una organización, un equipo, un espacio de trabajo, un proyecto, una colección, un registro o un campo.
Un límite de espacio de trabajo puede ser útil solo si realmente restringe el acceso de las maneras que necesita. Pruebe si las personas pueden buscar entre límites, seguir enlaces a otros objetos, recibir notificaciones con información restringida, exportar datos que cruzan límites u obtener acceso a través de membresías heredadas.
- ¿Puede crear un rol que se ajuste a cada requisito sin asignar privilegios no relacionados?
- ¿Los roles son globales o pueden variar por espacio de trabajo, proyecto, cliente u otro límite de negocio?
- ¿Se pueden establecer permisos a nivel de objeto o de campo cuando su riesgo lo requiera?
- ¿Se admiten jerarquías de roles y, de ser así, los privilegios heredados siguen siendo comprensibles y revisables?
- ¿Las concesiones directas pueden eludir el modelo de roles habitual y cómo se encontrarán esas excepciones durante una revisión?
- ¿Qué ocurre con el acceso cuando se mueve o copia un objeto, espacio de trabajo o usuario?
Pruebe la separación entre la administración y el acceso a datos empresariales sensibles
La administración operativa y el acceso a datos empresariales son responsabilidades diferentes. Un equipo puede necesitar que alguien gestione usuarios, enrutamiento, copias de seguridad o disponibilidad de la aplicación sin consultar habitualmente información confidencial de clientes, empleados o finanzas. Determine si la aplicación admite esa distinción, en lugar de suponer que un administrador puede limitarse de forma adecuada.
La separación de funciones aborda si una persona cuenta con privilegios suficientes para utilizar indebidamente un sistema por sí sola. Puede implementarse mediante roles incompatibles asignados por adelantado o mediante controles que restringen una acción incompatible en el momento de acceso. La necesidad de cualquiera de los dos enfoques depende de su proceso y su riesgo, pero la cuestión debe plantearse explícitamente para las acciones de alto impacto.
También trace el límite de la infraestructura. Docker advierte de que el control de un daemon de Docker es altamente privilegiado y puede proporcionar acceso root al host. Del mismo modo, las interfaces administrativas de apoyo requieren revisión; Traefik señala que una API o un panel de control de producción pueden exponer elementos de configuración, incluidos datos sensibles, y deben protegerse con autenticación y autorización.
- ¿Puede un administrador de usuarios crear cuentas y restablecer accesos sin leer registros empresariales ordinarios?
- ¿Puede un administrador de contenido o de espacio de trabajo gestionar membresías sin recibir privilegios ilimitados de exportación o configuración?
- ¿Quién puede cambiar roles, crear cuentas privilegiadas, modificar ajustes de autenticación, acceder a copias de seguridad o gestionar el despliegue?
- ¿Las acciones sensibles se registran de una forma que la organización pueda revisar?
- Para operaciones de alto riesgo, ¿deben requerirse dos personas distintas para la solicitud y la aprobación?
Compruebe los colaboradores externos, contratistas y usuarios clientes
Los usuarios externos suelen revelar la diferencia entre un rol general de colaboración y un modelo seguro de acceso de clientes. Su acceso puede necesitar una fecha de expiración próxima, un conjunto limitado de proyectos, ninguna visibilidad del directorio, ningún derecho de exportación y ninguna capacidad para invitar a otras personas. Pruebe estos requisitos con las funciones reales de compartición y membresía de la aplicación.
No suponga que una interfaz restringida implica datos restringidos. Verifique a qué puede acceder la cuenta externa mediante búsquedas, URL directas, notificaciones, archivos adjuntos, comentarios, exportaciones y API. Pruebe a un usuario cliente con registros representativos de otro cliente, no solo en un entorno vacío.
Si la aplicación no puede expresar el límite necesario, una instancia separada, un espacio de trabajo separado con controles cuidadosamente validados, un proceso de compartición diferente o una aplicación distinta pueden ser más seguros. La respuesta adecuada depende de la sensibilidad de los datos y de las consecuencias de un error.
- ¿Puede limitarse el acceso externo a usuarios identificados y ámbitos de negocio definidos?
- ¿Pueden caducar las invitaciones y puede retirarse el acceso con rapidez?
- ¿Pueden los usuarios externos descubrir otros usuarios, equipos, clientes o registros?
- ¿Pueden descargar, exportar, copiar o volver a compartir información?
- ¿Pueden crear usuarios, invitar a colaboradores o modificar membresías?
- ¿Puede la organización revisar todas las cuentas externas activas y sus accesos?
Evalúe por separado los tokens de API, las cuentas de servicio y las integraciones
Los permisos de la interfaz humana no demuestran que las integraciones sean seguras. Las API pueden exponer funciones administrativas o sensibles si falta la autorización a nivel de endpoint o si esta es demasiado amplia. OWASP identifica específicamente la autorización defectuosa a nivel de función como un riesgo cuando se puede acceder a endpoints administrativos sin comprobaciones adecuadas.
Haga un inventario de cada identidad no humana: tokens de API, credenciales de integración, usuarios de automatización, cuentas de servicio y webhooks cuando corresponda. Para cada una, identifique su propietario, propósito, permisos, alcance, ubicación de almacenamiento, proceso de rotación y método de revocación. Un token no debe heredar el acceso todopoderoso de un administrador humano simplemente porque resultaba cómodo crearlo.
Pruebe las integraciones con los mismos alcances representativos que las personas. Una integración de informes que necesita datos agregados no debe recibir automáticamente la capacidad de modificar registros o administrar usuarios. Mantenga diferenciadas las credenciales de desarrollo, prueba y producción cuando su modelo operativo admita esa separación.
- ¿La aplicación admite credenciales con alcance limitado o cada token equivale en la práctica a acceso total a la cuenta?
- ¿Pueden atribuirse los tokens a un propietario individual o a un propósito de servicio identificado?
- ¿Pueden limitarse los permisos por acción, alcance de recurso o caducidad?
- ¿Puede revocarse un token sin deshabilitar integraciones no relacionadas?
- ¿Las respuestas de la API respetan los mismos límites previstos que la interfaz de usuario?
- ¿Los endpoints y las funciones administrativas se prueban explícitamente, en lugar de inferirse a partir de restricciones de la interfaz?
Cree una matriz de pruebas de permisos con registros representativos y cuentas ajenas a producción
Una matriz de pruebas de permisos convierte los requisitos de acceso en evidencia. Cree usuarios de prueba representativos para cada rol, incluida una cuenta deliberadamente de bajo privilegio y una cuenta externa. Cree registros representativos que cubran escenarios ordinarios, confidenciales, entre equipos, entre clientes, archivados y de transferencia de propiedad relevantes para su organización.
Para cada rol y acción, indique el resultado esperado: permitido, denegado o permitido solo dentro de un alcance identificado. Pruebe a través de todas las vías disponibles, incluida la interfaz de usuario, enlaces directos, búsquedas, exportaciones, acciones masivas, clientes móviles si se utilizan, notificaciones y API. Las pruebas de autorización deben cubrir las rutas denegadas además de los recorridos de usuario exitosos.
Vuelva a realizar las pruebas cuando cambien los roles, las integraciones, los flujos de trabajo principales o las funcionalidades de la aplicación. OWASP señala que los problemas de autorización suelen surgir cuando se añaden o modifican funciones sin volver a evaluar el comportamiento de autorización.
- Use filas para los roles representativos y columnas para las acciones y los alcances de datos.
- Registre los resultados esperados y observados, además de evidencia como una fecha de prueba, el nombre de la cuenta y una referencia del resultado.
- Pruebe las acciones de lectura, creación, edición, eliminación, compartición, exportación, invitación, cambio de rol y configuración cuando sean pertinentes.
- Incluya intentos de acceder a datos de otro equipo, cliente o espacio de trabajo.
- Añada pruebas de regresión para las reglas de autorización de mayor riesgo cuando su equipo tenga esa capacidad.
Planifique los procesos de altas, cambios y bajas
Incluso un modelo de roles bien diseñado falla si las cuentas y membresías no se mantienen actualizadas. Defina cómo una persona obtiene acceso, cómo cambia su acceso cuando cambia su puesto o asignación a un cliente y cómo pierde el acceso cuando termina su empleo, contrato o proyecto. Asigne un responsable identificado para cada paso y establezca una cadencia de revisión operativa adecuada al riesgo.
Si la aplicación admite SCIM, el protocolo proporciona operaciones para recursos User y Group, incluidas su creación, recuperación, modificación y eliminación. Esto puede respaldar flujos de aprovisionamiento, pero no decide los desencadenantes del ciclo de vida, el diseño de roles, las reglas de transferencia de propiedad ni la gestión de excepciones. Estas siguen siendo responsabilidades organizativas.
Preste especial atención a la propiedad. Antes de deshabilitar una cuenta, determine quién será propietario de los registros activos, proyectos, colas, archivos, automatizaciones, informes y credenciales de integración asociados a ese usuario. Confirme que la transferencia no amplíe involuntariamente el acceso de la persona receptora.
- Alta: verifique la identidad, seleccione el rol aprobado, establezca el alcance correcto y registre al responsable o gerente que aprueba.
- Cambio: elimine el acceso obsoleto antes de añadir o al mismo tiempo que añade nuevo acceso; revise las concesiones directas y las membresías externas.
- Baja: deshabilite o elimine el acceso, revoque los tokens, transfiera la propiedad y revise los recursos compartidos.
- Fecha de finalización de contratista o cliente: utilice una revisión programada y confirme la retirada, en lugar de depender de una tarea manual que alguien recuerde.
- Revise periódicamente las cuentas privilegiadas, externas, inactivas y de excepción.
Preguntas frecuentes
¿Qué debe incluir una lista de verificación RBAC para una aplicación autoalojada?
Incluya grupos de usuarios reales, acciones requeridas y prohibidas, alcance de datos, roles y grupos, límites de espacios de trabajo u objetos, separación de administradores, controles para usuarios externos, permisos de API y cuentas de servicio, una matriz de pruebas de permisos y procesos de altas, cambios y bajas. Documente qué se ha demostrado frente a qué se da solo por supuesto.
¿El alojamiento gestionado proporciona RBAC de la aplicación?
La infraestructura gestionada y la autorización de la aplicación resuelven problemas diferentes. Airbip gestiona la infraestructura en la nube en torno a despliegues de aplicaciones basados en Docker, incluido el enrutamiento, los certificados TLS, la gestión del ciclo de vida y las copias de seguridad configurables. El cliente aún debe seleccionar una aplicación cuyo modelo de permisos se ajuste a la organización, definir los roles y alcances de acceso, y operar la gobernanza de acceso de forma adecuada.
¿Un rol llamado administrador siempre tiene demasiado poder?
No necesariamente, pero debe probarse. Determine exactamente qué puede ver, modificar, exportar y delegar el administrador, y si la administración operativa puede separarse del acceso a datos empresariales sensibles. Revise también la administración de la infraestructura de apoyo, ya que esos privilegios pueden ser muy sensibles.
¿Por qué probar los permisos de la API si la interfaz de usuario parece restringida?
Las restricciones de la interfaz de usuario no demuestran que los endpoints de API apliquen las mismas reglas de autorización. Pruebe las funciones de la API por separado, en especial las funciones administrativas, las exportaciones y el acceso entre alcances. Haga inventario de los tokens y las cuentas de servicio, y restrínjalos según su propósito específico.
¿Cuándo no es una aplicación autoalojada la opción adecuada para el modelo de acceso requerido?
Elija otra aplicación u otro enfoque de despliegue cuando los límites necesarios no puedan expresarse y verificarse sin excepciones amplias; cuando los usuarios externos no puedan aislarse con suficiente seguridad; cuando las acciones sensibles requieran una separación que el sistema no pueda admitir; o cuando el equipo no pueda operar las revisiones de acceso, pruebas y procesos de ciclo de vida necesarios. La infraestructura gestionada no compensa un modelo de autorización a nivel de aplicación inadecuado.
Fuentes y lecturas adicionales
- Role Based Access Control FAQs — National Institute of Standards and Technology
- Authorization Cheat Sheet — OWASP Foundation
- Authorization Testing Automation Cheat Sheet — OWASP Foundation
- API5:2023 Broken Function Level Authorization — OWASP Foundation
- Separation of Duty glossary entry — National Institute of Standards and Technology
- SP 800-53 Rev. 5 controls download page — National Institute of Standards and Technology
- RFC 7644: System for Cross-domain Identity Management Protocol — IETF
- Docker Engine security — Docker
- Protect the Docker daemon socket — Docker
- API & Dashboard — Traefik Labs