Nu servervirtualisatie steeds meer wordt gebruik door bijna elke onderneming en er plannen worden gemaakt om applicaties en databases te verplaatsen naar de cloud, is het is tijd om je af te vragen of de it-beveiligingsmethoden wellicht moeten worden vernieuwd of dat we kunnen blijven vertrouwen op de huidige netwerkbeveiligingsoplossingen.
Met de verschuiving in de gegevensverwerking van een platform van dedicated servers in het datacenter – waarbij applicaties op een of meer servers draaien en de ondersteunende databases op afzonderlijke netwerkservers – naar gevirtualiseerde platforms en cloudomgevingen, moeten we ook nadenken over de it security methodologieën. Nieuwe computing modellen vereisen namelijk ook andere beveiligingsaanpak.
Gebleken is dat veelgebruikte netwerkbeveiligingsmodellen vaak achterblijven op de technologische veranderingen die zich voordoen in de systemen en de softwareomgevingen die zij moeten beschermen. Controles van netwerkverkeer op protocolschendingen, schadelijke code, virussen en spam bieden onvoldoende bescherming tegen inbreuken door gebruikers met hoge toegangsrechten en geavanceerde aanvallen door externe hackers. Zeker nu dat meer en meer applicaties en databases worden gebruikt op virtuele machines (en in het geval van cloud computing buiten het bedrijfsnetwerk komen), zijn deze vaak alleen te beveiligen met behulp van oplossingen die beveiligingsrisico’s door middel van host-gebaseerde softwaremodellen verhelpen.
Beveiliging van databases
Als applicaties en de ondersteunende databases worden geïmplementeerd op virtuele servers en in cloudomgevingen, ontstaat een nieuwe complicatie voor de beveiliging van transacties tussen applicaties en de databases. Een van de voordelen van virtualisatie (in een eigen datacenter of in de cloud) is de mogelijkheid om resources te delen. Dit resulteert in omgevingen waar zowel de applicaties als de databases migreren naar dezelfde virtuele machines, die in veel gevallen op dezelfde fysieke servers draaien. De communicatie tussen de applicaties en de databases vindt in dat geval volledig binnen dezelfde fysieke server plaats. In een dergelijk geval is er weinig tot geen netwerkverkeer, waardoor netwerkbeveiligingsoplossingen deze transacties niet kunnen zien en dus ook niet kunnen beveiligen.
De enige oplossing die in alle omgevingen werkt, met inbegrip van virtuele machines en cloudomgevingen, is een op softwaresensors gebaseerde oplossing die alle database activiteiten direct controleert en real-time bescherming biedt voor alle soorten externe, interne en intra-database bedreigingen. Een oplossing die kan worden geïmplementeerd op iedere host waarop een of meerdere databases draaien en die de host machine zo min mogelijk belast. Deze sensoren kunnen vanuit een centrale console worden geïmplementeerd en beheerd, zonder dat de database-activiteiten worden onderbroken. Ze zijn ook in staat om zelfstandig te zorgen voor de beveiliging van de database indien een netwerkverbinding uitvalt. De sensoren identificeren automatisch alle database-exemplaren op de host en kunnen meerdere databases controleren, zelfs van verschillende databasetypen.
Beleidsinstructies kunnen vanuit de centrale console geladen worden in de sensoren. Op basis van deze instructies kan een sensor bepalen of database-activiteiten een gevaar vormen voor de integriteit van de database of in strijd zijn met het geldende bedrijfsbeleid, waarop een waarschuwing wordt afgegeven via de centrale console. De sensoren kunnen ook geconfigureerd worden om op basis van deze instructies bij specifieke overtredingen databasesessies te beëindigen en gebruikers in quarantaine te plaatsen, zonder dat de integriteit van de gegevens in de database in gevaar komt.
Bescherming door functiescheiding
Het plaatsen van databases in een cloudomgeving kan gevaar opleveren voor de integriteit van de informatie die is opgeslagen in de database. Gebruikers met hoge toegangsrechten die zijn verleend door de cloud serviceprovider (zoals databasebeheerders) hebben ook direct toegang tot alle informatie in de database. De op softwaresensors gebaseerde beveiligingsoplossingen kunnen geconfigureerd worden om een functiescheiding toe te passen. Daarbij kunnen gebruikers met hoge toegangsrechten wel het beheer van de databases uitvoeren maar krijgen zij geen inzage in de informatie in die databases. De sensoren zijn ook niet uit te schakelen zonder dat er op een centrale console een waarschuwing wordt gegeven en de acties van de gebruiker worden gelogd. Zo’n centrale console kan eenvoudig geplaatst worden bij de eigenaar, zodat deze altijd de controle kan behouden over de beveiliging van zijn gegevens in de clouddatabases.
Deze op softwaresensors gebaseerde beveiligingstechnologie kan er voor zorgen dat de integriteit van de gegevens in de databases blijft gewaarborgd bij zowel bestaande netwerkomgevingen als op gevirtualiseerde platforms en cloudomgevingen.
Cees,
Er zijn genoeg verschillen tussen eigen virtuele servers en in cloudomgevingen. Ik merk dat je geen onderscheiding maakt tussen deze twee scenario’s. Als ik naar Cloud ga dan verwacht ik dat ik “ontzorg” wordt. Het lijkt me raar om me als cloud-afnemer met dit soort dingen ga bemoeien (als ik eens van provider mag bemoeien)
Verder, beveiliging is een integraal onderwerp van je project. ga je van architectuur veranderen, ga je virtualiseren, ga je van cloud of een ander delivery model gebruik maken dan neem je altijd beveiliging van verschillende componenten en aspecten in je project mee. Sterker nog dat is iets wat in eerdere fase van een project bedacht en besproken dient te worden. Beveiliging doen we niet op 1x plek maar verschillende plekken en lagen binnen de infrastructuur of architectuur. Database is er een van.
Cees,
de sensors die je beschrijft kunnen ook bugs bevatten.
Hoe zit het met de false positives en negatives die dan een verkeerd beeld van de werkelijkheid geven en de klant tot kosten jaagt en onderhoud nodig is ?
En hoe zit het met de beveiliging van de cloudserver als deze sensors in onderhoud zijn?
#justasking
Cees,
Wat grappig, wij hanteren een andere oplossing voor dit probleem door wel te scheiden maar niet op functie door met Stealth communities te maken om zodoende niet alleen de end-to-end communicatie te beschermen maar ook de data-in-rest welke steeds vaker buiten databases opgeslagen wordt.
Wat vragen :
Hoe verhoudt zich het authorisatiemechanisme en logging van deze oplossing zich tot het DB authorisatiemechanisme en de DB audit logging?
Hoe zit het met conflicten daartussen?
Wat is de uiteindelijke meerwaarde van deze oplossing behalve de centrale console?
Tijdens een DB upgrade wordt er veel DML een DDL uitgevoerd die je niet ziet gedurende gewone operaties. Wat doe je dan met zo’n oplossing? Uitzetten dan maar voor de zekerheid?
Shared DB UIDs worden ook vaak misbruikt door hackers (default passwords etc) die ze weer gebruiken voor verdere privilege escalaties. Hoe is de oplossing in staat om onderscheid te maken tussen een hacker en een valide eindgebruiker?
De sensoren zouden elke DB transactie moeten bekijken hetgeen bij een volle produktieload wellicht kan gaan zorgen voor performance problemen.
Is deze oplossing wel getest tegen een behoorlijke DB onder full load?
Als ‘eyeopener’ best wel een zinnig artikel die qua presentatie natuurlijk enkele vragen oproepen. Als je sec je eigen product naar voren schuift dan is de vraag natuurlijk…. moet je niet gewoon naar een reeks van mogelijkheden kijken op dit vlak?
100% eens met de reactie van Reza en NumoQuest!