Des outils adaptés

applications et interfaces, on protège les ressources – bibliothèques, fichiers et autres – auxquelles ils prétendent accéder. Cela revient à installer une clôture autour de votre propriété et à poster devant le portail un garde qui ne laisse entrer que les gens figurant sur une certaine liste.

La sécurité des ressources désigne le niveau d’accès autorisé pour chaque profil utilisateur. Ainsi, certains utilisateurs peuvent avoir un accès en lecture seule à un fichier, tandis que d’autres peuvent en modifier les données. Cela peut paraître encombrant, mais on doit rarement gérer des profils et des objets utilisateur individuels. Au lieu de cela, en combinant des profils de groupes et des listes d’autorisations, on peut créer un maillage de règles contrôlant l’accès à chaque ressource. On peut aussi réduire la complexité des règles de sécurité des ressources grâce aux relations qui existent entre les objets. Par exemple, en restreignant l’accès à une bibliothèque, on le restreint aussi à tous les fichiers de cette bibliothèque.

Utiliser la sécurité des ressources plutôt que de contrôler les possibilités de chaque utilisateur, garantit la protection de la base de données, indépendamment des applications auxquelles les utilisateurs ont accès. Il est même souvent judicieux de pousser plus loin cette stratégie qui consiste à « protéger les données plutôt que contrôler l’utilisateur ». Le fait d’accorder aux utilisateurs l’accès direct aux ressources iSeries, comme des fichiers physiques, est généralement trop laxiste. On préfèrera restreindre l’accès à des applications désignées, comme on le faisait par le passé au moyen de la sécurité par menus.

Beaucoup d’applications basées sur PC supplantent l’ID utilisateur individuelle, et donc le profil utilisateur ne correspond pas forcément à l’individu qui exécute l’application. En utilisant une stratégie de sécurité qui contrôle l’accès aux données via des applications spécifiques, on peut aussi régler ce problème.

Les solutions qui restreignent l’accès via des applications désignées exigent deux profils utilisateur séparés : les profils qui ont des droits d’accès aux données ne peuvent pas servir pour se connecter au système, tandis que les profils qui servent pour la connexion n’ont pas de droits leur permettant de modifier données ou applications. Plus précisément, cette stratégie tente de contrôler non seulement qui peut accéder à une ressource, mais les tâches précises qu’un utilisateur peut effectuer.

En élargissant quelque peu notre analogie avec la sécurité physique, cette stratégie s’apparente à la méthode suivante : vérification d’une liste d’invités à la porte, puis désignation d’un employé qui accompagnera chaque invité circulant dans la propriété. Les invités n’ont pas accès aux ressources internes – fichiers physiques, par exemple. Mais leurs guides ouvrent les portes et surveillent leurs activités. Nos guides sont les applications que vous avez écrites. Il existe plusieurs méthodes différentes et quelque peu antagonistes, permettant d’atteindre cet objectif (pour prendre connaissance d’autres solutions, voir Autres lectures).