Que faire ?

l’accès. La plupart des modes d’accès
aux données d’un AS/400 peuvent être adaptés aux besoins de chacun. Pour des services
comme ODBC, contrôlés par des serveurs hôtes AS/400, IBM propose un mécanisme
appelé programmes d’exit, permettant d’insérer sa propre logique personnalisée
dans le processus de communication.

On peut, avec les programmes d’exit, accorder ou refuser des droits utilisateurs
en fonction de plusieurs facteurs: qui tente d’effectuer une opération et sur
quel objet, entre autres. Le programme d’exit personnalisé peut examiner cette
information et positionner des paramètres oui/non pour déterminer quels utilisateurs
peuvent effectuer telle ou telle opération.

L’utilisation d’un programme d’exit a pour inconvénient de ne contrôler qu’une
méthode d’accès aux données particulière. Dans certains cas, on peut réutiliser
des programmes d’exit pour différents points de sortie et serveurs, mais de nombreux
points de sortie ne s’appliquent qu’à  des services uniques. Ce qui oblige à  créer
des programmes d’exit pour chaque service que l’on veut sécuriser sur l’AS/400.
C’est là  une technique discutable, d’une part parce qu’elle demande beaucoup de
coding manuel, et, d’autre part parce qu’il faut repenser les sécurités à  chaque
fois qu’IBM ajoute une nouvelle fonctionnalité serveur à  l’AS/400 (ce qui n’est
pas rare en ce moment).

Pour compliquer davantage les choses, les pilotes ODBC tiers n’utilisent souvent
pas les serveurs hôtes de base de données IBM et, par conséquent, n’appellent
pas leurs programmes d’exit associés. Ceci a pour conséquence de rendre inopérant
le mécanisme de sécurité personnalisé. Quand, pour couronner le tout, on sait
que les utilisateurs peuvent downloader de nombreux pilotes ODBC tiers capables
de mise à  jour, à  partir d’Internet, pour un test gratuit de 30 jours, il est
clair que si les programmes d’exit sont utiles pour personnaliser l’interaction
avec le serveur, ils ne sont certainement pas le meilleur moyen pour sécuriser
les données.