Firma con @Xander e @Michael Hampton.
Questi schemi di crittografia del codice sorgente si basano tutti su ... una chiave privata. In modo che non risolva il tuo problema, sposta semplicemente il problema da un'altra parte.
Ottenere la chiave da un server separato [1] ha lo stesso problema: è necessario autenticarsi su quell'altro server e le credenziali di autenticazione devono essere memorizzate da qualche parte sull'host condiviso. Quindi, tutto ciò che hai fatto è stato spostare il problema un po '.
È possibile archiviare la chiave nel database stesso o nella memoria, nessuno dei quali dovrebbe essere letto da altri utenti sul proprio host condiviso a meno che non sfrutti qualche vulnerabilità per aumentare i privilegi [2]. Nel caso dell'archiviazione in memoria, ciò richiederebbe il collegamento all'applicazione ogni volta che viene riavviato e fornire la chiave in remoto, il che richiederebbe una connessione sicura.
Non ho idea di quali siano le leggi nel tuo paese [e IANAL], ma da un punto di vista puramente etico, non potrei mai ospitare informazioni sulla salute personale in una struttura di hosting condiviso non accreditata . Potresti riuscire a tirarlo fuori; potresti persino essere in grado di rispettare le leggi e i regolamenti locali, ma non sarebbe mai molto sicuro.
Hai anche imbattuto in un problema molto più grande in generale: anche la migliore crittografia è strong quanto la sicurezza delle chiavi private coinvolte. Anche in un ambiente di hosting dedicato, una vulnerabilità nell'applicazione può consentire a un utente malintenzionato di recuperare la chiave e inoltre è vulnerabile a chiunque abbia accesso fisico al server stesso, ad esempio a qualsiasi dipendente del provider di hosting.
Anche se la chiave è perfettamente sicura, devi ancora pensare a come la tua applicazione gestisce i dati dopo che è stata decifrata. I tuoi controlli di accesso assicurano che gli utenti vedano solo le informazioni che sono autorizzati a vedere? I tuoi controlli di sicurezza impediscono o attenuano il rischio che un utente malintenzionato ruba una sessione autorizzata e quindi la utilizza per scopi non autorizzati?
Le risposte a queste domande dipendono, in parte, dai requisiti legali in cui stai operando.
- Presumibilmente l'altro server è non su un host condiviso, altrimenti quali vantaggi ha questa separazione? Ma se hai accesso a un host non condiviso, perché stai ospitando la tua applicazione su un host condiviso, in primo luogo?
- L'escalation dei privilegi sembra fuori portata per la domanda che stai chiedendo.