14. Kreditwesen
14.1
Prüfung des Rechenzentrums der Hessischen Sparkassenorganisation
Die Datensicherungsmaßnahmen des Rechenzentrums der Hessischen Sparkassenorganisation entsprechen einem hohen Niveau. Einzelne Schwachstellen wurden so weit möglich sehr schnell behoben.
In meinem 20. und 21. Tätigkeitsbericht, Ziff. 15.2 bzw. 16.2 habe ich vom Ergebnis der Prüfungen von Kommunalen Gebietsrechenzentren berichtet. Um die Feststellungen in einen größeren Zusammenhang stellen zu können, habe ich im letzten Jahr das Rechenzentrum der Hessischen Sparkassenorganisation (RHSO) geprüft. Das RHSO war zu diesem Zeitpunkt das einzige Rechenzentrum aus dem Bereich der Kreditwirtschaft, das meiner Kontrolle unterlag. Andere Stellen, die Prüfungen bei Kreditinstituten vornehmen, berichten von den Ergebnissen nicht in der Öffentlichkeit. Die folgenden Darstellungen und fehlende Berichte über andere Institutionen lassen daher keinen Schluß zu, ob das RHSO in Relation zu anderen Rechenzentren der Kreditwirtschaft ein hohes oder niedriges Sicherheitsniveau erreicht.
Ein Vergleich könnte mit den früher geprüften kommunalen Gebietsrechenzentren versucht werden. Dabei muß aber beachtet werden, daß die Ausgangslage sehr unterschiedlich ist. Sowohl hinsichtlich der verfügbaren Ressourcen als auch der Gefährdungen und Risiken ist die Situation nicht identisch. Trotzdem sind einige Problemlösungen oder Schwachstellen des RHSO von genereller Bedeutung und sollen daher exemplarisch skizziert werden.
14.1.1
Ergebnisse
Bei der Prüfung zeigte sich immer wieder, daß die Geschäftsführung des RHSO der Sicherheit der Datenverarbeitung eine sehr hohe Bedeutung beimißt. Es mag als Binsenweisheit angesehen werden, daß Kunden Vertrauen zu ihrer Sparkasse haben müssen und fehlende Sicherheit, zumindest wenn sie publik wird, das Vertrauen untergräbt. Die Konsequenz hieraus wurde jedenfalls gezogen. Die Tatsache, daß an einigen wenigen Stellen Schwächen festgestellt wurden, kann angesichts der Komplexität der Aufgaben des Rechenzentrums nicht verwundern; sie steht jedenfalls nicht im Widerspruch zu dem positiven Gesamteindruck. Auch ist es nicht möglich, sämtliche Bereiche aufzuführen, in denen die Datensicherungsmaßnahmen einen hohen Stand hatten. Ich möchte daher ausschließlich auf Punkte eingehen, die mir besonders wichtig erscheinen.
14.1.1.1
Positive Feststellungen
14.1.1.1.1
Maßnahmen zur Gewährleistung der
Verfügbarkeit der Daten
Es wurden umfassende Untersuchungen vorgenommen, welche Risiken bestehen. Angesichts der Abhängigkeit der Sparkassen von einer funktionierenden Datenverarbeitung wurden solche Lösungen gewählt, die im Problemfall die schnellstmögliche Wiederaufnahme der Tätigkeit versprechen. Dazu gehört beispielsweise ein "heißes" Backup-Rechenzentrum, d.h. im Fehlerfall steht ein Ausweichrechenzentrum betriebsbereit zur Verfügung. Mehrfach im Jahr wird in diesem Rechenzentrum die Wiederaufnahme des Produktionsbetriebs geprobt.
14.1.1.1.2
Trennung von Test und Produktion
Der Anwendungsentwicklung stand räumlich getrennt vom Produktionsrechner ein eigener Rechner zur Verfügung, auf dem sich nur Testdaten befanden. Ein Zugriff auf Produktionsdaten war nicht möglich. Sollte ein Programm in die Produktion übernommen werden, so wurde es in ein Abnahmeumfeld kopiert, auf das nur die Revision und der für die Qualitätssicherung zuständige Bereich zugreifen konnten. Nachdem dort die Programme getestet worden waren, erfolgte die Übergabe in die Produktion. Dies konnte nur die Revision nach genau festgelegten Regeln vornehmen.
14.1.1.1.3
Automation der Abläufe
Die Abläufe im Rechenzentrum waren weitestgehend automatisiert. Infolgedessen waren auch die Zugriffsmöglichkeiten des Personals auf Kundendaten minimiert.
14.1.1.1.4
Aktivierung der RACF-Schnittstellen von
Subsystemen
Damit die Sicherheitsmechanismen der verschiedenen Subsysteme an einer Stelle verwaltet und kontrolliert werden können, wurde RACF soweit möglich als "Single Point of Control" eingesetzt.
Ein Großteil der Sicherheitsdefizite, die ich bei Prüfungen anderer Institutionen feststellen konnte, lag in der fehlenden Integration der diversen Schutzsysteme. Der im RHSO vorgefundene Ansatz führte daher zu einem höheren Schutz.
14.1.1.1.5
Sicherheitskonzept
Es wurde ein einheitliches Sicherheitskonzept mit Unterstützung einer Unternehmensberatung erarbeitet. Aktuelle Feststellungen wurden sofort in die tägliche Arbeit integriert. Der erhebliche Aufwand - so gingen die Beteiligten jedes Jahr mehrfach für eine Woche in Klausur - erscheint angesichts der Ergebnisse und der damit verbundenen Vorteile für den Betrieb angemessen.
14.1.1.1.6
Revision der Abläufe
Sämtliche Abläufe im Betrieb des Rechenzentrums wurden von einer gut funktionierenden Revision kontrolliert. Im Vergleich mit den anderen geprüften Rechenzentren stand in diesem Bereich mehr Personal zur Verfügung.
14.1.1.2
Schwachstellen
14.1.1.2.1
Datenträgeraustausch
Es war theoretisch ein Datenträgeraustausch mit nicht gelöschten Bändern möglich, die vom Bandverwaltungssystem freigegeben worden waren.
In der Praxis kam es zu diesem Austausch nicht, da beim RHSO ein Bestand von Magnetbandkassetten existierte, die wegen eines Fabrikationsfehlers nicht die erforderliche Lebensdauer hatten. Sie wurden daher nur im Rahmen des Datenträgeraustauschs verwendet, und ihr einmaliger Einsatz war unproblematisch. Theoretisch hätten jedoch auf den nicht gelöschten, nur teilweise überschriebenen Kassetten Kundendaten dem Partner zugehen können. Dieses Problem scheint nicht für die RHSO spezifisch zu sein; ihm ist in vielen Rechenzentren noch nicht die nötige Aufmerksamkeit gewidmet worden.
Mittlerweile wurden die Abläufe so geändert, daß diese Möglichkeit nicht mehr besteht.
14.1.1.2.2
Implementierung von RACF
14.1.1.2.2.1
Paßwortverwaltung
Die Parameter der Paßwortverwaltung entsprachen zum Teil nicht dem Standard, den ich im 19. Tätigkeitsbericht als Stand der Technik bei der Benutzerkontrolle dargelegt hatte. Die Defizite waren jedoch bekannt und die Vorbereitungen zur Beseitigung bereits getroffen. Noch im Verlauf der Prüfung wurden die Änderungen vorgenommen.
14.1.1.2.2.2
Kontrolle von RACF
Nach meiner Einschätzung waren noch zusätzliche Maßnahmen angebracht, um die Kontrolle von RACF zu verbessern.
Bei der Vergabe von Zugriffsrechten mußte ein "Ressourcenverantwortlicher" jeweils abzeichnen, daß ein Benutzer Zugriffsrechte auf "seine" Ressource erhält. Er war verantwortlich, daß nur berechtigte Personen im zulässigen Umfang mit der Ressource arbeiten konnten; die RACF-Administratoren nahmen lediglich die Eintragungen vor. Es war nicht geregelt, wie die Kontrolle der eingetragenen Zugriffsrechte vorzunehmen war. Folglich hing es von den handelnden Personen ab, ob diesem Aspekt genügend Aufmerksamkeit gewidmet wurde. m Laufe der Zeit konnte vielen Personen Zugriff auf eine Ressource erlaubt werden. Eine Aufstellung der vergebenen Zugriffsrechte erhielt die verantwortliche Person auf Wunsch. Ich habe gefordert, den Verantwortlichen in einem festen Turnus eine Aufstellung der vergebenen Zugriffsrechte zuzuleiten. Es ist geplant, dies so zu handhaben.
RACF bietet ferner Standardberichte, die es dem RACF-Administrator oder dem Revisor ermöglichen sollen, den Überblick zu behalten. Nach meiner Einschätzung sind jedoch die erzeugten Berichte nicht ohne Hilfsmittel angemessen auszuwerten, sobald sie mehrere hundert Seiten umfassen. Angesichts der nur eingeschränkten Aussagekraft von RACF-Reports halte ich es weiterhin für angebracht, den Administratoren Programme zu weitergehenden Untersuchungen der SMF -Sätze und der RACF-Dateien an die Hand zu geben. Hierzu bedarf es entsprechender Software.
14.1.1.2.2.3
Unberechtigter Zugriff auf Banddateien
Unberechtigten Personen wäre der Zugriff auf Banddateien unter bestimmten Randbedingungen, die hier nicht dargestellt werden sollen, möglich gewesen, obwohl RACF-Zugriffsrechte dem entgegenstanden.
Die Ursache ist in der Entstehungsgeschichte von MVS zu sehen. Es werden als Relikt aus den Vorläuferbetriebssystemen nur die letzten 17 Stellen eines Dateinamens auf dem Magnetband gespeichert. So wird beispielsweise von dem Dateinamen "GEHEIM.UMSATZ.DEZ1995" nur "IM.UMSATZ.DEZ1995" auf dem Band gespeichert. Der Zugriff wäre nun mit einem Job möglich gewesen, der auf eine Banddatei zugreift, deren Name mit den letzten 17 Stellen des ursprünglichen Dateinamens übereinstimmt. RACF hätte seine Prüfungen mit dem neuen Namen durchgeführt. Nachdem diese Lücke im Sicherheitskonzept erkannt war, wurde sie umgehend beseitigt.
Im Fall des RHSO gibt es keine Anhaltspunkte, daß diese Schwachstelle irgendwann ausgenutzt wurde. Sie kann aber in vielen Rechenzentren existieren, so daß es sich für Verantwortliche lohnt, besonders darauf zu achten.
14.1.1.2.3
Revision von MVS
Bei der Betrachtung, ob die Zugriffe in einem MVS-Rechenzentrum ausreichend kontrolliert werden, darf nicht außer acht gelassen werden, daß RACF nicht in das Betriebssystem integriert ist. Es ist ein Aufsatz von MVS, und dort können Hintertüren eingebaut werden. Daher muß von einer Revision kontrolliert werden, ob RACF korrekt implementiert ist und im MVS keine unzulässigen Funktionen existieren. Wegen der Komplexität von MVS stellt dies ein Problem dar. Ohne Hilfsmittel und erfahrene Prüfer ist es fast unmöglich, die nötigen Kontrollen vorzunehmen.
Im RHSO war zur Unterstützung der Revision von MVS eine Spezialsoftware testweise installiert. Die Testinstallation diente dazu festzustellen, ob die Software den Anforderungen genügt. Darüber hinaus wurde zusammen mit den anderen Rechenzentren der Sparkassenorganisation eine einheitliche Lösung gesucht. Über das weitere Vorgehen war noch nicht entschieden.
14.1.2
Fazit
Bei der Prüfung fand ich eine Reihe guter Problemlösungen vor und nur wenige Schwachstellen, die so weit möglich sehr schnell behoben wurden. Das Gesamtbild zeigte Datensicherungsmaßnahmen, die sich auf einem überzeugenden Stand befanden.