Die MCDMS WebAkte ist für den Betrieb innerhalb der vorgesehenen Klinik- bzw. MCDMS-Umgebung ausgelegt.

Im Produktivbetrieb erfolgt der Zugriff ausschließlich über HTTPS.

Sicherheitsrelevante Entscheidungen werden serverseitig getroffen. Der Browser bestimmt insbesondere nicht selbst:

• Benutzerrechte
• Patientenzuordnung
• Datensatzzugriff
• Tabellen oder Spalten
• Scriptpfade
• Action-Ziele
• technische Primärschlüssel
• Dateipfade

Die WebAkte behandelt Browserdaten grundsätzlich als nicht vertrauenswürdig.

HTTPS

Beispiel:

https://mcdms-webakte.klinik.intern:8443/

Der verwendete DNS-Name muss zum Serverzertifikat passen.

Für den Produktivbetrieb sollte ein Zertifikat einer vertrauenswürdigen internen oder öffentlichen Zertifizierungsstelle verwendet werden.

Selbstsignierte Zertifikate sind nur für technische Tests vorgesehen.

Benutzeranmeldung

Die Anmeldung erfolgt mit vorhandenen MCDMS-Benutzern.

Anmeldedaten werden ausschließlich für die Authentifizierung verwendet.

Passwörter:

• werden nicht in URLs übertragen
• werden nicht in Betriebslogs gespeichert
• werden nicht als normale Diagnoseinformation protokolliert

Fehlgeschlagene Anmeldeversuche können über die Konfiguration begrenzt werden:

[AUTHENTICATION]
Provider=MCDMS
FailedLoginLimit=5
FailedLoginWindowMinutes=15

WebSessions

Die Sessionsteuerung erfolgt über WEB.INI.

Beispiel:

[SESSION]
CookieName=MCDMS_SESSION
IdleTimeoutMinutes=30
AbsoluteTimeoutHours=8
MaxSessionsPerUser=3

IdleTimeoutMinutes

Beendet eine Sitzung nach der konfigurierten Zeit ohne Benutzeraktivität.

AbsoluteTimeoutHours

Begrenzt die maximale Gesamtdauer einer Session unabhängig von Aktivität.

MaxSessionsPerUser

Begrenzt die Anzahl gleichzeitig aktiver Sessions eines Benutzers.

Eine Session endet unter anderem durch:

• Logout
• Idle-Timeout
• Absolute-Timeout
• Verdrängung durch MaxSessionsPerUser
• Serverende
• sicherheitsbedingte Invalidierung

Die Session wird serverseitig verwaltet. PROJECT-HANDOVER

MCDMS5API und Sessionisolation

Jede authentifizierte WebSession besitzt eine eigene:

MCDMS5API.Framework

Instanz.

Framework-Instanzen werden nicht zwischen Benutzersitzungen geteilt.

Alle MCDMS-/COM-Aufrufe werden kontrolliert über die dafür vorgesehene gemeinsame Main-STA ausgeführt.

Beim Beenden einer Session werden soweit möglich:

ClosePatient
↓
Logout
↓
COM-Freigabe

ausgeführt.

Patientenschutz

Der aktuell ausgewählte Patient wird ausschließlich serverseitig in der Session verwaltet.

Bei jeder patientenbezogenen Operation werden unter anderem geprüft:

• aktuelle Session
• aktueller Patient
• PatientID
• Formular
• RecordID
• Berechtigung
• Patientenzuordnung des Datensatzes

Eine technische Datensatz-ID allein reicht niemals aus, um auf einen Datensatz eines anderen Patienten zuzugreifen.

Sicherer Patientenwechsel

Beim Wechsel des Patienten wird der bisherige MCDMS-Patientenkontext kontrolliert beendet.

Der vereinfachte Ablauf ist:

aktuellen Patienten schließen
↓
PatientVar zurücksetzen
↓
neuen Patienten initialisieren
↓
Benutzerkontext bereitstellen
↓
ScriptPatientSelect ausführen
↓
Patientenkontext freigeben

Schlägt das sichere Zurücksetzen des alten Patientenkontexts fehl, wird kein neuer Patient freigegeben.

In diesem Fall wird die Session verworfen und der Benutzer muss sich erneut anmelden. Die aktuelle Architektur arbeitet hier bewusst fail-closed. PROJECT-HANDOVER

