Microsoft Archives - HermanRonk.nl

Local administrator

Is het nou een goed of slecht idee om je eindgebruikers local administrator rechten te geven op hun endpoints?

De laatste jaren is de trend dat we eindgebruikers steeds meer vrijheid gegeven hebben op de systemen waar ze mee werken. Sterker nog, we hebben ze vaak Local Administrator gemaakt.

Niet op de laatste plaats doordat je gebruikers deze vrijheden ook in de privé sfeer gewend geraakt zijn door het gemak waarmee ze apps installeren op hun telefoons of eigen laptops. Veel software kent tegenwoordig gratis alternatieven en in een groeiend aantal gevallen is de gratis software misschien nog wel beter dan de betaalde alternatieven die op je zakelijke laptop staan.

Uiteindelijk zijn we zo ver gekomen dat we in veel gevallen de eindgebruiker ook local administrator (LA) gemaakt hebben op hun laptop zodat we zelf hun werkzaamheden uit kunnen voeren zoals zij dat willen.

Eerder in het BYOD stuk hintte ik al dat er ruimte was voor discussie op dit vlak.. Dus, is het verstrekken van LA autorisatie dan wel iets wat we echt moeten willen? En hebben we dan eigenlijk wel een keuze op dit vlak? Dat zijn de punten waar we in dit artikel eens naar gaan kijken.

Wat is een “Local Administrator”

Local administrator rechten zijn zoals iets als de sleutels van het huis. — Hier zijn de sleutels, succes!

Een gebruiker is local administrator als de hoogste rechten op het device zijn toegekend aan deze gebruiker. Een eerste verwarring hier is meteen al dat dit op een Intune (MEM) managed device eigenlijk al niet helemaal waar is.

Er zijn voldoende instellingen waarbij de instellingen die een local administrator zou maken aan bijvoorbeeld Windows Defender altijd overruled worden door de management instellingen vanuit Intune. Zoals bijvoorbeeld de “DisableLocalAdminMerge” setting die er voor zorgt dat de Defender instellingen van het managed profile altijd leidend zijn. (Zie hier meer van deze instellingen en bijvoorbeeld ook hier wat mogelijkheden met betrekking tot onder andere de firewall instellingen op je endpoints)

Maar, er zijn dus voldoende instellingen die een local admininistrator kan maken waar je niet direct of invloed over hebt. Niet op de laatste plaats het feit dat een LA zelf software kan installeren. Dit is vaak dan ook de reden waarom je deze rechten sowieso verstrekt aan je eindgebruikers.

Hier zit dan meteen ook het grootste security risico. Want niet alleen de software die de gebruiker zelf wil installeren kan dus gedraaid worden, maar ook allerlei malafide pakketten die soms onbewust of onbedoeld mee geïnstalleerd worden. (gelukkig zijn we alvast voor een heel eind verlost van allerlei search bars).

Wat een LA ook is in deze context, is een enkele entiteit met autorisatie over één device. een LA mag wel een oorsprong hebben in bijvoorbeeld een Azure AD, maar is LA op enkel zijn device en heeft in beginsel dus geen autorisatie op andere apparaten. Dat die autorisatie via allerlei routes alsnog gegeven kan worden is weer een heel ander verhaal.

Waarom zouden we een eindgebruiker “Local administrator” willen maken?

Local administrator rechten zetten de deur naar binnen op een kier — Zet je met LA rechten de deur open?

De voornaamste reden die we hiervoor horen is dat we de gebruiker de vrijheid willen geven om te werken zoals ze dat zelf willen. Het idee is dat wanneer je een gebruiker teveel beperkt ze buiten de normale IT om gaan werken en er een Shadow IT omgeving ontstaat waar je geen zicht en al helemaal geen controle over hebt.

De bovenstaande reden voer ik zelf ook wel eens aan, vooral ook omdat het alternatief (en eigenlijk de juiste werkwijze) een aanzienlijke investering in tijd gevolgd door aanzienlijk hogere onderhoudskosten met zich mee brengt.

De realiteit

De realiteit is dat het overgrote deel van de gebruikers met een relatief beperkte applicatie set overweg kan en ook helemaal niet de noodzaak heeft om daar van af te wijken. Echter, het inventariseren waar ze nou echt mee willen en moeten werken, zorgen dat ze daar volledig voor getraind worden en dat je die applicatie onderhoud (updates, wijzigende standaard configuraties en ga zo maar door) terwijl je ook nog eens de maandelijkse nieuwe gebruikers inleert in die werkplek is allemaal zo eenvoudig nog niet.

Dus, we pushen een aantal standaard applicaties, en of iemand nou de standaard notepad, of notepad++ gebruikt zal ons over het algemeen een worst wezen om het maar bot te omschrijven.

