Objekte in vernetzten und verteilten Systemen

Kommentieren Drucken
Teil 51 von 71 aus der Serie "Professionelle Datenkommunikation"
Alle Artikel der Serie "Professionelle Datenkommunikation":

Wir befassen uns jetzt mit Angriffen auf offene, also nicht geschlossene Systeme, wie sie normalerweise durch ein Netz gebildet werden, und deren Unterbindung. Dazu wollen wir zunächst konzeptionelle Aussagen treffen, dann die Angriffsmöglichkeiten an Netzwerken aufzeigen und mögliche Lösungen diskutieren, die sich neben den allgemeineren Verfahren für die Datensicherung durch Verschlüsselung ergeben.

Ein Intranet, das Internet und im Allgemeinen ein verteiltes Rechensystem besteht aus einer Menge von Stellen (angeschlossene Rechner, Clients und Server) und einem Nachrichtennetz (LAN, WAN, …). Die Stellen sollen Systeme mit den Eigenschaften eines geschützten geschlossenen Systems sein.

Dies ist in der Praxis zwar meist schon nicht gegeben, wir kommen aber an dieser Stelle ohne diese Voraussetzung überhaupt nicht mehr weiter und diskutieren später über sich aus dieser Diskrepanz ergebende Konsequenzen.

Ziel aller Bemühungen um sichere vernetzte und verteilte Systeme ist: Das Netz und die verschiedenen an ihm angeschlossenen Rechner bleiben völlig verdeckt. Jeder Benutzer arbeitet auf einem einheitlichen Systembild (Single System Image) mit seinen Zugriffsrechten genau so, als läge ein lokales geschlossenes System vor. Dies entspricht ja auch der heutigen Sicht, bei der z. B. ein Benutzer an einem PC-Netz gar nicht mehr sieht, ob die Ressource, die er aufruft, z. B. eine Datei, nun bei ihm in seinem Rechner oder in irgendeinem anderen Rechner abgespeichert ist. Ein Angriff ist nach wie vor der Versuch, ohne Zugriffsrechte an Objekte oder Operationen zu kommen.

Das Nachrichtennetz besitzt leider folgende Eigenschaften, wie wir noch weiter unten ausführen werden:

  • Passive und aktive Angriffe können nicht vermieden werden,
  • alle aktiven Angriffe sind Ausführungen von Operationen auf Objekten des Systems.

Wir gehen zur weiteren Vertiefung zum Beispiel davon aus, dass in unserem System zwei Prozesse (Subjekte) p und q existieren, die in einer Auftraggeber-Auftragnehmer-Beziehung (Client/Server) zueinander stehen, wobei p der Auftraggeber (Client) und q der Auftragnehmer (Server) sei. Dies tut der Allgemeinheit Genüge, da praktisch alles in Kommunikationssystemen auf dieser Basis abläuft und auch Peer-to-Peer-Systeme nichts weiter als »Vollduplex-Client/Server«-Systeme sind, bei denen eine Station (Instanz, Objekt) sozusagen wechselweise Client und Server ist. Auch alle bekannten in Intranets vorkommenden Kommunikationskonzepte lassen sich hierunter einordnen. Von den zwischen p und q in Frage kommenden Kommunikationskonzepten wählen wir das asynchrone Rendezvous, wie es z. B. in der Programmiersprache ADA explizit, in anderen Programmiersprachen oder Protokollstacks aber durchaus implizit definiert wurde.

Der Auftragnehmer (Server) q definiert eine Operation, die er nach außen zur Verfügung stellt:

service op (X: in ein; Y: out aus);

sei die Aufruf-Spezifikation der Operation, wobei die Typen ein und aus als definiert vorausgesetzt werden. Auch dies ist sehr allgemein, weil man in Kommunikationsbeziehungen Dienste aufrufen möchte und Ein- sowie Ausgaben für diese Dienste üblicherweise genau spezifiziert sind. So könnte z. B. ein Message Handling System-Server seinen Benutzern die Operation

service leite weiter (X: in brief; Y out brief);

mit einem vorher definierten Typ »brief« anbieten.

Der Auftraggeber p kennt den Server q und die von q zur Verfügung gestellte Operation einschließlich der Parameter-Typen. p hat ein qualifiziertes Zugriffsobjekt q_ref als Komponente verliehen bekommen, das p zum Aufruf von op auf q berechtigt. p enthält einen Aufruf

q_ref.op(a,b);.

Die Zusammenarbeit von p und q ist somit unter Einbeziehung des Rendezvous-Konzepts klar: p ruft die Operation auf und wartet, q führt sie zu gegebener Zeit aus und gibt das Ergebnis an p, p macht danach weiter.

