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 🙂 :
- Grupper er bare samlinger av brukere.
- Grupper er global i en områdesamling (dvs.. Det finnes ikke noe slikt som en gruppe som er definert på et områdenivå).
- Gruppenavn ikke motstå, grupper ikke, i og av seg selv, har et bestemt nivå av sikkerhet.
- Grupper har sikkerhet i forbindelse med et bestemt sikret objekt.
- Du kan tilordne forskjellige tillatelsesnivåer i samme gruppe for alle sikrede objekter.
- 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:
- Web søknad politikk fikser: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
- Clearinghuset for sikkerheten i SharePoint: http://www.sharepointsecurity.com/
- Lenker fra Joel Olesøn: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx
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!
hei,
Flott blogg med interessant informasjon.
Jeg kan bruke det t oppklare meg problem.
Thanx
M.
http://www.vanjobb.hu/
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.)
Vel tror jeg at utformingen av bloggen din er veldig interessant.
hei, Mitt navn er John, og nettstedet mitt http://geocities.com/whitejohn29/
November 27 9:04 AM
(http://www.EndUserSharePoint.com)