Planifier la sécurité des sites (Office SharePoint Server)

Mise à jour : 2009-06-25

Dans cet article :

• À propos des éléments de la sécurité des sites

• À propos de l’affectation des autorisations

• À propos des autorisations affinées et de l’héritage des autorisations

• Choisir les niveaux de sécurité de site à utiliser

• Planifier l’héritage des autorisations

• Script de sous-site

• Fiche

Cet article traite de la planification du contrôle et des autorisations d’accès au niveau de la collection de sites, des sites et des sous-sites et n’aborde pas la planification de la sécurité de votre serveur ou de votre batterie de serveurs. Pour plus d’informations sur la planification des autres aspects de la sécurité, tels que les méthodes d’authentification et le chiffrement, voir Planifier la sécurité de site et de contenu (Office SharePoint Server).

Pour contrôler la sécurité des sites, vous devez affecter des autorisations aux utilisateurs et aux groupes pour un objet sécurisable spécifique (tel qu’un site, une liste ou un élément). Lorsque vous planifiez la sécurité des sites, vous devez déterminer les points suivants :

• Dans quelle mesure vous souhaitez contrôler les autorisations pour les différents objets sécurisables. Par exemple, souhaitez-vous contrôler l’accès pour le site entier ou avez-vous besoin de paramètres de sécurité spécifiques pour une liste, un dossier ou un élément particulier ?

• La façon dont vous souhaitez classer et gérer vos utilisateurs (à l’aide de groupes). Cet article traite des notions fondamentales liées à la sécurité du site et vous aide à déterminer les objets sécurisables auxquels appliquer des autorisations spécifiques. Pour plus d’informations sur le classement des utilisateurs en groupes, voir Choisir les groupes de sécurité à utiliser (Office SharePoint Server).

  Remarque :

  La façon dont les groupes et les autorisations interagissent a évolué de manière significative par rapport à la version précédente. Dans la version précédente, les groupes de niveau site contenaient les utilisateurs et les autorisations (autrement dit, lorsque vous ajoutiez un utilisateur à un groupe de sites, vous déterminiez automatiquement les autorisations accordées à l’utilisateur pour un site). Dans cette version, les concepts de groupes d’utilisateurs et d’autorisations ont été séparés : les groupes SharePoint au niveau de la collection de sites contiennent les utilisateurs, les niveaux d’autorisation contiennent les autorisations et les groupes ne possèdent aucune autorisation tant qu’ils ne bénéficient pas d’un niveau d’autorisation pour un objet sécurisable spécifique (tel qu’un site, une liste, une bibliothèque, un dossier, un élément ou un document).

À propos des éléments de la sécurité des sites

Quel que soit le type de site que vous créez, la sécurité de votre site inclut les cinq éléments suivants :

• Autorisations utilisateur individuelles   Autorisations individuelles qui accordent la possibilité d’exécuter des actions spécifiques. Par exemple, l’autorisation Afficher les éléments accorde à l’utilisateur la possibilité d’afficher des éléments dans une liste. Les administrateurs de batterie peuvent contrôler les autorisations qui sont disponibles pour la batterie de serveurs en utilisant la page Autorisations des utilisateurs de l’application Web dans l’Administration centrale. (Pour accéder à cette page, dans la page Gestion des applications, sous Sécurité des applications, cliquez sur Autorisations des utilisateurs de l’application Web.) Pour plus d’informations sur les autorisations disponibles, voir User permissions and permission levels.

• Niveau d’autorisation   Jeu prédéfini d’autorisations qui accorde aux utilisateurs la possibilité d’effectuer des actions connexes. Les niveaux d’autorisation par défaut sont : Accès limité, Lecture, Collaboration, Conception et Contrôle total. Par exemple, le niveau d’autorisation Lecture comprend, entre autres, les autorisations Afficher les éléments, Ouvrir les éléments, Afficher les pages et Afficher les versions, qui sont toutes nécessaires pour la lecture des documents, des éléments et des pages d’un site SharePoint. Les autorisations peuvent être incluses dans plusieurs niveaux d’autorisation. Les niveaux d’autorisation peuvent être personnalisés par n’importe quel utilisateur affecté à un niveau d’autorisation qui inclut l’autorisation Gérer les autorisations. Pour plus d’informations sur les niveaux d’autorisation par défaut et sur les autorisations qui y sont incluses, voir User permissions and permission levels.

