Projektstudium SS98 - distributed computing

---

Ziele von objektorientierten Sicherheitssystemen

Die im folgenden aufgelisteten Ziele sind teilweise nicht gleichzeitig erreichbar. Sie stellen einige Schwerpunkte dar, die ein objektorientiertes Sicherheitssystem ganz oder teilweise erfüllen sollte. Es sind wie so oft die einzelnen Ziele mit den Anforderungen der Zielumgebung und den Ansprüchen der Firma (Entwickler ) zu vergleichen und in Einklang zu bringen.

• Einfachheit: Das Modell des Sicherheitssystems sollte einfach, verständlich und Wartbar sein. Das Bedeutet, es sollte wenige Konzepte und wenige Objekte beinhalten.

• Beständigkeit: Es sollte möglich sein beständige Sicherheit über das gesammte objektorientierte veteilte System und benachbarte Systeme zu gewährleisten. Das beinhaltet:

• Unterstützung der Beständigkeitspolitik für die Entscheidung, wer Zugriff auf welche Informationen in einer Securitydomain hat, die heterogene Systeme beinhaltet.
• Integrierbarkeit der schon bestehenden Mechanissmen für Zugriffsrechte
• Integrierbarkeit der schon existierenden Umgebungen. Zum Beispiel die Möglichkeit ende-zu-ende Sicherheit für Kommunikationsservices zu unterstützen, welche von Natur aus unsicher sind.
• Integrierbarkeit von existierenden Logons, so das keine weiteren Logons von nöten sind. Sowie die Übernahme der schon existierenden Benutzerdatenbank. (Dies ist wichtig um den Verwaltungsaufwand einigermaßen in grenzen zu halten.)

• Skalierbarkeit: Es sollte möglich sein Sicherheit für eine Reihe von Systemen zu unterstützen. Von kleinen, lokalen Systemen bis hin zu großen Intra- und Interunternehmungen sollte alles Unterstützt werden. Für große Systeme sollte es möglich sein:

• Grundzugangskontrollen basierend auf der vergabe von Privelegien für Benutzer einer Gruppe oder einer bestimmten gespielten Rolle um Verwaltungsaufwand zu minimieren.
• Die Einrichtung verschiedener Sicherheitsdomains mit jeweils unterschiedlichen Sicherheitspolitiken aber der Möglichkeit der Zusammenarbeit der Sicherheitspolitik betreffend.
• Verwalten der Verteilung von cryptographischen Schlüsseln innerhalb eines großen Netzwerkes, ohne administrativen Overhead zu verursachen.

• Benutzbarkeit für den Endanwender: Sicherheit sollte so transparent wie möglich gehalten werden, basierend auf fein einstellbare Standards. Benutzer sollten sich nur einmal in das verteilte System anmelden müssen, um Zugang zum Objektsystem und anderen Services zu erhalten.

• Benutzbarkeit für Administratoren: Das Sicherheitsmodell sollte einfach zu verstehen und verwalten sein. Es sollte nur eine einzige Systemsichtweise beinhalten. Es sollte für den Administrator nicht nötig sein die Kontrollen für individuelle Objekte oder Benutzer von Objekten zu spezifizieren, außer natürlich an den Stellen, wo es die gewählte Sicherheitspolitik dieses Vorschreibt. Das System sollte gute Flexibilität und Granularität unterstützen.

• Benutzbarkeit für Entwickler: Anwendungsentwickler sollten nicht mit allen einzelnen Sicherheitsaspekten vertraut sein müssen, um ihre Anwendung zu Schützen. Entwickler, die sich mit den einzelnen Sicherheitaspekten auskennen, sollte es darüber hinaus möglich sein besondere Anwendungsaktionen zu schützen.

