Conception Et Réalisation D'une Application de Gestion de Sécurité D'information Pour La Poste Tunisienne

Sujet:
Conception et Ralisation dune Application de Gestion de Scurit

dInformation pour la Poste Tunisienne
Elabore par :
GHAZEL Taoufik
Mmoire de fin dtudes

Pour lobtention du diplme Mastre Professionnel
Option
Nouvelles Technologies des Tlcommunications et Rseaux
Universit virtuelle de Tunis

(UVT)
Promotion: 2010/2011
DEDICACES
Je ddie ce travail mes trs chers parents ; ma mre qui ne cesse

jamais de mencourager, mon pre qui tait toujours mes cts
tout moment, Que dieu tout puissant les garde pour moi,
A mes frres et mes surs pour leur amour et leur
Soutien inconditionnel,
A toute ma famille,
Et A tous mes amis o quils soient.
REMERCIEMENTS
Jadresse mes vifs remerciements mon encadreur, Mr Riadh

Bouhouchi, enseignant lUniversit Virtuelle de Tunis, pour
son entire disponibilit, son aide inestimable et ses conseils, sans
lesquels ce travail naurait pu aboutir.
Je remercie galement tout le personnel de la Direction informatique,
et particulirement Mr Sami Sahraoui et Mr Taoufik Borsali pendant
toute la priode de mon stage.
Je remercie assez les membres de la commission de suivi, pour leur
disponibilit, leurs prcieux conseils et remarques constructives tout
au long de lanne.
Merci galement aux membres du jury qui ont accept dvaluer mon
travail.
Que tous les enseignants de lUVT qui ont contribu ma formation, le
long de ces deux annes, trouvent ici lexpression de ma gratitude et
de ma reconnaissance.
Enfin, je tiens remercier tous ceux qui, de prs ou de loin, ont
contribu laboutissement de ce travail.
Rsum
Initialement, notre principale motivation tait lie la volont de se dmarquer dans le
domaine de la protection des systmes dinformations par ralisation dun Systme de
Management de la Scurit de lInformation dans la poste tunisienne.
Aujourdhui, les bnfices ne se mesurent pas seulement en termes dimage mais galement
sur le fonctionnement en interne.
En effet, la mise en uvre du SMSI a t loccasion de mettre en avant limportance de la
scurit du SI, de la faire reconnatre dans les diffrents services et de donner aux actions un
rythme clair et partag.
Les exigences pour la mise en place du SMSI sont dcrites par la norme ISO/CEI 27001.
Cette norme sadapte tout type dentreprise, quelque soit le secteur dactivit, sa structure,
sa taille et la complexit de son systme dinformation.
Lapplication de cette norme passe par une dmarche qualiticienne classique : la roue de
Deming (Planifier, Dvelopper, Contrler, Agir) qui permet de prendre en compte des
dysfonctionnements le plus en amont possible et damener une amlioration continue du
systme.
Mots cls : Scurit de linformation, SMSI, ISO/CEI27001, PDCA,
Abstract
At the beginning, our main motivation was related to the will of standing out in the field of
information systems protection by the installation of a first Information Security Management
System in Tunisian Post.
Today, profits are not appeared only in terms of branding but also on the internal tasks.
Indeed, the implementation of the ISMS was an opportunity to highlight the importance of the
informations system security, to make it recognized in the various services and to give to the
actions a clear and shared rate.
The requirements for the implementation of the WSIS are described in ISO/ECI 27001. This
standard adapts to any type of business, whatever the sector of activity, structure, size and
complexity of its information system.
Applying this standard requires a classic approach of quality: the Deming wheel (Plan, Do,
Check, Act), which can take into account the failures as early as possible and bring a
continuous improvement of the system.
Key words: Information Security, ISMS, ISO/CEI 27001, PDCA.
Table des Matires

Introduction gnrale .................................................................................................6
Chapitre I : Prsentation du cadre du stage .......................................................9
I.
Prsentation de socit ................................................................................................. 10
II.
Etude de lexistant ....................................................................................................... 10
1.
Description de lexistant ............................................................................ 10
2.
Scurit de systme dinformation ............................................................... 11
3.
Critique de lexistant ................................................................................. 11
4.
Solution propose..................................................................................... 11
Chapitre 2 : Spcification et Analyse .................................................................. 13

I.
Introduction ................................................................................................................. 14
Systme de management de scurit de linformation : .................................... 14
II.
III.
1-
Comment mettre en place un SMSI : ................................................................... 15
2.
Architecture de lISO 27001 : ............................................................................. 16
3.
Processus de lISO 27001 de lSMSI : ................................................................ 16
4.
Dclaration d'applicabilit ................................................................................... 20
5.
Mthodes dapprciation des risques ................................................................... 20
6.
Analyse de risque : .............................................................................................. 23
7.
Gestion du risque : .............................................................................................. 23
8.
Processus damlioration continue : ....................................................................23

Conclusion : ............................................................................................ 24
Chapitre III : Conception ............................................................................................. 25

I.
Introduction ................................................................................................................. 26
II.
Modles de cycles de vie ............................................................................................. 27
1.
Modle en cascade ................................................................................... 27
2.
Modle en V ........................................................................................... 28
Conception et Ralisation dune Application de Gestion de Scurit dInformation pour la Poste Tunisienne
3.
III.
Le modle en spirale ................................................................................. 29

Mthodologies de conception : ................................................................................... 29
1.
Etude comparative entre MERISE et UML : .................................................. 29
2.
La dmarche adopte : .............................................................................. 31
IV.
Conception dtaille : ................................................................................................ 32
1.
Authentification : ..................................................................................... 33
2.
Cration dun nouveau compte : .................................................................. 36
3.
Communication: ...................................................................................... 37
4.
Contrler les services: ............................................................................... 39
5.
Diagramme de classe de SMSI : ............................................................. 42
6.
Conclusion ............................................................................................. 42
Chapitre IV : Ralisation ........................................................................................... 43

I.
Introduction : .......................................................................................... 44
II.
Environnement logiciel :............................................................................ 44
1.
Description du modle Vue Contrleur MVC2 : ............................................. 44
a-
Le modle ........................................................................................................... 44
b-
La vue ................................................................................................................. 45
c-
Le contrleur ...................................................................................................... 45
2.
Description de la diffrence entre le modle MVC1 et MVC2 : ......................... 46
a-
Le modle MVC type 1 ............................................................................. 46
b-
Le modle MVC de type 2 ......................................................................... 46
3.
Description du Framework JPA : .............................................................. 48
4.
Cration de la base de donnes : .................................................................. 49
a.
Dfinition ........................................................................................................... 49
N2TR
Page 2
b.
III.
Description de la gnration du bas de donnes : ................................................. 49

Environnement Matriel :........................................................................................... 50
1.
Architecture matrielle : ............................................................................ 50
2.
Matriel utilis : ....................................................................................... 50
III.
Technologies : ........................................................................................................... 50
IV.
Les composantes applicatives ralises ...................................................................... 51
1.
Interface de connexion : ............................................................................ 51
2.
Interface de Rclamation: .......................................................................... 52
3.
Interface dAdministrateur : ....................................................................... 55
CONCLUSION ET PERSPECTIVES ...................................................................................... 57

Bibliographie et rfrences ................................................................................... 63
Annexe .............................................................................................................................. 58
N2TR
Page 3
Liste des figures

Figure 1:Architecture de lISO 27001 ................................................................................... 16
Figure 2:Etapes de la phase Plan du PDCA ........................................................................... 17
Figure 3:Utilisation des modules de MEHARI ...................................................................... 22
Figure 4: Modle du cycle de vie en cascade......................................................................... 27
Figure 5: Modle du cycle de vie en V .................................................................................. 28
Figure 6: les diffrents types de diagrammes ........................................................................ 32
Figure 7: les diffrents types de diagrammes ........................................................................ 46
Figure 8: Le modle MVC de type 2 ..................................................................................... 47
Figure 9: architecture du modle MVC de type 2 ................................................................. 48
Figure 10: gnration du bas de donnes ............................................................................... 49
Figure 11: Architecture matriel de mon systme ................................................................. 50
Figure 12: interface Authentification .................................................................................... 52
Figure 13 : code source Authentification ............................................................................... 52
Figure 14: interface Client .................................................................................................... 53
Figure 15: code source cr Rclamation .............................................................................. 53
Figure 16: interface Rclamation .......................................................................................... 54
Figure 17: interface Rclamation sauvegarde ...................................................................... 55
Figure 18: interface Administrateur ...................................................................................... 55
Figure 19: interface Cration d'un nouvel Utilisateur ............................................................ 56
Figure 20: interface List Authentification ............................................................................ 56
N2TR
Page 4
Liste des diagrammes
Diagramme 1: Diagramme de cas dutilisation Authentification ......................................34

Diagramme 2: Diagramme de squence Authentification ................................................ 35
Diagramme 3: Diagramme de classe Authentification ..................................................... 35
Diagramme 4: Diagramme de squence cration dun nouveau compte .......................... 37
Diagramme 5: Diagramme cas dutilisation Communication ............................................ 38
Diagramme 6: Diagramme de classe Communication. ..................................................... 39
Diagramme 7: Diagramme de cas dutilisation Contrler les services. .............................. 41
Diagramme 8: Diagramme de squence Contrler les services ......................................... 41
Diagramme 9: Diagramme de classe de SMSI . ................................................................ 42
N2TR
Page 5
Introduction gnrale
N2TR
Page 6
Lomniprsence des informations croissante soutenue par la rvolution numrique

