OPPDATERINGEN 11/03/08: Les den utmerkede og detaljert kommentaren fra Dessie Lunsford til dette innlegget.

Jeg har jobbet med et hemmelig tech redigering prosjekt for en opp-kommende bok med referanser Dette bloggpost av Tyler Butler på MSDN ECM bloggen. Dette er første gang jeg leste personlig en klar definisjon av betydningen av begrenset tilgang. Her er kjøtt av definisjonen:

I SharePoint, anonyme brukere’ rettigheter bestemmes av tillatelsesnivået begrenset tilgang. Begrenset tilgang er en spesiell tillatelsesnivå som ikke kan tilordnes en bruker eller gruppe direkte. Grunnen til at det eksisterer er fordi hvis du har et bibliotek eller sekundært område som har brutt arving av tillatelser, og du gi en bruker/gruppe tilgang til bare det bibliotek/delområde, for å vise innholdet, bruker/gruppe må ha noen tilgang til det primære webområdet. Ellers kan bruker/gruppe ikke bla gjennom biblioteket/delområde, Selv om de har rettigheter der, fordi det er ting i rotområdet som trengs for å gjengi siden eller biblioteket. Derfor, Når du gir en gruppetillatelser bare for et sekundært område eller bibliotek som bryter arving av tillatelser, SharePoint gir automatisk begrenset tilgang til denne gruppen eller brukeren på rotområdet.

Dette spørsmålet kommer opp nå og da på MSDN-foraene og jeg har alltid vært nysgjerrig (men ikke nysgjerrig nok til å finne ut før i dag :)).

</slutten>

Abonner på bloggen min.

Følg meg på Twitter på http://www.twitter.com/pagalvin

I et tegn på at sosial databehandling begynner å ta av med SharePoint, Jeg ser for mitt område type spørsmål. Et vanlig spørsmål går omtrent slik:

"Jeg er en administrator og jeg trenger å få tilgang hver mitt område. Hvordan gjør jeg det?"

Trikset her er at hver mitt område er sin egen områdesamling. Sikkerheten i SharePoint er normalt administrert på områdesamlingsnivå og dette turer opp mange en SharePoint-administrator. Normalt, Hun har allerede tilgang til å konfigurere sikkerhet i "main" områdesamlinger og kan ikke forstå at dette ikke automatisk fungerer for mine områder.

Områdesamlinger bor kollektivt inne en større beholder, som er web-programmet. Gården admins kan kan konfigurere sikkerhet på web app nivå og dette er hvordan administratorer kan gi seg tilgang til en områdesamling i webprogrammet. Dette blogginnlegget beskriver en av mine personlige erfaringer med web programpolicyer. Definerte jeg en web søknad politikk ved et uhell: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!255.entry.

Web programpolicyer kan være farlig og foreslår at de brukes med måte. Hvis jeg var en admin (og gudskjelov jeg ikke), Jeg ville lage en egen AD-konto navn som "SharePoint Web App Administrator" og gi en kontoen web søknad sikkerhetsrollen må. Jeg ville ikke konfigurere denne typen ting for vanlige farmadministratoren eller enkelt område samling admins. Det vil tendere til å skjule potensielle problemer fordi rollen web app overstyrer lavere nivå sikkerhetsinnstillinger.

</slutten>

Abonner på bloggen min.

Følg meg på Twitter på http://www.twitter.com/pagalvin

OPPDATERINGEN (02/29/08): Dette nye codeplex prosjektet synes en metode for å sikre enkeltkolonner: http://www.codeplex.com/SPListDisplaySetting. Hvis du har noen erfaring med det, Legg igjen en kommentar.

Forum Plakater stille ofte et spørsmål som dette: "Jeg har utsikt manager og og personalet utsikt en liste. Hvordan sikrer jeg manager visningen slik at ansatte ikke kan bruke den?"

De spør også ofte en relaterte spørsmål: "Jeg ønsker å sikre en bestemt metadata-kolonne slik at bare administratorer kan redigere kolonnen mens andre ikke kan engang se det."

Disse svarene gjelder både WSS 3.0 og MOSS:

• SharePoint gir ikke ut av esken støtte for å sikre visninger.
• SharePoint gir ikke ut-av-støtte for sikkerhet kolonner.

Det finnes flere teknikker som kan følge for å møte slike sikkerhetskrav. Her er hva jeg kan tenke på:

