SharePoint säkerhet Fundamentals Primer / Undvika vanliga fallgropar

UPPDATERING 12/18/07: Se Paul Liebrand artikel för några tekniska konsekvenser av att ta bort eller ändra gruppnamn standard (se hans kommentar nedan samt).

Översikt:

SharePoint-säkerhet är lätt att konfigurera och hantera. Men, Det har visat sig vara svårt för vissa första gången administratörer att verkligen Linda sina händer runt den. Inte bara det, Jag har sett några administratörer komma till en perfekt förståelse på måndag bara för att ha förlorat det genom fredag eftersom de behövde inte göra någon konfiguration i den mellanliggande tiden. (Jag erkänna att jag har detta problem jag själv). Denna bloggpost förhoppningsvis ger en användbar SharePoint security primer och pekar mot några metodtips för konfiguration.

Viktigt att notera:

Denna beskrivning är baserad på ur lådan SharePoint security. Min personliga erfarenhet är orienterade kring mossa så det kan vara lite mossa specifika saker här, men jag tror det är exakt för WSS. Jag hoppas att någon ser eventuella fel eller utelämnanden kommer att påpeka det i kommentarer eller maila mig. Jag ska göra korrigeringar post brådska.

Grunderna:

Vid tillämpningen av denna översikt, Det finns fyra grundläggande aspekter på säkerhet: användare/grupper, objekt, behörighetsnivåer och arv.

Användare och grupper bryta ner till:

  • Enskilda användare: Drog från active directory eller skapade direkt i SharePoint.
  • Grupper: Mappade direkt från active directory eller skapade i SharePoint. Grupper är en samling av användare. Grupper är globala i en webbplatssamling. De är aldrig "bundna" till specifika objekt.

Objekt bryta ner till minst:

  • Platser
  • Dokumentbibliotek
  • Enskilda objekt i listor och dokumentbibliotek
  • Mappar
  • Olika BDC-inställningar.

Det andra objekt, men du får bilden.

Behörighetsnivåer: En bunt av granulat / låg nivå åtkomsträttigheter som inkluderar sådana saker som skapa/läsa/ta bort poster i listor.

Arv: Som standard ärver enheter säkerhetsinställningar från deras som innehåller objekt. Underwebbplatser ärver behörighet från deras överordnade. Dokumentbibliotek ärver från deras webbplats. Och så vidare.

Användare och grupper relaterar till objekt via behörighetsnivåer och arv.

De viktigaste säkerhetsreglerna att förstå, Någonsin 🙂 :

  1. Grupper är helt enkelt samlingar av användare.
  2. Grupper är globala inom en webbplatssamling (dvs. Det finns inget sådant som en grupp som definierats på en webbplatsnivå).
  3. Gruppens namn inte motstå, grupper inte, i och för sig, har någon särskild nivå av säkerhet.
  4. Grupper har säkerhet inom ramen för ett specifikt objekt.
  5. Du kan tilldela olika behörighetsnivåer till samma grupp för varje objekt.
  6. Web ansökan politik trumf allt detta (se nedan).

Säkerhetsadministratörer vilse i ett hav av användare och användargrupper listor kan alltid lita på dessa axiom att hantera och förstå deras säkerhetskonfiguration.

Vanliga fallgropar:

  • Namn innebär falskeligen tillstånd: Ur lådan, SharePoint definierar en uppsättning grupper vars namn antyda en inneboende säkerhetsnivå. Anser gruppen "Bidragsgivare". En obekant med SharePoint security kanske titta på det namnet och antar att varje medlem i gruppen kan "bidra" till någon webbplats/lista/bibliotek i portalen. Det kan vara sant men inte för att gruppens namn råkar vara "bidragsgivare". Detta gäller endast ur lådan eftersom gruppen har lämnats en behörighetsnivå som ger dem möjlighet att lägga till/redigera/radera innehållet på rotwebbplatsen. Genom arv, "bidragsgivarna" gruppen kan också lägga till/redigera/radera innehållet på varje underwebbplats. Man kan "bryta" i arvskedjan och ändrar behörighetsnivån för en underwebbplats så att medlemmar av den så kallade "bidragsgivaren" grupp inte kan bidra på alla, men bara läsa (till exempel). Detta skulle inte vara en bra idé, uppenbarligen, eftersom det skulle vara mycket förvirrande.
  • Grupperna definieras inte på en webbplatsnivå. Det är lätt att förväxla med användargränssnittet. Microsoft tillhandahåller en bra länk till användare/grupp förvaltning via varje webbplats "människor och grupper" länk. Det är lätt att tro att när jag är på plats "xyzzy" och jag skapa en grupp via xyzzy's människor och grupper länk som jag har just skapat en grupp som bara finns på xyzzy. Så är inte fallet. Jag har faktiskt skapat en grupp för hela webbplatssamlingen.
  • Grupper medlemskap varierar inte webbplats (dvs. Det är samma överallt gruppen används): Anser gruppen "ägare" och två platser, "HR" och "Logistik". Det skulle vara normalt att tror att två separata individer skulle äga dessa webbplatser — en HR och en logistik ägare. Användargränssnittet gör det enkelt för en säkerhetsadministratör misshandla detta scenario. Om jag inte visste bättre, Jag kan komma åt de personer och grupper länkar via webbplatsen HR, Välj "ägarna" grupp och lägga till min HR ägare till gruppen. En månad senare, Logistik kommer på rad. Jag åt personer och grupper från webbplatsen logistik, Lägg till dra upp "ägarna" grupp. Jag se HR ägare det och ta bort henne, tänker att jag är att ta bort henne från ägarna på webbplatsen logistik. I själva verket, Jag är att ta bort henne från den globala gruppen ägare. Munterhet följer.
  • Underlåta att namnet grupper baserat på specifika roll: "Godkännare" gruppen är ett perfekt exempel. Vad kan medlemmar i denna grupp Godkänn? Där kan de godkänner det? Vill jag verkligen människor logistikavdelning för att kunna godkänna HR dokument? Naturligtvis inte. Alltid namn grupper baserat på deras roll inom organisationen. Detta minskar risken att gruppen tilldelats en olämplig behörighetsnivå för ett visst objekt. Namn grupper baserat på deras avsedda roll. I det föregående scenariot som HR/logistik, Jag borde ha skapat två nya grupper: "HR ägare" och logistik ägare"" och tilldela förnuftiga behörighetsnivåer för varje och det minsta belopp som krävs för dessa användare att göra sitt jobb.

Andra användbara referenser:

Om du har gjort så här långt:

Låt mig veta dina tankar via kommentarerna eller maila mig. Om du vet andra goda referenser, gör samma!

Technorati Tags:

8 tankar på "SharePoint säkerhet Fundamentals Primer / Undvika vanliga fallgropar

  1. Perry

    Fler fallgropar:

    * Det finns vissa särskilda behörigheter tillgängliga någon annanstans i fartygets skyddsplan och inte syns i avsnittet personer och grupper: "Personalization tjänstbehörigheter" och "Business Data Catalog behörigheter"

    * Jag har läst att det finns också särskilda SharePoint Designer behörigheter i någon arcane xml begravd inuti html någonstans.

    * Den primära och sekundära administratörer för en webbplatssamling hålls på annat håll i en webbplatssamling inställningar, och de visas i avsnittet personer och grupper.

    * Vissa konton har magiska (särskilda) förmågor oavsett vad du ser i området personer och grupper: medlemmar i den inbyggda gruppen Administratörer på webbservrar, och kontot gård.

    (PS: Ta bort spam kommentarerna skulle förbättra läsbarheten här.)

    Svar
  2. Jean Wright
    Detta är ett mycket bra inlägg. Jag har fallit i den fällan vid några tillfällen. Säkerhetshantering kan få komplex när du börjar blanda autentiseringsmetoder och olika säkerhets grupperingsmetoderna. Detta måste betraktas som en del av planeringsprocessen och bör inte förbises.
    Svar
  3. Mark Miller skrev:
    (Kommentar från Paul: Mark bad mig att göra en liten förändring till hans kommentar men jag kan inte redigera live spaces kommentarer så jag har lagt till det på nytt här med förändringen och bort ursprungliga).
    Paul,
    Den sammanfattande strategin för att presentera denna information kom ut mycket bra. Jag gillade speciellt "fallgropar" avsnitt, eftersom jag har hamnat i några av dessa själv.
    En annan sak du sa hit hem: lärande på måndag betyder inte nödvändigtvis kommer du ihåg det på fredag. Jag är glad att någon förutom mig använder sin blogg som en "tickler" system för de viktiga saker som inte görs regelbundet.
    Bra arbete.
    Hälsningar,
    Mark
    EndUserSharePoint.com

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

    Svar
  4. Paul Galvin
    Jag tror det är nog en bra idé att ta bort de standardgrupperna, särskilt bidrag och ägare. De är överdrivet och förväxlas lätt. Jag föredrar att använda "alla autentiserade användare" i stället för en "besökare" gruppen samt. Om en specifik uppsättning bör användare endast läsbehörighet då jag skulle rekommendera att skapa en AD grupp eller SharePoint-gruppen med ett lämpligt beskrivande namn, t.ex. "Logistik besökare".
    –Paul G
    Svar
  5. Inget namn
    Det låter som det första du bör göra är att bara dumpa besökaren, Bidragsgivare och ägare grupper och ersätta dem med dina egna logiska grupper. Det skulle vara meningsfullt att göra?
    Svar

Lämna ett svar till Paul Liebrand Avbryt svar

Din e-postadress kommer inte att publiceras. behövliga fält är markerade *