Arbeitspapier zur Datensicherheit bei Client-Server-Systemen (Stand Dezember 1996, veröffentlicht in: 25. Tätigkeitsbericht des
Hessischen Datenschutzbeauftragten Ziff.20.2)


Seit einiger Zeit verlieren Zentralrechner bei der Datenverarbeitung an Bedeutung. Dezentrale Strukturen nehmen zu. Mit dieser Änderung gehen neue Anforderungen an die Datensicherheit einher, da nicht mehr der Zentralrechner, sondern das Netz und die lokalen Rechner ebenso wie die Server Gegenstand von Sicherheitsbetrachtungen sind.

Die Datensicherheit von IT-Systemen ist ein integraler Bestandteil des Datenschutzes (vgl. z.B. § 10 HDSG). In den letzten Jahren haben sich nach meinen Erfahrungen die Schwerpunkte der eingesetzten Technik verschoben (vgl. 20. Tätigkeitsbericht, Ziff. 15.2, 24. Tätigkeitsbericht, Ziff. 12.2, 25. Tätigkeitsbericht, Ziff. 5.1). Statt zentraler Großrechner-(Host-)Verfahren werden zunehmend dezentrale Verfahren mit einer Client-Server-Architektur geplant und eingesetzt. Bei dieser Technik finden, je nach Ausprägung, wesentliche Teile der Datenverarbeitung auf dem lokalen Arbeitsplatz statt. Dadurch bedingt ergeben sich andere Anforderungen an die Datensicherheit und damit an die zu treffenden Sicherheitsmaßnahmen.

Client-Server-Architektur
Modell des Ablaufs einer Datenverarbeitung mit, in der Regel, mehreren Rechnern. Dabei ruft ein Rechner, der Client oder Dienstnehmer, eine Leistung auf (Anforderung von Daten, Überstellen einer elektronischen Post, ...), und der aufgerufene Rechner, der Server oder Dienstgeber, erbringt eine Leistung (stellt die Daten zur Verfügung, leitet die elektronische Post weiter, ...). Je nach Ausprägung können die Verarbeitungsschritte unterschiedlich auf die Rechner verteilt sein.

Der Auslöser für diese Änderungen der Informationstechnik war meist eine generelle Unzufriedenheit mit der vorhandenen Datenverarbeitung. Die Gründe waren vielschichtig. So sollte z.B. die Abhängigkeit von einem Anbieter beendet werden; ob dieses Ziel erreicht wurde, muß in vielen Fällen bezweifelt werden. Es sollten die Fachabteilungen mehr Einfluß auf die Ausgestaltung der Datenverarbeitung erhalten, da sich der Eindruck einer unzureichenden Kunden- (Fachabteilungs-) orientierung der DV-Abteilungen ergeben hatte. Die zunehmende Verfügbarkeit von Fachprogrammen für PC ließ Lösungen sinnvoll erscheinen, bei denen ohne Einschaltung der DV-Abteilung eigene Rechner angeschafft werden. Ferner hatten immer mehr Benutzer eigene PC und damit die grafischen Benutzeroberflächen kennengelernt. Die Diskrepanz zu den am Arbeitsplatz üblichen Bildschirmmasken war so groß, daß Anpassungen nötig wurden. Aus diesen und weiteren Gründen wurden Lösungen gesucht, die in vielen Fällen auf eine Entscheidung zentrale gegen dezentrale Datenverarbeitung hinausliefen. Im Ergebnis wurde oft die Client-Server Technik gewählt.

Durch diese Technik ändern sich die Schwerpunkte bei der Betrachtung von Risiken und Maßnahmen für die Datensicherheit. Statt sich auf den Zentralrechner (Host) zu konzentrieren, müssen das Netz, die Clients und die Server betrachtet werden. Je nach der eingesetzten Technik gibt es neue Risiken, oder Risiken sind anders zu bewerten.

