16.2

Prüfung der Datensicherheitsmaßnahmen in einem kommunalen Gebietsrechenzentrum

16.2.1

Ausgangssituation

In meinem 20. Tätigkeitsbericht (Ziff. 15.2) hatte ich von meiner Prüfung des Kommunalen Gebietsrechenzentrums (KGRZ) Frankfurt berichtet. Die festgestellten Mängel haben mich bewogen, das KGRZ Gießen in ähnlicher Art und Weise zu prüfen. Prüfungsschwerpunkte waren wiederum die Sicherheitsmaßnahmen auf Betriebssystemebene und im systemnahen Bereich; ferner die räumlichen Sicherheitsmaßnahmen und - in Stichproben - die Datenträgerkontrolle, die Anwendungsentwicklung und die Organisationskontrolle. Das Verfahren, an dem das Zusammenspiel der Komponenten geprüft wurde, war das Vertriebswesen.

Das KGRZ Gießen gehört ebenso wie das KGRZ Frankfurt dem Hessischen DV-Verbund an. Dessen Mitglieder arbeiten im Bereich der Entwicklung von DV-Verfahren zusammen. Daher besteht eine weitgehende Übereinstimmung der eingesetzten Software im systemnahen Bereich und ähnlich der technische Verhältnisse in beiden Rechenzentren. Die Zusammenarbeit bedingt Abhängigkeiten, aufgrund derer Änderungen im Umfeld oft nur nach einer (u.U. langwierigen) gegenseitigen Abstimmung erfolgen können. Ein Beispiel dafür ist das Verfahren Vorstellungsdatei (vgl. 20. Tätigkeitsbericht, Ziff. 15.2.2.3).

16.2.1.1

Begriffe

In der Datenverarbeitung gibt es eine Reihe von Begriffen und Abkürzungen, die nicht allgemein verständlich sind. Die folgenden Umschreibungen sollen weniger eine Definition sein als Verständnisschwierigkeiten beheben:

- Betriebssystem Das Betriebssystem eines Rechners steuert den Rechner und überwacht die angeschlossenen Geräte. Weitere Funktionen dienen der Erstellung von Anwendungsprogrammen oder unterstützen die ständig notwendigen Arbeiten mit dem Rechner. Beispiele für Betriebssysteme sind MS-DOS, UNIX oder - wie im Fall des geprüften KGRZ - MVS (zu MVS vgl. 20. Tätigkeitsbericht, Ziff. 15.2.1).

- Datenbankmanagementsystem Ein Datenbankmanagementsystem (DBMS) ist eine Gruppe von Programmen, die es erlaubt, Datenbanken einzurichten, zu verwalten und zu nutzen.

- TP-Monitor Ein TP-Monitor (Tele-Processing-Monitor) steuert Anwendungsprogramme, die von Benutzern im Dialog aufgerufen und genutzt werden.

- JOB Ein JOB ist ein Auftrag an das Betriebssystem, Arbeitsprogramme in einer vorgegebenen Reihenfolge bestimmte Dateien verarbeiten zu lassen. Wenn Anwendungsprogramme als JOB Daten verarbeiten, spricht man von Batch-Verarbeitung. In den Rechenzentren des Hessischen DV-Verbundes werden das Betriebssystem MVS, die TP-Monitore Com-Plete und CICS und das Datenbankmanagement ADABAS genutzt. Zur Steuerung des Zugriffs auf Verfahren und teilweise zur verfahrensinternen Kontrolle wird die Vorstellungsdatei benutzt, eine Anwendung, die vom KGRZ Kassel federführend betreut wird. Soweit es bei der Datensicherheit Probleme gibt, die aus dem Einsatz dieser Produkte resultieren, stehen die Rechenzentren des DV-Verbundes vor ähnlichen Aufgaben.

16.2.2

Festgestellte Mängel

Da es mir bei der Prüfung des KGRZ Gießen nicht zuletzt darum ging, den Stand der Datensicherheitsmaßnahmen mit dem des KGRZ Frankfurt zu vergleichen, werde ich an einigen Stellen auch auf den in den Stellungnahmen des KGRZ Frankfurt dargelegten Stand vom Herbst dieses Jahres eingehen.

