Meilleures pratiques pour l’utilisation des autorisations affinées dans SharePoint Server

Article
03/08/2023

S’APPLIQUE À : oui-img-13 2013 oui-img-16 2016 oui-img-19 2019 oui-img-se Édition d’abonnement no-img-sop SharePoint dans Microsoft 365

Les autorisations affinées peuvent influencer la sécurité sur une batterie SharePoint. Des problèmes potentiels de performances peuvent se produire lorsque vous utilisez des autorisations affinées. Les informations suivantes vous aident à résoudre les problèmes rencontrés par un environnement en raison de l'utilisation ou la montée en puissance incorrecte des autorisations affinées.

Vous pouvez éviter les autorisations affinées en procédant comme suit :

Rompez l'héritage des autorisations le moins souvent possible.
Utilisez des groupes basés sur l'appartenance aux dossiers pour attribuer des autorisations.
En raison d'une modification dans les fonctions d'analyse continue de recherche SharePoint Server, qui incluent désormais des informations de sécurité, nous ne vous recommandons plus d'éviter d'utiliser les groupes SharePoint pour gérer les appartenances d'utilisateur et de groupe dynamiques. Avant SharePoint Server, l'utilisation des appartenances dynamiques dans les groupes SharePoint pouvait provoquer l'affichage incorrect des résultats de recherche pour certains membres jusqu'à ce qu'une analyse complète soit effectuée après le changement d'appartenance. Maintenant, avec la fonction d'analyse continue, y compris les informations de sécurité, toute modification d'appartenance dynamique ou autre modification de sécurité sera détectée plus tôt (valeur par défaut de 15 minutes) et utilisée par le filtrage des résultats de la requête de recherche.
Attribuez des autorisations au niveau le plus élevé possible. Dans le cadre de cette stratégie, envisagez les techniques suivantes :
- Placez les documents qui nécessitent des autorisations affinées dans les bibliothèques de documents définies pour prendre en charge chaque groupe d'autorisations. Conservez les bibliothèques de documents dans une collection de sites distincte ou un site distinct.
- Utilisez des niveaux de publication de document différents pour contrôler l'accès. Avant qu'un document soit publié, les autorisations avancées et les paramètres de contrôle de version peuvent être définis pour les utilisateurs qui peuvent uniquement approuver des éléments dans la bibliothèque de documents.
- Pour les bibliothèques hors documents (listes), utilisez les niveaux d'autorisation ReadSecurity et WriteSecurity. Quand une liste est créée, les propriétaires peuvent définir les autorisations au niveau de l'élément sur Accès en lecture ou Accès en création et modification.

Avant de commencer

Avant de commencer cette opération, lisez les informations suivantes sur les éléments prérequis :

Meilleures pratiques pour éviter les problèmes de limite communs associés aux autorisations affinées

Si votre entreprise doit utiliser des autorisations affinées, tenez compte des meilleures pratiques recommandées suivantes :

Veillez à ne pas avoir trop d’éléments au même niveau de hiérarchie dans les bibliothèques de documents, car le temps nécessaire au traitement des éléments dans les affichages augmente.
Utilisez des gestionnaires d'événements pour contrôler l'autorisation de modification. Vous pouvez posséder un gestionnaire d'événements qui enregistre un événement à l'aide des méthodes SPEventReceiverType.ItemUpdating et SPEventReceiverType.ItemUpdated, puis utiliser le code pour contrôler l'autorisation de mise à jour. Cette fonction est très puissante, car vous pouvez prendre des décisions en matière de sécurité basées sur les métadonnées d'une liste ou d'un élément sans affecter les performances d'affichage de vue.
Utilisez la méthode AddToCurrentScopeOnly pour affecter l'appartenance Accès limité dans un groupe SharePoint. L’élément clé de ce principe consiste à reconcevoir l’architecture afin que l’appartenance à l’étendue n’entraîne pas de recalcul de liste de contrôle d’accès (ACL) au niveau de la bibliothèque de documents parente et du web. Pour plus d'informations sur les modifications d'étendue , voir Problème 3 : Utiliser des autorisations affinées pour les changements de structure d'étendue (2010 uniquement).

Lorsque vous utilisez des autorisations affinées, il est facile de rencontrer involontairement des limites qui empêchent la résolution des autorisations. Cette section décrit certaines de ces limites et les meilleures pratiques sur leur définition pour permettre la résolution correcte des autorisations.

Trop d’étendues dans une liste

Il existe une limite intégrée de 50 000 étendues par liste ou bibliothèque de documents. Une fois que les 50 000 étendues sont atteintes, l'ajout de nouvelles étendues dans une liste ou bibliothèque de documents donnée est interdit.

Meilleures pratiques :

Définissez des étendues uniques seulement sur des objets parents tels que les dossiers.
Ne créez pas de système avec de nombreux objets avec autorisation unique sous un objet qui a de nombreuses étendues.
Si votre entreprise a besoin de plus de 50 000 éléments à autorisation unique dans une liste ou une bibliothèque de documents, vous devez déplacer certains éléments dans une autre liste ou bibliothèque de documents.

