Oracle
 sql >> Database >  >> RDS >> Oracle

Sicurezza del database Oracle:controllo del database

In questo articolo, continuerò con Oracle Database Security e presenterò alcuni fatti importanti sul controllo del database standard, i trigger di controllo e le politiche di controllo in Oracle. Il controllo del database ha due componenti:il monitoraggio e la registrazione permanente di insiemi di attività ed eventi del database stabiliti. Le finalità dell'audit del database sono il non ripudio, l'indagine su attività sospette, l'individuazione di problemi generati dalle configurazioni in materia di autorizzazione (accesso alle risorse), il rispetto della normativa vigente e il controllo.

Revisione standard

Quali attività controlliamo? L'avvio e l'arresto del database, nonché le connessioni effettuate dall'amministratore del database, sono implicitamente controllati da Oracle ei dati vengono archiviati automaticamente nel sistema operativo. La tabella seguente mostra altre attività che possono essere monitorate:

Dove conserviamo le attività controllate?

  • nel database , utilizzando l'audit trail del database, dove abbiamo due possibilità:
    • audit_trail =DB
      che può essere fatto con il seguente codice:

      alter system set audit_trail=db scope=spfile;
    • audit_trail =DB,EXTENDED
      utilizzando il seguente codice:

      alter system set audit_trail= db, extended scope=spfile;

    La differenza tra DB e DB,EXTENDED è che il secondo popola le colonne SQLBIND e SQLTEXT CLOB della tabella SYS.AUD$.

  • esterno , utilizzando l'audit trail del sistema operativo, con le seguenti possibilità:
    • audit_trail =OS
      e il codice utilizzato è:

      alter system set audit_trail=os scope=spfile;
    • audit_trail =XML e AUDIT_FILE_DEST =percorso del file (è implicitamente $ORACLE_BASE/admin/$ORACLE_SID/adump)
      con il codice:

      alter system set audit_trail=xml scope=spfile;

Per trovare la configurazione corrente delle attività controllate memorizzate, è possibile eseguire la seguente query, scritta in minuscolo:

select value from v$parameter where name='audit_trail';

Comandi più utili:

[id tabella=43 /]

Ora diamo alcuni esempi di controllo del database.

Ecco un esempio di audit standard con informazioni controllate archiviate nel database:

Le informazioni controllate sono costituite dalle istruzioni SELECT eseguite sulle tabelle del database.

In SQL Developer, esegui il seguente script:

alter system set audit_trail= db, extended scope=spfile;
AUDIT SELECT TABLE;

Quindi, il database deve essere riavviato. Per fare ciò, nel terminale SQLPlus, connettiti con il nome utente sys come sysdba / password ed esegui le seguenti istruzioni:

SHUTDOWN IMMEDIATE
STARTUP

Tieni presente che le dimensioni di cui sopra differiscono da un sistema all'altro.

Per verificare se l'audit trail è impostato correttamente, eseguire la query seguente:

select value from v$parameter where name='audit_trail';

oppure:

show parameter audit_trail;

Quando vuoi interrompere l'audit, esegui:

NOAUDIT SELECT TABLE;

Per visualizzare quali dichiarazioni sono state registrate dall'audit, puoi utilizzare:

select dbms_lob.substr( sqltext, 4000, 1 )
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS');

o

select count(*), OBJ$NAME, USERID
from SYS.AUD$
where OBJ$NAME IN ('EMPLOYEES','DEPARTMENTS','JOBS','LOCATIONS')
group by rollup (OBJ$NAME, USERID);

Un altro esempio è per l'audit standard con dati controllati archiviati in un file XML, nel percorso standard.

alter system set audit_trail=xml scope=spfile;
AUDIT SELECT, INSERT, UPDATE, DELETE ON employees WHENEVER NOT
SUCCESSFUL;

Di nuovo, riavvia il database:collegati al terminale SQLPlus con username sys come sysdba/password ed esegui i comandi SHUTDOWN IMMEDIATE e STARTUP.

Quindi, ogni volta che una query di selezione, inserimento, aggiornamento ed eliminazione non riesce nella tabella dipendenti, dovrebbe essere registrata nel file XML.

Quando vogliamo interrompere l'audit, eseguiamo i seguenti comandi nell'ambiente di sviluppo del database:

NOAUDIT ALL;
NOAUDIT ALL ON DEFAULT;

E ripristina l'audit trail predefinito:

alter system set audit_trail=db scope=spfile;

Di seguito è riportato un esempio di una parte di un file di controllo XML:

Come eliminiamo le informazioni controllate?

Il volume dei dati controllati può diventare molto grande a causa del numero delle attività controllate e della loro frequenza. Per questo motivo si consiglia di archiviare periodicamente i dati controllati ed eliminarli dal sistema produttivo.

Se i dati controllati sono archiviati nel database (traccia di controllo del database), possiamo utilizzare le istruzioni di eliminazione (ma solo dopo aver archiviato i dati!):

DELETE FROM SYS.AUD$;

Puoi scegliere di eliminare le informazioni controllate per un oggetto database specifico, ad esempio una tabella denominata prodotti:

DELETE FROM SYS.AUD$ WHERE OBJ$NAME='PRODUCTS';

Trigger di controllo

Un trigger è un blocco PL/SQL o l'istruzione CALL di una procedura PL/SQL che viene eseguita automaticamente ogni volta che si verifica un evento. Esistono due tipi di trigger:a livello di database (istruzioni di database) ea livello di applicazione (ad esempio premendo un pulsante su un modulo Oracle). I trigger utilizzati per il controllo sono i trigger a livello di database. Si classificano nelle seguenti categorie:

  • Trigger DML – dove un'istruzione DML viene attivata su una tabella. Tali trigger possono essere eseguiti una volta a livello di comando indipendentemente dal numero di record (trigger a livello di istruzione) oppure possono essere eseguiti PER OGNI RIGA (trigger a livello di record). Tipi di trigger a livello di record:PRIMA DICHIARAZIONE, DOPO DICHIARAZIONE, PRIMA DI OGNI RIGA, DOPO OGNI RIGA;
  • INVECE DI trigger – dove un'istruzione DML viene attivata su una vista;
  • Trigger di SISTEMA:attivati ​​da eventi quali avvio/arresto del database, istruzioni DDL, login/logout utente. Tipi di trigger di sistema:DOPO EVENTO, PRIMA DELL'EVENTO.

Interrogazione di SYS.TRIGGER$ tabella o ALL_TRIGGERS view offre informazioni su tutti i trigger a livello di database. Ad esempio, il tipo di trigger distinto dal database può essere trovato come segue:

SELECT DISTINCT TRIGGER_TYPE FROM ALL_TRIGGERS;

La vista DBA_TRIGGERS offre informazioni sui trigger creati automaticamente dai prodotti Oracle al momento dell'installazione. Se vogliamo trovare informazioni sui trigger SYSTEM ("BEFORE EVENT" e "AFTER EVENT"), possiamo eseguire la seguente istruzione:

SELECT SUBSTR(OWNER,1,20) OWNER ,SUBSTR(TRIGGER_NAME,1,30),
TRIGGER_NAME, SUBSTR(TRIGGERING_EVENT,1,30) TRIGGERING_EVENT,
TRIGGER_TYPE
FROM DBA_TRIGGERS
WHERE TRIGGER_TYPE='BEFORE EVENT' OR TRIGGER_TYPE='AFTER EVENT'
ORDER BY TRIGGER_TYPE DESC;

Inoltre, al momento dell'installazione, i trigger DML vengono creati automaticamente sullo schema utente HR:

SELECT SUBSTR(TABLE_NAME,1,20) TABLE_NAME,
SUBSTR(TRIGGER_TYPE,1,30) TRIGGER_TYPE,TRIGGER_BODY
FROM DBA_TRIGGERS
WHERE OWNER='HR';

Per il controllo, possiamo creare trigger personalizzati per registrare le informazioni desiderate, ma è necessario creare una tabella speciale per memorizzare le informazioni controllate.

È importante assicurarsi che i trigger sviluppati non influenzino la normale attività del database. Lo scopo dell'auditing è di monitorare passivamente la normale attività quotidiana del database e di archiviarla per un'analisi successiva. Di conseguenza, non è consigliabile creare trigger INSTEAD OF per restituire i risultati dalle tabelle di destinazione alla tabella di controllo.

I trigger DML a livello di istruzione possono coesistere con i trigger DML a livello di record. L'ordine di chiamata è:

  • istruzione trigger BEFORE
  • per ogni record interessato
    • attiva PRIMA della registrazione
    • Azione DML corrente
    • attiva DOPO la registrazione
  • Attiva l'istruzione AFTER

I trigger definiti dall'utente verranno eseguiti solo se, secondo Oracle, l'istruzione è corretta e può verificarsi. Per un'istruzione DML errata o che viola un vincolo, verrà restituito un errore e il trigger non verrà eseguito. Pertanto, per l'auditing, si consiglia di utilizzare soprattutto i trigger LMD a livello di istruzione.

Esempio di trigger di controllo:

Supponiamo di voler creare un trigger per registrare in una tabella di controllo (chiamata TAB_AUDIT_EMP) informazioni sulle dichiarazioni DML che stabiliscono stipendi superiori a 20000 (la valuta non è importante qui) per i dipendenti dell'azienda. Vogliamo memorizzare in TAB_AUDIT_EMP il numero di sequenza della query, il nome utente, la sessione, l'host e la data.

