SharePoint Security Fundamentals Primer / Gemeenschappelijke valkuilen te vermijden

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:

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!

Technorati Tags:

8 gedachten over "SharePoint Security Fundamentals Primer / Gemeenschappelijke valkuilen te vermijden

  1. Perry

    Meer valkuilen:

    * Er zijn bepaalde speciale machtigingen beschikbaar elders in de SSP en niet zichtbaar in de sectie personen en groepen: "Machtigingen voor personalisatie services" en "machtigingen van de catalogus met zakelijke gegevens"

    * Ik heb gelezen dat er ook speciale SharePoint Designer machtigingen beschikbaar in sommige geheimzinnige xml begraven in html ergens zijn.

    * De primaire en secundaire beheerders van een siteverzameling worden elders bewaard in een siteverzameling instellingen, en zijn niet zichtbaar in de sectie personen en groepen.

    * Bepaalde accounts hebben magische (speciale) capaciteiten ongeacht wat je op het gebied van personen en groepen ziet: leden van de ingebouwde groep Administrators op de web-servers, en een Account voor de boerderij.

    (PS: Verwijderen van spam comments zou verbeteren leesbaarheid hier.)

    Antwoord
  2. Jean Wright
    Dit is een zeer goede post. Ik heb gevallen in deze val bij een paar gelegenheden. Veiligheidsbeheer kunt complexe krijgen wanneer u begint met het mengen van verificatiemethoden en ander beveiligingsniveau groepering methoden. Dit moet worden beschouwd als onderdeel van het planningsproces en moet niet over het hoofd worden gezien.
    Antwoord
  3. Mark Miller schreef:
    (Opmerking van Paul: Mark vroeg me om een kleine wijziging aanbrengen in zijn commentaar, maar ik kan niet levende ruimten opmerkingen bewerken zodat ik heb toegevoegd het opnieuw hier met de verandering en verwijderd het origineel).
    Paul,
    De samenvatting aanpak voor de presentatie van deze info kwam uit zeer goed. Ik vond vooral de valkuilen"" sectie, Aangezien ik in een paar van die mezelf gevallen heb.
    Een ander ding die u zei getroffen huis: leren op maandag niet noodzakelijkerwijs betekent niet dat u het zult herinneren op vrijdag. Ik ben blij dat iemand naast me is het gebruik van hun blog als een "tickler" systeem voor deze kritische dingen die niet worden gedaan op een regelmatige basis.
    Goed werk.
    Groeten,
    Mark
    EndUserSharePoint.com

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

    Antwoord
  4. Paul Galvin
    Ik denk dat het waarschijnlijk een goed idee om te verwijderen die standaard-groepen, met name Inzender en eigenaar. Ze zijn overbroad en gemakkelijk verward. Verkies ik te gebruiken "alle geverifieerde gebruikers" in plaats van een 'bezoeker" groep ook. Als een specifieke van set moeten gebruikers alleen read-only toegang, dan zou ik adviseren een advertentiegroep of SharePoint-groep maken met een op de juiste wijze beschrijvende naam, bijvoorbeeld. "Logistiek bezoekers".
    –Paul G
    Antwoord
  5. Geen naam
    Het klinkt als het eerste wat dat u moet doen is gewoon dumpen de bezoeker, Groepen Inzender en eigenaar en vervang ze met uw eigen logische groepen. Dit zou zinvol om te doen?
    Antwoord

Laat een antwoord achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd *