Por que el control de acceso es lo primero que diseño en cualquier intranet

Llevo mas de una decada montando intranets en Drupal para organizaciones grandes, y si algo he aprendido a base de golpes es que los permisos no se configuran "al final, cuando todo funcione". Se diseñan antes que la primera linea de contenido.

Te cuento por que lo digo con tanta conviction. Hace tres años me contrataron para hacer una auditoria de seguridad en la intranet de una multinacional industrial con 14 filiales y unos 3.000 usuarios. La plataforma llevaba dos años en produccion, habia pasado por una fusion corporativa, y nadie se habia parado a revisar los roles despues de integrar a los nuevos empleados. Cuando cruce la matriz de permisos con el directorio activo, me encontre con que 340 usuarios tenian acceso de administrador. Trescientos cuarenta. Gente de recepcion, becarios, personal de almacen... todos con capacidad para borrar contenido, modificar workflows y acceder a documentacion de consejo. El equipo de compliance casi se cae de la silla.

Esa experiencia me confirmo algo que ya intuia: una intranet corporativa no es un WordPress con contraseña. Es un entorno donde conviven actas de consejo, contratos con proveedores, datos de nomina, comunicaciones estrategicas y documentos de propiedad intelectual. Si el sistema de permisos no esta bien pensado desde el minuto cero, tienes dos problemas esperandote: o alguien ve lo que no deberia ver (filtracion), o alguien no puede hacer su trabajo porque los permisos le bloquean (friccion operativa). Y los dos destruyen la confianza en la plataforma.

Drupal es el CMS que mas flexibilidad ofrece para esquemas de control de acceso a medida: desde RBAC clasico hasta politicas ABAC que combinan rol, departamento, nivel jerarquico y propiedades del contenido. Pero esa flexibilidad es un arma de doble filo si no la acompañas de una estrategia clara.

Anatomia del sistema de permisos nativo de Drupal

Conviene entender las tres capas que Drupal usa internamente para gestionar el acceso. Me he encontrado con equipos de IT que configuran permisos sin saber como funcionan por debajo, y eso siempre acaba generando problemas.

Roles y permisos del core: la base de todo

El esquema basico es sencillo: los permisos se asignan a roles, los roles se asignan a usuarios, y un usuario puede tener varios roles cuyos permisos se suman. Los permisos del core cubren operaciones sobre tipos de contenido (create article content, edit own article content, edit any article content), taxonomias, gestion de usuarios e informes. Para cada tipo de contenido, Drupal distingue entre operar sobre contenido propio (own) y sobre contenido de cualquier autor (any), lo que permite configuraciones como "los editores modifican sus borradores, pero solo los supervisores tocan los de otros".

Para un sitio web normal, esto basta. Pero en una intranet corporativa necesitas restricciones adicionales: por departamento, por sede, por nivel de confidencialidad o por estado del workflow. Ahi entran las otras capas.

Node access grants: el mecanismo que pocos entienden (pero que lo sostiene todo)

Cuando los permisos por tipo de contenido se quedan cortos, Drupal tira de los node access grants: un mecanismo de bajo nivel que permite a cualquier modulo definir reglas de acceso arbitrarias para cada nodo. Estas reglas se guardan en la tabla node_access y se evaluan en cada intento de acceso.

Funciona mediante hooks (hook_node_access_records y hook_node_grants). Es tremendamente potente, pero tiene un coste: en una intranet con 100.000 nodos y grants para diez roles, la tabla llega al millon de registros. No es un dato teorico, lo he medido en produccion. Mas adelante te cuento como optimizarlo.

Sobre este sistema construyen los modulos que uso a diario: Content Access, Taxonomy Access Control y Group.

Los modulos que uso en cada proyecto de intranet (y por que)

Group: cuando cada departamento es un mundo

Si me preguntas cual es el modulo que mas instalo en intranets corporativas, es Group sin duda. Permite crear espacios aislados —que pueden representar departamentos, proyectos, comites, filiales— y asignar contenido, usuarios y permisos dentro de cada uno de forma completamente independiente.

