Repräsentative Daten

Die meisten Anwendungssysteme – und somit auch unsere DeltaMaster-Welt – werden in einer Mehrsystemlandschaft betrieben. Typisch in aktuellen IT-Infrastrukturen sind 2- oder 3-Systemlandschaften. In einer 2-Systemlandschaft sprechen wir von einem Entwicklungssystem (DEV) und einem Produktivsystem (PROD). In einer 3-Systemlandschaft wird zusätzlich noch ein Testsystem (QS) für unterschiedliche Benutzergruppen und Testszenarien zwischengeschaltet. Grundsätzlich ist die Verwendung von solchen Mehrsystemlandschaften dringend zu empfehlen. Nur so können notwendige und gewünschte Änderungen separat vom produktiven System entwickelt, getestet und vom Kunden fachlich abgenommen werden.

Eine Mehrsystemlandschaft bedeutet aber auch einen Mehraufwand während der Entwicklungszyklen. Es muss ein Prozess definiert sein wie die Entwicklungen von DEV zu PROD möglichst automatisiert übertragen werden können. Außerdem müssen in geeigneten Intervallen die produktiven Daten vom PROD auf das DEV zurückgespielt werden, um möglichst repräsentative Testergebnisse bereits während der Entwicklung gewährleisten zu können. weiterlesen…

Berechtigungsverwaltung über AD-Gruppen

Über das Thema Berechtigungen wurde bereits mehrfach berichtet, dennoch gibt es immer wieder neue interessante Lösungen. Neulich beim Kunden in Shanghai hatte das Thema Berechtigungen allerhöchste Priorität aufgrund der hohen Fluktuation von Mitarbeitern. Die Anforderungen waren dementsprechend hoch und vermeintlich widersprüchlich: Berechtigungen sollten möglichst flexibel je Abteilung, je Region und je Kennzahl vergeben werden können und das natürlich ohne großen Aufwand.

Ohne Aufwand bedeutet in diesem Fall, dass ein Mitarbeiter einen Antrag über ein Formular stellt, dieser Antrag von einem Vorgesetzten geprüft wird und nach Freigabe von einem beliebigen Mitarbeiter der IT bearbeitet werden soll.

Durch den sehr volatilen Nutzerkreis kam als Lösung nur die Nutzung von Active-Directory(AD)-Gruppen in Frage. Jeder Anwender hat einen AD-User, und die IT braucht den Mitarbeiter ausschließlich bestimmten Gruppen zuordnen oder eben aus einer Zuordnung wieder herausnehmen bzw. den User deaktivieren. Selbstverständlich müssen die Berechtigungen über AD-Gruppen in OLAP und auch der SQL-Datenbank – beim DeltaMaster-SQL-Durchgriff – greifen.

Weiterhin enthält das BI-Modell mehrere hundert Kennzahlen und wird darüber hinaus nicht nur lokal, sondern auch in der Muttergesellschaft weiterentwickelt: Halbautomatisch werden neue Kennzahlen oder Kennzahlengruppen bereitgestellt. Eine Berechtigung auf einzelne Kennzahlen wäre somit sehr aufwändig und fehleranfällig, aber auch dafür haben wir eine Lösung. weiterlesen…

Dynamische Ermittlung von Mitgliedern einer AD-Gruppe per SQL

Die Vergabe von Benutzerrechten in einer OLAP-Datenbank auf einem Microsoft Analysis Server (SSAS) kann auf unterschiedliche Weise gelöst werden. Es können Lese- oder Schreibberechtigungen auf die ganze Datenbank, auf einen oder mehrere Würfel und Measuresgroups vergeben, oder einzelne Elemente einer Dimension oder Measures für den Zugriff gesperrt werden. Diese Berechtigungen wer-den für Rollen definiert. In Rollen werden Benutzer mit gleichen Benutzerrechten zusammengefasst. Somit muss nicht für jeden einzelnen Anwender die Berechtigung separat gesetzt werden. Bei weniger komplexen Berechtigungsszenarien können so mit einigen Mausklicks die Berechtigungen erstellt und gepflegt werden. Sieht das Berechtigungsszenario jedoch vor, dass jeder Anwender separat berechtigt werden muss, weil jeder von ihnen z. B. nur seine Region oder seine Kostenstelle sehen darf, muss für jeden Anwender eine eigene Rolle mit den entsprechenden Berechtigungen erstellt werden. Wird beim Reporting der SQL-Durchgriff zur Analyse von Belegdaten genutzt, müssen diese Berechtigungen auch auf der relationalen Datenbank Berücksichtigung finden. Um sich dabei doppelten Pflegeaufwand bei der Vergabe der Berechtigungen zu ersparen, empfiehlt es sich die Berechtigung gleich auf der relationalen Schicht zu pflegen und diese anschließend automatisch an einen Berechtigungswürfel auf der OLAP-Datenbank zu übergeben (siehe Beitrag Rechteverwaltung in SSAS – Teil 2). Oft wird die Verantwortung für die Berechtigungspflege an die Fachabteilung delegiert. Die IT-Abteilung stellt eine speziell benannte Benutzergruppe im Active-Directory (AD) zur Verfügung, der alle Benutzer mit Zugriff auf die BI-Anwendung zugeordnet wurden. Die Vergabe der Berechtigungen der einzelnen Benutzer innerhalb dieser AD-Gruppe muss anschließend von der Fachabteilung vorgenommen werden. Hierfür werden oft Pflegeanwendungen in DeltaMaster genutzt, in denen man jedem einzelnen Benutzer z. B. seine berechtigte Kostenstelle zuweisen kann. Damit die Berechtigungen wirken, muss der korrekte Name der Kostenstelle und der korrekte Benutzername angegeben werden. Dies stellt aber oft ein Problem dar, da nicht immer bekannt ist, wie der genaue Benutzername im Active-Directory lautet. Um dem Pflegenden bei dieser Arbeit zu unterstützen, wäre es hilfreich, wenn alle in der AD-Gruppe befindlichen Benutzer in einer Pflegeanwendung angezeigt würden und anschließend „nur noch“ die berechtigten Kostenstellen zugeordnet werden müssten. Wie eine solche Liste mittels einer SQL-Abfrage ermittelt werden kann, soll dieser Beitrag verdeutlichen. weiterlesen…

