BYOD.. Wel of niet?

Bring your own device, als je daar 15 jaar geleden over begon zou dat absoluut ondenkbaar geweest zijn. Het idee dat een apparaat aangesloten wordt op je bedrijfsnetwerk waar je geen controle en geen zicht op hebt zal nog menig beheerder doen gruwelen, ik kom in ieder geval nog voldoende pentesters tegen die hier grote problemen mee hebben.

Maar is het nog wel zo’n groot probleem? En wat zijn dan de overwegingen om te bepalen of je BYOD toe wil staan of niet, en welke maatregelen zijn er nodig als je die weg dan in slaat?

Oude mac met rugzak
er zijn grenzen..

Wat verstaan we onder BYOD

BYOD komt veel vaker voor dan we denken en strikt gezien is het waarschijnlijk zelfs zo dat we in bijna 100% van alle IT omgevingen tot op zekere hoogte te maken hebben met BYOD situaties.

In het kort is Bring Your Own Device het best te omschrijven als het uitvoeren van zakelijke activiteiten op een aparaat (laptop, telefoon, pc, fax) dat niet onder beheer staat van de IT afdeling van je organisatie.

De meest duidelijke situatie is natuurlijk wanneer een medewerker zijn of haar eigen laptop gebruikt om op te werken, veelal omdat ze dat gemakkelijker vinden of omdat dat systeem beter/sneller is dan wat ze van hun werkgever krijgen.

Een ander scenario is dat de gebruiker een eigen telefoon gebruikt. Wederom omdat deze beter is dan de zakelijke telefoon of domweg omdat er geen telefoon verstrekt wordt en er toch contact met de collega’s, leveranciers of klanten nodig is anders dan alleen teams meetings.

Daarnaast kan een medewerker ook nog vanaf een privé pc of laptop in de avonduren nog even snel een mail beantwoorden (webmail) of zelfs op vakantie even in een internetcafé inloggen op een van de systemen daar (de horror.. niet doen 🙁 ).

Er zijn nog wel meer grensgevallen te bedenken, maar we houden het hier even bij. Voor de rest van dit artikel focussen we ons op de werkplek in de vorm van de PC of de laptop. Mobiele telefoons is een post op zichzelf waard, dus die bewaren we nog even voor later ;).

Security

Volledige segmentatie van alle data, alle netwerken en alle devices die met elkaar in aanraking komen zou de meest veilige situatie opleveren, en meteen ook de meest onwerkbare. Er moet dus gekeken worden naar wat er allemaal mogelijk is op dit vlak om te bepalen of een BYOD oplossing de moeite waard is.

Aan technische mogelijkheden op dit vlak geen gebrek, zeker binnen het Microsoft 365 ecosysteem is er inmiddels meer dan voldoende mogelijk om de benodigde segmentatie zelf voor een groot deel te automatiseren. Met labeling van data (dataclassificatie – Microsoft Purview) heb je de segmentatie van je data op orde. Door je endpoints allemaal netjes in MDM (Microsoft Endpoint Manager) te hangen en zake als EDR en AIR (Automated Investigation and Remidiation) in te regelen hou je zicht op wat er met die data gebeurt en kan je een deel van je incident response automatiseren.

De tools zijn er dus wel, maar hoe pakken we dat dan aan, en wat voor impact heeft dit op de wel/geen BYOD discussie?

Een lange adem

Soms kosten dingen gewoon tijd..

Het inregelen van alle technische maatregelen zoals eerder omschreven (en dat is nog maar een kleine selectie) is een proces van lange adem, veel werk en een hoop keuzes.

Allereerst zal er iets van beleid gerealiseerd moeten worden. De configuratie keuzes die gemaakt moeten worden kunnen deels op de baselines van Microsoft bepaald worden. Echter, de verfijning en aansluiting op je eigen organisatie is van groot belang, niet op de laatste plaats voor de werkbaarheid van de oplossing.

Je beleid bijvoorbeeld moet voorzien in het model waarmee je dataclassificatie toe gaat passen. Ben je bijvoorbeeld ISO27001 gecertificeerd? Dan heb je een dergelijk model in je beleid staan, maar in veel andere gevallen zal dit ontbreken.

Ook voor het onder beheer brengen van je endpoints is mogelijk nog een hele weg te gaan, zeker ook omdat je misschien wel helemaal schoon wil beginnen zodat je zeker weet dat alle devices direct goed in beheer genomen worden en compliant zijn aan het beleid. (Full disk encryptie? Mag een gebruiker zelf local admin zijn op zijn systeem? (een hele discussie op zichzelf)).

Herinner je je dat dataclassificatie beleid nog? Nu we bepaald hebben wat de bedoeling is moeten we dat ook nog zien toe te passen op de berg data die je al hebt.. Het is gemakkelijk om te zeggen dat je alle bestaande data als vertrouwelijk markeert en de gebruikers labels mogen wijzigen als dat nodig is, maar hoeveel impact heeft dat op de werkwijze van de gebruikers? En hoeveel tijd gaat ze dat kosten?

Vragen en uitdagingen genoeg dus, en we zijn pas bij het voortraject.

en dan?

Voorbereidingen klaar? Go!