Cada grupo tiene sus propios roles internos. Un usuario puede ser administrador del grupo "Marketing" y simple lector del grupo "Finanzas", con permisos radicalmente diferentes en cada espacio. Esto resuelve de un plumazo el problema clasico de "necesito que esta persona vea todo lo de su departamento pero nada de los demas".

La configuracion sigue tres pasos que siempre repito con mis clientes:

Primero defines los tipos de grupo (Departamento, Proyecto, Comite) con sus roles y permisos internos. Segundo, creas las instancias concretas: el departamento de Marketing, el proyecto de migracion CRM, el comite de riesgos. Tercero, asocias usuarios y contenido a cada grupo, y los permisos del grupo determinan quien puede hacer que.

Un detalle que siempre recalco en las formaciones: Group gestiona el acceso a nivel de base de datos, mediante node access grants. Las restricciones no se pueden eludir escribiendo la URL directa del nodo. He visto intranets donde el "control de acceso" consistia en esconder enlaces del menu. Eso no es seguridad, es taparse los ojos.

Content Access y Taxonomy Access Control: para necesidades mas puntuales

Content Access permite configurar permisos de visualizacion, edicion y eliminacion por tipo de contenido y por rol, con la opcion de definir permisos individuales por nodo. Yo lo uso para casos concretos: un acta de consejo de administracion que solo deben ver los consejeros, dentro de un tipo de contenido "Acta" que normalmente es accesible para toda la direccion. En lugar de crear un tipo de contenido separado para esa unica acta, le pongo permisos especificos a ese nodo.

Taxonomy Access Control Lite (TACT) vincula los permisos a los terminos de taxonomia asignados al contenido. Si tu intranet clasifica documentos por nivel de confidencialidad —publico, interno, restringido, secreto—, TACT permite que solo los usuarios con el rol "Direccion" accedan a nodos etiquetados como "secreto". Lo elegante de este enfoque es que los propios editores controlan el acceso eligiendo la taxonomia correcta al crear contenido. No necesitan tocar configuraciones de permisos ni pedir nada al administrador.

En la multinacional de las 14 filiales que te mencionaba al principio, usamos TACT para clasificar toda la documentacion de compliance por nivel de confidencialidad. El equipo juridico podia etiquetar un contrato como "restringido" y automaticamente quedaba visible solo para los roles con acceso a ese nivel. Nos ahorro horas de configuracion manual.

Workflow y permisos por estado editorial

Las intranets corporativas suelen necesitar workflows donde el contenido pasa por borrador, revision, aprobacion, publicacion y archivado. Y los permisos tienen que cambiar segun el estado.

El modulo Content Moderation del core proporciona esta funcionalidad basica, pero los permisos de transicion entre estados se configuran por rol a nivel global. Para un control mas fino, uso Workflow Participants para asignar revisores especificos a cada pieza de contenido, y ECA (Event - Condition - Action) para automatizar la asignacion de permisos cuando el contenido cambia de estado.

Un ejemplo concreto que monte el año pasado: un documento en estado "revision legal" automaticamente se hacia visible solo para los usuarios del departamento juridico, independientemente de quien lo hubiese creado. La regla ECA escuchaba la transicion de estado y ajustaba los permisos del grupo en tiempo real. El equipo legal estaba encantado porque ya no les llegaban peticiones por email para "dar acceso al contrato X".

Como diseño la estructura de roles (y por que no creo un rol por cargo)

Este es probablemente el error que mas veo en intranets que me llegan para auditar: alguien creo un rol por cada perfil funcional de la organizacion. "Director de marketing", "Analista financiero junior", "Responsable de compliance EMEA"... Resultado: 47 roles, la mitad con permisos duplicados, un tercio obsoletos, y nadie sabe ya que hace cada uno.

Mi enfoque es siempre el mismo: separar los roles en dos dimensiones independientes.

Roles funcionales: que puede hacer el usuario

Definen capacidades genericas sobre el contenido, sin referencia a departamentos concretos. En la practica, me muevo con cuatro o cinco niveles que se repiten en casi todos los proyectos:

• Lector — solo ve el contenido al que tiene acceso por pertenencia a grupos o taxonomias.
• Contribuidor — crea contenido pero no lo publica; todo entra en workflow de revision.
• Editor — crea, edita contenido de otros y gestiona transiciones de workflow en su ambito.
• Administrador de area — gestiona usuarios, roles de grupo y configuracion dentro de su departamento.
• Administrador global — acceso completo a la plataforma. Como maximo dos o tres personas.