Zwar war die Ausgangslage beider Rechenzentren nicht identisch, da dem KGRZ Gießen sowohl die Schwerpunkte als auch die Ergebnisse meiner Prüfung in Frankfurt bekannt waren. Dennoch dürfte die Gegenüberstellung bei allen Unterschieden in der Ausgangslage von Interesse sein.

Bei der Prüfung habe ich einige Mängel festgestellt, was aber in Anbetracht der Komplexität des Rechenzentrumbetriebs nicht weiter verwundert.

Im konzeptionellen Bereich bestanden relativ klare Vorstellungen über Vorgehensweisen und deren Umsetzung. Einige dieser Ansätze, so bei der Revision, waren aber noch nicht zu Ende gebracht. Die Nutzung der Schutzkomponenten war - isoliert betrachtet - meist korrekt. Durch die fehlende Integration der Komponenten ergaben sich aber unnötige Schwachstellen. Die folgenden kurzen Abrisse sollen typische Mängel beleuchten bzw. auf Besonderheiten hinweisen.

An dieser Stelle möchte ich darauf hinweisen, daß in vielen der geprüften Bereiche gute Lösungen gefunden wurden. Als Beispiele können die Anwendungsdokumentation und die Datenträgerverwaltung, die beide durch entsprechende Softwareprodukte unterstützt werden, oder die räumlichen Sicherheitsmaßnahmen genannt werden.

Ein großer Teil der Mängel wurde bereits während der Prüfung behoben. Innerhalb von zwei Monaten ging mir darüber hinaus eine Stellungnahme des KGRZ Gießen zu, in der die Beseitigung der meisten Mängel mitgeteilt wurde. Zu den offenen Punkten, die im wesentlichen konzeptioneller Art sind, wurden mir die ergriffenen Maßnahmen genannt. Vorbehaltlich einer Nachprüfung, ob die getroffenen Maßnahmen ausreichend sind, waren die Reaktionen schnell und präzise.

16.2.2.1

Datenschutzgesamtkonzept

Es lag kein Datenschutzgesamtkonzept vor. Nicht zuletzt deshalb gab es Unklarheiten über Prioritäten bei der Realisierung von Datensicherungsmaßnahmen, wie im Fall von Schnittstellen zwischen ACF2 und TP-Monitoren. Das Konzept wurde allerdings, soweit ACF2 selbst betroffen ist, teilweise durch das ACF2-Handbuch abgedeckt. Dieses Handbuch wurde in den Jahren 1988 bis 1990 von einer Arbeitsgruppe begonnen, die ihre Tätigkeit nach einer Unterbrechung mittlerweile wieder aufgenommen hat. Das KGRZ Frankfurt hat zwischenzeitlich ebenfalls eine Arbeitsgruppe gebildet, die ein Gesamtkonzept erstellen soll; sie ist zur Zeit mit den Vorgaben für die Bereiche Benutzer- und Zugriffskontrolle befaßt.

16.2.2.2

Revisionskonzept

Ich konnte feststellen, daß die Revision von und mit ACF2 in gewissem Umfang stattfand. Die ACF2-Reports wurden mindestens einmal am Tag erstellt und ausgedruckt. Der ACF2-Administrator kontrollierte dann die Reports. Die Vorgehensweise bei der Kontrolle dieser Auswertung war, soweit die ACF2-Administration betroffen ist, in Ordnung. Es fehlte aber die Schriftform, und der durch die Revision abgedeckte Bereich muß noch erweitert werden. Hier ist ein Umfang anzustreben, wie ich ihn in meinem 20. Tätigkeitsbericht, Ziff. 15.2.2.2 beschrieben habe.

Es ergaben sich einige Punkte, die zu einer vermeidbaren Schwächung des Instruments der Revision führen:

- Der ACF2-Administrator prüft die Reports als einzige Person. Zumindest in Stichproben und aufgrund besonderer Anlässe ist eine Kontrolle durch eine weitere Person erforderlich.

- Der ACF2-Administrator kontrolliert seine eigene Tätigkeit.