Alle voorbereidingen zijn getroffen, het dataclassificatie beleid is ten uitvoering gebracht, alle systemen zijn onder beheer. Je nieuwe medewerker vraagt of hij zijn eigen laptop mag gebruiken omdat de resolutie beter voor zijn ogen is.

Eindelijk zijn we dan bij de BYOD vraag aangekomen..

Er zijn nu twee routes, wanneer je er voor kiest om eigen hardware toe te staan (we hebben het even over laptops/pc’s) kan je stellen dat je dit alleen accepteert als de laptop opgenomen wordt in het MDM systeem. De hardware is dan wel nog in eigendom van de gebruiker, maar alles wat er op staat is onder regie van de werkgever. Als je vooraf afspraken maakt over bepaalde hardware eisen (TPM bijvoorbeeld) is er in deze route geen noemenswaardig verschil tussen hardware die de organisatie zelf koopt en hardware van de eindgebruiker.(voor dit verhaal dan).

De tweede route is het scenario waarbij de eindgebruiker niet wil dat zijn/haar laptop wordt opgenomen in het centrale MDM systeem. Over het algemeen vind ik dit een onwenselijke situatie en ik zou ik vragen hebben over waarom hij/zij dat dan niet zou willen. De voornaamste reden zal het privé gebruik van het apparaat zijn en de onwil om daar toegang toe te geven (begrijpelijk). Maar dat wil niet zeggen dat dit scenario niet toch voorkomt en er legitieme use-cases zijn.

Unmanaged BYOD

Deze tweede route brengt ons bij een unmanaged BYOD scenario. Als je de eerdere stappen gevolgd hebt, het beleid en de classificaties in orde zijn en je omgeving voorbereid is zijn er wel mogelijkheden op dit vlak.

Middels conditional acces policies kan er onderscheid gemaakt worden tussen welke systemen en data er benaderd mogen worden door de diverse clients die we kennen (managed, unmanaged, location based enzovoorts).

In het geval van een unmanaged device zou je nog kunnen toestaan dat de webmail gelezen wordt en eventueel ook nog dat documenten met een bepaalde classificatie in de web vorm bekenen en bewerkt kunnen worden. Het downloaden van de data, het installeren van applicaties en het inloggen in gevoelige SaaS systemen is uit den boze op een unmanaged systeem.

Mogelijkheden

Is er dan echt niets mogelijk in het kader van Bring Your Own Device? Zeker wel! Wil je de gebruikers toch grote vrijheid geven op hun eigen devices is er altijd nog de mogelijk om een centrale werkplek op de bouwen vanaf waar alsnog alles gedaan kan worden. Het downloaden van data naar je eigen (dus niet zakelijke, unmanaged) laptop kan nog steeds niet, maar eenmaal ingelogd op het centrale platform (zoals Azure Virtual Desktop, zie ook mijn “Virtual Walled Garden” post) kan je in die volledig beheerde omgeving alles doen wat je met een managed systeem ook zou kunnen.

Dit brengt me dan ook bij een van de (ik denk meest voorkomende) scenario’s waarbij je mogelijkerwijs met grotere aantallen “BYOD” devices in je omgeving te maken krijgt. Wanneer er op grote schaal extra krachten ingehuurd moeten worden voor kortere tijd kan je je afvragen of je hiervoor de nodige devices wil aanschaffen en klaar wil hebben liggen op de plank, of dat je ze misschien wil huren. Deze mensen werken mogelijk ook niet op je eigen kantoren, maar misschien wel exclusief vanuit thuis.

Allemaal factoren waar je verminderd grip op hebt, door deze devices ook niet toe te laten op je netwerk, maar de werkzaamheden gecontroleerd centraal uit te laten voeren hou je optimaal grip op je data en bied je toch de vrijheid om te werken met de tools die passen bij de situatie.

Het gebruikersgemak van Bring Your Own Device

Laptop op een tuintafel
Een werkplek moet je eigenlijk kunnen maken zoals deze bij jou past..

Bring Your Own Device mogelijkheden spreken erg aan op het vlak van gebruikersgemak bij je eindgebruikers. Als ze kunnen werken met systemen die ze kennen, in situaties die bij ze passen, zal er minder snel buiten de zakelijke IT omgeving heen gewerkt worden.

Eerder schreef ik op dit vlak ook al wat over Security Awareness, en in het stuk over de Virtual Walled Garden ging ik in op de mogelijke oplossing die ook op dit vraagstuk pas. Maar ik kan ook niet genoeg benadrukken dat de bewustwording van de gebruikers, en het faciliteren van een comfortabele omgeving waar je als IT verantwoordelijke grip op hebt, cruciaal zijn voor de veiligheid van je data/organisatie.

In het verlengde daarvan zijn we er vanuit security oogpunt dus bij gebaat om een omgeving aan te bieden met net voldoende vrijheden om te voorkomen dat gebruikers dingen gaan doen die we niet willen, maar met voldoende grip zodat we precies weten wat er gebeurt.

Overigens is er mogelijk ook een heel ander probleem dan een inrichtingsvraagstuk als je veel gebruikers hebt die hun eigen spullen willen gebruiken. Het is (zeker ook gezien de situatie op de arbeidsmarkt) aan te raden om na te denken of die goedkope zakelijke laptop nog wel past bij de beleving die je je medewerkers wil bieden.

Microsoft heeft natuurlijk een erg nette Surface lijn beschikbaar, maar je hoeft niet direct zo ver te gaan (alhoewel ze verhoudingsgewijs niet een zo heel duur zijn ten opzichte van de Dell, of HP alternatieven.). Het is in ieder geval wel goed om eens na te denken bij de hardware die je standaard voert, ook hier speelt de beleving van de gebruiker weer een grote rol.

Conclusie?

Of BYOD bij je organisatie/omgeving past is sterk afhankelijk van het soort organisatie dat je bent en het soort data waar je mee werkt. Als de data zeer gevoelig of zeer waardevol is zijn oplossingen waarbij je openingen bied om de data te extracten zonder dat je daar zicht, of controle, over hebt onwenselijk.

Maar zelfs in die scenario’s zijn er ook rollen in je organisatie waarbij meer vrijheid misschien wel passend is. Als je daar dan de juiste voorwaarden voor schept zoals, segmentatie, conditional acces en de vele andere mogelijkheden in dat vlak, is er misschien toch best wel wat mogelijk.

Ook met een centrale werkplek die je optioneel aanbied voor de mensen die dan toch met hun eigen device willen of moeten werken is er best wel ruimte te creëren voor dergelijke situaties.

Mijn advies zou in ieder geval zijn om naast het belang van het beschermen van je omgeving ook goed te kijken naar de belevenis van je gebruikers. Probeer te voorkomen dat ze het idee hebben hun werk niet goed te kunnen doen met de middelen die je ze bied. In deze gevallen zullen ze zelf op zoek gaan naar oplossingen en werkwijzen, en die zijn vrijwel zeker niet in lijn met het beleid dat je hebt vastgesteld.

Boekenkast
Beleid hebben we vaak kasten vol.. Nu de uitvoering nog..

Virtual walled garden?

Veranderende inzichten in de IT brengen ook nieuwe risico’s en kansen met zich mee. Maar hoe moeten we nou omgaan met die IT omgeving? Moet alles op slot? of valt het wel mee? We bekijken de opties en sluiten af met de realiteit, de walled garden.

Er zit een golfbeweging in de oplossingen die we kiezen binnen de IT. Waar we begonnen met losse, niet gekoppelde systemen groeiden we naar een mainframe oplossing, via terminal server (oa Citrix) achtige oplossingen en dan nu weer meer werken op de endpoints zelf. Of we nu uiteindelijk ook nog een stap gaan zetten waarbij je hele PC eigenlijk vanuit de cloud draait (Windows 365 achtige oplossingen) gaan we de komende tijd ondervinden. Misschien is een virtuele walled garden wel een mooie omschrijving van een van de opties die je tegenwoordig tot je beschikking hebt.

Typewriter
Dit is pas lokaal werken

De wisselingen in de markt op dit gebied brengen een aantal fundamentele keuzes met zich mee over hoe je met je data en je endpoints om wil gaan. Om eens te verkennen wat er allemaal kan, wat gangbaar is en hoe ik dit zelf allemaal zie heb ik deze post geschreven.

Uitgangspunten en aannames

Allereerst een paar uitgangspunten en aannames die ik in alle scenario’s als standaard zie.

Voor het verzenden en ontvangen van mail ga ik uit van een Exchange Online of vergelijkbaar alternatief. In de Microsoft situatie zou ik altijd ATP meenemen voor het security component in je mailomgeving. Daarnaast is afhankelijk van de data waar je mee werkt ook verdere security wenselijk in de vorm van het (al dan niet autmatisch) labelen en detecteren van data die je organisatie binnen komt en uit gaat om te voorkomen dat je via deze route data lekt.

Email icon with notification
Email is misschien wel de makkelijkste weg om data te lekken

SaaS applicaties spelen ook een belangrijke rol in dit geheel. Alhoewel ik deze aanname in het dagelijkse leven niet zou maken ga ik er voor dit verhaal even vanuit dat SaaS applicaties compleet veilig zijn en geen concreet risico vormen in je IT landschap. Of dit daadwerkelijk zo is of niet is een artikel op zichzelf waard.

Alles centraal

Als we puur vanuit security en misschien ook wel compliance kijken is dit de optie waar we het meeste controle over hebben. En daarmee ook tot op zekere hoogte de meest “veilige” optie.

Alles centraal beleggen en vanuit daar regie voeren over wie waar bij kan. Dus zicht op welke applicaties en processen er allemaal draaien en daarmee ook volledige regie over alle “echte” endpoints (sessies). Dit zorgt er voor dat je ten alle tijden weet wat er gebeurt, wie wat doet en waar alles data verwerkt wordt. Gezien dit alles in je eigen (virtuele of fysieke) datacenter draait en achter je eigen firewalls op je eigen servers staat, weet je ook dat je zicht op alle data en processen compleet is.

Je hebt de optie om dit alles helemaal in eigen beheer te doen, of, zoals tegenwoordig meer gangbaar, in de public cloud. Ultiem maakt de keuze niet zo heel veel meer uit tegenwoordig. Voor het gemak ga ik in dit bericht uit van een Public Cloud optie (Microsoft Azure). Later is het misschien wel eens aardig om te kijken naar de nuances tussen een eigen datacenter en een public cloud oplossing.

