| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
...
Einer Core Identität kann eine oder mehrere Built-In CoreOne Suite Berechtigungsgruppen zugewiesen werden um die CoreOne Suite internen Berechtigungen zu steuern. Die Berechtigungen der Built-In CoreOne Suite Berechtigungsgruppen können bei Bedarf angepasst werden (nicht empfohlen).
...
Folgende Built-In CoreOne Suite Berechtigungsgruppen werden standardmässig und in Abhängigkeit der lizenzierten Module ausgeliefert:
...
Modul
...
CoreOne Suite Berechtigungsgruppe
...
Zugriff auf Elemente
...
Beschreibung
...
Basis
...
CoreOne Suite Administrator
...
Besitzt Schreibrechte auf alle Module und Elemente.
...
Basis
...
CoreOne Suite Service Desk
...
Besitzt Berechtigungen für die Ausführung von Service Desk Aufgaben
...
Basis
...
CoreOne Suite Self-Service User
...
Meine Daten
Meine Rollen
Meine Identitäten
Meine Anträge (Modul Shop)
Zu bewilligende Anträge (Modul Shop)
...
Besitzt Berechtigungen die persönlichen Daten zu bearbeiten und die ihm zugewiesenen Elemente anzuzeigen.
...
Basis
...
CoreOne Suite Security Supervisor
...
Audit-Trail
Dashboard
Anträge
Berichte
...
Besitzt Leserechte auf alle sicherheitsrelevanten Informationen und Funktionalitäten.
...
Basis
...
CoreOne Suite Stammdaten Manager
...
Stammdaten
...
Besitzt sämtliche Berechtigungen auf die Stammdaten (Meta Directory).
...
Patch Management Orchestrator
...
CoreOne Suite Patch Management Orchestrator Administrator
...
Besitzt Schreibrechte auf alle Elemente des Moduls Patch Management Orchestrator.
...
Patch Management Orchestrator
...
CoreOne Suite Patch Management Orchestrator User
...
Patch Management Orchestrator
...
Patch Management Orchestrator
...
Einsatzbereich
...
Nutzergruppe
...
Typ
...
Aktion
...
Beschreibung
...
Segragation of Duty
Lifecycle Management
...
SoD Rule Owner (Besitzer)
...
Gruppe
...
Bewilligt / verweigert Änderungen
...
Besitzer einer SoD Regel. Gibt Änderungen an einer SoD Rule frei.
Muss bei der Erstellung einer SoD Regel definiert werden.
Wird ein SoD Rule Owner definiert, erhält dieser eine Benachrichtigung, dass er SoD Rule Owner der entsprechenden SoD Rule wurde.
...
Segragation of Duty
...
SoD Rule Attestor (Beglaubiger)
...
Gruppe
...
Bewilligt / verweigert Attestierung
...
Attestieren (beglaubigen) periodisch eine SoD Rule.
Kann bei der Erstellung einer SoD Regel definiert werden. Standardmässig ist der SoD Rule Owner auch der SoD Rule Attestor, wenn er keinen explizieten SoD Rule Attestor definiert.
Wird ein SoD Rule Attestor definiert, erhält dieser eine Benachrichtigung, dass er SoD Rule Attestor der entsprechenden SoD Rule wurde.
...
Segragation of Duty
...
SoD Rule Exception Approver (Bewilliger)
...
Gruppe
...
Bewilligt / verweigert Konflikt
...
Bewilligen, verweigern oder lösen einen SoD Konflikt auf.
Die SoD Rule Exception Attestor werden global definiert - sprich eine oder mehrere Personen erhalten alle Benachrichtigungen über die Regelverletzungen.
Der SoD Rule Exception Approver wird automatisch zum SoD Rule Exception Attestor, wenn er keinen SoD Rule Exception Attestor definiert.
Wird ein SoD Rule Exception Attestor definiert, erhält dieser eine Benachrichtigung, dass er SoD Rule Exception Attestor des entsprechenden Konflikts wurde.
...
Segragation of Duty
...
SoD Rule Exception Attestor (Beglaubiger)
...
Gruppe
...
Bewilligt / verweigert Attestierung
...
Attestieren (beglaubigen) periodisch die SoD Regelverletzungen.
Der SoD Rule Exception Attestor ist eine globale IAM Rolle und wird explizit definiert.
...
Zertifizierung
Lifecycle Management
...
Role Owner (Besitzer)
...
Gruppe
...
Bewilligt / verweigert Änderung
...
Besitzer einer Rolle. Gibt Änderungen an einer Rolle frei, bewilligt Anträge für die Rolle.
...
Zertifizierung
...
Role Assignment Attestor (Beglaubiger)
...
Gruppe
...
Bewilligt / verweigert Attestierung
...
Attestieren (beglaubigen) periodisch die Rollenzuweisungen.
Wenn nicht definiert, ist Role Owner automatisch auch der Role Assignment Attestor und der Role Configuration Attestor.
Wird ein Role Assignment Attestor oder ein Role Configuration Attestor definiert, erhält dieser eine Benachrichtigung.
...
Zertifizierung
...
Role Configuration Attestor (Beglaubiger)
...
Gruppe
...
Bewilligt / verweigert Attestierung
...
Attestieren (beglaubigen) periodisch die Rollenkonfiguration (Inhalt).
...
Zertifizierung
Lifecycle Management
...
Resource Owner (Besitzer)
...
Gruppe
...
Bewilligt / verweigert Änderung
...
Besitzer einer Ressource.
Gibt Änderungen an einer Ressource frei und bewilligt Anträge für die Ressource.
...
Zertifizierung
...
Resource Assignment Attestor (Beglaubiger)
...
Gruppe
...
Bewilligt / verweigert Attestierung
...
Attestieren (beglaubigen) periodisch die Ressourcenzuweisungen.
Wenn nicht definiert, ist Ressource Owner automatisch auch der Ressource Assignment Attestor.
Wird ein Ressource Assignment Attestor definiert erhält dieser eine Benachrichtigung.
...
Zertifizierung
Lifecycle Management
...
Identity Owner (Besitzer)
...
Gruppe
...
Bewilligt / verweigert Änderung
...
Besitzer einer Identität. Gibt Änderungen an einer Identität frei.
Wenn nicht definiert, ist Identity Owner automatisch auch der Identity Attestor.
...
Zertifizierung
...
Identity Attestor (Beglaubiger)
...
Gruppe
...
Bewilligt / verweigert Attestierung
...
Attestieren (beglaubigen) periodisch eine technische Identität.
Wird ein Identity Attestor definiert, erhält dieser eine Benachrichtigung.
...
Zertifizierung
...
Scope Approver (Genehmiger)
...
Gruppe
...
Bewilligt / verweigert
...
Überwachen eine Gruppe von kritischen Berechtigungen
...
Access Approver (Genehmiger)
...
Gruppe
...
Bewilligt / verweigert Attestierung
...
Person welche beantragte Berechtigungen bewilligt oder ablehnt.
...
Access Requester (Antragsteller)
...
Person
...
Beantragt
...
Person welche Berechtigungen direkt über das CoreOne Portal beantragt. Die Auswahl der Berechtigungen (Aufgaben, Rollen, Ressourcen) können eingeschränkt sein.
...
Zertifizierung
...
Access Attestor (Beglaubiger)
...
Gruppe
...
Attestiert
...
Person (Bsp. Linienvorgesetzter) welche vergebene Berechtigungen einer Person oder Gruppe periodisch attestiert.
...
Delegated Access Requester (Antragsteller)
...
Person
...
Beantragt
...
Person welche für eine andere Person Berechtigungen beantragt (Bsp. der Vorgesetzte, Mitarbeiter, der für einer seiner Mitarbeiter Berechtigungen beantragt)
...
Delegated Access Approver (Genehmiger)
...
Person
...
Bewilligt / verweigert
...
Person welche für eine andere Person stellvertretend Berechtigungen bewilligt. Vorausgesetzt die Person delegiert diese Aufgabe für einen definierten Zeitraum an eine andere Person.
Die Auswahl der Personen können eingeschränkt sein (Bsp. nur an gleichgestellte Positionen).
...
Stellevertreter
...
Person
...
-
...
Stellvertreter einer Person. Die Person kann von den Stammdaten abgeleitet werden oder die Person bestimmt explizit und für einen definierten Zeitraum einen Stellvertreter.
...
Direkter Vorgesetzter
...
Person
...
-
...
Direkter Vorgesetzter einer Person.
...
Direkter Vorgesetzter Stellvertreter
...
Person
...
-
...
Stellvertretender, direkter Vorgesetzter einer Person.
...
Human Resources
...
Gruppe
...
-
...
CoreOne Administrator (Systemowner)
...
Administrator einer CoreOne Instanz
...
CoreOne Security Supervisor (Besitzer)
...
Person welche über definierte Vorkommnisse oder Konflikte informiert wird (Bsp. CISO)
...
CoreOne Supervisor (Besitzer)
...
Überwacht die Berechtigungsvergabe innerhalb der CoreOne Suite.
...
CoreOne Zielsystem Owner
...
Besitzer eines spezifischen Zielsystems. Bewilligt Änderungen am Zielsystem.
...
CoreOne Zielnetzwerk Owner
...
Besitzer eines spezifischen Zielnetzwerks. Bewilligt Änderungen am Zielnetzwerk.
...
CoreOne Stammdaten Owner
...
Introduction
By default, the CoreOne Suite is deployed with a set of security roles that you can assign to users to perform basic sets of operations. For example there is a Manage Representations security role. If you assign this role to a user, he will be able to see his representations in the CoreOne Self-Service Portal and can delegate some of his responsibilities to others.
This default security role always cover a basic use case and do have some restrictions attached to it. For example the Manage Representations security role only let’s a user delegate something to another Core Identity for which the user first has created a representation. In an eGoverment environment this is a valid use, but in an enterprise environment you might want to enable the user to delegate his permissions to everyone in the company or to co-workers in the same division or any other use case.
This is where the CoreOne Advanced Permission Management comes into place. This optional module allows you to create your own security rules. A security role contain two things, the view permissions and the data access permission. The view permissions are used across all UIs to handle who has access to which views and which actions. The access permissions are used to determinate what data is available to the user or service within the views or APIs. This way you can give certain users access to view and limit them to a subset of the available data.
Data Access Permissions
Data access permissions are configured by specifying the entity type, a security mode and a security filter. The entity type defines to which entity, i.e. a Core Identity or a Role, a user has access to. The security mode defines the nature of the access such as read, write, delete or similar. And finally the security filter specifies which conditions have to be met in order to give access. This can be anything from full access to only if a specific condition is met. You will find more on that in the Data Access Permissions section. But it’s important to understand that you can configure security filters based on relations and other attributes of the entity.
Security Roles Pitfalls
As we have learned, the security roles are a powerful tool to build various use cases. But there are a few things that need to be considered.
Performance
The more complex the filter get, the more slower the system will be for the user. If no filter is configured for let’s say roles, the user can be served with the list of roles immediately. But if we configure a security filter that only shows roles to a user that match certain criteria, those criteria have to be evaluated at runtime and therefore will take some time. Depending on the amount of roles, the amount of security filters applied and the complexity of the filters, this may be noticeable to the user.
Maintenance
If you build your own custom use case, you might have to combine a few entity rights to cover your use case. For example if you only want to give read rights to roles that are assigned to a specific organizational unit and the user has a specific employment type, you will not only need to give read rights to the roles, but you will also need to give read rights to the users employments, where the employment type of the user is stored. After an update of the Software it is possible that this data structure has changed. For example the employment type of the user might no longer be stored on the employment but on the Core Identity itself. Even tough such changes rarely happen and are documented in the release notes, there is still a chance. So in order to be sure, you should test each of your security role after each update. When designing security roles, you have to take this into account and plan accordingly.
Relying on default roles
If you use any of our default security roles, you have to be aware that they can change. They are intended to cover a standard use case as described in the documentation. But even though that standard use case might match your use case today, does not mean it will automatically match your use case after an update. We might add some rights to the default security rule that will not match your use case, so you should check the release notes carefully.
Creating Custom Security Roles
You can create custom security roles in the Admin UI. Go to Administration -> Securityroles and click create. Make sure to choose a good name for you rule.
This will automatically create a Ressource with the same name. You can use this ressource to assign your new security rule to core identities.
Best practices
Testing, testing, testing
It’s vital that you test your security rules after each update. Create a basic test plan for your most crucial cases and execute them after each update.
Blueprints
If you are planning on creating a lot of security roles that only have minor differences, try to extract the common things into a base security rule and only specify the difference in specific security rules. It might also be useful to create a blueprint, test the blueprint after each update and redeploy all specific rules based on the blue print if you have detected any changes.