- ACF2 ist Teil eines Sicherheitssystems, so daß auch die anderen Teile (MVS, TP-Monitore, Datenbanken, Anwendungen etc.) in die Revision einbezogen werden müssen. Punkte, die dabei kontrolliert werden müssen, sind die korrekte Implementierung der diversen Schnittstellen und die Prüfung von Einträgen in den diversen Schutzkomponenten auf ihre Aktualität hin. Die Prüfungsergebnisse unterstreichen, daß eine externe Prüfung/Revision nicht ausreicht. Abgesehen davon, daß diese nur selten stattfindet, fehlt der Kontakt im täglichen Betrieb und bei den täglichen Schwierigkeiten. Sie ist nur eine notwendige Ergänzung zur internen Revision. Die Überlegungen beim KGRZ Gießen gehen dahin, die Funktion "Innenrevision" zu schaffen, die mit entsprechenden Aufgaben betraut wird.

Die Aufarbeitung dieses Punktes will das KGRZ Frankfurt erst nach Erstellung des Gesamtkonzepts beginnen oder, wenn es sich ergeben sollte, als Teil des Gesamtkonzepts darstellen.

16.2.2.3

Anmeldung am System; Integration der Schutzkomponenten

Bei der Anmeldung am System wird die Benutzerkontrolle durchgeführt, die aus der Identifikation (Eingabe der Kennung) und Authentifikation (zur Zeit in der Regel Eingabe eines Paßwortes) der Benutzer besteht und von zentraler Bedeutung für die systemseitigen Sicherheitsmaßnahmen ist.

Eine datenschutzgerechte Anmeldung mit Kennung (User-ID) und Paßwort bedingt in der Regel Anforderungen an die Paßwortverwaltung, wie ich sie in meinem 19. Tätigkeitsbericht (Ziff. 15.5) genannt habe. Sicherzustellen ist, daß sich nur die Person, der eine Kennung zugewiesen ist, damit anmelden kann, da nur ihr das zugehörige Paßwort bekannt ist.

Beim KGRZ Gießen war die "Philosophie" für die Anmeldung am System, daß ein Benutzer mit möglichst wenig Aufwand die ihm zugewiesenen Aufgaben ausführen kann. Hierzu muß sich der Benutzer an einem sog. Session-Manager mit Kennung und Paßwort anmelden. Der Session-Manager zeigt in Form eines Menues die TP-Monitore oder TSO (Time-Sharing-Option, ein Programm mit dem betriebssystemnah der Benutzer den Rechner nutzen kann) an, mit denen der Benutzer (richtiger: die Kennung) arbeiten darf. Wird ein TP-Monitor bzw. TSO angewählt, so wird die Verbindung hergestellt und ein automatischer Anmeldevorgang (LOGON) durchgeführt. Am TP-Monitor ist die Eingabe einer Benutzerkennung und eines Paßwortes nicht mehr erforderlich, während Anmeldevorgänge auf Anwendungsebene mit spezifischen Abfragen von Berechtigungscodes weiterhin vorgenommen werden. Dadurch, daß ein Benutzer nicht an jedem TP-Monitor eine Anmeldung versuchen kann, wird eine höhere Sicherheit erreicht. Voraussetzung ist aber, daß die Schnittstellen zwischen den verschiedenen Schutzkomponenten korrekt implementiert sind und daß die erste Anmeldung am Session-Manager ein besonders hohes Maß an Sicherheit erreicht.

In der vorgefundenen Implementierung ergaben sich einige Mängel hinsichtlich der Speicherung bzw. der Pflege von Paßwörtern. Der Produktions-Session-Manager besaß keine Schnittstelle zu ACF2, so daß die nicht so guten Mechanismen des Session-Managers für die Identifikation/Authentifikation genutzt wurden. Für den Test-Session-Manager wurde zwar die Identifikation/Authentifikation durch ACF2 vorgenommen, jedoch war für das Paßwort die absolut unzureichende Mindestlänge von zwei Stellen vorgegeben. Ferner war für die meisten TP-Monitore ebenfalls keine ACF2-Schnittstelle aktiv, so daß in den Session-Managern definiert wurde, mit welchem Paßwort eine bestimmte Benutzerkennung einen automatischen LOGON am jeweiligen TP-Monitor durchführt. Kennung und Paßwort müssen darüber hinaus auch in den entsprechenden TP-Monitoren definiert sein. Im CICS erfolgt dies beispielsweise in Tabellen im Klartext.

