Utilisateurs et autorisations
Gérez les utilisateurs Kilo IoT et les autorisations ABAC par surface — Édition, Consultation ou Aucun accès définis indépendamment par surface.
Au sein de chaque organisation, Kilo IoT Server utilise le contrôle d’accès basé sur les attributs (ABAC) pour déterminer qui peut faire quoi. L’accès est attribué par surface du produit — tableaux de bord, appareils, règles, connecteurs, et plus encore — et non via un seul rôle tout ou rien. Lorsque vous invitez quelqu’un ou modifiez ses autorisations, vous définissez chaque surface individuellement sur Modifier, Voir ou Aucun accès.
Ce modèle par surface est plus flexible qu’un accès grossier limité aux rôles. Un ingénieur de déploiement pourrait obtenir l’accès Modifier aux appareils et aux connecteurs, mais Aucun accès à la facturation. Un responsable des opérations pourrait avoir l’accès Modifier aux tableaux de bord et aux alertes, mais un accès en lecture seule au moteur de règles. Une partie prenante pourrait tout voir sans rien modifier. Et comme l’accès est limité à chaque organisation, une même personne peut avoir des autorisations totalement différentes dans différentes organisations.
Comment fonctionnent les étiquettes d’autorisation
La plateforme utilise les autorisations par surface comme modèle d’accès principal. Il n’y a pas d’étape « sélectionner un rôle » — lorsque vous invitez un utilisateur, vous définissez chaque surface individuellement sur Modifier, Voir ou Aucun accès. La boîte de dialogue démarre avec des valeurs par défaut codées en dur (Modifier sur la plupart des surfaces, avec Gérer les utilisateurs et Piste d’audit définis sur Aucun accès), et vous pouvez ajuster chaque surface avant l’envoi.
Après l’enregistrement des autorisations, la plateforme calcule une étiquette d’affichage en faisant correspondre l’ensemble réel d’autorisations de l’utilisateur à trois modèles nommés — Admin, Éditeur, et Lecteur. Si l’ensemble correspond au modèle Admin, le tableau des utilisateurs affiche « Admin ». S’il correspond à Éditeur, il affiche « Éditeur ». Les combinaisons personnalisées qui ne correspondent à aucun modèle affichent à la place les noms des surfaces individuelles.
Propriétaire n’est pas un rôle prédéfini au même sens. C’est une propriété de l’organisation elle-même — exactement un membre est le propriétaire, et ce statut accorde un accès automatique à l’ensemble de l’organisation (la piste d’audit étant limitée à la lecture). L’accès du propriétaire ne peut pas être personnalisé ni supprimé ; il ne change qu’en cas de transfert de propriété.
Propriétaire
Statut de propriété de l’organisation. Accès automatique à l’ensemble de l’organisation. La piste d’audit est en lecture seule.
Non — implicite dans la propriété
Admin
Modifier sur toutes les surfaces, y compris Abonnement et Gérer les utilisateurs. La piste d’audit est toujours en mode Voir. Les clés API sont toujours en mode Modifier.
Oui — par surface
Éditeur
Modifier sur la plupart des surfaces. Piste d’audit = Voir. Clés API = Modifier. Aucun accès à Abonnement ni à Gérer les utilisateurs.
Oui — par surface
Lecteur
Voir sur la plupart des surfaces. Piste d’audit = Voir. Clés API = Modifier (exception en libre-service). Aucun accès à Abonnement ni à Gérer les utilisateurs.
Oui — par surface

Dans cette section
Comment envoyer une invitation à un utilisateur existant de la plateforme, attribuer des autorisations par surface et gérer les invitations en attente.
Ce qui se passe lorsqu’une personne clique sur un lien d’invitation pour une adhésion ou un transfert de propriété.
La référence complète des autorisations — chaque surface configurable, les options restreintes, les valeurs par défaut et la manière dont l’accès est évalué.
Mise à jour des autorisations, révocation des invitations en attente et suppression des utilisateurs de l’organisation.
Mis à jour