Ho bisogno di progettare un database che contenga informazioni sulla malattia personale degli utenti.
Quale può essere l'approccio per implementare le colonne delle tabelle del DB: crittografare le informazioni, separare i dati all'interno di due DB diversi, uno per i dati sensibili e un altro per i dati non sensibili, o entrambi o un altro approccio?
È possibile crittografare i dati con una chiave memorizzata nell'applicazione Web in modo che i dati vengano scritti / letti da db nella sua forma crittografata. Tuttavia chiunque abbia accesso al codice avrebbe accesso alla chiave e con la chiave i dati non crittografati. Questo risolve il requisito
the dba should not be able to view the information about disease of the user of the database.
Per quanto riguarda l'utilizzo di database separati, non penso che sia necessario. Stai archiviando i dati crittografati e utilizzando le autorizzazioni del database per utente, la tabella (se è addirittura necessaria) sarà più che sufficiente. Penso che il DB aggiuntivo aggiunga uno strato di complessità senza molto altro. A meno che non si trovi in una posizione diversa, potrebbe avere un piccolo miglioramento da un singolo sistema di database.
La risposta di Ominus affronta la tua prima domanda. La risposta alla seconda domanda potrebbe richiedere maggiori dettagli sulla tua domanda.
Un altro approccio con una sicurezza ancora maggiore se i pazienti devono accedere al database potrebbe essere quello di avere un database separato per ciascun utente. In questo approccio è possibile utilizzare un framework che fornisce funzionalità multi-tenant e multi-database. Tuttavia, il problema è che se si dispone di utenti di applicazioni separate e di utenti di database separati, la sincronizzazione di questi utenti sarà estremamente difficile. Direi che i pazienti non hanno bisogno di accedere al tuo database però. Se necessario, potrebbe essere più sicuro avere una chiave per utente.
Oltre ai requisiti legali o contrattuali, altri motivi per cui posso pensare di avere database separati sono: la percezione del cliente di una maggiore sicurezza che facilita le vendite, preoccupazioni per la crittografia in corso di interruzione e preoccupazioni circa la (e) chiave (e) chiave (e) compromessa.
Per quanto riguarda la parte della risposta di Briddmus in cui afferma "che è necessario crittografare più che solo le informazioni mediche": ciò vale solo se tutti i membri del database hanno una condizione medica. (Suppongo che sia così).
Nota: parti di questa risposta sarebbero più adatte come commenti, ma non ho ancora un rappresentante sufficiente per pubblicare commenti qui.
Per questo tipo di applicazione è necessario pensare a chi dovrebbe essere autorizzato ad accedere ai dati. Con informazioni mediche penso che potrebbe essere limitato all'utente che l'ha inserito e chiunque abbia dato il permesso di vederlo.
Per impedire al DBA di visualizzare i dati, è necessario crittografarlo utilizzando un codice a cui il DBA non ha accesso.
È inoltre necessario crittografare le informazioni in modo che il programmatore dell'applicazione non possa accedervi. Non ha senso crittografare le informazioni dal DBA se un programmatore può accedere come qualsiasi utente.
Inoltre non vuoi criptare tutti i dati con lo stesso codice. Il software potrebbe avere un bug che mostra a un utente l'informazione di un altro. Quindi sarebbe probabilmente meglio crittografare i dati di ciascun utente utilizzando un codice specifico per quell'utente.
È importante notare che è necessario crittografare più che solo le informazioni mediche; come utente finale non vorrei che il tuo DBA sapesse di avere una condizione medica, per non parlare di cosa sia. Quindi dovrai anche criptare qualsiasi informazione di identificazione personale sull'utente. Questo include cose come:
Leggi altre domande sui tag security mysql database-design