Data Warehousing - Sicurezza

L'obiettivo di un data warehouse è quello di rendere facilmente accessibili grandi quantità di dati agli utenti, consentendo così agli utenti di estrarre informazioni sull'azienda nel suo complesso. Ma sappiamo che potrebbero essere applicate alcune restrizioni di sicurezza sui dati che possono essere un ostacolo per l'accesso alle informazioni. Se l'analista ha una visione limitata dei dati, è impossibile acquisire un quadro completo delle tendenze all'interno dell'azienda.

I dati di ogni analista possono essere riepilogati e trasmessi alla direzione dove è possibile aggregare i diversi riepiloghi. Poiché le aggregazioni dei riepiloghi non possono essere uguali a quelle dell'aggregazione nel suo insieme, è possibile perdere alcune tendenze delle informazioni nei dati a meno che qualcuno non stia analizzando i dati nel loro insieme.

Requisiti di sicurezza

L'aggiunta di funzionalità di sicurezza influisce sulle prestazioni del data warehouse, pertanto è importante determinare i requisiti di sicurezza il prima possibile. È difficile aggiungere funzionalità di sicurezza dopo che il data warehouse è stato attivato.

Durante la fase di progettazione del data warehouse, dobbiamo tenere presente quali origini dati possono essere aggiunte in seguito e quale sarebbe l'impatto dell'aggiunta di tali origini dati. Dovremmo considerare le seguenti possibilità durante la fase di progettazione.

  • Se le nuove origini dati richiederanno l'implementazione di nuove restrizioni di sicurezza e / o controllo?

  • Se i nuovi utenti aggiunti che hanno accesso limitato ai dati che sono già generalmente disponibili?

Questa situazione si verifica quando i futuri utenti e le fonti di dati non sono ben noti. In una situazione del genere, dobbiamo utilizzare la conoscenza del business e l'obiettivo del data warehouse per conoscere i requisiti probabili.

Le seguenti attività sono influenzate dalle misure di sicurezza:

  • Accesso utente
  • Caricamento dei dati
  • Spostamento dei dati
  • Generazione di query

Accesso utente

Dobbiamo prima classificare i dati e poi classificare gli utenti sulla base dei dati a cui possono accedere. In altre parole, gli utenti vengono classificati in base ai dati a cui possono accedere.

Data Classification

I seguenti due approcci possono essere utilizzati per classificare i dati:

  • I dati possono essere classificati in base alla loro sensibilità. I dati altamente sensibili sono classificati come altamente limitati e i dati meno sensibili sono classificati come meno restrittivi.

  • I dati possono anche essere classificati in base alla funzione lavorativa. Questa restrizione consente solo a utenti specifici di visualizzare dati particolari. Qui limitiamo gli utenti a visualizzare solo quella parte dei dati a cui sono interessati e di cui sono responsabili.

Ci sono alcuni problemi nel secondo approccio. Per capire, facciamo un esempio. Supponiamo che tu stia costruendo il data warehouse per una banca. Considera che i dati archiviati nel data warehouse sono i dati delle transazioni per tutti gli account. La domanda qui è: chi può vedere i dati della transazione. La soluzione sta nel classificare i dati in base alla funzione.

User classification

I seguenti approcci possono essere utilizzati per classificare gli utenti:

  • Gli utenti possono essere classificati in base alla gerarchia degli utenti in un'organizzazione, ovvero gli utenti possono essere classificati per reparti, sezioni, gruppi e così via.

  • Gli utenti possono anche essere classificati in base al loro ruolo, con le persone raggruppate nei reparti in base al loro ruolo.

Classification on basis of Department

Facciamo un esempio di un data warehouse in cui gli utenti provengono dal reparto vendite e marketing. Possiamo avere la sicurezza dalla vista aziendale dall'alto verso il basso, con l'accesso centrato sui diversi reparti. Ma potrebbero esserci alcune restrizioni per gli utenti a diversi livelli. Questa struttura è mostrata nel diagramma seguente.

Ma se ogni reparto accede a dati diversi, dovremmo progettare l'accesso di sicurezza per ogni reparto separatamente. Ciò può essere ottenuto dai data mart dipartimentali. Poiché questi data mart sono separati dal data warehouse, possiamo applicare restrizioni di sicurezza separate su ogni data mart. Questo approccio è mostrato nella figura seguente.

Classification Based on Role

Se i dati sono generalmente disponibili per tutti i reparti, è utile seguire la gerarchia di accesso dei ruoli. In altre parole, se i dati sono generalmente accessibili da tutti i reparti, applicare le restrizioni di sicurezza in base al ruolo dell'utente. La gerarchia di accesso al ruolo è mostrata nella figura seguente.

Requisiti di audit

L'auditing è un sottoinsieme della sicurezza, un'attività costosa. L'auditing può causare pesanti sovraccarichi al sistema. Per completare un audit in tempo, abbiamo bisogno di più hardware e, pertanto, si consiglia, ove possibile, di disattivare l'audit. I requisiti di audit possono essere classificati come segue:

  • Connections
  • Disconnections
  • Accesso ai dati
  • Modifica dei dati