• Bruke out-of-the-box sikkerhet på elementnivå. Utsikt ære alltid sikkerhet varekonfigurasjon. Hendelsesmottakere og/eller arbeidsflyt kan automatisere sikkerheten oppgave.
• Bruke personlige visninger for "privilegert" visninger. Dette er enkelt nok å sette opp. Men, på grunn av deres "personlige" natur, disse må konfigureres for hver bruker. Bruk standard sikkerhetskonfigurasjon hindre andre i å opprette en personlig visning.
• Bruke en webdelen for datavisning og implementere en slags AJAXy sikkerhetsløsning for trimming.
• Roll din egen liste utfoldelse funksjonaliteten og innlemme sikkerhetstrimming på kolonnenivå.
• Endrer dataregistreringsskjemaer og bruker JavaScript sammen med sikkerhetsmodellen implementere kolonnenivå sikkerhetstrimming.
• Bruke et InfoPath-skjema for dataregistrering. Implementere kolonnenivå sikkerhetstrimming via web service samtaler til SharePoint og betinget Skjul felt etter behov.
• Roll din egen ASP.NET data oppføring funksjon som implementerer kolonnen sikkerhetstrimming.

Ingen av disse alternativene er virkelig så stor, men det er minst en sti å følge hvis du må, Selv om det er vanskelig.

NOTE: Hvis du går ned noen av disse banene, ikke glem "handlinger-> Åpne Windows Utforsker". Du vil være sikker på at du tester med funksjonen å sørge for at det ikke fungerer som en "bakdør" og beseire din sikkerhetsoppsett.

Hvis du har andre ideer for eller erfaringer med å sikre kolonner eller visninger, vær så snill email meg eller Legg igjen en kommentar og jeg vil oppdatere dette oppslaget etter behov.

</slutten>

Abonner på bloggen min.

OPPDATERINGEN: Jeg postet dette spørsmålet til MSDN her (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) og Michael Washam av Microsoft svarte med et kort svar.

Jeg opprettet en webtjeneste til å fungere som en BDC-vennlig fasaden til en SharePoint-liste. Når jeg brukte dette fra min utviklingsmiljø, den arbeidet fin. Når jeg overført dette til en ny server, Jeg har møtt denne feilen:

Her er linjen 69:

ved hjelp av (SPSite-området = ny SPSite("http://localhost/sandbox"))

Jeg prøvde forskjellige varianter på URL-Adressen, inkludert bruk av serverens virkelige navn, IP-adressen, etterfølgende skråstrek på URL-Adressen, osv.. Jeg fikk alltid det feilen.

Jeg brukte Google forskning det. Masse folk ansikt problemet, eller varianter av det, men syntes ingen å ha den løste.

Tricksy MOSS gitt slike en detaljert feil som det ikke oppstår for meg å sjekke det 12 strukturen logger. Til slutt, om 24 timer etter min kollega anbefalt jeg gjør det, Jeg sjekket ut den 12 hive logg og fant dette:

Det oppstod et unntak under forsøk på å opprette den lokale farmen:
System.Security.SecurityException: Forespurt registertilgang tillatt ikke.
ved System.ThrowHelper.ThrowSecurityException(ExceptionResource ressurs) ved Microsoft.Win32.RegistryKey.OpenSubKey(Strengnavn, Boolsk skrivbar) ved Microsoft.Win32.RegistryKey.OpenSubKey(Strengnavn) ved Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() ved Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() ved Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& gården, Boolsk& isJoined)
Sonen for samlingen som mislyktes var:  MinDatamaskin

Dette åpnet nye muligheter for forskning, så det var tilbake til The Google. Som førte meg til dette forum stolpe: http://Forums.codecharge.com/posts.php?post_id = 67135. Som ikke virkelig hjelpe meg, men det starte gjør meg tror det var en database og/eller sikkerhet problemet. Jeg soldiered og Andrew Connell legge til slutt utløste tanken at jeg må kontrollere at programutvalget identitet kontoen hadde riktig tilgang til databasen. Jeg trodde det allerede gjorde. Men, Min kollega gikk og ga app pool identitet konto full tilgang til SQL.

Så snart hun har gjort denne endringen, Alt begynte.

Hva skjedde neste beste uttrykkes som en Haiku diktet:

Problemer heve sine hender.
Du swing og miss. prøv igjen.
Suksess! Men hvordan? hvorfor?

Hun ønsker ikke å la ting være sånn, foretrakk å gi minimumstillatelsen som kreves (og sannsynligvis bruke skrive en bloggoppføring; Jeg slo henne til slag, muhahahahaha!).

