Arbeitsgruppe

Datenschutz und IT-Sicherheit im Gesundheitswesen (DIG)

Sicherheitsempfehlungen zum Betrieb von Servern und lokalen Netzen in Krankenhäusern

Erarbeitet von der GMDS-Arbeitsgruppe „Datenschutz in Gesundheitsinformationssystemen“

Lokale Netze und Client-Server-Systeme mit den Serverbetriebssystemen Windows (NT, 2000, XP) oder Unix (Linux oder andere Varianten) werden immer häufiger in Krankenhäusern eingesetzt, meist zusätzlich zu einem zentralen Patientendaten-Verwaltungssystem. Dabei treten durch mangelnde Fachkenntnis und zeitliche Überlastung des IT-Personals, aber auch aufgrund von Sicherheitslücken in den Server-Betriebssystemen, Sicherheitsprobleme auf, die wirksamen Datenschutz verhindern. Die Konfiguration eines einigermaßen sicheren lokalen Netzes ist komplex und aufwendig. Dieser Aufwand ist aber aufgrund der Datenschutzvorschriften unumgänglich, sobald Patientendaten auf dem Server oder dem Netz gespeichert oder verarbeitet werden; er sollte auch in allen anderen Fällen im eigenen Interesse nicht gescheut werden und erfordert in jedem Fall eine Vollzeitstelle für einen Systemverwalter. In dieser Empfehlung kann das Thema bei weitem nicht erschöpfend behandelt werden. Nicht behandelt wird auch die Sicherheit von Arbeitsplatzrechnern; hierzu wird auf

  • Datenschutz und informationstechnische Sicherheit bei PCs (LfD Berlin)
  • Sicherheitsmaßnahmen beim PC-Einsatz (BSI-Faltblatt)

verwiesen. Ebenfalls nicht behandelt wird die Sicherheit der angebotenen Dienste und Anwendungen; für HTTP-Server wird auf

  • Die Einrichtung sicherer HTTP-Server (Kompetenznetz Pädiatrische Onkologie und Hämatologie)

verwiesen.

Grundsätzliches zur Sicherheit von Server-Betriebssystemen

Auf einem unsicheren Betriebssystem kann man keinen sicheren Server aufsetzen. Daher ist der Sicherung des Betriebssystems große Sorgfalt zu widmen. Prinzipiell lassen sich die gängigen System-Plattformen hinlänglich sicher konfigurieren, wobei der Aufwand nicht unterschätzt werden sollte. Die Wahl zwischen Windows NT/2000/XP oder einem gängigen Unix-System (z.B. Linux) sollte in erster Linie vom vorhandenen Know-How bestimmt werden.
Windows NT (und seine Nachfolger 2000 und XP) wird oft als sicheres Betriebssystem angepriesen. In der Tat bietet NT einige Sicherheitsmechanismen, die für IT-Betreiber, die MS-DOS, Windows 3 oder Windows 95/98/ME gewöhnt sind, sehr eindrucksvoll wirken. Dieser Eindruck ist aber irreführend, zumal die Systemvoreinstellungen nur wenige der möglichen Sicherheitsschranken in Kraft setzen. Ebenso wird die Sicherheit eines Servers, besonders bei Windows-Systemen, durch Installation und Betrieb von Anwendungssoftware in der Regel unterlaufen; manche Anwendungssoftware funktioniert sogar nur mit unsicheren System-Einstellungen. Auch die durch die Benutzungsoberfläche, besonders ab NT-Version 4.0, suggerierte Leichtigkeit der Konfiguration ist irreführend und gefährlich, da sie Nachlässigkeit provoziert. Hinzu kommt bei Windows-Systemen, dass beim Einspielen von Bugfixes und »Service-Packs« oft sorgfältig konfigurierte Sicherheitseinstellungen zurückgesetzt werden.
Unix-Systeme sind im Gegensatz dazu für den erfahrenen Systemverwalter übersichtlicher. Die Einarbeitungszeit ist zwar möglicherweise etwas länger, dafür sind aber die Systemprozesse und Fehlerbehebungsvorgänge wesentlich leichter unter Kontrolle zu halten, und die Konfiguration ist deutlich leichter nachvollziehbar; der Server ist damit insgesamt leichter sicher zu halten. Im Zweifelsfall ist daher ein Unix-System vorzuziehen. Wichtig ist in jedem Fall eine "Härtung" des Servers. Das bedeutet unter anderem:

  • Einspielen aller aktuellen Patches, Schließen aller bekannten Sicherheitslücken. Hier sind vor allem die Hinweise des CERT/CC laufend zu beachten. Bei Windows-Systemen ist anschließend eine genaue Kontrolle und gegebenenfalls Restaurierung aller vorher getätigten Sicherheitseinstellungen nötig.
  • Deaktivieren aller nicht benötigten Dienste (File-Sharing/NFS, FTP, Mail, Telnet, RAS, RPC, …) - jeder nicht benötigte, "vergessene" Dienst ist ein potentielles Sicherheitsrisiko.
  • Aufstellen des Servers in einem gesicherten, nicht allgemein zugänglichen Bereich.
  • Verwenden eines kryptographischen Dateisystems für Dateien und Datenbanken mit personenbezogenen Daten. Unter Linux kann ein entsprechender Treiber eingebunden werden, siehe
    • The Linux Encryption-HOWTO Homepage
      Unter Windows ist PGPdisk oder ScramDisk zu empfehlen:
    • PGPdisk
    • ScramDisk
      Von der mit neueren Windows-Systemen mitgelieferten Dateisystem-Verschlüsselung ist wegen gravierender Mängel abzuraten.
  • Soll ein HTTP-basierter Service angeboten werden, sollte man den Internet Information Server (IIS) vermeiden. Auch unter Windows ist der Apache-Server die sicherere Lösung.
  • Administration des Servers nur über die Konsole. Falls die Administration über einen Netzzugang nicht zu vermeiden ist, sollte ein kryptographisch gesichertes Protokoll verwendet werden, also z. B. im Unix-Bereich nicht Telnet, sondern SSH, das in den üblichen Distributionen enthalten ist oder leicht nachgerüstet werden kann; Quelle im WWW hier. SSH-Clienten sind auch für Windows-Systeme kostenlos erhältlich. Auch eine VPN-Verbindung ist bei passender Konfiguration geeignet.

