A cette fin, les modèles de droits existants sont nombreux : MAC, DAC, GBAC, ABAC…

Comment comprendre concrètement ces multiples déclinaisons de modèles de droits et les appliquer à son entreprise ?

Les modèles diffèrent dans leur degré de complexité et dans la réponse qu’ils apportent à des besoins et contraintes spécifiques d’une organisation ou d’un système. Les plus récents intègrent des problématiques de sécurité, de scalabilité et de conformité dans un environnement technologique toujours plus complexe.

Dans cet article, nous suivrons une logique chronologique en identifiant comment l’autorisation a évolué au cours des décennies pour répondre aux défis des organisations. Nous verrons, que, comme les systèmes d’information, les approches de modèles de droits se sont complexifiées, et intègrent aujourd’hui de plus en plus de paramètres pour décider d’accorder ou de refuser un accès.

On peut ainsi regrouper les modèles selon 3 approches reflétant leur sophistication progressive :

• Approche classique : l’admin-time
• Approche moderne : run-time
• Approches prospectives : event-time

Nous illustrerons chacune de ces approches par des modèles emblématiques en mettant en évidence :

• la réponse apportée à un besoin initial
• les limitations du modèle.

Et conclurons notre propos par une synthèse chronologique des approches et de leurs modèles.

Approches classiques d’autorisation : Admin-time

Dans les années 60-70, le développement des systèmes informatiques, marqué par la mise au point des premiers systèmes multi-utilisateurs (Multics, HP-3000), fait naître la nécessité de repenser les droits des utilisateurs.

Des principes de sécurité innovants, encore utilisés aujourd’hui, sont ainsi définis sur ces systèmes, à l’instar des anneaux de protection (rings en anglais), qui d’une part, visent à protéger l’intégrité du système d’exploitation contre les modifications volontaires et accidentelles, et d’autre part, initient la réflexion sur les politiques d’accès aux ressources par les utilisateurs.

Dans les premiers modèles de droits d’accès qui émergent, la gestion des droits reste sommaire, définie en dur par des « administrateurs » : c’est l’admin-time, dont on retient en particulier les modèles DAC et MAC (années 60-70) et RBAC (années 90).

Discretionary Access Control (DAC) et Access Control Lists (ACLs)

Comme son nom le suggère, le modèle DAC – pour « contrôle d’accès discrétionnaire » – laisse à chaque propriétaire de ressource le soin d’attribuer les permissions aux utilisateurs. Il est le modèle de droits de base que l’on trouve sur les systèmes Unix, qui peut être complété par le mécanisme d’ACL, des « listes pour le contrôle d’accès ». Souvent associées à DAC, les ACLs spécifient, pour une ressource donnée, les utilisateurs et leurs droits sur la ressource, comme illustré ci-dessous sur l’exemple d’Unix.

Au-delà d’Unix, les systèmes de partage de fichiers tels que OneDrive ou encore les réseaux sociaux, où l’utilisateur peut choisir qui peut voir ou commenter chaque publication, sont d’autres exemples d’utilisation de DAC et des ACLs.

En effet, la flexibilité et la granularité de ce modèle constituent un avantage pour des implémentations locales et centrées sur les individus. En revanche, elles deviennent problématiques pour assurer un niveau correct de protection des ressources à large échelle sur des systèmes plus complexes.

Mandatory Access Control (MAC)

Le modèle MAC, pour « contrôle d’accès obligatoire », prend le contrepied de DAC. Plutôt que de laisser l’assignation des droits à la « discrétion » des utilisateurs, ressource par ressource, limitant la visibilité à l’échelle du système et favorisant de fait erreurs et failles, des règles sont prédéfinies par des administrateurs selon différentes classifications de sécurité et appliquées de façon stricte par une autorité centrale, généralement représentée par le système d’exploitation lui-même.

Il prévaut en particulier dans les milieux gouvernementaux, militaires ou industriels, car il permet un contrôle étroit de l’accès aux données sensibles. Il utilise ainsi des labels qui caractérisent la sensibilité des objets et des utilisateurs, selon les règles de l’organisation concernée :

• Un niveau de classification des ressources, par exemple : « Non classifié », « Restreint », « Confidentiel », « pointe de diamant »[1], …
• Un niveau d’habilitation des utilisateurs, liés aux niveaux de classification des ressources existants.

Nous détaillons ci-dessous Multics et SELinux, qui sont deux exemples fondamentaux d’implémentation de MAC.

Exemple MAC 1 : Multics et les anneaux de protection

Déjà évoqué précédemment comme un précurseur des systèmes multi-utilisateurs (également dits « à temps partagé »), le projet Multics, sorti en 1969, a été porteur de multiples fonctionnalités innovantes, notamment dans sa gestion de la mémoire ou de la sécurité. Il préfigure ainsi MAC avant même la formulation de modèles tels que Bell-LaPadula (1973) et sa première définition formelle énoncée dans le « Orange Book » (1983) du Department of Defense, qui établit les normes de sécurité informatiques américaines.

Il repose sur le concept d’anneaux de protection (rings), que Multics a créé, en témoigne son logo (image ci-dessus), et qui constituent le fondement des systèmes MLS – Multi-Level Security –, très utilisés dans les contextes de haute confidentialité. Il s’agit d’un ensemble d’anneaux concentriques représentant des niveaux de sensibilité d’autant plus élevés que l’on se rapproche du centre (ring 0) – et donc de privilèges requis pour y accéder. Des mécanismes dits guards ou gatekeepers, situés à l’interface entre deux anneaux, contrôlent étroitement la légitimité des accès dans les deux sens, qu’ils accordent ou réfutent.