Zellsicherheit – aus der Zelle zurück in die Dimension

Gelegentlich trifft man in der BI-Welt auf die Anforderung, dass nicht alle dargestellten Kennzahlen auch für alle Nutzer sichtbar sein sollen.

Zur Implementierung von Nutzerberechtigungen auf OLAP-Cubes stellt Microsoft in Analysis Services zwei Verfahren zur Verfügung: die Dimensionssicherheit und die Zellsicherheit. Die Dimensionssicherheit regelt den Zugriff der Nutzer über die in einer Dimension enthaltenen Elemente. Die (mächtigere) Zellsicherheit wird normalerweise nur benötigt, wenn die Steuerung der Nutzerrechte anhand der Elemente (nur) einer Dimension nicht mehr ausreicht.

Der Einsatz der Zellsicherheit hat allerdings auch einige Tücken. Erstens bleiben weiterhin alle Elemente der Dimensionen sichtbar. Nur die Kennzahlen auf den nicht-berechtigten-Elementen werden mit SEC überschrieben. Zweitens werden ohne Sonderbehandlung die Nutzungsrechte (nach oben) auf die Aggregate vererbt. Das heißt, hat ein Nutzer das Recht mindestens ein Element einer bestimmten Ebene zu sehen, so sieht er auch das echte Aggregat aller Elemente dieser Ebene, unabhängig davon, ob einzelne Elemente dieser Ebene per SEC geschützt sind.

Dieser Beitrag stellt eine elegante Alternative zum Einsatz der Zellsicherheit vor. weiterlesen…

Back(upp)en mit Rezept

Ein regelmäßiges Backup der von uns bearbeiteten Systeme lässt einen meist ruhig schlafen, korrekt? – Stimmt, wenn es denn ein Backup gibt und man darauf vertrauen kann!

In den meisten Projekten obliegt die Betriebsbereitschaft von Serversystemen der Verantwortung der IT-Abteilungen und das ist gut so. Es gibt regelmäßige Wartungspläne, ganze 19“-Racks voll mit Hardware sowie unterschiedliche Softwaretools, um automatisiert und möglichst effizient die wichtigen und sensiblen Daten zu kopieren, auf Medien auszulagern und damit vor Verlust zu schützen.
Die verschiedenen Verfahren sind nicht Bestandteil dieses Beitrags, es sei nur so viel gesagt: Je nach Schutzbedarf und Datenmenge kann es kompliziert werden. Weiterführende Details und Hintergründe finden sich zum Beispiel beim Bundesamt für Sicherheit in der Informationstechnik (kurz: BSI) unter Abschnitt B1.4 des IT-Grundschutzkatalogs.

Was tun wir aber, wenn unser Business Intelligence Projekt von der Fachabteilung an der IT vorbei begonnen und eingeführt wird und unsere Server eben nicht dem Luxus einer geregelten Datensicherung unterliegen? Ein allgemeines Rezept als Trumpf im Ärmel zu haben; das zeige ich auf den folgenden Seiten. weiterlesen…

Sehen und gesehen werden

In diesem Beitrag möchte ich mich einem Detail des oft behandelten Themas der OLAP-Berechtigungen widmen, der Berechtigung von Kennzahlen.
Wir alle haben uns sicherlich schon mit der Frage beschäftigt, was sieht ein Benutzer tatsächlich, nachdem man sich bei der Rechtevergabe auf der OLAP-Datenbank ausgetobt hat. Dazu stelle ich einen kleinen, aber feinen Trick vor.