Modifier la limite d’étendue intégrée

Modifiez la limite d'étendue intégrée à l'aide d'un script Microsoft PowerShell.

Pour modifier la limite d'étendue intégrée à l'aide de Windows PowerShell

Vérifiez que vous êtes membre :

du rôle serveur fixe securityadmin sur l'instance SQL Server.
du rôle de base de données fixe db_owner sur toutes les bases de données à mettre à jour ;
Groupe Administrateurs sur le serveur sur lequel vous exécutez les applets de commande PowerShell.
Ajoutez les appartenances qui sont nécessaires au-delà des minima décrits ci-dessus.

Un administrateur peut utiliser l'applet de commande Add-SPShellAdmin pour accorder des autorisations d'utilisation des applets de commande SharePoint Server 2016.

Notes

[!REMARQUE] Si vous ne disposez pas des autorisations, contactez votre administrateur d'installation ou votre administrateur SQL Server afin de les demander. Pour plus d’informations sur les autorisations PowerShell, consultez Add-SPShellAdmin.

Démarrez SharePoint Management Shell.
À partir de l’invite de commandes PowerShell, entrez la commande suivante :
```
$webapp = Get-SPWebApplication http://<serverName>
$webapp.MaxUniquePermScopesPerList
$webapp.MaxUniquePermScopesPerList = <Number of scope limit>
```
Où :
- Où <serverName> est le nom du serveur d’applications dans la batterie de serveurs SharePoint.
- Où <Nombre de limites> d’étendue correspond au nombre maximal d’étendues d’autorisations uniques que vous souhaitez autoriser par liste SharePoint. Souvent, la limite effective est bien inférieure à 50 000 si de nombreuses étendues existent au même niveau hiérarchique. Cela est dû au fait que les contrôles d'affichage pour les éléments en dessous de ce niveau hiérarchique doivent être appliqués par rapport à toutes les étendues au-dessus. Cette limitation peut provoquer le passage du nombre effectif d'étendues autorisées dans une requête particulière à 1 000 ou 2 000.

Notes

[!REMARQUE] Nous vous recommandons d'utiliser Windows PowerShell pour les tâches d'administration en ligne de commande. L’outil en ligne de commande Stsadm a été abandonné, mais il est inclus pour assurer la compatibilité avec les versions précédentes.

Trop de membres dans une étendue d’autorisation

Comme décrit précédemment, une liste de contrôle d’accès binaire est calculée lorsque l’appartenance à l’étendue d’autorisation associée change. Cela inclut l’ajout d’un nouveau membre à accès limité. À mesure que le nombre d’appartenances à l’étendue augmente, le temps nécessaire pour recalculer la liste de contrôle d’accès binaire augmente.

Le problème peut être aggravé car l'ajout d'utilisateurs à l'étendue unique d'un objet enfant va provoquer la mise à jour de ses étendues parent avec les nouveaux membres à accès limité, même si cela n'entraîne finalement aucun changement sur l'appartenance d'étendue parent. Lorsque cela se produit, la liste de contrôle d'accès binaire pour les étendues parent doit également être recalculée, au détriment du temps de traitement, même si cela aboutit à la même liste de contrôle d'accès.

Meilleure pratique :

Basez-vous sur l'appartenance de groupe plutôt que sur l'appartenance de chaque utilisateur dans les étendues d'autorisation. Par exemple, si un seul groupe peut être utilisé au lieu de 1 000 utilisateurs individuels, l'étendue sera allégée de 999 entrées d'appartenance pour l'étendue d'autorisation et ses étendues parent. De plus, le groupe unique sera mis à jour avec des droits à accès limité plutôt que de mettre à jour chaque utilisateur qui dispose de droits d'accès limité. Cela contribue également à augmenter la vitesse de transmission des droits d'accès limité et le recalcul de liste de contrôle d'accès sur les objets d'étendue parent.

Importante

L'utilisation d'un groupe SharePoint provoquera une analyse complète de l'index. Si possible, utilisez un groupe de domaine.

Hiérarchie d’étendue très profonde

Comme indiqué précédemment, la profondeur hiérarchique des étendues d’autorisation peut affecter le travail nécessaire pour ajouter des utilisateurs à accès limité aux étendues parent. Plus le nombre d'étendues uniques au-dessus d'un élément augmente, jusqu'au site web à autorisation unique inclus, plus le nombre d'ajouts à effectuer augmente. Si une hiérarchie d'étendue est très profonde, un changement d'appartenance d'étendue peut prendre beaucoup de temps, car chaque changement d'appartenance dans l'élément d'étendue le plus profond devra mettre à jour de manière itérative les étendues parent avec un ajout d'appartenance pour l'utilisateur ou le groupe explicitement ajouté qui possède des droits d'accès limités. De plus, cela va augmenter le nombre de listes de contrôle d'accès binaires à recalculer, avec un impact correspondant sur les performances.