C'è un motivo per creare un utente di database senza privilegi di schema?

Question

C'è un motivo per creare un utente di database senza privilegi di schema?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Una delle cose comuni che si vedono nell'installazione di persone sono gli utenti del database (per l'uso da un'applicazione vera e propria) che dispongono solo delle autorizzazioni SELECT / UPDATE / INSERT / DELETE. Un utente separato (che ha in aggiunta CREATE / ALTER / DROP / etc) viene utilizzato per distribuire effettivamente gli aggiornamenti dello schema (un account amministratore o un utente dedicato a tale scopo).

Mi chiedo quale sia il motivo dietro questo.

Ci sono due situazioni che sto esaminando in modo specifico, sia in un ambiente di distribuzione continuo (quindi l'applicazione viene creata e distribuita automaticamente):

Un sistema di distribuzione separato esegue gli aggiornamenti dello schema durante la distribuzione dell'app stessa.
L'applicazione esegue i propri aggiornamenti dello schema all'avvio iniziale.

Lo scenario 2 è spesso necessario quando ci sono molti ambienti che vengono distribuiti su reti separate (ad esempio, i VPC di AWS separati).

Nel caso dello scenario 1, non è un grosso problema avere un account utente separato con i privilegi dello schema, ma nel caso di 2, lo è.

L'unica spiegazione logica che ho mai sentito è la frase di sbocco "meno privilegi sono migliori per la sicurezza". Non è che non sono d'accordo con questa affermazione, ma mi piacerebbe capire perché è meglio per la sicurezza.

Penso che questo si riduce alla domanda: se qualcuno compromette le credenziali ... cosa possono fare con i privilegi dello schema che non possono fare con solo SELECT / UPDATE / DELETE?

"Distruggi" il database? DELETE è perfettamente in grado di farlo. UPDATE / INSERT è probabilmente ancora più pericoloso in quanto un utente malintenzionato potrebbe modificare in modo subdolo i dati esistenti in un modo che non causerà un errore catastrofico evidente come cadere una tabella o eliminare tutte le righe
Estrai dati? SELEZIONA.
Modifica lo schema? Uh .. a che fine? Se fatto in un modo che rompe l'app, è ovvio, e in entrambi i casi, può essere rimosso dalla prossima distribuzione dell'app.

Mi manca qualcos'altro?

permissions attack-prevention databases

posta gregmac 18.02.2016 - 19:54

fonte

3 risposte

Leggi altre domande sui tag permissions attack-prevention databases

Perché il mio handshake TLS v1.2 richiede 2 connessioni tcp / ip? In che modo gli utenti privilegiati devono tenersi reciprocamente sotto controllo? [duplicare]

score 2 · Answer 1

Non sono sicuro che ciò sia sempre fatto per la sicurezza degli utenti esterni. Ad esempio, potresti avere un DBA che desidera che gli sviluppatori siano in grado di selezionare / aggiornare / eliminare record, ma non iniziare a eseguire le proprie modifiche allo schema. Quindi impostano un account per essere utilizzato dagli sviluppatori mantenendo gli account più potenti per se stessi.

Nel caso in cui un utente esterno ottenga l'accesso al tuo database tramite SQLi o qualcosa del genere, sono d'accordo sul fatto che possono devastare le operazioni di selezione / aggiornamento / cancellazione di base, ma ci sono altre cose che potrebbero fare se hanno la possibilità di dire drop tables. Ad esempio, se la pagina principale di un'applicazione esegue una query su una tabella specifica e tale tabella è stata eliminata, l'autore dell'attacco può essenzialmente impedire che il sito venga visualizzato. Concesso: se il tuo db è stato compromesso, probabilmente vorrai portare il sito offline, ma idealmente decidi tu quando succede e non chi attacca.

Potrebbe essere molto interessante, ma un utente malintenzionato potrebbe anche iniziare a rintracciare le informazioni che potrebbero trovare utili registrando le informazioni su una tabella che hanno creato utilizzando i trigger o qualcosa del genere. Se il database non riceve molta attenzione, questo potrebbe non essere notato e potrebbero controllare e utilizzare queste informazioni per attacchi più sofisticati.

Questi sono alcuni scenari specifici che vengono in mente. Non sono d'accordo con la tua affermazione che creare account con i privilegi minimi di cui hanno bisogno per funzionare è un "cop-out". A seconda di quanto creativo è un aggressore, sono sicuro che ci sono altri modi in cui potrebbero sfruttare questi privilegi extra ai loro nefandi fini. Inoltre non posso pensare a un motivo per dare agli account più potere del necessario.

score 1 · Answer 2

La possibilità di modificare lo schema è tra le più potenti che puoi ottenere in un database. Seleziona / Inserisci / Aggiorna / Elimina consente solo di modificare i dati. L'aggiornamento dello schema consente di modificare tutti gli oggetti. Questo include cose estremamente potenti come:

Modifica delle stored procedure
Aggiunta di trigger
(eventualmente) Modifica delle attività pianificate (a seconda di come è configurato il DB)

I primi due consentono l'accesso a livello di codice, che è molto più che semplicemente la possibilità di visualizzare i dati. Un utente malintenzionato potrebbe facilmente ottenere un controllo molto maggiore sulla tua applicazione con accesso a livello di codice.

In ogni caso, la possibilità di modificare lo schema è estremamente potente e non può essere ignorata. Inoltre, è sostanzialmente privo di costi perché poche applicazioni, se esistenti, necessitano di questo livello di accesso una volta che sono in esecuzione.

Se hai bisogno di questo livello di accesso per CI, ti suggerisco di progettare per lo scenario in cui è necessario un livello più alto di accesso per distribuire l'applicazione piuttosto che semplicemente eseguirlo.

score 0 · Answer 3

Spesso non è necessario fornire le autorizzazioni DELETE. A seconda dell'applicazione, probabilmente troverai che la maggior parte delle tabelle non otterrà mai un DELETE (in particolare traccia di controllo e transazioni finanziarie). Probabilmente c'è un altro sottoinsieme di tabelle che non ha bisogno di UPDATE, dove è possibile limitare gli aggiornamenti a un sottoinsieme di colonne. Puoi anche avere alcune tabelle nello stesso schema totalmente non disponibili per un'applicazione, ma mantenibili da un'applicazione separata che potrebbe avere un accesso più sicuro (ad es. VPN ad una intranet aziendale).

Alcuni DBMS hanno capacità di limitare o controllare attività eccezionali anche dal proprietario della tabella, ma la separazione tramite i diritti di accesso è praticamente universale.