Corretta implementazione di HIPAA all'interno dell'app iOS con diversi fattori

Dichiarazione di non responsabilità: la mia azienda realizza un'applicazione per iPod conforme a HIPAA. Sono responsabile della conformità ...

L'iPhone soddisfa effettivamente molti requisiti HIPAA immediatamente. Una volta che il codice è stato impostato sul dispositivo, i contenuti sono crittografati, il che si prende cura di molti requisiti HIPAA, in particolare la crittografia a riposo.

Per scaricare i dati, devi utilizzare una connessione TLS o altrimenti crittografata per assicurarti che i dati siano crittografati durante il transito.

Devi configurare la tua applicazione per scaricare e inviare una politica di sicurezza a un sito web in un file .mobileconfig che costringe gli utenti a impostare un codice di accesso sul dispositivo per utilizzare l'applicazione. Se il passcode è impostato, il dispositivo viene crittografato. Quindi, il .mobileconfig la applicherà.

Dovresti inoltre sfruttare l'uso del portachiavi per memorizzare qualsiasi tipo di token o credenziale fornito dall'utente. Per semplificare, è possibile fare in modo che l'app richieda un codice di accesso a 4 cifre per sbloccare tali credenziali dal portachiavi - piuttosto che farle ridigitare una password sul telefono.

Se l'app non ha una connessione di rete al server costantemente, puoi creare un pulsante di sincronizzazione. Questo sincronizzerà i dati rilevanti con il filesystem locale. Quando vengono apportate modifiche, viene salvato in locale, finché l'app non viene nuovamente sincronizzata, nel qual caso riconcilia le modifiche con il database dell'applicazione Web principale.

Infine, questa non è una descrizione esauriente della conformità iOS HIPAA, ti incoraggio a consultare un avvocato per redigere le tue politiche di sicurezza e altra documentazione, che è richiesta per avere sotto HIPAA.

So che questa è una domanda piuttosto vecchia, ma l'ho trovata come parte di un'altra ricerca e ho pensato di buttare fuori un'altra idea qui nel caso in cui altri si trovassero di fronte a sfide simili.

Potresti voler vedere la crittografia delle buste.

Una strategia di esempio che potresti utilizzare è la seguente:

Ipotesi:

Hai PHI, hai utente A e utente B, e ogni utente ha una password diversa. Si desidera che entrambi gli utenti abbiano pieno accesso al PHI dopo aver inserito le rispettive password. Un accesso utente è composto da un nome utente e una password.

Strategia:

Cifrare il PHI con una chiave segreta (chiamiamola K). Spedisci una tabella di dati sul dispositivo, contenente per ogni utente: un hash del nome utente (ad es. Md5) e una versione di K crittografata dalla password dell'utente (chiamiamola chiave eK crittografata).

Quindi, per ottenere l'accesso al PHI, l'utente A inserisce il suo nome utente e la sua password, e si verifica quanto segue, nell'ordine:

• un hash viene calcolato dal nome utente
• quell'hash viene usato per trovare la voce pertinente nella tabella
• la chiave crittografata eK viene decifrata utilizzando la password inserita dall'utente, risultante in una chiave utilizzabile K
• il PHI viene decifrato usando K e caricato in memoria
• (l'utente può modificare i dati come necessario)
• il PHI viene crittografato nuovamente usando K e memorizzato nel dispositivo

Ora l'utente A potrebbe disconnettersi e l'utente B potrebbe accedere con il suo nome utente e password, il che comporta una versione decrittata dello stesso K, quindi utilizzabile per decrittografare e crittografare nuovamente il PHI secondo necessità.

Considerazioni

Mediante l'hashing del nome utente, evitiamo di rivelare eventuali nomi utente effettivi nella tabella dati.

Con questa strategia, si è in grado di memorizzare la chiave di crittografia stessa, ma in modo tale che un utente senza il nome utente / password appropriati non sarebbe in grado di accedere alla chiave e non sarebbe in grado di decodificare la PHI.

Mentre sto per iniziare presto una carriera con HIPAA, e quindi mi sto sfiorando, ho finora solo esperienza con la conformità PCI. Detto questo, la mia comprensione di ciò che ho esaminato finora sembra indicare sia l'ePHI stesso sia i metadati di quell'ePHI (data / ora di creazione, nome file, data ultimo mod --- ref. link ) deve essere crittografato.

Memorizzare una chiave in cui si memorizzano i dati che si desidera proteggere sembra una mossa rischiosa. Come tenere una chiave della tua auto sotto l'aletta parasole.

Inoltre, parte della conformità HIPAA è la sicurezza fisica. Che controllo fisico hai sul telefono di quell'utente? Per i miei due centesimi la soluzione migliore è dimenticare le funzionalità offline e concentrarsi su un'app che potrebbe richiedere sempre una connessione Internet, ma è sicura.

Penso che la tua domanda sia "Come eseguire l'autenticazione e l'autorizzazione offline su un dispositivo non sicuro?".

La risposta breve a questa domanda è: non puoi.

La lunga risposta è: alcuni ragazzi hanno cercato di aggirare questo problema, per i giocatori di raggi blu e le console per videogiochi. Per risolvere il problema, cercano di rendere affidabile il dispositivo non affidabile, impedendo agli utenti di assumere un controllo permanente del proprio dispositivo. I nuovi raggi blu avranno bisogno di giocatori aggiornati da giocare e i giocatori con vulnerabilità saranno elencati dal consorzio blu-ray. Le console utilizzano componenti crittografici resistenti al freddo per proteggere i loro segreti (in combinazione con altri meccanismi). Per informazioni dettagliate su questi due esempi, è possibile iniziare con wikipedia cercando le sezioni sulla gestione del DRM. Tuttavia , i videogiochi e i raggi blu non sono informazioni sanitarie protette. Possono tollerare i loro meccanismi di protezione per rompere di volta in volta, hanno pianificato per esso e possono recuperare. Inoltre, non hai alcun controllo sui dispositivi e non puoi implementare un meccanismo di sicurezza simile a loro.

Quello che ti consiglierei di fare è innanzitutto dimenticare di autenticare molti utenti per semplificare le tue esigenze. Devi solo autenticare l'utente dell'app iOS e poi trasferirgli la responsabilità del PHI. Può quindi condividere i suoi dati, ma qualsiasi problema che ne deriverà sarà di sua completa responsabilità. L'utente dovrà adottare le misure per rimanere conforme a HIPAA (la tua app potrebbe essere in grado di aiutarlo). In secondo luogo, dimentica l'autenticazione offline. Autenticarlo online, prima di recuperare i dati e i diritti associati. Tuttavia, non sarai in grado di applicare con forza tali diritti poiché non hai alcun controllo sul dispositivo. Inoltre, la tua applicazione può provare a imporli e puoi rendere illegale modificare o decodificare l'applicazione. In terzo luogo, la memorizzazione di dati crittografati con la chiave per decrittografarli è inutile. Aumenterà solo i costi di sviluppo e manutenzione senza aumentare il valore della vostra applicazione. Se HIPAA richiede la crittografia, lascia che sia iOS a gestirla: usa le sue API e lascia che sia crittografata con la password dell'utente o i token di sicurezza o altro.

Potrebbero esserci altre soluzioni più adatte alle tue esigenze.