En réalité, ces anneaux sont de deux types :

• Les anneaux de protection du kernel sont des anneaux physiques intégrés aux processeurs et exploités par le système d’exploitation pour garantir son intégrité contre les fautes (à l’origine de plantages de la machine) ou des modifications, intentionnelles ou non.
• Les anneaux de l’espace utilisateur sont des anneaux logiques mis en œuvre par le système d’exploitation. C’est là que l’on retrouve MAC. Par le biais de labels, chaque utilisateur et chaque ressource se retrouve rattaché à un niveau d’anneau. De là, des règles définissent les actions possibles ou non, à l’instar du modèle Bell-LaPadula qui met l’accent sur la confidentialité des données : « No read up » (un utilisateur ne peut accéder en lecture à des couches supérieures à la sienne), « No write down » (il ne peut non écrire dans des couches inférieures, évitant les fuites).

L’image ci-dessous résume le principe des anneaux de protection.

Exemple MAC 2 : SELinux, module de sécurité du noyau Linux

Initialement développé par la NSA, en 2001, SELinux a été proposé et ajouté dès 2003 aux modules de sécurité pour le noyau Linux (LSM, Linux Security Modules), et est nativement intégré aux distibutions RedHat, telles que Fedora.

C’est un autre exemple notoire d’implémentation de MAC : il permet aux administrateurs d’attribuer à chaque ressource un label security context afin de les classifier, et de définir les politiques de sécurité qui seront appliquées par le système d’exploitation. Même avec des droits privilégiés, une application verra ses droits cantonnés au domaine qui lui est nécessaire pour fonctionner (par exemple les dossiers qui ont été lui spécifiés), SELinux détectant et empêchant toute action non conforme.

SELinux apporte donc une couche de protection supplémentaire dans le cas où un utilisateur ou un processus parvient à contourner les contrôles d’accès traditionnels.

Dans la pratique, les politiques MAC se suffisent rarement à elles-mêmes mais viennent se superposer aux règles DAC existantes, dont elles pallient la flexibilité. Deux modèles avant tout fondés sur l’identité de l’utilisateur ou du processus, à partir de laquelle ils autorisent ou refusent des accès : on parle de contrôle d’accès basé sur l’identité ou IBAC (Identity-Based Access Control). Ces modèles restent limités à des contextes locaux qui résistent peu au passage à l’échelle.

Role-based Access Control (RBAC)

Formulé en 1992 par David FERRAIOLO et Richard KUHN, deux ingénieurs du NIST américain, le modèle RBAC – modèle d’accès basé sur les rôles – a été pensé pour simplifier la gestion des permissions à l’échelle d’une organisation tout en en reflétant au mieux la structure (hiérarchie, responsabilités, départements…).

Au lieu d’octroyer les droits directement à une identité comme avec IBAC, une méthode vite difficile à maintenir, on conçoit des rôles métier et les privilèges associés. L’utilisateur hérite alors des droits rattachés à son rôle au sein de l’entreprise, ce qui lui permet d’accéder aux différents applicatifs et systèmes de partage d’entreprise considérés comme nécessaires pour ses activités internes.

Ce premier cadre conceptuel a été complété et standardisé en 2004 avec la norme ANSI INCITS 359-2004, qui tient compte de cas pratiques et scénarios d’entreprise. Par exemple, il aborde les besoins en séparation des responsabilités (SoD, Segregation of Duty), fondamentale dans les institutions financières et bancaires, mais aussi le principe de moindre privilège, ou encore l’héritage des permissions.

Une adoption progressive et toujours plus centralisée de RBAC

Dès les années 80-90, largement adoptées par des grandes entreprises et susceptibles de contenir des informations sensibles dont on a naturellement voulu contrôler l’accès, les bases de données ont été pionnières dans la mise en œuvre du modèle RBAC. Elles illustrent son implémentation au niveau d’applications isolées, non répercutée sur les applications ou systèmes externes.

Les années 2000 voient le lancement de l’Active Directory de Microsoft, à partir du Windows 2000 Server. Cet annuaire centralisé vise la gestion de l’ensemble des ressources de l’organisation (personnes, ressources physiques, applicatifs). Bien que ce ne soit pas à proprement parler un outil RBAC, un rapprochement peut être fait. L’attribution de droits d’accès se base en effet sur des groupes de sécurité – qui peuvent être perçus comme des rôles – avec des mécanismes d’héritage de permissions et des concepts de domaines, arbres et forêts visant à représenter les structures logiques d’entreprise.

Depuis, les solutions IAM modernes, comme Okta, SailPoint IIQ ou Microsoft AzureAD, supportent RBAC pour des environnements hétérogènes, notamment les services cloud. Elles illustrent la centralisation progressive de la gestion des droits d’accès, d’abord gérée localement dans les applications, et aujourd’hui de plus en plus déléguée à des solutions IAM couvrant un spectre maximal.

RBAC attribue des droits en fonction d’un rôle métier tandis qu’IBAC est lié à une identité. La couche d’abstraction créée entre l’identité du sujet et son rôle permet de s’extraire de contextes restreints (systèmes de fichiers pour DAC, systèmes d’exploitation pour MAC) et de s’adapter (enfin !) aux besoins de contrôle d’accès d’organisations. Tous partagent néanmoins comme caractéristique une définition rigide des droits, basée sur une identité ou un rôle.

