Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

01.02.1991 - 

Ein verläßlicher Zugriffsschutz muß in das Betriebssystem integriert sein

Zugriffskontrolle: Häufig sind die Systeme falsch eingestellt

Datensicherheit und Datenschutz beginnen mit einer wirksamen Zugriffskontrolle. Wie Gerhard Weck anhand der Schutzsysteme für MVS, VMS und Unix zeigt, ist Sicherheit hier durchaus möglich. Nicht selten jedoch wächst den Anwendern die Komplexität der Systeme über den Kopf.

Im wesentlichen sind es zwei Arten von Rechten, die es erlauben, die einem EDV-Benutzer möglichen Operationen zu kontrollieren:

- Zugriffsrechte, die bestimmen, auf welche Informationen die einzelnen Benutzer in welcher Weise zugreifen dürfen, und

- Funktionsrechte, die festlegen, welche Operationen die einzelnen Benutzer ausführen dürfen.

Gravierende Schwächen beim Paßwortschutz

In vielen Fällen sind beiderlei Rechte zu überprüfen, ehe einem Benutzer eine bestimmte Operation gestattet werden darf. Im allgemeinen erfordert eine Operation nicht nur das Vorliegen von Funktionsrechten; sobald sie auf Daten Bezug nimmt, werden dafür auch die entsprechenden Zugriffsrechte benötigt.

Bei der Kontrolle des Zugriffs auf Daten muß man zwischen den dafür eingesetzten Strategien einerseits und den zu ihrer Durchsetzung beziehungsweise Realisierung verwendeten Verfahren andererseits unterscheiden. Bei den Strategien handelt es sich im wesentlichen um die beiden Klassen der "diskreten Kontrollen" und der "globalen Zugriffsmodelle", wobei die ersteren meist von einem Eigentümermodell ausgehen, während die letzteren die Durchsetzung organisatorischer Richtlinien zum Ziel haben, die für alle Eigentümer von Daten bindend sind.

Bei Zugriffsrechten, die nach dem Eigentümer-Modell strukturiert sind, werden für jede Information im Rechner ein oder mehrere Benutzer als "Eigentümer" dieser Information betrachtet, und genau diese Benutzer haben das Recht, über die Zugriffsmöglichkeiten darauf zu entscheiden.

Ältere Verfahren zum Schutz von Dateien beruhen auf der Vergabe von Zugriffs-Paßwörtern; diese Verfahren werden in modernen Schutzsystemen wegen gravierender Schwächen nicht mehr angewendet. Schutzverfahren, die auf Eigentümer-Modellen beruhen, organisieren die Zugriffsschutz-Informationen meist in der Form von Zugriffsmatrizen oder

-listen. Diese Matrizen oder Listen legen für jeden einzelnen Benutzer und jede einzelne Datei fest, ob und gegebenenfalls welche Zugriffsrechte dieser Benutzer auf die betreffende Datei besitzt.

Zugriffsrechte auf individueller Basis

Globale Zugriffsmodelle beruhen zumeist auf Einteilungen der Daten und der Benutzer in Kategorien und Schutzklassen, wobei der gewünschte Zugriff nur dann ausgeführt wird, wenn bestimmte mathematische Beziehungen zwischen den Klassifikationen der Daten und denen der zugreifenden Benutzer vorliegen. Diese statischen Kontrollen können durch Überprüfung der Informationsflüsse in den zugreifenden Programmen ergänzt werden.

Während globale Kontrollen für die Sicherheit militärischer Systeme eine wichtige Rolle spielen, ist ihre Bedeutung und die Form ihres Einsatzes in einer kommerziellen Umgebung noch weitgehend unklar. Sie werden aus diesem Grund in den folgenden Ausführungen nicht weiter betrachtet.

Es ist im Prinzip möglich, für jedes Datenobjekt separat die dafür geltenden Schutzanforderungen anzugeben. Eine derartige Beschreibung der Zugriffskontrolle legt im wesentlichen für jeden Benutzer fest, welche Operationen er - eventuell unter bestimmten Randbedingungen - auf das Datenobjekt anwenden darf.

