COMPUTERWOCHE

		<>
		12.08.2004 um 23:41 Uhr


		*C/S Verteilte Systeme managen/Heterogene Plattformen erschweren IT-Sicherheit* Schweizerische Kreditanstalt: Regelbasierte Sicherheit für Client/Server-Applikationen CW-focus Nr. 2 vom 03.05.1996 Kundenorientierung und flexible Strukturen waren die Prämisse, die sich die SKA bei der Neugestaltung von bankspezifischen Client/Server-Anwendungen setzte. Da damit bereits absehbar war, daß die fortschreitende Entwicklung in Richtung Dezentralisierung und Verteilung der Verarbeitung über heterogene Plattformen zu einer Situation führte, in der eine umfassende IT-Sicherheit nur noch mit sehr großem administrativem Aufwand zu gewährleisten gewesen wäre, sollte gleichzeitig der Aufwand für die reine Sicherheits-administration deutlich reduziert werden. Über das Ergebnis berichten Hans-Peter Korn und Joachim Kessel.* Bei der Neukonzeption ihrer bankspezifischen Anwendungen stellte die Schweizerische Kreditanstalt (SKA) die Ablösung von Verarbeitungsstrukturen, die vornehmlich an der bisherigen bankinternen Organisation ausgerichtet waren, in den Vordergrund. War es früher eine spezielle Bankstelle, der ein Kunde fix zugeordnet war, so sollte der Kunde nun unabhängig von der Filiale mit allen entsprechenden Services und Dienstleistungen der SKA versorgt werden können. Die stärkere Orientierung am Kunden und eine dynamische Dienstleistungspalette waren die primären Gestaltungsprinzipien der neuen Client/Server-Anwendungen. Übergeordnetes Ziel war, trotz hohem Kostendruck und dynamischer Marktverhältnisse auch weiterhin einen qualitativ hochwertigen Kundenservice zu gewährleisten. Die vor diesem Hintergrund entwickelte Client/Server-Banking Software (CSBS) bietet den DV-Benutzern der SKA dienstleistungsorientierte Business Services an, in deren Mittelpunkt einzelne Bankobjekte, zum Beispiel "Kunde" oder "Konto", stehen. Über diese inhaltlichen Gestaltungsprinzipien hinaus sollten zukünftige Anforderungen aus dem Bankgeschäft schnell und reibungslos umzusetzen sein.Neukonzeption der IT-Sicherheit Neben der Neuentwicklung ihrer bankspezifischen Anwendungen setzte die SKA ein Projekt mit dem Ziel auf, die Sicherheitsadministration SKA-weit zu vereinfachen und zu vereinheitlichen. Grund dafür war die hohe Komplexität und der wirtschaftlich kaum mehr vertretbare Aufwand bei der Administration der unterschiedlich eingesetzten zentralen und dezentralen Zugriffsschutzsysteme. Es war absehbar, daß die fortschreitende Entwicklung in Richtung Dezentralisierung und Verteilung der Verarbeitung über heterogene Plattformen zu einer Situation führte, in der eine umfassende IT-Sicherheit nur noch mit sehr großem administrativem Aufwand zu gewährleisten gewesen wäre. Mit der Schumann Unternehmensberatung AG als externem Berater startete das Projekt zunächst mit der Analyse der Ist-Situation der bankinternen IT-Sicherheit. Ein Ergebnis dieser Studie war, daß die dynamische Entwicklung des IT-Einsatzes die eingesetzten Mittel zur Aufrechterhaltung der Informationssicherheit hinter sich gelassen hatte. Daraus resultierend sollten nun alle bei der SKA eingesetzten zentralen und dezentralen Sicherheitssysteme in einen durchgängigen Lösungsansatz einbezogen werden. Besonderes Augenmerk wurde bei der Erstellung des Konzeptes auf die Integration der applikatorischen Sicherheit gelegt. Als strategische Softwareplattform wählte die SKA den Security Administration Manager (SAM) der Schumann AG aus. Ein Softwareprodukt, das auf Basis einer SKA-spezifischen unternehmensweiten Sicherheitspolitik alle eingesetzten Zugriffsschutzsysteme einheitlich kontrollieren und steuern sollte. Bei der Festlegung der Realisierungsreihenfolge entschied die SKA, mit der Entwicklung des Zugriffsschutzes für die neuen Client/Server-Anwendungen - dem access control system (acs) - zu beginnen, da die neuen Bankanwendungen nicht ungeschützt bleiben konnten und ein Zugriffsschutzsystem, das den Anforderungen der SKA entsprach, am Markt nicht verfügbar war. Der Handlungsbedarf für die Restrukturierung der Sicherheitsadministration war zwar offensichtlich, doch konnte man mit dem Nebeneinander der unterschiedlichen Sicherheitssysteme noch eine Weile leben. Dies betraf auch die applikatorische Sicherheit der noch existierenden, später abzulösenden IMS-Anwendungen. Bei der Konzeption des access control systems (acs) standen auf übergeordneter Ebene folgende vier Ziele im Vordergrund: -Analog zu den neuen Client/Server-Anwendungen sollte auch das acs die Flexibilität der Bank in Hinsicht auf zukünftige Änderungen unterstützen. -Die Funktionalität mußte deutlich auf die neue Client/ Server-Software ausgerichtet sein. -acs sollte mit in das neue IT-Sicherheitskonzept auf Basis des Security Administration Manager (SAM) einbezogen werden. -Die bestehenden Sicherheitskategorien und -standards, die nur für die applikatorische Sicherheit speziell verwaltet wurden, sollten durch Ableitung der Zugriffsrechte aus anderweitig schon vorhandenen bankfachlichen Merkmalen der Benutzer ersetzt werden. Daraus resultierend erwartete die SKA eine Reduktion des Aufwandes für die reine Sicherheitsadministration in diesem Bereich um rund zwei Drittel. Aus wirtschaftlichen Gründen war insbesondere der letzte Punkt von ausschlaggebender Bedeutung und stand damit im Mittelpunkt des Interesses bei dem Schweizer Bankhaus. Dieses Ziel sollte über die Steuerung der Zugriffsberechtigungen mit jenen Benutzerdaten, die im Interesse des Bankbetriebs ohnehin schon verwaltet werden müssen, erreicht werden. Darüber hinaus würde die Verwaltung zusätzlicher benutzerbezogener Daten, die allein nur der Zugriffsberechtigung dienten (Sicherheitskategorien und Sicherheitsstandards), grundsätzlich entfallen. Abstrakte Ziele im ersten Projektschritt präzisiert Geeignet waren aus Sicht der SKA dafür Daten, die zuverlässig und aktuell gepflegt werden, das heißt Daten, die einen direkten Einfluß auf das richtige Funktionieren des Bankbetriebs haben. Damit ist sichergestellt, daß die Zugriffsrechte eines Benutzers ohne Zeitverzögerung seinen aktuellen Aufgaben entsprechen. Im nächsten Projektschritt erfolgte die Erstellung des Feinkonzeptes, in dessen Rahmen auch die oben genannten, noch recht abstrakt formulierten Ziele, weiter präzisiert wurden: -Berücksichtigung der Flexibilität der Bank in Hinsicht auf Organisation, Rollen, Rollenträger, Zugriffsregeln, Bankobjekte und Mandantenfähigkeit, -regelbasierte Zuordnung von Berechtigungen auf der Basis betrieblich definierter Funktionen und Business Services, -Loslösung der Berechtigungslogik von einer fest vorgegebenen Organisationsstruktur der Bankstellen, -Erteilung der Zugriffsberechtigungen anhand von Regeln zum Zugriffszeitpunkt, -Vollständige Trennung von Prüfung beziehungsweise Erteilung der Zugriffsrechte vom applikatorischen Teil des Programmcodes, -Realisierung des acs als Client/Server-Anwendung, -Transparenz der Prüflogik für den Entwickler der Applikation, das heißt eine unberechtigte Manipulation der Prüflogik durch einen Entwickler ist nicht möglich, -gute Verständlichkeit der Berechtigungsdefinitionen für den Bankbetrieb, -Integration in die auf SAM basierende Gesamtlösung. Um die Lösung zum Erreichen dieser Ziele darzustellen, wird in einem kleinen Beispiel zunächst das Grundprinzip der Client/Server-Banking-Software erläutert: Ein Bankmitarbeiter, etwa ein Kundenberater, ruft über die grafische Oberfläche seiner Workstation die Postadresse eines bestimmten Kunden auf. Der Software-Client auf der Workstation löst nun eine Request Message an den Server auf dem Hostsystem aus. Dieser logisch als Business- Objekt "Kunde" auftretende Server stellt den Business Service "Postadresse des Kunden liefern" zur Verfügung. Dieser Service kann nur über die Request Message angesprochen werden und liefert die angeforderten Business-Objekt-Daten grundsätzlich nur als Response Message an den anfordernden Client zurück. Der Konto-Server muß seinerseits die Adresse vom Kundenserver holen, er selbst kennt nur den Inhaber-Key. Das Beispiel zeigt, daß sich die aufgerufenen Services nicht nur auf ein Business-Objekt beschränken. So kann ein Business Service wiederum weitere Services des gleichen Objektes oder weitere Business-Objekte/Services aufrufen. Direkte Zugriffe auf Datenbanken unter Umgehung der Business Services werden unterbunden. Der Client ruft Business Services auf dem Host auf Das acs, das für den Bankmitarbeiter vollständig transparent arbeitet, besteht im wesentlichen aus drei Teilen: -Einem operativen Teil, der zum Zeitpunkt der Ausführung über den Zugriff entscheidet, dem Access Control Decision Server (ADS), -einem Teil, der bei jedem Zugriff den ADS anspricht und den Zugriff entsprechend der Entscheidung ermöglicht oder verhindert, die Access Control Enforcement Function (AEF). Der ADS umfaßt die Access Control Decision Function (ADF) inklusive der Zugriffsregeln und Benutzermerkmale, -einem administrativen Teil, dem Access Control Administration Tool (AAT), zur Erfassung, Optimierung und Verteilung von Regeln sowie der Konsistenzprüfung. Ruft nun der Bankmitarbeiter aus dem obigen Beispiel über die Workstation die Postadresse des gewünschten Kunden auf, so läuft seine Anforderung zunächst auf die Access Control Enforcement Function (AEF). Alle Business-Objekte und damit auch ihre Services sind nach außen mit der Access Control Enforcement Function (AEF) abgeschirmt. Die AEF erzeugt nun eine Decision Request Message an den ADS, in dem die gesamte Prüflogik implementiert ist. Bei der Prüfung der Zugriffsberechtigung müssen die folgenden Fragen beantwortet werden: -Handelt es sich um den Folgeaufruf eines Services, für den die Zugriffsberechtigung bereits erteilt wurde? In diesem Fall erfolgt keine weitere Prüfung. Eine Mehrfachprüfung desselben Business Services wird damit ausgeschlossen. -Darf der Benutzer den gewünschten Service grundsätzlich nutzen? -Darf er das insbesondere auch für die gewünschte Instanz des Business-Objektes (zum Beispiel einen bestimmten Kunden)? Der ADS holt sich nun die für die Beantwortung der Fragen, bzw. die für die Prüfung relevanten Daten aus einer zugriffsoptimierten, geschützten Datenbasis. Dies sind die sicherheitsrelevanten Merkmale des Benutzers und die Zugriffsentscheidungsregeln des jeweiligen Services. Darüber hinaus sind die sicherheitsrelevanten Merkmale des jeweiligen Business-Objektes entscheidungsbestimmend. Dies kann zum Beispiel die "Kundenart" des Kontoinhabers sein. Um Funktionsaufrufe, das heißt Zugriffe auf Services zu vermeiden, zu denen ein Benutzer grundsätzlich keine Berechtigung hat, kann der Client vom ADS die Informationen beziehen, zu welchen Benutzerdaten in vertrauten SKA-Systemen belassen Services ein bestimmter Benutzer Zugang hat. Damit kann die Benutzeroberfläche auf der Workstation so gestaltet werden, daß der Benutzer nur die ihm erlaubten Aktionen aufrufen kann, beziehungsweise sieht. Die Rolle des Access Control Administration Tools (AAT), als administrativer Komponente des acs, wird durch den Security Administration Manager (SAM) übernommen. Dort sind alle Access-Control Informationen (ACI) der Benutzer und die Zugriffsregeln für alle Business Services in Form von Entscheidungstabellen abgelegt. Eine der wesentlichen Anforderungen zur Optimierung der Berechtigungsprüfungen und zur Reduktion des adminstrativen Aufwandes war die Ableitung der Zugriffsrechte aus anderweitig schon vorhandenen bankfachlichen Kennzeichen der Benutzer. Diese Benutzerdaten werden von den Verwaltungsstellen nicht in SAM, sondern weiterhin in den ihnen vertrauten SKA-Systemen gepflegt. Über entsprechende Schnittstellenprogramme werden die Benutzermerkmale unter anderem aus dem Personalinformationssystem der SKA in das AAT (SAM) importiert und in SAM-eigenen Datenstrukturen abgelegt. Darüber hinaus ist die Eingabe benutzerbezogener Spezialberechtigungen über einfache Erfassungsmasken im AAT möglich. Die Erfassung und Pflege der Zugriffsregeln für die Business Services erfolgt über Entscheidungstabellen ebenfalls in der acs-Administrationskomponente. Das auf Basis von SAM entwickelte AAT besitzt kein starres sondern ein ohne Codeänderung flexibel anpaßbares "Self Defining Data Model" für alle Sicherheitsdaten. Im Ergebnis sind damit alle Informationen zentral im AAT abgelegt, die für die Zugriffserteilung auf einen Business Service notwendig sind. SAM übergibt diese Access Control Informationen dann in zugriffsoptimierter Form der Datenbasis, auf die der ADS zugreift. Für die SKA sind an dieser Stelle zwei Punkte von wesentlicher Bedeutung: Zum einen ist damit die Ablösung zusätzlich zu verwaltender Sicherheitsmerkmale durch aus dem normalen Bankbetrieb abgeleitete Benutzermerkmale erreicht. Dies war eine Voraussetzung für die Reduktion des Administrationsaufwandes. Zum zweiten ist mit der Nutzung von SAM als zentraler acs-Administrationskomponente die Grundlage geschaffen, mit diesen Benutzermerkmalen auch andere Schutzsysteme, zum Beispiel ACF2, zu bedienen. Der Access Control Decision-Server ist so konzipiert, daß er mit wenig Aufwand auf verschiedene Plattformen und Betriebssysteme portiert werden kann. In der SKA ist er derzeit unter MVS/CICS implementiert. Dagegen ist die Access Control Enforcement Function (AEF) stets spezifisch für das jeweilige Client/Server-Design, das heißt sie muß an die entsprechenden Kommunikationskomponenten angepaßt werden. Bei der SKA ist die AEF Bestandteil des Business- Server-Hauptprogramms, das nicht manuell codiert, sondern vollständig generiert wird. Eine Manipulation der AEF ist damit praktisch ausgeschlossen. Die ersten Ideen für das acs entstanden im Frühjahr 1994. Nachdem die Schumann AG im August desselben Jahres mit der Entwicklung der acs-Komponente AAT auf der Basis von SAM begann, konnte Erwartungen an Sicherheitsmechanismen voll erfüllt der Prototyp bereits im Februar 1995 getestet werden. Die Übernahme in die Produktion als SKA-spezifische Lösung wurde Ende 1995 abgeschlossen. Für das Jahr 1996 ist das acs-Release 2 geplant, das auch auf OS/2-Plattformen implementierte Business Services schützen und funktionale Erweiterungen - unter anderem im Bereich Controlling und Reporting beinhalten wird. Die Erwartungen an die Wirtschaftlichkeit und die Effizienz der implementierten Sicherheitsmechanismen seien nach Angaben der Verantwortlichen damit voll erfüllt. So faßt Dr. Hans-Peter Korn, verantwortlicher acs-Projektleiter bei der SKA, die Erfahrungen aus dem Projektablauf zusammen: "Wir sind überzeugt, daß das acs auch die für die in den nächsten Jahren schrittweise einzuführende Client/Server-Banking- Software den nötigen Zugriffsschutz gewährleistet. Es werden dabei auch weitere Server-Plattformen neben MVS/ CICS unterstützt. Ich denke hier insbesondere an OS/2 und UNIX als Betriebssysteme mit objektorientiert realisierten Servern - zum Beispiel mit Smalltalk. Wir werden acs auch dafür implementieren. Darüber hinaus wollen wir als nächsten Schritt die Sicherheitssteuerdaten des bisherigen Zugriffsschutzsystems fürVerwaltungsaufwand soll drastisch reduziert werden die noch bestehenden Applikationen mit den Entscheidungstabellen des acs automatisch generieren und den Verwaltungsaufwand dafür drastisch reduzieren." Der betriebswirtschaftliche Hauptnutzen von acs liegt nach Meinung des Client/ Server-Spezialisten darin, daß der Zugriffsschutz primär mit bereits vorhandenen Daten und nicht mit zusätzlich zu verwaltenden Sicherheitsdaten gesteuert wird. Sein Fazit: "Das wollen wir auch für andere noch bestehende Applikationen nutzen." Dr. Korn führt die kurze Projektdauer von nur 19 Monaten (vom Projektauftrag bis Einführung) auf das Engagement und die Kompetenz der beteiligten Mitarbeiter zurück. Von den rund 2300 dafür verwendeten Personentagen wurde fast die Hälfte von SKA-externen Spezialisten der Schumann Unternehmensberatung AG (AAT auf Basis von SAM) und der Integrata Schweiz AG (ADS und AEF) erbracht. Die zeit- und kostenintensive Umsetzung des aufgaben- beziehungsweise funktionsorientierten Regelwerkes in technologiekonforme Definitionen wird von dem System geleistet. Die Eingabe und Pflege der Zugriffsregeln für die Business Services erfolgt auf einer logischen bankbetrieblichen Ebene über Entscheidungstabellen. Mit dem Prinzip der Trennung von Programm- und Prüflogik können Änderungen, sei es der Anwendung selbst oder der Zugriffsregeln, schnell und mit geringem Aufwand umgesetzt werden. Der SKA-Konzern 1993 erwarb die CS Holding (CSH) die Schweizerische Volksbank (SVB) und schuf den SKA-Konzern, bestehend aus zwei vollwertigen Dienstleistungsbanken: Schweizerische Kreditanstalt (SKA) und die Schweizerische Volksbank sowie deren Tochtergesellschaften. Der Teilkonzern SKA besteht aus der SKA und deren Tochtergesellschaften, darunter Credit Suisse, Financial Products und Credis Investment Funds. Als international tätige Universalbank bietet die SKA Finanzdienstleistungen für mittlere bis große Unternehmen, private sowie institutionelle Investoren und gehobene Privatkunden an. Der Teilkonzern SVB, welcher die SVB und deren Tochtergesellschaften umfaßt, bietet standardisierte Bankdienstleistungen mit Schwerpunkt auf Retail Banking an. Die CSH ist eine der führenden Gruppen auf dem Finanzdienstleistungssektor weltweit. Sie verfügt über rd. 500 Geschäftsstellen in der ganzen Welt, beschäftigt mehr als 50.000 Mitarbeiter und ist auf allen fünf Kontinenten sowie an allen Hauptfinanzplätzen der Welt aktiv. Weitere Unternehmen in der CS Holding sind CS First Boston, Privatbankgruppe, Fides Informatik, CS Life und Electrowatt AG. Firmenprofil: SKA-Konzern, Zürich Schlüsselzahlen (Geschäftsjahr 1995): Bruttoertrag: 7.940 Mio. sfr Konzerngewinn: 1.234 Mio. sfr Bilanzsumme: 244.699 Mio. sfr Personal (Schweiz) per 1.1.96: 21.747 Mitarbeiter Personal (Ausland) per 1.1.96: 4.611 Mitarbeiter Büros einschließlich Filialen: 383 in der Schweiz, 102 im Ausland



		Anzeige