Questo sito web utilizza cookie tecnici e, previo Suo consenso, cookie di profilazione, nostri e di terze parti. Chiudendo questo banner, scorrendo questa pagina o cliccando qualunque suo elemento acconsente all'uso dei cookie. Leggi la nostra Cookie Policy per esteso.OK

4 scenari aziendali in cui è necessario implementare strumenti per la sicurezza dei database

pittogramma Zerouno

Database

4 scenari aziendali in cui è necessario implementare strumenti per la sicurezza dei database

24 Set 2015

di redazione TechTarget da Digital4

Incrementare la sicurezza dei database significa proteggere il patrimonio informativo aziendale, salvare la qualità dei servizi e la reputazione nei confronti dei propri mercati di riferimento. Esistono alcuni strumenti incredibilmente versatili che, oltre alla sicurezza, garantiscono la compliance e le operation

Incrementare la sicurezza dei database significa proteggere il patrimonio informativo aziendale, salvare la qualità dei servizi e la reputazione nei confronti dei propri mercati di riferimento. Esistono alcuni strumenti incredibilmente versatili che, oltre alla sicurezza, garantiscono la compliance e le operation.

Questi prodotti, forniti da terze parti, offrono un livello di sicurezza superiore, rispetto a quello che propongono i sistemi di gestione dei database relazionali (RDBMS – relational database management system) che hanno a catalogo i vendor.

Questo è particolarmente vero nel caso degli strumenti che effettuano la valutazione della vulnerabilità del database, la crittografia, la conformità e la gestione del database dei dati di test, così come la tokenizzazione e il mascheramento dei dati. 

Strumenti per la protezione dei database, in 4 varianti d’uso

Gli esperti, per aiutare a capire gli orizzonti applicativi, hanno modellizzato alcuni casi di studio che aiutano le organizzazioni nell’identificare dove aggiungere delle componenti a supporto della sicurezza per aumentare i livelli di protezione dei database.

Il presupposto fondamentale dell’investimento è che si deve comprendere bene il valore del database rispetto alla filiera aziendale. I database, infatti, sono un anello indispensabile del processo informatico, in quanto supportano quasi tutte le funzioni e le applicazioni di business all’interno delle imprese. In pratica, in un’impresa i database sono ovunque. Questo è il motivo per cui questo insieme eterogeneo di sistemi ha bisogno di un corrispondente livello di sicurezza.

Caso di utilizzo # 1: la compliance

Parlando di investimenti, la conformità è di gran lunga il più grande driver del potenziamento della sicurezza, anche perché la maggior parte delle imprese implementa tool solo per i database che richiedono regolari controlli. Le normative tendono a funzionare meno in due ambiti differenti: l’antifrode, capitanata dalla Sarbanes-Oxley, e la PCIDSS (Payment Card Industry Data Security Standard) necessaria alla privacy dei clienti e guidata dal Gramm-Leach-Bliley Act così come da altri regolamenti statali per la protezione della privacy. La sicurezza dei database è anche vincolata alla riduzione dei costi. Spesso, per proteggere un database o i dati che il database gestisce è più facile e meno costoso intervenire su tutte le applicazioni e le reti collegate a questi database. Tra gli strumenti di sicurezza dei database utilizzati per eseguire questo tipo di servizio, gli esperti citano:

– Lo scanner di valutazione, che ispeziona periodicamente i database per conoscere le istanze di sicurezza e le politiche interne legate alla compliance. Alcune normative richiedono una valutazione periodica del database per questioni di sicurezza, per policy legate a determinate configurazioni o entrambi i casi.

– Il monitoraggio dei permessi, che accerta se la separazione dei compiti è a posto ed effettua una verifica rispetto alla sottoscrizione dei diritti, così come è stato definito dalle diverse normative. Mentre tutti gli strumenti di monitoraggio dei permessi verificano le piattaforme di database, tenendo conto che le performance sono diverse a seconda del tool prescelto, senza questo strumenti specifici è possibile solo eseguire un controllo attraverso le credenziali degli utenti e una valutazione dei diritti degli utenti. Esistono oggi diverse specifiche atte a garantire che gli user non possano operare al di fuori del campo a loro assegnato, o che aiutino i responsabili a intercettare gli utenti a cui sono stati assegnati più ruoli, generando il rischio di un conflitto di interessi. Si tratta di casi che possono essere valutati manualmente, ma certamente automatizzando i processi si raggiunge un livello di efficienza superiore.