Wesentliches Charakteristikum dieser diskreten Schutzstrategie ist es, daß die Zugriffsrechte auf einer individuellen Basis festgelegt werden. Die Rechte, die ein bestimmter Benutzer auf ein bestimmtes Datenobjekt hat, beeinflussen weder seine Rechte auf andere Datenobjekte - zumindest solange diese von dem betrachteten Datenobjekt unabhängig sind

-, noch beeinflussen sie direkt die Rechte anderer Benutzer auf dieses Datenobjekt. Man spricht daher von "diskreter Kontrolle" der Zugriffsrechte beziehungsweise vom "benutzerbestimmbaren Zugriffsschutz".

Der Hauptvorteil diskreter Zugriffskontrollen ist ihre Flexibilität und Anpaßbarkeit an individuelle Schutzbedürfnisse und Zugriffserfordernisse. Durch die Vergabe einzelner Zugriffsrechte läßt es sich im Prinzip erreichen, daß jeder Benutzer auf genau die Datenobjekte in genau der Form zugreifen darf, für die er autorisiert ist.

Um die Vergabe der Zugriffsrechte formal beschreiben und damit steuern zu können, geht man bei diskreten Zugriffskontrollen im allgemeinen vom Konzept des "Eigentümers" eines Datenobjektes aus. Eigentümer ist im allgemeinen zunächst derjenige, der dieses Datenobjekt erzeugt beziehungsweise auf dessen Veranlassung es erzeugt wird. Der Eigentümer ist - bei personenbezogenen Daten - im allgemeinen nicht die Person, auf die sich die Daten beziehen, sondern die Person, die die Kontrolle über die Daten hat.

Bei Erzeugung eines Datenobjektes stehen seinem Eigentümer bestimmte Zugriffsrechte auf dieses Objekt zur Verfügung. Zu diesen Zugriffsrechten gehört insbesondere das Recht der Veränderung der Zugriffsrechte. Der Eigentümer kann, sofern er nicht ohnehin alle Zugriffsrechte auf dieses Objekt besitzt, seine Rechte erweitern, und ebenso kann er bei Bedarf - etwa um sich selbst vor Fehlern zu schützen - seine eigenen Rechte einschränken.

Ein wichtiges Recht, das dem Eigentümer eines bestimmten Datenobjektes zusteht, ist das der Vergabe und Rücknahme von Zugriffsrechten für andere Benutzer. Es ist eine wesentliche Eigenschaft des Eigentümermodells, daß die Vergabe aller Zugriffsrechte letztlich vom Eigentümer eines Datenobjektes kontrolliert wird. In manchen dieser Systeme ist es zwar möglich, daß der Eigentümer Rechte zur Kontrolle und auch zur Weitergabe der Zugriffsrechte an andere Benutzer weitergeben kann, doch ist letztlich er selbst die Quelle auch aller weitergegebenen Zugriffsrechte.

Die Basis für viele Systeme zur diskreten Zugriffskontrolle, die auf dem Eigentümermodell basieren, stellt das Modell der "Zugriffsmatrizen" dar. Dieses Modell läßt sich durch Schutzzustände und Übergänge zwischen diesen Zuständen beschreiben. Jeder dieser Schutzzustände wird durch den Inhalt einer sogenannten Zugriffsmatrix definiert, und Zustandsübergänge werden durch Operationen repräsentiert, die diese Matrix auf bestimmte Arten verändern.

Jede Zeile der Zugriffsmatrix enthält die Zugriffsrechte eines Benutzers, während die einzelnen Spalten durch die geschützten Objekte adressiert werden. In jeder Zelle der Matrix stehen die aktuell gültigen Zugriffsrechte des Benutzers, zu dessen Zeile diese Zelle gehört, auf das Objekt, zu dessen Spalte die Zelle gehört.