Unabhängig von der eingesetzten Technik sollte, um eine ausreichende Datensicherheit zu erreichen, ein Datensicherheitskonzept erarbeitet werden. Hierbei hat sich das Vorgehen nach dem IT-Sicherheitshandbuch des Bundesamtes für Sicherheit in der Informationstechnik (vgl. 23. Tätigkeitsbericht, Ziff. 25.1) bewährt, wobei u.a. auf das Grundschutzhandbuch des Bundesamt für Sicherheit in der Informationstechnik zurückgegriffen werden kann, das für personenbezogene Daten nach meiner Auffassung einen Mindestschutz definiert. Im folgenden möchte ich auf Punkte hinweisen, die sich nach meiner Erfahrung bei Beratungen und Prüfungen als beachtenswert gezeigt haben, da sie in der Praxis oft nicht oder nicht ausreichend umgesetzt sind. Die ganze Bandbreite der umzusetzenden Maßnahmen kann an dieser Stelle nicht aufgezeigt werden; dazu und zu Details muß weiterführende Literatur herangezogen werden.

20.2.1
Organisatorische Maßnahmen

20.2.1.1
Unternehmenspolitik bestimmen

Die Unternehmenspolitik muß die Perspektiven für die DV-Entwicklung festlegen. Bei einer Client-Server-Lösung muß zuerst die Entscheidung gefallen sein, zukünftig die Datenverarbeitung in Teilen dezentral durchzuführen. Dabei gilt es die Funktionen zu bestimmen, die in die Abteilungen verlagert werden. Zur Zeit wird unter dem Stichwort "Outsourcing" oft überlegt, die Datenverarbeitung oder zumindest Teile an Dritte zu übertragen.

20.2.1.2
Konzepte erstellen

Für die Planungen ist es unumgänglich, ein IT-Gesamtkonzept, ein IT-Sicherheitskonzept - z.B. nach der Vorgehensweise gemäß IT-Sicherheitshandbuch-, Datenschutzkonzepte und ein Revisionskonzept zu erstellen. Das Revisionskonzept kann in andere Konzepte, beispielsweise das IT-Sicherheitskonzept, integriert werden.

Es zeigt sich immer wieder, daß insbesondere ein IT-Sicherheitskonzept und Datenschutzkonzepte fehlen.

20.2.1.3
Berechtigungen vergeben und dokumentieren

Zutrittsberechtigungen und Zugriffsberechtigungen müssen festgelegt und dokumentiert werden. Dabei ist es nicht Aufgabe der Systemverwaltung, die Zugriffsberechtigungen festzulegen; die Vorgaben müssen von der für die jeweilige Anwendung/Teilanwendung zuständigen Fachabteilung gemacht werden. Die Systemverwaltung setzt diese Vorgaben dann um. Die Kontrolle, ob die Einträge korrekt sind, muß dann - soweit möglich - eine dritte unabhängige Instanz, wie z.B. der behördliche Datenschutzbeauftragte oder die DV-Revision, vornehmen. Es muß mit der Dokumentation der Benutzerverwaltung nachvollziehbar sein, wer wann welche Rechte hatte und wer das Anlegen oder Ändern von Benutzerkennungen und Zugriffsrechten veranlaßt hat.

Bei der Vergabe von Benutzerkennungen ist darauf zu achten, daß einer Benutzerkennung nur eine Person zugeordnet ist. Nur in diesem Fall ist durch die (technische) Identifikation und Authentisierung bei Client bzw. Server ein Rückschluß auf die Person möglich, was Grundlage von Zugriffskontrolle und Protokollierung ist. Eine Abweichung darf nur in Ausnahmefällen akzeptiert werden (vgl. Ziff. 5.1).

Bei Prüfungen und Beratungen zeigen sich in diesem Punkt oft Schwachstellen. So ist es allzuhäufig nicht nachvollziehbar, wer wann mit welchen Zugriffsrechten auf einem System arbeiten konnte.

20.2.1.4
Dokumentationen