Met oplossingen als AVD (Azure Virtual Desktop) of W365 (Windows 365) creëer je de virtuele werkplekken die gekoppeld zijn aan je centrale infrastructuur. Effectief vind alles dus in 1 gesloten netwerk plaats en zou de data los van alle gewenste uitwisselingen (mail, koppelingen, enz.) de organisatie niet mogen verlaten.

Met de juiste configuratie zorg je er voor dat het endpoint waar de gebruiker daadwerkelijk werkt (laptop/desktop/tablet) eigenlijk niet meer is dan een stepping stone naar je zakelijke omgeving.

Servers in a rack
Of het nou je eigen servers zijn of die van Microsoft, de data staat ergens op severs.

Deze aanpak levert vooral veel controle op over de omgeving en zorg je er voor dat je zicht hebt op alles wat daar gebeurt. Het risico is wel dat dat alle data gemakkelijk bij elkaar staat, en ja, met de juiste segmentatie van data, netwerken en servers kan je ook dit risico wel weer mitigeren, maar feit is wel dat het een risico is waar je over na moet denken.

Een ander risico is dat deze benadering vaak vanuit de organisatie benaderd wordt, met onvoldoende aandacht voor de echte werkwijze van de eindgebruiker. Wanneer een eindgebruiker niet kan werken zoals hij/zij dat graag wil bestaat het risico op “shadow IT“. Dit gebeurt niet uit slechte wil, maar eerder de drive om het werk goed te kunnen doen, met security awareness kan je de ongewenste aspecten van deze drive wel wat afvangen.

Alles decentraal

In de meest pure vorm komen we deze optie eigenlijk niet echt meer tegen tenzij het hele kleine organisaties betreft en die zijn niet echt de scope van dit bericht. Maar toch is dit het scenario dat het best te plotten is op de “modern work” oplossing zoals Microsoft deze ziet.

Bij het decentrale scenario hebben we geen (eigen of public cloud) server infrastructuur meer waar dedicated zaken als storage of applicaties gehost worden. Dat wil niet zeggen dat er geen centrale storage meer is, maar deze bestaat enkel nog uit SharePoint/OneDrive/Teams opslag.

Accounts staan in de Azure AD en mail wordt gerealiseerd via Exchange Online / M/O365. De clients waar de eindgebruikers mee werken zijn eigenlijk het middelpunt van deze omgeving, ze kunnen ingezet worden op alle locaties. Er wordt dus geen onderscheid meer gemaakt tussen eventuele kantoor locaties, thuis, de lunchroom om de hoek of de locatie van de klant.

Decentralized nodes
Alle nodes staan op zichzelf, er is geen centrale entiteit

In dit scenario zijn twee stromingen mogelijk, één waarbij de eindgebruiker zelf de vrijheid heeft om te installeren wat hij/zij wil gebruiken en één waarbij de gebruiker enkel de bedrijfsapplicaties kan/mag gebruiken.

Voor de eindgebruiker is dit de meest flexibele optie, zeker ook als ze de vrijheid krijgen om zelf te installeren wat ze willen gebruiken. Vaak is in deze scenario’s ook privé gebruik van het device tot op zekere hoogte toegestaan. Waar de gebruiker echter wel rekening mee zal moeten houden is dat er zeer uitgebreide monitoring van de endpoints plaats zal vinden, met als gevolg dat er onoverkomelijk ook inzage ontstaat in bepaalde privé gegevens.

Om dit model te laten werken is goed endpoint management een vereiste, samen met een goede security suite. In het Microsoft ecosysteem zijn dus Microsoft Endpoint Manager en Windows Defender cruciaal om controle te houden over de endpoints. Niet alleen wil je ten aller tijden weten wat er met de devices aan het gebeuren is, maar je wil ook de er geautomatiseerd geanalyseerd wordt of dat wat er gebeurt door de beugel kan.

Een andere belangrijke factor bij het decentrale model is het segmenteren van je data. Binnen een compleet gecentraliseerd model is er een risico op interne datalekken als de data segmentatie niet op orde is, maar bij een de-centraal model veranderd datzelfde risico ook in een verhoogde kans op grootschalige externe datalekken als een van de systemen gecompromitteerd zou raken.

Het segmenteren van data is een mooi onderwerp voor een ander artikel.

Hybride

Dit is denk ik inmiddels de meest gangbare variant. Gedreven door legacy software die nog niet als SaaS beschikbaar is (of niet gevangen kan worden in de diverse Azure Services) en daarmee eigen infrastructuur vereist. In dit scenario werken mensen deels op hun endpoints en eventueel aanvullend in een virtuele werkplek (AVD, Citrix, enz.) of eventueel met published applications.

Een andere reden kan zijn dat er op de achtergrond nog het nodige gebeurt op applicatieservers in de vorm van databases (ja, je kan ook in Azure SQL gebruiken als service, maar er zijn voldoende redenen waarom dat niet altijd kan). Of eventuele specifieke workloads die om diverse redenen lokaal dienen te gebeuren.

In dat laatste scenario kan je overwegen om dat deel van de omgeving volledig te scheiden van de rest van je omgeving. Een dergelijke segmentatie kan de veiligheid ten goede komen, maar dan moet het wel mogelijk zijn.

Hybrid car
Nee.. niet dit soort hybride..

