Fachbeitrag · Wirtschaftsinformatik ·
Berechtigungsrollen: Warum zwei einzeln passende Rollen zusammen einen Konflikt erzeugen können
Eine Rolle erlaubt das Anlegen eines Vorgangs, eine andere dessen Freigabe. Für sich betrachtet kann jede Rolle sachgerecht sein. Werden beide derselben Person zugewiesen, entsteht jedoch möglicherweise ein unerwünschter Gesamtzugriff. Rollenbasierte Berechtigungskonzepte müssen deshalb nicht nur einzelne Rechtepakete beschreiben. Sie brauchen auch Regeln für Kombinationen, Vererbungen und die Frage, wer innerhalb eines konkreten Vorgangs welche Schritte bereits ausgeführt hat.

Statische und dynamische Trennung unterscheiden
Bei statischer Funktionstrennung wird schon die gleichzeitige Zuweisung bestimmter Rollen ausgeschlossen. Eine dynamische Trennung prüft dagegen bei der Ausführung, ob eine Person die betreffende Kombination in diesem Kontext nutzen darf. So kann jemand grundsätzlich sowohl Anträge bearbeiten als auch freigeben, den eigenen Antrag jedoch nicht selbst abschließen. Diese zweite Variante benötigt Informationen über den Ablauf und die Identität der Beteiligten. Eine bloße Liste von Rollenbezeichnungen bildet die fachliche Regel nicht vollständig ab.
Auch geerbte Rechte betrachten
Rechte entstehen oft nicht ausschließlich durch direkte Rollenzuweisungen. Sammelrollen, Gruppenmitgliedschaften und übergeordnete Rollen können weitere Berechtigungen vermitteln. Ein Konflikttest muss deshalb den wirksamen Zugriff betrachten. Wird eine Berechtigung aus einer untergeordneten Rolle geerbt, verschwindet der mögliche Konflikt nicht durch einen anderen Namen der übergeordneten Rolle. Auch zeitlich befristete Zusatzrechte sind einzubeziehen. Eine sauber dokumentierte Ausnahme benennt Zweck, Geltungsbereich, Laufzeit und die vorgesehenen zusätzlichen Kontrollen.
Einen Vorgang durchspielen
In einem vereinfachten Stammdatenprozess darf eine Person eine neue Lieferadresse erfassen. Eine zweite Person prüft die Änderung, bevor sie produktiv genutzt wird. Der Test endet nicht bei der Frage, ob zwei unterschiedliche Konten angemeldet sind. Er prüft auch, ob beide Konten tatsächlich unterschiedlichen verantwortlichen Personen zugeordnet sind und ob eine Vertretungsregel den Kontrollschritt ungewollt aufhebt. Erfolgreiche und abgewiesene Freigabeversuche werden mit Vorgangskennung und relevanter Rolle nachvollziehbar protokolliert.
Grenzen und Pflege einplanen
Funktionstrennung verhindert nicht jede denkbare Absprache oder jeden fachlichen Fehler. Sie begrenzt bestimmte Möglichkeiten und macht Kontrollanforderungen prüfbar. Die Konfliktregeln müssen zu realen Aufgaben passen, sonst entstehen schwer bearbeitbare Ausnahmebestände. Bei Änderungen der Organisation, neuer Schnittstellen oder zusätzlicher Automatisierung werden sie erneut betrachtet. Entscheidend ist nicht die Anzahl der Rollen, sondern ob erlaubte Arbeit möglich bleibt und kritische Kombinationen im tatsächlichen Systemzustand erkannt oder wirksam verhindert werden.
Technical insight · Business information systems ·
Access roles: Why two individually suitable roles can create a conflict together
One role allows a request to be created; another allows it to be approved. Each role may be appropriate in isolation. Assigning both to the same person can nevertheless create an unwanted combined capability. Role-based access design therefore needs more than descriptions of individual permission packages. It also requires rules for combinations, inheritance and the actions a person has already performed within a particular transaction.

Distinguish static and dynamic separation
Static separation of duties prevents certain roles from being assigned together. Dynamic separation checks at execution time whether a person may use a particular combination in the current context. Someone might therefore be permitted to process requests and approve requests in general, but not to approve their own request. The dynamic approach needs process history and participant identity. A simple list of role names does not fully capture that business rule.
Consider inherited permissions as well
Permissions often come from more than direct role assignment. Composite roles, group membership and higher-level roles can grant additional access. Conflict checks must therefore consider effective permissions. If a permission is inherited from a subordinate role, changing the name of the higher-level role does not remove the potential conflict. Temporary additional access also belongs in the analysis. A documented exception should state its purpose, scope, duration and the additional controls that are intended to apply.
Walk through a concrete transaction
In a simplified master-data process, one person enters a new delivery address. Another reviews the change before it is used in production. Testing should go beyond checking that two different accounts were logged in. It should establish that the accounts are actually assigned to different accountable people and that a delegation rule does not unintentionally remove the control step. Successful and rejected approvals are recorded using the transaction identifier and relevant role.
Plan for limits and maintenance
Separation of duties cannot prevent every possible collusion or business error. It restricts specific capabilities and makes control requirements testable. Conflict rules must match real work, otherwise they produce exceptions that are difficult to manage. Revisit them when the organisation changes, new interfaces are introduced or automation gains additional permissions. The key measure is not how many roles exist, but whether legitimate work remains possible and critical combinations are detected or prevented in the actual system state.
Approfondimento tecnico · Sistemi informativi aziendali ·
Ruoli di accesso: perché due ruoli singolarmente adeguati possono creare un conflitto insieme
Un ruolo consente di creare una richiesta; un altro di approvarla. Ogni ruolo può essere appropriato se considerato da solo. Assegnarli entrambi alla stessa persona può tuttavia creare una capacità combinata indesiderata. Progettare gli accessi in base ai ruoli richiede quindi più della descrizione dei singoli pacchetti di permessi. Servono anche regole per le combinazioni, l’ereditarietà e le azioni che una persona ha già svolto in una determinata operazione.

