Quindi, secondo le linee guida sulla sicurezza HHS, una combinazione di nome utente e password è un meccanismo sufficiente per autenticare un individuo. Tuttavia ... la memorizzazione delle password utente in testo normale in un file di configurazione non è in genere un modello di progettazione consigliato. Certamente non un elenco di ogni singolo utente autorizzato ad accedere al database insieme alle loro password in chiaro. Non sono un revisore dei conti PHI / HIPAA, ma mi aspetto strongmente che se dovessi presentare questo progetto a un revisore dei conti, potrebbe mettere in discussione questo.
Alcune misure che potresti prendere per limitare il rischio:
1) Non memorizzare affatto le password. Piuttosto, memorizzare solo la password necessaria per accedere a un database utente per l'autenticazione e non la password per il database che contiene il PHI. La password del database può essere ricavata dalla password dell'applicazione dell'utente utilizzando un KDF e può essere derivata dall'autenticazione piuttosto che essere archiviata.
2) Memorizza la password, ma crittografa il file di configurazione. Per evitare che questo diventi semplice offuscamento, è necessario memorizzare la chiave di crittografia in un luogo più sicuro di un altro file di configurazione, come in un HSM.
3) Assicurarsi che l'accesso al database indiretto sia bloccato, in caso di credenziali rubate. Il server del database dovrebbe essere protetto da firewall e l'accesso dovrebbe avvenire tramite una whitelist. Nella maggior parte dei casi, è necessario concedere l'accesso al server di database solo ai server dell'applicazione (Web). In questo modo, anche se qualcuno ruba credenziali, non possono semplicemente accedere al database dalla propria macchina. Inoltre, poiché i dati per regola devono essere crittografati, se decifri utilizzando l'applicazione anziché le funzioni a livello di database, anche se un utente malintenzionato riesce ad accedere al database dall'esterno dell'applicazione, non avrà accesso a dati non crittografati.