De documentdienst · versleuteling, toegang, en de grenzen die echt zijn
Elke bewering over naleving op deze site — de Amerikaanse, de Europese, de Britse, de Duitse — wijst uiteindelijk naar één stuk machinerie: de dienst die klinische documenten bewaart. Deze pagina legt in gewone taal uit hoe zij werkt, en doet daarna iets wat de meeste leveranciersdocumentatie vermijdt.
Zij somt de risico's op waar geen technische oplossing voor is. Niet de risico's die wij opgelost hebben en waar wij u graag over vertellen — de risico's waarbij het eerlijke antwoord is « dit kan gebeuren, dit is waarom wij daarvoor gekozen hebben, en dit is wat u eraan moet doen ». Leest u maar één hoofdstuk, lees dan dat.
Stel u elk klinisch document voor in een kist met een eigen hangslot, en elk hangslot met een andere sleutel. Die sleutels zitten zelf opgesloten in één kluis. De kisten en de sleuteltjes wonen in uw database. De kluissleutel niet.
Dat is het hele ontwerp. Alles hieronder is detail daar bovenop, en de gevolgen zijn het waard om eerst te noemen, vóór de mechaniek:
Wie uw hele database kopieert krijgt de kisten en de vergrendelde sleuteltjes. Zonder de kluissleutel gaat daar niets van open. Dit is wat de versleutelingsuitzondering in het recht rond datalekken voor u beschikbaar maakt — u kunt betogen dat de gegevens onleesbaar waren, mits de kluissleutel niet óók is meegenomen.
Om een document te vernietigen vernietigt u het sleuteltje ervan. De kist blijft, leeg en voor altijd niet te openen. Dat is sterker dan een regel verwijderen — een verwijderde regel komt terug uit de back-up van gisteravond, een vernietigde sleutel niet.
Er is geen hoofdkopie, geen bewaargeving bij de leverancier, geen hersteldienst. Is de kluissleutel weg, dan is elk klinisch document dat u bewaart mee weg. Dit is bewust zo, en hoofdstuk 05 legt uit waarom elke « oplossing » daarvoor erger zou zijn dan het probleem.
De techniek heet envelopversleuteling, en het is wat banken en cloudaanbieders voor hetzelfde probleem gebruiken. Er zijn drie lagen. De reden voor drie in plaats van één staat in de derde kolom.
| Laag | Wat het is | Waarom het apart staat |
|---|---|---|
| De documentversie | Het eigenlijke bestand — een sessieverslag, een incidentdossier, een identiteitsbewijs — versleuteld met AES-256-GCM. Het versleutelde resultaat wordt naar een eigen map op de schijf geschreven, buiten de gewone bestandsopslag van Odoo, en wordt nooit via de normale downloadroute geserveerd. | Cijfertekst buiten het gewone bestandsgebied houden betekent dat een verkeerd ingestelde webserver klinische bestanden niet per ongeluk kan publiceren, want ze liggen niet waar een webserver zou kijken. |
| De gegevenssleutel (DEK) | Een verse willekeurige 256-bits sleutel, aangemaakt voor elke versie van elk document. Niet per patiënt, niet per document — per versie. Hij wordt in de database bewaard, maar alleen in ingepakte vorm. | Eén sleutel per versie is wat vernietiging precies maakt. De sleutel van een versie vernietigen vernietigt precies die versie en niets anders, zodat een correctie bewaard kan blijven terwijl het origineel vernietigd wordt, of andersom. |
| De implementatiesleutel (KEK) | Eén 256-bits sleutel voor de hele installatie, bewaard in een bestand op de server, die elke gegevenssleutel inpakt. Hij wordt nooit in de database bewaard en verlaat de server nooit. | Dit is de scheiding die het werk doet. Database en sleutels zijn verschillende dingen op verschillende plekken met verschillende back-ups, dus de ene bemachtigen geeft u de andere niet. |
Voor elke documentversie bestaan er zes dingen. Ze worden bewust op verschillende plekken gehouden, want het hele ontwerp rust erop dat geen enkele plek er twee van bevat.
| Het onderdeel | Waar het bewaard wordt | Wat u eraan hebt als u alleen dit hebt |
|---|---|---|
| Het bestand zelf, versleuteld | Een eigen map op de server, ingedeeld als
<opslag>/<eerste 2 van uuid>/<volgende 2>/<uuid>.enc.v<versie>. Mappen zijn alleen voor de eigenaar, bestanden lezen/schrijven voor de eigenaar. Buiten de filestore van Odoo, dus het is niet bereikbaar via /web/content en het wordt niet aangeraakt door de opruiming van bijlagen. |
Niets. Geauthenticeerde cijfertekst zonder sleutel. Eén bestand per versie, zodat een nieuwe versie indienen de vorige niet kan overschrijven. |
| De nonce en twee hashes | In de database, op de versieregel: de nonce die voor deze versleuteling gebruikt is, een hash van de platte tekst, en een hash van de cijfertekst. | Op zichzelf niets — maar de hash van de platte tekst is nodig om de binding hieronder opnieuw op te bouwen, dus hem kwijtraken maakt de cijfertekst onontcijferbaar. Dat is met opzet, geen vergissing. |
| De gegevenssleutel, ingepakt | In de database, versleuteld onder de implementatiesleutel. De uitgepakte vorm bestaat alleen in het geheugen, voor de duur van één leesactie, en wordt daarna meteen weggegooid. | Niets zonder de implementatiesleutel. Een gestolen database geeft u ingepakte sleutels en paden naar cijfertekst, en geen van beide opent iets. |
| De implementatiesleutel | Een bestand op de server, alleen leesbaar door het account waaronder Odoo draait. Nooit in de database. Nooit in de filestore. Nooit binnen een opgegeven back-upwortel — elk daarvan wordt bij het starten gecontroleerd en is fataal, geen waarschuwing. | Niets zonder de database, die de ingepakte gegevenssleutels bevat, en zonder de cijfertekstopslag. Er zijn drie losse dingen nodig, en ze worden op drie plekken bewaard. |
| De toegangsregels | In de database, als vastleggingen — wie wat mag openen, op welke grond, en tot wanneer. | Ze bepalen wat een collega kan openen. Ze hebben geen enkel effect op iemand die de bestanden heeft maar de sleutels niet, en juist voor dat geval is versleuteling bedoeld. |
| Het toegangslogboek | In de database, alleen aangroeiend en hash-geketend. Alles wat wordt gelezenkomt erin, niet alleen alles wat wordt gewijzigd. | De vastlegging van wie wat opende. Zij wordt weggeschreven voordat de inhoud wordt afgegeven, zodat een download die iemand afbreekt toch als toegang genoteerd staat. |
Alles hierboven is makkelijker te toetsen aan deze twee. De eerste is wat er gebeurt wanneer een document wordt ingediend; de tweede is wat er gebeurt wanneer iemand er een wil zien. Lees de tweede aandachtig — daar zijn de meeste systemen zwakker dan ze beweren.
Een sessieverslag, een incidentdossier, een identiteitsbewijs. Het komt binnen in het geheugen.
32 bytes uit de cryptografische toevalsbron van het besturingssysteem. Niet afgeleid van een wachtwoord, niet hergebruikt uit een ander document, niet hergebruikt uit de vorige versie van dit document.
één sleutel per versie — dit is wat vernietiging precies maaktEen SHA-256 van de platte tekst, en een 96-bits getal dat één keer gebruikt wordt. Geen enkele functie in de versleutelingskern aanvaardt een nonce van de aanroeper, dus de klassieke hergebruikfout kan hier niet gemaakt worden.
AES-256-GCM, met uuid | versienummer | vingerafdruk van de inhoud als aanvullende geauthenticeerde gegevens. Die binding is verplicht. Cijfertekst die later op een ander document of een andere versie gekopieerd wordt, weigert te ontcijferen in plaats van stilletjes open te gaan onder de toegangsregels van de verkeerde persoon.
Versleuteld met de implementatiesleutel, gemerkt met de sleutelgeneratie en de sleutelnaamruimte, en in die vorm in de database bewaard. De uitgepakte sleutel wordt meteen uit het geheugen weggegooid.
Geschreven naar een tijdelijk bestand in de doelmap, doorgespoeld naar de fysieke schijf, en dan op zijn plaats hernoemd — zodat een crash halverwege het schrijven geen halve versie kan achterlaten. Het tijdelijke bestand bevat cijfertekst, nooit platte tekst.
Opslagpad, nonce, beide hashes, omvang, en de ingepakte sleutel. Nooit de platte tekst, nooit een uitgepakte sleutel, nooit de implementatiesleutel.
Wie het indiende, wanneer, hoe groot, en van welk type. Alleen aangroeiend en geketend aan de regels ervoor.
Een behandelaar in de backoffice, of een cliënt op zijn eigen dossierpagina. Beide gaan door dezelfde controles; geen van beide routes omzeilt die van de ander.
Op de route naar de cliënt worden dossiers niet getoond aan een account dat alleen een wachtwoord heeft. De weigering zegt wat eraan te doen is, in plaats van te doen alsof het document niet bestaat.
Een snelheidslimiet per persoon op de route naar de cliënt. Onomwonden verteld, want het zeggen lekt niets en het scheelt een telefoontje naar support.
Eerst de weigerregels — één ervan is beslissend. Dan de toestaanregels: past er geen, dan is het antwoord nee. Noodtoegang wordt pas op dat punt geraadpleegd, zodat zij kan bereiken wat nooit verleend is maar een weigering niet ongedaan kan maken. Gevoeligheidslabels worden als laatste toegepast en kunnen alleen toegang wegnemen.
standaard gesloten · in deze controle bestaat geen supergebruikerstakDe regel wordt als eerste weggeschreven, zodat een overdracht die iemand halverwege afbreekt toch als toegang op de vastlegging staat. Het logboek groeit alleen aan en is hash-geketend; regels kunnen er achteraf niet stilletjes uit verwijderd worden, niet door ons en niet door uw eigen beheerder.
Voordat er een sleutel wordt aangeraakt. Beschadiging in de opslag wordt dan als beschadiging gemeld, in plaats van later als een verwarrende authenticatiefout boven te komen.
Gebruikt om de gegevenssleutel van deze versie uit te pakken, waarbij onderweg de sleutelgeneratie en de naamruimte gecontroleerd worden. Een sleutel die voor de ene naamruimte is ingepakt kan niet als een andere worden uitgepakt, zelfs niet door iemand die beide implementatiesleutels heeft.
De documentidentificatie, het versienummer en de vingerafdruk van de inhoud worden opnieuw opgebouwd en moeten overeenkomen. Knoeien, een verkeerde sleutel, en cijfertekst die uit een ander dossier is verplaatst falen hier alle drie — en ze falen alle drie gelijk, want een aanvaller vertellen welk deel faalde is gratis informatie.
De gegevenssleutel wordt uit het geheugen gegooid. Geen enkel codepad in dit product schrijft een ontcijferde byte naar schijf — niet voor voorbeelden, niet voor miniaturen, niet voor zoekindexering.
Een vernietigde versie meldt dat haar sleutel niet meer bestaat. Er is geen terugval, geen gecachete kopie en geen herstelroute, en dat is juist de bedoeling van het op die manier vernietigen.
Eén sleutel beschermt elke gegevenssleutel in de installatie, dus hoe daarmee wordt omgegaan is het deel dat het regel voor regel nakijken waard is. Alle onderstaande controles draaien bij het starten en ze zijn allemaal fataal — de server start liever niet dan te draaien met bescherming waarvan u denkt dat u haar hebt terwijl dat niet zo is.
32 bytes uit de toevalsbron van het besturingssysteem, weggeschreven naar een bestand dat in één stap met leesrecht alleen voor de eigenaar wordt aangemaakt, zodat het nooit even voor iemand anders leesbaar is.
Het bestand moet óf 32 ruwe bytes óf 64 hexadecimale tekens bevatten. Er wordt niets anders aanvaard — een wachtwoordzin wordt geweigerd in plaats van tot een sleutel uitgerekt, want een uitgerekte wachtwoordzin is een zwakkere sleutel die op een sterkere lijkt.
Niet in de database. Niet in de datamap van Odoo, zijn addons-pad of zijn filestore. Niet binnen de cijfertekstopslag. En niet binnen een map die u als back-upwortel hebt opgegeven.
Die laatste is degene die mensen fout doen. Een back-up die zowel de database als de sleutel bevat is een gecompromitteerde sleutel, en hij zet de implementatie buiten de Amerikaanse safe harbour bij datalekken en buiten de Europese uitzondering van art. 34 lid 3 onder a — en dat is de hele reden dat de versleuteling er is.
De implementatiesleutel rouleren pakt de gegevenssleutels opnieuw in en herschrijft geen enkele byte cijfertekst. Honderdduizend documenten rouleren zo snel als honderd sleutels opnieuw versleuteld kunnen worden, niet zo snel als honderdduizend bestanden herschreven kunnen worden.
Het generatienummer zit in de inpakking, dus een sleutel die onder de oude generatie is ingepakt kan niet stilletjes geopend worden alsof hij de nieuwe was.
Een versie vernietigen overschrijft haar ingepakte sleutel met willekeurige bytes in plaats van het veld leeg te maken, dus er is niets meer terug te halen, zelfs niet uit de databasepagina.
De metadatahuls van de versie en het hele toegangslogboek blijven bestaan — u kunt nog steeds aantonen dat u het document had en het correct vernietigd hebt. Een versie kan niet verwijderd worden zolang haar sleutel nog bestaat, dus de volgorde kan nooit verkeerd om zijn.
Dit zijn de plekken waar versleuteling meestal bijna-correct wordt geïmplementeerd, en « bijna » is het hele verschil.
Wanneer een versie wordt versleuteld, wordt de versleuteling vastgeknoopt aan de identificatie van dat document, het versienummer ervan en een vingerafdruk van de inhoud. Cryptografen noemen dit de aanvullende geauthenticeerde gegevens, en het is hier verplicht — geen enkele aanroeper kan het overslaan.
Het gevolg: cijfertekst die op een ander document of een andere versie gekopieerd wordt, weigert te ontcijferen. Zij gaat niet stilletjes open onder de toegangsregels van de verkeerde patiënt — en dat is precies de aanval waaraan een systeem zonder deze binding blootstaat.
AES-GCM is rampzalig zwak wanneer dezelfde nonce twee keer met dezelfde sleutel wordt gebruikt: een aanvaller die twee van zulke cijferteksten ziet, kan uit allebei informatie terughalen. Het is de klassieke implementatiefout.
Hier maakt elke versleuteling haar eigen nonce aan en aanvaardt geen enkele functie een nonce van de aanroeper. De fout wordt niet moeilijker te maken gemaakt; zij wordt onmogelijk te maken gemaakt.
De versleutelingskern is als zelfstandig stuk geschreven, zonder afhankelijkheid van het toepassingsraamwerk, zodat iemand die de bewering over de versleuteling controleert haar los kan lezen en testen zonder een praktijksysteem te draaien.
Wil uw beveiligingsteam de beweringen op deze pagina verifiëren in plaats van geloven, dan is dat het bestand om hun te geven, en het is een kort bestand.
Waar het recht de eigen procesaantekeningen van een therapeut scheidt van het klinische dossier — de Amerikaanse uitzondering voor psychotherapienotities is het duidelijkste geval — worden die aantekeningen versleuteld onder een tweede, andere implementatiesleutel. De sleutel die het gewone dossier opent, opent ze niet.
Dit doet ertoe omdat het de scheiding een eigenschap van de opslag maakt in plaats van van de toegangsregels. Als morgen elke rechteninstelling in het systeem fout zou zijn, zou de gewone sleutel die aantekeningen nog steeds niet ontcijferen. Het betekent ook dat de tweede sleutel vóór de livegang ingericht moet zijn: zo'n aantekening indienen zonder die sleutel faalt in plaats van stilletjes op de hoofdsleutel terug te vallen, want een stille terugval zou de scheiding vernietigen zonder dat iemand het merkt.
De twee worden vaak verward. Versleuteling beschermt tegen iemand die überhaupt niet in het systeem hoort te zijn. Zij doet niets aan het veel gewonere probleem: iemand die wél in het systeem zit en naar een dossier kijkt dat hem niets aangaat.
Daar is de autorisatielaag voor, en zij werkt op een ander beginsel dan de meeste systemen: toegang volgt de behandelrelatie, niet de functietitel.
Elke keer. Niet één keer bij het aanmelden.
Uitdrukkelijk vermeld, want beoordelaars vragen ernaar
Een behandelaar heeft soms werkelijk een dossier nodig waarmee hij geen relatie heeft — een crisis, een telefoontje buiten kantooruren, een collega die ziek is geworden. Waar uw organisatie het toestaat, is break-glass-toegang beschikbaar. Haar gebruiken opent een vastgelegde sessie die achteraf beoordeeld wordt.
Een systeem dat alleen maar weigert is op zijn eigen manier onveilig, en in het Verenigd Koninkrijk is het uitdrukkelijk niet conform: Caldicott-beginsel 7 maakt de plicht om te delen even belangrijk als de plicht om te beschermen. De toegang bestaat dus, en het gebruik ervan is nooit stil.
Bij een documenttype — dat type is wat de regels, de bewaartermijn en de vraag wie het mag openen bepaalt.
In gewone woorden, voordat het wordt opgeslagen. De meeste verkeerd ingediende documenten komen doordat niemand wist waar een document terecht zou komen.
Gebonden aan dit document, deze versie, en een vingerafdruk van deze inhoud.
De uitgepakte sleutel bestaat alleen in het geheugen, voor het moment dat hij nodig is.
Met eigen rechten, in een eigen map.
Elke opening gelogd voordat de inhoud verschijnt.
Als nieuwe versie, met een eigen nieuwe sleutel. Het origineel blijft onaangeraakt en nog leesbaar — een dossier dat te wijzigen valt is waardeloos als bewijs.
Zij weigert te ontcijferen, want de versleuteling is gebonden aan de identiteit van het oorspronkelijke document.
Vanaf het einde van de relatie — niet vanaf de dag dat het dossier is aangemaakt.
Het sleutelmateriaal wordt met willekeurige bytes overschreven, en daarna wordt de sleutelregel verwijderd. Eerst overschrijven is bewust: wordt het proces onderbroken, dan is de faalwijze een document dat niet gelezen kan worden, nooit een document dat blijft bestaan terwijl dat niet had gemogen.
U kunt nog steeds aantonen dat het dossier bestond, wie het over twintig jaar gezien heeft, en dat het op schema is vernietigd. De inhoud is voor iedereen blijvend onleesbaar, ook voor ons.
Alles hierboven is wat het systeem goed doet. Dit hoofdstuk is het tegendeel: de plekken waar er iets naars kan gebeuren en waar geen hoeveelheid techniek het dichttimmert — want het dichttimmeren zou meer bescherming kosten dan het oplevert.
Elk risico zegt wat er werkelijk gebeurt, wat wij eraan doen, en wat er bij u blijft. Vertelt een leverancier u dat zijn versleuteling geen van deze risico's kent, dan heeft hij er óf niet over nagedacht óf hij hoopt dat u dat niet doet.
Wat er gebeurt: het sleutelbestand wordt verwijderd, de schijf begeeft het, de server wordt zonder de sleutel opnieuw opgebouwd, of de ene persoon die wist waar hij lag is vertrokken. Elk klinisch document in het systeem wordt blijvend onleesbaar. Niet lastig terug te halen — onmogelijk. De database is intact en waardeloos.
Waarom wij het niet oplossen: de enige oplossingen zijn een kopie bij de leverancier of een achterdeur voor herstel. Beide vernietigen de eigenschap waarvoor het hele ontwerp bestaat. Hadden wij een kopie, dan houdt « een gestolen database is geen datalek » op waar te zijn, en wordt elke belofte op deze pagina over wat wij niet kunnen zien onjuist. Een sleutel die terug te halen is, is een sleutel die iemand anders kan gebruiken.
Wat wij doen: het systeem weigert te starten als de sleutel ontbreekt, in plaats van stilletjes door te draaien en u het probleem te laten ontdekken wanneer een document niet opengaat. De startcontrole weigert ook als het sleutelbestand leesbaar is voor iemand anders dan de eigenaar, of als het van het verkeerde account is.
Wat aan u is: maak een back-up van de sleutel, los van de gegevens, en test of u hem kunt terugzetten. Twee mensen horen te weten waar hij ligt. Dit is veruit de operationele plicht met de zwaarste gevolgen in het hele platform, en hem goed doen kost ongeveer tien minuten.
Wat er gebeurt: een beheerder mailt het sleutelbestand naar een collega, plakt het in een ticket, kopieert het naar een laptop, of een vertrekkende engineer houdt een kopie. Iedereen die zowel dat bestand als een kopie van de database heeft, kan elk document ontcijferen, offline, zonder aanmelding, en er wordt niets naar uw toegangslogboek geschreven — want het logboek legt leesacties via de toepassing vast, en dit omzeilt de toepassing volledig.
Waarom wij het niet oplossen: de sleutel moet leesbaar zijn voor de software die hem gebruikt. Elk proces dat hem kan lezen, kan hem kopiëren. Hardwarebeveiligingsmodules verplaatsen dit probleem in plaats van het op te lossen — de software moet de module nog steeds kunnen vragen sleutels uit te pakken, dus een aanvaller met de rechten van die software krijgt nog steeds platte tekst.
Wat wij doen: de bestandsrechten worden bij het starten afgedwongen, zodat een sleutel die voor iedereen leesbaar is het systeem stilzet in plaats van onopgemerkt door te glippen. En omdat u zelf host, hebben wij dat bestand helemaal nooit — de groep mensen die hem zou kunnen kopiëren bestaat uit uw medewerkers, niet uit uw medewerkers plus de onze.
Wat aan u is: behandel de sleutel als een beheerst fysiek voorwerp. Beperk wie er op de server kan aanmelden, gebruik persoonlijke beheerdersaccounts in plaats van één gedeeld account, en rouleer de sleutel wanneer iemand met servertoegang vertrekt — hoofdstuk 06 legt uit waarom rouleren goedkoop is.
Wat er gebeurt: de stilste en gewoonste misser. Iemand richt een back-up in die de hele server meeneemt, en het sleutelbestand zit in hetzelfde archief als de database. Nu bevat één gestolen back-upband beide helften, beschermt de versleuteling niets, en — erger nog — zou u nog steeds de versleutelingsuitzondering claimen in een melding van een datalek, want op papier was alles versleuteld.
Waarom het lastig is: aan het draaiende systeem is niets anders te zien. Het werkt perfect. Het probleem bestaat alleen in de back-up, en het doet er alleen toe op de dag dat de back-up gestolen wordt.
Wat wij doen: dit is de enige op deze lijst waar wij deels wél iets tegen gebouwd hebben. U geeft uw back-upmappen in de inrichting op, en het systeem weigert te starten als het sleutelbestand in een daarvan ligt. Geeft u helemaal geen back-uppaden op, dan waarschuwt het dat de uitzondering niet te verifiëren is — want een ongecontroleerde bewering is de gevaarlijke soort.
Wat aan u is: geef de back-upwortels eerlijk op, en controleer wat uw back-upgereedschap werkelijk meeneemt in plaats van wat u denkt dat het meeneemt.
Wat er gebeurt: een therapeut opent het dossier van een cliënt die ook zijn buurman is. Een baliemedewerker zoekt een plaatselijke beroemdheid op. Aan elke regel was voldaan — de persoon had een geldige behandelrelatie, of geldige gronden, en heeft die simpelweg misbruikt. Versleuteling doet hier niet ter zake. Toegangscontrole evenmin, want de toegang was verleend.
Waarom geen enkel systeem het oplost: software kan geen bedoelingen lezen. Een systeem dat het zou proberen — toegang blokkeren omdat een naam plaatselijk klinkt — zou in een noodgeval echt klinisch werk blokkeren, en dat is een eigen schade en in het VK een eigen nalevingsfout.
Wat wij doen: het zichtbaar maken in plaats van onmogelijk. Elke opening wordt vastgelegd voordat er inhoud verschijnt, in een logboek dat niemand kan wijzigen — uw beheerders niet en wij niet. Behandelrelaties eindigen, en de toegang eindigt na een korte coulanceperiode met hen mee, zodat het venster smal is. Noodtoegang is een aparte, bewuste, beoordeelde handeling in plaats van een stille mogelijkheid.
Wat aan u is: iemand moet het logboek werkelijk gelezen hebben. De governancemodule geeft die beoordeling een plek — een ritme, een beoordelaar met naam, een spoor van bevindingen — maar een logboek waar niemand naar kijkt schrikt niemand af. Dit is de beheersmaatregel die het vaakst op papier bestaat en nooit gebeurt.
Wat er gebeurt: om een document aan een bevoegde behandelaar te tonen, moet de software het ontcijferen. Op dat moment bestaat het in het geheugen van de server als leesbare tekst. Iemand met volledige zeggenschap over het besturingssysteem kan het daar in beginsel lezen — of de software aanpassen om kopieën te bewaren.
Waarom geen enkel systeem het oplost: dit geldt voor elk systeem dat ooit iets aan iemand toont. Kan de machine het document tonen, dan kan de eigenaar van de machine het document bemachtigen. Versleuteling beschermt gegevens in rust en onderweg; zij kan gegevens niet beschermen tegen de computer die ze rechtmatig aan het verwerken is.
Wat wij doen: het venster zo klein mogelijk maken — ontcijferen gebeurt in het geheugen voor het moment van de leesactie en de platte tekst wordt nooit naar schijf geschreven. En zelf hosten betekent dat u de partij met root bent, en niet wij.
Wat aan u is: serverbeheer is de rol met de hoogste rechten die u hebt. Weinig mensen, ieder bij naam, sleutels in plaats van wachtwoorden, en een vastlegging van wie er toegang heeft. Het hoort op de checklist voor in- en uitdiensttreding, naast de klinische accounts.
Wat er gebeurt: een bewaarregel is verkeerd ingericht, of er wordt een vernietiging op de verkeerde selectie gedraaid. De sleutels worden overschreven en de documenten zijn onleesbaar. Er is geen ongedaan maken, en de back-up van gisteravond terugzetten helpt niet — de back-up bevat dezelfde cijfertekst, en de sleutel ervan is weg.
Waarom wij het niet oplossen: een omkeerbare vernietiging is geen vernietiging. De hele waarde van crypto-shredding voor een toezichthouder is dat het niet teruggedraaid kan worden. Een « prullenbak » voor vernietigde sleutels zou betekenen dat de gegevens nooit werkelijk vernietigd waren, en elke bewering over wissing die u gedaan hebt zou onjuist zijn.
Wat wij doen: sleutels kunnen via geen enkel gewoon pad verwijderd worden — de verwijderhandeling is ronduit geblokkeerd en vernietiging gebeurt alleen via de vernietigingsroute, die onderweg een auditregel wegschrijft. Juridische blokkades schorten de vernietiging volledig op. Bewaartermijnen tellen vanaf opgeslagen ankerdatums in plaats van vanaf de leeftijd van een bestand, dus de gewoonste oorzaak van vernietiging op de verkeerde datum doet zich niet voor.
Wat aan u is: controleer de bewaarinrichting vóór de livegang, niet na de eerste vernietigingsronde. En bevestig dat de geplande taken werkelijk draaien — een bewaartaak die stilletjes gestopt is, is een ander probleem, maar het wordt op dezelfde manier ontdekt, namelijk te laat.
Wat er gebeurt: ggz-dossiers worden twintig jaar bewaard en soms langer. AES-256 wordt op dit moment niet als breekbaar beschouwd, ook niet door de kwantumcomputers waarover gespeculeerd wordt — maar geen eerlijke engineer belooft met droge ogen iets over 2046.
Waarom niemand het oplost: u kunt geen bescherming kopen tegen een wiskundig resultaat dat er nog niet is. Wie « kwantumbestendige » opslag voor klinische dossiers verkoopt, verkoopt een verhaal.
Wat wij doen: het algoritme en de sleutels vervangbaar maken zonder uw gegevens aan te raken. Sleutelroulatie pakt elke gegevenssleutel opnieuw in onder een nieuwe implementatiesleutel zonder één byte cijfertekst te herschrijven, dus het is een achtergrondtaak in plaats van een migratieproject. De cryptografie is afgezonderd in één klein, na te kijken onderdeel, precies zodat zij vervangen kan worden wanneer het zover is.
Wat aan u is: rouleer periodiek in plaats van nooit, en verwacht dat u in de levensduur van een dossier van twintig jaar één keer opnieuw moet versleutelen. Plan het in als onderhoud, niet als crisis.
Kijk naar wat de zeven gemeen hebben. In elk geval zou de « oplossing » die het risico zou wegnemen — een terug te halen sleutel, een omkeerbare vernietiging, een systeem dat bedoelingen leest, bescherming tegen uw eigen beheerders — iets vernietigen dat waardevoller is dan wat zij beschermt. De ontwerpkeuze is niet dat deze risico's over het hoofd gezien zijn. Het is dat ze dichttimmeren de overblijvende garanties onwaar zou maken.
Wat er voor u overblijft is klein, concreet en grotendeels procedureel: maak apart een back-up van de sleutel, beheers wie er bij de server kan, geef uw back-uppaden op, lees het toegangslogboek, en controleer de bewaarinstellingen één keer. Die lijst past op één pagina en meer is het niet.
Aangezien risico 1 en risico 2 de twee punten met de zwaarste gevolgen op deze pagina zijn, is het de moeite waard precies te zijn over welke delen automatisch gaan en welke aan u zijn.
| Controle | Status | Wat er gebeurt |
|---|---|---|
| De sleutel bestaat | ✓ | Bij het starten geverifieerd. Een ontbrekende sleutel zet het systeem stil in plaats van het te laten draaien en later te laten falen, document voor document, waar een patiënt bij zit. |
| Alleen de eigenaar kan hem lezen | ✓ | Een sleutel die voor de groep of voor iedereen leesbaar is, is fataal bij het starten, geen waarschuwing in een logboek waar niemand naar kijkt. |
| Hij is van het juiste account | ✓ | Gecontroleerd tegen het account waaronder de dienst draait. Een sleutel die van de aanmelding van een vertrokken engineer is, is een bevinding. |
| Hij ligt niet in een back-upmap | ✓ | U geeft uw back-upwortels op; het systeem weigert te starten als de sleutel in een daarvan ligt. Geeft u er geen op, dan waarschuwt het dat de uitzondering bij een datalek niet te verifiëren is. |
| Hij ligt niet ergens waar hij met de gegevens mee zou reizen | ✓ | Er is een korte lijst mappen waar de sleutel nooit mag wonen, en die worden ronduit geweigerd. |
| Het is een echte sleutel | ✓ | Alleen aanvaard als 32 ruwe bytes of 64 hexadecimale tekens. Een afgekapt of beschadigd bestand wordt geweigerd in plaats van gebruikt om documenten voort te brengen die niemand ooit nog kan openen. |
| Er is apart een back-up van | — | Aan u, en de software kan niet helpen. Wij kunnen geen back-up verifiëren die wij niet mogen zien, en een systeem dat zijn eigen sleutelback-up zou kunnen controleren, zou een systeem zijn dat erbij kan. Twee mensen, twee plekken, en een geteste terugzetting. |
| Wie er bij de server mag | — | Aan u. Iedereen met root kan de sleutel lezen. Die lijst hoort kort te zijn, bij naam, en nagekeken te worden wanneer mensen vertrekken. |
| Roulatie wanneer iemand vertrekt | ⚙ | Ondersteund en goedkoop: roulatie pakt elke gegevenssleutel opnieuw in onder een nieuwe implementatiesleutel zonder enige cijfertekst te herschrijven, en vervangen sleutels kunnen bewaard blijven om uit te pakken wat nog onderweg is. Beslissen wanneer u rouleert is aan u. Nadat een serverbeheerder vertrokken is, is het voor de hand liggende moment, en het is het moment dat het vaakst gemist wordt. |
Elke versie van elk klinisch document wordt versleuteld met een eigen sleutel, gebonden aan de identiteit van dat document zodat zij niet elders heen verplaatst kan worden. Die sleutels worden ingepakt onder één implementatiesleutel die buiten de database woont en uw server nooit verlaat — zodat een gestolen database geen verstrekking is, en vernietiging gebeurt door een sleutel te vernietigen in plaats van een regel te verwijderen. Documenten gaan alleen open voor mensen met een lopende behandelrelatie, en elke opening wordt eerst naar een geketend logboek geschreven, zodat misbruik zichtbaar is ook wanneer de toegang rechtmatig was. Wat techniek niet kan oplossen staat benoemd in hoofdstuk 05, en de korte versie van uw kant daarvan is: maak apart een back-up van de sleutel, houd de servertoegang kort en bij naam, geef uw back-uppaden op, lees het logboek, en controleer de bewaarinstellingen één keer vóór de livegang.
Elke landenpagina leunt op de machinerie die hier beschreven staat en voegt de rechten- en governancemachinerie toe die haar eigen recht verlangt.
