Sécurité du gestionnaire de travaux

Dans un environnement de gestion souple, un ID utilisateur doit disposer des autorisations requises pour utiliser le gestionnaire de travaux et les noeuds enregistrés.

Rôles de sécurité requis

Les rôles suivants sont nécessaires pour utiliser le gestionnaire de travaux :

Tableau 1. Rôles de sécurité requis pour les tâches de gestionnaire de travaux. Ces rôles sont administrateur, opérateur, configurateur et surveillant.
Tâches d'administration Rôles de sécurité requis
Enregistrer ou annuler l'enregistrement auprès du gestionnaire de travaux administrateur
Soumettre un travail opérateur
Modifier la configuration du gestionnaire de travaux configurateur
Lire la configuration ou l'historique des travaux du gestionnaire de travaux contrôler

Si les noeuds de serveur d'applications de base (autonome) gérés par un agent d'administration sont enregistrés auprès d'un gestionnaire de travaux, les rôles suivants sont requis pour utiliser l'agent d'administration et gérer ses noeuds :

Tableau 2. Rôles de sécurité requis pour les tâches de l'agent d'administration. Les rôles incluent celui d'administrateur et les rôles nécessaires à l'opération ou au noeud.
Tâches d'administration Rôles de sécurité requis
Enregistrer ou annuler l'enregistrement d'un noeud (autonome) de base auprès de l'agent d'administration administrateur
Utiliser l'agent d'administration : Rôles d'administration requis pour l'opération en cours d'exécution
Utiliser le sous-système d'administration, par exemple les noeuds enregistrés Rôles administratifs requis pour le noeud de base enregistré

Lorsqu'un travail s'exécute sur une cible, l'utilisateur doit disposer des privilèges contenant le rôle requis pour ce travail. Par exemple, un travail consistant à créer un serveur d'applications requiert au minimum le rôle de configurateur sur le noeud de base ou sur la cellule WebSphere Application Server, Network Deployment.

Sécurité des travaux d'Installation Manager ou de Liberty sur des hôtes distants

Lorsqu'un nom d'utilisateur et un mot de passe sont requis pour l'accès à un hôte distant comme Installation Manager ou un Liberty, vous devez fournir un nom d'utilisateur et un mot de passe de système d'exploitation valides pour qu'un travail s'exécute sur l'hôte distant. Vous pouvez fournir les types d'autorisation suivants :

Nom d'utilisateur et mot de passe du système d'exploitation
Le nom d'utilisateur et le mot de passe sont les valeurs de connexion de l'hôte. Si l'hôte ne requiert pas de mot de passe, il n'est pas nécessaire de fournir un mot de passe lors de la soumission d'un travail.
Sudo
Si vous voulez qu'un autre utilisateur exécute des commandes sur l'hôte, vous pouvez utiliser sudo pour changer d'utilisateur avant l'exécution d'un travail et spécifier ensuite le nom d'utilisateur et le mot de passe de l'autre utilisateur. sudo signifie "exécuter en se substituant à l'utilisateur". Si l'hôte ne requiert pas de mot de passe, il n'est pas nécessaire de fournir un mot de passe lors de la soumission d'un travail.
Authentification par clé publique-privée
Vous pouvez utiliser l'authentification par clé publique-privée. Lors de la soumission d'un travail, vous spécifiez le chemin d'accès complet au fichier de clés et, si ce dernier l'exige, la phrase passe. Une clé privée SSH (Secure Shell) permet à un administrateur d'exécuter un travail sur l'hôte distant sous un nom d'utilisateur spécifique. La clé est chiffrée par mot de passe afin qu'elle ne soit pas utilisée par un utilisateur différent.

For Liberty servers, the type of authorization that you use depends upon the user names that are configured for each host:

Nom d'utilisateur unique
Si chaque hôte utilise un seul nom d'utilisateur, vérifiez uniquement que les répertoires dans lesquels les ressources du Liberty doivent être installées sont inscriptibles par l'utilisateur. Pour prendre en charge la soumission de travaux à des hôtes différents, vérifiez que le même nom d'utilisateur est configuré sur chaque hôte ou utilisez une clé SSH pour vous authentifier sous un nom d'utilisateur différent pour chaque hôte.
Passage à un nom d'utilisateur unique
Si les hôtes prennent en charge plusieurs noms d'utilisateur, vous pouvez soumettre les travaux sous des noms d'utilisateur différents, mais utilisez sudo pour passer à un nom d'utilisateur commun unique. Seul le nom d'utilisateur commun peut gérer des ressources du Liberty. Ce nom d'utilisateur est souvent configuré pour désactiver la connexion.
Noms d'utilisateur différents
Dans certaines configurations, vous pouvez installer chaque ressource du Liberty sous un nom d'utilisateur de système d'exploitation différent. Par exemple, les ressources partagées peuvent être installées sous un ou plusieurs noms d'utilisateur et mises à disposition en lecture seule au niveau global ou pour un groupe de systèmes d'exploitation spécifique. Des ressources de travail non partagées peuvent être créées exclusivement pour des noms d'utilisateur différents.

