Problematiche di sicurezza su database
Oracle

I database mantengono i principali dati aziendali e debbono essere adeguatamente protetti.
Questa breve pagina riporta le problematiche piu' diffuse per quanto riguarda le basi dati ed i piu' comuni errori sulla sicurezza dei database ma sopratutto... indica come risolverle con l'RDBMS Oracle!

Nel seguito sono riportate le informazioni di interesse organizzate in paragrafi specifici: Introduzione, Matrice delle soluzioni, Controllo accessi, Controllo SQL, Protezione dati, Configurazione sicura, Varie ed eventuali.

Introduzione

Le piu' recenti normative per la sicurezza dei dati hanno posto l'attenzione di tutte le aziende sulla protezione dei dati: GDPR (General Data Protection Regulation, per la protezione dei dati personali), SOX (Sarbanes-Oxley Act of 2002, per la protezione dei dati finanziari), PCI-DSS (Payment Card Industry Data Security Standard, standard internazionale a protezione dei dati delle carte di credito), HIPAA (Health Insurance Portability and Accountability Act, legge USA a protezione dei dati personali e sanitari), ...

I database mantengono i principali dati aziendali e debbono essere adeguatamente protetti. Questo documento presenta quelli che sono le problematiche di sicurezza piu' comuni relativamente ai database e come possono essere risolte. A seconda dei casi verranno presentate soluzioni introducendo Best Practice di programmazione o di progettazione, utilizzando funzionalita' standard Oracle, utilizzando Option Oracle (componenti aggiuntivi), utilizzando strumenti o pacchetti esterni.

Tra i molti elenchi di problematiche da cui partire... ne abbiamo scelto uno italiano che ha anche il pregio di avere le virtu' Calviniane dell'esattezza e della rapidita'. L'elenco sulle problematiche di sicurezza piu' comuni per i database e' quello contenuto nel Rapporto 2016 preparato dal Clusit (Associazione Italiana per la Sicurezza Informatica) su aziende italiane ed e' quindi uno specchio reale della situazione presente nella maggioranza delle imprese.

Le problematiche emerse nella ricerca sono state suddivise nelle seguenti categorie:

• DB Access Control
  Definizione dell'accesso ai dati ai soli utenti autorizzati e controllo di quando, dove e come i dati sono acceduti.

  1. No distinction between Application User and Schema Owner (AC1)

  2. Application user credential not protected in the application server (AC2)

  3. Developers use application user credential (AC3)

  4. DBAs do not have personal accounts and use technical accounts (AC4)

  5. Technical accounts defined with a human algorithm and never changed (AC5)

  6. End users have direct access to the DB bypassing the application (AC6)

  7. No lifecycle management for DB users (AC7)

  8. OS administrators can escalate their privileges to DBA (AC8)

  9. DBAs have full access to users' data (AC9)

• Monitoring / Blocking and Audit
  Analisi delle transazioni che avvengono sulla base dati ed visualizzazione le attivita' correnti e storiche

  1. No preventive SQL controls (LG1)

  2. No or partial and inconsistent logs (LG2)

  3. Logs are not analyzed (LG3)

  4. Logs are not managed (LG4)

  5. No DB user accountability (LG5)

  6. No end user accountability (LG6)

• Data Protection
  Processi e controlli sulla trasmissione, sull'accesso e la memorizzazione delle informazioni per tutto il ciclo di vita dei dati.

  1. Applications do not encrypt (DP1)

  2. No datafile encryption (DP2)

  3. No storage encryption (DP3)

  4. No network encryption (DP4)

  5. No backup / export encryption (DP5)

  6. Production data copied to development environments (DP6)

• Secure Configuration
  Processi e controlli per garantire la corretta configurazione dei Database

  1. Obsolete DB / OS releases (SC1)

  2. No DB / OS hardening (SC2)

  3. No patching (SC3)

  4. Poor SDLC production promotion and SoD (SC4)

  5. No production user, privileges, db objects change control (SC5)