Roles de ambito: donde puede actuar

La segunda dimension la gestiono con la pertenencia a grupos (modulo Group) o con terminos de taxonomia asignados al perfil del usuario. Un usuario con el rol funcional "Editor" y pertenencia al grupo "Recursos Humanos" puede editar dentro de ese grupo, pero no toca nada del grupo "Finanzas".

La gracia de esta separacion es que la matriz de permisos crece de forma lineal: 5 roles funcionales multiplicados por N grupos. Si creas un rol por cada combinacion posible de funcion y departamento, el crecimiento es exponencial y la gestion se vuelve un infierno. En la multinacional de 14 filiales, con esta estructura bidimensional pasamos de los 340 roles descontrolados que me encontre en la auditoria a 5 roles funcionales y 38 grupos. Manejable, auditable y documentable.

Integracion con directorios corporativos: LDAP y SAML

En ninguna intranet corporativa seria se gestionan usuarios a mano dentro de Drupal. Las organizaciones tienen sus identidades centralizadas en Active Directory, Azure AD, Google Workspace, Okta... y la intranet se tiene que enganchar ahi para autenticacion y, si haces bien las cosas, para asignacion automatica de roles.

SAML 2.0: mi opcion preferida en la mayoria de proyectos

El modulo SAML Authentication (samlauth) configura Drupal como Service Provider contra cualquier Identity Provider compatible con SAML 2.0. La configuracion implica intercambiar metadatos XML entre el IdP y Drupal, y definir como mapear los atributos SAML a campos del perfil de usuario.

La funcionalidad clave es el mapeo automatico de roles. Defines reglas: si department es "Legal", asignar al grupo "Departamento Juridico"; si memberOf incluye "DirectionBoard", asignar el rol "Direccion". Cuando un empleado cambia de departamento en el directorio, su siguiente login actualiza automaticamente todo en Drupal.

En la auditoria que te contaba, el problema raiz era que no tenian este mapeo. Habian dado de alta a los 800 empleados de la empresa adquirida con roles copiados del primer usuario migrado, que resultaba ser administrador.

Sincronizacion LDAP para casos especificos

El modulo LDAP permite autenticar contra servidores LDAP/Active Directory y sincronizar usuarios, grupos y atributos, en tiempo real o mediante cron. Lo uso cuando el cliente necesita la base de usuarios completa en Drupal antes de que nadie haga login —para preconfigurar grupos u organigramas internos—. Si solo necesitas autenticacion y mapeo de roles al vuelo, SAML suele ser mas limpio.

Auditoria y trazabilidad: la parte que nadie quiere hacer (hasta que llega la inspeccion)

Una configuracion de permisos impecable sin herramientas de auditoria es como una caja fuerte sin camara de seguridad. Sabes que esta cerrada, pero no sabes quien la abrio anoche.

En intranets que manejan datos personales sujetos al RGPD, documentacion financiera o contratos, la trazabilidad no es opcional. Es una obligacion legal. Y te aseguro que las inspecciones llegan. He acompañado a tres clientes en auditorias de la AEPD, y en los tres casos lo primero que pidieron fue: "muestrennos quien accedio a los datos de empleados en los ultimos seis meses, con fechas y direcciones IP".

El dblog del core tiene capacidad de busqueda y retencion limitada. Para auditoria seria, instalo siempre Audit Log, que registra operaciones CRUD con detalle de usuario, timestamp, IP y valores antes/despues de cada cambio, en tablas dedicadas que no rota el dblog.

Para RGPD, el modulo GDPR añade registro de consentimientos, anonimizacion bajo solicitud y exportacion de datos en formato portable. Si tu intranet almacena datos de empleados —y todas lo hacen—, es obligatorio bajo normativa europea.

Un truco que funciona muy bien: combinar Audit Log con Views para crear dashboards de auditoria. En un proyecto reciente, monte un panel filtrado por tipo de accion, departamento y nivel de confidencialidad. El equipo de compliance lo revisaba cada viernes y en dos meses detecto tres accesos anomalos que resultaron ser cuentas de exempleados sin desactivar. La automatizacion SAML que montamos despues cerro ese agujero.

