• Home
  • Nieuws
  • Terug naar de tekentafel met Access Management

Terug naar de tekentafel met Access Management

Opinie door Robin van Sambeek, co-founder Topicus

Uitdagingen te over voor hosters. Hosters dragen de verantwoordelijkheid voor het continueren van kritieke systemen en processen. Klanten vertrouwen er op dat dit zorgvuldig en goed wordt uitgevoerd. Toch is het vanuit de optiek van een klant vaak een black box met veel ‘magie onder de motorkap’. Een incident waarbij ineens wat gebeurt zonder dat exact duidelijk is wie wat heeft gedaan. Hier wringt de schoen weleens. Waar er vroeger volledig vertrouwen was van de klant in de hosting provider zien we steeds meer een beweging waar de klant transparantie wil over wie er wat op zijn systemen of servers doet.

Een goed hostingbedrijf wil die transparantie natuurlijk ook bieden. Toch zijn we er in de laatste jaren, waar de mogelijkheden van IT haast eindeloos lijken, aan gewend geraakt dat deze kloof tussen beheer en gebruik is gegroeid. Zo is het tegenwoordig bijna normaal geworden dat er op basis van puur vertrouwen administrator-accounts worden verstrekt. Logisch gezien de noodzakelijke werkzaamheden, maar vreemd vanuit het oogpunt van een klant: de controle op toegang tot systemen wordt hiermee namelijk op vertrouwen uit handen gegeven. Iets dat zeker gezien de AVG-wetgeving een groot aandachtspunt is.

Het kan ook anders. Als we terug gaan naar de tekentafel, wordt er een ander plaatje geschetst. In dit plaatje is het de klant die verantwoordelijk is voor toegang tot zijn systemen. De klant bepaalt wie er met welke rechten mag inloggen en tevens bepaalt de klant welke eisen er worden gesteld aan deze toegang. Het is helemaal niet raar dat een systeembeheerder toegang moet vragen tot een omgeving. En dat deze admin een gepersonaliseerd account krijgt zodat te allen tijde terug kan worden gezien wie welke updates heeft uitgevoerd. Het is ook niet vreemd dat het account van die administrator nadat hij zijn werk heeft gedaan automatisch weer wordt uitgezet . Het klinkt misschien vreemd, maar alleen maar omdat we niet gewend zijn dat het mogelijk is.

Naar klanten toe is dit natuurlijk een mooie gelegenheid om transparant te zijn, en ook ook een commerciële kans. Klanten zullen het op prijs stellen dat niemand zonder toestemming kan inloggen op hun omgeving. Als het wel nodig is, gebeurt het op naam en middels 2-factor authenticatie en na gebruik wordt het account automatisch weer gedeactiveerd. Alles natuurlijk vastgelegd in een leesbare audit trail. Geen admin-rechten, geen ongepersonaliseerde toegang en geen standaardwachtwoorden meer. Maar wel vertrouwen uitstralen naar de klant en aantoonbaar in controle.

Hoe werkt dit in de praktijk?

De toegang tot systemen wordt bijvoorbeeld gekoppeld aan de ActiveDirectory van de klant. Dit AD wordt real-time geprovisioned met accounts van de engineers inclusief een prefix van de hostingprovider. De conventie is dan – wat voor mijn accountnaam betekent: TKH-robin.van.sambeek.

Een klantcase

De klant belt met een probleem. Een engineer van de hoster gaat aan de slag om dit te verhelpen. Als eerste activeert hij zijn klant-account. Op dat moment wordt zijn account aangezet in de ActiveDirectory van de klant en met de daarbij behorende rechten kan hij inloggen. De engineer lost het probleem van de klant op en logt weer uit. De engineer zet zijn account weer uit of dit gebeurt automatisch na een ingestelde tijd. Na de werkzaamheden is er dus geen actief account meer op de omgeving van de klant, waardoor dat account ook niet misbruikt kan worden.

Op de achtergrond wordt netjes bijgehouden dat zijn account aan- en later weer uitgezet wordt, eventueel zelfs met een expliciete reden waarom er is ingelogd. Dit geeft de hoster ook bewijslast naar de klant over wanneer een medewerker toegang heeft gehad op zijn systemen.

Terug naar de tekentafel levert vaak nieuwe inzichten. Zo ook in het geval van access management. Waar de verantwoordelijkheid van toegang ligt, behoort een weloverwogen keuze te zijn waarbij keuzes uit het verleden geen garanties bieden voor de toekomst. Het is niet alleen de wet die dit vereist, het is niet alleen de klant die het wil, het is vooral de dienstverlener die het moet willen aanbieden.

Meld je nu aan voor onze nieuwsbrief!
[mc4wp_form id="483"]

ISPConnect en DHPA zijn nu Dutch Cloud Community

We zijn sinds januari 2021 gefuseerd tot de Dutch Cloud Community.

De fusie van ISPConnect en DHPA heeft plaatsgevonden om als nieuwe branchevereniging de belangen te behartigen voor de Nederlandse cloud-, hosting- en internetsector.

Al onze informatie vind je vanaf nu op dutchcloudcommunity.nl