Gli ingegneri che si avvicinano al primo cliente nel settore sanitario spesso immaginano HIPAA come un enorme audit del codice. In realtà non è così. La Security Rule è un insieme di misure di sicurezza amministrative, fisiche e tecniche. La parte principale di un programma HIPAA riguarda l'analisi dei rischi, le politiche, il personale e i contratti con i fornitori. Solo una parte è determinata da ciò che fa il codice, e sapere quale parte rende tutto meno misterioso.
Questa pagina tratta quella parte legata al codice. Non è una determinazione di entità coperta, un BAA o una promessa che heygrc o ISMS Copilot gestiscano ePHI.
Le misure di sicurezza che interessano il codice
Le misure di sicurezza tecniche si trovano nel 45 CFR 164.312. Quelle che effettivamente cambiano in una pull request sono: identificazione univoca dell'utente (164.312(a)(2)(i)), accesso di emergenza (164.312(a)(2)(ii)), disconnessione automatica (164.312(a)(2)(iii)), crittografia e decrittografia (164.312(a)(2)(iv)), controlli di audit (164.312(b)), integrità (164.312(c)(1)), autenticazione della persona o dell'entità (164.312(d)) e sicurezza della trasmissione (164.312(e)(1)). La disconnessione automatica e la crittografia/decrittografia sono specifiche affrontabili: implementale dove ragionevole e appropriato, o documenta perché no e usa una misura equivalente. Se puoi ragionare su chi può accedere a ePHI, se l'attività viene registrata, se è crittografata a riposo e in transito e se una modifica autentica ancora il chiamante, stai ragionando sulla maggior parte della superficie legata al codice della Security Rule.
Molto di ciò che sembra legato a HIPAA in ingegneria risiede fuori dal diff: revisioni degli accessi, formazione del personale, analisi dei rischi e un BAA firmato quando si applicano le regole per i business associate (quest'ultimo è un contratto richiesto, non solo una prova che un processo è stato eseguito). Il codice stesso riguarda principalmente il 164.312.
Le modifiche che diventano riscontri
Una pull request che registra l'intero corpo di una richiesta contenente dati dei pazienti può inserire ePHI in un archivio accessibile a più persone rispetto al sistema di riferimento. Una modifica che rimuove la crittografia da un archivio di record o che instrada ogni accesso attraverso un account di servizio condiviso è dello stesso tipo di problema: la misura di sicurezza è più debole dopo il merge che prima. Se individuata nella PR, l'autore ha ancora il contesto per sistemarla. Se individuata in una revisione di sicurezza del cliente o in un'indagine, diventa una correzione con una traccia cartacea.
Questa asimmetria è l'argomento per verificare la superficie del 164.312 nel diff piuttosto che scoprirla dopo che un cliente ha richiesto prove.
Dove si inserisce heygrc e il confine dell'onestà
heygrc è progettato per riconoscere queste situazioni quando HIPAA è uno dei framework selezionati e per citare la misura di sicurezza alla clausola. Non determina se sei un'entità coperta o un business associate, non scrive la tua analisi dei rischi, non firma un BAA o non archivia ePHI. Né heygrc né ISMS Copilot sono business associate HIPAA per i dati dei tuoi clienti in questo prodotto. Usalo come revisore della modifica, non come programma di conformità.