Hun fjernet etterfølgende tillatelser fra den app identitet-kontoen for programutvalg til … Det var ikke lenger eksplisitt tillatelse for app pool identitet kontoen på alle. Webtjenesten fortsatte å fungere.

Vi gikk og gjenstartet servere. Alt arbeidet fin.

Så, til oppsummering: Vi ga app pool identitet full tilgang og deretter tok det bort. Webtjenesten begynte å jobbe og aldri sluttet å virke. Bisarre.

Hvis noen vet hvorfor som bør har jobbet, Legg igjen en kommentar.

</slutten>

Jeg måtte møte i dag et sikkerhetskrav for et InfoPath-skjema. I denne virksomheten situasjonen, et relativt lite antall personer tillates å opprette et nytt InfoPath-skjema og et mye bredere publikum er tillatt å redigere. (Dette er nye-utleie on-boarding skjemaet brukes av menneskelige ressurser som starter en arbeidsflyt).

Å oppfylle dette målet, Jeg opprettet skapt to nye tillatelsesnivåer («opprette og oppdatere" og "oppdatere bare"), brøt arv for skjemabiblioteket og tillatelsene til en "lag, oppdatere" bruker og en egen "oppdatering bare" bruker. Mekanikerne alle arbeidet, men det viste seg for å være litt mer med enn jeg forventet. (Hvis du føler litt ustø på SharePoint-tillatelser, Sjekk ut denne bloggen). Nødvendig sikkerhetskonfigurasjonen for tillatelsesnivået var ikke opplagt settet med granular permission. Opprette en oppdatering bare tillatelsesnivået for et InfoPath-skjema, Jeg did det fulgte:

1. Opprett en ny tillatelse.
2. Fjerne alle alternativer.
3. Valgt bare følgende fra "Listetillatelser":

• Redigere elementer
• Vis elementer
• Vise programsider

Disse alternativene kan en bruker oppdaterer et skjema, men ikke opprettet.

Kunsten var å aktivere "Application sidene". Det er ikke noen verbage på tillatelsesnivået som angir som er nødvendig for oppdateringen bare InfoPath-skjemaer, men dreier ut det er.

Opprett og Oppdater var enda rarere. Jeg fulgte de samme trinnene, 1 gjennom 3 ovenfor. Jeg måtte legge spesielt "område tillatelse" alternativet: "Bruke funksjoner for klientintegrasjon". Igjen, beskrivelsen det gjør ikke det virke som det burde være nødvendig for et InfoPath-skjema, men det er.

</slutten>

OPPDATERINGEN 01/28/08: Dette codeplex prosjektet løser denne problem: http://www.codeplex.com/AccessChecker. Jeg har ikke brukt det, men det ser lovende Hvis dette er et problem du skal ta i ditt miljø.

OPPDATERINGEN 11/13/08: Joel Oleson skrev opp et meget godt innlegg på større sikkerhet management problemet her: http://www.sharepointjoel.com/lists/posts/post.aspx?Listen = 0cd1a63d % 2D183c % 2D4fc2% 2 D 8320% 2Dba5369008acb&ID = 113. Det linker til en rekke andre nyttige ressurser.

Forum brukere og kunder spør ofte et spørsmål langs disse linjene: "Hvordan kan jeg generere en liste over alle brukere med tilgang til et område" eller "hvordan kan jeg automatisk varsle alle brukere med tilgang til liste om endringer i listen?"

Det er ingen ut av boksen løsningen for denne. Hvis du tenker på det et øyeblikk, Det er ikke vanskelig å forstå hvorfor.

SharePoint-sikkerhet er svært fleksibel. Det er minst fire hovedkategorier av brukere:

• Anonyme brukere.
• SharePoint brukere og grupper.
• Active Directory-brukere.
• Skjemaer basert godkjenning (FBA) brukere.

Fleksibiliteten betyr at fra et sikkerhetsperspektiv, et angitt SharePoint-område vil være forskjellig fra en annen. For å generere en tilgangsrapport for liste, man trenger å fastslå hvor området er sikret, Query flere annen bruker profil repositories og deretter presentere det på en nyttig måte. Det er et vanskelig problem å løse generelt.

Hvordan organisasjoner arbeider med dette? Jeg vil gjerne høre fra deg i kommentarer eller e-post.

</slutten>

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:

• 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!