SICUREZZA DEI SISTEMI INFORMATICI 1

Docente: Giuseppe Scollo

Universit di Catania, sede di Comiso (RG)
Facolt di Scienze Matematiche, Fisiche e Naturali
Corso di Studi in Informatica Applicata, AA 2007-08

Presentazione del Progetto:

SICUREZZA IN ORACLE

Dario Intelisano
Matricola: A40/000104

INDICE
INTRODUZIONE
1. ORACLE
1.1

Caratteristiche di Oracle

1.2

Livelli di Protezione

2. MECCANISMI DI AUTENTICAZIONE
2.1

Secure Socket Layer (SSL)

2.2

Kerberos

2.3

Smart Card

2.4

Biometric

2.5

Password

3. AUTORIZZAZIONE
4. AUDITING
4.1

Auditing

4.2

Perch lAuditing?

4.3

Risultato

5. BACKUP
5.1

Frequenza di Backup

5.2

Archivelog

5.3

Forme di backup

5.3.1 Export e Import

5.3.2 Backup a freddo
5.3.3 Backup a caldo
6. ROW LEVEL SECURITY
6.1

Cosa significa

7. SECURITY CHECK-LIST
7.1

Bloccare gli utenti di default

7.2

Cambiare le password degli utenti di default

7.3

Controllo delle password

7.4

Proteggere il data dictionary

7.5

Privilegi e ruoli

7.6

Restringere laccesso alla rete

7.7

Auditing

7.8

Backup

7.9

Applicare patch di sicurezza

8. CONCLUSIONE
9. BIBLIOGRAFIA

INTRODUZIONE
I dati e le informazioni sono indubbiamente il bene pi prezioso per ciascuna azienda
pertanto la loro salvaguardia di vitale importanza. La maggior parte dei sistemi
informativi odierni utilizza una base dati o database1 per la registrazione ed
elaborazione di queste informazioni. I moderni database costituiscono pertanto
lelemento portante di ogni sistema di business ed altre attivit di natura differente.
Molti dei dati in essi conservati sono di natura confidenziale (numeri di carte di
credito, dati finanziari, ecc ) e/o critici per il corretto funzionamento dellazienda
stessa. Per questi motivi necessario provvedere ad analizzare potenziali rischi e
predisporre opportune misure di sicurezza.
Lobiettivo principale di questo progetto quello di porre laccento sulle possibili
vulnerabilit del database Oracle e le misure di sicurezza adottate per evitare che
un malintenzionato prenda il pieno controllo del sistema. Ho scelto Oracle come caso
studio in quanto a livello aziendale appare essere una delle base dati maggiormente
utilizzata. Possiamo associare alla parola sicurezza il significato di tutte quelle
procedure sia tecniche sia personali che dovrebbero permettere di assicurare che
persone non autorizzate non accedano ad informazioni private e che persone
autorizzate non mettano a repentaglio il sistema e i dati. Naturalmente opportuno
ricordarsi che la creazione di un ambiente sicuro non si esprime in qualcosa di
statico, ma unoperazione continua nel tempo spesso in funzione di nuove tecnologie
disponibili.

1 ORACLE
1.1 Caratteristiche di Oracle
Oracle uno tra i pi famosi database management system (DBMS), cio sistema di
gestione di basi di dati. Esso fa parte dei cosiddetti RDBMS (Relational DataBase
Management System) ovvero di sistemi di database basati sul Modello relazionale che
si affermato come lo standard dei database dell'ultimo decennio. Una base di dati
Oracle comprende istanze e dati memorizzati. Un'istanza costituita da un set di
3

processi di sistema e strutture di memoria che interagiscono con i dati memorizzati.

Tra questi processi i seguenti sono necessari per il funzionamento dell'istanza:

PMON (monitor dei processi)

SMON (monitor di sistema)

DBWR (scrive nei datafile)

LGWR (scrive nei logfile)

CKPT (scrive i checkpoint controllandone la consistenza)

ARCH (archiviatore dei log delle transazioni per il DB)

Un compito importante svolto dal System Global Area (SGA), una regione di
memoria condivisa che contiene dati ed informazioni per il controllo di una istanza
Oracle. L'SGA si occupa della cache, i dati bufferizzati, i comandi SQL e informazioni
sull'utente.
Gli elementi fondamentali sono:

control

files:

qui

sono

memorizzate

informazioni

essenziali

al

corretto

funzionamento del database. Tra queste il DBID identificativo dell'istanza, il

valore di CKPT per la sincronizzazione dei datafile e dati relativi ad alcune viste
V$ da interrogare quando il DB stesso non in stato di Open. necessario
averne almeno uno associato all'istanza; per maggior sicurezza possono esserne
creati pi di uno, il database stesso si occuper della loro sincronizzazione, in
modo da poter avviare il DB anche in stato di mount ed avviare un recovery.

l'archivio delle transazioni (online redologs): i redologs sono necessari per il

funzionamento del Db stesso e sono composti da coppie di 2, come a dire che il
minimo indispensabile 2.

Oracle memorizza i dati sia logicamente, sotto forma di tablespace, sia fisicamente,
sotto forma di file (datafile). Un tablespace, formato da uno o pi datafile, contiene
vari tipi di segment; ogni segment a sua volta si suddivide in uno o pi extent. Ogni
extent comprende gruppi contigui di blocchi di dati (data block), quest'ultimi sono la
pi piccola informazione memorizzabile da Oracle.
4

Oracle tiene traccia dei dati memorizzati tramite l'aiuto di informazioni presenti
nelle tabelle di sistema. Esse contengono il dizionario dei dati e se presenti indici e
cluster. Un dizionario dei dati consiste di una collezione di tabelle che contengono
informazioni riguardo tutti gli oggetti utente del database.

1.3 Livelli di protezione

La

sicurezza

dei

database

assume

almeno

questi

tre

livelli

di

protezione:

autenticazione, autorizzazione, auditing

Autenticazione: quel processo che identifica correttamente gli utenti e gli

permette di accedere al sistema. Normalmente un normale processo di
identificazione potrebbe consistere nella verifica di un nome utente e
lautenticazione

nella

verifica

della

validit

della

password

associata.

Lautenticazione un elemento necessario per valutare in quale circostanza

qualcuno fa qualcosa. Esistono comunque altri sistemi di autenticazione quali
smart-card, certificati X.5093 o elementi biometrici (impronta digitale).

Autorizzazione: una volta riconosciuto dal sistema, lutente ha accesso ai propri

privilegi ed autorizzazioni. Vengono decise pertanto quali siano le risorse a cui
lutente pu aver accesso e quali siano le modalit operative.

Auditing: questa fase finalizzata, mediante alcune funzionalit idonee, ad

