Partager via

Planifier la gestion de la sécurité et des utilisateurs des flux de travail (SharePoint Foundation 2010)

  • Article

 

S’applique à : SharePoint Foundation 2010

Dernière rubrique modifiée : 2011-03-09

Avant de déployer des flux de travail dans Microsoft SharePoint Foundation 2010 pour des utilisateurs, les administrateurs peuvent avoir des craintes concernant les problèmes de sécurité, tels que la divulgation d’informations ou l’élévation de privilège. Cet article souligne certains aspects du comportement des flux de travail relatifs à la sécurité et présente d’autres problèmes que les administrateurs et les développeurs de flux de travail doivent considérer lorsqu’ils prévoient de configurer et de développer des flux de travail.

Dans cet article :

Rôles et responsabilités des gestionnaires de listes, des administrateurs et des développeurs

Voici quelques actions de flux de travail courantes et les responsabilités associées, qui expliquent le rôle des administrateurs et des développeurs dans l’exécution des flux de travail.

Développeurs de flux de travail

Développer la planification et le modèle des flux de travail   Les développeurs de flux de travail sont responsables de la codage de l’assembly contenant la logique métier qui s’exécute sur un élément SharePoint. Cet assembly est appelé planification de flux de travail. Ils sont également responsables du conditionnement en package des formulaires et de l’assembly du flux de travail en fonctionnalité de flux de travail ou en modèle de flux de travail.

Administrateurs de site

Gérer les paramètres des flux de travail de l’administration centrale   Les administrateurs de site peuvent contrôler les paramètres généraux des flux de travail, tels que les résultats des alertes de tâche et les paramètres des participants externes sur le site Web d’administration centrale de SharePoint.

Déployer des fonctionnalités de flux de travail   Les administrateurs de site peuvent installer des fonctionnalités de flux de travail sur une collection de sites de façon à les rendre disponibles pour des associations.

Administrateurs de liste (toute personne disposant des autorisations Gérer les listes ou Concepteur Web)

Ajouter des flux de travail   Les administrateurs de liste doivent associer (ajouter) un modèle de flux de travail à un type de liste ou de contenu, en fonction des besoins métiers du type de liste ou de contenu. Cette association rend le modèle de flux de travail disponible pour les utilisateurs, qui peuvent alors sélectionner des valeurs par défaut et des paramètres.

Supprimer des flux de travail   Les administrateurs de liste peuvent supprimer des associations de flux de travail d’un type de liste ou de contenu, ou empêcher l’exécution de nouvelles instances.

Mettre fin à un flux de travail   Si une instance de flux de travail échoue, les administrateurs de liste peuvent arrêter une instance de flux de travail en cours d’exécution, par exemple quand une instance de flux de travail produit une erreur ou ne démarre pas, à l’aide du lien Interrompre ce flux de travail sur la page État du flux de travail. Cette action est réservée aux administrateurs.

Exécution de flux de travail en tant qu’administrateur

Le concept de sécurité le plus important à connaître est que les flux de travail s’exécutent dans le cadre du compte système dans SharePoint Foundation 2010, via les paramètres de pool d’applications d’identité sur l’ordinateur et le domaine du serveur. Cela signifie que dans SharePoint Foundation 2010, les flux de travail ont des autorisations d’administrateur. Sur le serveur, les flux de travail ont les mêmes autorisations que le pool d’applications, qui a souvent des autorisations d’administrateur. Ces autorisations permettent aux flux de travail d’effectuer des actions que les utilisateurs ordinaires ne peuvent pas réaliser, telles que le routage d’un document vers un emplacement ou un centre des enregistrements spécifique, ou encore l’ajout d’un compte d’utilisateur au système.

Le fait que les flux de travail ont des autorisations d’administrateur ne peut pas être changé. C’est la responsabilité de la planification du flux de travail (c’est-à-dire le code du flux de travail) de détecter les actions des utilisateurs et, en fonction de ces actions, de continuer ou d’annuler les modifications, ou d’emprunter l’identité d’un utilisateur de façon à imiter les autorisations de cet utilisateur.

