Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03620.jsonl.gz/2593

Distributed Systems Security

Sicherheits-Framework für Anwendungen in vernetzten Systemen
A. Beuchat, B. Federspiel, M. Isler, D. Maurer, A. Thorn, G. Trenta.
Disclaimer
Das vorliegende Dokument gibt ausschliesslich die Meinung der Autoren wieder und stellt keinen offiziellen Standpunkt der SI oder der SI Fachgruppe Security dar.
Angaben über Produkte und Hersteller stellen keine Empfehlung oder Bewertung dar.
Irrtum und Druckfehler vorbehalten.
Das 'Sicherheits-Framework für Anwendungen in vernetzten Systemen' ist eine Uebersicht über die besonderen Sicherheitsaspekte in modernen Rechnernetzen. Ausgehend von den Strukturen im Netzverbund werden die hauptsächlichsten Risiken und die vielfältigen Ursachen der Bedrohungen in vernetzten Systemen aufgezeigt.
Nach der Definition der für die Sicherheit im Netzverbund notwendigen Security Services werden an Hand eines 'Distributed Security Models' die relevanten Beziehungen zwischen Benutzern, Prozessen und Daten untersucht. Diese Betrachtung von Services und Beziehungen erlaubt eine strukturierte Analyse der Elemente. Dabei wird auch auf die dem idealisierten Modell zugrundeliegenden Annahmen und Voraussetzungen eingegangen, die erfüllt sein müssen, damit das Modell den angestrebten Schutz tatsächlich bieten kann.
Die Umsetzung der Sicherheitsservices und des Distributed Security Models verlangt nach Standardisierung. Am meisten Erfolg verspricht eine einheitliche Programmschnittstelle (Application Programming Interface, API), welche den Aufruf der Sicherheitsfunktionen unabhängig von den darunterliegenden Verfahren generisch definiert.
In vernetzten Systemen muss die Sicherheit bereits im System Design und in der Auslegung der Systeminfrastruktur beachtet werden. Dazu gehören insbesondere die Wahl der Verarbeitungsmodelle und die Plazierung von Funktionen und Daten in Client / Server Netzen. Das 'Sicherheits-Framework' untersucht die Merkmale der verschiedenen Verarbeitungsmodelle bezüglich der Sicherheit als Grundlage für die Struktur der Anwendungen und die Plazierung von Prozessen und Daten.
Das 'Sicherheits-Framework' vertritt die These, dass die Sicherheit durch eine Kombination von Massnahmen in drei Dimensionen verwirklicht werden muss:
Die personenorientierte Sicherheit umfasst die organisatorischen Voraussetzungen, an die in vernetzten Systemen deutlich höhere Anforderungen gestellt werden.
Die ressourcenorientierte Sicherheit bezieht sich auf Standards, Base Line Controls und unternehmensweite Richtlinien, um die zum Schutz der Unternehmenswerte notwendigen technischen Anforderungen sicherzustellen.
Die werteorientierte Sicherheit beinhaltet die Sicherheitsanforderungen gemessen am Wert der Information und unter Berücksichtigung der Geschäftsprozesse, vor allem im Finanzbereich.
Abschliessend werden Merkmale einer umfassenden Lösung aufgezeigt, deren Verständnis für das Lösungskonzept wesentlich ist.
Die Sicherheitsanforderungen verteilter Systeme werden selbst von Informatik-Fachleuten oft unterschätzt. Mit dem 'Sicherheits-Framework' soll insbesondere der Führungsstufe die Problematik aus Sicht der Bedrohungen, Massnahmen und Lösungskonzepte verständlicher gemacht werden. Das Informatik-Sicherheitsdispositiv der Unternehmung muss auf dieser Stufe verankert sein, um erfolgreich umgesetzt zu werden. Das 'Sicherheits-Framework' möchte aber auch für den interessierten Nichtfachmann einen Beitrag zum Verständnis der Materie leisten.
Die Entwickler von 'Mainframe' Anwendungen können sich auf eine gut eingeführte Infrastruktur verlassen, um ihre Sicherheitsanforderungen zu realisieren. Nun, wo die Applikationen den geschützten Bereich des zentralen Grosscomputers verlassen, fehlt eine entsprechende Infrastruktur weitgehend.
Am Anfang dieser Entwicklung war die Versuchung gross und auch verständlich, Sicherheitsanstrengungen vorerst einmal beiseite zu schieben. Zu Beginn und in der Pionierphase der Client / Server Anwendungsentwicklung mochte eine solche Haltung 'funktionieren', bei zunehmender Ausbreitung im kommerziellen Bereich und beginnender Stabilisierung melden sich jedoch Bedenken. Nun wird der Ruf nach einer gesicherten Umgebung für eine dezentrale Verarbeitung von Daten immer lauter.
Das nachträgliche Einführen von Sicherheit in eine bereits gewachsene Umgebung ist jedoch ein schwieriges Unterfangen. Jede Sicherheitsfunktionalität, auch dann, wenn sie von der Applikation getragen wird, muss nämlich in letzter Konsequenz in der Integrität der Maschine wurzeln. Ansonsten bleibt die Sicherheit aufgepfropft und lässt sich von einem erfahrenen Angreifer mehr oder weniger leicht 'aus den Angeln heben'.
Die Hersteller und Anbieter der Betriebssysteme wissen um diese Problematik. Da sie marktorientiert sind, beginnen sie jedoch mit dem Umbau offener zu gesicherten Betriebssystemen erst dann, wenn es der Markt verlangt. Für Betriebe, deren Sicherheitsbedürfnisse grösser sind als jene des durchschnittlichen Anwenders, kommt diese Entwicklung zu spät.
Banken, Versicherungen, Chemie- und andere grossindustrielle Betriebe sowie Behörden haben bereits vor geraumer Zeit damit begonnen, Sicherheitsfunktionalität für verteilte Anwendungen fallweise selber zu realisieren. Sie stehen nun vor der Problematik, die für eine spezialisierte, proprietäre Umgebung entwickelten Anwendungen entweder auf andere Kommunikationsprotokolle und Plattformen zu erweitern, oder zugunsten von einzukaufenden Produkten fallenzulassen.
Die momentane Situation im Sicherheitsbereich ist unserer Meinung nach weder genügend stabil, noch ist die Richtung, in der sich die zukünftigen Problemlösungen bewegen, eindeutig bestimmbar. Den Betrieben bleiben deshalb, sofern sie sich für echtes Client / Server Computing in vernetzten Systemen entscheiden, nur von Geschäftsleitung und Management unterstützte Zwischenschritte im Sinne der Aufrechterhaltung eines bereits erreichten Sicherheitsstandards.
Das vorliegende Framework soll begriffliche und strategische Hilfestellung bei der Aufgabe bieten, die Sicherheitsanforderungen von Anwendungen in vernetzten Systemen auf eine am derzeit Machbaren orientierte Weise abzudecken, bis sich generalisierte Lösungen auf dem Markt durchsetzen.
Das vorliegende Dokument gliedert sich nach Vorwort und Einführung in drei unterschiedliche Teile:
|Risikolage =>||Umfeld und Bedrohungen|
|Theoretische Grundlage =>||Das Distributed Security Model|
|Massnahmen =>||Vorstellung von Lösungsansätzen|
Im Anhang schliesslich werden einzelne Themen gesondert und überblicksartig beschrieben.
Durchgängig durch das ganze Dokument wird jeweils eine Gliederung vorgetragen, die die Sicherheitsproblematik in vernetzten Systemen aus den unterschiedlichen Blickwinkeln der Anforderungen an eine Identifikation und Authentikation, an eine Authorisation (Zuteilung von Rechten), an einen gesicherten Datentransport und an Ueberwachung und Nachvollziehbarkeit betrachtet.
Das Dokument wurde von einem Autorenteam verfasst und widerspiegelt nicht eine gänzlich einheitliche Ansicht. In den Grundsatzfragen haben wir jedoch in intensiven Diskussionen einen unserer Meinung nach tragfähigen Konsens gefunden.
In dem vorliegenden Dokument befassen wir uns ausführlicher mit neueren Konzepten und Lösungen, deren Ansatz tendenziell darin besteht, die Sicherheit im Rahmen der Anwendungen und unter Einsatz von Client / Server Techniken zu realisieren.
Der Unterhalt eines unternehmensweiten Netzwerkes bringt indess eine ganze Reihe von organisatorischen und technischen Sicherheitsproblemen mit sich, ohne deren vernünftige Handhabung eine direkt an den informationsverarbeitenden Prozessen und Objekten ansetzende Sicherheit sinnlos ist. Darauf gehen wir wiederholt und insbesondere in den Lösungsansätzen ein, wenn auch in etwas allgemeinerer Form.
Da sie den Rahmen dieser Betrachtungen sprengen würden, können eine Reihe weiterer wichtiger Probleme, die die Sicherheit in vernetzten Systemen gefährden, nicht behandelt werden. Dies sind vor allem Infrastrukturprobleme wie die Bereitstellung von Ausweichprozeduren und effizienten Backup-Verfahren, die Entwicklung, Qualitätssicherung und Verbreitung von Software und das dezentralisierte Management der Maschinen und Netzwerke.
Das Szenario, von dem wir ausgehen, ist das moderne, unternehmensweite Netzwerk. In der 'alten' Umgebung hatten wir Grund zur Annahme die Sicherheit sei unter Kontrolle. Einige spezifische Veränderungen verursachen uns nun Probleme:
Bild 1 'alte Umgebung'
Heute nun ist das Königreich des Zentralcomputers in Auflösung begriffen und viele seiner Funktionen sind von kräftigen Kleincomputern oder gar von 'intelligenten' Arbeitsstationen übernommen worden. Die datenverarbeitenden Ressourcen sind nicht mehr konzentriert, sondern über das ganze Unternehmen verstreut.
Bild 2 'neue Umgebung'
Was vielleicht noch mehr ins Gewicht fällt, ist die Veränderung des Netzwerk Designs von einem hierarchischen Modell zu einem Modell von Beziehungen unter Gleichberechtigten, dem sogenannten 'peer to peer' Netzwerk. In der Vergangenheit band eine feste Verbindung das Terminal an einen Kontroller. Heute ist im Prinzip das ganze Netzwerk ein Verbund aller mit allen. Das bedeutet, dass ein Benutzer, der früher Zugang zu einem einzigen System hatte, heute mit einer Vielzahl von Rechnern in Verbindung treten kann.
Ein weiterer Effekt des grundlegenden Wandels ist die allmähliche Auflösung früher deutlich von einander unterscheidbarer Organisationsformen in dem komplexen Prozess der Informationsverarbeitung. So verwischen sich heute oft die Grenzen zwischen Entwicklungssystemen, Test und Produktion. Verteilte Rechner werden häufig durch firmenfremdes Personal gewartet. Betriebssysteme und Netzwerkprotokolle sind tendenziell weniger proprietär als früher und an 'offenen' publizierten Standards orientiert. Die traditionelle Bindung des Unternehmens an einen Hersteller nimmt ab.
All diese Veränderungen haben selbstverständlich Auswirkungen auf die Sicherheit der Informatik eines Unternehmens. Wir glauben, dass es gerade im Bereich der Informatiksicherheit nicht übertrieben ist, von einer radikal veränderten Situation auszugehen, die zusätzlich zu einer bereits vorhandenen und allfällig auszubauenden Basissicherheit grundsätzlich andere mit den früheren unvereinbare Lösungsansätze erfordert.
Obwohl sich das Umfeld wesentlich geändert hat, bleibt sich die Art und Weise der möglichen Bedrohungen gleich. Wir sind weiterhin konfrontiert mit Verletzungen der Verfügbarkeit, der Integrität und Vertraulichkeit von Informationen. Die Anforderungen an eine sichere Datenverarbeitung sind immer noch:
Die Information ist Angriffen vermehrt ausgesetzt
Im modernen Netzwerk zirkulieren die Daten - und im speziellen die zur Feststellung der Authentizität benötigten Daten (Benutzerkennzeichnung und Passwort) - über weite Netzstrecken durch zahlreiche Arbeitsstationen und Rechner. Was die Sicherheit betrifft, ist dabei das gesamte Netzwerk gerade so stark wie sein schwächstes Glied. Im Fall einer Attacke - komme sie nun von innerhalb oder ausserhalb des privaten Netzwerkes (autorisierte Benutzer miteingeschlossen) - kann jeder Benutzer oder jede Maschine gerade dieses schwächste Glied in der Kette sein.
Die Netzwerkknoten sind verwundbarer
Weil Betriebssysteme und Netzwerkprotokolle öffentlich publiziert sind, besitzen heute zahllose Studenten und junge Informatik-Cracks Kenntnisse von UNIX, DOS oder TCP/IP, die früher einer kleinen Kaste von Systemspezialisten vorbehalten waren. Eine mögliche Konsequenz davon ist, dass ein Angreifer seine Arbeitsstation durch das einfache Installieren eines auf dem öffentlichen Markt erhältlichen Programmes in einen Netzwerk-Sniffer verwandeln kann, der alle Passwörter speichert, die dort vorbeikommen (und das sind gewiss einige!).
Eine weitere Konsequenz ist die Bedrohung durch Hacker. Jedes grössere Netz ist heute an öffentliche Dienste angeschlossen und zu diesem Zweck mit einem öffentlichen Netzwerk verbunden. Das Risiko ist real: eine multinational tätige amerikanische Grossfirma rapportiert durchschnittlich 30 unautorisierte Angriffsversuche pro Woche auf ihre Netzwerkeinrichtungen (Firewall) am Schnittpunkt zu den öffentlichen Netzen (in diesem Fall dem Internet).
Durch die rasche und schwer kontrollierbare Vernetzung ist oft unklar, welche Netzsegmente miteinander verbunden sind. Ein Firmendispositiv, welches den physischen Einschluss aller Netzwerkknoten verlangt, ist deshalb sehr wichtig, lässt sich aber in der Praxis nur schwer kontrollieren. Beinahe sicher muss davon ausgegangen werden, dass zumindest zeitweise Segmente an das private Netzwerk angeschlossen sind, die sich einer organisatorischen Kontrolle entziehen. Dies ist bereits dann der Fall, wenn ein einzelner Teilnehmer eine Modemverbindung von seiner Workstation zu einem öffentlichen Netz aufschaltet.
Die Verwaltung und Ueberwachung ist schwieriger geworden
Durch die Verteilung der Rechenkapazitäten im ganzen Netzwerk ist es oft auch ungeschultes Personal, das die Funktionen eines Systemadministrators ausübt. Dies führt natürlich zu weitaus mehr Fehlern und Unwägbarkeiten als dies früher der Fall war, als die Systemfunktionen durch vollzeitliche trainierte Professionals der zentralen Fachstellen wahrgenommen wurden.
Die Zahl der Passwortabfragen nimmt zu
Weil der Benutzer heute, um seine Arbeit ausführen zu können, auf viele Systeme Zugriff haben muss, wird er wiederholt nach einem Passwort gefragt. Verwendet er nun überall dasselbe Passwort, ist dieses mit jeder Verwendung gefährdeter, entdeckt zu werden. Dennoch wird man von einem Benutzer kaum verlangen können, dass er sich fünf bis zehn Passwörter merken soll, die dazu noch strengen Regeln genügen und öfters gewechselt werden müssen. Der Benutzer wird sich deshalb die Passwörter aufschreiben oder einfache Kombinationen bilden. Solche Verhaltensweisen gefährden aber die Sicherheit der Passwörter, die zu allem Unglück oft die einzige Sicherheit darstellen, über die ein System verfügt.
Die loyalen Benutzer sind zunehmend überfordert
Die Mehrheit der heutigen Angestellten ist sich in allgemeiner Form bewusst, das die moderne Informationsverarbeitung Gefahren mit sich bringt. Sie empfinden dies allerdings als lastende Verantwortung, zu deren Bewältigung sie sich im Regelfall ausserstande sehen. Um dieses weitverbreitete Gefühl einer gewissen Hilfslosigkeit zu beseitigen, sind enorme Anstrengungen in der Bewusstseinsbildung, sogenannte 'Awareness'-Programme notwendig. Leider drücken sich immer noch die meisten Unternehmen um diese aufwendige, aber wichtige Aufgabe. Gerade in vernetzten Systemen bildet der loyale (im 'vernetzten Denken' geschulte) Benutzer das wertvollste Kapital zur Bewältigung der Sicherheitsprobleme.
Angemessene 'Security Tools' sind noch nicht erhältlich
Zur Zeit fehlen Werkzeuge, die alle Sicherheitsanforderungen in vernetzten Systemen mit einem einheitlichen Ansatz abdecken würden, oder sie sind noch nicht ausgereift. Mischlösungen aus verschiedenen teils eingekauften, teils eigenentwickelten, möglicherweise kaum vereinbaren Produkten, ergänzt durch eine Reihe organisatorischer Massnahmen sind (noch) die einzige Antwort.
Obwohl die Verwundbarkeit des unternehmensweiten Netzwerkes wesentlich grösser ist als früher, und einheitliche Lösungen noch nicht ausgereift sind, werden wir uns im folgenden um eine Sicht bemühen, die die manchmal auseinanderlaufenden Sicherheitsstrategien in vernetzten Systemen auf eine gemeinsame Grundlage bringt, von der aus zumindest die Migration in spätere generalisierte Lösungen nicht behindert ist.
Es besteht heute ein weitgehender Konsens darüber, welche Sicherheitsservices zum Schutz von Informatiksystemen notwendig sind. Diese Sicherheitsservices werden im folgenden kurz vorgestellt.
Bewusst beschränken wir uns auf die wichtigsten Services der unternehmensweit vernetzten Systeme (siehe auch Kapitel Bedrohungen).
Der Authentikationsservice stellt die Identität eines Benutzers beziehungsweise eines Programmes fest und überprüft sie. Der Authentikationsservice ist notwendig, um auf einem Informatiksystem verschiedene Benutzer zu unterscheiden und differenzierte Zugriffsrechte definieren zu können.
Authentikation der Benutzer
Die Authentikation der Benutzer ist die eigentliche Grundlage der Informatiksicherheit, denn diese sind letztendlich für alle im System ablaufenden Prozesse verantwortlich. Der Authentikationsservice verlangt vom Benutzer nebst der Identifikation mit einer User ID (z.B. ACF2 PID) die Angabe einer zusätzlichen Information, die unlösbar mit ihm verknüpft ist (z.B. Passwort, persönliches Token, Fingerabdruck).
Weitervererbung der Authentikation
Der Benutzer führt Aktivitäten in einem System typischerweise unter Einbezug verschiedener dazwischenliegender Hard- und Softwarekomponenten aus, die in seinem Namen agieren (z.B. Arbeitsstation, Netzwerk, Programme). Der Authentikationsprozess muss diese ganze Kette von Komponenten umfassen. Bei der Client / Server-Verarbeitung ist die gegenseitige Authentikation von Clientprogramm und Serverprogramm besonders wichtig.
Der Access Control Service übt die Kontrolle darüber aus, wer auf welche Art auf welche Objekte zugreifen kann. Der Access Control Service ist notwendig, um die in einem Unternehmen verbindliche Sicherheitspolitik durchzusetzen.
Wir unterscheiden dabei zwischen zwei theoretisch und praktisch völlig verschiedenen Arten von Zugriffskontrollen.
Technische Zugriffskontrolle für Systemressourcen
Kontrolle des Zugriffes auf die Komponenten eines Computers (z.B. Datenbanken, Programme) sowie des Zugriffes auf den Computer selber.
Die Kontrolle wird dabei von einer systemnahen, spezialisierten Anwendung ohne Zutun der datenverarbeitenden Anwendung ausgeübt (z.B. RACF).
Applikatorische Zugriffskontrolle für Business Prozesse
Kontrolle des Zugriffes auf geschäftsorientierte Funktionen in Abhängigkeit von Attributen des betroffenen Geschäftsgegenstandes. (z.B. Lesen des aktuellen Saldos des eigenen Kontos).
Die Kontrolle wird dabei aus der datenverarbeitenden Anwendung heraus allenfalls unter Zuhilfenahme einer applikationsnahen (Middelware-) Komponente ausgeübt.
Data Confidentiality
Der Confidentiality Service schützt die über Kommunikationsverbindungen transportierten Daten vor unberechtigter Einsicht (z.B. mittels Verschlüsselung).
Data Integrity
Der Integrity Service schützt die über Kommunikationsverbindungen transportierten Daten und den Meldungsfluss vor unberechtigter Manipulation (z.B. mittels kryptografischer Quersummenberechnung, sogenanntem MACing).
Non-Repudiation
Der Non-Repudiation Service verhindert das Widerrufen von Meldungen. Er basiert auf der Integrität der übermittelten Daten und setzt deshalb den Integrity Service voraus.
(z.B. durch die Realisierung von digitalen Unterschriften).
Non-Repudiation of origin entspricht einer Unterschrift. Der Empfänger einer Meldung kann gegenüber einer dritten Partei die Identität des Absenders nachweisen.
Non-Repudiation of delivery entspricht einer Notariatsfunktion. Der Absender einer Meldung kann gegenüber einer dritten Partei beweisen, dass die Meldung vom Empfänger erhalten worden ist.
Der Audit-Service erfüllt zwei Anforderungen: jene nach Ueberwachung und jene nach Nachvollziehbarkeit.
Audit
Der eigentliche Audit-Service stellt sicher, dass genügend Informationen über normale und aussergewöhnliche Ereignisse transparent gemacht werden, damit Untersuchungen möglich sind, wenn Sicherheitsverstösse entdeckt oder vermutet werden (z.B. durch Monitoring, um Hackerversuche festzustellen).
Accountability
Der Accountability-Service sorgt dafür, dass relevante Informationen über ausgeführte Aktionen abgespeichert werden, so dass diese zu einem späteren Zeitpunkt nachvollzogen werden können. (z.B. durch Sammeln und Aufbewahren von Logdaten).
Nachfolgend wird ein idealisiertes Modell für die Integration der Security Services in eine verteilte Systemumgebung vorgestellt.
Das Distributed Security Model basiert auf dem im Standard ECMA-138 in Appendix C definierten 'Application, Application-Data Model' (European Computer Manufacturers Association, Dezember 1989).
Bild 3 'Distributed Security Model'
Das Modell unterscheidet drei "Komponenten": Die Benutzer, die Applikationen und die Applikationsdaten. Es zeigt die möglichen Interaktionen in einem sicheren verteilten System, die allesamt durch Sicherheitsservices vermittelt werden müssen. Die möglichen Interaktionen mit den entsprechenden Sicherheitsmassnahmen sind:
(1) Benutzer zu Applikation
Wenn ein Benutzer auf eine Applikation zugreifen will, so stellt zuerst der Authentikationsservice seine Identität fest und prüft, ob es sich um einen gültigen Systembenutzer handelt (Authentikation des Benutzers).
Anschliessend prüft der Access Control Service, ob der Benutzer die angeforderte Applikation benutzen darf (Technische Zugriffskontrolle für Systemressourcen).
(2) Applikation zu Applikation
Eine Applikation kommuniziert mit einer anderen Applikation entweder auf demselben System (Interaktion (2a)), oder, via ein Netzwerk, auf einem anderen System (Interaktion (2b)). Die aufrufende Applikation (der Client) unterscheidet nicht zwischen den beiden Fällen.
Wird diese Programm-zu-Programm Kommunikation via ein dazwischenliegendes Netzwerk aufgebaut, so übermittelt der Authentikationsservice die Identität des Benutzers und des Client Programmes sowie allenfalls zusätzliche Benutzerattribute an die Server Plattform (Weitervererbung der Authentikation).
Anschliessend prüft der Access Control Service, ob die angeforderte Applikation benutzt werden darf (Technische Zugriffskontrolle für Systemressourcen).
Weil in diesem Modell keine Sicherheitsanforderungen an das dazwischenliegende Netzwerk gestellt werden, wird die Kommunikation mit geeigneten Mitteln geschützt (Data Exchange Security).
(3) Applikation zu Applikationsdaten
Wenn eine Applikation auf eine Datenbank zugreift, wird die Berechtigung durch den Access Control Service geprüft. Diese Prüfung basiert auf der Identität des Benutzers oder des aufrufenden Programmes (Technische Zugriffskontrolle für Systemressourcen).
Anschliessend prüft der Access Control Service, ob ein bestimmter Benutzer auf bestimmte Daten in Abhängigkeit des Datenwertes zugreifen darf (Applikatorische Zugriffskontrolle für Business Services).
Theorie und Praxis
Dem Modell liegt eine idealisierte Sicht zugrunde, die selbstverständlich nicht in allen Punkten der äusserst komplexen Realität gerecht werden kann.
Um einen durchgängig hohen Sicherheitsgrad erreichen zu können, müssen dem Modell entsprechend Applikationen jeglicher Art gleichermassen durch die Sicherheitsservices geschützt werden.
In einer realen Umgebung ist dies jedoch technisch nicht möglich, wobei insbesondere für Infrastrukturkomponenten (z.B. verteilte Datenbanksysteme, System Management Services u.a.) fallweise die optimale Lösung gesucht werden muss.
Trusted Computing Base
Die Sicherheitsservices basieren auf einer vertrauenswürdigen Zone des Systems (der sogenannten Trusted Computing Base, TCB). Spezielle Prüfmechanismen auf dem System stellen die Integrität der TCB sicher und verhindern Manipulationen. Die TCB kann einer eingehenden Sicherheitsevaluation unterzogen und entsprechend in eine Sicherheits-Funktionalitätsklasse gemäss Orange Book oder ITSEC eingeteilt werden.
Die Benutzer, die Applikationen ausserhalb der TCB, die Applikationsdaten sowie das Netzwerk werden als nicht vertrauenswürdig angenommen.
Programm-zu-Programm Kommunikation
Die plattformübergreifende Kommunikation findet zwischen zwei Applikationen statt (Program-to-Program Communication, PPC), die ein dazwischenliegendes Netzwerk als Transportmittel benützen. Die sichere Kommunikation wird durch die Data Exchange Security Services gewährleistet.
Die Kommunikationssicherung erfolgt für die Applikation transparent, wenn die Sicherheitsservices in die Systemumgebung (z.B. in den RPC-stub bei OSF DCE) integriert sind.
Integrierte Sicherheit
Jegliche Interaktion ist nur via die Trusted Computing Base respektive die Sicherheitsservices möglich. Es ist deshalb anzustreben, die TCB möglichst nahe am Betriebssystem anzusiedeln.
Application Programming Interfaces
Zwischen den Applikationen und den Sicherheitsservices liegen Schnittstellen, die je nach Art der gewünschten Interaktion aufzurufen sind.
Im vorhergehenden Kapitel wurde modellhaft vorgestellt, wie die Sicherheitsservices bei den Interaktionen zwischen Benutzern, Applikationen und Applikationsdaten involviert sind. Aus dieser Darstellung wird klar, welche Schnittstellen zwischen den Applikationen und den Sicherheitsservices bei den möglichen Interaktionen relevant sind.
In einer idealen Welt standardisierter, generell verfügbarer und umfassender Sicherheitsprodukte würden die Sicherheitsservices von der Trusted Computing Base, völlig transparent für die Applikationen, abgedeckt. Eine solche transparente Sicherheit ist für die nächsten Jahre allerdings nicht zu erwarten. Es wird deshalb notwendig sein, die Sicherheitsservices teilweise aus den Applikationen heraus aufzurufen.
(1) Benutzer zu Applikation
Der Authentikationsservice auf der Client-Plattform authentisiert den Benutzer. Die Identität des Benutzers (evtl. zusammen mit anderen benutzerspezifischen Daten) wird an den Access Control Service übergeben und dieser entscheidet, ob der Benutzer die gewünschte Applikation benutzen darf. Die Identität des Benutzers kann daraufhin auch an die Applikation selber weitergegeben werden.
Die Benutzerdaten werden der Applikation über eine Schnittstelle zur Verfügung gestellt. Der Aufruf des Authentikationsservices muss ausserhalb der Applikation durch die Client-Plattform erfolgen.
(2) Applikation zu Applikation
Eine Applikation kann als Client eine Serverapplikation aufrufen, die sich entweder auf dem gleichen oder auf einem entfernten System befindet.
Beim Erstellen einer solchen Kommunikationsverbindung müssen die Sicherheitsservices verschiedene Funktionen wahrnehmen (Weitervererbung der Authentikation, Data Exchange Security, Access Control für das aufgerufene Server-Programm).
Die Sicherheitsservices werden entweder für die Applikation transparent durch die Client-Plattform aufgerufen (z.B. durch den RPC-stub bei OSF DCE), oder sie werden explizit von der Applikation über eine Schnittstelle angesprochen.
In diesem Bereich der plattformübergreifenden Sicherheitsservices ist die Standardisierungsarbeit heute schon recht weit fortgeschritten. Besonders hervorzuheben ist dabei das GSS-API (Generic Security Service - Application Programming Interface (Definition: Internet RFC 1508)). Es definiert eine Anzahl Schnittstellen, über die verschiedene sich heute in der Entwicklung befindliche oder verfügbare Sicherheitsmechanismen (z.B. Kerberos V5, OSF DCE Security, CCITT X.509) angesprochen werden können.
(3) Applikation zu Applikationsdaten
Der Datenzugriff wird durch den lokalen Access Control Service kontrolliert, der anhand von Benutzer- und/oder Applikationsattributen die Berechtigung prüft.
Der lokale Service wird entweder für die Applikation transparent durch das lokale System aufgerufen, oder explizit von der Applikation über eine Schnittstelle angesprochen.
Während wir uns in den vorigen Kapiteln mit Umfeld und Begriffsbildung der Sicherheitsproblematik in vernetzten Systemen beschäftigt haben, versuchen wir nun eine schrittweise Konkretisierung und Annäherung an Lösungen, mit denen die Sicherheitsanforderungen moderner Informationsverarbeitung abgedeckt werden können.
Die Strukturierung der Lösungsansätze in Strategie und Design und - darauf aufbauend - personen-, ressourcen- und werteorientierte Sicherheit kann verstanden werden als:
Allesumfassende Lösungen gibt es (noch) nicht
Produkte, die alle Sicherheitsanforderungen einer Client / Server Anwendung abdecken, fehlen weitgehend oder sind noch nicht ausgereift.
Im allgemeinen herrscht die nüchterne Einschätzung vor, dass plattformübergreifende Konzepte in vernetzten Umgebungen schwieriger zu realisieren sind als angenommen. Insbesondere dort, wo Access Control Funktionen mit Anforderungen von Profilvererbung verbunden sind, lassen sich nur beschränkte Projektfortschritte feststellen.
Unserer Meinung sind deshalb die Anforderungen an Identifikation/Authentikation, Access Control, Data Exchange Security und Audit bis auf weiteres getrennt zu realisieren.
Tools müssen ineinandergreifen
Mischlösungen aus verschiedenen (Hard- und Software-) Produkten sind derzeit die einzige Möglichkeit, die Sicherheitsproblematik in der Client / Server Umgebung in den Griff zu bekommen. Solche Lösungen sind weder ganz ohne eigene Aufwände noch ausschliesslich innerhalb der Applikation realisierbar. Sie benötigen als Basis weiterhin systemnahe (proprietäre) Sicherheitsfunktionalität.
Eigenentwicklungen sind weiterhin notwendig
Begrenzte Eigenentwicklungen sind unter Umständen notwendig und sinnvoll, besonders dort wo die betrieblichen Anforderungen hoch sind, jedoch noch einige Jahre keine Aussicht besteht, entsprechende Produkte einkaufen zu können. Dies trifft etwa auf die Access Control, im besonderen auf die applikatorische (objektorientierte, regelbasierte) Zugriffskontrolle zu.
Bei Eigenentwicklungen empfiehlt sich die Zusammenarbeit mit dem Betriebssystemanbieter
Wenn immer möglich empfehlen wir eine Zusammenarbeit mit den Herstellern der Betriebssysteme. Im heiklen Bereich der Sicherheit stösst eine Implementierung von Konzepten, die in der Theorie unabhängig von Protokollen und Betriebssystemen sind, rasch an technische Grenzen, die ohne das Wissen des Betriebssystemherstellers kaum zu überwinden sind.
Dezentrale Rechteverwaltung ist notwendig
Im kommerziellen Bereich eingesetzte Sicherheitsprodukte erzwingen keine Sicherheit, sondern müssen konfiguriert und administriert werden. Die bis jetzt zentral geleistete Verwaltung der Benutzerrechte wird den komplexen Verhältnissen in einer verteilten Umgebung nicht mehr gerecht.
Kompatibilität mit GSS-API ist wichtig (als Zukunftsinvestition)
Es kann der Client / Server Applikation nicht zugemutet werden, auf die Sicherheitsfunktionalität in Betriebssystem oder (Eigen-)Produkten direkt zuzugreifen. Aus der Sicht der Applikation ist es vielmehr wünschenswert, dazu API-Funktionen zur Verfügung gestellt zu bekommen, die auf allen Plattformen gleich sind. Die Applikation soll sich nicht darum kümmern müssen, auf welche Art und Weise die API-Calls von der darunter liegenden Sicherheitsfunktionalität abgearbeitet werden.
Um diese Forderung der Anwender zu erfüllen, wird international an einem standardisierten Sicherheits-API gearbeitet (GSS-API). Obwohl die Arbeiten weit fortgeschritten sind, wird es noch einige Jahre dauern, bis Produkte auf den Markt kommen, die ein generalisiertes API unterstützen. Zu gross scheint die Konkurrenz der Hersteller, zu komplex die technische Realisierung der standardisierten Vorgabe.
Dennoch sollte bereits jetzt im Sinn einer Zukunftsinvestition beim Einsatz eines Produktes darauf geachtet werden, ob sich die Hersteller zur Unterstützung des GSS-API verpflichtet haben.
Sicherheitsstrategien müssen sich ergänzen
Vernetzte Systeme sind nicht nur in technischer, sondern auch in organisatorischer Hinsicht derart komplex, dass einseitige Strategien die Sicherheitsprobleme nicht lösen können. Ein Betrieb, der in erster Linie seine Hardware vor unautorisiertem Zugriff schützt, wiegt sich in trügerischer Sicherheit. Wirkungsvolle Angreifer machen sich die Eigenschaften der modernen Informationsverarbeitung wie etwa die hohe Interdependenz der Systeme und Verarbeitungsabläufe zunutze und entfalten ihre zerstörerischen Aktivitäten innerhalb der Applikationen oder zumindest an den zahlreichen Uebergängen zwischen der Welt der Bits und Bytes und der Welt der businessorientierten Objekte.
Ebenso falsch wäre auch eine einseitige Ausrichtung auf applikatorische Sicherheitsmassnahmen. Wenn etwa ein Datenspeicher ganz einfach weggetragen werden kann, schützt auch die raffinierteste Kommunikationsverschlüsselung nicht vor dem Vertraulichkeitsverlust der Daten.
Dies bedeutet, dass für jeden Spieler im Spiel eine eigene Sicherheitsstrategie entworfen und mit anderen Strategien kombiniert werden muss. Organisatorische, technische und applikatorische Massnahmen sollen sich ergänzen. Awarenessprogramme, Bewachungsdienste, der Einschluss wichtiger Maschinen und Leitungen sind ebenso wichtig wie Regulative und Arbeitsanweisungen, der Einsatz von Kryptoboxen oder Netzwerkfiltern und schliesslich die Implementation einer kompletten applikatorischen Sicherheitsarchitektur.
Aus der Sicht des Informationsschutzes spielt es eine grosse Rolle, auf welchen Plattformen Funktionen und Daten plaziert werden und in welchen Ausprägungen die Verarbeitungsprozesse ablaufen; oder, anders ausgedrückt, auf welche Art und Weise Akteure und Objekte des Informationsverarbeitungsprozesses im System verteilt sind.
Diesbezügliche Designüberlegungen können günstige Bedingungen für eine wirkungsvolle Anwendung des Informationsschutzes schaffen und die notwendigen strategischen Entscheide bezüglich der Wahl der richtigen Mittel erleichtern.
Die verschiedenen Systemplattformen und Betriebsarten der Rechner in vernetzten Systemen schaffen unterschiedliche Voraussetzungen für den Informationsschutz. Speziell der Personal Computer als Arbeitsplatzstation ist ohne Zusatzausrüstung verwundbar:
Server und deren direkt angeschlossene Datenstationen können entfernt von den Benutzern in Räumen mit erhöhter Zutrittskontrolle plaziert werden.
Die meisten Client / Server Netze bieten eine gute logische Trennung zwischen Client und Server. Die Möglichkeiten des Zugriffsschutzes für Daten und Prozesse auf dem Server sind im allgemeinen ausreichend. Dies schützt insbesondere die Prozesse vor Manipulationen.
Wir empfehlen, dass Anwendungen so konzipiert werden, dass Funktionen und Daten entsprechend ihrer Sicherheitsklassifikation auf Arbeitsstation-, Server-, respektive Grosscomputer-Plattform plaziert werden.
Client / Server Computing existiert in verschiedenen Ausprägungen. Ein Blick auf einige wesentliche Merkmale der verschiedenen Techniken dient dem besseren Verständnis der Probleme des Informationsschutzes betrachtet werden.
Die im folgenden beschriebenen Prozessmodelle können in beliebigen Kombinationen eingesetzt werden. Aus der Sicht des Informationsschutzes kann jede Art der Verbindung für sich betrachtet werden.
Bild 4 'Client / Server Prozessmodelle'
Distributed Presentation
Im Modell einer verteilten Präsentation bleiben Geschäftslogik und Daten zusammen und sind nicht im Netz verteilt. Die Auslagerung der Präsentation in die Datenstationen schafft für den Informationsschutz keine zusätzlichen Risiken gegenüber dem Einsatz nicht programmierbarer Terminals. Der Zugriff auf die Systemressourcen und die Datenhaltung entsprechen konzeptionell dem Host-zentrischen Modell. Die von den proprietären Mainframes bekannten Identifikations- und Zugriffskontrollsysteme genügen den Anfoderungen.
Bild 5 'Distributed Presentation'
Distributed Data
In diesem Modell sind die Daten von der Geschäfts- und Präsentationslogik getrennt. Es besteht eine verwundbare Verbindung zwischen dem Client und dem Datenserver: der Datenserver muss Identität und Berechtigungen des Client verlässlich feststellen können. In diesem Modell ist der Client berechtigt für den Zugriff auf bestimmte Daten. Die Verwendung der Daten wird durch die Prozesse im Client bestimmt. Ein verlässlicher Schutz gegen Missbrauch im Rahmen des autorisierten Datenzugriffes kann deshalb davon abhängen, wie gut die Prozesse im Client gegen Manipulationen abgesichert sind, also von der Qualität des Zugriffskontrollsystems des Requesters. Für den Zugriff zwischen entsprechend gesicherten Servern ist diese Voraussetzung normalerweise erfüllt.
Bild 6 'Distributed Data Prozessmodell'
Distributed Function
Hier werden Teile der Geschäftslogik, also der eigentlichen Anwendung, als Server Prozesse implementiert. Es besteht eine verwundbare Verbindung zwischen den Client und Server Prozessen, die speziell gesichert werden muss, was, wie im vorigen Modell, eine Prüfung der Identität des Client und seiner Berechtigungen verlangt.
Das Distributed Function Prozessmodell hat folgende Vorteile für den Informationsschutz:
Das Distributed Function Prozessmodell bietet damit einen guten Schutz gegen unberechtigten Zugriff und Manipulationen. Es verlangt aber eine entsprechende Planung und Strukturierung der Anwendungen. Der Umbau bereits bestehender, nicht entsprechend konzipierter Anwendungen ist aufwendig.
Bild 7 'Distributed Function Prozessmodell'
Kombination von Prozessmodellen
Bei sorgfältiger Planung und Konzeption können die verschiedenen Prozessmodelle miteinander kombiniert und so deren spezielle Vorteile in bezug auf die Sicherheitsanforderungen genutzt werden.
Das folgende Beispiel kombiniert die Modelle 'Distributed Function' und 'Distributed Data':
Bild 8 'Kombinierte Prozessmodelle'
Es versteht sich von selbst, dass jegliche Sicherheitsmassnahmen letzlich nur so gut sind, wie das Personal, das sie konzipiert, implementiert und anwendet. Diesbezüglich ändert sich in vernetzten Systemen gegenüber früher nur wenig, mit dem Unterschied allerdings, dass die Anforderungen deutlich gestiegen sind. Es ist deshalb ausserordentlich wichtig, dass das Management die Sicherheitsverantwortung der Benutzer des unternehmensweiten Netzwerkes definiert, unterstützt und über deren Einhaltung wacht.
Im folgenden zählen wir einige Massnahmen auf, die das Sicherheitsbewusstsein im Unternehmen stärken und verbessern:
Technische Informatiksicherheit bedeutet unserer Meinung nach eine auf den Schutz der an der Informationsverarbeitung beteiligten Komponenten ausgerichtete Sicherheit. Aus der Sicht des Unternehmens stellen diese Komponenten Ressourcen dar, die zur Erreichung der Geschäftsziele benötigt werden, die aber von den Geschäftsabläufen getrennt sind, und für die Benutzer weitgehend unsichtbare Grössen darstellen.
In der 'alten' Umgebung konnten die informationsverarbeitenden Prozesse, die die technischen Ressourcen nutzten, noch weitgehend selber als solche betrachtet werden, besonders da sie 'nahe an der Maschine' programmiert waren. In der 'neuen' Umgebung lösen sie sich von dieser Grundlage und bilden eine eigene, 'businessorientierte' Welt. Da sie sich von ihren 'technischen Müttern' getrennt haben, neigen die heutigen Anwendungen dazu, alles selbstständig zu regeln, das heisst also auch die Sicherheit des Stoffes, mit dem sie umgehen, - der Informationen - selbstständig zu garantieren. Bei dieser Arbeit sind sie allerdings auf eine technische Sicherheitsinfrastruktur nach wie vor angewiesen, möchten aber deren Dienste soweit wie möglich in transparenter oder abstrahierter Form nutzen.
Die ressourcenorientierte (technische) Sicherheit muss auf diese Herausforderung mit einem Basisangebot antworten, das kaum mehr Rücksicht auf spezielle Risiken nehmen kann, sondern einen sogenannten 'standard of due care' garantiert, d.h. eine über das gesamte unternehmensweite Netzwerk und alle daran angeschlossenen Komponenten sich erstreckende Basissicherheit.
In der 'neuen' gegenüber Geschäftspartnern und zunehmend auch gegenüber der Öffentlichkeit relativ offenen Umgebung kann ein solches Basisangebot nur in Kooperation mit andern aufrechterhalten werden. Geeignete Massnahmen hierzu sind:
Die heutigen Netzwerke streuen die Daten (und insbesondere die Authentikationsinformationen) aus Sicherheitssicht zu weitläufig und erlauben die Verbindungsaufnahme zwischen beinahe allen Netzknoten. Eine der Konsequenzen davon ist, dass die früher als selbstverständlich betrachtete Trennung zwischen Entwicklungs-, Test- und Produktionssystemen schwierig durchzusetzen ist und dementsprechend vernachlässigt wird.
Noch schlimmer scheint, dass aufgrund der durchgängigen Verfügbarkeit aller Informationen Oeffnungen gegenüber externen Netzen selbst an den Rändern des unternehmensweiten Netzwerkes den Zugriff auf alle Ressourcen gestatten. Einen zu Recht besonders zweifelhaften Ruf geniesst in dieser Hinsicht das weltweite Internet mit seiner in die tausenden gehenden Hackerpopulation.
Weiter weist das unternehmensweite Netzwerk unter Umständen eine derartige Grösse auf und umfasst neben den um den früheren zentralen Grosscomputer gruppierten lokalen Netzen noch zahlreiche Netze neu assoziierter Firmen, dass es zunehmend unkontrollierbar scheint, und in der Konsequenz das Vertrauen in seine Verfügbarkeit und Sicherheit abnimmt.
Die Gegenstrategie besteht in der Unterteilung des Netzwerkes in Teilsysteme, denen man vertraut und die man selbst kontrollieren kann, und Teilsysteme, gegen die man sich abschottet. Eine weitere Abwehrmassnahme ist das Schaffen sicherer Kanäle (z.B. durch die Anwendung kryptografischer Methoden).
Packet Filter und Firewalls
Bild 9 'Beispiel eines Firewall-Systemes'
Das Prinzip der Netzwerkunterteilung ist einfach: zur Abschottung des internen und mit betrieblichen Massnahmen kontrollierten Netzes wird am Verbindungspunkt zum externen Netz eine Sicherheitsbarriere errichtet. Jeglicher Verkehr zwischen den beiden Netzen muss durch einen von autorisierten Systemverwaltern kontrollierten Rechner gezwungen werden und wird nur unter bestimmten, in einem Sicherheitskonzept festgelegten Bedingungen durchgelassen. Dabei gilt: je mehr Informationen dem 'Pförtner' zur Verfügung stehen, desto genauer, angemessener und dadurch auch sicherer sind seine Entscheidungen.
Unterschieden wird in der Anwendung zwischen den einfacheren Packet Filtern und komplexen Firewall-Systemen. Packet Filter sind Hubs und Routers, die den Datenstrom aufgrund von Informationen auf der Netz- oder IP-Schicht (d.h. auf OSI-Layer 3) blockieren können. Firewalls dagegen treffen ihre Entscheidungen aufgrund von Informationen auf der Netz- bis zur Applikationsebene (d.h. bis OSI-Layer 7) und sind so konfiguriert, dass sie den Endpunkt aller Verbindungen bilden. Der Datenstrom endet also auf dem Rechner, der die Daten entsprechend seiner Spezifikationen authentisiert und bei positiver Prüfung einer neu aufgebauten Verbindung zur Verfügung stellt.
Implementationen von Firewallsoftware sind entsprechend dem Grad ihrer Komplexität frei erhältlich oder sehr kostengünstig bis zu ausgesprochen teuer vor allem dann, wenn sie mehrere Routers, Gateways und ein isoliertes Teilnetz benötigen.
Der Nutzen eines Firewalls kann durch die Verbindung mit einem strengen Authentikationsverfahren (d.h. einem Verfahren, das Passwörter mit einem Challenge-Response-Protokoll 'verschlüsselt' oder mit dynamischen Passcodes ergänzt) wesentlich vergrössert werden, weil dann die Passwörter nicht mehr im Klartext über das externe (wie das interne) Netzwerk gehen, respektive deren Kenntnis allein zu einem Passieren des Firewallpförtners nicht ausreicht.
Sichere Kanäle
Einige Verbindungen des unternehmensweiten Netzwerkes sind unter Umständen speziell verletzbar. Es ist deshalb sinnvoll, sich anfänglich auf diese zu konzentrieren, weil punktuelle Gegenmassnahmen hier das Gesamtrisiko beträchtlich reduzieren.
Typische kommerzielle Beispiele sind Verbindungen für den Zahlungsverkehr oder den Transport von Personaldaten. Finanzinstitute setzen zur Begrenzung deren spezieller Risiken bereits seit gut einem Jahrzehnt kryptografische Verfahren ein. Gut bekannt sind etwa die PIN-Applikationen bei den Bancomaten. In Zahlungssystemen bildet dabei die Forderung nach Nichtwiderrufbarkeit einer Zahlung oder Gutschrift eine besonders hohe Hürde, die nur mit sogenannten asymmetrischen Verfahren in der Anwendung selber gelöst werden kann (siehe auch im Anhang unter dem Stichwort Kryptologie).
Kritische Verbindungen oder sensitive LAN und WAN Segmente können mit kryptografischer Hardware geschützt werden. Obwohl die hohen Kosten gewöhnlich gegen den flächendeckenden Einsatz von Kryptoboxen sprechen, kann deren Anwendung an kritischen Punkten des Netzwerkes sehr kosteneffizient sein.
Gegenwärtig befindet sich eine neue Generation von Hardwareverschlüsslern im Rollout. Während die früheren Geräte auf Linkebene verschlüsselten, kryptografieren die neuen auch auf dem Netzwerk-Layer und automatisieren Schlüsselverwaltung und Konfigurationsmanagement. Zumindest mittelfristig scheint deshalb ein flächendeckender Einsatz im LAN-Bereich nicht mehr ausgeschlossen.
In einem Sicherheitsdispositiv nicht vergessen gehen darf die Anwendung 'handfester' physischer Massnahmen. Eine speziell verwundbare Komponente des unternehmensweiten Netzwerkes ist der die lokalen Netzwerke verbindende Backbone, wo sich alle Daten der einzelnen LANs sammeln. In gesicherten Trunks verlegte fiber-optische Kabel sind dabei erheblich weniger verletzbar als Ethernet-Kabel und besitzen den zusätzlichen Vorteil eines Widerstandes gegen elektromagnetische Störungen.
Sicherheitsmassnahmen im Netzwerk dienen der Abschottung gegenüber unsicheren Netzen und der Kanalisierung und Kontrolle des Datenstromes. Solche Massnahmen mindern zwar die Risiken, können sie aber nicht restlos beseitigen. Die heutigen Netzwerke sind ihrer Aufgabe entsprechend auf schnelle und problemlos aufbaubare, sogar dynamische Verbindungen ausgerichtet. Der Aufbau widerrechtlicher oder fahrlässiger Verbindungen ist also relativ einfach und wird auch bei effizienten Kontrollmassnahmen erst nach einer gewissen Zeitspanne entdeckt. Das Netzwerk als Komponente im vernetzten System sollte auch nach konsequenter Durchsetzung der vorgestellten Sicherheitsmassnahmen als tendenziell offen und unsicher betrachtet werden. Daraus folgt, dass sich die daran angeschlossenen Knoten oder Plattformen zusätzlich (selber) schützen müssen.
Grosscomputer Systeme
Der (zentrale) Grosscomputer wird auch in den nächsten Jahren der zunehmend dezentralen Datenverarbeitung eine gewichtige Rolle (als Massendatenspeicher und -verarbeiter) spielen. Er muss deshalb als integriertes Mitglied des vernetzten Systems betrachtet werden.
Dadurch wird der Grosscomputer einerseits neuen, im Vergleich zu früher erhöhten Risiken ausgesetzt. Andererseits eröffnen sich interessante Möglichkeiten, um die auf dem Grosscomputer verfügbaren Sicherheitseinrichtungen für eine sichere Client / Server-Verarbeitung nutzen zu können.
Der Grosscomputer bietet, da er in der Regel in eigentlichen Rechenzentren eingeschlossen ist, eine hohe physische Sicherheit und verfügt über praktisch erprobte, robuste und sichere Betriebssysteme. Damit verfügt er immer noch über einen höheren Grad an Basissicherheit als jedes dezentrale System. Dennoch erfordert die sichere Integration von Client / Server-Komponenten (wie z.B. APPC oder RPC) den optimalen Einsatz der vorhandenen Sicherheitseinrichtungen (wie z.B. ACF2 oder RACF) und die enge (und aufwendige) Zusammenarbeit der Sicherheitsexperten mit Anwendern, Entwicklern und der System Design Organisation.
UNIX Systeme
Im vernetzten System finden sich komplette UNIX-LANs als auch UNIX-Server im LAN-Verbund mit Arbeitsstationen, die ein anderes Betriebssystem geladen haben.
UNIX Systeme besitzen eine ins Betriebssystem eingebaute Basissicherheit. Je nach UNIX-Variante baut darauf ein unterschiedlich ausgeprägtes Sicherheitssystem auf.
Ein gut ausgebautes UNIX-Sicherheitssystem besitzt folgende Funktionalität:
Das Definieren von Richtlinien und Empfehlungen ist der erste Schritt. Diese müssen nun sorgfältig und planmässig in ein organisatorisches Konzept und Verfahren umgesetzt werden. Prinzipiell kann aber die Sicherheit der UNIX-Systeme, obwohl im 'Rohzustand' ungenügend, durch eine optimale Konfiguration und begleitet von dem Einspielen der neuesten Patches, welche bekannte Schwächen beheben, auf ein befriedigendes Niveau gehoben werden.
PC Systeme
Aufgrund dem Fehlen von ins Betriebssystem eingebauten Sicherheitsfunktionen bleiben PC Systeme ein empfindliches Sicherheitsrisiko. Dieses kann durch physische Massnahmen wie Einschluss der Geräte oder Versiegelung der Schnittstellen etwas entschärft werden.
Auf dem Markt sind zudem eine Reihe von Paketen erhältlich, die mehr oder weniger ausgereifte Sicherheitsfunktionalität anbieten. Sie haben allerdings professionellen Attacken bis jetzt kaum standgehalten. Dies könnte sich vielleicht in Kürze ändern, weil die Anbieter durch die erhöhte Nachfrage nach Sicherheit im Bereich der mobilen Arbeitsgeräte herausgefordert sind.
Mit einer Kombination aus taktischen und organisatorischen Massnahmen, lässt sich ein akzeptables Niveau an Informatiksicherheit in einer vernetzten Umgebung erreichen.
Aus der Sicht der Anwendung schliesslich, für die die Befreiung von der Rücksichtnahme auf die technischen Plattformen der grösste Fortschritt der verteilten Informationsverarbeitung ist, ist ein derartiges Sicherheitsdispositiv ungenügend. Es interessiert die Anwendung nicht, ob die Daten auf diesem Server oder in jenem Netzsegment sicher sind oder nicht. Sie möchte vielmehr im Verlauf des Geschäftsvorganges auf die Integrität von ihr als wichtig empfundener Daten vertrauen können, und sie möchte Geschäftsfunktionen voneinander trennen, so dass die Inhaber einer Funktion keinen Zugriff auf Geschäftsinformationen und -prozesse der Inhaber anderer Funktionen haben.
Zur Erfüllung solcher Anforderungen kommen nur Lösungen in Frage, die wie die Anwendung selber über verteilte Strukturen und an der Geschäftslogik ausgerichtet eingreifen.
Dabei benötigen folgende Punkte besondere Beachtung:
Qualitative Differenzierung
Die verteilte Verarbeitung begünstigt eine Sicht, die die Schutzanforderungen bezüglich einer Information nicht mehr von deren Standort oder deren technischem Charakter ableitet, sondern an deren Wert innerhalb eines Geschäftsablaufes festmacht. Um werteorientierten Anforderungen genügen zu können, müssen Werkzeuge zur Verfügung gestellt werden, mit deren Hilfe die Anwendungen ihre Informationen unabhängig von der technischen Implementierung entsprechend der Anwendungslogik schützen können.
Im folgenden versuchen wir einige neuere Ansätze aufzuzeigen, wie diese für die verteilte Verarbeitung in vernetzten Systemen typischen Probleme angegangen werden können. Bezeichnenderweise nähern sich alle Lösungen schrittweise der in Kapitel 4 dargelegten modellhaften Vorstellung der Funktionsabläufe, bekunden aber mit der Einbindung eines generalisierten APIs etliche Mühe.
Dynamische Verbindungen
Die Verbindungen zwischen den Ressourcen in vernetzten Systemen sind dynamisch in Abhängigkeit der verwendeten Funktionen und Daten und deren Plazierung im Netz. In komplexen Netzen kann nur die transparente Sicht des Client für alle vernetzten Ressourcen als einheitliches System den Anforderungen genügen.
Interoperabilität
Sicherheitsservices für heterogene Systemplattformen müssen getrennt von den Anwendungssystemen implementiert werden. Traditionelle Massnahmen können das Fehlen plattformbergreifender Mechanismen nicht überbrücken. Hier ist die Informatikbranche gefordert, systemübergreifende Register und verträgliche Mechanismen auf den unterschiedlichen Plattformen zur Verfügung zu stellen.
Der Authentikations-Service im vernetzten System soll dem Anwender ein einfaches, einmaliges, benutzerfreundliches und plattformübergreifendes Anmelden ermöglichen. Er soll mit möglichst einem Log-on alle für seine Arbeit nötigen Ressourcen zur Verfügung gestellt bekommen.
Um dies zu gewährleisten, ist es wichtig, zwischen zwei Formen von Anforderungen zu unterscheiden: Dem Single Log-on und der Client / Server Authentikation
Single Log-on
Der Anwender wird durch einmaliges 'Einloggen' an einem Log-on-Server angemeldet. Anschliessend wird die Authentikationsinformation aufgrund eines Ressourcenprofils an mehrere Zielsysteme (z.B. LAN Server, Mail Server, Mainframe) weitervererbt (i.e. Sign On).
Erreicht wird dadurch ein einfacheres und schnelleres Arbeiten, Effizienz und Motiviationssteigerung des Benutzers und - dank der Verwaltung eines einzigen Passwortes - höhere Sicherheit.
Bei gleichzeitiger Verwendung eines Tokens (z.B. Chipkarte oder Codegenerator) kann die Sicherheit der Authentisierung darüber hinaus noch wesentlich gesteigert werden.
Client / Server Authentication
Bei dieser Form von Sign On wird die Authentikationsinformation nicht an Ressourcen weitervererbt, sondern der Applikation übergeben. Der Client-Applikationsteil authentisiert sich gegenüber dem Server-Applikationsteil und umgekehrt. Um diese Programm zu Programm Authentikation durchführen zu können, erhält die Anwendung von einem Log-on-Server 'Service-Tickets', die über definierte Schnittstellen verwaltet werden können. Der Authentisierungsprozess läuft dabei für den Benutzer transparent und automatisch im Hintergrund ab.
Ablauf in vier Schritten
Bild 10 'Beispiel einer Single Sign On Lösung'
Der Authentikationsvorgang im vernetzten System - für eine Umschreibung wird oft Single Sign On verwendet - lässt sich zum Beispiel in vier Schritte unterteilen:
1. Schritt: (Start der lokalen Arbeitsstation)
Die Arbeitsstation wird aufgestartet und es erscheint die gewohnte Benutzeroberfläche mit dem Single Sign-on-Icon, sowie den lokal verfügbaren Ressourcen.
2. Schritt: (Benutzer-Log-on)
Nach erfolgtem Doppelklick des Single Sign-on-Icons erscheint ein Fenster mit der Aufforderung zur Eingabe von UID und Passwort (ergänzt durch die allfällige Eingabe eines Codes, falls ein Token verwendet wird).
Nach erfolgter Eingabe wird vom Log-on-Server ein Initial-Ticket generiert und der Arbeitsstation übergeben. Dieses Ticket berechtigt zur Benutzung des Netzwerkes und ist z.B. einen Tag lang gültig.
3. Schritt: (Weitervererbung Single Log-on)
Dieser Schritt wird vom Single Sign-on ausgeführt und erfolgt für den Benutzer transparent.
Die Arbeitsstation erhält vom Log-on-Server durch Vorweisen des Initial-Ticket für jeden Single Log-on ein Pass-Ticket (gültig z.B.1 Sekunde), das sie für jede im Ressourcenprofil des Benutzers definierte Anmeldung benötigt.
Als Resultat erhält der Benutzer auf seinem Bildschirm in Form von Icons die jeweiligen für ihn verfügbaren Anwendungen. Das mögen eine Reihe von traditionellen Hostsessions oder aber eigentliche Client / Server Anwendungen sein.
4. Schritt: (Client / Server Authentikation)
Im letzten Schritt werden zwischen den Programmen Meldungen ausgetauscht. Für jede Client / Server Beziehung löst der Sender beim Log-on-Server durch Vorweisen des Initial-Tickets ein Service-Ticket. Anhand dieses Service-Tickets kann der Empfänger den Absender einer Nachricht zweifelsfrei identifizieren und seine Authentizität feststellen.
Bei einer derart komplexen Anforderung, wie sie der Single Sign-on darstellt, gibt es in der Praxis eine ganze Reihe von Klippen zu umschiffen. Im folgenden versuchen wir die wichtigsten kurz zu beleuchten:
Die Wahl der kryptografischen Verfahren setzt enge Grenzen
Der Single Sign-on ist in sich selber eine Client / Server Anwendung. Der Benutzer authentisiert sich gegenüber einem im Netzwerk positionierten Log-on-Server. Dieser Log-on-Server wickelt, in Zusammenarbeit mit einem auf jeder Plattform installierten Client-Code, die Weitervererbung des Log-on ab. Die Single Sign-on Infrastruktur besteht dabei im wesentlichen aus einem kryptografischen Schlüsselverteilungs-System, das durch den zentralen Log-on-Server unterhalten wird. Dieser wiederum kann, obwohl er physisch aus mehreren Maschinen bestehen kann, von einer zentralen Stelle aus administriert werden.
Es ist möglich, auf applikatorischer Ebene diese kryptografische Infrastruktur auch für andere Sicherheitsanwendungen einzusetzen.Für das Gelingen entscheidend ist jedenfalls die Art und Weise der kryptografischen Verfahren und vor allem deren Umsetzung in der Schlüsselverwaltung. Derzeit ist keines der auf dem Markt angebotenen Single Sign-on Produkte bezüglich Verfahren und Umsetzung mit einem anderen kompatibel. Zudem setzt die Wahl des kryptografischen Verfahrens der physischen Platzierung der Log-on-Server, die für die Performance des Single Sign-on Systems ausschlaggebend ist, enge Grenzen.
Transparenz ist bei Standardanwendungen fraglich
Um eine für den Benutzer und die Anwendung grösstmögliche Transparenz zu erreichen ist ein Einbau des Single Sign-on Verfahrens in die Kommunikations-Middelware unter Umständen (d.h. abhängig vom gewählten Kommunikationsparadigma) wünschenswert. Besonders schwierig ist dies allerdings bei Standardanwendungen, die eigene Log-on- und Kommunikationsverfahren einsetzen (z.B. Lotus Notes). Die fortgeschrittenen Single Sign-on Produkte stellen solchen Anwendungen zwar die zur Einbettung in den Single Sign-on notwendigen Schnittstellen (basierend auf dem GSS-API) zur Verfügung, diese müssen aber von der Applikation angesprochen werden.
Nicht alle Plattformen sind unterstützt
Die Hersteller von Single Sign-on Produkten müssen ihre Verfahren auf jeder Plattform separat umsetzen. Entsprechend ihrer Kundenstruktur werden sie die eine oder andere Plattformkombination zuerst oder gar nie unterstützen.
Ungesicherte Arbeitsstation (in der Regel ein PC) ist ein grosses Risiko
Im Design des Single Sign-on spielt die Arbeitsstation eine bedeutende Rolle. Kann sie nicht ausreichend (d.h. mit einer 'Trusted Computing Base') gesichert werden, bedeutet dies, dass sicherheitsrelevante Daten nur im flüchtigen Speicher und nur für beschränkte Zeit auf der Arbeitsstation zwischengespeichert werden dürfen. Diese Konsequenz setzt der Schlüsselverwaltung enge Grenzen, so dass in der Praxis (zumindest längerfristig) mit Vorteil in Vorhaben zur Sicherung der Benutzerstation investiert werden sollte.
Weniger die Rechteverwaltung (siehe hierzu unter Kapitel Sicherheitsadministration) als vielmehr die Rechtevergabe und Rechteprüfung direkt aus der Anwendung heraus, bildet das Kerngebiet und jener Bereich werteorientierter Sicherheit mit dem grössten Innovations- und Wachstumspotential. Hievon, nämlich von einer Dynamisierung und Flexibilisierung des Informationszuganges, verspricht sich die Anwendung den grössten Nutzen.
Verwirklicht werden kann diese Vorstellung nur, wenn Mechanismen eingeführt und mitgeführt werden, die der Anwendung an jedem Ort und zu jeder Zeit einen Durchgriff auf Sicherheitsprofile und Funktionalität zu deren Prüfung ermöglichen.
Die Sicherheitsinformationen müssen untrennbar mit Objekten und Subjekten verknüpft und über definierbare Schnittstellen prüfbar sein. Sie müssen, um den informationsverarbeitenden Prozess nicht über Gebühr zu verlangsamen, in verdichteter Form mitgeführt und in Regeln abgearbeitet werden. Technische Voraussetzung dazu sind aus der Sicht der Performance optimal integrierte systemnahe Regelverarbeiter, sogenannte 'Ruler'. Organisatorische Voraussetzung ist eine werteorientierte, das heisst auf den Geschäftsvorgang ausgerichtete Definition der Datenbasis.
Die Probleme bei der Realisierung solcher Forderungen sind begreiflicherweise extrem komplex und übersteigen das Vermögen der meisten Unternehmen bei weitem. Gearbeitet wird hierzu vorallem in Konsortien, wie der Open Software Foundation, der European Computer Manufacturers Association oder dem X/OPEN-Gremium.
Die Entscheidungsfindungsprozesse benötigen in solchen Gremien naturgemäss recht lange. Es kann deshalb noch einige Zeit dauern, bis Produkte erhätlich sind, die es den Anwendungen ermöglichen, objektorientierte, regelbasierte Zugriffskontrolle über standardisierte Schnittstellen ausüben zu können. In der Zwischenzeit mag es, allerdings nur für homogene Teilbereiche im vernetzten System, sinnvoll sein, eine begrenzte Eigenentwicklung zu versuchen.
Verteilte Verarbeitung impliziert, dass Datenbestände verschoben werden. Für den Transport werden auf verschiedenen Schichten die unterschiedlichsten Produkte und Methoden eingesetzt:
Falls kryptografische Verfahren eingesetzt werden, so werden internationale Standards und Normen in der Regel eingehalten (zu dieser Thematik findet sich eine Reihe von Hinweisen im Anhang dieses Papieres).
Auch für den Data Exchange Service gilt: je näher an der Anwendung, desto differenzierter, kostengünstiger und angemessener ist die Sicherheitslösung. Solange jedoch keine integrierte Lösung erhältlich ist, die die Anforderungen nach Authentikation, Authorisation und Audit mit der Sicherheit des Datenaustausches verbindet, sind Einzellösungen die Folge.
Eine Möglichkeit, eine Vielzahl schwer kombinierbarer Lösungen zu vermeiden, ist die vollständige Verschlüsselung des Wide Area Netzwerkes. Mit neueren Hardware-Verschlüsslern, die auf der Transportebene verschlüsseln, ist diese Lösung mittelfristig realistisch, allerdings nur für Unternehmen, deren Geschäfte ausserordentlich sicherheitskritisch sind, und die den grossen finanziellen und organisatorischen Aufwand nicht scheuen.
Eine weitere, pragmatische Lösung ist die Sicherung einer Anwendung und deren Bevorzugung für den Transport sensitiver Daten. Sinnvoll, weil in Eigenregie und unter Verwendung von im Internet publizierten Verfahren oder mittels einem der zahlreichen angebotenen Produkte machbar, ist etwa der Schutz der im Unternehmen eingesetzten E-Mail Applikation mit kryptografischer Software.
Bestehende Systeme sind in der Lage (wenn entsprechend konfiguriert) bestimmte sicherheitsrelevante Ereignisse in Logfiles zu registrieren.
In vernetzten Systemen werden auf verschiedenen technischen und applikatorischen Ebenen Systemaktivitäten registriert und gespeichert. In den Logfiles fallen auf diese Weise riesige Datenmengen an. Leider bleiben oft wichtige Informationen in der Datenmenge versteckt und unausgewertet weil Werkzeuge zur Konsolidierung und Analyse fehlen.
Konsolidierung
Ein wichtiger Schritt in Richtung Konsolidierung eines verteilten Audits ist die Lösung des Logfiles von der technischen Plattform. Middelware-Werkzeuge sind in Entwicklung, die transportierbare, von den Betriebssystemen unabhängige ('Runtime'-)Logs schreiben, die von einem Host zum andern kopiert werden können.
Analyse
Die Aufgabe, Stapel von ausgedruckten Logfiles nach sicherheitsrelevante Ereignisse zu durchsuchen, ist offensichtlich für den Menschen ungeeignet.
Mit risikoorientierten, koordinierten detektischen Kontrollen könnte andererseits die Sicherheit im vernetzten System wesentlich erhöht werden. Dies wäre umso wünschenswerter, solange kein einheitliches Sicherheitssystem verfügbar ist, sondern Massnahmen unterschiedlichen Niveaus mit Restrisiken, die überwacht werden müssen, im Einsatz sind.
Im kommerziellen Bereich gibt es heute jedoch kaum Produkte, die eine risikoorientierte Kontrolle erlauben. Am ehesten finden sich entsprechende Werkzeuge für die Grosscomputer-Plattform. Prinzip sind dabei auf Regeln basierende, zeitgerechte Auswertungen von Logfiles. Wird ein Ereignisablauf entdeckt, der von den festgelegten Regeln abweicht oder einem bestimmten als kritisch betrachteten Verhaltensmuster entspricht, reagiert das System mit einem Rapport oder Alarm.
Die technischen Voraussetzungen für eine verteilte Ueberwachung sind in Reichweite. Noch viel zu tun gibt es dagegen bei der Festlegung der Ereignismuster, bei deren Auftreten das Ueberwachungssystem reagieren sollte. Wie allgemein im Zusammenhang mit einer werteorientierten Sicht der Sicherheitsproblematik, ist zu deren wirkungsvoller Definition ein Umdenken notwendig, eine veränderte Sicht der Informationsverarbeitung als einem Unternehmen, das über verteilte Strukturen und an der Geschäftslogik ausgerichtet sich ereignet. Dementsprechend muss auch die optimale Sicherheitslösung gebaut sein.
Die Sicherheitsadministration in einer verteilten Umgebung ist mit zahlreichen Schwierigkeiten behaftet, weil bis heute die Sicherheitsparameter pro Plattform oder gar Applikation unterschiedlich verwaltet werden. Die traditionelle zentrale Sicherheitsadministration ist ab einer bestimmten Grösse und Heterogenität der Umgebung nicht mehr in der Lage, die Sicherheitsparameter angemessen zu bewirtschaften. Als Ziel wird deshalb angestrebt, die Rechte lokal zu vergeben und zu verwalten, sie jedoch an einem zentralen Ort unter einer Struktur zusammenzuführen und zu kontrollieren (single point of control).
Seit einiger Zeit sind solche Werkzeuge für homogene Netzwerke auf dem Markt, für heterogene Umgebungen sind sie zumindest auf dem Weg zur Entstehung.
Die Funktionalität dieser Tools mag auf Benutzerverwaltung und das Setzen von Zugriffsrechten beschränkt sein, oder sich auf Softwareverteilung und die Konsolidierung und Auswertung von Audit Informationen erstrecken. Entsprechend der Grösse und Diversifikation des vernetzten Systemes ist es sinnvoll, bereits jetzt eines der auf dem Markt erhältlichen Produkte einzusetzen. Die Frage ist, ob es sich lohnt, zu den ersten zu gehören, die neue Technologien adoptieren, oder ob man sich mit einem bewährten, aber weniger ambitionierten Werkzeug für den Anfang begnügen will.
Als Nagelprobe zur Beantwortung dieser Frage kann die Strukturierung der Organisationseinheiten des Unternehmens dienen. Traditionelle Produkte unterstützen eher eine Strukturierung in Benutzergruppen und örtliche (das heisst zentrale und regionale) Geschäftseinheiten, während die neueren Produkte eine geschäftsbezogene (wertorientierte) Sicht und Strukturierung in Funktionen, Klassen- und Rollenbeziehungen abzubilden versuchen (das heisst die verteilten Einheiten in übergeordneten Strukturen zusammenfassen).
Die speziellen Sicherheitsprobleme in vernetzten Systemen haben wir in einem früheren Kapitel beschrieben. Wir haben ein Modell eingeführt, das die Sicherheitsanforderungen strukturiert und eine allgemeine Lösung aufzeigt. Wir mussten feststellen, dass es derzeit kein Produkt gibt, das die mit der Realisierung der geforderten Lösung verknüpften Aufgaben befriedigend löst.
Wir warten auf ein Produkt, das
Zwar gibt es noch kein Produkt, das unseren Anforderungen entspricht, doch immerhin einige Kandidaten. Sie erscheinen unter verschiedenen Ausprägungen:
OSF/DCE
OSF ist ein Zusammenschluss von Computer-Herstellern (unter ihnen die grössten), die sich auf eine gemeinsame Spezifikation für eine verteilte Umgebung einigten (Distributed Computing Environment), diese nun weiterentwickeln und in plattformunabhängigen Code übersetzen. Im wesentlichen bleibt es dem Markt überlassen, Produkte auf der Grundlage von DCE zu entwickeln. Dies hat den Vorteil der Multi-Vendor-Kompatibilität, bindet aber den schnellsten Anbieter an das Tempo des langsamsten.
DCE-Sicherheit basiert auf dem Kerberos-Prinzip und verwendet den symmetrischen DES Algorithmus zur Authentikation. Betriebssysteme und Anwendungen unter DCE müssen 'kerberisiert' d.h. mit DCE-Interfaces ausgerüstet werden. DCE besitzt derzeit noch eine enge Verbindung zu TCP/IP und 'secure RPC'. Bis heute gibt es keine publizierten Erfahrungen über den Einsatz von DCE in weitläufig vernetzten Umgebungen, sogenannten 'multi-cells' im DCE-Jargon. Es ist unsicher, inwiefern die Grösse und Art der Segmentierung des Netzwerkes Performance und Verfügbarkeit von DCE einschränken.
Derzeit werden Produkte angeboten, die OSF/DCE Version 1.1 unterstützen. Durch seine breite Abstützung profitiert OSF/DCE nicht nur von Ideen aus parallelen Gremien wie SESAME, sondern auch von praktischen Anregungen der Benutzergemeinschaft.
Für DCE Version 1.2 verspricht OSF:
IBM NetSP
NetSP basiert auf einem proprietären 'third party authentication protocol'. Es wurde entwickelt, um die enge Bindung des Kerberos-Konzeptes an TCP/IP und RPC zu überwinden, und um die Exportrestriktionen, die mit dem Einsatz des DES Algorithmus verbunden sind, zu umgehen. NetSP unterstützt zusätzlich ein sogenanntes 'scripting', d.h. es ermöglicht die Weitergabe von Authentikationsinformationen an verteilte Plattformen zum Zweck der Anmeldung in einem Schritt (aus Benutzersicht). Obwohl der Transport der Daten dabei nicht abhörsicher ist, deckt das Produkt auf diese Weise eine grundlegende Anforderung von Beginn an und erleichtert damit die schrittweise Migration der Plattformen unter die 'third party authentication'.
Der Pferdefuss des Produktes ist sein proprietärer Charakter. Derzeit gibt es wenig Anzeichen, das NetSP von Applikationen oder Plattformen ausserhalb der IBM-Welt übernommen wird. Da die IBM gleichzeitig an der Entwicklung von DCE massgeblich beteiligt ist, muss erwartet werden, dass NetSP nicht über die Rolle eines Lückenbüssers für IBM-Plattformen bis zu deren DCE-Reife hinauskommt.
Bull ISM/Access Master und ICL Access Manager
ISM/Access Master und Access Manager sind Produkte von Mitgliedern des SESAME Forschungsprojektes. SESAME besitzt eine Reihe von konzeptionellen Vorteilen, doch leidet seine Anerkennung darunter, dass es sich um eine europäische Intiative handelt. Solange der Markt von amerikanischen Herstellern dominiert wird, werden zu wenige auf den SESAME-Zug aufspringen.
Die Essenz der Problematik, eine Sicherheitslösung für eine heterogene Umgebung zu finden, liegt nicht in erster Linie in technischen Schwierigkeiten begründet, sondern darin, dass ein Produkt genügend dominant werden muss, dass beinahe alle Hersteller es unterstützen.
Tatsächlich scheint es uns unmöglich, dass ein proprietäres Produkt eines europäischen Herstellers je diesen Status erlangen wird, selbst dann nicht, wenn die konzeptionellen Fragestellungen ausgezeichnet gelöst sind. Da aber die Mitglieder des ECMA/SESAME-Gremiums auch an OSF/DCE beteiligt sind, darf erwartet werden, dass die besten SESAME-Ideen in zukünftige Versionen von DCE einfliessen werden
Novell Netware 4
Die Benutzerauthentikation Sicherheitslösung von Netware 4 basiert auf einer proprietären Auslegung des X.500-Standards und wird bis jetzt von keinem anderen Hersteller unterstützt. Novell dominiert den PC/LAN-Markt mit einem Marktanteil von 70 Prozent (allerdings nicht mit Netware 4) und kann deshalb nicht ignoriert werden. Wie im Fall von NetSP haben wir es mit einem sehr potenten Hersteller zu tun, der eine proprietäre Lösung anbietet. Der Erfolg eines solchen Produktes bleibt für uns unabschätzbar. Er ist beinahe vollständig von der Strategie des Herstellers, von Kraft und Druck seiner diesbezüglichen Initiativen und von der Art und Weise abhängig, wie die Frage der Kompatibilität des Produktes zu OSF/DCE angegangen wird.
Nur einige wenige (nicht-proprietäre) Frameworks und Architekturen prägen die aktuellen Initiativen zur Lösung der Sicherheitsprobleme in vernetzten Systemen:
Wie bereits erwähnt führte dieses Projekt zum technisch am weitesten fortgeschrittenen und attraktivsten Forschunsansatz zur Lösung unserer Probleme. Aufgrund seines europäischen Ursprungs ist es dennoch unwahrscheinlich, dass dieser Quelle marktbeherrschende Produkte entspringen, doch ist zu hoffen, dass die SESAME-Gedanken Eingang in DCE finden.
X/OPEN XDSF, POSIX 1003
XDSF ist das Resultat einer Zusammenarbeit von X/OPEN und IEEE POSIX. Es repräsentiert den jüngsten (Januar 1995) konzeptionellen Ansatz für ein übergreifendes Sicherheitsframework für verteilte Systeme. XDSF ist charakterisiert durch eine im Vergleich zu anderen Ansätzen unerreicht feine Granularität der Sicherheitsdomänen. Es wird interessant sein zu verfolgen, wie die Hersteller auf diese Herausforderung reagieren. Ein Hinweis auf die künftige Entwicklung ist der erfolgte Vorschlag, dass X/OPEN aufgrund seiner Rolle als Zertifizierungsgremium die Uebereinstimmungen zwischen XDSF und DCE Version 1.1 evaluieren solle.
OMG/CORBA Security
In den nächsten Jahren erwarten wir eine steigende Bedeutung des objekt-orientierten Ansatzes in den IT-Architekturen. Aufgrund der führenden Rolle des OMG-Gremiums in der OO-Welt ist zu erwarten, dass dessen Strategie bezüglich Sicherheit sehr einflussreich sein wird. Allerdings beschreibt das OMG White Paper von 1994 die benötigte Funktionalität, geht aber nicht viel weiter als klarzumachen, dass OMG (oder wenigstens die Autoren des Papieres) sich der Schwierigkeit der Problemstellung bewusst sind.
Hewlett-Packard, ein in OO-Kreisen einflussreicher Anbieter, hat angekündigt, dass seine Lösung für objekt-orientierte Sicherheit darin bestehen wird, DCE Mechanismen in HP-Objekte einzubauen. Für uns ein ermutigendes Zeichen, dass den Herstellern allmählich bewusst wird, dass die Annäherung an einen bestehenden Standard sinnvoller ist als das Warten auf einen besseren.
An dieser Stelle möchten wir abschliessend die drei - im Zusammenhang mit Sicherheit in vernetzten Systemen - wichtigsten Standards erörtern:
IS 7498-2
IS 7498-2 beschreibt die Definition der Sicherheitsservices in Begriffen des OSI-Layer Modells. So hält der Standard zum Beispiel fest, dass Vertraulichkeit in allen OSI-Layern mit Ausnahme von Layer 5 garantiert werden kann, oder dass Nichtwiderrufbarkeit nur auf Layer 7 realisierbar ist. Da die meisten verteilten Systeme keine OSI-Protokoll-Stacks einsetzen, kann dieser Standard zwar nicht in Realität, wohl aber inhaltlich angewandt werden. Er bildet ganz einfach eine gute Grundlage, um sich auf konzeptioneller Ebene miteinander zu verständigen.
GSS-API
Das GSS-API ist eine definierte Schnittstelle, über welche eine Anwendung Sicherheitsservices aufrufen kann. Es ist eine generische Schnittstelle, d.h. es kann in einer Anwendung aufgerufen werden, ohne dass der Applikations-Designer die Mechanismen kennen muss, die ihm den Service garantieren. Dies bedeutet, dass unterschiedliche Mechanismen, z.B. verschiedenartige Implementationen von kryptografischen Algorithmen und Schlüsselverwaltungen auf verschiedenen Plattformen möglich sind, ohne dass die Applikation sich daran anpassen muss. Es befreit jedoch keineswegs von der Etablierung eines sicheren Kontextes, innerhalb dessen sich die Aktionen abspielen. Das GSS-API ist also nicht selber ein Sicherheitsprodukt, sondern ein Vermittler zwischen verteilten Anwendungen und Sicherheitslösungen.
Bevor das GSS-API publiziert wurde, erfand jeder Applikations-Designer sein eigenes API. Zurzeit ist das GSS-API der einzige publizierte Standard auf diesem Gebiet - der künftige ISO-Standard scheint nicht mehr als ein erweitertes GSS-API zu werden - und es wird mit steigender Begeisterung in die Anwendungen eingebaut. Manche Designer erachten es als notwendig, Funktionen hinzuzufügen, die der Standard nicht (oder noch nicht) unterstützt (z.B. PIN-Handling).
GSS-API basiert auf Konzepten von DEC, wird aber heute von der Internet Engineering Taskforce (via RFCs) verwaltet und wurde von X/OPEN als preliminary specification übernommen.
Zusammengefasst betrachten wir das GSS-API als sehr wichtig, weil es das einzige API ist, das in existierenden Produkten unterstützt wird. Das GSS-API allein garantiert allerdings noch keine Interoperabilität.
X.500
X.500 Empfehlungen (oder IS 9594 Standards) beschreiben die Directory-Services, welche nötig sind, um OSI-Applikationen, -Prozesse und andere -Einheiten zusammenzubinden. Im speziellen beschreibt X.509 die Authentikations-Architektur. Das darin angewandte Authentikationsverfahren ist ein asymmetrisches (oder 'Public-Key'-) Verfahren (mit RSA-Algorithmus) und demonstriert exzellenten Gebrauch eines X.500 Directory. Die Bedeutung des X.509-Standards im Sicherheitsbereich ist deshalb eng an den Gebrauch asymmetrischer Kryptografie gebunden.
Asymmetrische Kryptografie besitzt spezifische Vorteile, wenn sie für das Schlüsselmanagement einer grossen Anzahl von Systemen eingesetzt wird. Eine hierarchische Directory-Struktur, wie sie X.500 beschreibt, unterstützt eine solche Art von Anwendung optimal. Die X.500 Empfehlungen könnten die Entwicklung einer standardisierten Sicherheitslösung für verteilte Systeme beschleunigen.
Es ist darum unseres Erachtens schwer erklärbar, wieso der Markt die X.500 Empfehlungen nur äusserst langsam adoptiert. Die Gründe hierzu liegen wohl in der Lizenzproblematik, in den politischen Konsequenzen und nicht zuletzt in der mathematischen Komplexität der Anwendung asymmetrischer Kryptografie begründet.
Mit einer Kombination aus taktischen und organisatorischen Massnahmen lässt sich ein akzeptables Niveau an Informatiksicherheit in einer vernetzten Umgebung erreichen. Wichtige Probleme der verteilten Verarbeitung können aber durch diese vergleichsweise traditionellen Massnahmen nicht befriedigend gelöst werden. Weil sie einzelne Komponenten, speziell riskante Systemsegmente oder homogene Teilbereiche schützen, gleicht das Resultat einem Flickenteppich (i.e. Patchwork Security). Da die Informationsverarbeitung im vernetzten System verteilt erfolgt, sind die Informationen im Prozess ihrer Verarbeitung einmal geschützt und dann wieder nicht. Tendenziell stellen wir fest: je stärker ein Unternehmen seine Informationsverarbeitung in Client / Server-Strukturen migriert, desto unzulänglicher greifen punktuelle Massnahmen, desto wichtiger werden Massnahmen in Richtung Etablierung einer verteilten Sicherheit (i.e. Distributed Security), wenn ein rascher Fall des Sicherheitsniveaus vermieden werden will.
Uebergang zu einer verteilten Sicherheit gestaltet sich nicht ohne Probleme. Wir haben eine Reihe von Schwierigkeiten aufgezeigt und ein strukturiertes Modell vorgestellt, das die Probleme adressiert. Wir haben festgestellt, dass es derzeit kein Produkt gibt, das die Probleme einheitlich und in einer gesamthaft befriedigenden Weise löst. Der überzeugendste Kandidat - OSF/DCE - ist zwar auf dem richtigen Weg, aber noch lange nicht am Ziel.
Alle Konzepte, Initiativen und Produkte unterstützen aber gemeinsam trotz zählebiger proprietärer Eigenschaften zwei wesentlich neue Ansätze:
Das Security Server Konzept
Alle bekannten Lösungsansätze beinhalten die Konzeption und Etablierung eines Security Servers. Dies hat folgende Konsequenzen:
Bild 11 'Security Server: The third player in the game'
Die standardisierte Schnittstelle zur Applikation
Alle bekannten Lösungsansätze haben die Absicht bekundet, ein standardisiertes Interface zu unterstützen, oder sie benutzen bereits das GSS-API. Das GSS-API ist selber kein Sicherheitsprodukt, sondern ein Vermittler zwischen verteilten Anwendungen und Sicherheitslösungen. Die Bedeutung des Security-API liegt in seiner Uebersetzerfunktion begründet. Es ermöglicht der Anwendung, mit unterschiedlichen (proprietären) Ausprägungen von Sicherheitsdiensten zurechtzukommen.
Verfügbarkeit
Die zentrale Bedeutung des Security Servers gefährdet die Verfügbarkeit des Gesamtsystems. In der Praxis empfiehlt sich eine Kombination der folgenden Auslegungen:
Einsatz hochmoderner Kommunikationstechnologie mit optimaler Verfügbarkeit ermöglicht eine geringe Anzahl zentral positionierter Security Servers.
Die Unterteilung des Systems in tendenziell kleine Domänen oder Zellen mit dazugehörigem Security Server verringert das Schadenspotential beim Ausfall eines Security Servers.
Performance
Die Art und Weise der Unterteilung des vernetzten Systems, d.h. Grösse und Anzahl der Domänen, die Positionierung des Security Servers und die Verteilung der Applikations-Server beeinflussen die Performance wesentlich, umso mehr, weil über den Gesamtprozess der Verarbeitung ein Sicherheitskontext aufrechterhalten werden muss. Bis jetzt sind nur sehr wenige Erfahrungen mit grösseren Systemen publiziert worden, so dass es ausserordentlich schwierig ist, eine optimale Auslegung der Domänen (oder Zellen im DCE-Jargon) zu empfehlen.
Administration
Die derzeit erhältlichen Produkte sind nicht genügend einfach zu administrieren. Bis jetzt wurden zudem die Implikationen einer an den Geschäftsvorgängen ausgerichteten verteilten Sicherheitsadministration unterschätzt. Neuerdings gibt es Hinweise, dass die Hersteller sich der Problematik bewusst wurden und markante Verbesserungen zu erwarten sind. Dennoch lässt sich heute nicht gültig sagen, ob die Administration technischer Ressourcen und die Administration von geschäftsbezogenen Funktions- und Rollenbeziehungen unter das Dach einer einheitlichen Sicherheitsadministration gebracht werden können
Cryptografie
Das Zusammenspiel von Client, Applikations- und Security-Server (vermittelt durch das standardisierte Security-API) muss sich in einem sicheren Kontext vollziehen. Der Einsatz von Kryptografie im vernetzten System ist deshalb unverzichtbar. Die Stärke der kryptografischen Mechanismen wird durch die Gesetze der Mathematik bestimmt, ihre Anwendung aber wird durch Lizenzen und Exportrestriktionen kontrolliert und ist Subjekt politischer Programme. Es benötigt eine Initiative der Vereinten Nationen, die Kryptografie aus nationalen und protektionistischen Zwängen zu befreien und allen Völkern und Gesellschaften im Rahmen einer gemeinsam festgelegten Definition von Privatheit zur Verfügung zu stellen.
Über Jahrhunderte befassten sich Menschen damit, "Geheimschriften" zu erfinden, um über unsichere Wege geheime Informationen auszutauschen. Eine chiffrierte Nachricht ist für den Empfänger nur brauchbar, wenn auch eine Funktion bekannt ist, welche die enthaltene Information mittels Interpretationsschüssel zugänglich macht. Der Zugriff auf eine Nachricht schliesst somit den Zugriff auf die eingeschlossene Information direkt nicht mehr ein, da für den Zugriff auf die Information neben der Nachricht auch der Algorithmus und Schlüssel erforderlich sind.
Moderne Chiffrierfunktionen wie DES (Data Encryption Standard) oder IDEA (International Data Encryption Algorithm) arbeiten nicht mehr nach der alten Caesar-Methode, bei welcher Buchstaben durch andere Buchstaben nach einem bestimmten Muster einfach ersetzt wurden. Gegenüber elektronischer Datenverarbeitung und statistischen Analysen von Nachrichten bieten solch naive Methoden keine Sicherheit mehr. Die Entwicklung und Analyse von Chiffrieralgorithmen ist heute zu einer Wissenschaft geworden, welche die Erkenntnisse im Bereich der Mathematik (Zahlentheorie, Stochastik, Statistik, Algebra) ausnützt.
Die Sicherheit moderner kryptographischer Algorithmen sollte nicht von der Geheimhaltung des angewandten Chiffrierverfahrens sondern von der Geheimhaltung der Schlüssel abhängen. Nur wenn ein Verfahren veröffentlicht wird, kann sich die Öffentlichkeit von der Qualität überzeugen, was letztlich zu einer besseren Akzeptanz führt. Ein Verfahren etabliert sich zum Standard, wenn es allgemein akzeptiert und eingesetzt wird.
Krytographische Verfahren erlauben nicht nur die Vertraulichkeit der Informationen zu gewähren, sondern auch deren Authentizität zu überprüfen. Der Umgang mit den Schlüsseln (key management) spielt eine zentrale Rolle für die Sicherheit eines Gesamtsystems und sollte auch bis ins Detail mit grösster Aufmerksamkeit untersucht werden.
Kryptographische Algorithmen lassen sich in zwei Hauptfamilien unterteilen: symmetrische und asymmetrische Algorithmen.
Angesichts des rasanten Fortschritts auf anderen Gebieten der Informations Technologie mag es überraschen, dass die Sicherheit in verteilten Systemen immer noch, was die Produkte betrifft, in den Kinderschuhen steckt.
Die besondere Herausforderung der verteilten Systeme ist, dass proprietäre Lösungen unbrauchbar bleiben, solange diese nicht zum de Facto-Standard werden. Der Standardisierungs-Prozess, und damit der Fortschritt, wurde von den zwei folgenden rechtlichen Problemen stark gebremst.
Kontrolle und Verbreitung der Kryptologie
Die US-Behörden (und wahrscheinlich fast alle anderen auch) wollen sicherstellen, dass sie Meldungen im Nachrichtenwesen von organisierten Verbrechen und feindlichen Nationen abhorchen und interpretieren können. Dazu müssen sie verhindern, dass solche Organisationen starke kryptologische Produkte erhalten und einsetzen können. Das wirksamste Mittel für die Einschränkung und Verbreitung sind Exportrestriktionen.
Welche Produkte/Mechanismen in welches Land exportiert werden dürfen muss ständig an die jeweilige politische Lage und den aktuellen Stand der Technik angepasst werden. Diese Situation ist für Produkte-Hersteller so schwierig, dass sie sich gezwungen fühlen, für den Export nur schwache kryptologische Mechanismen einzusetzen. Die Veröffentlichung von Informationen, welche Schlüsse über die kryptoanalytische Fähigkeit der Regierung zulassen, muss selbstverständlich auch verhindert werden.
Die US Regierung arbeitet auf zwei Wegen um den Konflikt zwischen den öffentlichen und privaten Interessen zu entschärfen:
Erstens ist die Regierung grundsätzlich bereit den Export von kryptographischen Mechanismen zu erlauben, welche zur Authentikation und Integrität der Daten dienen, aber den Vertraulichkeitsschutz nicht erlauben. Damit besteht die Möglichkeit wenigstens ein Teil der notwendigen Sicherheitsdienste zu unterstützen.
Mit der zweiten Lösung, dem Key-escrow Verfahren, wird der Benutzer nicht mehr gezwungen einen schwachen kryptologischen Algorithmus zu wählen, welcher von der Regierung ohne grossen Aufwand geknackt werden kann.
Anstelle der Kontrolle über die Verbreitung kryptographischer Produkte verlangt das Key-escrow Verfahren, stark vereinfacht, dass Teile der Chiffrierschlüssel bei zwei unabhängigen Stellen deponiert werden, welche die Schlüsselinformationen an die Strafverfolgungs Behörde gegen eine rechtsgültige Verfügung abliefern würden.
Dieser Vorschlag hat eine enorme Kontroverse, mit folgenden Argumenten, ausgelöst:
Patentwesen
Das grösste Hindernis für eine verbreitete Einführung/Aufnahme von asymmetrischen Algorithmen sind die Patente welche von Public Key Partners (PKP) verwaltet werden. Um RSA in den Vereinigten Staaten kommerziell nutzen zu können werden von PKP Lizenzgebühren verlangt. Obwohl das DSS als lizenzfreier, exportierbarer Mechanismus für digitale Unterschriften entwickelt wurde, verlangt PKP auch dafür Gebühren für ihre Patente.
Die Definition des "Generic Security Service Application Program Interface" (GSS-API) bietet Sicherheitsdienste, welche bei den Anwendungen in einer generischen Weise aufgerufen werden können. Die Schnittstelle ist unabhängig von integrierten kryptographischen Mechanismen, deshalb unterstützt sie die Portabilität von Quellencodes in verschiedensten Einsatzumgebungen. Eine Anwendung, welche die Funktionen des GSS-API aufruft, ist typischerweise das Kommunikationsprotokoll, welches die Authentizität, die Integrität und evtl. auch die Vertraulichkeit seiner Kommunikation gewährleisten sollte.
Anwendungen, die GSS-API aufrufen, müssen fähig sein, sogenannte "Token" vom lokalen GSS-API zu beziehen und diese zum remote System weiterzuleiten. Umgekehrt muss das remote System die eingetroffenen Token zum GSS-API übergeben können. Beim Token handelt es sich um eine für die Applikation undurchsichtige Datenmenge, welche nur die integrierten kryptographischen Mechanismen des GSS-API interpretieren können.
Das GSS-API lässt die Wahl von kryptographischen Mechanismen frei. Diese können auf symmetrischen oder auf asymmetrischen kryptographischen Technologien basieren. Zwei miteinander kommunizierende Applikationen müssen die gleichen Mechanismen verwenden, um ihre Kommunikation zu schützen.
Das GSS-API bietet vier Typen von Funktionen:
Die heutige Definition des GSS-API ist in ihrer Funktionalität begrenzt. Zwei Punkte sind hier erwähnt:
Unterstützung des Benutzer-Logins:
Dies ist der Prozess der Benutzer-Authentisierung auf einem System ("Login"), und die Weiterverwendung dieser Informationen für die Benutzer-Authentisierung auf anderen Systemen oder Applikationen ("Single Sign On"). Die Authentisierung des Benutzers soll nur auf dem System geschehen, wo der Benutzer sich das erste Mal anmeldet. Dabei werden Authentisierungsinformation freigegeben, welche für die weiteren Authentisierungen dieses Benutzers verwendet werden.
Unterstützung der Datenfluss-Sicherheit:
Der Schutz der Daten geschieht auf Packet-Ebene (Integritätsschutz, Vertraulichkeit). Bei der Übermittlung grosser Datenmengen wäre es effizienter, die Sicherheitsmechanismen hardwaremässig (evtl. auch softwaremässig) auf dem Datenfluss, statt auf Applikationsebene auszuführen. In diesem Fall müsste die Applikation einen Sicherheitskontext aufbauen, wodurch der Datenfluss automatisch geschützt würde.
Unter System Security Management verstehen wir die sicherheitsrelevanten Aspekte in Bereichen wie das Initialisieren und Nachführen der Konfigurationen, die Schlüsselverwaltung, die Verwaltung der Systemkomponenten, die Administration der Benutzer, Logging und Audit, etc.
Noch vor einigen Jahren konzentrierten sich die Benutzer auf die Realisierung einigermassen stabiler Sicherheitssysteme, auch wenn deren Administration und Verwaltung umständlich war und sich funktionell auf ein Minimum beschränkte. In den letzten Jahren schenken die Hersteller dem System Security Management grössere Beachtung. Verschiedene Systeme mit benutzerfreundlichen Verwaltungsfunktionen wurden entwickelt, welche umfassende Lösungen für die Aufgaben des System Security Management unterstützen.
Weitere Fortschritte sind aber immer insbesondere in folgenden Bereichen noch notwendig:
IS 10164
Diese Norm umschreibt das System Security Management in folgenden Areas:
System Security Management
Der Umfang gliedert sich in die folgende wichtigsten Managementdisziplinen:
Referenzliteratur (als Auswahl zur Vertiefung der Materie).
Architectures and Frameworks
|IS 7498-2||OSI Reference Model. Part 2: Security Architecture|
|IS 10181||Security Frameworks|
|ECMA TR/46||A Security Framework|
|POSIX 1003.22||A Security Framework|
|XDSF||A Open Distributed Security Framwork|
GSS-API
|IETF RFC 1508 und 1509|
|POSIX P1003.6|
|X/Open Preliminary Specification P308|
|X/Open Snapshot Specification S307|
Security Management
|IS 10745||Upper Layers Security Model (GULS) (X.803)|
|IS 10164||System Security Management|
|IS 10165-2||OSI Management Information Services|
Requirements
|OMG White Paper on security|
DCE
|OSF White Paper 'Security in a Distributed Computing Environment'|
|OSF DCE FAQ on comp.unix.osf.misc and comp.client-server ; http://www.osf.org:8001/|
SESAME
|ftp.enst.fr;/pub/sesame|
|ftp.esat.kuleuven.ac.be:/pub/COSIC/vdwauver/sesame|
|DCE RFC 19|
|SESAME FAQ on talk.politics.crypto|
Kerberos
|IETF RFC 1510|
Alain Beuchat, Dipl. El. Ing. EPFL, IT Revisor bei der SBG, Schwergewicht UNIX operating System and network security.
Adresse:
Alain Beuchat
SBG
Bahnhofstrasse 45
8021 Zürich
Beat Federspiel, Berater für Informationstechnologie mit
Schwergewicht in den Bereichen IT Systemkonzepte für Client /
Server Anwendungen und Security.
Adresse:
Beat Federspiel IT Consulting
Mischelistrasse 15
4153 Reinach
Max Isler, Projektleiter, Informatik Global Operation, Telekurs AG.
Adresse:
Max Isler
Telekurs AG
Postfach
Hardturmstrasse 201
8021 Zürich
Daniel Felix Maurer, lic. phil., IT Sicherheitsberater und System
Designer, Leiter der Fachstelle für Technische IT Sicherheit des
SKA Konzerns.
Adresse:
Daniel Felix Maurer
SKA
Dept. Oqx9
Postfach
8070 Zürich
Anthony Thorn, M. A. (Cantab.),IT Sicherheitsberater, AT Systems & Services
Adresse:
Anthony Thorn
AT Systems & Services
Ringstrasse 5
6332 Hagendorn
Giampaolo Trenta, Dipl. Informatiker Ing. ETHZ, IT Revisor bei der
SBG, Schwergewicht UNIX operating System and network security.
Adresse:
Giampaolo Trenta
SBG
Bahnhofstrasse 45
8021 Zürich
|isss Editor (content) /||isss Webmaster (technology/configuration) /||04 April 2003|