Accès sécurisé au serveur de ressources

Objectifs du scénario : L’objectif de cette étape est d’étendre le serveur mandataire (Patterns Serveur mandataire et Decorateur ) modélisé par les concepteurs de templates (sous-section

5.6) avec des fonctionnalités sécurisant son accès. Pour cela, les modeleurs ont défini les deux fonctionnalités suivantes : Limitation du nombre de requêtes sur une ressource et Accès au serveur par mot de passe.

Limitation du nombre de requêtes sur une ressource en un temps donné Cette fonc- tionnalité a pour but d’éviter un nombre trop important de requêtes clientes sur une ressource en un temps donné : un grand nombre de requêtes sur le serveur en un temps très court peut fortement ralentir, voir bloquer l’accès à celui-ci. La fonctionnalité à modéliser doit donc limiter l’impact de ce type d’attaques (DDOS2_{). La figure 5.2 décrit la séquence d’opérateurs utilisée}

pour la représentation de cette fonctionnalité par le concepteur de système CS1. Pour rappel (cf. section 5.4), chacun des concepteurs de système sont identifiés dans le scénario par le label “C(oncepteur de) S(ystème)”, suivit d’un identifiant.

(A) (B) (B) (C) (D) (D) (super-modèle) (D) (C) ExtendableProxyfied ResourceAccess

X : identifiant d'étape de modélisation ControlledRequestProxy =

apply ( ExtendableProxyfiedResourceAccess, S, ResourceRequestControl) ResourceRequestControl =

extract ( ProtectedResourceserver,

{ FraudTracker, Map<String, Date [0..*]>, lastClientAccessTime, logFraud} ) extract e Protected ResourceServer Resource RequestControl CS1

Figure 5.2 – Limitation du nombre de requêtes sur une ressource

La numérotation indiquée sur le diagramme d’activité, situé dans la partie gauche de la figure, représente les numéros d’étape de modélisation, exposées dans l’annexe D.1.

Le modeleur sélectionne la fonctionnalité souhaitée dans le modèle ProtectedResourceServer (par- tie supérieure droite de la hiérarchie de modèles, en figureC.1), via l’opérateur extract. Dans un second temps, il utilise l’opérateur apply afin d’ajouter au serveur mandataire la fonctionnalité limitant le nombre de requêtes en un temps donné. Le modeleur a extrait la fonctionnalité telle que décrite dans la partie supérieure droite de la figure 5.2: en partant d’une version de modèle existante (A sur la figure), le modeleur a utilisé l’opérateur extract. Il a passé en paramètres de cet opérateur (B sur la figure) le nom de la version de modèle ProtectedResourceServer dont il souhaitait extraire la fonctionnalitéet l’ensemble des éléments composants celle-ci, i.e. la classe FraudTracker et ses éléments. Il a ainsi obtenu une nouvelle version de modèle ResourceRequest- Control, sous-modèle de ProtectedResourceServer. Le résultat de cette extraction est présenté en figure5.3.

La classe FraudTracker et ses éléments ont été extrait car (1) les accès à une ressource sont

Figure 5.3 – Résultat de l’extraction de ResourceRequestControl à partir de ProtectedResourceServer

stockés dans un dictionnaire (lastClientAccessTime) : pour une ressource (son URI, sous forme de chaine de caractères) correspondent toutes les dates et heures d’accès. Et (2) selon les dates et heures d’accès à une ressource, l’accès à celle-ci sera bloqué pendant un certain temps (une attaque est détectée quand le temps est trop court entre chaque accès). Cette restriction d’accès lors de la détection est enregistrée via la méthode logFraud.

Après avoir ainsi obtenu ResourceRequestControl par extraction, le modeleur a étendu le serveur mandataire avec cette fonctionnalité, tel que décrit dans la partie inférieure droite de la figure