Lorsqu’ils déploient des flux de travail, les administrateurs doivent comprendre les actions qui seront effectuées par ces flux de travail, de façon à pouvoir évaluer les risques potentiels associés à l’élévation d’autorisation dans un flux de travail et à aider le développeur à réduire les risques de sécurité.

Paramètres de configuration des flux de travail

Certains paramètres de configuration de SharePoint Foundation 2010 doivent être définis par les administrateurs en fonction de leurs besoins en matière de sécurité.

Autorisations requises pour démarrer un flux de travail

En plus d’empêcher l’élévation des autorisations dans le code, les administrateurs de liste peuvent limiter le niveau d’autorisation requis pour démarrer un flux de travail lors du processus d’association. Les administrateurs peuvent choisir entre deux niveaux d’autorisation pour démarrer une association de flux de travail spécifique : Modifier l’élément ou Gérer les listes.

Le paramètre par défaut pour l’association d’un flux de travail est de permettre aux utilisateurs ayant les autorisations Modifier l’élément de démarrer manuellement un flux de travail. Cela signifie que tout utilisateur SharePoint Foundation 2010 authentifié sur la liste qui a des autorisations Modifier l’élément peut démarrer une instance de cette association de flux de travail. Si, lors de la création du flux de travail, l’administrateur choisit l’option de requérir que l’utilisateur dispose des autorisations Gérer les listes pour pouvoir démarrer le flux de travail, seuls les administrateurs de liste peuvent démarrer une instance de cette association.

Les flux de travail étant conçus pour être utilisés par des contributeurs standard, la plupart des flux de travail ne nécessitent pas la limitation à des autorisations Gérer les listes. Cependant, les administrateurs peuvent utiliser cette option pour des flux de travail tels qu’un flux de travail de suppression de documents, où l’administrateur veut que seules certaines personnes exécutent les actions de suppression.

Paramètres de l’administration centrale

Les paramètres suivants sont accessibles à partir de la page Administration centrale en cliquant sur Gestion des applications, puis en cliquant sur Gérer les applications Web dans la section Applications Web. Dans la page Applications Web, sélectionnez l’application Web à configurer, puis, dans le groupe GestionGérer du Ruban, cliquez sur Paramètres généraux et sélectionnez Flux de travail. La page Paramètres du flux de travail s’ouvre et affiche les paramètres suivants :

  • Flux de travail définis par l’utilisateur

  • Notifications des tâches du flux de travail

Activation des flux de travail définis par l’utilisateur

Par défaut, les flux de travail définis par l’utilisateur sont activés pour tous les sites sur l’application Web, comme l’indique la section Flux de travail définis par l’utilisateur de la page Paramètres du flux de travail. Lorsque cette option est sélectionnée, les utilisateurs peuvent définir des flux de travail dans un éditeur de flux de travail tel que l’éditeur de flux de travail de SharePoint Designer 2010. Les utilisateurs qui définissent ces flux de travail doivent avoir les autorisations Gérer les listes pour le site sur lequel ils déploient le flux de travail.

Notification de tâche pour les utilisateurs sans accès au site

Sur la page Paramètres du flux de travail, dans la section Notifications des tâches du flux de travail, vous pouvez définir des options pour l’envoi de notifications à propos des tâches de flux de travail en attente aux utilisateurs qui n’ont pas accès au site.

-
Utilisateurs internes