Wenn nun p und q an zwei verschiedenen Stellen (Stationen, Rechner) des Rechensystems implementiert sind, bedarf es einer Verwendung des Nachrichtentransportsystems zwischen diesen beiden Stellen. sp und sq seien diese Stellen (Stationen, Rechner) und kp und kq die die Kommunikation realisierenden Objekte bezüglich p und q, also die Protokollstacks, die dafür sorgen, dass p und q überhaupt kommunizieren können. Bezogen auf die Architekturen, wie sie in einem Intranet vorliegen, bedeutet dies: Die Stellen sp und sq beinhalten die Rechner- und Kommunikationshardware, z. B. LAN-Anschlüsse nach IEEE 802 mit der Schnittstelle LLC. kp und kq sind die auf dieser Hard- und Firmware arbeitenden Protokollstacks der Schichten 3 bis 7, also einschließlich der anwendugsorientierten Grunddienste.

Nach wissenschaftlichen Untersuchungen der späten 70er und frühen 80er Jahre sind an diese Realisierung die folgenden Anforderungen zu stellen, wenn das Ergebnis eine vollständig sichere Kommunikation sein soll:

  • kp und kq sind authentisch, also »echt«,
  • kp und kq arbeiten ausschließlich für p und q,
  • die Zusammenarbeit zwischen p und kp bzw. q und kq ist sicher,
  • kp und kq sind funktional korrekt,
  • der Nachrichtenaustausch zwischen kp und kq ist sicher.

Authentizität von kp und kq bedeutet, dass kp und kq eigenständige Objekte im Rahmen einer geordneten Realisierung sind. Sie dürfen nicht durch andere Komponenten nachgebildet (»emuliert«) werden, weil sonst die Eindeutigkeit des Kontrollflusses nicht mehr gegeben ist. Wenn man es ganz genau nimmt, müsste die Funktionsweise jedes Elementes im Protokollstapel durch einen mathematischen Beweis der Korrektheit »abgesegnet« sein. Dies wäre auf den Schichten 3 und 4 durchaus möglich, bei höheren Schichten steht die Komplexität der Verfahren dem im Wege. Das bei Intranets verwendete TCP/IP ist aber für 3/4 schon zu komplex. kp und kq dürfen nur ausschließlich für p und q arbeiten. Ist dies nicht der Fall, so könnten andere Elemente, die ebenfalls mit kp und kq arbeiten, Informationen über den Inhalt der Kommunikation bekommen, da sich die Informationsströme in den virtuellen Speichern mehrfach genutzter Protokollstapel mischen. Es ist nicht sicherzustellen, dass ein weiterer Benutzer des Protokollstapels nicht beginnt, Kopien durchlaufender Informationen anzufertigen.

Gleiche Bedenken gelten für die Schnittstellen: Wenn die Kommunikation zwischen Client/Server und den betreffenden Schnittstellen nicht sicher ist, ist der ganze Aufwand umsonst, weil sich auch hier noch andere Subjekte andocken können und Information abzweigen.

Alle Forderungen bis auf die letzte könnten aber dennoch lokal in jedem Rechner durch die gleichen Maßnahmen wie bei geschlossenen Systemen durchgesetzt werden. Dies nützt jedoch nichts, denn der Nachrichtenaustausch zwischen kp und kq kann vielfältigen Angriffen ausgesetzt sein, die die verschiedensten Ursachen haben.

Zunächst gehen wir davon aus, dass es keine weiteren Objekte gibt, die das Nachrichtennetz benutzen und auch keine, die es von außen angreifen wollen.

Schon diese Forderung ist in der Realität schwierig durchzusetzen. Die korrekte Funktionalität des Nachrichtennetzes kann dann durch verschiedene Maßnahmen in einem hohen Maße abgesichert werden, wie Fehlerkontrolle, Wiederaufsetzen nach Fehlern, Korrektheitsbeweise für Protokollimplementierungen, fehlererkennende und -korrigierende Codes auf der Leitungsebene.

In der Praxis ist die o.g. Annahme natürlich alleine dadurch hinfällig, dass es in einem Netzwerk mehr als zwei Teilnehmer gibt. Informationen, die zwischen kp und kq ausgetauscht werden sollen, müssen demnach, wenn sie von anderen Teilnehmern nicht gelesen bzw. verfälscht werden sollen, durch entsprechende Maßnahmen wie kryptographische Verfahren geschützt werden.

« Teil 50: Schutz von Objekten in verteilten UmgebungenTeil 52: Schwachstellen der Informationssicherheit in Netzen und Absicherungsmaßnahmen bis zur Schicht 5 »


zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.