Das hat zur Folge, daß den Mitarbeitern des KGRZ, die die Einträge vornehmen, in diesen Fällen die Kennung und das Paßwort bekannt sind und sie sich mit jeder beliebigen Kennung anmelden könnten. Da unter ACF2 eine ganze Abteilung Schreib- und Leserechte für die CICS-Tabellen hatte, war diese Möglichkeit zumindest für CICS einem noch größeren Personenkreis gegeben. Noch während der Prüfung wurden die Einträge vorgenommen, um die Zugriffsmöglichkeiten auf den derzeitig benötigten Personenkreis zu beschränken.

Ein weiterer Mangel ergab sich aus dem Problem, für mehrere hundert Personen und jeweils mehrere Monitore unterschiedliche Paßwörter zu finden und in den Monitoren zu pflegen. Die Paßwörter wurden oft nach festen Regeln gebildet und waren dementsprechend leicht abzuleiten.

Diese Schwachstellen waren bekannt und ihre Beseitigung war vorgesehen. Durch dringende Neuanforderungen hatte man sie dann zurückgestellt. Ich habe gefordert, schnellstmöglich die Schnittstellen zu aktivieren und damit die Schutzsysteme zu integrieren.

16.2.2.4

Vorstellungsdatei

Die Anwendung "Vertriebswesen" benutzt zur verfahrensinternen Benutzer- und Zugriffskontrolle die Vorstellungsdatei. Im Unterschied zu den Verhältnissen, wie ich sie noch in meinem 16. Tätigkeitsbericht (Ziff. 4.2.2) beschrieben habe, gehören mittlerweile Auswertungen zum Funktionsumfang der Vorstellungsdatei. Die anderen Schwächen des Verfahrens wie z.B. keine Trennung von Identifikation/Authentifikation, keine Möglichkeit zur Änderung des Codes für den Benutzer (einige Codes waren mehr als zwei Jahre alt) oder keine Schnittstellen zu ACF2 lagen aber weiterhin vor.

Beim Verfahren Vorstellungsdatei können weder das KGRZ Gießen noch das KGRZ Frankfurt sinnvollerweise Änderungen vornehmen, da sie nicht federführend sind. Nicht zuletzt wegen der Ergebnisse der Prüfung des KGRZ Frankfurt und des in meinem 19. Tätigkeitsbericht (Ziff. 15.5) beschriebenen Vorfalls, sind für das Jahr 1993 durch das federführende KGRZ Kassel Anpaßungen geplant, die die Schwächen der Vorstellungsdatei beseitigen sollen.

16.2.2.5

Einsatz von ACF2

Für die Zugriffskontrolle auf Systemebene ist im DV-Verbund ACF2 vorgesehen. Wegen der Bedeutung für das Gesamtsystem habe ich ACF2 näher untersucht.

Durch den Einsatz von ACF2 mußten ca. 300 Benutzer kontrolliert werden, die mittels TSO arbeiten konnten. Um die Zugriffe auf Dateien zu beschränken, wurden ca. 3.000 Regeln geschrieben.

Die Zahl der Benutzer, die nach Implementierung aller Schnittstellen der Kontrolle von ACF2 unterliegen müssen, beträgt fast 2.000. Wieviele ACF2-Regeln vorhanden sein werden, um alle Resourcen zu schützen, läßt sich derzeit noch nicht abschätzen. Diese Zahlen lassen erahnen, daß bei einer Prüfung mit ziemlich hoher Wahrscheinlichkeit Stellen gefunden werden, an denen Einträge hätten anders sein sollen oder müssen.

Ich konnte feststellen, daß ACF2 in der vorgefundenen Implementierung den Zugriff auf alle Dateien prinzipiell kontrollierte. Auch erfolgte eine Kontrolle der Anmeldung am TSO und an dem Test-Session-Manager durch ACF2. Insofern waren die Voraussetzungen anders als bei der Prüfung des KGRZ Frankfurt. Dort war ACF2 zwar als Software vorhanden, jedoch waren die Schutzmechanismen beim Dateizugriff in weiten Bereichen nicht aktiviert. Infolgedessen habe ich bei der Prüfung des KGRZ Gießen verstärkt auf die Ausprägung von Zugriffsrechten geachtet, was sich in der Konstellation beim KGRZ Frankfurt erübrigt hatte.

Die wesentlichen Schwachstellen lagen in folgenden Bereichen:

- Zu den meisten TP-Monitoren und zum DBMS fehlten Schnittstellen.

