Sicurezza del database in Oracle

Non c'è nessun segreto che le informazioni facciano girare il mondo attualmente. Se un'impresa si prende cura della sua proprietà intellettuale e ogni dipendente può facilmente ottenere le informazioni necessarie, l'impresa può sperare in una crescita. Se c'è caos nei dati, l'impresa fallirà nonostante lo spirito di squadra.

In questo articolo, esploreremo le basi della sicurezza del database e gli esempi di protezione delle informazioni in Oracle. In realtà, le basi teoriche per la protezione delle informazioni nel database, che considereremo in questo articolo, saranno utili anche alle persone che lavorano con altri database.

Autorizzazioni di accesso

Nella maggior parte delle aziende per cui ho lavorato, tutti gli amministratori e gli sviluppatori avevano pieno accesso ai database, così come un dipendente del dipartimento IT era un dio e poteva fare tutto ciò che volevano. Perché succede? Ci sono due ragioni per questo:

Mentre lavorano in un reparto, i dipendenti possono incontrarsi per 8 ore al giorno e diventare amici. Come non possono concedere l'accesso? L'amicizia è una cosa, ma gli affari sono affari.
La concessione di alcuni diritti di accesso o la modifica di alcune configurazioni potrebbe richiedere alcuni privilegi. A volte, gli amministratori pensano che i programmatori configurino meglio le impostazioni. Pertanto, forniscono ai programmatori diritti di accesso non necessari. Invece, i programmatori non devono essere coinvolti nell'amministrazione e non devono avere alcun diritto per questo.

Nella mia esperienza, il secondo problema è molto comune, quindi lo analizzeremo in dettaglio.

Quando sviluppano programmi per database, i programmatori conoscono una password di superutente o semplicemente dispongono dei diritti di amministratore del database. Questo è inutile e assolutamente insicuro. Solo l'amministratore del database deve disporre dei diritti completi. Anche il capo dipartimento, il direttore e i migliori amici possono avere meno privilegi.

Ad esempio, quando si sviluppano programmi, è sufficiente disporre dei diritti di proprietario dello schema nel database Oracle che memorizza le tabelle di lavoro. Questi diritti sono sufficienti per creare nuove tabelle, pacchetti, indici e altri oggetti, nonché per concedere diritti di accesso agli oggetti dello schema ad altri utenti. Non hai bisogno dei diritti di sistema per il lavoro a tempo pieno.

Se non c'è un amministratore del database a tempo pieno, è molto brutto. È meglio quando c'è qualcuno responsabile delle prestazioni, dell'ottimizzazione e della sicurezza del database. Almeno, devi nominare un programmatore che sarà responsabile di questo e avrà diritti esclusivi.

Secondo le statistiche, i dipendenti dell'azienda causano più spesso la perdita di dati. Tuttavia, nonostante ciò, la maggior parte delle aziende continua a ignorare questo thread e diversi database archiviati su dischi ad accesso gratuito vengono venduti anche in metropolitana.

Utenti e ruoli

Esistono due tipi di oggetti per concedere diritti di accesso nei database:utenti e ruoli. I ruoli sono alcuni gruppi che combinano utenti che devono avere diritti simili. Ad esempio, tutti i contabili possono richiedere l'accesso ai documenti finanziari. Per impedirti di concedere diritti a ciascun contabile, possiamo combinarli in un ruolo con l'accesso necessario.

Come puoi vedere, il principio dei ruoli è simile ai gruppi nel sistema operativo Windows. Tuttavia, ha alcune differenze. Non senza motivo, tutti e tre i tipi di oggetti come utenti, gruppi e ruoli possono essere implementati nel database. Tuttavia, nella maggior parte dei database vengono implementati solo utenti e ruoli. È necessario gestire e monitorare tutti questi oggetti in modo che ogni utente che ottiene i diritti concessi dai ruoli possa avere accesso ai dati effettivamente necessari per risolvere i compiti. È necessario utilizzare i diritti di accesso come regole per un firewall. Utilizzando questi diritti, puoi risolvere lo stesso problema:consentire a un utente di eseguire solo determinate attività e prevenire possibili perdite o danneggiamenti.

