Come separare i dati sensibili nel database (MySql)

Devo 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 differenti, uno per i dati sensibili e l'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

il dba non dovrebbe essere in grado di visualizzare le informazioni sulla malattia dell'utente del database.

Per quanto riguarda l'utilizzo per separare i database non penso che sia necessario. Stai memorizzando i dati crittografati e usando le autorizzazioni del database per utente, la tabella (se necessario) sarà più che sufficiente. Penso che il DB aggiuntivo aggiunga un livello di complessità senza molto altro. A meno che non si trovi in ​​una posizione diversa, potrebbe avere un PICCOLO miglioramento rispetto a 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. Il problema tuttavia è che se si hanno utenti dell'applicazione separati e utenti del database separati, la sincronizzazione di questi utenti sarà incredibilmente difficile. Immagino che i pazienti non debbano accedere al tuo database però. Se necessario, potrebbe essere più sicuro disporre di una chiave per utente.

Oltre ai requisiti legali o contrattuali, alcuni altri motivi a cui posso pensare di avere database separati sono: la percezione del cliente di una maggiore sicurezza che semplifica le vendite, le preoccupazioni sulla rottura della crittografia e le preoccupazioni sulla (la) chiave (e) compromessa.

Per quanto riguarda la parte della risposta di Briddmus in cui afferma "che è necessario crittografare più delle semplici informazioni mediche": ciò vale solo se tutti nel database hanno una condizione medica. (Immagino 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 le informazioni mediche penso che dovrebbe essere limitato all'utente che lo ha inserito e a chiunque abbia dato il permesso di visualizzarlo.

Per evitare che il DBA visualizzi i dati dovrai crittografarlo usando un codice a cui il DBA non ha accesso.

È inoltre necessario crittografare le informazioni in modo che neanche il programmatore dell'applicazione possa accedervi. Non ha senso crittografare le informazioni dal DBA se un programmatore può accedere come qualsiasi utente.

Inoltre, non vuoi crittografare tutti i dati con lo stesso codice. Il software potrebbe avere un bug che mostra a un utente le informazioni di un altro. Quindi sarebbe probabilmente meglio crittografare i dati di ciascun utente usando un codice specifico per quell'utente.

È importante notare che è necessario crittografare più delle semplici informazioni mediche; come utente finale non vorrei che il tuo DBA sapesse che ho una condizione medica, figuriamoci di cosa si tratta. Quindi dovrai anche crittografare qualsiasi informazione di identificazione personale dell'utente. Ciò include cose come:

• nome
• data di nascita
• indirizzo email
• sesso
• indirizzo