Warum bilden Client-Server-Anwendungen nach wie vor eher die Ausnahme als die Regel? Haftet ihnen immer noch der Ruf der mangelnden Sicherheit an? Im folgenden analysieren Klaus Buecklers und Thorsten Glattki* die sicherheitsrelevanten Strukturen von Client-Server-Konzepten und stellen Loesungsmoeglichkeiten vor.

Viele Experten vertreten die Meinung, dass Client-Server- Anwendungen die Zukunft gehoert, dass dezentrale und mit dem Host vernetzte PCs direkten Zugang zu sensitiven Daten erhalten. Das ist schon seit Jahren der Fall? Nun, nicht ganz. In den ersten zehn Jahren seiner Existenz war es dem PC nur vergoennt, mittels einer Terminalemulation wie jedes andere dumme Terminal auch mit dem Host zu kommunizieren. Fuer die Host-Verantwortlichen war damit jahrelang die Welt wieder in Ordnung.

Dann entdeckte man, dass sich die PC-Rechenleistung dazu nutzen laesst, die teure Grossrechner-CPU zu entlasten. Die Idee der verteilten Anwendungen war geboren. Damit kamen grosse Probleme auf die DV-Verantwortlichen zu. Solange PCs nichts anderes als bessere Terminals waren, dominierten RACF-Verfahren. Daran hat sich auch bis heute nicht viel geaendert, denn auf rund 90 Prozent aller IBM- Hosts ist dieses Zugangskontrollsystem installiert.

RACF als Datenwaechter reicht nicht mehr aus

Als PCs nur als Terminalersatz verwendet wurden, hatten RACF- Funktionen lediglich die Aufgabe, beim Login darauf zu achten, ob ein Benutzer ins System durfte, und sollten sicherstellen, dass nur auf freigegebene Datenbereiche zugegriffen wurde.

Mit Aufkommen der Client-Server-Idee wurde die Sache aber deutlich komplizierter, da ein PC im Rahmen einer verteilten Anwendung direkt mit den verschiedenen Bereichen des Host-Systems kommuniziert. Alle Einzeldialoge zwischen einer PC- und einer korrespondierenden Host-Applikation (Transaktionen) sollen gesichert ablaufen. Prinzipiell geht eine Transaktion einen fest definierten Weg. Am Beispiel einer auf dem PC unter OS/2 laufenden Anwendung, die mit einem Host unter MVS kommuniziert, soll das Ganze konkret dargestellt werden.

Ueber ein Fenster identifiziert sich ein Anwender dem Gesamtsystem gegenueber mit Benutzerkennung und Passwort. Ueber die Stationen GUI- Prozessor, Dialogsteuerung und Anwendungskern gelangen diese sensiblen Daten zu den auf dem PC laufenden Services. Vor allem den Kommunikationsdiensten wie dem OS/2 Communication Manager gilt besondere Aufmerksamkeit: Hier werden die Pakete geschnuert, die dann ueber das Netz zum Host geschickt werden. Sie bestehen aus APPC-Verben und enthalten den Transaktionscode, die Benutzerkennung, das dazugehoerige Passwort, die Logical-Unit- Kennung des Kommunikationspartners und eventuell noch Benutzerdaten.

Der Zugang zum Host fuehrt in der Regel ueber den APPC-Adressraum, der vom uebrigen System abgeschottet ist. Ausnahme: Das OLTP CICS fuehrt die APPC-Kommunikation selbst durch. Von diesem Adressraum aus gelangen die einzelnen Transaktionscodes an das Transaktionsprogramm des Hosts beziehungsweise an darunterliegende abhaengige Programme, die dann ueber Ketten direkt auf die Datenbanken zugreifen.

Der APPC-Adressraum laesst sich sicher definieren. In der strengsten Form werden alle Transaktionscodes, die nicht mit den vordefinierten Tabellen uebereinstimmen, sofort geloescht.

Das hat sich in der Praxis jedoch eher als hinderlich denn als praktisch erwiesen - insbesondere bei der Anwendungsentwicklung. Die Transaktion laesst sich auf dem Host ueber RACF schuetzen. Das genuegt allerdings nicht, denn RACF sorgt auf der Ebene Dateien und Datenbanken fuer Sicherheit. Zudem arbeitet es nur auf dem IBM- Host. Will man den Passwortschutz auf Datenelementebene erweitern, werden Zusatzprodukte wie "Bonnprotect" benoetigt. Der Weg des Passworts zwischen dem Eingabefenster und den Kommunikationsservices auf dem PC ist ebenfalls recht sicher. Damit der Anwender sein Passwort nicht permanent eingeben muss, wird es auf dem PC fuer einen definierten Zeitraum gespeichert. Aus Sicherheitsgruenden verwendet man dafuer das als sicher geltende DES-Verschluesselungsverfahren.

