Sécurité administrative à granularité fine
Dans les éditions WebSphere Application Server antérieures à la version 6.1, les utilisateurs auxquels ont été accordés des rôles d'administration peuvent administrer toutes les ressource contenues dans la cellule. WebSphere Application Server est maintenant configuré de manière plus fine, ce qui signifie qu'un accès par ressource peut être octroyé à chaque utilisateur.
Pour que la sécurité fondée sur les instances ou la sécurité à granularité fine soient mises en oeuvre, les ressources qui nécessitent les mêmes privilèges sont placées dans un groupe appelé groupe d'autorisations d'administration ou groupe d'autorisations. Il est possible d'octroyer aux utilisateurs l'accès au groupe d'autorisations en leur affectant le rôle d'administration requis.
La sécurité administrative à granularité fine peut également être utilisée dans des environnements de serveur unique. Plusieurs applications installées sur le serveur peuvent être regroupées et placées dans des groupes d'autorisation différents. Il existe donc des contraintes d'autorisation différentes pour des applications différentes. Sachez que le serveur lui-même ne peut pas faire partie d'un groupe d'autorisations dans un environnement à un seul serveur.
Vous pouvez octroyer le rôle adminsecuritymanager à des utilisateurs et à des groupes au niveau de la cellule au moyen de wsadmin et de la console d'administration. Le rôle adminsecuritymanager vous permet d'octroyer des rôles d'administration à des utilisateurs et à des groupes.
Lorsqu'une sécurité à granularité fine est appliquée, les utilisateurs auxquels le rôle d'adminsecuritymanager a été octroyé peuvent gérer des groupes d'autorisation. Pour obtenir une description détaillée de tous les rôles d'administration, voir Rôles d'administration et autorisation du service de nommage.
Un administrateur ne peut pas octroyer de rôles d'administration incluant le rôle adminsecuritymanager à des utilisateurs ou à des groupes. Voir Rôles d'administration pour plus de détails.
- Créer un groupe d'autorisations :
$AdminTask createAuthorizationGroup {-authorizationGroupName authGroup1}
- Suppression d'un groupe d'autorisations :
$AdminTask deleteAuthorizationGroup {-authorizationGroupName groupName}
- Ajout de ressources à un groupe d'autorisations :
$AdminTask addResourceToAuthorizationGroup {-authorizationGroupName groupName -resourceName Application=app1}
- Suppression de ressources d'un groupe d'autorisation :
$AdminTask removeResourceFromAuthorizationGroup {-authorizationGroupName groupName -resourceName Application=app1}
- Ajout d'ID utilisateur aux rôles dans un groupe d'autorisation :
$AdminTask mapUsersToAdminRole {-authorizationGroupName groupName -roleName administrator -userids user1}
- Ajout d'ID de groupe aux rôles dans un groupe d'autorisation :
$AdminTask mapGroupsToAdminRole {-authorizationGroupName groupName -roleName administrator -groupids group1}
- Suppression d'ID utilisateur des rôles dans un groupe d'autorisation :
AdminTask removeUsersFromAdminRole {-authorizationGroupName groupName -roleName administrator -userids user1}
- Suppression d'ID de groupe des rôles dans un groupe d'autorisation :
$AdminTask removeGroupsFromAdminRole {-authorizationGroupName groupName -roleName administrator -groupids group1}
Ressources pouvant être ajoutées à un groupe d'autorisation
- Cell
- Noeud
- Cluster de serveurs
- Serveur
- Application
- Groupe de noeuds
Si une ressource n'est pas d'un type précédemment répertorié, sa ressource parent est utilisée.
Une ressource ne peut appartenir qu'à un seul groupe d'autorisation. Toutefois, il existe une relation de confinement entre les ressources. Si une ressource parent appartient à un groupe d'autorisation différent de celui de sa ressource enfant, cette dernière appartient implicitement à plusieurs groupes d'autorisation. Vous ne pouvez pas ajouter une même ressource à plusieurs groupes d'autorisation.
Le diagramme suivant décrit la relation de confinement entre les ressources :
- Le groupe d'autorisation de la ressource administrative. Si un droit d'accès à un groupe d'autorisation est octroyé à un utilisateur, toutes les ressources contenues dans ce groupe sont incluses.
- La relation de confinement de la ressource. Si un droit d'accès à une ressource parent est octroyé à un utilisateur, toutes les ressources enfant sont incluses.
La gestion des fichiers de clés demande un utilisateur doté de privilèges administratifs de niveau cellule car ces fichiers sont créés au niveau des cellules. L'accès sécurisé modulé à une ressource spécifique ne donne pas accès à la gestion des fichiers de clés associés.
Ressource | Action | Rôles requis |
---|---|---|
Serveur | Démarrage, arrêt, opérations d'exécution | Opérateur de serveur, opérateur de noeud, opérateur de cellule |
Serveur | Nouveau, supprimer | Configurateur de noeud, configurateur de cellule |
Serveur | Modifier la configuration | Configurateur de serveur, configurateur de noeud, configurateur de cellule |
Serveur | Afficher la configuration, statut d'exécution | Moniteur de serveur, moniteur de noeud, moniteur de cellule |
Noeud | Redémarrer, arrêter, sync | Opérateur de noeud, opérateur de cellule |
Noeud | Ajouter, supprimer | Configurateur-cellule |
Noeud | Modifier la configuration | Configurateur de noeud, configurateur de cellule |
Noeud | Afficher la configuration, statut d'exécution | Moniteur de noeud, moniteur de cellule |
Cluster | Démarrage, arrêt, opérations d'exécution | Opérateur de cluster, opérateur de cellule |
Cluster | Nouveau, supprimer | Configurateur-cellule |
Cluster | Modifier la configuration | Configurateur de cluster, configurateur de cellule |
Cluster | Afficher la configuration, statut d'exécution | Moniteur de cluster, moniteur de cellule |
Membre de cluster | Démarrage, arrêt, opérations d'exécution | Opérateur de serveur, opérateur de cluster, opérateur de noeud, opérateur de cellule |
Membre de cluster | Nouveau, supprimer | Configurateur de noeud, configurateur de cellule |
Membre de cluster | Modifier la configuration | Configurateur de serveur, configurateur de cluster, configurateur de noeud, configurateur de cellule |
Membre de cluster | Afficher la configuration, statut d'exécution | Moniteur de serveur, moniteur de cluster, moniteur de noeud, moniteur de cellule |
Application | Toutes les opérations | Voir la section "Rôles de déployeur" dans Rôles d'administration. |
Noeud, cluster | Ajouter, supprimer | Configurateur-cellule |
Le rôle opérateur de serveur est le rôle opérateur du groupe d'autorisation dont fait partie l'instance de serveur. De même, le rôle opérateur de noeud est le rôle opérateur du groupe d'autorisation dont fait partie l'instance de noeud.
Pour utiliser la sécurité administrative à granularité fine dans la console d'administration, un utilisateur doit au minimum avoir un rôle moniteur au niveau des cellules. Toutefois, pour se connecter à l'aide de wsadmin, un utilisateur doit avoir un rôle de moniteur pour n'importe quel groupe d'autorisation.
Exemple : Utilisation de la sécurité à granularité fine.
Les scénarios suivants décrivent l'emploi de la sécurité administrative précise, en particulier le nouveau rôle de déploiement.
Scénario de rôle de déploiement 1.Dans le scénario suivant, quatre applications sont configurées sur le serveur S1, comme illustré dans le tableau suivant. Chaque application doit être isolée de sorte que l'administrateur de l'une d'entre elles ne puisse pas en modifier une autre. Supposons que seul l'utilisateur 1 peut gérer l'application A1, l'utilisateur 2 peut gérer les applications A2 et A3 et seul l'utilisateur 3 peut gérer l'application A4.
Un ASP (Application Service Provider) en est un exemple, dans lequel un serveur d'applications unique peut avoir plusieurs applications fournisseur. Dans cet exemple, l'administrateur du serveur est responsable de l'installation de toutes les applications fournisseur. Une fois les applications installées, chaque fournisseur peut gérer sa propre application sans interférer avec les applications d'autres fournisseurs.
Application | Serveur | Noeud |
---|---|---|
A1 | S1 | N1 |
A2 | S1 | N1 |
A3 | S1 | N1 |
A4 | S1 | N1 |
Nous pouvons configurer des groupes d'autorisation comme illustré dans le schéma suivant :