- Batch-Jobs liefen unter "Gruppen-ID's".

- In einigen Fällen waren die eingeräumten Zugriffsrechte zu

weitgehend.

16.2.2.5.1

Batch-Jobs

Wenn Mitarbeiter der Systemprogrammierung oder der Arbeitsvorbereitung durch das Operating Jobs starten lassen wollten, stellten sie ihren Job in eine Datei. Das Operating löste die Abläufe durch Aufruf eines Programms aus, das die Jobs in der gespeicherten Reihenfolge startete. Dabei wurde für alle Jobs der Arbeitsvorbereitung und der Systemprogrammierung je eine feste ACF2-Kennung eingesteuert. Jeder Job hat in dieser Konstellation also die Zugriffsmöglichkeiten der jeweiligen Kennung, d.h. die Summe der Zugriffsrechte der jeweiligen Mitarbeitergruppe. Diese Abläufe hatten sich im Laufe der Zeit aus Lösungen entwickelt, die zur einfacheren Steuerung von Jobs dienten.

Neben der Problematik, daß mit einem einzelnen Job evtl. zu weitgehende Zugriffsmöglichkeiten verbunden waren, waren auch die ACF2-Protokolle nicht mehr aussagekräftig. Es konnte den Protokollen nicht entnommen werden, welcher Benutzer im Rahmen eines Jobs welche ACF2-Protokolleinträge verursacht hatte.

In seiner Stellungnahme teilte mir das KGRZ Gießen mit, daß die Abläufe sicherer gestaltet wurden, indem eine weitergehende Differenzierung bei den Kennungen stattfindet. Inwieweit die gefundene Lösung den datenschutzrechtlichen Anforderungen gerecht wird, muß noch geprüft werden.

16.2.2.5.2

Zugriffsregeln

Die Implementierung von ACF2 verlangte, bis auf eine Ausnahme (Zugriff auf Banddateien), daß zu jeder Datei eine Zugriffsregel existieren muß. Bei der stichprobenhaften Kontrolle wurden nur Regeln gefunden, die den Modus ABORT hatten, d.h. bei einem Regelverstoß wurde der Zugriff abgewiesen und der unzulässige Versuch protokolliert.

Bei der Vielzahl der Regeln gibt es verständlicherweise Fälle, in denen zu weit gehende Zugriffsmöglichkeiten eingeräumt wurden, sei es durch Unachtsamkeit oder weil eine andere Auffassung über den zulässigen Zugriff vorlag. Es ergaben sich daher Regeln, die unbedingt anzupaßen waren. Beispielhaft sollen hier genannt werden:

- In zu vielen Fällen wurde für alle Benutzer ein Leserecht auf Dateien eingeräumt (dabei muß beachtet werden, daß die "normalen" Benutzer nur innerhalb von Dialoganwendungen auf Daten zugreifen können und dadurch unzulässige Zugriffe auf Dateien ausgeschlossen wurden. Die Schwachstelle trifft im wesentlichen für KGRZ-Mitarbeiter zu. Es gibt freilich eine wichtige Ausnahme davon; vgl. 16.2.2.6). Der Zugriff auf Systemdateien war in weiten Bereichen nur lesend möglich. Lediglich die Systemprogrammierung besaß Schreibrechte. Obwohl damit ein Schutz gegen unbefugte Änderungen am Betriebssystem und an der systemnahen Software erreicht war, ist doch eine Verschärfung in einigen Bereichen erforderlich. Hier sind die SYS1.PARMLIB, APF-autorisierte Dateien u.ä. zu nennen.

- Die Dateien des Betriebssystems, in denen die Daten der

Produktionsdatenbanken gespeichert waren, waren nicht lesegeschützt und für Mitarbeiter des KGRZ auch änderbar. Da gleichzeitig die ADABAS-Programmbibliotheken nicht lesegeschützt waren, konnten alle Benutzer mit Zusatzwissen, die Zugang zur Betriebssystemebene besaßen, Datenbanken lesen und mit - allerdings starken - Einschränkungen ändern. Hier wurden umgehend Maßnahmen ergriffen. Für die Behandlung von Magnetbändern, die im Datenträgeraustausch eingehen und keinen oder einen dem ACF2 nicht bekannten Dateinamen haben, ist die Regel "NORULES" definiert. Diese besagt, daß jeder Mitarbeiter der Systemprogrammierung bzw. Arbeitsvorbereitung die Daten lesen bzw. ändern kann. Dies war erforderlich, da eingehende Magnetbänder zumindest gelesen werden müssen.