Het grote nadeel van een hybride oplossing is dat je de mitigerende maatregelen van zowel de centrale als de decentrale omgevingen nodig hebt. Daarnaast kan het verwarrend zijn voor de eindgebruikers om met systemen en data te moeten werken die verspreid zijn over verschillende omgevingen.

Een hele andere probleemfactor bij de hybride oplossing is dat het risico op dubbelingen (data) in scenario’s met een centrale en een lokale werkplek aanzienlijk toeneemt. Daarbij wordt het ook moeilijker om al die data in het vizier te houden. Als er niet direct goed nagedacht wordt over waar je welke data wil laten en hoe je deze data gaat monitoren zal er vrij snel een situatie ontstaan waarbij je grote verzamelingen van dubbele en mogelijk oude data krijgt. Dit laatste is een aanzienlijk probleem als je ondertussen ook nog aan de regels van de AVG wil voldoen.

Mijn visie (de virtuele walled garden)

Wat zijn dan mijn verwachtingen voor de toekomst en wat zou mijn geprefereerde situatie zijn?

Zoals al wel gebleken zal zijn uit de eerdere punten ben ik groot voorstander voor vrijheid voor een groot deel van de eindgebruikers. Zolang zijn zich bewust zijn van het feit dat we de endpoints tot op groot detailniveau monitoren en verregaande automatisering toepassen op het mitigeren van de risico’s heb ik er geen moeite mee als er ook privé gebruik plaatsvind op de systemen.

Een beperking op het bovenstaande is wel dat wanneer er op grotere schaal met persoonsgegevens en zeker in de gevallen waarbij bijzondere persoonsgegevens verwerkt worden er geen ruimte is voor deze vrijheid.

En dat brengt me bij het concept wat ik de “virtual walled garden” zou willen noemen. In dit scenario trekken we een muur op rondom alle individuele endpoints en de volledige centrale omgeving, we brengen deze “centrale” omgeving en de endpoints vervolgens samen in een “virtual walled garden” . Tot op zekere hoogte zal dit altijd een vorm van een hybride omgeving zijn.

Indoor garden
Indoor tuin, met gecontroleerde toegangspunten en een gecontroleerde omgeving.

Binnen de muren van de virtuele “tuin” zijn er zones waarin andere regels gelden, maar waarbinnen de gebruiker voor zover ze geautoriseerd zijn vrijelijk rond kunnen “dwalen”. Moet je aan de slag met bijzondere persoonsgegevens die enkel met aanvullende beveiliging toegankelijk zijn? Maak dan gebruik van je AVD sessie. Wil je werken vanaf je thuis PC? Dat kan, dat systeem zelf is niet welkom in de “virtual walled garden” maar vanaf daar een AVD sessie opstarten om daar je werk te doen is geen probleem.

Diezelfde oplossing is ook toepasbaar op derden die werkzaamheden in je “tuin” moeten komen doen., Geef ze toegang tot een AVD sessie en je hebt volledig controle over wat ze daar wel/niet kunnen doen en hebt de risico’s van hun lokale endpoint voor een groot deel gemitigeerd.

Wat is dan een virtual walled garden?

De kern van deze aanpak is het segmenteren van de endpoints als individuele entiteiten en het encapsuleren van eventuele centrale infrastructuur. Door al deze compotenten samen in 1 omgeving met elkaar te verbinden (de virtual walled garden) krijg een best of both worlds scenario die effectief de hybride oplossing van eerder is, maar met een zeer hoge mate van integratie en modernisering.

Of je nou alle clients middels een always-on-vpn oplossing direct naar de virtuele tuin moet leiden is een vraag die per scenario bekeken zal moeten worden. Als de gebruiker enkel met Sharepoint/Teams/OneDrive data hoeft te werken en er een AVD achtige oplossing is voor eventuele aanvullende toegang is daar geen noodzaak voor.

In een dergelijk scenario zie ik de Microsoft 365 tenant als de virtual walled garden waar iedereen in werkt. In scenario’s waarbij meer infrastructuur bij komt kijken zou ik voor een verregaande integratie van de verschillende netwerk segementen gaan en dan is een always-on-vpn oplossing misschien wel op zijn plek.

Azure function apps in combinatie met AFAS Profit

Als je wil proberen om zo min mogelijk eigen infrastructuur te gebruiken zonder dat dat meteen veel geld moet kosten zijn er talloze opties te bedenken. Een van die opties is Microsoft Azure. De eerste stap die je zal moeten zetten is gaan denken in de daadwerkelijke handelingen die er uitgevoerd moeten worden. Deze handelingen wil je vervolgens in logische blokken opdelen, met als voorwaarde dat deze blokken moeten onafhankelijk van elkaar kunnen functioneren. Vervolgens kan je per blok gaan kijken wat de beste manier is om de gewenste functionaliteit te realiseren.

Het “Probleem”

In dit voorbeeld gaan we voor nieuwe medewerkers in AFAS Profit een aantal velden vullen. Omwille van de eenvoud van het voorbeeld heb ik het gebruikte script even eenvoudig gehouden. Gezien het in Profit niet mogelijk is om logica toe te passen bij het automatisch vullen van velden hebben we een externe oplossing nodig om dit te doen. Het heeft mijn voorkeur om dit soort zaken met Powershell en de connectoren in Profit op te lossen. Voorheen gebruikte ik hiervoor altijd een van onze applicatieservers voor (om het script te draaien). We kunnen dit echter ook prima in Azure oplossen