Dans des entités où les échanges sont plus dynamiques et plus fluctuants, cette abstraction au travers de rôles seuls peut s’avérer insuffisante. De nouveaux modèles ont émergé pour représenter des organisations plus complexes, prenant en compte des attributs supplémentaires, évolutifs, pour évaluer plus finement un droit d’accès à un instant t : de l’admin-time, nous entrons dans le run-time.

Les nouvelles approches d’autorisation : Run-time

La complexification des systèmes d’informations, donc des accès, ont conduit à l’approche run-time. Une approche qui répond aux besoins de flexibilité et de sécurité dynamiques des organisations. Contrairement à l’ère “admin-time”, caractérisée par des permissions statiques, l’ère “run-time” offre une gestion en temps réel au moment de la demande d’accès, fondée sur différents éléments contextuels. Cette transition vers des modèles d’autorisation plus flexibles et précis permet aux organisations de s’adapter aux changements et de mieux protéger leurs ressources contre les menaces actuelles.

Graph-Based Access Control (GBAC)

Le modèle GBAC (Graph-Based Access Control) ou GraphBAC, repose sur l’utilisation de graphes pour représenter les relations entre les utilisateurs, les rôles et les ressources au sein d’une organisation. Ces 3 types d’entités (utilisateurs, rôles, ressources) et les relations entre elles constituent le cœur de ce modèle : on peut représenter les entités par les nœuds du graphe, et les relations entre elles par les arêtes.

Les autorisations d’accès à une ressource sont déterminées en temps réel par des requêtes sur cette base de données de graphe, permettant de prendre des décisions d’accès basées sur les connexions entre les entités au moment de la demande. Un utilisateur peut ainsi obtenir l’accès à une ressource en fonction de son rôle et de ses relations avec d’autres utilisateurs ou ressources de l’organisation

Le modèle GBAC est adapté aux environnements dynamiques de grandes organisations, où les relations entre entités évoluent constamment. En revanche, sa mise en œuvre peut s’avérer complexe et les projets de mise en place sont relativement longs donc avec des coûts élevés non négligeables. De plus, l’ajout progressif de nouvelles relations peut rendre le graphe de plus en plus difficile à gérer, compliquant ainsi les activités d’audit interne ou encore de recertification par exemple.

Attribute-Based Access Control (ABAC)

Dans le modèle d’accès ABAC (Attribute-Based Access Control), la gestion des accès à une ressource s’appuie sur la combinaison dynamique d’attributs. Ces attributs concernent aussi bien l’utilisateur demandant l’accès (rôle, groupe), la ressource demandée (type de ressource), que le contexte dans lequel s’effectue la demande (heure, type de réseau). Cette approche permet d’autoriser ou non l’accès de façon flexible et en temps réel.

Le modèle a été formalisé en 2014 dans la publication par le NIST (SP 800-162) qui fournit des informations détaillées pour sa mise en place.

4 composants sont essentiels au fonctionnement de ce modèle : les Policy Enforcement Points (PEP), les Policy Decision Points (PDP), les Policy Administration Points (PAP), et les Policy Information Points (PIP).

Après interception par le PEP, la demande d’accès est transmise au PDP, qui est responsable de la prise de décision en analysant les politiques d’accès qui sont gérer au niveau du PAP et souvent accessible depuis une base de données de politique d’accès. Le PIP fournit lui, au PDP des informations complémentaires sur l’utilisateur ou la ressource provenant de différentes sources permettant ainsi de rendre des décisions conformes aux règles d’accès. Pour les informations contextuelles le système d’information peut être connecter à d’autres outils ou sources (IDS, logs, capteurs) qui permettent la collecte de ces informations au moment d’une demande d’accès.

L’ABAC se présente comme un modèle particulièrement intéressant dans les environnements où les besoins d’accès sont variés et évolutifs, car il permet une gestion fine et granulaire des autorisations, notamment dans le cadre du PAM (Privileged Access Management), concernant des accès, et ressources critiques.

Cependant, ce niveau de détail et de flexibilité vient avec des défis comme la revue continue des attributs, la maintenance des politiques qui nécessitent une attention constante afin de s’assurer qu’ils répondent aux besoins de l’entreprise. Au fil du temps, le nombre croissant d’attributs et de conditions peut compliquer le maintien d’une architecture ABAC claire et fonctionnelle, surtout dans des environnements en perpétuelle transformation.

Dans les architectures ABAC actuelle, les PEPs sont généralement conçus pour fonctionner uniquement avec les PDPs du même fournisseur, avec des protocoles propriétaires, sans support pour une compatibilité entre différents fournisseurs.

Standardiser la manière dont ces différents PEP et PDP interagissent, afin d’améliorer l’interopérabilité des systèmes et de réduire la dépendance à un seul fournisseur est l’objectif du groupe de travail OpenID AuthZEN.

OpenID AuthZEN : Vers une interopérabilité améliorée

AuthZen est une initiative lancée en 2023, au travers d’un groupe de travail, par l’OpenID Foundation visant à standardiser les interactions entre les PEPs et les PDPs afin d’améliorer l’interopérabilité entre les systèmes de différents fournisseurs.

Cette initiative répond aux problèmes actuels où les services d’autorisation (PEP et PDP) sont souvent conçus pour fonctionner uniquement avec des solutions du même fournisseur, limitant leur interopérabilité.

AuthZen a été lancée pour développer un protocole standardisé qui faciliterait l’intégration et la communication entre les PEPs et les PDPs, et réduirait la dépendance aux solutions provenant d’un seul fournisseur mais aussi d’améliorer la sécurité globale des autorisations.