Dans le schéma, l'application A1 se trouve dans le groupe d'autorisation G1, les applications A2 et A3 sont dans le groupe d'autorisation G2 et l'application A4 est dans le groupe d'autorisation G3.
Un rôle de déployeur est attribué du groupe d'autorisation G1 à l'utilisateur 1, du groupe d'utilisation G2 à l'utilisateur 2 et du groupe d'autorisation G3 à l'utilisateur 3.
En conséquence, l'utilisateur 1 peut effectuer toutes les opérations sur l'application A1, l'utilisateur 2 sur les applications A2 et A3 et l'utilisateur 3 sur l'application A4. Toutes les applications partageant le même serveur, nous ne pouvons pas mettre le même serveur dans tous les groupes d'autorisation. Seul un administrateur au niveau de la cellule peut installer une application. Au terme de l'installation d'une application, le déployeur de chaque application peut modifier sa propre application. Pour démarrer et arrêter le serveur, une autorisation administrative au niveau de la cellule est requise. Ce type de scénarios est utile dans un environnement ASP.
Scénario de rôle de déploiement 2.Dans le scénario suivant, un groupe d'applications requiert les mêmes rôles administratifs sur un même serveur. Dans cet exemple, les applications A1 et A2 sont des applications connexes qui peuvent être administrées par un ensemble d'administrateurs. Elles s'exécutent sur le même serveur (S1). Les applications A3 et A4 nécessitent un ensemble d'administrateurs différent et s'exécutent respectivement sur les serveurs S2 et S3.
Application | Serveur | Noeud |
---|---|---|
A1 | S1 | N1 |
A2 | S1 | N1 |
A3 | S2 | N2 |
A4 | S3 | N3 |