• Utilisateur   Personne possédant un compte d’utilisateur qui peut être authentifié par le biais de la méthode d’authentification utilisée pour le serveur. Vous pouvez ajouter des utilisateurs individuels et attribuer directement un niveau d’autorisation à chacun d’eux ; les utilisateurs n’ont pas besoin de faire partie d’un groupe. Il est recommandé d’affecter les autorisations à des groupes plutôt qu’à des utilisateurs. Étant donné qu’il est inefficace de gérer directement des comptes d’utilisateurs, vous ne devez affecter des autorisations à un utilisateur spécifique qu’à titre exceptionnel. Pour plus d’informations sur les types de compte d’utilisateur, voir User permissions and permission levels.

• Groupe   Groupe d’utilisateurs. Il peut s’agir d’un groupe de sécurité Windows (tel que Département_A) que vous ajoutez au site ou d’un groupe SharePoint tel que Propriétaires du site, Membres du site ou Visiteurs du site. Chaque groupe SharePoint reçoit un niveau d’autorisation par défaut, mais le niveau d’autorisation associé à n’importe quel groupe peut être modifié selon vos besoins. Toute personne à laquelle est affecté un niveau d’autorisation qui comprend l’autorisation Créer des groupes (incluse dans le niveau d’autorisation Contrôle total par défaut) peut créer des groupes SharePoint personnalisés.

• Objet sécurisable   Les utilisateurs ou les groupes reçoivent un niveau d’autorisation pour un objet sécurisable spécifique : site, liste, bibliothèque, dossier, document ou élément. Par défaut, les autorisations associées à une liste, une bibliothèque, un dossier, un document ou un élément sont héritées du site, de la liste ou de la bibliothèque parent. Cependant, toute personne bénéficiant, pour un objet sécurisable particulier, d’un niveau d’autorisation qui inclut l’autorisation Gérer les autorisations peut modifier les autorisations associées à cet objet sécurisable. Par défaut, les autorisations sont initialement contrôlées au niveau du site et toutes les listes et bibliothèques héritent les autorisations du site. Utilisez des autorisations au niveau de la liste, du dossier et de l’élément pour mieux contrôler les utilisateurs autorisés à afficher le contenu du site ou à interagir avec ce contenu. Vous pouvez opter pour l’héritage des autorisations d’une liste parent, de la totalité du site ou d’un site parent à tout moment.

À propos de l’affectation des autorisations

Vous pouvez affecter à un utilisateur ou à un groupe un niveau d’autorisation pour un objet sécurisable spécifique (site, liste ou élément). Des utilisateurs individuels ou des groupes peuvent avoir différents niveaux d’autorisation pour différents objets sécurisables.

Remarque :

Étant donné qu’il est inefficace de gérer directement des comptes d’utilisateurs, il est recommandé d’utiliser des autorisations de groupe autant que possible. En particulier, si vous utilisez des autorisations affinées (voir la section suivante), vous devez utiliser des groupes pour ne pas avoir à effectuer le suivi de comptes d’utilisateurs individuels. Les personnes pouvant intégrer ou quitter les équipes et changer de responsabilité fréquemment, vous ne souhaitez pas être obligé de suivre toutes ces modifications et de mettre à jour en permanence les autorisations associées à des objets sécurisés de manière unique.

Le diagramme suivant illustre la façon dont les utilisateurs et les groupes reçoivent des niveaux d’autorisation spécifiques pour un objet sécurisable particulier.

À propos des autorisations affinées et de l’héritage des autorisations

Vous pouvez utiliser les autorisations affinées (autorisations au niveau de la liste, de la bibliothèque, du dossier ou du document) pour contrôler plus précisément les actions que les utilisateurs peuvent effectuer sur votre site. Les objets sécurisables suivants sont disponibles pour les affectations des autorisations :

• Site   Contrôle l’accès au site dans sa globalité.

• Liste ou bibliothèque   Contrôle l’accès à une liste ou bibliothèque spécifique.

• Dossier   Contrôle l’accès aux propriétés d’un dossier (telles que le nom du dossier).

• Élément ou document   Contrôle l’accès à un élément ou document de liste spécifique.

Héritage des autorisations et autorisations affinées

Par défaut, les autorisations au sein d’un site sont héritées du site. Toutefois, vous pouvez interrompre cet héritage pour n’importe quel objet sécurisable à un niveau inférieur dans la hiérarchie en modifiant les autorisations (créant ainsi une affectation d’autorisation unique) sur cet objet sécurisable. Par exemple, vous pouvez modifier les autorisations pour une bibliothèque de documents, ce qui interrompt l’héritage du site. Toutefois, l’héritage est uniquement interrompu pour l’objet sécurisable pour lequel vous avez affecté des autorisations ; les autres autorisations du site demeurent inchangées. Vous pouvez à tout moment revenir à l’héritage des autorisations de la liste ou du site parent.

