par Wayne O. Evans - Mis en ligne le 12/06/03
Dans la première partie de cet article
(« Accès exclusif aux applications :
une stratégie de protection des ressources,
1ère partie », iSeries News, octobre
2002, N°9), j'ai expliqué la nécessité
de l'AOA (application only-access)
sur l'iSeries. La solution est simple : ne donner aux utilisateurs aucun droit d'accès aux données de production en dehors des
applications approuvées. Pour permettre
aux applications approuvées
d'accéder aux données de production,
il faut soit faire adopter à chaque application
l'autorité de son propriétaire,
soit remplacer le profil de groupe de
l'utilisateur par un profil d'utilisateurs
de groupe ayant des droits d'accès aux
données de production.
Je décris ici les problèmes rencontrés
quand j'ai essayé pour la première
fois d'utiliser une stratégie AOA, et les
solutions qui m'ont permis d'en faire
une technique utile.
Stratégie de protection des ressources, 2e partie
En utilisant les fonctions de sécurité niveau
30 et plus de l’iSeries, une stratégie
AOA restreint l’accès aux données
de production en dehors d’une application.
Les utilisateurs de l’application
ne devraient pas avoir un profil de
groupe qui donne à un utilisateur
quelconque des droits d’accès aux
données de production.
La figure 1 montre une mise en
oeuvre d’AOA. Le profil utilisateur
OWNPRD01 n’a pas de mot de passe
(pour empêcher son utilisation pour le
sign-on) et est le propriétaire de tous
les programmes, fichiers, et bibliothèques
de production. Les applications
shell que j’appelle programmes
d’entrée adoptent l’autorité du propriétaire
de l’application et procurent
de ce fait aux utilisateurs un point
d’entrée aux applications de production.
Dans cet exemple, les programmes
d’entrée adopteront l’accès
de OWNPRD01 pour permettre aux
utilisateurs d’accéder aux objets de
production.
Quand un utilisateur dans le profil
de groupe GRPAPP01 sélectionne l’option
de menu 1 (RUN APP01), un programme
d’entrée provenant de la bibliothèque
PGMLIB est appelé. Ce
programme adopte la propriété de
OWNPRD01, qui donne aux utilisateurs
l’accès aux données de production.
Le programme d’entrée appelle
ensuite la fonction d’application réelle.
Dans le cas de logiciel acheté, vous
ne pourrez peut-être pas contrôler le
programme qui est exécuté par l’utilisateur.
Par exemple, vous n’aurez peutêtre
pas le code source pour les menus
de l’application. Dans ce cas, il faudra
modifier tous les programmes de l’application
pour adopter la possession
du propriétaire de production (OWNPRD01).
Un responsable de la sécurité
peut modifier les programmes adoptables
sans être obligé de recompiler
les programmes.
Ce modèle empêche la modification
et la divulgation des données de
production en dehors des applications
de production, mais il permet aux utilisateurs
d’accéder aux données à partir
des applications de production, où
leur comportement est contrôlé. Les
utilisateurs n’ont pas d’accès (comme
le transfert de fichiers PC, les commandes
à distance, ou FTP) en dehors
de l’application.
Téléchargez cette ressource
Livre blanc Sécurité et Stockage des documents
Découvrez dans ce livre blanc Kyocera les outils logiciels qui permettent une approche holistique et efficace de la collecte, du stockage, de la gestion et de la sécurisation des documents en entreprise.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Top 6 de la sécurité des secrets
- Déploiement Data Zone de votre IA !
- Le nouvel espace-temps de la transformation digitale : redéfinition des rôles dans les projets IT
- Facturation électronique : les craintes des entreprises liées à la réforme
- Cyber-assurances, priorité ou faux remède pour les TPE et PME ?