De snelste weg om ons daar als IT afdeling niet meer druk over te maken is de gebruiker het zelf maar uit te laten zoeken en ze de autorisatie geven om te installeren wat ze willen. De hele security afdeling slaapt vervolgens slecht, maar met de nodige monitoring en automatische mitigatie vanuit de Microsoft 365 E5 of E3 met de Security add-on kijken we met een iets geruster gevoel de andere kant op. (En hebben we ook daadwerkelijk aanzienlijk meer grip op de situatie, maar wel tegen de nodige kosten)

Waarom zouden we gebruikers geen local admin maken?

Het innemen van local administrator rechten kan als een gevangenis voelen voor gebnruikers. — Voor sommige mensen voelt het als opgesloten worden (voornamelijk IT’ers gelukkig)

Als we geen grip houden op wat men installeert op hun systeem hebben we dus ook geen grip op waar die installers vandaan komen.

In het notepad++ voorbeeld van hier boven pakte dat in 2021 nog goed verkeerd uit toen er installers verspreid werden met malware.

Als de gebruiker enkel de officiële bron gebruikt is dit risico minder groot, maar we weten allemaal ook wel dat de eerste google link gebruikt zal worden voor het downloaden van de gezochte software.

Hiervoor heb ik kort stil gestaan bij het werk dat komt kijken bij het standaardiseren van het volledige applicatie landschap. Dit mag dan wel een hoop werk zijn, maar het bied zeker voordelen.

Wanneer je met een homogeen landschap kan werken is er meer mogelijk op het vlak van het standaardiseren van bijvoorbeeld je onboarding en adoptie trajecten. Daarnaast maakt het je landschap overzichtelijker en zaken als patch management voor applicaties op de endpoints eenvoudiger.

Veel aanvallen die starten via een device van een eindgebruiker gaan uit van een autorisatie niveau waarbij aanvullende tools (zonder tussenkomst van de eindgebruiker) geïnstalleerd kunnen worden om de aanval verder uit te breiden. Deze tactiek sluit je uit door de gebruiker deze autorisatie domweg niet te geven. Dat sluit het risico op een aanval via het endpoint niet uit, maar het verkleint de kans aanzienlijk.

Vanuit het perspectief van de eindgebruiker valt ook wel wat te zeggen voor een meer restrictieve omgeving. Het overgrote deel heeft niets met IT en wil gewoon hun werk doen, met goede instructies, goed geconfigureerde werkplekken en applicaties is al die vrijheid en de bijbehorende verantwoordelijkheid helemaal niet nodig.

Nuances

Er is niet één antwoord op of je je gebruikers local administrator wil maken ja/nee. Los van dat het sterk afhangt van wat voor soort organisatie je bent en wat voor type personeel er rondloopt heb je ook een zekere mate van vrijheid in hoeveel risico je wil/kan/mag lopen.

Los daarvan kan je prima differentiëren binnen je organisatie. Als je er voor gaat om gebruikers niet standaard LA autorisatie te geven wil dat niet direct zeggen dat je geen van je gebruikers dergelijke rechten geeft.

Je kan overwegen om een kleine groep “power-users” meer autorisatie te verstrekken zodat zij voor de curve kunnen werken met nieuwe tools die mogelijk later voor de rest beschikbaar gesteld kunnen worden.

Of mogelijk heb je een development team dat nou eenmaal meer vrijheden nodig heeft gezien de aard van de ontwikkelingen die ze doen.

En tot slot heb je natuurlijk ook je IT afdeling nog (eventueel). Los van het feit dat die er niet zo goed tegen kunnen om beperkt te worden op hun werkstations valt er ook wel wat te zeggen voor de vrijheid om alle tools te mogen gebruiken om de omgeving goed te laten functioneren. ~~Daarnaast kan je er ook op vertrouwen dat ze bekend zijn met de materie en geen onnodige risico’s nemen.~~

Conclusie

En nu dan? Moeten we iedereen meteen de local administrator rechten afnemen? Of ligt het iets gecompliceerder?

Als je momenteel in de situatie zit waarbij je eindgebruikers allemaal LA zijn is de weg terug niet zonder risico en vergt het zeker de nodige planning en voorbereiding. Maar dat neemt niet weg dat een dergelijk traject niet de moeite waard kan zijn.

Vanuit security oogpunt zou het wenselijk zijn om de LA autorisatie enkel te verstrekken aan mensen waarvoor het functioneren ernstig verstoord wordt zonder die autorisatie. Maar je hebt dus ook sectoren waar veel vrijheid op de systemen waar ze mee werken onontbeerlijk is, in die gevallen zal het risico via andere routes gemitigeerd moeten worden.