Nel resto del documento analizzeremo le tecnologie disponibili in Oracle per risolvere le problematiche di sicurezza dei dati su ciascuna delle categorie citate.

Matrice delle soluzioni

La tabella seguente riporta come approcciare le diverse problematiche di sicurezza con l'RDBMS Oracle [NdA si fa riferimento alle funzionalita' presenti nella Enterprise Edition per le versioni attualmente supportate]. La matrice e' volutamente sintetica e riassuntiva. E' importante sottolineare che molte problematiche non possono essere solo risolte a livello di tecnologia ma richiedono un preciso processo aziendale. La tabella riporta se il DB fornisce un supporto per gestire la problematica, quanto il supporto e' completo e se sono necessari componenti esterni o opzionali.

Dalla tabella e' chiaro che la molti dei punti sono da gestire con processi o con strumenti esterni al Database. Quando la problematica riguarda il database il supporto fornito da Oracle e' sempre adeguato; in qualche caso e' opportuno l'utilizzo di Option aggiuntive all'RDBMS disponibili nell'edizione Enterprise.
Nei prossimi capitoli vengono riportati maggiori dettagli su ciascuna delle soluzioni tecniche disponibili in Oracle.

DB Access Control

Per il principio del minimo privilegio (least privilege) vanno utilizzate le utenze con i diritti minori possibili per svolgere le diverse attivita'. Questo e' particolarmente importante per le utenze applicative che debbono svolgere tipicamente solo operazioni CRUD, a cui non servono i privilegi per operazioni di DDL e sono tipicamente maggiormente soggette ad attacchi e meno protette. E' quindi necessario che le utenze utilizzate dagli Application Server o dai Web Server non siano proprietarie dello schema dati.

Sono molteplici le soluzioni tecnologiche fornite da Oracle per quanto riguarda il controllo degli accessi:

• No distinction between Application User and Schema Owner (AC1)

  Oracle per questa problematica, oltre a supportare in modo completo i GRANT ed i ROLE previsti dall'SQL offre da sempre un'elegante soluzione basata sui SYNONYM (che sono un'estensione di Oracle all'SQL Standard).
  Utilizzare un'utenza Owner dello schema ed una o piu' utenze differenti per l'esecuzione delle applicazioni e l'accesso ai dati e' una Best Practice consolidata, normalmente applicata e fatta rispettare da tutti i DBA Oracle.
  E' buona norma utilizzare il principio del minimo privilegio, per le utenze applicative. Mentre per lo schema owner viene tipicamente concesso a livello di sistema il grant di RESOURCE (che comporta la possibilita' di creare oggetti), alle utenze applicative viene concesso solo il grant di CONNECT. Sara' poi lo schema owner a fornire i grant di SELECT/INSERT/UPDATE/DELETE per le tabelle utilizzate dalle applicazioni. Da questo punto di vista Oracle ha una definizione di privilegi tra le piu' ampie e sofisticate. E' consigliato l'utilizzo dei ROLE quando l'elenco dei privilegi e' complesso.
  La verifica della corretta applicazione di tali direttive si svolge facilmente con query sul data dictionary di Oracle.
  Nel seguito e' riportato un esempio minimale di configurazione con GRANT e SYNONNYM.

  La definizione dello schema dati e dei GRANT e' compito dell'Application Schema Owner:

  REM As ApplicationSchemaOwner
  
  create table emp(EMPNO integer not null, ENAME VARCHAR(10), JOB VARCHAR(9),
         MGR integer, HIREDATE DATE, SAL float, COMM float, DEPTNO integer);
  ...
  
  GRANT SELECT, INSERT, UPDATE, DELETE ON emp TO ApplicationUser;
  GRANT SELECT ON emp TO EndUser;
  

  Su ogni utente che acceda ai dati sara' necessario creare i sinonimi con:

  REM As ApplicationUser o EndUser
  
  create synonym emp for ApplicationSchemaOwner.emp;
  ...
  

  A questo punto l'accesso ai dati e' trasparente:

  sqlplus EndUser SELECT * from emp;

  La granularita' delle abilitazioni in Oracle e' molto elevata, per una verifica puntuale e' consigliabile l'utilizzo di script e tool certificati.

  Con la 12c una particolare attenzione va posta, utilizzando l'Opzione Multitenant, alle utenze comuni C## perche' in grado di operare su tutti i pluggable database.