• Flexibilität der Sicherheitspolitik: Die Sicherheitpolitik hat verschiedene Anforderungen von Unternehmen zu Unternehmen. Daraus folgt, das die Sicherheitsleistungen auswählbar sein sollten. Ein Unternehmen brauch dann nur für die Sicherheit bezahlen, die es auch benötigt. Die Reduzierung der Sicherheitsebenen für nicht sensible Daten spart Kosten. Dies ist beispielsweise auch nützlich wenn ein System weniger Anfällig für Sabotage oder anderen Bedrohungen ist. Dem Unternehmen sollte es möglich sein die Kosten von der unterstützten Sicherheitsebene( inclusive der benötigten Ressourcen, Administration und Wartung des laufenden Systems ) gegenüber den potentiellen Verlust von Daten (aufgrund von Sicherheitslücken) auszubalancieren.

• Besondere Arten der Flexibilität benötigen:
• Wählbarkeit der Zugriffskontrollenpolitik: Es sollten für die Zugriffskontrollen Schnittstellen definiert werden, die es ermöglichen die verschiedenen Mechanismen auszuwählen, aber alle Details versteckt halten. Nur bei einigen administrativen Funktionen und sicherheitsbewußten Anwendungen werden diese Einzelheiten zugänglich gemacht.
• Wählbarkeit der Prüfungspolitik: Die Ereignisse, die eine Prüfung verursachen lassen sich über Konfigurationenen individuell bestimmen. Dies macht es dann möglich die Größe der Prüfspur zu regulieren, und dementsprechend die Ressourcen für die Speicherung und Verwaltung.
• Unterstützung von Sicherheitsfunktionalitätsprofilen, definiert entweder als nationale oder internationale Regierungskriterien wie die ITSEC (European Information Technology Security Evaluation Criteria) oder wie sie bei kommerziellen Gruppen (wie X/Open) benötigt wird.

• Unabhängigkeit von Sicherheitstechnologien: Ein sinnvolles Sicherheitsmodell sollte von der gerade aktuellen Sicherheitstechnologie unabhängig sein. Zum Beispiel sollten Schnittstellen, definiert für ein Client-Objekt, die verwendeten Sicherheitsmechanismen verstecken. Es sollte ohne weiteres möglich sein symetrische oder aber auch asymetrische Schlüsseltechnologien für die Codierung zu nutzen. Es sollte möglich sein des Sicherheitsmodell auf einer großen Variation von exisierenden Systemen zu implementieren (jeweil unter Berücksichtigung der schon vorhandenen Infrastruktur). Es sollte zum Beispiel das schon bestehende Zugriffskontrollrepository oder Benutzerarchiev verwendet werden. Wenn das Sicherheitssystem in einer Umgebung, die ein prozedurales Sicherheitsregime birgt, installiert wird, dann sollte keine doppelte Verwaltungen für die zusammengesetzten Systeme anfallen.

• Anwendungsportabilität: Ein Anwendungsobjekt sollte nichts über Sicherheit wissen müssen. So kann es dann zu Umgebungen portiert werden, die unterschiedliche Sicherheitspolitiken und Sicherheitsmechanismen verfolgen. Wenn ein Objekt selbst Sicherheitsfunktionen durchführt, dann sollten Schnittstellen zu den Sicherheitsservices die besonderen Sicherheitsmechanismen verstecken. Die Anwendungssicherheitspolitik sollte mit der Systemsicherheitspolitik übereinstimmen. Es sind beispielsweise die Nutzungen von Objekten für die Zugriffskontrollen mit den selben Attributen auszustatten. Portabilität von Anwendungen verursacht ihre eigenen Sicherheitsabhängigkeiten auf den Attributen, die für die Anwendung sichtbar oder überhaupt verfügbar sind.

• Zusammenarbeit: Die Sicherheitsarchitektur sollte die Zusammenarbeit zwischen Objekten inclusive des folgenden erlauben:

• Unterstützen von gleichbleibender Sicherheit über ein heterogene System, wo denoch verschiedene Sicherheitsimplementationenen von verschiedenen Herstellern verwendet werden können.
• Zusammenarbeit von Sicherheitssystemen und Systemen ohne Sicherheitsarchitektur.
• Zusammenarbeit von Domains von einen verteilten System, wo verschiedene Domains auch verschiedene Sicherheitspolitiken verfolgen. (Zum Beispiel verschiedene Zugriffskontrollattribute bei den jeweiligen Domains)
• Zusammenarbeit zwischen Systemen, die verschiedene Sicherheitstechnologien unterstützen.

