SharePoint-rechten inrichten lijkt een kwestie van een paar vinkjes. Toch ontstaan de meeste rechtenproblemen niet door één verkeerde klik, maar door de manier waarop SharePoint is ingericht.
Hoe het fout gaat
- een afgeschermde omgeving voor het eigen team;
- een omgeving die iedereen mag lezen, maar alleen het team mag bewerken;
- tijdelijke samenwerking met andere teams en collega’s;
- extra bescherming voor vertrouwelijke informatie.
De functioneel beheerder kent het uitgangspunt: stel rechten bij voorkeur niet in op afzonderlijke mappen of bestanden. Maar als alles in één site moet staan, ontstaat bijna vanzelf een groeiend stelsel van uitzonderingen.
Na verloop van tijd is niet meer duidelijk wie toegang heeft, waarom die toegang is verleend en wanneer tijdelijke rechten moeten worden verwijderd.
Met Microsoft Copilot wordt te ruime toegang bovendien sneller zichtbaar. Copilot doorbreekt geen rechten, maar kan wel informatie vinden, combineren en samenvatten waarvoor een gebruiker toegang heeft. Ook wanneer die toegang ooit per ongeluk of om een inmiddels vergeten reden is toegekend.
Een beheersbare rechtenstructuur begint daarom niet bij machtigingen, maar bij de informatiearchitectuur.
SharePoint-rechten inrichten: wat is de beste aanpak?
De belangrijkste regel is eenvoudig:
Plaats structurele toegang op het hoogste niveau waarop doelgroep, eigenaarschap en levenscyclus gelijk zijn.
Dat betekent: rechten bij voorkeur op een site instellen, waar nodig op een bibliotheek en alleen bij uitzondering op een map of bestand.
1. Begin met een logische SharePoint-architectuur
Moderne SharePoint-omgevingen worden bij voorkeur opgebouwd uit zelfstandige sites met ieder een duidelijk doel. Gerelateerde sites kunnen via een hubsite worden verbonden voor navigatie, uitstraling, contentaggregatie en zoeken.
Een hubsite verandert de rechten van aangesloten sites niet. Iedere site houdt zijn eigen leden, eigenaren en machtigingen. Een hubsite zorgt dus voor samenhang, niet voor beveiliging.
Niet ieder onderwerp heeft een eigen site nodig. De combinatie van doelgroep, eigenaarschap, vertrouwelijkheid en levenscyclus bepaalt welk niveau passend is.
Binnen een site kun je meerdere bibliotheken gebruiken voor content met een ander doel, proces of beveiligingsniveau. Gebruik metadata, contenttypen en weergaven om documenten logisch te ordenen. Mappen zijn niet verboden, maar diepe en inconsistente mapstructuren maken beheer en vindbaarheid onnodig complex.
Meer over dit architectuurprincipe staat in Planning your SharePoint hub sites.
2. SharePoint-rechten inrichten op het hoogste niveau
Hoe hoger in de structuur je rechten instelt, hoe beter ze zichtbaar en controleerbaar blijven.
| Niveau | Geschikt voor | Advies |
|---|---|---|
| Site | Een herkenbare groep die structureel samenwerkt | Voorkeursniveau |
| Bibliotheek | Een afgebakend onderdeel met een afwijkende doelgroep | Beheersbare uitzondering |
| Map | Een beperkt en herhaalbaar beveiligingsscenario | Alleen bewust toepassen |
| Bestand | Incidentele of tijdelijke toegang | Zo veel mogelijk beperken |
Wanneer je de overerving op een map of bestand doorbreekt, ontstaat een unieke rechtenset, in Microsoft-documentatie een permission scope genoemd.
Een bibliotheek kan technisch maximaal 50.000 unieke rechtensets bevatten. Microsoft adviseert om voor goede prestaties onder de 5.000 te blijven. Bestanden die rechten erven van dezelfde bovenliggende map delen één rechtenset en tellen niet ieder afzonderlijk mee.
De technische limiet is echter niet het grootste risico. Het echte probleem ontstaat wanneer niemand meer kan uitleggen waar de uitzonderingen staan, waarom ze bestaan en wie ze moet controleren.
Merk je dat binnen één bibliotheek steeds meer mappen moeten worden afgeschermd? Dan is dat meestal een signaal dat de informatie beter in een aparte bibliotheek of site past.
Lees meer in Manage permission scopes in SharePoint.
3. Zijn maprechten altijd verkeerd?
Nee. Maprechten kunnen bruikbaar zijn als ze onderdeel zijn van een bewust en herhaalbaar ontwerp.
Denk aan een bouwproject waarin een architect, constructeur, installateurs en onderaannemers samenwerken. Iedere partij mag slechts een deel van de projectinformatie zien.
Gebruik bij voorkeur een aparte projectsite wanneer het project een eigen deelnemersgroep, vertrouwelijkheid of levenscyclus heeft. Binnen die site kun je werken met bibliotheken voor stabiele doelgroepen en een gedeelde bibliotheek voor informatie die alle partijen mogen zien.
Zijn unieke maprechten toch noodzakelijk? Zorg dan dat:
- vergelijkbare projecten dezelfde structuur krijgen;
- rechten via een beheerde provisioningoplossing worden ingesteld;
- structurele toegang via groepen loopt;
- de inrichting en uitzonderingen zijn vastgelegd;
- tijdelijke toegang en gasttoegang periodiek worden gecontroleerd;
- rechten bij het afsluiten van een project worden opgeschoond.
Het verschil zit dus niet alleen in het niveau waarop rechten staan. Het gaat er vooral om of het model voorspelbaar, herhaalbaar en controleerbaar is.
4. Beheer structurele toegang via groepen
Ken structurele rechten bij voorkeur toe via Microsoft 365-groepen, SharePoint-groepen of Microsoft Entra ID-beveiligingsgroepen. Vermijd rechtstreekse toekenningen aan individuele medewerkers.
Als het groepslidmaatschap centraal en actueel wordt beheerd, werken wijzigingen automatisch door naar alle SharePoint-locaties waaraan de groep toegang heeft. Dat voorkomt dat een vertrekkende medewerker op verschillende plekken handmatig moet worden verwijderd.
Individuele toegang kan nodig zijn voor een tijdelijke uitzondering. Houd zulke uitzonderingen beperkt en controleerbaar.
Zorg daarnaast dat iedere site minimaal twee actieve eigenaren heeft. Zo blijft de omgeving beheersbaar bij ziekte, vakantie, functiewijziging of vertrek.
5. Gebruik SharePoint, Teams en OneDrive voor het juiste doel
Veel rechtenproblemen ontstaan doordat persoonlijk werk, structurele samenwerking en publicatie op dezelfde plek terechtkomen.
Gebruik OneDrive voor persoonlijk conceptwerk en beperkte, tijdelijke samenwerking waarbij één medewerker de logische eigenaar is. Gebruik een Teams-team of SharePoint-teamsite zodra informatie van een groep of organisatie is, meerdere eigenaren nodig heeft of langdurig beschikbaar moet blijven.
Gebruik een communicatiesite voor informatie die een kleine groep auteurs publiceert voor een brede doelgroep, zoals beleid, procedures en formats.
Een Teams-vergadering is geen zelfstandige opslagomgeving. Bepaal daarom bewust waar agenda’s, vergaderstukken, besluiten, opnames en verslagen worden bewaard.
6. Geef vertrouwelijke informatie een eigen plek
HR-dossiers, directieoverleggen, juridische stukken en ongevalsrapportages horen niet thuis in een algemene samenwerkingsomgeving.
Gebruik voor vertrouwelijke informatie bij voorkeur een eigen site met een beperkte doelgroep, beheerde groepen, minimaal twee eigenaren en restrictieve instellingen voor delen.
Een standaardlabel op een bibliotheek kan worden toegepast op nieuwe bestanden, uploads en bestaande bestanden die opnieuw worden bewerkt. Bestaande bestanden die onaangeroerd in de bibliotheek staan, worden niet automatisch allemaal gelabeld.
Meer informatie vind je in:
- Sensitivity labels for groups and sites
- Configure a default sensitivity label for a SharePoint document library
7. Geef voor aanleveren niet onnodig toegang
Iemand die alleen een document moet aanleveren, hoeft niet automatisch toegang te krijgen tot een volledige site of bibliotheek. Voor interne medewerkers kan bijvoorbeeld Microsoft Forms met bestandsupload geschikt zijn. Voor externe aanlevering kan Bestanden aanvragen in SharePoint of OneDrive een oplossing zijn.
Het uitgangspunt is belangrijker dan de techniek: geef iemand niet meer toegang dan nodig is om de taak uit te voeren.
Bij Bestanden aanvragen kan de aanleverende persoon bestanden uploaden zonder de andere bestanden in de map te kunnen bekijken. Deze functionaliteit is afhankelijk van de instellingen voor Iedereen-links binnen de Microsoft 365-omgeving.
8. Houd deellinks beheersbaar
Niet iedere deellink werkt hetzelfde.
Een link voor Mensen met bestaande toegang verleent geen nieuwe toegang. Een link voor Mensen in je organisatie kan worden gebruikt door iedereen binnen de organisatie die de link ontvangt. Een link voor Specifieke personen werkt alleen voor de opgegeven ontvangers.
Stel daarom waar passend Specifieke personen in als standaardtype deellink. Dit kan op organisatie- en siteniveau. Welke ruimere linktypen gebruikers nog kunnen kiezen, hangt af van het maximaal toegestane niveau voor delen.
Wees terughoudend met brede deellinks, organisatiebrede groepen en links zonder einddatum. Als Iedereen-links noodzakelijk zijn, stel dan waar mogelijk een passende maximale geldigheidsduur in.
Leg gebruikers bovendien uit dat delen niet alleen betekent dat je iemand een URL stuurt. Afhankelijk van het gekozen linktype kan ook nieuwe toegang worden verleend.
Zie Change the default sharing link type for a site.
9. Governance voorkomt wildgroei
De angst voor wildgroei is vaak een reden om zo min mogelijk sites toe te staan. Maar één grote site lost wildgroei niet op. De complexiteit verschuift alleen naar bibliotheken, mappen, groepen en uitzonderingen.
Goed governancebeleid begint voordat een site wordt aangemaakt. Spreek af wie sites mag aanvragen en goedkeuren, werk met herkenbare sjablonen en naamgeving en wijs direct minimaal twee eigenaren aan.
Laat eigenaren periodiek beoordelen of de site nog nodig is en of leden, gasten, deellinks en beveiligingsinstellingen nog kloppen. Stem de frequentie af op het risico. Een vertrouwelijke site of externe projectomgeving vraagt vaker om controle dan een reguliere interne site.
Regel ook wat er gebeurt wanneer een project of samenwerking stopt. Bepaal of de site alleen-lezen wordt, wordt gearchiveerd of uiteindelijk verwijderd. Verwijder toegang en deellinks die niet langer nodig zijn.
10. Controleer op oversharing bij het gebruik van Copilot
Copilot verandert het rechtenmodel van SharePoint niet, maar vergroot wel het belang van een goed rechtenmodel. Copilot kan informatie waarvoor een gebruiker toegang heeft gemakkelijker vinden, combineren en samenvatten
De Data Access Governance-rapporten binnen SharePoint Advanced Management kunnen, afhankelijk van de beschikbare licenties en functies, inzicht geven in brede gebruikerstoegang, activiteit met deellinks en toegang via zeer ruime groepen.
Een rapport is geen automatisch bewijs dat een site verkeerd is ingericht. Een intranetsite kan bewust voor de hele organisatie toegankelijk zijn. Gebruik de rapportages om afwijkingen te vinden en onderzoek daarna de context, de bedoelde doelgroep en de onderliggende machtigingen.
Meer informatie staat in Data Access Governance reports.
Terug naar de praktijk
Wat betekent dit voor de beheerder uit het begin van dit artikel?
Als één SharePoint-site echt een harde randvoorwaarde is, werk dan met een beperkt aantal duidelijk afgebakende bibliotheken en beheer structurele toegang via groepen. Voorkom dat voor ieder team en ieder nieuw scenario weer afwijkende maprechten ontstaan.
Hoe langer de uitzonderingen doorgroeien, hoe moeilijker de rechtenstructuur later nog uit te leggen en op te schonen is.
Checklist: SharePoint-rechten inrichten
Architectuur
- Heeft iedere site een duidelijk doel en herkenbare eigenaar?
- Staat informatie met een afwijkende doelgroep, vertrouwelijkheid of levenscyclus op een passende eigen plek?
Rechten
- Staat structurele toegang op het hoogst passende niveau?
- Worden structurele rechten via groepen beheerd?
Delen en vertrouwelijkheid
- Zijn brede deellinks beperkt en waar nodig voorzien van een einddatum?
- Hebben vertrouwelijke gegevens een eigen beveiligingszone en passende labels?
Governance
- Worden eigenaren, leden, gasten en uitzonderingen periodiek gecontroleerd?
- Worden oude sites en tijdelijke rechten daadwerkelijk opgeruimd?
De gouden regel voor SharePoint-rechten
Plaats structurele toegang op het hoogste niveau waarop doelgroep, eigenaarschap en levenscyclus gelijk zijn. Bij voorkeur op de site, waar passend op de bibliotheek en alleen op een map of bestand als bewuste, beperkte en controleerbare uitzondering.
Hoe zijn de SharePoint-rechten binnen jullie organisatie ingericht? Herken je de discussie over één grote site, of hebben jullie inmiddels gekozen voor een beter beheersbare architectuur?