In hoofdlijnen komt het er wat mij betreft op neer dat je voor een combinatie moet gaan. De teams die werken met een vaste set applicaties en processen wil je eigenlijk geen LA autorisatie geven, de toegevoegde waarde is marginaal en de risico’s te groot. In het kort krijg je dan dus een tweedeling in de organisatie, maar de basis is hetzelfde.

Iedereen begint met dezelfde laptop, de beheer tooling, monitoring, security tooling en de initiële set applicaties zijn voor de gehele organisatie gelijk, of anders functie gebaseerd. Een (zo klein mogelijk) deel van de organisatie geef je vervolgens aanvullend autorisatie zodat ze LA zijn op hun devices.

Je kan overwegen om deze (LA) gebruikers een stukje aanvullende instructie te geven. Eventueel kan je ze ook mogelijk ook nog te laten tekenen voor de aanvullende verantwoordelijkheid die je ze geeft. Deze vrijheid komt namelijk niet zonder de nodige plichten zoals het goed onderhouden van de software (overigens deels te automatiseren), maar ook extra waakzaamheid voor verdachte situaties bij het uitvoeren van de werkzaamheden.

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?

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

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?

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.

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.

AFAS Profit – Power BI Historische data

Van niet alle data in AFAS Profit wordt de historie opgeslagen, in andere gevallen kan je deze minder gemakkelijk ophalen via connectoren. Een voorbeeld is bijvoorbeeld de forecast module, je kan de huidige status ophalen, maar het is niet te zien welke statussen deze nog meer gehad heeft in het verleden. We gaan dus kijken naar Historische AFAS Data in Power BI.

Mocht je dergelijke data nu wel in Power BI beschikbaar willen hebben zijn er een aantal mogelijke oplossingen. In dit bericht gaan we in op de quick and dirty oplossing. Mocht ik later nog tijd vinden voor een zal ik het bericht verder uitbreiden.

Wat gaan we doen?

We gaan een export ophalen uit AFAS Profit middels een getconnector, deze slaan we vervolgens op in Azure Storage. Dat doen we volgens de instructies uit dit artikel, met een kleine aanpassing. De files worden voorzien van een datumveld, in dit voorbeeld neem ik nog niet het opschonen van de historie mee en bouwen we de historie in principe eindeloos op.

Aanpassing Powershell script

Het enige echte verschil met het script uit het eerder genoemde artikel zit in de loop waar we data ophalen. In het eerste geval overschrijven we altijd de vorige export, maar in dit geval willen we graag meer versies van het bestand opslaan, hiervoor hebben we dus een extra variabele nodig:

foreach ($conn in $todo.getConnectors.id) {
    $naamDatum = Get-Date -Format "dd-MM-yyyy"
    $url = 'https://**URL_VAN_PROFIT_OMGEVING**/profitrestservices/connectors/' + $conn + '?skip=-1&take=-1'
    $file = '.\' + $conn + '.json'
    Invoke-WebRequest -Uri $url -OutFile $file -Headers $Headers -UseBasicParsing
    $filename = $conn + '_' + $naamDatum '.json'
    Set-azurestorageblobcontent -File $file -container $ContainerName -Blob $filename -Context $Context -Force
}

Iedere keer dat het script nu draait zal er een export gemaakt worden van de getconnector, deze wordt vervolgens op de blobstorage opgeslagen met de datum in de filename. Het gevolg hiervan is wel dat je maar 1 export per dag kan maken, iedere keer dat je het script opnieuw draait wordt de huidige dag overschreven.

Power BI

De handigheid zit hem in het consolideren van de diverse bestanden in Power BI. Hiervoor moet je eenmalig wat stappen doorlopen, maar vervolgens zal iedere keer dat je de rapportage ververst de nieuwe data opgehaald worden als die aanwezig is.

Stap 1: Toevoegen blob storage als datasource

In dit artikel staat (onder andere) uitgelegd hoe je blob storage kan toevoegen als datasource in PowerBI. In dit geval kan je de eerste stappen daarvan herhalen tot je dit scherm ziet:

Overzicht met files in de blobstorage — Blobstorage overzicht

Klik hier op OK, er zal een query ingeladen worden waarmee we verder kunnen werken.

Stap 2: Filter de bestanden die je nodig hebt (indien nodig)

Je kan in de tabelweergave die je vervolgens te zien krijgt op het “Name” veld filteren zodat alleen de velden (bestandsnamen) overblijven die je nodig hebt. Je kan hier allerlei filters, waaronder tekstfilters gebruiken.

Filterweergave power BI — Filter invoeren

