Einrichten von Datenzugriffsprofilen
Sie müssen für alle gesicherten Modelldimensionen ein Datenzugriffsprofil definieren.
Ist für eine gesicherte Dimension kein Profil definiert, besitzen die Benutzer, die dem Profil zugeordnet sind, keine Zugriffsrechte für dieses Modell. Wenn Sie den Zugriff nur teilweise definieren, z. B. für eine der beiden gesicherten Dimensionen, können Benutzer dennoch nicht auf das Modell zugreifen.
Sobald Sie ein Datenzugriffsprofil festgelegt haben, können Sie es Ihren Benutzern zuordnen.
Allgemeine Regeln für die Datenzugriffssicherheit
Die Datenzugriffssicherheit basiert auf den folgenden Regeln:
Standardmäßig hat außer dem Systemadministrator niemand Zugriff auf Elemente. Der Zugriff auf Elemente muss explizit erteilt werden.
Einem Benutzer kann der Datenzugriff individuell oder über die Zugehörigkeit zu einem Team zugewiesen werden.
Datenzugriffsrechte werden in einer Hierarchie vom übergeordneten Element an das untergeordnete Element weitergegeben.
Im Fall eines Konflikts wird das am wenigsten restriktive Datenzugriffsprofil angewendet.
Bei einem Konflikt zwischen dem Datenzugriff eines einzelnen Benutzers und dem eines Teams gilt die am wenigsten restriktive Einstellung.
Erstellen von Datenzugriffsprofilen
Gehen Sie zur Seite Administration und wählen im Bereich Sicherheit die Option Datenzugriffsprofile.
Wählen Sie auf dem daraufhin angezeigten Bild Neu.
Geben Sie die ID und die Beschreibung des neuen Datenzugriffsprofil ein.
Wählen Sie aus der Liste das gewünschte Modell aus.
Wählen Sie zu jeder berechtigungsrelevanten Dimension die gewünschten Elemente aus, und legen Sie Zugriffsrechte fest.
Navigieren Sie zur Registerkarte Benutzer bzw. Teams, um das Datenzugriffsprofil den Benutzern, die der aktuellen Umgebung zugewiesen sind, bzw. den Teams, denen die jeweiligen Benutzer zugewiesen sind, zuzuordnen.
Definieren von Zugriffsrechten für Elemente mit untergeordneten Elementen
Beim Definieren von Zugriffsrechten für eine gesicherte Dimension mit mehreren definierten Hierarchien werden die Sicherheitseinstellungen auf das jeweilige Element und alle zugehörigen untergeordneten Elemente angewendet. Wenn Sie beispielsweise Zugriffsrechte für ein Element mit zehn untergeordneten Elementen definieren, haben Benutzer mit Zugriff auf das übergeordnete Element auch Zugriff auf dessen zehn untergeordnete Elemente.
Sie können den Zugriff auf ein untergeordnetes Element eines übergeordneten Elements, dem die Zugriffsrechte „Nur Lesen“ oder „Schreiben“ zugeordnet sind, einschränken, indem Sie ein separates Datenzugriffsprofil erstellen und dem untergeordneten Element das Zugriffsrecht „Verweigern“ zuweisen. Alternativ können Sie dasselbe Datenzugriffsprofil wie für das übergeordnete Element verwenden und eine neue Position für das untergeordnete Element erstellen.
Lösen von Datenzugriffsprofil-Konflikten
Da der Zugriff auf Elemente sowohl für einzelne Benutzer als auch Teams definiert werden kann, können Konflikte auftreten. Im folgenden Abschnitt werden einige mögliche Szenarios von Konflikten beim Zugriff auf Elemente sowie die Regeln, die das System im Fall eines Konflikts anwendet, beschrieben. Diese Szenarios basieren auf der Annahme, dass die Entitätsdimension eine gesicherte Dimension ist und die folgende hierarchische Struktur aufweist:
Hierarchie |
Elemente |
|||
H1 |
Weltweit1 |
Umsatz |
UmsatzAsien |
UmsatzKorea UmsatzJapan EUmsatzAsien |
UmsatzEuropa |
UmsatzItalien UmsatzFrankreich EUmsatzEuropa |
|||
H2 |
Weltweit2 |
Asien |
Korea |
UmsatzKorea |
Japan |
UmsatzJapan |
|||
eAsien |
EUmsatzAsien |
|||
Europa |
Italien |
UmsatzItalien |
||
Frankreich |
UmsatzFrankreich |
|||
eEuropa |
EUmsatzEuropa |
|||
Konflikt zwischen Profilen
Bei einem Konflikt zwischen Datenzugriffsprofilen wird stets das am wenigsten restriktive Profil angewendet. In diesem Abschnitt werden drei verschiedene Szenarios von Konflikten zwischen Profilen veranschaulicht.
Szenario 1:
Benutzer 1 gehört zu Team 1 und Team 2.
Es gibt zwei Datenzugriffsprofile: Profil A und Profil B.
Profil A ist Team 1 und Profil B Team 2 zugeordnet.
Die Datenzugriffsprofile sind in der folgenden Tabelle beschrieben:
Datenzugriffsprofil |
Zugriff |
Dimension |
Element |
Profil A |
Schreiben |
Entität |
Umsatz |
Profil B |
Nur Lesen |
Entität |
UmsatzAsien |
In diesem Fall wird das weniger restriktive Profil, Profil A („Schreiben“), angewendet. Profil B wird folglich vom System ignoriert, und Benutzer 1 kann sowohl Daten an „UmsatzKorea“ als auch „UmsatzItalien“ senden.
Szenario 2:
Benutzer 1 gehört zu Team 1 und Team 2.
Es gibt zwei Datenzugriffsprofile: Profil A und Profil B.
Profil A ist Team 1 und Profil B Team 2 zugeordnet.
Die Datenzugriffsprofile sind in der folgenden Tabelle beschrieben:
Datenzugriffsprofil |
Zugriff |
Dimension |
Element |
Profil A |
Nur Lesen |
Entität |
Umsatz |
Profil B |
Schreiben |
Entität |
UmsatzAsien |
In diesem Fall wird das weniger restriktive Profil, Profil B („Schreiben“), auf die untergeordneten Elemente von „UmsatzAsien“ angewendet. Profil A wird folglich vom System ignoriert, und Benutzer 1 kann Daten an „UmsatzKorea“, jedoch nicht an „UmsatzItalien“ senden.
Szenario 3:
Benutzer 1 gehört keinem Team an.
Es gibt zwei Datenzugriffsprofile: Profil A und Profil B.
Dem Benutzer sind beide Profile zugeordnet.
Die Datenzugriffsprofile sind in der folgenden Tabelle beschrieben:
Datenzugriffsprofil |
Zugriff |
Dimension |
Element |
Profil A |
Verweigern |
Entität |
UmsatzAsien |
Profil B |
Nur Lesen |
Entität |
Umsatz |
In diesem Fall wird das weniger restriktive Profil, Profil B („Nur Lesen“), angewendet. Profil B wird folglich vom System ignoriert, und Benutzer 1 kann sowohl Daten aus „UmsatzKorea“ als auch „UmsatzItalien“ empfangen.
Konflikt zwischen über- und untergeordneten Elementen
Befugnisse werden in einer Hierarchie vom übergeordneten Element an das untergeordnete Element weitergegeben. Sofern nicht anders definiert, verfügen untergeordnete Elemente stets über dieselbe Zugriffsebene wie dessen übergeordnete Elemente.
Szenario 1:
Benutzer 1 gehört zu Team 1, und Profil A ist Team 1 zugeordnet.
Für Profil A sind zwei Datenzugriffsprofile definiert.
Die Datenzugriffsprofile für Profil A sind in der folgenden Tabelle beschrieben:
Datenzugriffsprofil |
Zugriff |
Dimension |
Element |
Profil A |
Schreiben |
Entität |
Umsatz |
Profil A |
Nur Lesen |
Entität |
UmsatzAsien |
In diesem Fall wird das Zugriffsrecht „Schreiben“ des Elements „Umsatz“ an die zugehörigen untergeordneten Elemente weitergegeben. Die Weitergabe wird durch die Zuordnung des Zugriffsrechts „Nur Lesen“ von „UmsatzAsien“ (ein Nachfolger von „Umsatz“) verhindert. Die Zugriffsrechte für „UmsatzAsien“ werden an dessen Nachfolger weitergegeben. Benutzer 1 kann folglich zwar Daten an „UmsatzItalien“, jedoch nicht an „UmsatzKorea“ senden.
Szenario 2:
Benutzer 1 gehört zu Team 1, und Profil A ist Team 1 zugeordnet.
Profil A weist zwei Ebenen von Datenzugriffsprofilen auf.
Die Datenzugriffsprofile für Profil A sind in der folgenden Tabelle beschrieben:
Datenzugriffsprofil |
Zugriff |
Dimension |
Element |
Profil A |
Nur Lesen |
Entität |
Umsatz |
Profil A |
Schreiben |
Entität |
UmsatzAsien |
In diesem Fall wird das Zugriffsrecht „Nur Lesen“ des Elements „Umsatz“ an die zugehörigen untergeordneten Elemente weitergegeben. Die Weitergabe wird durch die Zuordnung des Zugriffsrechts „Schreiben“ von „UmsatzAsien“ (ein Nachfolger von „Umsatz“) verhindert. Die Zugriffsrechte für „UmsatzAsien“ werden an dessen Nachfolger weitergegeben. Benutzer 1 kann folglich zwar Daten an „UmsatzKorea“, jedoch nicht an „UmsatzItalien“ senden.
Konflikte, wenn dasselbe Element verschiedenen Hierarchien angehört
Gehört ein Element verschiedenen Hierarchien an und es kommt zu einem Konflikt beim Zugriff auf einzelne Elemente, wird das restriktivere Zugriffsrecht angewendet.
Szenario: Profil A und Profil B sind Benutzer 1 zugeordnet. Die Datenzugriffsprofile sind in der folgenden Tabelle beschrieben:
Datenzugriffsprofil |
Zugriff |
Dimension |
Element |
Profil A |
Nur Lesen |
Entität |
Weltweit1 |
Profil B |
Schreiben |
Entität |
Weltweit2 |
In diesem Fall ist der Zugriff von Benutzer 1 über das Profil B definiert. Benutzer 1 kann folglich Daten an „UmsatzKorea“ senden, selbst wenn Profil A Benutzer 1 den Schreibzugriff auf „UmsatzKorea“ (in Hierarchie „Weltweit1“) verweigert.
Attributbasierte Datenzugriffsprofile
Beim Erstellen eines Datenzugriffsprofils können Sie mehrere Ebenen von Zugriffsrechten basierend auf Eigenschaften zuordnen. Die nachfolgenden Beispiele basieren auf der folgenden Hierarchie:
ID |
Region |
Land |
Währung |
|---|---|---|---|
Entität0 |
Europa |
Deutschland |
Euro |
— Entität1 |
Europa |
Deutschland |
Euro |
— — Entität101 |
Europa |
Großbritannien |
GBP |
— — Entität102 |
Europa |
Frankreich |
Euro |
— — Entität103 |
Europa |
Deutschland |
Euro |
— Entität2 |
Nordamerika |
USA |
USD |
— — Entität201 |
Nordamerika |
USA |
USD |
— — Entität202 |
Nordamerika |
Kanada |
CAD |
— — Entität203 |
Nordamerika |
Mexiko |
MXN |
Beispiel: Ein Datenzugriffsprofil
Das Datenzugriffsprofil DAP1 ist wie folgt definiert:
Regelnummer |
Elemente |
Zugriff |
Kommentar |
Ergebnis |
|---|---|---|---|---|
1 |
Entität1 |
Lesen |
Zugriff „Lesen“ auf Entität1 und alle nachfolgenden Elemente |
Zugriff „Lesen“ auf Entität1, Entität101, Entität102, Entität103 |
2 |
Land = Deutschland und Währung = Euro |
Schreiben |
Zugriff „Schreiben“ auf Elemente, deren Land „Deutschland“ und Währung „Euro“ ist |
Zugriff „Schreiben“ auf Entität0, Entität1 und Entität103 |
3 |
Entität103 |
Verweigern |
Kein Zugriff auf Entität103 |
Kein Zugriff auf Entität103 |
Bei sich widersprechenden Regeln in einem Datenzugriffsprofil gilt die folgende Priorität (von höchster zu niedrigster):
Die Zugriffsrechte, die für das Element (Basiselement oder übergeordnetes Element) genau definiert wurden.
Die Zugriffsrechte, die durch Attribute definiert wurden (werden nicht vererbt).
BeispielSind die Attribute Currency=Euro: Read und Country=France: Write definiert, ist Entität102 beschreibbar.
Die Zugriffsrechte, die vom übergeordneten Element vererbt wurden.
Die Zugriffsrechte, die für „Alle Elemente“ definiert wurden (wie für das „virtuelle“ übergeordnete Element ganz oben in der Hierarchie definiert).
Das Ergebnis ist in der folgenden Tabelle veranschaulicht:
ID |
Zugriff |
Kommentar |
|---|---|---|
Entität0 |
Schreiben |
Durch Regel 2 definiert. |
Entität1 |
Lesen |
Zugriff „Lesen“ durch Regel 1, Zugriff „Schreiben“ durch Regel 2 definiert. Regel 1 wird angewendet, da sie direkt für Entität1 gilt. |
Entität101 |
Lesen |
Durch Regel 1 definiert. |
Entität102 |
Lesen |
Durch Regel 1 definiert. |
Entität103 |
Verweigern |
Zugriff „Lesen“ durch Regel 1, Zugriff „Schreiben“ durch Regel 2, Zugriff „Verweigern“ durch Regel 3 definiert. Regel 3 wird angewendet, da sie direkt für Entität103 gilt. |
Entität2 |
Verweigern |
Wenn keine Regeln existieren, wird der Zugriff standardmäßig verweigert. |
Entität201 |
Verweigern |
Wenn keine Regeln existieren, wird der Zugriff standardmäßig verweigert. |
Entität202 |
Verweigern |
Wenn keine Regeln existieren, wird der Zugriff standardmäßig verweigert. |
Entität203 |
Verweigern |
Wenn keine Regeln existieren, wird der Zugriff standardmäßig verweigert. |
Beispiel: Zwei Datenzugriffsprofile
Das Datenzugriffsprofil DAP2 ist wie folgt definiert:
Regelnummer |
Elemente |
Zugriff |
Kommentar |
Ergebnis |
|---|---|---|---|---|
1 |
Alle Elemente |
Lesen |
Zugriff „Lesen“ auf alle Elemente |
Zugriff „Lesen“ auf alle Elemente |
2 |
Entität1 |
Verweigern |
Kein Zugriff auf Entität1 und seine Nachfolger |
Kein Zugriff auf Entität1, Entität101, Entität102 und Entität103 |
3 |
Währung = USD |
Schreiben |
Zugriff „Schreiben“ auf Elemente, deren Währung „USD“ ist |
Zugriff „Schreiben“ auf Entität2 und Entität201 |
Das Ergebnis dieses Datenzugriffsprofils wird in der folgenden Tabelle veranschaulicht:
ID |
Zugriff |
Kommentar |
|---|---|---|
Entität0 |
Lesen |
Durch Regel 1 definiert. |
Entität1 |
Verweigern |
Zugriff „Lesen“ durch Regel 1, Zugriff „Verweigern“ durch Regel 2 definiert. Regel 2 wird angewendet, da sie direkt für Entität1 und deren Nachfolger gilt. |
Entität101 |
Verweigern |
Zugriff „Lesen“ durch Regel 1, Zugriff „Verweigern“ durch Regel 2 definiert. Regel 2 wird angewendet, da sie direkt für Entität1 und deren Nachfolger gilt. |
Entität102 |
Verweigern |
Zugriff „Lesen“ durch Regel 1, Zugriff „Verweigern“ durch Regel 2 definiert. Regel 2 wird angewendet, da sie direkt für Entität1 und deren Nachfolger gilt. |
Entität103 |
Verweigern |
Zugriff „Lesen“ durch Regel 1, Zugriff „Verweigern“ durch Regel 2 definiert. Regel 2 wird angewendet, da sie direkt für Entität1 und deren Nachfolger gilt. |
Entität2 |
Schreiben |
Zugriff „Lesen“ durch Regel 1, Zugriff „Schreiben“ durch Regel 3 definiert. Regel 3 wird angewendet, da es direkt für die Eigenschaften von Entität2 gilt. |
Entität201 |
Schreiben |
Zugriff „Lesen“ durch Regel 1, Zugriff „Schreiben“ durch Regel 3 definiert. Regel 3 wird angewendet, da es direkt für die Eigenschaften von Entität201 gilt. |
Entität202 |
Lesen |
Durch Regel 1 definiert. |
Entität203 |
Lesen |
Durch Regel 1 definiert. |
Sind einem Benutzer oder einem Team mehrere Datenzugriffsprofile zugewiesen, wird die Kombination der am wenigsten restriktiven Regeln aller Profile angewendet. Wenn einem Benutzer also sowohl DAP1 und DAP2 zugeordnet sind, besitzt der Benutzer die folgenden Berechtigungen:
ID |
Zugriff gewährt durch DAP1 |
Zugriff gewährt durch DAP2 |
Ergebnis |
|---|---|---|---|
Entität0 |
Schreiben |
Lesen |
Zugriff „Schreiben“ |
Entität1 |
Lesen |
Verweigern |
Zugriff „Lesen“ |
Entität101 |
Lesen |
Verweigern |
Zugriff „Lesen“ |
Entität102 |
Lesen |
Verweigern |
Zugriff „Lesen“ |
Entität103 |
Verweigern |
Verweigern |
Zugriff verweigert |
Entität2 |
Verweigern |
Schreiben |
Zugriff „Schreiben“ |
Entität201 |
Verweigern |
Schreiben |
Zugriff „Schreiben“ |
Entität202 |
Verweigern |
Lesen |
Zugriff „Lesen“ |
Entität203 |
Verweigern |
Lesen |
Zugriff „Lesen“ |