Weitere Hinweise zur Serverhärtung findet man im WWW:

  • Linux Security HOWTO
  • The Bastille Linux Hardening System
  • Hardening OpenBSD Internet Servers (GeodSoft Website Consulting)
  • Deaktivieren von Diensten unter W2K
  • Windows 2000 Security Recommendation Guides (NSA)
  • Hardening Windows 2000 (Phil Cox, System Experts)
  • Building a Windows NT bastion host in practice

Das angestrebte Sicherheitsniveau sollte mindestens dem „mittleren Schutzbedarf“ im

entsprechen, soweit möglich auch darüber hinausgehen.
Um über aktuelle Sicherheitsfragen stets auf dem laufenden zu sein, sollte der Systemverwalter mindestens eine einschlägige Usenet-Newsgruppe oder Mail-Liste verfolgen.

Sicherheitsratschläge für Aufstellung und Konfiguration von Servern

Um die Sicherheitsmechanismen des Betriebssystems wirkungsvoll einzusetzen, ist eine ausführliche Planung, insbesondere der Zugriffsrechte, und eine sehr sorgfältige Umsetzung nötig. Das Prinzip der minimalen Rechte sollte bei der Zugriffsregelung strikt beachtet werden. Im Netz sollte genau festgelegt werden, welcher Rechner in welche anderen welches Ausmaß an Vertrauen setzt und welche Ressourcen an ihn freigegeben werden. Ebenso sollten die Benutzer-Zugriffsrechte auf Ressourcen und Shares in einer Rechte-Matrix spezifiziert werden.
Es sollte stets eine ausgedruckte Version der System-Konfiguration einschließlich Vernetzungsplan und eine exakte Beschreibung der Sicherheitspolitik („Policy“, „Systemrichtlinien“) zur Hand sein. Die Konfiguration sollte sorgfältig dokumentiert sein, insbesondere die Sicherheitsmaßnahmen. Eine Auswahl wichtiger Sicherheitsmaßnahmen ist:

  • Server sind physisch geschützt aufzustellen, z.B. in einem verschlossenen Raum.
  • Es ist sicherzustellen, dass unbefugte Benutzer nicht ein alternatives Betriebssystem booten können. Geeignete Maßnahmen hierfür sind:
    • Aufstellung in einem verschlossenen Raum,
    • verschließbares Sicherheitsgehäuse,
    • keine Installation anderer Betriebssysteme oder Betriebssystem-Versionen auf anderen Partitionen,
    • Entfernung oder Verschluss der Diskettenlaufwerke,
    • Einschränkung der Boot-Möglichkeiten in der Hardware-Konfiguration,
    • Setzen eines Hardware-Passworts (nicht geeignet, wenn autoboot für den Server notwendig ist),
    • Setzen des Boot-Timeouts auf 0 Sekunden;
      sie können einzeln oder in sinnvoller Kombination angewendet werden.
  • Die Benutzerkennung „Gast“ ist stillzulegen, ebenso die Gruppe "Gäste"; letzteres geht nur, wenn auf dem System nicht der Internet Information Server laufen soll.
  • Die CD-Autoplay-Funktion ist abzuschalten.
  • Die Protokollierung ist, soweit sinnvoll, einzurichten. Um die Balance zwischen der Aufzeichnung wichtiger sicherheitsrelevanter Vorgänge und der Erzeugung einer nicht mehr überblickbaren Datenflut zu wahren, sind dazu sorgfältige Detail-Überlegungen nötig. Zugriff auf Log-Dateien sollte nur der Administrator haben. Da NT die Protokollierung stillschweigend einstellt, wenn eine Log-Datei voll ist, ist die Größe dieser Dateien stets sorgfältig zu kontrollieren.
  • Der Zugriff auf die Konfigurations-Datenbank (Registry) ist soweit wie möglich einzuschränken.
  • Auf Systemverzeichnisse (z.B. \winnt) und deren Unterverzeichnisse dürfen gewöhnliche Benutzer und Prozesse nur Lesezugriff haben.
  • Da Backup-Operatoren Lese- und Schreibzugang zum gesamten Dateisystem haben, ist der berechtigte Personenkreis eng einzugrenzen; es sollte eine besondere Benutzer-Kennung dafür verwendet werden, deren Rechte genau an die Aufgabe angepasst sind.
  • Für alle Benutzer, auch die voreingestellten, sind Passwörter zu setzen. Die Auswahl von Trivial-Passwörtern sollte verhindert werden (Passfilt.dll ab NT 4.0 mit SP2 verfügbar).
  • Als Maßnahme gegen das systematische Ausprobieren von Passwörtern sollten folgende Vorkehrungen getroffen werden: ◦Konto sperren nach 3 ungültigen Fehlversuchen.
    • Konto zurücksetzen nach 30 Minuten (das betrifft den Fehlversuchs-Zähler).
    • Dauer der Sperrung: Für immer (bis der Administrator sie aufhebt).
      Unter Windows macht man das im Benutzer-Manager unter „Richtlinien“, „Konten“.

