Aujourd’hui, il n’est plus question de configurer les objets application avec des autorités publiques permettant au premier utilisateur venu de voir ou de mettre à jour tous les fichiers de données. Remerciez-en les lois et règlements qui s’appliquent aux configurations de données, visant à refuser l’accès par défaut.Désormais, tous les objets application doivent être configurés de telle sorte que les fichiers ne puissent être ni mis à jour ni vus hors des interfaces applicatives approuvées. Sur i5/OS, cela se fait en excluant (par *EXCLUDE) l’autorité *PUBLIC sur nos objets fichiers de données. Mais, direz-vous, si l’autorité publique est réglée sur *EXCLUDE, comment l’utilisateur peut-il obtenir l’autorité suffisante pour accéder et mettre à jour, les fichiers de données pendant qu’il utilise l’application ? Cet article décrit les techniques qui fournissent l’autorité pendant l’exécution de l’application, sans l’accorder en permanence.
Techniques pour permettre l’accès aux applications
L’autorité adoptée est l’une des méthodes permettant d’accorder aux utilisateurs l’autorité nécessaire et suffisante. Elle donne temporairement aux utilisateurs l’autorité sur des objets application tels que des programmes ou des fichiers. L’autorité adoptée est validée par un attribut de programme. Quand le programme est appelé, l’autorité adoptée reste en vigueur tant que le programme est actif ou, plus exactement, tant que le programme se trouve dans la pile d’appels. L’autorité que détient l’utilisateur pendant que le programme est dans la pile, est celle du propriétaire du programme. Ainsi, si un utilisateur choisit dans le menu une option visant à mettre à jour un champ dans un fichier, mais si son autorité est insuffisante pour cela, il reçoit généralement un message « Not authorized to file XYZ ». En revanche, s’il y a un programme d’application dans la pile d’appels qui adopte l’autorité, i5/OS vérifie l’autorité du propriétaire du programme sur le fichier. Si elle est suffisante, l’utilisateur peut accéder au fichier et mettre à jour le champ.
Les développeurs utilisent souvent l’autorité adoptée pour appliquer le modèle d’autorisation Application Only Access. Dans ce modèle d’autorisation, les objets tels que des fichiers bases de données ne peuvent faire l’objet d’un accès que quand un utilisateur effectue une fonction autorisée. Ces fonctions autorisées sont généralement validées via les options du menu d’application. Si un utilisateur tente d’accéder directement à un fichier (par le biais d’une interface telle que FTP), il reçoit un message « Not authorized ». Ce refus s’explique parce que l’autorité publique est généralement réglée sur *EXCLUDE et que les utilisateurs ne reçoivent aucune autorité, privée ou explicite, sur les fichiers de données de l’application. Cependant, les utilisateurs peuvent effectuer les fonctions nécessaires tout en passant par le menu de l’application, parce que les programmes qui travaillent pour le compte de ces options, adoptent l’autorité du propriétaire, et le propriétaire du programme soit possède les fichiers de données soit, de manière plus stricte, a juste assez d’autorité sur les fichiers pour utiliser normalement l’application.
L’autorité adoptée trouve aussi sa place dans d’autres menus : administrateur système, help desk ou opérateur. En effet, les administrateurs et opérateurs disposent souvent de leurs propres menus pour effectuer leurs tâches. On peut créer un menu dans lequel une ou plusieurs options invoquent une fonction demandant plus d’autorité que celle dont dispose l’administrateur système ou l’opérateur. Par exemple, l’autorité sur le profil utilisateur et l’autorité spéciale *SECADM est nécessaire pour redéfinir le mot de passe d’un utilisateur. Plutôt que de donner *SECADM aux administrateurs système, vous pouvez créer une option de menu qui appelle un programme chargé d’exécuter la commande Change User Profile (CHGUSRPRF). Ce programme adopte et est possédé par un profil avec l’autorité spéciale *SECADM, ainsi que l’autorité *USE et *OBJMGT, sur tous les profils présents sur le système.
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
