Introduction
Evolution des architectures vers plus de complexité
On trouvera ci’-après un résumé succint des principales étapes de l’évolution des architectures matérielles et
logicielles qui se sont profondément modifiées lors des deux dernières décennies.
| Type client | Type serveur | Type connexion / architecture | logiciels clients | logiciels serveur |
| terminal | Mainframe | directe | - | OS + Applicatif + fichiers de données |
| PC terminal | Départemental | réseau | émulateur | OS + Applicatif + SGBD |
| PC lourd | Départemental | client / serveur |
applicatif nav + applet |
OS + Applicatif + SGBD |
| PC léger | Départemental / Central | n-tier+ X Net |
navigateur | Srv d’application :OS + web Srv de données : OS + SGBD |
la plupart de ces architectures peuvent sembler désuettes, voire anachroniques, mais il suffit de se pencher sur l’écran d’un ordinateur dans une grande surface ou un aéroport pour constater que l’émulation de terminal (même enjolivée) est toujours très utilisée .
Quoi qu’aie pu en penser SUN il y a quelques années :” the Network is NOT YET the computer”
On constate cependant à l’évidence une tendance à la complexité :
- multiplication des matériels (plusieurs clients fixes ou mobiles,
plusieurs serveurs, réseau hétérogènes) - multiplication des couches logicielles (OS client, application client, client
reseau, OS serveur, serveur reseau, serveur applicatif, SGBD) - multiplication (voire ubiquité) des réseaux ( intranet, internet
et surtout en ce qui concerne la sécurité des données
EXTRAnet) - généralisation du partage de données : entre particuliers,
mais aussi employés, entreprises, clients, fournisseurs, partenaires
qui fait de la sécurité des données un enjeu majeur
La sécurité : un nouvel enjeu
Plusieurs raisons font que la sécurité devient un enjeu important :
- complexité croissante des SI
- exigence croissante de qualité (certification ISO 9001, et plus spécifiquement ISO 27001)
- exposition accrue des données et applications avec INTERNET + INTRANET ++ EXTRANET
- augmentation (et meilleure diffusion / communication) des attaques
Pour info, ci après les statistiques du CERT sur les enregistrements d’incidents des dernières années :

Note : l’absence de statistiques depuis 2003 indique simplement que le CERT a arrété de compter !!!!!!!!!!!!!!!!! Notamment à cause du fait que de + en + d’automates font des attaques massives, ce qui rend leur nombre de moins en moins significatif.
Statistiques sur les incidents réel…et supposés
On trouve dans le tableau ci après issu d’une étude du CLUSIF (Club de la Sécurité de l4Information Francais) de 2008, la perception des incidents de sécurité des SI :
perception des incidents
et dans le tableau suivant (même source), les statistiques réelles sur les incidents en entreprise

Un petit exemple de dérive
Voici un extrait du site ‘comment ca marche’ sur l’introduction à la sécurité des systèmes d’information :
<< …Afin de pouvoir sécuriser un système, il est nécessaire d’identifier les menaces potentielles, et DONC de connaître et de prévoir la façon de procéder de l’ennemi. Le but de ce dossier est ainsi de donner un aperçu des motivations éventuelles des pirates, de catégoriser ces derniers, et enfin de donner une idée de leur façon de procéder afin de mieux comprendre comment il est possible de limiter les risques d’intrusions…>>
en 3 lignes on retrouve les termes : menaces, ennemi, motivation, pirate, intrusion… qui présupposent que la sécurité des SI est forcément (’donc’) mise en péril par des Hackers malveillants, ce qui est loin d’être la réalité comme en témoignent les stats précédentes…
Comme quoi tout ce qui est sur le net (sauf mon site bien sûr) n’est pas parole d’évangile.
A savoir (et à se rappeler…)
-
La complexité des SI impose une approche globale,
’systémique’ du problème (attention de ne pas envisager QUE la sécurité des BDs) - K.I.S.S principle (Keep It Simple Stupid !) : VISEZ LA SIMPLICITE
- pour réduire la complexité du SI ( Normes et standards des différentes couches matérielles et logicielles + moyens d’imposer et vérifier ces standards)
- pour produire des règles, des procédures et des contraintes pragmatiques, de bon sens et ‘respectables’
- adapter les procédures et règles en fonction des populations (un poste admin local n’est pas un PC d’internaute)
-
Un SI a le niveau de sécurité du plus faible de ses composant (principe du “maillon faible” !)
-
Elle nécessite l’implication ET SURTOUT L’ADHESION de TOUS (si certains employés n’adhèrent pas, ils généreront du “maillon faible”)
-
La sécurité est fonction d’objectifs et d’un enjeu (la mise en place d’un plan de sécurité est un projet)
- Il n’existe pas de système totalement sûr ( on visera à satisfaire au mieux les objectifs et répondre aux besoins)



