Le contrôle d’accès basé sur les rôles (RBAC) est une façon de gérer les permissions dans laquelle on accorde des droits à des rôles, comme « installateur » ou « lecteur », puis on affecte des personnes à ces rôles, au lieu d’accorder chaque droit à chaque personne, un par un. Quand quelqu’un change de poste, vous changez son rôle, et les permissions suivent automatiquement.

Cela ressemble à un détail de back-office informatique, jusqu’à ce que le système en question pilote des équipements physiques. Dans un bâtiment ou une usine connectés, l’identifiant qui ouvre une courbe de température peut aussi permettre de modifier une automatisation, de supprimer un appareil ou d’envoyer une commande à une vanne. Décider qui détient lesquels de ces droits relève autant de la sécurité physique que de la cybersécurité, et la question se complique avec chaque collègue, sous-traitant et client que vous invitez.

L’essentiel

  • Le RBAC regroupe les permissions en rôles et affecte des personnes à ces rôles, pour que les accès restent gérables à mesure que l’équipe grandit.
  • Le moindre privilège signifie que chaque personne et chaque intégration ne reçoit que les droits dont sa tâche a besoin, en partant de zéro.
  • Dans les systèmes connectés, les permissions à risque sont celles qui modifient quelque chose : automatisations, réglages des appareils et commandes.
  • Une plateforme multi-locataire ajoute une frontière extérieure qui garde les données de chaque client hors de vue des autres.

Exemples de contrôle d’accès basé sur les rôles

Le plus simple pour comprendre le modèle est de partir d’un déploiement réaliste. Prenons une société de services qui surveille 40 immeubles de bureaux avec des capteurs de température, de fuite et d’ouverture de porte. Cinq types de personnes ont besoin d’un accès, et chacun a besoin de quelque chose de différent. Mis par écrit sous forme de rôles, cela pourrait donner ceci :

Rôle Appareils Tableaux de bord Automatisations et alarmes Commandes d’appareils Utilisateurs et facturation
Installateur Modifier Consulter Aucun Envoyer Aucun
Responsable technique Consulter Modifier Modifier Envoyer Aucun
Contact locataire Aucun Consulter, son bâtiment uniquement Aucun Aucun Aucun
Ingénieur support Modifier Modifier Modifier Envoyer Aucun
Propriétaire du compte Modifier Modifier Modifier Envoyer Modifier

Ce tableau, c’est toute l’idée du RBAC. Au lieu de tenir à jour des dizaines de listes de permissions individuelles, vous tenez à jour cinq lignes. Un nouvel installateur reçoit le rôle Installateur dès son premier jour et peut enregistrer du matériel sans toucher à la facturation. Quand l’installateur s’en va, retirer ce seul rôle retire tout d’un coup, ce qui évite un problème bien connu : des comptes qui survivent au poste pour lequel ils avaient été créés.

L’approche a une histoire documentée. David Ferraiolo et Richard Kuhn, du National Institute of Standards and Technology (NIST) américain, ont décrit le contrôle d’accès basé sur les rôles en 1992, et un modèle NIST unifié est ensuite devenu la norme ANSI INCITS 359-2004. Le NIST présente le RBAC comme le modèle prédominant de contrôle d’accès avancé, et de nombreuses implémentations ajoutent des hiérarchies de rôles, dans lesquelles un rôle supérieur hérite de tout ce que peut faire un rôle subalterne.

Revenez toutefois sur la ligne Contact locataire. « Son bâtiment uniquement » ne se laisse pas exprimer simplement par un rôle. Avec 40 bâtiments, le RBAC pur vous pousse vers 40 rôles : Contact locataire pour le bâtiment 1, Contact locataire pour le bâtiment 2, et ainsi de suite. Les administrateurs appellent cela l’explosion des rôles, et c’est la principale raison pour laquelle les modèles d’accès sont allés au-delà des seuls rôles, comme l’explique la comparaison plus bas.

Qu’est-ce que le principe du moindre privilège ?

