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

Cybersécurité des collectivités : Enjeux, Perspectives & Solutions
Villes, intercommunalités, métropoles, départements et régions sont particulièrement exposés aux risques de cybersécurité. Ce livre blanc Stormshield présente les défis cyber que rencontrent les collectivités, les solutions et perspectives pour qu’elles puissent assurer leur mission d’utilité publique, en toute sécurité.
Les articles les plus consultés
- Cybersécurité Active Directory et les attaques de nouvelle génération
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
- Afficher les icônes cachées dans la barre de notification
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
- Activer la mise en veille prolongée dans Windows 10