Dans SharePoint Foundation 2010, il est possible de résoudre les noms des utilisateurs internes du service d’annuaire qui ne sont pas membres du site ou qui n’ont pas accès à cette tâche. Dans ce cas, un administrateur peut sélectionner l’option **Voulez-vous que les utilisateurs internes sans accès au site reçoivent une alerte lorsqu’une tâche du flux de travail leur est attribuée ?** dans la section **Notifications des tâches du flux de travail** pour spécifier si ces utilisateurs reçoivent une notification par courrier électronique. Cette option signifie que les utilisateurs sont alertés lorsqu’une tâche de flux de travail leur est affectée. Cette option est activée par défaut, et le message électronique reçu par les utilisateurs contient un lien sur lequel ils peuvent cliquer pour demander à accéder au site (les administrateurs doivent néanmoins leur accorder ce droit d’accès). Ce message peut également contenir des informations sur le document. Ces informations peuvent comprendre le titre du document et des instructions provenant du propriétaire du flux de travail. S’il existe des problèmes de divulgation d’informations liés à des utilisateurs internes qui ne sont pas membres du site, les administrateurs peuvent désactiver l’option **Voulez-vous que les utilisateurs internes sans accès au site reçoivent une alerte lorsqu’une tâche du flux de travail leur est attribuée ?**.

  • Utilisateurs externes

    Les utilisateurs externes qui ne sont pas dans le service d’annuaire, mais auxquels une adresse de messagerie SMTP correctement formée est attribuée peuvent néanmoins se voir affecter des tâches de flux de travail. Comme les utilisateurs externes accéderont difficilement au document, SharePoint Foundation 2010 comporte un paramètre, Voulez-vous autoriser les utilisateurs externes à participer au flux de travail en leur envoyant une copie de ce document ?, qui rend possible l’envoi par courrier électronique d’une notification de tâche aux utilisateurs externes, avec le document en pièce jointe. Lorsque cette option est activée, la tâche est attribuée au propriétaire du flux de travail, et l’utilisateur externe peut achever la réalisation de la tâche en envoyant un courrier électronique au propriétaire.

    Par défaut, l’option Voulez-vous autoriser les utilisateurs externes à participer au flux de travail en leur envoyant une copie de ce document ? est désactivée. Ce paramètre peut cependant être utile dans des situations qui nécessitent une participation externe, telle que l’approbation de documents commerciaux impliquant des clients externes. Les administrateurs qui activent ce paramètre (en sélectionnant Oui) doivent vérifier que la planification du flux de travail prend en charge ce paramètre relatif aux participants externes. Par exemple, lorsqu’une tâche est créée pour un utilisateur externe, le flux de travail personnalisé doit spécifier une adresse de messagerie dans la propriété OnBehalfEmail de l’objet SPWorkflowTaskProperties qui a été utilisé pour initialiser la tâche. Plusieurs flux de travail intégrés dans SharePoint Foundation 2010 prennent en charge ce paramètre.

    Les développeurs de flux de travail personnalisés qui veulent activer cette fonctionnalité doivent consulter les administrateurs pour déterminer s’il existe des risques de divulgation d’informations liés à l’envoi du document réel en pièce jointe d’un message électronique externe. Les administrateurs doivent évaluer les avantages et les risques lors de l’activation de ce paramètre.

Divulgation d’informations dans les historiques de tâches et de flux de travail

Les tâches et les éléments d’historique pouvant contenir des données sur les utilisateurs et les actions qu’ils effectuent sur des documents, les éléments sont susceptibles de divulguer des informations confidentielles. Par exemple, un flux de travail Approbation pour une promotion peut contenir des commentaires sur ces tâches, dont l’organisation veut que seuls le propriétaire du flux de travail et chaque participant de la tâche puisse les voir.

Les listes de tâches et les historiques sont des listes courantes dans un site. Par défaut, tous les lecteurs peuvent donc voir les éléments des tâches et des historiques. Les administrateurs et les développeurs doivent déterminer les informations qui ne peuvent pas être divulguées et décider s’il faut sécuriser les éléments des tâches et des historiques qui sont créés par le flux de travail.