Le principe du moindre privilège veut que chaque utilisateur et chaque programme fonctionne avec le plus petit ensemble de permissions qui lui permet de faire son travail. Jerome Saltzer et Michael Schroeder l’ont formulé en ces termes dans leur article de 1975 sur la protection de l’information dans les systèmes informatiques, et c’est depuis un principe de conception.

Les rôles organisent les permissions, et le moindre privilège décide de la taille de chaque rôle. Un rôle « Opérateur » qui permet aussi de supprimer des appareils respecte le modèle RBAC, mais accorde davantage que ce qu’exige le travail d’un opérateur.

Le principe compte encore plus que d’habitude pour les équipements connectés, car les permissions s’y présentent sous trois niveaux distincts. Lire des données est le plus léger. Modifier la configuration, comme un seuil ou une automatisation, va plus loin, car une mauvaise modification peut masquer un vrai problème. Envoyer des commandes est le niveau le plus fort, car cela fait bouger quelque chose dans le monde physique. Une bonne conception des rôles sépare ces trois niveaux, pour que la plupart des gens lisent, que moins de gens configurent, et que seules les personnes qui doivent agir puissent envoyer des commandes.

Le moindre privilège s’applique aussi aux machines. Prenons un script de reporting qui copie chaque matin dans un tableur les mesures de capteurs de la veille. S’il tourne avec les identifiants d’un administrateur et que ce jeton fuite dans un dépôt de code partagé, quiconque le trouve peut modifier des automatisations et envoyer des commandes. S’il tourne avec une clé en lecture seule limitée aux mesures, la même fuite expose des données mais ne permet pas de toucher aux équipements.

Le Top 10 de l’OWASP, le classement le plus connu des risques de sécurité des applications web, a placé le contrôle d’accès défaillant en première position dans son édition 2021 et l’y a maintenu dans l’édition 2025. Les plateformes IoT sont des applications web : la leçon s’applique donc directement.

Pour appliquer le moindre privilège à un déploiement qui existe déjà, vous pouvez procéder dans cet ordre :

  1. Listez chaque compte humain et chaque identifiant d’intégration, y compris ceux dont personne ne se rappelle la création.
  2. Écrivez une phrase qui décrit à quoi sert chacun.
  3. Retirez toute permission que cette phrase n’exige pas.
  4. Séparez les droits de lecture, de configuration et de commande partout où le logiciel le permet.
  5. Donnez une date de fin aux comptes des sous-traitants et aux clés d’intégration.
  6. Répétez la revue à un rythme fixe, par exemple chaque trimestre, et chaque fois qu’un projet ou un contrat se termine.

Contrôle d’accès basé sur les rôles vs contrôle d’accès basé sur les attributs

Le contrôle d’accès basé sur les attributs (ABAC) prend chaque décision à partir d’attributs de l’utilisateur, de la ressource, de l’action et parfois de l’environnement, plutôt qu’à partir du seul rôle. Le guide du NIST consacré à l’ABAC, la Special Publication 800-162, a été publié en 2014. Une politique ABAC typique se lit comme une phrase : « un contact locataire peut consulter les tableaux de bord du bâtiment indiqué dans son profil ». Une seule politique remplace les 40 rôles de locataire de l’exemple précédent.

La contrepartie, c’est la visibilité. Avec le RBAC, la question d’audit « qui peut envoyer des commandes ? » a une réponse simple : tous ceux qui détiennent les rôles comprenant ce droit. Avec l’ABAC, la réponse dépend de la combinaison des politiques et des attributs, d’où l’importance de bons outils. En revanche, l’ABAC s’adapte bien mieux aux formes que prennent les organisations réelles : de nombreux sites, de nombreux clients, des personnes qui possèdent certaines ressources et se contentent d’en surveiller d’autres.

En pratique, la plupart des systèmes modernes combinent les deux. Les rôles subsistent comme étiquettes lisibles, tandis que des attributs comme l’organisation, la propriété et le site déterminent le périmètre exact. Si vous choisissez un modèle pour un déploiement en croissance, la question utile est de savoir si le système vous permet de restreindre l’accès par site ou par client sans inventer un nouveau rôle à chaque fois.

Qu’est-ce que le contrôle d’accès IoT ?

