• 20 hours
  • Hard

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 12/12/19

Initiez-vous à la gestion du contrôle d’accès aux ressources

Log in or subscribe for free to enjoy all this course has to offer!

Sécuriser le canal de communication

La sécurité dans une architecture IoT peut être mise en place à différents endroits. Vous pouvez tout d’abord sécuriser le canal de communication qui relie un client ou un objet à une plateforme. Ensuite, vous pouvez gérer directement sur la plateforme l’accès et la modification aux données.

Tout d’abord, prenons un exemple simple. Vous avez un client qui souhaite interagir avec une plateforme, mais il doit passer par un canal non sécurisé.

Pour pallier cela, vous pouvez utiliser un protocole sécurisé tel que HTTPS, la version sécurisée du protocole HTTP. Dans ce cas-là, le message sera chiffré et l’attaquant potentiel ne pourra pas interpréter le message que vous avez échangé avec le serveur.

En revanche, ce genre de protocole n’empêche pas l’attaquant de se faire passer pour vous s’il a vos identifiants et ainsi, il peut réaliser des requêtes à votre place. Pour cela, des systèmes de clés partagées au préalable peuvent être mis en place pour être sûr que la personne avec qui on interagit est la bonne.

Ce sont des problèmes possibles dans d’autres architectures que des architectures IoT, mais ils sont bien présents dans notre cas d’étude.

Dans le cadre du standard oneM2M, un groupe de travail produit un document de spécification sur les types de sécurité qui doivent être mis en place. Ce document est le TS-0003, disponible sur le site de oneM2M.

Comment s’authentifier auprès du serveur ?

Une fois que vous avez établi la communication avec le serveur, il faut vous authentifier. En effet, suivant les droits que vous avez, vous n’allez pas pouvoir réaliser toutes les requêtes que vous voulez. Vous ne pouvez pas supprimer des ressources qui ne vous appartiennent pas, par exemple, sauf si le possesseur vous en a donné les droits.

Dans le cas de oneM2M, cette authentification se fait à travers un identifiant, sous forme d’une chaîne de caractères, qui doit être donné à la plateforme pour chaque requête. Il se nomme l’originator dans le standard. La plateforme peut ainsi établir si vous avez le droit de réaliser cette opération (animation) ou non.

Pour les tutoriels, vous allez principalement utiliser le protocole HTTP et, dans ce cadre-là, l’originator doit être spécifié dans un header nommé X-M2M-Origin.

Dans oneM2M : identifiant donné à chaque requête | En HTTP pour oneM2M: -> Header nommé X-M2M-Origin
Dans oneM2M : identifiant donné à chaque requête | En HTTP, pour oneM2M : -> Header nommé X-M2M-Origin

La représentation des contrôles d’accès

Ce mécanisme que vous venez de voir permet à l’utilisateur de s’authentifier. Mais comment faire en sorte de changer ou de mettre en place une politique de gestion particulière sur ses ressources ?

Pour cela, il existe une autre ressource, nommée Control Access Policy, que nous abrègerons en ACP, qui représente ces droits.

Un ACP se présente comme ceci, avec plusieurs champs :

Le premier attribut correspond aux privilèges, c’est-à-dire à la politique d’accès aux ressources que l’on va appliquer sur votre container de données, par exemple.

Le deuxième attribut est les self-privilèges ; ils correspondent aux droits d’accès pour l’ACP même. En effet, les ACP étant des ressources comme les autres, il faut définir qui peut y accéder, les modifier ou les supprimer. Cela se fait par cet attribut qui doit être spécifié pour chaque ACP.

La structure des privilèges ou des self-privilèges est la même.

Elle est composée d’une ou plusieurs règles, nommées acr, qui comprennent une liste d’originators ainsi que des opérations. Les originators sont sous le tag acor et chaque originator est séparé par un espace. Cela signifie qu’un originator ne peut pas avoir d’espace.

Pour les règles, il s’agit d’un entier qui doit être spécifié. Pour trouver cet entier, on fait la somme des opérations que l’on veut donner aux originators et on le rentre dans le champ acop.

Prenons un exemple en nous appuyant sur ce tableau :

Nous avons les deux règles suivantes :

La première donne à l’orignator « admin » les droits 63.

Il s’agit de la somme de toutes les opérations que l’on voit dans ce tableau :

Ainsi, l’admin aura le droit de réaliser toutes les opérations sur ces ressources.

La deuxième règle concerne deux originators, « guest » et « arthur ». Pour eux, ils ont comme droit 34, ce qui correspond à 32 + 2, donc le droit de lecture et le droit de découverte.

Le lien avec les autres ressources

Maintenant que vous avez vu comment représenter une politique de contrôle d’accès, comment faire pour l’appliquer aux ressources ?

Pour les ressources de type ACP, nous avons vu que le champ pvs régissait cet accès. Pour les autres ressources, un mécanisme différent est utilisé.

Ces ressources vont spécifier un attribut acpi pour Access Control Policy Identifiers. Lors d’un accès ou de la modification d’une ressource, la plateforme oneM2M va récupérer le ou les ACP concernés et va vérifier si l’originator de la requête possède les droits corrects pour faire l’opération qu’il souhaite sur la ressource.

Cela permet ainsi de valider et l’opération voulue sera exécutée.

Conclusion

Grâce à ce chapitre, vous êtes maintenant sensibilisé à quelques notions de sécurité pour les plateformes IoT. Il existe beaucoup de cas critiques qu’il faut gérer dans la conception et l’établissement de ce genre de plateforme. Nous en avons illustré quelques-uns par des exemples basiques, mais non exhaustifs.

Vous avez aussi découvert comment formuler une politique de droit d’accès et comment la lier aux ressources. Vous allez mettre cela en application dans l’activité suivante pour gérer l’accès à vos ressources.

Example of certificate of achievement
Example of certificate of achievement