des technologies de linformation et de la communication TIC a amplifi le besoin dassurer
lintgrit, la confidentialit et la disponibilit de linformation.
Malgr des moyens techniques permettant de les contrler et des comptences pour les mettre
en uvre, la complexit des systmes dinformation exige une planification rigoureuse de la
supervision.
Des outils sous forme de codes de bonnes pratiques et mthodes dapprciation des
risques permettent aux entreprises de fixer des objectifs, des priorits et coordonner les
actions entreprendre.
Nanmoins ces outils, bien quayant prouv leur efficacit, souffrent dun manque de
reconnaissance au plan international cause de leur trop grande diversit.
Pour remdier lhtrognit des mthodes et pallier le manque de reconnaissance des
codes de bonnes pratiques , lISO (Organisation Internationale de Normalisation) a publi en
2005 la norme ISO/CEI 27001.
LISO/CEI 27001, clef de vote dune famille de normes encore en dveloppement, apporte
une dimension supplmentaire la politique de scurit de linformation en y intgrant le
concept de systme de management . Cette norme est la base de notre rflexion pour ce
mmoire.
Le travail de la mise en uvre dun systme de management de la scurit de linformation
(SMSI), prsent dans ce rapport a t effectu dans le cadre de mon projet de fin dtudes du
Master Nouvelles technologies des tlcommunications et Rseaux de lEntreprise
lUniversit Virtuelle de Tunis.
Ce travail, ralis dans les locaux de la poste tunisienne et a pu mener terme grce la
collaboration du responsable scurit.
Durant mon stage de PFE, il ma t demand de faire la conception, et le dveloppement

dune application de Systme de Management de la Scurit de lInformation de la poste
tunisienne.
Ce prsent rapport sera structur en 4 chapitres :
Dans le premier chapitre Prsentation du cadre du stage , je prsente le cadre de mon
stage de PFE savoir lorganisme de la socit la direction informatique d la poste
tunisienne , je me propose danalyser lexistant, de critiquer lexistant et de proposer propose
une solution.
N2TR
Page 7
Dans le second chapitre intitul Spcification et Analyse, jai bien parl sur le Systme de
Management de la Scurit de lInformation, sa mise en place, son architecture, la gestion de
risque, Processus damlioration continue
Dans le troisime chapitre Conception du systme, jai parl des mthodologies de

conception, et jai fais une conception dtaille des cas dutilisation, les diagrammes de
squence, ainsi que le diagramme de classe complet.
Dans le dernier chapitre intitul Ralisation, jai prsent lenvironnement matriel et
logiciel, le passage vers le schma relationnel et quelques composantes applicatives ralises.
Enfin, jai cltur ce mmoire par une conclusion dans laquelle jai rsum ma solution et
exposant quelques perspectives futures.
N2TR
Page 8
Chapitre I : Prsentation du cadre du stage
N2TR
Page 9
I.
Prsentation de socit
La Poste tunisienne, dnomination commerciale pour l'Office national des Postes
tunisiennes, est l'entreprise publique tunisienne de service postal. Depuis le 1er janvier 1999,
suite au retrait des activits de tlphonie, la Poste tunisienne est un tablissement
caractre industriel et commercial centr sur deux activits principales :
la collecte, le transport et la distribution de courrier ;

l'exploitation et la fourniture de services financiers ainsi que des services divers :
traditionnels ; telles que la production et la vente de timbres et nouveaux ; tels qu'un
ensemble de services informatiques.
LISO 27001 permettent aux entreprises et aux administrations d'obtenir une certification
qui atteste la mise en place effective d'un systme de management de la scurit de
l'information SMSI). Cette norme garantit aux parties prenantes (clients, actionnaires,
partenaires, etc.) que la scurit des systmes d'information a t srieusement prise en
compte et que l'entreprise s'est engage dans une dmarche d'amlioration constante.
II.
Etude de lexistant
1. Description de lexistant
Les dernires annes a connu galement le dmarrage de nouveaux services bass sur
les technologies de linformation et de la communication visant dvelopper les services
distance et renforcer le positionnement de la Poste tunisienne au cur de lconomie
immatrielle, ladministration communicante et commerante et le commerce lectronique
annonce le rapport. Parmi ces produits, on trouve les chques postaux via Internet, le
paiement des factures distance, le dveloppement du dinar lectronique, la messagerie
scurise via Internet, le service de courrier hybride, le transfert dargent partir de ltranger,
le service de mandat minute, le paiement en ligne des bourses et prts universitaires aux
tudiants et des pensions de retraite, le rseau de distributeurs automatiques des billets DAB.
Le systme d'information est compos d'lment divers (employs, ordinateur...) chargs de
stocker et de traiter les informations relative au systme oprant afin de les mettre la
disposition du systme de pilotage. Il peut en outre recevoir de celui-ci des dcisions
N2TR
Page 10
destines son propre pilotage. Enfin il peut mettre vers le systme oprant des
informations-interaction, c'est dire qu'il peut ragir sur le systme oprant.
2. Scurit de systme dinformation
La scurit des systmes d'information se cantonne gnralement garantir les droits

d'accs aux donnes et ressources d'un systme, en mettant en place des mcanismes
d'authentification et de contrle. Ces mcanismes permettent d'assurer que les utilisateurs des
dites ressources possdent uniquement les droits qui leurs ont t octroys.
La scurit informatique doit toutefois tre tudie de telle manire ne pas empcher les
utilisateurs de dvelopper les usages qui leur sont ncessaires, et de faire en sorte qu'ils
puissent utiliser le systme d'information en toute confiance. C'est la raison pour laquelle il est
ncessaire de dfinir dans un premier temps une politique de scurit, c'est--dire :
laborer des rgles et des procdures, installer des outils techniques dans les diffrents
services de l'organisation (autour de l'informatique) ;

dfinir les actions entreprendre et les personnes contacter en cas de dtection d'une
intrusion ;
sensibiliser les utilisateurs aux problmes lis la scurit des systmes
d'informations ;
prciser les rles et responsabilits.
3. Critique de lexistant
Il nya pas une norme bien structure.
Il n ya pas une description pratique et dtaille de la mise en uvre. des objectifs et
mesures de scurit.
Il ny a pas daudit rgulier qui permet le suivi entre les risques initialement identifis,
les mesures prises et les risques nouveaux ou mis jour, afin de mesurer lefficacit des
mesures prises.
4. Solution propose
Un SMSI est un ensemble dlments interactifs permettant un organisme dtablir
une politique et des objectifs en matire de scurit de linformation, dappliquer la politique,
datteindre ces objectifs et de contrler latteinte des objectif.
La politique de scurit de linformation donne les grandes orientations de lorganisme en
matire de scurit de linformation et fixe des objectifs quantifis. Elle est officiellement
N2TR
Page 11
formule par la direction, qui sengage fournir les moyens ncessaires pour atteindre ses
objectifs.
Elle est cohrente avec les objectifs mtiers de lorganisme, et avec les besoins de ses clients
et partenaires. Elle est communique au sein de lorganisme, sa comprhension par les
intervenants internes et externes est vrifie, elle est revue de faon priodique(en gnral
annuellement) pour rester en adquation avec les objectifs globaux de lentit.
Le SMSI tabli, document, mis en uvre et entretenu. Son efficacit est mesure par rapport
aux objectifs de lentit, et cette mesure permet damliorer en permanence le SMSI.
Le SMSI est cohrent avec les autres systmes de management de lentit, notamment avec
les systmes de management de la qualit, de la scurit des conditions de travail, et de
lenvironnement.
Le SMSI inclut donc au minimum :
*des lments documentaires (politique, description des objectifs, cartographie des processus
impacts, des activits de scurit, et des mesures),
*la description de la mthode danalyse des risques utiliss,
*les processus impliqus dans la mise en uvre de la scurit de linformation,
*les ressources ncessaires sa mise en uvre,
*les activits relatives la scurit de linformation.
Lexistence dun SMSI dans lorganisme permet de renforcer la confiance dans le mode de
gestion de la scurit de linformation.
N2TR
Page 12
Chapitre 2 : Spcification et Analyse
N2TR
Page 13
I.
Introduction
Les dernires annes ont connu galement le dmarrage de nouveaux services bass
sur les technologies de linformation et de la communication visant dvelopper les services
distance et renforcer le positionnement de la Poste tunisienne au cur de lconomie
immatrielle, ladministration communicante et commerante et le commerce lectronique
annonce le rapport.
Parmi ces produits, on trouve les chques postaux via Internet, le paiement des factures
distance, le dveloppement du dinar lectronique, la messagerie scurise via Internet, le
service de courrier hybride, le transfert dargent partir de ltranger, le service de mandat
minute, le paiement en ligne des bourses et prts universitaires aux tudiants et des pensions
de retraite, le rseau de distributeurs automatiques des billets DAB.
Pour ce qui est du rseau commercial, les efforts sont intensifis en vue de moderniser ce
rseau.
II.
Systme de management de scurit de linformation :
Un SMSI est un ensemble dlments interactifs permettant un organisme dtablir

une politique et des objectifs en matire de scurit de linformation, dappliquer la politique,
datteindre ces objectifs et de contrler latteinte des objectif.
La politique de scurit de linformation donne les grandes orientations de lorganisme en
matire de scurit de linformation et fixe des objectifs quantifis. Elle est officiellement
formule par la direction, qui sengage fournir les moyens ncessaires pour atteindre ses
objectifs.
Elle est cohrente avec les objectifs mtiers de lorganisme, et avec les besoins de ses clients
et partenaires. Elle est communique au sein de lorganisme, sa comprhension par les
intervenants internes et externes est vrifie, elle est revue de faon priodique(en gnral
annuellement) pour rester en adquation avec les objectifs globaux de lentit.
Le SMSI tabli, document, mis en uvre et entretenu. Son efficacit est mesure par rapport
aux objectifs de lentit, et cette mesure permet damliorer en permanence le SMSI.
Le SMSI est cohrent avec les autres systmes de management de lentit, notamment avec
les systmes de management de la qualit, de la scurit des conditions de travail, et de
lenvironnement.
N2TR
Page 14
Le SMSI inclut donc au minimum :

