Nachdem ich mich in letzter Zeit vermehrt mit Metadaten beschäftigt habe, wird mir immer klarer, dass dort das Thema Security nicht vernachlässigt werden darf, aber auch nicht trivial ist -- insbesondere in einer Installation, bei der die meisten Komponenten mittels Metadaten verbunden sind und der Metadatenserver also einen Single Point of Failure darstellt.

Hier einmal konkrete Punkte, die mir aufgefallen und zum Teil unklar sind, in der Hoffnung eine Diskussion in Gang zu bekommen:

1. Die nach Installation vorliegenden Standardberechtigungen (Access Controls) für die Metadaten bieten fast keinerlei Schutz vor unbefugtem Verändern systemkritischer Metadaten. Man sollte unbedingt die Schutzmaßnahmen durchführen, die im SAS 9.1.3 Intelligence Platform - Security Administration Guide (Second Edition) vom Juni 2007 auf den Seiten 67 ff. (Protecting the Foundation Repository) beschrieben sind.

2. Es ist mitunter schwer zu verstehen, welche Berechtigungen ein bestimmter Nutzer für ein bestimmtes Metadatenobjekt effektiv bekommt, da es mehrere Ebenen der Vererbung gibt (nämlich einerseits von Nutzergruppen auf Mitglieder und andererseits entlang bestimmter Metadatenassoziationen, z.B. von einem Tree auf seine Members). Hier sollte man sich sehr eingehend das Entscheidungsdiagramm auf S. 47 des Security Administration Guide anschauen und sich merken, dass die in der Metadatenkonsole (SMC) angezeigten grau hinterlegten Rechte nicht immer tatsächlich effektiv sind und bei bestimmten Metadatentypen (z.B. Logins) weitere spezielle Zugriffsregeln wirken, die in der SMC nicht sichtbar sind.

3. Es ist ebenfalls nicht offensichtlich, welche Rechte man überhaupt für die verschiedenen Aufgaben benötigt, insbesondere für welche Objekte man alles ein Schreibrecht benötigt, um mit ihm assoziierte Objekte erstellen oder löschen zu können. Beispielsweise benötigt man Schreibrecht an einem ServerComponent-Objekt, wenn man mit ihm assozierte Pfade oder Datenbankschemen in den Metadaten registrieren möchte.

4. Um Rechte-Vererbungen entlang von Metadatenassoziationen nachvollziehen zu können, fehlt aber im Security Administration Guide leider eine entscheidende Information, nämlich eine Liste aller Assoziation, entlang der vererbt wird. Anhand eines speziellen Plugins für die SMC konnte ich die unten anhängende Liste ermitteln.

5. Aus der u.a. Liste wird deutlich, dass es bestimmte systemkritische Metadatentypen gibt, die Ihre Rechte von keinem anderen Objekt erben. Für diese gelten folglich die Zugriffsberechtigungen, die in der Default ACL des Repositories eingestellt sind. Dort muss man aber häufig einer großen Zahl Anwendern (meist sogar allen, also der Gruppe SASUSERS) ein Metadatenschreibrecht einräumen, z.B. wenn man Nutzer Stored Processes anlegen oder in Channels veröffentlichen lassen möchte.

6. Aus 5. scheint zu folgen, dass man alle Metadatenobjekte, die von einem der folgenden systemkritischen Typen sind, explizit einzeln schützen muss: AuthenticationDomain, Machine, ServerContext, SoftwareComponent. Insbesondere die letzteren sind aber in der Regel Dutzende von Objekten. Jeder, dem das Recht "WriteMetadata" an einem solchen Objekt nicht entzogen wird, kann dieses sehr einfach löschen. Noch ist mir unklar, was dies jeweils zur Folge hätte...

7. Zusätzlich kompliziert wird die Angelegenheit durch folgende Umstände:

a) Viele Metadaten-"Objekte", die in der SMC sichtbar sind, bestehen in Wirklichkeit aus mehreren Metadatenobjekten, und es ist nicht offensichtlich, auf welche dieser Objekte eine in der SMC durchgeführte Aktion (z.B. Löschen oder Berechtigungen ändern) genau wirkt. Hier empfiehlt sich im Zweifelsfall eine Kontrolle im Metadatenbrowser des Display-Managers.

b) Die in der SMC dargestellte Baumstruktur ist nicht identisch mit der Rechtevererbungshierarchie und diese wiederum nicht identisch mit der Hierarchie, entlang der sich Löschungen fortsetzen. Mit anderen Worten: Wenn ich eine Berechtigung in der SMC einstelle, sind zum Teil weitere Objekte betroffen, die scheinbar unabhängig sind, und wenn ich etwas in der SMC lösche, kann ich nicht immer sicher sein, dass alles, was scheinbar davon abhängt, auch gelöscht wird. So können leicht Metadatenleichen entstehen.

c) Viele SAS-Clients und -Solutions scheinen das Metadatenmodell in anderer Weise zu verwenden, als man es aufgrund der (leider relativ spärlichen) Dokumentation des Modells vermuten würde, so dass zum Teil unnötig komplexe und zahlreiche Metadaten entstehen, die schwer durchschaubar sind. Z.B. wird kaum von der Wiederverwendbarkeit von PropertyTypes Gebrauch gemacht, sondern für jede Stringproperty eine neue Kopie des PropertyTypes "String" angelegt; und es wird kaum von der Möglichkeit Gebrauch gemacht, Pfade relativ zu Basispfaden zu vergeben.

d) Assoziationen zwischen Metadatenobjekten sind immer zweiseitig, aber zusammengehörige Assoziationen kann man häufig nicht an ihrem Namen erkennen. Das führt zu gefährlichen Verwechslungsmöglichkeiten, z.B. zwischen AccessControls und AccessControlItems bei einem AccessControlTemplate.

8. Je nach Plattform sollte man sich auch einmal die Zugriffsberechtigungen auf die Metadatenrepositories auf Betriebssystemebene anschauen. Ist z.B. in einer Unix- oder z/OS-Installation das Verzeichnis Foundation, in dem die den einzelnen Metadatentypen entsprechenden SAS-Datasets liegen, nicht schreibgeschützt, so können alle SAS-Datasets gelöscht werden, auch wenn man kein Schreibrecht an den einzelnen Dateien besitzt!

Liste mit Metadatentypen, entlang deren Assoziationen sich Berechtigungen vererben:

ServerContext -> LogicalServer -> ServerComponent -> Connection

ServerComponent -> Directory

ServerComponent -> DeployedDataPackage -> RelationalSchema -> DataTable -> Column

Tree -> SubTree -> Member

Person -> ITSubscriber

PSPortalPage -> PSLayoutComponent

Root -> Extension/Property/PropertyGroup/PropertySet

PropertySet -> Property

TransformationStep -> ClassifierMap

aber nicht (!):

PSPortalPage -x-> PSPortlet

IdentityGroup -x-> Subgroup -x-> Person -x-> Login

PropertyGroup/PropertyType -x-> Property

irgendwas -x-> AuthenticationDomain/Machine/ServerContext/SoftwareComponent