Plan de nommage des groupes de sécurité SharePoint

Dans une organisation, la sécurité des informations stockées dans SharePoint est assurée uniquement à travers les groupes de sécurité SharePoint.

Il est interdit de donner un autorisation en utilisant directement un groupe de l’annuaire central. Par contre, un groupe de l’annuaire central peut appartenir à un groupe de sécurité SharePoint.

L’objectif est de disposer d’un plan de nommage des groupes de sécurité qui soit :

  • structuré de manière identique quelque soit le groupe, l’objet à sécuriser ou l’autorisation,
  • adapté au modèle de sécurité SharePoint.

Structuré de manière identique quelque soit le groupe, l’objet à sécuriser ou l’autorisation

Afin de normaliser la codification pour nommer le groupe de sécurité, il est proposé le format suivant:

CODESITE _ AAAAAAAA

où :

  • CODESITE: Nom court du site des Directions / Départements / Services,
  • AAAAAAAA: Niveaux d’autorisations SharePoint accordées avec les libellés suivants: Contrôle total, Lecture, Collaboration, Conception, etc.

Pour des raisons de lisibilité et de compréhension, il a été préféré d’afficher directement le niveau d’autorisations (Contrôle total) plutôt que les noms classiques des groupes SharePoint: Approbateurs, Concepteurs, Gestionnaires de hiérarchies, Lecteurs de ressources de style, Membres, Propriétaires, Visiteurs.

Les espaces entre les valeurs doivent être respectés.

Le nom court du site correspond à une nomenclature interne sur 3 ou 4 caractères. Par exemple, le site du Service de Support aux Fournisseurs étrangers de langue française a le code: SFEF, celui de la Direction des Ressources Humaines est: DRH.

Ceux qui donne les noms de groupes suivants pour le site de la Direction des Ressources Humaines:

  • DRH _ Collaboration
  • DRH _ Lecture
  • etc.

La présence de l’underscore (« _ ») permettra de ne pas mélanger ces autorisations avec celles des niveaux inférieurs (cf. ci-dessous).

Adapté au modèle de sécurité SharePoint

Vue de l’utilisateur, les objets sécurisables dans SharePoint sont la Collection de sites, les sites, les listes (ou les bibliothèques), les dossiers des bibliothèques et les éléments (ou les documents).

Compte-tenu de l’héritage des autorisations, le besoin de disposer d’un groupe de sécurité au niveau d’un objet enfant (par exemple une bibliothèque d’un site) se justifie par la nécessité de personnaliser les autorisations.

Pour répondre à cette contrainte, il a été proposé que la valeur du code T varie en fonction de l’objet et du nom interne de l’objet.

Liste ou bibliothèque

Dans le cas d’une liste, le nom interne est généré automatiquement par SharePoint à partir du nom. Le nom interne ne varie jamais, même en cas de renommage de la liste. Par ailleurs, il n’est pas possible d’avoir deux noms internes identiques dans un site.

Afin d’avoir des noms internes courts et lisibles, les listes sont systématiquement créées avec le nom interne désiré puis ensuite elles sont renommées.

Par exemple, si vous désirez avoir une bibliothèque nommée Rapports d’activités, vous la créez avec le nom RAPACT puis ensuite vous la renommez en Rapports d’activités.

Le format de normalisation du nom des listes devient:

CODESITE CODELISTE _ _ AAAAAAAA

où :

  • CODELISTE: Nom interne de la liste.

CODESITE et AAAAAAAA sont inchangés par rapport à la codification du site.

La présence des underscores en double est obligatoire à cause des dossiers et des éléments (cf. ci-dessous).

Donc, s’il est nécessaire d’avoir des groupes spécifiques à la bibliothèque Rapports d’activités du site DRH, cela donnerait:

  • DRH RAPACT _ _ Collaboration
  • DRH RAPACT _ _ Lecture
  • etc.

Dossier

Il n’est pas facile d’interdire à un utilisateur de créer un dossier dans une bibliothèque SharePoint.

Vous savez bien qu’il ne suffit pas de cacher l’option Nouveau dossier. par exemple, l’utilisateur peut contourner ce paramétrage grâce au lien Ouvrir avec l’Explorateur du ruban Bibliothèque ce qui lui permet de créer des dossiers.

Malgré tout, il existe des méthodes pour l’interdire complètement. Elles seront détaillées dans un autre article.

