Il servizio dei documenti · cifratura, accessi, e i limiti veri
Ogni affermazione di conformità di questo sito — quella americana, quella europea, quella britannica, quella tedesca — prima o poi punta a un solo pezzo di macchina: il servizio che conserva i documenti clinici. Questa pagina spiega come funziona, in parole ordinarie, e poi fa una cosa che quasi nessuna documentazione di fornitore fa.
Elenca i rischi che non hanno rimedio tecnico. Non quelli che abbiamo risolto e di cui ci farebbe piacere parlarvi — quelli in cui la risposta onesta è « questo può succedere, ecco perché abbiamo scelto così, ed ecco che cosa dovete farci ». Se leggete una sola sezione, leggete quella.
Immaginate ogni documento clinico dentro una scatola con il proprio lucchetto, e ogni lucchetto con una chiave diversa. Quelle chiavi sono a loro volta chiuse in una cassaforte. Le scatole e le chiavine vivono nel vostro database. La chiave della cassaforte no.
È tutto qui il progetto. Tutto ciò che segue è dettaglio posato sopra, e vale la pena dire le conseguenze prima della meccanica:
Chi copia il vostro intero database ottiene le scatole e le chiavine chiuse. Senza la chiave della cassaforte non si apre nulla. È ciò che vi rende disponibile l'esenzione da cifratura nel diritto delle violazioni — potete sostenere che i dati erano incomprensibili, purché la chiave della cassaforte non sia stata presa anch'essa.
Per distruggere un documento si distrugge la sua chiavina. La scatola resta, vuota e per sempre inapribile. È più forte del cancellare una riga — una riga cancellata torna dal backup di ieri notte, una chiave distrutta no.
Non esiste una copia principale, né un deposito presso il fornitore, né un servizio di recupero. Se la chiave della cassaforte sparisce, ogni documento clinico che detenete sparisce con essa. È deliberato, e la sezione 05 spiega perché qualunque « soluzione » sarebbe peggiore del problema.
La tecnica si chiama cifratura a busta, ed è quella che banche e fornitori di nuvola usano per lo stesso problema. Ci sono tre strati. Il motivo per cui sono tre e non uno sta nella terza colonna.
| Strato | Che cos'è | Perché è separato |
|---|---|---|
| La versione del documento | Il file vero e proprio — una relazione di seduta, una scheda di incidente, un documento d'identità — cifrato con AES-256-GCM. Il risultato cifrato è scritto in una directory tutta sua su disco, fuori dall'archivio file ordinario di Odoo, e non è mai servito attraverso il normale percorso di scaricamento. | Tenere il testo cifrato fuori dall'area file ordinaria significa che un server web mal configurato non può pubblicare per sbaglio file clinici, perché non sono dove un server web guarderebbe. |
| La chiave dati (DEK) | Una nuova chiave casuale da 256 bit, generata per ogni versione di ogni documento. Non per paziente, non per documento — per versione. È conservata nel database, ma solo in forma avvolta. | Una chiave per versione è ciò che rende precisa la distruzione. Distruggere la chiave di una versione distrugge esattamente quella versione e nient'altro, così si può tenere una correzione distruggendo l'originale, o il contrario. |
| La chiave di installazione (KEK) | Una sola chiave da 256 bit per l'intera installazione, tenuta in un file sul server, che avvolge ogni chiave dati. Non è mai conservata nel database e non lascia mai il server. | È questa la separazione che fa il lavoro. Database e chiavi sono cose diverse in posti diversi con backup diversi, quindi ottenere l'uno non dà l'altro. |
Per ogni versione di documento esistono sei cose. Sono tenute deliberatamente in posti diversi, perché tutto il progetto poggia sul fatto che nessun singolo posto ne detenga due.
| Il pezzo | Dove è tenuto | Che cosa vi dà detenere solo questo |
|---|---|---|
| Il file stesso, cifrato | Una directory tutta sua sul server, disposta come
<archivio>/<primi 2 dell'uuid>/<successivi 2>/<uuid>.enc.v<versione>. Le directory sono accessibili al solo proprietario, i file in lettura e scrittura al solo proprietario. Fuori dall'archivio file di Odoo, quindi non è raggiungibile tramite /web/content e non è toccato dalla raccolta rifiuti degli allegati. |
Nulla. Testo cifrato autenticato senza chiave. Un file per versione, così archiviare una nuova versione non può sovrascrivere quella precedente. |
| Il nonce e due impronte | Nel database, sulla riga della versione: il nonce usato per questa cifratura, un'impronta del testo in chiaro, e un'impronta del testo cifrato. | Da soli nulla — ma l'impronta del testo in chiaro serve a ricostruire il legame descritto sotto, quindi perderla rende il testo cifrato indecifrabile. È per progetto, non una svista. |
| La chiave dati, avvolta | Nel database, cifrata sotto la chiave di installazione. La forma non avvolta esiste solo in memoria, per la durata di una lettura, e viene scartata subito dopo. | Nulla senza la chiave di installazione. Un database rubato vi dà chiavi avvolte e percorsi di testo cifrato, e nessuno dei due apre alcunché. |
| La chiave di installazione | Un file sul server, leggibile solo dall'account con cui gira Odoo. Mai nel database. Mai nell'archivio file. Mai dentro una radice di backup dichiarata — ciascuna di queste cose è verificata all'avvio ed è fatale, non un avvertimento. | Nulla senza il database, che contiene le chiavi dati avvolte, e senza l'archivio del testo cifrato. Servono tre cose separate, e sono tenute in tre posti. |
| Le regole di accesso | Nel database, come registrazioni — chi può aprire che cosa, a che titolo, e fino a quando. | Decidono che cosa può aprire un collega . Non hanno alcun effetto su chi ha i file ma non le chiavi, che è il caso per cui esiste la cifratura. |
| Il registro degli accessi | Nel database, in sola aggiunta e concatenato per impronte. Ogni lettura, non solo ogni modifica. | La registrazione di chi ha aperto che cosa. È scritta prima che il contenuto sia consegnato, così anche uno scaricamento che qualcuno annulla resta registrato come accesso. |
Tutto ciò che precede è più facile da verificare contro questi due. Il primo è ciò che succede quando un documento viene archiviato; il secondo è ciò che succede quando qualcuno chiede di vederne uno. Leggete con attenzione il secondo — è lì che la maggior parte dei sistemi è più debole di quanto dichiari.
Una relazione di seduta, una scheda di incidente, un documento d'identità. Arriva in memoria.
32 byte dalla sorgente casuale crittografica del sistema operativo. Non derivata da una password, non riusata da un altro documento, non riusata dalla versione precedente di questo documento.
una chiave per versione — è questo che rende precisa la distruzioneUno SHA-256 del testo in chiaro, e un numero da 96 bit usato una volta sola. Nessuna funzione del nucleo di cifratura accetta un nonce dal chiamante, quindi il classico errore di riuso qui non si può commettere.
AES-256-GCM, con uuid | numero di versione | impronta del contenuto come dati autenticati aggiuntivi. Quel legame è obbligatorio. Un testo cifrato in seguito copiato su un altro documento o su un'altra versione rifiuterà di decifrarsi anziché aprirsi in silenzio sotto le regole di accesso della persona sbagliata.
Cifrata con la chiave di installazione, marcata con la generazione della chiave e lo spazio dei nomi della chiave, e conservata nel database in quella forma. La chiave non avvolta viene scartata dalla memoria immediatamente.
Scritto in un file temporaneo nella directory di destinazione, scaricato sul disco fisico, poi rinominato al suo posto — così un blocco a metà scrittura non può lasciare una versione a metà. Il file temporaneo contiene testo cifrato, mai testo in chiaro.
Percorso di archiviazione, nonce, entrambe le impronte, dimensione, e la chiave avvolta. Mai il testo in chiaro, mai una chiave non avvolta, mai la chiave di installazione.
Chi l'ha archiviato, quando, quanto grande, e di che tipo. In sola aggiunta e concatenato alle voci precedenti.
Un clinico nel back office, o un paziente sulla pagina delle proprie cartelle. Entrambi passano dalle stesse verifiche; nessuno dei due percorsi aggira quelle dell'altro.
Sul percorso rivolto ai pazienti, le cartelle non si mostrano a un account che ha solo una password. Il rifiuto dice che cosa fare, anziché fingere che il documento non esista.
Un limite di frequenza per persona sul percorso rivolto ai pazienti. Detto chiaramente, perché dirlo non svela nulla e risparmia una chiamata all'assistenza.
Prima le regole di diniego — una sola è definitiva. Poi le regole di permesso: se nessuna corrisponde, la risposta è no. L'accesso di emergenza è consultato solo a quel punto, così può raggiungere ciò che non era stato concesso ma non può ribaltare un rifiuto. Le etichette di sensibilità si applicano per ultime e possono solo togliere accesso.
chiuso per impostazione predefinita · in questa verifica non esiste alcun ramo da superutenteLa voce è scritta per prima, così un trasferimento che qualcuno interrompe a metà resta comunque a verbale come accesso. Il registro è in sola aggiunta e concatenato per impronte; le voci non si possono rimuovere in silenzio dopo, né da noi né dal vostro amministratore.
Prima che si tocchi qualunque chiave. Una corruzione nell'archivio viene così segnalata come corruzione, anziché emergere più tardi come un confuso errore di autenticazione.
Usata per svolgere la chiave dati di questa versione, verificando strada facendo la generazione e lo spazio dei nomi della chiave. Una chiave avvolta per uno spazio dei nomi non può essere svolta come un altro nemmeno da chi detenga entrambe le chiavi di installazione.
L'identificativo del documento, il numero di versione e l'impronta del contenuto vengono ricostruiti e devono corrispondere. Una manomissione, una chiave sbagliata, e un testo cifrato spostato da un'altra registrazione falliscono tutti qui — e falliscono tutti allo stesso modo, perché dire a un attaccante quale parte sia fallita è informazione regalata.
La chiave dati viene lasciata cadere dalla memoria. Nessun percorso di codice in questo prodotto scrive un byte decifrato su disco — non per le anteprime, non per le miniature, non per l'indicizzazione di ricerca.
Una versione distrutta segnala che la sua chiave non esiste più. Non c'è ripiego, né copia in cache, né via di recupero, che è proprio il senso di distruggerla in quel modo.
Una sola chiave protegge ogni chiave dati dell'installazione, quindi il modo in cui è maneggiata è la parte che vale la pena verificare riga per riga. Tutte le verifiche qui sotto girano all'avvio e tutte sono fatali — il server non parte, anziché girare con una protezione che credete di avere e non avete.
32 byte dalla sorgente casuale del sistema operativo, scritti in un file creato con permesso di sola lettura per il proprietario in un unico passaggio, così non è mai brevemente leggibile da altri.
Il file deve contenere o 32 byte grezzi o 64 caratteri esadecimali. Non si accetta nient'altro — una passphrase viene rifiutata anziché allungata in una chiave, perché una passphrase allungata è una chiave più debole che sembra più forte.
Non nel database. Non nella directory dati di Odoo, nel suo percorso dei moduli o nel suo archivio file. Non dentro l'archivio del testo cifrato. Non dentro alcuna directory che abbiate dichiarato come radice di backup.
Quest'ultima è quella che si sbaglia più spesso. Un backup che contiene sia il database sia la chiave è una chiave compromessa, e mette l'installazione fuori dal porto sicuro americano per le violazioni e fuori dall'esenzione europea dell'art. 34(3)(a) — che è l'intero motivo per cui la cifratura è qui.
Ruotare la chiave di installazione riavvolge le chiavi dati e non riscrive un solo byte di testo cifrato. Centomila documenti ruotano alla velocità con cui si possono ricifrare cento chiavi, non a quella con cui si possono riscrivere centomila file.
Il numero di generazione è dentro l'avvolgimento, quindi una chiave avvolta sotto la vecchia generazione non può essere aperta in silenzio come se fosse la nuova.
Distruggere una versione sovrascrive la sua chiave avvolta con byte casuali anziché svuotare il campo, così non resta nulla da recuperare nemmeno dalla pagina del database.
Il guscio di metadati della versione e l'intero registro degli accessi sopravvivono — potete ancora dimostrare di aver detenuto il documento e di averlo distrutto correttamente. Una versione non può essere cancellata finché la sua chiave esiste ancora, così l'ordine non può mai essere sbagliato.
Sono i punti in cui la cifratura è di solito implementata quasi correttamente, e il quasi è tutta la differenza.
Quando una versione viene cifrata, la cifratura è legata all'identificativo di quel documento, al suo numero di versione e a un'impronta del suo contenuto. I crittografi lo chiamano dati autenticati aggiuntivi, ed è obbligatorio qui — nessun chiamante può saltarlo.
L'effetto: un testo cifrato copiato su un altro documento, o su un'altra versione, rifiuta di decifrarsi. Non si apre in silenzio sotto le regole di accesso del paziente sbagliato — che è esattamente l'attacco a cui un sistema privo di questo legame è esposto.
AES-GCM è catastroficamente debole se lo stesso nonce è usato due volte con la stessa chiave: un attaccante che veda due testi cifrati così può ricavare informazioni da entrambi. È il classico errore di implementazione.
Qui ogni cifratura genera il proprio nonce e nessuna funzione accetta un nonce dal chiamante. L'errore non è reso più difficile da commettere; è reso impossibile da commettere.
Il nucleo di cifratura è scritto come pezzo a sé, senza dipendenze dal framework applicativo, così chi voglia verificare l'affermazione sulla cifratura possa leggerlo e provarlo da solo senza far girare un sistema per cliniche.
Se il vostro reparto sicurezza vuole verificare le affermazioni di questa pagina anziché crederci, è quello il file da consegnargli, ed è corto.
Dove la legge separa gli appunti di processo di un terapeuta dalla cartella clinica — l'eccezione americana sulle note di psicoterapia è il caso più chiaro — quegli appunti sono cifrati sotto una seconda chiave di installazione, diversa. La chiave che apre la cartella ordinaria non li apre.
Conta perché rende la separazione una proprietà dell'archiviazione anziché delle regole di accesso. Se domani ogni permesso del sistema fosse sbagliato, la chiave ordinaria continuerebbe a non decifrare quegli appunti. Significa anche che la seconda chiave dev'essere configurata prima della messa in esercizio: archiviare un appunto del genere senza di essa fallisce anziché ripiegare in silenzio sulla chiave principale, perché un ripiego silenzioso distruggerebbe la separazione senza che nessuno se ne accorga.
Le due cose si confondono spesso. La cifratura protegge da chi non dovrebbe proprio essere nel sistema. Non fa nulla contro il problema assai più comune: qualcuno che è nel sistema, e guarda una cartella che non lo riguarda.
È per questo che c'è lo strato di autorizzazione, e funziona su un principio diverso da quello della maggior parte dei sistemi: l'accesso segue la relazione di cura, non la qualifica.
Ogni volta. Non una volta all'accesso.
Detto esplicitamente, perché i revisori lo chiedono
A volte un clinico ha davvero bisogno di una cartella con cui non ha alcuna relazione — una crisi, una chiamata fuori orario, un collega che si è ammalato. Dove la vostra organizzazione lo permette, l'accesso a rottura del vetro è disponibile. Usarlo apre una sessione registrata che viene riesaminata dopo.
Un sistema che si limita a rifiutare è insicuro a modo suo, e nel Regno Unito è esplicitamente non conforme: il principio Caldicott 7 rende il dovere di condividere importante quanto il dovere di proteggere. Perciò l'accesso esiste, e il suo uso non è mai silenzioso.
Su un tipo di documento — è quel tipo a decidere le regole, il periodo di conservazione e chi possa aprirla.
In parole semplici, prima che venga salvata. La maggior parte degli errori di archiviazione avviene perché nessuno sapeva dove sarebbe atterrato un documento.
Legata a questo documento, a questa versione, e a un'impronta di questo contenuto.
La chiave non avvolta esiste solo in memoria, per il momento in cui serve.
Con permessi propri, in una directory propria.
Ogni apertura registrata prima che il contenuto compaia.
Come nuova versione, con la sua nuova chiave. L'originale resta intatto e ancora leggibile — una registrazione modificabile non vale nulla come prova.
Rifiuta di decifrarsi, perché la cifratura è legata all'identità del documento originale.
Dalla fine della relazione — non dal giorno in cui il file è stato creato.
Il materiale della chiave viene sovrascritto con byte casuali, poi la riga della chiave viene cancellata. Sovrascrivere prima è deliberato: se il processo si interrompe, il modo di fallire è un documento che non si può leggere, mai uno che sopravvive quando non dovrebbe.
Potete ancora dimostrare che la cartella è esistita, chi l'ha vista in vent'anni, e che è stata distrutta nei tempi. Il contenuto è illeggibile da chiunque, per sempre, noi compresi.
Tutto ciò che precede è ciò che il sistema fa bene. Questa sezione è l'opposto: i punti in cui può succedere qualcosa di brutto e nessuna quantità di ingegneria lo chiude — perché chiuderlo costerebbe più protezione di quanta ne compri.
Ognuno dice che cosa succede davvero, che cosa ne facciamo noi, e che cosa resta a voi. Se un fornitore vi dice che la sua cifratura non ha nessuno di questi problemi, o non ci ha pensato o spera che non ci pensiate voi.
Che cosa succede: il file della chiave viene cancellato, il disco si guasta, il server viene ricostruito senza di essa, o l'unica persona che sapeva dove fosse se n'è andata. Ogni documento clinico del sistema diventa definitivamente illeggibile. Non difficile da recuperare — impossibile. Il database è intatto e inutile.
Perché non lo risolviamo: gli unici rimedi sono una copia tenuta dal fornitore o una porta di servizio per il recupero. Entrambi distruggono la proprietà per cui tutto il progetto esiste. Se ne tenessimo una copia, « un database rubato non è una violazione » smetterebbe di essere vero, e ogni promessa di questa pagina su ciò che non possiamo vedere diventerebbe falsa. Una chiave recuperabile è una chiave che qualcun altro può usare.
Che cosa facciamo: il sistema rifiuta di partire se la chiave manca, anziché girare in silenzio e lasciarvi scoprire il problema quando un documento non si apre. La verifica all'avvio rifiuta anche se il file della chiave è leggibile da qualcuno che non sia il proprietario, o se appartiene all'account sbagliato.
Che cosa spetta a voi: fate il backup della chiave, separatamente dai dati, e provate a ripristinarla. Due persone dovrebbero sapere dov'è. È il dovere operativo dalle conseguenze più gravi dell'intera piattaforma, e ci vogliono una decina di minuti per farlo bene.
Che cosa succede: un amministratore spedisce il file della chiave per email a un collega, lo incolla in un ticket, lo copia su un portatile, oppure un tecnico che se ne va ne tiene una copia. Chiunque detenga sia quel file sia una copia del database può decifrare ogni documento, fuori linea, senza alcun accesso, e nel vostro registro degli accessi non viene scritto nulla — perché il registro annota le letture fatte attraverso l'applicazione, e questo aggira l'applicazione del tutto.
Perché non lo risolviamo: la chiave dev'essere leggibile dal software che la usa. Qualunque processo possa leggerla può copiarla. I moduli di sicurezza hardware spostano il problema anziché risolverlo — il software deve comunque poter chiedere al modulo di svolgere le chiavi, quindi un attaccante con i privilegi di quel software ottiene comunque il testo in chiaro.
Che cosa facciamo: i permessi del file sono imposti all'avvio, quindi una chiave leggibile da tutti ferma il sistema anziché passare inosservata. E poiché vi auto-ospitate, noi il file non ce l'abbiamo proprio — l'insieme delle persone che potrebbero copiarlo è il vostro personale, non il vostro personale più il nostro.
Che cosa spetta a voi: trattate la chiave come un oggetto fisico controllato. Limitate chi può collegarsi al server, usate account di amministrazione individuali anziché uno condiviso, e ruotate la chiave quando qualcuno con accesso al server se ne va — la sezione 06 spiega perché la rotazione costa poco.
Che cosa succede: il guasto più silenzioso e più comune. Qualcuno imposta un backup che spazza via l'intero server, e il file della chiave finisce nello stesso archivio del database. Ora un solo nastro di backup rubato contiene entrambe le metà, la cifratura non protegge nulla e — peggio — starete comunque rivendicando l'esenzione da cifratura in una segnalazione di violazione, perché sulla carta era tutto cifrato.
Perché è difficile: nulla nel sistema in funzione appare diverso. Funziona perfettamente. Il problema esiste solo nel backup, e conta solo il giorno in cui il backup viene rubato.
Che cosa facciamo: è l'unico di questo elenco contro cui in parte abbiamo fatto ingegneria. Dichiarate le vostre directory di backup nella configurazione, e il sistema rifiuta di partire se il file della chiave si trova dentro una di esse. Se non dichiarate alcun percorso di backup, avverte che l'esenzione non può essere verificata — perché una rivendicazione non verificata è quella pericolosa.
Che cosa spetta a voi: dichiarate onestamente le radici di backup, e controllate che cosa includa davvero il vostro strumento di backup anziché che cosa pensiate che includa.
Che cosa succede: una terapeuta apre il fascicolo di un paziente che è anche il suo vicino di casa. Una receptionist cerca una celebrità locale. Ogni regola era soddisfatta — la persona aveva una relazione di cura valida, o motivi validi, e semplicemente ne ha abusato. Qui la cifratura è irrilevante. E lo è anche il controllo degli accessi, perché l'accesso era concesso.
Perché nessun sistema lo risolve: il software non sa leggere le intenzioni. Un sistema che ci provasse — bloccando un accesso perché un nome sembra del posto — bloccherebbe lavoro clinico autentico in un'emergenza, che è un danno a sé e, nel Regno Unito, una violazione di conformità a sé.
Che cosa facciamo: renderlo visibile anziché impossibile. Ogni apertura è registrata prima che il contenuto compaia, in un registro che nessuno può modificare — compresi i vostri amministratori e noi compresi. Le relazioni di cura finiscono, e con esse finisce l'accesso dopo un breve periodo di grazia, quindi la finestra è stretta. L'accesso di emergenza è un atto separato, deliberato e riesaminato anziché una capacità silenziosa.
Che cosa spetta a voi: qualcuno deve davvero dare lettura del registro. Il modulo di governance dà al riesame una casa — cadenza, revisore nominato, pista di constatazioni — ma un registro che nessuno guarda non dissuade nessuno. È il controllo che più spesso esiste sulla carta e non avviene mai.
Che cosa succede: per mostrare un documento a un clinico autorizzato, il software deve decifrarlo. Per quel momento esiste nella memoria del server come testo leggibile. Chi ha il controllo completo del sistema operativo può, in linea di principio, leggerlo lì — o modificare il software perché ne tenga copia.
Perché nessun sistema lo risolve: questo vale per qualunque sistema abbia mai mostrato qualcosa a qualcuno. Se la macchina può mostrare il documento, il padrone della macchina può ottenere il documento. La cifratura protegge i dati a riposo e in transito; non può proteggerli dal computer che li sta lecitamente trattando.
Che cosa facciamo: ridurre al minimo la finestra — la decifratura avviene in memoria per il momento della lettura e il testo in chiaro non viene mai scritto su disco. E auto-ospitare significa che a detenere i privilegi di root siete voi , non noi.
Che cosa spetta a voi: l'amministrazione del server è il ruolo a più alto privilegio che avete. Poche persone, nominate una per una, chiavi anziché password, e una registrazione di chi abbia accesso. Sta nella lista di ingressi e uscite accanto agli account clinici.
Che cosa succede: una regola di conservazione è configurata male, o una cancellazione viene lanciata sulla selezione sbagliata. Le chiavi sono sovrascritte e i documenti sono illeggibili. Non c'è modo di annullare, e ripristinare il backup di ieri notte non aiuta — il backup contiene lo stesso testo cifrato, e la sua chiave non c'è più.
Perché non lo risolviamo: una distruzione reversibile non è una distruzione. Tutto il valore della crypto-cancellazione davanti a un'autorità sta nel fatto che non si può tornare indietro. Un « cestino » per le chiavi distrutte significherebbe che i dati non sono mai stati davvero distrutti, e ogni affermazione di cancellazione che avete fatto sarebbe falsa.
Che cosa facciamo: le chiavi non si possono cancellare per alcuna via ordinaria — l'operazione di cancellazione è bloccata del tutto e la distruzione avviene solo per la via della triturazione, che scrive una voce di audit strada facendo. I blocchi legali sospendono del tutto la distruzione. La conservazione conta da date di ancoraggio memorizzate anziché dall'età del file, quindi la causa più comune di distruzione alla data sbagliata non si presenta.
Che cosa spetta a voi: verificate la configurazione della conservazione prima della messa in esercizio, non dopo la prima esecuzione di distruzione. E confermate che i processi pianificati stiano davvero girando — un processo di conservazione fermatosi in silenzio è un problema diverso, ma si scopre allo stesso modo, cioè troppo tardi.
Che cosa succede: le cartelle di salute mentale si conservano vent'anni e a volte di più. AES-256 non è al momento considerato violabile, nemmeno dai computer quantistici di cui si specula — ma nessun ingegnere onesto promette alcunché sul 2046 restando serio.
Perché nessuno lo risolve: non si può comprare protezione contro un risultato matematico che non è ancora avvenuto. Chi vi vende archiviazione « a prova di quantistico » per cartelle cliniche vi vende una storia.
Che cosa facciamo: rendere sostituibili l'algoritmo e le chiavi senza toccare i vostri dati. La rotazione delle chiavi riavvolge ogni chiave dati sotto una nuova chiave di installazione senza riscrivere un solo byte di testo cifrato, quindi è un'attività di sottofondo anziché un progetto di migrazione. La crittografia è isolata in un unico piccolo componente riesaminabile proprio perché possa essere sostituita quando sarà il momento.
Che cosa spetta a voi: ruotate periodicamente anziché mai, e mettete in conto di ricifrare una volta nella vita di una cartella ventennale. Pianificatelo come manutenzione, non come una crisi.
Guardate che cosa hanno in comune i sette. In ogni caso il « rimedio » che chiuderebbe il rischio — una chiave recuperabile, una distruzione reversibile, un sistema che legge le intenzioni, una protezione contro i vostri stessi amministratori — distruggerebbe qualcosa di più prezioso di ciò che protegge. La scelta di progetto non è che questi rischi siano stati trascurati. È che chiuderli renderebbe false le garanzie rimanenti.
Ciò che resta a voi è poco, preciso e soprattutto procedurale: fate il backup della chiave separatamente, controllate chi può raggiungere il server, dichiarate i percorsi di backup, leggete il registro degli accessi, e verificate una volta le impostazioni di conservazione. Quell'elenco sta in una pagina ed è tutto qui.
Dato che il rischio 1 e il rischio 2 sono le due voci dalle conseguenze più gravi di questa pagina, vale la pena essere precisi su quali parti siano automatiche e quali siano vostre.
| Verifica | Stato | Che cosa succede |
|---|---|---|
| La chiave esiste | ✓ | Verificato all'avvio. Una chiave mancante ferma il sistema anziché lasciarlo girare e fallire più tardi, un documento alla volta, davanti a un paziente. |
| Solo il proprietario può leggerla | ✓ | Una chiave leggibile dal gruppo o da tutti è fatale all'avvio, non un avvertimento in un registro che nessuno legge. |
| Appartiene all'account giusto | ✓ | Verificato rispetto all'account con cui gira il servizio. Una chiave che appartiene all'utenza di un tecnico che se n'è andato è un rilievo. |
| Non è dentro una directory di backup | ✓ | Dichiarate le vostre radici di backup; il sistema rifiuta di partire se la chiave sta dentro una di esse. Se non ne dichiarate nessuna, avverte che l'esenzione da violazione non può essere verificata. |
| Non è in un posto da cui viaggerebbe con i dati | ✓ | Un breve elenco di directory in cui la chiave non deve mai stare è rifiutato senza appello. |
| È una chiave vera | ✓ | Accettata solo come 32 byte grezzi o 64 caratteri esadecimali. Un file troncato o corrotto è rifiutato anziché usato per produrre documenti che nessuno potrà mai aprire. |
| È salvata in backup, separatamente | — | Spetta a voi, e il software non può aiutare. Non possiamo verificare un backup che non ci è permesso vedere, e un sistema che potesse verificare il backup della propria chiave sarebbe un sistema in grado di raggiungerla. Due persone, due posti, ripristino provato. |
| Chi può raggiungere il server | — | Spetta a voi. Chiunque abbia i privilegi di root può leggere la chiave. Quell'elenco dovrebbe essere corto, nominativo, e riesaminato quando le persone se ne vanno. |
| Rotazione quando qualcuno se ne va | ⚙ | Supportata e poco costosa: la rotazione riavvolge ogni chiave dati sotto una nuova chiave di installazione senza riscrivere alcun testo cifrato, e le chiavi superate si possono conservare per svolgere ciò che è ancora in volo. Decidere quando ruotare spetta a voi. Dopo che un amministratore di server se n'è andato è il momento ovvio, ed è quello che più spesso si manca. |
Ogni versione di ogni documento clinico è cifrata con la propria chiave, legata all'identità di quel documento così da non poter essere spostata altrove. Quelle chiavi sono avvolte sotto un'unica chiave di installazione che vive fuori dal database e non lascia mai il vostro server — così un database rubato non è una comunicazione di dati, e la distruzione si fa distruggendo una chiave anziché cancellando una riga. I documenti si aprono solo per chi ha una relazione di cura in corso, e ogni apertura è scritta per prima in un registro concatenato, così l'abuso è visibile anche quando l'accesso era legittimo. Ciò che l'ingegneria non può risolvere è nominato nella sezione 05, e la versione breve della vostra parte è: fate il backup della chiave separatamente, tenete l'accesso al server corto e nominativo, dichiarate i percorsi di backup, leggete il registro, e verificate una volta le impostazioni di conservazione prima della messa in esercizio.
Ogni pagina di paese poggia sulla macchina descritta qui e vi aggiunge la macchina dei diritti e della governance che la propria legge richiede.
