Dokumenttjenesten · kryptering, tilgang, og grensene som er reelle
Hver påstand om etterlevelse på dette nettstedet — den amerikanske, den europeiske, den britiske, den tyske — peker til slutt på ett stykke maskineri: tjenesten som lagrer kliniske dokumenter. Denne siden forklarer hvordan den virker, i vanlig språk, og gjør så noe det meste av leverandørdokumentasjon unngår.
Den lister opp risikoene som ikke har noen teknisk løsning. Ikke de vi løste og gjerne vil fortelle om — de der det ærlige svaret er «dette kan skje, her er hvorfor vi valgte det, og her er hva du må gjøre med det». Leser du bare ett avsnitt, les det.
Se for deg hvert klinisk dokument i en eske med sin egen hengelås, og hver hengelås med sin egen nøkkel. De nøklene er selv låst inn i én safe. Eskene og de små nøklene ligger i databasen din. Safenøkkelen gjør det ikke.
Det er hele designet. Alt under er detaljer oppå det, og følgene er verdt å si før mekanikken:
Den som kopierer hele databasen din får eskene og de innelåste små nøklene. Uten safenøkkelen åpner ingenting av det. Det er dette som gjør krypteringsunntaket i avviksreglene tilgjengelig for deg — du kan hevde at opplysningene var uforståelige, forutsatt at safenøkkelen ikke ble tatt også.
For å slette et dokument ødelegger du den lille nøkkelen. Esken består, tom og ulåsbar for alltid. Det er sterkere enn å slette en rad — en slettet rad kommer tilbake fra sikkerhetskopien i natt, en ødelagt nøkkel gjør det ikke.
Det finnes ingen hovedkopi, ingen depot hos leverandøren, ingen gjenopprettingstjeneste. Er safenøkkelen borte, er hvert klinisk dokument du har borte med den. Dette er med vilje, og avsnitt 05 forklarer hvorfor enhver «løsning» på det ville vært verre enn problemet.
Teknikken heter konvoluttkryptering, og den er den banker og skyleverandører bruker på det samme problemet. Det er tre lag. Grunnen til tre framfor ett står i den tredje kolonnen.
| Lag | Hva det er | Hvorfor det er atskilt |
|---|---|---|
| Dokumentversjonen | Selve filen — en timerapport, en hendelsespost, et identitetsdokument — kryptert med AES-256-GCM. Det krypterte resultatet skrives til en egen mappe på disk, utenfor Odoos vanlige fillagring, og leveres aldri gjennom den vanlige nedlastingsruten. | Å holde kryptotekst utenfor det vanlige filområdet betyr at en feilkonfigurert vevtjener ikke ved et uhell kan publisere kliniske filer, fordi de ikke er der en vevtjener ville lett. |
| Datanøkkelen (DEK) | En ny tilfeldig 256-bits nøkkel, generert for hver versjon av hvert dokument. Ikke per pasient, ikke per dokument — per versjon. Den lagres i databasen, men bare i innpakket form. | Én nøkkel per versjon er det som gjør sletting presis. Å ødelegge en versjons nøkkel sletter nøyaktig den versjonen og ingenting annet, så en retting kan bevares mens originalen slettes, eller omvendt. |
| Installasjonsnøkkelen (KEK) | Én 256-bits nøkkel for hele installasjonen, i en fil på serveren, som pakker inn hver datanøkkel. Den lagres aldri i databasen og forlater aldri serveren. | Dette er skillet som gjør arbeidet. Database og nøkler er forskjellige ting på forskjellige steder med forskjellige sikkerhetskopier, så å få tak i det ene gir deg ikke det andre. |
Seks ting finnes for hver dokumentversjon. De holdes med vilje på forskjellige steder, fordi hele designet hviler på at ingen ett sted har to av dem.
| Delen | Hvor den ligger | Hva det gir deg å ha bare denne |
|---|---|---|
| Selve filen, kryptert | En egen mappe på serveren, lagt opp som
<lager>/<de 2 første av uuid>/<de 2 neste>/<uuid>.enc.v<versjon>. Mapper er bare for eieren, filer lese/skrive for eieren. Utenfor Odoos filstore, så den er ikke tilgjengelig gjennom /web/content og berøres ikke av opprydding av vedlegg. |
Ingenting. Autentisert kryptotekst uten nøkkel. Én fil per versjon, så å arkivere en ny versjon kan ikke overskrive den forrige. |
| Nonce og to hashverdier | I databasen, på versjonsraden: nonce brukt for denne krypteringen, en hash av klarteksten, og en hash av kryptoteksten. | Ingenting i seg selv — men hashen av klarteksten trengs for å bygge bindingen under på nytt, så å miste den gjør kryptoteksten umulig å dekryptere. Det er ved design, ikke en forglemmelse. |
| Datanøkkelen, innpakket | I databasen, kryptert under installasjonsnøkkelen. Den utpakkede formen finnes bare i minnet, så lenge ett oppslag varer, og forkastes umiddelbart etter. | Ingenting uten installasjonsnøkkelen. En stjålet database gir deg innpakkede nøkler og filstier, og ingen av dem åpner noe. |
| Installasjonsnøkkelen | En fil på serveren, lesbar bare for kontoen Odoo kjører som. Aldri i databasen. Aldri i filstoren. Aldri inne i en erklært sikkerhetskopirot — hver av dem kontrolleres ved oppstart og er fatal, ikke en advarsel. | Ingenting uten databasen, som har de innpakkede datanøklene, og uten kryptotekstlageret. Tre atskilte ting trengs, og de holdes på tre steder. |
| Tilgangsreglene | I databasen, som poster — hvem som kan åpne hva, på hvilket grunnlag, og til når. | De avgjør hva en kollega kan åpne. De har ingen virkning på noen som har filene men ikke nøklene, som er tilfellet kryptering er til for. |
| Tilgangsloggen | I databasen, bare-skriv og lenket med hashverdier. Hvert oppslag, ikke bare hver endring. | Oppføringen av hvem som åpnet hva. Den skrives før innholdet gis videre, så en nedlasting noen avbryter er likevel registrert som en tilgang. |
Alt over er lettere å kontrollere mot disse. Det første er hva som skjer når et dokument arkiveres; det andre er hva som skjer når noen ber om å se ett. Les det andre nøye — det er der de fleste systemer er svakere enn de hevder.
En timerapport, en hendelsespost, et identitetsdokument. Den kommer inn i minnet.
32 byte fra operativsystemets kryptografiske tilfeldighetskilde. Ikke utledet av et passord, ikke gjenbrukt fra et annet dokument, ikke gjenbrukt fra forrige versjon av dette dokumentet.
én nøkkel per versjon — dette er det som gjør sletting presisEn SHA-256 av klarteksten, og et 96-bits tall brukt én gang. Ingen funksjon i krypteringskjernen godtar en nonce fra den som kaller den, så den klassiske gjenbruksfeilen kan ikke gjøres her.
AES-256-GCM, med uuid | versjonsnummer | fingeravtrykk av innholdet som tilleggsautentiserte data. Den bindingen er obligatorisk. En kryptotekst som senere kopieres over på et annet dokument eller en annen versjon vil nekte å dekryptere framfor å åpne seg i stillhet under feil persons tilgangsregler.
Kryptert med installasjonsnøkkelen, merket med nøkkelgenerasjonen og nøkkelens navnerom, og lagret i databasen i den formen. Den utpakkede nøkkelen forkastes fra minnet umiddelbart.
Skrevet til en midlertidig fil i målmappen, tømt til den fysiske disken, og så gitt nytt navn på plass — så et havari midt i skrivingen ikke kan etterlate en halvskrevet versjon. Den midlertidige filen inneholder kryptotekst, aldri klartekst.
Lagringssti, nonce, begge hashverdiene, størrelse, og den innpakkede nøkkelen. Aldri klarteksten, aldri en utpakket nøkkel, aldri installasjonsnøkkelen.
Hvem som arkiverte den, når, hvor stor, og hvilken type. Bare-skriv og lenket til oppføringene før den.
En kliniker i backoffice, eller en klient på sin egen journalside. Begge går gjennom de samme kontrollene; ingen av rutene omgår den andres.
På den klientvendte ruten vises ikke journaler til en konto som bare har et passord. Avvisningen sier hva du skal gjøre med det framfor å late som om dokumentet ikke finnes.
En grense per person på den klientvendte ruten. Sagt rett ut, fordi det ikke lekker noe og sparer en støttehenvendelse.
Nekteregler først — én av dem er endelig. Så tillatelsesregler: treffer ingen, er svaret nei. Nødtilgang konsulteres bare på det punktet, så den kan nå det som aldri ble gitt, men kan ikke oppheve en avvisning. Følsomhetsmerker anvendes til sist og kan bare ta tilgang bort.
lukket som standard · det finnes ingen superbrukergren i denne kontrollenOppføringen skrives først, så en overføring noen avbryter halvveis står likevel på oppføringen som en tilgang. Loggen er bare-skriv og lenket med hashverdier; oppføringer kan ikke fjernes i stillhet etterpå, verken av oss eller av din egen administrator.
Før noen nøkkel berøres. Ødelagte data i lageret rapporteres da som ødelagte data, framfor å komme fram senere som en forvirrende autentiseringsfeil.
Brukt til å pakke ut denne versjonens datanøkkel, med kontroll av nøkkelgenerasjon og navnerom underveis. En nøkkel innpakket for ett navnerom kan ikke pakkes ut som et annet selv av noen som har begge installasjonsnøklene.
Dokumentets identifikator, versjonsnummeret og fingeravtrykket av innholdet bygges på nytt og må stemme. Manipulering, en feil nøkkel, og en kryptotekst flyttet fra en annen post feiler alle her — og alle feiler likt, for å fortelle en angriper hvilken del som feilet er gratis informasjon.
Datanøkkelen slippes fra minnet. Ingen kodevei i dette produktet skriver en dekryptert byte til disk — ikke for forhåndsvisninger, ikke for miniatyrbilder, ikke for søkeindeksering.
En slettet versjon melder at nøkkelen dens ikke finnes lenger. Det finnes ingen reserveløsning, ingen hurtiglagret kopi og ingen gjenopprettingsvei, som er hele poenget med å slette den på den måten.
Én nøkkel beskytter hver datanøkkel i installasjonen, så håndteringen av den er delen det er verdt å kontrollere linje for linje. Alle kontrollene under kjører ved oppstart og alle er fatale — serveren starter ikke framfor å kjøre med en beskyttelse du tror du har og ikke har.
32 byte fra operativsystemets tilfeldighetskilde, skrevet til en fil opprettet med lesetilgang bare for eieren i én operasjon, så den aldri er kortvarig lesbar for andre.
Filen må inneholde enten 32 rå byte eller 64 heksadesimale tegn. Ingenting annet godtas — en passfrase avvises framfor å strekkes til en nøkkel, fordi en strukket passfrase er en svakere nøkkel som ser ut som en sterkere.
Ikke i databasen. Ikke i Odoos datamappe, dens addons-sti eller dens filstore. Ikke inne i kryptotekstlageret. Ikke inne i noen mappe du har erklært som en sikkerhetskopirot.
Den siste er den folk gjør feil. En sikkerhetskopi som har både databasen og nøkkelen er en kompromittert nøkkel, og den setter installasjonen utenfor den amerikanske trygge havnen ved avvik og det europeiske unntaket i art. 34 nr. 3 bokstav a — som er hele grunnen til at krypteringen er her.
Å rotere installasjonsnøkkelen pakker datanøklene inn på nytt og skriver ikke om en eneste byte kryptotekst. Hundre tusen dokumenter roterer så fort hundre nøkler kan krypteres på nytt, ikke så fort hundre tusen filer kan skrives om.
Generasjonsnummeret ligger inne i innpakningen, så en nøkkel innpakket under den gamle generasjonen ikke kan åpnes i stillhet som om den var den nye.
Å slette en versjon overskriver dens innpakkede nøkkel med tilfeldige byte framfor å tømme feltet, så det er ingenting igjen å gjenopprette selv fra databasesiden.
Versjonens metadataskall og hele tilgangsloggen består — du kan fortsatt vise at du hadde dokumentet og slettet det riktig. En versjon kan ikke slettes mens nøkkelen dens fortsatt finnes, så rekkefølgen kan aldri bli den gale.
Dette er stedene der kryptering vanligvis er implementert nesten riktig, og nesten er hele forskjellen.
Når en versjon krypteres, knyttes krypteringen til dokumentets identifikator, versjonsnummeret og et fingeravtrykk av innholdet. Kryptografer kaller dette tilleggsautentiserte data, og det er obligatorisk her — ingen som kaller funksjonen kan hoppe over det.
Virkningen: en kryptotekst kopiert over på et annet dokument, eller en annen versjon, nekter å dekryptere. Den åpner seg ikke i stillhet under feil pasients tilgangsregler — som er nettopp angrepet et system uten denne bindingen er utsatt for.
AES-GCM er katastrofalt svak hvis samme nonce brukes to ganger med samme nøkkel: en angriper som ser to slike kryptotekster kan hente ut informasjon fra begge. Det er den klassiske implementasjonsfeilen.
Her genererer hver kryptering sin egen nonce, og ingen funksjon godtar en nonce fra den som kaller den. Feilen gjøres ikke vanskeligere å gjøre; den gjøres umulig å gjøre.
Krypteringskjernen er skrevet som et frittstående stykke uten avhengighet til applikasjonsrammeverket, slik at den som reviderer krypteringspåstanden kan lese og teste den for seg uten å kjøre et klinikksystem.
Vil sikkerhetsfolkene dine kontrollere påstandene på denne siden framfor å tro på dem, er det filen å gi dem, og den er kort.
Der loven skiller en terapeuts egne prosessnotater fra den kliniske journalen — det amerikanske unntaket for psykoterapinotater er det klareste tilfellet — krypteres de notatene under en annen, egen installasjonsnøkkel. Nøkkelen som åpner den vanlige journalen åpner dem ikke.
Dette betyr noe fordi det gjør skillet til en egenskap ved lagringen framfor ved tilgangsreglene. Var hver rettighet i systemet feil i morgen, ville den vanlige nøkkelen fortsatt ikke dekryptere de notatene. Det betyr også at den andre nøkkelen må være satt opp før driftsstart: å arkivere et slikt notat uten den feiler framfor å falle stille tilbake på hovednøkkelen, for et stille tilbakefall ville ødelagt skillet uten at noen la merke til det.
De to blandes ofte. Kryptering verner mot noen som ikke skal være i systemet i det hele tatt. Den gjør ingenting med det langt vanligere problemet: noen som er i systemet, og ser på en journal de ikke har noe med å lese.
Det er hva autorisasjonslaget er til for, og det virker etter et annet prinsipp enn de fleste systemer: tilgang følger behandlingsrelasjonen, ikke stillingstittelen.
Hver gang. Ikke én gang ved innlogging.
Sagt uttrykkelig, fordi revisorer spør
En kliniker trenger av og til reelt en journal de ikke har noen relasjon til — en krise, en vakttelefon, en kollega som er blitt syk. Der virksomheten din tillater det, finnes nødtilgang. Å bruke den åpner en registrert økt som gjennomgås etterpå.
Et system som bare nekter er utrygt på sin egen måte, og i Storbritannia er det uttrykkelig ikke i samsvar med regelverket: Caldicott-prinsipp 7 gjør plikten til å dele like viktig som plikten til å verne. Så tilgangen finnes, og bruken av den er aldri stille.
Mot en dokumenttype — den typen er det som avgjør reglene, oppbevaringstiden og hvem som kan åpne den.
Med vanlige ord, før den lagres. Det meste av feilarkivering skjer fordi ingen visste hvor et dokument ville havne.
Bundet til dette dokumentet, denne versjonen, og et fingeravtrykk av dette innholdet.
Den utpakkede nøkkelen finnes bare i minnet, i det øyeblikket den trengs.
Med egne rettigheter, i sin egen mappe.
Hver åpning logget før innholdet vises.
Som en ny versjon, med sin egen nye nøkkel. Originalen er urørt og fortsatt lesbar — en journal som kan endres er verdiløs som bevis.
Den nekter å dekryptere, fordi krypteringen er bundet til det opprinnelige dokumentets identitet.
Fra relasjonens slutt — ikke fra dagen filen ble opprettet.
Nøkkelmaterialet overskrives med tilfeldige byte, og så slettes nøkkelraden. Å overskrive først er med vilje: blir prosessen avbrutt, er feilmodusen et dokument som ikke kan leses, aldri ett som består når det ikke skulle.
Du kan fortsatt vise at journalen fantes, hvem som så den gjennom tjue år, og at den ble slettet etter planen. Innholdet er uleselig for alle, permanent, inkludert oss.
Alt over er hva systemet gjør godt. Dette avsnittet er det motsatte: stedene der noe vondt kan skje og ingen mengde ingeniørarbeid lukker det — fordi lukkingen ville koste mer beskyttelse enn den kjøper.
Hver av dem sier hva som faktisk skjer, hva vi gjør med det, og hva som blir igjen hos deg. Sier en leverandør at krypteringen deres ikke har noen av disse, har de enten ikke tenkt på det eller håper at du ikke gjør det.
Hva som skjer: nøkkelfilen slettes, disken svikter, serveren bygges opp på nytt uten den, eller den ene personen som visste hvor den var har sluttet. Hvert klinisk dokument i systemet blir permanent uleselig. Ikke vanskelig å gjenopprette — umulig. Databasen er intakt og verdiløs.
Hvorfor vi ikke løser det: de eneste løsningene er en kopi hos leverandøren eller en bakdør for gjenoppretting. Begge ødelegger egenskapen hele designet finnes for. Hadde vi hatt en kopi, ville «en stjålet database er ikke et avvik» sluttet å være sant, og hvert løfte på denne siden om hva vi ikke kan se ville blitt usant. En nøkkel som kan gjenopprettes er en nøkkel noen andre kan bruke.
Hva vi gjør: systemet nekter å starte hvis nøkkelen mangler, framfor å kjøre i stillhet og la deg oppdage problemet når et dokument ikke vil åpne seg. Oppstartskontrollen nekter også hvis nøkkelfilen er lesbar for andre enn eieren, eller eid av feil konto.
Hva som er ditt: ta sikkerhetskopi av nøkkelen, atskilt fra opplysningene, og prøv at du kan gjenopprette den. To personer bør vite hvor den er. Dette er den enkeltvis mest konsekvenstunge driftsplikten i hele plattformen, og den tar omtrent ti minutter å gjøre riktig.
Hva som skjer: en administrator sender nøkkelfilen på e-post til en kollega, limer den inn i en sak, kopierer den til en bærbar maskin, eller en utvikler som slutter beholder en kopi. Enhver som har både den filen og en kopi av databasen kan dekryptere hvert dokument, uten nett, uten innlogging, og ingenting skrives til tilgangsloggen din — fordi loggen registrerer oppslag gjennom applikasjonen, og dette omgår applikasjonen helt.
Hvorfor vi ikke løser det: nøkkelen må være lesbar for programvaren som bruker den. Enhver prosess som kan lese den, kan kopiere den. Maskinvaresikkerhetsmoduler flytter dette problemet framfor å løse det — programvaren må fortsatt kunne be modulen om å pakke ut nøkler, så en angriper med den programvarens rettigheter får fortsatt klartekst.
Hva vi gjør: filrettighetene håndheves ved oppstart, så en nøkkel som er lesbar for alle stanser systemet framfor å passere ubemerket. Og fordi du drifter selv, har vi aldri filen i det hele tatt — gruppen av mennesker som kunne kopiere den er dine ansatte, ikke dine ansatte pluss våre.
Hva som er ditt: behandle nøkkelen som en kontrollert fysisk gjenstand. Begrens hvem som kan logge på serveren, bruk personlige administratorkontoer framfor en delt, og roter nøkkelen når noen med servertilgang slutter — avsnitt 06 forklarer hvorfor rotering er billig.
Hva som skjer: den stilleste og vanligste svikten. Noen setter opp en sikkerhetskopi som sveiper hele serveren, og nøkkelfilen ligger inne i samme arkiv som databasen. Nå inneholder ett stjålet sikkerhetskopibånd begge halvdelene, krypteringen beskytter ingenting, og — verre — du ville fortsatt hevdet krypteringsunntaket i en avviksrapport, fordi på papiret var alt kryptert.
Hvorfor det er vanskelig: ingenting med systemet i drift ser annerledes ut. Det virker perfekt. Problemet finnes bare i sikkerhetskopien, og betyr bare noe den dagen sikkerhetskopien blir stjålet.
Hva vi gjør: dette er den ene i denne listen vi delvis har bygget vern mot. Du erklærer sikkerhetskopimappene dine i konfigurasjonen, og systemet nekter å starte hvis nøkkelfilen ligger inne i en av dem. Erklærer du ingen sikkerhetskopistier i det hele tatt, advarer det om at unntaket ikke kan kontrolleres — for en ukontrollert påstand er den farlige typen.
Hva som er ditt: erklær sikkerhetskopirøttene ærlig, og kontroller hva sikkerhetskopiverktøyet ditt faktisk tar med framfor hva du tror det tar med.
Hva som skjer: en terapeut åpner journalen til en klient som også er naboen deres. En resepsjonist slår opp en lokal kjendis. Hver regel var oppfylt — personen hadde en gyldig behandlingsrelasjon, eller gyldig grunnlag, og misbrukte det rett og slett. Kryptering er irrelevant her. Det er tilgangsstyring også, fordi tilgangen ble gitt.
Hvorfor ingen system løser det: programvare kan ikke lese hensikt. Et system som prøvde — og blokkerte tilgang fordi et navn ser lokalt ut — ville blokkert reelt klinisk arbeid i en nødssituasjon, som er sin egen skade og, i Storbritannia, sin egen etterlevelsessvikt.
Hva vi gjør: gjør det synlig framfor umulig. Hver åpning registreres før innholdet vises, i en logg ingen kan endre — inkludert administratorene dine og inkludert oss. Behandlingsrelasjoner tar slutt, og tilgangen tar slutt med dem etter en kort frist, så vinduet er smalt. Nødtilgang er en egen, bevisst, gjennomgått handling framfor en stille mulighet.
Hva som er ditt: noen må faktisk oppslag loggen. Styringsmodulen gir gjennomgangen et hjem — rytme, navngitt ansvarlig, spor av funn — men en logg ingen ser på avskrekker ingen. Dette er kontrollen som oftest finnes på papiret og aldri skjer.
Hva som skjer: for å vise et dokument til en autorisert kliniker må programvaren dekryptere det. I det øyeblikket finnes det i serverens minne som lesbar tekst. Noen med full kontroll over operativsystemet kan i prinsippet lese det der — eller endre programvaren til å beholde kopier.
Hvorfor ingen system løser det: dette er sant for hvert system som noen gang viser noe til noen. Kan maskinen vise dokumentet, kan maskinens eier skaffe seg dokumentet. Kryptering verner opplysninger i ro og under overføring; den kan ikke verne opplysninger mot datamaskinen som rettmessig behandler dem.
Hva vi gjør: gjøre vinduet minst mulig — dekrypteringen skjer i minnet i det øyeblikket oppslaget varer, og klarteksten skrives aldri til disk. Og egen drift betyr at du er den som har rot, ikke vi.
Hva som er ditt: serveradministrasjon er den rollen med høyest rettigheter du har. Få mennesker, navngitt hver for seg, nøkler og ikke passord, og en oppføring over hvem som har tilgang. Det hører på sjekklisten for nyansatte og avganger ved siden av de kliniske kontoene.
Hva som skjer: en oppbevaringsregel er satt opp feil, eller en makulering kjøres på feil utvalg. Nøklene overskrives og dokumentene er uleselige. Det finnes ingen angremulighet, og å gjenopprette sikkerhetskopien fra i natt hjelper ikke — sikkerhetskopien inneholder den samme kryptoteksten, og nøkkelen dens er borte.
Hvorfor vi ikke løser det: en sletting som kan reverseres er ikke en sletting. Hele verdien av kryptomakulering overfor et tilsyn er at den ikke kan gås tilbake på. En «papirkorg» for ødelagte nøkler ville betydd at opplysningene aldri var reelt ødelagt, og hver slettepåstand du har framsatt ville vært usann.
Hva vi gjør: nøkler kan ikke slettes gjennom noen vanlig vei — sletteoperasjonen er blokkert helt, og sletting skjer bare gjennom makuleringsruten, som skriver en revisjonsoppføring underveis. Rettslige sperrer suspenderer sletting helt. Oppbevaring regnes fra lagrede ankerdatoer framfor fra filalder, så den vanligste årsaken til sletting på feil dato oppstår ikke.
Hva som er ditt: kontroller oppbevaringskonfigurasjonen før driftsstart, ikke etter den første slettekjøringen. Og bekreft at de planlagte jobbene faktisk kjører — en slettejobb som stanset i stillhet er et annet problem, men det oppdages på samme måte, som er å si for sent.
Hva som skjer: journaler innen psykisk helse bevares i tjue år og av og til lenger. AES-256 regnes ikke i dag som mulig å bryte, heller ikke med kvantemaskinene folk spekulerer om — men ingen ærlig ingeniør lover noe om 2046 med rett ansikt.
Hvorfor ingen løser det: du kan ikke kjøpe vern mot et matematisk resultat som ikke har skjedd ennå. Den som selger «kvantesikker» lagring for kliniske journaler, selger en historie.
Hva vi gjør: gjøre algoritmen og nøklene utbyttbare uten å berøre opplysningene dine. Nøkkelrotering pakker hver datanøkkel inn på nytt under en ny installasjonsnøkkel uten å skrive om en eneste byte kryptotekst, så det er en bakgrunnsoppgave framfor et migrasjonsprosjekt. Kryptografien er isolert i én liten, gjennomgåelig komponent nettopp for at den skal kunne byttes ut når tiden kommer.
Hva som er ditt: roter med jevne mellomrom framfor aldri, og regn med å kryptere på nytt én gang i løpet av livet til en tjueårsjournal. Planlegg for det som vedlikehold, ikke som en krise.
Se på hva de sju har til felles. I hvert tilfelle ville «løsningen» som lukket risikoen — en nøkkel som kan gjenopprettes, en sletting som kan reverseres, et system som leser hensikt, vern mot dine egne administratorer — ødelagt noe mer verdifullt enn den verner. Designvalget er ikke at disse risikoene ble oversett. Det er at å lukke dem ville gjort de gjenstående garantiene usanne.
Det som blir igjen for deg er lite, konkret og stort sett prosedyre: ta sikkerhetskopi av nøkkelen for seg, kontroller hvem som kan nå serveren, erklær sikkerhetskopistiene dine, les tilgangsloggen, og kontroller oppbevaringsinnstillingene én gang. Den listen går inn på én side, og det er hele den.
Siden risiko 1 og risiko 2 er de to mest konsekvenstunge punktene på denne siden, er det verdt å være presis om hvilke deler som er automatiske og hvilke som er dine.
| Kontroll | Status | Hva som skjer |
|---|---|---|
| Nøkkelen finnes | ✓ | Kontrollert ved oppstart. En manglende nøkkel stanser systemet framfor å la det kjøre og svikte senere, ett dokument om gangen, foran en pasient. |
| Bare eieren kan lese den | ✓ | En nøkkel som er lesbar for gruppen eller for alle er fatal ved oppstart, ikke en advarsel i en logg ingen leser. |
| Den eies av riktig konto | ✓ | Kontrollert mot kontoen tjenesten kjører som. En nøkkel eid av innloggingen til en utvikler som har sluttet er et funn. |
| Den ligger ikke inne i en sikkerhetskopimappe | ✓ | Du erklærer sikkerhetskopirøttene dine; systemet nekter å starte hvis nøkkelen ligger inne i en av dem. Erklærer du ingen, advarer det om at unntaket ved avvik ikke kan kontrolleres. |
| Den ligger ikke et sted der den ville reist med opplysningene | ✓ | En kort liste over mapper nøkkelen aldri får ligge i, avvises rett ut. |
| Den er en virkelig nøkkel | ✓ | Godtas bare som 32 rå byte eller 64 heksadesimale tegn. En avkortet eller ødelagt fil avvises framfor å brukes til å lage dokumenter ingen noen gang kan åpne. |
| Den er sikkerhetskopiert, for seg | — | Ditt, og programvaren kan ikke hjelpe. Vi kan ikke kontrollere en sikkerhetskopi vi ikke har lov til å se, og et system som kunne kontrollere sin egen nøkkelkopi ville vært et system som kan nå den. To personer, to steder, prøvd gjenoppretting. |
| Hvem som kan nå serveren | — | Ditt. Enhver med rot kan lese nøkkelen. Den listen bør være kort, navngitt, og gjennomgått når folk slutter. |
| Rotering når noen slutter | ⚙ | Støttet og billig: rotering pakker hver datanøkkel inn på nytt under en ny installasjonsnøkkel uten å skrive om noen kryptotekst, og erstattede nøkler kan beholdes for å pakke ut det som fortsatt er underveis. Å bestemme når det skal roteres, er ditt. Etter at en serveradministrator har sluttet er det åpenbare øyeblikket, og det er det som oftest blir glemt. |
Hver versjon av hvert klinisk dokument krypteres med sin egen nøkkel, bundet til dokumentets identitet slik at den ikke kan flyttes andre steder. De nøklene pakkes inn under én installasjonsnøkkel som ligger utenfor databasen og aldri forlater serveren din — så en stjålet database er ikke en utlevering, og sletting gjøres ved å ødelegge en nøkkel framfor å slette en rad. Dokumenter åpnes bare for folk med en gjeldende behandlingsrelasjon, og hver åpning skrives til en lenket logg først, så misbruk er synlig også når tilgangen var rettmessig. Det som ikke kan løses med ingeniørarbeid, er navngitt i avsnitt 05, og kortversjonen av din side av det er: ta sikkerhetskopi av nøkkelen for seg, hold servertilgangen kort og navngitt, erklær sikkerhetskopistiene dine, les loggen, og kontroller oppbevaringsinnstillingene én gang før driftsstart.
Hver landside hviler på maskineriet som er beskrevet her, og legger til det rettighets- og styringsmaskineriet dens egen rett krever.