Con l'aiuto dei ruoli, è abbastanza conveniente controllare l'accesso, fornire autorizzazioni o bloccare l'intero gruppo di utenti. Un ruolo può essere incluso nell'altro, ereditandone così i diritti di accesso. Pertanto, possiamo creare una struttura gerarchica dei diritti.

Tutti i dipendenti con diritti di accesso a un database aziendale possono essere inseriti in un unico ruolo con i diritti minimi. Ora, se hai bisogno di privilegi aggiuntivi, per accedere a tabelle particolari, dovrai aggiungere un utente ad altri ruoli (se un gruppo richiede lo stesso accesso) o fornire un account particolare con i diritti.

Nel programma, per controllare l'accesso alle tabelle, è possibile verificare la presenza di errori nel risultato dopo ogni tentativo di apertura del dataset. Se si verifica un errore di accesso, l'accesso alla tabella specificata viene bloccato per un utente. Pertanto, non è necessario implementare i diritti di accesso all'applicazione client. Tuttavia, se vuoi implementarlo, non ci sarà alcun danno. Almeno, non vedo nulla di critico in questo; sembra avere l'effetto opposto.

Controllo di sicurezza

Se ogni utente lavora con il proprio account nel database, puoi chiamare la variabile utente per determinare l'utente corrente, ad esempio:

SELECT user from dual

Questa query restituirà un nome utente, sotto il quale viene aperta la connessione al server. Se più persone possono accedere utilizzando un nome, questa query restituirà lo stesso nome per entrambi e sarebbe inutile per l'audit. Soprattutto se il controllo del blocco si verifica a livello di server.

Se più utenti possono accedere utilizzando lo stesso nome utente, è complicato, ma comunque possibile, identificare chi ha effettuato l'accesso all'account. La seguente query consente di ottenere informazioni dettagliate sulla sessione:

select s.user#, s.username, s.osuser, s.terminal, s.program
from sys.v_$session s
WHERE username=user

Come puoi vedere, la query ha restituito il nome utente, connesso al database, un nome nel sistema operativo, un nome utente del terminale e un programma.

Qui puoi accedere alla vista della sessione v_$ dallo schema del sistema sys. Questa visualizzazione restituisce alcune informazioni sulle connessioni al server. Nella clausola WHERE, limitiamo l'output solo all'utente corrente. Di conseguenza, la query restituisce l'ID utente, il nome, il nome nel sistema operativo, il terminale e il programma da cui è stata stabilita la connessione.

Quando conosci un nome utente e un nome di terminale, puoi sicuramente identificare un utente. Per sapere a quali ruoli è stato aggiunto l'utente corrente, puoi eseguire la seguente query:

SELECT GRANTED_ROLE 
FROM dba_role_privs 
WHERE grantee=user

Sicurezza dell'account

Non diremo che non dovrebbero esserci password predefinite. Alcuni database, ad esempio MySQL, sbagliano quando creano una password di sistema semplice e nota dopo l'installazione. Inoltre, non diremo che la password dovrebbe essere complicata. Questa regola si applica a tutte le aree IT e dovrebbe essere nota anche a un utente inesperto. Parleremo di problemi con il database.

Nella mia esperienza, durante lo sviluppo di programmi aziendali, gli sviluppatori utilizzano lo stesso account per accedere a un database. I parametri di questo conto sono registrati direttamente nel programma, mentre l'accesso a particolari moduli, tra cui contabilità, magazzino, reparto personale, ecc. è implementato in maniera programmatica. Da un lato, questo metodo è conveniente, perché il programma può connettersi al database con diritti di amministratore e non dovrà occuparsi dei ruoli e dei diritti di accesso alle tabelle. D'altra parte, questo metodo è tutt'altro che sicuro. Il livello degli utenti sta crescendo e gli amici dei dipendenti della tua azienda possono essere formati nel campo della sicurezza e dell'hacking. Dopo aver conosciuto il nome e la password, con cui il programma si connette al database, un utente ordinario può ottenere più opportunità di quelle che volevi.

