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.

Security awareness

Iedereen die voor een organisatie van een beetje formaat werkt zal inmiddels wel bekend zijn met Security Awareness trainingen. Wat is nou een datalek, wat moet ik doen bij een datalek en hoe houd ik mijn werkomgeving en daarmee de data van je werkgever en haar klanten zo veilig mogelijk. Soms voelt het een beetje als die verplichte hoepel waar je jaarlijks doorheen moet springen. Maar toch is het echt de moeite waard om aandacht te besteden aan wat er allemaal voorbij komt bij een dergelijke training.

De ontwikkelingen

Het aanbod in de markt voor de verschillende trainingen op dit gebied is gelukkig flink gegroeid en daarmee ook zeker in kwaliteit verbeterd. Een meer interactieve vorm van trainen begint gelukkig ook meer en meer de norm te worden. Echter, wat mogelijk een nog veel belangrijker aspect is dat de trainingensteeds vaker geplot worden op de deelnemer als mens, en niet zo zeer alleen de deelnemers als medewerker.

Dat laatste is niet geheel onbelangrijk. Met de verschuiving van centrale werkplekken zoals Citrix en Remote Desktop omgevingen naar toch weer meer werken op de endpoints zelf (laptops telefoons) wordt het ook moeilijker om je bedrijfsdata veilig op te bergen in een centrale omgeving met een hoge muur er omheen. Er is natuurlijk van alles technisch te realiseren om de potentieel onwenselijke toegang tot deze data en systemen te voorkomen, maar feit is wel dat de gebruikers buiten het zicht van je eigen infrastructuur op pad gaan met hun devices en jouw data.

Alles op slot of totale vrijheid?

De waarheid ligt uiteraard in het midden en het antwoord is sterk afhankelijk van de data waarmee gewerkt wordt. In het geval van privacy gevoelige data zal je eerder geneigd zijn om de zaak goed op slot te zetten terwijl er andere scenario’s denkbaar zijn waarbij meer vrijheid op zijn plaats is.

Toch wil je in alle gevallen wel grip houden op je endpoints en alles wat daar op staat. Effectief resulteert dat er in dat in de gevallen dat je meer vrijheid geeft je ook meer monitoring zal toepassen om ten alle tijden te weten welke applicaties er gebruikt worden, welke datastromen er van en naar deze endpoints gaan, welke processen er allemaal draaien en hoe dit alles met elkaar samenhangt.

Alhoewel alles op slot zetten de veiligste optie lijkt heeft het wel als gevolg dat de kans dat de gebruikers om de officiele IT systemen heen gaan werken aanzienlijk toeneemt. Als de gebruiker vindt dat hij/zij niet goed kan werken met de aangeboden toolset zal er gezocht worden naar alternatieve werkwijzen die mogelijk buiten het zichtveld van de security en IT afdelingen liggen, met alle risico’s van dien.

Zoals met alles is het dus zaak om een balans te vinden en dat valt of staat met een goed beeld van de risico bereidheid van een organisatie. Die zal anders zijn voor een ziekenhuis dan bij een loodgieter, maar de ene loodgieter is ook de andere weer niet.

Sidenote: Technische uitdagingen bij totale vrijheid

Bij een groot deel van de organisaties zie je dat er een consolidatie plaatsvind van security componenten in het Microsoft framework. Het verwerken van deze data vergt verregaande automatisering en veel kennis, zeker ook omdat enkel het verwerken niet voldoende is, er moet ook nog geacteerd worden op de bevindingen. (Bij voorkeur automatisch). Het consolideren van deze componenten in één omgeving maakt de implementatie overzichtelijker en sneller en je kan bovendien leunen op de expertise van een gigant als Microsoft. Het voordeel is dat het vrijwel onzichtbaar is voor de eindgebruiker en zelfs voor een groot deel van de beheerders, maar het risico is dat de effort om dit goed te implementeren vaak onderschat wordt.

Gevolgen voor security awareness

Hebben de bovenstaande keuzes dan impact op de security awareness training? Voor sommige feitelijke componenten wel uiteraard, je kan lastig in een training verkondigen dat de gebruiker zelf geen applicaties mag installeren terwijl dat wel zo is. Maar in zo goed als alle andere onderdelen van de security awareness training zou het niet al te veel uit moeten maken