• No lifecycle management for DB users (AC7)

  Oracle, in particolare nelle versioni piu' recenti, permette una gestione completa del ciclo di vita delle utenze mediante i PROFILE:

  CREATE PROFILE app_user2 LIMIT
     FAILED_LOGIN_ATTEMPTS 5
     PASSWORD_LIFE_TIME 60
     PASSWORD_REUSE_TIME 60
     PASSWORD_REUSE_MAX 5
     PASSWORD_VERIFY_FUNCTION verify_function
     PASSWORD_LOCK_TIME 1/24
     PASSWORD_GRACE_TIME 10;
  

  La definizione dei profile corretti e la gestione degli account lock/unlock consente una gestione semplice ed efficace di tutte le utenze in Oracle.

• OS administrators can escalate their privileges to DBA (AC8)

  Questa problematica non e' risolta in modo facile con Oracle perche' l'utente con cui si effettua l'installazione del software puo' connettersi alla base dati con sqlplus / as sysdba e l'utente root puo' diventare facilmente l'utente di installazione con su - .
  Vanno quindi considerati utenti privilegiati sul DB anche i system administrator. Innanzi tutto e' necessario utilizzare utenze personali anche per gli utenti amministratori del sistema e non solo per i DBA, quindi deve essere presente un preciso auditing delle attivita' anche a livello di sistema operativo.
  Oracle inoltre fornisce la funzionalita' DB Vault, descritta nel punto successivo, che consente di definire e limitare gli accessi ai dati anche ai DBA stessi.

  Al contrario non e' necessario che un DBA diventi root (serve solo il lancio di qualche comando in fase di installazione del DB) e sono anche rare le privilege escalation. Questo rende piu' sicuri i sistemi perche' le utenze DBA non hanno la possibilita' di installare rootkit.

• DBAs have full access to users' data (AC9)

  Le utenze amministrative in Oracle hanno accesso a tutti i dati applicativi e non e' possibile escludere tali diritto. Oracle tuttavia fornisce una specifica Option che consente di restringere l'accesso ai dati applicativi anche ai DBA. L'opzione e' Oracle Database Vault Option. Con il DB Vault tutti gli accessi dati possono essere segnalati e/o autorizzati configurandoli in Realm di protezione. Anche le utenze amministrative risultano essere limitate: quindi se connessi come SYS non si riesce comunque ad eseguire SELECT sal FROM scott.emp e si ottiene l'errore:

  ERROR at line 1:
  ORA-00604: error occurred at recursive SQL level 1
  ORA-47400: Command Rule violation for select on SCOTT.EMP
  ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 69
  ORA-06512: at line 17
  

Le altre problematiche riportate in questa categoria vengono risolte definendo ed applicando opportune policy di sicurezza.
Ad esempio non ci sono ragioni tecniche su Oracle per far utilizzare l'utenza applicativa agli sviluppatori negli ambienti di produzione. Una corretta definizione degli ambienti (eg. sviluppo, collaudo, produzione) e delle procedure per la messa in esercizio delle applicazioni e' necessaria per disporre di sistema sicuro nel suo complesso.

Monitoring / Blocking and Audit

Sono molteplici le soluzioni tecnologiche fornite da Oracle per quanto riguarda il monitoraggio delle attivita' correnti sulla base dati (eg. V$SESSION).
Oracle fornisce una vista completa delle attivita' svolte sulla base dati grazie ad un ricchissimo catalogo, a specifiche opzioni aggiuntive ed a tool esterni.

