Dossier Sécurité : Protection des données DB2 (3/3)

Bien qu’un utilisateur ait besoin de privilèges au niveau schéma pour pouvoir changer ou ajouter des données, les contrôles d’accès au niveau table sont primordiaux pour sécuriser les données de gestion. Et ce, quelles que soient les autorités : privées ou adoptées par programme. La propriété ou possession d’un objet est un aspect de la sécurité des données dont nous n’avons pas encore parlé. Quand une table DB2 (fichier physique) est créée, la propriété de l’objet est attribuée à un profil utilisateur. Le propriétaire d’une table DB2 peut effectuer toute opération sur cette table. Bien entendu, il faut planifier soigneusement les niveaux d’accès des propriétaires de chaque objet dans la base de données.

Le mode d’attribution de la propriété des objets dépend de l’interface utilisée. Avec des interfaces non SQL, on attribue la propriété aux profils utilisateur ou aux profils utilisateur de groupes du job qui crée l’objet base de données. Avec des interfaces SQL, on contrôle le comportement de la propriété de l’objet en utilisant le paramètre de format de nommage – exactement comme l’autorité publique. Pour les tables DB2 que vous créez avec le nommage System, vous devez attribuer la propriété des objets de la même manière qu’avec des interfaces non SQL. Quand vous créez une table avec le nommage SQL, le propriétaire de la table est le profil utilisateur de même nom que le schéma dans lequel l’objet est créé. Par exemple, si vous créez la table TAB1 dans un schéma nommé USER1, le propriétaire de l’objet pour TAB1 est USER1. Si aucun profil utilisateur ne correspond au nom du schéma, le propriétaire de l’objet est le profil utilisateur ou profil de groupe du job créant la table. Il n’est pas bon d’attribuer la propriété de l’objet à un profil de groupe, parce que cela permet à chaque membre du profil d’hériter de l’autorité propriétaire de l’objet créé.