De oplossing (Microsoft Azure)

Als je in Microsoft Azure scripts wil laten draaien die gebruik kunnen maken van web connectiviteit zijn de “Function Apps” een goede optie. Binnen dit systeem heb je bijvoorbeeld ook Web Proxies beschikbaar en die gaan we in een latere post gebruiken :). We gaan dus een Function App aanmaken waarbinnen we één of meerdere scripts op een tijdschema laten draaien. In dit voorbeeld gaan we een lijst ophalen van medewerkers die nog geen licenties toegekend gekregen hebben. Deze lijst met medewerkers krijgt vervolgens de juiste licenties toegekend op hun medewerkerkaart. Voor deze stappen heb je een actieve Azure Subscription nodig (je moet dus of in de trial zitten of een betaalmethode gekoppeld hebben). De kosten van het draaien van dit script (15 uur per dag) zijn 6 eurocent per maand (afhankelijk van de gebruikte opslag / data). Ik zou Azure altijd instellen op de Engelse taal gezien de vertalingen naar het Nederlands erg verwarrend kunnen zijn. Daarnaast zijn niet alle vertalingen correct.

Stappenplan (functie)

We starten op de Azure portal en kiezen daar voor het aanmaken van een nieuwe resource:
Azure portal "Create Resource"
In het volgende venster zoek je naar “Function app”:
Azure function app aanmaken
Je krijgt een nieuw menu te zien waar je een aantal instellingen in kan geven. De “App name” is voor dit stappenplan niet zo van belang. Mocht je later de Proxy functionaliteit wil gaan gebruiken wordt dit de URL waarop je de proxy kan benaderen. In ons geval moeten we een nieuwe resoursegroup aanmaken waar alle elementen voor deze functionaliteit gebundeld worden. als locatie kiezen we voor West Europe gezien die geografisch het dichtste bij onze AFAS Profit omgeving zal staan. De naam van de storagegroup is niet heel belangrijk in dit geval, als je het maar eenvoudig terug kan vinden. Uiteindelijk heb je dan grofweg het onderstaande. Als je nu op “Create” klikt wordt de Function App aangemaakt, dit kan ongeveer een minuut duren.
Na een minuutje wachten kan je de Function App openen en krijg je een overzicht zoals dit te zien:
Function app overzicht.
We kunnen nu daadwerkelijk de functie aan gaan maken die het script gaat draaien. We klikken hiervoor bij “Funtions” op het plusje om de wizzard te openen. Er zijn een groot aantal standaard functies beschikbaar, maar in ons geval willen we een custom function bouwen:
In het volgende venster zal je de beta talen aan moeten zetten. Powershell is nu nog in beta (al tijden), maar werkt prima. Om deze mogelijkheid te krijgen moet je deze switch even omzetten:
Vervolgens kan je de “Time Trigger” optie kiezen:
Azure function Time Trigger
In het volgende venster zal je de taal moeten kiezen (in ons geval PowerShell) en het schema moeten definiëren. Dit schema maakt gebruik van dezelfde notatie als CRON en is niet heel erg gemakkelijk leesbaar als je er niet veel mee werkt. Je kan hiervoor eventueel een generator gebruiken. In het voorbeeld hier onder draaien we het script ieder uur vanaf 7.00 in de ochtend tot 20.00 in de avond. (let wel op dat je je tijdzone goed ingesteld hebt).
Na het aanmaken van de functie krijg je een leeg venster te zien waar het script geplaatst kan worden. Je kan dit allemaal integreren met bijvoorbeeld Github (of andere repositories), maar dat gaat voor dit voorbeeld even te ver.

Het script

De laatste stap is het toevoegen van het script zelf. Ik ga niet al te veel in op de werking van het script, maar kort samengevat gebeurt er het volgende:
  • Roep een getconnector aan die een gefilterde lijst met gebruikers zonder licenties ophaalt.
  • Loop door deze lijst en voer de gewenste licentiecodes in bij de diverse users.
Om het voorbeeld een beetje overzichtelijk te houden staat hier onder een versimpelde versie van ons script. We gebruiken zelf een complexer script met een aantal randvoorwaarden om te bepalen welke licentie nodig is voor welke gebruiker.
begin {

    # define the access token for the AFAS service
    $token = '<token><version>1</version><data>***</data></token>'
    $encodedToken = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($token))
    $authValue = "AfasToken $encodedToken"
    $Headers = @{
        Authorization = $authValue
    }

    # Connect and retrieve the table
    $url = 'https://**/profitrestservices/connectors/***?skip=-1&take=-1'
    $records = ((Invoke-WebRequest -Uri $url -UseBasicParsing -Headers $Headers).content  | ConvertFrom-Json).Rows
}

