Come proteggere un database dall'amministratore del server in Sql Server

Question

Abbiamo un requisito da parte di un cliente per proteggere il database utilizzato dalla nostra applicazione, anche dai loro amministratori locali (i revisori hanno dato loro quel requisito).

Nel loro requisito, proteggere i dati significa che l'amministratore del server Sql non può leggere, né modificare i dati sensibili memorizzati nelle tabelle.

Potremmo farlo con la crittografia in SQL Server 2005, ma che potrebbero interferire con il nostro ORM di terze parti, e ha altri svantaggi, come l'indicizzazione, ecc

in SQL Server 2008 potremmo utilizzare TDE, ma Comprendo che questa soluzione non protegge da un utente con diritti di amministratore di Sql Server per interrogare il database.

Esiste una soluzione migliore o una soluzione nota a questo problema?

Questo problema potrebbe essere simile a quello di avere un'applicazione ospitata da un provider host e si desidera proteggere i dati dagli amministratori dell'host.

Possiamo usare SQL Server 2005 o 2008.

Answer 1

questo è stato chiesto molto nell'ultimo fewweeks. Le risposte di solito si riducono a:

(

a) Se non si controlla l'applicazione si sono condannati ad avere fiducia il DBA

o

b) Se fate controllare l'applicazione è possibile crittografare tutto con una chiave nota solo all'applicazione e decrittografare all'uscita. Ciò penalizzerà le prestazioni un po '(o molto), ma è per questo che esiste TDE. Una variante di questo per impedire la manomissione consiste nell'utilizzare un hash crittografico dei valori nella colonna, controllandoli all'accesso dell'applicazione.

)

e

c) fare approfondite di controllo, in modo da poter controllare quali sono i tuoi amministratori che fanno.

Answer 2

Se non si desidera che nessuna persona nel gruppo admin sul server sia in grado di accedere al database, rimuovere l'utente "BUILTIN \ Administrators" sul server.

Tuttavia, assicurarsi di avere un altro utente che è un amministratore di sistema sul server!

Answer 3

un altro modo in cui ho sentito dire che un'azienda ha implementato ma non l'ho visto: c'è un ente governativo che emette un tipo di certificato con data e ora. ogni modifica db viene inviata alla coda asincrona e viene timestampata con questo certificato e viene archiviata fuori dal sito. in questo modo nessuno può cancellare nulla senza interrompere la catena timestamp.

Non so come funzioni esattamente a un livello più profondo.

Answer 4

Penso che la soluzione giusta sarebbe consentire solo alle persone fidate di essere DBA. È implicito essere DBA, che hai pieno accesso, quindi, a mio parere, il tuo auditor dovrebbe chiedere di avere procedure per limitare chi ha accesso DBA. In questo modo si lavora con il sistema attraverso i processi invece di lavorare con il sistema (es. SQL Server). Per avere una persona di cui non ti fidi, DBA sarebbe impazzito ...

Answer 5

Potrei avere informazioni sui salari nelle mie tabelle e non voglio che i miei dba di fiducia vengano visualizzati. Di fronte allo stesso problema che abbiamo ristretto sono le opzioni a:

1- Criptare fuori SQLServer, prima di inserire e aggiornare e decodificare dopo aver selezionato. vale a dire: utilizzando la crittografia .net. Lato negativo: si perdono alcune funzionalità di indicizzazione e ricerca, non è possibile utilizzare come e intermediari.

2- Utilizzare strumenti di terze parti (a livello di io) che blocchino il database fino a quando non viene fornita una password. vale a dire: www.Blockkk.com Lato negativo: è necessario fidarsi di uno strumento di terze parti installato nel proprio server. Potrebbe non tenere il passo con le patch di SQL Server, ecc ...

3- Utilizzare una soluzione di controllo che tenga traccia di selezioni, inserimenti, eliminazioni, ecc. E notificherà (tramite e-mail o registro eventi) se si sono verificate violazioni Una violazione di esempio potrebbe essere un dba che esegue una selezione sulla tabella degli stipendi. quindi licenzia il dba e cambia tutti i salari.

Answer 6

I revisori chiedono sempre questo, come chiedono altre cose che non possono mai essere fatte.

Quello che devi fare è metterlo in termini di mitigazione del rischio e mostrare quali controlli hai (monitoraggio quando gli utenti sono elevati agli amministratori, cosa hanno fatto e che sono stati disattivati ​​in seguito) anziché in assoluti.

Una volta un capo chiedeva la ridondanza totale del sistema senza definire cosa intendesse o quanto fosse disposto a pagare e sacrificare.