Chapitre 4 CONCLUSION
Les systèmes d'authentification à base de
certificats X.509 semblent moins facilement attaquables et
donc plus robustes que les systèmes basés sur les mots de passe.
Mais un système jugé sûr aujourd'hui peut
révéler des failles ou faiblesses demain. Nous nous souvenons de
la chronique qui a fait la une de nombreux journaux en Fevrier 2000 racontant
comment un informaticien a fabriqué une fausse carte à puce,
appelée « Yescard», capable de tromper un
automate distribuant des tickets de métro et mettant ainsi en exergue
une vulnérabilité dans le système d'authentification du
porteur de carte bancaire. Il est donc primordial de garder à l'esprit
qu'une méthode d'authentification avec Zéro défaut
n'existe malheureusement pas. La sécurité absolue est
une utopie. Cependant il est possible de réduire à un
degré tolérable le niveau de risque lié à une
authentification permissive d'une personne non-autorisée à
accéder au système d'information en mettant en place des
solutions d'authentification forte. Toutefois, il est à noter que
quelque soit la robustesse de la méthode d'authentification
employée, la sécurité du système d'information ne
doit pas uniquement reposer dessus. En effet, la sécurité est un
tout et d'autres mesures de sécurité doivent compléter une
méthode d'authentification forte, comme la mise en place de
séances de sensibilisation à la sécurité
informatique, la diffusion aux utilisateurs de la politique de
sécurité du laboratoire ou de l'entreprise, le cloisonnement de
certains réseaux, etc. (De nombreux exemples sont
présentés dans l'article sur les tableaux de bord de la
sécurité du système d'information du numéro 45 de
la revue).
Chapitre 5 APPLICATION
L'application de gestion des utilisateurs est donc une
application importante. La réalisation de l'application commence par la
modélisation des besoins de l'administrateur de l'entreprise. Il est
donc question de savoir et d'identifier les taches que l'administrateur
souhaitera accomplir. Ceci nous amène à utiliser l'UML et ses
quelques diagrammes pour illustrer ses besoins. Nous aborderons une
méthodologie qui s'articule comme suit :
FIGURE VIII-1MÉTHODOLOGIE DE
TRAVAIL
Dans les sections qui suivent nous allons utiliser une
méthodesimple et générique qui se situe à mi-chemin
entre UP (UnifiedProcess), qui constitue un cadregénéral
très complet de processus de développement, et XP
(eXtremeProgramming) qui est uneapproche minimaliste à la mode
centrée sur le code. Cette méthode est issue de celle
présentéepar Pascal Roques (2008) dans son livre « UML -
Modéliser une application web » qui résulte de
plusieursannées d'expérience sur de nombreux projets dans des
domaines variés. Elle a donc montré son efficacité dans la
pratique et est :
- conduite par les cas d'utilisation, comme UP, mais bien plus
simple ;
- relativement légère et restreinte, comme XP,
mais sans négliger les activités de modélisationen analyse
et conception ;
- fondée sur l'utilisation d'un sous-ensemble
nécessaire et suffisant du langage UML (modéliser80% des
problèmes en utilisant 20% d'UML).
1.17 5.1. Identifications des besoins et spécification
des fonctionnalités
5.1.1. Identification et représentation des besoins
(diagramme de cas d'utilisation)
Dans cette partie il est question de recenser les
éléments de besoins des utilisateurs.
- L'administrateur du système devra pouvoir demander au
système des informations concernant l'utilisateur (les
caractéristiques détaillées du poste, les applications en
cours d'exécution, et bien d'autre encore).
- Les utilisateurs devront se connecter au système et
effectuer leurs tâches courantes sans se soucier d'une quelconque
surveillance
Il est donc judicieux de représenter l'essentiel des
besoins dans un diagramme de cas d'utilisation
FIGURE VIII-2 DIAGRAMME DE
CAS D'UTILISATION
Dans ce diagramme, il peut être lu que :
· L'administrateur peut
afficher les taches en cours : ceci nous amène à tester
au préalable l'ordinateur dont on souhaite connaitre les taches en cours
· L'administrateur peut effectuer directement
une tache ou une opération distante selon une liste des dache
connu.
· L'utilisateur peut allumer son poste :
(il devra s'être authentifié au préalable) ce qui entraine
une notification dans le système, et ainsi avertir l'administrateur de
cette notification.
· L'utilisateur peut lancer une nouvelle application,
basculé entre applications : ce qui amène aussi
à une notification d'action.
Ces quelques fonctionnalités sont les
éléments de bases que l'application devra réaliser.
Il est donc question de les détailler pour obtenir une
vue plus claire de ses fonctionnalités. Ceci nous amène à
l'élaboration des détails par des diagrammes de
séquence.
5.1.2.
| 
