Rund um das Repository

Mit Delta­Master 6 erscheint das Repo­si­to­ry – das nun Repo­si­to­ry Rol­len­ver­wal­tung heißt – nicht nur in einem neu­em Desi­gn, es ist auch um eini­ge neue und mäch­ti­ge Funk­tio­nen erwei­tert wor­den. Wie die­se opti­mal genutzt wer­den kön­nen, wird im Fol­gen­den beschrie­ben. wei­ter­le­sen…

Repräsentative Daten

Die meis­ten Anwen­dungs­sys­te­me – und somit auch unse­re 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­li­ch noch ein Test­sys­tem (QS) für unter­schied­li­che Benut­zer­grup­pen und Test­sze­na­ri­en zwi­schen­ge­schal­tet. Grund­sätz­li­ch 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­di­ge und gewünsch­te Ände­run­gen sepa­rat vom pro­duk­ti­ven Sys­tem ent­wi­ckelt, getes­tet und vom Kun­den fach­li­ch 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­ti­ve Test­ergeb­nis­se 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 The­ma Berech­ti­gun­gen wur­de bereits mehr­fach berich­tet, den­no­ch gibt es immer wie­der neue inter­es­san­te Lösun­gen. Neu­li­ch beim Kun­den in Shang­hai hat­te das The­ma Berech­ti­gun­gen aller­höchs­te Prio­ri­tät auf­grund der hohen Fluk­tua­ti­on von Mit­ar­bei­tern. Die Anfor­de­run­gen waren dem­entspre­chend hoch und ver­meint­li­ch wider­sprüch­li­ch: Berech­ti­gun­gen soll­ten mög­lichst fle­xi­bel je Abtei­lung, je Regi­on und je Kenn­zahl ver­ge­ben wer­den kön­nen und das natür­li­ch 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­ga­be 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 Fra­ge. Jeder Anwen­der hat einen AD-User, und die IT braucht den Mit­ar­bei­ter aus­schließ­li­ch 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­li­ch 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­re­re 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­zel­ne 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­ga­be 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 Wei­se gelöst wer­den. Es kön­nen Lese- oder Schreib­be­rech­ti­gun­gen auf die gan­ze Daten­bank, auf einen oder meh­re­re Wür­fel und Mea­su­res­groups ver­ge­ben, oder ein­zel­ne Ele­men­te einer Dimen­si­on oder Mea­su­res für den Zugriff gesperrt wer­den. Die­se 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­ri­en 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 sei­ne Regi­on oder sei­ne Kos­ten­stel­le sehen darf, muss für jeden Anwen­der eine eige­ne Rol­le mit den ent­spre­chen­den Berech­ti­gun­gen erstellt wer­den. Wird beim Reporting der SQL-Durch­griff zur Ana­ly­se von Beleg­da­ten genutzt, müs­sen die­se 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­ga­be 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 die­se anschlie­ßend auto­ma­ti­sch an einen Berech­ti­gungs­wür­fel auf der OLAP-Daten­bank zu über­ge­ben (sie­he Bei­trag Rech­te­ver­wal­tung in SSAS – Teil 2). Oft wird die Ver­ant­wor­tung für die Berech­ti­gungs­pfle­ge an die Fach­ab­tei­lung dele­giert. Die IT-Abtei­lung stellt eine spe­zi­ell benann­te Benut­zer­grup­pe im Active-Direc­to­ry (AD) zur Ver­fü­gung, der alle Benut­zer mit Zugriff auf die BI-Anwen­dung zuge­ord­net wur­den. Die Ver­ga­be der Berech­ti­gun­gen der ein­zel­nen Benut­zer inner­halb die­ser AD-Grup­pe 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. sei­ne berech­tig­te Kos­ten­stel­le zuwei­sen kann. Damit die Berech­ti­gun­gen wir­ken, muss der kor­rek­te Name der Kos­ten­stel­le und der kor­rek­te Benut­zer­na­me ange­ge­ben wer­den. Dies stellt aber oft ein Pro­blem dar, da nicht immer bekannt ist, wie der genaue Benut­zer­na­me im Active-Direc­to­ry 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-Grup­pe 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 Lis­te mit­tels einer SQL-Abfra­ge 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­li­ch 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­si­on ent­hal­te­nen Ele­men­te. Die (mäch­ti­ge­re) Zell­si­cher­heit wird nor­ma­ler­wei­se nur benö­tigt, wenn die Steue­rung der Nut­zer­rech­te anhand der Ele­men­te (nur) einer Dimen­si­on nicht mehr aus­reicht.

Der Ein­satz der Zell­si­cher­heit hat aller­dings auch eini­ge Tücken. Ers­tens blei­ben wei­ter­hin alle Ele­men­te 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­rech­te (nach oben) auf die Aggre­ga­te ver­erbt. Das heißt, hat ein Nut­zer das Recht min­des­tens ein Ele­ment einer bestimm­ten Ebe­ne zu sehen, so sieht er auch das ech­te Aggre­gat aller Ele­men­te die­ser Ebe­ne, unab­hän­gig davon, ob ein­zel­ne Ele­men­te die­ser Ebe­ne per SEC geschützt sind.

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

Back(upp)en mit Rezept

Ein regel­mä­ßi­ges Back­up der von uns bear­bei­te­ten Sys­te­me lässt einen meist ruhig schla­fen, kor­rekt? – Stimmt, wenn es denn ein Back­up gibt und man dar­auf ver­trau­en 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ä­ßi­ge War­tungs­plä­ne, gan­ze 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 Medi­en 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­men­ge kann es kom­pli­ziert wer­den. Wei­ter­füh­ren­de Details und Hin­ter­grün­de 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­gen­ce Pro­jekt von der Fach­ab­tei­lung an der IT vor­bei begon­nen und ein­ge­führt wird und unse­re 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 zei­ge ich auf den fol­gen­den Sei­ten. wei­ter­le­sen…

Sehen und gesehen werden

In die­sem Bei­trag möch­te 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­li­ch schon mit der Fra­ge beschäf­tigt, was sieht ein Benut­zer tat­säch­li­ch, nach­dem man sich bei der Rech­te­ver­ga­be auf der OLAP-Daten­bank aus­ge­tobt hat. Dazu stel­le ich einen klei­nen, aber fei­nen Trick vor.

Spricht man mit IT-Admi­nis­tra­to­ren, wei­se 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 Datei­en oder Ver­zeich­nis­sen ist man gewöhnt, dass wenn ein­mal einem Benut­zer ein belie­bi­ges Recht ent­zo­gen wur­de, dann bleibt die­se Restrik­ti­on erhal­ten, egal wor­über son­st einem viel­leicht ein höhe­res Recht ein­ge­räumt wird. Die­ser Grund­ge­dan­ke bie­tet einen recht guten Schutz gegen Fehl­kon­fi­gu­ra­ti­on und damit uner­wünsch­te Zugriffs­rech­te.

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

Was es bei dem Ein­satz von Berech­ti­gun­gen auf Kenn­zah­len geson­dert zu beach­ten gilt, schau­en 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-Datei­en 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­to­ry bereit­zu­stel­len. Die beson­de­re Her­aus­for­de­rung war, dass der Über­tra­gungs­zy­klus (von DEV nach QS nach PROD) so gestal­tet wer­den soll­te, dass die Rech­te-Ein­stel­lun­gen im Repo­si­to­ry 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 wer­de 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­ta­re” beschrie­ben, bie­tet Delta­Master die Mög­lich­keit, für ein­zel­ne Zell­wer­te Zell­kom­men­ta­re zu erfas­sen. Das kann z. B. sehr hilf­reich sein, wenn wäh­rend einer Pla­nungs­pha­se gen­au beschrie­ben wer­den soll, war­um ein Plan­wert in einer bestimm­ten Höhe erfasst wur­de oder eine Abwei­chun­gen zustan­de 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 Wer­te auf der für ihn defi­nier­ten Aggre­ga­ti­ons­ebe­ne ein­ge­ben. Bei­spiels­wei­se kann es Pla­ner geben, die nur ein­zel­ne Pro­duk­te pla­nen dür­fen. Ande­re wie­der­um dür­fen gan­ze Pro­dukt­grup­pen pla­nen, bzw. die aggre­gier­ten Plan­wer­te 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 Schrit­te dafür not­wen­dig sind, soll der fol­gen­de 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­di­an damit began­nen, gehei­me Doku­men­te 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, wur­de der Welt­öf­fent­lich­keit klar, wie trans­pa­rent schein­bar jeg­li­che Kom­mu­ni­ka­ti­on und damit auch die dadurch erho­be­nen Daten eines jeden von uns sind. Die dadurch neu­ent­fach­te Debat­te 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 vor­an das Finanz- und Ban­ken­we­sen, haben in den meis­ten Fäl­len fest­ge­schrie­be­ne Regeln, wie mit all­ge­mei­nen Geschäfts­da­ten umzu­ge­hen ist. In Deutsch­land wer­den die­se 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­zie­le 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­gen­ce-Pro­jek­ten? Der fol­gen­de Arti­kel soll die poten­zi­el­len Gefah­ren­quel­len hin­sicht­li­ch 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­quel­le mit Hil­fe 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…