Mantenimento della sicurezza dei dati in movimento con SSL

TL; DR: Qualsiasi politica di sicurezza richiederà la fiducia di base dei dipendenti e dei partner commerciali, che dovrebbe essere bilanciata con i controlli.

In theory, isn't it possible for a rogue employee at the hosting company to use the private key to decrypt the data in motion?

Sì, è possibile.

This seems to be a hole in our security policy

Non proprio. Hai una relazione d'affari e un BAA con questa azienda. È ragionevole supporre che agiranno in modo responsabile e non tenteranno di comprometterti in modo pericoloso a causa del loro accesso. Lo riconosci te stesso quando dici "dipendente canaglia" - non sei preoccupato che siano cattivi, sei preoccupato per una mela cattiva che funziona per loro.

Per lo stesso motivo, non sei preoccupato per le mele cattive che funzionano per te? Dovresti esserlo.

Ci sono controlli di accesso sui file chiave? Ci sono registri delle attività sul server? Hai accesso a loro? Li controlli per un accesso inappropriato? Queste sono tutte cose che dovresti fare, sia che si tratti del tuo server e dei tuoi dipendenti o del server e dei dipendenti del provider di hosting.

Dipende da come hai implementato SSL, da te impieghi inoltrare la segretezza rispetto al tuo solo a rischio da un attacco di tipo MitM (con i certificati e le chiavi private questo è banale da fare e NESSUNA PROPOSTA POSSIBILE è possibile imho.)

La segretezza Forward indica che le chiavi utilizzate per la connessione (che dovrebbero essere qualcosa di diverso dalla RSA utilizzata per i certificati stessi).

come già sottolineato @gowenfawr. il problema di sicurezza di base è di fiducia. e come viene mitigato (tramite la registrazione, ad esempio).

E se sei davvero preoccupato per questo. Ospita il tuo server o usa un server non gestito sul quale tu stesso fai la manutenzione.

Disclaimer - Non sono un avvocato!

Preambolo: -

HIPAA impone un esercizio ricorrente di valutazione del rischio che esamina l'intera infrastruttura a supporto dell'e-PHI e cerca di identificare, analizzare e valutare i rischi per la riservatezza, l'integrità e la disponibilità di e-PHI (Altre informazioni ).

Un aspetto cruciale di questo intero esercizio è - identificare le cose che puoi fare per minimizzare i rischi (detti anche controlli). Alcuni esempi di controlli possibili sono stati forniti da gowenfawr sopra.

I miei 2 centesimi: -

SE questo aspetto è stato identificato come un rischio, E SE i controlli necessari sono in atto (ad esempio, dati adeguati / registro / condivisione delle informazioni e diritto di audit contratto tra il fornitore di servizi di hosting e la vostra azienda, prova della continua conformità di il fornitore di hosting per HIPAA, registrazione corretta, controlli di accesso più rigorosi da parte del fornitore di hosting, revisione periodica dell'accesso da parte del provider di hosting, periodica valutazione del rischio da parte della vostra azienda e tempestiva segnalazione del rischio alla direzione, ecc.). essere indirizzato e non dovrebbe porre alcun problema a e-PHI.

Mentre molte politiche di sicurezza affrontano cose da 30.000 piedi, e quindi dovrebbero essere infallibili, i processi sottostanti (ad es. audit periodico, cose da scalare, valutazioni del fornitore, criteri di valutazione del fornitore, messa in atto come audit clausola con i venditori, ecc.) non sono sempre infallibili, con conseguenti buchi nel sistema generale.