Schutz vor veralteten Antworten

Patienten- und Formularoperationen verwenden einen serverseitig gebundenen Kontext mit Revision.

Dadurch kann eine verspätete Antwort eines älteren Patienten- oder Formularzustands nicht einfach in einen inzwischen gewechselten Kontext übernommen werden.

Die Kontextrevision schützt insbesondere bei:

• Patientenwechsel
• parallelen Requests
• Formularwechsel
• längeren Serveroperationen

Rechte über MATCHCODE

Für MCDMS-bezogene Formulare und Akteneinträge kann ein MATCHCODE verwendet werden.

Beispiel:

MATCHCODE=MEDIKATION

Die WebAkte ermittelt das effektive MCDMS-Recht serverseitig.

Dabei gelten:

-1 = gesperrt
 0 = kein Zugriff
 1 = lesen
 2 = lesen / erstellen / bearbeiten
 3 = Vollzugriff

Ein MCDMS-Administrator mit:

UserType=0

besitzt Vollzugriff.

Löschen

Löschen erfordert zusätzlich zur Formularfreigabe die entsprechende Berechtigung.

Zulässig ist Löschen für:

Administrator

oder

MCDMS-Recht 3

oder

MCDMS-Recht 2 + Eigentümer des Datensatzes

Die Prüfung erfolgt serverseitig.

Formulare ohne MATCHCODE

Für reine Webformulare ohne MCDMS-MATCHCODE stehen zusätzliche Regeln zur Verfügung.

AdminOnly

AdminOnly=TRUE

Das Formular ist nur für MCDMS-Administratoren verfügbar.

ONLY_USERS

ONLY_USERS=MUELLER;MEIER;SCHMIDT

Der Zugriff wird auf die angegebenen MCDMS-Loginnamen beschränkt.

Statusrechte

Akteneinträge können folgende Statuswerte besitzen:

0 = weiß / Ausgangszustand
1 = grün
2 = gelb
3 = rot
4 = blau

Statusänderungen werden ebenfalls serverseitig geprüft.

Administrator bzw. Recht 3 können Statuswerte entsprechend der vorgesehenen Logik ändern.

Benutzer mit Recht 2 dürfen bei eigenem Eintrag Statusänderungen durchführen, unterliegen jedoch den definierten Einschränkungen.

Ein grüner Eintrag ist besonders geschützt.

Beim Wiederfreigeben erscheint beispielsweise:

Zur weiteren Bearbeitung wieder freigeben?

SQL-Sicherheit

Tabellen-, Spalten- und Schlüsseldefinitionen stammen ausschließlich aus der serverseitigen Konfiguration.

Der Browser kann keine eigenen:

• SQL-Befehle
• Tabellennamen
• Spaltennamen
• Primärschlüssel
• Patientenfelder

vorgeben.

Datenwerte werden parametrisiert an SQL Server übergeben.

SQL-Metadatenprüfung

Vor Schreibvorgängen werden reale SQL-Metadaten geprüft.

Ein editierbares Formularfeld muss einer tatsächlich vorhandenen und beschreibbaren Spalte entsprechen.

Geschützt sind insbesondere:

• Primärschlüssel
• PatientID
• Identity
• computed columns
• rowversion / timestamp
• Detail-PK
• Master-FK

Diese Werte können nicht frei durch den Browser überschrieben werden. PROJECT-HANDOVER

Access-Sicherheit

Auch Access-basierte Formulare verwenden ausschließlich serverseitig konfigurierte Datenbankpfade.

Bei dynamischen Pfaden wie:

DatabaseFile=DATABASE\MEDDOK{IDDEV}.MDB

stammt {IDDEV} aus dem gesicherten Patientenkontext.

Der resultierende Pfad wird serverseitig geprüft.

Nicht zulässig sind unter anderem:

• Traversal aus dem vorgesehenen Bereich
• ungeprüfte Browserpfade
• unzulässige Reparse-/Weiterleitungsziele

Script-Sicherheit

MCDMS-Scripts können ausschließlich über serverseitige Konfiguration referenziert werden.

Beispiele:

ScriptLoadHTML=CONFIG\Scripts\WEB\load.mcfscr
ScriptSaveHTML=CONFIG\Scripts\WEB\save.mcfscr
Action_DRUCKEN=CONFIG\Scripts\WEB\DRUCKEN.MCFSCR