Der OS/2 Communication Manager erlaubt Entwicklern das Tracen der APPC-Kommunikation. Auch hierbei wird das eigentliche Passwort in der Trace-Datei nur mit Leerstellen ausgewiesen, so dass kein Missbrauch moeglich ist. Leider reicht es in der heutigen Praxis aber nicht aus, Benutzern nur ein Kennwort zuzuweisen. Vielmehr operieren sie in verteilten Anwendungen oft mit drei und mehr Passwoertern: Eines wird zum Login auf dem Server benoetigt und je ein weiteres fuer jeden vorhandenen Host, fuer die DB2-Datenbank etc.

Installiert man DB2 zum Beispiel mit den Default-Werten, so benoetigt der Anwender unter DB2 ein eigenes Passwort, das sich nicht aus den anderen Kennwoertern ableiten laesst. Richtig fehleranfaellig wird eine Viel-Passwort-Umgebung immer dann, wenn die Kennwoerter routinemaessig geaendert werden, um die Sicherheit zu erhoehen. Hier helfen nur entsprechende Verwaltungssysteme weiter. "KUS" von SWT beispielsweise traegt Passwoerter von Siemens-Host- Security-Systemen auf IBM-Host-RACF-Systemen ein. Allerdings arbeitet auch dieses Tool nur auf Dateiebene. Vergleichbar einfache Tools haben zwischenzeitlich einige auf Sicherheit bedachte Anwenderunternehmen und Systemhaeuser fuer den Eigenbedarf entwickelt. Eine deutliche Verbesserung verspricht das Produkt "RACF Secured Signon", das IBM soeben auf den Markt gebracht hat.

RACF Secured Signon laesst sich auf allen Rechnern einsetzen, auf denen RACF laeuft. So sind Client-PC und Host-Server in der Lage, miteinander zu kommunizieren, ohne staendig das RACF-Passwort benutzen zu muessen. Als Alternative steht ein aehnliches Sicherheitselement, das "Passticket", zur Verfuegung. Damit dieses Universal-Quasi-Passwort nicht zum Sicherheitsrisiko wird, kann man ihm eine Lebensdauer zuweisen, die standardmaessig bei zehn Minuten liegt - das ist fuer die Praxis hinreichend sicher und dennoch komfortabel. Wem dieses Sicherheitskonzept noch zu unsicher ist, der hat die Moeglichkeit, bei der Kommunikation ueber das Netz zusaetzliche Funktionen zu nutzen. Schon die Auswahl der Netztopologie bestimmt bei einer Client-Server-Installation ueber den Grad an Sicherheit mit. Bei Ethernet-Verbindungen ist jede Station von vornherein dazu in der Lage, alle Datenpakete zu empfangen. Bei Token-Ring-Netzen gestaltet sich das deutlich schwieriger. Werden PCs mit Hilfe eines solchen Netzes an einen IBM-Host angeschlossen, erhoeht sich der Schutz mit der Verwendung von physikalischen Adressen (PUs) anstelle logischer Einheiten (LUs). Schon heute nutzen daher viele Netzadministratoren in sensiblen Umgebungen vorzugsweise PUs statt der deutlich komfortableren LUs. Allerdings bedeutet das einen hoeheren Verwaltungsaufwand und eine staerkere Belastung der Steuereinheiten.

Zusaetzlich sollte das Passwort verschluesselt ueber die Netzleitung gesendet werden. Dies gehoert in vielen Netzwerkumgebungen bereits zu den Standardfunktionen. Doch ein verschluesseltes Kennwort allein bringt noch keine absolute Sicherheit. Mit marktgaengigen Netzanalysatoren lassen sich heute Datenstroeme eines Netzes anzapfen, sichern und analysieren. Derartige Geraete gehoeren bei grossen Netzen mittlerweile zur Standardausruestung einer Netz-Crew, geraten sie jedoch in die falschen Haende, ist es vorbei mit dem Schutz vor unberechtigtem Zugriff.

Eine weitere Forderung fuer eine technisch moeglichst perfekte Sicherheitsloesung lautet daher, das Passwort mit einem staendig wechselnden Code zu verschluesseln. Hierzu wird gerne ein Zeitstempel verwendet. Das gilt auch fuer das Passticket, eine Implementierung des Kerberus-Standards. Alles in allem lassen sich also auch Client-Server-Installationen beliebig sicher gestalten.

Begriffe

APPC = Advanced Program-to-Program Communication, eine Protokolldefinition der IBM fuer verteilte Anwendungen in SNA- Netzen

CICS = Customer Information Control System

DES = Data Encryption Standard

GUI = Graphical User Interface

IMS = Information Management System

LU = Logical Unit

MVS = Multiple Virtual System

OLTP = Online Transaction Program, deutsch: TP-Monitor

PU = Physical Unit

RACF = Resource Access Control Facility

SNA = Systems Network Architecture

TSO = Time-sharing Option, eine Multiuser-Verwaltung unter MVS

VM/CP = Virtual Machine/ Control Program