Il linguaggio SQL non è un linguaggio segreto e complicato. Esistono molti programmi che consentono di visualizzare facilmente qualsiasi dato nel database. Con il nome utente e la password, chiunque può rubare tutti i tuoi dati. Pertanto, sarà venduto in qualsiasi bancarella che vende dischi.

Un nome utente e una password non devono mai essere memorizzati nel programma. Anche l'accesso al programma deve essere limitato e impossibile per i terzi. È abbastanza logico combinare entrambi gli accessi in uno. È necessario creare un account separato sul server del database con i diritti minimi necessari per ciascun utente dell'organizzazione. Questi nomi e password devono essere utilizzati quando si accede al programma. Puoi utilizzare una logica comune e molto efficace:se puoi accedere al database con i dati inseriti, l'accesso è consentito; in caso contrario, è necessario interrompere il programma. Questo processo è semplice ed efficace perché abbiamo utilizzato l'autorizzazione del database.

Per verificare che gli utenti non lavorino contemporaneamente da due computer diversi con lo stesso nome, puoi eseguire la seguente query:

select s.username, s.terminal, count(*)
from sys.v_$session s
WHERE username=user
HAVING count(*)>1
GROUP BY s.username, s.terminal

Infatti, non deve restituire alcun record.

Viste

Le viste sono un modo molto conveniente per staccare dalla struttura dei dati e creare allo stesso tempo un ulteriore livello di protezione. È vero che le visualizzazioni hanno un impatto negativo sulla produttività, tuttavia hanno un impatto positivo sulla sicurezza. Possiamo concedere i propri diritti di accesso, mentre le tabelle da cui vengono recuperati i dati possono rimanere inaccessibili a questo account.

Quando è meglio usare le visualizzazioni? Innanzitutto, definiamo quali sono i loro svantaggi. Una vista è un'istruzione SELECT per recuperare i dati. Può accedere sia a uno che a più tavoli. Se selezioni semplicemente i dati dalla vista, non ci sarà alcuna perdita di prestazioni. Tuttavia, possiamo utilizzare le visualizzazioni in altre query per selezionare i dati e fare riferimento ad essi come alle tabelle. Ad esempio:

SELECT list of fields
FROM view, table_1, table_2
WHERE some parameters

In questo caso, la query recupera i dati dalla vista e da due tabelle. Inoltre, possiamo visualizzare una relazione tra tutti gli oggetti ed è possibile impostare una condizione aggiuntiva.

Ora, diamo un'occhiata alla query come la vede l'ottimizzatore di database:

SELECT list of fields
FROM (SELECT ...), table1, table2
WHERE some parameters

In questo caso, ho sostituito la vista con un'istruzione SELECT astratta tra parentesi in cui è composta la vista. Si scopre che il server vede una query con una sottoquery. Se la sottoquery restituisce dati dinamici, anziché un valore statico, questa selezione dei dati funzionerà più lentamente rispetto a quando scrivessimo la stessa query senza la sottoquery.

Sicurezza dei dati

Non dovresti mai concedere un accesso completo agli oggetti senza una necessità speciale. Inizio sempre a fornire i diritti solo per consentire la selezione dei dati con l'istruzione SELECT. Se l'utente ha davvero bisogno di inserire nuovi record e non può eseguire le attività a lui assegnate, in questo caso, aggiungi l'autorizzazione sull'istruzione INSERT della tabella specificata.

Le operazioni più pericolose per i dati sono la modifica e la cancellazione, rispettivamente UPDATE e DELETE. È necessario concedere questi diritti con attenzione. Assicurati che i dati possano essere modificati o cancellati. Solo in questo caso, selezionare i diritti appropriati. Alcune tabelle sono estese solo per natura.

È necessario essere sicuri che i dati saranno interessati frequentemente. Ad esempio, la tabella dei dipendenti può essere estesa e modificata, ma un singolo record non deve mai essere cancellato. La rimozione può influenzare lo sfondo del lavoro, dei rapporti e dell'integrità dei dati dei dipendenti. Il caso in cui un responsabile delle risorse umane aggiunge accidentalmente un record aggiuntivo e desidera eliminarlo è ancora possibile. Tuttavia, questi casi sono rari e l'errore può essere corretto dall'amministratore del database. Capiamo che nessuno vuole lavorare troppo ed è più facile concedere un'autorizzazione, tuttavia, la sicurezza è più preziosa.