Operationen, die zu einer Änderung der Schutzzustände führen, dürfen prinzipiell nur dann ausgeführt werden, wenn der Benutzer, der diese Operation veranlaßt, auch der Eigentümer des betreffenden Objektes ist. Derartige Operationen können das Erteilen eines Zugriffsrechtes, sein Entzug oder eventuell auch der Wechsel des Eigentümers oder der Eintrag zusätzlicher Eigentümer sein.

Schutz kann zur Laufzeit ausgeschaltet werden

Allerdings ist das Zugriffsmatrix-Modell ohne geeignete Modifikationen für einen praktischen Einsatz noch nicht verwendbar. Dies liegt im wesentlichen daran, daß normalerweise die Zugriffsrechte sehr ungleich in dieser Matrix verteilt sind: Während einerseits bestimmte Objekte allgemein oder zumindest sehr weit verfügbar sein müssen, dürfen andererseits die meisten privaten Datenobjekte nur dem Eigentümer oder einer relativ kleinen Gruppe von Benutzern zugänglich sein. Dies bedeutet, daß - abgesehen von den systemweiten Objekten, deren Spalte üblicherweise für alle Benutzer dieselben Einträge enthält - die Matrix ziemlich leer ist. Berücksichtigt man nun, daß in einem größeren System die Anzahl der Benutzer leicht in die Hunderte oder Tausende geht, während die Anzahl der zu schätzenden Objekte noch um bis zu drei Größenordnungen darüber liegt, so kann man sich leicht vorstellen, daß es äußerst unpraktisch wäre, die Zugriffsmatrix direkt abzuspeichern; eine solche Matrix bestünde aus vielen Millionen Zellen, die fast alle leer wären. Aus diesem Grunde wurden für die praktische Realisierung des Matrix-Modells verschiedene Varianten entwickelt, die die Zugriffsmatrizen durch Abbildungen auf eine oder mehrere Listenstrukturen mehr oder weniger stark komprimieren.

MVS - Sicherheit nur als Systemaufsatz

Das Großrechner-Betriebssystem MVS verfügt selbst über keine wirksamen Verfahren zur Zugriffskontrolle; der über Dateipaßworte gebotene Schutz ist weder ein ernsthaftes Hindernis für einen potentiellen Angreifer, noch ist er im praktischen Betrieb sinnvoll zu verwalten. Aus diesem Grund werden von IBM und von Drittlieferanten Sicherheitspakete angeboten, die auf MVS installiert werden können und den benötigten Zugriffsschutz realisieren. Die wichtigsten davon sind RACF, Top Secret und ACF2.

Diese Pakete werden als installierbare Subsysteme außerhalb des Systemkerns geliefert. Sie benutzen eine von außen zugängliche Schnittstelle zu MVS, das Standard-MVS-Security-Interface (SU32). Das heißt, sie sind auf das Betriebssystem aufgesetzt und somit nicht im eigentlichen Sinne integriert. Es ist bei entsprechender Systemkenntnis möglich, einen Rechner, auf dem eines der Pakete installiert ist, ohne dieses Paket zu starten und damit jegliche Kontrolle zu umgehen. Es ist teilweise auch möglich, durch die Änderung von Steuerparametern des Betriebssystems zur Laufzeit, den Schutz völlig auszuschalten. Der hierdurch gebotene Schutz ist damit niedriger als bei Systemen, deren Zugriffskontrolle direkt in das Betriebssystem integriert ist. Dennoch ist er erheblich höher als bei einem ohne Sicherheitspaket betriebenen MVS.

RACF: Das IBM-eigene System RACF (Resource Access Control Facility) schützt Objekte - die hier als Ressourcen bezeichnet werden - gegen unerlaubte Zugriffe durch sogenannte Benutzer-"Profile". Jedes Profil enthält Namen und Paßwort des Benutzers, wobei das Paßwort durch eine Verschlüsselung mit dem DES-Algorithmus gegen Offenlegung geschätzt ist. Mehrere Benutzer können zu einer "Gruppe" zusammengefaßt werden. Zwischen dem einzelnen Benutzerprofil und dem Gruppenprofil verbindet ein Anschlußprofil. In den Profilen wird durch "Attribute" festgelegt, welche Funktionen der jeweilige Benutzer ausführen