• No preventive SQL controls (LG1)

  Per quanto riguarda il controllo preventivo dell'SQL questo puo' essere realizzato con proxy esterni all'RDBMS. Con il proxy Oracle Firewall DB e' possibile implementare controlli preventivi sull'SQL. Altre soluzioni (eg. WAF: Web Application Firewall) sono esterne al DB.

• No or partial and inconsistent logs (LG2)

  Il logging di Oracle e' sempre stato ampio ed esaustivo. Vengono registrate le principali attivita' sul DB ed eventuali errori (eg. alert.log), gli accessi dalla rete (eg. listener.log), i trace e gli eventuali core, ...
  In effetti una delle tipiche attivita' del DBA Oracle e' la pulizia dei log non piu' utili per evitare problemi di spazio!

  Per tracciare gli accessi Oracle ha sviluppato, fin dalle prime versioni, un potente e sofisticato sistema di Auditing.

  Naturalmente l'AUDIT va configurato...
  Un insieme minimale di controlli puo' essere attivato con le istruzioni SQL (da utente DBA):

  AUDIT SESSION WHENEVER NOT SUCCESSFUL;
  AUDIT SESSION BY ACCESS;
  AUDIT DBA;
  AUDIT INSERT, UPDATE, DELETE ON sys.aud$ BY ACCESS;
  

  Con tali definizioni si controllano gli accessi al DB e la tabella di auditing stessa.
  Per attivare controlli su tabelle utente specifiche l'attivazione e' la seguente:

  
  AUDIT INSERT, UPDATE, DELETE ON scott.emp BY ACCESS;
  
  

  Altra tecnica, molto potente ed utilizzata spesso anche da tool di terze parti, e' l'utilizzo di trigger. In particolare del trigger di AFTER LOGON consente anche di impostare politiche di accesso:

  CREATE OR REPLACE TRIGGER global_logon_trg AFTER logon ON DATABASE
  DECLARE
     p_session_user  varchar2(64);
     p_module        varchar2(64);
     p_term          varchar2(64);
  BEGIN
     SELECT UPPER(SYS_CONTEXT('USERENV', 'SESSION_USER')) INTO p_session_user FROM DUAL;
     SELECT UPPER(SYS_CONTEXT('USERENV', 'MODULE')) INTO p_module FROM DUAL;
     SELECT UPPER(SYS_CONTEXT('USERENV', 'TERMINAL')) INTO p_term FROM DUAL;
  
     DBMS_SESSION.SET_IDENTIFIER(p_session_user || '-' || p_module || '-' || p_term);
  
     IF ((p_session_user = 'SCOTT') AND (p_module IN ('MYAPP.EXE'))) THEN
        DBMS_SESSION.SET_IDENTIFIER('about to raise app_error..');
        RAISE_APPLICATION_ERROR(-20069,'You are not allowed to connect to the database');
     END IF;
  END;
  /
  

  La raccolta e la securizzazione dei log, comunque generati, e' tipicamente realizzata dal SIEM aziendale.

• No DB user accountability (LG5)

  Va utilizzato lo strumento di auditing descritto nel punto precedente.

• No end user accountability (LG6)

  Va utilizzato lo strumento di auditing descritto nel punto precedente.

Data protection

Sono molteplici le soluzioni tecnologiche fornite da Oracle per quanto riguarda la protezione dei dati:

• Applications do not encrypt (DP1)

  Anche se si tratta di un processo esterno alla base dati Oracle fornisce un ampio insieme di funzioni di crittografia e datatype adatti a mantenere dati crittografati.

  Quali dati e con quali algoritmi va analizzato in modo adeguato. Per iniziare e' possibile adattare alcuni semplici script SQL per estrarre dal DB le tabelle e le colonne da verificare. Da questo punto di vista e' molto importante la conoscenza del dato.

  Una panoramica sulle funzioni di crittografia disponibili a livello di database ed a quale livello sono applicabili e' contenuto in questo documento.