identificare e riconoscere potenziali abusi oltre ad assicurare lintegrit delle
informazioni. Lauditing pu essere un ottimo strumento per il controllo del
database ma non dovrebbe limitarsi a rilevare le sole informazioni sullaccesso ai
dati degli utenti ma dovrebbe anche tracciare la modalit daccesso per
valutare le possibili intrusioni dellutente. Le funzionalit di auditing hanno un
impatto negativo sulle performance dellintero sistema nonostante ci`o
opportuno e consigliabile ricorrere alle stesse cercando un giusto compromesso
tra le prestazioni e le quantit di dati raccolti mediante il monitoraggio.

2. AUTENTICAZIONE
Lautenticazione degli utenti di fondamentale importanza per la sicurezza del
database, soprattutto in un ambiente distribuito. indispensabile identificare gli
utenti prima di poter determinare i privilegi e i diritti di accesso. Il pi comune
metodo di autenticazione la password (discusso in maggiore dettaglio nel paragrafo
successivo) ma non il solo. Oracle Advanced Security una Suite Oracle che fornisce
il software per la crittografia, lautenticazione e i protocolli di sicurezza e fornisce
anche diversi sistemi di autenticazione (di terze parti) e luso di SSL e certificati
digitali.
Oracle Advanced Security offre i seguenti metodi:

2.1 Secure Socket Layer (SSL)

Questi protocolli utilizzano la crittografia per fornire sicurezza nelle comunicazioni su
Internet e consentono alle applicazioni client/server di comunicare in modo tale da
prevenire il tampering' (manomissione) dei dati, la falsificazione e l'intercettazione.
Scopo primario di SSL fornire sistemi di crittografia per comunicazioni affidabili e
riservate sulla rete sfruttabili in applicazioni quali, ad esempio, posta elettronica e

sistemi di autenticazione. Il protocollo SSL provvede alla sicurezza del collegamento

garantendo:
Autenticazione: l'identit nelle connessioni pu essere autenticata usando la
crittografia asimmetrica, ovvero a chiave pubblica (RSA, DSS, EL-Gamal). Cos
ogni client comunica in sicurezza con il corretto server, prevenendo ogni
interposizione. prevista la certificazione del server e, opzionalmente, quella del
client.
Confidenzialit nella trasmissione dei dati: la crittografia usata dopo un
handshake (accordo) iniziale per definire una chiave segreta di sessione. In
seguito, per crittografare i dati usata la crittografia simmetrica (AES, 3DES,
RC4, ecc.).
Affidabilit: il livello di trasporto include un controllo dell'integrit del
messaggio basato su un apposito MAC (Message Authentication Code) che
utilizza funzioni hash sicure (MD5, SHA, RIPEMP-160, ecc). In tal modo si
verifica che i dati spediti tra client e server non siano stati alterati durante la
trasmissione.

2.2. Kerberos
Il sistema Kerberos (Miller, Neuman, Schiller & Saltzer, 1987) trae origine dal
protocollo di (Needham & Schroeder, 1978), di key transport autenticazione di
utenti a servizi in un sistema distribuito, fornita da un server centrale di
autenticazione (KAS) che agisce da centro di distribuzione di chiavi di sessione (KDC)
il KAS condivide con ciascun utente A o servizio B un chiave segreta di lungo
termine, risp. Kas, Kbs, ha un database che associa le identit di utenti e servizi a tali
chiavi, e genera una chiave di sessione Kab di durata limitata L per ciascuna sessione
di A con B, alla quale associa un ticket tB = eKbs (Kab,A,L)

lo schema del protocollo il seguente, dove na un nonce generato da A e Ta un

timestamp riferito al clock di A:
A S:

A, B, na

S A:

eKas (Kab,na,L,B), tB

A B:

tB, eKab (A,Ta)

B A:

eKab (Ta)

2.3. Smart Cards

La smart card un dispositivo hardware delle dimensioni di una carta di credito che
possiede potenzialit di elaborazione e memorizzazione dati ad alta sicurezza. Pi in
generale, il termine smart card sottintende un insieme di tecnologie, comprendenti
circuiti integrati, microprocessori, memorie RAM, ROM, EEPROM, antenne, ecc.,
8

integrate nello stesso circuito elettrico per formare un microchip che il "cuore" della
smart card
La smart card costituita da un supporto di plastica nel quale incastonato un
microchip connesso ad un'interfaccia di collegamento che pu essere una contattiera
o un'antenna. Il microchip fornisce funzionalit di calcolo e memorizzazione dati; la
contattiera o l'antenna consentono al microchip di dialogare con uno speciale
terminale di lettura collegato solitamente ad un computer mediante porta seriale,
parallela, USB, ecc.
La smart card a microprocessore, grazie alle caratteristiche di protezione dei dati
intrinseci del microchip e alla presenza di un coprocessore crittografico che gli
consente di eseguire le principali funzioni crittografiche on-board, si propone come il
mezzo adeguato a proteggere le chiavi private rilanciando la crittografia come
supporto tecnologico

di base

per lo

sviluppo

di

sistemi

informatici

sicuri

riproponendo in maniera decisa la firma digitale come un sicuro e insostituibile

strumento per l'autenticazione e l'identificazione degli individui, per la verifica
dell'integrit di insiemi di dati e per il non ripudio delle transazioni.
2.4. Biometric
verifica lidentit di un utente per una sua caratteristica fisica univoca quale
limpronta digitale o la voce.
2.5 Password
Per garantire una determinata sicurezza Oracle mette a disposizione un meccanismo
di password per proteggere laccesso al database. Il DBA ha il pieno controllo della
politica di gestione delle password e la possibilit di definire come deve essere una
password dal punto di vista fisico. Inoltre Oracle mette a disposizione un meccanismo
di verifica della complessit delle password che permette di controllare che ciascuna
password definita dagli utenti sia abbastanza complessa (protezione ragionevole)
contro possibili attacchi. Questa verifica fornita da Oracle attraverso una funzione
PL/SQL per cui possibile aggiungere ulteriore sicurezza scrivendone una propria
(sarebbe una buona norma). Per scrivere una funzione PL/SQL necessario rispettare
alcune regole base:

1. Contenere almeno quattro caratteri;

2. Non deve essere lunga quanto lusername;
3. Contiene almeno un carattere alfabetico, un carattere numerico e un segno di
punteggiatura;
4. Differisce dalla password precedente definita dallutente per almeno tre caratteri.
Com possibile osservare lultima regola sopra descritta un ulteriore ricerca di
sicurezza e si cerca di evitare che un utente cambi la password di un solo carattere
per volta. Naturalmente, come gi succede per la sicurezza del sistema operativo,
buona regola non utilizzare parole o nomi che per noi assumono un particolare
significato. Alcune password che adempirebbero alle regole di complessit sopra citate
sarebbero: du4 ck e qwpx2#1.
In Oracle le password scadono e il sistema provvede un periodo di proroga
in cui lutente ha la notifica che la propria password deve essere cambiata. Ma
qualora la password non venga cambiata durante tale periodo, laccount utente viene
bloccato e non avr laccesso al database fino a quando il DBA non lo permetter.
Ulteriore caratteristica quella di poter bloccare un utente che superi un
determinato numero di tentativi di autenticazione falliti.
CREATE PROFILE studenti LIMIT
FAILED_LOGIN_ATTEMPTS 4
ACCOUNT_LOCK_TIME 30
PASSWORD_GRACE_TIME 3;
Oracle permette poi di avere una storia delle password attraverso luso di parametri
quali password reuse time e password reuse max per definire il periodo che deve
essere trascorso prima che si possa riutilizzare un password. chiaro che riutilizzare
una password (sarebbe buona norma non farlo) pu risultare un enorme rischio per
la sicurezza. Le password sono criptate e memorizzate nel dizionario dei dati.

10

3. AUTORIZZAZIONE
Nella sua forma pi elementare, unautorizzazione di accesso coinvolge tre entit: il
soggetto a cui viene conferita, loggetto a cui riferito laccesso, loperazione di
accesso del soggetto alloggetto. Una classica rappresentazione delle autorizzazioni
definite in un dato stato del sistema la matrice di Lampson, in cui si dispongono i
soggetti in una dimensione e gli oggetti nellaltra: in ciascun elemento della matrice si
elencano le operazioni su un dato oggetto che un dato soggetto autorizzato a
compiere in quello stato del sistema. Tradizionalmente possono seguirsi due vie per
decomporre la matrice di Lampson in strutture pi`u ridotte:

fissare il soggetto, per ottenere la lista delle capacit (ingl. capabilities) di un

dato soggetto su qualsiasi oggetto;

fissare loggetto, per ottenere la lista di controllo di accesso (ingl. ACL: Access
Control List) alloggetto stesso da parte di qualsiasi soggetto.

I seguenti concetti semplificano la definizione e gestione delle ACL. Premesso che

intendiamo, in prima approssimazione, per classe di oggetti un insieme di oggetti sui
quali sono definite le stesse operazioni, 2 definiamo:

tipo di diritti di accesso: un nome, ovvero una designazione univoca, di un

sottoinsieme delle operazioni definite per una classe di oggetti;

ruolo: un nome, ovvero una designazione univoca, di un sottoinsieme delle

operazioni definite su un oggetto.

Le due definizioni sono molto simili, ma non del tutto identiche; alla piccola
differenza fra esse corrisponde una notevole differenza del significato intuitivo e degli
usi pratici di tali concetti. Esaminiamo questa differenza: essa consiste nel fatto che il
requisito di univocit della designazione
1. per i tipi di diritti di accesso, locale a ciascuna classe di oggetti, dunque uno
stesso tipo di diritti di accesso pu designare insiemi diversi di operazioni su
oggetti diversi solo se questi sono di classi diverse; mentre
11

2. per i ruoli, locale a ciascun oggetto: uno stesso ruolo pu designare insiemi
diversi di operazioni su oggetti diversi anche se della stessa classe.

