Von Dirk Nouvortne, Reiner Pliefke und Michael Schmidt*
*Dirk Nouvortne ist Leiter "Bürokommunikation", Reiner Pliefke Gruppenleiter "Nachrichtentechnik" und Michael Schmidt Projektleiter "Electronic Mail" im Gerling-Konzern, Köln.
"Wie Sand am Meer" gibt es Checklisten, Hochglanz-Broschüren und Fachbücher, die den Segen der modernen Informations- und Kommunikationsmittel als Wettbewerbsinstrument preisen. Die meisten haben den Nachteil, diese Techniken hochzujubeln, "wie Blinde die Farbe".
Ein zentraler Bestandteil der Rechnerarchitektur-übergreifenden Electronic-Mail-Anwendung X.400 ist die Adressierung. Die Standardisierungsgremien haben dies erkannt und die Norm "X.500" entwickelt. Die Festlegung von Directory-Services und Protokollen ist vor allem auf die Sicherstellung der Interoperabilität zwischen unabhängigen Segmenten verteilter Inhaltsverzeichnisse gerichtet.
Wesentlich ist die Erkenntnis, daß nicht nur die Adressierung im Rahmen der Textkommunikation zu standardisieren ist, sondern darüber hinaus ebenso die der Datenkommunikation. Auch wenn die Adressierung im Rahmen der Sprachkommunikation schon durchgängig einheitlich zu sein scheint, so sind doch im Hinblick auf das ISDN mit seinem Anspruch hinsichtlich einer Integration der Kommunikationsformen einheitliche Muster für Daten, Sprache und Text zu definieren. Vor allem für Unternehmen, die Wert auf eine komfortable Benutzeroberfläche legen, ist ein einheitliches Adressierungsmuster von Interesse. So läßt sich ein Trend in Richtung Alias-Namen erkennen, während Nummern wesentlich weniger praktisch sind.
Im Rahmen eines Corporate Networks ist vorstellbar, daß ein derartiger Auskunftsdienst in Form elektronischer Verzeichnisse durch den Netzwerkbetreiber angeboten wird. Der Directory-Dienst ist im Begriff, sich zu einem universalen Verzeichnisdienst weiterzuentwickeln.
Die Aufgabe eines Directory-Systems liegt in der Speicherung und Bereitstellung von Informationen (Adressen) über Objekte und deren Eigenschaften. Darunter können beispielsweise Personen und deren X.400-Adressen, Datenanwendungen mit den Zugangsadressen oder Endgeräte und Hardware-Adressen verstanden werden.
Die Affinitäten lassen sich an einem Beispiel dokumentieren.
Dargestellt wird eine X.400-Adressierung, die die Basis für den X.500-Standard abgibt. Ausgangspunkt ist ein Alias-Name (Matchcode oder auch Ordnungsbegriff), der auf einen Datensatz, bestehend aus fünf Datenfeldern, verweist:
Wobei ADMD Administrative Management Domain, PRMD Private Management Domain und OU Organizational Unit bedeuten.
Ähnlich verhält es sich in der Datenkommunikation. Bei diesem Datensatz besteht noch die Option, sogenannte Attribute anzufügen. Die Attribute geben die Möglichkeit, anwenderspezifische Nutzungsmöglichkeiten anzugeben, wie etwa öffentliche Schlüssel, Zugriffsberechtigungen, Teilnahme an Verteilerlisten etc.
Dieser Aufbau bietet die Basis für die eingangs dargestellte Integration eines Mehrwertdienstes in die Abläufe und die Funktionalität von Systemen bei der Sachbearbeitung eines Anwenderunternehmens. Eine Person oder ein Programm editiert beziehungsweise nutzt einen Baustein oder Standardtext und versendet ihn über die hausinternen beziehungsweise über die Gateways des Netzbetreibers zu den entsprechenden Telematikdiensten unter Angabe einer Adresse (Alias-Namen) und gegebenenfalls sonstiger Funktionen (Geschwindigkeit, Dienstgüte etc.). Hinsichtlich der Adresse prüft das X.500-Modul, ob die Adresse bekannt ist oder ob eine Suche in einer nebenoder übergeordneten X.500-Instanz gewählt werden muß, um die fragliche Adresse "hinunterzuladen" (DDP-Ansatz). Es kann nicht davon ausgegangen werden, daß ein Serviceanbieter alle möglichen Adressen vorrätig hat.
Diese Vorgänge sollten vollautomatisch vollzogen werden, da es sich um rein technische
Funktionen handelt, von denen ein Sachbearbeiter in einer Fachabteilung allein unter betriebswirtschaftlichen Gesichtspunkten entbunden werden muß.
Die Frage ist nun - und das leitet auch zur Rolle eines Dienstanbieters über - wo diese Adreßinformationen verwaltet werden. Generell sollte die Verwaltung von Adreßinformationen einem unabhängigen und gegebenenfalls verteilten Directory-Dienst als Kommunikation unterstützendes System übertragen werden. Dabei muß das Directory sich nicht nur auf die Textkommunikation beschränken, sondern vielmehr - im Sinne eines allgemeinen Kommunikationsdienstes - seine Leistungen allen Kommunikationsformen zur Verfügung stellen, soweit es sich um OSI-Applikationen handelt einschließlich der Telematikdienste. Neben den Einsparungen für jedes Nutzerunternehmen hinsichtlich Erwerb beziehungsweise Entwicklung eigener X.500-Applikationen und der gesparten Vorhaltung eigener zentraler und dezentraler DV-Ressourcen kann ein Carrier, außer den bereits bei X.400 dargestellten Verwaltungsleistungen, insbesondere noch hinsichtlich der Textkommunikation Konvertierungsleistungen anbieten, wie zum Beispiel Konvertierungen in Gruppe 4 Fax, T 61 und ASCII etc.
Kein angebundenes Unternehmen muß ein eigenes unternehmenseigenes Directory aufbauen. Lediglich der Netzbetreiber hat die Notwendigkeit, sich an den internationalen Standard anzubinden. Die Abnahme durch den öffentlichen Versorgungsanbieter, die Deutsche Bundespost Telekom, erfolgt nur einmal. Internationale Konventionen sind nicht unbedingt durchgehend, so daß auch hier der Serviceanbieter nur einmal für alle Nutzer eine Konvertierung einzuleiten braucht.
In diesem Zusammenhang drängt sich der Vergleich zum User Agent im X.400-Standard auf. Es ist durchaus ausreichend, daß der User Agent beim Anwender verbleibt, während den Aufbau und die Recherche zu anderen Directories (öffentlich oder privat) der Netzbetreiber gewährleistet.
Sofern Adressen bei einem öffentlichen oder privaten Unternehmen beschafft werden, handelt es sich um einen Zugriff auf eine externe Datenbank, wobei die Informationsrecherche gebührenpflichtig ist. Fragen des Accountings und der Berechtigungsprüfung werden durch den Serviceanbieter an die Konventionen des öffentlichen Anbieters einmalig angepaßt.
Auch hinsichtlich der Sicherheit gibt es Dienste, die ein Netzwerkbetreiber seinen Klienten anbieten kann und - wie könnte es in konsequenter Fortschreibung des bisher dargestellten Services anders sein - die Sicherheitsdienste sind vor allem standardisierten Protokollen entlehnt. In diesem Fall der X.500-Standardisierung, besonders X.509.
Die zunehmende Nutzung öffentlicher und privater Netzwerke macht es bei verschiedenen sicherheitssensiblen Anwendungen notwendig, Mechanismen zur Verfügung zu stellen, um die transferierten Daten zu schützen. Sicherheitsfunktionen sind dabei Verschlüsselung und Authentifizierung. Verschlüsselung erschwert es einem potentiellen Angreifer, übertragene Daten im Klartext zu lesen. Authentifizierung stellt sicher, daß der jeweilige Kommunikationspartner wirklich derjenige ist, für den er sich ausgibt. Der Bezug zu einer elektronischen Unterschrift ist naheliegend.
Es werden in der Sicherheitsthematik unterschiedliche Verfahren diskutiert, die sich zum Teil auf bilaterale Funktionen stützen oder die die Nutzung einer dritten - servicebezogenen - Instanz in Anspruch nehmen. Hier wird die zweite Möglichkeit skizziert, da die Serviceleistungen von einem Netzwerkbetreiber angesprochen werden. Im Vordergrund steht das "Public-key-Verfahren". Dieses Verfahren nutzt zum Ver- und Entschlüsseln zwei verschiedene Schlüssel.
Ist die Entschlüsselungsmethode nicht aus dem Verschlüsselungscode ableitbar und läßt sich die Codierung nicht durch einen Angriff brechen, kann man den Verschlüsselungscode öffentlich bekanntgeben. Will nun ein Teilnehmer mit einem anderen kommunizieren, so entnimmt er dessen Public key aus einem öffentlichen Verzeichnis, das beispielsweise als Authentifizierungsserver bei einem Carrier geführt wird. Da nur der gewünschte Zielteilnehmer den zugehörigen Secret key besitzt und dieser Secret key die einzige Möglichkeit ist den mit dem Public key verschlüsselten Text zu entziffern, kann der Absender sicher sein, daß kein anderer die Nachricht entschlüsseln kann (Bild 16).
Neben der Verschlüsselulgsfunktion läßt sich auch die Authentizitätsprüfung mit Hilfe von Public-key-Verfahren realisieren und damit auch die elektronische Unterschrift. Durch den Netzwerkbetreiber wird ein Authentifizierungsserver als vertrauenswürdige Instanz im Netz betrieben, die für alle Teilnehmer die öffentlichen Schlüssel verwaltet. Das Problem der authentischen Schlüsselverteilung reduziert durch diesen VAS den Transport vom Server zum Teilnehmer und umgekehrt.
Der Absender schickt einen mit seinem Secret key verschlüsselten Text. Der Empfänger entschlüsselt diesen Text unter Nutzung des Public key des Absenders, den er aus dem Authentifizierungsserver holt, und ist so sicher, daß der Text nur von dem bestimmten Absender kommt.
Die Software eines Authentifizierungsservers basiert auf X.500, wo neben den Adreßinformationen in der Form von Attributen die Public keys der Kommunikationspartner verwaltet werden. Es handelt sich dabei um eine Tabelle, die als Datensatz den Namen der Kommunikationsteilnehmer beinhaltet und um einen Datensatz, der die Adreßinformationen über fünf Datenfelder enthält. X.500 sieht neben dem Datensatz noch Attributfelder vor, wobei ein Attributfeld der öffentliche Schlüssel eines Kommunikationspartners ist. Es ist Aufgabe der Authentifizierungszentrale, die öffentlichen Schlüssel, die nicht geheim sind, aufzubewahren und als ein Auskunftssystem diese auf Anfrage "amtlich beglaubigt" mitzuteilen. Man könnte sich hier durchaus vorstellen, daß ein Carrier zwar das Netzwerk stellt, den Dienst jedoch durch einen spezialisierten Dienstleister organisiert, wie das etwa ein Notar der Schlüsselverwaltung bewerkstelligt.
Transparent und vollautomatisch
Sofern die Kommunikationspartner nicht der gleichen Schlüssel-Verteilzentrale angehören, besteht das gleiche Prinzip der verteilten Kommunikation über eine Fülle öffentlicher - in diesem Fall durch den Netzbetreiber oder einem besonderen Dienstanwender angebotenen - VAS mit Sicherheitscharakter.
Entscheidend für diesen Dienst ist, daß das komplette Verschlüsselungssystem für den einzelnen Teilnehmer vollautomatisch und transparent, das heißt ohne Änderung am Endgerät oder an der Anwendung arbeitet. Eine ungesicherte Kommunikation mit Teilnehmern, die über keine Sicherheitseinrichtung verfügen, ist weiterhin möglich.