Pour rendre ces interactions plus flexibles et universelles, AuthZen s’appuie sur des architectures et des technologies existantes (OPA/Rego, XACML…), afin d’améliorer le déploiement, la scalabilité et l’interopérabilité. Les deux premières étapes de cette standardisation avec l’Open ID AuthZen sont la mise en place d’un protocole simple de type “Request/Response” et “Permit/Deny” et d’une approche de décisions multiples afin de regrouper plusieurs demandes d’autorisation en une seule et de recevoir plusieurs décisions en retour.

Ce cadre de réflexion autour de l’AuthZen comprend des acteurs du domaine de la sécurité tels que 3Edges, Axiomatic, et d’autres. Il est également ouvert aux acteurs voulant faire évoluer les systèmes d’autorisation et rendre les architectures plus sécurisées et interopérables.

Perspectives d’évolution d’autorisation : Event-time

Une nouvelle approche dans l’évolution des systèmes d’accès est l’event-time. Il se défini comme une implémentation de l’autorisation dynamique où les droits des accès sont ajustés en temps réel en réponse à des événements ou changements immédiats qui surviennent. Contrairement aux approches statiques ou basées sur des attributs, l’event-time se caractérise par une évaluation continue des droits d’accès, afin de s’assurer que tous les accès restent conformes aux politiques en place dans l’organisation.

Par exemple, lorsque l’état d’un utilisateur change (promotion, départ, mobilité, etc.), le système ajuste ou révoque automatiquement ses droits d’accès. Cette approche d’ajustement proactive basée sur des évènements est courante dans la surveillance des systèmes d’informations et la gestion des incidents de sécurité.

L’event-time repose sur des concepts clés qui sont :

• Les écouteurs (listeners), des composants du système surveillant les évènements en temps et analysant les changements importants (mobilité, promotions, départ, etc.) provenant de diverses sources notamment systèmes RH.
• Les déclencheurs (triggers), des actions en réponse à un événement identifié par un écouteur comme la révocation des droits d’accès au jour effectif de départ d’un utilisateur.
• Shared Signals (Signaux partagés), permettant à différents systèmes de partager des informations sur des événements en temps réel.
• L’évaluation continue est la vérification constante des droits d’accès pour s’assurer que chaque action ou accès reste en conformité avec les politiques.

Les frameworks et standards jouent un rôle clé dans l’implémentation de l’event-time en fournissant une structure pour la mise en œuvre les concepts dans les systèmes :

Le Shared Signals Framework (SSF) est directement lié au concept de shared signals, qui permet aux systèmes via une API de partager des informations sur les événements en temps réel pour assurer une gestion cohérente des accès. L’évaluation continue de ces informations est soutenue par le CAEP (Continuous Access Evaluation Protocol), un protocole permettant de standardiser l’écriture des changements de statut. Le RISC (Risk and Incident Sharing and Coordination) est un protocole générique qui lui permet la standardisation de la transmission et la réception des incidents de sécurité entre ces différents systèmes, renforçant ainsi la réactivité globale d’un système d’information.

L’event-time ne repose pas sur un modèle spécifique de type RBAC ou ABAC mais peut fonctionner comme une couche de gestion des accès complémentaires à ces systèmes d’accès traditionnels en les rendant plus dynamiques et alignés sur les situations en temps réel.

L’évolution des modèles d’autorisation, des approches traditionnelles aux méthodes modernes et dynamiques, reflète l’adaptation continue de l’IAM et des systèmes d’accès aux besoins croissants et changeants des organisations.

Les approches admin-time ont posé les bases de la sécurité des ressources avec des modèles tels que le DAC et le MAC. Le RBAC a introduit une gestion structurée des droits, largement adoptée dans les organisations aujourd’hui du fait de son application relativement simple.

Avec l’avènement du runtime, les décisions d’accès se sont affinées en s’appuyant sur des attributs spécifiques aux utilisateurs, aux ressources et au contexte, comme avec les modèles ABAC et GBAC. Cependant, ces modèles toujours plus sophistiqués ont conduit à l’apparition de nombreux éditeurs de solutions propriétaires, limitant l’interopérabilité des composants d’autorisation et créant une dépendance envers des technologies spécifiques. C’est ainsi qu’ont émergé des initiatives telles que le groupe de travail AuthZen œuvrant à l’élaboration de standards.

L’approche event-time apporte une réactivité en temps réel, permettant aux systèmes d’ajuster automatiquement les accès en réponse à des événements spécifiques. Le CAEP et le Shared Signals Framework facilitent cette dynamique en standardisant l’échange d’informations entre systèmes, renforçant ainsi la sécurité et la conformité.

Une vue d’ensemble de ces différentes approches et de leurs modèles associés est présentée dans la frise chronologique ci-dessous, accompagnée d’un tableau récapitulatif des différents modèles abordés. 

En combinant ces différentes approches, vous pouvez mettre en place une gestion des accès plus sécurisée, flexible et proactive, capable de répondre aux défis actuels et futurs liés à l’identité. Ces évolutions soulignent également l’importance d’adopter des solutions d’autorisation adaptatives et interopérables pour assurer une protection efficace des ressources tout en répondant aux exigences opérationnelles des équipes.

Ces évolutions posent une question essentielle sur la capacité des organisations à anticiper ces changements et intégrer ces nouvelles dynamique de la gestion de leur accès.

 Que vous utilisiez encore des modèles admin-time, exploriez des options runtime, ou envisagiez de passer à une gestion event-time, il est crucial de choisir un modèle qui répond à vos enjeux spécifiques. Il est aussi très important d’anticiper les conséquences sur la gestion dans le temps de ce modèle (revue de droits, mesure de la qualité des données, revue des politiques, définition des réactions attendues, etc.). 