Es muß aussagefähige Dokumentationen zum lokalen Netz (Verkabelungsplan, Installationsdokumentation, Konfigurationsdokumentation), zur Hardware (Geräteverzeichnis) und zur Software (Dateiverzeichnis, Verfahrensdokumentationen) geben.

20.2.1.5
Richtlinien, Standards und Zuständigkeiten festlegen, Dienstanweisungen erstellen

Nähere Ausführungen sind im Arbeitspapier zu Dienstanweisungen für den Datenschutz zu finden.

20.2.1.6
Protokollierung

Protokolle spielen bei vielen der folgenden Maßnahmen eine Rolle. Immer dann, wenn die Nachvollziehbarkeit der Abläufe gewährleistet sein muß, ist eine Protokollierung von Ereignissen unumgänglich. Dies trifft für mehrere der im folgenden genannten Punkte zu wie: Zutrittsschutz, kontrollierte Netzübergänge, Identifikation und Authentisierung (bei Server und Client), Zugriffskontrolle und Tätigkeit der Systemverwaltung. Eine Protokollierung darf jedoch nicht zum Selbstzweck werden. Deshalb muß z.B. im Revisionskonzept festgelegt werden, wer zu welchen Zwecken welche Protokolle wann benötigt. Auf Protokolle, die niemand benötigt, muß - selbstverständlich - verzichtet werden (zur Protokollierung s. auch die im 24. Tätigkeitsbericht, Ziff. 19.1 abgedruckte Orientierungshilfe).

20.2.2
Personalmaßnahmen

20.2.2.1
Ausreichende Anzahl Mitarbeiter

Wenn keine ausreichende Zahl Betreuer vorhanden ist, müssen Aufgaben liegen bleiben oder nur unzureichend erfüllt werden. Die Erfahrung zeigt, daß bei Überlastung solche Bereiche nicht bearbeitet werden, in denen Versäumnisse nicht sofort augenfällig werden, unabhängig davon, welche Konsequenzen mittelfristig zu erwarten sind. Der Bereich Datensicherheit und Datenschutz gehört allzuhäufig dazu.

Auf die Frage, wieviele Benutzer ein Betreuer sinnvoll unterstützen kann, gibt es keine allgemein gültige Antwort. Es spielt beispielsweise eine Rolle, welche Programme eingesetzt werden, welche Art Unterstützung ein Betreuer gibt, wieviel Aufgaben am Arbeitsplatz anfallen und wieviel Hilfe außerhalb der DV-Betreuung erfolgt. So wurden Ende 1993 bei einer nicht repräsentativen Umfrage zu bestehenden Bürokommunikationslösungen in der Hessischen Landesverwaltung Werte zwischen 0,3 und 1,2 Betreuern je 100 Personen im Rahmen der Benutzerbetreuung genannt; ohne Kenntnis der Rahmenbedingungen ist aber kein Vergleich möglich. Es wird immer wieder in diesem Zusammenhang auf Aussagen der KGSt Bezug genommen, die vor ca. zehn Jahren Relationen von 70 Personen zu einem Betreuer bei der Systembetreuung und 30 zu 1 bei der Benutzerbetreuung empfohlen hat. Diese Werte können nur einen Anhaltspunkt darstellen. Für fundierte Aussagen muß jede Konstellation einzeln analysiert werden.

Ein weiterer Problembereich ist bei Spezialaufgaben zu sehen, in denen eine Vertretung gewährleistet sein muß. Hier muß auf die Firewalls verwiesen werden (vgl. Orientierungshilfe Internet). Sind die Aufgaben so wichtig, daß jederzeit eine qualifizierte Person zugegen sein muß, ergibt sich ein Mindestbedarf von drei Personen, von denen zwei die Aufgabe allein erfüllen können und eine Person mit Unterstützung.

20.2.2.2
Qualifiziertes Personal