5.2: en partant d’un template existant (C sur la figure), le modeleur a utilisé l’opérateur apply. Il a passé en paramètres de celui-ci (D sur la figure) le template ExtendableProxyfiedResourceAc- cess, représentant le serveur mandataire extensible3, le modèle ResourceRequestControl extrait précédemment et un ensemble de substitutions. Ceci lui a permis d’obtenir la version de modèle ControlledRequestProxy, sur-modèle de ResourceRequestControl. Ceci est exposé en figure 5.4.

Figure 5.4 – Résultat de l’application de ExtendableProxyfiedResourceAccess sur ResourceRequestControl

Accès par mot de passe L’objectif est ici d’empêcher la connexion de n’importe quel individu ou organisation au serveur de ressources. La fonctionnalité à modéliser doit donc restreindre l’accès au serveur par l’utilisation d’un login et d’un mot de passe. Les opérateurs utilisés sont décrits en figure 5.5.

Le concepteur choisit la fonctionnalité souhaitée dans le modèle PowerControlledServer, avec l’opérateur extract. Ensuite, il utilise apply afin d’ajouter au serveur mandataire la fonctionnalité

CS1

Figure 5.5 – Accès par mot de passe

restreignant l’accès par mot de passe et login.

Le modèle extrait est UserPasswordManagement, sous-modèle de PowerControlledServer, tel que présenté dans la figure5.6.

Figure 5.6 – Résultat de l’extraction de UserPasswordManagement à partir de PowerControlledServer

Les classes ResourceServer, Proxy et Account et leurs constituants ont été extraits car (1) les logins et mots de passes des différents comptes autorisés sont gérés par le serveur de ressources, auquel (2) des utilisateurs vont se connecter via un serveur mandataire.

Le modeleur a ensuite appliqué le template représentant le serveur mandataire sur UserPass- wordManagement, obtenant ainsi le modèle UserPasswordProxy, exposé en figure5.7.

Fusion des fonctionnalités Après avoir modélisé les deux fonctionnalités précédentes, le concepteur CS1 les fusionne afin d’avoir un accès sécurisé au serveur. L’opérateur utilisé est merge (cf. figure 5.8), prenant en paramètre les deux modèles résultant des étapes précédentes, i.e. ControlledRequestProxy et UserPasswordProxy (A sur la figure).

Le résultat de cette fusion est la version SecuredAccessServer (B dans la partie basse de la figure), présentée en figure5.9.

Le modèle résultat permet ainsi à des clients de se connecter au serveur de ressources mais en sécurisant celui-ci par (1) la présence d’un serveur mandataire restreignant l’accès aux ressources en lecture uniquement (utilisation des templates construits en sous-section 5.6), (2) la limitation du nombre de requêtes sur une ressource en un temps donné et (3) une connexion

Figure 5.7 – Résultat de l’application de ProxyfiedResourceAccess sur UserPasswordManagement

(super-modèle)

CS1

Figure 5.8 – Fusion des fonctionnalités

via un login et un mot de passe des clients.

Évolution de la hiérarchie de modèles (Serveurs de ressources) La modélisation de l’accès sécurisé au serveur a créé des versions de modèles au sein de la hiérarchie de sous-modèles des figures C.1 etC.2.

Une version simplifiée (i.e. se concentrant sur les modèles créés précédemment) est exposée en figure5.10.

Chacune des fonctionnalités modélisées (2 : Limitation du nombre de requêtes sur une ressource, 4 : Accès par mot de passe) a généré une nouvelle branche dans la hiérarchie.

Comme on peut le voir en figure 5.10, deux branches ont été créées, via les opérateurs extract et apply. La première branche contient UserPasswordProxy, version alternative de UserPass- wordManagement (l’autre version alternative étant PowerControlledServer ). La seconde branche contient quand à elle ControlledRequestProxy, incluant ResourceRequestControl.

Figure 5.9 – Résultat de la fusion de UserPasswordProxy avec ControlledRequestProxy

Figure 5.10 – Serveur de ressources : Hiérarchie de modèles après modélisation de l’accès sécurisé au serveur

Les versions finales (ControlledRequestProxy et UserPasswordProxy) des deux branches ont par la suite été fusionnées ( 5 ), permettant d’obtenir SecuredAccessServer.