Rendimiento del sistema de permisos a escala real

Este tema me lo suelen plantear tarde, cuando la intranet ya va lenta. Pero el sistema de permisos de Drupal tiene un coste computacional que se amplifica con cada nodo, cada usuario y cada regla de acceso que añades.

La reconstruccion de permisos —que se dispara cuando cambias reglas de acceso globales— puede tardar varios minutos con tablas grandes. El modulo Node Access Rebuild Progressive ejecuta la reconstruccion en lotes por cron, evitando timeouts.

La cache de permisos se invalida cada vez que cambian los roles de un usuario o los grants de un nodo. Si usas permisos individuales por nodo en lugar de por grupo, la tasa de invalidacion sera altisima.

Mi recomendacion: diseña siempre al nivel mas amplio posible. Permisos por grupo antes que por tipo de contenido, y por tipo de contenido antes que por nodo individual. En un proyecto para una administracion publica con 85.000 documentos, pasar de permisos por nodo a permisos por grupo redujo la tabla node_access de 2.3 millones de filas a 180.000, y los tiempos de carga de listados bajaron de 4.2 segundos a 0.6.

Los errores que veo en todas las auditorias (y como evitarlos)

Despues de revisar la configuracion de permisos de mas de 30 intranets corporativas, hay patrones que se repiten una y otra vez. Los dejo aqui para que no los cometas tu.

El permiso bypass node access en roles que no deberian tenerlo. Este es el mas peligroso. bypass node access ignora completamente el sistema de grants y da acceso ilimitado a todo el contenido. Solo deberia estar asignado al rol de administrador del sistema, nunca a editores ni gestores de contenido. En la auditoria de la multinacional, este era el permiso que tenian los 340 usuarios con acceso de administrador. Alguien lo habia marcado en un rol generico "para que no dieran problemas los permisos durante la migracion" y nunca lo quito.

Confundir visibilidad de menus con permisos reales. Lo he visto tantas veces que ya lo detecto en las primeras cinco minutos de una auditoria. Ocultar un enlace de navegacion no impide el acceso si el usuario conoce o adivina la URL. Los permisos se configuran siempre a nivel del sistema de acceso —roles, grants, Group—, nunca a nivel de la interfaz de navegacion.

No probar los permisos desde la perspectiva de cada rol. El modulo Masquerade permite suplantar a cualquier usuario para verificar que ve y que puede hacer. Yo dedico un dia completo a esto antes de cada lanzamiento. Un dia entero. Los errores de permisos en produccion son de los mas caros de corregir, no por esfuerzo tecnico sino por confianza perdida.

No documentar la matriz de permisos fuera de Drupal. La configuracion esta repartida entre roles, Group, Content Access, reglas SAML... Sin una matriz consolidada en un documento externo, las auditorias son arqueologia y la incorporacion de nuevos administradores una tortura. En mis proyectos, la matriz de permisos es un entregable tan formal como la propia intranet.

Un sistema de permisos que crece con tu organizacion sin romperse

Configurar permisos granulares en Drupal para una intranet no es marcar checkboxes. Es arquitectura que necesita entender como funciona la organizacion, anticipar como va a crecer y diseñar un modelo de roles mantenible a tres años vista.

Las herramientas —Group, Content Access, TACT, SAML, Audit Log— son potentes. Pero su eficacia depende de un diseño que equilibre seguridad y usabilidad. Demasiado restrictivo y la gente busca atajos (PDFs por email, drives personales). Demasiado permisivo y quedas expuesto cuando llega la auditoria.

El equilibrio se encuentra con un analisis riguroso de requisitos, roles bidimensionales, integracion con el directorio corporativo y cultura de auditoria continua. Si en la multinacional de las 14 filiales hubieramos hecho esto desde el principio, nos habriamos ahorrado los 340 administradores fantasma y tres meses de remediacion.

Si tienes una intranet en Drupal y no estas seguro de que tus permisos esten bien configurados —o si estas planificando una nueva y quieres empezar con buen pie—, hablamos cuando quieras.