Office Groups, wanneer wel en wanneer niet?

Er zijn in het ‘moderne’ Office 365 landschap verschillende manieren van toegang verlenen voor gebruikers. Het inrichten van het permissiemodel is een fundamentele keuze en daarom erg belangrijk. Goed om duidelijk te hebben welke consequenties die keuze heeft. Wellicht dat dit artikel kan helpen in het uitwerken van deze keuzes.

Als je naar SharePoint kijkt, is er een tweetal type sites te onderscheiden:

  • Samenwerken binnen een groep (in de brede zin van het woord);
  • Publiceren van content, denk hierbij aan portalen of publicatie van documenten voor inzage.

Samenwerken binnen een groep

Bij het samenwerken binnen een groep, is het verstandig vast te houden aan de architectuur van Office Groups. Office Groups zijn als het ware beveiligingsgroepen in de AAD (Azure Active Directory), waarin de permissies voor die groep te beheren is. Dit heeft grote voordelen als het gaat om beheersbaarheid, maar ook de toegang, omdat het overweg kan met de functies binnen de AAD en zaken als conditional access en identity management.

groups_5
Voorbeeld van een Office Group in de AAD

Je kan de groepen beschouwen als onderdeel van IDM (het mechanisme/proces waarmee je gebruikers beheert), waarmee de controle in inzichten mee kunnen liften met de AAD. Office Groups hebben één groot punt waarmee rekening gehouden moet worden, namelijk dat er twee type permissies ingesteld kunnen worden:

  • Eigenaren (welke controle hebben over de groep) en,
  • Leden (welke bewerk rechten hebben, dus niet alleen bijdragen). In de praktijk komt het dus neer dat leden bijvoorbeeld rechten hebben om in SharePoint lijsten te bewerken.
groups_3
Groepslidmaatschap is beperkt tot Eigenaren en Leden

Tevens is er geen functionaliteit voor ‘bezoekers’. Binnen de SharePoint site welke gekoppeld is aan een Office Group, is het uiteraard wel mogelijk om bezoekers toe te voegen (en andere specifieke rechten). Hou er in dat geval rekening mee dat je deze niet middels de AAD kunt beheren, en deze ook geen doorwerking hebben op bijvoorbeeld Teams of Planner, welke ook gekoppeld kunnen zijn aan dezelfde Office Group.

Hoewel dit dus allemaal mogelijk is, zou dit een bewuste keuze moeten zijn, bijvoorbeeld vanuit het oogpunt van transparantie (open, tenzij). Hou er in dat geval ook rekening mee dat gebruikers die alleen leesrechten hebben, ook geconfronteerd worden met bijvoorbeeld meer resultaten uit de zoekfunctie en mogelijk andere zaken die als ‘vervuilend’ bestempeld kunnen worden door de gebruiker. Het advies hierin is dit ook beperkt toe te passen binnen Office Group gekoppelde sites, ook vanuit het security oogpunt (wat als iemand gevoelige informatie deelt binnen een groep?).

groups_4
Toch ook sitebezoekers, maar dit zijn de SharePoint beveiligingsgroepen!

Binnen Office Groups is het mogelijk om verschillende ‘privacy’ niveaus aan te houden. Grofweg zijn er hierbij 3 mogelijke opties:

  • Privé. Leden moeten hierbij worden toegevoegd door de eigenaar. Dit is de meest logische keuze als je samenwerk in groepen.
  • Openbaar. Leden mogen zichzelf hierbij als lid toevoegen. Dit zou een logische keuze zijn als je bijvoorbeeld wilt samenwerken in een community of een thema, waarbij de leden ook content mogen bewerken/toevoegen.
  • Company-wide (alleen door admin in te stellen). Hierbij worden alle leden automatisch toegevoegd aan de groep, ook als er nieuwe users worden aangemaakt. Denk hierbij aan een bedrijfs-brede community (of vergelijk het met een Yammer groep, waarbij iedereen standaard lid is).
groups_2
Keuze voor privacyinstellingen

Bij het instellen van het niveau, is het ook goed om de link te leggen naar de consequenties in Teams (als je deze gebruikt). Zo is het gebruik van het gekoppelde Team weer specifiek in te regelen in Teams zelf. Denk bijvoorbeeld aan het beperken van aanmaken van kanalen, of het mogen verwijderen van chats, etc.. Vaak zie ik in de praktijk dat de ‘Privé’ groepen de standaard zijn.

Publiceren van content

Voor sites met een publicerend karakter (intranet, portalen, documentpublicatie, etc.), is het verstandiger om geen Office Group te gebruiken, maar een losse SharePoint site. Vaak zijn er bij dit soort sites ook geen Planner of Team nodig en voldoet SharePoint alleen. Kies in deze gevallen om een Communicatiesite, of een moderne teamsite zonder Office Group (sinds kort mogelijk). Let daarbij ook dat de rechten dus niet meer vanuit de AAD geregeld worden, maar vanuit de permissies in SharePoint zelf, zoals ‘vroeger’ ook het geval al was. Advies hierbij is na te denken over een ‘publicatie’ team (groep content beheerders) en een bezoekers groep (standaard bezoekersgroep). Probeer niet af te wijken van de standaard permissies die SharePoint biedt, omdat dit in de praktijk altijd tot problemen gaat leiden.

Ook is het verstandig een model te hanteren met uniforme rechten binnen de site collectie. Probeer, indien het gewenst is verschillende rechten niveaus te hanteren, ervoor te kiezen dit in een nieuwe site collectie te doen, en deze site collecties middels een Hub Site te koppelen. Zo blijft de rechtenstructuur beheersbaar en transparant.

groups_6
Probeer gebroken rechten te vermijden binnen een site collectie. Een hubsite zou een alternatief kunnen zijn.

Governance

Verstandig is de keuzes (wanneer gebruik je wat, en hoe dan) vast te leggen in een governance, zodat iedereen weet en kan lezen hoe jullie SharePoint en Teams inzetten en welke keuzes er hier zijn gemaakt. Denk hierbij ook na over de lifecycle van vooral Office Groups (publicaties sites zullen vaak permanent zijn). Als gebruikers zelf groepen (en Teams) mogen gaan aanmaken, kan dit leiden tot veel Office Groups, waarbij sommigen wellicht nooit gebruikt worden. Hoewel er een limiet is van 500.000 site collecties per tenant, het is het verstandig hier vanaf dag 1 rekening mee te houden. De AAD biedt hiervoor een mechanisme, maar je zou het ook in een proces kunnen vangen.

Als archivering hierbij een rol speelt, kijk dan vooral naar de retentielabels in het compliance center. Hiermee borg je op centraal niveau de bewaartermijnen en daarmee het beleid dat je wilt voeren.

2 gedachtes over “Office Groups, wanneer wel en wanneer niet?

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit /  Bijwerken )

Google photo

Je reageert onder je Google account. Log uit /  Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit /  Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit /  Bijwerken )

Verbinden met %s