UPDATE 12/18/07: Zie Paul Liebrand van artikel voor sommige technische gevolgen van het verwijderen of veranderen van de standaard groepsnamen (Zie hieronder zijn commentaar zo goed).

Overzicht:

SharePoint veiligheid is eenvoudig te configureren en beheren. Echter, het heeft bewezen te zijn moeilijk voor sommige beheerders eerst echt hun handen eromheen laten teruglopen. Niet alleen dat, Ik heb sommige beheerders komen tot een perfect begrip op maandag alleen te hebben verloren door vrijdag, omdat ze niet hoefde te doen elke configuratie in de tussenliggende tijd. (Ik geef toe aan het hebben van dit probleem zelf). Deze blog entry hopelijk biedt een nuttig SharePoint veiligheid primer en verwijst naar sommige beveiliging configureren-aanbevolen procedures.

Belangrijke opmerking:

Deze beschrijving is gebaseerd op uit de doos SharePoint veiligheid. Mijn persoonlijke ervaring is gericht rond MOSS zodat er enkele MOSS specifieke dingen hier wellicht, maar ik denk dat het juist voor WSS. Ik hoop dat iedereen zien eventuele fouten of omissies die zal erop wijzen in commentaren of e-mail me. Ik maak correcties post haast.

Grondbeginselen:

Voor de toepassing van dit overzicht, Er zijn vier fundamentele aspecten voor de veiligheid: gebruikers/groepen, beveiligbare objecten, machtigingsniveaus en overerving.

Gebruikers en groepen breken neer:

• Individuele gebruikers: Getrokken uit active directory of gemaakt direct in SharePoint.
• Groepen: Toegewezen rechtstreeks uit active directory of gemaakt in SharePoint. Groepen zijn een verzameling van gebruikers. Groepen zijn globaal in een siteverzameling. Ze zijn nooit "gebonden" voor een bepaald beveiligbaar object.

Beveiligbare objecten breken neer aan ten minste:

• Sites
• Documentbibliotheken
• Afzonderlijke items in lijsten en documentbibliotheken
• Mappen
• Verschillende BDC instellingen.

Er andere beveiligbare objecten, maar je krijgt het beeld.

Machtigingsniveaus: Een bundel van granulaire / lage niveau toegangsrechten die zaken als maken/lezen/verwijderen items in lijsten behoren.

Overname: Standaard overnemen entiteiten beveiligingsinstellingen van hun waarin het andere object. Subsites overnemen machtigingen van hun bovenliggende. Documentbibliotheken overnemen van hun site. Enzovoort enzovoort.

Gebruikers en groepen hebben betrekking op beveiligbare objecten via machtigingsniveaus en overerving.

De belangrijkste veiligheidsvoorschriften te begrijpen, Ever 🙂 :

1. Groepen zijn gewoon verzamelingen van gebruikers.
2. Groepen zijn globale binnen een siteverzameling (dwz. Er is niet zoiets als een groep die wordt gedefinieerd op het niveau van een site).
3. Groepsnaam niet weerstaan, groepen niet, in en van zichzelf, hebben een bepaald niveau van beveiliging.
4. Groepen hebben veiligheid in het kader van een bepaald beveiligbaar object.
5. U kunt verschillende machtigingsniveaus toewijzen aan de dezelfde groep voor elk beveiligbare object.
6. Web toepassingenbeleid troef dit alles (Zie hieronder).

Beveiligingsbeheerders verloren in een zee van groeps- en aanbiedingen kunnen altijd rekenen op deze axioma's te beheren en te begrijpen hun Beveiligingsconfiguratie.

Gemeenschappelijke valkuilen:

• Groepsnamen impliceren ten onrechte toestemming: Out of the box, SharePoint definieert een set van groepen waarvan de namen een inherente beveiligingsniveau impliceren. Beschouwen de groep 'Contributor'. Een onbekend met SharePoint beveiliging kan goed kijken naar die naam en ga ervan uit dat elk lid van die groep kan "bijdragen" op elke site/lijst/bibliotheek in het portaal. Dat mag waar zijn, maar niet omdat de naam van de groep gebeurt te zijn 'contributor'. Dit is alleen waar out of the box, omdat de Fractie heeft gekregen een machtigingsniveau dat hen in staat te toevoegen/bewerken/verwijderen inhoud op de hoofdsite stelt. Via overname, de 'contributies" groep kan ook toevoegen/bewerken/verwijderen inhoud op elke sub site. Een kunt "break" de overervingsketen en wijzig het machtigingsniveau van een dergelijke sub-site dat leden van de zogenaamde 'Contributor" groep niet kan helemaal dragen, maar alleen lezen (bijvoorbeeld). Dit zou niet een goed idee, Uiteraard, omdat het zou erg verwarrend.
• Groepen worden niet gedefinieerd op het niveau van een site. Het is gemakkelijk om worden verward door de user interface. Microsoft biedt een handige koppeling naar gebruiker/groep beheer via elke site "mensen en groepen" koppeling. Het is gemakkelijk om te geloven dat als ik op de site "xyzzy" en ik maak een groep door xyzzy van mensen en groepen koppelen die ik heb zojuist een groep die alleen bestaat bij xyzzy. Dat is niet het geval. Ik heb eigenlijk gemaakt een groep voor de hele siteverzameling.
• Lidmaatschap van groepen verandert niet door site (dwz. het is hetzelfde overal die de groep wordt gebruikt): Beschouwen de groep "eigenaar" en twee sites, "HR" en "Logistics". Het zou normaal te denken dat twee afzonderlijke individuen die sites zou zelf — de eigenaar van een HR en een logistiek. De user interface maakt het gemakkelijk voor een beveiligingsbeheerder behandel dit scenario. Als ik niet beter wist, Ik kan toegang tot de personen en groepen links via de HR-site, Selecteer de "eigenaars" groep en mijn HR-eigenaar aan die groep toevoegen. Een maand later, Logistiek komt op regel. Ik heb toegang tot personen en groepen van de logistieke site, trekken van de "eigenaars toevoegen" groep. Ik zie er de HR-eigenaar en haar verwijderen, denken dat ik ben haar het verwijderen van eigenaars op de logistieke site. Eigenlijk, Ik ben het verwijderen van haar uit de globale groep eigenaren. Hilariteit ontstaat.
• Bij gebreke aan naam groepen op basis van specifieke rol: De fiatteurs"" groep is een perfect voorbeeld. Wat kunnen leden van deze groep goedkeuren? Waar kunnen ze het goedkeuren? Wil ik echt mensen logistieke afdeling voor zitten kundig voor HR documenten goedkeuren? Natuurlijk niet. Altijd naam groepen op basis van hun rol binnen de organisatie. Dit zal verminderen het risico dat de groep een ongepaste machtigingsniveau voor een bepaald beveiligbaar object is toegewezen. Naam groepen op basis van hun beoogde rol. In het vorige scenario van de HR/logistiek, Ik heb twee nieuwe groepen: "HR eigenaren" en logistiek eigenaren"" en verstandige machtigingsniveaus voor elk en het minimale bedrag dat vereist is voor gebruikers om hun werk te doen toewijzen.

Andere nuttige verwijzingen:

• Web toepassing beleid gotcha: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!255.entry
• Clearinghouse voor SharePoint beveiliging: http://www.sharepointsecurity.com/
• Links van Joel Oleson: http://blogs.msdn.com/joelo/archive/2007/08/23/sharepoint-security-and-compliance-resources.aspx

Als je dit hebt gemaakt veel:

Gelieve te laten me weten wat uw gedachten via de opmerkingen of e-mail me. Als u weet van andere goede referenties, Doe hetzelfde!