Qual è una buona confutazione per gli utenti che desiderano crittografare tutti i dati WITHIN Db?

I am building an application in VB.NET (WinForms) utilizing SQL Server 2008 R2 as a Backend.

*Edit:*The information is to be encrypted so DBA's cannot see it, even if they have access to it.

Bene, questo riduce le cose - supponendo che i DBA abbiano pieno accesso alle comunicazioni che entrano ed escono dal server del database, questo indica che per soddisfare il requisito, la crittografia deve essere fatta prima dell'arrivo dei dati nel database, e la decrittografia deve essere eseguita dopo la partenza dal database.

Pertanto, possiamo considerare quanto segue:

• Alcune applicazioni o livelli middleware devono gestire la crittografia e la decrittografia.
  • Parla con i DBA! Guarda cosa ne pensano loro .
    • Se sono d'accordo con te che è una cattiva idea, quindi collabora con loro per comunicare i tuoi problemi condivisi alla gestione.
  • Si noti che la crittografia non impedisce agli indici di essere utili per ricerche su un'uguaglianza - un indice di database è altrettanto utile per cercare "Bob" o "1 gen 2010" come per cercare "51hsnGL58Uz" o " n8DfUp9vvJJECT". Sono le operazioni di disuguaglianza che si trasformano in:
    • Impossibile farlo in modo efficace / efficiente
    • Genera un elenco di tutte le opzioni nell'intervallo / disuguaglianza, crittografa ciascuna di esse e quindi esegui un'operazione di uguaglianza utilizzando gli indici.
    • Scarica l'intero set di dati nell'app (esegui il caching se c'è abbastanza RAM disponibile), decrittalo, memorizzalo tutto se hai la RAM, quindi esegui l'operazione localmente.
    • Hanno tabelle / dimensioni di dati aggregati che l'applicazione mantiene aggiornati "abbastanza spesso" per quel tipo di query / rapporti basati su intervallo (data).
• Se possibile, aiuta i DBA a creare una dimostrazione di concetto - e intendo davvero aiutarli.
  • Lavorate anche insieme per caricarlo con la quantità "atteso" di dati che vedrete tra 2-3 anni e poi lavorate insieme per eseguire test di stress delle prestazioni.
    
    • O hai ragione, e non gestirà il carico (in modo simile), o ti sbagli e non hai nulla di cui preoccuparti.
• Sii chiaro sui limiti dei dati completamente crittografati a cui non ti è permesso di vedere posto sull'azienda.
• Sii chiaro sui limiti dei dati completamente crittografati a cui non è consentito vedere il posto negli amministratori di database per il business (ad esempio, non c'è più aiuto da parte loro nella risoluzione di problemi, nella ricerca di dati errati o nella correzione di dati non corretti).
• Sii chiaro sui costi aggiuntivi, sul tempo aggiunto per il progetto e sui rischi aggiunti, inclusi ma non limitati al ripristino di emergenza, al ripristino dei backup, alla modifica delle chiavi di crittografia quando vengono filtrati / al DBA / ai requisiti che cambiano / a chi averli non è più impiegato, ecc.
  • La crittografia eseguita correttamente significa che se le chiavi sono perse / danneggiate e non sottoposte a backup, i tuoi dati non sono più disponibili. Questo significa che la gestione delle chiavi è un grosso problema.

Puoi e dovresti chiedere informazioni sull'azienda:

• Gli obiettivi di business che questo requisito è destinato a soddisfare (vale a dire il modello di minaccia @ColinCassidy menzionato).
• In che modo tali obiettivi interagiscono con altri obiettivi aziendali che potrebbero influire, come ad esempio le prestazioni, ovvero la priorità e le risorse.
• Requisiti legali, conformità normativa, requisiti di controllo o standard di settore che potrebbero essere alla base di questo.
  • Se ce ne sono, chiedi riferimenti ai requisiti originali - leggi attentamente, perché sono importanti.
• Come lo sviluppatore può essere in grado di vedere i dati decrittografati, come avrai le chiavi, o non avrai le chiavi e non sarai in grado di investigare in modo efficace su possibili dati non validi in produzione.
  • vale a dire. "Perché il fondo di Bill ha $ 520,15 in esso? È sbagliato!" viene risposto con "Non riesco a vedere i dati, né i DBA. Mi dispiace, per favore replicalo in un ambiente di test in cui io oi DBA possiamo vedere i dati."

Su una nota politica dell'ufficio, o hai a che fare con problemi di conformità legale o normativa (nel qual caso è abbastanza normale), oppure tu e gli amministratori di database dovresti aggiornare i tuoi curriculum, nel caso in cui semplicemente non ti fidi di te gente.

Guarda cosa hai lì è una soluzione alla ricerca di un problema.

Dovresti iniziare chiedendo all'azienda che problema stanno cercando di risolvere. molto probabilmente desideri inquadrare la risposta in termini di CIA (Riservatezza, integrità, disponibilità).

Se ti senti davvero coraggioso, prova a convincere l'azienda a realizzare un modello di minaccia sul sistema, potresti scoprire che la riservatezza dei dati non è necessariamente il tuo più grande rischio.

Una volta ottenute tali informazioni, è possibile trovare delle vere soluzioni al vero problema che non include necessariamente la crittografia dell'intero database. per esempio. per motivi di riservatezza è possibile utilizzare una buona autorizzazione / elenchi di controllo degli accessi. Per l'integrità dei dati è possibile considerare l'utilizzo di hash di dati o MAC (si vorrebbe anche considerare un auditing strong per vedere chi sta usando / cambiando i dati). Per la disponibilità si stanno cercando soluzioni IT tipiche per questo, backup e ripristino dei dati, ridondanze del server ecc.

Chiedi loro di classificare un elenco di requisiti in ordine di importanza. Includi requisiti di sicurezza, come ad esempio:

#1. DBAs cannot see employee identity (name, DOB).

#2. DBAs cannot see transaction details (date, amount).

e requisiti di rendimento:

#3. Answer search query of form a in b seconds.

#4. Answer search query of form c in d seconds.

Se classificano i requisiti nell'ordine sopra, traccia una linea sotto il n. 2 e dì loro che è tutto ciò che è possibile.

Se pubblicano requisiti di rendimento prima del n. 2, disegna la riga sopra il n. 2.

È quindi loro responsabilità capire se scendere a compromessi. Se decidono che il # 2 è più importante di qualsiasi prestazione ragionevole, costruiscilo e conserva tutte le prove che è quello che hanno chiesto.