*des lments documentaires (politique, description des objectifs, cartographie des processus
impacts, des activits de scurit, et des mesures),
*la description de la mthode danalyse des risques utiliss,
*les processus impliqus dans la mise en uvre de la scurit de linformation,
*les ressources ncessaires sa mise en uvre,
*les activits relatives la scurit de linformation.
Lexistence dun SMSI dans lorganisme permet de renforcer la confiance dans le mode de
gestion de la scurit de linformation.
1-
Comment mettre en place un SMSI :
Ladoption dun SMSI est une dcision stratgique pour un organisme. Sa

conception, son implmentation et son organisation dpendent des besoins de scurit de
lorganisme. Ces besoins sont eux-mmes fonction du mtier de lorganisme, des exigences
de scurit (client/ interne) qui en rsultent, des processus mis en place, de sa taille et de sa
structure.
Pour initialiser une dmarche de SMSI, lorganisme doit :
Dterminer le primtre (fonctionnel, gographique, organisationnel, etc.) concern.
Identifier parmi les processus de ce primtre, ceux qui sont concerns par la scurit
de linformation, et leurs risques associs.
Dterminer les exigences (objectifs, rfrentiels, mthodes, etc..) ncessaires pour
assurer la scurit des processus,
Dfinir les mesures de scurit ncessaires pour se conformer aux exigences
exprimes.
Les processus ncessaires au SMSI comprennent ceux relatifs :
Aux activits de management,

la mise disposition de ressources,
la ralisation des produits/ services,
aux mesures et lamlioration.
Si lorganisme dcide dexternaliser un processus ayant une incidence sur la scurit, il doit
en assurer la maitrise et mentionner dans le SMSI les moyens de cette maitrise.
N2TR
Page 15
2.
Architecture de lISO 27001 :
Cette architecture met en relief la dcomposition de cet ISO en deux parties, un

usage obligatoire dans la certification de la SMSI et un autre usage facultatif o il ya le
vocabulaire, les mesures de scurit, limplmentation, le mtrage et mtriques, la gestion de
risques, laudit de SMSI. Le shma suivant nous explique cette dcomposition :
Figure 1:Architecture de lISO 27001
3.
Processus de lISO 27001 de lSMSI :
La norme ISO 27001 est destine sappliquer un systme de management de la

scurit de linformation (SMSI) ; elle comporte notamment un schma de certification
susceptible dtre appliqu au SMSI au moyen dun audit.
Comme toutes les normes relatives aux systmes de management, ISO 27001 repose sur une
approche par processus, et plus prcisment sur le modle PDCA. Les SMSI fonctionnent
selon un modle cyclique en 4 tapes appel PDCA cest--dire Plan, Do, Check, Act.
N2TR
Page 16
Figure 2:Etapes de la phase Plan du PDCA
1. Phase Plan : consiste planifier les actions que lentreprise va entreprendre en termes
de scurit,
2. Phase Do : lentreprise ralise ce quelle a planifi dans ce domaine,
3. Phase Check : lentreprise vrifie quil nexiste pas dcart entre ce quelle a dit et ce
quelle a fait,
4. Phase Act : consiste entreprendre des actions correctives pour les carts qui ont t
constats prcdemment.
La norme 27001 comporte 9 chapitres dont 5 (les chapitres 4 8) doivent
obligatoirement tre respects pour rpondre cette norme et obtenir une certification.
Le chapitre 4 est au cur de la norme et est divis en plusieurs parties correspondant aux 4
phases du PDCA. Il dtermine la mise en place du SMSI, son implmentation et son
exploitation, le contrle du SMSI et son amlioration. Le chapitre 5 dfinit les engagements et
responsabilits de la direction, le chapitre 6 dveloppe les questions daudits internes du
SMSI tandis que les 7me et 8me prcisent respectivement le rexamen du SMSI par la
direction et son amlioration.
N2TR
Page 17
Phase Plan : fixe les objectifs du SMSI La phase Plan du SMSI comprend 4 tapes :
Etape 1 : Dfinir la politique et le primtre du SMSI

Primtre : domaine dapplication du SMSI. Son choix est libre mais doit tre bien dfini car
il doit inclure toutes les activits pour lesquelles les parties prenantes exigent de la confiance.
Politique : niveau de scurit (intgrit, confidentialit, disponibilit de linformation) qui
sera pratiqu au sein de lentreprise. La norme nimpose pas de niveau minimum de scurit
atteindre dans le SMSI.
Le choix du primtre et de la politique tant libre, ces deux lments sont des leviers de
souverainet pour lentreprise. Ainsi une entreprise peut tre certifie ISO 27001 tout en
dfinissant un primtre trs rduit et une politique de scurit peu stricte et sans rpondre
aux exigences de ses clients en termes de scurit.
Etape 2 : Identifier et valuer les risques lis la scurit et laborer la politique de
scurit
La norme ISO 27001 ne donne pas de directives sur la mthode dapprciation des risques
adopter. Les entreprises peuvent donc en inventer une en veillant bien respecter le cahier des
charges ou en choisir une parmi les plus courantes notamment la mthode EBIOS (Expression
des Besoins et Identification des Objectifs de Scurit) mise en place en France par l'ANSSI
(Agence Nationale de la Scurit des Systmes dInformation). Le cahier des charges relatif
lapprciation des risques se dveloppe en 7 points :
1.
2.
3.
4.
5.
6.
7.
Identifier les actifs

Identifier les personnes responsables
Identifier les vulnrabilits
Identifier les menaces
Identifier les impacts
Evaluer la vraisemblance
Estimer les niveaux de risque
Etape 3 : Traiter le risque et identifier le risque rsiduel par un plan de gestion

Il existe 4 traitements possibles de chacun des risques identifis :
1. Lacceptation : ne mettre en place aucune mesure de scurit supplmentaire car les
consquences de cette attaque sont faibles (exemple : vol dun ordinateur portable ne
comportant pas de donnes primordiales pour lentreprise, piratage de la vitrine
N2TR
Page 18
web). Cette solution ne doit tre que ponctuelle pour viter la perte de confiance des
parties prenantes.
2. Lvitement : politique mise en place si lincident est jug inacceptable
3. Le transfert : lorsque le risque ne peut pas tre vit et quelle ne peut pas mettre en
place les mesures de scurit ncessaires elle transfre le risque par le biais de la
souscription dune assurance ou de lappel la sous-traitance.
4. La rduction : le rendre un niveau acceptable par la mise en uvre de mesures
techniques et organisationnelles, solution la plus utilise.
Lorsque la dcision de traitement du risque est prise lentreprise doit identifier les risques
rsiduels cest--dire ceux qui persistent aprs la mise en place des mesures de scurit. S'ils
sont jugs inacceptables, il faut dfinir des mesures de scurit supplmentaires.
Etape 4 : Slection des mesures de scurit mettre en place
La norme ISO 27001 dispose dune annexe A qui propose 133 mesures de scurit classes
en 11 catgories (politique de scurit, scurit du personnel, contrle des accs) et
numrotes sur 3 niveaux, dont on a parler essentiellement des articles A5, A6.1, A10, A6,
A9.2, A10, A10.5, A13. Toutefois cette annexe nest quune liste qui ne donne aucun conseil
de mise en uvre au sein de lentreprise.
Phase Do : elle met en place les objectifs fixs, et se dcoupe en plusieurs tapes :
1. Etablir un plan de traitement des risques
2. Dployer les mesures de scurit
3. Gnrer des indicateurs
o De performance pour savoir si les mesures de scurit sont efficaces
o De conformit qui permettent de savoir si le SMSI est conforme ses
spcifications
4. Former et sensibiliser le personnel
Phase Check : consiste grer le SMSI au quotidien et dtecter les incidents en
permanence pour y ragir rapidement 3 outils peuvent tre mis en place pour dtecter ces
incidents :
1. Les audits internes qui vrifient la conformit et lefficacit du systme de
management. Ces audits sont ponctuels et planifis lavance.
2. Le contrle interne qui consiste sassurer en permanence que les processus
fonctionnent normalement.
3. Les revues (ou rexamens) qui garantissent ladquation du SMSI avec son
environnement.
N2TR
Page 19
Phase Act : mettre en place des actions correctives, prventives ou damlioration pour les
incidents et carts constats lors de la phase Check
Actions correctives : agir sur les effets pour corriger les carts puis sur les causes pour
viter que les incidents ne se reproduisent
Actions prventives : agir sur les causes avant que lincident ne se produise
Actions damlioration : amliorer la performance dun processus du SMSI.
4.
Dclaration d'applicabilit
Qu'est qu'une dclaration d'applicabilit? L'annexe de L'ISO 27001 fait la liste des mesures
de contrle les plus rgulires, soit 133 contrles catgoriss en 39 objectifs de contrles, dont
on a parler essentiellement des articles A5, A6.1, A10, A6, A9.2, A10, A10.5, A13. On s'en
sert comme une liste de vrification afin d'tablir quels sont les mesures de contrles
appropries et/ou dj mises en place dans l'entreprise. Comme exemple de contrle, la
protection contre les intrusions est faite via un couvre-feu et un logiciel anti-virus mis jour
rgulirement ou encore; le vol de documents sensibles est assur par des classeurs sous cls
et des locaux avec serrures, un systme d'alarme et une sensibilisation du personnel cet
effet. Pour chacun des contrles, une valuation d'applicabilit est faite. Une grille Excel est
utilise cet effet et un responsable est indiqu pour chacun des contrles applicables.
Certains sont peu coteux, d'autres ncessitent une infrastructure plus ou moins onreuse.
5.
Mthodes dapprciation des risques
En 2004, une tude du CLUSIF (Club de la Scurit de lInformation Franais) dnombrait