Speziell im öffentlichen Dienst gibt es in Abhängigkeit von der Arbeitsmarktlage immer wieder Abwanderungen von Spezialisten, die in der Privatwirtschaft bessere Verdienstmöglichkeiten oder andere Vorteile sehen. Aber auch der öffentliche Dienst kann ohne qualifiziertes Personal nicht bestehen. Hier sei an die Beispiele Firewall-Administration oder Systemverwalter erinnert. Nur mit qualifiziertem Personal kann die Leistung in der geforderten Güte erbracht werden.

20.2.2.3
Schulung aller Mitarbeiter in Fragen des Datenschutzes und der Datensicherheit

Die Sensibilisierung der Mitarbeiter in Fragen des Datenschutzes und der Datensicherheit ist unbedingt erforderlich. Anderenfalls werden Schutzmaßnahmen als Schikane wahrgenommen und nicht oder nur unzureichend umgesetzt. Dies gilt insbesondere für die Bedeutung von Benutzerkennungen und Paßwörtern. (Zur Bedeutung des Paßwortes vgl. 19. Tätigkeitsbericht, Ziff. 15.5; ferner Ziff. 20.2.5.1).

20.2.3
Zutrittsschutz

Auch bei einer Client-Server-Technik kommt den räumlichen Sicherheitsvorkehrungen eine hohe Bedeutung zu. Wer Zutritt zur Hardware hat, kann Manipulationen vornehmen, die anderenfalls nicht möglich sind. Beispielsweise kann man Server mit an sich sicherem Betriebssystem oft mit Disketten booten, um dann an den Zugriffskontrollmechanismem des Betriebssystems vorbei mit Hilfsprogrammen auf Daten zuzugreifen. Auch für Netzkomponenten gilt, daß Manipulationen leichter möglich sind, wenn man den Zutritt zu den Komponenten hat. Während es bei Servern und Netzkomponenten unabdingbar ist, durch bauliche oder andere Maßnahmen (z.B. verschließbare Stahlschränke) nur berechtigten Personen einen Zugriff möglich zu machen, treten bei Clients Schwierigkeiten auf. Hier gibt es viele Konstellationen, in denen es nicht ausgeschlossen werden kann, daß andere Personen einen Zugriff haben. In diesem Fall müssen weitere Schutzmaßnahmen ergriffen werden.

20.2.4
Netz

Ein unbefugter Zugriff auf Daten während der Übertragung im lokalen Netz birgt große Risiken; eine allgemeine Darstellung von Aspekten der Datensicherheit in Netzen habe ich im 22. Tätigkeitsbericht (Ziff. 21.1) gegeben. Die Ursache liegt in den meist eingesetzten broadcastorientierten Protokollen. Broadcastorientiert bedeutet, daß Nachrichten an alle angeschlossenen Rechner gehen und jeder Rechner nach Auswertung der Zieladresse erst feststellt, ob die Nachricht für ihn bestimmt war. Dabei erhält er jedoch die gesamte Nachricht. An jeder Stelle im Netz stehen daher theoretisch alle übertragenen Daten zur Verfügung. Aus diesem Grund, aber auch wegen der starken Beeinflussung der Leistung im Netz bei hohem Datenaufkommen, wurden Techniken entwickelt, die geeignet sind, beide Probleme zu reduzieren.

20.2.4.1
Festlegung zulässiger, erforderlicher Kommunikationsbeziehungen

Im Vorfeld weiterer Maßnahmen, wie der Bildung von Subnetzen, müssen die zulässigen und erforderlichen Kommunikationsbeziehungen bestimmt werden.

20.2.4.2
Bildung von Subnetzen

Aufgrund der im ersten Schritt festgestellten Kommunikationsbeziehungen lassen sich Subnetze definieren, in denen Rechner zusammengefaßt werden, zwischen denen eine Kommunikation zulässigerweise stattfindet.

20.2.4.3
Kontrollierte Netzübergänge