La sécurisation de ces éléments peut être effectuée de plusieurs façons. Par exemple, les administrateurs peuvent définir des autorisations au niveau des listes. Si la divulgation doit être privée, c’est-à-dire non publique mais disponible pour un groupe de personnes spécifique, les administrateurs peuvent créer une nouvelle tâche ou un nouvel historique, et définir des autorisations pour la liste spécifiques à ce groupe. Si les administrateurs veulent que personne ne voie les événements des historiques sur une page d’état du flux de travail, ils peuvent supprimer les autorisations d’affichage de l’historique du flux de travail duquel une page d’état extrait ses informations. Les utilisateurs qui n’ont pas les autorisations pour afficher l’historique lui-même ou un élément de cet historique reçoivent une erreur d’accès refusé lorsqu’ils ouvrent une page d’état qui extrait des données de cet historique.

Si des restrictions plus fines sont requises, les développeurs de flux de travail peuvent définir des autorisations au niveau des éléments lorsqu’ils créent des tâches ou des éléments d’historique. L’activité CreateTask a une propriété SpecialPermissions qui ne donne que des autorisations spécifiées pour accéder à la tâche nouvellement créée. L’activité LogToHistoryList n’a pas de propriété semblable : pour définir des autorisations au niveau des éléments sur des éléments d’historique, les administrateurs doivent utiliser le modèle objet de SharePoint Foundation 2010. Les autorisations au niveau des éléments peuvent affecter négativement les performances et ne doivent être utilisées que lorsqu’elles sont nécessaires.

Les tâches et les éléments d’historique ne doivent pas être gérés de la même manière. Les administrateurs peuvent combiner et faire correspondre des autorisations au niveau des listes et des autorisations au niveau des éléments.

Attaques d’usurpation d’identité et de falsification dans les historiques des tâches et des flux de travail

Tout contributeur peut modifier des tâches ou des éléments d’historique s’il n’existe pas de restrictions sur ces listes. Cela signifie que des utilisateurs malveillants peuvent modifier des descriptions de tâche pour donner aux participants des instructions incorrectes ou pour leur demander de cliquer sur des liens malveillants. Pour modifier les résultats perçus d’un processus, des utilisateurs malveillants peuvent aussi ajouter des événements d’historique faux ou incorrects, ou ils peuvent modifier des événements d’historique existants pour les rendre faux ou incorrects.

Comme expliqué plus haut, les listes de tâches et les historiques sont des listes normales dans un site. Par défaut, il n’y a pas de restrictions d’autorisation sur les listes de tâches ou les historiques. Pour éviter les attaques d’usurpation d’identité et de falsification, les administrateurs doivent déterminer les vulnérabilités qui existent et choisir entre limiter l’accès aux colonnes d’une liste (par exemple, mettre en lecture seule les colonnes vulnérables, telles que les descriptions des tâches, de sorte que seul le flux de travail puisse les définir lors de la création de l’élément), définir des autorisations spéciales sur la liste ou définir des autorisations au niveau des éléments d’une liste.

Problèmes de sécurité dans l’historique des flux de travail

Un avantage important des flux de travail est la possibilité de faire le suivi des informations des processus, de façon à offrir une visibilité dans les processus. L’historique du flux de travail est un référentiel pour ces informations, où une page d’état de flux de travail peut rechercher des données relatives à une instance de flux de travail et peut rendre ces informations disponibles pour les utilisateurs. Les utilisateurs peuvent voir tous les éléments auxquels ils ont accès dans l’historique.

Cependant, l’historique de flux de travail effectuant un suivi des informations, les utilisateurs peuvent supposer qu’il peut être utilisé en tant que piste d’audit pour les événements. Ce n’est pas le cas : l’historique de flux de travail n’est pas une fonctionnalité de sécurité. Les historiques sont des listes SharePoint standard utilisées pour stocker des événements qui sont visibles par tous les utilisateurs et auxquelles aucune autorisation spéciale n’est associée. Par défaut, les utilisateurs peuvent modifier et ajouter des événements s’ils ont des autorisations de modification et d’ajout sur le site. Pour auditer les événements, utilisez la fonctionnalité Journal d’audit de SharePoint. Seuls les administrateurs peuvent accéder à ce journal, qui ne requiert pas de travail supplémentaire pour être protégé des attaques de falsification.