4. AUDITING
Questo capitolo vuole approfondire il concetto di auditing gi espresso nel capitolo 1.
Come gi precisato la sicurezza un processo dinamico che si sviluppa nel tempo ed
pertanto opportuno che lamministratore o il semplice utente che accede al database
abbia una visione globale del sistema e conosca come proteggere le proprie risorse e/o
oggetti.

4.1 Auditing
Oracle stesso fornisce alcune funzioni di controllo della sicurezza del sistema. Tra
queste consideriamo la funzione di AUDIT TRAIL che permette la registrazione di
qualsiasi attivit, di nostro particolare interesse, svolta allinterno del database.
Possiamo infatti definire con auditing quel processo che offre la possibilit di
monitorare e registrare le attivit allinterno del database. Alcune azioni che possono
ad esempio essere monitorate sono le seguenti:

La visualizzazione/modifica/cancellazione di informazioni dalle tabelle;

La creazione o la rimozione di oggetti quali tabelle, viste, triggers ecc;

Esecuzione di programmi.

utile precisare immediatamente che per mezzo di funzionalit standard di Oracle

non possibile effettuare un monitoraggio a livello riga. In altre parole, attraverso lo
standard Oracle, possibile ad esempio controllare le azioni che sono state effettuate
su una tabella ma non cosa sia effettivamente cambiato in una specifica tabella.
Quindi possiamo dire che le caratteristiche dellauditing sono principalmente utili per
la sicurezza e per poter valutare chi connesso in un determinato istante, da dove
connesso, poter effettuare statistiche degli accessi, monitorare gli accessi ai dati e

12

potenziali attivit sospette. Normalmente lauditing non attivato di default. Quindi

esistono molte scuole di pensiero a riguardo. Se allinterno dellazienda stato
installato un firewall oppure altre misure di sicurezza possibile credere che il
sistema sia abbastanza sicuro e non sia necessario attivare lauditing. Lauditing
potrebbe essere attivato a meno che o fino al momento in cui si sia verificato un
problema di sicurezza dovuto ad un intrusore esterno oppure un dipendente che ha
oltrepassato il limite. Potreste quindi abilitare lauditing come conferma che qualcosa
sia anormale. Questo approccio retro-attivo naturalmente non consigliato.
In altre situazioni ancora si opta per una scelta di auditing pesante. Anche questo
approccio ha i suoi svantaggi e quindi non sempre pu essere considerata una scelta
corretta, in quanto ogni oggetto sotto controllo porta con se un costo potenziale sia
per quanto riguarda le risorse sia di prestazioni. Pertanto opportuno scegliere con
attenzione le forme di auditing in modo da ridurre al minimo indispensabile le risorse
sotto controllo.

4.2 Perch auditing

Il primo passo nello sviluppo di un piano di auditing determinare il motivo oppure
le ragioni per cui si ha la necessit di controllare il database.
Al livello generale possono esistere due principali motivi:
1. Sicurezza: determinare se qualcuno sta tentando di entrare nel sistema.
Quindi lauditing una risorsa utile per confermare possibili abusi (sospetti).
Ad esempio possibile confermare se dei dati siano stati cancellati da una
tabella del database semplicemente abilitando lauditing per tracciare le
operazioni di cancellazione da quella specifica tabella. opportuno e possibile
cominciare con un controllo generale per poi restringere il campo di controllo
per poter individuare meglio la sorgente del problema.
2. Prestazioni: perch il sistema cos lento? Come viene utilizzato il database?
Una volta definito lo scopo sar pi facile decidere gli oggetti da controllare.
Determinare le ragioni aiuter inoltre a restringere lambito per evitare di
raccogliere troppe informazioni inutili.

13

4.3 Risultato dellauditing

Ciascuna azione sotto controllo, qualora venga eseguita pu generare uno o pi record
nella tabella SYS.AUD$ del data dictionary. Interrogando direttamente questa tabella
oppure le viste create a partire da questa tabella possibile ottenere un riassunto
delle informazioni di particolare interesse per la sicurezza del sistema. Le colonne
sono numerose pertanto ne riporto alcune significative:
1. Azione compiuta;
2. Privilegio usato per compierla;
3. Lutente che lha compiuta;
4. Loggetto su cui stata compiuta;
5. Il giorno e lora in cui stata compiuta;
6. ecc

5. BACKUP
Oramai chiaro quanto i dati siano di notevole importanza per ciascuno di noi. Tutto
ruota attorno alle informazioni memorizzate nel database. Perdere dei dati potrebbe
ripercuotersi negativamente allinterno di unazienda. Per questo motivo opportuno
definire una strategia di backup e di recupero funzionale che permetta di recuperare
in breve tempo la disponibilit dei dati e cos perdere il numero minore di
transazioni non completate. Quando gestiamo un database buona regola ricordarsi
che software e hardware possono essere sostituiti ma i dati, in assenza di copie, non
possono essere ripristinati o quanto meno non completamente.

5.1 Frequenza di backup

Il backup essenzialmente una copia dei dati. I backup possono essere divisi in due
categorie principali: backup fisici e backup logici. I backup fisici sono copie dei file fisici
del database mentre i backup logici contengono dati esportati usando comandi sql e
memorizzati

in

un

file

binario.

Generalmente

quindi

backup

logici

sono

supplementari ai backup fisici. Un amministratore potrebbe eseguire un backup

14

giornalmente, settimanalmente oppure mensilmente ma corretto precisare che

esistono alcuni fattori che dovrebbero essere presi in considerazione:
1. Requisiti di disponibilit del database;
2. Importanza dei dati del database;
3. Possibilit o meno di arrestare il database per effettuare copie dei dati;
4. Dimensione totale dei file logici da copiare.

5.2 Archivelog
Ogni volta che occorre un cambiamento nel database, Oracle genera un record
(cambiamento) in un redo log. Vengono memorizzati tutti i cambiamenti, quindi
sia quelli che hanno avuto effetto sia quelli che non hanno avuto esito positivo. Oracle
costantemente registra i redo log negli online redo log che sono sul disco. Attivando
la modalit archivelog, il sistema pu memorizzare queste informazioni copiando gli
online redo log in altre destinazioni sul disco.

5.3 Forme di backup

Oracle mette a disposizione diverse possibilit per effettuare backup. Presento qui si
seguito alcune opportunit. Ciascuna soluzione pi`u o meno raffinata rispetto alle
altre, comunque sia tutte sono ugualmente funzionali ed utili:
5.3.1 Export e Import
Export e Import sono due utility Oracle che permettono rispettivamente di esportare
ed importare il contenuto logico di un database verso e da un unico file. Contenuto
logico significa che non sono esportati file fisici (datafile, log file, ecc) bens il loro
contenuto (tabelle,viste,ecc...). Naturalmente export un utility che permette di
creare un output a partire da un ambiente di Oracle mentre Import un utility che
pu leggere solo file generati da export.
Un vantaggio di avere un export quello di poter facilmente ripristinare una singola
oppure un insieme di specifiche tabelle. Le due utility possono essere utilizzate
comunemente per eseguire i seguenti compiti:

15

1. Backup e recovery (per piccoli database);

2. Riorganizzare i dati;
3. Rilevare corruzione del DB ed assicurare che tutti i dati possano esser letti;
4. Trasportare tablespace da un database ad un altro.
Ci sono differenti forme di export che possono essere eseguite. Queste si distinguono
utilizzando un parametro INC TYPE
1. COMPLETE: per un completo export del database;
2. INCREMENTAL: cattura ci che cambiato dallultimo incremento;
3. CUMULATIVE: cattura ci che cambiato dallultimo export completo.
5.3.2 Backup a freddo
Backup off-line pu essere definito anche backup a freddo. Per poter effettuare
questo tipo di backup necessario arrestare il database tramite Sql*Plus (oppure
Enterprise Manager) e successivamente copiare nelle apposite unit di recupero tutti i
file che costituiscono il database. Una volta fatto ci`o possibile far ripartire il
database.
Questa strategia totale per cui significa che viene effettuato un backup completo del
database e la sola mancanza di uno dei file potrebbe portare
allinutilit della copia. Lo svantaggio di adottare questo tipo di strategia la
difficolt che occorre qualora si voglia recuperare una oppure un insieme di
specifiche tabelle.
5.3.3 Backup a caldo
Backup on-line pu essere definito anche backup a caldo. possibile effettuare copie
di salvataggio senza dover arrestare il database. La procedura corretta richiede di
mettere i tablespace nello stato di backup, effettuare la copia, e poi riportarli in stato
normale.

