Approches de la sécurité DB2

/>

L’autorité adoptée par programme peut simplifier votre dispositif de sécurité en réduisant le nombre de profils utilisateur auxquels il faut accorder l’accès aux objets DB2. En raison du faible nombre d’autorités individuelles, ce modèle de sécurité est celui que le responsable de la sécurité intégrée IBM i peut imposer le plus efficacement. Ici, l’accès public aux objets DB2 est désactivé en spécifiant *EXCLUDE pour l’autorité PUBLIC, après quoi le seul utilisateur ayant des droits d’accès sur l’objet est le profil utilisateur qui possède le programme.

Quand un programme tourne sur le système et qu’il référence des objets DB2, le comportement par défaut est que le profil utilisateur du job soit validé par rapport aux contrôles de sécurité en place pour l’objet référencé. Ainsi, si APPUSER1 est le profil utilisateur exécutant le programme WORKAPP, chaque fois que WORKAPP essaie d’accéder à un objet DB2, le responsable sécurité vérifie si le profil utilisateur APPUSER1 a l’autorité suffisante pour exécuter l’opération demandée sur cet objet DB2.

Avec l’autorité adoptée par programme, vous pouvez créer (ou chan ger) le programme pour utiliser l’autorité du propriétaire du programme. Pour cela, spécifiez un paramètre USRPRF(*OWNER) sur les commandes Create Program (CRTP GM) ou Change Program (CHGP GM).

Supposons que PRFWRKAPP soit le profil qui possède l’objet programme. APPUSER1 démarre une session et exécute le programme WORKAPP. Avec l’autorité adoptée en place, chaque fois que WORKAPP référence un objet DB2, les privilèges des deux profils utilisateur APPUSER1 et PRFWRKAPP sont vérifiés pour savoir si le programme a le droit d’effectuer l’opération spécifiée sur la base de données.

En plus de changer le programme pour adopter l’autorité propriétaire, certaines autorités doivent être données au propriétaire du programme. Avec l’autorité adoptée par programme, en principe seul le profil utilisateur propriétaire de l’objet possède l’accès aux objets DB2, et l’accès public est restreint avec l’autorité *EXCLUDE. De plus, les utilisateurs de l’application ont besoin de l’autorité *EXECUTE sur l’objet programme.

On suppose que WORKTAB est le seul objet DB2 auquel l’application accède. Cet exemple d’autorité adoptée devrait démontrer comment l’utilisation de ce modèle peut simplifier votre dispositif de sécurité de base de données. Au lieu d’accorder l’accès à la table WORKTAB à chaque utilisateur de l’application, seul le propriétaire du programme (PRFWRKAPP) a besoin de privilèges pour changer et lire la table WORKTAB.

L’autorité adoptée par programme donne l’impression d’être liée à l’ancienne technologie AS/400. Et donc vous vous demandez peut-être si elle est compatible avec des technologies plus récentes comme Java et SQL. Oui, elle l’est. Quand SQL est imbriqué dans les programmes, les précompilateurs SQL vous permettent de spécifier *OWNER pour les paramètres USRPRF (User Profile) et DYNUSRPRF (Dynamic User Profile). Les mêmes options existent sur la clause SET OPTION pour les procédures déclencheurs et fonctions SQL.

Les applications Java ne sont pas associées aux objets programmes IBM i et donc il n’y a aucun objet programme que vous puissiez modifier. Dans ce genre de situation, les applications peuvent utiliser le jeu d’API swap profile pour émuler le modèle d’autorité adopté. Le jeu d’API swap profile comporte trois éléments : Get Profile Handle (QSYGETPH), Set Profile (QWTSETP) et Release Profile Handle (QSYRLSPH). Le jeu d’API swap profile est exécuté au début de l’application pour passer du profil utilisateur qui exécute l’application à un profil utilisateur doté des autorisations sur la base de données que l’application requiert. Une fois l’application exécutée, le jeu d’API swap profile est utilisé pour libérer le profil utilisateur permuté et revenir au profil utilisateur original. C’est la même technique que pour le traitement d’une autorité adoptée par programme : au terme de l’appel du programme, l’utilisateur exécutant l’application revient aux droits d’autorisation que son profil utilisateur détient.

Jusqu’ici nous n’avons parlé que des avantages du modèle d’autorité adopté. Voyons-en maintenant les inconvénients. Premier écueil : le ris – que qui existe si le programme fonctionnant avec l’autorité adoptée présente une ligne de commande à l’utilisateur de l’application. Par exem – ple, l’application WORKAPP offre peutêtre des possibilités d’impression et une option de menu qui conduit l’utilisateur à l’interface de WORKSPLF (Work with Spooled Files). Une ligne de commande est présente sur l’interface WRKSPLF. Toutes les opérations que APPUSER1 exécute à partir de cette interface de ligne de commande incluent aussi les nouvelles autorisations ajoutées avec l’autorité adoptée (PRFWRKAPP). L’utilisateur de l’application peut utiliser à sa guise les autorités adoptées à partir de la ligne de commande. Pour réduire ce risque, vous pouvez utiliser le paramètre USEADPAUT sur la commande CHGP GM. Mais il est clair que l’autorité adoptée par programme doit être soumise à une planification rigoureuse, pour éviter que l’utilisateur de l’application puisse utiliser les autorités adoptées en dehors de l’application.

Le modèle d’autorité adoptée par programme demande aussi la possibilité de modifier les attributs des objets programmes ou le code programme lui-même ; mais, si vous utilisez des programmes IBM ou tiers, vous ne pouvez pas effectuer des modifications de ce genre. Supposons qu’un analyste de gestion veuille créer un rapport au moyen de Query/400 ou IBM DB2 Web Query for i. Dans ce cas, pour que l’autorité adoptée fonctionne, il faut de la programmation supplémentaire. Par exemple, vous pourriez écrire un programme CL enveloppant (wrapper) qui adopte l’autorité nécessaire pour que le rapport Query/400 fonctionne. DB2 Web Query peut interroger un jeu de résultats renvoyé depuis un appel de procédure stockée, et donc vous pourriez coder une procédure stockée qui adopte l’autorité. Votre équipe IT a-t-elle les ressources et les compétences pour créer un programme pour chaque rapport ? Qu’advient-il s’il est impossible de créer un wrapper pour les outils tiers tel que System i Navigator ? Vous devez rechercher et étudier les interfaces logicielles et bases de données tierces à l’extérieur de l’application de votre société, avant de trop compter sur l’autorité adoptée pour protéger vos bases de données DB2.