MISE À JOUR 12/18/07: Voir l'article de Paul Liebrand pour certaines conséquences techniques de supprimer ou de modifier les noms de groupe par défaut (voir son commentaire ci-dessous ainsi).

Vue d'ensemble:

Sécurité de SharePoint est facile à configurer et à gérer. Cependant, Il s'est avéré difficile pour les nouveaux administrateurs à vraiment envelopper les mains autour d'elle. Non seulement cela, J'ai vu certains administrateurs de parvenir à une compréhension parfaite lundi seulement pour avoir perdu en vendredi parce qu'ils n'ont pas à faire n'importe quelle configuration dans l'intervalle. (J'avoue avoir ce problème moi-même). Cette entrée de blog, j'espère que fournit une amorce de sécurité SharePoint utile et est orientée vers des meilleures pratiques de configuration de sécurité.

Remarque importante:

Cette description est issue hors de la zone de sécurité de SharePoint. Mon expérience personnelle est orienté autour de MOSS donc il peut y avoir des trucs spécifiques MOSS ici, mais je crois que c'est exact pour WSS. J'espère que quelqu'un voyant toute erreur ou omission sera signaler dans les commentaires ou Ecrivez-moi. Je vais faire des corrections post hâte.

Principes de base:

Aux fins de cette vue d'ensemble, Il y a quatre aspects fondamentaux de la sécurité: utilisateurs/groupes, objets sécurisables, héritage et niveaux d'autorisation.

Utilisateurs et groupes break down to:

• Utilisateurs individuels: Tiré d'active directory ou créés directement dans SharePoint.
• Groupes: Directement mappé d'active directory ou créé dans SharePoint. Les groupes sont une collection d'utilisateurs. Les groupes sont mondiaux dans une collection de sites. Ils sont jamais "liés" pour un objet sécurisable spécifique.

Objets sécurisables pause au moins:

• Sites
• Bibliothèques de documents
• Éléments individuels dans les listes et les bibliothèques de documents
• Dossiers
• Divers paramètres de BDC.

Il autres objets sécurisables, mais vous obtenez l'image.

Niveaux d'autorisation: Un faisceau de granulaire / droits d'accès de bas niveau qui incluent des choses comme créer/lire/effacer les entrées dans les listes.

Héritage: Par défaut des entités héritent des paramètres de sécurité de leur objet conteneur. Sous-sites héritent de l'autorisation de leur parent. Bibliothèques de documents héritent de leur site. Ainsi de suite, etc..

Les utilisateurs et les groupes se rapportent à des objets sécurisables via les niveaux d'autorisation et d'héritage.

Règles de sécurité les plus importantes à comprendre, Jamais 🙂 :

1. Les groupes sont tout simplement des collections d'utilisateurs.
2. Les groupes sont globales au sein d'une collection de sites (i.e. Il n'y a rien de tel qu'un groupe défini à un niveau de site).
3. Nom du groupe ne pas résister, groupes ne, dans et d'eux-mêmes, avoir un niveau particulier de sécurité.
4. Les groupes ont la sécurité dans le contexte d'un objet sécurisable spécifique.
5. Vous peut attribuer des niveaux d'autorisation différents pour le même groupe pour chaque objet sécurisable.
6. Stratégies d'application Web l'emporte sur tout cela (voir ci-dessous).

Les administrateurs de sécurité perdus dans une mer de listes d'utilisateurs et de groupes peuvent toujours compter sur ces axiomes de gérer et de comprendre leur configuration de la sécurité.

Pièges:

• Noms de groupe impliquent faussement la permission: Out of the box, SharePoint définit un ensemble de groupes dont les noms impliquent un niveau inhérent de sécurité. Considérons le groupe « Contributeur ». Un peu familier avec sécurité SharePoint peut bien regarder ce nom et supposer que n'importe quel membre de ce groupe peut "contribuer" à n'importe quel site/liste/bibliothèque dans le portail. C'est peut-être vrai mais pas parce que le nom du groupe se trouve être « contributeur ». Ceci n'est vrai out of the box parce que le groupe a bénéficié d'un niveau d'autorisation qui leur permet d'ajouter/modifier/supprimer des contenus à la racine du site. Par héritage, les contributeurs »" groupe peut également ajouter/modifier/supprimer contenu à chaque sous-site. On peut "casser" la chaîne d'héritage et le changement du niveau d'autorisation d'un sous-site que les membres de la soi-disant « contributeur" groupe ne peuvent pas contribuer à tous les, mais seulement lire (par exemple). Ce ne serait pas une bonne idée, de toute évidence, car il serait très confuse.
• Les groupes ne sont pas définis à un niveau de site. Il est facile de confondre par l'interface utilisateur. Microsoft fournit un lien pratique vers gestion utilisateur/groupe par l'intermédiaire "de personnes et de groupes de chaque site" lien. Il est facile de croire que quand je suis au site "xyzzy" et j'ai créer un groupe par le biais personnes de xyzzy et groupes lien que je viens de créer un groupe qui existe seulement à xyzzy. Ce n'est pas le cas. J'ai effectivement créé un groupe pour la collecte de l'ensemble du site.
• Appartenance à des groupes ne varie pas par site (i.e. C'est le même partout où que le groupe est utilisé): Considérons le groupe propriétaire »" et deux sites, « HR" et « Logistique ». Il serait normal de penser que deux personnes différentes détiendrait ces sites — un propriétaire de HR et propriétaire d'une logistique. L'interface utilisateur, il est facile pour un administrateur de sécurité à altérer ce scénario. Si je ne savais pas mieux, Je pourrais accéder les personnes et les groupes liens via le site RH, Sélectionnez les propriétaires"" groupe et ajouter mon propriétaire HR à ce groupe. Un mois plus tard, Logistique est en ligne. J'ai accéder des personnes et des groupes depuis le site de logistique, ajouter pull up les propriétaires"" Groupe. Je vois le propriétaire HR là et lui enlever, pensant que je suis lui retirer propriétaires sur le site de logistique. En fait, Je suis lui retirer le groupe global des propriétaires. Hilarité s'ensuit.
• Négliger de nom basé sur le rôle spécifique des groupes: Les approbateurs"" groupe est un parfait exemple. Ce qui peut les membres de cette approbation de groupe? Où est-ce qu'ils peuvent approuver il? Ai-je vraiment envie département logistique personnes pour pouvoir approuver des documents RH? Bien sûr que non. Toujours nommer des groupes fondées sur leur rôle au sein de l'Organisation. Cela permettra de réduire le risque que le groupe est assigné un niveau d'autorisation inappropriés pour un objet sécurisable particulier. Nommer des groupes fondées sur leur rôle. Dans le scénario précédent de HR/logistique, Je devrais avoir créé deux nouveaux groupes: « Les propriétaires des ressources humaines" « les propriétaires de logistique et" et attribuer des niveaux d'autorisation raisonnable pour chacun et le montant minimal requis pour les utilisateurs de faire leur travail.

Autres références utiles:

• Web application politique piège n: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Centre d'information pour la sécurité de SharePoint: http://www.sharepointsecurity.com/
• Liens de Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Si vous avez fait il ce bien:

S'il vous plaît laissez-moi savoir votre opinion via les commentaires ou à m'envoyer un email. Si vous connaissez d'autres bonnes références, Veuillez faire de même!