Traducido del English por IA ·
Desde la versión 2.0.1 puedes crear tus propios grupos de acceso. Esta es la pestaña Groups de Settings > Access Control en una organización de prueba, antes de añadir nada.
Los roles integrados aparecen aquí como grupos, cada uno con su clave, el número de permisos que contiene y sus miembros: Owner (OWNER) con 1426, Admin (ADMIN) con 1343 y User (USER) con 294. La organización tiene un miembro, el propietario. Los roles integrados son fijos. Sus números dependen de los módulos que incluya tu plan, ya que un módulo que no tienes no añade permisos.Ahora, un equipo de planta. Supongamos que los operadores de una planta necesitan editar dispositivos y escribir atributos, pero no deben ver las credenciales de los dispositivos ni tocar la configuración. Hacerlos Admin les da todo eso y mucho más. En su lugar:
- New group. Clave
plant.north.operators, etiqueta «North plant operators». La clave no se puede cambiar después y aparece en el registro de auditoría y en las políticas de acceso, así que ponle un nombre adecuado. - Create, abre el grupo y marca sus permisos. Para este caso,
iot_device.devices.updateeiot_device.attributes.write, además de lo que ya tiene User. - En la pestaña Users, déjalos como User y añade el grupo.
Los grupos solo añaden permisos al rol; nunca quitan ninguno. Un grupo puede elevar a un miembro por encima del mínimo de Admin, pero nunca por encima del de Owner, de modo que los comandos directos, las claves de firma de firmware y la transferencia de propiedad siguen en manos de los propietarios, pase lo que pase con un grupo.El interruptor Active de un grupo es útil: un grupo inactivo conserva sus miembros pero no concede nada. From template… junto a New group añade un grupo ya preparado que luego puedes editar como cualquier otro.Comprueba el resultado por persona en su página de miembro, pestaña Permissions, que muestra el acceso efectivo. Documentación: Groups and permissions.
Since 2.0.1 you can make your own access groups. This is the Groups tab of Settings > Access Control on a test organisation, before I add anything.
The built-in roles appear here as groups, each with its key, the number of permissions it holds and its members: Owner (OWNER) with 1426, Admin (ADMIN) with 1343 and User (USER) with 294. The organisation has one member, the owner. The built-in roles are fixed. Their numbers depend on the modules your plan has, since a module you don’t have adds no permissions.
Now a plant team. Say the operators of one plant need to edit devices and write attributes, but must not see device credentials or touch settings. Making them Admin hands them all of that and much more. Instead:
- New group. Key
plant.north.operators, label «North plant operators». The key can’t be changed later and it shows up in the audit log and in access policies, so name it properly. - Create, open the group, and tick its permissions. For this case
iot_device.devices.updateandiot_device.attributes.write, on top of what User already has. - On the Users tab, leave them as User and add the group.
Groups only add permissions to the role; they never take one away. A group can lift a member over an Admin minimum, never over an Owner one, so raw commands, firmware signing keys and ownership transfer stay with owners whatever a group says.
The Active switch on a group is handy: an inactive group keeps its members but grants nothing. From template… next to New group adds a ready-made group that you can then edit like any other.
Check the result per person on their member page, Permissions tab, which shows effective access. Docs: Groups and permissions.
Traducido del English por IA ·
¿Y en la otra dirección? Tenemos contratistas con nivel User que no deberían enviar ningún comando. Si los grupos solo añaden permisos, ¿cómo les quito eso?
And the other direction? We have contractors at User level who should not send any commands at all. If groups only add, how do I take that away from them?
Traducido del English por IA ·
Dos formas.Si ningún User debe enviar comandos, desmarque iot_rpc.send.basic para User en la pestaña Derechos de acceso.Si solo son los contratistas, colóquelos en un grupo (clave contractors, por ejemplo) y añada una política de acceso Deny: acciones iot_rpc.send.basic, iot_rpc.send.privileged e iot_device.attributes.write, condición subject.roles contains contractors. Un deny prevalece sobre cualquier permit. Las políticas requieren el rol Owner. Active primero el modo shadow y revise el registro de decisiones durante unos días antes de aplicarla.
Two ways.
If no User should send commands, untick iot_rpc.send.basic for User on the Access Rights tab.
If it’s only the contractors, put them in a group (key contractors, say) and add a Deny access policy: actions iot_rpc.send.basic, iot_rpc.send.privileged and iot_device.attributes.write, condition subject.roles contains contractors. A deny wins over any permit. Policies need the Owner role. Turn on shadow mode first and watch the decision log for a few days before you enforce it.
Traducido del English por IA ·
¿Se puede limitar un grupo a los dispositivos de una sola planta? ¿Así los operadores del norte solo ven los dispositivos del norte?
Can a group be limited to one plant’s devices? So the north operators only see north devices?
Traducido del English por IA ·
No. Los grupos y las políticas deciden sobre la acción, y las páginas de IoT no pasan atributos de dispositivo a las políticas, así que un miembro que puede ver dispositivos ve todos los dispositivos de la organización. Si la planta norte nunca debe ver los dispositivos de la planta sur, deben pertenecer a dos organizaciones. Una misma cuenta puede ser miembro de ambas, con un rol distinto en cada una.
No. Groups and policies decide on the action, and IoT pages pass no device attributes to policies, so a member who may view devices sees all devices of the organisation. If the north plant must never see the south plant’s devices, they belong in two organisations. One account can be a member of both, with a different role in each.
Traducido del English por IA ·
Creé un grupo de operadores similar para nuestra línea de empaquetado. La pestaña Permissions de la página del miembro me ayudó a detectar un error: había marcado attributes write y olvidado devices update, por lo que podían cambiar atributos pero no renombrar un dispositivo.
Did an operators group like this for our packaging line. The Permissions tab on the member page caught a mistake for me, I had ticked attributes write and forgotten devices update, so they could change attributes but not rename a device.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.