process {
    # Specify update authorization
    $token = '<token><version>1</version><data>***</data></token>'
    $encodedToken = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($token))
    $authValue = "AfasToken $encodedToken"
    $Headers = @{
        Authorization = $authValue
    }
    $connectorname = "KnEmployee"
    
    # Process records 
    foreach ($record in $records) {
        $url = "https://***/profitrestservices/connectors/KnEmployee"

        Write-Host $record.profituser
        $medewerker = $record.profituser

        $messagecontent = '{"AfasEmployee": {"Element": {"@EmId": "' + $medewerker + '", "Fields": { "***": "02", "***": "01"}}}}'

        $results = ((Invoke-WebRequest -Uri $url -UseBasicParsing -ContentType 'application/json;charset=utf-8' -Method PUT -Headers $Headers -Body $messagecontent).content | ConvertFrom-Json)
        Write-Host $results
    }
}
Na het invoeren van het script kan je op “save en run” klikken en daarna zal het script volgens het voorgestelde schema draaien. Je kan eventuele fouten opsporen door de logging na te kijken, deze is voor de losse run direct onder in het scherm beschikbaar:
En later via het monitor menu:

Tot slot

Dit is natuurlijk maar een eenvoudig voorbeeld, maar je kan je voorstellen dat je op deze manier veel zaken kan automatiseren zonder dat je hier eigen infrastructuur voor nodig hebt. Het script wat ik gebruikt heb in dit voorbeeld is gemaakt samen met Jaap de Koning, lees ook eens zijn blog als je geïnteresseerd bent in automatisering. Laat even een berichtje achter als je meer wil weten over deze manier van automatiseren rondom AFAS Profit of het gebruik van Azure functions. De komende tijd zal ik meer in gaan op deze aanpak. Daarbij kijken we naar de veranderingen die nodig zijn in de manier van denken om goed gebruik te maken van cloud en hybride oplossingen.

Detron Open Script Night – Ronde 1

Als een van de Business Developers bij Detron IT Consultants mag ik samen met het als team altijd zoeken naar methoden om onze collega’s kennis te laten maken met nieuwe systemen en technieken. Maar soms moet je ook de aanpak van deze kennisdeling eens op de schop gooien om zo een andere groep mensen te bereiken of een hoger niveau te behalen. Zeker op het gebied van het schrijven van een script ten behoeve van automatisering zien we het niveau flink stijgen en moeten we de aanpak dus veranderen.

Zo gaan we na 2 jaar aan PowerShell bootcamps eens proberen om op een hele andere wijzen kennis te delen over niet alleen PowerShell, maar ook andere scripttalen waar we in onze dagelijkse werkzaamheden mee in aanraking komen. Het resultaat van wat berichten heen en weer tussen collega’s was dat we vanuit het Detron ICT Kenniscafé (communicatie middel en organisatie van een deel van onze kennissessies en trainingen en mijn hobby op het werk 😉 ) ook wel een Open Script Night konden houden. Hier kunnen collega’s of externe sprekers in 10-20 minuten een demo en toelichting geven van iets wat ze zelf gemaakt hebben en misschien handig is voor collega’s.

Als we deze korte sessies combineren met een introductie van een nieuwe of bestaande techniek die voor iedereen interessant kan zijn hopen we een leuke actieve avond te hebben. Het is niet de bedoeling dat bezoekers alleen maar gaan zitten luisteren, maar ook direct met de laptop aan de slag kunnen om ervaring op te doen met wat ze horen en zien.

Ondanks dat ik met al 6 jaar bezig houd met het organiseren van trainingen en sessies heb ik anders dan het welkomstwoord nog nooit zelf inhoudelijk gesproken op een sessie, gezien een van mijn hobby’s nogal wat met scripting te maken heeft (clickfarm.nluitleg) was dit een mooie gelegenheid om hier ook een keer verandering in te brengen. Tijdens de eerste Detron Open Script Night zal ik 30 minuten spreken over twee tools die mij enorm helpen en een stukje techniek waar ik dagelijks mee in aanraking kom. Een van de andere onderwerpen  waar we deze eerste avond naar gaan kijken is git, wat mij betreft ook een onmisbaar stuk gereedschap voor het onderhouden van je scripts.

Onderwerp 1: Visual Studio Code (script editor)

Visual Studio Code een erg mooi stukje gratis software van Microsoft voor het schrijven van je code. Voor de meeste talen is er een intellisense module beschikbaar. Daarnaast zorg de Emmet.io integratie voor een aanzienlijke versnelling van het schreven van de code. Ook een directe integratie met git draagt bij aan een goede workflow. Visual Studio Code - Script editor

Onderwerp 2: Postman

Eigenlijk al een stukje voorbereiding op het derde onderwerp, maar Postman is een tool voor het testen van allerlei web connectoren (om het maar eens heel simpel uit te leggen). De eerste keer dat ik er mee in aanraking kwam was voor het testen van de backend voor Clickfarm, maar inmiddels gebruik ik de tool ook zakelijk.

Postman API Test suite

Onderwerp 3: Web-connectoren (API’s)

Wanneer je meerdere (SaaS) systemen aan elkaar wil koppelen ontkom je niet meer aan allerlei verschillende API’s. Nou zijn er aardig wat standaarden, maar in hoofdlijnen werken ze technisch veelal hetzelfde. Reden genoeg om eens beter te kijken wat nu de kracht kan zijn van een goede API, maar ook wat de uitdaging kan zijn als je meerdere passieve systemen wil koppelen.

api grafische weergave

 

Microsoft Power BI Gateway (Deel 2)

