Les points de sécurité non-PCI à prendre en compte

Ce genre d’autorité est souvent octroyé aux programmeurs, réputés plutôt laxistes quant à la sécurité. Dans des installations où la sécurité est stricte, certains programmeurs ont pu néanmoins la compromettre par suite de privilèges négligés ou d’un héritage de privilèges non évident. Par exemple, une valeur système peut imposer une rotation régulière des mots de passe et interdire que le nouveau mot de passe reproduise l’un des quatre ou huit précédents par exemple.

Dans la mesure où un programmeur a l’autorité au niveau des commandes, il pourrait simplement changer son mot de passe le nombre de fois voulu jusqu’à revenir à l’actuel. Cette faille a été traitée dans la version IBM i 6.1 avec la valeur système QPWDCHGBLK. Elle contient le nombre d’heures qui doit séparer deux changements de mot de passe. Les valeurs acceptables sont *NONE ou 1 à 99.

IBM i donne au job actif d’un utilisateur la possibilité d’adopter l’autorité si c’est nécessaire. Ainsi, dans telle application, un utilisateur pourrait avoir à effectuer une fonction qui requiert un niveau d’autorité supérieur à son niveau normal. On peut concevoir qu’un objet particulier puisse utiliser l’autorité de la personne qui a créé l’objet, c’est-à-dire un profil avec une autorité supérieure à celle de l’utilisateur actuel. Les programmes appelés à partir de ce point seront exécutés avec le plus haut niveau d’autorité.

Au-delà des vulnérabilités non prévues, le cryptage peut nuire à l’utilisation des applications. Par exemple, quand les utilisateurs doivent comparer du crypté à du clair, comme un numéro de carte de crédit fourni par un client par rapport à celui stocké dans une base de données, cela peut se faire en cryptant les données reçues du client puis en recherchant les enregistrements correspondants dans la base de données, en utilisant la valeur cryptée comme index.

Cette méthode présente l’inconvénient d’introduire la clé de cryptage dans des applications qui n’en auraient normalement pas besoin. Une autre technique consiste à employer un « one-way hash » (total de contrôle dans un sens) : lors du cryptage d’un numéro de carte, stocker aussi une valeur « hashée » en utilisant un algorithme one-way hash qui ne peut pas être inversé. Après quoi les données du client peuvent être hashées en utilisant le même algorithme, et les hash (totaux de contrôle) peuvent être comparés.

Sur des sites web de e-commerce et pour des appels téléphoniques qui demandent l’authentification de l’utilisateur, la question secrète standard est très souvent « Quel est le nom de jeune fille de votre mère ? » . C’est une nouvelle faiblesse car, avec les recherches généalogiques sur Internet, il est très facile de découvrir ce « secret ». Les sociétés allongent maintenant la liste des questions pour authentifier la personne au bout du fil. Par exemple : « De quelle école ou université êtes-vous diplômé ? » ou « Quelle est l’adresse de votre maison natale ? » Mais, là aussi, une partie de ces renseignements peut être trouvée sur Internet.

Il existe une meilleure approche pour identifier un utilisateur. C’est l’authentification à deux facteurs, dans laquelle un client a à la fois un ID et mot de passe utilisateur et un jeton sécurisé ou un second canal de communication sécurisée. Il existe aujourd’hui une méthode assez répandue d’authentification à deux facteurs : elle consiste à envoyer un message texte au numéro de téléphone mobile précédemment enregistré du client, puis demander à celui-ci de répéter le message à l’agent ou à l’application qui tente d’authentifier le client.

Où trouver davantage d’informations

Les API de sécurité IBM i et le traitement du cryptage en général se trouvent dans l’IBM i and System i Information Center  (publib.boulder.ibm.com/iseries/). Dans l’Information Center, après avoir choisi votre OS, sélectionnez Programming dans la navigation du côté gauche. De là, naviguez jusqu’aux API  Application programming interfaces, APIs by category, Cryptographic Services. Dans cette section, vous trouverez d’abondantes informations sur les concepts de cryptographie généraux,  les API de cryptographie, les programmes de sortie de service, et les scénarios de mise en oeuvre de ces fonctions. Ces scénarios contiennent des exemples de code source en ILE C et RPG. Les exemples de programmes permettent de créer et de peupler un magasin de clés et d’écrire et de lire des données cryptées vers et à partir d’un fichier physique.

Pour effectuer ces fonctions, il n’y a pas que les API. Vous pouvez aussi exécuter les principales fonctions de gestion des clés à l’aide de commandes CL ou la section Security de Systems Director Navigator for i, sous Cryptographic Services Key Management.

Pour la plupart des sites, en particulier ceux qui ne peuvent s’offrir une solution personnalisée, je recommande une solution de cryptage tierce. Mais cela ne dispense pas de comprendre ce qui se passe sous le capot. Cela dit, il est possible de concevoir et de mettre en oeuvre une solution maison conforme, et il existe des sites qui le prouvent. Vous devez simplement bien peser les risques et les responsabilités liés à cette autonomie. Quelle que soit la méthode choisie, vous devez absolument tester et documenter tout le processus. Ce faisant, vous bâtirez et maintiendrez la confiance de vos utilisateurs et clients. Et vous tiendrez à l’écart les drapeaux rouges des auditeurs de sécurité.