Distinguere separazione statica e dinamica
La separazione statica delle funzioni impedisce di assegnare insieme determinati ruoli. Quella dinamica verifica al momento dell’esecuzione se una persona possa utilizzare una specifica combinazione nel contesto attuale. Una persona può quindi essere autorizzata in generale a elaborare e approvare richieste, ma non ad approvare la propria. L’approccio dinamico richiede la cronologia del processo e l’identità dei partecipanti. Un semplice elenco di nomi dei ruoli non rappresenta completamente questa regola operativa.
Considerare anche i permessi ereditati
I permessi spesso non derivano soltanto dall’assegnazione diretta dei ruoli. Ruoli compositi, appartenenze a gruppi e ruoli sovraordinati possono concedere ulteriori accessi. Le verifiche dei conflitti devono quindi considerare i permessi effettivi. Se un permesso viene ereditato da un ruolo subordinato, rinominare quello superiore non elimina il possibile conflitto. Nell’analisi rientrano anche gli accessi aggiuntivi temporanei. Un’eccezione documentata dovrebbe indicare scopo, ambito, durata e controlli aggiuntivi previsti.
Seguire un’operazione concreta
In un processo semplificato di gestione dei dati anagrafici, una persona inserisce un nuovo indirizzo di consegna. Un’altra verifica la modifica prima che venga utilizzata in produzione. I test devono andare oltre la verifica dell’accesso con due account diversi. Devono accertare che gli account siano effettivamente attribuiti a persone responsabili diverse e che una regola di delega non elimini involontariamente il controllo. Approvazioni riuscite e respinte vengono registrate con l’identificativo dell’operazione e il ruolo pertinente.
Prevedere limiti e manutenzione
La separazione delle funzioni non può impedire ogni possibile collusione o errore operativo. Limita determinate capacità e rende verificabili i requisiti di controllo. Le regole sui conflitti devono corrispondere al lavoro reale, altrimenti generano eccezioni difficili da gestire. Vanno riesaminate quando cambia l’organizzazione, vengono introdotte nuove interfacce o l’automazione ottiene ulteriori permessi. La misura decisiva non è il numero dei ruoli, ma la possibilità di svolgere il lavoro legittimo e di rilevare o impedire le combinazioni critiche nello stato effettivo del sistema.
Artículo técnico · Sistemas de información empresarial ·
Roles de acceso: por qué dos roles adecuados por separado pueden generar un conflicto al combinarse
Un rol permite crear una solicitud; otro permite aprobarla. Cada uno puede ser apropiado por separado. Sin embargo, asignar ambos a la misma persona puede crear una capacidad combinada no deseada. Por ello, el diseño del acceso basado en roles requiere algo más que descripciones de paquetes individuales de permisos. También necesita reglas sobre combinaciones, herencia y las acciones que una persona ya ha realizado en una operación concreta.

Distinguir la separación estática de la dinámica
La separación estática de funciones impide asignar conjuntamente determinados roles. La separación dinámica comprueba durante la ejecución si una persona puede utilizar una combinación concreta en el contexto actual. Así, alguien puede tener permiso general para tramitar y aprobar solicitudes, pero no para aprobar la suya propia. El enfoque dinámico necesita el historial del proceso y la identidad de los participantes. Una simple lista de nombres de roles no recoge por completo esa regla operativa.
Considerar también los permisos heredados
Los permisos no suelen proceder únicamente de la asignación directa de roles. Los roles compuestos, la pertenencia a grupos y los roles superiores pueden conceder acceso adicional. Por tanto, las comprobaciones de conflictos deben considerar los permisos efectivos. Si un permiso se hereda de un rol subordinado, cambiar el nombre del rol superior no elimina el posible conflicto. El acceso adicional temporal también forma parte del análisis. Una excepción documentada debe indicar su finalidad, alcance, duración y los controles adicionales previstos.
Recorrer una operación concreta
En un proceso simplificado de datos maestros, una persona introduce una nueva dirección de entrega. Otra revisa el cambio antes de utilizarlo en producción. Las pruebas deben ir más allá de comprobar que se iniciaron sesiones con dos cuentas distintas. Deben establecer que las cuentas corresponden realmente a personas responsables diferentes y que una regla de delegación no elimina involuntariamente el paso de control. Las aprobaciones aceptadas y rechazadas se registran con el identificador de la operación y el rol correspondiente.
Prever límites y mantenimiento
La separación de funciones no puede impedir toda posible colusión o error operativo. Restringe capacidades específicas y permite comprobar los requisitos de control. Las reglas de conflicto deben ajustarse al trabajo real; de lo contrario, generan excepciones difíciles de gestionar. Deben revisarse cuando cambia la organización, se introducen interfaces nuevas o la automatización obtiene permisos adicionales. La medida clave no es cuántos roles existen, sino si sigue siendo posible el trabajo legítimo y si las combinaciones críticas se detectan o impiden en el estado real del sistema.