Risques liés à  la gestion de l’accès au réseau

l’utilisateur n’avait pas l’option paie sur son menu, il ne pouvait pas accéder à la paie. Quelle simplicité ! Même la sécurité au niveau objet que nous avions mise en place ne pesait pas lourd, aussi l’avions-nous laissée ouverte à tous les vents, pour nous concentrer sur un travail plus important et plus urgent. Malheureusement, il en est encore ainsi dans la plupart des sites.

C’est ainsi que Lucie, qui travaille sur le quai de chargement, possède les autorités objet lui permettant de modifier… le plan comptable. « Mais, » direz-vous, « elle n’a pas cette option de menu sur son écran ! » Et vous aurez raison. Mais aujourd’hui, nous vivons dans un monde en réseau et les règles ont changé. Voyons donc ce que Lucie peut faire aujourd’hui.

FTP. Sur tous les iSeries que j’ai audités, il y avait un serveur FTP. Comme son nom l’indique, FTP sert à transférer des fichiers. Il sert aussi à exécuter des commandes sur l’iSeries. Un client FTP est livré avec chaque copie de Microsoft Windows. Cette réalité, conjointement à des autorités au niveau objet mal configurées, signifie que n’importe quel utilisateur autorisé peut transférer un fichier à partir du système. En fait, la plupart des autorités au niveau objet permettraient aussi à Lucie de transférer un simple fichier texte PC par dessus notre fichier maître client, corrompant ainsi son contenu.

FTP est également puissant pour l’exécution de commandes. Si Lucie a l’autorité spéciale *JOBCTL, elle peut lancer une simple commande FTP pour mettre fin à notre système interactif ou même à notre sous-système de contrôle. Cela aurait pour effet d’arrêter purement et simplement le système. Si Lucie a l’autorité spéciale *ALLOBJ, elle peut causer des dégâts illimités par la simple exécution de la commande FTP.

Le serveur FTP OS/400 présente une autre particularité importante : il ne produit pas de journaux. Et donc, il n’y a absolument aucune trace ou journal d’audit des actions effectuées via FTP. En fait, si Lucie mettait fin au sous-système QINTER, un message serait écrit dans la file d’attente de messages QSYSOPR, mais dans beaucoup d’autres cas – comme la destruction d’un fichier de données par le transfert d’enregistrements fictifs – il n’existe aucun enregistrement à moins de journaliser le fichier base de données. A noter que si Lucie a LMTCPB(*YES) spécifié sur son profil utilisateur, elle ne peut pas exécuter les commandes via FTP, mais elle peut encore transférer des fichiers.

Pour contrôler et auditer toutes les requêtes FTP, vous devez mettre en oeuvre un programme de sortie de serveur FTP OS/400. Un programme de sortie permet de maîtriser totalement qui peut utiliser FTP pour faire quoi. Un programme de sortie FTP peut être simple ou complexe, selon le degré de contrôle que l’on veut avoir sur l’accès à distance.
Bien que vous puissiez écrire vos propres programmes de sortie pour couvrir la totalité des 30 ou plus serveurs de réseau, le serveur FTP n’étant que l’un d’entre eux, la plupart des sociétés préfèrent acheter des programmes de sortie de serveur de réseau auprès d’un fournisseur de sécurité iSeries.

iSeries Access. En matière d’iSeries Access, IBM a validé tellement de fonctions d’accès aux données qu’il est difficile de les suivre. Et il semble qu’IBM en ajoute toujours plus à chaque nouvelle release. Certes, cette prolifération des fonctions améliore la possibilité d’accès aux données et aux services iSeries mais, en contre-partie, elle rend de plus en plus difficile la régulation de l’accès à distance des utilisateurs finaux.
Par exemple, vos utilisateurs finaux peuvent-ils accéder aux ressources critiques via DDM (Distributed Data Management), JDBC, ODBC, des commandes à distance, SQL et autres ? Ce n’est pas parce que Bernard est autorisé à mettre à jour l’information du compte bancaire pour les clients, qu’il a aussi la capacité d’utiliser le transfert de fichiers iSeries Access ou ODBC pour transférer le fichier des comptes bancaires sur son PC et … l’envoyer par courriel à un ami ou complice.