Spricht man mit IT-Administratoren, weise ich immer auf einen grundlegenden Unterschied zwischen Berechtigungen von Microsoft Analysis Services (kurz: SSAS) und z. B. dem Dateisystem einer Microsoft Windows Systemumgebung hin: die Berechtigungen auf OLAP-Datenbanken sind additiv, nicht restriktiv!

Von Dateien oder Verzeichnissen ist man gewöhnt, dass wenn einmal einem Benutzer ein beliebiges Recht entzogen wurde, dann bleibt diese Restriktion erhalten, egal worüber sonst einem vielleicht ein höheres Recht eingeräumt wird. Dieser Grundgedanke bietet einen recht guten Schutz gegen Fehlkonfiguration und damit unerwünschte Zugriffsrechte.

Bei Microsoft Analysis Services Datenbanken gilt dieser Grundsatz leider nicht, weder für „normale“ Dimensionselemente noch für die Berechtigung von Kennzahlen. Einmal erlaubt = immer erlaubt; das ist die Devise!

Was es bei dem Einsatz von Berechtigungen auf Kennzahlen gesondert zu beachten gilt, schauen wir uns in der Demonstrationsdatenbank „Chair“ an. weiterlesen…

Kopieren von Analysesitzungen im DeltaMaster-Repository

In einem Kundenprojekt gab es die Anforderung, DAS-Dateien in drei Versionen für Entwicklungs- (DEV), Qualitätssicherungs- (QS) und Produktivsystem (PROD) im DeltaMaster-Repository bereitzustellen. Die besondere Herausforderung war, dass der Übertragungszyklus (von DEV nach QS nach PROD) so gestaltet werden sollte, dass die Rechte-Einstellungen im Repository erhalten bleiben und nicht mit den Rechten eines anderen Systems überschrieben werden.

In diesem Beitrag werden die Faktoren erläutert, die bei einem solchen Vorhaben berücksichtigt werden müssen. Außerdem werde ich den Aufbau des SQL-Scripts darstellen, mit dem jetzt bereits seit mehreren Monaten erfolgreich der Übertragungszyklus bei unserem Kunden ausgeführt wird. weiterlesen…

Berechtigungen für Zellkommentare

Wie im Beitrag „Zellkommentare“ beschrieben, bietet DeltaMaster die Möglichkeit, für einzelne Zellwerte Zellkommentare zu erfassen. Das kann z. B. sehr hilfreich sein, wenn während einer Planungsphase genau beschrieben werden soll, warum ein Planwert in einer bestimmten Höhe erfasst wurde oder eine Abweichungen zustande gekommen ist. Bei der Planung werden Daten oft auf verschiedenen Aggregationsebenen erfasst. Es kann Top-Down, Bottom-Up oder über das Gegenstromverfahren geplant werden. Dabei werden unterschiedliche Verantwortlichkeiten definiert und jeder Planer darf Werte auf der für ihn definierten Aggregationsebene eingeben. Beispielsweise kann es Planer geben, die nur einzelne Produkte planen dürfen. Andere wiederum dürfen ganze Produktgruppen planen, bzw. die aggregierten Planwerte der Produktplaner korrigieren oder überarbeiten. In manchen Fällen ist eine solche Berechtigungslogik auch für die Erfassung von Zellkommentaren notwendig. Welche Schritte dafür notwendig sind, soll der folgende Artikel beschreiben. weiterlesen…

Transparente Verschlüsselung

Als im Juni 2013 die amerikanische Washington Post und der britische Guardian damit begannen, geheime Dokumente eines ehemaligen Mitarbeiters des amerikanischen Auslandsgeheimdienstes NSA zu veröffentlichen, wurde der Weltöffentlichkeit klar, wie transparent scheinbar jegliche Kommunikation und damit auch die dadurch erhobenen Daten eines jeden von uns sind. Die dadurch neuentfachte Debatte um den Datenschutz schafft immer mehr Sensibilität im Umgang mit unseren privaten Daten. Auch Unternehmen, allen voran das Finanz- und Bankenwesen, haben in den meisten Fällen festgeschriebene Regeln, wie mit allgemeinen Geschäftsdaten umzugehen ist. In Deutschland werden diese Regeln vom Bundesamt für Sicherheit in der Informationstechnologie (kurz: BSI) definiert und als sogenannter IT-Grundschutz veröffentlicht. Kernziele sind dabei Vertraulichkeit, Verfügbarkeit, Integrität und Identität sicherzustellen, um dadurch Gefahren und Risiken zu minimieren. Was bedeutet dies nun aber in Business-Intelligence-Projekten? Der folgende Artikel soll die potenziellen Gefahrenquellen hinsichtlich der Vertraulichkeit aufzeigen und im Detail die Möglichkeit zur Verschlüsselung der relationalen Datenquelle mit Hilfe der sogenannten transparenten Datenverschlüsselung (kurz: TDE) des Microsoft SQL Servers aufzeigen. weiterlesen…