Security awareness zou moeten gaan om het activeren van bewustzijn en gedragsveranderingen. En dat gaat verder dan alleen de training zelf natuurlijk. Het moet normaal worden om elkaar ook aan te spreken op zaken die niet door de beugel kunnen, dus ook jij kan die projectengineer die “tijdelijk” even het wachtwoord Welkom01 invult daar gewoon op aanspreken.

Elkaar aanspreken is dus geen synoniem voor “de ander voor de bus gooien” en dat is misschien ook nog iets waar we met zijn allen in het security domein nog wat over kunnen leren. Tenzij iemand een “veelpleger” wordt moeten we er vanuit gaan dat security nou eenmaal niet top-of-mind is voor iedereen. Daarnaast heeft harder schreeuwen maar zelden tot een oplossing geleid (ik hoop dat mijn kinderen dat ooit nog leren).

Bomen in een bos — De gebruikers zien door de bomen het bos niet meer

Mensen met een technische achtergrond zijn geneigd om te vergeten dat niet iedereen dezelfde technische basiskennis heeft. We grijpen dan ook te vaak naar het uitleggen van de technische maatregelen. Zaken als “controleer de URL in de mail goed voor je klikt” terwijl het overgrote deel van de bevolking geen idee heeft van wat een URL nu eigenlijk is, laat staan hoe je een Office365 safelink kan controleren.

Focus op gedragsverandering

Het is goed om mensen bekend te maken met termen zoals Phishing, Spam, Malware, Cryptolocker en al dat soort zaken, maar voornamelijk om context te bieden voor alle berichten die ze daarover tegenwoordig voorbij zien komen.

Het doel van security awareness zou niet zo zeer het trainen van technische handelingen moeten zijn. Maar een gezond wantrouwen tegenover zaken die je zelf niet onder controle hebt. En doe dat in een context die mensen kennen of waar ze meer affiniteit mee hebben. Een voorbeeld:

Als iemand ergens snoep op de grond vind hebben we allemaal geleerd dat we dat beter niet op kunnen eten. Dit leren we al op jonge leeftijd en gaan zelfs nog een stapje verder, als je snoep aangeboden krijgt van een vreemde leren we onze kinderen dat je dat moet weigeren.

Hoe is dit anders dan het vinden van een USB stick op de parkeerplaats? Je zal er zelf niet ziek van worden of worden gedrogeerd, maar je laptop wel..

Door te linken aan allerlei zaken die al vanaf onze jeugd in ons brein geprint zijn kunnen we security zaken die van origine puur technisch zijn aanhaken op ons instinct wat we al jaren gekweekt hebben.

Een ander makkelijk voorbeeld is vreemden binnenlaten op het kantoor. We zouden thuis iemand die bij de deur staat die we niet kennen nooit zomaar binnen laten, maar toch vinden we het op kantoor vrij normaal om iedereen maar gewoon mee door de deur te laten lopen. Er heerst een soort van schaamte om toch even te vragen of die persoon er wel hoort.

Daarnaast moeten we ons aanleren dat we berichten die we ontvangen allereerst moeten toetsen op of we een dergelijk bericht wel verwachten en of het past bij de afzender. Een directeur die ineens een Engelse mail stuurt om geld over te maken terwijl hij dat anders nooit zou doen moet natuurlijk alarmbellen af laten gaan. Maar ook de mail van een “webshop” die ineens op je zakelijke adres binnen komt terwijl je daar zakelijk niets koopt moet wel wat te denken geven.

Conclusie

Ik heb de wijsheid niet in pacht en er zullen ongetwijfeld anderen zijn die hier een andere visie over hebben. Maar ik denk dat we het met zijn allen eens zijn dat te technische security awareness trainingen eerder een averechts effect hebben op de bewustwording. Gelukkig lijkt de markt voor dergelijke trainingen zich dat ook te realiseren. Wel zijn er kansen voor trainigen juist gericht op het IT personeel van een organisatie.

Met een focus op gedragsverandering en het aansluiten op zaken die mensen al kennen vanuit het dagelijkse leven die niet per se IT gerelateerd zijn kunnen we gebruik maken van het gezonde wantrouwen wat iedereen tot op zekere hoogte in zich heeft. IT is immers meer en meer verweven in het dagelijkse leven, en het bewustzijn van de risico’s die daarbij komen kijken behoren dan ook tot de basiskennis die iedereen zou moeten hebben.