Héritage d’autorisations et sous-sites

Les sites Web constituent eux-mêmes des objets sécurisables auxquels des autorisations peuvent être affectées. Vous pouvez configurer des sous-sites de manière à ce qu’ils héritent les autorisations d’un site parent ou créer des autorisations uniques pour un site particulier. L’héritage des autorisations est la façon la plus simple pour gérer un groupe de sites Web. Toutefois, si un sous-site hérite les autorisations de son parent, ce jeu d’autorisations est partagé. Cela signifie que les propriétaires de sous-sites qui héritent les autorisations du site parent peuvent modifier les autorisations du parent. Si vous souhaitez modifier les autorisations pour le sous-site uniquement, vous devez au préalable interrompre l’héritage des autorisations.

Les sous-sites peuvent hériter les autorisations d’un site parent. Vous pouvez interrompre l’héritage des autorisations pour un sous-site en créant des autorisations uniques. Cette opération copie les groupes, les utilisateurs et les niveaux d’autorisation depuis le site parent vers le sous-site, puis interrompt l’héritage. Si vous abandonnez les autorisations uniques au profit d’autorisations héritées, les utilisateurs, les groupes et les niveaux d’autorisation commencent à être hérités et vous perdez les utilisateurs, les groupes ou les niveaux d’autorisation que vous avez définis de manière unique dans le sous-site. Les niveaux d’autorisation peuvent également être hérités (ils le sont par défaut), si bien que le niveau d’autorisation Lecture est le même, quel que soit l’objet auquel il est appliqué. Vous pouvez interrompre cet héritage en modifiant le niveau d’autorisation. Par exemple, peut-être ne souhaitez-vous pas que le niveau d’autorisation Lecture sur un sous-site particulier inclue l’autorisation Créer des alertes.

Choisir les niveaux de sécurité de site à utiliser

Lorsque vous créez votre structure d’autorisations, il est important de trouver un point d’équilibre entre la facilité d’administration, les performances et la nécessité de contrôler des autorisations spécifiques pour des éléments particuliers. Si vous utilisez des autorisations affinées de manière intensive :

• vous allez consacrer plus de temps à la gestion des autorisations ;

• Microsoft Office SharePoint Server risque de désactiver le cache de sortie si une collection de sites contient plus de 10 000 listes de contrôle d’accès uniques. Les utilisateurs peuvent subir une baisse des performances lorsqu’ils essaient d’accéder au contenu du site. Pour plus d’informations sur la mise en cache, voir Mise en cache dans Office SharePoint Server 2007.

Comme dans le cas de n’importe quel serveur ou site Web, il est important de suivre le principe des privilèges minimum en matière d’autorisation d’accès au site : les utilisateurs ne doivent bénéficier que des niveaux d’autorisation dont ils ont besoin. Commencez par utiliser les groupes standard (Membres, Visiteurs et Propriétaires) et contrôler les autorisations au niveau du site afin de simplifier l’administration au maximum. Intégrez la plupart des utilisateurs aux groupes Visiteurs ou Membres. Limitez le nombre de personnes dans le groupe Propriétaires aux seuls utilisateurs que vous souhaitez autoriser à modifier la structure du site ou ses paramètres et son apparence. Par défaut, les utilisateurs figurant dans le groupe Membres peuvent collaborer au site, ajouter ou supprimer des éléments ou des documents, mais ils ne peuvent pas modifier la structure du site, ni ses paramètres ou son apparence. Vous pouvez créer des niveaux d’autorisation et des groupes SharePoint supplémentaires si vous devez contrôler davantage les actions que vos utilisateurs peuvent effectuer.

S’il existe des listes, des bibliothèques, des dossiers, des éléments ou des documents particuliers qui contiennent des données sensibles et qui doivent bénéficier d’une sécurisation renforcée, vous pouvez accorder des autorisations à un groupe ou à un utilisateur spécifique. Sachez, toutefois, qu’il est impossible d’afficher toutes les autorisations spécifiques à des listes, bibliothèques, dossiers, éléments ou documents au sein d’un site. Cela signifie qu’il est difficile de déterminer rapidement les personnes qui disposent d’autorisations sur des objets sécurisables spécifiques et de réinitialiser en bloc les autorisations affinées.

Planifier l’héritage des autorisations

