La società dovrebbe proteggere lo schema DB allo stesso livello dei dati stessi?

@ John-Wu's è la risposta giusta, non si dovrebbe fare investimento per dare priorità alla protezione dello schema al di sopra della protezione dei dati.

I dati sono più importanti e rappresentano un obiettivo di compromesso per gli aggressori. Lo schema è nella migliore delle ipotesi una perdita di informazioni.

Detto questo, i database stessi di solito trattano i metadati dello schema a un livello di privilegio diverso e più elevato rispetto ai dati, non senza ragione. Come dice @ marcus-muller, lo schema fornisce agli aggressori suggerimenti utili. E un utente con privilegi di vedere lo schema può quasi sempre vedere i dati, mentre gli utenti con privilegi per vedere i dati potrebbero non essere in grado di vedere lo schema.

Quindi lo schema non dovrebbe essere considerato non necessario da proteggere. Ma i dati sono più importanti.

No

La protezione dello schema del database è un tipo di sicurezza per oscurità .

Il tuo software dovrebbe essere progettato e configurato in modo tale che nessuna sicurezza venga compromessa quando un hacker ne apprende la progettazione. Infatti, nel migliore dei casi il tuo design è reso pubblico in modo che i professionisti della sicurezza possano criticarlo e puoi migliorarlo continuamente.

Anche se sono d'accordo con la risposta di @ JohnWu che Security By Obscurity è un concetto sbagliato, c'è una cosa:

Sì. In un certo senso.

Gli schemi di database complessi in genere hanno relazioni complesse. Ma lasciatemi fare un semplice esempio:

Hai una tabella

+----+------------+-------+
| ID | CustomerNo | Order |
+----+------------+-------+
|  0 |          1 |  Nuts |
|  1 |          1 | Bolts |
|  2 |          2 |  Nuts |
|  3 |          1 |  Wire |
+----+------------+-------+

Dove ID è una chiave primaria che aumenta automaticamente, CustomerNo fa riferimento alla chiave primaria della tabella dei clienti e Order fa riferimento alla chiave primaria della tabella degli ordini. In questo modo, esegui il mapping degli ordini ai clienti.

Tu, naturalmente, permetti solo a ciascun cliente di vedere le righe che "appartengono" a se stesse.

Ancora, vedi il problema?

Esattamente, attraverso il campo ID lineare in aumento, il cliente 1 ha un modo semplice di capire quando la concorrenza fa i suoi ordini, semplicemente non agendo come un cliente "normale", ordinando gli ordini in massa, ma ordinando automaticamente ogni ordine minuto.

In questo modo, scoprono che ogni martedì pomeriggio alle 16:30, gli ordini della competizione. Ora, conoscendo molto bene il mercato dell'hardware, martedì 4:20 pm hanno messo sul mercato una grande opzione di vendita, aumentando così il prezzo di mercato delle noci, danneggiando il loro concorrente, e anche approfittando finanziariamente delle conoscenze che non avrebbero mai dovuto ottenere il primo posto.

Questa è una questione di dati pulizia , in linea di principio. Una chiave primaria monotona fornisce informazioni (parziali) che non dovresti avere. Quindi, l'API del cliente dovrebbe assicurarsi che la perdita di informazioni sia zero. E io intendo matematicamente : l'informazione ha una pseudo-unità, un po ', e c'è un'intera disciplina matematica chiamata teoria dell'informazione , che descrive quanta informazione c'è nell'osservazione di un certo evento basato sulla casualità (ad esempio, se ci sono più di due clienti in quella tabella, non puoi sapere quale dei tuoi concorrenti ha fatto l'ordine alle 4:30 del pomeriggio, ma ottieni ancora probabilità da questo, e quindi, non- zero informazioni).

È molto improbabile che tu possa nascondere tali informazioni ai tuoi clienti se hanno accesso allo schema del database. In realtà, questo schema non li aiuta senza che tu gli dessi informazioni che probabilmente non dovrebbero ottenere. In questo senso, beh, il tuo schema non ha bisogno di essere segreto, ma alcuni dei dati che probabilmente consideri ancora "relazionali" all'interno dei record accessibili di un cliente dovrebbero, in realtà, essere segreti dal cliente.