In diesem Fall muß ein Verstoß gegen die Grundphilosophie von ACF2, nach der ein Zugriff abgewiesen wird, wenn ACF2 keine Erlaubnis gibt, hingenommen werden, da nicht für alle fremden Banddateien Regeln existieren können. Um dies zu erreichen, kennt ACF2 die Möglichkeit, die Ergebnisse von Regelprüfungen zu modifizieren. Dazu war ein EXIT (ein kleines Programm, das es erlaubt, zu bestimmten Zeitpunkten in die Abläufe von systemnahen Programmen einzugreifen) bestimmt, der nach der Regelprüfung beim Dateizugriff ausgeführt wurde. Es handelte sich um den sog. VIOEXIT. Im vorliegenden Fall wurde in dem Programm festgestellt, ob es sich um eine Banddatei handelt, zu der keine Regel existiert. In diesem Fall wurde dem o.g. Personenkreis der Zugriff eröffnet. Der EXIT hätte aber genausogut einer bestimmten Kennung jeden Dateizugriff erlauben können. Um sicherzustellen, daß ACF2 tatsächlich Zugriffe so kontrolliert, wie es die Regeln vorgeben, muß im Rahmen der Revision dieser oder andere EXITs dahingehend kontrolliert werden, ob sie die geforderten Funktionen tatsächlich ausführen.

16.2.2.5.3

GSO-Record, generelle Parameter

Die Parameter entsprachen im wesentlichen den Erfordernissen. Es waren zwar einige veraltete Einträge vorhanden, die jedoch sofort gelöscht wurden.

Einen Mangel stellte die vorgeschriebene Mindestlänge der Paßwörter dar, die mit einem Wert von zwei erheblich zu gering war (vgl. 19. Tätigkeitsbericht, Ziff. 15.5.4).

16.2.2.5.4

Benutzerdefinitionen

Die Definitionen waren bis auf ganz wenige Ausnahmen korrekt. Auch wurden Benutzerprivilegien im Regelfall nicht zu weit gestreut.

Probleme ergaben sich durch die Häufung von Privilegien bei bestimmten Personen. So waren die Systemprogrammierer MVS gleichzeitig Vertreter des ACF2-Administrators. Diese Zuordnung wurde mittlerweile aufgehoben.

16.2.2.5.5

Reaktionen

Die ACF2-spezifischen Mängel wurden, da meist nur eine Korrektur vorhandener Regeln erforderlich war, oft schon während der Prüfung beseitigt. Ein wesentlicher Punkt, der noch geregelt werden muß, betrifft die Aktualität von Einträgen. Hier und bei der Frage, welche Zugriffe eingeräumt werden dürfen oder müssen, gilt es, tätig zu werden.

Das KGRZ Frankfurt hat in einer Stellungnahme zum Stand bei ACF2 dargelegt, daß die Regelschreibung fortschreitet. So werden die Regeln derzeit vom LOG-Modus (ein nach der Regel unerlaubter Zugriff wird akzeptiert, jedoch erfolgt ein Protokolleintrag) in den ABORT-Modus (ein unerlaubter Zugriff wird abgewiesen und protokolliert) umgestellt. Die Änderung der Grundeinstellung, die zum Zeitpunkt der Prüfung einen Zugriff erlaubte, wenn keine Regel vorlag, wurde mir noch nicht mitgeteilt.

Ein Stand wie beim KGRZ Gießen ist noch nicht erreicht.

16.2.2.6

Zugriffsmöglichkeiten für Mitarbeiter der Verwaltung

Die Online-Anwendungen des DV-Verbundes sind in der Regel mandantenfähig, d.h. es können die Daten mehrerer Anwender verarbeitet werden, und die Abschottung der Datenbestände ist möglich. Je nach Anwendung ist auch noch eine weitere Differenzierung von Zugriffen vorgesehen. Beim Vertriebswesen habe ich keine programmseitigen Mängel der Datensicherheitsmaßnahmen festgestellt.

