Traduit de English par IA ·
Depuis la version 2.0.1, vous pouvez créer vos propres groupes d’accès. Voici l’onglet Groups de Settings > Access Control sur une organisation de test, avant que j’ajoute quoi que ce soit.
Les rôles intégrés apparaissent ici comme des groupes, chacun avec sa clé, le nombre de permissions qu’il détient et ses membres : Owner (OWNER) avec 1426, Admin (ADMIN) avec 1343 et User (USER) avec 294. L’organisation compte un seul membre, le propriétaire. Les rôles intégrés sont fixes. Leurs nombres dépendent des modules inclus dans votre offre, car un module que vous n’avez pas n’ajoute aucune permission.Passons à l’équipe d’une usine. Disons que les opérateurs d’une usine doivent modifier des équipements et écrire des attributs, mais ne doivent pas voir les identifiants des équipements ni toucher aux paramètres. Les passer Admin leur donne tout cela et bien plus encore. Procédez plutôt ainsi :
- New group. Clé
plant.north.operators, libellé « North plant operators ». La clé ne peut pas être modifiée ensuite, elle apparaît dans le journal d’audit et dans les politiques d’accès, donc donnez-lui un nom correct. - Create, ouvrez le groupe et cochez ses permissions. Pour ce cas,
iot_device.devices.updateetiot_device.attributes.write, en plus de ce que User possède déjà. - Sur l’onglet Users, laissez-les en User et ajoutez le groupe.
Les groupes ne font qu’ajouter des permissions au rôle ; ils n’en retirent jamais. Un groupe peut faire passer un membre au-delà du minimum Admin, mais jamais au-delà du minimum Owner : les commandes brutes, les clés de signature du firmware et le transfert de propriété restent donc aux propriétaires, quoi que dise un groupe.L’interrupteur Active d’un groupe est pratique : un groupe inactif conserve ses membres mais n’accorde rien. From template… à côté de New group ajoute un groupe prêt à l’emploi que vous pouvez ensuite modifier comme les autres.Vérifiez le résultat pour chaque personne sur sa page de membre, dans l’onglet Permissions, qui affiche les accès effectifs. Documentation : 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.
Traduit de English par IA ·
Et dans l’autre sens ? Nous avons des sous-traitants au niveau User qui ne devraient pas envoyer de commandes du tout. Si les groupes ne font qu’ajouter des droits, comment puis-je les leur retirer ?
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?
Traduit de English par IA ·
Deux façons de faire.Si aucun User ne doit envoyer de commandes, décochez iot_rpc.send.basic pour User dans l’onglet Droits d’accès.Si ce sont uniquement les sous-traitants, placez-les dans un groupe (clé contractors, par exemple) et ajoutez une politique d’accès Deny : actions iot_rpc.send.basic, iot_rpc.send.privileged et iot_device.attributes.write, condition subject.roles contains contractors. Un deny l’emporte sur toute permission. Les politiques nécessitent le rôle Owner. Activez d’abord le mode shadow et surveillez le journal des décisions pendant quelques jours avant de l’appliquer.
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.
Traduit de English par IA ·
Peut-on limiter un groupe aux appareils d’une seule usine ? Ainsi, les opérateurs du site nord ne verraient que les appareils du nord ?
Can a group be limited to one plant’s devices? So the north operators only see north devices?
Traduit de English par IA ·
Non. Les groupes et les politiques décident de l’action, et les pages IoT ne transmettent aucun attribut d’appareil aux politiques ; un membre autorisé à consulter les appareils voit donc tous les appareils de l’organisation. Si l’usine nord ne doit jamais voir les appareils de l’usine sud, ils doivent appartenir à deux organisations. Un même compte peut être membre des deux, avec un rôle différent dans chacune.
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.
Traduit de English par IA ·
J’ai créé un groupe d’opérateurs de ce type pour notre ligne de conditionnement. L’onglet Permissions de la page du membre m’a permis de repérer une erreur : j’avais coché attributes write et oublié devices update, de sorte qu’ils pouvaient modifier les attributs mais pas renommer un appareil.
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.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.