• Leistung: Sicherheit sollte nicht einen unakzeptablen Performanceoverhead verursachen. Eine implementation von höheren Sicherheitsebenen wird sicherlich immer einen Zusatz an Overhead bedeuten. Dieser sollte jedoch immer im Verhältnis zu der gewonnenen Sicherheit und Funktionalität stehen.

• Objektorientierung: Die Spezifikation sollte für das Sicherheitssystem objektorientiert sein:

• Die Sicherheitsschnittstellen sollten rein objektorientiert definiert sein.
• Das Modell sollte die Methoden der Einkapselung verwenden, um Systemintegrität zu gewährleisten und die Komplexität der Sicherheitsmechanismen unter einfachen Schnittstellen zu verstecken.
• Das Modell sollte es einen erlauben polymorphistische Implementationen von ihren Objekt, basierend auf verschiedenen darunter liegenden Mechanismen, zu entwickeln.

• Besondere Sicherheitsziele: In Ergänzung zu den zuvor erwähnten Sicherheitserfordernissen existieren weitere mehr speziefische erforderliche Dinge, die in einigen System nötig sind. So sollte eine vollständige und offene Sicherheitsarchitektur diese mit aufnehmen:
• Regulierende Erfordenisse: Das Sicherheitsmodell muß zu nationalen Regierungsbestimmungen Komform sein. Insbesondere im gebrauch von Sicherheitsmechanismen wie Cryptographie. Es existieren eine Reihe von Kontrollen: Exportkontrollen, Entwicklungskontrollen und Beschränkungen für die Chiffrierung von vertraulichen Daten um einige hier zu erwähnen. Einzelheiten varieren zwischen den verschiedenen Ländern. Beispiele für unterschiedliche Verlangen sind:

• Die Erlaubnis bestimmte cryptographische Algorithmen zu verwenden
• Die Menge von Chiffrierung von vertraulichen Daten auf ein Minimum halten
• Benutzung von Identifikatoren für die Prüfung, die anonym sind, außer für den Prüfer

• Entwicklung von Kriterien für Sicherungen: Die Sicherheitsfunktionalität und Architektur muß implementationen zu entsprechenden Standardsicherheitsentwicklungskriterien ermöglichen, wie ITSEC für Sicherheitsfunktionalität und Sicherungen. ( welche die verlangten Vertrauensebenen und die Korrektheit und Effizienz der Sicherheitsfunktionalität gibt) Die Sicherheitsarchitektur sollte Sicherheitsfunktionalitätklassen oder Profile bis zur Ebene E3/B2 ermöglichen. Es ist trotzdem als vorteilhaft zu betrachten, wenn auch Sicherheitskonzepte niedrigerer Ebene mit der Architektur unterstützt werden, für den Fall, daß andere Dinge gefordert sind, und die Performance eine wichtigere Rolle spielt.

• Ziele der Sicherheitsarchitektur: Die Sicherheitsarchitektur sollte sich bei der Sicherheitsschlüsselfunktionalität auf einen bewährten Kern beschränken, welcher die wesentlichen Teile der Sicherheitspolitik wie folgt beinhaltet:

• Sicherstellen, das die Objektaufrufe, wie in der Sicherheitspolitik entsprechend verlangt, geschützt sind.
• Das die verlangten Zugriffkontrollen bei Objektaufrufen durchgeführt werden.
• Verhindern von Störungen zwischen Anwendungsobjekten untereinander oder widersprechen von unauthorisierten Zugriffen auf deren Stati.

Die Sicherheitsarchitektur sollte kompatibel zu standard verteilten Sicherheitsframeworks, wie POSIX und X/Open sein.

Für einen tieferen Einstieg in die verlangten Kriterien von Sicherheitssystemen für verteilte Systeme ist es sinnvoll die entsprechenden Whitepapers der OMG heran zuziehen.