darf.

RACF organisiert den Zugriff auf Objekte ebenfalls über Profile in der RACF-Datei. Neue Ressourcen-Profile für Dateiobjekte werden automatisch in die RACF-Datei eingetragen, wenn der erstellende Benutzer dies implizit durch ein Attribut oder explizit durch einen Befehl verlangt. Die Profile für andere Ressourcen und die Profile für die bei der Installation von RACF bereits vorhandenen Dateiobjekte muß der Systemverwalter explizit in der RACF-Datei definieren.

Andere Ressourcen als Dateien werden in einem "allgemeinen Ressourcen-Profil" definiert, das sie mit einem jeweils eindeutigen Namen in eine Ressourcen-Klasse einreiht. Schützbare Klassen sind PIattenstapel, Bandstationen, Bänder, Terminals, Transaktionen oder Transaktionsgruppen unter einem IBM-Terminal-Monitor und Anwendungsprogramme.

Um RACF zu aktivieren, muß es durch Systemgenerierung eingebunden werden. Bei jedem SVC verzweigt MVS zur Sicherheits-Schnittstelle. Wenn diese Schnittstelle durch ein Sicherheitssystem versorgt ist, so werden die Prüfungen dieses Sicherheitssystems, also in diesem Falle von RACF, durchlaufen.

Top Secret: Dieses System schützt Transaktionen, Terminals, Kommandos, Programme, Dateien, Datenträger und CPUs, wobei dieser Schutz jeweils explizit definiert oder als Default vorgegeben sein kann. Subsysteme wie CICS, TSO oder eines der Batchsysteme können ebenso geschätzt werden, wobei für jedes Subsystem eigene Schutzregeln gelten können. Es ist auch möglich, benutzerspezifische Objekte zu definieren und durch Top Secret schützen zu lassen. Dazu gehören insbesondere die Felder einer Datenbank.

Die Zugriffsregeln von Top Secret sind an die einzelnen Benutzer gebunden, die jeweils durch eine sogenannte "Accessor Identification" (ACID) definiert werden. ACIDs können für Benutzer, Abteilungen, Bereiche, Verwalter und Profile festgelegt werden, wobei Profile zur Gruppierung von Benutzern mit ähnlichen Zugriffsrechten verwendet werden.

Top Secret organisiert den Zugriff auf Objekte hierarchisch; zu jedem Benutzer gibt es nur einen organisatorischen Pfad in die höheren Ränge der Hierarchie.

Zugriffsprofile werden schrittweise eingeführt

Der Betrieb von Top Secret kann in verschiedenen Modi erfolgen. Damit wird beispielsweise festgelegt, ob das System unerlaubte Zugriffsversuche nur meldet oder sie auch wirklich abweist, und ob Zugriffsversuche von Benutzern ohne zugewiesene ACID abgewiesen oder mit Default-Zugriffsrechten durchgeführt werden. Hierdurch ist es während der Installationsphase des Produktes möglich, die Zugriffsprofile allmählich einzuführen und auf ihre Wirksamkeit und Korrektheit hin zu überprüfen, ohne daß abgewiesene Zugriffsversuche laufende Anwendungen zum Absturz bringen.

ACF2: Die Organisation der Benutzer wird bei ACF2 mittels einer frei definierbaren Menge von Identifikatoren dargestellt. Für jeden Benutzer muß jedem Identifikator ein Wert zugeordnet sein. Bedingung ist, daß alle Benutzer innerhalb einer ACF2-Installation durch den gleichen Satz von Identifikatoren beschrieben werden. Durch eine Verkettung dieser Werte entsteht ein String, der User-Identifier (UID). Dieser String regiert die Zugriffsmechanismen unter ACF2.

