La sécurité du controle d’accès

Avant d’aborder la mise en oeuvre des
mesures de sécurité, considérez que
d’entrée de jeu, vous devrez peut-être
publier des informations destinées à 
des départements/sections différents,
posant des exigences de sécurité de
degrés variables. Peut-être vous demandera-
t-on aussi de fournir une
zone non sécurisée sur votre site
(peut-être la page d’accueil ellemême),
qui pourra servir de page polyvalente.
Pour parvenir à  ces différents
niveaux de sécurité, veillez à  diviser
l’information sur le critère de la sécurité.
Autrement dit, ayez des répertoires
séparés pour l’information qui
requiert un domaine de sécurité spécifique
(par exemple, des répertoires séparés
pour Comptabilité, Système véhicules,
Ressources humaines). La
page d’accueil peut être dépourvue de
sécurité et peut par conséquent se
trouver au niveau racine de votre hiérarchie
de diffusion. Cela signifie que
vous devez créer des instances séparées
pour chacune de vos applications
dans le serveur HTTP. Vous faites cela
dans la procédure de configuration
Apache. Chacun de ces serveurs aura
son propre domaine de protection, à 
l’intérieur duquel vous pourrez définir
le groupe d’utilisateurs pouvant accéder
au contenu.
La hiérarchie de diffusion par défaut
pour des pages HTML est la suivante

\www\your_Project_dir\htdocsHome Directory Name\

Pour des servlets, la hiérarchie de
diffusion par défaut est la suivante

\www\your_Project_dir\htdocsHome Directory Name\servlets\

Ainsi, vous devez implémenter
votre domaine de protection au niveau
Home Directory Name.
La figure 1 montre une page d’accueil
intranet classique avec une zone
non sécurisée (Company News) et plusieurs
zones sécurisées (Accounts,
Service, Automobiles). Les exigences
de ce site sont les suivantes :

• réer une instance (serveur) pour la page d’accueil principale (non sécurisée).
• er des instances individuelles
  (serveurs) pour chacun des sites à 
  sécuriser.

• ssurer que toutes les instances
  créées ci-dessus sont démarrées sur
  le système.

• instances s’exécuteront simultanément,
  donc configurez-les de manière
  à  écouter les ports uniques (80,
  3001, 3002, 3003, dans cet exemple).

A noter que l’authentification
HTTP de base ne crypte pas les mots
de passe utilisateur quand ils voyagent
sur l’intranet du navigateur vers le serveur.
Assurez-vous que le réseau d’entreprise
est sûr avant d’employer l’authentification
HTTP de base. En outre,
comme les ID et mots de passe utilisateur
ne sont pas cryptés quand les utilisateurs
se connectent à  l’iSeries via
TCP, des intrus peuvent provoquer des
dégâts en lâchant un sniffer sur votre
réseau. Un renifleur permet à  l’intrus
d’accéder à  une information sensible,
comme les ID et mots de passe utilisateur.
Toutefois, l’OS/400 V4R4 et les releases
ultérieures permettent le cryptage
de l’ID et du mot de passe
utilisateur, empêchant ainsi les intrus
de parvenir à  leurs fins.
Commençons maintenant la mise
en oeuvre de la sécurité (ou plutôt de la
protection). Dans la configuration
iSeries Apache, on peut contrôler l’accès
à  un répertoire Web donné de deux
manières simples : en utilisant des
listes de validation ou en employant la
sécurité par profil utilisateur iSeries
existante. Une troisième possibilité
(qui fait appel à  l’authentification LDAP,
ou Lightweight Directory Access
Protocol) consiste à  concevoir une
configuration LDAP bien pensée pour
l’entreprise, ce qui peut être compliqué.
C’est pourquoi nous nous limitons
ici aux deux solutions simples.