– Il monitoraggio delle attività del database (DAM – Database Activity Monitoring) aiuta a tenere sotto controllo i privilegi ed è la motivazione principale per cui sono utilizzati questo tipo di tool in un progetto di compliance. La soluzione offre dei report su cui sono riportate informazioni di accesso/disconnessione e sono tracciate tutte le attività di sistema e di allarme quando gli amministratori e gli utenti privilegiati visualizzano informazioni sensibili. Il DAM è dunque molto utile nel caso si debbano stilare rapporti di conformità completi, che includano più database e applicazioni. Le piattaforme SIEM (Security Information and event management) non solo non collezionano gli eventi necessari ma gli strumenti di database incorporati non forniscono una raccolta dei dati coerente tra più database e non potenziano le policy. I report sui livelli delle policy dimostrano solo che sono in atto dei controlli, mentre è un altro genere di reportistica a tenere traccia della convalida dei controlli. La maggior parte degli strumenti di protezione del database includono questi rapporti relativamente a una serie di normative importanti, con modelli configurati a misura di azienda.

– Tokenizzazione e mascheramento sono utilizzati per rimuovere i dati sensibili e quindi escludere il database dal campo di applicazione della compliance. Se i dati sensibili viene sostituiti con dati non sensibili, infatti, i requisiti di conformità vengono rimossi.

Caso di utilizzo # 2: Sicurezza delle applicazioni Web

Un SQL Injection è un attacco contro un database. La minaccia, che arriva attraverso un’applicazione, è uno dei tre vettori di attacco più comuni dell’ultimo decennio. Quasi tutte le applicazioni Web sono supportate da un database ma, mentre l’applicazione ha un front end pubblico, i database fanno parte delle retrovie informatiche e, proprio per questo motivo, gli sviluppatori li lasciano senza una protezione adeguata. I Web Application Firewalls possono bloccare alcune infezioni SQL, ma il loro limite è che non sono in grado di capire il database che stanno proteggendo, e quindi sono soggetti a falsi positivi e negativi.

A questo proposito meglio optare per i prodotti DAM e i firewall per i database, che risolvono tutti questi problemi senza richiedere onerose attività di riscrittura dei codici applicativi per rimuovere le vulnerabilità generate dalle infezioni SQL e dallo scripting. Intervenire sulle applicazioni aziendali per risolvere i problemi di sicurezza spesso può arrivare a costare molto più di quanto non sia costato lo sviluppo inziale. Inoltre le correzioni richiedono anni di lavoro considerato il livello di preparazione dei team su questo genere di argomenti. Questo è il motivo per cui le imprese si rivolgono a degli add on dedicati a contrastare questi attacchi.

Per esempio, interrogare le white list aiuta gli amministratori a capire quali sono le nuove query o i nuovi modelli do sviluppo, oppure a imparare in che modo l’applicazione deve effettuare un invio automatico e bloccare tutto il resto. Alcuni strumenti presenti sul mercato comunicano anche le violazioni a un WAF, sia come semplice segnalazione che attraverso un’azione che termina le sessioni sospette, arrivando persino a bloccare l’indirizzo IP incriminato.

Caso di utilizzo # 3: Change management e monitoraggio interno

I database più critici cadono a causa di una cattiva gestione delle patch e delle modifiche che subentrano durante i cicli di aggiornamento conseguenti ad un attacco. A differenza delle variazioni al codice dell’applicazione, gli amministratori normalmente optano per un intervento diretto sul database in produzione, manipolando direttamente i dati, il che può facilmente causare delle interruzioni nel servizio. Aggiungere un sistema automatico per la gestione delle modifiche (ad esempio, sistemi di trouble-ticket) supportate da uno strumento di DAM riduce la probabilità di interventi sbagliati, offrendo un grado di responsabilità più alto, anche nel caso vengano utilizzate delle credenziali condivise.