Vous pouvez contrôler qui peut installer les ressources du Liberty en contrôlant les droits d'accès aux fichiers du répertoire racine pour chaque ressource. Si vous définissez le répertoire comme étant inscriptible par un seul utilisateur, seul ce dernier peut effectuer l'installation dans ce répertoire. Si vous définissez le répertoire comme étant inscriptible par un groupe d'utilisateurs, les utilisateurs appartenant à ce groupe peuvent installer des ressources sous le répertoire racine. Si vous définissez le répertoire comme étant inscriptible au niveau global, tous les utilisateurs peuvent effectuer l'installation dans ce répertoire.

Au cours de l'installation, vous pouvez définir des droits d'accès aux fichiers qui empêchent d'autres utilisateurs de modifier les ressources. Par exemple, vous pouvez précréer ${WLP_WORKING_DIR}/project1 avec des droits d'accès aux fichiers de manière à ce qu'il soit inscriptible par un utilisateur ou un groupe spécifique uniquement. Une fois que l'utilisateur a installé un nouveau Liberty, comme server1, vous pouvez configurer ${WLP_WORKING_DIR}/project1/server1 de manière à ce qu'il ne puisse pas être remplacé par un utilisateur différent.

Lorsque plusieurs utilisateurs peuvent accéder à des ressources, vous devez définir des variables ou des paramètres de travaux qui permettent à un travail d'inventaire de trouver toutes les ressources disponibles :

  • Vous devez définir la variable WLP_ADDITIONAL_DIRS afin que la recherche des ressources s'effectue dans tous les chemins appropriés ; ou
  • Vous devez vous assurer que toutes les ressources sont lisibles par le nom d'utilisateur employé pour exécuter le travail d'inventaire. Les ressources doivent être créées comme étant lisibles au niveau global, les ressources doivent être lisibles au niveau du groupe de systèmes d'exploitation avec le nom d'utilisateur appartenant au groupe, ou le nom d'utilisateur racine doit être utilisé pour exécuter le travail d'inventaire.

Configuration de sécurité de base

L'agent d'administration et le gestionnaire de travaux prennent en charge deux configurations de sécurité de base différentes :

  • Même domaine de sécurité

    Dans cette configuration, toutes les cellules de la topologie partagent le même registre d'utilisateurs et, par conséquent, le même domaine de sécurité. Il en est de même pour l'agent d'administration et ses noeuds de base enregistrés, ainsi que les gestionnaires de travaux ou les cellules WebSphere Application Server, Network Deployment de la topologie.

  • Domaines de sécurité différents

    Dans cette configuration, toutes les cellules sont configurées avec des registres d'utilisateurs différents, et par conséquent, des domaines de sécurité différents.

Pour la topologie de l'agent d'administration, lorsqu'un utilisateur se connecte au port de connecteur JMX d'un sous-système d'administration ou qu'il sélectionne le noeud enregistré dans la console d'administration, la table d'autorisation du noeud sélectionné est utilisée.

Par exemple, supposons qu'Utilisateur1 dispose de droits d'accès en tant qu'administrateur pour le premier noeud de base mais pas pour le second. Utilisateur2 dispose de droits d'accès en tant que configurateur pour le second noeud mais pas pour le premier. La figure Même registre d'utilisateurs illustre cela :

Same security domain configuration

Supposons également qu'Utilisateur1 puisse se connecter au gestionnaire de travaux en tant qu'opérateur avec un nom d'utilisateur et un mot de passe. Utilisateur1 peut également se connecter au gestionnaire de déploiement en tant que surveillant avec un nom d'utilisateur et un mot de passe. La figure Registres d'utilisateurs différents illustre cet exemple :

Configuration de domaine de sécurité différente

Bien qu'Utilisateur1 ait le même nom d'utilisateur sur le gestionnaire de travaux et le gestionnaire de déploiement, il peut aussi avoir des noms d'utilisateur et des mots de passe différents.

Transfert des informations de sécurité

