|
|
France-Français | |
|
|
 |
|
Guide d'administration Software Distributor : HP-UX 11i v1, 11i v2 et 11i v3 > Chapitre 9 Sécurité de SD-UX
Modèles d'utilisation de sécurité |
|
|
Les modèles d'utilisation ci-dessous font appel au groupe swadm, fourni dans les ACL hôte par défaut, ACL installées en même temps que SD-UX. Ce groupe ne fait pas partie de la configuration HP-UX par défaut, mais il est facile de l'y ajouter. En premier lieu, ajoutez le groupe swadm et les éléments concernés de ce groupe au moyen du produit HP-UX System Administration Manager (sam). Ensuite, ajoutez le lien /etc/logingroup au répertoire /etc/group pour activer les groupes HP-UX supplémentaires. Si le fichier /etc/logingroup n'existe pas sur les systèmes considérés comme des contrôleurs SD-UX, exécutez la commande qui suit (en tant que superutilisateur) sur les systèmes concernés : ln -s /etc/group /etc/logingroup Une utilisation classique des capacités de fonctionnement à distance de SD-UX pour un administrateur de logiciel consiste à extraire le logiciel d'un dépôt local sur différentes cibles distantes. Pour définir ce type de configuration, procédez de la manière suivante :
Il est possible que vous ayez le souhait d'accorder des droits à des utilisateurs spécifiques afin de gérer des produits particuliers dans le dépôt principal. Par exemple, l'utilisateur raymond peut avoir pour responsabilité de gérer le produit ALLBASE de votre dépôt, d'installer de nouvelles versions et corrections dès qu'elles sont disponibles. Pour ajouter raymond à l'ACL du produit ALLBASE dans le dépôt local et lui accorder l'ensemble des droits concernant ce produit, exécutez la commande : swacl -l product -M user:raymond:a ALLBASE Simultanément, il est possible que vous souhaitiez éliminer l'entrée d'ACL du groupe swadm pour le même produit : Les administrateurs de systèmes hôtes peuvent accorder des droits d'administration locale de logiciels à des utilisateurs isolés ou des groupes certifiés par le système hôte local. Les utilisateurs locaux certifiés disposent d'entrées d'ACL racine destinées à accorder des droits d'insertion et d'écriture. Pour le dépôt source, l'accès aux produits logiciels est autorisé par un accès en lecture sans restriction aux systèmes hôte, dépôts et produits. Cette approche constitue la base d'un modèle d'extraction de distribution de logiciels. Les responsables de dépôts source de logiciels sont susceptibles d'accorder l'installation libre des logiciels, comme indiqué ci-dessus. Ils peuvent aussi choisir de limiter la distribution à des systèmes spécifiques. Les ACL qui protègent des produits de dépôts source sont susceptibles de contenir des entrées restreignant l'accès au produit en lecture à certains systèmes, interdisant ainsi son installation. Cette restriction s'applique aussi bien au modèle par copie que par extraction. L'exemple d'ACL de produit qui suit restreint l'accès en lecture pour systèmeA et systèmeB et accorde tous les droits à l'utilisateur swadm:
Les développeurs de logiciels conditionnent leurs produits de manière répétitive et les testent avant diffusion. Il s'agit d'intégrer les produits dans des dépôts et de les installer dans des répertoires racine pour essai. Du fait de la nécessité de plusieurs cycles pour obtenir la configuration adéquate, il est inefficace d'empêcher les développeurs de logiciels d'avoir libre accès aux dépôts et aux répertoires racine pour ce test. Il est préférable par ailleurs que des produits testés n'entrent et ne sortent pas de dépôts et de répertoires racine d'usage général. Ils sont susceptibles d'être installés accidentellement ou utilisés avant d'être prêts. La méthode de développement conseillée consiste à créer un ou plusieurs dépôts de développement et répertoires racine à des fins de test, chacun d'eux disposant de protections personnalisées en fonction des besoins du groupe de développement qui les utilise. À cette fin, le mécanisme de modèle d'ACL par défaut décrit précédemment est commode, car les produits sont copiés et repartent rapidement. Un administrateur hôte (qui dispose du droit d'insertion sur le système hôte) doit créer le dépôt de test pour les développeurs, puis affecter un administrateur de dépôt et modifier l'ACL de dépôt pour accorder à cette personne le droit de contrôle (modification d'ACL) sur le dépôt. Le modèle d’ACL de produit du dépôt doit alors être configuré de telle sorte que les utilisateurs qui insèrent un produit puissent également y écrire (modification et suppression) et de telle sorte qu’il ne puisse être que lu par les systèmes de test connus. De manière similaire, il est possible de créer de répertoires racine de test, éventuellement sur les autres systèmes hôtes de test. Les développeurs sont ainsi à même d'installer des produits en essai. L'accès pour installation au répertoire de test doit être limité au groupe de développement. Lorsque le test est achevé et qu'un produit est prêt pour diffusion, le produit peut alors être copié dans un dépôt de distribution général pour en assurer le plus large accès en lecture sans exposer les produits non testés du dépôt d'essai. Il existe bien d'autres approches permettant de mettre en œuvre ces concepts afin d'appliquer une politique de sécurité définie pour le développement de produits. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Version imprimable |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