Von ACF2 schützbare "Ressourcen", also Objekte, können Dateien, Plattenstapel, Laufwerke, Bänder, Bandstationen, einzelne Transaktionen oder Transaktionsgruppen unter CICS oder einem ähnlichen Transaktionsmonitor sein. Es ist möglich, installationsspezifische Ressourcen zu definieren. Grundsätzlich kann ACF2 den Zugriff auf diese Ressourcen kontrollieren.

ACF2 organisiert den Zugriff auf Objekte durch die Angabe von Zugriffsregeln je Objekt oder Objektklasse. Da in der Liste von Zugriffsmöglichkeiten, die an einem Objekt oder

einer Objektklasse hängen, mehrere UID-Spezifikationen hängen können, von denen mehr als eine auf einen gegebenen UID zutreffen können, muß die Liste der UID-Spezifikationen geordnet sein.

Die Zugriffsentscheidung wird getroffen, indem zunächst mit der vollen Objektqualifikation nach einem entsprechenden Zugriffskontrolleintrag gesucht wird. Existiert ein solcher, wird die dort vorgefundene UID-Liste ausgewertet. Ansonsten wird die volle Objektqualifikation reduziert (hintere Teile werden entfernt) und nach dem Klasseneintrag gesucht. Führt auch das nicht zum Erfolg, wird der Zugriff verweigert. Weil beim Durchsuchen der UID-Liste nur der erste passende UID-Eintrag ausgewertet wird, müssen die Einträge, wie gesagt, eine geeignete Reihenfolge aufweisen.

VMS bietet standardmäßig einen benutzerbestimmbaren Zugriffsschutz, der die Kontrolle des Zugriffs einzelner Benutzer auf einzelne Objekte erlaubt. Realisiert wird dieser Schutz einerseits durch die Festlegung UIC-bezogener Zugriffsrechte, wobei unter UIC ein sogenannter "User Identification Code" verstanden wird, andererseits wird es durch Zugriffskontroll-Listen ("Access Control Lists", ACLs) erweitert.

VMS bestimmt die aktuellen Zugriffsrechte eines Benutzers auf ein durch Zugriffskontroll-Listen geschätztes Objekt, beispielsweise eine Datei, indem die einzelnen Elemente der Liste der Reihe nach auf ihre Anwendbarkeit auf den betreffenden Benutzer untersucht werden. Ein Element wird dabei als anwendbar betrachtet, wenn der Benutzer über alle in dem Element angegebenen Zugriffsschlüssel ("Identifier") verfügt.

Flexibler und komplexer Zugriffsschutz bei VMS

Sobald ein anwendbares Zugriffskontroll-Element gefunden ist, werden die darin angegebenen Zugriffsarten mit der vom Benutzer gewünschten Zugriffsart verglichen und je nach dem Ergebnis dieses Vergleichs wird der Zugriff gestattet oder abgelehnt. Weitere Prüfungen erfolgen dann nicht mehr; ist die Entscheidung über ein anwendbares Zugriffskontroll-Element getroffen, werden weder der Rest der Zugriffskontroll-Liste noch der über den UIC spezifizierte Zugriffsschutz berücksichtigt. Die einzige Ausnahme von dieser Regel ist die Anwendung der Prozeß-Privilegien: Wenn ein Zugriff über die Zugriffskontroll-Liste abgelehnt wurde, kann er dennoch gewährt werden, wenn der Prozeß über erhöhte Privilegien verfügt, die ihn dazu berechtigen.

Wenn in der gesamten Zugriffskontroll-Liste kein anwendbares Element gefunden wurde, wird der Zugriff entsprechend den über den UIC spezifizierten Zugriffsrechten gewährt oder abgelehnt. Dieser UIC-basierte Zugriffsschutz legt die erlaubten Zugriffsarten für die vier Benutzergruppen "System", "Eigentümer", "andere Benutzer innerhalb der Projektgruppe", "alle anderen Benutzer" fest. Falls der UIC-Zugriffsschutz den Zugriff verbietet, kann der Zugriff dennoch gewährt werden, wenn der Prozeß über Privilegien verfügt.