16

6 ROW LEVEL SECURITY

Con questo capitolo si conclude la panoramica di alcune caratteristiche del sistema
Oracle in termini di sicurezza del sistema e dei dati. Fin qui si potuto costatare
come

mediante

diversi

sistemi

di

autenticazione,

ruoli,

privilegi

ed

altre

caratteristiche descritte nei precedenti capitoli, si possano gestire gli utenti e le azioni
che essi possono compiere allinterno del database. In tutte le versioni di Oracle
sempre stato possibile concedere oppure negare laccesso a particolari oggetti del
database, purtroppo questi privilegi sono definiti al livello di oggetto, per unintera
tabella, non per una o pi`u specifiche righe di una tabella. In alcuni casi pu essere
sufficiente questo tipo di approccio, in altre circostanze opportuno un maggiore
controllo. Row Level Security una caratteristica di Oracle, introdotta con la
versione Oracle 8i, che permette di restringere laccesso a sole specifiche righe di una
tabella in base ai privilegi sulla tabella stessa. Questa funzionalit stata anche spesso
descritta come fine grained access control o virtual private databases.

6.1 Cosa significa

Per garantire un maggior controllo sulla sicurezza dei dati, Oracle permette di
definire delle funzioni di politica di sicurezza (strettamente connesse ad una tabella
oppure una vista del database) eseguite ogni volta che i dati della tabella o vista
vengono visualizzati e/o modificati. Questa funzione restituisce un pezzo addizionale
di codice sql definito predicato che viene attaccato alla clausola where della
dichiarazione sql originale. Ci`o significa che la funzione controlla quali righe dei dati
della tabella sono restituite allutente che ha effettuato la richiesta. Il database
impone quindi le politiche di sicurezza, indipendentemente dal metodo utilizzato per
accedere ai dati. Consente di gestire con un unico database i dati di utenti differenti
nello stesso modo in cui fossero fisicamente residenti su database diversi tra loro.
possibile inoltre implementare la sicurezza una sola volta, nel server dati, anzich in
tutte le applicazioni che accedono ai dati.
Pertanto per mezzo di questa funzionalit possiamo:
1. Aumentare la sicurezza dei dati in maniera dinamica, evitando di dover
mantenere delle viste statiche;
2. Impostare delle politiche di sicurezza differenti per select, insert, update, delete.
17

7 SECURITY CHECK-LIST
Obiettivo di questa sezione quello di mettere in evidenza alcune linee guida che un
amministratore (soprattutto uno alle prime armi) dovrebbe seguire per rendere il
sistema il pi`u sicuro possibile. I punti a seguire possono essere pertanto un primo
aiuto alla configurazione post-installazione:

7.1 Bloccare gli utenti di default

In fase di installazione Oracle crea un numero prefissato di utenti di default (pu
variare a seconda della versione), vivamente consigliato bloccarli. Il DBCA (Database
Client Administration Tool) blocca automaticamente gli utenti di default eccetto i
seguenti:

SYS,

SYSTEM,

SCOTT,

DBSNMP,

OUTLN,

3utenti

JSERV

(vedi

documentazione della propria versione installata). Ma ci non avviene se linstallazione

viene effettuata manualmente. In questultimo caso quindi non bisogna dimenticarsi
di bloccarli, soprattutto se inutilizzati, altrimenti possono essere sfruttati per
conseguire laccesso non autorizzato ai dati o interrompere le operazioni del database
oltre ad essere un enorme rischio per lintegrit del database:
ALTER USER username ACCOUNT LOCK;

7.2 Cambiare le password degli utenti di default

Cambiare immediatamente le password degli amministratori: SYS e SYSTEM (change
on install e manager). Cambiare le password di tutti gli altri utenti.
ALTER USER username IDENTIFIED BY {new_password};

7.3 Controllo delle password

raccomandabile che siano applicate le regole base per la gestione delle password e
che sia richiesto agli utenti del database di cambiare periodicamente la propria
password. Utilizzare i profili.

7.4 Proteggere il data dictionary

importante proteggere il data dictionary poich gli utenti con un privilegio di
sistema ANY potrebbero potenzialmente leggere, eseguire, o modificare oggetti nel
18

data dictionary. possibile restringere i privilegi ponendo a false il parametro 07

DICTIONARY ACCESSIBILITY nel file di configurazione init.ora. Per la versione 9i
false di default. In questo caso si permette solo ad utenti sysdba di gestire il data
dictionary.

7.5 Privilegi e ruoli

Evitare di concedere privilegi quali SELECT/INSERT ANY TABLE. Usare i ruoli per
poter gestire meglio i privilegi. Non concederli a specifici utenti. I privilegi di sistema
dovrebbero essere concessi esclusivamente ad amministatori o amministratori della
sicurezza.

7.6 Restringere laccesso alla rete

1. Utilizzare un firewall;
2. Prevenire lamministrazione non autorizzata del listener impostando una
password ben definita. Per impostare la password, al prompt lsnrctl:set
password xxxxxxxxxx; possibile inoltre prevenire lamministrazione non
autorizzata del listener oracle impostando ad on il parametro seguente nel file
listener.ora: ADMIN_RESTRICTIONS_listener_name=ON;
3. Verifica dellindirizzo ip: permettere o negare laccesso ai processi del server
Oracle da parte di specifici client (ip). Configurare i seguenti parametri nel file
protocol.ora:
tcp.validnode_checking = YES
tcp.excluded_nodes = {list of ip address}
tcp.invited_node0s = {list of ip address}
4. Password criptate: impostare a TRUE i parametri ORA ENCRYPT LOGIN sul
client e DBLINK ENCRIPT LOGIN sul server per permettere una trasmissione
criptata delle password.
5. Utilizzare Advanced Security (enterprise edition)

7.7 Auditing
Attivare lauditing per favorire un controllo pi`u agevole della sicurezza del sistema
specialmente quando notevole l'importanza dei dati conservati nel database. Come
gi

