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.
Fijn om te zien dat er mensen zijn die de voordelen zien van beheer ter plaatse. Een goede leidraad voor de beveiliging van database-systemen.
De beveiliging is pas goed als mensen er over klagen. Of eerder zeuren dat ze extra moeite moeten doen.
Maar het aantal keren dat ik DBA rechten kreeg op productie databases durf ik al niet meer te tellen want dat zijn er behoorlijk wat. Een enkele keer kreeg ik een kruisverhoor om de redenen en kreeg toen pas beperkte toegang.
Verhaal is herkenbaar en er is ook niks mis met goede procedures maar het verhaal over ticketsysteem is onzin als je een goed change management proces hebt. Argumentatie van dynamiek heb ik wel wat vragen over als ik ontwikkelingen zoals DevOps in overweging neem, allemaal scripts welke tot doel hebben om menselijke fouten te minimaliseren. Het is naar mijn opinie dan ook nogal tendentieus om te stellen dat eigen DBA geen fouten maakt.
Data Leak Prevention (DLP) lijkt me dan ook wat meer te omvatten dan wat hier beschreven wordt hoewel het een goed begin is om er eens over na te denken en dat vooral te blijven doen.
Local senior DBA, fulltime ? Vervanging bij vakantie/ziekte ? Abstracte Jumphost met tijdwindows, informeren gebruikers over mogelijk nieuwe route. Individuele admin accounts. Auditing. Security officer..
Laten we wel zijn. Wie gaat dat betalen in 2015 ? Begrijpt een CEO/CTO de baten van dit verhaal (de kosten gaat wel lukken 🙂 Is het niet veel eenvoudiger + goedkoper om de zooi uit te besteden. DBA on demand. Kun je die de schuld geven als het mis gaat, ook wat waard 😛
@Felix : is mijn vraag ook.
Werkende in een wat grotere private cloud is mijn ervaring dat de procedure om access te verkrijgen de grote bottleneck wordt in projecten en BAU werk. veelal duurt het langer om een access change af te werken dan de klus waarvoor access wordt aangevraagd. Aangezien access changes simpel zijn, wordt dit vaak bij resources in Azie belegd (want goedkoop) waardoor (mede vanwege het tijdsverschil) zo’n change lang kan duren.
Verder valt het mij op dat in de praktijk zelden de logs worden doorgespit (want saai en tijdrovend).