De huidige stand van hardware- en software-technieken, zoals onomkeerbare encryptiealgoritmen, maken het mogelijk om een goede beveiliging aan te leggen, meent Huub Hillege, principal data(base) management consultant bij Info-Shunt. ‘Zeker als dit wordt uitgebreid met fysieke controles.
Een voorbeeld hiervan is wanneer een bepaalde applicatie alleen maar vanaf een bepaalde pc in een bepaalde ruimte kan worden gestart tussen zekere tijdstippen en door een bepaald persoon. Ik denk dat dit bij een aantal bedrijven en specifieke overheidsdiensten al meer dan twintig jaar wordt toegepast.’
Maar hoewel dit de beveiliging moet verbeteren, zijn medewerkers hier volgens Hillege niet blij mee. ‘Een veel gehoorde klacht is dan ook dat medewerkers zo niet kunnen werken, wanneer zij al die stappen moeten ondernemen om aan het werk te kunnen gaan. Werknemers moeten dan, als zij iets speciaals moeten doen, vanuit de beveiligde zone 3 naar de bewaking lopen, die zich in zone 1 bevindt, om een envelop voor die dag met noodtoegangscodes te halen, legt Hillege uit. ‘Het management is dan gevoelig voor de welzijnsargumenten van de medewerkers en om die reden wordt dan voor een minder veilige oplossing gekozen.'
Authenticatie en autorisatie
Daarnaast moet er volgens Hillege onderscheid worden gemaakt tussen de authenticatie, waarbij je controleert of je de juiste persoon voor je hebt, en de autorisatie, waarbij je bepaalt welke toegang de herkende gebruiker mag hebben. ‘De authenticatie moet namelijk andere veranderingscycli hebben dan de autorisatie. Zo moet je er bij zwaar beveiligde informatie voor zorgen dat de periode van de verplichte verandering altijd veel korter is dan de tijd die nodig is om de beveiliging te kraken’, licht Hillege toe. ‘Laat de gebruiker nooit direct door een logon op de beveiligde server komen, maar zet altijd een VM-server tussen. Bij DDoS-aanvallen kan die dan namelijk gemakkelijk worden ververst met een ander ip-adres en logon. In geval van nood informeer je alleen de gebruikers over een nieuwe route of server.’
De laatste jaren is er een sterke beweging geweest bij vooral de grotere organisaties om de beveiliging aan gespecialiseerde bedrijven te outsourcen, zegt Hillege. ‘In mijn optiek wordt dit echter onveiliger.’ Dit licht Hillege toe door de verschillen tussen het outsourcen en centralisatie naast elkaar te zetten. ‘Bij de derde partij, ergens anders in de wereld, voeren beveiligers scripten uit om database toegang en dergelijke verzoeken uit te voeren. Deze verzoeken zijn meestal via een 'ticket'-systeem aangevraagd. Omdat er zeer veel nuance in de autorisaties kan zijn en bij het uitvoerende bedrijf veel wisseling van uitvoerders, ziet men dat de wijzigingen met behulp van een 'functionele user logon, zoals database administrator (dba), worden uitgevoerd. Uit oogpunt van security, vanuit het data-eigenaarschap, is later niet meer te achterhalen (door bijvoorbeeld auditors) welke persoon de 'dba'-logon heeft gebruikt om zekere wijzigingen of autorisaties door te voeren.’
Een ander gevaarlijk aspect is volgens Hillege dat voornoemde gebruikers van de 'dba'-logon relatief weinig kennis cq overzicht hebben: De outsourcing moet immers goedkoper zijn dan een goede dba in Nederland. ‘Wanneer er dan een fout wordt gemaakt, kan dat vergaande gevolgen hebben omdat de krachtigste logon is gebruikt .’ Dit is dus een lek in de opzet, meent Hillege.
‘Om dit alsnog te voorkomen worden er procedures ontworpen waarin alles tot op de 'millimeter' is geregeld. Dan veegt iedereen zijn eigen straatje schoon, omdat daar buiten geen verantwoording wordt genomen. De dynamiek, slagvaardigheid is dan volkomen verdwenen.’ Als voorbeeld noemt Hillege dat het in zo’n ‘millimeter-procedure’ zes weken duurde om drie tabellen in productie te nemen, terwijl een dba in de organisatie dit binnen twintig minuten heeft geregeld.
‘Wanneer je de security (de dba-rol) in de eigen organisatie houdt en centraliseert - al dan niet met beperkte delegatie in verband met tijdzones, en specifieke groepen met speciale eisen - dan kan de eigen beheerder uit de logs of uit de actieve gebruikers direct zien welke gebruiker er niet in de database thuis hoort’, zegt Hillege. ‘Een illegale user kan er dan meteen uit worden gegooid, omdat deze beheerder ook de rechten heeft om dit te doen. Geen aanvraag via ticket systeem!’
Data access
Wat betreft de toegang tot de data, ziet Hillege meestal dat de dba ook alle data kan lezen. ‘Dit is heden ten dage niet nodig om een database management systeem (dbms) goed te kunnen beheren. Noodzakelijk is wel een formele procedure, inclusief een benoeming van een security officer, die bepaalt waar in noodgevallen logon of toegangscodes kunnen worden gehaald. Deze zijn dan uiteraard wel verzegeld, benadrukt Hillege, en het gebruik van de speciale logon wordt in een log weggeschreven die alleen de security officer kan lezen.
Kortom, Hillege raadt af om 'functionele logon users' te gebruiken. Wel is het volgens hem verstandig om met persoonlijke logons te werken en adviseert hij om bovendien met goede authenticatie te werken.
Lees ook