Sécurité IBM i : vos exit programs vous protègent-ils vraiment ?

Un exit program branché sur l'ODBC, un tableau de bord au vert, et le sentiment que l'IBM i est protégé. C'est l'une des situations que Pierre-Marie Seris, architecte IBM i chez OCSI avec plus de 30 ans sur la plateforme, croise le plus souvent en mission. Et c'est souvent là que les ennuis commencent.
pc portable sur bureau

Un exit program, à quoi ça sert ?

L’IBM i propose des points de sortie (exit points) sur la plupart de ses interfaces réseau : accès base de données en ODBC ou JDBC, FTP, commandes à distance, partage de fichiers IFS, DDM. Quand une requête arrive par l’une de ces portes, le système appelle le programme enregistré sur le point correspondant. Ce programme décide alors d’accepter ou de refuser la requête, et peut la journaliser.

C’est un outil puissant pour contrôler qui entre, par où, et pour faire quoi. Mais c’est un contrôle d’entrée, pas une sécurité complète.

Le piège du périmètre

Toute la logique du guide tient en une phrase : un périmètre dur autour d’un intérieur mou reste mou.

Concrètement, un exit program filtre les portes qu’il surveille. Il ne corrige pas les droits trop larges sur les objets, les profils qui ont bien plus d’autorité que nécessaire, ni les bibliothèques ouvertes à tous. Si quelqu’un passe par une porte non surveillée, ou entre légitimement avec un compte trop puissant, l’exit program ne voit rien.

Trois angles morts qu’on retrouve souvent

Le guide en recense plus de 20. En voici trois, parmi les plus fréquents en mission.

1. Les portes oubliées

L’ODBC est couvert, parce que c’est l’accès le plus visible. Mais le FTP, les commandes à distance ou le serveur de fichiers IFS ne le sont pas toujours. Or il suffit d’un seul point de sortie non couvert pour contourner tout le reste. Certaines interfaces, comme SSH, échappent même complètement à ce mécanisme.

2. Le mode « on regarde d’abord » qui dure

Beaucoup d’exit programs sont installés en simple journalisation, le temps d’observer les flux sans risquer de bloquer la production. C’est une bonne pratique au démarrage. Le problème, c’est quand ce mode reste en place pendant des années : le tableau de bord est rempli, mais rien n’est jamais refusé.

3. Les règles que personne ne relit

Un compte de service ajouté en liste blanche pour un projet de 2019, une exception temporaire jamais retirée, un prestataire parti depuis longtemps. Sans propriétaire clair ni revue régulière, les règles d’un exit program se dégradent en silence.

Téléchargez le guide complet ! 

Ces trois angles morts ne sont qu'un aperçu ! Le guide de Pierre-Marie va beaucoup plus loin, avec un contenu pensé pour être appliqué sur votre propre système :

- Un catalogue de plus de 20 faiblesses, réparties en 5 familles, chacune expliquée avec son mécanisme, un scénario concret et la parade.
- Une checklist en 11 points pour vérifier si votre exit program tient vraiment la route.
- Une hiérarchie des dangers en 5 niveaux, pour savoir quels points de sortie traiter en priorité.

Une feuille de route en 6 étapes, de l'état des lieux à la gouvernance dans la durée, sans casser la production.

Télécharger le guide complet

👉 Vous préférez en parler directement ? Les consultants IBM i d'OCSI accompagnent les équipes sur l'audit et le durcissement de leur dispositif : découvrir notre expertise IBM i.

Partagez ce post
Nivram

Nivram

Breton têtu, sushi-addict et allergique au discours bullshit. "L’IT c’est du sérieux… mais on est pas obligé d'en faire quelque chose de chiant."