> Tech > Exigences de Save/Restore quant à  la sécurité

Exigences de Save/Restore quant à  la sécurité

Tech - Par iTPro - Publié le 24 juin 2010
email

  Pour effectuer une sauvegarde ou une restauration, un utilisateur doit avoir le droit d'employer les commandes Save et Restore. La plupart des sites octroient aux utilisateurs chargés des opérations Save, l'autorité spéciale *SAVRST permettant aux utilisateurs de sauvegarder des objets même s'ils n'ont pas autorité sur eux. Les utilisateurs qui

Exigences de Save/Restore quant à  la sécurité

n’ont pas l’autorité spéciale *SAVRST doivent avoir le *OBJEXIST (object existence) pour chaque objet qu’ils veulent sauvegarder.

  Une opération Restore ajoute ou remplace des objets dans le système. Pendant un Restore, si l’objet restauré existe déjà  dans le système, l’information d’autorité le concernant est inchangée, mais son contenu est modifié. Si l’objet restauré n’existe pas déjà  dans le système, l’information sur son autorité propriétaire d’objet, autorité *PUBLIC, et autorité du profil de groupe primaire (éventuel) est restaurée telle qu’elle a été rangée sur le média de sauvegarde. Si le profil d’utilisateur propriétaire d’un objet sur le média de sauvegarde n’existe pas, l’opération Restore attribue l’objet au profil d’utilisateur par défaut QDFTOWN.

  Quand on restaure les objets sauvegardés, l’OS/400 traite l’opération Restore de façon variable, selon qu’une liste d’autorisations protège, ou non, chaque objet. Quand un objet sauvegardé est restauré sur le même système où il a été sauvegardé, l’OS/400 associe l’objet à  la liste d’autorisations de même nom. Si le système ne parvient pas à  trouver la liste d’autorisations, l’autorité *PUBLIC est mise à  *EXCLUDE parce que la liste d’autorisations peut avoir accès à  des utilisateurs précédemment restreints.

  Si un objet est restauré sur un système différent de celui sur lequel il a été sauvegardé, il n’est pas associé à  une liste d’autorisations parce que les utilisateurs figurant sur la liste d’autorisations du nouveau système peuvent être différents. (Si l’on spécifie *YES pour le paramètre ALWOBJDIF, l’objet sera associé à  la liste d’autorisations de même nom sur le nouveau système quand la restauration sera effectuée sur un système différent.)

  En cas de restauration système complète sur un système différent, il est très important de spécifier ALWOBJDIF(*ALL) afin que les listes d’autorisations soient rattachées aux objets. Il faut être  » officier de sécurité  » (c’est-à dire posséder l’autorité spéciale *ALLOBJ et SECADM) pour spécifier le paramètre ALWOBJDIF(*YES) sur les commandes restore. En fait, le besoin de spécifier le paramètre ALWOBJDIF(*ALL) est l’une des raisons pour lesquelles les instructions d’installation ordonnent souvent à  un utilisateur de se connecter comme un officier de sécurité ( » Sign on as the security officer « ).

  Si un utilisateur autre que le propriétaire ou un officier de sécurité restaure un programme qui adopte l’autorité de son propriétaire, tout accès au programme est révoqué. C’est indispensable pour empêcher les utilisateurs de compromettre la sécurité en restaurant un programme qui adopte l’autorité.

  L’utilisation de l’autorité privée pour sécuriser un objet pose un problème : l’autorité privée n’est pas restaurée en même temps que l’objet. D’un point de vue Restore, le meilleur moyen d’octroyer aux utilisateurs l’accès à  un objet consiste à  utiliser une liste d’autorisations. De telles listes sont donc recommandées. Une liste d’autorisations présente deux avantages : Premièrement, quand on restaure un objet qui a été sécurisé par une liste d’autorisations, l’objet sera de nouveau sécurisé par la liste pendant l’opération de restauration. (Notons la nécessité de spécifier ALWOBJDIF(*ALL) si l’objet est restauré sur un système autre que celui sur lequel il a été sauvegardé.) Deuxièmement, une liste d’autorisations unique peut sécuriser de multiples objets, avec un double avantage : un plus petit nombre d’autorités privées et une sauvegarde plus rapide des profils d’utilisateurs.

Téléchargez cette ressource

Guide de cybersécurité en milieu sensible

Guide de cybersécurité en milieu sensible

Sur fond de vulnérabilités en tout genre, les établissements hospitaliers, pharmacies, laboratoires et autres structures de soin font face à des vagues incessantes de cyberattaques. L’objectif de ce livre blanc est de permettre aux responsables informatiques ainsi qu’à l’écosystème des sous-traitants et prestataires du secteur médical de se plonger dans un état de l’art de la cybersécurité des établissements de santé. Et de faire face à la menace.

Tech - Par iTPro - Publié le 24 juin 2010