Pour mieux protéger l’historique, les administrateurs peuvent limiter les autorisations de modification et d’ajout à la liste, de sorte que seuls les administrateurs du compte système (par exemple des administrateurs de flux de travail) et des administrateurs de liste puissent ajouter des éléments. Les administrateurs de liste doivent avoir des autorisations d’ajout pour consigner des événements « Interrompre ce flux de travail ». Si les autorisations de modification et d’ajout sont limitées sur l’historique, les utilisateurs doivent recevoir des autorisations d’affichage pour pouvoir afficher les informations d’état.

Type Étape d’emprunt d’identité d’utilisateur pour les flux de travail déclaratifs

Le type Étape d’emprunt d’identité d’utilisateur peut être utilisé pour exécuter des sections de flux de travail déclaratifs par la personne qui a créé le flux de travail plutôt que par l’initiateur du flux de travail. Déclaratif signifie un modèle que vous utilisez pour créer le flux de travail et définir les paramètres pour le flux de travail sans écrire de code.

Dans SharePoint Foundation 2010, les flux de travail déclaratifs s’exécutent toujours dans le contexte utilisateur de l’initiateur du flux de travail, sauf si une étape d’emprunt d’identité est rencontrée. Dans ce cas, le flux de travail déclaratif est exécuté dans le contexte de l’associateur du flux de travail. Les tâches de flux de travail par défaut respectent les autorisations SharePoint en empruntant l’identité de l’utilisateur qui a démarré un flux de travail lorsque le flux de travail est exécuté. Cette implémentation permet de conserver un bon niveau de sécurité dans SharePoint Foundation 2010, mais bloque certains scénarios où un concepteur de flux de travail avec des autorisations élevées veut créer un flux de travail puissant qui peut être effectué avec succès par des utilisateurs qui ont des autorisations d’un niveau moins élevé.

Grâce une forme sécurisée et étendue d’élévation de privilège, les actions de site peuvent être automatisées à travers le flux de travail. Ceci réduit la charge d’un administrateur de site SharePoint. L’automatisation d’un processus de haute sécurité est utile dans les scénarios de publication et d’approbation dans lesquels des actions existantes sont autorisées à emprunter l’identité de quelqu’un d’autre que l’initiateur du flux de travail.

Voici des exemples de scénarios qui montrent le type Étape d’emprunt d’identité d’utilisateur :

  • Publier vers une liste sécurisée

    Jacqueline a verrouillé la bibliothèque de documents Pages pour la partie publique de son site SharePoint. Elle a configuré un flux de travail Approbation qui, en utilisant Microsoft SharePoint Designer 2010, envoie pour approbation du contenu provenant de contributeurs du site. Jacqueline place les actions de son flux de travail dans une étape d’emprunt d’identité pour que ces actions empruntent toujours sa propre identité (administrateur du site) en tant qu’auteur du flux de travail.

    Lorsque Corine (une contributrice) envoie le brouillon d’un contenu dans la bibliothèque de documents Pages du site et tente de publier son article, cette action provoque le démarrage du flux de travail Approbation de Jacqueline, qui permet la relecture et l’approbation de l’envoi. Les tâches sont envoyées aux approbateurs du flux de travail pour le compte de Corine. Après relecture et approbation par les approbateurs, le système donne la valeur « Approuvé » à l’état de modération de l’envoi, même si Corine n’a pas l’autorisation d’approuver des pages.

  • Accorder des autorisations à des utilisateurs

    Joëlle a configuré un flux de travail dans SharePoint Designer 2010, qui utilise une action d’emprunt d’identité d’utilisateur « Ajouter un utilisateur au groupe » pour accorder des autorisations de conception pour son site. Le flux de travail utilisant une possibilité d’emprunt d’identité, l’action d’ajout d’un utilisateur au groupe sera toujours effectuée pour le compte de Joëlle.

    Le reste du flux de travail permet aux contributeurs de visiter le site et de remplir un formulaire pour enregistrer leur demande d’accès à une liste.

    Par exemple, un utilisateur distinct, Olivier, reçoit une tâche lorsque Corine, une utilisatrice, enregistre une demande et, lorsqu’il approuve la tâche, Corine est ajoutée au groupe Concepteur pour le site, même si ni Olivier ni Corine n’ont les autorisations Gérer les listes sur le site de Joëlle.

  • Modèles et acquisition de propriété

    William a créé plusieurs flux de travail dans SharePoint Designer 2010 et les a enregistrés en tant que modèles pour qu’ils puissent être réutilisés dans toute la société, mais il quitte peu après la société. Son compte est supprimé, son statut d’administrateur est révoqué et maintenant, l’exécution des flux de travail SharePoint Designer 2010 que William a créés échoue en raison de la perte des autorisations de William.

    Un administrateur du site SharePoint parent, Jean, peut intervenir pour chaque flux de travail, sans avoir à recréer les flux de travail dans SharePoint Designer 2010. Jean prend la propriété des éléments relevant de l’administration dans chaque modèle concerné. Après cela, la publication sécurisée et l’attribution des autorisations d’accès se font sous le nom de Jean au lieu de celui de William ; rien d’autre n’a changé.

