--- title: "05 Sicherheit & Betrieb" description: "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 -…" url: "https://aspi-gmbh.de/docs/05-sicherheit-betrieb/" updated: "2026-10-15" category: Anleitungen / MCDMS WebAkte --- # 05 Sicherheit & Betrieb 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=DATABASEMEDDOK{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=CONFIGScriptsWEBload.mcfscr ScriptSaveHTML=CONFIGScriptsWEBsave.mcfscr Action_DRUCKEN=CONFIGScriptsWEBDRUCKEN.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}CONFIGUSER.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}WebLOGS ``` 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: ``` WebPROGRAM ``` 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 ```