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.
Si vous adoptez l’autorité privée, préparez-vous à assurer vous-même l’analyse et la sécurisation de chaque objet DB2 sur le système avec les autorités appropriées. Au lieu de définir les droits d’accès pour chaque profil utilisateur du système, vous pouvez utiliser des profils de groupes et des listes d’autorisation dans IBM i pour réduire le nombre de privilèges de sécurité que vous devez accorder. Cette pratique de l’autorité privée semble déjà représenter beaucoup trop de travail. Cependant, si vous et votre entreprise considérez les données stockées dans vos bases de données DB2 comme l’un des biens les plus précieux de l’organisation, il est facile de justifier un travail de protection efficace.
La technique de l’autorité privée présente l’avantage d’offrir une sécurité difficile à transgresser, et ce même si de nouvelles interfaces et applications viennent s’ajouter au fil du temps. L’efficacité vient du fait que vous sécurisez les objets bases de données eux-mêmes et pas simplement les programmes ou interfaces. On l’a vu, la difficulté de cette approche est le temps nécessaire pour définir et gérer toutes les autorités privées pour chaque objet DB2. De plus, cette méthodologie dégrade aussi légèrement la performance, parce que le responsable de la sécurité IBM i a davantage d’autorités individuelles à traiter et à valider. L’impact sur la performance dépendra de plusieurs facteurs, dont le nombre d’objets et le nombre d’autorités.
Pour simplifier l’administration de la sécurité base de données sur DB2 for i, vous disposez de profils de groupes et de listes d’autorisation. Commençons par expliquer les profils de groupes. Les profils utilisateur IBM i peuvent appartenir à un ou plusieurs groupes. Ainsi, vous pouvez accorder des autorités à un groupe d’utilisateurs au lieu de définir les autorités pour chaque profil utilisateur. Par exemple, on pourrait avoir un profil de groupe pour la base de données Ventes (GPSales) et un autre profil de groupe pour la base de données Paie (GPPay). Vous ajoutez des profils utilisateur individuels à ces groupes, puis accordez l’autorité sur l’objet base de données aux profils de groupes. Les profils de groupes sont souvent fondés sur le rôle du département ou de l’activité (par exemple help desk, guichetier).
A noter qu’il n’y a pas toujours de commande pour créer un profil de groupe. Au lieu de cela, un profil utilisateur est implicitement transformé en un profil de groupe quand ce profil utilisateur est référencé sur les paramètres des profils de groupes (c’est-à-dire Group Profile – GRPPRF et Supplement Group Profile – SUPGRPPRF) sur les commandes CRTUSRPRF ou CHGUSRPRF. Généralement, un profil de groupe est créé avec PASSWORD(*NONE), comme dans cet exemple, afin qu’aucun utilisateur ne puisse se servir individuellement du profil de groupe pour se connecter.
Dans l’exemple, on voit que APPUSER3 appartient aux deux profils de groupes. Un profil utilisateur peut appartenir jusqu’à seize profils de groupes. Les profils de groupes ne peuvent pas appartenir à d’autres groupes. Le premier groupe doit toujours être spécifié sur le paramètre GRPPRF et les autres groupes sur le paramètre SUPGRPPRF. La principale différence entre ces deux paramètres est que les valeurs OWNER, GRPAUT et GRPAUTTYP pour le profil utilisateur individuel ne s’appliquent qu’au profil de groupe spécifié sur le paramètre GRPPRF. Ces paramètres contrôlent la manière dont la propriété de l’objet est attribuée quand un profil utilisateur appartenant à un groupe crée un objet. Le responsable de la sécurité IBM i n’additionne pas les autorités de profils individuelles et de groupes pour déterminer si le profil utilisateur est autorisé à effectuer une opération sur la base de données. Il examine séparément les références pour un profil utilisateur et un profil de groupe. Quand on utilise des profils de groupes, il vaut mieux que les profils utilisateur individuels n’aient pas d’autorités (même *EXCLUDE) sur les objets DB2, avec les autorités objets accordées au profil utilisateur de groupe. Un autre conseil concernant les profils de groupes consiste à utiliser la commande Change Object Primary Group (CHGOBJPGP), pour améliorer la performance. Elle l’améliore en stockant l’information à propos de l’autorité du profil de groupe spécifié dans l’objet table lui-même.
Téléchargez cette ressource
Comment sécuriser une PME avec l’approche par les risques ?
Disposant de moyens financiers et humains contraints, les PME éprouvent des difficultés à mettre en place une véritable stratégie de cybersécurité. Opérateur de services et d’infrastructures, Naitways leur propose une approche pragmatique de sécurité « by design » en priorisant les risques auxquelles elles sont confrontées.
