Ausarbeitung zum Vortrag
Referent: Tim Wellhausen
Betreuer: Markus Schumacher
30.01.2000
Seminar Information und Kommunikation
Information Transfer Office
Diese Arbeit behandelt das Thema "Quality of Service-Parameter Sicherheit". Sie entstand im Zusammenhang mit dem Seminar "Information und Kommunikation" an der TU Darmstadt im Wintersemester 1999/2000.
In dieser Ausarbeitung werden die wesentlichen Aspekte von Quality of Service geklärt. Da Sicherheit ein zentrales Thema in der Informatik geworden ist, hat sich die Frage gestellt, wie sich die Sicherheitsproblematik auf die Zusicherung der Qualität von Diensten ausweiten läßt.
Zuerst werden die Merkmale von Quality of Service und die Sicherheitsproblematik beschrieben. Anschließend wird dargelegt, wie die beiden Bereich zusammenhängen, also, wo ihre Gemeinsamkeiten und Unterschiede sind. Darauf folgt ein Abschnitt mit der Vorstellung verschiedener Systeme und Szenarien, die zeigen, wie mögliche Integrationen aussehen können. Die Schlußfolgerungen beschäftigen sich mit den Konsequenzen der Erörterungen, und eine kurze Zusammenfassung beendet diese Arbeit.
Der Begriff des Quality of Service (QoS) existiert schon seit längerer Zeit. In diesem Abschnitt soll geklärt werden, was dieser Begriff bedeutet. Weiterhin werden verschiedene Anwendungsgebiete des QoS aufgezeigt und schließlich erklärt, wie Quality of Service in der Praxis funktioniert. Dabei wird darauf eingegangen, was Parameter sind und wie sie statisch bzw. dynamisch ausgehandelt werden.
Quality of Service bestimmt eine Zusicherung bestimmter Eigenschaften eines Dienstes. Die Eigenschaften von Diensten, wie Übertragungsraten, Fehlerraten oder andere Charakteristiken, sollen gemessen, verbessert und im Voraus garantiert werden. Wie der Name schon besagt, bezieht sich Quality of Service (QoS) also auf die Qualität eines Dienstes beziehungsweise auf die Performanz und nicht auf die Funktionalität.
Von besonderer Bedeutung ist Quality of Service für Übertragungen von Videoströmen und Multimedia-Daten, die hohe Bandbreiten erfordern. In bisherigen Netzen ist es nämlich schwer, diese Übertragungen zuverlässig zu ermöglichen, da die derzeitigen Protokolle nur versuchen, zu jedem Zeitpunkt die Daten "so gut wie möglich" zu übertragen.
Die Rolle von Quality of Service besteht also zuerst darin, die gewünschten Anforderungen an die Eigenschaften eines Dienstes zwischen dem Anbieter des Dienstes und dem oder den Nutzern zu verhandeln. Ist dies erfolgt, hat QoS dafür zu sorgen, daß diese Kriterien dauerhaft eingehalten werden.
Quality of Service spielt durch den Einsatz von dedizierte QoS-Komponenten schon eine große Rolle in vielen Systemen. Die Entwicklung des neuen Standards für das Internetprotokoll (IPv6) ([2]) dürfte für eine weitere Verbreitung von Anwendungen, die QoS beachten, sorgen. In diesem Protokoll ist beispielsweise eine Bandbreitenreservierung vorgesehen, die maßgeblich für zu erreichende Übertragungsqualitäten verantwortlich ist.
Quality of Service wurde zuerst für Systeme in einem lokalen Netz mit vergleichbar überschaubaren Anforderungen benutzt. Diese Systeme wurden dann auf verteilte Netze (WANs) ausgeweitet. Im Zuge der Ausbreitung des Internet sind die Anforderungen entsprechend gewachsen. Vereinbarungen bezüglich der Qualität der Dienste sollten jetzt für jeden weltweit vernetzten Computer möglich sein.
Der nächste Schritt hinsichtlich der Ausbreitung von QoS wird derzeit durch den Mobilfunk ausgelöst ([13]). Die dazu existierenden Systeme müssen versuchen, jedem Mobilfunk-Benutzer bestmögliche Qualität zu bieten. Die benutzten Geräte übernehmen aber immer mehr Aufgaben als nur die Sprachübertragung. Der nächste Schritt ist die Verbreitung von PDAs, die einen großen Funktionsumfang haben, ähnlich wie ein persönlicher Computer, dies aber an jedem Ort ermöglichen.
Damit verbunden sind sowohl die Ansprüche an die verfügbaren Dienste, als auch die Komplexität der angebotenen Dienste stark angestiegen. Die Aufgabe wird sein, dem in Form von ausgereiften Quality of Service-Systemen Rechnung zu tragen.
Die Hauptanwendungsgebiete für Quality of Service sind in erster Linie alle Anwendungen, die miteinander kommunizieren. Sehr wichtig ist die Dienstequalität für jegliche Art von Audio- und Videoanwendungen, bei denen Multimedia-Daten übertragen werden.
Weiterhin ist QoS für den ganzen Bereich der Echtzeitanwendungen wichtig. Hier kommt es nicht primär auf den Datendurchsatz an, sondern auf Anwortzeiten. Dies betrifft beispielsweise Produktionsanlagen, die jederzeit innerhalb fest vorgegebener Zeiten reagieren müssen.
Ähnliche Anforderungen weisen Realzeitanwendungen auf: Ein typischer Fall im Internet sind beispielsweise Chat-Systeme, bei denen nur kleine Datenpakete verschickt werden, die aber in kurzer Zeit bei den Clients ankommen müssen.
Abgesehen von Kommunikationsdiensten lassen sich nur wenige weitere Anwendungen angeben, die ebenfalls QoS benutzen. Ein Beispiel mögen Datenbanken sein, die bestimmte Transaktionsweisen anbieten. Je nach Wunsch der Benutzer kann sich die Qualität des Dienstes hier unterscheiden in der Schnelligkeit, mit der Daten gespeichert und gefunden werden. Dies läßt sich beispielsweise durch Prioritäten mancher Transaktionen variieren.
Wie schon angedeutet, bestimmen verschiedene Parameter die Qualität eines Dienstes. Als Parameter gilt jeder Wert der zwischen am Dienst teilnehmenden Entitäten ausgehandelt wird. Bei Verbindungsaufbau zwischen einem Nutzer eines Dienstes und dem Anbieter des Dienstes müssen daher alle relevanten Parameter bestimmt und ihre Werte verhandelt werden. Dazu ist es notwendig, daß beide Seiten von vorne herein Anforderungen besitzen.
Zum einen muß bestimmt sein, welche Parameter es überhaupt gibt. Auf beiden Seiten muß also ein fester Satz festgelegter Parameter existieren. Weiterhin muß klar sein, welche Mindestanforderungen beide Seiten an alle Parameter haben. Diese Anforderungen können sich auf einzelne Parameter beziehen oder auch auf eine Menge von Parameter, die gemeinsam bestimmten Anforderungen entsprechen müssen. Schließlich können die Teilnehmer noch angeben, welche Wünsche sie hinsichtlich der Werte der Parameter haben.
Im Idealfall existieren Profile in Form einer Sammlung aller relevanten Parameter einschließlich Grundeinstellungen für die gewünschten Werte. Diese Profile verbergen einen Teil der Komplexität solcher Systeme vor dem Anwender. So gibt es beispielsweise Soundkarten, deren Treiber verschiedene Profile für die Qualität der Ausgabe anbieten (Telefon-Qualität, CD-Qualität, etc.).
Die folgende Tabelle listet verschiedene Werte auf, die typische Parameter von Quality of Service-Systeme sind:
|
Datendurchsatz |
Prioritäten |
|
Antwortzeiten |
Kosten |
|
Verzögerung |
Stabilität |
|
Verfügbarkeit |
Benutzbarkeit |
Ein grundsätzliches Problem ergibt sich daraus, daß nicht alle gewünschten Eigenschaften eines Systems parametrisierbar sind. Eigenschaften wie Datendurchsatz und Antwortzeiten lassen sich leicht mit Werten bestimmen. So kann man verlangen, daß der Datendurchsatz zumindest 50 KB/Sekunde und die Antwortzeiten unter 100ms bleiben müssen.
Bei einem Parameter wie Kosten kann man auch noch versuchen, Werte zu bestimmen. Aber hier ist es möglicherweise nicht einfach, alle wesentlichen Kostenfaktoren einzubeziehen und zu bestimmen.
Schließlich gibt es Parameter wie Stabilität und Benutzbarkeit, die sich praktisch gar nicht in Werte fassen lassen. Diese Parameter lassen sich oft nur durch feste Vorgaben anderer Parameter festlegen, indem beispielsweise bestimmt wird, unter welchen Voraussetzungen ein System als benutzbar gilt. Diese Angaben sind aber zwangsweise subjektiv. Wie sich später noch zeigen wird, ist dies ein wesentliches Problem im Bereich der Sicherheit.
Das Bestimmen der Parameter kann auf unterschiedliche Arten erfolgen: Entweder werden die Parameter vor dem Start des Dienstes festgelegt, oder es erfolgen als erstes Verhandlungen. Diese Verhandlungen wiederum können einmal zu Beginn der Nutzung eines Dienstes erfolgen, oder aber sie werden während der Nutzung bei Änderung der Umgebungsbedingungen wiederholt.
Die ersten beiden Ansätze sind statisch. Es erfolgt einmal eine Festlegung, die sich nicht wieder ändert. Nur der letzte Ansatz wird als dynamisch bezeichnet, da sich die Werte der Parameter während der Nutzung des Dienstes ändern können.
Werden die Parameter im Voraus festgelegt, so wird bei der Erstellung des Systems untersucht, wie es sich verhalten soll und wie die Randbedingungen sind. Daraufhin erfolgt die Entscheidung über Hardware und Software, die eingesetzt beziehungsweise erstellt wird. Ist der Dienst einsatzfähig, so sind die Eigenschaften dauerhaft festgelegt. Dies ist bei ISDN zum Beispiel der Fall.
Bei einmaligen Verhandlungen wird auf der Grundlage der zu Beginn herrschenden Bedingungen eine Übereinkunft festgelegt, welche Werte die Parameter annehmen sollen. Diese Werte werden dann während der ganzen Zeitdauer der Nutzung des Dienstes genutzt. Sollten sich die Bedingungen ändern (es fällt beispielsweise eine Leitung aus, so daß die Übertragungskapazität abnimmt), werden die Einstellungen nicht geändert.
Bei dynamischen Verhandlungen wird dies aber getan. Das bedeutet, daß zwar zu Beginn eine Übereinkunft festgestellt wird, diese Übereinkunft sich aber ändern kann. Dafür ist es notwendig, dauernd die erreichte Qualität zu überprüfen. Stimmt diese nicht mehr mit den Anforderungen überein, oder wäre eine bessere Qualität möglich, so werden die Parameter neu verhandelt. Telephonie-Dienste über das Internet, die auf dem IP-Protokoll basieren, sind hierfür ein gutes Beispiel.
Sicherheit wird gebraucht gegen nicht-autorisierte Versuche, auf Informationen zuzugreifen oder in Operationen einzugreifen.
Da, besonders durch das Internet, die weltweite Vernetzung immer größer wird, nimmt die Anzahl der möglichen Angriffspunkte immer weiter zu. Unternehmensnetze sind in vielfältiger Weise mit öffentlichen Netzen verbunden, und die Privat-PCs vieler Menschen sind meistens ohne jegliche Schutzvorkehrungen an das Internet angeschlossen.
Unternehmen sind in sehr großem Maße abhängig von der Verfügbarkeit ihrer Daten. Kein großes Unternehmen kann es sich leisten, selbst für einen kurzen Zeitraum ohne Zugriff auf interne Netze zu sein, geschweige denn die Unternehmensdaten zu verlieren.
Aber auch für Privatpersonen spielt das Thema Sicherheit eine große Rolle. Eine Person, die über das Internet Waren bestellt, möchte sicher sein, daß keine vertraulichen persönlichen Informationen (wie beispielsweise die Kreditkartennummer) an Dritte gelangt. Ebenso mag auf so manchem Rechner Informationen gespeichert sein, die nicht für die Allgemeinheit bestimmt sind (Steuerberechnungen für das Finanzamt, etc.).
Angriffe gegen Unternehmen können von verschiedenen Seiten erfolgen. So können fremde Personen versuchen, in die unternehmenseigenen Datennetze unberechtigt einzudringen, um Schaden anzurichten. Es könnten aber auch Konkurrenten sein, die an vertrauliche Informationen gelangen wollen. Schließlich haben viele Angriffe ihren Ursprung innerhalb der Organisation durch Angestellte.
Weiterhin gibt es natürlich die Gefahr, daß Systeme falsch bedient werden. Sicherheit der Daten bedeutet daher auch, die Daten gegen das unbeabsichtigte Löschen eines Mitarbeiters zu schützen.
Es gibt eine Reihe unterschiedlicher Sicherheitsaspekte. Diese sind in der folgenden Tabelle aufgegliedert, einschließlich möglicher Verfahren zur Verbesserung der Sicherheit bezüglich dieses Aspektes:
|
Aspekt |
Erklärung |
Verfahren |
|---|---|---|
|
Authentifizierung |
Überprüfung, ob ein Benutzer oder Dienst Zugriff zu einem Dienst erhält |
Kryptographische Funktionen, Ticket-Dienst, etc. |
|
Autorisierung |
Kontrolle, zu welchen Diensten Zugriff gewährt wird |
Zugriffskontrolllisten, etc. |
|
Vertraulichkeit |
Schutz von Informationen vor Einsicht anderer |
Verschlüsselung |
|
Datenintegrität |
Schutz der Informationen vor Änderungen |
Digitale Signaturen |
|
Anonymität |
Schutz der Privatsphäre |
Verwenden von Filtern oder Proxies, die persönliche Daten unkenntlich machen |
|
Verantwortlichkeit |
Zuordnung der Verantwortlichkeit zu Vorgängen |
Erstellen von Logdateien, Audit |
|
Urheberrecht |
Schutz der Urheberrechte |
Z.B. digitale Wasserzeichen |
|
Schutz gegen Angriffe |
Abwehr von nicht-autorisierten Zugriffen |
Einsatz von Produkten wie Firewalls |
Nachdem bisher Quality of Service und Sicherheit einzeln und unabhängig voneinander betrachtet und erläutert wurden, wird jetzt darauf eingegangen, wie beides bisher einzeln genutzt wurde und wie beide Funktionalitäten bisher miteinander interagieren. Weiterhin wird gezeigt, wo die grundsätzlichen Unterschiede und Gemeinsamkeiten von QoS und Sicherheit sind.
Das Konzept Quality of Service hat sich mittlerweile soweit durchgesetzt, daß es eine Reihe von Systeme gibt, die in der Lage sind, die Qualität von Diensten auszuhandeln. Gerade bei Neuentwicklungen im Kommunikationsbereich (wie beispielsweise neue Dienste für Mobilfunknetze) spielt QoS eine große Rolle. Weiterhin bieten Middleware-Systeme wie CORBA ([11]) der Object Management Group (OMG) Schnittstellen für QoS (z.B. [17]) und sehen dieses als eine der zentralen Anforderungen für Erweiterungen an.
Bei Sicherheit spricht man häufiger auch von der Quality of Protection im Vergleich zur Quality of Service. Leider ist diese Bezeichnung etwas irreführend, da Quality of Protection mit dem Maß oder der Stufe der Sicherheit gleichzusetzen ist und nicht mit der Güte.
Lösungsansätze zur Erhöhung des Grades der Sicherheit gibt es auf verschiedenen Ebenen: Diese reichen von abhörsicheren Lichtwellenleitern über Einzelprodukte zur Abschottung von Netzen bis hin zu Programmen, die durch Verschlüsselung Daten schützen. Diese Verfahren sind unterschiedlich eng an die Dienste gekoppelt, deren Sicherheit sie erhöhen sollen. Teilweise ist die Integration sehr eng, teilweise werden die Anforderungen an die Sicherheit völlig unabhängig von bestimmten einzelnen Diensten aufgestellt.
Die Integration von Quality of Service und Sicherheit und deren Interoperabilität fehlt bisher aber weitestgehend. Bei sicherheitskritischen Anwendungen fehlen meistens Schnittstellen zur Wahrung der Dienstequalität. Und bei Systemen, die Quality of Service anbieten, sind Sicherheits-maßnahmen, wenn vorhanden, fest integriert und nicht verhandelbar.
Um zu verstehen, warum es bisher nur wenige gemeinsame Ansätze gibt, muß man die beiden gewünschten Eigenschaften vergleichen. Dabei kann man feststellen, daß ein Hauptanliegen von QoS und QoP die Sicherstellung der Verfügbarkeit eines Dienstes ist. Folgende Skizze soll dies veranschaulichen:
Dabei geht es bei Quality of Service um Zuverlässigkeit und Performanz, wobei es bei Sicherheit um Aspekte wie Vertraulichkeit und Integrität geht. Bei genauerer Betrachtung läßt sich aber auch sehen, daß Quality of Service eine Sicherung des Dienstes gegen Störung und Ausfall darstellt, wohingegen Quality of Protection Sicherheit der Information im weiteren Sinne gegen Angriffe erwirken soll.
Geht es um konkrete Gemeinsamkeiten, so läßt sich zuerst einmal feststellen, daß es auch sicherheitsrelevante Funktionen gibt, bei denen Parameter ausgetauscht werden. Dies betrifft zum Beispiel verschlüsselte Datenübertragung, bei der zu Beginn der Kommunikation ausgehandelt wird, auf welche Art und mit welchen Algorithmen die Kommunikation erfolgen soll.
Der Standard in diesem Bereich ist das TLS-Verfahren (Transport Layer Security [16]), welches der Nachfolger von SSL (Secure Socket Layer) ist. Hierbei müssen beide Seiten, die eine Kommunikation aufnehmen wollen, bestimmte kryptographische Verfahren unterstützen. Beim Verbindungsaufbau wird ausgehandelt, welches Verfahren dabei genutzt wird. Je nach Verfahren ist die damit erfolgende Kommunikation unterschiedlich sicher geschützt.
Allgemeiner läßt sich feststellen, daß grundsätzlich alle Verfahren, die das Maß an Sicherheit erhöhen, die Qualität eines Dienstes bezüglich anderer Parameter beeinflussen. Da Sicherheit in den allermeisten Fällen durch zusätzliche Verfahren erreicht wird, werden dadurch Ressourcen verbraucht, die für die Erfüllung des normalen Dienstes nicht mehr zur Verfügung stehen.
Schließlich läßt sich feststellen, daß sowohl QoS-Funktionalitäten als auch sicherheitsrelevante Funktionen auf die gleichen Ressourcen zur Erfüllung ihrer Funktionen zurückgreifen. Dies sind beispielsweise die übermittelten Daten, aber auch weniger abstrakt der benutzte Speicher, der Übertragungskanal, usw. Dieser gemeinsame Zugriff muß so koordiniert werden, daß möglichst wenig Leistung und Sicherheit verloren geht.
QoS und Sicherheit weisen aber auch einige grundlegende Unterschiede auf. Um auf das Beispiel von TLS zurückzukommen: Im Prinzip gibt es auch bei diesem Verfahren kaum Entscheidungsmöglichkeiten. Grundsätzlich wird versucht, eine möglichst gute Übereinkunft zu erzielen. Dies wird dadurch erreicht, daß die besten gemeinsam unterstützten Algorithmen genutzt werden.
Dies hat mehrere Konsequenzen: Zum einen ist dabei gar nicht vorgesehen, daß irgend jemand eine Entscheidung trifft, welche Algorithmen genutzt werden sollen. Vielmehr wird davon ausgegangen, daß automatisch die beste Wahl getroffen wird.
Weiterhin ist von jedem Benutzer normalerweise die maximale Sicherheit gewünscht, die erzielt werden kann. Nur in den seltensten Fällen wird ein Benutzer bereit sein, eine geringere Sicherheit zu akzeptieren, um die Qualität anderer Dienste zu verbessern.
Dies führt zu der Schlußfolgerung, daß die Ansprüche an die Sicherheit in den meisten Fällen statisch sind. Eine einmal erfolgte Festlegung auf eine bestimmte Stufe der Sicherheit soll durchgehend bewahrt bleiben. Eine automatische Reduktion der Sicherheit, die vielleicht gar nicht mal offensichtlich angezeigt wird, ist nicht zu akzeptieren.
Das oben angeführte Argument, daß eine Verbesserung der Sicherheit immer mit einer Verschlechterung der Qualität der Dienste einher geht, muß man ebenso relativieren. Gerade im Bereich der Verschlüsselung steigt der Aufwand zur Verbesserung der Sicherheit nicht linear mit dem Grad der Sicherheit an. Die Benutzung des Algorithmus 3DES ist dreimal so aufwendig wie die des Algorithmus DES und benutzt einen Schlüssel doppelter Länge. Die Sicherheit wird dadurch derart größer, daß DES zwar relativ unsicher ist, es aber derzeit als nicht möglich erscheint, 3DES auch in der Zukunft mit herkömmlichen Methoden zu brechen. Der höhere Aufwand ist demgegenüber vernachlässigbar.
Das größte Problem der Nutzung eines Parameters Sicherheit für Quality of Service aber ist, daß es sehr schwierig erscheint, Sicherheit geeignet zu parametrisieren. Wie schon erwähnt, gibt es verschiedene Parameter für QoS, die nur schwierig mit Werten zu belegen sind. Für Sicherheit trifft dies in jedem Fall zu.
Zum einen mag ein Verfahren für eine Person ausreichend sicher sein, für eine andere Person aber nicht, da andere Ansprüche vorliegen. In welcher Form dies einem System übermittelt werden soll, bleibt ein Problem.
Nicht zuletzt hängt Sicherheit eng zusammen mit dem Begriff des Vertrauens. Sicherheit kann auch als das Maß des Vertrauens in die erwartete Funktionsweise des Systems gelten. Diese Form von Vertrauen aber unterliegt den subjektiven Anforderungen von Menschen.
Weder das Vertrauen in ein System, noch objektive Maßstäbe zur Bewertung von Sicherheit können dauerhaft sein. Viele Verfahren zur Erreichung von Sicherheit beruhen darauf, daß nicht bekannt ist, wie bestimmte mathematische Probleme gelöst werden können. Ebenso beruht die Sicherheit auf der fehlerfreien Implementierung dieser Verfahren. Wann immer es vorkommt, daß entweder neue Erkenntnisse bisher sichere Verfahren zu unsicheren Verfahren machen oder aber Fehler in Implementierungen gefunden werden, verändert sich der Grad der Sicherheit, den ein System mit den gleichen Verfahren erreicht. Damit unterscheidet sich Sicherheit fundamental von anderen Quality of Service Parametern.
In diesem Abschnitt werden nun verschiedene Systeme und Szenarien vorgestellt, die beispielhaft zeigen sollen, wie man sich eine Integration von Sicherheit und Quality of Service in verschiedenen Bereichen vorstellen kann. Zuerst werden Anforderungen der Object Management Group vorgestellt, danach Überlegungen zu einem System für vertrauliche Videokonferenzen skizziert und schließlich ein System beschrieben, das in einem lokalen Netzwerk eingesetzt werden könnte.
In der Object Management Group (OMG) organisiert sich eine große Anzahl von verschiedenen Herstellern, um gemeinsam den Middleware-Standard CORBA zu definieren. CORBA dient u.a. zur Realisierung verteilter Dienste auf unterschiedlichen Plattformen. Quality of Service ist schon seit längerem ein fester Bestandteil von CORBA. Eine Gruppe der OMG beschäftigt sich mit der Sicherheitsproblematik ([4]).
Daher ergeben sich hier automatisch Anforderungen an die Integration beider Bereiche. Neben einem White Paper von 1997 ([3]) existiert seit September 1998 ein sogenannter Request for Comments (RFC) zum Thema "Quality of Protection Management and Control" ([5]). In diesem RFC wird dazu aufgefordert, Entwürfe für eine Schnittstelle zwischen QoS und QoP zu entwickeln und zur Begutachtung einzubringen. Leider ist der Zeitraum schon verstrichen, in dem Entwürfe vorgestellt werden sollten, ohne daß es einen gegeben hätte.
Dieser RFC läßt sich in zwei Bereichen zusammenfassen. Zum einen wurden Anforderungen definiert, die solch ein System erfüllen muß: Es muß kompatibel zur bisherigen QoS-Architektur sein, Authentifizierung und Autorisierung unterstützen, Sicherheit in der Kommunikation unterstützen und Überwachungsfunktionen anbieten.
Die Ziele solch einer Erweiterung der bisherigen Architektur sind folgende: Einfachheit, Konsistenz mit existierenden Lösungen, Skalierbarkeit, Benutzbarkeit, Flexibilität und Interoperabilität.
Es ist davon auszugehen, daß sich die OMG weiterhin mit dem Thema befassen wird. Durch den Weg, den zu definierende Standards gehen müssen, ist aber derzeit nicht absehbar, wann die gewünschten Erweiterungen realisiert sein werden.
Als nächstes soll ein Anwendungsgebiet vorgestellt werden, in dem die Qualität des Dienstes und Sicherheitsbelange recht eng miteinander verzahnt sind: Ein Videokonferenzsystem, das vertrauliche Konferenzen an unterschiedlichen Standorten ermöglichen soll.
Solch ein System muß verschiedene Anforderungen erfüllen, die sich durch die schon erwähnten QoS- und Sicherheitsfunktionalitäten abdecken lassen: Jeder, der an einer Konferenz teilnimmt, muß sich zuerst anmelden und dazu die Erlaubnis erhalten. Die Kommunikation muß abhörsicher sein, und es darf niemand in der Lage sein, übertragene Informationen unbemerkt zu verändern. Die Qualität der Übertragung muß möglichst hoch sein, das bedeutet, pro Sekunde müssen möglichst viele Bilder übertragen werden, und für weitere Kommunikationsmittel wie einem gemeinsamen, verteilten Notizblock sind kurze Antwortzeiten nötig.
Die Aufgabe, die dieses System zu bewerkstelligen hat, ist, all diese Anforderungen mit den vorhandenen Ressourcen möglichst gut abzudecken. Die Anforderungen an die Qualität des Dienstes richtet sich in diesem Fall an alle Parameter, einschließlich der sicherheitsrelevanten.
Bei der Entwicklung eines Videokonferenzsystems mag es daher sinnvoll sein, Sicherheit als einen QoS-Aspekt anzusehen und entsprechend zu behandeln. Da enorme Datenmengen verschickt werden müssen, kann Verschlüsselung zur Erreichung der Geheimhaltung beispielsweise so viele Ressourcen verbrauchen, daß auf einem Rechner der Prozessor mit der Kodierung und dem Dekodieren der Bildinformationen nicht mehr mithalten kann.
Je nachdem, welchen Wert die Anwender auf Sicherheit und Benutzbarkeit legen, kann das System zu Beginn Parameter unterschiedlich aushandeln, um mal bessere Sicherheit zu garantieren, und mal eine angenehmere Darstellung zu ermöglichen.
In diesem Bereich gibt es derzeit noch eine Reihe von Forschungsvorhaben. Diese beziehen sich unter anderem darauf, wie man die enormen Datenmengen geschützt übertragen kann ohne alle Daten zu verschlüsseln. In [1] findet man eine gute Übersicht über verschiedene Ansätze dazu.
Das nun folgende Szenario zeigt, daß auch eine weniger enge Integration von Quality of Service und Sicherheit Sinn macht. In diesem Szenario kann man beides als Komponenten ansehen, die interagieren, um gemeinsam Reaktionen zu planen. Das folgende Schaubild soll verdeutlichen, wie solche Komponenten in einem Rechner-Netzwerk miteinander agieren könnten:
Die Quality of Service-Komponente ist dafür verantwortlich, daß die Dienste im Netzwerk so gut wie möglich verfügbar sind. Dies bedeutet beispielsweise, daß auf der Grundlage von benötigten bzw. erwarteten Antwortzeiten und Übertragungskapazitäten die Routing-Tabellen aufgestellt werden.
Die Quality of Protection-Komponente hingegen ist für die Sicherheit im Netzwerk verantwortlich. Alle Zugriffe auf Dienste müssen zuerst durch Funktionen dieser Komponente erlaubt werden. Weiterhin können Funktionen vorhanden sein, die automatisch jeglichen Datenverkehr verschlüsseln oder signieren. Allgemein gesagt soll diese Komponente den Schutz der Daten und der Dienste gewährleisten.
Wenn in einem solchen Netzwerk nun ein Rechner plötzlich ausfällt, müssen beide Komponenten das weitere Vorgehen planen. Der Fokus der QoS-Komponente liegt darin, zuerst die neuen Bedingungen festzustellen und darauf basierend Parameter neu zu verhandeln, Dienste möglicherweise zu ändern oder aber Routeneinträge zu modifizieren.
Die QoP-Komponente hat zur Aufgabe, den Vorfall zu untersuchen und festzustellen, ob dadurch die Sicherheit gefährdet sein könnte. Die Komponente muß klären, ob ein Angriff erfolgte, der möglicherweise auch nur ein Ablenkmanöver sein könnte, oder ob der besagte Rechner einfach nur einen Hardware-Ausfall hatte.
Beide Komponenten müssen nun miteinander kommunizieren, um das Handeln abzustimmen. Es muß in jedem Fall zu einer Übereinkunft kommen, die besagt, wie reagiert werden soll. Diese Übereinkunft mag sein, bestimmte Dienste oder gar das ganze Netzwerk zu sperren, falls die QoP-Komponente zum Schluß kommt, daß ein Angriff erfolgt war. Oder aber die QoS-Komponente bestimmt neue Werte für die Kommunikation.
Die Beurteilung in beiden Komponenten kann weitestgehend unabhängig stattfinden. Es muß aber gewährleistet sein, daß beide Seiten auf eine klar definierte Weise miteinander kommunizieren und alle wesentlichen Informationen austauschen.
Die Belange von Quality of Service und Sicherheit überschneiden sich teilweise, aber unterscheiden sich auch oder widersprechen sich gar. Dies wurde in der Betrachtung der Gemeinsamkeiten und Unterschiede dargestellt.
Gerade in der Kommunikation und Anbindung an Dienste aber erscheint eine Integration von Sicherheitsbelangen in ein Quality of Service-System sinnvoll. Dies kann entweder in der Form eines Sicherheit-Parameters geschehen, oder aber es werden einzelne Komponenten erstellt, die über fest definierte Schnittstellen miteinander kommunizieren.
Die Grundlage für Sicherheit als QoS-Parameter ist eine Festlegung auf bestimmte Anforderungen, die erfüllt sein müssen, um einen bestimmten Grad an Sicherheit zu erreichen. Wie schon ausgeführt, ist es schwer, dies objektiv zu bestimmen. Ein einmal bestimmtes System kann zwar immer die gleichen Verfahren zum Erlangen von Sicherheit aushandeln, nur können sich diese Verfahren plötzlich als nicht sicher herausstellen.
Die Forderungen, die an solch ein System zu stellen sind, kann man in Anlehnung an die OMG-Forderungen so aufstellen: Die neu zu schaffende Sicherheit-Funktionalität muß mit bisherigen Lösungen und Systemen konsistent sein und auf bestehenden Standards beruhen. Diese Funktionalität muß entweder in ein QoS-System integriert werden oder ausreichend interoperabel sein. Weiterhin ist es wichtig, daß eine hohe Flexibilität erreicht wird: Es muß möglich sein, Verfahren und Algorithmen auszutauschen, ohne die Architektur des Systems zu ändern. Und schließlich muß es einfach zu bedienen sein. Das bedeutet, daß die Sicherheitsaspekte möglichst transparent und einfach zu nutzen sind und sich in einer ähnlichen Weise wie andere QoS-Parameter verstehen und steuern lassen.
Es läßt sich somit eine Reihe von Problempunkten feststellen, die gelöst werden müssen. Zentral ist das Problem, wie sich Sicherheit überhaupt parametrisieren läßt. Dies hängt mit der Fragestellung zusammen, was eigentlich als "sicher" angenommen wird bzw. wovor etwas gesichert werden soll.
Der Einsatz eines Quality of Service-Parameters Sicherheit kann also sinnvoll sein. Dies kann aber nur komplementär zu anderen Technologien zum Erlangen von Sicherheit angesehen werden.
Diese Arbeit hat beschrieben, was Quality of Service ist, wo es eingesetzt wird und welche Sicherheitsaspekte es gibt. Davon ausgehend wurden die Gemeinsamkeiten und Unterschiede zwischen diesen Funktionalitäten erarbeitet. Verschiedene Systeme und Szenarien wurden vorgestellt, die gezeigt haben, wie eine sinnvolle, mal stärker, mal weniger starke Integration aussehen kann.
Die Schlußfolgerung war, daß es sinnvolle Anwendungen gibt, um Sicherheitsbelange eng mit einem QoS-System zu verkoppeln. Zwar macht dies nicht überall Sinn, und es kann auch nur ein Teil der verschiedenen Sicherheitsaspekte abgedeckt werden, aber in verschiedenen Bereichen könnten Fortschritte durch eine Integration erzielt werden.
Bisher gibt es aber nur wenige Arbeiten zu diesem Thema und es existieren nur wenige Ansätze für solche Systeme. Daher besteht weiterhin ein Forschungsbedarf, um durch konkrete Systeme oder Prototypen den Sinn und Nutzen solch einer Vereinigung von Quality of Service und Sicherheitsaspekten zu bestimmen.
Kunkelmann, Thomas: Sicherheit für Videodaten, vieweg, 1998
IETF: Internet
Protocol Next Generation (v6) Working Group,
URL:
http://www.ietf.org/html.charters/ipngwg-charter.html
Object Management Group: Quality of Service OMG Green Paper, Juni 1997
Object Management Group: OMG
Security SIG Home Page,
URL:
http://www.omg.org/homepages/secsig/
Object Management Group:
RFC: Quality of Protection Management and Control,
URL: http://www.omg.org/docs/orbos/98-11-23.pdf
International Workshop on QoS 1997, URL: http://www.ctr.columbia.edu/iwqos/
International Workshop on QoS 1998, URL: http://www-ece.rice.edu/conf/iwqos98/
International Workshop on QoS 1999, URL: http://www.cs.ucl.ac.uk/research/iwqos99/
Special Interest Group on QoS (GMD):
URL:
http://www.fokus.gmd.de/research/cc/tip/employees/jdm/private/jdmQoSIG.html
ITU: International Telecommunication Union (ITU) Home
Page,
URL: http://www.itu.int/
CORBA Research Overview:
URL:
http://siesta.cs.wustl.edu/~schmidt/corba-research-overview.html
Architectural Support for Quality of Service for CORBA
Objects,
URL:
http://www.dist-systems.bbn.com/papers/1997/TAPOS/TAPOS.html
Fallmyr, Stabell-Kulö: QoS applied to security in
mobile computing,
URL:
http://www.cs.uit.no/forskning/rapporter/Reports/9729.html
Siqueira: The Design of a QoS
Architecture for Open Systems,
URL:
http://www.cs.tcd.ie/Frank.Siqueira/PhD-Design/
Siqueira: Quartz, URL: http://www.dsg.cs.tcd.ie/research/quartz.html
IETF: Transport Layer
Security Working Group,
URL:
http://www.ietf.org/html.charters/tls-charter.html
OMG: CORBA Messaging,
URL:
http://www.omg.org/docs/orbos/98-05-06.pdf