Il est plus facile de gérer les autorisations lorsqu’il existe une hiérarchie claire des autorisations et des autorisations héritées. Cela devient plus difficile lorsque des autorisations affinées sont appliquées à certaines listes au sein d’un site et que certains sites disposent de sous-sites auxquels sont associées des autorisations uniques et de sous-sites auxquels sont associées des autorisations héritées. Dans la mesure du possible, réorganisez les sites, les sous-sites, les listes et les bibliothèques afin qu’ils puissent partager la plupart des autorisations. Placez les données sensibles dans leurs propres listes, bibliothèques ou sous-sites.

Par exemple, il est beaucoup plus facile de gérer un site qui bénéficie de l’héritage des autorisations, comme illustré dans le tableau suivant.

Comparativement, il n’est pas si facile de gérer un site qui bénéficie de l’héritage des autorisations, comme illustré dans le tableau suivant.

Script de sous-site

Si votre environnement requiert le niveau d’isolation de contenu et de site le plus élevé, il peut s’avérer opportun de concevoir votre structure de site Office SharePoint Server de telle sorte que les risques associés à l’utilisation d’espaces de noms d’URL contigus soient réduits au minimum. La configuration des espaces de noms d’URL de site Office SharePoint Server par défaut pourrait favoriser la survenue d’un problème de script de sous-site, caractérisé par le fait qu’un utilisateur malveillant effectue sur un site des actions qui ne sont pas couvertes par le niveau d’autorisation qui lui a été accordé. Le problème existe, car les sites Office SharePoint Server sont des étendues de sécurité, dont un nombre quelconque peut se côtoyer sous le même nom d’hôte. Étant donné que les navigateurs Web ne considèrent que les noms d’hôte (et non les sites) comme des étendues de sécurité, le contenu comportant des scripts qui résident sur un site Office SharePoint Server donné peut, dans certaines circonstances, être exécuté sur les autres sites si ceux-ci se trouvent sous le même nom d’hôte.

Office SharePoint Server autorise l’accès au contenu en fonction des droits et des appartenances à un groupe associés à un utilisateur authentifié. Par conséquent, un script qui s’exécute pour le compte d’un utilisateur peut en réalité effectuer n’importe quelle action que l’utilisateur est autorisé à réaliser. Le problème potentiel est décrit dans l’exemple suivant :

• L’utilisateur A et l’utilisateur B possèdent leurs propres collections de sites Office SharePoint Server : http://my/sites/UserA et http://my/sites/UserB.

• L’utilisateur A possède les autorisations de collaborateur sur son propre site, mais ne possède aucune autorisation sur le site de l’utilisateur B. Lorsque l’utilisateur A accède au site de l’utilisateur B, il obtient une erreur Accès refusé.

• Toutefois, l’utilisateur A peut télécharger vers son site un document qui contient un script malveillant et accorder à l’utilisateur B un accès en lecture à ce document. Si l’utilisateur B affiche le document créé par l’utilisateur A, le script malveillant peut s’exécuter sans émission d’un avertissement à l’aide des informations d’identification de l’utilisateur B. Dans le contexte de nombreux navigateurs Web disponibles, le script ne franchit pas une étendue de sécurité et l’exécution du script n’est pas considérée comme un événement impliquant plusieurs domaines.

Le problème existe, car le site Office SharePoint Server de l’utilisateur B et le site Office SharePoint Server de l’utilisateur A se trouvent sous le même nom d’hôte. Dans cette structure de site, l’utilisateur B et l’utilisateur A doivent être en mesure de se faire mutuellement confiance quant au fait qu’aucun d’eux n’essaiera de lancer une attaque de script. Si les groupes de collaborateurs ne peuvent pas s’approuver mutuellement, leurs sites doivent être partitionnés sous différents noms d’hôtes. Le problème de script revêt une grande importance dans les scénarios de collaboration Office SharePoint Server, plutôt que dans les scénarios de publication Internet ou de portail structuré, car l’utilisateur malveillant doit disposer d’un accès à titre de collaborateur pour lancer une attaque de script de sous-site.