Et vous quel type de modèle utilisez-vous ?  

N’hésitez pas à nous contacter pour en savoir plus et comprendre concrètement comment les appliquer en fonction du contexte de votre organisation !

[1] Habilitation de sécurité en France, Wikipédia (wikipedia.org)

Cet article Gestion des accès : comment l’autorisation évolue pour répondre aux défis et besoins des organisations ? est apparu en premier sur RiskInsight.

Azure, ces dernières années, s’impose de plus en plus dans ce secteur, comme a pu le souligner le Gartner, qui les classe dans les leaders visionnaires des plateformes IIoT [1] en raison de ses capacités, et de sa couverture quasiment complète de tous les cas d’utilisation et secteurs d’activité.

L’IoT, par nature souvent largement exposé, voire sur Internet, peut-être la cible d’attaques.

Avant de passer à des recommandations spécifiques pour protéger vos dispositifs IoT et vos données, examinons comment les différents services d’Azure IoT peuvent être utilisés ensemble pour créer des solutions IoT sécurisées.

Présentation de l’offre Azure IoT

Microsoft Azure IoT est une plateforme de bout en bout pour la connectivité, l’analyse et la visualisation de données provenant d’appareils IoT. Elle offre également une interconnexion avec les autres services standards d’Azure comme Azure Machine Learning ou encore Azure SQL Database.

Azure IoT propose deux écosystèmes de solutions à ses clients :

• Azure IoT Central est une aPaaS, application Platform as a Service, entièrement managée qui simplifie la création de solutions IoT. Ce service est responsable de connecter, gérer et exploiter des flottes d’appareils, et fournit à une interface utilisateur de gestion. Azure IoT Central est en réalité un agrégat de différents services Azure IoT comme Azure IoT Hub ou encore Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central propose des modèles d’application selon plusieurs domaines d’activité : Retail, Santé, Energie, Industrie, etc., et vise une mise en œuvre « clés en main ».  

• Un écosystème personnalisé grâce aux différents services PaaS, Platform as a Service, d’Azure. Dans cet écosytème, deux services ; Azure IoT Hub et Azure Digital Twins sont les fondations d’une solution IoT. Nous les avons également combinés à Azure Device Provisionning et Azure Device Update pour une couverture des besoins cybersécurité optimale.

Ces deux écosystèmes permettent à Azure de répondre à tous types de besoins IoT et IIoT :

• Azure IoT Central est un très bon service si vous souhaitez développer rapidement une application peu complexe grâce à son catalogue de modèle d’application.
• Si vous souhaitez une solution personnalisée, ou avec des fonctionnalités non supportées par Azure IoT Central : optez pour un écosystème fondé sur Azure IoT Hub.

Maintenant que nous avons une bonne compréhension des écosystèmes d’Azure IoT, il est important de se concentrer sur la sécurisation de ces écosystèmes. Comment protéger efficacement des dispositifs IoT et des données lors de l’utilisation des services Azure IoT ? C’est ce que nous allons étudier dans les prochaines parties.

Préambule : l’outil Azure CLI

Afin de gérer des ressources Azure, Microsoft met à disposition plusieurs outils, la plupart étant utilisables en CLI (Command Line Interface, ou en lignes de commandes). L’outil proposant le plus de fonctionnalités pour la gestion étant Azure CLI.

Cet outil, disponible pour les systèmes d’exploitation de type Windows et UNIX, permet notamment à un utilisateur membre d’un environnement Azure de gérer et d’obtenir des informations concernant des ressources Azure. Il est à noter que l’éventail des possibilités de cet outil varie en fonction des droits que possède l’utilisateur sur les ressources en question.

Pour l’installer, Microsoft met à disposition une page dédiée expliquant les étapes pour tout type d’environnement.

Afin de l’utiliser, il suffit de se connecter à un compte utilisateur Azure via l’interface de commande choisie (Powershell ou Bash), puis d’entrer les commandes voulues. Lorsque l’utilisation de cet outil est terminée, une déconnexion du compte est recommandée.

Une utilisation classique de cet outil est présentée ci-dessous :

La documentation de cet outil, présentant et expliquant l’ensemble des commandes possibles, est disponible à cette adresse.

Cet outil sera utilisé par la suite lors d’exemple de manipulations techniques.

1^er vecteur de sécurisation : authentification des objets

L’authentification des appareils est cruciale pour une infrastructure Azure car elle permet de garantir que seuls les dispositifs autorisés puissent accéder aux ressources Cloud. Les services Azure IoT supporte deux principaux moyens d’authentification pour les dispositifs IoT :

• Un Jeton SAS (Shared Access Signature, ou SAS Token en anglais) est une chaine de caractères permettant d’authentifier des appareils, ainsi que des services. Un jeton SAP à la structure suivante :

Ce type d’authentification a une durée de validité définie et des permissions, qui lui sont attribué à partir d’une stratégie d’accès, sur un périmètre donné. La signature, quant à elle, est un élément crucial car elle est responsable de garantir la sécurité des communications entre l’objet et les services Azure, mais également de prouver l’identité du dispositif. Cette signature est générée à partir d’un secret qui doit être propre à chaque appareil.

• Un certificat X.509 [2] est un certificat numérique permettant une authentification forte de l’objet. Il contient des informations sur l’entité émettrice du certificat, la durée de validité du certificat mais également l’identité du sujet (par exemple : l’objet). L’une des forces des certificats est la capacité à pouvoir créer des chaines de certificats, et ainsi créer des relations de confiance:

En termes de sécurité, les certificats X.509 offrent un niveau de sécurité plus élevé, en supposant un algorithme cryptographique à l’état de l’art, car ils permettent de représenter des relations de confiance. Cependant, la gestion et l’utilisation des certificats peut impliquer une complexité supplémentaire pour un projet IoT.

Afin de forcer l’utilisation des certificats X.509 pour authentifier des objets connectés, il est possible d’interdire les jetons SAS pour un IoT Hub. En effet, les IoT Hubs d’Azure possèdent trois propriétés liées à l’utilisation ou non des jetons SAS :  disableLocalAuth, disableDeviceSAS et disableModuleSAS. Par conséquent, la bonne pratique associée à l’interdiction des jetons SAS passe par l’attribution de ces trois paramètres à True. Cette manipulation peut être réalisée à l’aide de l’outil Azure CLI :

La vérification des valeurs de ces mêmes paramètres peut également être réalisée à l’aide d’Azure CLI :

Dans l’exemple de réponse ci-dessous, la propriété disableDeviceSAS a été correctement paramétrée, ce qui n’est pas le cas des deux autres.

Le portail d’Azure permet également d’effectuer cette vérification :

Le choix du moyen d’authentification pour Azure IoT dépendra des exigences de sécurité de votre solution. Si vous avez besoin d’une sécurité élevée et que vous avez une infrastructure pour gérer les certificats, alors l’authentification par certificat X.509 est une bonne option. Cependant, si vous recherchez une solution simple à gérer et à utiliser, le jeton SAS pourrait être plus adapté à vos besoins.

2^ème vecteur de sécurisation : RBAC et alertes

L’assignement des rôles sur votre infrastructure Azure IoT doit être réfléchi et défini selon les besoins des utilisateurs. Une définition de rôles et de permissions précise permet de limiter l’accès aux ressources et aux divers fonctionnalités disponibles sur la plateforme. Les différents services Azure IoT fournissent une multitude de rôles préconfigurés qui peuvent être adaptés à vos besoins et à votre organisation. Ensuite, appliquer le principe du moindre privilège, et limiter le nombre de comptes disposant de privilèges importants, permet d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Azure CLI permet notamment de lister les utilisateurs possédant des droits sur la ressource Azure IoT souhaitée, ainsi que leurs rôles associés. La commande suivante permet de réaliser cette action :

Il est possible d’utiliser des sélecteurs de chaînes de caractères (Select-String pour Powershell, grep pour Bash) afin de ne récupérer que les informations souhaitées.

Dans l’exemple ci-dessous, les noms, types et rôles ont été les seuls éléments récupérés à l’aide de Select-String :

La fonction des rôles intégrés Azure est disponible à cette page.

De plus, la configuration d’alertes basées sur les métriques de vos services Azure IoT est un autre outil à prendre en compte. Des alertes peuvent être configurées pour détecter des comportements suspects ou des anomalies, et ainsi permettre une investigation rapide sur votre infrastructure. Azure met à la disposition de ses clients une large collection de signaux permettant de définir des conditions d’alertes. Il est également possible de définir des signaux d’alertes customisés via le langage de requête utilisé par Azure Log Analytics.

Le Portail Azure est le moyen le plus facile pour mettre en place des alertes basées sur les données collectées par le IoT Hub. Par exemple, pour définir une règle d’alerte de journal, il faut :

1. Aller sur la page de management du IoT Hub souhaité ;
2. Aller dans la sous-catégorie Logs de la catégorie Monitoring;
3. Choisir une règle en utilisant le langage de Azure Log Analytics ;
4. Ajouter une règle d’alerte liée à cette requête ;
5. Choisir l’opérateur, l’unité, la valeur seuil, la récurrence de vérification et la période concernée par la règle.

Ces actions sont résumées par les captures d’écran ci-dessous :

Il suffira ensuite de choisir un groupe d’action lié à un type d’action (envoi de mail, de SMS, etc.).

L’exemple donné entrainera une action si le nombre de connexions échouées d’objets connectés à l’IoT Hub concerné dépasse les 10 échecs en 10 minutes ou moins.

En complément, un guide détaillé prenant la forme d’un tutoriel est disponible sur la documentation Azure. Il est à noter que ce service est payant en supplément.

3^ème vecteur de sécurisation : le service en lui même

Enfin, la mise en place d’une configuration adéquate des services Azure IoT est un autre élément clé pour améliorer le niveau de maturité cyber de la plateforme. Cela inclut des options telles que par exemple les règles de routage ou encore paramétrer la version minimum de TLS utilisé par les appareils pour se connecter sur Azure IoT Hub.

Les règles de routage sont utilisées pour rediriger les messages des appareils IoT vers un point de terminaison (stockage, services, base de données, etc.) et sont paramétrables par des requêtes de routage. Il est recommandé de filtrer les messages entrants, via les requêtes de routage, afin d’augmenter la sécurité de votre solution IoT.

La vérification de la version minimale de TLS acceptée peut être faite à l’aide d’Azure CLI : en effet, un IoT Hub possède l’attribut minTlsVersion permettant de contrôler cette propriété. Cette vérification est réalisée à l’aide de la commande suivante :

Si cette commande ne retourne rien, ou retourne une valeur inférieure à 1.2, alors la configuration n’est pas satisfaisante.

Le portail d’Azure permet également d’effectuer cette vérification :

En synthèse