plus de deux cents mthodes dapprciation des risques. Nous en avons retenu deux, EBIOS,
MEHARI qui pour lENISA (European Network and Information Security Agency) figurent
parmi les plus utilises.
EBIOS
Dveloppe dans les annes 90 sous l'autorit de lagence franaise ANSSI (Agence nationale
de la scurit des systmes dinformation), cette mthode est lExpression des Besoins et
Identification des Objectifs de Scurit. Elle permet dapprcier, de traiter et communiquer
sur les risques au sein dun SMSI.
LANSSI et le Club EBIOS14 proposent en libre accs sur leur site web toute la
documentation15 ainsi quun logiciel libre16 facilitant lutilisation de la mthode.
Lapproche de la mthode est itrative, chaque module peut tre rvis, amlior et tenu jour
de manire continue.
EBIOS se compose de cinq modules :
N2TR
Page 20
Module 1 : il concerne ltude du contexte. Il sagit de dtailler lorganisation, les missions,

les contraintes et les mtiers pour rendre applicable et cohrent le choix des objectifs de
scurit. Le point suivant consiste identifier les fonctions estimes sensibles, la perte, le
dysfonctionnement ou la divulgation dinformations qui peuvent avoir des rpercussions sur
le bon fonctionnement de lorganisme.
Enfin, on rpertorie sous forme de matrice les entits17 techniques propres au SMSI
(matriel, logiciels, rseaux) ainsi que les entits organisationnelles (groupes de
collaborateurs) pour tablir les liens entre les lments essentiels et les entits.
Module 2 : il concerne ltude des vnements redouts. Cette tape permet de dfinir les
besoins de scurit des lments essentiels prcdemment identifis. On quantifie les besoins
sur une chelle de 0 4 laide dun questionnaire que lon adresse aux collaborateurs de
lorganisme. Les besoins sont slectionns sur des critres de scurit tels que la disponibilit,
lintgrit, la confidentialit et la non-rpudiation ainsi que sur des critres dimpacts18
(interruption de services, dommages matriels).
Module 3 : consiste tudier les scnarios de menaces. Estimer, valuer les menaces
(incendie, perte dalimentation lectrique, divulgation dinformation etc.) et identifier les
objectifs de scurit qu'il faut atteindre pour les traiter. EBIOS fournit une liste de menaces
que lon associe aux lments essentiels dfinis dans le module 1. Puis on attribue chaque
lment un niveau de vulnrabilit sur une chelle de 0 4.
Module 4 : il vise tudier les risques. Cette tape permet de dresser une cartographie des
risques. Elle explique aussi comment traiter le risque. Estimer, valuer les risques puis
identifier les objectifs de scurit atteindre pour les traiter.
Module 5 : il concerne ltude des mesures de scurit. Cette dernire tape explique
comment appliquer les mesures de scurit mettre en uvre, comment planifier la mise en
uvre de ces mesures et comment valider le traitement des risques rsiduels.
En conclusion, la mthode EBIOS par son caractre exhaustif, permet de formaliser tout le
SMSI et son environnement. Cette mthode contribue formuler une politique de scurit du
systme dinformation. Cest une des mthodes pour mettre en uvre le cadre dfini par
l'ISO/CEI 27005. Elle rpond aux exigences de lISO/CEI 27001 et peut exploiter les mesures
de scurit de l'ISO/CEI 27002.
MEHARI
La mthode MEHARI (Mthode Harmonise dAnalyse de Risques) a t dveloppe dans
les annes 1990 par le CLUSIF19 (Club de la Scurit de l'Information Franais). A lorigine,
cette mthode ne traitait que de lanalyse des risques. Elle a volu pour permettre une gestion
de la scurit de lorganisme dans un environnement ouvert et gographiquement rparti.
N2TR
Page 21
MEHARI a t adopte par des milliers dorganismes travers le monde et reste la mthode
la plus utilise en France, en particulier dans l'industrie. Lutilisation et la distribution de son
logiciel sont libres. En outre, certaines bases de connaissances sont disponibles et une tude
illustre la mthode pour faciliter son utilisation.
MEHARI s'appuie sur deux mthodes anciennes aujourdhui abandonnes, appeles
MARION20 (Mthode d'Analyse de Risques Informatiques Optimise par Niveau) et
MELISA (Mthode d'valuation de la Vulnrabilit Rsiduelle des Systmes d'armement).
Contrairement la mthode EBIOS, MEHARI repose sur des scnarios de risques qui
permettent didentifier les risques potentiels au sein de lorganisme. Elle est dfinie comme
une bote outils conue pour la gestion de la scurit. En fonction des besoins, des choix
dorientation, de politique de l'organisation ou simplement des circonstances, la mthode
veille ce qu'une solution dapprciation des risques approprie puisse tre labore. La
mthode est prsente sous la forme d'un ensemble que l'on appelle modules, centrs sur
l'valuation des risques et leur gestion.
Figure 3:Utilisation des modules de MEHARI
En conclusion, la mthode MEHARI, se caractrise par une dmarche descendante , c'est-dire une dlgation des dcisions de la direction vers les entits oprationnelles.
Elle convient bien aux organisations multi-environnements. Cette mthode est conforme au
cahier des charges impos par lISO/CEI 27001.
N2TR
Page 22
6.
Analyse de risque :
Les exigences de scurit (Disponibilit, Intgrit, Confidentialit, Preuve) sont dfinies par
les propritaires des informations.
Le responsable de lanalyse des risques partir de lidentification exhaustive des actifs
sensibles de lentreprise, des menaces pesant sur ces derniers et des vulnrabilits quelles
pourraient exploiter, value les risques.
7.
Gestion du risque :
Le RSSI est le principal acteur qui sadresse ce document. Il devra :

dfinir la dmarche suivre (description des tapes ncessaires) pour tablir son SMSI,
proposer les mesures de scurit mettre en place a priori .
La direction gnrale a pour attribution principale :
daffecter les ressources humaines financires ncessaires la mise en uvre des
mesures et ventuellement daccepter certains risques pour lentreprise,
de valider et sengager sur les objectifs de la politique de scurit.
Les diffrentes structures de lentreprise devront mettre en place les mesures valides par la
direction gnrale.
8.
Processus damlioration continue :
Le Contrle Interne ou Audit a en charge la conduite de missions daudit interne de la gestion

de la politique de scurit dploye. Le document prcise les modalits (la priodicit, les
objets et la qualit) de ses audits du SMSI.
Pourquoi l'ISO 27001 pour la SSI ?
N2TR
Amlioration continue.
Gestion du temps.
Ce qui n'a cess de manquer la SSI depuis son existence universalit.
Pas de concurrence.
Applicable tous les mtiers, tous les secteurs d'activit.
Applicable toutes les tailles d'entreprises ou de primtres compltude.
Mthodologie d'apprciation des risques
Mthodologie de construction d'indicateurs et processus d'amlioration continue
Page 23
III.
Conclusion :
Ce chapitre est une introduction au systme de management de scurit de

linformation. Il passe en revue les notions indispensables considrer avant de se lancer dans
le dveloppement dun systme de scurit de linformation en gnral, et la ncessit dun
SMSI pour la scurit dun systme dinformation pour la poste tunisienne plus prcisment.
Ltude synthtise des exemples de quelques normes montre qu chaque socit peut
correspondre un ensemble de fonctionnalits adaptes et donc un systme de management de
scurit de linformation potentielle.
Cependant, dans un choix raisonn dun SMSI, il semble indispensable de bien dfinir un
cahier des charges pour le projet de management envisag et ses objectifs. Cest pour cela que
plusieurs tentatives de standardisation de ces environnements ont t proposes.
N2TR
Page 24
Chapitre III : Conception
N2TR
Page 25
I.
Introduction
Le cycle de vie d'un logiciel (en anglais software lifecycle), dsigne toutes les
tapes du dveloppement d'un logiciel, de sa conception sa disparition. L'objectif d'un tel
dcoupage est de permettre de dfinir des jalons intermdiaires permettant la validation du
dveloppement logiciel, c'est--dire la conformit du logiciel avec les besoins exprims, et la
vrification du processus de dveloppement, c'est--dire l'adquation des mthodes mises en
uvre.
Le cycle de vie du logiciel comprend gnralement au minimum les activits suivantes :
Dfinition des objectifs, consistant dfinir la finalit du projet et son inscription dans une
stratgie globale.
Analyse des besoins et faisabilit, cest--dire l'expression, le recueil et la formalisation des
besoins du demandeur (le client) et de l'ensemble des contraintes.
Conception gnrale. Il s'agit de l'laboration des spcifications de l'architecture gnrale du
logiciel.
Conception dtaille, consistant dfinir prcisment chaque sous-ensemble du logiciel.
Codage (Implmentation ou programmation), soit la traduction dans un langage de
programmation des fonctionnalits dfinies lors de phases de conception.
Tests unitaires, permettant de vrifier individuellement que chaque sous-ensemble du
logiciel est implment conformment aux spcifications.
Intgration, dont l'objectif est de s'assurer de l'interfaage des diffrents lments (modules)
du logiciel. Elle fait l'objet de tests dintgrations consignes dans un document.
Qualification (ou recette), c'est--dire la vrification de la conformit du logiciel aux
spcifications initiales.
Documentation, visant produire les informations ncessaires pour l'utilisation du logiciel et
pour des dveloppements ultrieurs.
Mise en production, Cest le dploiement sur site du logiciel
Maintenance, comprenant toutes les actions correctives (maintenance corrective) et
volutives (maintenance volutive) sur le logiciel.
N2TR
Page 26
La squence et la prsence de chacune de ces activits dans le cycle de vie dpend du choix
d'un modle de cycle de vie entre le client et l'quipe de dveloppement.
II.
Modles de cycles de vie

Afin d'tre en mesure d'avoir une mthodologie commune entre le client et la socit de
service ralisant le dveloppement, des modles de cycle de vie ont t mis au point
dfinissant les tapes du dveloppement ainsi que les documents produire permettant de
valider chacune des tapes avant de passer la suivante.
1. Modle en cascade
Figure 4: Modle du cycle de vie en cascade
Le modle de cycle de vie en cascade a t mis au point ds 1966, puis formalis aux
alentours de 1970.
N2TR
Page 27
Dans ce modle le principe est trs simple : chaque phase se termine une date prcise par la
production de certains documents ou logiciels. Les rsultats sont dfinis sur la base des
interactions entre tapes, ils sont soumis une revue approfondie et on ne passe la phase
suivante que sils sont jugs satisfaisants.
Le modle original ne comportait pas de possibilit de retour en arrire. Celle-ci a t rajoute
ultrieurement sur la base quune tape ne remet en cause que ltape prcdente, ce qui, dans
la pratique, savre insuffisant.
Linconvnient majeur du modle de cycle de vie en cascade est que la vrification du bon
fonctionnement du systme est ralise trop tardivement: lors de la phase dintgration, ou
pire, lors de la mise en production.
2. Modle en V
Le modle de cycle de vie en V part du principe que les procdures de vrification de la
conformit du logiciel aux spcifications doivent tre labores ds les phases de conception.
Figure 5: Modle du cycle de vie en V
Le modle en V demeure actuellement le cycle de vie le plus connu et certainement le plus

utilis. Il sagit dun modle en cascade dans lequel le dveloppement des tests et des logiciels
sont effectus de manire synchrone.
N2TR
Page 28
Le principe de ce modle est quavec toute dcomposition doit tre dcrite la recomposition et
que toute description dun composant est accompagne de tests qui permettront de sassurer
quil correspond sa description.
Ceci rend explicite la prparation des dernires phases (validation-vrification) par les
premires (construction du logiciel), et permet ainsi dviter un cueil bien connu de la
spcification du logiciel : noncer une proprit quil est impossible de vrifier objectivement
aprs la ralisation.
La reprsentation en V tient d'avantage compte de la ralit, le processus de dveloppement
n'est pas rduit un enchanement de tches squentielles. Elle montre que:
Cest en phase de spcification que l'on se proccupe des procdures de qualification.
c'est en phase de conception globale que l'on se proccupe des procdures
d'intgration.
C'est en phase de conception dtaille que l'on prpare les tests unitaires.
Le modle de cycle de vie en V permet d'anticiper sur les phases ultrieures de
dveloppement du produit. En particulier le modle en V permet de commencer plus tt:
Plan de tests de qualification.
Plan d'valuation des performances.
Cependant, ce modle souffre toujours du problme de la vrification trop tardive du bon
fonctionnement du systme.
3. Le modle en spirale
(spiral model) est un modle de cycle de dveloppement logiciel qui reprend les diffrentes
tapes du cycle en V. Par l'implmentation de versions successives, le cycle recommence en
proposant un produit de plus en plus complet et dur. Le cycle en spirale met cependant plus
l'accent sur la gestion des risques que le cycle en V.
On distingue quatre phases dans le droulement du cycle en spirale :
III.
dtermination des objectifs, des alternatives et des contraintes.

analyse des risques, valuation des alternatives.
dveloppement et vrification de la solution retenue.
revue des rsultats et vrification du cycle suivant.
Mthodologies de conception :
1. Etude comparative entre MERISE et UML :
N2TR
Page 29
MERISE (Mthode dEtude et de Ralisation Informatique pour les Systmes dEntreprise)

est une mthode d'analyse et de ralisation des systmes d'information qui est labore en
plusieurs tapes: schma directeur, tude pralable, tude dtaille et la ralisation.
Alors que UML (Unified Modeling Langage), est un langage de modlisation des systmes
standard, qui utilise des diagrammes pour reprsenter chaque aspect d'un systme ie: statique,
dynamique,....en s'appuyant sur la notion d'orient objet qui est un vritable atout pour ce
langage.
Merise ou UML ?
Les "mthodologues" disent qu'une mthode, pour tre oprationnelle, doit avoir 3
composantes:
une dmarche (les tapes, phases et tches de mise en oeuvre),
des formalismes (les modlisations et les techniques de transformation),
une organisation et des moyens de mise en oeuvre.
Merise s'est attache, en son temps, proposer un ensemble "cohrent" sur ces trois
composantes. Certaines ont vieilli et ont du tre ractualises (la dmarche), d'autre "tiennent
encore la route" (les modlisations).
UML se positionne exclusivement comme un ensemble de formalismes. Il faut y associer une
dmarche et une organisation pour constituer une mthode.
Merise se positionne comme une mthode de conception de SI organisationnel, plus tourne
vers la comprhension et la formalisation des besoins du mtier que vers la ralisation de
logiciel. En sens, Merise se rclame plus de l'ingnierie du SI mtier que du gnie logiciel.
Jamais Merise ne s'est voulu une mthode de dveloppement de logiciel ni de programmation.
UML, de par son origine (la programmation objet) s'affirme comme un ensemble de
formalismes pour la conception de logiciel base de langage objet.
Merise est encore tout fait valable pour:
la modlisation des donnes en vue de la construction d'une base de donnes
relationnelle, la modlisation des processus mtiers d'un SI automatis en partie par du
logiciel,
la formalisation des besoins utilisateur dans le cadre de cahier des charges utilisateur,
en vue de la conception d'un logiciel adapt.
UML est idal pour :
N2TR
Page 30
concevoir et dployer une architecture logiciel dveloppe dans un langage objet

(Java, C++, VB.net). Certes UML, dans sa volont "unificatrice" a propos des
formalismes.
pour modliser les donnes (le modle de classe rduit sans mthodes et strotyp en
entits), mais avec des lacunes que ne prsentait pas l'entit relation de Merise.
pour modliser le fonctionnement mtier (le diagramme d'activit et de cas
d'utilisation) qui sont des formalismes trs anciens qu'avait, en son temps, amlior
Merise...
Aprs cette tude comparative, il est certes que je vais adopter UML comme langage de
modlisation puisque je vais utiliser le concept de lorienter objet ainsi JAVA comme
langage, pour dvelopper lapplication de lSMSI pour la poste tunisienne.
2. La dmarche adopte :
La dmarche que jadopte sinspire du Processus Unifi, dans la mesure o elle suit
les cinq activits cites prcdemment et sera ralise en une seule itration.
Je justifie mon choix par le fait que les besoins de mon futur systme, quoi que nombreux,
sont clairs et dfinis ds le dpart. Il est donc inutile de les analyser selon plusieurs itrations.
Ainsi, dans chaque activit, je traite les cas dutilisation qui traduisent les fonctionnalits du
futur systme et qui seront analyss et conus de faon dtaille.
Mon outil de conception UML est le logiciel Rational Rose 2003 Enterprise Edition de
Rational Software Corporation. Cest une rfrence pour la modlisation UML. Je vais
lutiliser pour raliser tous les diagrammes UML.
Il ya 9 types de diagrammes :
N2TR
Page 31
Figure 6: les diffrents types de diagrammes
Dans notre travail, on va essayer de travailler avec deux vues (trois diagrammes)
Vue statique :
- diagramme de cas d'utilisation : dcrit les besoins utilisateurs.
-diagramme des classes : dfinit la structure statique.
Vue dynamique :
- diagramme de squence : scnarios et flots de messages
IV.
Conception dtaille :
Cas dutilisation
Acteurs
Authentification
utilisateur (site)/
responsable (administrateur).
Rclamation
utilisateur (site)
Service
utilisateur (site)
contrler les services
responsable (administrateur)
N2TR
Page 32
1.
Authentification :
Description :
Dans un souci de scurit de notre systme, et la scurisation de linformation, avant
deffectuer une tche quelconque, tous les utilisateurs du systme doivent sidentifier en
saisissant leurs identificateurs (Login, Password) respectifs.
SOMMAIRE D'IDENTIFICATION
Titre :
Exprimer une Authentification.
But :
Entrer un login et un password pour pouvoir connecter.
Rsum :
Aprs avoir entr Login et Password, lutilisateur peut accder seulement

linterface site sil est client, ou peut accder aux diffrents sites et consulter les
donnes sil est administrateur (central).
Acteur :
utilisateur
DESCRIPTION DES ENCHAINEMENTS

Pr conditions
Post conditions
Identifiant ().
-afficher linterface site, ou
Mot de passe ().
-afficher linterface centrale et pouvoir

consulter les donnes de tous les sites.
Scnario nominal
1. Lutilisateur sauthentifier.
2. si les donnes sont correctes, le contenu de la plateforme saffiche.
3.. Lutilisateur choisit une tache ( partir des menus).
4.. lorsque lutilisateur click sur une tache, il peut consulter ce quil se trouve sur la
plateforme.
Enchanement alternatif
E1 : champs authentifiant ou mot de passe est faut ou vide.
1. Le systme affiche un message derreur
N2TR
Page 33
2. Le scnario reprend au point 1
Diagramme 1: Diagramme de cas dutilisation Authentification
N2TR
Page 34
Diagramme 2: Diagramme de squence Authentification
Diagramme 3: Diagramme de classe Authentification
N2TR
Page 35
Cration dun nouveau compte :
2.
Description :
La cration dun nouveau compte par le responsable se limite crer une instance de la classe
Authentification et une autre de la classe des utilisateurs; le responsable doit remplir les
informations du nouvel utilisateur lors de linscription.
SOMMAIRE D'IDENTIFICATION
Titre :
Crer un nouveau compte.
But :
Cration dun nouveau compte sil ya ajout dun nouveau site.
Rsum :
Le responsable au droit dajouter ou de crer un nouveau compte chaque fois

il ya ncessite, une fentre saffiche pour enregistrer les informations propos
le nouveau site.
Acteur :
responsable

Pr conditions
Post conditions
Identifiant ().
-afficher le menu.
Mot de passe ().
-choisir le menu crer compte.

-valider la cration.
Scnario nominal
3. Le responsable sauthentifi.
2. une fentre responsable sera affiche.
3. Le responsable choisit le menu crer compte .
4. le responsable remplit le formulaire
5. le responsable valide la cration.
E1 : champs authentifiant ou mot de passe est faut ou vide.
N2TR
Page 36
2. Le scnario reprend au point 1
Diagramme 4: Diagramme de squence cration dun nouveau compte
3.
Communication:
SOMMAIRE De Service
Titre :
Choisir le menu communication et choisir la commande faire (changer mot de

passe, donnes critiques, rupture exportation, demande).
But :
Afficher les diffrentes demandes, et envoyer la demande concerne.
Rsum :
Aprs avoir choisi la commande, le client doit remplir un formulaire et cliquer

sur le bouton envoyer.
Acteur :
client.
N2TR
Page 37

Pr conditions
Post conditions
Authentification ().
Remplir le formulaire et cliquer sur le bouton

envoyer.
Choix de la commande par le client.

Scnario nominal
1. Le client choisit une commande depuis la liste de menu demande.

2. le client doit remplir le formulaire.
3. le client doit cliquer sur le bouton envoyer.
E1 : Liste de commandes non affiche.
1. Le systme affiche un message derreur vous navez pas le droit de donner une
demande maintenant
Diagramme 5: Diagramme cas dutilisation Communication

N2TR
Page 38
Diagramme 6: Diagramme de classe Communication.
4.
Contrler les services:
SOMMAIRE de contrler les services

Titre :
Contrler les services.
But :
Contrler tous les clients et scuriser linformation.
Rsum :
Le responsable peut consulter, contrler, et modifier quelques donnes critiques

de tous les sites afin de pouvoir rectifier un paiement faut, dpanner un
problme rseaux, importer la base de donne, contrler le service informatique
et les fournisseurs, essayer de minimiser la tolrance de panne
Acteur :
responsable (central).

Pr conditions
N2TR
Post conditions
Page 39
-Authentification.
-consulter les rclamations.
-Accessibilit de voir tous les clients.
- consulter les services.

-rpondre aux besoins clients.
- contrler les services et les pannes.
-importation et exportation de la base.
Scnario nominal
1. le responsable peut accder tous les clients.
2. il consulte, contrle, et exploite les donnes
E1 : Liste de clients vide
2. Le scnario affiche linterface responsable.
E2 : ne peut pas accder aux clients
2. Le scnario affiche la liste de clients.
N2TR
Page 40
Diagramme 7: Diagramme de cas dutilisation Contrler les services.
Diagramme 8: Diagramme de squence Contrler les services

N2TR
Page 41
5.
Diagramme de classe de SMSI :
Diagramme 9: Diagramme de classe de SMSI .
6.
Conclusion
Ce chapitre est dune grande importance pour la suite du travail ; du fait quil projette
les notions thoriques vues dans ltude bibliographique sur un cas pratique dun systme de
management de scurit de linformation et quil traite de la conception du systme raliser ;
sans laquelle la ralisation ne pourra se faire comme il se doit. Nous y avons dabord dcrit le
fonctionnement gnral de notre systme de scurisation de linformation, puis expliqu le
fonctionnement dtaill de chaque sous-systme composant le systme global par le moyen de
schmas explicatifs et une modlisation par des diagrammes UML. La partie suivante du
document sera consacre limplmentation et la mise en uvre technique du SMSI.
N2TR
Page 42
Chapitre IV : Ralisation
N2TR
Page 43
I.
Introduction :
Ce chapitre traite des aspects techniques lis limplmentation et la mise en uvre
de notre systme de management de scurit de linformation base sur MySQL. Nous y
prsenterons dabord nos choix des technologies et outils adopts pour le dveloppement du
systme. Nous aborderons ensuite les principales fonctionnalits offertes par notre application
aux diffrents types dutilisateurs (responsable, clients) ainsi leur droit daccs. Les prises
dcrans et les explications assez approfondies sont mme de rsumer le fonctionnement
global du systme (SMSI de la poste tunisienne).
II.
Environnement logiciel :
1.
Description du modle Vue Contrleur MVC2 :
L'organisation globale d'une interface graphique est souvent dlicate. L'architecture

MVC ne rsout pas tous les problmes. Elle fournit souvent une premire approche qui peut
ensuite tre adapte. Elle offre aussi un cadre pour structurer une application.
Ce modle d'architecture impose la sparation entre les donnes, la prsentation et les
traitements, ce qui donne trois parties fondamentales dans l'application finale : le modle, la
vue et le contrleur
a-
Le modle
Le modle reprsente le comportement de l'application : traitements des donnes,

interactions avec la base de donnes, etc. Il dcrit ou contient les donnes manipules par
l'application. Il assure la gestion de ces donnes et garantit leur intgrit. Dans le cas typique
d'une base de donnes, c'est le modle qui la contient. Le modle offre des mthodes pour
mettre jour ces donnes (insertion, suppression, changement de valeur). Il offre aussi des
mthodes pour rcuprer ces donnes. Les rsultats renvoys par le modle sont dnus de
toute prsentation.
Dans le cas de donnes importantes, le modle peut autoriser plusieurs vues partielles
des donnes. Si par exemple le programme manipule une base de donnes pour les emplois du
temps, le modle peut avoir des mthodes pour avoir tous les cours d'une salle, tous les cours
d'une personne ou tous les cours d'un groupe de TD.
N2TR
Page 44
b-
La vue
La vue correspond l'interface avec laquelle l'utilisateur interagit. Sa premire tche

est de prsenter les rsultats renvoys par le modle. Sa seconde tche est de recevoir toutes
les actions de l'utilisateur (clic de souris, slection d'une entre, boutons, etc). Ces diffrents
vnements sont envoys au contrleur. La vue n'effectue aucun traitement, elle se contente
d'afficher les rsultats des traitements effectus par le modle et d'interagir avec l'utilisateur.
Plusieurs vues, partielles ou non, peuvent afficher des informations d'un mme modle. Par
exemple, une application de conversion de bases a un entier comme unique donne. Ce mme
entier peut tre affich de multiples faons (en texte dans diffrentes bases, bit par bit avec
des boutons cocher, avec des curseurs). La vue peut aussi offrir la possibilit l'utilisateur
de changer de vue.
Elle peut tre conue en html, ou tout autre langage de prsentation.
c-
Le contrleur
Le contrleur prend en charge la gestion des vnements de synchronisation pour

mettre jour la vue ou le modle et les synchroniser. Il reoit tous les vnements de
l'utilisateur et enclenche les actions effectuer. Si une action ncessite un changement des
donnes, le contrleur demande la modification des donnes au modle, ce dernier avertit la
vue que les donnes ont change pour qu'elle se mette jour. Certains vnements de
l'utilisateur ne concernent pas les donnes mais la vue. Dans ce cas, le contrleur demande
la vue de se modifier. Le contrleur n'effectue aucun traitement, ne modifie aucune donne. Il
analyse la requte du client et se contente d'appeler le modle adquat et de renvoyer la vue
correspondant la demande.
Par exemple, dans le cas d'une base de donnes grant les emplois du temps des professeurs
d'une cole, une action de l'utilisateur peut tre l'entre (saisie) d'un nouveau cours. Le
contrleur ajoute ce cours au modle et demande sa prise en compte par la vue. Une action de
l'utilisateur peut aussi tre de slectionner une nouvelle personne pour visualiser tous ses
cours. Ceci ne modifie pas la base des cours mais ncessite simplement que la vue s'adapte et
offre l'utilisateur une vision des cours de cette personne.
Quand un mme objet contrleur reoit les vnements de tous les composants, il lui faut
dterminer quelle est l'origine de chaque vnement. Ce tri des vnements peut s'avrer
fastidieux et peut conduire un code pas trs lgant C'est pourquoi le contrleur est souvent
scind en plusieurs parties dont chacune reoit les vnements d'une partie des composants.
N2TR
Page 45
2.
a-
Description de la diffrence entre le modle MVC1 et MVC2 :

Le modle MVC type 1
Dans ce modle, chaque requte est traite par un contrleur sous la forme d'une
servlet. Celle-ci traite la requte, fait appel aux lments du model si ncessaire et redirige la
requte vers une JSP qui se charge de crer la rponse l'utilisateur.
Figure 7: les diffrents types de diagrammes

L'inconvnient est donc une multiplication du nombre de servlets ncessaire l'application :
l'implmentation de plusieurs servlets ncessite beaucoup de code produire d'autant que
chaque servlet doit tre dclare dans le fichier web.xml.
b-
Le modle MVC de type 2
Le principal dfaut du modle MVC est le nombre de servlets dvelopper pour une
application.
Pour simplifier les choses, le modle MVC model 2 ou MVC2 de Sun propose de n'utiliser
qu'une seule et unique servlet comme contrleur. Cette servlet se charge d'assurer le worflow
des traitements en fonction des requtes http reues.
N2TR
Page 46
Le modle MVC 2 est donc une volution du modle 1 : une unique servlet fait office de
contrleur et gre toutes les requtes traiter en fonction d'un paramtrage gnralement sous
la forme d'un fichier au format XML.
Figure 8: Le modle MVC de type 2

Le modle MVC II conserve les principes du modle MVC, mais il divise le
contrleur en deux parties en imposant un point d'entre unique toute l'application (premire
partie du contrleur) qui dterminera chaque requte reue les traitements applicatifs
invoquer dynamiquement (seconde partie du contrleur).
Une application web implmentant le modle MVC de type II utilise une servlet comme
contrleur traitant les requtes. En fonction de celles-ci, elle appelle les traitements ddis
gnralement encapsuls dans une classe.
Dans ce modle, le cycle de vie d'une requte est le suivant :
1. Le client envoie une requte l'application qui est prise en charge par la servlet faisant
office de contrleur.
2. La servlet analyse la requte et appelle la classe ddie contenant les traitements
3. Cette classe excute les traitements ncessaires en fonction de la requte notamment en
faisant appel aux objets mtiers.
4. En fonction du rsultat des traitements, la servlet redirige la requte vers la page JSP
5. La JSP gnre la rponse qui est renvoye au client
N2TR
Page 47
Figure 9: architecture du modle MVC de type 2
La seconde version de ce modle de conception se base sur la premire version. Suite

au retour dexprience sur lutilisation du MVC1, le modle a t revu pour tre
simplifi. Alors que dans un MVC1 il y a avait autant de contrleurs que dactions
possibles par lutilisateur, le MVC2 autorise la cration de contrleur grant un
ensemble dactions. Cela permet de rduire considrablement le nombre de
contrleurs et de les regrouper dun point de vue fonctionnel (ou en terme de use
case).
De plus, ce nouveau modle recommande lutilisation dun super contrleur. Ce
dernier reoit toutes les interactions de lutilisateur et les redirige vers le bon
contrleur.
3.
Description du Framework JPA :
L'intrt d'implmenter une couche de mapping objet-relationnel entre un modle

mtier objet et une base de donnes relationnelle n'est probablement plus dmontrer : le
code qui contient les requtes SQL est isol dans un endroit unique, permettant une adhrence
rduite au schma de la base ; le modle mtier peut respecter les principes de la
programmation objet, utiliser l'hritage et la navigation.
N2TR
Page 48
Issue des travaux du groupe d'experts de la JSR 220 (EJB 3), JPA est une spcification cl de
Java EE 5. Loin d'tre un framework de plus, JPA tablit une norme standard simplifie pour
la persistance afin de garantir une meilleure portabilit des applications Java EE 5. JPA
reprend naturellement les meilleures pratiques de Framework tablis tels Hibernate ou
TopLink. EJB 3 s'appuie sur JPA pour la persistance des entits.
4.
Cration de la base de donnes :
a. Dfinition
Visual Paradigm est un outil de modlisation UML. Il permet d'analyser, de dessiner, de
coder, de tester et de dployer. L'application vous permet de dessiner tous les types de
diagrammes UML, d'inverser le code source pour le modle UML, gnrer le code source
partir de diagrammes et d'laborer la documentation.
b. Description de la gnration du bas de donnes :
Figure 10: gnration du bas de donnes
N2TR
Page 49
III.
Environnement Matriel :
1.
Architecture matrielle :
Cette architecture nous montre comment tous les sites (clients) envoient la rclamation au
central (serveur), qui stocke toute les taches et les rclamations dans la base de donnes.
Figure 11: Architecture matriel de mon systme
2. Matriel utilis :
Pour la ralisation du projet, jai utilis : Un pc portable pour le dveloppement ayant les
caractristiques suivantes :
Processeur Intel Core 2 Duo 1.73 GHz,

1 Go de mmoire vive,
Disque dur de capacit 120 Go,
Systme dexploitation Microsoft Windows XP.
III.
Technologies :
JSF est un standard J2EE.
Java Server Faces est un Framework d'interface utilisateur pour les applications web, bas sur
les technologies JSP et Servlets.
N2TR
Page 50
Le but de JSF est d'accrotre la productivit des dveloppeurs dans le dveloppement des
interfaces utilisateur tout en facilitant leur maintenance.
Le support de JSF par les diteurs J2EE est obligatoire. Actuellement, les plus grands diteurs
Java annoncent ou proposent une intgration de JSF dans leurs IDEs.
JSF permet :
une sparation nette entre la couche de prsentation et les autres couches
le mapping HTML/Objet
un modle riche de composants graphiques rutilisables
une gestion de l'tat de l'interface entre les diffrentes requtes
une liaison simple entre les actions ct client de l'utilisateur et le code Java correspondant
ct Serveur
la cration de composants customs grce une API
IV.
Les composantes applicatives ralises

1.
Interface de connexion :
Cette interface donne la main aux utilisateurs pour accder aux diffrentes
interfaces, aprs la vrification si leur login et password existent dans la base de
donnes.
N2TR
Page 51
Figure 12: interface Authentification
Figure 13 : code source Authentification
2.
Interface de Rclamation:
Une fois lutilisateur a le droit daccder aux rclamations, il va choisir lune des
interfaces ; et rempli le formulaire (date, code type incident, action raliser..),
attentivement, ensuite, il doit lenregistrer dans la base de donne.
N2TR
Page 52
Figure 14: interface Client
Figure 15: code source cr Rclamation
N2TR
Page 53
Figure 16: interface Rclamation

Dans cette fiche, le client doit prciser le type dintervention, le systme, le fournisseur, et il
attend le fournisseur ou le technicien pour rsoudre le problme.
N2TR
Page 54
Figure 17: interface Rclamation sauvegarde
3.
Interface dAdministrateur :
Ladministrateur a le droit de consulter les diffrentes client, il a le droit aussi
deffacer, modifier, ou ajouter un client.
Figure 18: interface Administrateur

N2TR
Page 55
Figure 19: interface Cration d'un nouvel Utilisateur
Figure 20: interface List Authentification
N2TR
Page 56
CONCLUSION ET PERSPECTIVES
Mon projet a consist en la conception et le dveloppement dune application de

Systme de Management de Scurisation de lInformation au sein de la direction informatique
de la poste tunisienne qui cherche intgrer ce systme selon la norme ISO 27001, afin
dapporter une valeur ajoute et un meilleur service aux clients en ce qui concerne la
scurisation des informations et la gestion des risques.
Je suis arriv dvelopper une fonctionnalit du systme dans les temps. Le test a t ralis
avec succs, c'est--dire que lapplication est maintenant prte installer sur les diffrentes
rgions.
Ce stage a t pour moi, loccasion dune part dapprofondir mes connaissances thoriques,
acquises durant les 3 semestres de mon master, par la pratique des nouvelles technologies.
Cette exprience ma permis de matriser le langage UML, lenvironnement de
dveloppement java savoir lIDE Netbeans, sous lequel, le dveloppement na pas t une
tche facile, mais je nai pas hsit y participer.
Il ma galement permis de dcouvrir comment se passe lintgration dune application sur un
serveur web. Le stage quotidien au sein de la poste tunisienne a aussi t pour moi une
occasion unique pour panouir mes capacits de communication dans un environnement
professionnel. Cest une exprience trs enrichissante sur tous les domaines.
Enfin, lapplication que jai dvelopp pourrait tre enrichie par des fonctionnalits avances
telles que lintgration des nouvelles taches selon la ncessit des clients, la cration dun
protocole de communication ddi et plus scuris que le HTTP et pourquoi pas rendre
lapplication compatible avec plusieurs plateformes mobiles.
N2TR
Page 57
Annexe
Objectifs de scurit et mesures de scurit
Les objectifs de scurit et les mesures de scurit numrs dans le Tableau A.1 proviennent
directement et sont aligns sur les objectifs de scurit et les mesures de scurit numrs
dans l'ISO/CEI 27001: 2005, Articles A5, A6.1, A10, A6, A9.2, A10, A10.5, A13. Les listes
figurant dans ces tableaux ne sont pas exhaustives et un organisme peut considrer
ncessaires des objectifs de scurit et des mesures de scurit additionnels. Les objectifs de
scurit et les mesures de scurit mentionns dans ces tableaux doivent tre slectionns
comme partie intgrante du processus d'application du SMSI.
Les Articles A5, A6.1, A10, A6, A9.2, A10, A10.5, A13, de l'ISO/CEI 27001: 2005
fournissent des recommandations de mise en uvre et des lignes directrices affrentes aux
meilleures pratiques, venant l'appui des mesures spcifies aux paragraphes , A6.1, A10,
A6, A9.2, A10, A10.5, A13.
Tableau A.1 de quelques Objectifs de scurit et mesures de scurit :
A.5 Politique de scurit

A.5.1 Politique de scurit de l'information
Objectif: Apporter la scurit de linformation une orientation et un soutien de la part de la
direction,
conformment aux exigences mtier et aux lois et rglements en vigueur
A.5.1.1
Document de politique de
Mesure
scurit de linformation
Un document de politique de scurit de
linformation doit tre
approuv par la direction, puis publi et
diffus auprs de
lensemble des salaris et des tiers
concerns.
A.5.1.2
Rexamen de la politique de Mesure
Pour garantir la pertinence, ladquation et
lefficacit de la politique
de scurit de linformation, la politique doit
tre rexamine
intervalles fixs pralablement ou en cas de
changements majeurs.
N2TR
Page 58
A.6 Organisation de la scurit de linformation

A.6.1 Organisation interne
Objectif: Grer la scurit de linformation au sein de lorganisme.
Implication de la direction
Mesure
vis--vis
de
la
scurit
de
La direction doit soutenir activement la
A.6.1.1
l'information
politique de scurit au sein
de lorganisme au moyen de directives
claires, dun engagement
dmontr, dattribution de fonctions
explicites et dune
reconnaissance des responsabilits lies la
scurit de
linformation.
Coordination de la scurit
Mesure
de
l'information
Les activits relatives la scurit de
A.6.1.2
linformation doivent tre
coordonnes par des intervenants ayant des
fonctions et des rles
appropris reprsentatifs des diffrentes
parties de lorganisme.
Mesure
Attribution des
Toutes les responsabilits en matire de
A.6.1.3
responsabilits en matire
de scurit de linformation doivent tre dfinies clairement.
Mesure
Systme
dautorisation
Un systme de gestion des autorisations doit
A.6.1.4
concernant les moyens de
tre dfini et mis-en uvre pour chaque
traitement de linformation
nouveau moyen de traitement de
linformation.
A.9.2 Scurit du matriel

Objectif: Empcher la perte, lendommagement, le vol ou la compromission des actifs et
linterruption des activits
de lorganisme.
A.9.2.1
N2TR
Choix de lemplacement et
protection du matriel
Mesure
Le matriel doit tre situ et protg de
manire rduire les
risques de menaces et de dangers
environnementaux et les
possibilits daccs non autoris.
Page 59
A.9.2.2
A.9.2.3
A.9.2.4
A.9.2.5
A.9.2.6
A.9.2.7
Services gnraux
Scurit du cblage
Mesure
Le matriel doit tre protg des coupures de
courant et autres
perturbations dues une dfaillance des
services gnraux.
Mesure
Les cbles lectriques ou de
tlcommunications transportant des
donnes doivent tre protgs contre toute
interception
dinformation ou dommage.
Maintenance du matriel
Mesure
Le matriel doit tre entretenu correctement
pour garantir sa
disponibilit permanente et son intgrit.
Scurit du matriel hors

des locaux
Mesure
La scurit doit tre applique au matriel
utilis hors des locaux de
lorganisme en tenant compte des diffrents
risques associs au
travail hors site.
Mise au rebut ou recyclage

scuris(e) du matriel
Sortie d'un actif
Mesure
Tout le matriel contenant des supports de
stockage doit tre vrifi
pour sassurer que toute donne sensible a
bien t supprime et
que tout logiciel sous licence a bien t
dsinstall ou cras de
faon scurise, avant sa mise au rebut.
Mesure
Un matriel, des informations ou des
logiciels ne doivent pas tre
sortis des locaux de lorganisme sans
autorisation pralable.
A.10 Gestion de lexploitation et des tlcommunications

A.10.1 Procdures et responsabilits lies l'exploitation
Objectif: Assurer lexploitation correcte et scurise des moyens de traitement de
N2TR
Page 60
linformation.
A.10.1.1
A.10.1.2
A.10.1.3
A.10.1.4
Procdures dexploitation
documentes
Management des
modifications
Sparation des tches
Sparation des quipements

de dveloppement, d'essai
et dexploitation
Mesure
Les procdures dexploitation doivent tre
documentes, tenues
jour et disponibles pour tous les utilisateurs
concerns.
Mesure
Les changements apports aux systmes et
moyens de traitement
de linformation doivent tre contrls.
Mesure
Les tches et les domaines de responsabilit
doivent tre spars
pour rduire les occasions de modification
ou de mauvais usage non
autoris(e) ou involontaire des actifs de
lorganisme.
Mesure
Les quipements de dveloppement, d'essai
et dexploitation
doivent tre spars pour rduire les risques
daccs ou de
changements non autoriss dans le systme
dinformation en
exploitation.
A.10.5 Sauvegarde
Objectif: Maintenir lintgrit et la disponibilit des informations et des moyens de
traitement de linformation.
A.10.5.1
N2TR
Sauvegarde des
informations
Mesure
Des copies de sauvegarde des informations
et logiciels doivent tre
ralises et soumises rgulirement essai
conformment la
politique de sauvegarde convenue.
Page 61
A.13 Gestion des incidents lis la scurit de linformation

A.13.1 Remonte des vnements et des failles lis la scurit de linformation
Objectif: Garantir que le mode de notification des vnements et failles lis la scurit de
linformation permet la
mise en uvre dune action corrective, dans les meilleurs dlais.
A.13.1.1
A.13.1.2
N2TR
Remonte des vnements

lis la scurit de
linformation
Remonte des failles de

scurit
Mesure
Les vnements lis la scurit de
linformation doivent tre
signals, dans les meilleurs dlais, par les
voies hirarchiques
appropries.
Mesure
Il doit tre demand tous les salaris,
contractants et utilisateurs
tiers des systmes et services dinformation
de noter et de signaler
toute faille de scurit observe ou
souponne dans les systmes
ou services.
Page 62
Bibliographie et rfrences
http://www.northconsulting.fr/ISO27001.html
http://www.resys-consultants.com/index.php?page=certification_BS
http://www.piloter.org/systeme-information/securite-ISO-27001.htm
http://javaweb.developpez.com/cours/
http://uml.developpez.com/
http://webstore.iec.ch/preview/info_isoiec27001%7Bed1.0%7Dfr.pdf
http://javaweb.developpez.com/faq/jsf/?page=composants_selectMany
N2TR
Page 63

Conception Et Réalisation D'une Application de Gestion de Sécurité D'information Pour La Poste Tunisienne

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Et Réalisation D'une Application de Gestion de Sécurité D'information Pour La Poste Tunisienne

Transféré par

Droits d'auteur :

Formats disponibles

Sujet:

Conception et Ralisation dune Application de Gestion de Scurit

Mmoire de fin dtudes

Universit virtuelle de Tunis

Je ddie ce travail mes trs chers parents ; ma mre qui ne cesse

Jadresse mes vifs remerciements mon encadreur, Mr Riadh

Key words: Information Security, ISMS, ISO/CEI 27001, PDCA.

Table des Matires

Prsentation de socit ................................................................................................. 10

Etude de lexistant ....................................................................................................... 10

Description de lexistant ............................................................................ 10

Scurit de systme dinformation ............................................................... 11

Critique de lexistant ................................................................................. 11

Chapitre 2 : Spcification et Analyse .................................................................. 13

Comment mettre en place un SMSI : ................................................................... 15

Architecture de lISO 27001 : ............................................................................. 16

Processus de lISO 27001 de lSMSI : ................................................................ 16

Dclaration d'applicabilit ................................................................................... 20

Mthodes dapprciation des risques ................................................................... 20

Analyse de risque : .............................................................................................. 23

Gestion du risque : .............................................................................................. 23

Processus damlioration continue : ....................................................................23

Chapitre III : Conception ............................................................................................. 25

Modles de cycles de vie ............................................................................................. 27

Modle en cascade ................................................................................... 27

Le modle en spirale ................................................................................. 29

Etude comparative entre MERISE et UML : .................................................. 29

La dmarche adopte : .............................................................................. 31

Conception dtaille : ................................................................................................ 32

Cration dun nouveau compte : .................................................................. 36

Contrler les services: ............................................................................... 39

Diagramme de classe de SMSI : ............................................................. 42

Chapitre IV : Ralisation ........................................................................................... 43

Environnement logiciel :............................................................................ 44

Description du modle Vue Contrleur MVC2 : ............................................. 44

Description de la diffrence entre le modle MVC1 et MVC2 : ......................... 46

Le modle MVC type 1 ............................................................................. 46

Le modle MVC de type 2 ......................................................................... 46

Description du Framework JPA : .............................................................. 48

Cration de la base de donnes : .................................................................. 49

Description de la gnration du bas de donnes : ................................................. 49

Architecture matrielle : ............................................................................ 50

Matriel utilis : ....................................................................................... 50

Les composantes applicatives ralises ...................................................................... 51

Interface de connexion : ............................................................................ 51

Interface de Rclamation: .......................................................................... 52

Interface dAdministrateur : ....................................................................... 55

CONCLUSION ET PERSPECTIVES ...................................................................................... 57

Liste des figures

Liste des diagrammes

Diagramme 1: Diagramme de cas dutilisation Authentification ......................................34

Lomniprsence des informations croissante soutenue par la rvolution numrique

Durant mon stage de PFE, il ma t demand de faire la conception, et le dveloppement

Dans le troisime chapitre Conception du systme, jai parl des mthodologies de

Chapitre I : Prsentation du cadre du stage

la collecte, le transport et la distribution de courrier ;

2. Scurit de systme dinformation

La scurit des systmes d'information se cantonne gnralement garantir les droits

services de l'organisation (autour de l'informatique) ;

Chapitre 2 : Spcification et Analyse

Systme de management de scurit de linformation :

Un SMSI est un ensemble dlments interactifs permettant un organisme dtablir

Le SMSI inclut donc au minimum :