Les listes d’autorisation

données contient plusieurs tables qui incluent des historiques de ventes, à la disposition des analystes. Dans ce cas, chaque analyste de gestion qui utilise l’entrepôt de données a besoin d’accéder à chaque table. Au lieu d’accorder des autorités privées sur chaque table, il vaut mieux créer une liste d’autorisations qui donne aux utilisateurs l’autorité nécessaire sur chaque table associée à la liste. Il faut considérer une liste d’autorisations comme contenant une liste de profils utilisateur et l’autorité que chacun d’eux a sur les objets DB2 associés à la liste. La figure 5 montre une liste d’autorisations en action. La première étape consiste à créer l’objet liste d’autorisations avec la commande Create Authorization List (CRTAUTL). Le paramètre AUTHORITY sur la commande CRTAUTL n’est pas l’autorité que chaque profil utilisateur a sur les objets DB2 associés à la liste. Si un objet DB2 associé a *AUTL comme paramètre d’autorité public, la valeur de paramètre AUTHORITY (*EXCLUDE dans ce cas) provenant de la liste d’autorisations est utilisée comme le paramètre d’autorité publique de l’objet DB2. L’étape suivante consiste à mettre l’objet base de données sous le contrôle de sécurité d’une liste d’autorisations. Cela se fait avec la commande GRTOBJAUT. Un objet IBM i ne peut être associé qu’à une liste d’autorisations à la fois.

La dernière étape consiste à donner aux utilisateurs l’autorité sur la liste d’autorisations. Après quoi les profils utilisateur ont l’autorité spécifiée sur tout objet que la liste d’autorisations sécurise. Vous devez effectuer cette étape avec la commande Add Authorization List Entry (ADDAUTLE) car il n’y a aucune instruction SQL pour cela. Dans cet exemple, les deux premiers utilisateurs reçoivent l’autorité *USE sur les objets DB2 sécurisés par la liste, et le dernier utilisateur administrateur reçoit l’autorité *CHANGE. De ce fait, les utilisateurs BIZUSER1 et BIZUSER2 ont l’autorité *USE sur tout objet DB2 associé à la liste d’autorisations, tandis que le profil utilisateur DWADMIN a les possibilités *CHANGE.

Le principe de base est que l’autorité utilisateur est définie pour la liste d’autorisations, et pas pour les objets individuels sécurisés par la liste. Si un nouvel objet DB2 est sécurisé par la liste d’autorisations, les utilisateurs présents sur la liste acquièrent automatiquement l’autorité sur l’objet. Il est donc facile de sécuriser de nouveaux objets avec les mêmes exigences de sécurité que celles des objets existant dans votre base de données.

Quand vous sécurisez une table DB2 avec une liste d’autorisations, vous pouvez changer les autorités même quand la table est ouverte. Avec des profils de groupes et des profils utilisateur individuels, vous ne pouvez pas octroyer ou révoquer des autorités provenant d’un objet ouvert. D’où la question : vaut-il mieux une liste d’autorisations qu’un profil de groupe ? La réponse est qu’aucun des deux n’est meilleur. Le choix d’une technique dépend vraiment de ce qui résout le mieux votre problème. En fait, vous pouvez ajouter un profil de groupe à une liste d’autorisations de la même manière que vous ajoutez un profil utilisateur individuel. D’ailleurs, de nombreux sites utilisent les deux possibilités à la fois.

Comme avec l’autorité adoptée par programme, l’approche autorité privée devrait s’accompagner de la réduction de l’autorité publique à *EXCLUDE si c’est possible. Interdire à tous les utilisateurs d’accéder à un objet DB2 est bien plus sûr que de laisser la porte ouverte à votre objet DB2 par défaut. Il est également possible d’utiliser une combinaison de l’autorité adoptée et des autorités privées, pour réduire l’administration de la sécurité de la base de données ; les autorités privées n’étant alors employées que pour les interfaces qui ne sont pas facilement supportées par l’autorité adoptée.

Bien qu’un modèle d’autorité privée demande plus de temps à mettre en oeuvre et à gérer, il protège mieux la sécurité des données sur toutes les interfaces, d’aujourd’hui et de demain. Maintenant que nous comprenons les deux approches basiques vis-à-vis de la sécurité DB2, voyons plus en détail les considérations de sécurité pour les interfaces et les objets présents dans votre base de données.