Ik heb een game geschreven

Eigenlijk een hele tijd terug al, maar het was er nog niet echt van gekomen om daar hier wat over te schrijven. Nu met een klein beetje extra tijd is het wel aardig om eens wat inzage te geven over hoe ik het schrijven van een web-based spel nu eigenlijk aangepakt heb. Niet op de laatste plaats omdat ik daar 0 ervaring mee had, en als ik het kan dan kan jij het ook.

Het gaat hier om clickfarm.nl een simpele web game die uiteindelijk draait om het verzamelen van zo veel mogelijk geld met een zo goed mogelijk gebalanceerd en geautomatiseerd productie proces.

Clickfarm landbouw knop — Dit zou ik niet handmatig blijven doen 😉

Waarom heb ik een game geschreven?

Ik vroeg me af of ik mezelf iets helemaal nieuws kon leren, alhoewel ik in het verleden wat PHP geschreven heb in in mijn werk de nodige scripts schreef wilde ik graag weten of ik ook HTML, CSS en Javascript kon leren.

Wat begon met een knop die simpelweg een teller liet oplopen mondde uit in een volledig spel met meer dan 2.000 regels code (dat had vast efficiënter gekund). Ik heb veel geleerd over JavaScript en ook het nodige over HTML en CSS, maar daar ligt voor mij toch minder de focus.

Random clickfarm broncode — Random clikcfarm code (game geschreven)

Mijn doel was dus het leren van een nieuwe taal, en dit is de eerste keer geweest dat er voor mij ook echt wat geklikt heeft waarbij ik het gebruik van objecten, functions en al dergelijke zaken ook heb kunnen plaatsen. Alles wat ik hierna geschreven heb voelt aanzienlijk eenvoudiger omdat er blijkbaar wat op zijn plek gevallen is.

Hoe heb ik de game geschreven?

Excessief gebruik van Google en heel veel proberen. De aanpak was heel iteratief en ik heb niet vooraf een groot plan gemaakt over hoe de bouw er uit zou gaan zien, sterker nog, de meeste functionaliteit is on the fly bedacht terwijl ik het aan het schrijven was. In dat opzicht is het een klein wonder dat het spel zo goed werkt als dat het doet.

Verder heb ik zeker in de latere stadia van de ontwikkeling veel input gebruikt vanuit onder andere het forum op Tweakers.net om het nodige in balans te brengen.

Ik denk wel dat dit een mooi voorbeeld is van hoe je als je enige affiniteit hebt met scripting vrij eenvoudig je kennis steeds verder kan uitbreiden. Begin met een klein projectje en bouw daar op door, probeer niet meteen de lat te hoog te leggen en accepteer dat het een zeer iteratief proces gaat zijn.

Wat is er van gekomen?

Los van dat ik er een hoop van geleerd heeft hebben een hoop mensen veel tijd van hun leven verloren met het spelen van het spel. Op de piek waren er 400+ gelijktijdige spelers met een paar duizend bezoekers per dag op de site. Ik heb nooit reclame op de site gehad, maar wel de mogelijkheid geboden om donaties te doen, en wonderwel ook daadwerkelijk voor een aardig bedrag aan donaties ontvangen (dat had ik niet verwacht).

Voor mezelf is het voornaamste doel bereikt, ik heb weer een nieuwe taal geleerd waar ik comfortabel mee aan de slag kan. De stap naar NodeJS is inmiddels ook gezet dus ook daar ben ik inmiddels de nodige kennis van op aan het doen.

Tot slot

Alhoewel ik niet uitsluit dat ik later nog een klein stukje verder schrijf aan het spel en mogelijk het een en ander zal moderniseren acht ik dit ook weer niet heel waarschijnlijk. Het is een mooi project geweest en ik heb er een hoop van geleerd, maar het verder onderhouden zou wel aardig wat tijd gaan kosten waar voor mijzelf eigenlijk niets meer tegenover staat.

De code van het spel is beschikbaar op Github, mocht iemand nog goede toevoegingen aanbieden via die route zal ik die waarschijnlijk nog wel implementeren.

GitHub – HermanRonk/Clickfarm: Clickfarm webgame

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.