RBAC en n8n: lista de comprobación para revisar los accesos periódicamente
Revisa el RBAC de n8n según las responsabilidades actuales, incluye el uso de credenciales mediante workflows y verifica los cambios de permisos hasta su cierre.
Comprobado con las fuentes citadas el .
Define la revisión de RBAC en n8n
Una revisión periódica de RBAC en n8n debe responder quién tiene acceso, por qué sigue necesitándolo y si los cambios aprobados se han aplicado realmente. Esta lista propone un proceso de revisión manual para responsables de ingeniería y de TI; su periodicidad y sus criterios de finalización son recomendaciones editoriales, no normas obligatorias ni pruebas de cumplimiento.
Empieza por registrar el contexto de la revisión indicado a continuación. n8n distingue entre permisos de toda la instancia y permisos de proyecto, así que revisa ambos. La disponibilidad de las funciones depende de la suscripción y de la versión instalada; aplica únicamente las comprobaciones compatibles con tu configuración.
Inventaría todas las vías de acceso
Utiliza una fila de revisión por usuario, recurso y vía de acceso. La pertenencia a proyectos importa: n8n documenta que los workflows de un proyecto se comparten con sus miembros y que los roles de proyecto controlan las acciones permitidas. Este comportamiento al compartir workflows se aplica a todos los planes de n8n Cloud y a las ediciones Business y Enterprise autoalojadas.
Los siguientes campos son nuestra propuesta de registro de revisión. Esta parte se considera completada cuando cada fila incluida tiene un revisor responsable. Creemos que revisar las vías de acceso resulta más útil que limitarse a aprobar una lista de nombres de usuario: permite concretar cada decisión sobre permisos.
| Campo | Qué registrar |
|---|---|
| Identidad y recurso | Usuario y proyecto, workflow o credencial afectados |
| Vía de acceso | Rol de instancia, pertenencia a un proyecto o acceso compartido |
| Responsabilidad | Tarea actual que requiere el acceso |
| Revisor | Persona responsable de la decisión |
| Decisión y motivo | Mantener, modificar o revocar, con justificación |
| Corrección | Responsable de aplicar el cambio, fecha límite y resultado de la verificación |
Sources: Share with others | Build | n8n Docs
Justifica los privilegios de toda la instancia
n8n documenta que los propietarios de la instancia pueden ver y editar todos los workflows, credenciales y proyectos. Su rol de instancia Admin está disponible en Cloud Pro y Enterprise y en Enterprise autoalojado. Revisa el acceso con privilegios elevados por separado de las asignaciones a proyectos, en lugar de considerar la pertenencia a un proyecto como el límite completo del acceso.
Utiliza estas comprobaciones sugeridas para terminar esta parte de la revisión. Se considera completada cuando cada asignación con privilegios elevados tiene una justificación de negocio registrada o un cambio asignado.
Ajusta los permisos de proyecto al trabajo actual
Comprueba las acciones que necesita cada persona, incluidas la visualización, la ejecución manual y la edición. El rol Project Viewer de n8n es de solo lectura y no permite ejecutar workflows manualmente, pero incluye acceso a los workflows, credenciales y ejecuciones del proyecto; está disponible en Cloud Enterprise y Enterprise autoalojado. Los usuarios con el rol Project Editor pueden ver, crear, actualizar y eliminar workflows, credenciales y ejecuciones del proyecto; n8n documenta la disponibilidad de Editor en Cloud Pro y Enterprise autoalojado.
Para Cloud Enterprise y Enterprise autoalojado, los roles de proyecto personalizados están documentados a partir de n8n 1.122.0; algunos permisos específicos pueden requerir versiones posteriores. Editar un rol personalizado compartido afecta a los usuarios que lo tienen asignado en distintos proyectos. Inspecciona tanto sus permisos como sus asignaciones antes de aprobar un cambio en su definición.
Nuestra comprobación sugerida para completar esta parte de la revisión de RBAC en n8n consiste en comparar cada asignación con las tareas actuales de la persona, registrar los desajustes e identificar a todos los afectados por una modificación propuesta de un rol personalizado.
Sources: n8n-docs/docs/administer/manage-users-and-access/set-permissions-and-roles-rbac/see-available-roles.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/administer/manage-users-and-access/set-permissions-and-roles-rbac/create-custom-project-roles.md at main · n8n-io/n8n-docs · GitHub
Incluye el uso de credenciales a través de workflows
Al compartir workflows en todos los planes de n8n Cloud y en Business y Enterprise autoalojados, los editores pueden utilizar las credenciales incorporadas en los workflows compartidos aunque esas credenciales no se hayan compartido explícitamente con ellos. n8n también restringe la edición de nodos que utilizan credenciales no compartidas. Utilizar una credencial es distinto de ver sus valores secretos.
Al compartir credenciales en esos mismos planes y ediciones, los usuarios que utilizan una credencial compartida no pueden ver ni editar sus detalles por esa vía de acceso compartido; los permisos elevados y los de roles de proyecto deben considerarse por separado. Eliminar una entrada de acceso compartido a una credencial requiere guardar el cambio.
Utiliza las siguientes comprobaciones sugeridas antes de dar por revisado el acceso a las credenciales. En nuestra opinión, eliminar una entrada de acceso compartido debe dar inicio a la verificación, en lugar de servir como prueba de que la retirada del acceso se ha completado.
Sources: n8n-docs/docs/administer/manage-credentials/share-credentials-securely.md at main · n8n-io/n8n-docs · GitHub, Share with others | Build | n8n Docs
Verifica las decisiones con comprobaciones seguras de permisos
Para verificar el RBAC en n8n, sugerimos utilizar cuentas de prueba autorizadas y comprobaciones no destructivas basadas en una matriz de acceso aprobada. Compara la visibilidad esperada y las acciones denegadas, incluido el uso de credenciales a través de workflows. No reveles valores secretos ni ejecutes workflows de producción solo para demostrar que existe acceso.
Esta parte se considera completada cuando los permisos observados coinciden con la decisión aprobada. Si el acceso persiste de forma inesperada, vuelve a revisar los privilegios de instancia, la pertenencia a proyectos, el acceso compartido directo y el uso de credenciales incorporadas antes de cerrar el cambio.
Sources: n8n-docs/docs/administer/manage-users-and-access/understand-instance-roles.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/administer/manage-users-and-access/set-permissions-and-roles-rbac/see-available-roles.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/administer/manage-credentials/share-credentials-securely.md at main · n8n-io/n8n-docs · GitHub, Share with others | Build | n8n Docs
Cierra los cambios con pruebas
El artículo de IDPro de 2025 escrito por Vatsal Gupta, Optimizing Access Certifications, describe cómo registrar los resultados de las revisiones y comprobar que las acciones correctivas se realizaron a tiempo. Es orientación profesional, no una prueba de que esta lista reduzca los incidentes.
Las comprobaciones de cierre que sugerimos a continuación convierten las decisiones en un registro que se puede revisar. Esta parte se considera completada cuando los cambios verificados están cerrados y el trabajo pendiente sigue siendo visible.
Sources: Optimizing Access Certifications