Lorsque le produit transfère un travail depuis le gestionnaire de travaux vers l'agent d'administration, le gestionnaire de déploiement ou le système hôte, il transfère également les informations de sécurité relatives à l'émetteur du travail. Ce transfert authentifie et autorise l'utilisateur tout en exécutant le travail. Les informations de sécurité utilisateur suivantes peuvent être transmises avec un travail soumis :

  • Nom d'utilisateur et mot de passe

    Lors de la soumission d'un travail, l'utilisateur peut indiquer un nom d'utilisateur et un mot de passe. Lorsque le travail atteint le sous-système d'administration ou le gestionnaire de déploiement, le nom d'utilisateur et le mot de passe sont utilisés pour la connexion.

    En ce qui concerne la configuration du même registre d'utilisateurs, si Jean soumet un travail sur le premier noeud de base, il peut spécifier son nom d'utilisateur et son mot de passe dans le cadre du travail. Le nom d'utilisateur et le mot de passe permettent de se connecter au premier sous-système d'administration et le travail est exécuté. Si Jean soumet un travail sur la cellule du gestionnaire de déploiement ou sur le second noeud de base, le travail échoue car Jean ne dispose pas des autorisations requises.

    Dans le cas de la configuration de registres d'utilisateurs différents, Jean peut soumettre un travail sur la cellule de gestionnaire de déploiement en indiquant son nom d'utilisateur et son mot de passe pour la cellule de gestionnaire de déploiement. Lorsque le travail atteint le gestionnaire de déploiement, la connexion aboutit et le travail est exécuté. Si Jean soumet un travail sur les noeuds de base, l'accès est refusé et le travail échoue.

  • Jeton de sécurité

    Si l'utilisateur n'indique pas de nom d'utilisateur et de mot de passe pour un travail, ses données d'identification sont automatiquement conservées en tant que jeton de sécurité dans la base de données des travaux. Le jeton contient les attributs de sécurité de l'utilisateur, y compris les groupes. Lorsqu'un travail est extrait, le jeton permet l'authentification et la validation sur le sous-système d'administration ou le gestionnaire de déploiement.

    En ce qui concerne la configuration du même registre d'utilisateurs, Jean peut soumettre un travail sur le premier noeud de base sans indiquer un nom d'utilisateur et un mot de passe. Le travail s'exécute car les données d'identification de Jean sont automatiquement propagées en tant que jeton de sécurité au sous-système d'administration et utilisées pour l'authentifier et l'autoriser à exécuter le travail. Si Jean soumet un travail sur le second noeud de base ou la cellule de gestionnaire de déploiement, ce travail échoue car son jeton de sécurité n'est pas autorisé dans ces deux environnements.

    Dans le cas de la configuration de registres d'utilisateurs différents, le jeton de sécurité d'un utilisateur n'autorise pas automatiquement le travail soumis à s'exécuter sur le sous-système d'administration ou le gestionnaire de déploiement. Pour activer un jeton utilisateur sur un domaine différent, vous devez utiliser la fonction de domaines de sécurité multiples. Vous devez d'abord établir le domaine du gestionnaire de travaux en tant que domaine sécurisé pour les noeuds de base enregistrés et la cellule de gestionnaire de déploiement. En outre, vous devez importer l'ID d'accès de l'utilisateur du gestionnaire de travaux dans la table des autorisations locales et attribuer un rôle à cet ID. L'utilisateur peut alors soumettre un travail sans entrer de nom d'utilisateur ni de mot de passe.

    Supposons que Jean soit un opérateur sur le gestionnaire de travaux, mais que son ID d'accès soit importé en tant qu'administrateur dans la table des autorisations administratives du premier noeud de base. Bien que Jean n'existe pas dans le registre d'utilisateurs du noeud de base, en transmettant le jeton de sécurité et la définition de la table des autorisations administratives, John est validé en tant qu'administrateur sur le noeud de base. Jean peut soumettre un travail pour le premier noeud de base sans avoir à spécifier de nom d'utilisateur ni de mot de passe.

    Si Jean soumet un travail sur le gestionnaire de déploiement, ce travail échoue. Le jeton de sécurité de Jean provient du domaine du gestionnaire de travaux et son ID d'accès n'a pas été autorisé sur le gestionnaire de déploiement. Dans ce cas, l'administrateur peut exporter l'ID d'accès de Jean du gestionnaire de travaux et l'importer dans le gestionnaire de déploiement. Jean peut aussi soumettre un travail en indiquant le nom d'utilisateur et le mot de passe utilisés pour le gestionnaire de déploiement, ce qui lui permet d'exécuter des travaux avec son rôle de surveillant.

    Il est en de même si la fonction de sécurité à granularité fine est utilisée. Vous devez disposer des autorisations requises dans la table d'autorisations pour un nouveau groupe d'autorisations. Il se peut que la table d'autorisations contienne également un ID d'accès externe.

Configuration de registres mixtes

Dans une topologie plus complexe, où des cellules partagent le même registre d'utilisateurs et d'autres pas, les règles suivantes s'appliquent :

  • Vous pouvez toujours indiquer un nom d'utilisateur et un mot de passe pendant la soumission d'un travail si le noeud cible ou le gestionnaire de déploiement reconnaît votre nom d'utilisateur et votre mot de passe.
  • Si le gestionnaire de travaux et le noeud cible ou le gestionnaire de déploiement ont le même registre d'utilisateurs, la soumission du travail ne nécessite pas de nom d'utilisateur et de mot de passe. Toutefois, vous devez disposer des autorisations nécessaires sur le noeud cible ou le gestionnaire de déploiement.
  • Si le gestionnaire de travaux et le noeud cible ou le gestionnaire de déploiement ont des registres d'utilisateurs différents, si les domaines sécurisés ont été établis et si l'ID d'accès de l'émetteur du travail a été importé dans la table des autorisations administratives du noeud cible ou du gestionnaire de déploiement, la soumission du travail ne nécessite alors pas de nom d'utilisateur et de mot de passe.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cagt_jobmgr_security
Nom du fichier : cagt_jobmgr_security.html