SharePoint: Héritage des autorisations

Le modèle de sécurité de SharePoint est basé sur la notion d’héritage. A chaque fois qu’un nouvel objet est créé, il hérite par défaut des autorisations de son parent.

Par exemple, un nouveau site dans une collection de site hérite par défaut des autorisations du site parent. Un sous-site d’un site hérite par défaut des autorisations du site parent. De même, si vous créez une nouvelle bibliothèque dans un site, elle héritera par défaut des autorisations du site.

Un héritage par défaut à tous niveaux

L’héritage est proposé par défaut. Toutefois, à la création d’un objet, vous pouvez demander des autorisations uniques pour que l’objet n’hérite pas des autorisations de son parent.

L’héritage fonctionne en cascade. Les autorisations données sur un site s’appliquent aux sites enfants et aux objets qu’ils contiennent (bibliothèques, listes), ainsi qu’aux enfants des sites enfants, etc. Autrement dit, chaque enfant hérite de son parent, qui hérite lui-même de son parent, etc.

Tant que l’héritage n’est pas rompu, il maintient un lien dynamique avec les autorisations de l’objet du parent. Ce qui signifie que toute modification d’une autorisation du site parent, par exemple, est automatiquement appliquée à tous les objets enfants qui héritent des autorisations.

Si vous voulez modifier des autorisations existants d’un objet enfant, ci celui-ci hérite des autorisations de l’objet parent, il suffit de rompre l’héritage. Lorsque que l’héritage est rompu, les autorisations de l’objet parent sont recopiés sur l’objet enfant sans lien dynamique et les autorisations de l’objet enfant deviennent modifiables.

Un héritage rompu peut être rétabli à chaque instant. Dans ce cas, tous les autorisations existants de l’objet enfant sont perdus.

Différences avec les ACL de NTFS

Ce modèle ressemble à celui mis en oeuvre par Microsoft avec le système de fichiers NTFS (New Technology File System) de Windows. Cependant, il s’en écarte sur de nombreux aspects.

En particulier, dans le modèle de sécurité de SharePoint, il n’est pas possible de rajouter une autorisation lorsque les autorisations sont héritées du parent. Il faut impérativement rompre l’héritage. Au contraire, dans NTFS, il est possible de rajouter une ACE (Access Control Entries) à une ACL (Access Control List) héritée.

Rapidité dans les cas simples

Le principal avantage de ce modèle d’héritage est sa simplicité et sa rapidité, car aucune configuration particulière de sécurité n’est nécessaire. C’est sa force dans les implémentations de SharePoint où la sécurité n’est pas une grande préoccupation.

Les changements à appliquer sont centralisés. Par exemple, vous modifiez les autorisations d’une collection de sites et ils s’appliquent automatiquement à tous les sites enfant.

Ce modèle de sécurité n’est pas toujours maîtrisé par les administrateurs. Les audits de sécurité révèlent deux écueils principaux: trop de droits et pas assez de droits.

Difficultés réelles aussi

Certains administrateurs n’ont pas toujours à l’esprit les conséquences de certaines décisions qui semblent anodines. Cela peut conduire à des situations où certaines informations sensibles enregistrées sur SharePoint peuvent être compromises par inadvertance.

C’est par exemple le cas, lorsque des autorisations de lecture ont été accordées au niveau le plus élevé à un groupe trop large d’utilisateurs.

A l’inverse une politique trop restrictive, ou mal pensée, peut exclure à tort certaines catégories d’utilisateurs (par exemple, les utilisateurs de l’organisation qui se trouvent dans les filiales).

Pour diverses raisons, ils ne voudront pas ou ils ne pourront pas se manifester et ils créeront de toutes pièces un gisement de données « pirate », qui échappera à l’administration générale.

Outils d’administration de la sécurité

A la décharge des administrateurs, il faut reconnaître qu’il n’était pas évident de connaître les autorisations accordées sur un objet d’un simple coup. Toutefois, la situation s’est améliorée avec SharePoint 2013.

Globalement, il y a un manque d’outils natifs pour les administrateurs pour planifier et maintenir les autorisations SharePoint.

Sans qu’il s’agisse d’une recommandation (!), j’ai apprécié des outils de sociétés commerciales comme ceux de Varonis qui permettent d’avoir des rapports d’une grande clarté sur les autorisations accordées.

Pour mémoire, AvePoint qui est un acteur historique de SharePoint propose aussi des outils de gouvernance. Toutefois, je n’ai pas trouvé l’équivalent de Varonis.

Avec une approche différente, TITUS propose une solution intéressante avec l’utilisation de métadonnées pour gérer la sécurité.

Enfin pour les adeptes de l’huile de coude, il y a toujours les scripts gratuits de Gary Lapointe: cmdlets PowerShell et commandes STSADM. Ils permettent de construire une solution complète et évolutive d’analyse de la configuration de sécurité. Cela m’a été utile pour construire un kit personnalisé d’audit de sécurité SharePoint.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *