Kort sagt: Ved lægepraksis-websitet handler det om sikkerhed for sundhedsdata, ikke kun om et visitkort på nettet. Undersøg, hvilke formularer der gemmer data eller sender dem pr. mail, lad serverens PHP-patchstatus bekræfte skriftligt, og sikr ved mistanke straks logs.
Hvilke PHP-systemer der kører i praksis og MVZ
De fleste praksis-websites bygger på et PHP-CMS, ofte WordPress, sjældnere TYPO3 eller Joomla. Spændende bliver det ved tillægsfunktionerne: formularer til recept- og henvisningshenvendelser, anamneseskemaer til download eller upload, recall-tilmeldinger, stillingsopslag med ansøgningsupload og online tidsbestilling.
Tidsbestillingen er ofte en ekstern tjeneste, der blot indlejres. Så ligger tidsbestillingsdata hos udbyderen. Nogle praksisser bruger dog booking-plugins, som gemmer tider inklusive henvendelsen i websitets egen database. Netop denne forskel bør I kende, før I vurderer risikoen.
Sundhedsdata: hvorfor websitet er mere følsomt, end det ser ud
En sætning som »Jeg har igen brug for min blodtryksmedicin« i kontaktformularen er en sundhedsoplysning. Sådanne oplysninger hører til de særlige kategorier af personoplysninger efter art. 9 GDPR. For læger gælder desuden tavshedspligten, hvis overtrædelse efter § 203 StGB (den tyske straffelov) kan være strafbar.
For websitet betyder det: Formularindtastninger, der bliver liggende i databasen, kopier i formular-plugins, maillogs på serveren og uploadede dokumenter er inden for rækkevidde ved et angreb. Den, der udfører kode på serveren, læser dem som regel med.
Lad kontrollere, om jeres formular-plugin desuden gemmer indtastninger i databasen. Mange gør det som standard. Det, der ikke er gemt, kan heller ikke slippe ud.
Hvad et udfald eller dataudslip betyder for praksis
Falder websitet ud, ringer patienter, og praksistelefonen er under alle omstændigheder travlt optaget. Det er irriterende, men håndterbart. Tungere vejer et uset angreb: omdirigeringer til svigagtige sider i praksis' navn, forfalskede formularer eller opsnappede henvendelser med sygdomsrelation.
En sådan hændelse kan udløse anmeldelsespligter over for databeskyttelsestilsynet, alt efter risikoen også underretning af de berørte. GDPR's 72-timersfrist begynder, så snart I får kendskab til bruddet. Afklar vurderingen med jeres databeskyttelsesrådgiver.
Lægepraksis-website og sikkerhed: det typiske ansvarshul
I praksisser er der som regel tre involverede, som hver føler sig ansvarlige for en del:
| Involveret | Tager sig som regel af | Er ofte ikke opmærksom på |
|---|---|---|
| Praksissens it-leverandør | PVS, netværk, konnektor, arbejdspladser | Website-serveren hos hostingudbyderen |
| Webbureau | Design, indhold, plugins | PHP-versionen og serverens genstart |
| Hostingudbyder | Serverdrift | Praksis' formulardata og plugins |
Ved PHP2Shell ligger sårbarheden netop mellem disse roller: i PHP på webserveren. Ved shared hosting er som regel hostingudbyderen ansvarlig, men bekræftelsen af pakkestatus skal I selv anmode om. I MVZ med flere lokationer kommer ofte også driftsherren til, som har egne regler.
Findes der en bro mellem website og praksisnetværk?
Oftest kører praksis-websitet hos hostingudbyderen og har ingen direkte forbindelse til praksisadministrationssystemet. Men der er undtagelser, som I bør kende: formularer, der automatisk overfører data til PVS, en website-server i det egne MVZ-datacenter eller adgangsdata, der samtidig bruges til website, mailkonti og fjernvedligeholdelse.
I sådanne tilfælde er en kompromitteret webserver ikke kun et website-problem. Lad jeres praksis-it-leverandør og website-vedligeholderen sammen undersøge, hvilke forbindelser der findes, og hvilke adgangskoder der bruges flere gange. For praksis-it gælder desuden de krav til it-sikkerhed, som Kassenärztliche Bundesvereinigung (den tyske forbundssammenslutning af læger i den offentlige sygesikring) har fastsat. I hvilket omfang de berører websitet, afklarer I med jeres databeskyttelsesrådgiver.
De første timer efter en advarsel
- Spørg hostingudbyderen, om PHP står på 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, eller om en backport er indspillet, og om alle PHP-processer er genstartet.
- Er det ikke bekræftet: Sluk websitet midlertidigt eller erstat det med en statisk informationsside med telefontider, som BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler for servere, der ikke kan patches.
- Sikr server- og adgangslogs fra 20.10.2026.
- Hold øje med tegn på kompromittering: ukendte filer, nye admin-konti, ændrede omdirigeringer.
- Inddrag databeskyttelsesrådgiveren tidligt, ikke først efter oprydningen.
Hvordan hjælper PHP SOS konkret?
- Vi afklarer med hostingudbyder og bureau, hvem der patcher og genstarter PHP, og indhenter bekræftelsen med pakkestatus.
- Vi undersøger, hvor på webserveren formulardata, uploads og mailkopier ligger, og om der er forbindelser ind i praksisnetværket.
- Ved mistanke sikrer vi spor, leder efter webshells og renser serveren inden for rammerne af vores nødhjælp ved hackede websites.
- Vi dokumenterer hændelsen, så jeres databeskyttelsesrådgiver kan vurdere anmeldelsespligten.
- Bagefter reducerer vi gemte data og hærder serveren, så der næste gang står mindre på spil.
Ofte stillede spørgsmål
Er vores praksissoftware berørt af PHP2Shell?
Praksisadministrationssystemet og adgangen til telematikinfrastrukturen kører som regel adskilt fra websitet. Berørt er PHP-webservere, altså oftest praksis-websitet og formularer eller portaler, der er tilsluttet det. Om der er forbindelser mellem website og praksisnetværk, bør jeres it-leverandør undersøge.
Er data fra kontaktformularen sundhedsdata?
Ofte ja. Allerede ønsket om en fornyet recept eller et tidsønske på grund af bestemte gener tillader slutninger om helbredet. Sådanne data hører til de særlige kategorier efter art. 9 GDPR. Den præcise vurdering afklarer I med jeres databeskyttelsesrådgiver.
Skal jeg informere patienterne, hvis websitet er blevet hacket?
Det afhænger af, om personoplysninger er berørt, og hvor høj risikoen er for patienterne. Ved sundhedsdata er risikoen ofte høj. Beslutningen træffer I sammen med jeres databeskyttelsesrådgiver, om nødvendigt med juridisk rådgivning.
Hvem er ansvarlig for PHP-opdateringer på praksis-websitet?
Det står i hosting- eller vedligeholdelsesaftalen. Ved shared hosting og managed hosting patcher som regel hostingudbyderen, ved en egen server den ansvarlige tjenesteudbyder. Mangler der en klar regulering, bør I få den fastholdt skriftligt nu.