In nagenoeg elke organisatie bevindt de belangrijkste en meest gestructureerde data zich in enkele kritieke tabellen binnen uw (Oracle) databases. De database wordt daarmee uw Fort Knox, uw laatste verdediging tegen diefstal van uw belangrijkste gegevens.

25 mei 2018 wordt binnen Nederland de Algemene Verordening Gegevensbescherming ingevoerd, het Nederlandse antwoord op de Europese wetgeving ‘GDPR’. Waarschijnlijk bent u reeds bekend met deze wetgeving. Mogelijk bent u binnen uw organisatie zelfs aangewezen als “Functionaris Gegevensbescherming” (FG). Een titel met verantwoordelijkheden. Maar hoe gaat u hiermee om?

Oracle Nederland heeft verschillende Enterprise Edition componenten in gebruik genomen als het gaat om data security, aan deze componenten zijn vaak aanzienlijke kosten verbonden. Wist u echter dat er ook voldoende zaken zijn welke u zelfs in een Standard Edition omgeving al op kunt pakken, in veel gevallen zelfs zonder impact op het applicatiegebruik?

Bij DBA.nl gebruiken wij onze jarenlange ervaring met complexe database omgevingen om u advies en service te kunnen bieden omtrent uw database security. Onderstaande stappen bieden u houvast bij uw database hardening:

1. Bepaal en beperk waar uw “goud” ligt. Uw belangrijkste informatie.

Indien u dit nog niet gedaan heeft, is het zaak om zo snel mogelijk in kaart te brengen op welke locaties uw belangrijkste informatie zich bevindt. Hiertoe is het handig een classificatie in belangrijke informatie op te stellen.

Binnen de AVG zijn richtlijnen opgesteld wat voor ‘persoonlijke gegevens’ dit zijn. De autoriteit persoonsgegevens zegt hierover:

Verder kunnen er andere gegevens zijn, welke niet in de wet geregeld zijn, maar u wel graag beschermd ziet. Denk daarbij aan creditcardgegevens of wachtwoorden van eindgebruikers. Als eerste stap is het zaak om te bepalen waar uw “goud” ligt. Welke databases, applicaties en servers hebben toegang tot dergelijke gevoelige informatie.

In de praktijk weten systeem -en applicatie- beheerders en/of Enterprise architecten vaak goed welke databases deze gevoelige informatie bevatten. Vaak wordt echter de toegang tot back-ups, geautomatiseerde kopieën van back-ups, niet geanonimiseerde test- en ontwikkeldatabases en applicatieservers en hierin vaak vergeten. DBA.nl adviseert dan ook onder andere anonimiseringsscripts toe te passen op OTA databases, in beeld te brengen waar en hoe lang back-ups worden bewaard, en op te helderen in welke tabellen binnen de database de meest gevoelige informatie wordt opgeslagen. Dit laatste is vaak lastig.

2. Maak een gastenlijst voor uw database en update die regelmatig.

Bij instituties zoals Fort Knox wordt een gastenlijst bijgehouden wie er op welk moment binnenkomt en wanneer deze zou kunnen vertrekken. Binnen uw database is het van belang te monitoren welke applicaties en users toegang hebben tot uw omgeving. Ook is het noodzakelijk om gebruikers en applicaties welke niet langer toegang behoeven tot uw database ‘de deur te ontzeggen’. Denk hierbij aan medewerkers die niet langer in dienst zijn, applicaties welke zijn vervangen of geüpdatet en rechtenpakketten voor users of applicaties die niet langer benodigd zijn.

3. Breng in kaart welke deuren open moeten (en sluit de rest).

Wanneer een geoorloofde werknemer, bijvoorbeeld een schoonmaker, binnenloopt in Fort Knox, is dit geen probleem. De schoonmaker heeft immers voldoende security clearances om de gangen van het complex schoon te maken. Wanneer deze schoonmaker echter dagelijks om 08:00 “dienstingang 3” neemt om te beginnen met zijn werkzaamheden, is het natuurlijk onzin om de gehele dag zowel de voordeur en álle dienstingangen in het complex open te houden.

Dit is vaak wel wat er gebeurt binnen databases. De database moet, conform haar functie, bereikbaar zijn voor applicaties vanaf andere servers. Echter, het is niet nodig om elke applicatie of gebruiker toegang te geven tot de volledige database via alle mogelijke ingangen.

In de praktijk zien wij dat het lastig is om bij te houden welke ingangen uw database allemaal heeft en welke er gebruikt worden: Welke beperkingen heeft de listener en door welke gebruikers zijn listener beperkingen aan te passen? Welke koppelingen zijn aanwezig? Welke applicaties kunnen allemaal bij uw databases. Vanaf welke applicatieservers is toegang tot uw databases noodzakelijk? Zijn dataconnecties encrypted?

4. Monitor en bepaal wát er wordt gedaan met monitoring informatie.

Binnen Fort Knox hangen overal camera’s die bijhouden wat er gebeurt binnen het Fort. Indien u het (gratis) component database auditing aan heeft staan in uw database, gebeurd daar hetzelfde.

In de praktijk blijkt echter niet het aanzetten van de monitoring, maar de interpretatie van deze data en het acteren op verdacht gedrag de moeilijkheid: Het is alsof binnen Fort Knox wel camera’s hangen, die aan staan, maar niemand naar de cameraschermen kijkt. Achteraf kan deze monitoring informatie vaak wel bekeken worden, maar er is geen trigger dát dit moet gebeuren. Dit betekent dat monitoring effectief uitstaat en afwijkend gedrag (bijvoorbeeld de schoonmaker die ineens om 11:00 uur binnen komt via een andere dienstingang en een boormachine in plaats van een stofzuiger bij zich heeft) wordt niet gesignaleerd. Dit terwijl juist in een digitale omgeving deze notificaties automatisch opgesteld en gedigitaliseerd kunnen worden.

Een ander uiterste wat vaak gebeurt, is dat er te veel informatie wordt gemonitord. Uw database is immers bedoeld om het veelvuldig raadplegen en schrijven van data te faciliteren. Dit lijkt niet intuïtief. Volledige data geeft immers de illusie van volledige controle. Echter, wanneer het beveiligingssysteem iedere paar uur een melding afgeeft, zullen deze meldingen al snel genegeerd worden. Het risico dat de inbreker in Fort Knox hetzelfde gedrag vertoont als de schoonmaakster is minimaal. Belangrijker nog: Dit kan geen kwaad. Het is vaak praktischer om te focussen op fluctuaties in gedrag. Een goede ondersteuning van database audit bestanden geeft u de mogelijkheid dit zelf zonder moeite aan te passen en u te notificeren bij fluctuaties in databasegedrag.

Hoe kan DBA.nl u hierbij helpen?

De door DBA.nl ontwikkelde security scan biedt u een éénmalig overzicht van user acces, auditing en technische kwetsbaarheden van uw databases. U ontvangt een rapportage omtrent de te nemen stappen en een volledige beoordeling van uw database hardening, inclusief listener.

Ook kunnen wij u ondersteunen in het opzetten van effectieve database auditing jobs en kunnen we voor u zowel de gebruikte, als de openstaande database toegangsmogelijkheden in kaart brengen.

Ten slotte kunnen wij u ondersteunen tijdens de implementatie van Oracle’s geavanceerde options. Zie hiertoe dit artikel.