Dans notre cas, les utilisateurs pouvaient créer eux-mêmes les dossiers grâce au navigateur. Il n’était donc pas possible d’imposer un nom unique pour tous les dossiers d’un site. Il est donc possible d’avoir deux bibliothèques distinctes avec chacune un dossier qui porte le même nom.

La solution a consisté à modifier la codification pour les dossiers, de la façon suivante:

CODESITE CODELISTE _ CODEDOS AAAAAAAA

où :

  • CODEDOS: Nom court du dossier.

Dans un souci de simplicité, il n’a pas été imposé une codification stricte du nom court du dossier. La seule contrainte est d’être significatif, de ne pas dépasser 6 caractères et d’être unique.

Donc, s’il est nécessaire d’avoir des groupes spécifiques au dossier Audits internes de la bibliothèque Rapports d’activités du site DRH, cela donnerait par exemple:

  • DRH RAPACT _ AUDINT Lecture
  • DRH RAPACT _ AUDINT Collaboration
  • etc.

Élément ou Document

Pour des raisons liées au caractère sensible des données de l’organisation (Laboratoire pharmaceutique) et pour des raisons historiques (ancien système basé sur Lotus Domino), les autorisations sont fréquemment données au niveau du document…

Pour s’adapter à cette contrainte forte, la codification des groupes de sécurité SharePoint liés à un élément dans une liste ou un document d’une bibliothèque est à la suivante:

CODESITE CODELISTE CODEDOC AAAAAAAA

où :

  • CODEDOC: Nom court du document ou de l’élément.

Le nom court du document est généré comme un nom court de fichiers (nom 8dot3 http://technet.microsoft.com/en-us/library/ff621566(v=ws.10).aspx). Dans une invite de commande, les noms courts sont visibles grâce à l’instruction DIR /X.

Volontairement, il n’est pas tenu compte de la présence ou de dossiers dans la bibliothèque.

Si le document qui s’intitule Produit XYZ.docx a comme nom court PRODUI~1.DOC (par exemple).

Donc, s’il est nécessaire d’avoir des groupes spécifiques à ce document, cela donne:

  • DRH RAPACT PRODUI~1.DOC Lecture
  • DRH RAPACT PRODUI~1.DOC Collaboration
  • etc.

En images

Plan de nommage des groupes de sécurité SharePoint

SharePoint: Utiliser les métadonnées pour la sécurité

Une organisation rencontrait un problème de diffusion de documents assez classique. Cette organisation assure le rôle de diffuseur de contenu auprès d’autres organismes officiels, via un site extranet SharePoint. Une fois qu’un utilisateur d’un organisme étranger s’est identifié, il accède à ses documents.

Les métadonnées sont souvent utilisées pour faciliter la recherche ou pour catégoriser des documents afin d’opérer des filtres.

Un autre usage méconnu (ou peu utilisé) concerne la sécurité.

Modèle de sécurité standard de SharePoint

En effet, l’organisation mettait à disposition des documents qui sont communs à certains organismes et qui ne doivent pas être accessibles à tous. Afin de répondre à ce problème, le responsable de l’organisation avait décidé de s’appuyer sur le modèle de sécurité standard de SharePoint.

Pour cela, il avait mis en place différentes bibliothèques SharePoint pour les différents utilisateurs avec des droits spécifiques.

La gestion de plusieurs bibliothèques de documents devenait complexe et la maintenance des autorisations de niveau était difficile. De plus, certains documents furent volontairement dupliqués dans plusieurs bibliothèques pour résoudre rapidement des cas complexes.

Nouveau modèle de sécurité basé sur les métadonnées

Cette solution étant inacceptable, un nouveau modèle de sécurité basé sur l’utilisation de métadonnées a été proposé.

En utilisant ce nouveau modèle, il peut déposer de nouveaux documents dans SharePoint avec des métadonnées qui spécifie simplement les organismes qui peuvent y accéder: les niveaux de permissions accordés au document sont déduits des métadonnées des documents. Ce qui permet de réduire aussi le nombre de bibliothèque de documents à gérer.

Dans de nombreux cas, les métadonnées du document permettent d’indiquer qui peut y avoir accès. Toutefois, si vous avez l’intention d’utiliser les métadonnées pour la sécurité, vous devez planifier avec soin le type de métadonnées à collecter.

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.