• No datafile encryption (DP2)

  Generalmente i datafile Oracle vengono salvati in chiaro ovvero con un formato complesso (una struttura a blocchi che, oltre all'RDBMS Oracle, il DUL o strumenti simili sanno analizzare) ma senza crittografazione.
  Il TDE (transparent data encryption) e' componente dell'Advanced Security Option che fornisce la funzionalita' di data-at-rest encryption. Con il TDE i datafile vengono scritti in modo crittografato ed e' quindi impossibile accedere ai dati se non attraverso l'RDBMS.

• No network encryption (DP4)

  SQL*Net supporta la crittografia delle trasmissioni [NdA l'encryption e' disponibile dalla v.2 ovvero dalla versione Oracle 7.0 del 1992]. Inizialmente era necessario l'acquisto dell'opzione di Advanced Security ma nelle versioni piu' recenti non e' necessaria alcuna opzione [NdE oramai da molto tempo: l'autore di questa pagina e' chiaramente un vecchio DBA].

  La configurazione si effettua nel file listener.ora e nel file sqlnet.ora impostando il wallet per la gestione dei certificati:

  SSL_CLIENT_AUTHENTICATION = FALSE
  WALLET_LOCATION=
    (SOURCE=
      (METHOD=file) (METHOD_DATA=(DIRECTORY=/home/oracle/app/oracle/product/11.1.0/dbhome_1/db_wallet)))
  

• No backup / export encryption (DP5)

  RMAN ed expdp/impdp supportano in modo completo la crittografia ma per utilizzarla e' necessaria l'Advanced Security Option.

  Con i tool Oracle non e' generalmente possibile utilizzare in pipe i comandi di backup [NdA lo era con exp che pero' e' desupportati dalla 11g]. Se non si dispone dell'Advanced Security Option, il modo piu' semplice e' quello di effettuare i backup su disco ed al termine effettuare la crittografia, spesso preceduta dalla compressione, con comandi del sistema operativo.

• Production data copied to development environments (DP6)

  expdp fornisce strumenti per effettuare il datamasking (eg. come utilizzati in miXen). L'opzione Advanced Security Option permette la definizione di politiche di redaction utilizzabili anche per il ribaltamento dei dati. Altro prodotto utile e' l'Oracle Data Masking and Subsetting (e' un pack per EM).

• Unnecessary data are not hidden/masked (DP7)

  Con viste, sinonimi ed opportuni GRANT da Oracle e' possibile mascherare i dati non necessari:

  create view emp_rest as
  select EMPNO, ENAME, JOB,
         MGR, HIREDATE, 0 SAL, 0 COMM, DEPTNO
    from emp;
  

  La maggior difficolta' e' nell'analisi che richiede competenze sui dati/applicazioni e spesso non viene eseguita con la necessaria attenzione. Anche in questo caso e' possibile utilizzare semplici script SQL per individuare i dati da trattare con l'encryption/masking di miXen [NdE l'utility DBSAT ha di recente inserito la feature di discover per il GDPR].

  Particolarmente sofisticata e' la data redaction, inclusa nell'Option Oracle Advanced Security, che permette la definizione di policy di mascheramento dei dati:

  BEGIN
    DBMS_REDACT.add_policy(
      object_schema => 'scott',
      object_name   => 'emp',
      column_name   => 'sal',
      policy_name   => 'redact_employee',
      function_type => DBMS_REDACT.nullify,
      expression    => '1=1'
    );
  END;
  /
  

Secure Configuration

Oracle da sempre ha tenuto in forte considerazione questi aspetti e tutte le versioni piu' recenti hanno configurazioni di default molto sicure.

