SharePoint Security Fundamentals Primer / Undgå fælles faldgruber

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:

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!

Technorati Tags:

8 tanker om ”SharePoint Security Fundamentals Primer / Undgå fælles faldgruber

  1. Perry

    Flere faldgruber:

    * Der er visse særlige tilladelser til rådighed andetsteds i skibets sikringsplan og ikke synlige i afsnittet personer og grupper: "Personalisering tjenester tilladelser" og "firmadatakataloget tilladelser"

    * Jeg har læst at der findes også særlige SharePoint Designer tilladelser i nogle uforståelige xml begravet inde i html eller andet sted.

    * Den primære og sekundære administratorer til en gruppe af websteder holdes andetsteds i indstillinger for gruppe af websteder, og er ikke synlige i afsnittet personer og grupper.

    * Bestemte konti har magiske (særlige) evner uanset hvad du ser på området mennesker og grupper: medlemmer af den indbyggede administratorgruppe på web-servere, og farmen-tjenestekontoen.

    (PS: Sletning af spam-kommentarer vil forbedre læsbarheden her.)

    Svar
  2. Jean Wright
    Dette er en meget god post. Jeg er faldet i denne fælde et par gange. Security management kan få sammensat når du begynder at blande godkendelsesmetoder og forskellige sikkerhed gruppering metoder. Dette skal betragtes som en del af planlægningsprocessen og bør ikke blive overset.
    Svar
  3. Mark Miller skrev:
    (Notat fra Paul: Mark bedt mig om at gøre en lille ændring til hans kommentar men jeg kan ikke redigere live spaces kommentarer, så jeg har tilføjet det igen her med ændringen og slettet oprindelige).
    Paul,
    Den sammenfattende tilgang til at præsentere denne info kom meget godt. Jeg især godt lide "faldgruberne" sektion, da jeg har faldet i et par af dem selv.
    En anden ting du sagde hit hjemme: læring på mandag betyder ikke nødvendigvis, du vil huske det på fredag. Jeg er glad for nogen ud over mig bruger deres blog som en "skrabekæder" system for disse kritiske ting, der ikke er gjort med jævne mellemrum.
    Godt arbejde.
    Hilsen,
    Mark
    EndUserSharePoint.com

    November 27 9:04 AM
    (http://www.EndUserSharePoint.com)

    Svar
  4. Paul Galvin
    Jeg tror det er nok en god ide at fjerne disse standardgrupper, især bidragyder og ejer. De er overbroad og forveksles let. Jeg foretrækker at bruge "alle godkendte brugere" i stedet for en "besøgende" Gruppen samt. Hvis et bestemt sæt af bør brugere kun skrivebeskyttet adgang, så jeg vil anbefale at oprette en annoncegruppe eller SharePoint-gruppen med en passende beskrivende navn, strømsparetilstand. "Logistik besøgende".
    –Paul G
    Svar
  5. Intet navn
    Det lyder som den første ting du skal gøre er bare dumpe besøgende, Bidragyder og ejer grupper og erstatte dem med dine egne logiske grupper. Det ville være fornuftigt at gøre?
    Svar

Efterlad et svar

Din e-mail adresse vil ikke blive offentliggjort. Krævede felter er markeret *