Dès lors que l’utilisation d’Office SharePoint Server s’intensifie, notamment en ce qui concerne l’utilisation de l’intranet dans les grandes organisations, et que plusieurs utilisateurs au sein des organisations collaborent à une partie d’un déploiement basé sur des chemins d’accès (par exemple, http://my ou http://corp), la possibilité de faire confiance à tous les collaborateurs à cet hôte peut s’apparenter à un défi. C’est notamment le cas dans les scénarios où la création de sites libre-service est utilisée et où les sous-sites deviennent profondément imbriqués. Vous pouvez concevoir votre déploiement Office SharePoint Server de manière à réduire au minimum ces motifs d’inquiétude. Pour plus d’informations sur la conception d’une architecture de l’information, voir Déterminer l’architecture de l’information de votre site.

Pour plus d’informations sur la conception de collections de sites, de sites et de sous-sites Office SharePoint Server, voir Définir des sites et des sous-sites.

Pour une aide complémentaire sur la sécurité, voir Centre de ressources pour la sécurité des produits et technologies SharePoint (en anglais) (https://go.microsoft.com/fwlink/?linkid=148056&clcid=0x40C) (en anglais).

Utilisation de collections de sites nommées par l’hôte

L’utilisation de collections de sites nommées par l’hôte vous permet de renforcer la sécurité des sites et du contenu en prenant en charge la création de plusieurs collections de sites de niveau racine au sein d’une même application Web. Par exemple, les administrateurs d’organisations d’hébergement peuvent utiliser des collections de sites nommées par l’hôte pour créer plusieurs sites nommés par le domaine. Windows SharePoint Services 3.0 prend en charge la création de plusieurs domaines dans une même application Web. Cela vous permet de placer plusieurs domaines, tels que http://UserB.collab.mycorp.com et http://UserB.collab.mycorp.com, dans des collections de sites distinctes au sein de la même application Web. Toutefois, vous devez prendre en considération les points suivants lorsque vous utilisez cette approche pour gérer le problème lié au script de sous-site :

• L’utilisation de noms d’hôte conviviaux, tels que http://UserB.collab.mycorp.com, peut engendrer des problèmes liés à DNS, car vous devez faire pointer tous les noms d’hôte conviviaux vers le déploiement Office SharePoint Server adéquat. Les noms de domaine complets peuvent atténuer ce problème en autorisant l’utilisation d’entrées DNS génériques, telles que *.collab.mycorp.com.

• Office SharePoint Server prend en charge la création libre-service et la gestion de collections de sites basées sur les chemins d’accès. Le déploiement de sites nommés par l’en-tête de l’hôte peut créer une charge opérationnelle pour la mise en service des sites. Pour plus d’informations sur la création de sites libre-service, voir Configurer la création de sites libre-service.

Pour plus d’informations sur les collections de sites nommées par l’hôte, voir Planifier des collections de sites nommées par l’hôte (Office SharePoint Server).

Déplacement de contenu vers un nom d’hôte distinct

Si vous souhaitez déplacer du contenu vers un nom d’hôte distinct, tenez compte des recommandations suivantes :

• Vous pouvez déplacer de petites quantités de contenu, notamment des bibliothèques de documents et des listes, à l’aide des fonctionnalités clientes telles qu’Envoyer vers, Autre emplacement, Ouvrir en mode Explorateur (pour les documents) ou Exporter vers une feuille de calcul (pour les listes).

• Pour déplacer des quantités de contenu plus volumineuses, notamment des sites et des collections de sites, envisagez de sauvegarder et de restaurer votre contenu. Pour plus d’informations sur la sauvegarde et la restauration de votre contenu, voir Sauvegarder et restaurer des collections de sites à l’aide des outils intégrés (Office SharePoint Server 2007).

• Pour les quantités de données plus volumineuses, envisagez de créer une collection de sites en utilisant un nom d’hôte différent.

• Envisagez de créer un chemin d’accès géré au même niveau que le site de l’emplacement d’origine pour l’hébergement de la collection de sites. La définition d’un chemin d’accès géré consiste à spécifier les chemins d’accès, dans l’espace de noms d’URL d’une application Web, qui sont utilisés pour les collections de sites. Cela est important, car le contenu Office SharePoint Server utilise des chemins d’accès relatifs au serveur dans de nombreux cas. Tout en restaurant le contenu à un nouvel emplacement, Office SharePoint Server peut réparer le nom d’hôte d’une URL, mais une incohérence de niveau à ce stade peut se traduire par l’échec de l’opération de restauration. Pour plus d’informations sur les chemins d’accès gérés, voir Définir des chemins d’accès gérés.

Fiche

Dans la fiche relative à la sécurité du contenu et des sites (https://go.microsoft.com/fwlink/?linkid=73135&clcid=0x40C) , renseignez votre hiérarchie de site, puis répertoriez les autorisations nécessaires à chaque niveau de la hiérarchie et tout héritage d'autorisations.

Télécharger ce livre

Cette rubrique est incluse dans le livre téléchargeable suivant pour une lecture et une impression plus faciles :

• Planification et architecture pour Office SharePoint Server 2007, partie 1

Vous trouverez la liste complète des livres disponibles sur Contenu téléchargeable pour Office SharePoint Server 2007.