Les Exit Programs sans prise de tête

 

SÉCURITÉ IBM i

Les Exit Programs sans prise de tête

Euh… De quoi ça ? … Qui c’est que t’y ça fait pas ? … Par où que je commence ?

1. C'est quoi, un Exit Program ?

Imaginez une boîte de nuit. Il y a un videur à la porte : il vérifie qui entre, éventuellement refuse quelqu'un. 

C'est utile, mais ça ne remplace pas : 

• les murs costauds pas en placo, 

• les serrures des vestiaires des Chippendales et des Gogo-Danseuses, 

• le coffre-fort et la Winchester à canon scié sous le zinc du bar. 

Un Exit Program, c'est exactement ce videur, posé sur une porte réseau de l'IBM i (ODBC, FTP, commande à distance...).

Techniquement : à certains endroits précis du système (les « points de sortie », ou exit points), l'OS accepte d'appeler un programme que vous avez écrit (ou acheté). Ce programme regarde qui demande quoi, et renvoie une réponse simple : « oui, je laisse passer » ou « non, je bloque ».

Le message le plus important de tout ce document : 

Un Exit Program est un videur à l'entrée, pas les fondations de l'immeuble. 

Il vient EN PLUS de la sécurité de base (qui a le droit de lire quel fichier), jamais À LA PLACE.

« Un périmètre dur autour d'un intérieur mou reste mou. »

2. Comment ça marche, en trois étapes

• Un utilisateur (ou un programme, ou un PC) essaie d'utiliser une porte réseau : ODBC, FTP, commande distante, partage de fichiers...

• L'OS appelle automatiquement le programme d'exit enregistré sur cette porte, en lui donnant les infos de la demande (qui, quoi, depuis où).

• Le programme répond « autorisé » ou « refusé ». L'OS applique la réponse.

Le point sensible : si le programme plante, boucle, ou ne répond pas clairement, l'OS a un comportement par défaut. Et par défaut, la plupart du temps... il laisse passer. C'est LE piège numéro un, détaillé au chapitre suivant.

3. Les pièges les plus fréquents

3.1 Le programme qui bug "ouvre la porte" au lieu de la fermer

Un Exit Program mal écrit, qui plante sur une erreur inattendue, laisse en général tout le monde passer. 

C'est contre-intuitif : on croit qu'une panne bloque, alors qu'une panne autorise. 

La bonne pratique : écrire le programme pour qu'il refuse par défaut, et n'autorise qu'après avoir tout vérifié avec succès.

3.2 « Tout est permis sauf... » plutôt que « Rien n'est permis sauf... »

Lister ce qu'on interdit, c'est perdu d'avance : on oublie toujours un cas. 

Lister ce qu'on autorise (et refuser le reste), c'est plus long à mettre en place mais ça vieillit bien : un cas non prévu est refusé, pas laissé passer.

3.3 On ne voit que la demande, pas ce qui sort réellement

L'Exit Program voit souvent la requête (« un SELECT sur telle vue ») mais pas le contenu réel renvoyé. 

Si la vue autorisée cache une jointure vers une table de salaires, il ne le saura jamais. 

Pour filtrer au niveau des colonnes ou des lignes, il faut d'autres outils (RCAC, vues restreintes), pas l'Exit Program.

3.4 Ça ralentit tout, et on finit par le débrancher

Le programme s'exécute à CHAQUE requête. 

Mal optimisé, il devient le goulot d'étranglement, et l'exploitation finit par le désactiver « en urgence » supprimant du même coup toute la protection. 

Un contrôle de sécurité qu'on est tenté d'éteindre n'est pas un contrôle de sécurité.

3.5 Un protocole oublié = une porte grande ouverte

Sécuriser l'ODBC ne protège pas contre le même accès via FTP, DDM, remote command ou un partage de fichiers.

Chaque protocole a sa propre porte, son propre videur à poser. 

Oublier une porte annule tout le travail fait sur les autres, car c'est souvent la même donnée qui est accessible par plusieurs chemins.

Réflexe à adopter : ne pas raisonner « ai-je sécurisé l'ODBC ? » mais « par combien de chemins peut-on atteindre ce fichier sensible, et lesquels sont couverts ? »

4. Ce que les Exit Programs ne verront JAMAIS