I tool di assessment per la scansione dei database consentono ai team addetti alla sicurezza e alla compliance di validare la qualità del lavoro fatto dai responsabili dei database. Il DAM è utilizzato per convalidare in automatico che le azioni di amministratore corrispondono ad un protocollo di intervento specifico, attraverso un monitoraggio che mostra il registro completo di tutti i comandi SQL, e spesso anche i valori di ritorno.

Il DAM è usato anche per la raccolta e l’analisi degli eventi, per i report di conformità e per i sistemi SIEM: in questo modo i gruppi di audit hanno tutti i dati relativi agli eventi di cui hanno bisogno. Per questo sempre più aziende stanno utilizzando soluzioni DAM e di mascheramento dinamico per proteggere questi sistemi da query maligni, così le politiche di sicurezza possono essere attuate senza modificare l’applicazione o interrompere l’operatività del database. Per le imprese che devono tutelarsi maggiormente dal furto di informazioni privilegiate e dai rischi di frode, questa forma di convalida successiva offre una vista completa rispetto alla manutenzione del database e alle attività di patch management.

Caso di utilizzo # 4: Sicurezza dei database legacy

Siamo onesti: in ogni azienda ci sono un sacco di database che sono stati progettati e distribuiti molto prima che qualcuno si fosse messo a preoccuparsi della protezione delle informazioni o dei software di sicurezza del database. Questi database sono stati progettati con livelli di vulnerabilità molto alti, dalla memorizzazione di procedure esterne all’utilizzo di numeri di previdenza sociale utilizzate come chiavi di accesso del database primario. Questi sistemi sopravvivono perché supportano i processi di business critici, ma il vero problema è che non sono sicure.

Oggi non è facile per un’organizzazione riuscire a trovare qualcuno che sappia ancora come funziona un sistema legacy con competenze sufficienti a riuscire ad ammodernare le applicazioni legacy, e quindi a ottenere il budget per fare il lavoro. Il problema, infatti, è che l’hardware e il software sono così vecchi che cadono non appena si prova a toccare il sistema. In sintesi, gli strumenti di sicurezza del database per i sistemi legacy diventano particolarmente utili, soprattutto considerando le difficoltà di proteggere un database su un vecchio server, in quanto il rischio è che le modifiche necessarie imporrebbero al database di smettere di lavorare. E, come si sa, la business continuity deve rimanere un must.

Chi trae vantaggio dal software di sicurezza del database?

Sulla protezione dei data center le aziende sono molto attente, ma la maggior parte delle imprese è ancora ben lontana dal chiedersi se ci sia bisogno o meno di proteggere i database relazionali. Eppure c’è ormai una lunga lista di violazioni dei dati e dei requisiti di conformità che risponde alla domanda. Le organizzazioni, nel frattempo, hanno anche trovato i loro prodotti di sicurezza di rete e degli endpoint che però non arrivano a coprire i database. Molte organizzazioni hanno scoperto a loro discapito che l’offerta di alcuni vendor di RDBMS che promettevano la sicurezza dei database corrispondeva a policy al di sotto degli standard e a una raccolta degli eventi a macchia di leopardo. In sostanza, i prodotti generici non riescono a distinguere tra quello che è un utilizzo normale e quello che è un uso maligno. Non riescono a valutare i livelli di configurazione e di patch management adeguati, perché non hanno le necessarie capacità di analisi. Ad aggravare il problema è che i soggetti che hanno bisogno di questi dati (ad esempio, la sicurezza e le squadre addette all’audit interno) non hanno la sufficiente esperienza tecnica per raccoglierli. IT e amministratori di database sono riluttanti nel modificare le applicazioni o i database per paura di destabilizzare i sistemi. Anche in questo caso, gli strumenti di sicurezza del database forniscono un beneficio reale, consentendo agli utenti di garantire la sicurezza e il monitoraggio di cui hanno bisogno, senza modificare il database effettivo o impattare negativamente sulle prestazioni del database.

La vera sfida, dunque, è la selezione del software di sicurezza del database più adatto ad affrontare le sfide che ogni organizzazione deve affrontare.

 

 

redazione TechTarget da Digital4

Articolo 1 di 5