Sicherheitsratschläge für den Systemadministrator

  • Systemverwalter sollten eine Benutzer-Kennung mit Administrator-Rechten nur für wirkliche Verwaltungsaufgaben nutzen. Für Arbeiten, die nicht die vollen Privilegien benötigen, sind gewöhnliche Benutzer-Kennungen zu verwenden. Insbesondere sollte unter Administrator-Rechten nicht mit Anwendungen gearbeitet werden, die für das Einschleusen von Schadprogrammen anfällig sind, wie die MS-Office-Anwendungen, E-Mail oder WWW-Browser.
  • An Servern sollte, außer für Administrator-Aufgaben, nicht lokal gearbeitet werden.
  • Bei der Unterbrechung von Systemadministrator-Arbeiten sollte ein Logout ausgeführt oder die Arbeitsstation gesperrt werden (unter Windows im Task-Manager ([Strg]+[Alt]+[Entf])).
  • Um das Aussperren des Systemverwalters und als Folge möglicherweise eine längerdauernde Nichtverfügbarkeit des Rechners oder einzelner Dienste (`denial of service'-Attacke) zu verhindern, darf es für �Administrator� bzw. �root� keine Passwortsperre nach mehreren Fehlversuchen geben. Daher sollte man dessen Logon nur lokal zulassen.
  • Um auch in Notfällen Administrator-Aufgaben wahrnehmen zu können, sollte das Administrator-Passwort in einem versiegelten Umschlag an sicherer Stelle, z.B. in einem Safe, hinterlegt werden. Gleiches gilt für ein eventuelles Hardware-Passwort und für Schlüssel zu Zugangstüren oder Rechnergehäuse.
  • Eine Anmeldung über das Netz oder gar über eine unverschlüsselte Fernverbindung (mit RAS-Berechtigung) ist unter Sicherheitsgesichtspunkten besonders kritisch zu werten. Als mögliche Sicherheitsmaßnahme unter Windows können im Benutzer-Manager unter „Benutzerrechte“ in der Rubrik „Zugriff auf diesen Computer vom Netz“ die Gruppen „Administratoren“ und „Jeder“ entfernt werden. Eine weitere, damit allerdings nicht zu vereinbarende, Maßnahme ist die Einrichtung einer anderen Kennung mit Administrator-Rechten, für die der Zugang über das Netz möglich ist, allerdings die Passwortsperre bei Fehlversuchen funktioniert.
  • Als Logon-Möglichkeit über das Netz sollte nur ein verschlüsseltes Protokoll (SSH unter Unix) zugelassen werden.
  • Mitarbeiter sollten auf ihren Arbeitsplatzrechnern keine, auch nicht die lokale, Administrator-Berechtigung erhalten; Ausnahmen sind nur bei besonderen Systemkenntnissen möglich.

Die gelegentlich gehörte Empfehlung, die Administrator-Kennung mit einem anderen Benutzernamen zu versehen, ist weitgehend nutzlos, da NT-Rechner auf mehreren Wegen bereitwillig die Kennung des Administrators verraten.

21. Oktober 2001. Letzte redaktionelle Änderung: 26. Oktober 2001.