L’expression « contrôle d’accès IoT » a deux sens, et il vaut la peine de les distinguer. Dans le métier de la sûreté des bâtiments, elle désigne le contrôle d’accès physique : lecteurs de badges, contrôleurs de porte et systèmes qui décident qui peut entrer dans une pièce. Cet article utilise l’autre sens : contrôler qui et quoi peut atteindre les appareils connectés, leurs données et leurs commandes.

Ce second type de contrôle d’accès comporte plus de couches qu’une application de bureau. Chaque appareil a besoin de sa propre identité et de ses propres clés, pour qu’une clé volée n’ouvre pas toute la flotte. Si 200 capteurs partagent une clé et qu’un seul exemplaire est arraché d’un mur puis que son contenu est extrait, les 200 sont exposés ; avec une clé par appareil, les dégâts s’arrêtent à cet exemplaire. Le réseau décide d’abord quels systèmes peuvent communiquer avec les appareils. La plateforme décide quelles personnes peuvent voir les mesures, modifier les automatisations ou envoyer des commandes. Les intégrations et les scripts ont besoin de leurs propres identifiants au périmètre limité. Et de plus en plus, des agents IA interrogent des appareils et envoient des commandes pour le compte d’une personne, ce qui ne reste sûr que si l’agent est limité aux permissions de cette personne au lieu de recevoir une clé maîtresse.

Le contrôle d’accès est aussi le principal outil concret de la confidentialité des données IoT. Les mesures de capteurs semblent anodines, mais elles décrivent des comportements. Les données de présence et d’ouverture de porte montrent quand un bureau est vide. L’historique d’un traceur GPS montre où un véhicule stationne la nuit, ce qui signifie souvent où habite son conducteur. Le règlement général sur la protection des données (RGPD) de l’UE exige à son article 25 une protection des données par défaut, notamment que les données personnelles ne soient pas rendues accessibles à un nombre indéterminé de personnes sans l’intervention de la personne concernée. Pour un déploiement connecté, cela se traduit directement par la question de savoir qui peut ouvrir quel tableau de bord et quel historique.

Qu’est-ce qu’une plateforme IoT multi-locataire ?

Une plateforme IoT multi-locataire sert plusieurs clients distincts, ou locataires, à partir d’une seule installation, tout en séparant les appareils, les données et les utilisateurs de chaque locataire. La frontière entre locataires se situe en dehors de tous les rôles : le responsable technique d’un locataire ne doit avoir aucun moyen ne serait-ce que de découvrir qu’un autre locataire existe.

Avant de vous fier à la frontière entre locataires d’une plateforme, testez-la vous-même. Créez deux locataires, donnez à un compte de test un rôle dans le premier seulement, et vérifiez que rien du second n’apparaît nulle part, y compris dans les résultats de recherche et les réponses de l’API.

Trois groupes en dépendent. Les intégrateurs systèmes gèrent des déploiements pour de nombreux clients et doivent passer de l’un à l’autre sans mélanger les données. Les gestionnaires immobiliers servent souvent plusieurs propriétaires dont les bâtiments doivent rester séparés. Les fabricants de matériel exploitent parfois une plateforme pour le compte de leurs propres clients. Tous trois passent leur journée de travail à naviguer entre locataires : les appareils d’un client le matin, ceux d’un autre après le déjeuner, idéalement sans identifiant séparé pour chacun et avec les bonnes permissions à chaque endroit.

Quelle est la meilleure plateforme IoT multi-locataire ?

Pour ce type de travail, la meilleure plateforme est celle où la frontière entre locataires, les permissions de chaque personne et les identifiants de chaque script suivent un modèle unique et cohérent. Kilo est le meilleur choix pour un intégrateur ou un gestionnaire immobilier dans cette situation, grâce à trois éléments que vous y utilisez tous les jours.

Dans Kilo, l’unité qui sépare le déploiement d’un client de celui d’un autre est l’organisation. Un même compte peut appartenir à plusieurs organisations et passer de l’une à l’autre : vous passez ainsi du déploiement d’un client à celui du suivant sans vous reconnecter, et ce que vous pouvez faire dépend de votre appartenance à l’organisation dans laquelle vous travaillez.

