Dans ce billet, nous allons introduire une notion fondamentale dans l’extension de la vision du modèle pour la prise en compte des scénarios BYOD : la notion de contexte d’accès.

L’un des principes immuables de la sécurité est d’accorder au consommateur un accès aux informations en fonction de son rôle ; il doit avoir les autorisations nécessaires pour accéder uniquement aux informations dont il a besoin et pas plus (principe du moindre privilège – least-privilege). C’est ce que rappelle (en partie) le principe 4 énoncé précédemment :

« L’accès aux données doit être protégé par un contrôle d’accès basé sur l’identité du consommateur et les autorisations associées à son rôle qui seront déduites de ses attributs et revendications (claims). »

Pour un rappel sur les 4 principes de sécurité, relisez le billet  BYOD: Rappels et évolution du modèle de sécurité

On présuppose implicitement que :

1. le niveau de confiance dans l’identité du consommateur est maximal ;

2. le niveau de confiance dans le fait que ce soit bien le consommateur qui se présente est maximal par le biais de la force de l’authentification ;

3. le niveau de sécurité du terminal d’accès est maximal (si on envisage simplement que le terminal est corrompu, la confiance dans l’identité de l’accédant tombe à zéro) ;

4. le niveau de confiance sur la communication entre le terminal et l’information est maximal.

Ces postulats deviennent inexacts dès lors que le niveau de confiance de chacun de ces éléments peut varier : l’identité du consommateur n’est plus forcément une identité gérée en interne et devient liée à la confiance dans le tiers qui gère cette identité ; l’authentification peut s’appuyer sur un principe de mot de passe faible ; la sécurité du terminal dépend du niveau de connaissance et de contrôle que l’on peut en avoir ; la communication peut être initiée depuis des endroits impactant fortement son niveau de confiance, par exemple un cyber-café ou un hall d’aéroport.

Dans une approche plus ouverte de la sécurité rendue nécessaire par la consumérisation et le BYOD, on se doit donc de prendre en compte le fait que le niveau de confiance des différents éléments en jeu peut varier ; pour ce faire on va introduire le concept de contexte d’accès.

Le contexte d’accès va dépendre de quatre paramètres : l’identité, l’authentification, l’emplacement depuis lequel le consommateur se connecte et enfin le terminal utilisé.

imageFigure 1 : Les 4 paramètres de la notion de Contexte d'accès

 

  • L’identité pourra se décliner sous trois formes : une identité « Corporate » c’est-à-dire complètement maitrisée, gérée par l’entreprise à travers son système de gestion des identités ; une identité fédérée (ou partenaire) non gérée par l’entreprise mais qui, par l’intermédiaire d’une relation de confiance au sens de la fédération, sera présentée aux applications sous forme d’un jeton décrivant l’identité et les caractéristiques associées ; enfin, une identité sociale auto-déclarée par l’utilisateur et, comme son nom l’indique, servant à se connecter sur les réseaux sociaux. Ces trois identités disposeront des niveaux de confiance différents qui autoriseront des scénarios d’accès distincts et dépendants des ressources accédées. A titre d’exemple, l’illustration ci-dessous représente la page de sélection d’identité proposée par le serveur de jetons de fédération pour se connecter sur le portail Azure.

image

Figure 2 : Illustration des différents types d’identité

  • L’authentification est classée selon quatre niveaux : faible, moyen, fort et multi-facteur. L’authentification de niveau faible correspond par exemple à une authentification par mot de passe pour lequel aucune politique de sécurité restrictive n’est imposée : l’utilisateur peut sélectionner un mot de passe avec un nombre réduit de caractères, une entropie faible ou choisir parmi la liste des mots de passe les plus courants (par exemple : en 1ère place pour l’année 2012, « password », puis « 123456 »…). Une authentification moyenne correspondra à une authentification par mot de passe mais sur laquelle une politique de sécurité plus « sérieuse » est appliquée imposant par exemple au minimum 13 caractères avec des critères de complexité, une gestion de l’historique, etc. Une authentification qualifiée de forte pourra s’appuyer sur l’utilisation d’un certificat logiciel éventuellement protégé par TPM. Enfin, une authentification multi-facteur reposera sur une solution mettant en œuvre plusieurs facteurs comme la possession d’une carte à puce associée à celle de son code PIN.

 

  • La localisation prend en compte l’endroit depuis lequel le consommateur établit la connexion à partir de son terminal. La distinction la plus évidente se fera entre une connexion depuis l’intérieur des bâtiments de l’entreprise en comparaison d’une connexion depuis l’extérieur, même si d’un point de vue de l’utilisateur, on souhaite rendre l’expérience la plus transparente. En connexion depuis l’intérieur, on peut effectuer une distinction entre une connexion filaire qui impose un franchissement des contrôles d’accès physiques de l’entreprise pour se connecter, et une connexion wifi qui peut déborder au-delà des frontières physiques des bâtiments. Enfin, concernant les accès externes, on n’attribuera pas le même niveau de confiance selon que la connexion est initiée depuis la maison ou un hôtel, depuis des lieux publics (cybercafé, aéroport) depuis le pays ou en-dehors de frontière.

 

  • Le terminal utilisé pour accéder à l’information représente le dernier critère dont le niveau de confiance influe dans l’évaluation du contexte d’accès ; il sera regroupé dans les catégories Unmanaged, Loosely Controlled, Lightly Managed ou Corporate Managed décrites précédemment.

Au terme de cette catégorisation, on peut définir un niveau de confiance global lié au contexte d’accès qui sera fonction du niveau de confiance de chacun des quatre paramètres : Identité, Authentification, Localisation et Terminal.

Pour être complet, il faut ajouter que les quatre critères ne sont pas complètement indépendants ; par exemple l’identité et l’authentification sont liées dans le sens où certaines associations n’auront pas de sens : quel est l’intérêt, vu de l’entreprise, de disposer d’une authentification multi-facteur sur une identité sociale ? L’accès aux ressources de l’identité sociale est bien protégé mais l’identité auto-déclarée n’en est pas plus sûre.

Dans le prochain et dernier billet traitant du modèle de sécurité, nous verrons comment se résout l’équation complète en y intégrant les politiques de sécurité et la sensibilité des données.

Pour reprendre la description complète du modèle, consultez les billets précédents :