La sécurité est un enjeu majeur pour les projets IoT : Microsoft, avec son produit Azure IoT, fournit une plateforme IoT répondant à une majorité des besoins IoT, et ce de manière sécurisée, sous couvert d’en faire la bonne configuration. Au cours de cette article, nous avons abordé des recommandations permettant d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Il est important de garder en tête que d’autres vecteurs d’attaques existent, tels que les vulnérabilités matérielles et logicielles ainsi que les réseaux utilisés par les dispositifs IoT.  En somme, la sécurité d’une infrastructure IoT est un défi complexe qui nécessite une approche de bout en bout.

Avec la participation de Marius ANDRE

[1] “Magic Quadrant for Global Industrial IoT Platforms”

https://www.gartner.com/doc/reprints?id=1-2BQFX3BJ&ct=221116&st=sb

[2] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

https://www.rfc-editor.org/rfc/rfc5280

Cet article Améliorer la sécurité de son infrastructure IoT : conseils de configuration et bonnes pratiques sur Azure IoT est apparu en premier sur RiskInsight.

DAC, RBAC, OrBAC, ABAC ou encore GraphBAC ? Les modèles d’habilitation phares évoluent régulièrement et apportent chacun leur lot d’enjeux, de promesses et de complexité.

Depuis une vingtaine d’années au cours desquelles les modèles RBAC/OrBAC semblent s’être imposés, les difficultés de conception, d’implémentation et de maintenance d’un modèle d’habilitation sont restées les mêmes, et rares sont les exemples de réalisation parfaitement satisfaisants.

Vouloir refondre son modèle d’habilitation amène à se poser beaucoup de questions. Nous essayons au travers de deux articles de répondre aux plus fréquentes.

Mais avant cela, revenons sur quelques notions de base concernant les modèles d’habilitation.

Qu’est-ce qu’un modèle d’habilitation ?

Une couche d’abstraction…

Un modèle d’habilitation est une couche d’abstraction qui vient se placer au-dessus des permissions techniques (droits applicatifs, transactions, groupes…). Elle est constituée d’objets soigneusement définis (rôles, permissions…), disposant d’un nom en langage naturel, et souvent organisés hiérarchiquement.

…qui simplifie la gestion des habilitations…

Cette couche d’abstraction permet notamment de rationaliser le nombre d’objets à manier.

Pour le Métier, il devient plus facile de comprendre les habilitations disponibles et de demander ou valider les droits adéquats.

Pour les équipes IT et le support, la charge d’attribution des habilitations s’en retrouve globalement réduite. La mise en place d’outils d’automatisation peut prendre en charge une grande partie des demandes quotidiennes, ce qui permet de traiter les demandes spécifiques avec plus d’attention.

… et améliore la sécurité

Au-delà de la dimension réglementaire et normative de la maîtrise des habilitations, souvent rappelée par les Commissaires aux Comptes lors de leurs audits, le manque de contrôle des habilitations est une porte ouverte aux intrusions et aux mauvaises utilisations du SI.

La connaissance de ses habilitations est un prérequis à leur sécurisation, et la mise en place d’un modèle permet de simplifier les contrôles, notamment lors des campagnes de revue. Il est en effet bien plus aisé pour un manager de valider l’attribution d’un rôle métier parlant, que celle d’une transaction à la dénomination très technique.

Panorama des modèles possibles

DAC : Discretionary Access Control, ou pas de modèle !

Et si le meilleur modèle était l’absence de modèle ? Dans certains cas limités, en particulier si le nombre de permissions ou d’utilisateurs est très restreint, on peut très bien se passer de concevoir un modèle qui viendrait ajouter une couche de complexité non nécessaire. Cela suppose néanmoins que les permissions applicatives soient suffisamment explicites.

RBAC : Role-Based Access Control

Le modèle RBAC permet de regrouper en « rôles » les habilitations nécessaires à l’exercice d’une fonction au sein une entreprise (métier, mission, projet…). Ces rôles sont alors attribués en lieu et place des habilitations discrétionnaires. Ils peuvent être organisés hiérarchiquement, par exemple en subdivisant des « rôles métier » en « rôles applicatifs ».

OrBAC : Organization-Based Access Control

Le modèle OrBAC est une variante du modèle RBAC dans laquelle les entités qui composent une entreprise sont un des axes de modélisation. Chaque utilisateur a alors un ou plusieurs rôles en fonction de son appartenance à une direction, un service ou une équipe.

ABAC : Attribute-Based Access Control

L’attribution des habilitations via le modèle ABAC se fait grâce à un ensemble de règles qui se basent sur des attributs liés aux utilisateurs, aux ressources elles-mêmes, ou bien à l’environnement. Cette attribution est souvent « dynamique », c’est-à-dire que l’autorisation ou non d’accéder à une application ou une partie d’une application est évaluée au moment où l’utilisateur tente d’y accéder. Dans les faits, il est possible de mettre en place un modèle ABAC tirant parti des rôles d’un utilisateur, comme dans le modèle RBAC.

GraphBAC : Graph-Based Access Control

Le modèle GraphBAC ou GBAC repose sur la représentation des habilitations à l’aide d’un graphe liant entre eux des objets (fichier, compte utilisateur, …) grâce à des relations diverses (lien entre manager et managé, appartenance à une structure, possession d’un fichier…). Les habilitations sont alors le résultat de requêtes sur ce graphe, ce qui permet de donner accès à une ressource suivant sa relation avec d’autres objets.

Vision du marché

Le tableau ci-dessous compare de manière très synthétique les différents modèles d’habilitation que nous venons de voir.

Les questions les plus fréquentes sur les modèles d’habilitation

À quoi doit servir mon modèle d’habilitation ?