In de vorige post hebben we gekeken naar hoe we data uit Profit via de webconnectoren naar JSON files kunnen halen. Om deze files ook beschikbaar te maken in de cloud voor Power Bi kunnen we het beste gebruik maken van de Power Bi gateway. Hier onder vind je een instructie van hoe deze te installeren en configureren. De instructie is op basis van de documentatie van Microsoft die je hier vind.

Stap 1: Download Enterprise Gateway

Om de Gateway te kunnen downloaden moet je inloggen op Office.com en dan doorklikken naar de PowerBI omgeving.

Office 365 Power BIRechts bovenaan heb je een “download” knop, kies daar voor “Data Gateway”

Power BI Gateway

Je wordt vervolgens doorverwezen naar de download pagina, klik daar op de “Download Gateway” optie.

Download Power BI gateway

Stap 2: Installeer Enterprise Gateway

Na de download kan je de installer starten, als er al andere applicaties draaien op de server is het zeer waarschijnlijk dat aan alle requirements voldaan wordt voor de installatie.

Power BI Gateway installatie

Je krijgt de keuze voor twee types gateway, kies hier voor de aanbevolen optie en dus NIET voor de personal mode!

Power BI Gateway Installtie modusDruk op volgende tot de installatie daadwerkelijk start.

Stap 3: Koppel Gateway

Na de installatie moet deze gekoppeld worden. Het maakt in principe niet al te veel uit welke user hier gekoppeld wordt, maar:

Alleen deze user kan:

  • aanpassingen doen aan de configuratie van de gateway zelf
  • Logging exporteren

Verder:

  • Er wordt een recovery code aangemaakt waarmee we deze user kunnen omzeilen, bewaar deze goed
  • Je moet met deze user in kunnen loggen op Office.com en je hebt dus een volledige O365 licentie nodig!

Power BI Gateway user

Je zal vervolgens een pop-up krijgen voor je credentials.

Vervolgens moet je een keuze maken of je een oude gateway wil recoveren of dat je een nieuwe gaat installeren, in ons geval installeren we dus een nieuwe:

Power BI Gateway Nieuw of Recover

Geef de gateway een naam en voer de herstelsleutel in, bewaar deze goed, we hebben deze nodig als we de gateway ooit zouden willen migreren naar een nieuwe server.

Power BI Gateway Recovery Key en naam

Je krijgt vervolgens de instellingen te zien, deze staan goed, dus die kan je zo laten:

Power BI Gateway regio

Zet tot slot het vinkje voor het verzenden van de gebruikersgegevens nog even uit. Vervolgens is de installatie klaar.

Power BI Gateway installatie voltooid

Stap 4: Autoriseer Gateway

Tot slot moet de gateway nog geautoriseerd worden. Deze is op dit moment alleen beschikbaar voor de user die je bij de installatie hebt opgegeven.

Log als deze user in op Offic.com, ga naar de PowerBI pagina en kies deze keer voor de “Settings” knop en kies voor manage gateways

Power BI Gateway autorisatie

Klik vervolgens op administrators:

Power BI Gateway administrators

 

 

De rest van de configuratie vind plaats vanuit Power Bi zelf.

AFAS Profit – Microsoft Power BI (Deel 1)

Het was voor ons al langer een wens om data uit AFAS Profit eenvoudig in Power BI te kunnen gebruiken, en alhoewel het nog steeds geen helemaal directe link is kunnen we nu wel middels een klein stukje Powershell en de Power BI gateway gebruik maken van automatisch bijgewerkte Profit data in Power BI.

De voorbereidingen beginnen in Profit:

Zorg er voor dat je eerst in AFAS Profit een app connector aanmaakt, koppel hier vervolgens een gebruiker aan en zorg er voor dat je het autorisatie token genereert.

De volgende stap is het toevoegen van de “Getconnectoren” die je automatisch wil exporteren. Het Powershell script zal alle getconnectoren voor deze gebruiker exporteren, dus het is zaak om te zorgen dat je alleen de data die je naar PowerBI wil sturen beschikbaar stelt voor deze connector. In dit geval betreft het drie connectoren:

 

Tot slot hebben we voor het exporteren van de data een klein stukje Powershell nodig:

$token = ‘<token><version>1</version><data>***</data></token>’
$encodedToken = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($token))
$authValue = “AfasToken $encodedToken”
$Headers = @{
Authorization = $authValue
}

$url = ‘https://**/Profitrestservices//metainfo’
$file = ‘C:\PBIData\todo.json’
Invoke-WebRequest -Uri $url -OutFile $file -Headers $Headers

$todo = Get-Content -Raw -Path $file | ConvertFrom-Json

foreach ($conn in $todo.getConnectors.id){
$url = ‘https://**/profitrestservices/connectors/’+$conn+’?skip=-1&take=-1′
$file = ‘C:\PBIData\’+$conn+’.json’
Invoke-WebRequest -Uri $url -OutFile $file -Headers $Headers
}

Het bovenstaande script haalt de beschikbare getconnectoren op en zal deze vervolgens zonder filtering volledig ophalen en als JSON op de gespecificeerde locatie neerzetten. Overigens kan dit natuurlijk ook mooi opgelost worden met een stukje storage en een function app in Azure, maar dat is iets voor later :).

We hebben de data nu klaar staan voor de integratie met PowerBI, hoe dat in zijn werk gaat wordt in de volgende post uitgewerkt.