Note- Per ciascuna delle suddette categorie, è necessario verificare il successo, il fallimento o entrambi. Dal punto di vista dei motivi di sicurezza, il controllo dei guasti è molto importante. Il controllo dei guasti è importante perché possono evidenziare accessi non autorizzati o fraudolenti.

Requisiti di rete

La sicurezza della rete è importante quanto gli altri titoli. Non possiamo ignorare i requisiti di sicurezza della rete. Dobbiamo considerare i seguenti problemi:

  • È necessario crittografare i dati prima di trasferirli al data warehouse?

  • Ci sono restrizioni su quali percorsi di rete possono prendere i dati?

Queste restrizioni devono essere considerate attentamente. Di seguito sono riportati i punti da ricordare:

  • Il processo di crittografia e decrittografia aumenterà i costi generali. Richiederebbe più potenza di elaborazione e tempo di elaborazione.

  • Il costo della crittografia può essere elevato se il sistema è già un sistema caricato poiché la crittografia è a carico del sistema di origine.

Spostamento dei dati

Esistono potenziali implicazioni per la sicurezza durante lo spostamento dei dati. Supponiamo di dover trasferire alcuni dati limitati come file flat da caricare. Quando i dati vengono caricati nel data warehouse, vengono sollevate le seguenti domande:

  • Dove viene archiviato il file flat?
  • Chi ha accesso a quello spazio su disco?

Se parliamo del backup di questi file flat, vengono sollevate le seguenti domande:

  • Esegui il backup delle versioni crittografate o decrittografate?
  • È necessario eseguire questi backup su nastri speciali archiviati separatamente?
  • Chi ha accesso a questi nastri?

È necessario considerare anche alcune altre forme di spostamento dei dati come i set di risultati delle query. Le domande sollevate durante la creazione della tabella temporanea sono le seguenti:

  • Dove si terrà quel tavolo temporaneo?
  • Come si rende visibile questo tavolo?

Dobbiamo evitare la violazione accidentale delle restrizioni di sicurezza. Se un utente con accesso ai dati limitati può generare tabelle temporanee accessibili, i dati possono essere visibili agli utenti non autorizzati. Possiamo superare questo problema disponendo di un'area temporanea separata per gli utenti con accesso a dati limitati.

Documentazione

I requisiti di controllo e sicurezza devono essere adeguatamente documentati. Questo sarà trattato come una parte della giustificazione. Questo documento può contenere tutte le informazioni raccolte da:

  • Classificazione dei dati
  • Classificazione degli utenti
  • Requisiti di rete
  • Requisiti per lo spostamento e l'archiviazione dei dati
  • Tutte le azioni verificabili

Impatto della sicurezza sul design

La sicurezza influisce sul codice dell'applicazione e sui tempi di sviluppo. La sicurezza influisce sulla seguente area:

  • Sviluppo di applicazioni
  • Progettazione di database
  • Testing

Sviluppo di applicazioni

La sicurezza influisce sullo sviluppo generale dell'applicazione e influisce anche sulla progettazione dei componenti importanti del data warehouse, come il gestore del carico, il gestore del magazzino e il gestore delle query. Il gestore del carico potrebbe richiedere il controllo del codice per filtrare i record e posizionarli in posizioni diverse. Potrebbero essere necessarie ulteriori regole di trasformazione per nascondere determinati dati. Inoltre potrebbero essere necessari metadati aggiuntivi per gestire eventuali oggetti aggiuntivi.

Per creare e mantenere viste aggiuntive, il responsabile del magazzino potrebbe richiedere codici aggiuntivi per rafforzare la sicurezza. Potrebbe essere necessario codificare controlli aggiuntivi nel data warehouse per evitare che venga indotto a spostare i dati in una posizione in cui non dovrebbero essere disponibili. Il gestore delle query richiede le modifiche per gestire eventuali restrizioni di accesso. Il gestore delle query dovrà essere a conoscenza di tutte le visualizzazioni e aggregazioni aggiuntive.

Progettazione di database

Anche il layout del database viene influenzato perché quando vengono implementate le misure di sicurezza, si verifica un aumento del numero di visualizzazioni e tabelle. L'aggiunta di sicurezza aumenta le dimensioni del database e quindi aumenta la complessità della progettazione e della gestione del database. Aggiungerà inoltre complessità alla gestione del backup e al piano di ripristino.

Test

Il test del data warehouse è un processo lungo e complesso. L'aggiunta di sicurezza al data warehouse influisce anche sulla complessità del tempo di test. Influisce sul test nei due modi seguenti:

  • Aumenterà il tempo necessario per l'integrazione e il test del sistema.

  • Sono presenti funzionalità aggiuntive da testare che aumenteranno le dimensioni della suite di test.