Pratiques recommandées pour l’utilisation des autorisations affinées
Ce document est fourni en l’état. Les informations et les vues contenues dans ce document, y compris les URL et autres références de site Web Internet, sont susceptibles d’être modifiées sans préavis. Vous les utilisez à vos risques.
Les exemples fournis ici le sont à titre d’illustration uniquement et sont fictifs. Aucune association ou connexion réelle n’est voulue ni suggérée.
Ce document ne vous confère aucun droit sur la propriété intellectuelle inhérente à quelque produit Microsoft que ce soit. Vous pouvez copier ou utiliser ce document pour vos propres besoins de référence internes.
© 2010 Microsoft Corporation. Tous droits réservés.
Pratiques recommandées pour l’utilisation des autorisations affinées
Auteur : Sean Livingston, responsable produit - Groupe de produits SharePoint
Publication : Septembre 2010
Résumé : Ce document décrit les pratiques recommandées relatives aux autorisations affinées et explique comment les utiliser au sein de votre organisation avec les produits et technologies SharePoint® ou les produits Microsoft® SharePoint® 2010.
Sommaire Sommaire 2 Présentation de l’utilisation des autorisations affinées 2 Présentation du système des autorisations SharePoint 3 Niveaux d’autorisation 4 Groupes SharePoint 4 Étendue 4 Objet sécurisable 4 Héritage 5 Accès limité 5 Liste de contrôle d’accès binaire 7 Pratiques recommandées pour éviter les problèmes courants de limitation des autorisations affinées 7 Trop grand nombre d’étendues au sein d’une liste 7 Trop grand nombre de membres au sein d’une étendue 8 Hiérarchie d’étendues très profonde 9 Solutions recommandées pour les problèmes courants de performances liés aux autorisations affinées 9 Solution 1 : Supprimer les autorisations affinées et utiliser la mise en œuvre de la sécurité uniquement au niveau Web 10 Nettoyage de la sécurité environnementale 10 Nouvelle conception de l’architecture de la sécurité environnementale 11 Solution 2 : Utiliser des autorisations affinées par modification de structure hiérarchique 12 Nouvelle conception de la hiérarchie de l’environnement 12 Solution 3 : Utiliser des autorisations affinées par modification de structure d’étendue (2010 uniquement) 13 Nouvelle conception du code modifiant la sécurité de façon dynamique 13 Exemple d’architecture de l’environnement 15 Présentation de l’environnement 15 Conception des flux de travail 16 Problèmes liés aux autorisations affinées 16 Résolution des problèmes liés aux autorisations affinées 18 Résumé 20 Présentation de l’utilisation des autorisations affinées
Cet article décrit l’utilisation des autorisations affinées avec les produits SharePoint® 2010 (Microsoft® SharePoint® Server 2010 et Microsoft® SharePoint® Foundation 2010) et les produits et technologies SharePoint® (Office SharePoint® Server 2007 et Windows SharePoint® Services version 3.0), ainsi que les problèmes de performances liés aux autorisations affinées. Il recommande les pratiques à adopter pour configurer des solutions mettant en œuvre des autorisations affinées.
Remarque : Les autorisations affinées ne sont recommandées que dans les solutions métiers où elles sont indispensables. En effet, ces autorisations peuvent s’avérer coûteuses aussi bien en matière de supervision opérationnelle que sur le plan des performances.
Vous pouvez éviter le recours aux autorisations affinées en procédant de la manière suivante :
Évitez de rompre l’héritage des autorisations autant que possible.
Utilisez des groupes basés sur l’appartenance d’annuaire pour attribuer les autorisations.
Remarque : Il est déconseillé d’utiliser un groupe SharePoint pour attribuer des autorisations à des sites, car cela provoque une analyse complète de l’index. Il est recommandé d’utiliser des groupes de domaine à la place.
Attribuez les autorisations au niveau le plus haut possible. Dans le cadre de cette stratégie, considérez les techniques suivantes :
Séparez les documents qui requièrent des autorisations affinées dans des bibliothèques de documents définies pour prendre en charge chaque groupe d’autorisations et conservez ces bibliothèques dans une collection de sites ou un site séparé. Pour des informations supplémentaires sur les modifications hiérarchiques, voir Solution 2 : Utiliser les autorisations affinées par modification de structure hiérarchique.
Remarque : Dans ce document, les termes Web et site correspondent à l’objet SPWeb, et collection de sites correspond à l’objet SPSite.
Utilisez des niveaux de publication de documents différents pour contrôler l’accès. Avant de publier un document, des paramètres avancés d’autorisations et de contrôle des versions peuvent être définis pour les utilisateurs censés seulement approuver des éléments dans la bibliothèque de documents.
Pour les autres bibliothèques autres que documents (listes), utilisez les niveaux d’autorisation ReadSecurity et WriteSecurity. Quand une liste est créée, les propriétaires peuvent définir des autorisations au niveau de l’élément soit pour un accès en lecture soit pour un accès en création et modification.
Si vous devez utiliser des autorisations affinées, envisagez les pratiques recommandées suivantes :
Assurez-vous que le nombre d’éléments au même niveau hiérarchique dans les bibliothèques de documents ne soit pas trop élevé, car le temps nécessaire pour traiter les éléments dans les vues en dépend.
Utilisez des gestionnaires d’événements pour contrôler l’autorisation de modification. Vous pouvez avoir un gestionnaire d’événements qui enregistre un événement à l’aide des méthodes SPEventReceiverType.ItemUpdating et SPEventReceiverType.ItemUpdated, et utiliser du code pour contrôler si la mise à jour est autorisée. Cela est extrêmement efficace, car vous pouvez baser sur des métadonnées de liste ou d’élément une décision en matière de sécurité, sans affecter les performances d’affichage de la vue. Pour des informations supplémentaires sur les gestionnaires d’événements, voir Résolution des problèmes liés aux autorisations affinées.
Utilisez la méthode AddToCurrentScopeOnly pour attribuer l’appartenance Accès limité dans un groupe SharePoint. Le fondement de ce principe est de réagencer l’architecture de sorte que l’appartenance d’étendue ne cause pas le recalcul de la liste de contrôle d’accès sur la bibliothèque de documents et sur l’objet Web parents. Pour des informations supplémentaires sur les modifications d’étendue, voir Solution 3 : Utiliser des autorisations affinées par modification de structure d’étendue (2010 uniquement).
|
