OPDATERING 12/18/07: Se Paul Liebrand artikel for nogle tekniske konsekvenser af fjerne eller ændre standardnavnene på gruppe (se hans bemærkning nedenfor samt).

Oversigt:

SharePoint sikkerhed er let at konfigurere og administrere. Dog, Det har vist sig for at være svært for nogle første gang administratorer virkelig ombryde deres hænder omkring det.. Ikke kun det, Jeg har set nogle administratorer kommer til en perfekt forståelse på mandag kun at have mistet det af fredag, fordi de ikke behøvede at gøre enhver konfiguration i den mellemliggende tid. (Jeg indrømmer at have dette problem selv). Denne blogoptegnelse forhåbentlig giver en nyttig SharePoint sikkerhed primer og peger i retning af nogle sikkerhed konfiguration af bedste praksis.

Vigtig bemærkning:

Denne beskrivelse er baseret på ud af boksen SharePoint sikkerhed. Min personlige erfaring er orienteret omkring mos, så der kan være nogle MOSS specifikke ting her, men det forekommer mig nøjagtig for WSS. Jeg håber, at nogen ser fejl eller udeladelser vil påpege at, i kommentarer eller e-mail mig. Jeg vil foretage rettelser post hast.

Fundamentals:

Med henblik på denne oversigt, der er fire grundlæggende aspekter til sikkerhed: brugere/grupper, securable objekter, tilladelsesniveauer og arv.

Brugere og grupper bryde ned til:

• Individuelle brugere: Trukket fra active directory eller skabt direkte i SharePoint.
• Grupper: Tilknyttede direkte fra active directory eller oprettet i SharePoint. Grupper er en samling af brugere. Grupper er globale i en gruppe af websteder. De er aldrig "bundet" til et bestemt objekt.

Securable objekter bryde ned til mindst:

• Websteder
• Dokumentbiblioteker
• Individuelle elementer på lister og dokumentbiblioteker
• Mapper
• Forskellige BDC-indstillingerne.

Der andre securable objekter, men du får billedet.

Tilladelsesniveauer: Et bundt af kornet / lavt niveau adgangsrettigheder, der omfatter sådanne ting som oprette/læse/slette poster i lister.

Arv: Objekter arver som standard sikkerhedsindstillinger fra deres indeholdende objekt. Underordnede websteder nedarver tilladelse fra deres forældre. Dokumentbiblioteker arver fra deres hjemmeside. Så videre og så videre.

Brugere og grupper vedrører securable objekter via tilladelsesniveauer og arv.

De vigtigste sikkerhedsregler for at forstå, nogensinde 🙂 :

1. Grupper er simpelthen samlinger af brugere.
2. Grupper er globale inden for en gruppe af websteder (dvs. der er ikke sådan noget som en gruppe, der er defineret på et webstedsniveau).
3. Gruppenavnet ikke modstå, grupper ikke, i og for sig selv, har nogen bestemt sikkerhedsniveau.
4. Grupper har sikkerhed i forbindelse med et bestemt objekt.
5. Du kan tildele forskellige tilladelsesniveauer til den samme gruppe for hvert objekt.
6. Web application politikker trumfe alt dette (Se nedenfor).

Sikkerhedsadministratorer tabt i et hav af gruppen og bruger lister kan altid stole på disse aksiomer at håndtere og forstå deres sikkerhedskonfiguration.

Fælles faldgruber:

• Gruppenavne indebærer fejlagtigt tilladelse: Ud af boksen, SharePoint definerer et sæt af grupper hvis navne indebærer en iboende sikkerhedsniveau. Overveje gruppen "Bidragyder". En uvant med SharePoint sikkerhed kan godt kigge på dette navn og antage, at ethvert medlem af denne gruppe kan "bidrage" til ethvert websted/liste/bibliotek i portalen. Det kan være sandt, men ikke fordi gruppens navn sker for at være "bidragyder". Dette er kun rigtigt ud af kassen fordi gruppen har fået et tilladelsesniveau, der sætter dem i stand til at tilføje/redigere/slette indhold på rodwebstedet. Gennem arv, "bidragydere" Gruppen kan også tilføje/redigere/slette indholdet på hvert underordnet websted. Man kan "bryde" arven kæden og ændre tilladelsesniveauet for et underordnet websted sådan at medlemmer af den såkaldte "bidragyder" Gruppen kan ikke bidrage på alle, men kun læse (for eksempel). Dette ville ikke være en god idé, naturligvis, da det ville være meget forvirrende.
• Grupper er ikke defineret på et webstedsniveau. Det er nemt at blive forvirret af brugergrænsefladen. Microsoft giver et praktisk link til bruger eller gruppe forvaltning via hver site "mennesker og grupper" link. Det er nemt at tro, at når jeg er på webstedet "xyzzy" jeg oprette en gruppe gennem xyzzy's folk og grupper link, jeg har lige oprettet en gruppe, som kun findes på xyzzy. Det er ikke tilfældet. Jeg har faktisk lavet en gruppe til hele gruppen af websteder.
• Grupper medlemskab er ikke afhængig af hjemmeside (dvs. Det er den samme overalt benyttes gruppen): Overveje gruppen "ejer" og to websteder, "HR" og "Logistik". Det ville være normalt at tænke, at to separate enkeltpersoner ville eje disse websteder — en HR ejer og en logistik ejer. Brugergrænsefladen gør det nemt for en sikkerhedsadministrator at fejlhåndtere dette scenario. Hvis jeg ikke vidste bedre, Jeg kan få adgang til personer og grupper links via webstedet HR, Vælg "ejere" gruppe og tilføje min HR ejer til denne gruppe. En måned senere, Logistik kommer på linje. Jeg adgang til personer og grupper fra webstedet logistik, tilføje pull up "ejere" gruppe. Jeg ser HR ejeren der og fjerne hende, tænker at jeg fjerner hende fra ejere på webstedet logistik. Faktisk, Jeg fjerner hende fra gruppen globale ejere. Munterhed ensues.
• Undlade at navnet grupper baseret på specifikke rolle: "Godkendere" Gruppen er et perfekt eksempel. Hvad kan medlemmer af denne gruppe Godkend? Hvor kan de godkende det? Vil jeg virkelig folk logistikafdeling at godkende HR dokumenter? Naturligvis ikke. Altid navn grupper baseret på deres rolle i organisationen. Dette vil reducere den risiko, at gruppen er tildelt en upassende tilladelsesniveauet for et bestemt objekt. Navnet grupper baseret på deres tiltænkte rolle. I det forrige HR/logistik scenarie, Jeg skal have lavet to nye grupper: "HR ejere" og "logistik ejere" og tildele fornuftige tilladelsesniveauer for hver og det minimumsbeløb, der kræves til disse brugere at gøre deres job.

Andre nyttige referencer:

• Web application politik gotcha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Clearinghouse for SharePoint sikkerhed: http://www.sharepointsecurity.com/
• Links fra Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Hvis du har gjort det så langt:

Lad mig vide dine tanker via kommentarer eller email mig. Hvis du kender andre gode referencer, venligst gøre det samme!