detto

precedentemente

pu

essere
19

notevole

l'impatto

sulle

prestazioni

Lamministratore ha il compito di decidere a quale dettaglio effettuare il

monitoraggio.

7.8 Backup
Definire, usare e verificare una completa strategia di backup.

7.8 Applicare patch di sicurezza

Periodicamente visitare il seguente indirizzo per valutare possibili vulnerabilit ed
applicare le opportune patch: http://otn.oracle.com/deploy/security/alert

8 CONCLUSIONI
La conoscenza e la consapevolezza sono alla base della sicurezza. Garantire la
sicurezza assoluta del sistema e dei dati che conserviamo nel nostro database pu
cadere nellipocrisia. Nonostante ci nostro dovere fare in modo che i problemi di
sicurezza possano, nel limite del possibile, essere sempre rilevati e risolti. ormai
chiaro come siano pi di una le operazioni indispensabili per rendere un sistema
sicuro e come sia importante non tralasciare nessun dettaglio. Oracle richiede una
configurazione (orientata alla sicurezza) sin dalla fase iniziale di installazione (ad es.
cambiare le password e/o bloccare gli utenti non autorizzati). Successivamente
necessario monitorare con continuit`a le azioni che compiono gli utenti (ruoli,
privilegi, auditing, ...ecc) e configurare una comunicazione sicura in rete. Inoltre
opportuno (quasi obbligatorio) prevenire, mediante strategie di backup, perdite
accidentali dei dati.
Infine

responsabilit

dellamministratore

restare

al

passo

con

eventuali

aggiornamenti (patch rilasciate dal produttore) contro vulnerabilit riscontrate nel

sistema.

20

9 BIBLIOGRAFIA

http://it.wikipedia.org/wiki/Oracle

http://www.oracle.com/global/it/index.html

http://www.oracle.com/lang/it/database/index.html

http://www.kosmous.com/risorse/articolo.php?id=15

http://www.ippari.unict.it/~scollo/slidy/s1-2007/gss1/it/gss1.html#(1)

http://it.wikipedia.org/wiki/Smart_card

http://it.wikipedia.org/wiki/Transport_Layer_Security

http://www.dia.unisa.it/~ads/corso-security/www/CORSO9900/oracle/modello.htm

http://www.xml-dev.com/xml/images/Kerberos.png

Sicurezza in informatica Charles P.Pfleeger, Shari Lawrence Pfleeger, prima

edizione italiana

21