Zwischen dem gesamten Netz und der Außenwelt, aber auch zwischen den Subnetzen, darf eine Kommunikation nur kontrolliert stattfinden. Dazu bieten sich Firewalls an (vgl. 25.Tätigkeitsbericht Ziff. 21.8), mit denen eine Kommunikation hinsichtlich der gewünschten Dienste sowie Quell- und Zieladresse überprüft und bei positivem Ergebnis erlaubt werden kann.

In diesem Bereich finden sich häufig Lücken, weil z.B. für Fernwartungen (vgl. 24. Tätigkeitsbericht, Ziff. 17.4) unzureichend gesicherte Zugänge geschaffen werden oder Mitarbeiter ohne Rücksprache an ihrem Arbeitsplatz mit Modem eigene Zugänge realisieren.

20.2.4.4
Netzadministration

Die Netzadministration sollte nur von speziellen Arbeitsplätzen in zutrittskontrollierten Räumen aus möglich sein und mit einer Protokollierung der Tätigkeit verbunden sein.

20.2.4.5
Topologie

Derzeit wird oft noch eine busförmige Topologie eingesetzt, d.h. alle Geräte befinden sich an einem Kabelstrang. Um den Gesichtspunkten der Datensicherheit genügen zu können, ist jedoch in der Regel eine Topologie besser geeignet, bei der eine sternförmige Verkabelung auf Etagenebene mit abgeschirmten Kupferkabeln und eine Verbindung zwischen den Etagen mit Glasfasern realisiert wird. Die Netzkomponenten wie Router, Switches usw. müssen dabei gegen unberechtigte Zugriffe geschützt sein.

20.2.4.6
Technik

Nicht jede auf dem Markt verfügbare Technik ist zur Erreichung der o.g. Ziele gleich gut einsetzbar. So sind selbstlernende Router/Bridges mit Problemen verbunden, da sie keine vordefinierten Subnetze erlauben, während sich filternde Sternkoppler (per-port-Bridge) sinnvoll einsetzen lassen. Ferner müssen nicht zugelassene Rechner erkannt und abgewiesen werden; denkbare Maßnahmen sind beispielsweise abgeschlossene Netzsteckdosen oder das Erkennen von unzulässigen Ethernet-Adressen.

Während eine Verschlüsselung von Paßwörtern in jedem Fall erforderlich ist, kann auf eine Verschlüsselung der Inhaltsdaten bei der Übertragung verzichtet werden, soweit die Technik sicherstellt, daß Daten nur an den vorgesehenen Rechner gelangen oder es sich um weniger sensible Daten handelt, die in einem Subnetz bleiben. Mittelfristig ist eine Verschlüsselung von Inhaltsdaten in jedem Fall wünschenswert und bei sensiblen Daten unumgänglich.

20.2.5
Clients

Clients dürfen nur durch berechtigte Personen im zulässigen Umfang genutzt werden können. Auch darf die Gesamtsicherheit nicht davon abhängen, daß alle Rechner im Netz sicher sind. Es gibt Bereiche, bei denen nach meiner Erfahrung häufig Probleme auftreten.

20.2.5.1
Identifikation und Authentisierung

Die Identifikation und Authentisierung gegenüber dem Rechner, d.h. meist die Eingabe der Benutzerkennung (Identifikation) und eines Paßwortes (Authentisierung) beim Anmeldevorgang, ist die für die Datensicherheit entscheidende technische Funktion. Dies gilt für Server, Hosts oder Clients. Obwohl z.Z. neue Verfahren zur Authentisierung aufkommen (Prüfung biometrischer Merkmale, Einsatz von Chipkarte), ist die Eingabe eines Paßwortes weiterhin die gebräuchliche Methode. Die Zugriffskontrolle, die Protokollierung und alle weiteren benutzerbezogenen Funktionen basieren auf der in diesem Schritt festgestellten Identität. Deshalb ist es erforderlich, daß jede Person, die mit einem Rechner arbeitet, eine Anmeldeprozedur durchläuft. Dies gilt insbesondere für Systemverwalter.