• Obsolete DB / OS releases (SC1)

  Le procedure di upgrade di Oracle sono ben definite ed il calendario delle release supportate e' ben noto.
  Il numero di versione e' composto da cinque cifre, le prime due indicano una major release con variazioni significative delle funzionalita'. La quinta cifra indica l'ultimo update (RU: Release Updates o, per le versioni precedenti alla 12.2, PSU: Patch Set Updates) che occorre con cadenza trimestrale. Dal 2018 e' prevista una varizione sulla numerazione delle release Oracle (eg. 18.1).
  Oltre al calendario per l'applicazione dei Critical Patch Updates Oracle emette anche, in casi di particolare gravita' (eg. CVE-2017-9805 "Equifax"), specifici Security Alerts. Spesso questi ultimi si riferiscono ad altri prodotti Oracle (eg. WebLogic) che sono esposti su Internet.

  La difficolta' maggiore in un upgrade e' esterna al DB e riguarda la certificazione delle applicazioni sulle nuove releases.
  Oracle non consente accessi via SQL*Net quando tra client e server vi sono piu' di due release major release di differenza.

  L'upgrade di Oracle richiede generalmente un effort significativo.
  E' quindi necessario che venga definito un processo aziendale di aggiornamento delle releases e che siano previste finestre periodiche di manutenzione.

  L'aggiornamento del sistema operativo e' esterno al DB.

• No DB / OS hardening (SC2)

  Le impostazioni di default di Oracle sono generalmente sicure ma vanno comunque verificate con attenzione. Nel tempo le funzionalita' di sicurezza di Oracle si sono accresciute pur mantenendo la compatibilita' con le versioni precedenti. La limitazione degli accessi dalla rete non e' molto comune con Oracle ma puo' essere effettuata configurando il file sqlnet.ora.

  Sono ben documentate le Best Practices sulla sicurezza Oracle e vi sono tool supportati per verificarle (eg. DBSAT). Utili sono anche i controlli riportati nei CIS Benchmark e le STIG (Security Technical Implementation Guides) dello IASE [NdA un po' datati i documenti sono Pratical Oracle Security e Secure Your Oracle DB by breaking into! che avevo scritto il secolo scorso]. Non va dimenticato il controllo delle password tra cui le famigerate, ma non piu' con le attuali versioni, password Oracle di default.

  E' sicuramente importante raccogliere periodicamente le configurazioni ed i dati sull'utilizzo degli ambienti. La raccolta di tali informazioni non e' solo importante per le attivita' sistemistiche ma anche per la sicurezza degli ambienti: senza una baseline e' impossibile qualsiasi analisi. Tra gli strumenti utili: ux2html (raccolta configurazione sistemi Unix), ora2html (raccolta configurazione Oracle).

  L'hardening dell'OS e' esterno al DB, ma ugualmente importante. Fondamentale e' anche la protezione degli accessi da rete con Firewall.

• No patching (SC3)

  Oracle emette patch con cadenza trimestrale seguendo un preciso calendario. L'applicazione delle patch, oltre ad essere fortemente consigliata, e' stata resa nel tempo sempre meno critica per le applicazioni: nell'ultima versione [NdA 12.2] le RU (Release Update che comprendono i principali fix di sicurezza) non introducono nessuna variazione di comportamento dell'ottimizzatore.
  Anche le attivita' di patching Oracle vanno inserite nel processo aziendale di aggiornamento e manutenzione degli ambienti.

Varie ed eventuali

Va sottolineato che, delle attivita' di messa in sicurezza evidenziate, solo alcune sono legate all’acquisto di nuovi prodotti. Spesso per risolvere la maggioranza delle problematiche e' sufficiente un buon uso di quello che si ha gia' come versioni/supporto/opzioni Oracle, e l'applicazione di adeguati processi aziendali il tutto dopo una corretta e completa analisi di sicurezza.

Il riferimento ufficiale per la sicurezza dell'RDBMS Oracle e' sul sito ufficiale e vengono periodicamente aggiornati i Security Alerts. Va riportato pero' che l'importanza e la complessita' della materia sono notevoli (eg. la sola Security Guide e' di oltre 800 pagine) gli interventi di messa in sicurezza di Oracle vanno quindi approcciati con la necessaria competenza ed esperienza.

Titolo: Risolvere gli errori di sicurezza sui database Oracle
Livello: Medio (2/5)
Data: 1 Ottobre 2017
Versione: 1.0.0 - 1 Gennaio 2018
Autori: mail [AT] meo.bogliolo.name, Guido Marino