La concessione dei diritti viene eseguita utilizzando l'operatore GRANT. In generale, si presenta così:

CONCEDERE cosa concedere diritti su oggetti ON A utenti o ruoli

Ad esempio, la query seguente concede a Utente1 il diritto di inserire e visualizzare la tabella TestTable:

GRANT Select, Insert ON TestTable TO User1

Chiavi estere

Molti utenti hanno paura delle chiavi esterne perché di solito non consentono l'eliminazione dei dati quando è presente un join esterno. Il problema può essere facilmente risolto se viene stabilita un'eliminazione a cascata. Tuttavia, alla maggior parte degli specialisti non piace questa possibilità. Un'azione ridicola può corrompere dati molto importanti senza alcuna richiesta di conferma. I dati collegati devono essere cancellati in modo esplicito e solo se l'utente ha consapevolmente confermato che i dati possono essere cancellati.

Non aver paura delle chiavi esterne. Ci forniscono un modo conveniente per controllare l'integrità dei dati dal server del database, quindi questa è una sicurezza che non guasta mai. Il fatto che potrebbero esserci problemi con l'eliminazione è solo un vantaggio. È meglio non cancellare i dati piuttosto che perderli per sempre. La chiave esterna insieme all'indice non riduce le prestazioni. Questo è solo un piccolo controllo quando si eliminano i dati o si modifica il campo chiave a cui sono collegati i dati in tabelle diverse.

Backup

Il backup è anche uno dei fattori di sicurezza che ignoriamo prima della prima perdita di dati. Tuttavia, personalmente, l'avrei incluso tra quelli principali. La perdita di dati può essere causata non solo da hacker e utenti inadeguati, ma anche da malfunzionamenti delle apparecchiature. I guasti alle apparecchiature possono portare alla perdita del database, il cui ripristino può richiedere ore o addirittura giorni.

È necessario sviluppare in anticipo la politica di backup più efficace. Cosa si intende con ciò? I tempi di fermo causati dalla perdita di dati e fino al momento del ripristino della capacità di lavoro dovrebbero essere minimi. Anche la perdita di dati dovrebbe essere minima e il backup non dovrebbe influire sul lavoro dell'utente. Se ci sono soldi e opportunità, è meglio usare sistemi come RAID, cluster o persino la replica dei dati.

Il backup e il ripristino sono un argomento separato e interessante. Non potremmo toccarlo qui, ma non lo considereremo in dettaglio.

Riepilogo

Abbiamo considerato le basi della sicurezza, in particolare per Oracle. Non dimenticare che la protezione fornita dal database è di un solo livello, mentre la protezione deve essere multilivello. Per dormire un po' con la mente lucida, è necessario implementare tutte le funzionalità di sicurezza sulla rete, sui server e su tutti i computer, inclusi antivirus, antispyware, VPN, IDS, ecc. Più livelli di protezione ci sono, più sarà difficile superarli.

Ci dovrebbe essere una chiara politica di sicurezza e controllo. Se un dipendente lascia, il suo account viene eliminato. Se sono presenti utenti che lavorano con la stessa password o utilizzano una password di gruppo per eseguire attività, tutte queste password devono essere modificate. Ad esempio, se un amministratore esce e tutti gli amministratori utilizzano lo stesso account, è necessario modificare la password.

La sicurezza è necessaria. Devi proteggerti non solo dagli hacker ma anche dagli utenti "novizi", che possono corrompere i dati con la loro inesperienza. Una buona politica di sicurezza aiuta a prevenire tali casi e questa possibilità non può essere esclusa. È meglio fornire in anticipo la possibilità di proteggere i dati dall'inesperienza piuttosto che perdere molto tempo per ripristinare i dati e ottenere inutili tempi di inattività.