Wegen der zentralen Bedeutung muß eine hohe Qualität des Anmeldevorgangs erreicht werden. In meinem 19. Tätigkeitsbericht (Ziff. 15.5) habe ich insbesondere die folgenden Anforderungen genannt:

Ein Paßwort muß eine Mindestlänge von 6 - 8 Stellen haben; es muß eine maximale Anzahl von Fehlversuchen einstellbar sein, nach denen eine Kennung gesperrt wird; es muß eine maximale/minimale Gültigkeit festgelegt werden können; die Paßwörter müssen verschlüsselt gespeichert werden.

Systemseitig können diese Anforderungen von vielen Betriebssystemen in ihren neuen Versionen weitgehend umgesetzt werden, wenn sie korrekt administriert sind; Beispiele sind Guardian, Windows NT 4.n, neue UNIX-Versionen oder Novell Netware 4.n. Einige weitverbreitete Betriebssysteme wie DOS oder Windows 3.n sind ohne Zusatzprodukte jedoch nicht geeignet.

Um bei Clients eine Authentisierung vorzunehmen, wird als rudimentärer Schutz oft mit dem BIOS-Paßwort gearbeitet. Arbeiten mehrere Benutzer mit einem Client oder werden sensible Daten verarbeitet, reicht dieser Schutz nicht aus, da mehrere Anforderungen an eine Paßwortverwaltung nicht erfüllt werden (Mindestlänge, Gültigkeitsdauer, Historie, Protokoll fehlgeschlagener Anmeldeversuche, nur einer Person bekannt, ...). Als Konsequenz ist, wenn mehrere Benutzer mit einem Client arbeiten, keine Identifikation der Person möglich, oder, bei sensiblen Daten, die Güte der Anmeldeprozedur unzureichend. Es bedarf einer Zugriffsschutzsoftware. Als weiteres Problem zeigt sich in der Praxis, daß Vertreterregelungen nur schwer umgesetzt werden können.

Wenn möglich sollte die User-ID eines Benutzers netzweit eindeutig sein.

20.2.5.2
Bildschirmschoner mit Paßwortabfrage

Bei einem Bildschirmschoner muß die Paßwortfunktion aktiviert sein. Trotz der häufig genannten Schwächen dieser Lösung, die eine Sicherheit allein auf dieser Funktion nicht ausreichend erscheinen läßt, bietet sie zumindest einen ersten Ansatz. Der Zeitraum, nach dem der Schoner anspricht, sollte sich nach den Erfordernissen am Arbeitsplatz richten. Kriterien sind insbesondere, ob Dritte Einsicht nehmen können und wie lang die üblichen Eingabepausen während der Arbeit sind.

20.2.5.3
Kein Diskettenlaufwerk

Mit Disketten - oder besser auswechselbaren Datenträgern wie auch CD-ROM - sind eine Reihe von Risiken verbunden, die ein DV-Verantwortlicher beachten muß. So könnten Viren auf Rechner eingeschleust werden, Software aufgespielt werden, für die keine Lizenz vorhanden ist oder Daten unzulässigerweise kopiert werden (gilt nicht für CD-ROM). Im Grundsatz dürfen daher Diskettenlaufwerke nur zur Verfügung stehen, wenn diese und weitere Risiken weitgehend ausgeschlossen werden können. Insofern spricht vieles dafür, nur über zentrale "Schleusen" einen Datenaustausch mittels Disketten zuzulassen und Clients ohne Diskettenlaufwerke einzusetzen. Diese Lösung stößt immer dann auf Probleme, wenn häufig Fehler auftreten, die ein Booten von Diskette erforderlich machen. Auch bereitet es Schwierigkeiten, wenn sich viele Personen eine "Schleuse" teilen müssen und durch die Abläufe spürbare, störende Einflüsse auf die Arbeit eintreten. Nach Abwägung aller Argumente kann es sich als erforderlich erweisen, zusätzliche Diskettenlaufwerke vorzuhalten. Dann müssen aber die Prüfungen, die sonst an der zentralen "Schleuse" vorgenommen werden, an den "Abteilungsschleusen" durch Verantwortliche weiterhin erfolgen. Für normale Benutzer müssen die Diskettenlaufwerke gesperrt bleiben.

