De herontdekking van informatiebeveiliging
Dit blogje had al even geleden geschreven moeten worden. Niet heel lang geleden, maar wel een paar weken. In de voorgaande blogs ging het over datalekken, vooral vanuit oude(rwetse) informatiesystemen. En wat mij betreft is het probleem niet zozeer dat die systemen niet deugen, maar eerder dat de beslissingsbevoegdheid voor toegang heel vaak verkeerd is belegd. Dat is natuurlijk van oudsher ontstaan, in vroeger tijden toen ict-afdelingen de systemen ontwikkelden. Maar dat wil niet zeggen dat het zo moet blijven. Integendeel, de bedrijfsvoering (de ‘business’) moet weer de zeggenschap krijgen. En daarbij moeten misschien wel alternatieve wegen worden bewandeld. De wereld is veranderd, de bedrijfsprocessen veranderen en de informatievoorziening is veranderd.
Vroeger werd een systeem gebouwd om gegevens te beheren, waarbij iemand voor het gebruik van dat systeem een account krijgt en waar een beheerder aan die gebruiker de rechten toekende. Dat leidde tot enorme fragmentatie van accounts in verschillende systemen om processen te kunnen uitvoeren. Tegenwoordig doen we het anders. We kopen nieuwe cloud-gebaseerde diensten, en verlenen mensen met een enkel Azure account via single sign-on toegang tot al die diensten en gegevens.
En dan nog gaat het fout..
We zijn weliswaar af van dat accountmanagement en wachtwoordenbeheer, maar toegang is nog steeds niet opgelost.
En de reden is dat we nog steeds in mensen, systemen en diensten denken. We kopen een systeem of een dienst om onze medewerkers te helpen met onze processen. Maar dat is niet meer schaalbaar. Probeer maar eens om aan business partners, klanten en leveranciers toegang te verlenen. De verleiding is groot om dat op traditionele manieren te doen, om op een traditionele manier onze informatie te beveiligen. Toegangsbeheer vanuit de optiek van accounts en systemen is niet schaalbaar.
Dat moet anders: “‘wie’ is niet schaalbaar”
We moeten niet meer denken vanuit de traditionele kaders, maar we moeten denken vanuit de processen en de gegevens die worden verwerkt. Niet meer denken aan wie toegang mag hebben tot processen en gegevens (‘wie’ is niet schaalbaar), maar waarom, onder welke voorwaarden iemand toegang zou mogen hebben om de beveiligde informatie te kunnen gebruiken. En dan komen we weer bij de kern van informatiebeveiliging: de informatie moeten we beveiligen, niet de gebruikers. Op grond waarvan mag iemand een proces of een informatie-element gebruiken? En dat kan van alles zijn. Dat kunnen competenties van de gebruikers zijn (junior versus senior), het betrouwbaarheidsniveau van de persoon (bijvoorbeeld afkomstig van een betrouwbare partner, met multi-factor authenticatie), bedrijfsregels rondom belangenverstrengeling (iemand mag niet zijn eigen objectgegevens, bijv. een eigen declaratie afhandelen) of een key control als functiescheiding (als iemand taak 3 heeft uitgevoerd, mag die persoon niet ook taak 4 afhandelen).
Maar het gaat hierbij dus niet over: Wie ben je, wat is je rol, wat is je profiel, wat mag je. Het gaat over: waarom zou je dit mogen. Het is een omgekeerde vraagstelling. Natuurlijk moeten we nog steeds wel weten wie iets gedaan heeft, maar dat is gewoon standaard logging en monitoring, dat kennen we al.
Dus terug naar de basis, beveiligen van informatie.
De meeste traditionele systemen zijn daar niet echt voor gemaakt. Er zijn meer knelpunten dan datalekken die het resultaat zijn van onhandige toegangsfaciliteiten. Op termijn moeten we terug naar beveiliging van informatie, juist omdat we die gebruiker zelf misschien niet eens meer kennen. En dat moment is sneller dan we misschien wel denken: denk maar eens aan het ontsluiten van API’s en machine2machine communicatie. Denk maar eens aan een Zero Trust Architectuur. In die omgevingen bestaan geen accounts meer, er is alleen toegang. Dat betekent dat we op grond van die ontwikkeling identiteit en toegang moeten scheiden. En dat betekent dat we op basis van toegangsbeleid, op basis van access policies, toegang verlenen. Gebruik makend van allerhande andere kenmerken dan gebruikersnamen en rollen. Attribute Based Access Control, Policy Based Access Control in plaats van Role Based Access Control.
Voor meer achtergronden verwijs ik graag naar een mooi artikel van Mary McKee: https://bok.idpro.org/article/id/61/
IDPro is de beroepsvereniging van Identity & Access professionals. SonicBee is partner van IDPro en levert een actieve bijdrage aan ontwikkeling en delen van de kennis binnen het vakgebied. Het artikel van Mary is voor ons een een waardevolle bijdrage aan het vakgebied!