Políticas de acceso

Las políticas de acceso añaden reglas basadas en atributos (ABAC) sobre los roles y los grupos. Una política examina quién solicita, qué quiere hacer y en qué contexto, y permite o deniega. Use las políticas para restringir lo que los roles y los grupos permitirían en otro caso, por ejemplo «nadie puede enviar comandos críticos desde fuera de la red de la planta» o «el firmware solo puede asignarse desde una sesión iniciada con una passkey». Las políticas son una herramienta avanzada: la mayoría de las organizaciones solo necesitan roles y grupos.

Necesita el rol Owner. Abra Settings > Access Policies (dirección /admin/access-policies).

Cómo se toma una decisión

Para cada solicitud protegida:

1. Se recogen todas las políticas activas cuyo destino coincida (sus acciones y tipos de recurso) y cuyas condiciones se cumplan todas, en orden de prioridad (la más baja se ejecuta primero).
2. Si alguna de ellas deniega, la solicitud se rechaza. Denegar siempre prevalece.
3. En caso contrario, si alguna permite, la solicitud sigue adelante.
4. Si ninguna política se aplica, prevalece la decisión de roles, grupos y matriz («RBAC fallback»).

Las políticas son restricciones aditivas: escriba los requisitos como políticas Deny. Una política Permit cuyas condiciones no se cumplan no rechaza nada; la solicitud simplemente recurre a la decisión del rol.

Qué solicitudes ven las políticas

Las políticas se comprueban en las rutas que llaman al motor de políticas. La mayoría de las páginas y rutas de la API de Hermetry lo hacen; algunas no, porque no hay un miembro con sesión iniciada que evaluar (el propio inicio de sesión, las conexiones de dispositivos, las devoluciones de llamada de webhooks, los trabajos programados y las solicitudes con el contrato de una clave de API, como SCIM). La página Coverage indica exactamente qué rutas llegan al motor y, para las demás, «What guards it instead». Consúltela antes de confiar en una política.

Crear una política

1. Seleccione New policy (o Load examples para partir de políticas predefinidas).
2. Introduzca un Name, el Effect (Permit, o Deny (overrides any permit)) y la Priority (lower runs first). Seleccione Create & edit.
3. En Definition, configure:
   • Actions (comma-separated, empty = all): identificadores de permiso como iot_rpc.send.critical, iot_ota.assign.
   • Resource types (comma-separated, empty = all).
   • Description: por qué existe la política.
   • Status: Active o Inactive. Seleccione Save definition.
4. En Conditions, seleccione Add condition para cada prueba. «Todas las condiciones deben cumplirse (AND) para que la política se aplique.» Seleccione Save conditions.

Una política sin condiciones se aplica a toda solicitud que coincida con su destino.

Condiciones

Cada condición consta de un Attribute, un Operator y un Value (o Values (comma-separated)).

Atributo	Significado
subject.role	El rol integrado: OWNER, ADMIN, USER
subject.roles	El rol más las claves de grupo del miembro
subject.permissions	Los permisos que otorgan los grupos del miembro
subject.id, subject.email	El miembro
subject.department, subject.jobTitle	Del perfil del miembro, cuando está definido
subject.amr	Cómo se inició la sesión: pwd, otp, mfa, hwk (passkey), fed:saml, fed:<provider>
subject.acr	El nivel de garantía derivado: NONE, LOW (solo contraseña o federada), SUBSTANTIAL (un segundo factor verificado), HIGH (una passkey)
environment.ip	La dirección del solicitante
environment.now, environment.method, environment.userAgent, environment.host	Hora, método HTTP, navegador, nombre de host
action	El permiso que se comprueba

Operadores: equals, not equals, in list, not in list, contains, greater than, less than, exists, matches regex, DN equals (RDN).

Un atributo ausente se lee como vacío, lo que cumple not equals y not in list. Por eso las reglas de denegación son seguras y las de permiso no lo son.

Ejemplos

Denegar comandos críticos y en bruto salvo que la sesión haya usado un segundo factor o una passkey:

Campo	Valor
Efecto	Deny
Acciones	iot_rpc.send.critical, iot_rpc.send.raw
Condición	subject.acr not in list SUBSTANTIAL, HIGH

Impedir que los miembros de un grupo contractors escriban atributos o envíen comandos, sea cual sea su rol:

Campo	Valor
Efecto	Deny
Acciones	iot_device.attributes.write, iot_rpc.send.basic, iot_rpc.send.privileged
Condición	subject.roles contains contractors

Para conceder un derecho solo a un grupo, la matriz Access Rights suele ser más sencilla que una política: desmarque el permiso para Admin y márquelo para el grupo. Consulte Groups and permissions.

Modo sombra, probador de acceso y registro de decisiones

Herramienta	Dónde	Uso
Shadow Mode	Settings en la página de políticas (Access Control Settings)	«Las políticas se evalúan y las decisiones se registran, pero una denegación NUNCA bloquea la solicitud.» Desactivado por defecto. Actívelo antes de aplicar una nueva política, revise el registro y desactívelo después.
Access tester	Simulator	«Simule una decisión con las políticas activas: no se guarda ni se registra nada.» Introduzca Subject id, Subject role, Action, Resource type, Resource ownerId, Environment IP y un RBAC fallback role, y luego Evaluate. El Policy trace muestra el destino y las reglas de cada política.
Decision log	Decision log	Cada solicitud evaluada con Effect, Action, Reason (Policy permit, Explicit deny, RBAC fallback, Default deny, Not applicable) y Subject. Las denegaciones en modo sombra se marcan como Shadow.

Decision Log Mode (All decisions, Deny only, Off; por defecto all) y Permit Log Sample Rate (%) determinan cuánto se envía al registro de auditoría. Las denegaciones siempre se registran.

Buenas prácticas

• Empiece con Load examples y léalos antes de escribir los suyos.
• Use políticas de denegación con listas de acciones acotadas. Evite las políticas sin acciones: evalúan cada solicitud.
• No deje nunca fuera a los owners: pruebe cada política con el rol de un owner en el probador de acceso.
• Los cambios surten efecto de inmediato en todos los nodos.