Arda Solutions s.r.l. | The Informal Blog

oracle_database_vault

Nella moderna amministrazione digitale, con particolare attenzione sia a compagnie che trattano dati personali  che ad amministrazioni pubbliche , un posto importante trovano i temi di sicurezza dei dati non solo verso l’esterno ( ad esempio accessi non autorizzati e SQL Injection ) ma soprattutto verso l’interno, preservando l’integrità dei dati e la segretezza dall’errore umano e infedeltà dei propri dipendenti. A tal proposito trovano posto strategie di auditing , criptazione del dato , delle connessioni e il concetto di separation of duties altrimenti detto “separazione dei compiti”. Mentre le prime due  possono essere orientate nei confronti dell’intero popolo di utenti di database il terzo è rivolto a figure quali amministratori di sistema e Database Administrator : con ” separation of duties ” ( d’ora in avanti SoD )  ci si riferisce a quel principio che intende separare letteralmente i privilegi di alto profilo distribuendoli su persone diverse.

In Oracle, nella configurazione di default, esistono almeno due utenti con la capacità di controllo totale dell’istanza , con poche differenze : SYS e SYSTEM . Questo approccio viene stravolto implementando una opzione, a pagamento, della Enterprise Edition dal nome evocativo : Oracle Vault ( Vault = cassaforte, caveau ) . Innanzitutto, riprendendo il concetto di SoD, vengono creati nuovi utenti e nuovi ruoli tra i quali viene scorporato il ruolo DBA : questo perchè un superutente non deve avere accesso contemporaneamente a tutti gli elementi dell’istanza. Ad esempio, se un Application DBA avesse  necessità di accedere senza limitazioni  a oggetti di uno o piu’ schema, anche in ambiente business, non dovrebbe contemporaneamente poter modificare le impostazioni delle tabelle di audit, pena la possibilità di  modificare i dati a proprio piacimento. Un altro esempio possiamo trovarlo lì dove non sia necessario che un DBA sistemistico possa vedere i dati degli utenti : immaginiamo lo scenario di un amministratore di sistema in campo sanitario.

L’implementazione delle logiche di gestione appena descrittie  si ottiene  configurando alcuni aspetti di Oracle Vault, imparando a comprenderne la nuova semantica introdotta :

REALMS : Unità logica di oggetti. Un REALMS ( o reame ) è una zona atomica composta da diverse entità alle quali si vuole accedere o alle quali si vuole impedire l’accesso o la modifica.

COMMAND RULES: Gruppo di statement che si intende gestire sia DDL, DML  o anche ALTER SYSTEM .

FACTORS : Una qualsiasi variabile che possa definire se concedere o no una grant. Puo’ essere un IP di provenienza, uno user, una applicazione.

SECURE APPLICATION ROLES (S.A.R): Sono dei ruoli speciali creati da ORacle Vault che identificano specifiche necessità di sicurezza

RULE SETS: Lì dove i REALMS, le COMMAND RULES, i FACTORS e i S.A.R. sono parole , i RULE SETS costituiscono le frasi e la ragion d’essere stessa di ORacle Vault. In pratica sono espressioni con le quali si associano dei COMMAND RULES o dei S.A.R , all’interno di un REALMS  a patto che si rispettino delle condizioni che possono essere espresse anche mediante i Factors .

Nel prossimo post, proveremo a installare Oracle Database Vault e daremo una panoramica generale dell’interfaccia usata per amministrarlo.

Leave a Reply