Voici des actions de flux de travail qui peuvent faire l’objet d’emprunts d’identité :

  • Définir le statut d’approbation du contenu (en tant que propriétaire)

  • Créer un élément dans la liste (en tant que propriétaire)

  • Mettre à jour l’élément de la liste (en tant que propriétaire)

  • Supprimer les éléments d’une liste (en tant que propriétaire)

  • Ajouter/supprimer/définir/hériter des autorisations pour un élément d’une liste (en tant que propriétaire)

En tant qu’administrateur SharePoint, vous devez considérer les effets possibles sur la sécurité de l’incorporation de l’emprunt d’identité dans des flux de travail sur le site SharePoint. Ceci s’applique non seulement aux nouvelles actions mais aussi aux actions existantes, telles que la mise à jour des éléments d’une liste.

Par exemple, considérez un modèle dans lequel des actions d’emprunt d’identité d’utilisateur du flux de travail peuvent encore s’exécuter en tant qu’initiateur. Si un utilisateur a des autorisations d’administrateur sur un seul des sites de la collection de sites, cet utilisateur, s’il était malveillant, pourrait créer un flux de travail pour obtenir des droits sur le site Web parent du site. Tout ce qu’il aurait à faire serait de persuader l’administrateur de charger un fichier dans une bibliothèque de documents sur le site de l’utilisateur malveillant pour commencer une attaque du flux de travail et compromettre tout le site Web parent du site.

Ce risque a incité à développer la restriction selon laquelle « les actions d’emprunt d’identité d’utilisateur empruntent toujours l’identité de leur associateur » dans SharePoint Designer 2010. L’associateur est la personne qui associe un flux de travail à une liste ou un site Web particulier. Dans les flux de travail déclaratifs de SharePoint Foundation 2010, l’associateur est la même personne que l’auteur du flux de travail, c’est-à-dire l’utilisateur qui a créé le flux de travail dans SharePoint Designer 2010. Cependant, l’associateur peut aussi être quelqu’un qui associe un modèle de flux de travail déclaratif. Le problème est maintenant que l’auteur/associateur est forcé d’accepter la responsabilité pour tout ce qui peut se produire à cause d’un type Étape d’emprunt d’identité d’utilisateur, car les informations d’identification de l’auteur/associateur seront utilisées dans l’élévation. Ceci requiert que les auteurs/associateurs comprennent les flux de travail qu’ils conçoivent ou qu’ils associent. Lors de la création d’un flux de travail, SharePoint Designer 2010 affiche donc, sur la page de création du flux de travail, un message de mise en garde destiné à l’auteur/associateur à propos du type Étape d’emprunt d’identité d’utilisateur.