iSeries Navigator fait merveille grâce à ses nombreux outils base de données. Mais, dans de mauvaises mains, ce fabuleux outil peut devenir très dangereux. Si Marc peut créer une table SQL, peut-il aussi en supprimer une ? Bien sûr, il peut faire un SQL SELECT pour visualiser les données dans un format plus facilement utilisable, mais il peut probablement faire tout aussi bien un UPDATE et DELETE. Je pourrais vous raconter quelques sombres histoires sur des utilisateurs bien intentionnés qui, par une simple instruction UPDATE, ont détruit des bases de données de production.
Ils avaient tout simplement trop d’autorité sur les données et il n’y avait pas de programmes de sortie pour les protéger. Je suis sûr que vous connaissez aussi quelques histoires horribles en la matière. Pour corrompre vos ressources critiques, il ne faut pas forcément un pirate ou un utilisateur en colère : il suffit d’un utilisateur bien intentionné muni d’une trop grande autorité.

Toujours sur ce sujet : toute l’activité effectuée par des accès à la base de données et aux services iSeries Access est non journalisée et par conséquent ne peut pas être auditée sans la présence de programmes de sortie pour chaque serveur intéressant.
Utilisez les programmes de sortie pour contrôler granulairement l’accès à distance OS/400, et aussi pour journaliser toutes les requêtes d’accès.

Remote Command. Une fonction particulièrement utile, bien qu’onéreuse, chargée sur un PC lors de l’installation de iSeries Access, est la fonction RMTCMD (Remote Command). On peut exécuter RMT CMD à partir d’une invite Windows pour envoyer une commande CL à l’iSeries. L’aspect déplaisant de RMTCMD est qu’elle ne respecte pas le paramètre LMTCPB (*YES) du profil utilisateur. Par conséquent, même si les utilisateurs sont cantonnés à la ligne de commande, ils peuvent quand même utiliser RMTCMD pour exécuter des commandes CL. Ainsi, Lucie (avec l’autorité spéciale *JOBCTL) peut très certainement mettre fin à vos sous-systèmes et mettre votre système à genoux.

Je vais donc reparler des programmes de sortie. S’ils sont en place pour RMTCMD, vous pouvez contrôler et journaliser complètement toute l’activité. Sans programmes de sortie, il n’existe aucune trace de ce qui se passe sur votre système par l’intermédiaire de ses serveurs de réseau. Donc, quand le patron demande « Comment empêcherons-nous cela de se reproduire ? », vous restez sans voix ! iSeries Access : Application Administration vs programmes de sortie. iSeries Navigator a une fonction appelée Application Administration. Vous pouvez l’utiliser pour établir des règles définissant ce que les utilisateurs peuvent faire avec iSeries Access et FTP. Par exemple, vous pouvez établir une règle empêchant Lucie d’utiliser FTP. Mieux encore, vous pouvez laisser Lucie utiliser FTP pour transférer un fichier en aval, mais l’empêcher de le transférer en amont, ou d’exécuter une commande CL.

Application Administration est intéressant en l’absence de programmes de sortie, mais cet outil souffre de deux grosses faiblesses. En premier lieu, il ne journalise aucune activité réseau, et donc vous ne pouvez pas auditer les transactions à distance. En second lieu, le contrôle qu’il offre n’est pas suffisamment granulaire pour permettre des cas simples d’accès aux données. Par exemple, je veux que Paul puisse transférer le fichier de ventes hebdomadaires mais pas d’autres fichiers. Application Administration ne me permet pas d’établir une règle simple de ce type. En revanche, avec des programmes de sortie bien étudiés, je peux définir et imposer des contrôles très granulaires et aussi journaliser toutes les transactions à distance à des fins d’audit.