Dokumenttjänsten · kryptering, åtkomst och de gränser som är verkliga
Varje påstående om regelefterlevnad på den här webbplatsen – det amerikanska, det europeiska, det brittiska, det tyska – pekar till slut på en enda maskin: tjänsten som lagrar kliniska dokument. Den här sidan förklarar hur den fungerar, på vanlig svenska, och gör sedan något som de flesta leverantörers dokumentation undviker.
Den listar riskerna som inte har någon teknisk lösning. Inte de vi löst och gärna berättar om – utan de där det ärliga svaret är ”det här kan hända, här är varför vi valde det, och här är vad du måste göra åt det”. Läser du bara ett avsnitt, läs det.
Tänk dig varje kliniskt dokument i en låda med ett eget hänglås, och varje hänglås med en egen nyckel. De nycklarna ligger i sin tur inlåsta i ett kassaskåp. Dokumenten och de små nycklarna finns i din databas. Kassaskåpets nyckel gör det inte.
Det är hela designen. Allt nedan är detaljer ovanpå den, och följderna är värda att säga innan mekaniken:
Den som kopierar hela din databas får lådorna och de inlåsta små nycklarna. Utan kassaskåpets nyckel öppnas inget av det. Det är det som gör krypteringsundantaget i reglerna om personuppgiftsincidenter tillgängligt för dig – du kan hävda att uppgifterna var obegripliga, förutsatt att kassaskåpets nyckel inte också togs.
För att gallra ett dokument förstör du dess lilla nyckel. Lådan finns kvar, tom och för alltid omöjlig att öppna. Det är starkare än att radera en rad – en raderad rad kommer tillbaka från gårdagens säkerhetskopia, en förstörd nyckel gör det inte.
Det finns ingen huvudkopia, ingen deposition hos leverantören, ingen återställningstjänst. Är kassaskåpets nyckel borta är varje kliniskt dokument du har borta med den. Det är avsiktligt, och avsnitt 05 förklarar varför varje ”lösning” på det vore värre än problemet.
Tekniken kallas kuvertkryptering, och det är den banker och molnleverantörer använder för samma problem. Det finns tre lager. Skälet till tre i stället för ett står i tredje kolumnen.
| Lager | Vad det är | Varför det hålls separat |
|---|---|---|
| Dokumentversionen | Själva filen – en samtalsrapport, en incidentrapport, en identitetshandling – krypterad med AES-256-GCM. Det krypterade resultatet skrivs till en egen katalog på disken, utanför Odoos vanliga fillagring, och serveras aldrig via den vanliga nedladdningsvägen. | Att hålla chiffertexten borta från det vanliga filområdet innebär att en felkonfigurerad webbserver inte av misstag kan publicera kliniska filer, eftersom de inte ligger där en webbserver skulle leta. |
| Datanyckeln (DEK) | En ny slumpmässig 256-bitarsnyckel, genererad för varje version av varje dokument. Inte per patient, inte per dokument – per version. Den sparas i databasen, men bara i inslagen form. | En nyckel per version är det som gör gallringen exakt. Att förstöra en versions nyckel gallrar exakt den versionen och inget annat, så en rättelse kan behållas medan originalet gallras, eller tvärtom. |
| Driftsättningsnyckeln (KEK) | En 256-bitarsnyckel för hela installationen, i en fil på servern, som slår in varje datanyckel. Den sparas aldrig i databasen och lämnar aldrig servern. | Det här är separationen som gör jobbet. Databas och nycklar är olika saker på olika ställen med olika säkerhetskopior, så att få tag i det ena ger dig inte det andra. |
Sex saker finns för varje dokumentversion. De hålls avsiktligt på olika ställen, eftersom hela designen vilar på att inget enskilt ställe har två av dem.
| Delen | Var den förvaras | Vad du får om du bara har den |
|---|---|---|
| Själva filen, krypterad | En egen katalog på servern, ordnad som
<store>/<first 2 of uuid>/<next 2>/<uuid>.enc.v<version>. Katalogerna är bara för ägaren, filerna läs/skriv för ägaren. Utanför Odoos filarkiv, så den kan inte nås via /web/content och berörs inte av städningen av bilagor. |
Ingenting. Autentiserad chiffertext utan nyckel. En fil per version, så en ny version kan inte skriva över den före. |
| Nonce och två hashvärden | I databasen, på versionsraden: den nonce som användes för krypteringen, en hash av klartexten och en hash av chiffertexten. | Ingenting i sig – men klartextens hash behövs för att återskapa bindningen nedan, så om den går förlorad går chiffertexten inte att dekryptera. Det är avsiktligt, inte ett förbiseende. |
| Datanyckeln, inslagen | I databasen, krypterad med driftsättningsnyckeln. Den uppackade formen finns bara i minnet, under en enda läsning, och kastas direkt efteråt. | Ingenting utan driftsättningsnyckeln. En stulen databas ger dig inslagna nycklar och sökvägar till chiffertext, och inget av dem öppnar något. |
| Driftsättningsnyckeln | En fil på servern, läsbar bara för kontot som Odoo körs som. Aldrig i databasen. Aldrig i filarkivet. Aldrig inuti en angiven rot för säkerhetskopior – var och en av dessa kontrolleras vid start och stoppar systemet, det är ingen varning. | Ingenting utan databasen, som håller de inslagna datanycklarna, och utan chiffertextlagret. Tre skilda saker behövs, och de förvaras på tre ställen. |
| Åtkomstreglerna | I databasen, som poster – vem som får öppna vad, på vilken grund och till när. | De avgör vad en kollega kan öppna. De har ingen verkan på någon som har filerna men inte nycklarna, vilket är fallet krypteringen finns till för. |
| Åtkomstloggen | I databasen, endast tillägg och hashkedjad. Loggar varje gång någon vill läsa, inte bara ändra. | Registret över vem som öppnade vad. Det skrivs innan innehållet lämnas ut, så en nedladdning som någon avbryter registreras ändå som en åtkomst. |
Allt ovan är lättare att kontrollera mot de här. Det första är vad som händer när ett dokument lämnas in; det andra är vad som händer när någon ber att få se ett. Läs det andra noga – det är där de flesta system är svagare än de påstår.
En samtalsrapport, en incidentrapport, en identitetshandling. Den hamnar i minnet.
32 byte från operativsystemets kryptografiska slumpkälla. Inte härledd från ett lösenord, inte återanvänd från ett annat dokument, inte återanvänd från föregående version av just det här dokumentet.
en nyckel per version – det är det som gör gallringen exaktEn SHA-256 av klartexten, och ett 96-bitarstal som används en gång. Ingen funktion i krypteringskärnan tar emot en nonce från den som anropar, så det klassiska misstaget att återanvända den kan inte göras här.
AES-256-GCM, med uuid | versionsnummer | innehållets fingeravtryck som ytterligare autentiserade data. Bindningen är obligatorisk. En chiffertext som senare kopieras till ett annat dokument eller en annan version vägrar att dekrypteras i stället för att i tysthet öppnas under fel persons åtkomstregler.
Krypterad med driftsättningsnyckeln, märkt med nyckelgeneration och nyckelnamnrymd, och sparad i databasen i den formen. Den uppackade nyckeln kastas ur minnet direkt.
Skrivs till en temporär fil i målkatalogen, töms till den fysiska disken och döps sedan om på plats – så en krasch mitt i en skrivning kan inte lämna en halvskriven version. Den temporära filen innehåller chiffertext, aldrig klartext.
Sökväg, nonce, båda hashvärdena, storlek och den inslagna nyckeln. Aldrig klartexten, aldrig en uppackad nyckel, aldrig driftsättningsnyckeln.
Vem som lämnade in det, när, hur stort och vilken typ. Endast tillägg, och kedjat till posterna före.
En behandlare i backoffice, eller en klient på sin egen sida med uppgifter. Båda går igenom samma kontroller; ingen av vägarna kringgår den andras.
På vägen som klienten använder visas uppgifter inte för ett konto som bara har ett lösenord. Avslaget säger vad man kan göra åt det i stället för att låtsas att dokumentet inte finns.
En hastighetsgräns per person på vägen som klienten använder. Sägs rakt ut, eftersom det inte röjer något och sparar ett supportsamtal.
Nekande regler först – en enda är slutgiltig. Sedan tillåtande regler: om ingen matchar är svaret nej. Nödåtkomst beaktas först i det läget, så den kan nå sådant som aldrig beviljats men kan inte upphäva ett nej. Känslighetsetiketter tillämpas sist och kan bara ta bort åtkomst.
stängt som standard · det finns ingen superanvändargren i den här kontrollenPosten skrivs först, så en överföring som någon avbryter halvvägs finns ändå registrerad som en åtkomst. Loggen är endast tillägg och hashkedjad; poster kan inte i tysthet tas bort efteråt, varken av oss eller av er egen administratör.
Innan någon nyckel rörs. Skador i lagret rapporteras då som skador, i stället för att senare dyka upp som ett förvirrande autentiseringsfel.
Används för att packa upp den här versionens datanyckel, med kontroll av nyckelgeneration och namnrymd på vägen. En nyckel inslagen för en namnrymd kan inte packas upp som en annan inte ens av någon som har båda driftsättningsnycklarna.
Dokumentets identifierare, versionsnummer och innehållets fingeravtryck återskapas och måste stämma. Manipulering, fel nyckel och en chiffertext flyttad från en annan post misslyckas alla här – och alla misslyckas likadant, eftersom det är gratis information att berätta för en angripare vilken del som misslyckades.
Datanyckeln tas bort ur minnet. Ingen kodväg i den här produkten skriver en dekrypterad byte till disken – inte för förhandsvisningar, inte för miniatyrer, inte för sökindexering.
En gallrad version rapporterar att dess nyckel inte längre finns. Det finns ingen reserv, ingen cachad kopia och ingen återställningsväg, vilket är poängen med att gallra på det sättet.
En nyckel skyddar varje datanyckel i installationen, så hanteringen av den är den del som är värd att kontrollera rad för rad. Alla kontroller nedan körs vid start och alla stoppar systemet – servern startar inte hellre än att köra med ett skydd du tror att du har och inte har.
32 byte från operativsystemets slumpkälla, skrivna till en fil som skapas med läsrätt bara för ägaren i ett enda steg, så den aldrig ens för ett ögonblick är läsbar för någon annan.
Filen måste innehålla antingen 32 råa byte eller 64 hexadecimala tecken. Inget annat accepteras – en lösenfras avvisas i stället för att sträckas ut till en nyckel, eftersom en utsträckt lösenfras är en svagare nyckel som ser ut som en starkare.
Inte i databasen. Inte i Odoos datakatalog, dess sökväg för tillägg eller dess filarkiv. Inte inuti chiffertextlagret. Inte inuti någon katalog du har angett som rot för säkerhetskopior.
Det sista är det folk gör fel. En säkerhetskopia som innehåller både databasen och nyckeln är en röjd nyckel, och den placerar driftsättningen utanför den amerikanska safe harbour-regeln för incidenter och det europeiska undantaget i art. 34.3 a – vilket är hela skälet till att krypteringen finns här.
Att rotera driftsättningsnyckeln slår in datanycklarna på nytt och skriver inte om en enda byte chiffertext. Hundratusen dokument roteras lika snabbt som hundra nycklar kan krypteras om, inte lika snabbt som hundratusen filer kan skrivas om.
Generationsnumret finns inuti inslagningen, så en nyckel inslagen under den gamla generationen kan inte i tysthet öppnas som om den vore den nya.
Att gallra en version skriver över dess inslagna nyckel med slumpmässiga byte i stället för att tömma fältet, så det finns inget kvar att återskapa ens från databassidan.
Versionens metadataskal och hela åtkomstloggen finns kvar – du kan fortfarande bevisa att du hade dokumentet och gallrade det korrekt. En version kan inte raderas medan dess nyckel fortfarande finns, så ordningen kan aldrig bli fel.
Det här är ställena där kryptering oftast är nästan rätt implementerad, och nästan är hela skillnaden.
När en version krypteras knyts krypteringen till dokumentets identifierare, dess versionsnummer och ett fingeravtryck av innehållet. Kryptografer kallar det ytterligare autentiserade data, och det är obligatoriskt här – ingen som anropar kan hoppa över det.
Effekten: en chiffertext som kopieras till ett annat dokument, eller en annan version, vägrar att dekrypteras. Den öppnas inte i tysthet under fel patients åtkomstregler – vilket är precis den attack ett system utan den här bindningen är utsatt för.
AES-GCM är katastrofalt svagt om samma nonce används två gånger med samma nyckel: en angripare som ser två sådana chiffertexter kan få fram information ur båda. Det är det klassiska implementationsmisstaget.
Här genererar varje kryptering sin egen nonce och ingen funktion tar emot en nonce från den som anropar. Misstaget görs inte svårare att begå; det görs omöjligt att begå.
Krypteringskärnan är skriven som en fristående del utan beroende av applikationsramverket, så att den som granskar krypteringspåståendet kan läsa och testa den för sig utan att köra ett mottagningssystem.
Vill ert säkerhetsteam verifiera påståendena på den här sidan i stället för att tro på dem är det den filen ni ska ge dem, och den är kort.
Där lagen skiljer en terapeuts egna processanteckningar från journalen – det amerikanska undantaget för psychotherapy notes är det tydligaste fallet – krypteras de anteckningarna under en andra, annan driftsättningsnyckel. Nyckeln som öppnar den vanliga journalen öppnar inte dem.
Det spelar roll eftersom det gör separationen till en egenskap hos lagringen snarare än hos åtkomstreglerna. Om varje behörighet i systemet vore fel i morgon skulle den vanliga nyckeln ändå inte dekryptera de anteckningarna. Det innebär också att den andra nyckeln måste vara konfigurerad före driftstart: att lämna in en sådan anteckning utan den misslyckas i stället för att i tysthet falla tillbaka på huvudnyckeln, eftersom en tyst reserv skulle förstöra separationen utan att någon märkte det.
De två blandas ofta ihop. Kryptering skyddar mot någon som inte borde vara i systemet alls. Den gör ingenting åt det mycket vanligare problemet: någon som finns i systemet och tittar på en uppgift de inte har med att göra.
Det är det behörighetslagret är till för, och det bygger på en annan princip än de flesta system: åtkomst följer behandlingsrelationen, inte yrkestiteln.
Varje gång. Inte en gång vid inloggningen.
Sagt uttryckligen, eftersom granskare frågar
En behandlare behöver ibland verkligen en uppgift de inte har någon relation till – en kris, ett samtal utanför kontorstid, en kollega som blivit sjuk. Där er organisation tillåter det finns nödåtkomst. Att använda den öppnar en registrerad session som granskas i efterhand.
Ett system som bara nekar är osäkert på sitt eget sätt, och i Storbritannien uttryckligen inte förenligt med reglerna: Caldicott-princip 7 gör skyldigheten att dela lika viktig som skyldigheten att skydda. Så åtkomsten finns, och användningen av den sker aldrig i det tysta.
Mot en dokumenttyp – den typen avgör reglerna, lagringstiden och vem som får öppna den.
Med enkla ord, innan den sparas. Den mesta felaktiga inlämningen sker för att ingen visste var ett dokument skulle hamna.
Bundet till det här dokumentet, den här versionen och ett fingeravtryck av det här innehållet.
Den uppackade nyckeln finns bara i minnet, i det ögonblick den behövs.
Med egna behörigheter, i en egen katalog.
Varje öppning loggas innan innehållet visas.
Som en ny version, med en egen ny nyckel. Originalet är orört och fortfarande läsbart – en uppgift som kan ändras är värdelös som bevis.
Den vägrar att dekrypteras, eftersom krypteringen är bunden till originaldokumentets identitet.
Från relationens slut – inte från dagen filen skapades.
Nyckelmaterialet skrivs över med slumpmässiga byte, sedan raderas nyckelraden. Att skriva över först är avsiktligt: avbryts processen blir felet ett dokument som inte kan läsas, aldrig ett som överlever när det inte borde.
Du kan fortfarande bevisa att uppgiften fanns, vem som såg den under tjugo år och att den gallrades enligt plan. Innehållet är oläsbart för alla, för alltid, även för oss.
Allt ovan är det systemet gör bra. Det här avsnittet är motsatsen: ställena där något dåligt kan hända och ingen mängd teknik stänger det – eftersom stängningen skulle kosta mer skydd än den köper.
Var och en säger vad som faktiskt händer, vad vi gör åt det och vad som lämnas åt dig. Säger en leverantör att deras kryptering inte har någon av dessa har de antingen inte tänkt på saken eller hoppas att du inte gör det.
Vad som händer: nyckelfilen raderas, disken går sönder, servern byggs om utan den, eller den enda person som visste var den fanns har slutat. Varje kliniskt dokument i systemet blir permanent oläsbart. Inte svårt att återställa – omöjligt. Databasen är intakt och värdelös.
Varför vi inte åtgärdar det: de enda lösningarna är en kopia hos leverantören eller en bakdörr för återställning. Båda förstör den egenskap som hela designen finns till för. Om vi hade en kopia skulle ”en stulen databas är inget intrång” sluta vara sant, och varje löfte på den här sidan om vad vi inte kan se skulle bli falskt. En nyckel som går att återskapa är en nyckel någon annan kan använda.
Vad vi gör: systemet vägrar att starta om nyckeln saknas, i stället för att köra vidare i tysthet och låta dig upptäcka problemet när ett dokument inte går att öppna. Startkontrollen vägrar också om nyckelfilen kan läsas av någon annan än ägaren, eller ägs av fel konto.
Vad som ligger hos dig: säkerhetskopiera nyckeln, separat från data, och testa att du kan återställa den. Två personer bör veta var den finns. Det är den enskilt mest avgörande driftuppgiften i hela plattformen, och det tar ungefär tio minuter att få rätt.
Vad som händer: en administratör mejlar nyckelfilen till en kollega, klistrar in den i ett ärende, kopierar den till en bärbar dator, eller en avgående tekniker behåller en kopia. Den som har både den filen och en kopia av databasen kan dekryptera varje dokument, offline, utan inloggning, och inget skrivs till din åtkomstlogg – eftersom loggen registrerar läsningar genom applikationen, och det här kringgår applikationen helt.
Varför vi inte åtgärdar det: nyckeln måste vara läsbar för programvaran som använder den. Varje process som kan läsa den kan kopiera den. Hårdvarusäkerhetsmoduler flyttar problemet snarare än löser det – programvaran måste fortfarande kunna be modulen packa upp nycklar, så en angripare med programvarans behörigheter får ändå klartext.
Vad vi gör: filbehörigheterna kontrolleras vid start, så en nyckel som alla kan läsa stoppar systemet i stället för att passera obemärkt. Och eftersom du driftar själv har vi aldrig filen alls – de som skulle kunna kopiera den är din personal, inte din personal plus vår.
Vad som ligger hos dig: behandla nyckeln som ett kontrollerat fysiskt föremål. Begränsa vem som kan logga in på servern, använd personliga administratörskonton i stället för ett delat, och rotera nyckeln när någon med serveråtkomst slutar – avsnitt 06 förklarar varför rotation är billig.
Vad som händer: det tystaste och vanligaste felet. Någon sätter upp en säkerhetskopiering som sveper över hela servern, och nyckelfilen ligger i samma arkiv som databasen. Nu innehåller ett stulet säkerhetskopieband båda halvorna, krypteringen skyddar ingenting, och – värre – du skulle ändå åberopa krypteringsundantaget i en incidentrapport, eftersom allt på papperet var krypterat.
Varför det är svårt: inget i det körande systemet ser annorlunda ut. Det fungerar perfekt. Problemet finns bara i säkerhetskopian, och spelar bara roll den dag säkerhetskopian stjäls.
Vad vi gör: det här är den i listan som vi delvis faktiskt byggde in skydd mot. Du anger dina kataloger för säkerhetskopior i konfigurationen, och systemet vägrar att starta om nyckelfilen ligger i någon av dem. Anger du inga sökvägar för säkerhetskopior alls varnar det för att undantaget inte kan verifieras – eftersom ett okontrollerat påstående är den farliga sorten.
Vad som ligger hos dig: ange rötterna för säkerhetskopior ärligt, och kontrollera vad ditt verktyg för säkerhetskopiering faktiskt tar med snarare än vad du tror att det tar med.
Vad som händer: en terapeut öppnar journalen för en klient som också är granne. En receptionist slår upp en lokal kändis. Varje regel var uppfylld – personen hade en giltig vårdrelation, eller giltiga skäl, och missbrukade den helt enkelt. Kryptering spelar ingen roll här. Det gör inte heller åtkomstkontroll, eftersom åtkomsten var beviljad.
Varför inget system åtgärdar det: programvara kan inte läsa avsikter. Ett system som försökte – blockerade åtkomst för att ett namn ser lokalt ut – skulle blockera verkligt kliniskt arbete i en nödsituation, vilket är en skada i sig och, i Storbritannien, ett eget regelbrott.
Vad vi gör: göra det synligt snarare än omöjligt. Varje öppning registreras innan innehållet visas, i en logg som ingen kan ändra – inte era administratörer och inte vi. Vårdrelationer upphör, och åtkomsten upphör med dem efter en kort frist, så fönstret är smalt. Nödåtkomst är en separat, medveten och granskad handling snarare än en tyst möjlighet.
Vad som ligger hos dig: någon måste faktiskt läsa loggen. Styrningsmodulen ger granskningen ett hem – intervall, namngiven granskare, spår av fynd – men en logg som ingen tittar på avskräcker ingen. Det här är den kontroll som oftast finns på papperet och aldrig blir av.
Vad som händer: för att visa ett dokument för en behörig behandlare måste programvaran dekryptera det. I det ögonblicket finns det i serverns minne som läsbar text. Någon med full kontroll över operativsystemet kan i princip läsa det där – eller ändra programvaran så att den sparar kopior.
Varför inget system åtgärdar det: det här gäller varje system som någonsin visar något för någon. Kan maskinen visa dokumentet kan maskinens ägare få tag i dokumentet. Kryptering skyddar data i vila och under överföring; den kan inte skydda data från den dator som lagligt behandlar dem.
Vad vi gör: minimera fönstret – dekrypteringen sker i minnet under läsningens ögonblick och klartexten skrivs aldrig till disken. Och egen drift innebär att du är den som har root, inte vi.
Vad som ligger hos dig: serveradministration är den mest privilegierade roll ni har. Få personer, namngivna var för sig, nycklar i stället för lösenord, och en förteckning över vem som har åtkomst. Den hör hemma på checklistan för nyanställda och avgående, bredvid de kliniska kontona.
Vad som händer: en lagringsregel är felaktigt inställd, eller en radering körs på fel urval. Nycklarna skrivs över och dokumenten blir oläsbara. Det finns inget ångra, och att återställa gårdagens säkerhetskopia hjälper inte – säkerhetskopian innehåller samma chiffertext, och dess nyckel är borta.
Varför vi inte åtgärdar det: en gallring som går att ångra är ingen gallring. Hela värdet av kryptografisk radering för en tillsynsmyndighet är att den inte kan tas tillbaka. En ”papperskorg” för förstörda nycklar skulle betyda att uppgifterna aldrig verkligen förstördes, och varje påstående om radering ni gjort skulle vara falskt.
Vad vi gör: nycklar kan inte raderas via någon vanlig väg – raderingen är helt spärrad och gallring sker bara via raderingsvägen, som skriver en granskningspost under tiden. Rättsliga kvarhållanden stoppar gallringen helt. Lagringstiden räknas från sparade ankardatum snarare än filens ålder, så den vanligaste orsaken till gallring vid fel datum uppstår inte.
Vad som ligger hos dig: kontrollera lagringsinställningarna före driftstart, inte efter den första gallringen. Och bekräfta att de schemalagda jobben faktiskt körs – ett lagringsjobb som tyst har slutat är ett annat problem, men det upptäcks på samma sätt, det vill säga för sent.
Vad som händer: journaler inom psykisk hälsa sparas i tjugo år och ibland längre. AES-256 anses i dag inte gå att knäcka, inte heller med de kvantdatorer folk spekulerar om – men ingen ärlig ingenjör lovar något om 2046 med rak min.
Varför ingen åtgärdar det: man kan inte köpa skydd mot ett matematiskt resultat som ännu inte har inträffat. Den som säljer ”kvantsäker” lagring för journaler säljer en berättelse.
Vad vi gör: göra algoritmen och nycklarna utbytbara utan att röra dina data. Nyckelrotation slår in varje datanyckel på nytt under en ny driftsättningsnyckel utan att skriva om en enda byte chiffertext, så det är en bakgrundsuppgift snarare än ett migreringsprojekt. Kryptografin är isolerad i en liten granskningsbar komponent just för att den ska kunna bytas ut när den dagen kommer.
Vad som ligger hos dig: rotera med jämna mellanrum snarare än aldrig, och räkna med att kryptera om en gång under en tjugoårig journals livstid. Planera för det som underhåll, inte som en kris.
Se vad de sju har gemensamt. I varje fall skulle den ”lösning” som stänger risken – en nyckel som går att återskapa, en gallring som går att ångra, ett system som läser avsikter, skydd mot era egna administratörer – förstöra något mer värdefullt än det skyddar. Designvalet är inte att riskerna förbisågs. Det är att stänga dem skulle göra de återstående garantierna osanna.
Det som lämnas åt dig är litet, konkret och mest en fråga om rutiner: säkerhetskopiera nyckeln separat, styr vem som kan nå servern, ange dina sökvägar för säkerhetskopior, läs åtkomstloggen och kontrollera lagringsinställningarna en gång. Den listan får plats på en sida, och det är allt.
Eftersom risk 1 och risk 2 är de två punkterna med störst konsekvenser på den här sidan är det värt att vara exakt om vilka delar som är automatiska och vilka som är dina.
| Kontroll | Status | Vad som händer |
|---|---|---|
| Nyckeln finns | ✓ | Kontrolleras vid start. En saknad nyckel stoppar systemet i stället för att låta det köra och misslyckas senare, ett dokument i taget, framför en patient. |
| Bara ägaren kan läsa den | ✓ | En nyckel som gruppen eller alla kan läsa stoppar systemet vid start, det är ingen varning i en logg som ingen läser. |
| Den ägs av rätt konto | ✓ | Kontrolleras mot kontot som tjänsten körs som. En nyckel som ägs av en avgången teknikers inloggning är ett fynd. |
| Den ligger inte i en katalog för säkerhetskopior | ✓ | Du anger dina rötter för säkerhetskopior; systemet vägrar att starta om nyckeln ligger i någon av dem. Anger du ingen varnar det för att incidentundantaget inte kan verifieras. |
| Den ligger inte någonstans där den skulle följa med data | ✓ | En kort lista över kataloger som nyckeln aldrig får ligga i avvisas rakt av. |
| Det är en riktig nyckel | ✓ | Accepteras bara som 32 råa byte eller 64 hexadecimala tecken. En avkortad eller skadad fil avvisas i stället för att användas för att skapa dokument som ingen någonsin kan öppna. |
| Den är säkerhetskopierad, separat | — | Ditt ansvar, och programvaran kan inte hjälpa till. Vi kan inte verifiera en säkerhetskopia vi inte får se, och ett system som kunde kontrollera sin egen nyckelkopia vore ett system som kan nå den. Två personer, två ställen, testad återställning. |
| Vem som får nå servern | — | Ditt ansvar. Den som har root kan läsa nyckeln. Den listan ska vara kort, namngiven och ses över när folk slutar. |
| Rotation när någon slutar | ⚙ | Stöds och är billig: rotationen slår in varje datanyckel på nytt under en ny driftsättningsnyckel utan att skriva om någon chiffertext, och ersatta nycklar kan behållas för att packa upp sådant som fortfarande är på väg. Att avgöra när du ska rotera är ditt ansvar. När en serveradministratör har slutat är det självklara tillfället, och det är det som oftast missas. |
Varje version av varje kliniskt dokument krypteras med en egen nyckel, bunden till dokumentets identitet så att den inte kan flyttas någon annanstans. De nycklarna slås in under en driftsättningsnyckel som finns utanför databasen och aldrig lämnar din server – så en stulen databas är inget röjande, och gallring görs genom att förstöra en nyckel snarare än att radera en rad. Dokument öppnas bara för personer med en aktuell behandlingsrelation, och varje öppning skrivs först till en kedjad logg, så missbruk syns även när åtkomsten var legitim. Det som inte kan lösas med teknik namnges i avsnitt 05, och kortversionen av din del är: säkerhetskopiera nyckeln separat, håll serveråtkomsten kort och namngiven, ange dina sökvägar för säkerhetskopior, läs loggen och kontrollera lagringsinställningarna en gång före driftstart.
Varje landssida bygger på maskineriet som beskrivs här och lägger till den maskin för rättigheter och styrning som dess egen lag kräver.
