In einem unserer Kundenprojekte wurden wir vor die Herausforderung gestellt, allen Mitarbeitern des Unternehmens spezifizierte Berichte aus einem Teilbereich des Datenwürfels über die DeltaMaster Weboption bereitzustellen. Das klingt zunächst nach einer Kleinigkeit, da der Kunde bereits die DeltaMaster Weboption einsetzt, der Zugriff über einen Browser ist also implementiert. Bei genauer Betrachtung stellten sich uns allerdings doch einige Fragen hinsichtlich Administration der relevanten Benutzer und der Datensicherheit von den im Modell enthaltenen Kennzahlen.
Erklärtes Ziel des Kunden:
„Nur sog. Verfügbarkeitsberichte sollen allen Benutzern (ca. 13.000) jederzeit zur Verfügung stehen.“
Die Herausforderung:
Das Modell besteht aus sechs Analysewertgruppen, aber nur eine Analysewertgruppe ist für die Auswertung von Verfügbarkeiten relevant. Die „primäre“ Analysewertgruppe stellt die gesamten Kostenstrukturen des Konzerns dar und darf nur von einem kleinen Anwenderkreis gesehen und analysiert werden, keinesfalls von allen Benutzern.
Das Ergebnis unserer Überlegungen möchten wir hier jetzt vorstellen. Die Lösung besteht aus mehreren eingesetzten Hilfsmitteln, nämlich:
- DeltaMaster Weboption mit Report.aspx
- ActiveDirectory Systemgruppe „Authenticated Users“
- SSAS Cube-Perspektive
- OLAP-Rolle mit Rechteeinschränkungen inkl. Kennzahlen
Unsere Idee dabei ist, eine bestehende DAS mit den relevanten Berichten soweit abzusichern, dass der Zugriff über die Report.aspx nicht manuell ausgehebelt werden kann. Das Vorgehen des Kunden sieht folgendermaßen aus:
Alle Benutzer haben in einem internen Sharepoint-Portal einen Bereich für die Verfügbarkeiten der IT-Systeme. Dabei wird in Sharepoint eine Webseite angelegt, welche als Ziel eine DeltaMaster Applikation im Repository unter Angabe der ReportID darstellt. Die Benutzer haben also nicht direkt Zugriff auf das Repository, sondern erhalten als Ergebnis des Aufrufs der Sharepoint-Webseite nur den DeltaMaster-Bericht. Da in dem Projekt der Kunde jegliche Sharepoint-Administration selbständig aufgebaut hat (und er nicht ca. 80 Links anpassen möchte), kamen wir auf die Idee, einfach in der verwendeten Analysesitzung den Cube durch eine Perspektive zu ersetzen, welche lediglich die benötigten Dimensionen und Measuregruppen für die Berichte beinhaltet. Kurzer Exkurs: Was ist eigentlich eine Perspektive in SSAS (seit Version 2005)?
„(…)In Microsoft SQL Server 2005 Analysis Services (SSAS) können Sie eine Perspektive verwenden, um die wahrgenommene Komplexität eines Cubes in Analysis Services zu reduzieren. Eine Perspektive definiert eine sichtbare Teilmenge eines Cubes, die fokussierte, unternehmensspezifische oder anwendungsspezifische Sichten für einen Cube bereitstellt. Über die Perspektive wird die Sichtbarkeit der in einem Cube enthaltenen Objekte gesteuert….
…Perspektiven sollen nicht als Sicherheitsmechanismus verwendet werden, sondern werden als Tool zur Vereinfachung der Nutzung von Business-Intelligence-Anwendungen für Endbenutzer verwendet. Die gesamte Sicherheit einer bestimmten Perspektive wird vom zugrunde liegenden Cube geerbt. So können z. B. Perspektiven keinen Zugriff auf Objekte in einem Cube ermöglichen, auf die ein Benutzer nicht bereits Zugriff hat.“ (Quelle: http://technet.microsoft.com/de-de/library/ms175338.aspx)
Generell können folgende Objekte in eine Perspektive aufgenommen werden:
- Dimensionen
- Attribute
- Hierarchien
- Analysewertgruppen
- Analysewerte
- Key Performance Indicators (KPIs)
- Berechnungen (berechnete Elemente, benannte Mengen und Skriptbefehle)
- Aktionen
Kommen wir jetzt zu Erstellung einer solchen Perspektive. Im BI Development Studio (kurz: BIDS) verbindet man sich auf die gewünschte OLAP-Datenbank, öffnet den Cube und wechselt auf den Register „Perspektiven“. Mit einem Klick auf „Neue Perspektive“ (s. nachfolgender Screenshot) wird der Teilausschnitt aus dem Cube erzeugt. Durch An- und Abhaken der gewünschten Objekte kann man nun die Perspektive sehr detailliert konfigurieren. Dann muss noch ein Name vergeben und eine Standardkennzahl über eine Drop-down-Box festgelegt werden.
Durch „Speichern“ werden die Änderungen auf der OLAP-Datenbank übernommen. Legt man anschließend ein neues Analysemodell in DeltaMaster an, erscheint die Perspektive wie ein eigener Cube im Auswahldialog (s. nachfolgender Screenshot).
Eine Prüfung mittels des Analysewertbrowsers zeigt, dass nur der eingestellte Analysewert in der Analysesitzung angezeigt wird.
Aber: Die Perspektive ist kein Sicherheitsmechanismus! Sie gibt uns aber die Möglichkeit, einem Anwender den unerlaubten Zugriff auf alle anderen enthaltenen Daten zu verschleiern und somit unerlaubten Zugriff wenigstens mal zu erschweren. Der Zugriff an sich wird natürlich weiterhin über eine definierte OLAP-Rolle gewährleistet.
Für das hier aufgezeigte Projekt ist weiterhin darauf zu achten, dass auch nur die benötigten Kennzahlen aktiviert sind, damit durch manuelle Eingriffe nicht „aus Versehen“ andere Kennzahlen vor die Augen der Betrachter geraten. Außerdem sollte in der Perspektive nur die notwendige Hierarchie der Kostenstellendimension aktiviert und der Unknownpfad ausgeblendet werden. Über den Unknownpfad wären Rückschlüsse auf die Gesamtkostensituation des Unternehmens möglich. Ebenso gilt es, die Funktion „sichtbare Gesamtwerte aktivieren“ anzuhaken. Andernfalls würde auf dem AllMember-Knoten der bereitgestellten Hierarchie wiederum die Summe Rückschlüsse auf die Gesamtkosten zulassen.
Die Additivität der OLAP-Berechtigungsrollen hilft uns jetzt dabei, weitere Änderungen an bereits bestehenden Rollen zu verhindern, die darin enthaltenen „erweiterten“ Rechte bleiben erhalten. Damit beschränkt sich der Administrationsaufwand also auf das Hinzufügen einer einzigen neuen Rolle.
Das ist aber nur Teil 1 der Lösung. Damit nun alle Benutzer des Unternehmens Zugriff auf die Berichte des Sharepoint-Portals haben, müssen diese auch in unserem Repository und auf der OLAP-Datenbank berechtigt werden. Hier hilft eine Systemgruppe des beim Kunden eingesetzten Verzeichnisdienstes Active Directory (kurz: AD) weiter. In jedem AD existiert die Benutzergruppe „authentifizierte Benutzer“ und diese beinhaltet jedes derzeit angemeldete AD-Benutzerkonto. Diese Gruppe muss jetzt im Repository eingetragen und der korrekten Applikation zugewiesen werden. Ab diesem Zeitpunkt haben alle in der Domäne des Kunden angemeldeten Benutzer Zugriff auf den (oder die) definierten Berichte. An dieser Stelle sei darauf hingewiesen, dass dieses Vorgehen nur eine rudimentäre Datensicherheit gewährleisten kann, findige Benutzer können immer noch auf alle Objekte im Datenwürfel zugreifen.
Ich möchte jetzt noch auf ein paar relevante Aspekte der OLAP-Perspektiven in unseren Projekten hinweisen:
- OLAP-Perspektiven sind kein Sicherheitsmechanismus und können auch nicht direkt in der Rollenverwaltung berechtigt werden.
- Nach einem Deploy eines Cubes über DeltaMaster Modeler geht derzeit eine angelegte Perspektive verloren. An eine vorherige Sicherung mittels XMLA-Skript über das SQL-Server Management Studio muss also gedacht werden.
Fazit: Die Perspektiven eignen sich hervorragend zur Vereinfachung des „sichtbaren“ Datenmodells, daher empfehlen wir, in komplexen Datenmodellen öfter die Anwendung von Perspektiven zu berücksichtigen bzw. zu prüfen, unsere Benutzer werden es uns danken. Das hier gezeigte Anwendungsbeispiel wird wahrscheinlich selten in dieser Form wiederkehren, stellt aber einen interessanten Ansatz für die Informationsbereitstellung von DeltaMaster-Berichten für eine große Benutzeranzahl dar.