Het resultaat is dan als het goed is de lijst met json files die je wil inlezen. Dit filter wordt iedere keer bij het verversen van de data toegepast, dus als er na een verversing meer bronbestanden zijn die aan het filter voldoen worden deze ook mee ingelezen.

Gefilterde weergave power bi — Het gefilterde resultaat

Stap 3: Het samenvoegen van de verschillende files

als het goed is hebben de files allemaal dezelfde structuur (LET OP: Dus niet de get-connector nog aanpassen nadat je dit gedaan hebt, dat levert problemen op met je historische data)! Je kan deze nu samenvoegen zodat we vanuit daar verder kunnen werken.

Klik voor het samenvoegen op de twee pijlen naar beneden naast “Content”

Samenvoegen files knop in power bi — Merge files

Je zal nu afhankelijk van de hoeveelheid data heel even moeten wachten, maar uiteindelijk zie je de volgende tabel (iets van die strekking)

Samengevoegde file-lijst power bi — Samengevoegde bestanden

Hier gaan we net als eerder weer een filter op toepassen, in de kolom “Name” filteren we zodat alleen de rows over blijven.

Stap 4: Bronbestanden “uitvouwen”

De volgende stap is het “uitvouwen” van het bronbestand. Door de aard van de JSON files moeten we de “lists” omzetten naar daadwerkelijke regels. Dat doen we als volgt:

Exploderen lijsten naar rijen — Expand to New Rows

Door op de “expand” knop te klikken krijgen we een keuze, kies hier voor “Expand to New Rows”. Je zal wederom even moeten wachten, maar daarna zie je dat er voor iedere regel uit iedere JSON file een regel gemaakt is in de tabel:

Toevoegen kolommen uit importbestanden — Uitgevouwen regels

De vervolgstap is om te bepalen welke kolommen uit de bronbestanden we zichtbaar willen maken in de eindtabel:

Vink de kolommen aan die je wil behouden en druk op OK.

Stap 5: Historisch datumveld prepareren

Je hebt nu de tabel met alle data, maar nog geen mogelijk om hier historisch op te filteren. Hiervoor moeten we het veld met de filename nog afmaken. we hebben de filename eerder in het Powershell script voorzien van de datum waarop de export gemaakt is. We zullen nu dus de overbodige tekst uit dat veld moeten weghalen en er een datumveld van moeten maken.

Onder het kopje “Transform” kan je voor “Replace” kiezen (selecteer eerst de kolom met de filenames):

Replace functie power bi — Replace Values

Je krijgt een dialoog te zien, afhankelijk van de opmaak kan je hier de tekst invullen die je niet meer nodig hebt. In mijn geval moet ik zowel voor als na de waarde die ik wil houden tekst verwijderen, dus ik moet deze handeling twee keer doen. Je voert de tekst in die je wil vervangen door “” oftewel niets, wat effectief betekend dat je de waarde verwijderd.

Wanneer je dit zo veel gedaan hebt als je nodig hebt om alleen de datum nog in het veld over te houden kan je het veld transformeren naar een datumveld:

Transformeren kolom in Power BI — Transformeren naar datumveld

Tot slot kan je eventueel nog Kolommen verwijderen die je niet nodig hebt of andere transformaties doorvoeren. Wanneer je klaar bent kie je voor Close & Apply en daarna kan je met je data aan de slag!

Doordat we nu de exportdatum per regel beschikbaar hebben kan je deze datum als peildatum gebruiken voor bijvoorbeeld historische forecast statussen of debiteurenstanden vanuit AFAS Profit.

Tesla Model 3 VIN status met Azure Logic Apps

Als je je droomauto mag bestellen moet je vaak wachten tot je deze daadwerkelijk in ontvangst mag nemen. Bij Tesla is dat wachten een “beetje” een black box, dus wat doe je dan om de tijd te verdrijven? Inderdaad.. kijken hoe je Microsoft Azure kan toepassen op dat wachtproces 😉

Voor wie niet bekend is met het bestellen van een Tesla zal ik eerst kort opsommen hoe dat proces ongeveer gaat (in het geval van een leasemaatschappij):

Je regelt intern de order en deze gaat naar de leasemaatschappij
De leasemaatschappij bestelt daadwerkelijk de auto bij Tesla en doet de aanbetaling
Je ontvangt een mailtje “Welkom bij de Tesla familie” en mag een account aanmaken
Je krijgt een RN nummer en als je geluk hebt een leverindicatie
Vervolgens is eerst alleen in de broncode het serienummer (VIN) van je auto zichtbaar
Het serienummer is zichtbaar op je profiel pagina
Je krijgt een leverdatum aangeboden
Je mag je auto ophalen