Dieses zweistufige Verfahren über ACLs und UICs erlaubt eine extrem flexible und gleichzeitig - bei sinnvoller Definition von Zugriffsschlüsseln als Äquivalenzklassen von Benutzern - leistungsfähige, die Performance wenig beeinträchtigende Steuerung der Zugriffe auf Datenobjekte, die allen Anforderungen diskreter Zugriffskontrollen genügt. Als Nachteil ist lediglich die nicht unbeträchtliche Komplexität des Verfahrens zu nennen, die gerade einem Anfänger bei der Einrichtung der Schutzstrukturen erhebliche Schwierigkeiten bereiten kann.

Die Zugriffskontrolle unter Unix ist ähnlich wie der UIC-Schutz in VMS aufgebaut: Die erlaubten Zugriffsarten - Lesen, Schreiben, Ausführen - werden jeweils für den Eigentümer, für andere Benutzer in derselben Gruppe und für alle anderen Benutzer ("World") in einer Bitliste spezifiziert. Da Benutzer mehreren Gruppen angehören können, ist es möglich, überlappende Gruppen zu definieren und so die Zugriffsrechte spezifischer an aktuelle Erfordernisse anzupassen.

Unix: Sicherheit bis zum totalen Chaos möglich

Bei der Bestimmung der Zugriffsrechte eines Benutzers wird jedoch nicht in jedem Fall die Identität des zugreifenden Benutzers zugrundegelegt: Der Eigentümer einer Datei kann festlegen, daß für den Zugriff seine eigenen Rechte (oder die seiner Gruppe) anstelle derer des Zugreifers zu verwenden sind. Damit ist es möglich, Zugriffsrechte an bestimmte Programme zu binden, gleichzeitig jedoch entstehen höchst unübersichtliche oder sogar gefährliche Rechtebeziehungen, die zum Unterlaufen der Sicherheit des gesamten Systems mißbraucht werden können. Beispielsweise half diese Eigenschaft des Unix-Betriebssystems den "KGB-Hackern", sich in vielen Maschinen Systemverwalterrechte zu verschaffen.

Ein weiteres Problem der Zugriffskontrolle unter Unix besteht darin, daß die Bestimmung der Gruppenzugriffsrechte neuer Dateien in verschiedenen Unix-Varianten unterschiedlich gehandhabt wird: In BSD-Unix wird die Gruppe über den Datei-Katalog bestimmt, während System V die Gruppe des Eigentümers zugrundelegt; in einigen Systemen, wie zum Beispiel SUNOS kann die Gruppensemantik sogar katalogspezifisch gemäß BSD oder System V gewählt werden, womit sich ein beliebiges Chaos erzielen läßt.

Der Katalog, in dem ein zu startendes Programm zu suchen ist, wird über einen vom Benutzer bestimmbaren Suchpfad festgelegt. Eine unzweckmäßige Festlegung oder Manipulation dieses Suchpfades kann zur Folge haben, daß anstelle des gewünschten Programms ein völlig anderes aufgerufen wird; insbesondere können auf diese Weise "Trojanische Pferde" zur Ausführung gebracht werden. Es gibt zwar Empfehlungen, wie ein sicherer Suchpfad definiert werden kann, doch ist der vom System vorgegebene Suchpfad nicht sicher.

Fazit: Ein Betrieb mit Unix erfordert erheblichen Aufwand und sehr gute Kenntnisse des Systemverwalters. Nur wenn eine Reihe von Voreinstellungen geeignet angepaßt werden und wenn im laufenden Betrieb sehr genau kontrolliert wird, daß keine unerwünschten Zugriffsrechte entstehen, läßt sich die Sicherheit eines Unix-Systems aufrechterhalten. Schon geringste Modifikationen an einigen Stellen, die ohne ein sehr gutes Verständnis der Mechanismen durchgeführt werden, führen mit einiger Wahrscheinlichkeit zu einem völligen Zusammenbruch jeglichen Schutzes. Durch diverse Hacker-Vorfälle wurde dies eindrucksvoll demonstriert.