20.2.5.4
Booten von der Festplatte oder dem Server

Weiterhin sollte das Booten von der Festplatte nicht unterbrechbar sein.

20.2.5.5
Kein Zugriff auf die Systemebene

Dem normalen Benutzer ist der Zugriff auf die Betriebssystemebene zu sperren, da anderenfalls anwendungsinterne Zugriffsschutzmechanismen unterlaufen werden könnten.

20.2.5.6
Zugriffseinschränkungen auf lokale Daten

Wenn auf der lokalen Festplatte Daten gespeichert werden, muß eine Zugriffskontrolle stattfinden. Das bedeutet, daß eine Zugriffsschutzsoftware in der Regel installiert werden muß, wenn mehrere Benutzer mit einem Client arbeiten oder sensible Daten gespeichert werden.

20.2.5.7
Datenverschlüsselung

Eine Datenverschlüsselung der Festplatte des Clients kann erforderlich werden, wenn lokal sensible Daten gespeichert werden oder wenn das Diebstahlrisiko für den Rechner vergleichsweise hoch ist.

20.2.5.8
Physisches Löschen

Als immer wiederkehrende Schwierigkeit muß das physische Löschen von Daten angesehen werden (s. hierzu 21. Tätigkeitsbericht, Ziff. 16.1).

20.2.5.9
Zentrale Systemverwaltung der Clients

Die Systemverwaltung der Clients sollte in einer Sicherheitsdomäne zentral erfolgen, damit u.a. Sicherheitslücken schneller erkannt werden.

Um dem Benutzer schnell helfen zu können, wird oft eine Fernsteuerungssoftware für PC eingesetzt. Diese Programme können dem Betreuer aus Datenschutzsicht problematische Möglichkeiten eröffnen. So sind sie z.B. unter Umständen geeignet, die Leistung von Mitarbeitern zu kontrollieren oder lokale Sicherheitsmaßnahmen zu umgehen. Im 22. Tätigkeitsbericht (Ziff. 21.4) habe ich beschrieben, was man bei der Nutzung dieser Programme beachten sollte.

20.2.6
Server

Server bieten in einer Client-Server-Architektur vielfältige Dienste an, wie z.B. Datenbankzugriffe, Versendung elektronischer Post oder Sicherheitsfunktion. Es gibt auch immer wieder die Auffassung, daß die Hosts als riesige Datenserver genutzt werden können. Zumindest hinsichtlich der räumlichen Sicherungsmaßnahmen ist ein Vergleich nicht abwegig, da nur das DV-Personal Zugang zum Server haben darf. An dieser Stelle möchte ich auf einige wichtige Punkte hinweisen.

20.2.6.1
Identifikation und Authentisierung beim Server (oder einem Authentication-Server)

Die Erläuterungen unter 20.2.5.1 zur Identifikation und Authentisierung bei Clients gelten auch für Server. Die Abläufe müssen dabei so sein, daß die Identität mit hoher Sicherheit feststeht. Dazu kann die Authentisierung durch den Server selbst oder durch einen Authentication-Server erfolgen.

Authentication Server (Ablauf am Beispiel DCE; Distributed Computing Environment)
Auf den Clients befindet sich ein Programm, das bei der Anmeldung unter Verwendung der User-ID eine Authentisierungsanforderung an den Authentication-Server sendet, d.h. eine Anforderung zu prüfen, ob die Person authentisch ist. In der Benutzerdatenbank wird die User-ID gesucht, zu der das zugehörige, verschlüsselte Paßwort als Code gespeichert ist. Der Authentication-Server sendet dann ein mit dem Code verschlüsseltes "Ticket", das bei jeder Anmeldung unterschiedlich ist, an den Client, welches nur mit dem Paßwort entschlüsselt werden kann. Mit diesem "Ticket", das u.a. die User-ID enthält, kann dann z.B. gegenüber anderen Servern beim Zugriff auf Daten oder Dienste die Identität des Anfragers bewiesen werden.