La mise en place d’un modèle d’habilitation peut s’avérer complexe, coûteuse et chronophage. Il est donc crucial d’étudier en profondeur les besoins et de définir clairement ses attentes. Comme évoqué en introduction, la mise en place d’un modèle d’habilitation peut permettre de répondre aux enjeux de sécurité des accès, aux enjeux réglementaires, mais également de simplifier l’expérience utilisateur et d’améliorer l’efficacité des processus IAM (Identity & Access Management). Un des facteurs clés de succès d’un projet de modélisation des habilitations réside dans la capacité à exprimer ses attentes précisément, à l’aide d’indicateurs chiffrés le cas échéant : réduire le temps nécessaire à la création des accès par un manager lors de l’arrivée d’un collaborateur à 15 min, atténuer 90% des risques considérés critiques, etc.

Qui impliquer pour construire, instancier et faire vivre mon modèle ?

Vu le caractère transversal et l’ampleur de la transformation induite par un changement ou une création de modèle d’habilitation, il est nécessaire de prévoir une gouvernance forte.

Il est préférable d’impliquer un sponsor à forte visibilité auprès du COMEX, qui saura apporter son appui, et qui permettra d’obtenir une adhésion forte de la part du Métier, premier concerné par les changements, et des responsables applicatifs, qui seront fortement sollicités lors de la conception et de la mise en œuvre. On peut également identifier des relais clés, qui viendront apporter leur aide au sein des différentes équipes de l’organisation (RH, DSI, Contrôle Interne…).

Au-delà de la phase projet, il faut également identifier les acteurs qui seront en charge de faire vivre le modèle. Un facteur clé de succès de la mise en place d’un modèle d’habilitation est l’identification des propriétaires des rôles. Si chaque rôle ne comprend que des permissions d’une seule application, on peut facilement se tourner vers le responsable d’application, mais dans la plupart des cas, chaque rôle est composé de permissions provenant d’applications diverses.

L’idéal est de trouver une personne qui a à la fois la connaissance des processus métiers, de l’organisation de l’entreprise, des applications, et une compréhension des règles de sécurité : c’est un exercice difficile ! À défaut, une petite équipe combinant les différentes expertises doit permettre d’assurer cette fonction.

Dois-je couvrir les « droits fins » ? Les « périmètres » ? Quelle granularité pour mon modèle ?

Le monde des habilitations est aussi vaste que la multitude des applications existantes, et les cas d’usage qu’un modèle d’habilitation doit couvrir sont nombreux.

La question des droits fins et de la gestion des périmètres revient régulièrement sur la table lors de la phase de conception. Faut-il, ou non, les inclure dans son modèle ? Il n’existe pas de réponse prédéfinie.

Il est parfaitement envisageable dans certains cas de n’inclure dans le modèle que l’accès à l’application, et de laisser la gestion des droits fins et des périmètres à la main du responsable applicatif et de son équipe, en précisant uniquement les accès demandés dans un champ libre lors de la demande. On perd alors en auditabilité, mais on gagne en simplification de la gestion des demandes.

Si l’on décide d’inclure la notion de périmètre, il faut alors choisir entre une implémentation croisée, dans laquelle on crée autant de droits que de croisements permission-périmètre, ce qui risque de créer un nombre important de rôles, et une implémentation séparée, où on crée d’une part les permissions, et d’autre part les périmètres.

Il est probablement préférable d’aborder le problème séparément, quitte à créer les rôles combinés avec leur périmètre dans un second temps, en fonction des usages identifiés : le modèle qui en découle a ainsi une volumétrie plus limitée.

Que dois-je inclure dans mon modèle ? Quid des accès physiques et des assets physiques ?

Inclure l’ensemble des habilitations au sein de son modèle est extrêmement difficile, voire impossible, d’une part au vu de la grande diversité des cas existants, d’autre part pour des raisons d’efficacité du projet.

Il faut sans cesse garder en ligne de mire l’objectif de la mise en place d’un modèle. Ainsi par exemple, si le but est l’amélioration de l’expérience utilisateur lors des demandes de droits, il vaut mieux prioriser le traitement des permissions orientées vers le métier, qui seront susceptibles d’être attribuées fréquemment, par rapport à des permissions techniques peu utilisées.

Par ailleurs, il peut être tentant d’inclure dans son modèle d’habilitation les accès physiques (locaux, salles spécifiques…) ou les assets physiques (badge, PC, téléphone…) car ils font partie – au même titre que les accès logiques – des moyens dont doivent disposer les collaborateurs pour travailler.

Ici encore, il n’y a pas d’interdit majeur, et des sociétés gèrent par exemple les accès à leurs locaux au sein de leur modèle d’habilitation. Néanmoins, en règle générale, les accès et assets physiques n’en font pas partie en tant que telles.

Pour autant, la solution IAM peut contribuer à leur bonne gestion avec par exemple :

• Un rôle de centralisateur de demandes, envoyées à différents acteurs ou systèmes lors de l’arrivée d’un collaborateur. Ce « package d’arrivée » comporte alors aussi bien des accès logiques (comptes et droits par défaut) que des ressources physiques.
• Un rôle de référent des données et évènements relatifs à une personne. Ces informations, en particulier les dates d’arrivée/départ sont partagées avec les systèmes de gestion des badges pour en gérer le cycle de vie.

Nous venons d’aborder quatre premières questions pour mener à bien un projet de refonte de modèle d’habilitation. D’autres questions seront détaillées dans un second article, à venir très prochainement.

Cet article Refondre son modèle d’habilitation : les questions essentielles (1/2) est apparu en premier sur RiskInsight.