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

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

Tech - Par Terry Ford et Kent Milligan - Publié le 21 février 2011
email

Pas un jour ne se passe sans qu’il soit question de piratage, intrusion et autres vols de données. En fait, quelque 250 millions d’enregistrements de données ont été compromis dans un millier d’incidents depuis 2005.

Forrester Research estime que le coût du redressement consécutif à une intrusion est de 90 à 305 dollars par enregistrement exposé. Il est certain que de telles violations coûtent cher tant aux individus qu’aux sociétés concernées. Même la forteresse que représente DB2 est vulnérable, donc explorons les technologies et techniques aptes à sécuriser vos bases de données sur IBM i.

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éé.

Téléchargez cette ressource

Livre blanc Sécurité et Stockage des documents

Livre blanc Sécurité et Stockage des documents

Découvrez dans ce livre blanc Kyocera les outils logiciels qui permettent une approche holistique et efficace de la collecte, du stockage, de la gestion et de la sécurisation des documents en entreprise.

Tech - Par Terry Ford et Kent Milligan - Publié le 21 février 2011