La solution ingénieuse: les droits adoptés

pour mettre à  jour
des fichiers base de données à  un profil utilisateur, l’utilisateur en question
ne pourra pas mettre à  jour la base de données depuis une ligne de commande de
l’AS/400 ou depuis une application PC comme MS Query.

Mais, me direz-vous, si l’on empêche les utilisateurs de mettre à  jour les fichiers
base de données, comment pourront-ils travailler en utilisant les applications
répertoriées? La réponse est fournie par un concept AS/400 appelé droits adoptés.

Quand on protège le système par des droits adoptés, on empêche les utilisateurs
de mettre à  jour les fichiers base de données avec des outils comme DFU (Data
File Utility) ou ODBC, tout en leur permettant de le faire avec des programmes
applicatifs agréés.
Pour cela, ils adoptent les droits du propriétaire d’un programme pendant qu’ils
l’exécutent. Dès que l’utilisateur quitte le programme (en changeant de session
ou en appuyant sur la touche AppSys par exemple), ils perdent leurs droits adoptés
(le propriétaire du programme doit bien entendu être autorisé à  mettre à  jour
la base de données.)

Il en découle que vos utilisateurs ne peuvent mettre à  jour des données que lorsqu’ils
exécutent des programmes contenant votre logique de gestion, ce qui empêche, en
théorie, les mises à  jour non valides. Cette méthode est bien supérieure aux programmes
de sortie ou aux autres moyens de contrôle d’accès aux données, parce qu’elle
sécurise les fichiers base de données à  la source, plutôt que d’essayer de sécuriser
chaque méthode d’accès.

Une mise en garde: Si les utilisateurs peuvent accéder à  une ligne de commande
pendant l’exécution d’un programme adoptant des droits, ils conservent leur niveau
de droits adoptés, ce qui constitue une menace potentielle. Si certains de vos
programmes donnent aux utilisateurs l’accès aux lignes de commande, assurez-vous
que ces programmes n’utilisent pas de droits adoptés ou n’adoptent pas des droits
eux-mêmes.