Autorisation
Si vous souhaitez refuser l'accès à un utilisateur d'un profil de sécurité individuel, vous devez supprimer cet utilisateur du profil de sécurité.
Le système propose des profils de sécurité prédéfinis et vous permet de créer autant de profils que vous le souhaitez, à l'aide de la boîte de dialogue Profils de sécurité.
Nous vous recommandons qu'au moins l'un de ces profils ait un contrôle total du droit d'accès au système.
Présentation des autorisations
L'autorisation couvre les types d'autorisation suivants :
■
Autorisations de classes
■
Autorisations sur l'objet
■
Autorisations pour une zone
Le sous-système de sécurité gère tous les types d'autorisations et utilise une approche cumulative afin d'obtenir des autorisations effectives.
Si vous avez activé les autorisations pour une zone, deux types d'autorisations (d'objet et de zone) sont vérifiés pour accéder aux objets. Cela signifie qu'un utilisateur nécessite des autorisations pour un objet et pour une zone afin d'obtenir un objet géré. Les autorisations pour un objet sont vérifiées uniquement si la prise en charge de zone est désactivée.
Autorisations de classes
Les autorisations de classes correspondent aux droits d'accès que vous spécifiez au niveau des classes. Cela signifie que les autorisations au niveau de la classe correspondent aux droits par défaut pour chaque objet constituant une instance de cette classe.
Lorsque vous créez un profil de sécurité, vous devez spécifier les autorisations de classes pour chaque profil de sécurité. Pour toutes les classes de sécurité, Aucun accès est défini par défaut. Les profils de sécurité disposant des autorisations de classes appropriées vous confèrent des droits d'accès au système. Vous pouvez spécifier ces informations dans la boîte de dialogue Autorisations de classes.
Les autorisations de classes s'appliquent globalement à tous les objets d'une classe d'objet. Si vous souhaitez limiter les utilisateurs à un objet ou à un dossier spécifique de l'Explorateur, ou leur accorder des droits d'accès étendus, utilisez respectivement les boîtes de dialogue Autorisations sur l'objet ou Autorisations du groupe de sécurité.
422 Manuel d'implémentation
Autorisation
■
■
■
■
■
■
■
Les classes de sécurité servent à regrouper des objets de type identique. Le soussystème de sécurité dans CA Client Automation prend en charge les classes de sécurité suivantes :
■
Matériel détecté (Ordinateur)
■
Utilisateurs
■
Utilisateurs
■
Gestionnaire
■
Serveurs
■
Groupes d'actifs
■
Groupes de serveurs
■
Groupes de domaines
■
Requêtes
■
Classes de sécurité
■
Profils de sécurité
■
Packages logiciels
■
Procédures logicielles
■
Groupes de procédures
■
Conteneurs de job
■
Jobs logiciels
■
Jobs d'actifs
■
Modules
■
Règles basées sur une requête
■
Stratégies basées sur les événements
Images de démarrage OSIM
Images de système d'exploitation OSIM
Moteur
Ordinateur de stratégies de configuration
Utilisateur de stratégies de configuration
■
Accès aux répertoires externes
Modèles de rapports
Modules d'inventaire
Chapitre 11: Fonctionnalités de sécurité Client Automation 423
Autorisation
Les classes de sécurité suivantes sont uniquement utilisées au niveau de la classe.
■
MDB Access
■
Activez le Panneau de configuration
■
Activez Remote Control
La sécurité au niveau de la classe signifie que chaque objet ou instance d'une classe obtient l'autorisation, comme défini pour la classe par défaut.
Autorisations de classes combinées requises pour des actions spécifiques
Quelques droits de classe d'objet dépendent les unes des autres ; cela signifie que pour réaliser les actions suivantes, vous devez accorder des droits à plus d'une classe d'objet.
Modèles de rapports
Pour planifier un modèle Rapport, vous devez accorder la modification à la classe d'objet "Planification de rapport" et la modification pour la classe d'objet "Moteur".
Profils de sécurité
La classe d'objet "Profils de sécurité" contrôle la gestion avec des profils de sécurité uniquement (supprimer, etc.). Si vous voulez modifier des autorisations de classes d'objets dans un profil de sécurité, vous devez disposer d'un accès spécial (VRWXP, avec l'autorisation P) pour la classe d'objet "Autorisations de classe".
Moteur
Pour relier une tâche de moteur à un moteur, vous devez accorder Modifier à la classe d'objet "Moteur" et Gérer à la classe d'objet "Tâche de moteur".
Concernant la sécurité de moteur, si vous voulez démarrer, arrêter ou modifier des objets de moteur, vous devez accorder un Contrôle total à la classe "Moteur" dans le profil de sécurité et au-delà des droits Administrateur NT ou racines à l'ordinateur sur lequel est exécuté le moteur.
Sécurité de job logiciel
Pour modifier ou supprimer un job logiciel sous le dossier /computer, le logiciel est livré dans /Jobs/Software Jobs ; les classes d'objets Ordinateur et Job logiciel doivent disposer de droits Modifier.
424 Manuel d'implémentation
Autorisation
Autorisations d'objet
Sécurité de procédure
Si vous voulez démarrer, arrêter ou modifier des objets Procédure, vous devez accorder Modifier (VRWXD) à la classe "Procédure" et au-delà des autorisations de fichier administrateur/utilisateur racine.
Prise en charge des zones de sécurité
Si vous souhaitez activer ou désactiver la prise en charge des zones de sécurité et définir les zones de sécurité par défaut, les autorisations de classe pour la classe de l'objet "Zone de sécurité" doivent être configurées au moins sur Accès spécial (VP).
Si vous souhaitez lier les profils de sécurité à une zone de sécurité, les autorisations
Affichage (V) sont suffisantes pour la classe d'objet "Zone de sécurité". Les autorisations de classe pour les classes d'objets "Profils de sécurité" doivent être configurées au moins sur Accès spécial (VW).
La définition des autorisations sur l'objet est utile lorsque vous souhaitez limiter les droits d'accès d'un objet particulier. Par défaut, tous les objets héritent des autorisations définies pour la classe d'objets.
Les autorisations d'objets sont prioritaires sur les autorisations de classes et de groupes.
Les autorisations d'objet sont toujours présentes et gérées par le sous-système de sécurité. Elles ne peuvent être désactivées. Si vous ne voulez pas vous charger des autorisations d'objet, vous pouvez définir des autorisations au niveau de la classe pour toutes les classes d'objets par Contrôle complet.
L'autorisation est basée sur le concept d'une entrée de contrôle d'accès (ACE). ACE représente n'importe quelle combinaison de lettres indiquée dans le tableau suivant, notamment VR. Cette ACE vous permet d'afficher et de lire des objets. Toute autre forme d'accès est refusée.
Si une ACE est vide (qu'elle ne contient aucune lettre du code), aucun droit d'accès n'est accordé.
Lettre de code dans une ACE
Le tableau suivant définit des autorisations d'objet :
Signification Droits accordés
V Affichage Permet d'afficher des objets
Chapitre 11: Fonctionnalités de sécurité Client Automation 425
P
O
R
W
X
D
Autorisation
Lettre de code dans une ACE
V
Signification Droits accordés
Affichage Permet d'afficher des objets
C Créer Permet de créer des objets
Lecture
Ecriture
Exécuter
Supprimer
Permet de lire les sous-objets d'un objet
Vous permet de modifier un objet
Permet l'exécution, en fonction du type d'objet
Permet de supprimer des objets
Droit d'accès Permet de modifier l'ACE même.
Ownership Permet de s'approprier un objet
Un utilisateur appartient à un ou plusieurs profils de sécurité. Un utilisateur peut aussi
être le propriétaire d'un objet. Un ensemble de classes de sécurité est affecté à chaque profil de sécurité. Une autorisation de classe de sécurité définit l'autorisation par défaut qui est affectée à un objet, lorsqu'une instance de la classe est créée.
426 Manuel d'implémentation
Autorisation
L'illustration ci-dessous indique la manière dont les profils de sécurité, les classes de sécurité et les autorisations d'objet sont liées entre elles et qu'un objet hérite des droits d'une classe de sécurité où l'objet représente une instance de :
Dans l'illustration, l'utilisateur 1 fait partie du profil de sécurité A, l'utilisateur 2 fait partie du profil de sécurité A et est également le propriétaire des objets, représentés par une ACE. Les utilisateurs 1 et 2 disposent de ACE spécifiques, par exemple VR par le biais du profil de sécurité A. L'utilisateur 2 dispose d'une ACE supplémentaire, par exemple VCRWD en tant que propriétaire d'un objet.
Pour vérifier les droits d'accès des utilisateurs 1 et 2 sur un objet, le système de sécurité crée une union (logique) entre l'ACE de l'utilisateur et celle associée à l'objet sécurisé spécifique. Dans l'exemple, les utilisateurs 1 et 2 ont tous les deux des droits d'affichage et de lecture, mais seul l'utilisateur 2 dispose des droits d'écriture et de suppression.
Chapitre 11: Fonctionnalités de sécurité Client Automation 427
Autorisation
Niveaux de sécurité
Selon la manière dont les autorisations d'objet sont dérivées, il existe différents types de niveaux de sécurité pour l'objet :
Sécurité de niveau de classe
L'autorisation d'objet est dérivée de l'autorisation au niveau de la classe (à partir de la classe à laquelle appartient l'objet) et le niveau de sécurité est défini sur le niveau de la classe. Il s'agit de la valeur par défaut en cas de création d'un objet sécurisé.
Sécurité de niveau de groupe
Lorsqu'un objet sécurisé appartient à un groupe de sécurité où l'héritage est activé, le niveau de sécurité est défini sur le niveau du groupe. Les autorisations sont dérivées du groupe duquel fait partie l'objet (autorisation au niveau du groupe).
Sécurité de niveau d'objet
Lorsque l'utilisateur définit manuellement l'autorisation d'objet pour un objet sécurisé spécifique, le niveau de sécurité est défini sur le niveau de l'objet (en effet, les autorisations sont définies individuellement pour l'objet).
Héritage d'autorisation d'un groupe
Si un objet est membre d'un groupe, le sous-système de sécurité dans Client
Automation prend en charge l'héritage dynamique des autorisations à partir d'un groupe vers un membre, comme suit :
■
Un indicateur marque un groupe pour un héritage dynamique.
■
Tous les membres de ce groupe héritent des autorisations de membre spécifiées.
■
Si un membre est ajouté à un groupe, il hérite automatiquement des autorisations du groupe.
La conception de la sécurité du groupe est basée sur les décisions suivantes :
■
L'héritage de la sécurité peut être activé ou désactivé pour un groupe. Lorsqu'il est activé, le groupe devient un groupe de sécurité (l'application peut utiliser une icône différente pour la visualisation).
■
Le groupe possède alors deux masques d'autorisation, un pour le groupe même
(comme tout autre objet sécurisé) et le masque d'héritage.
■
Lorsqu'un groupe hérite d'un groupe parent, les deux masques sont modifiés en fonction du masque d'héritage du groupe parent.
■
■
■
Le masque d'autorisation d'un membre d'un ou de plusieurs groupes est évalué en fonction de l'union de l'ensemble des autorisations des parents du membre, etc.
(les autorisations sont reliées par le connecteur OR).
L'héritage s'effectue depuis un parent vers un enfant, ce qui peut donner lieu à une mise à jour récursive des objets.
Il n'existe aucune restriction à la profondeur d'héritage.
428 Manuel d'implémentation
Autorisation
■
■
Concernant l'ordre de priorité, les autorisations d'objet sont prioritaires par rapport
à celle de groupe, qui sont prioritaires sur les autorisations de classes.
Si un objet est membre d'un groupe de sécurité au moins, l'unique modification autorisée sur cet objet consiste à appliquer une sécurité d'objet, car l'application d'une sécurité de classe romprait le modèle. Afin que la sécurité de classe devienne active, l'objet doit être supprimé du groupe ou l'héritage de la sécurité doit être désactivée sur le groupe.
Remarque : L'héritage d'un groupe est désactivé si le niveau de sécurité d'un objet est défini sur le niveau de l'objet.
L'illustration suivante indique l'héritage lorsqu'un objet est membre d'un groupe et que ce groupe permet l'héritage des autorisations d'objet :
Le groupe g1.1 est un sous-groupe du groupe g1. Les ordinateurs john et smith sont membres du groupe g1.1.
L'héritage des autorisations est désactivé pour le groupe g1, mais il est activé pour le groupe g1.1. Les ordinateurs john et smith héritent des autorisations du groupe g1.1.
Chapitre 11: Fonctionnalités de sécurité Client Automation 429
Autorisation
Autorisations pour une zone
Le concept de zone de sécurité étend le modèle de sécurité. Une zone de sécurité constitue une fonctionnalité facultative qui convient aux implémentations importantes avec des milliers d'objets gérés par différents utilisateurs.
Une zone de sécurité constitue une division géographique, organisationnelle ou topologique. La définition de zones de sécurité est utile si vous souhaitez restreindre l'accès des utilisateurs uniquement aux objets liés à leur zone de sécurité. Dans le concept des zones de sécurité, des utilisateurs, représentés par des profils de sécurité, et des objets sont liés à des zones de sécurité. Une zone de sécurité peut être liée à un ou plusieurs profils et à un ou plusieurs objets. Un utilisateur peut accéder à un objet si l'une des zones de sécurité au moins liée à l'objet l'est également au moins à un profil de sécurité de l'utilisateur. Si l'accès à l'objet est refusé, l'objet n'est pas visible pour l'utilisateur.
430 Manuel d'implémentation
Autorisation
Exemple : Deux zones de sécurité et trois utilisateurs
Trois profils utilisateurs (HRMgrProfile, SrMgrProfile et DevMgrProfile, avec tous les droits d'accès) ont été assignés à trois utilisateurs (HRManager, SeniorManager et
DevManager). Deux zones de sécurité ont été définies, HumanResources et
Development. Les profils HRMgrProfile et SrMgrProfile sont reliés à la zone de sécurité
HumanResources. Les profils SrMgrProfile et DevMgrProfile sont reliés à la zone de sécurité Development. Puis SeniorManager, représenté par le profil SrMgrProfile, a accès aux deux zones, HumanResources et Development. HRManager dispose uniquement des droits d'accès à la zone de sécurité HumanResources et DevManager uniquement à la zone Development. Par exemple, si HRManager crée une requête sur sa console dans la zone HumanResources, DevManager ne la voit pas. Seuls les objets créés par le système sont visibles pour tous les profils utilisateur.
La définition des autorisations de zone permet de limiter les droits d'accès sur un objet particulier d'un ou de plusieurs profils. Cela signifie que même les autorisations au niveau de la classe définies pour un profil sont identiques. Vous pouvez affecter ou lier un objet à différentes zones ou restreindre l'accès pour des profils, afin d'afficher uniquement les objets liés à une zone spécifique.
En plus des autorisations d'objet, qui sont gérées par les classes de sécurité, le soussystème de sécurité permet de créer jusqu'à 32 zones.
Chapitre 11: Fonctionnalités de sécurité Client Automation 431
Autorisation
L'illustration suivante fournit un aperçu de la prise en charge de zone du sous-système de sécurité.
Les utilisateurs 1 et 2 font partie du profil de sécurité A. Dans la définition de la zone reliée au profil A, sont indiquées les zones visibles par les utilisateurs faisant partie du profil A.
L'utilisateur 2 a créé un objet visible par tous les utilisateurs reliés à la zone concernée.
Pour les cas d'utilisation importante et les descriptions des opérations effectuées par la
prise en charge de zone dans ces cas d'utilisation, reportez-vous à la section Cas d'utilisation de prise en charge des zones de sécurité (page 589).
432 Manuel d'implémentation
Autorisation
Conditions préalables à l'accès aux objets dans les différentes zones
Les conditions suivantes doivent être remplies avant l'évaluation de l'autorisation de zone de l'utilisateur :
■
L'utilisateur doit disposer d'un accès à l'objet (affichage ou lecture).
■
La prise en charge des zones de sécurité sur le gestionnaire de domaines doit être activée.
■
Tous les profils de sécurité dont l'utilisateur est membre doivent être activés pour la prise en charge des zones de sécurité.
Si la première condition n'est pas remplie, l'accès à l'objet est refusé à l'utilisateur, quelles que soient la deuxième et la troisième conditions. Si la deuxième ou la troisième condition n'est pas remplie, l'utilisateur n'est pas restreint en fonction des autorisations de zone et peut accéder à tous les objets.
Remarques :
■
Tous les objets sont accessibles aux utilisateurs membres de profils de sécurité dont la zone de sécurité est désactivée. Nous recommandons à l'administrateur de s'assurer que tous les profils de sécurité soient activés pour la prise en charge des zones de sécurité.
■
La prise en charge des zones de sécurité n'est pas disponible sur les gestionnaires d'entreprise DSM.
■
Le profil Distributions constitue l'unique profil intégré pouvant être activé pour la prise en charge des zones de sécurité. Tous les autres profils intégrés sont désactivés pour la prise en charge des zones de sécurité.
■
Les objets qui appartiennent aux classes de sécurité "Procédure" ou "Job logiciel" ne peuvent pas être liés à une zone de sécurité dans l'explorateur DSM. Ils sont automatiquement liés aux zones auxquelles sont liés leurs conteneurs parents
(Package logiciel et Conteneur de jobs logiciels).
Autorisations dérivées pour une zone
Les autorisations concernant une zone peuvent être définies ou dérivées de plusieurs manières :
Autorisation de zone du profil de sécurité
Si l'utilisateur de création est valide lors de la création d'un objet sécurisé, alors les autorisations de zone sont dérivées de l'utilisateur ayant créé l'objet.
(niveau de sécurité : Utilisateur de création)
Autorisation de zone d'un groupe
Ce cas s'applique uniquement lorsque l'objet sécurisé est membre d'un groupe et que l'héritage est activé.
(niveau de sécurité : Groupe)
Chapitre 11: Fonctionnalités de sécurité Client Automation 433