Falsch eingestellt hilft das beste System nichts

Die hier beschriebenen Zugriffskontrollsysteme unterscheiden sich zwar in vielen Einzelheiten, doch sind genügend Gemeinsamkeiten festzustellen, um die grundsätzlichen Stärken und Schwächen der ihnen zugrundeliegenden Verfahren zu erkennen. Man stellt dabei die folgenden allgemeinen, systemunabhängigen Tatsachen fest:

- Die in einem größeren Betriebssystem zu verwaltenden Informationsmengen sind in den meisten Fällen nicht nur sehr umfangreich, sondern sie verfügen auch über höchst komplexe Strukturen und Abhängigkeiten, aus denen sich dann ihrerseits oft sehr komplexe Schutzanforderungen ergeben. Diese Anforderungen lassen sich zwar in den meisten Fällen auf geeignete Strukturen in den einzelnen Zugriffskontrollsystemen abbilden, doch ist die Abbildung nicht immer einfach oder überschaubar.

- Dies führt in der Praxis häufig dazu, daß Zugriffsrechte falsch und/oder vereinfacht vergeben werden. Die Folge ist, daß schützenswerte Daten eventuell unzureichend geschätzt sind oder daß umgekehrt Zugriffe unnötig abgewiesen werden. Beispielsweise werden in MVS-Systemen die Zugriffsrechte oft identisch für alle Dateien vergeben, deren Qualifikation mit denselben Zeichen anfängt. Tatsächlich jedoch würden einzelne dieser Dateien einen höheren oder niedrigeren Schutz benötigen. In VMS dagegen findet man häufig einen inadäquaten Schutz, wenn nur der UIC-bezogene Zugriffsschutz verwendet wird, obwohl ein Schutz über Zugriffskontroll-Listen erforderlich wäre.

- Oft läßt sich die Verwaltung der Zugriffsrechte durch die Vergabe geeigneter Default-Schutzattribute stark vereinfachen. So wäre beispielsweise der Schutz über Zugriffskontroll-Listen in VMS kaum handhabbar, wenn nicht Verfahren zur automatischen Erzeugung und Propagierung dieser Listen verfügbar wären. (Aufgrund dieser Erfahrung läßt sich jetzt schon sagen, daß die Implementierung von Zugriffskontroll-Listen, die in einigen "sicheren"

Unix-Systemen vorgesehen ist, ohne solche Default-Mechanismen in der Praxis unbrauchbar sein werden.)

Trotz dieser Schwierigkeiten - die in Einzelfällen zu Ineffizienzen oder zu einer falschen Anwendung des Schutzes führen können - wird die Zugriffskontrolle über Zugriffsmatrizen inzwischen (mit Ausnahme der Unix-Umgebung) weitgehend beherrscht. Für die gängigen System-Umgebungen stehen entweder geeignete Sicherheitspakete zur Verfügung, die bei richtiger Anwendung einen guten Schutz gegen viele Mißbrauchsmöglichkeiten bieten, oder diese Kontrollen sind schon direkt in das Betriebssystem integriert, wodurch sich ein optimaler Schutz erzielen läßt.

Generell läßt sich sagen, daß mit den hier betrachteten Systemen für viele Anwendungen eine ausreichende oder sogar gute Zugriffskontrolle realisierbar ist. Bei Übertragung der so geschätzten Anwendungen und ihrer Daten auf PCs oder Arbeitsplatzrechner, wozu auch die meisten Unix-Systeme zu rechnen sind, geht dieser Schutz allerdings in den meisten Fällen verloren, so daß die individuelle Datenverarbeitung, was die Zugriffskontrolle angeht, als ziemlich gefährlich einzuschätzen ist.