Field Guard | Wilkes & Liberty

Field Guard está pensado para arquitectos de Drupal y equipos de seguridad que necesitan que determinados campos fallen en modo cerrado, incluso para administradores e incluso cuando JSON:API o Views preguntan por un campo sin cargar una entidad. Wilkes & Liberty mantiene el módulo con licencia GPL para Drupal 10.6+, 11.3+ y Drupal 12. La política vive en la configuración exportada y nombra permisos que el sitio ya posee.

Por qué existe

Un campo sensible puede filtrar información sin llegar a renderizarse. JSON:API y Views realizan verificaciones a nivel de definición para decidir si un campo puede filtrarse u ordenarse, a veces sin ninguna entidad en contexto. Devolver un resultado de acceso neutral puede dejar disponible la superficie de filtrado u ordenamiento, lo que permite a quien realiza la llamada inferir una fecha, un estado, una clasificación u otro valor oculto mediante consultas repetidas.

Una segunda trampa es el comportamiento de administrador de Drupal. hasPermission() devuelve true para todos los permisos en el usuario 1 y en los roles marcados como administrativos. Un módulo que pretende denegar el acceso cuando falta un permiso puede eximir silenciosamente a las cuentas más poderosas antes de devolver un resultado prohibido.

Quién debe usarlo, y cuándo

Arquitectos de seguridad de Drupal que protegen campos cuya existencia, ordenamiento o comportamiento de filtrado es sensible.
Equipos de API que exponen JSON:API o Views cuando el acceso al valor renderizado por sí solo no cierra las vías de inferencia.
Operadores de cumplimiento que quieren que las concesiones aparezcan como configuración de roles explícita y revisable, en lugar de herencia de administrador.
Mantenedores de distribuciones que necesitan importar la misma política de campos de forma consistente en todos los entornos.

Use Field Guard para un mapa pequeño y deliberado de campos sensibles. No lo use como reemplazo universal de los sistemas de acceso de Drupal para entidades, bundles, flujos de trabajo o reglas de negocio.

Dónde aplica la política

Field Guard implementa el hook de acceso a campos de Drupal. Para un tipo de entidad, bundle, campo y operación configurados, devuelve AccessResult::forbidden() a menos que un rol regular, no administrador, contenga explícitamente el permiso indicado. Drupal combina los resultados de acceso a campos de modo que un veredicto prohibido no puede ser anulado por otro módulo, por el usuario 1 ni por un rol administrativo.

Cuando no se proporciona ninguna entidad (la vía a nivel de definición que se usa para filtrar y ordenar), el módulo deniega el campo protegido para todos. Eso elimina la superficie de inferencia, con una contrapartida intencional: incluso un usuario autorizado no puede filtrar ni ordenar ese campo cuando Drupal no ofrece contexto de entidad.

Modelo de configuración

protected:
  profile:
    compliance_record:
      field_evidence_date:
        view: 'view compliance evidence'
        edit: 'record compliance evidence'

La jerarquía es tipo de entidad → bundle → campo → operación → permiso. Solo view y edit son operaciones válidas. Las operaciones omitidas quedan abiertas, las cadenas de permiso vacías se tratan como no definidas y el módulo se entrega con un mapa vacío: la instalación por sí sola no cambia nada.

El esquema de configuración cerrado rechaza las claves de operación mal escritas en lugar de aceptar una política que no hace nada. Los resultados de acceso llevan la dependencia de caché de la configuración, por lo que cambiar el mapa invalida las decisiones anteriores en lugar de dejar un campo protegido legible desde una caché obsoleta.

Por qué importan las concesiones explícitas por rol

Para las verificaciones a nivel de valor, Field Guard carga los roles de la cuenta, omite los roles marcados como administrativos e inspecciona directamente la configuración de los roles restantes. Una concesión aparece, por tanto, como una línea en la configuración que puede revisarse, desplegarse y revertirse. Esto crea separación de funciones sin inventar un segundo sistema de permisos: el módulo no define permisos y nunca concede acceso.

Límites honestos

Field Guard gobierna la API de acceso a campos de Drupal. El SQL directo, Drush y el PHP personalizado que lee $entity->get() sin invocar el acceso a campos aún pueden ver el valor. El módulo no registra las lecturas; su mapa de campos protegidos expone un punto de integración para un consumidor de auditoría como Audit Chain.

La protección es de coincidencia exacta. Los tipos de entidad, bundles, campos y operaciones no listados permanecen abiertos. No proteja campos de flujo de trabajo como moderation_state o status en edit: Drupal verifica el acceso de edición del campo contra el valor almacenado durante un patch de la API, mientras que las reglas de transición necesitan una validación que pueda inspeccionar el valor entrante.

La denegación a nivel de definición hace que un campo protegido no pueda filtrarse ni ordenarse para nadie. Si el filtrado autorizado es un requisito, rediseñe la superficie de consulta en lugar de debilitar la decisión sin contexto.

Instalación, configuración y pruebas

Requiere PHP 8.1+ y los módulos Field y User del núcleo de Drupal. El mismo modelo de configuración se aplica en todas las versiones de Drupal compatibles; los rangos de compatibilidad declarados reflejan el soporte probado de la API del núcleo, no conjuntos de funciones distintos.

composer require drupal/field_guard
drush en field_guard

# Add field_guard.settings.yml to configuration, then import normally.
drush config:import

Las pruebas de kernel del repositorio cubren la denegación a administradores y al usuario 1, el comportamiento a nivel de definición de JSON:API y Views, la validación de la configuración y la cacheabilidad. La prueba clave que conviene inspeccionar es NullItemsFailsClosedTest.

Proyecto, código fuente, incidencias y trabajo relacionado

Mantenido por Jeremy Michael Cerda y Wilkes & Liberty bajo GPL-2.0-or-later. La versión del código fuente verificada para esta página es la 1.1.0.