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:
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.
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:
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?).
Binnen Office Groups is het mogelijk om verschillende ‘privacy’ niveaus aan te houden. Grofweg zijn er hierbij 3 mogelijke opties:
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.
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.
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.
In deel 1 van deze serie blog postings, heb ik aangegeven dat veel inrichtingen die in SharePoint gedaan zijn, gebaseerd zijn op metadata modellen. Bij Microsoft zijn ze er inmiddels achter dat dit voor veel gebruikers als lastig wordt ervaren en in vele inrichtingen gaat dit het doel dan ook voorbij. Er is daarom besloten een aantal zaken anders aan te pakken, waardoor het voor de gebruiker een stuk eenvoudiger wordt. Dit is best een verandering; een aantal principiële uitgangspunten wordt namelijk in twijfel getrokken:
Het grote uitgangspunt binnen Office 365 is dat het niet meer uit maakt wat voor content op welke plek staat, zolang je de content maar classificeert. Dit classificeren kan op verschillende manieren. Een van deze manieren het is het classificeren van de Office Group (met daarbij de SharePoint site). Het is standaard mogelijk om een Group een ‘classificatie label’ mee te geven, waardoor Office 365 bewust wordt van het feit dat de content in deze Group van een bepaalde gevoeligheid is.
Met de gevoeligheid van content wordt bedoeld dat duidelijk is wat het effect is van bijvoorbeeld een datalek van de content. Wat is de ‘schade’ (in kosten, in reputatie, in wetgeving) als de content gelekt wordt naar personen die het niet zouden mogen zien. Denk bijvoorbeeld aan het lekken van persoonsgegevens, e-mail uitwisseling over bedrijfsovernames of beursgang van een organisatie. De effecten daarvan kunnen enorm zijn!
Veel (grotere) organisaties hebben daarom een classificering van gegevens opgesteld. Bijvoorbeeld: openbaar, intern, vertrouwelijk en geheim. Hierbij worden regels ofwel beleid opgesteld over wat er met deze content wel en niet mag. Zo mag vertrouwelijke content bijvoorbeeld niet gedeeld worden met externen of moet geheime informatie versleuteld zijn.
Dit beleid kan worden vertaald naar een inrichting in Office 365, maar daarvoor moeten we wel eerst goed weten hoe dat beleid er uit ziet. Zo kan het bijvoorbeeld zijn dat er nog verschillende gradaties zijn in vertrouwelijke informatie. Bijvoorbeeld ‘persoonsgegevens’ mogen niet gedeeld worden met externen, maar moeten ook vernietigd worden binnen 1 jaar. Of: ‘jaarverslagen’ mogen alleen door het management ingezien worden, maar mogen 7 jaar niet verwijderd worden.
Het is daarom van belang dat deze differentiaties in kaart gebracht worden. Als voorbeeld de volgende indeling:
Let wel: dit is een voorbeeld en (waarschijnlijk) geen complete lijst. Dit is uiteraard organisatieafhankelijk, maar in ons geval voldoet het als voorbeeld.
Het is nu mogelijk om op basis van deze classificatie indeling, Office Groups te gaan classificeren. Om dit te doen kan er met behulp van een Powershell commando worden aangegeven welke classificaties er beschikbaar zijn, wat de omschrijvingen zijn van de classificaties en welke classificatie als standaard kan worden ingesteld.
$setting= Get-AzureADDirectorySetting | ? {$_.DisplayName -eq "Group.Unified"}
$AzureADDirectorySettingId= Get-AzureADDirectorySetting | where {$_.DisplayName -like "Group.Unified"} | Select-Object Id
# zet classificatie opties
$setting["ClassificationList"] = "Openbaar,Intern (geen gevoelige informatie),Vertrouwelijk (Persoonsgegevens),Vertrouwelijk (Financiële gegevens),Geheim (Persoonsgegevens),Geheim (Strategisch)"
# Sla classificaties op
Set-AzureADDirectorySetting -Id $AzureADDirectorySettingId.id -DirectorySetting $setting
# bepaald de standaard waarde
$setting["DefaultClassification"] = "Intern (geen gevoelige informatie)"
# bepaal de omschrijvingen
$setting["ClassificationDescriptions"] = "Openbaar: mag gedeeld worden met iedereen en bevat geen gevoelige informatie,Intern (geen gevoelige informatie): mag alleen binnen de organisatie gedeeld worden,Vertrouwelijk (Persoonsgegevens): bevat vertrouwelijke persoonsgegevens,Vertrouwelijk (Financiële gegevens): bevat financiële gegevens als jaarverslagen of contracten,Geheim (Persoonsgegevens): bevat geheime medische gegevens als bijvoorbeeld medische gegevens,Geheim (Strategisch): bevat strategische inforamtie als bijvoorbeeld overnames"
# Sla instellingen iop
Set-AzureADDirectorySetting -Id $AzureADDirectorySettingId.id -DirectorySetting $setting
# Toon ingestelde waarden
(Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value "Group.Unified" -EQ).id).Values
Na het uitvoeren van deze actie, wordt in het standaard scherm voor aanmaken van een nieuwe SharePoint site, de mogelijkheid geboden de classificatie van de site (of eigenlijk de Office Group) te kiezen. Dit is standaard functionaliteit.
Het prettige is dat de site die vervolgens wordt aangemaakt ook zodanig gekenmerkt is in de header van de site. Het is dus voor gebruikers direct duidelijk welk type informatie er op de site staat.
Bij het aanmaken van de site zijn ook ‘privacy instellingen’ te specificeren. Dit onderdeel behoeft wel wat uitleg, want de keuze is hierbij ‘Openbaar (public)’ of ‘Privé (private)’. In het geval van ‘Privé’ is de site alleen te benaderen door eigenaren en leden die specifiek zijn toegevoegd. In het geval van ‘Openbaar’ kan iedereen op de site komen (logisch), maar heeft iedereen ook bewerk rechten (minder logisch). Het idee hier achter is dat iedereen in het laatste geval deelneemt aan het team en daarmee bewerk rechten krijgt. Echter, deze bewerkrechten houden ook in dat er bibliotheken kunnen worden aangemaakt of verwijderd en dat pagina’s in de site kunnen worden bewerkt. Kortom, dit is vaak niet het doel van een openbare site waarbij de verwachting is dat iedereen standaard alleen leesrechten heeft.
Mocht dit laatste daarom gewenst zijn, dan is wellicht een communicatiesite een logische optie, waarbij dit wel het geval is.
Met het instellen van de classificatie is verder niets gezegd over het beveiligingsniveau van de site of het beleid dat geldt op de site. Hiervoor moet de volgende stap worden uitgevoerd: het toevoegen van site designs en site scripts.
De specifieke inrichting van de site, samen met de classificatie en privacy instellingen, kan ervoor zorgen dat de gewenste instellingen (grotendeels) automatisch bepaald worden. Voor elke type template kan in Office 365 een zogenaamd ‘Site Design’ worden geregistreerd. Een Site Design bevat één of meerdere Site Scripts, waarin de inrichting van een site mee wordt bepaald. Zo kunnen bijvoorbeeld branding, rechten, inhoudstypen of lijsten worden bepaald in een Site Script, welke na het aanmaken van een site worden uitgevoerd.
In dit mechanisme is het ook mogelijk om Flow triggers te definiëren, zodat ook complexere inrichting kan worden gedaan, of bijvoorbeeld het initiëren van een provisioning tool (of Powershell) actie. Site Designs komen beschikbaar bij het aanmaken van een nieuwe site. Na het aanmaken van de site, zullen de acties automatisch worden uitgevoerd en uitgerold op de SharePoint site. Een van de zaken die je hierbij niet wilt missen, is het uitrollen van labels en beleid op de site. Hierover zal de volgende blog post gaan.
Site designs komen ook weer als standaard functionaliteit terug bij het aanmaken van een nieuwe site.
Tip: Laura Kokkarinen heeft een helder en compleet overzicht uitgewerkt over Site Designs en Site Scripts. Het is het lezen waard als je hiermee aan de slag wilt gaan.
Het valt je misschien op dat het bovenstaande vooral gaat over SharePoint sites. Dit is deels waar: bij het aanmaken van een site wordt je geconfronteerd met deze classificatie. Het mooie echter is dat de classificatie ook terug komt als je een Planner omgeving aanmaakt, een Power BI workspace of een Microsoft Teams omgeving. Hierbij wordt onder water ook een Office Group aangemaakt, waardoor de classificatie ook daar doorwerkt:
In deze gevallen geldt ook dat hieraan het juiste beleid gekoppeld kan gaat worden, wat van toepassing is op de achterliggende SharePoint site, de chat conversaties en planner taken. Kortom, binnen alle Office Group gebaseerde content kan gebruik gemaakt worden van de classificatie!
In de volgende post zal ik het samenstellen van beleid voor content verder bespreken.
Eind vorig jaar schreef ik een blog met daarin een voorspelling over Bots in Microsoft Teams. Hierin benoemde ik de mogelijk om zelf aan de slag te gaan met het maken van een eigen Bot. In het (verre) verleden (2004) heb ik ooit een bot gemaakt die je SharePoint kon laten doorzoeken met behulp van Live Communication Server (LCS), de verre voorloper van Skype voor Bedrijven.
Met de mogelijkheid om Bots te bouwen in Microsoft Teams, is het een stuk eenvoudiger geworden om hiermee aan de slag te gaan. In een uurtje tijd lukte het me om een eigen bot te maken, deze in Azure uit te rollen, en deze vervolgens in Microsoft Teams, Skype en Skype voor bedrijven te gebruiken! Een korte samenvatting:
Bouwen van je Bot
Een goed startpunt is de Bot Builder SDK for .Net te gebruiken. Hier heb je de mogelijkheid om drie zip bestanden te downloaden die een Bot template beschikbaar maken in Visual Studio 2017.
Tevens wordt er een link gelegd naar de Bot emulator, waarmee je je eigen Bot offline kan testen. Als je alles binnen hebt, kan je een nieuw project starten. Ik kan in dit artikel niet te veel in op de logica van een Bot, maar je kan heel eenvoudig je eerste logica toevoegen.
Testen van je Bot
Je kan de Bot testen door de emulator te gebruiken. Debug je project en voer het Bot ‘endpoint’ in, in de emulator. Het endpoint is van belang; via dit kanaal communiceert je Bot straks met Teams of Skype. Het endpoint bevindt zich op: https://[url]/api/messages
Registratie van je Bot
Bij het verbinden met je Bot, werk je met een application ID en een wachtwoord. Deze kan je zelf genereren en aanpassen in de web.config van het project, maar omdat je Bot straks ook online geregistreerd wordt, is het handig deze registratie eerst uit te voeren. Ga hiervoor naar https://dev.botframework.com/bots, en maak een nieuwe Bot aan. Je geeft tijdens deze registratie aan wat je Bot is en doet, de afbeeldingen van je Bot, en je endpoint. Tevens genereer je een ID en wachtwoord. Deze heb je op verschillende plekken nodig.
Uitrollen van je Bot
Nadat je registratie van je Bot klaar is, je het ID en wachtwoord in de web.config hebt geregistreerd hebt, en je de Bot werkend gezien hebt in de emulator, kan je de Bot uitrollen naar bijvoorbeeld Azure. Dit gaat eenvoudig via de publicatie optie in Visual Studio. Let er wel op dat je Bot communiceert over een beveiligde verbinding (https). Uiteraard is dit standaard binnen een Azure Web app.
Kanalen configureren
Je bot is gepubliceerd in Azure, en je kan nu beginnen met het configureren van de kanalen waar je Bot over mag communiceren. In mijn geval stel ik de Bot beschikbaar in Microsoft Teams, Skype en Skype voor Bedrijven. Het is een kwestie van aanzetten in je Bot configuratie online.
Je Bot gebruiken in Microsoft Teams
Het is mogelijk om je Bot nu te gebruiken in Teams. Hiervoor is het handig om de Teams App Studio te downloaden. Met deze tool maak je eenvoudig een package (.zip) zodat je deze kan toevoegen in Teams.
Ook hier gebruik je weer de ID en gegevens van je Bot. Uiteindelijk package je de Bot en wordt een .zip bestand gegenereerd welke gebruikers kunnen gebruiken om je Bot toe te voegen. Omdat het een test betreft, is dit de makkelijkste manier om je Bot te gebruiken. Uiteraard kan je de Bot, indien deze voldoet aan bepaalde eisen, ook publiceren in de Store van Microsoft.
Gebruikers kunnen nu de .zip gebruiken om de Bot toe te voegen. Selecteer hiervoor in de Store de optie ‘Een aangepaste app uploaden’ (linksonder in het menu).
Je Bot is vervolgens beschikbaar in je Chat scherm, of in het Team waaraan je de Bot toevoegt.
Je Bot gebruiken in Skype
Het is eenvoudig je Bot te gebruiken in Skype (voor consumenten). Bij het activeren van het kanaal online, krijg je een URL. Door deze URL aan te klikken wordt de Bot toegevoegd aan je contacten in Skype. Je kan de Bot daarna direct gebruiken
Je Bot gebruiken in Skype voor Bedrijven
Je Bot beschikbaar stellen in Skype voor Bedrijven binnen je organisatie kan je centraal regelen. Dit kan vooralsnog alleen via PowerShell. De handleiding hiervoor staat hier beschreven: https://skypeappregistration.azurewebsites.net/bot/93640d52-ac94-47c9-8609-2c985b8fd1b2. In feite registreer je de Bot in Skype onder een eigen account (bijvoorbeeld: bot@bitspraak.nl). Het kan tot 8 uur duren voordat de Bot bij alle gebruikers beschikbaar is.
Conclusie
Het maken van een Bot is relatief eenvoudig, als je tenminste de logica van je Bot buiten beschouwing laat. Hoewel je een bewerkelijk aantal stappen moet zetten om je Bot werkend te krijgen, zijn de stappen niet heel lastig. De uitdaging ligt vooral bij het ‘intelligent’ maken van je Bot.
De toepassingen van een Bot zijn natuurlijk legio: informatie opvragen, simpele taken uitvoeren, etc. Doordat je Bot in Teams of Skype aanwezig is, kan je makkelijk ook onderweg via je telefoon je Bot benaderen.
Op dit moment bevat mijn Bot nog niet veel handigheidjes. De komende tijd zal ik daarom af en toe een update geven van de vorderingen van de Bitspraak Bot. Mocht je intussen vragen hebben, laat het mij dan weten!
In 2017 kriebelde het al, maar in 2018 wordt het ‘hot’: bots in Microsoft Teams. Bots (in de context van Office 365) zijn eigenlijk digitale gesprekspartners in Microsoft Teams. Het is in Teams mogelijk om bots toe te voegen aan je conversaties, waardoor je gesprekken kan voeren met deze digitale hulpjes.
Niet alleen is het mogelijk om informatie op te vragen aan de bot via een chatscherm, maar het is ook mogelijk om de bot bepaalde taken te laten uitvoeren. Denk bijvoorbeeld aan het inplannen van een vergadering, of nog interessanter, het aftrappen van een Flow.
De gebruiker doet dit door de bot een opdracht te geven, en aan de achterkant wordt de opdracht vertaald in een digitale actie met behulp van code. Een krachtige combinatie, waarmee je veel werk kan digitaliseren en laten afhandelen.
Er is op dit moment een aantal bots beschikbaar, echter vrijwel allemaal Engelstalig. Kom er achter welke bots je in Teams kan toevoegen, door te klikken op ‘Chat’ en dan te klikken in de zoekbalk.
Je kan vervolgens een scala aan bots toevoegen.
En je kan de bot vervolgens gebruiken:
Er is echter een aantal zaken waar je rekening mee zal moeten houden. Het gebruik van bots heeft ook een aantal aandachtspunten.
Het is goed een bot te vergelijken met bijvoorbeeld Siri van Apple of Cortana van Microsoft. Deze digitale assistenten kunnen je helpen met het uitvoeren van simpele taken. Maar ook vaak wordt de vraag of opdracht niet goed begrepen. Het geeft aan hoe moeilijk het is een goede bot te maken.
En wat betreft de bot functionaliteit in Microsoft Teams? Het is een mooie toevoeging en het biedt veel mogelijkheden! Probeer het eens uit en voor de meer technische lezers, maak je eigen bot!
