Repräsentative Daten

Die meis­ten Anwen­dungs­sys­teme – und somit auch unsere Delta­Master-Welt – wer­den in einer Mehr­sys­tem­land­schaft betrie­ben. Typi­sch in aktu­el­len IT-Infra­struk­tu­ren sind 2- oder 3-Sys­tem­land­schaf­ten. In einer 2-Sys­tem­land­schaft spre­chen wir von einem Ent­wick­lungs­sys­tem (DEV) und einem Pro­duk­tiv­sys­tem (PROD). In einer 3-Sys­tem­land­schaft wird zusätz­lich noch ein Test­sys­tem (QS) für unter­schied­li­che Benut­zer­grup­pen und Test­sze­na­rien zwi­schen­ge­schal­tet. Grund­sätz­lich ist die Ver­wen­dung von sol­chen Mehr­sys­tem­land­schaf­ten drin­gend zu emp­feh­len. Nur so kön­nen not­wen­dige und gewünschte Ände­run­gen sepa­rat vom pro­duk­ti­ven Sys­tem ent­wi­ckelt, getes­tet und vom Kun­den fach­lich abge­nom­men wer­den.

Eine Mehr­sys­tem­land­schaft bedeu­tet aber auch einen Mehr­auf­wand wäh­rend der Ent­wick­lungs­zy­klen. Es muss ein Pro­zess defi­niert sein wie die Ent­wick­lun­gen von DEV zu PROD mög­lichst auto­ma­ti­siert über­tra­gen wer­den kön­nen. Außer­dem müs­sen in geeig­ne­ten Inter­val­len die pro­duk­ti­ven Daten vom PROD auf das DEV zurück­ge­spielt wer­den, um mög­lichst reprä­sen­ta­tive Test­ergeb­nisse bereits wäh­rend der Ent­wick­lung gewähr­leis­ten zu kön­nen. wei­ter­le­sen…

Berechtigungsverwaltung über AD-Gruppen

Über das Thema Berech­ti­gun­gen wurde bereits mehr­fach berich­tet, den­noch gibt es immer wie­der neue inter­es­sante Lösun­gen. Neu­lich beim Kun­den in Shang­hai hatte das Thema Berech­ti­gun­gen aller­höchste Prio­ri­tät auf­grund der hohen Fluk­tua­tion von Mit­ar­bei­tern. Die Anfor­de­run­gen waren dem­entspre­chend hoch und ver­meint­lich wider­sprüch­lich: Berech­ti­gun­gen soll­ten mög­lichst fle­xi­bel je Abtei­lung, je Region und je Kenn­zahl ver­ge­ben wer­den kön­nen und das natür­lich ohne gro­ßen Auf­wand.

Ohne Auf­wand bedeu­tet in die­sem Fall, dass ein Mit­ar­bei­ter einen Antrag über ein For­mu­lar stellt, die­ser Antrag von einem Vor­ge­setz­ten geprüft wird und nach Frei­gabe von einem belie­bi­gen Mit­ar­bei­ter der IT bear­bei­tet wer­den soll. 

Durch den sehr vola­ti­len Nut­zer­kreis kam als Lösung nur die Nut­zung von Active-Directory(AD)-Gruppen in Frage. Jeder Anwen­der hat einen AD-User, und die IT braucht den Mit­ar­bei­ter aus­schließ­lich bestimm­ten Grup­pen zuord­nen oder eben aus einer Zuord­nung wie­der her­aus­neh­men bzw. den User deak­ti­vie­ren. Selbst­ver­ständ­lich müs­sen die Berech­ti­gun­gen über AD-Grup­pen in OLAP und auch der SQL-Daten­bank – beim Delta­Master-SQL-Durch­griff – grei­fen.

Wei­ter­hin ent­hält das BI-Modell meh­rere hun­dert Kenn­zah­len und wird dar­über hin­aus nicht nur lokal, son­dern auch in der Mut­ter­ge­sell­schaft wei­ter­ent­wi­ckelt: Halb­au­to­ma­ti­sch wer­den neue Kenn­zah­len oder Kenn­zah­len­grup­pen bereit­ge­stellt. Eine Berech­ti­gung auf ein­zelne Kenn­zah­len wäre somit sehr auf­wän­dig und feh­ler­an­fäl­lig, aber auch dafür haben wir eine Lösung. wei­ter­le­sen…

Dynamische Ermittlung von Mitgliedern einer AD-Gruppe per SQL

Die Ver­gabe von Benut­zer­rech­ten in einer OLAP-Daten­bank auf einem Micro­soft Ana­ly­sis Ser­ver (SSAS) kann auf unter­schied­li­che Weise gelöst wer­den. Es kön­nen Lese- oder Schreib­be­rech­ti­gun­gen auf die ganze Daten­bank, auf einen oder meh­rere Wür­fel und Mea­su­res­groups ver­ge­ben, oder ein­zelne Ele­mente einer Dimen­sion oder Mea­su­res für den Zugriff gesperrt wer­den. Diese Berech­ti­gun­gen wer-den für Rol­len defi­niert. In Rol­len wer­den Benut­zer mit glei­chen Benut­zer­rech­ten zusam­men­ge­fasst. Somit muss nicht für jeden ein­zel­nen Anwen­der die Berech­ti­gung sepa­rat gesetzt wer­den. Bei weni­ger kom­ple­xen Berech­ti­gungs­sze­na­rien kön­nen so mit eini­gen Maus­klicks die Berech­ti­gun­gen erstellt und gepflegt wer­den. Sieht das Berech­ti­gungs­sze­na­rio jedoch vor, dass jeder Anwen­der sepa­rat berech­tigt wer­den muss, weil jeder von ihnen z. B. nur seine Region oder seine Kos­ten­stelle sehen darf, muss für jeden Anwen­der eine eigene Rolle mit den ent­spre­chen­den Berech­ti­gun­gen erstellt wer­den. Wird beim Reporting der SQL-Durch­griff zur Ana­lyse von Beleg­da­ten genutzt, müs­sen diese Berech­ti­gun­gen auch auf der rela­tio­na­len Daten­bank Berück­sich­ti­gung fin­den. Um sich dabei dop­pel­ten Pfle­ge­auf­wand bei der Ver­gabe der Berech­ti­gun­gen zu erspa­ren, emp­fiehlt es sich die Berech­ti­gung gleich auf der rela­tio­na­len Schicht zu pfle­gen und diese anschlie­ßend auto­ma­ti­sch an einen Berech­ti­gungs­wür­fel auf der OLAP-Daten­bank zu über­ge­ben (siehe Bei­trag Rech­te­ver­wal­tung in SSAS – Teil 2). Oft wird die Ver­ant­wor­tung für die Berech­ti­gungs­pflege an die Fach­ab­tei­lung dele­giert. Die IT-Abtei­lung stellt eine spe­zi­ell benannte Benut­zer­gruppe im Active-Direc­tory (AD) zur Ver­fü­gung, der alle Benut­zer mit Zugriff auf die BI-Anwen­dung zuge­ord­net wur­den. Die Ver­gabe der Berech­ti­gun­gen der ein­zel­nen Benut­zer inner­halb die­ser AD-Gruppe muss anschlie­ßend von der Fach­ab­tei­lung vor­ge­nom­men wer­den. Hier­für wer­den oft Pfle­ge­an­wen­dun­gen in Delta­Master genutzt, in denen man jedem ein­zel­nen Benut­zer z. B. seine berech­tigte Kos­ten­stelle zuwei­sen kann. Damit die Berech­ti­gun­gen wir­ken, muss der kor­rekte Name der Kos­ten­stelle und der kor­rekte Benut­zer­name ange­ge­ben wer­den. Dies stellt aber oft ein Pro­blem dar, da nicht immer bekannt ist, wie der genaue Benut­zer­name im Active-Direc­tory lau­tet. Um dem Pfle­gen­den bei die­ser Arbeit zu unter­stüt­zen, wäre es hilf­reich, wenn alle in der AD-Gruppe befind­li­chen Benut­zer in einer Pfle­ge­an­wen­dung ange­zeigt wür­den und anschlie­ßend nur noch“ die berech­tig­ten Kos­ten­stel­len zuge­ord­net wer­den müss­ten. Wie eine sol­che Liste mit­tels einer SQL-Abfrage ermit­telt wer­den kann, soll die­ser Bei­trag ver­deut­li­chen. wei­ter­le­sen…

Zellsicherheit – aus der Zelle zurück in die Dimension

Gele­gent­lich trifft man in der BI-Welt auf die Anfor­de­rung, dass nicht alle dar­ge­stell­ten Kenn­zah­len auch für alle Nut­zer sicht­bar sein sol­len.

Zur Imple­men­tie­rung von Nut­zer­be­rech­ti­gun­gen auf OLAP-Cubes stellt Micro­soft in Ana­ly­sis Ser­vices zwei Ver­fah­ren zur Ver­fü­gung: die Dimen­si­ons­si­cher­heit und die Zell­si­cher­heit. Die Dimen­si­ons­si­cher­heit regelt den Zugriff der Nut­zer über die in einer Dimen­sion ent­hal­te­nen Ele­mente. Die (mäch­ti­gere) Zell­si­cher­heit wird nor­ma­ler­weise nur benö­tigt, wenn die Steue­rung der Nut­zer­rechte anhand der Ele­mente (nur) einer Dimen­sion nicht mehr aus­reicht.

Der Ein­satz der Zell­si­cher­heit hat aller­dings auch einige Tücken. Ers­tens blei­ben wei­ter­hin alle Ele­mente der Dimen­sio­nen sicht­bar. Nur die Kenn­zah­len auf den nicht-berech­tig­ten-Ele­men­ten wer­den mit SEC über­schrie­ben. Zwei­tens wer­den ohne Son­der­be­hand­lung die Nut­zungs­rechte (nach oben) auf die Aggre­gate ver­erbt. Das heißt, hat ein Nut­zer das Recht min­des­tens ein Ele­ment einer bestimm­ten Ebene zu sehen, so sieht er auch das echte Aggre­gat aller Ele­mente die­ser Ebene, unab­hän­gig davon, ob ein­zelne Ele­mente die­ser Ebene per SEC geschützt sind.

Die­ser Bei­trag stellt eine ele­gante Alter­na­tive zum Ein­satz der Zell­si­cher­heit vor. wei­ter­le­sen…

Back(upp)en mit Rezept

Ein regel­mä­ßi­ges Backup der von uns bear­bei­te­ten Sys­teme lässt einen meist ruhig schla­fen, kor­rekt? – Stimmt, wenn es denn ein Backup gibt und man dar­auf ver­trauen kann!

In den meis­ten Pro­jek­ten obliegt die Betriebs­be­reit­schaft von Ser­ver­sys­te­men der Ver­ant­wor­tung der IT-Abtei­lun­gen und das ist gut so. Es gibt regel­mä­ßige War­tungs­pläne, ganze 19“-Racks voll mit Hard­ware sowie unter­schied­li­che Soft­ware­tools, um auto­ma­ti­siert und mög­lichst effi­zi­ent die wich­ti­gen und sen­si­blen Daten zu kopie­ren, auf Medien aus­zu­la­gern und damit vor Ver­lust zu schüt­zen.
Die ver­schie­de­nen Ver­fah­ren sind nicht Bestand­teil die­ses Bei­trags, es sei nur so viel gesagt: Je nach Schutz­be­darf und Daten­menge kann es kom­pli­ziert wer­den. Wei­ter­füh­rende Details und Hin­ter­gründe fin­den sich zum Bei­spiel beim Bun­des­amt für Sicher­heit in der Infor­ma­ti­ons­tech­nik (kurz: BSI) unter Abschnitt B1.4 des IT-Grund­schutz­ka­ta­logs.

Was tun wir aber, wenn unser Busi­ness Intel­li­gence Pro­jekt von der Fach­ab­tei­lung an der IT vor­bei begon­nen und ein­ge­führt wird und unsere Ser­ver eben nicht dem Luxus einer gere­gel­ten Daten­si­che­rung unter­lie­gen? Ein all­ge­mei­nes Rezept als Trumpf im Ärmel zu haben; das zeige ich auf den fol­gen­den Sei­ten. wei­ter­le­sen…

Sehen und gesehen werden

In die­sem Bei­trag möchte ich mich einem Detail des oft behan­del­ten The­mas der OLAP-Berech­ti­gun­gen wid­men, der Berech­ti­gung von Kenn­zah­len.
Wir alle haben uns sicher­lich schon mit der Frage beschäf­tigt, was sieht ein Benut­zer tat­säch­lich, nach­dem man sich bei der Rech­te­ver­gabe auf der OLAP-Daten­bank aus­ge­tobt hat. Dazu stelle ich einen klei­nen, aber fei­nen Trick vor.

Spricht man mit IT-Admi­nis­tra­to­ren, weise ich immer auf einen grund­le­gen­den Unter­schied zwi­schen Berech­ti­gun­gen von Micro­soft Ana­ly­sis Ser­vices (kurz: SSAS) und z. B. dem Datei­sys­tem einer Micro­soft Win­dows Sys­tem­um­ge­bung hin: die Berech­ti­gun­gen auf OLAP-Daten­ban­ken sind addi­tiv, nicht restrik­tiv!

Von Dateien oder Ver­zeich­nis­sen ist man gewöhnt, dass wenn ein­mal einem Benut­zer ein belie­bi­ges Recht ent­zo­gen wurde, dann bleibt diese Restrik­tion erhal­ten, egal wor­über sonst einem viel­leicht ein höhe­res Recht ein­ge­räumt wird. Die­ser Grund­ge­danke bie­tet einen recht guten Schutz gegen Fehl­kon­fi­gu­ra­tion und damit uner­wünschte Zugriffs­rechte.

Bei Micro­soft Ana­ly­sis Ser­vices Daten­ban­ken gilt die­ser Grund­satz lei­der nicht, weder für nor­male“ Dimen­si­ons­ele­mente noch für die Berech­ti­gung von Kenn­zah­len. Ein­mal erlaubt = immer erlaubt; das ist die Devise!

Was es bei dem Ein­satz von Berech­ti­gun­gen auf Kenn­zah­len geson­dert zu beach­ten gilt, schauen wir uns in der Demons­tra­ti­ons­da­ten­bank Chair“ an. wei­ter­le­sen…

Kopieren von Analysesitzungen im DeltaMaster-Repository

In einem Kun­den­pro­jekt gab es die Anfor­de­rung, DAS-Dateien in drei Ver­sio­nen für Ent­wick­lungs- (DEV), Qua­li­täts­si­che­rungs- (QS) und Pro­duk­tiv­sys­tem (PROD) im Delta­Master-Repo­si­tory bereit­zu­stel­len. Die beson­dere Her­aus­for­de­rung war, dass der Über­tra­gungs­zy­klus (von DEV nach QS nach PROD) so gestal­tet wer­den sollte, dass die Rechte-Ein­stel­lun­gen im Repo­si­tory erhal­ten blei­ben und nicht mit den Rech­ten eines ande­ren Sys­tems über­schrie­ben wer­den.

In die­sem Bei­trag wer­den die Fak­to­ren erläu­tert, die bei einem sol­chen Vor­ha­ben berück­sich­tigt wer­den müs­sen. Außer­dem werde ich den Auf­bau des SQL-Scripts dar­stel­len, mit dem jetzt bereits seit meh­re­ren Mona­ten erfolg­reich der Über­tra­gungs­zy­klus bei unse­rem Kun­den aus­ge­führt wird. wei­ter­le­sen…

Berechtigungen für Zellkommentare

Wie im Bei­trag Zell­kom­men­tare” beschrie­ben, bie­tet Delta­Master die Mög­lich­keit, für ein­zelne Zell­werte Zell­kom­men­tare zu erfas­sen. Das kann z. B. sehr hilf­reich sein, wenn wäh­rend einer Pla­nungs­phase genau beschrie­ben wer­den soll, warum ein Plan­wert in einer bestimm­ten Höhe erfasst wurde oder eine Abwei­chun­gen zustande gekom­men ist. Bei der Pla­nung wer­den Daten oft auf ver­schie­de­nen Aggre­ga­ti­ons­ebe­nen erfasst. Es kann Top-Down, Bot­tom-Up oder über das Gegen­strom­ver­fah­ren geplant wer­den. Dabei wer­den unter­schied­li­che Ver­ant­wort­lich­kei­ten defi­niert und jeder Pla­ner darf Werte auf der für ihn defi­nier­ten Aggre­ga­ti­ons­ebene ein­ge­ben. Bei­spiels­weise kann es Pla­ner geben, die nur ein­zelne Pro­dukte pla­nen dür­fen. Andere wie­derum dür­fen ganze Pro­dukt­grup­pen pla­nen, bzw. die aggre­gier­ten Plan­werte der Pro­dukt­pla­ner kor­ri­gie­ren oder über­ar­bei­ten. In man­chen Fäl­len ist eine sol­che Berech­ti­gungs­lo­gik auch für die Erfas­sung von Zell­kom­men­ta­ren not­wen­dig. Wel­che Schritte dafür not­wen­dig sind, soll der fol­gende Arti­kel beschrei­ben. wei­ter­le­sen…

Transparente Verschlüsselung

Als im Juni 2013 die ame­ri­ka­ni­sche Washing­ton Post und der bri­ti­sche Guar­dian damit began­nen, geheime Doku­mente eines ehe­ma­li­gen Mit­ar­bei­ters des ame­ri­ka­ni­schen Aus­lands­ge­heim­diens­tes NSA zu ver­öf­fent­li­chen, wurde der Welt­öf­fent­lich­keit klar, wie trans­pa­rent schein­bar jeg­li­che Kom­mu­ni­ka­tion und damit auch die dadurch erho­be­nen Daten eines jeden von uns sind. Die dadurch neu­ent­fachte Debatte um den Daten­schutz schafft immer mehr Sen­si­bi­li­tät im Umgang mit unse­ren pri­va­ten Daten. Auch Unter­neh­men, allen voran das Finanz- und Ban­ken­we­sen, haben in den meis­ten Fäl­len fest­ge­schrie­bene Regeln, wie mit all­ge­mei­nen Geschäfts­da­ten umzu­ge­hen ist. In Deutsch­land wer­den diese Regeln vom Bun­des­amt für Sicher­heit in der Infor­ma­ti­ons­tech­no­lo­gie (kurz: BSI) defi­niert und als soge­nann­ter IT-Grund­schutz ver­öf­fent­licht. Kern­ziele sind dabei Ver­trau­lich­keit, Ver­füg­bar­keit, Inte­gri­tät und Iden­ti­tät sicher­zu­stel­len, um dadurch Gefah­ren und Risi­ken zu mini­mie­ren. Was bedeu­tet dies nun aber in Busi­ness-Intel­li­gence-Pro­jek­ten? Der fol­gende Arti­kel soll die poten­zi­el­len Gefah­ren­quel­len hin­sicht­lich der Ver­trau­lich­keit auf­zei­gen und im Detail die Mög­lich­keit zur Ver­schlüs­se­lung der rela­tio­na­len Daten­quelle mit Hilfe der soge­nann­ten trans­pa­ren­ten Daten­ver­schlüs­se­lung (kurz: TDE) des Micro­soft SQL Ser­vers auf­zei­gen. wei­ter­le­sen…