Quale DBMS è appropriato per mantenere uno schema privato anche se installato 'in the wild'

StackOverflow https://stackoverflow.com/questions/654758

Domanda

Ho un server delle applicazioni che si collega a un server di database. Vorrei essere in grado di fornire agli utenti installatori e, con un moderato livello di comfort, confido che lo schema del database sia sicuro.

Comprendo che ci sono alcuni rischi che dovrò semplicemente accettare per non controllare il computer su cui è installato: una persona determinata con gli strumenti e le conoscenze giuste potrebbe guardare direttamente la memoria ed estrarre informazioni.

Inizialmente pensavo che la mia area di interesse fosse semplicemente quella di aggiungere le credenziali all'installer senza che fossero banalmente visualizzate in un editor esadecimale.

Tuttavia, quando ho iniziato a ricercare, ho imparato che per PostGreSQL, anche se installo il database in silenzio e non fornisco le credenziali all'utente, possono semplicemente modificare un file di configurazione basato su testo (pg_hba.conf ) e riavviare il server, consentendo l'accesso completo al database senza credenziali.

Questo scenario è protetto in altri DBMS? In che modo la maggior parte dei prodotti commerciali protegge i propri schemi in questo scenario? La maggior parte dei prodotti utilizzerà database incorporati?

Modifica: presumo (forse a torto) che alcuni prodotti si basano su database che l'utente non tocca mai direttamente. E ovviamente non li vedo mai perché l'hanno progettato in modo che l'utente non ne abbia bisogno, probabilmente usando un database incorporato.

È stato utile?

Soluzione

La maggior parte dei prodotti commerciali non protegge i loro schemi. Cadono in uno dei due campi:

O stanno facendo uso di un database di classe enterprise per un componente chiave del prodotto (come un sistema di gestione stipendi), nel qual caso non si tenta di nascondere lo schema / i dati. Nella maggior parte di questi casi, il cliente deve comunque controllare il database: per configurare il modo in cui viene eseguito il backup del database, per poter creare un ambiente cluster, ecc.

L'altro caso è se il tuo " database " non è altro che un piccolo file di impostazioni o di archiviazione per un'applicazione desktop (ad es. database di cronologia e segnalibri in FireFox). In tal caso dovresti semplicemente utilizzare un database incorporato (come SQLite, come FireFox) e aggiungere un livello di crittografia in streaming (esiste una versione ufficiale di questo chiamato SEE), oppure utilizzare semplicemente il database incorporato e dimenticare il livello di crittografia, poiché l'utente dovrà installare i propri strumenti di database per leggere il file in primo luogo.

Altri suggerimenti

Per quanto ricordo, non ci sono prodotti commerciali che "proteggono" i loro schemi. Da cosa vuoi proteggere lo schema?

Considera i seguenti punti:

  • Dopotutto, l'unica persona che può proteggere qualsiasi cosa in un RDBMS è l'amministratore del server di database. E vuoi che lo schema sia protetto da questa persona?

  • Se fossi un cliente e avessi i miei dati all'interno del tuo schema, non solo mi piacerebbe, ma mi aspetto, di poterlo vedere e consumare direttamente.

  • Hai davvero bisogno di proteggere il tuo design relazionale? È davvero così interessante? Hai inventato qualcosa che vale la pena nascondere? Davvero non la penso così. E mi scuso in anticipo se lo hai fatto.

EDIT: commento aggiuntivo:

Non mi interessa la maggior parte degli interni del database per i prodotti che utilizzo. Questa è un'altra ragione per cui penso che la maggior parte di loro non intervenga per proteggerli. Molti di loro non sono così interessanti.

Da un lato, sono fermamente convinto che gli utenti non debbano conoscere o preoccuparsi degli interni del database. Ma allo stesso livello, come sviluppatore, non credo valga la pena provare a proteggerli. Nascondendoli all'utente, sì. Proteggili dall'accesso diretto, nella maggior parte dei casi, no. E non perché penso che sia sbagliato proteggere il tuo schema. È perché penso che sia una cosa molto difficile da fare, e non merita il tuo tempo come sviluppatore.

Ma alla fine, come per qualsiasi argomento relativo alla sicurezza, l'unica risposta corretta è quali sono i rischi coinvolti rispetto ai costi dell'implementazione della misura di sicurezza.

I motori di database attuali, incorporati o in stile server, non sono progettati per nascondere facilmente lo schema del database e, pertanto, il costo di sviluppo di farlo è molto più elevato del rischio coinvolto, per la maggior parte delle persone.

Ma il tuo caso potrebbe essere diverso.

Quale problema stai cercando di risolvere? Nulla può impedire a DBA * di fare tutto ciò che desidera su database standard e, come altri hanno sottolineato, è attivamente ostile interferire con esigenze specifiche del sito come backup e aggiornamenti del database. Al massimo puoi crittografare il contenuto del tuo database, ma anche in questo caso devi fornire una chiave di decrittazione per la tua applicazione per essere effettivamente eseguita e un DBA motivato e ostile può probabilmente sovvertirlo.

Le comunità militari e di intelligence hanno indubbiamente basi di dati in cui anche lo schema è altamente classificato, ma non so se siano protetti con mezzi tecnici o solo grandi uomini con le pistole.

(*) DBA o amministratore di sistema in grado di modificare file come pg_hba.conf.

  

Come funzionano la maggior parte dei prodotti commerciali   proteggere i loro schemi in questo   scenario?

Non credo che la maggior parte dei prodotti commerciali faccia qualcosa per proteggere i loro schemi.

In che modo un DBMS incorporato può impedire a qualcuno di armeggiare con la sua memoria (file in questo contesto hardware non incorporato) quando tale persona ha accesso fisico alla macchina su cui è in esecuzione questo DBMS? La sicurezza attraverso l'oscurità è una proposta rischiosa.

Questa idea soffrirà degli stessi problemi del DRM. Non puoi impedire l'accesso da parte di determinati e causerai solo dolori e sofferenze generali ai tuoi clienti. Basta non farlo.

SQLite racchiude il suo intero formato di database in un singolo file e potreste concepirlo e decodificarlo sul posto. Il difetto, ovviamente, è che gli utenti hanno bisogno della chiave per usare subito il database, e l'unico modo che può accadere è se lo dai a loro, forse codificandolo in tempo reale durante la compilazione (sicurezza per oscurità) o uno schema telefonico-casa (tutta una serie di ragioni per cui questa è una cattiva idea). Inoltre ora ti odieranno perché hai contrastato ogni tentativo di un utile sistema di backup e hanno prestazioni terribili da avviare.

Inoltre, a nessuno importa davvero degli schemi. Odio fartelo sfuggire, ma la progettazione dello schema non è un problema difficile e certamente non è mai un legittimo vantaggio competitivo (al di fuori di forse alcune aree specifiche come la rappresentazione della conoscenza e il data warehousing). Gli schemi in genere non meritano di essere protetti in primo luogo.

Se è davvero così importante per te, fai invece un'applicazione ospitata.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top