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

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

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Sanjay Lavakare - Mis en ligne le 24/11/2004 - Publié en Novembre 2003

Instaurez des mesures de sécurité intranet en utilisant des listes de validation ou des profils utilisateur existants

Votre intranet est peut-être merveilleux. Il est donc naturel que vous (ou les développeurs) aimiez montrer ce nouveau bébé à  votre entourage. Mais, au fur et à  mesure que le « bébé » grandit en taille et en importance, la direction va s'inquiéter de sa sécurité ... Vous avez commencé par un site sympa servant à  publier des annonces (BBS, bulletin board services) anodins : Roger affiche une annonce pour sa Volvo d'occasion, Marie pose une question à  propos d'un problème Excel. Ou le responsable logiciel publie des détails sur la configuration des systèmes mis à  niveau, au profit de tous les utilisateurs.
Mais voilà  que tout à  coup on vous demande d'offrir des liens avec le système Interrogation véhicules sur votre iSeries pour un certain groupe d'utilisateurs du SID (système d'information pour la direction) et de créer un autre lien avec des données de Comptabilité pour votre service financier. Et là , attention à  qui peut accéder aux données !
Les soucis de sécurité sont désormais une boule de neige qui dévale la pente ! Pour éviter de tels problèmes, nous allons voir quelles sont les mesures de sécurité à  appliquer dès la construction de la fondation de l'intranet.

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.

Téléchargez cette ressource

Checklist de protection contre les ransomwares

Checklist de protection contre les ransomwares

Comment évaluer votre niveau de protection contre les ransomwares à la périphérie du réseau, et améliorer vos défenses notamment pour la détection des ransomwares sur les terminaux, la configuration des appareils, les stratégies de sauvegarde, les opérations de délestage... Découvrez la check list complète des facteurs clés pour améliorer immédiatement la sécurité des terminaux.

Tech - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT