SharePoint sikkerhet grunnleggende Primer / Unngå vanlige feller

OPPDATERINGEN 12/18/07: Se Paul Liebrand artikkelen for noen tekniske konsekvenser av å fjerne eller endre standardnavn for gruppen (se hans kommentar nedenfor i tillegg).

Oversikt:

Sikkerheten i SharePoint er enkelt å konfigurere og administrere. Men, Det har vist seg for å være vanskelig for enkelte første gang administratorer å virkelig vikle hendene rundt det.. Ikke bare det, Jeg har sett noen administratorer kommer til en perfekt forståelse mandag bare å ha mistet den fredag fordi de ikke har å gjøre noe konfigurasjonen i tiden. (Jeg innrømmer å ha dette problemet selv). Dette blogginnlegget forhåpentligvis gir en nyttig SharePoint sikkerhet primer og peker mot noen anbefalte fremgangsmåter for sikkerhet-konfigurasjon.

Viktig merknad:

Denne beskrivelsen er basert på esken sikkerheten i SharePoint. Min personlige erfaring er orientert rundt MOSS så det kan være noen MOSS bestemte ting her, men jeg tror det er nøyaktig for WSS. Jeg håper at noen ser eventuelle feil eller forsømmelser vil påpeke at i kommentarer eller email meg. Jeg skal gjøre rettelser post hast.

Grunnleggende:

I forbindelse med denne oversikten, Det er fire grunnleggende aspekter sikkerhet: brukere/grupper, sikrede objekter, tillatelsesnivåer og arv.

Brukere og grupper bryte ned til:

  • Individuelle brukere: Trukket fra active directory eller opprettet direkte i SharePoint.
  • Grupper: Tilordnet direkte fra active directory eller opprettet i SharePoint. Grupper er en samling brukere. Grupper er global i en områdesamling. De bundet aldri"" til et bestemt sikret objekt.

Sikrede objekter bryte ned til minst:

  • Nettsteder
  • Dokumentbiblioteker
  • Individuelle elementer i lister og dokumentbiblioteker
  • Mapper
  • Ulike BDC-innstillinger.

Det andre sikrede objekter, men du får bildet.

Tillatelsesnivåer: En bunt av detaljert / lav tilgangsrettigheter som inkluderer slike ting som opprette/lese/slette oppføringer i lister.

Arv: Standard arver enheter sikkerhetsinnstillinger fra deres inneholdende objekt. Sekundære områder arver tillatelser fra det overordnede området. Dokumentbiblioteker arver fra deres nettsted. Så videre og så videre.

Brukere og grupper knyttet til sikrede objekter via tillatelsesnivåer og arv.

De viktigste sikkerhetsreglene å forstå, Noen gang 🙂 :

  1. Grupper er bare samlinger av brukere.
  2. Grupper er global i en områdesamling (dvs.. Det finnes ikke noe slikt som en gruppe som er definert på et områdenivå).
  3. Gruppenavn ikke motstå, grupper ikke, i og av seg selv, har et bestemt nivå av sikkerhet.
  4. Grupper har sikkerhet i forbindelse med et bestemt sikret objekt.
  5. Du kan tilordne forskjellige tillatelsesnivåer i samme gruppe for alle sikrede objekter.
  6. Web programpolicyer trumfe alt dette (se nedenfor).

Sikkerhetsadministrator mistet i et hav av gruppe- og oppføringer kan alltid stole på disse aksiomer å administrere og forstå deres sikkerhetskonfigurasjon.

Felles fallgruver:

  • Gruppenavn antyder feilaktig tillatelse: Esken, SharePoint definerer et sett av grupper med navn innebærer et iboende sikkerhetsnivå. Vurdere gruppen "Bidragsyter". En ukjent med sikkerheten i SharePoint kan også se på navnet og anta at medlemmer av gruppen kan "bidra" noen området/liste/biblioteket i portal. Det kan være sant, men ikke fordi gruppen navnet skulle "bidragsyter". Dette gjelder bare ut av boksen fordi gruppen er gitt et tillatelsesnivå som lar dem legge til/redigere/slette innholdet i rotområdet. Gjennom arv, "bidragsytere" gruppen kan også legge til/redigere/slette innhold på hver sub-området. Man kan "break" arven kjeden og endre tilgangsnivået for et delområde slik at medlemmer av den såkalte "bidragsyteren" gruppen kan ikke bidra hele, men bare lest (for eksempel). Dette ville ikke være en god idé, åpenbart, siden det ville være veldig forvirrende.
  • Gruppene defineres ikke på et områdenivå. Det er lett å bli forvirret av brukergrensesnittet. Microsoft skaffer en enkel kobling til bruker/gruppe administrasjon via hvert område "mennesker og grupper" kobling. Det er lett å tro at når jeg er på nettstedet "xyzzy" og jeg lage en gruppe gjennom xyzzy's mennesker og grupper link som jeg har nettopp opprettet en gruppe som finnes bare på xyzzy. Det er ikke tilfelle. Jeg har faktisk laget en gruppe for hele områdesamlingen.
  • Grupper medlemskap varierer ikke av nettstedet (dvs.. Det er den samme overalt gruppen brukes): Vurdere gruppen "eier" og to områder, "HR" og «Logistikk». Det ville være normalt å tenke at to separate individer ville eier disse nettstedene — HR eier og en logistikk eier. Brukergrensesnittet gjør det enkelt for en sikkerhetsadministrator mishandle dette scenariet. Hvis jeg ikke visste bedre, Jeg kan få tilgang til personer og grupper koblinger via webområdet HR, Velg "eiere" og legge min HR eier til denne gruppen. En måned senere, Logistikk kommer på linje. Jeg tilgang til personer eller grupper fra webområdet logistikk, legge til trekke opp "eiere" gruppe. Jeg ser HR eier det og fjerne henne, tenker at jeg tar henne fra eiere på området logistikk. faktisk, Jeg tar henne fra den globale eiergruppen. Hilarity følger.
  • Sviktende å Navnegrupper basert på bestemt rolle: "Godkjennere" gruppen er et perfekt eksempel. Hva kan medlemmer av denne gruppen Godkjenn? Hvor kan de godkjenne det? Jeg virkelig ønsker folk logistikk avdeling skal kunne godkjenne HR? Selvfølgelig ikke. Alltid Navnegrupper basert på deres rolle i organisasjonen. Dette vil redusere risikoen at gruppen er tilordnet et upassende tillatelsesnivå for et bestemt sikret objekt. Navnegrupper basert på deres tiltenkte rolle. I det forrige eksemplet HR/logistikk, Jeg burde ha laget to nye grupper: "HR eiere" og "logistikk eiere" og tilordne fornuftig tillatelsesnivåer for hver og minimumsbeløpet som kreves for brukere å gjøre jobben sin.

Andre nyttige referanser:

Hvis du har gjort det så langt:

Behage utleie meg vite dine tanker via kommentarer eller email meg. Hvis du vet andre gode referanser, gjør det samme!

Technorati Merkelapper:

8 tanker om “SharePoint sikkerhet grunnleggende Primer / Unngå vanlige feller

  1. Perry

    Flere fallgruver:

    * Det er visse spesialtillatelser tilgjengelig andre steder i SSPEN og ikke synlig under personer og grupper: "Personalisering tjenester tillatelser" og "forretningsdatakatalogen tillatelser"

    * Jeg har lest at det finnes også spesielle SharePoint Designer tillatelser i noen uforståelige xml begravd inne html sted.

    * Den primære og sekundære administratorer for en områdesamling holdes andre steder i områdesamlingen innstillinger, og er ikke synlig under personer og grupper.

    * Visse kontoer har magisk (spesielle) evner uansett hva du ser i mennesker og grupper: medlemmer av den innebygde gruppen Administratorer på webservere, og gården tjenestekontoen.

    (PS: Slette spam kommentarer vil forbedre lesbarheten her.)

    Svar
  2. Jean Wright
    Dette er et meget godt innlegg. Jeg har falt i denne fellen ved et par anledninger. Sikkerhetsadministrasjon får komplekse når du begynner å blande godkjenningsmetoder og ulike sikkerhet gruppering metoder. Dette må betraktes som en del av planleggingsprosessen og bør ikke overses.
    Svar
  3. Mark Miller skrev:
    (Notat fra Paul: Mark ba meg om å gjøre en liten endring i sin kommentar, men jeg kan ikke redigere live spaces kommentarer så jeg har lagt det på nytt her med endringen og slette opprinnelige).
    Paul,
    Sammendrag tilnærming for å presentere denne informasjonen kom ut veldig bra. Jeg likte spesielt "fallgruvene" delen, siden jeg har falt i noen av disse selv.
    En annen ting du sa hit hjem: læring mandag betyr ikke nødvendigvis du husker det fredag. Jeg er glad noen foruten meg bruker sin blogg som en "tickler" systemet for dem kritisk tingene som ikke utføres regelmessig.
    Godt arbeid.
    Hilsen,
    Mark
    EndUserSharePoint.com

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

    Svar
  4. Paul Galvin
    Jeg tror det er sannsynligvis lurt å fjerne disse standardgrupper, spesielt bidragsyter og eier. De er overbroad og forvirret lett. Jeg foretrekker å bruke "alle godkjente brukere" i stedet for "besøkende" gruppen også. Hvis et bestemt sett med bør brukere bare lesetilgang så ville jeg anbefale å opprette en annonsegruppe eller SharePoint-gruppe med riktig beskrivende navn, f.eks. "Logistikk besøkende".
    –Paul G
    Svar
  5. Ingen navn
    Det høres ut som det første du bør gjøre er bare dumpe besøkende, Bidragsyter og eier og erstatte dem med dine egne logiske grupper. Dette fornuftig å gjøre?
    Svar

Avreise en svar til Paul Liebrand Avbryt svar

e-postadressen din vil ikke offentliggjøres. Obligatoriske felt er merket *