La separazione dei dati da diverse applicazioni tramite gli schemi Oracle è considerata sicura?

Question

La separazione dei dati da diverse applicazioni tramite gli schemi Oracle è considerata sicura?

#1 da (2 voti)
#2 da (1 voti)

6

Sto valutando i pro e i contro di avere diversi schemi Oracle rispetto a server Oracle separati. Avere un server dedicato per ogni applicazione è molto costoso e voglio solo tenerlo presente se ne valgono i benefici per la sicurezza.

Uno dei principali punti critici è l'argomento dell'iniezione SQL. Nel caso in cui l'applicazione A abbia un'iniezione SQL che compromette tutti i dati nello schema A nel database Oracle, sarebbe possibile che un utente malintenzionato acceda ai dati nello schema B (nello stesso database Oracle)?

Mi sto appoggiando all'opinione che la separazione tramite schemi sia sufficiente tranne che per i più critici degli archivi di dati. È questa la migliore pratica e quali sono i principali fattori da considerare?

sql-injection oracle

posta Demento 12.01.2015 - 17:10

fonte

2 risposte

1

Nello scenario che hai descritto, se lo Schema A è stato compromesso, che ha escluso qualche vulnerabilità sconosciuta con Oracle stesso - avrebbe solo accesso ai dati dallo Schema B nella misura in cui i privilegi di B era stato condiviso con A.

Nel caso in cui questo non sia chiaro, supponiamo di avere TABLE1 e TABLE2 nello schema B. Ora si assume che si esegua il seguente comando nello schema B:

GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA_B.TABLE1 TO SCHEMA_A;

Quindi, se lo schema A è compromesso, TABLE1 è a rischio, ma TABLE2 dovrebbe essere sicuro.

E se invece esegui quanto segue nello schema B:

GRANT SELECT ON SCHEMA_B.TABLE1 TO SCHEMA_A;

Quindi il tuo rischio è ridotto (ma non eliminato): il malvagio che ha penetrato lo schema A potrebbe vedere i dati per TABLE1 (che potrebbe essere ancora molto brutto, a seconda di cosa c'è) - ma non dovrebbe essere in grado di modificare i dati .

Ora torniamo al punto in cui ho scritto in corsivo: (" blocco di alcune vulnerabilità sconosciute con Oracle stesso "): un lotto delle vulnerabilità che hanno causato un enorme dolore iniziato come vulnerabilità sconosciute con applicazioni specifiche. Se hai il lusso di separare i server (tenendo conto delle spese del server, dei tempi e delle spese di manutenzione, delle esigenze attuali e future di condividere i dati direttamente), più isolamento dai tuoi dati, più sicuro è.

risposta data 13.01.2015 - 15:55

fonte

Leggi altre domande sui tag sql-injection oracle

Sicurezza di LXC rispetto a OpenVZ Quali sono i rischi di accettare il parametro URL per il reindirizzamento automatico?

score 2 · Accepted Answer

È un concetto comune creare specifico Database- Utenti per ciascuna applicazione . Questi utenti dovrebbero avere i privilegi minimi necessari per fare il loro lavoro.

Consente di applicare questo al tuo esempio:

ApplicationA utilizza DataBaseUserA che ha i privilegi di lettura / inserimento / aggiornamento / eliminazione tabellaA in SchemaA.
L'applicazione B utilizza DataBaseUserB che ha i privilegi per leggere la tabella B nello schemaB.
Naturalmente hai anche almeno un account DBA.

Ora considera ApplicationB vulnerabile a SQL-injection:

select * from SchemaA.TableA viene iniettato ed eseguito da DataBaseUserB.
La risposta DataBase potrebbe essere ORA-00942: tabella o vista non esiste

Nella maggior parte dei casi d'uso, considererei questo comportamento abbastanza sicuro. Naturalmente un'istanza DataBase completamente diversa potrebbe aggiungere un altro livello di sicurezza in caso di problemi di sicurezza sconosciuti nel DB Oracle.