Chaque développeur doit être en mesure de modifier la configuration de son serveur et pouvoir installer son application sur ce serveur. Il doit aussi être en mesure de démarrer et d'arrêter le serveur ainsi que l'application qui s'y trouve.
Les développeurs doivent aussi pouvoir configurer le serveur de façon à déboguer les problèmes qu'ils y rencontrent. Ils doivent pouvoir mettre à jour ou modifier l'application en cours de développement. Le groupe d'autorisations d'administration de ce développeur comprend au moins un serveur et les applications que le développeur installer sur ce serveur.

Dans l'exemple suivant, les développeurs du groupe d'autorisations G1 ont une nouvelle application (A11). Ils ne peuvent installer et cibler cette nouvelle application que sur les serveurs du groupe d'autorisations G1. Ils peuvent aussi placer cette nouvelle application dans leur groupe d'autorisations (G1).

Dans ce scénario, le client est un ASP. Il a ses propres clients à qui il fournit une fonction de serveur d'applications. Il veut activer ses clients pour administrer et surveiller leurs applications, mais ne pas voir ni administrer les applications d'autres clients. Dans cet exemple, toutefois, l'ASP a un groupe d'administrateur interne dont le travail consiste à maintenir les serveurs.
Ce groupe d'administrateurs ASP interne peut vouloir déplacer une application d'un serveur à un autre pour s'assurer qu'elle demeure disponible. Le groupe d'administrateurs ASP interne doit pouvoir arrêter et démarrer les serveurs et modifier leur configuration.
En revanche, l'administrateur client ASP ne doit pas pouvoir arrêter ou démarrer des serveurs. Toutefois, l'administrateur client ASP doit être en mesure de mettre à jour ses applications exécutées sur ces serveurs. Le groupe d'autorisations d'administration de l'administrateur ASP interne peut être la cellule entière ou peut inclure un sous-ensemble de serveurs, noeuds, clusters et applications. Le groupe d'autorisations d'administration de l'administrateur client ne comprend que les applications que le client a payées pour être servies par cet ASP.
Lors de la mise à jour du référentiel de configuration, exécutez les scripts d'administration depuis le gestionnaire de déploiement de sorte que les règles de sécurité d'administration à granularité fine soient en vigueur à ce moment-là.
Le schéma suivant contient un scénario dans lequel deux clients différents ont deux types d'applications différents et peuvent les gérer. Cependant, les serveurs et noeuds sur lesquels les applications sont exécutées, sont isolés de leurs clients. Les serveurs et noeuds ne peuvent être maintenus que par les administrateurs internes. En outre, les clients ne peuvent pas cibler leurs applications sur un serveur différent. Cela ne peut être réalisé que par l'administrateur interne ou les déployeurs internes.

Dans ce scénario, le client est une grande société mondiale. Les noeuds et serveurs de la société sont organisés de sorte à servir des applications vers différentes régions (ou encore vers différentes lignes d'activités). La société souhaite que les représentants des différentes zones régionales soient en mesure de surveiller et d'administrer les noeuds et serveurs associés à la région. Cependant, elle ne veut pas que l'administrateur régional soit en mesure d'affecter des noeuds et serveurs associés à une région différente.
Le groupe d'autorisation d'administration de chaque représentant régional comprend les noeuds, serveurs, clusters et applications associés à cette région.
Par exemple, supposons une société qui fournit des services multiples, comme un établissement financier qui assure des services tels que des comptes de carte de crédit, des comptes de courtage, des comptes bancaires ou des comptes voyages. Chacun de ces services peut être des applications distinctes et l'administrateur de chacune de ces applications doit aussi être différent. La figure suivante indique une méthode de configuration d'un tel système :

La figure suivante montre comment grouper les ressources d'un tel système afin d'isoler les administrateurs les uns des autres :

Observez que les noeuds ne font pas partie d'un groupe d'autorisations. Par conséquent, un administrateur d'applications commerciales ne peut arrêter un serveur sur aucun des noeuds ni arrêter une application de voyage.
Le même système peut être configuré d'une autre façon comme illustré ci-dessous :

La figure suivante montre comment grouper les ressources d'un tel système afin d'isoler les administrateurs les uns des autres :