Tesla bestelling overzicht. (goed irritant dat de kleur van het interieur op het plaatje niet klopt :() — Beetje jammer dat de interieurkleur niet overeen komt met de kleur in de bestelling 🙁

Stap 1 tot 4 gaan redelijk vanzelf, en dan begint het kijken naar sheets zoals deze om te zien wanneer er weer een schip/shit-load aan Tesla Model 3’s deze kant op komen, in de hoop dat die van jou daar ook bij staat en je dus een serienummer toegekend krijgt.

Het vervelende is echter dat je dus iedere keer (als je een beetje ongeduldig bent, zoals de gemiddelde Tesla besteller) met de hand in de source moet zoeken of er een VIN beschikbaar is (of je gebruikt een Chrome plugin)

Automatiseren die hap

Alles wat of vervelend is om te doen, of je meer dan eens moet doen moet je proberen te automatiseren, en gelukkig zijn er dan oplossingen als Azure Logic Apps om dat te realiseren.

Tesla heeft een API beschikbaar waar je met je account gebruik van kan maken, er is niet echt officiele documentatie van, maar zoals vaker heeft dat het internet er niet van weerhouden er toch gebruik van te maken.

De stappen die we gaan doorlopen:

Een autorisatie token genereren met je Tesla account
Een Azure Logic App bouwen die ieder uur:
1. Een webrequest doet bij Tesla
2. Het webrequest interpreteert en een als dan functie uitvoert
3. Je een mailtje stuurt bij goed nieuws

Ik heb eigenlijk alleen Postman gebruikt voor het maken van de initiele requests, ~~maar met de code voorbeelden hier onder kan je als het goed is zelf wel uit de voeten zonder het gebruik van Postman.~~

Door wat tijdgebrek ben ik er niet aan toe gekomen om een generator te maken voor je autorisatie token, dus dat moet voor nu nog met de hand middels postman. Je kan eventueel ook een externe website gebruiken voor het genereren van je token, zoals bijvoorbeeld deze.

Autorisatie token genereren

Je kan je (Oauth) autorisatie token ophalen door de onderstaande stappen te volgen. Samengevat gaan we een API call doen om met je inloggegevens een token te genereren.

Als je Postman geopend hebt kies je voor “New request”:

Postman "Create New" menu — Postman – New Request

Je moet het request een naam geven en toevoegen aan een “Collection”, je kan hier een bestaande kiezen of een nieuwe aanmaken.

Postman save request menu — Postman – New request details

Als je een nieuw request aangemaakt hebt krijg je onderstaand scherm te zien (alleen dan nog leeg):

Postman request editor — Postman request

Pas het type request aan naar een “POST”
Voer de volgende URL in: https://owner-api.teslamotors.com/oauth/token
Maak de volgende parameters aan en vul de value’s
1. grant_type – password
2. client_id – De waarde voor dit veld vind je hier: https://pastebin.com/pS7Z6yyP en de toelichting hier: https://tesla-api.timdorr.com/api-basics/authentication
3. client_secret – De waarde voor dit veld vind je hier: https://pastebin.com/pS7Z6yyP en de toelichting hier: https://tesla-api.timdorr.com/api-basics/authentication
4. email – het email adres van je Tesla account
5. password – het wachtwoord van je Tesla account
Druk vervolgens op Send

Je krijgt nu een response te zien die er grofweg zo uit ziet:

{
    "access_token": "****",
    "token_type": "bearer",
    "expires_in": 3888000,
    "refresh_token": "****",
    "created_at": 1568872567
}

Het access_token heb je in de volgende stappen nodig.

LET OP: Het token dat je hier aanmaakt (en je login gegevens sowieso) geven controle over veel meer dan alleen de data die we nu ophalen, ook zodra je je auto eenmaal hebt kan dit token gebruikt worden voor bijvoorbeeld het openen van de deuren.. Zorg er dus voor dat je zorgvuldig om gaat met het token. Tokens zijn momenteel 30 dagen houdbaar en moeten dan vervangen worden (zie daarvoor de documentatie)

Azure Logic App aanmaken

Logic apps kosten (zoals veel services op Azure als je ze goed gebruikt) zo ongeveer niks, en zeker niet als je het voor dit doel gebruikt. Als het wachten een beetje mee zit zou je zelfs in je trial account genoeg dagen gratis gebruik moeten hebben zitten om daarmee de wachttijd uit te zitten.

Als je nog geen account hebt kan je deze aanmaken via portal.azure.com, als je wel al een account hebt kan je daar inloggen en in de zoekbalk zoeken naar “Logic Apps”

Op de volgende pagina kan je vervolgens middels “Add” een nieuwe logic app aanmaken:

Het aanmaken van de lege Logic App is in tegenstelling tot sommige andere Microsoft Azure onderdelen relatief eenvoudig:

Logic App aanmaken interface — Logic App Aanmaken

Je voert een naam in, kiest een subscription en een bestaande of nieuwe resource group (een bundel gerelateerde services en onderdelen) en kiest tot slot een locatie, waarbij het zinnig is een locatie zo dicht mogelijk bij je eigen locatie te kiezen.

Het aanmaken zelf duurt vervolgens even (1-2 minuten, verwaarloosbaar in Tesla-tijd), maar na een tijdje zie je je gloednieuwe Logic App in de lijst staan:

Azure Logic App overzicht — Logic App overzicht na aanmaken App

Je kan hier vervolgens op klikken en zal dan naar de design view gestuurd worden waar we de logic app kunnen gaan inrichten.

Azure Logic App configureren

In het eerste overzicht dat je krijgt zie je allerlei templates staan. Deze zijn leuk om eens mee te experimenteren, maar voor deze app kiezen we voor een “Blank Logic App”

Lege logic app template — Een leeg template

De eerste stap die je vervolgens zet is het bepalen van een trigger. De trigger bepaalt wanneer het proces in de Logic App moet starten. Je hebt hier een grote hoeveelheid opties die interessant zijn om te bekijken. In dit geval kiezen we voor de “Schedule” optie, en vervolgens voor recurring (oftewel, starten op basis van een timer):

Logic app recurrence — Logic App trigger

De vervolgstap is het invoegen van de daadwerkelijke actie waar het proces mee moet beginnen. In ons geval gaan we een “GET” actie uitvoeren tegen de Tesla API. We geven hierbij een autorisatie header mee met het Autorisatie token dat we eerder in deze post aangemaakt hebben met ons account.

Voor het toevoegen van deze stap zoeken we naar HTTP, en kiezen voor de HTTP actie, je krijgt dan een veld zoals hier onder:

Logic app http request — HTTP Request opbouwen

De waardes die je hier invult:

Method: GET
URI: https://owner-api.teslamotors.com/api/1/vehicles
Headers: Authorization | Bearer “token zoals eerder gegenereerd”

Wat deze stap doet is het webrequest opbouwen dat volgens het schema dat we eerder samengesteld hebben aangeroepen wordt.

De volgens stap is het oppakken van het resultaat van het webrequest dat we hiervoor aangemaakt hebben. We gaan het resultaat omzetten naar een JSON object, dat is niet per definitie nodig voor de werking zoals de app nu is, maar bied wel meer mogelijkheden voor de toekomst en is een kleine moeite.

Voeg een action toe en zoek naar “Parse JSON”. Je krijgt een blok te zien zoals hier onder:

Logic app JSON parser — Parse JSON configuratie

Klik hier eerst in het “Content” vak (1) en vervolgens in het Dynamic Content veld onder HTTP (eventueel even op klikken als je geen opties ziet) op “Body” (2). Tot slot klik je dan op ” Use Sample Payload to generate schema ” (3) en voer deze code in:

{
    "response": [],
    "count": 0
}

Er zal een schema gegenereerd worden waar we later naar refereren.

De volgende stap is een stukje “Als, dan” logicia om te zorgen dat je alleen een bericht ontvangt als er een VIN gekoppeld is aan je account. Je zoekt hiervoor naar de actie “Control” en kiest vervolgens voor “Condition”:

Logic app controller / condition — Condition Operators

De eerste stap die we hier zetten is de werkelijke vergelijking bepalen. In her eerste veld klikken we en kiezen we in de “Dynamic” content voor de waarde “Count”. Deze stap is iets makkelijker geworden door het schema dat we hier voor toegevoegd hebben, anders had je dat veld hier handmatig moeten specificeren.

Als de “Count” waarde niet gelijk is aan 0 is er dus blijkbaar een auto toegevoegd aan je account, dus dan gaan we in de volgende stap een “If true” actie instellen. Klik hiervoor op “Add an action” in het “If true” blok. Vervolgens zoek je naar “Send email”, in mijn geval kies ik hier voor Office 365 en vervolgens opnieuw voor “Send Email”, je mag vervolgens inloggen:

Logic app mailer connector — O365 Sign In

Na het inloggen kan je de mail opmaken, je kan hierbij elementen gebruiken uit alle eerdere stappen, deze zijn beschikbaar als dynamic content. Ik heb het niet al te moeilijk gemaakt en gewoon de hele HTTP response gepakt, als de auto eenmaal gekoppeld is maakt het me niet zo veel meer uit dat het mailtje niet zo mooi is ;). Als het menu bij Dynamic Content leeg blijft moet je even op “See more” klikken.