Der Browser übermittelt bei einer Action lediglich den konfigurierten Action-Namen.

Der tatsächliche Scriptpfad wird serverseitig ermittelt.

Scriptpfade werden gegen unzulässige Pfade, Traversal und Verlassen des APPPATH geschützt. PROJECT-HANDOVER

CSRF-Schutz

Schreibende bzw. zustandsverändernde Requests benötigen den vorgesehenen WebAkte-Request-Header:

X-MCDMS-Request: 1

Dies betrifft unter anderem:

• Login
• Patientenauswahl
• Speichern
• Actions
• Löschen
• Duplizieren

Zusätzlich werden jeweils Methode, Session, Kontext, Requestgröße und Ziel serverseitig validiert. PROJECT-HANDOVER

Security Header und CSP

Die WebAkte setzt restriktive HTTP-Sicherheitsheader.

Für Formularseiten gilt unter anderem eine Content-Security-Policy, die Ressourcen grundsätzlich auf die eigene WebAkte begrenzt.

Unterstützt werden normale lokale:

• Scripts
• Styles
• Bilder
• Fonts
• Media-Dateien

Externe Quellen sind standardmäßig nicht freigegeben.

eval() und new Function() sind nicht zulässig.

Zusätzlich werden unter anderem eingesetzt:

X-Content-Type-Options: nosniff
X-Frame-Options: DENY

und eine restriktive Referrer-Policy. PROJECT-HANDOVER

Dateizugriff über den Browser

Nicht jede Datei unter:

{APPPATH}\Web

ist automatisch per HTTP erreichbar.

Statisch ausgeliefert werden nur ausdrücklich zugelassene Webressourcen.

Typischerweise:

CSS
JS
IMAGES

Nicht direkt statisch erreichbar sind beispielsweise:

PROGRAM
SETUP
LOGS
WEB.INI
FORMULARE.INI

Formular-HTML wird ebenfalls nicht einfach als statische Datei ausgeliefert, sondern kontrolliert über den WebAkte-Formularweg gerendert. PROJECT-HANDOVER

Native MCDMS-Dokumente

Dateien aus der nativen MCDMS-Akte werden nicht über beliebige Browserpfade geöffnet.

Der Zugriff erfolgt anhand des Akteneintrags und des aktuellen Patienten- und Rechtekontexts.

Geprüft werden unter anderem:

• Patient
• AkteID
• Dokumenttyp
• Rechte
• konfigurierte Dateibereiche
• tatsächlicher Dateipfad

Pfade werden gegen Traversal und unzulässige Dateiumleitungen geschützt.

Windows-Dienst

Die MCDMS WebAkte läuft im Produktivbetrieb als Windows-Dienst.

Dienstname:

MCDMS.WebAkte

Status prüfen:

Get-Service MCDMS.WebAkte

Dienst neu starten:

Restart-Service MCDMS.WebAkte

Der Dienst ist auf automatischen Start konfiguriert.

Recovery

Für echte Prozessabstürze ist eine Recovery-Konfiguration vorgesehen.

Der Dienst wird bei entsprechenden Abstürzen automatisch neu gestartet.

Kontrolliert erkannte Konfigurations- oder Startupfehler werden dagegen bewusst beendet, ohne einen endlosen Windows-Service-Restart-Loop auszulösen.

Dienstkonto

Für eine lokale MCDMS-Installation kann beispielsweise:

LocalSystem

verwendet werden.

Liegt der APPPATH oder eine benötigte Ressource auf einer Netzwerkfreigabe, muss ein geeignetes Dienst- oder Domänenkonto verwendet werden.

Das Konto benötigt ausschließlich die für die verwendeten MCDMS-, Datenbank- und WebAkte-Ressourcen erforderlichen Rechte.

Zuletzt ausgewählte Patienten

Die Liste zuletzt ausgewählter Patienten verwendet die vorhandene MCDMS-VRL-Datei:

{APPPATH}\CONFIG\USER\<LOGINNAME>.VRL

Die Datei wird ausschließlich anhand des authentifizierten MCDMS-Loginnamens bestimmt.

Beim Lesen werden Einträge erneut gegen die aktuelle Patientenauswahl bzw. Sichtbarkeit geprüft.

Die Anzahl der im Web angezeigten Einträge wird über:

[PATIENT]
RecentPatientCount=10

gesteuert.

Logging

Die Logdateien befinden sich unter:

{APPPATH}\Web\LOGS

Dateinamen:

MCDMS-WebAkte-yyyy-MM-dd.log

Im Normalbetrieb werden insbesondere relevante:

WARN
ERROR

Einträge protokolliert.

Die aktuelle Loggingarchitektur verwendet korrelierbare Fehler-IDs, über die ein Benutzerfehler mit dem passenden Serverlog verbunden werden kann. PROJECT-HANDOVER

Fehler-ID

Bei technischen Fehlern kann der Benutzer beispielsweise sehen:

Fehler-ID: 20261014-085352-0FD0

Diese ID kann im Serverlog gesucht werden.

Technische Details wie:

• Exception
• Stacktrace
• SQL-Fehlerdetails
• interne Pfade

werden nicht im Benutzer-Dialog ausgegeben.

Datenschutz im Logging

Nicht als normale Betriebsdaten protokolliert werden insbesondere:

• Passwörter
• Session-Secrets
• Request-Bodies
• PatientVar-Inhalte
• vollständige medizinische Formulardaten
• Secrets

Diagnoseinformationen werden soweit möglich auf technische Metadaten begrenzt. PROJECT-HANDOVER

Log-Aufbewahrung

Die Aufbewahrungsdauer wird über:

[LOGGING]
DeleteLogsAfterDays=30

gesteuert.

Erweiterte Formulardiagnose

Für gezielte Fehlersuche kann aktiviert werden:

[LOGGING]
DetailedFormDiagnostics=TRUE

Im Normalbetrieb:

DetailedFormDiagnostics=FALSE

Die erweiterte Diagnose sollte nur temporär eingesetzt werden.

Statusprüfung

Die Erreichbarkeit des WebServers kann über:

/api/status

geprüft werden.

Beispiel:

Invoke-WebRequest `
  https://mcdms-webakte.klinik.intern:8443/api/status `
  -UseBasicParsing

Erwartet:

StatusCode : 200

Der Status-Endpunkt bestätigt die grundsätzliche Erreichbarkeit des WebServers.

Er ersetzt keinen vollständigen Funktionstest von:

• MCDMS-Login
• Patientenauswahl
• SQL
• Scripts
• konkreten Formularen
• Dateizugriffen

Betriebskontrolle

Für eine vollständige Betriebsprüfung sollte zusätzlich getestet werden:

Dienst läuft
↓
HTTPS ohne Zertifikatswarnung
↓
Login
↓
Patientensuche
↓
Patientenauswahl
↓
Formular öffnen
↓
Lesen
↓
Testdatensatz speichern
↓
Rechte prüfen

Updates

Updates sollten über den vorgesehenen Setup-/Deploymentprozess durchgeführt werden.

Bei einem reinen Programmupdate wird normalerweise nur:

Web\PROGRAM

aktualisiert.

Klinikspezifische Dateien wie:

WEB.INI
FORMULARE.INI
HTML
CSS
JS
IMAGES

dürfen nicht pauschal durch Beispielstände ersetzt werden.

Das aktuelle Setup bewahrt diese Bereiche bei einem reinen PROGRAM-Update. PROJECT-HANDOVER

Konfigurationsänderungen

Änderungen an:

WEB.INI
FORMULARE.INI

erfordern einen Neustart des Dienstes.

Beispiel:

Restart-Service MCDMS.WebAkte

HTML-/CSS-/JavaScript-Dateien werden dagegen beim Formularaufruf neu eingelesen und können grundsätzlich ohne Austausch der EXE geändert werden.

Grundprinzip

Die Sicherheitsgrenze liegt immer auf dem Server.

Vereinfacht:

Browser
↓
Request
↓
Session prüfen
↓
Patient prüfen
↓
Formular prüfen
↓
Rechte prüfen
↓
Datensatz prüfen
↓
Metadaten / Pfade prüfen
↓
Operation ausführen

Der Browser ist für Darstellung und Bedienung zuständig.

Er entscheidet nicht selbst über:

Patient
Recht
SQL-Ziel
Script
Dateipfad
technische IDs