C'est la partie la plus importante à retenir pour un non-spécialiste : il existe des chemins d'accès qui ne passent tout simplement pas par un point de sortie réseau. 

Aucun Exit Program, même parfait, ne peut les voir.

• Une session 5250 classique avec ligne de commande (DSPPFM, RUNQRY...) : invisible pour les Exit Programs.

• Un traitement batch, un SBMJOB, un appel de programme direct : invisible aussi.

• Un utilisateur *ALLOBJ (tous les droits) : il passera par n'importe quelle porte non filtrée, exit program ou pas.

• L'« adopted authority » (un programme qui emprunte les droits d'un autre profil en cours d'exécution)  peut contourner ce qui a été vérifié à l'entrée.

• Une adresse IP « de confiance » : ça se falsifie, se partage, ou passe par un VPN.
  Ce n'est pas une identité.

Conséquence pratique : si vos fichiers sensibles sont en *PUBLIC *CHANGE et que vous avez des dizaines de profils *ALLOBJ, le meilleur Exit Program du monde ne protège quasiment rien. 

Le vrai travail de fond, c'est l'autorité sur les objets (qui a le droit de faire quoi sur quel fichier).

5. La checklist simple d'un bon Exit Program

• Refuse par défaut, n'autorise qu'après vérification complète.

• Couvre TOUS les protocoles et TOUS les formats qui mènent à la même donnée.

• Liste blanche (on ouvre nommément) plutôt que liste noire.

• Vient en complément d'une autorité objet propre, jamais à sa place.

• Reste rapide, pour ne jamais être tenté de le débrancher.

• Ne garde pas d'état en mémoire d'une requête à l'autre (pas de cache mal maîtrisé).

• Est surveillé : on sait s'il est actif, absent, ou désactivé par erreur.

• Trace ses décisions, en complément du journal d'audit système (QAUDJRN).

• A été testé aussi sur ses chemins d'erreur, pas seulement le cas nominal.

• Ses règles sont entretenues dans le temps (pas d'exception « temporaire » oubliée depuis trois ans).

6. Feuille de route : par où commencer, simplement

Deux réflexes à garder en tête tout du long : 

1. réduire la surface avant de filtrer (le meilleur Exit Program est celui qu'on n'a pas eu besoin d'écrire), 

2. observer avant de bloquer (on ne coupe rien tant qu'on n'a pas mesuré le trafic réel).

Étape	Ce qu'on fait	Ce que ça rapporte
0	Faire l'état des lieux :  quels points de sortie existent, lesquels ont un programme actif,  combien de profils *ALLOBJ,  combien de fichiers sensibles en *PUBLIC *CHANGE.	Une photo factuelle, sans jugement, pour cadrer la suite.
1	Éteindre les services réseau inutilisés (REXEC, DDM, FTP si plus utile...).	Danger supprimé sans écrire une ligne de code. Rapide et sans risque.
2	Remettre de l'ordre dans les droits objets :  réduire les *ALLOBJ,  remonter les *PUBLIC sensibles vers *EXCLUDE avec autorisation nommée.	Le vrai fond du sujet. Plus long, mais c'est ce qui protège réellement.
3	Déployer les Exit Programs en mode « journalisation seule » (on observe, on ne bloque pas encore).	On voit qui se connecte, d'où, pour quoi faire — sans casser la production.
4	Basculer au blocage progressivement, une porte à la fois, en commençant par les plus dangereuses (exécution de commandes à distance).	Un filtrage réel, avec un plan de retour arrière à chaque étape.
5	Surveiller dans la durée :  vérifier que les programmes sont toujours actifs,  revoir les règles,  refaire le point à chaque montée de version.	La sécurité tenue dans le temps, pas un one-shot qu'on oublie.

7. À retenir en une phrase

Un Exit Program ne vaut que s'il refuse par défaut, couvre tous les chemins vers la donnée, et vient compléter, jamais remplacer, une autorité objet propre.

Et pour ceux qui commencent : achetez plutôt que de développer maison si le budget le permet. 

Faire un bon Exit Program maison (tous les formats, fail-closed, supervision, tests des cas d'erreur, maintenance à chaque version) est un vrai projet dans la durée. 

Les solutions du marché (Fortra/PowerTech, Raz-Lee, Kisco...) ont déjà fait ce travail encore faut-il les configurer correctement et vérifier qu'elles ne tournent pas en simple mode journalisation.