Uiteindelijk heb je dan iets zoals hier onder:

Logic app totaaloverzicht — Logic App overzicht

Als je hier eerst nog op “Save” (1) en vervolgens op “Run” (2) klikt zal de app eerst een keer zichtbaar draaien en vervolgens ieder uur op de achtergrond (volgens het eerder ingestelde schema). Je kan op deze pagina meteen zien wat er in iedere stap gebeurt is en wat het resultaat is geweest. Als het “goed” is zal je geen mail krijgen omdat er nog geen gekoppelde auto is. Als je zeker wil weten dat alles naar behoren werkt zou je ook een bericht kunnen koppelen aan de “If false” branch, maar dat is normaal gezien eigenlijk niet nodig.

Wachten

Als de logic app eenmaal draait merk je daar doorgaans niets van (tot je goed nieuws krijgt). Als je dan toch de status wil zien kan je de logic app op de Azure Portal opzoeken en open klikken. Je ziet dan altijd een overzicht van de keren dat de app gelopen heeft en de resultaten van iedere run:

Logic app history — Azure logic app history

Verder rest er nu dan niets meer dan wachten tot de mail komt.

Tot slot

Echt heel erg zinnig is deze logic app natuurlijk niet, maar het is wel een (erg simpele) introductie tot een zeer krachtig Microsoft Azure onderdeel wat eindeloos veel toepassingen kent en eigenlijk voor iedereen relatief goedkoop beschikbaar is.