20.2.6.2
Zugriffskontrolle durch den Server

Die Prüfung, ob angeforderte Zugriffe auf Daten oder Services zulässig sind, hat durch den Server oder einen dazu vorgesehenen Sicherheitsserver zu erfolgen. Dazu muß die Identität des anfordernden Benutzers feststehen.

Bei meinen Prüfungen und Beratungen habe ich insbesondere Probleme auf Ebene der Anwendungsprogramme vorgefunden. Sie beruhten entweder auf Defiziten bei der Nutzung vorhandener Zugriffskontrollmechanismen oder darauf, daß die Anwendung/das System die Zugriffskontrolle nicht mit der nötigen Feinheit zuließ. Im ersten Fall ist eine Korrektur relativ schnell durchgeführt, während im zweiten Fall nur über langwierige Abstimmungsprozesse, wenn überhaupt, eine Änderung an den Programmen möglich ist.

20.2.6.3
Systemverwaltung

Ein Bereich, in dem die verfügbaren technischen Sicherheitsmechanismen verbessert werden müssen, ist die Systemverwaltung. Systemverwalter haben umfassende Zugriffsrechte, ohne daß ihre Tätigkeit durch Protokolle oder andere Mittel in ausreichendem Maße nachvollziehbar ist; theoretisch können sie bei fast allen Unregelmäßigkeiten im IT-Bereich die Verursacher sein, aber aus Protokollen läßt sich nur unzureichend ablesen, inwieweit sie tatsächlich involiert sind. Insbesondere zum Schutz des Personals vor ungerechtfertigten Vorwürfen muß die Technik in Richtung auf eine bessere Nachvollziehbarkeit fortentwickelt werden.

Folgende Rahmenbedingungen sollten bei der heute verfügbaren Technik erfüllt sein:
- Der Behördenleitung muß bekannt sein, welche Möglichkeiten ein Systemverwalter besitzt. In Kenntnis dieser Zusammenhänge ist über die Ausgestaltung von sensitiven Anwendungen zu entscheiden.
- Als Systemverwalter dürfen nur Personen ausgewählt werden, denen man vertraut.
- Die Arbeit mit einer Benutzerkennung, die Systemverwalterprivilegien hat, sollte auf das unumgängliche Maß beschränkt sein.

- Die Systemverwalterfunktionen müssen soweit möglich dem Vier-Augen-Prinzip unterliegen (z.B. geteiltes Paßwort zwischen Systemverwaltung und Fachabteilung).

- Protokolle, die geeignet sind, die Tätigkeit von Systemverwaltern transparent zu machen, sollten soweit möglich genutzt werden (zur Protokollierung allgemein s.Orientierungshilfe zur Protokollierung ).

20.2.6.4
Verschlüsselung sensibler Daten

Um einen Zugriff unbefugter Personen im Rahmen von Wartungen oder wegen der großen Sensibilität der Daten einen Zugriff für Systemverwalter weitgehend unmöglich zu machen, kann eine Verschlüsselung notwendig sein.

20.2.6.5
Systemverwaltung nur von speziellen Arbeitsplätzen aus

Die Systemverwaltung sollte nur von Arbeitsplätzen in zutrittskontrollierten Bereichen aus erfolgen können.

20.2.6.6
Konsole in zutrittskontrollierten Räumen

Wegen der oft an Rechnerkonsolen gebundenen, weitgehenden Zugriffsrechte sollten diese in entsprechend gesicherten Räumen stehen.


Zurück zur Übersicht

zurück nach oben
zurück nach oben springen
 
Artikel/Seite in der Druckansicht öffnen
Artikel/Seite in der Druckansicht öffnen
 
Artikel/Seite per eMail versenden
Artikel/Seite per eMail versenden
   
Stand: 16.06.2008