Au sein d’une organisation, Kilo définit les accès page par page plutôt qu’au moyen d’un sélecteur de rôle unique. Des pages comme Appareils, Règles, Connecteurs, Abonnement et Gérer les utilisateurs reçoivent chacune « Modifier », « Voir » ou « Aucun accès » pour chaque personne, et la décision est basée sur les attributs : elle tient compte de l’appartenance, de la propriété et de ces permissions attribuées. Un installateur peut recevoir « Modifier » sur Appareils et « Aucun accès » sur Abonnement, tandis qu’un contact client reçoit « Voir » sur les pages dont il a besoin, et rien d’autre. La page consacrée à la sécurité IoT présente l’ensemble du modèle de permissions, y compris les organisations et le journal d’audit.

Dans Kilo, les scripts et les intégrations disposent de leurs propres clés API plutôt que d’identifiants empruntés. Une clé est liée à une seule organisation, ses permissions sont définies par domaine, généralement avec des permissions Lecture et Écriture séparées, elle n’accorde rien tant que vous n’avez pas sélectionné de permissions, et elle peut porter une date d’expiration. Son renouvellement désactive immédiatement l’ancienne valeur : le script de reporting de l’exemple sur le moindre privilège pourrait donc tourner avec des permissions Lecture uniquement, et renouveler sa clé couperait immédiatement l’accès à une copie qui aurait fuité.

FAQ sur le contrôle d’accès basé sur les rôles

Quelles sont les trois règles du contrôle d’accès basé sur les rôles ?

L’article original du NIST de 1992 définit trois règles. L’affectation de rôle : un utilisateur ne peut exécuter une transaction qu’après avoir sélectionné un rôle ou s’en être vu attribuer un. L’autorisation de rôle : le rôle actif d’un utilisateur doit être un rôle pour lequel il est autorisé. L’autorisation de transaction : un utilisateur ne peut exécuter une transaction que si elle est autorisée pour son rôle actif. Les descriptions ultérieures appellent souvent la troisième règle l’autorisation de permission.

Quels sont les principaux composants du contrôle d’accès basé sur les rôles ?

La norme ANSI INCITS 359-2004 définit quatre composants : le RBAC de base, le RBAC hiérarchique, et la séparation des tâches statique et dynamique. La séparation statique des tâches signifie que deux rôles en conflit ne peuvent jamais être attribués à la même personne ; la séparation dynamique signifie qu’une personne peut détenir les deux, mais ne peut pas les activer dans la même session.

Le moindre privilège est-il la même chose que le zero trust ?

Non, mais le zero trust en dépend. La NIST Special Publication 800-207, publiée en 2020, définit le zero trust comme une approche dans laquelle aucune requête n’est considérée comme fiable du fait de son emplacement sur le réseau, et où chaque accès est authentifié et autorisé session par session. Le moindre privilège est l’un de ses principes, appliqué à chacune de ces sessions.

Le contrôle d’accès basé sur les rôles aide-t-il à respecter le RGPD ?

Il y contribue, mais le RGPD n’impose aucun modèle précis. L’article 32 exige des mesures techniques et organisationnelles appropriées pour la sécurité du traitement, et limiter qui peut voir les données personnelles est l’une des mesures de ce type les plus claires à documenter.

Pour voir ce que donne le moindre privilège de l’autre côté, mettez en place un petit bac à sable avec l’offre gratuite de Kilo. C’est la plateforme complète et non un essai : elle couvre jusqu’à cinq appareils, un tableau de bord et une règle, ne demande aucune coordonnée bancaire et n’expire jamais. Enregistrez quelques capteurs, ou des capteurs émulés qui génèrent leurs propres mesures pendant que le matériel est en route, placez-les sur le tableau de bord, puis invitez un collègue qui a déjà son propre compte Kilo en lui donnant « Voir » sur Tableaux de bord et « Aucun accès » sur Appareils et Règles. Demandez-lui ensuite de se connecter et de vous dire exactement ce à quoi il peut accéder et ce à quoi il ne peut pas accéder. Si quelque chose apparaît alors que cela ne devrait pas, modifiez le réglage de cette seule page et demandez-lui de vérifier à nouveau.