Azure Function App Proxy

In de voorgaande posts hebben we het gehad over een directe koppeling tussen AFAS Profit en Power BI en het gebruik van een Azure Function App om scripts te kunnen draaien. Deze twee onderdelen hebben echter nog een extra toepassing.

Wanneer je een Power BI rapportage die gebruik maakt van directe AFAS Profit data wil publiceren ga je bij de refresh problemen krijgen met het autoriseren van de (web) databronnen. Het probleem is dat het deel van de URL met de autorisatie token afgekapt wordt (samen met eventuele filters). Waarom dit precies gebeurt is mij niet helemaal duidelijk. Een mogelijke oplossing is het gebruik van een Azure Function App Proxy. Als je toch al een Azure Function App hebt voor het draaien van je scripts kost deze proxy je normaal gezien niets extra.

Wat gaan we doen?

Een Azure Function App Proxy kent vele mogelijke toepassingen. In dit voorbeeld gaan we de Proxy tussen de AFAS Profit Webconnector (REST) en Power BI plaatsen. Power BI gaat een request naar de proxy sturen met een aantal parameters, de proxy reformat het verzoek en doet het verzoek bij de Profit omgeving. Het resultaat wordt vervolgens 1-op-1 doorgestuurd naar Power BI. (We zouden hier eventueel nog acties aan de response kunnen hangen, maar dat is nu niet nodig).

De stap voor het maken van de function app zelf slaan we deze keer even over, als je wil weten hoe dat werkt kan je dit item lezen. Ik ga dan ook uit van dezelfde demo als in die post, het startpunt is dan ongeveer het volgende:

Toelichting endpoint (AFAS Profit REST API)

Wanneer je gebruik wil maken van de AFAS Profit REST API moet er gewerkt worden met een bepaalde opbouw van de URL gecombineerd met een een autorisatie header. Wanneer je deze direct vanuit Power BI ingeeft als bron kan je deze handmatig autoriseren, echter, wanneer je de rapportage publiceert werkt deze authenticatie niet meer. Dat betekend dat we een tussenstap moeten maken.

Het doel is uiteindelijk dat we een request zoals deze naar naar de REST API van Profit kunnen sturen:

https://url_van_omgeving/profitrestservices/connectors/{connector}

Vervolgens moeten daar de connector specifieke velden, filters en autorisatie aan meegegeven worden. Alle velen die we nodig hebben zijn al bekend gezien we deze in de directe koppeling uit de eerdere posts ook al gebruikt hebben.

Inrichting Azure Function App Proxy

Wanneer je in het Function App menu zit zie je bij Proxies ongeveer het volgende:

Je kan daar op de + klikken om een nieuwe proxy aan te maken, daarvoor moet het een en ander ingevoerd worden, dat ziet er dan uiteindelijk ongeveer als volgt uit:

We lopen even door de velden heen:

Route template

Hier geef je de structuur van de proxy url op, in dit geval beginnen we met de “/naca” dit doet van zichzelf niets. Het geeft een stukje structuur waarmee de url’s en verwijzingen van elkaar onderscheiden kunnen worden. Dit wordt gevolgd door een aantal velden tussen {} geplaatst zijn. Dit zijn de variabelen die we willen kunnen gebruiken in de “request override” of de “header”. In dit geval zijn dat:

Token = Autorisatie token (zie eerdere posts)
Periode = De periode waarvan we de data op willen halen, dit gaan we in een filter gebruiken
Connector = De naam van de connector die we op willen roepen.

Het resultaat van deze route template komt terug in de URL die je gebruikt in Power BI.

Backend url

Dit is het adres waarop de AFAS Profit REST API benaderd kan worden. Je ziet hier aan het einde {connector} staan, dat wil dus zeggen dat hij de variabele uit de request URL overneemt naar de backend url.

Request override

Vervolgens zal je de “Request override” open moeten klikken en invullen, voor de duidelijkheid staat hieronder nog specifiek een screenshot van dat onderdeel:

Dit is het deel waar we het request dat naar de Azure Funtion App Proxy gestuurd is om gaan zetten naar het request waar onze AFAS Profit omgeving wat mee kan.

De skip en take velden zijn gelijk aan wat we kennen uit de directe koppeling. We kunnen hier direct ook een specifieke periode ophalen. We gebruiken hiervoor de standaard filter opties van de AFAS Profit REST API. Het “filterfieldsids” geeft de velden aan waar je op wil filteren. Het “filtervalues” veld is de waarde waarop je op wil filteren, je ziet hier {periode} staan, wat weer betekend dat we de variabele die we in de route template gespecificeerd hebben overnemen in het filter voor AFAS. Tot slot staat er nog “operatortypes” en dat is weer een onderdeel van de filteropties vanuit Profit.

Je kan in deze velden eigenlijk alles kwijt wat je normaal ook zou gebruiken bij het ophalen van een getconnector in AFAS Profit.

Headers

Tot slot moeten we nog de autorisatie headers mee geven. Dit is namelijk de hele reden dat we de directe koppeling niet in de gepubliceerde rapportages kunnen gebruiken. Het token wat we nodig hebben zit al in het route template. Zoals eerder zie je ook hier weer dat we de variabele kunnen gebruiken, in dit geval het veld {token}:

Het “ContentType” veld en de inhoud (“application/json;charset=utf-8”) zijn voor Profit connectoren altijd gelijk.

Als we dit alles ingevuld hebben kan de proxy opgeslagen worden. Je krijgt dan een URL terug die je in het vervolg kan gebruiken voor het ophalen van de data uit AFAS Profit. De URL ziet er grofweg als volgt uit:

https://****.azurewebsites.net/naca/{token}/{periode}/{connector}

Verwerking in Power BI

Je kan de URL hier boven nu gebruiken in de rapporten die je wil publiceren. Hiervoor maak je in Power BI een “web” bron aan:

Je bouwt deze vervolgens op aan de hand van de structuur voor de proxy url zoals we deze in de vorige stap gemaakt hebben:

Wanneer je deze bron nu opslaat kan je de data gebruiken op dezelfde manier als de directe koppeling die we in een van de eerdere posts gemaakt hebben. In het voorbeeld hierboven heb ik gebruik gemaakt van parameters in Power BI om de variabelen op te slaan en mee te nemen. Je kan hier ook direct de waardes voor de variabelen vullen.

Veiligheid

Op zich is het gebruik van de proxy net minder veilig dan de directe koppeling naar Profit. Echter, het is wel altijd een goed idee om een stap extra te zetten om de hoeveelheid mensen die potentieel de data kunnen benaderen te verkleinen. Je kan daarvoor op IP niveau filtering aanbrengen voor je Azure Function App. In ons geval weten we zeker dat alleen vanaf 2 kantoren en onze datacenters gewerkt mag worden met deze data (alles voor Power BI loopt via onze “On-premises Data Gateways”).

Open hiervoor het overzicht van je function app, kies hier voor “Platform features”:

Vervolgens voor “networking”:

Onderaan zie je de optie “ip restrictions”:

Je ziet dan een pagina zoals hier onder:

Hier kan je regels toevoegen om de adressen vanaf waar de apps benaderd mogen worden te beperken.

Tot slot

Het heeft even geduurd voordat ik dit artikel daadwerkelijk helemaal af heb kunnen maken. De techniek hier achter is niet heel complex maar er zijn talloze mogelijkheden en oplossingen denkbaar in Azure. Ik wilde graag iets meer ervaring opdoen voordat ik dit stuk helemaal af zou ronden. Dit zodat iemand die hier mee aan de slag gaat geen onnodige stappen hoeft te zetten of onnodige risico’s loopt.

Mochten er naar aanleiding van dit stuk nog vragen zijn hoor ik het graag!