Environnements multi-équipes

Les environnements multi-équipes permettent aux organisations de modéliser des configurations de sécurité de plus en plus complexes dans Blue Prism® en étendant les contrôles d'accès basés sur les rôles existants pour permettre des configurations plus granulaires. Ces capacités permettent aux organisations de partager les actifs Blue Prism, par exemple les objets métier et les ressources d'exécution, avec plusieurs équipes dans un environnement Blue Prism donné en permettant d'attribuer des permissions non seulement en fonction du type de ressource, mais également en fonction de la structure hiérarchique des ressources.

Par exemple, les utilisateurs membres d'une équipe peuvent avoir un accès complet à certains objets métier, mais peuvent seulement avoir la capacité d'en afficher ou d'en exécuter d'autres, selon ce qui est approprié pour les actifs partagés par plusieurs équipes.

Les environnements multi-équipes permettent à Blue Prism de prendre en charge des structures organisationnelles diverses et complexes afin que plusieurs équipes puissent travailler indépendamment tout en partageant les ressources appropriées dans un même environnement.

La liste ci-dessous indique les zones dans lesquelles les environnements multi-équipes sont efficaces dans le client Blue Prism :

  • Accueil : les données affichées sur la page d'accueil ne sont pas filtrées par les droits d'accès appliqués aux groupes.
  • Studio : les utilisateurs disposant des permissions appropriées y gèrent les droits d'accès pour les groupes de processus et les groupes d'objets.
  • Contrôle : les utilisateurs bénéficient d'un affichage personnalisé de la salle de contrôle afin que seuls les processus et les ressources correspondant à leur rôle soient visibles et interactifs. Cela ne comprend pas la zone de gestion de la file d'attente. Les utilisateurs ayant accès à cette zone peuvent consulter les informations relatives aux files d'attente conventionnelles dans l'environnement.
  • Pour les files d'attente actives, les utilisateurs ne voient qu'une file d'attente s'ils disposent de la permission d'exécution sur le processus qui traite la file d'attente et la permission de contrôle sur toutes les ressources cibles pour cette file d'attente.
  • Outil d'analyse : les données affichées dans les dalles du tableau de bord ne sont pas filtrées par les droits d'accès appliqués aux groupes.
  • Versions : seuls les éléments auxquels les permissions d'un utilisateur permettent d'accéder peuvent être inclus dans une version ou un ensemble logiciel.
  • Système : les zones suivantes du gestionnaire de système ont été mises à jour pour les environnements multi-équipes :
    • Ressources : les utilisateurs disposant des permissions appropriées y gèrent les droits d'accès pour les groupes de ressources d'exécution.
    • Audit (logs de session) : les logs de processus et les logs d'objets sont soumis aux permissions de l'utilisateur connecté. Ils peuvent uniquement voir les logs pour les éléments autorisés par leur rôle. Les logs d'audit ne sont pas filtrés par les droits d'accès appliqués aux groupes.

Les opérations Trouver les références, Afficher et Comparer sont également mises à jour pour ne renvoyer que les objets auxquels l'utilisateur a accès.

Sécurisé sur base de l'appartenance à un groupe hiérarchique

Si les permissions au niveau du groupe ne sont pas définies, les utilisateurs disposant des permissions pour un type d'élément particulier, comme les processus, bénéficient des mêmes permissions pour chaque élément du même type dans le système.

En limitant les permissions à un groupe de processus, d'objets ou de ressources, les permissions définies par les rôles d'utilisateur peuvent être configurées pour accorder les droits d'accès requis aux éléments du groupe.

Les permissions appliquées au niveau du groupe ne peuvent pas accorder aux utilisateurs des droits d'accès dépassant le maximum autorisé par leur rôle. Par exemple, si un rôle permet à un utilisateur de modifier des processus, cette permission peut être supprimée pour un groupe. Si le rôle n'autorise pas un utilisateur à supprimer des processus, cette permission ne peut pas être accordée pour ce rôle au niveau du groupe.