Separazione per tabelle

Separare le tabelle sembra una buona idea, specialmente se puoi stimare l'importanza delle tabelle sulla tua sicurezza. Ad esempio, una tabella con nomi utente e password è piuttosto importante, mentre una tabella con commenti sul blog è meno importante. Se si dispone di un utente di database diverso per tali tabelle importanti, un'iniezione, ad esempio in una query che seleziona i commenti, potrebbe non ottenere un utente malintenzionato in quanto non è in grado di accedere ai dati rilevanti (il massimo che potrebbero fare è riflettere XSS).

Separare il blog e il sito Web sembra ragionevole (almeno dal punto di vista della progettazione di un sistema), ma darei a ciascuno di essi un database separato (in realtà non sembrano appartenere l'uno all'altro, quindi è logico senso, e sarebbe anche più facile da gestire).

Separazione per lettura / scrittura

Non sono sicuro che la separazione tra scrittura e lettura varrà la pena (quale sarebbe il filo reale contro cui difendersi? Penso soprattutto un attaccante che inietta un post sul blog), e sarà probabilmente difficile da far rispettare. Ad esempio se hai un utente amministratore che può modificare il database tramite un'interfaccia web:

• l'utente malintenzionato può leggere: l'autore dell'attacco può leggere la password dell'amministratore e quindi scrivere (tramite l'interfaccia web)
• l'utente malintenzionato può scrivere: l'utente malintenzionato può aggiungere la password dell'amministratore e quindi leggere (tramite l'interfaccia web)

Anche la gestione dei privilegi per prefisso tabella non sembra una buona idea. Considera questo (potrebbe essere un po 'inverosimile, ma è solo un esempio di come ignorare le tue regole):

• website_read ha diritti di selezione su website_*
• global_write ha diritti di scrittura su website_* e blog_*
• blog_read ha diritti di selezione su blog_*
• l'attaccante ha accesso a global_write e blog_read (ad es. tramite iniezione) e desidera leggere website_users (a cui non hanno i diritti)
• attacker rinomina la tabella website_users in blog_users con global_write [*] e la legge con blog_read .

_{[*] Se questo è effettivamente consentito dipenderà dal tuo sistema concreto, ma generalmente il nome è un'attività di scrittura. Ad esempio MySQL richiede ALTER, DROP, CREATE e INSERT che chiamerei scrivere diritti.}

Devi distinguere tra l'account utilizzato per connettersi al database e l'account dell'utente originale:

• l'account di servizio utilizzato per connettere l'applicazione al database dovrebbe essere usato per limitare l'accesso a quegli schemi e tabelle a cui si deve accedere. L'account del servizio dovrebbe concentrarsi su aspetti di sicurezza come la prevenzione di DROP o CREATE TABLE - quei tipi di azioni SQL che in genere non sono richieste in un'operazione quotidiana
• l'account dell'utente originale (o identità): non è pratico creare un account nel database per ogni utente che potenzialmente utilizzerebbe il database. Eppure vuoi ancora controllare l'accesso ai dati (attenzione, accesso ai dati stessi, non al database di per sé). A livello dell'utente, potremmo anche preoccuparci di controllare su quali celle / righe / tabelle specifiche un utente può fare azioni CRUD.

Prendiamo il tuo esempio di blog. Abbiamo un tavolo chiamato blog_post. Si desidera implementare la seguente logica di autorizzazione:

• tutti gli utenti autenticati possono visualizzare qualsiasi post del blog.
• un utente con il ruolo di approvazione può modificare lo stato di un post del blog dalla bozza

Ci sono molti modi per ottenerlo:

• configura un'autorizzazione dettagliata utilizzando gli strumenti del tuo database, ad es.
  • Oracle VPD (Virtual Private Database)
  • IBM DB2 RCAC (controllo dell'accesso a righe e colonne)
• configura un'autorizzazione dettagliata utilizzando un proxy di fronte ai tuoi database
  • IBM Guardium
  • Filtro di accesso ai dati Axiomatics MD (ADAF MD)

Ciò che ti consente di fare è

1. disaccoppia l'autorizzazione dal database stesso. Piuttosto che dover creare tabelle, ruoli e account utente artificiali, è possibile esprimere una logica a grana fine utilizzando gli strumenti disponibili in VPD, DB2 o Axiomatics.
2. Implementa il controllo degli accessi basato sugli attributi (come definito da NIST ) e la sicurezza incentrata sui dati.

L'approccio proxy consente anche la completa esternalizzazione della logica di controllo degli accessi.

Alcuni dei vantaggi includono:

• approccio non intrusivo: non è necessario modificare nulla nel database. Ciò renderà sicuramente il tuo sysdba felice
• riutilizzabile per altri livelli, ad es. il livello applicazione o anche il livello presentazione
• più facile da mantenere e controllare. ABAC utilizza attributi (coppie chiave-valore, ad esempio role == manager) e policy.

HTH