English 
Français 
Español 
Deutsch 
Português 
Italiano 
العربية Sécurité IoT
Une sécurité IoT fondée sur un contrôle d’accès précis
Kilo accorde l’accès par surface, pas par intitulé de poste : chaque utilisateur reçoit Modification, Lecture ou Aucun accès pour chaque partie de la plateforme, et un journal d’audit en ajout seul enregistre qui a changé quoi. Les organisations restent totalement isolées les unes des autres.
Contrôle d’accès
ABAC : des permissions par surface, pas des rôles tout-ou-rien
Le contrôle d’accès par attributs (ABAC) définit Modification, Lecture ou Aucun accès pour chaque surface produit, indépendamment.
Tableaux de bord, appareils, règles, connecteurs, abonnement, gestion des utilisateurs — chacun est une permission à part entière. Un ingénieur de déploiement obtient la modification sur les appareils et les connecteurs, mais aucun accès à la facturation. Un responsable des opérations modifie tableaux de bord et alertes tandis que le moteur de règles reste en lecture seule. Une partie prenante voit tout et ne change rien.
Aucun sélecteur de rôles qui finit par vous limiter : vous définissez exactement l’accès dont chaque personne a besoin, puis ajustez une surface donnée sans toucher au reste.
app.kiloiot.io · Organisation
Real productRôles et propriété
Contrôle d’accès IoT : des libellés de rôle calculés à partir des vraies permissions
Admin, Editor et Viewer sont des libellés que Kilo déduit de l’ensemble réel de permissions d’un utilisateur. Si les permissions correspondent à un modèle, le libellé s’affiche ; sinon, la table liste les surfaces individuelles. Rien ne se cache derrière un nom de rôle.
Owner (propriétaire)
Exactement un par organisation. La propriété est un attribut de l’organisation elle-même : elle donne un accès automatique partout et ne change de mains que par un transfert explicite, que le nouveau propriétaire doit accepter.
Admin
Modification sur toutes les surfaces, y compris l’abonnement et la gestion des utilisateurs. Le journal d’audit reste en lecture seule — pour les admins comme pour le propriétaire.
Editor (éditeur)
Modification sur les surfaces opérationnelles — tableaux de bord, appareils, règles — sans accès à l’abonnement ni à la gestion des utilisateurs.
Viewer (lecteur)
Lecture sur la plupart des surfaces : une visibilité complète sur le déploiement, sans possibilité de rien modifier.
Organisations
Des organisations qui isolent chaque déploiement IoT
Appareils, tableaux de bord, membres, permissions, historique d’audit — tout dans Kilo est rattaché à une organisation. Ce qui se passe dans une organisation est invisible pour toutes les autres.
Un même compte peut pourtant appartenir à plusieurs organisations : propriétaire de la vôtre, éditeur chez un partenaire, lecteur dans un environnement de test. Changer de contexte prend un clic — et vos permissions changent avec lui.
Les invitations portent les permissions
L’accès est défini avant même l’entrée : vous réglez chaque surface dans l’invitation elle-même. Les invitations ne visent que des comptes Kilo existants, restent valables 7 jours et peuvent être révoquées à tout moment.
Isolation par défaut
Chaque organisation a ses propres membres et son propre jeu de permissions. La même personne peut détenir des accès complètement différents selon l’organisation.
Changer sans se déconnecter
La liste « Mes organisations » affiche toutes vos appartenances, avec une coche sur l’organisation active. Votre dernière sélection est mémorisée à la prochaine connexion.
Traçabilité
Une sécurité IoT prouvable : journal d’audit et clés API
Contrôler qui entre n’est que la moitié du travail — l’autre moitié, c’est montrer exactement ce qui s’est passé ensuite.
Journal d’audit en ajout seul
Chaque événement d’appartenance et de permission est enregistré : qui a invité qui, qui a accepté, qui a été retiré — et les changements de permissions incluent la différence avant/après montrant exactement ce qui a changé. Le journal est en lecture seule pour tous, y compris le propriétaire : aucun chemin d’accès ne permet de le modifier ou de le supprimer.
- Différence avant/après sur chaque changement de permissions
- Lecture seule pour tous les utilisateurs — propriétaire inclus
- Filtres par acteur, type d’événement et période
Clés API à portée limitée
L’accès programmatique suit la même discipline. Chaque clé ne porte que les portées dont son intégration a besoin — lecture ou écriture, par ressource — avec une date d’expiration optionnelle. La valeur complète de la clé ne s’affiche qu’une seule fois.
- Rotation : nouvelle valeur émise, l’ancienne clé cesse immédiatement
- Révocation définitive — la clé reste visible pour l’historique
- Préfixe de clé et dernière utilisation dans la table
Kilo On-Premise
Le même serveur, auto-hébergé sur votre propre infrastructure — vos appareils, vos données et votre contrôle d’accès restent dans votre réseau.
Continuer la visite
Ce qu’un accès maîtrisé rend possible
FAQ
FAQ sécurité IoT
En quoi le contrôle d’accès de Kilo diffère-t-il des rôles fixes ?
Kilo utilise le contrôle d’accès par attributs (ABAC) : chaque surface produit — tableaux de bord, appareils, règles, connecteurs et plus — est réglée indépendamment sur Modification, Lecture ou Aucun accès. Admin, Editor et Viewer sont des libellés calculés à partir de l’ensemble réel de permissions ; les combinaisons personnalisées affichent simplement les noms des surfaces.
Un compte peut-il appartenir à plusieurs organisations ?
Oui. Un même compte peut être propriétaire d’une organisation, éditeur dans une autre et lecteur dans une troisième. Le changement se fait en un clic depuis la liste « Mes organisations », l’interface adopte immédiatement le nouveau contexte, et les organisations restent totalement isolées entre elles.
Qu’enregistre le journal d’audit ?
Les événements d’appartenance et de permissions : invitations envoyées et acceptées, changements de permissions — avec la différence avant/après — et retraits d’utilisateurs. Le journal est en ajout seul et en lecture seule pour tous, y compris le propriétaire ; personne ne peut modifier ni supprimer une entrée.
Que se passe-t-il si une clé API est compromise ?
Faites-la tourner — une nouvelle valeur est émise et l’ancienne clé cesse immédiatement de fonctionner — ou révoquez-la définitivement. Chaque clé étant limitée aux seules permissions nécessaires à son intégration, l’impact reste circonscrit, et les clés tournées ou révoquées restent visibles dans la table pour un historique complet.
Un contrôle d’accès que toute votre équipe accepte
Commencez gratuitement avec 5 appareils — invitez votre équipe avec exactement les permissions nécessaires, et suivez chaque changement dans le journal d’audit.