Das Konzept für die Zugriffskontrolle im Rahmen von Online-Anwendungen bot bei korrekter Umsetzung die Gewähr, daß kein Zugriff auf die Daten anderer Anwender möglich war. Dabei war es wesentlich, daß die Mitarbeiter keinen Zugang zur Systemebene hatten.

Eine Schwachstelle hatte sich aber in Gestalt von "DV-Altlasten" eingeschlichen. Es waren sechs Benutzerkennungen für KGRZ-externe Benutzer vorhanden, die mit TSO arbeiten konnten. Wegen der unter ACF2 vorhandenen Schwächen bei bestimmten Zugriffsregeln konnten auch mit diesen Kennungen die unter 16.2.2.5.2 beschriebenen Zugriffe vorgenommen werden. Bei der Diskussion verschiedener Zugriffsregeln stellte sich heraus, daß die Tatsache bei der Regelschreibung nicht berücksichtigt worden war. Diese Abweichung von dem Konzept, daß externe Benutzer keinen Zugriff auf die Systemebene haben, war nicht ausreichend gegenwärtig.

Das KGRZ Frankfurt hat aufgrund meiner Prüfung die Schnittstelle zwischen dem Com-Plete und ACF2 aktiviert. Dadurch unterliegen die Zugriffe der Kontrolle von ACF2. Wegen der noch vorhandenen Schwächen bei ACF2 ist der Mangel aber noch nicht behoben. Die Situation stellt sich eher ungünstiger dar als beim KGRZ Gießen.

16.2.2.7

Zugriffsmöglichkeiten von KGRZ-Mitarbeitern

Soweit KGRZ-Mitarbeiter unter TSO arbeiten konnten, und das war die Regel, sind die unter 16.2.2.5.2 gemachten Feststellungen relevant.

Die beiden folgenden Fälle sollen deshalb Zugriffsmöglichkeiten illustrieren, die nicht mit ACF2 in Zusammenhang stehen. Sie sind auch deshalb interessant, weil sie typische Abläufe wiedergeben, wie es zu einer Ausweitung von Zugriffsrechten kommen kann.

a) Anwendungsentwicklung Vertriebwesen Einige Entwickler des Verfahrens Vertriebswesen hatten im Rahmen der Anwendung jederzeit umfassenden Zugriff auf Produktionsdaten. Begründet wurde dies mit dem Erfordernis, im Einzelfall zur Fehlerbehebung oder Unterstützung kurzfristig auf die Daten zugreifen zu müssen. Aus Sicht der Kundenfreundlichkeit mag der Ansatz seine Berechtigung haben, ansonsten ist er in der vorgefundenen Form nicht zu akzeptieren. Es wurde daher nach einer Lösung gesucht, die der Problematik gerecht wird. Der derzeit verfolgte Ansatz sieht folgende wesentliche Punkte vor:

- Die Anwender werden über den möglichen Service und evtl. Konsequenzen unterrichtet.

- Der Anwender kann den Service annehmen, wobei die Möglichkeit besteht, hinsichtlich der Datenbestände und der Zugriffsrechte von Mitarbeitern Einschränkungen vorzusehen.

- Auch wenn der Service gewählt wurde, muß er im Einzelfall angefordert werden. Die Anforderung wird protokolliert.

- Die Zugriffe werden protokolliert.

b) Zugriffsmöglichkeiten auf Job-Output Es gibt immer wieder Fälle, in denen Mitarbeiter im Laufe eines Projekts für eine kurze Zeit weitgehende Zugriffsmöglichkeiten auf die Ergebnisse von Job-Läufen haben müssen. Auch beim KGRZ Gießen trat ein solcher Fall auf. Allerdings wurden nach Beendigung der Projektphase die Rechte nicht zurückgenommen, so daß zwei Mitarbeiter der Anwendungsentwicklung auf die Ergebnisse aller Job-Outputs zugreifen konnten. Ferner gab es für einen großen Teil der Mitarbeiter der Arbeitsvorbereitung und der Systemprogrammierung keine Einschränkung der Zugriffsmöglichkeiten auf alle Jobs. Diese zu weit gehenden Zugriffsrechte wurden umgehend zurückgenommen.

16.2.2.8

Sonstige Anmerkungen zu einzelnen Produkten

16.2.2.8.1

Com-Plete