Questo può essere fatto con quanto segue:

CREATE TABLE TAB_AUDIT_EMP

(secv_id NUMBER(3) PRIMARY KEY,
username VARCHAR2(20),
session_nr NUMBER(10),
hostname VARCHAR2(100),
query_date DATE
);

CREATE SEQUENCE secv_aud_emp START WITH 1 INCREMENT BY 1;
CREATE OR REPLACE TRIGGER huge_salary
AFTER INSERT OR UPDATE OR DELETE OF SALARY ON EMPLOYEES
FOR EACH ROW WHEN (NEW.salary>20000)
BEGIN
INSERT INTO TAB_AUDIT_EMP
VALUES(secv_aud_emp.NEXTVAL , sys_context('userenv', 'session_user'), sys_context('userenv', 'sessionid'), sys_context('userenv', 'host'), sysdate);
END;

Supponiamo di apportare una modifica salariale per i dipendenti in un reparto specifico:

UPDATE EMPLOYEES
SET SALARY=25000
WHERE ID_DEPARTMENT = 1;

E poi verifichiamo il monitoraggio:

select secv_id, substr(username,1,20) username, session_nr, substr(hostname,1,30) hostname, query_date
from TAB_AUDIT_EMP;

Politiche di controllo

Il terzo metodo di controllo si riferisce alle politiche di controllo. La definizione di una politica di audit contiene quanto segue:

  • Specifica dell'oggetto (schema, nome oggetto, colonne) sottoposto a monitoraggio
  • specifica delle azioni controllate per un oggetto (SELECT, INSERT, UPDATE, DELETE):implicitamente è SELECT
  • la specificazione delle condizioni che devono essere soddisfatte per poter registrare le informazioni controllate, avviene nella clausola WHEN del trigger ed è facoltativa
  • un gestore di eventi che gestisce anche l'evento, che è facoltativo.

Un criterio di audit può essere attivo (stato ABILITATO) o inattivo (stato DISABILITATO). L'elenco delle politiche di controllo può essere ottenuto interrogando la vista ALL_AUDIT_POLICIES:

SELECT POLICY_TEXT, ENABLED
FROM ALL_AUDIT_POLICIES

Per l'amministrazione della politica di audit abbiamo il pacchetto DBMS_FGA. Per utilizzare questo pacchetto, è necessario concedere il privilegio agli utenti che scriveranno il codice PL/SQL:

grant execute on dbms_fga to username;

Esempio di politica di controllo:

Vogliamo creare una policy di audit per la registrazione delle istruzioni DML che modificano i gestori (MANAGER_ID) nella tabella DEPARTMENTS. Possiamo scegliere di creare un gestore per la politica, chiamato proc_audit_alert, che ci informa di una modifica riguardante il gestore:

CREATE OR REPLACE PROCEDURE proc_audit_alert ( object_schema VARCHAR2, object_name VARCHAR2, policy_name VARCHAR2 ) AS
BEGIN
DBMS_OUTPUT.PUT_LINE('Alert! Manager Changed !');
END;

E la politica può essere:

CREATE OR REPLACE PROCEDURE proc_audit_manager AS
BEGIN
DBMS_FGA.ADD_POLICY
(
object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager',
audit_column=>'ID_MANAGER',
enable=>false,
statement_types=>'UPDATE',
handler_module=>'proc_audit_alert'
);
DBMS_FGA.ENABLE_POLICY
( object_schema=>'ADMINDB',
object_name=>'DEPARTMENTS',
policy_name=>'proc_audit_manager');
END;

Nota che object_schema, object_name, policy_name, audit_column, statement_types e handler_module devono essere adattati alla policy che vuoi scrivere.

Quindi, eseguiamo la procedura:

EXECUTE proc_audit_manager;

Possiamo verificare se la politica è abilitata:

SELECT ENABLED, POLICY_NAME
FROM ALL_AUDIT_POLICIES
WHERE OBJECT_NAME='DEPARTMENTS';

Quindi, verifica se la procedura e la policy funzionano correttamente, eseguendo un aggiornamento:

UPDATE DEPARTMENTS
SET ID_MANAGER=2
WHERE ID_DEPARTAMENT=1;

In conclusione, l'auditing è necessario per ogni database e i metodi forniti sopra ti aiutano a trovare un'attività sospetta che potrebbe influire sulla sicurezza del tuo database. Per maggiori dettagli sull'audit del database Oracle, vedere la bibliografia di seguito.

Bibliografia:

  • http://www.datadisk.co.uk/html_docs/oracle/auditing.htm
  • http://docs.oracle.com/cd/B10501_01/server.920/a96521/audit.htm
  • https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000