In meinem 20. Tätigkeitsbericht (Ziff. 15.2.2.5) hatte ich Mängel aufgezeigt, die sich aus den fehlenden Schnittstellen zwischen Com-Plete und AFC2 ergeben, wenn Benutzer unter Com-Plete editieren, Jobs starten und deren Ergebnisse ansehen können. Diese Probleme hatte man in Gießen dadurch beseitigt, daß es nicht mehr möglich war, unter Com-Plete Jobs zu starten, und Benutzern die Editiermöglichkeit nicht eingeräumt wurde.

Bei der Umsetzung war der Tatsache keine Bedeutung zugemessen worden, daß der Com-Plete-Administrator weiterhin editieren konnte. Für ihn galt also, daß er mit den Rechten von Com-Plete arbeiten konnte, ohne daß es mit ACF2 möglich war, zwischen seinen Tätigkeiten und denen anderer Benutzer zu unterscheiden. Da die Editiermöglichkeit für die Tätigkeit des Administrators nicht erforderlich war, wurden die entsprechenden Com-Plete-Programme entfernt. Die Schwachstelle war damit beseitigt. In diesem Fall wurde damit ein Standardprodukt um die nicht erforderliche Funktion reduziert.

16.2.2.8.2

Performance-Monitore

Im täglichen Betrieb von Rechnern gibt es immer wieder Probleme mit schlechten Antwortzeiten, Fehlern, die nicht zu lokalisieren sind, oder andere Ereignisse, die tiefgehende Untersuchungen verlangen. Zur Unterstützung in diesen Fällen wird Spezialsoftware angeboten, die auf einer tiefen Ebene in die Software des Rechners eingreift; ein Beispiel sind sog. Performance-Monitore, die Engpässe bei Rechnerressourcen feststellen.

Derartige Monitore bieten zum Teil sensible Funktionen wie Trace (Verfolgung eines Ablaufs mit Anzeige von übertragenen Daten) oder Anzeigen bzw. Ändern von Hauptspeicherinhalten. Im Fehlerfall ist es ohne derartige Hilfsmittel oft nicht mehr möglich, schnell und sicher zu helfen. Diese Abhängigkeit darf aber nicht dazu führen, daß der Einsatz derartiger Produkte unkontrolliert erfolgt.

Bei der Prüfung stellte sich heraus, daß der Personenkreis, der einen Trace aufsetzen konnte oder die Möglichkeit hatte, sich Speicherinhalte anzusehen bzw. sie abzuändern, zu weit gesteckt war. Der Einsatz derartiger Spezialsoftware kann nur unter bestimmten Rahmenbedingungen erfolgen:

- Die Funktionen müssen hinsichtlich ihrer sicherheitsspezifischen Relevanz bewertet werden.

- Es muß festgelegt sein, wer wann welche relevanten Funktionen ausführen darf. Nur berechtigte Personen dürfen die Funktionen ausführen können.

- Es muß nachvollziehbar sein, wer wann mit den Funktionen gearbeitet hat. Zwischenzeitlich wurde mit den in den Produkten vorhandenen Schutzmechanismen eine stärkere Differenzierung vorgenommen.

16.2.3

Fazit

Ein Großteil der Mängel, die ich bei der Prüfung des KGRZ Frankfurt vorgefunden hatte, waren auch beim KGRZ Gießen anzutreffen. Die Ausprägung war aber generell nicht so gravierend. Hier sind zu nennen:

- Ein Datenschutzkonzept war nur zum Teil vorhanden.

- Es fehlte ein schriftliches Revisionskonzept.

- Die Integration der Schutzkomponenten war noch nicht ausreichend.

- Zugriffsregeln von ACF2 waren nicht in allen Fällen korrekt.

- Einträge in Schutzkomponenten waren nicht immer aktuell.

Insbesondere waren nicht alle ungültigen Einträge gelöscht. Durch die geleistete Vorarbeit war es möglich, die meisten Mängel schnell zu beheben. Es bleibt aber noch einiges zu tun, um den Stand der Umsetzung voranzutreiben. Auch wenn dies erreicht ist, sind die Maßnahmen ständig zu kontrollieren und fortzuschreiben.

Ich werde die Fortschritte bei der Umsetzung von Datensicherungsmaßnahmen verfolgen und die Erfahrungen bei der Prüfung anderer Rechenzentren einfließen lassen.

Inhalt, weiter,