Polski (PL) 
English (United Kingdom) 
Unabhängige IFS-Cloud-Beratung · Sicherheit und Compliance
Permission Sets und Funktionstrennung in IFS Cloud: vom Prüfungsrisiko zurück zu einem Zugriffsmodell, das arbeitet
Auf einen Blick
- Aufgeblähte Berechtigungen entstehen mechanisch durch Kopieren: Eine Kopie übernimmt jedes Recht der Vorlage, auch die, die die Vorlage längst nicht haben sollte, und nirgends steht, warum ein einzelnes Recht existiert.
- Ein Zugriffsmodell, dem ein Prüfer folgen kann, besteht aus Fachrollen und einem gemeinsamen Basisprofil. Dann beantwortet das Modell die Frage „Warum hat diese Person dieses Recht?“ und nicht ihre Beschäftigungsgeschichte.
- Ein in Page Designer ausgeblendetes Feld verschwindet vom Bildschirm, bleibt aber in der Projection. Wer die Projection über OData erreicht, kann es weiter lesen. Die Absicherung gehört in die Projection, nicht auf die Seite.
- Funktionstrennung (Segregation of Duties, SoD) ist eine Eigenschaft des Berechtigungsmodells, nicht eines Richtliniendokuments: Hat ein Benutzer sowohl das Recht, Lieferanten anzulegen, als auch das Recht, Zahlungen freizugeben, existiert die Kontrolle nicht, was auch immer die Richtlinie sagt.
- Eine kleine Zahl bewusst benannter Permission Sets verkürzt die Einarbeitung neuer Mitarbeiter und macht Evergreen-Releases planbar, weil Sie auflisten können, welche Rollen eine neue oder geänderte Projection berührt.
Sicherheitsschulden in einem ERP verhalten sich wie jede technische Schuld: billig zu erzeugen, unsichtbar, solange nichts passiert, und teuer genau dann, wenn der Berechtigungsbestand sauber sein muss. In IFS Cloud sammeln sie sich in Permission Sets, die kopiert statt entworfen wurden, in Administratorrechten, die für ein Go-live vergeben und nie zurückgenommen wurden, und in Zugriffsentscheidungen, die nirgends stehen außer in der Tabelle der Rechte selbst. Das System läuft weiter. Die Rechnung kommt in der Prüfung, denn der Prüfer fragt nicht, ob die Benutzer ihre Arbeit erledigen können. Er verlangt den Nachweis, dass sie nichts anderes können, und eine kopierte Rolle kann diese Frage nicht beantworten.
Dieser Artikel zeigt, woher die Aufblähung auf Objektebene kommt, wie eine Zugriffsmatrix aussieht, die den Nachweisanforderungen von ISO 27001 und SOC 2 genügt, warum mobile Anwendungen und Außendienst der Ort sind, an dem eine Kontrolle auf Seitenebene still aufhört, eine Kontrolle zu sein, und was ein sauberes Modell dem Unternehmen zurückgibt. Es ist das Sicherheitsgegenstück zur Frage, wie der Kern von IFS Cloud sauber bleibt: In beiden Fällen zählt nicht, ob etwas heute funktioniert, sondern was es beim nächsten Release und bei der nächsten Prüfung kostet.
1.Woher die Aufblähung der Permission Sets kommt
Ein kopiertes Permission Set erbt jedes Recht, das die Vorlage im Moment des Kopierens hielt, ohne Vermerk darüber, welche dieser Rechte die Vorlage tatsächlich brauchte. Das ist der ganze Mechanismus. Stößt ein neuer Einkäufer dazu und der Administrator kopiert das Set eines Kollegen, der seit neun Jahren im Haus ist, erhält der Neue die Rechte, die sich über drei Rollenwechsel angesammelt haben, dazu die temporären Rechte aus dem Go-live, als jemand Daten laden musste. Nichts in der Kopie markiert, welche Rechte bewusst vergeben wurden.
Wiederholt sich das Jahr für Jahr, ist der Berechtigungsbestand kein Modell, sondern Sediment. Zwei Sets mit fast gleichem Namen unterscheiden sich durch Rechte, die niemand erklären kann. Ein Set, das nach einer Stellenbezeichnung benannt ist, passt nicht zu dem, was die Stelleninhaber heute tun. Der Praxistest ist kurz: Nehmen Sie ein beliebiges Recht in einem beliebigen Permission Set und fragen Sie, welcher Geschäftsprozess es verlangt. Lautet die ehrliche Antwort „es war in dem Set, das wir kopiert haben“, ist das Modell bereits gescheitert.
Was das unter Evergreen kostet
IFS-Cloud-Releases verändern Projections, und ein Permission Set ist eine Menge von Rechten auf Projections. Teilt ein Release eine Projection, benennt eine Action um oder führt einen neuen Sicherheitscheckpoint ein, lässt sich ein Set, das aus einer bewusst gewählten Liste benötigter Projections besteht, an einem Nachmittag gegen diese Änderung prüfen. Ein Set mit Hunderten geerbter Rechte lässt das nicht zu, denn niemand kann die Rechte, die neu zu prüfen sind, von denen trennen, die nie gebraucht wurden. Es ist dieselbe Dynamik wie bei der Upgrade-Vorbereitung, nur auf Sicherheit statt auf Code angewandt: Der Aufwand eines Upgrades hängt davon ab, wie viel vom Bestand Sie noch erklären können.
Der typische Prüfungsbefund: Der Mangel ist nicht ein falsches Recht. Der Mangel ist ein Bestand, in dem niemand sagen kann, ob ein Recht falsch ist. Damit lässt sich kein einziges Recht nachprüfen, und das Modell ist insgesamt nicht prüffähig.
Dauerhafte Administratorrechte
Voller Systemzugriff, der für ein konkretes Problem vergeben wurde, kann dauerhaft bestehen bleiben, weil sein Entzug voraussetzt, dass jemand klärt, was der Inhaber tatsächlich braucht, und diese Klärung ist Arbeit, die niemandem zugewiesen ist. Zwei Folgen ergeben sich. Gelangen Zugangsdaten eines solchen Kontos in falsche Hände, liegt der gesamte Datenbestand offen und nicht nur ein Prozess. Als Prüfungsbefund tritt jedoch die zweite Folge auf: Das Konto hebelt jede Funktionstrennung auf einmal aus, denn ein Benutzer mit Administratorrechten erfüllt per Definition beide Seiten jedes Konfliktpaares. Dieselbe Konzentration zeigt sich organisatorisch, wenn Wissen und Zugriff bei einer einzigen Person liegen. Deshalb stoßen Zugriffsprüfungen und Nachfolgeplanung auf dieselben Namen.
2.Eine Zugriffsmatrix aufbauen, der ein Prüfer folgen kann
Das Prinzip der minimalen Rechte (Least Privilege) lässt sich nur belegen, wenn der Zugriff aus Geschäftsprozessen abgeleitet ist und nicht aus einzelnen Personen. Ein Prüfer nach ISO 27001 oder SOC 2 testet nicht, ob Ihr Zugriff abstrakt minimal ist. Er verlangt auf Anforderung die Regel, die einer bestimmten Person ein bestimmtes Recht gegeben hat. Das ist eine Frage nach der Struktur, und eine Struktur muss entworfen sein, bevor sie sich nachweisen lässt.
Schritt 1: Rechte Prozessen zuordnen, nicht Personen
Gehen Sie von den Fachrollen aus, die das Unternehmen tatsächlich betreibt: Kreditorenbuchhalter, Einkäufer, Lagerleiter, Instandhaltungstechniker, Kreditkontrolle. Listen Sie für jede Rolle die Projections, Seiten und Actions auf, die der Prozess wirklich verlangt, und bauen Sie daraus ein Permission Set, das nur dies enthält. Die Benennung entscheidet, ob das den nächsten Administrator überlebt: Ein Set, das nach dem Prozess heißt, den es ermöglicht, lässt sich gegen diesen Prozess prüfen, ein Set mit dem Namen einer Abteilung oder einer Person nicht. Die Prozesse zuerst zu beschreiben, ist dieselbe Vorarbeit wie beim zentralen Einkauf in IFS Cloud, und beide Übungen speisen sich gegenseitig, denn einen Prozess, den Sie nicht beschreiben können, können Sie auch nicht mit Zugriffsrechten eingrenzen.
Schritt 2: Basisprofil und Rolle trennen
Jeder Benutzer erbt ein globales Basis-Set für Zugriffe ohne Trennungsrisiko: die Lobby für Mitarbeiter, den Grundzugriff auf Dokumente, die persönliche Zeiterfassung. Alles Prozessspezifische liegt in der Fachrolle, die darübergelegt wird. Diese Trennung erledigt einen Teil der Prüfarbeit, weil aus „Warum sieht diese Person das?“ eine Antwort in zwei Zeilen wird: Entweder liegt der Zugriff im Basisprofil, das für alle gilt und einmal geprüft wird, oder in einer benannten Rolle, die auf einen dokumentierten Prozess verweist. Ohne die Trennung ist jeder Benutzer eine eigene Untersuchung.
Schritt 3: Konflikte ausdrücklich festlegen
Funktionstrennung wird durch das Berechtigungsmodell durchgesetzt oder gar nicht. Die Kontrolle, die in IFS Cloud am dringendsten gebraucht wird, lautet: Wer einen Lieferanten anlegen oder ändern darf, darf keine Zahlung an einen Lieferanten freigeben, denn beide Rechte zusammen reichen aus, Geld auf ein Konto zu lenken, das der Inhaber kontrolliert. Weitere Standardpaare: Eingangsrechnung erfassen und im Hauptbuch buchen, Bestand korrigieren und eine Lieferung freigeben, Personalstammdaten ändern und die Lohnabrechnung ausführen.
Schreiben Sie diese Paare als Konfliktmatrix auf, bevor Sie die Sets entwerfen, und prüfen Sie das fertige Modell dagegen, indem Sie die Benutzer auflisten, die beide Seiten jedes Paares halten. IFS Cloud bietet Berichte über Zuweisungen von Permission Sets, die diese Analyse stützen. Ob die Konflikterkennung in Ihrem Release und Ihrer Konfiguration laufend arbeitet oder nur auf Abruf, sollten Sie in Ihrer eigenen Umgebung klären, bevor Sie sie dem Prüfer als laufende Kontrolle vorstellen.
| Prüfanforderung | Wo sie in IFS Cloud umgesetzt wird | Nachweis für den Prüfer |
|---|---|---|
| Identifikation | IAM-Anbindung an den Identitätsanbieter des Unternehmens | Anmeldeprotokolle aus SAML / Entra ID |
| Autorisierung | Permission Sets mit Geltungsbereich Projection, nach Fachrolle zugewiesen | Berichte zu Zuweisungen von Permission Sets plus die Zuordnung Rolle zu Prozess |
| Funktionstrennung | Konfliktmatrix, angewandt auf das Berechtigungsmodell | Liste der Benutzer, die beide Seiten eines definierten Konfliktpaares halten |
| Nachvollziehbarkeit | Konfiguration des Änderungsverlaufs (History Log) für die betroffenen Objekte | Protokoll der Datensatzänderungen mit Benutzer und Zeitstempel |
| Prüfturnus | Geplante Rezertifizierung der Rollen und ihrer Inhaber | Datierte Prüfprotokolle mit Name des Freigebenden |
Die rechte Spalte entscheidet über den Verlauf der Prüfung. Eine Kontrolle, die Sie ausüben, aber nicht belegen können, zählt als nicht vorhandene Kontrolle. Deshalb gehört die Zeile zur Rezertifizierung in die Tabelle, obwohl sie kein technisches Artefakt erzeugt. Dieselbe Nachweisdisziplin gilt für Datenmodell und Data Governance in IFS Cloud, und beide Prüfungen laufen auf eine Frage hinaus: Wer darf was ändern, und wie würden Sie das im Nachhinein belegen?
3.Mobiler Zugriff: Ein Feld auszublenden sichert es nicht
Im Außendienst trifft der Zugriffsentwurf auf seine härteste Bedingung: Ein Techniker beim Kunden braucht von IFS Cloud genug, um einen Arbeitsauftrag abzuschließen, auf einem Gerät, das offline sein kann, ohne einen Weg in Finanz- oder Personaldaten mitzuführen. Der typische Fehler ist unauffällig genug, um die Abnahmetests zu überstehen.
Page Designer blendet aus, Projections sichern ab
Wer ein Feld im Page Designer entfernt, ändert, was der Client darstellt, nicht, was die Projection zurückgibt. Stellt die zugrunde liegende Projection das Feld weiter bereit und hat der Benutzer das Recht, lässt sich der Wert per direkter OData-Anfrage abrufen. Das ist eine unterstützte Schnittstelle und kein Exploit. Jede Kontrolle, die nur auf der Seite besteht, ist daher kosmetisch. Die Regel dazu ist kurz: Legen Sie an der Projection fest, was eine Rolle lesen darf, und behandeln Sie das Seitenlayout als Frage der Bedienbarkeit, die danach kommt.
Diese Prüfung gehört in den Testplan und nicht in ein Sicherheitsreview achtzehn Monate später. Nehmen Sie ein Testkonto, das nur die mobile Rolle trägt, rufen Sie die Projection direkt auf und bestätigen Sie, dass die Antwort kein Feld enthält, auf das diese Rolle keinen Anspruch hat. Dasselbe Projection-Denken liegt dem Überwachen von IFS Cloud über schreibgeschütztes OData zugrunde: Was die API zurückgibt, ist die tatsächliche Grenze.
Offline-Zwischenspeicher verlegen die Grenze auf das Gerät
Daten, die für den Offline-Betrieb auf ein mobiles Gerät synchronisiert werden, liegen außerhalb des Sicherheitsperimeters von IFS Cloud, solange sie dort bleiben. Daraus folgen zwei Entwurfsentscheidungen. Begrenzen Sie den Zwischenspeicher auf das, was der Einsatz verlangt, zum Beispiel die offenen Arbeitsaufträge mit den zugehörigen Ersatzteilen und Kundendaten, statt aus Bequemlichkeit einen größeren Datenbestand zu spiegeln. Und halten Sie den Entzug zentral: Scheidet jemand aus, muss das Deaktivieren der Identität im Unternehmensverzeichnis den Zugriff überall beenden. Das gilt nur, wenn die Anmeldung tatsächlich über IAM läuft und daneben kein lokaler Zugangsweg besteht.
Der Umgang mit Austritten ist eine Kontrolle, die Teams voraussetzen, statt sie zu testen. Führen Sie ihn einmal als Übung mit einer echten Testidentität durch, beim Go-live, wenn das Risiko an den Betrieb übergeht, denn ein Entzugsweg, der nie ausgeführt wurde, ist eine Annahme und keine Kontrolle.
4.Was ein sauberes Berechtigungsmodell dem Unternehmen zurückgibt
Ein entworfenes Zugriffsmodell macht aus der Einrichtung eines Benutzers eine Zuweisung statt einer Untersuchung. Ein neuer Kreditorenbuchhalter erhält das Basisprofil und die Rolle Kreditoren und arbeitet am selben Tag, weil die Entscheidung, was diese Rolle darf, einmal getroffen und festgehalten wurde. In einem kopierten Berechtigungsbestand beginnt dieselbe Anforderung damit, dass jemand zu rekonstruieren versucht, was ein vergleichbarer Benutzer hat. So ist der Bestand überhaupt gewachsen.
- Planbare Releases - ändert ein Release eine Projection, zeigt eine Zuordnung Rolle zu Projection, welche Rollen neu getestet werden müssen, statt einen vollständigen Regressionslauf über die Sicherheit zu verlangen.
- Prüfungen, die enden - Nachweise, die aus dem Modell zusammengestellt statt je Benutzer rekonstruiert werden, machen aus einer wiederkehrenden Übung über Wochen einen Bericht.
- Geringerer Pflegeaufwand - eine kleine Zahl bewusst angelegter Sets ist leichter im Kopf zu behalten als eine große Zahl zufälliger, und der Unterschied wächst mit jedem neuen Mitarbeiter.
- Automatisierung, auf die Verlass ist - Workflows und Business Process Automation erben das Zugriffsmodell, unter dem sie laufen. Ein automatisierter Schritt auf einem überberechtigten Konto vergrößert die Angriffsfläche, statt sie einzugrenzen.
Es gibt auch eine organisatorische Seite. Engere Zugriffsrechte ändern, was Mitarbeiter in eigener Verantwortung tun können, und ein Rollout, der nur als Kontrollmaßnahme auftritt, stößt auf Widerstand, den ein Rollout als Rollenklärung nicht auslöst. Planen Sie diese Spannung bewusst ein: Sie ist ein Problem der Umsetzung und wird dort gelöst, nicht im Berechtigungsmodell. Diese Art von Arbeit wird leicht aufgeschoben, bis ein externer Termin sie erzwingt.
Zur Reihenfolge: Das Berechtigungsdesign gehört vor die Datenmigration, nicht danach. Benutzer- und Rollendaten, die in ein nicht entworfenes Modell geladen werden, tragen die angesammelten Zugriffe des Altsystems in die neue Umgebung. So startet eine Neueinführung am ersten Tag bereits mit Sicherheitsschulden. Der Migrationsplan für IFS Cloud ist der richtige Ort, diese Reihenfolge festzulegen.
5.Fragen und Antworten
Wie unterscheidet sich die Sicherheit in IFS Cloud von IFS Applications 10?
IFS Cloud sichert den Zugriff an der Projection ab, der Einheit, die der OData-Provider und die REST-APIs bereitstellen, während sich IFS Applications 10 stärker auf Rechte auf Datenbankebene stützte. Praktisch folgt daraus, dass ein Permission Set in IFS Cloud eine Menge von Rechten auf Projections und deren Actions ist. Die Absicherung der API-Oberfläche und die der Benutzeroberfläche sind damit dieselbe Aufgabe und nicht zwei getrennte.
Kann Azure AD (Entra ID) die Rollen in IFS Cloud verwalten?
Die IAM-Anbindung von IFS Cloud nutzt Entra ID für die Authentifizierung, sodass Anmeldung, Richtlinie zur Multifaktor-Authentifizierung und Deaktivierung von Konten beim Identitätsanbieter des Unternehmens liegen. Die Autorisierung bleibt in IFS Cloud: Permission Sets legen fest, welche Projections und Actions ein Benutzer erreicht, und diese Granularität hat im Verzeichnis keine Entsprechung. Für den Umgang mit Austritten ist die Trennung wichtig, denn das Deaktivieren des Verzeichniskontos beendet den Zugriff nur dann, wenn neben IAM kein separater lokaler Zugangsweg besteht.
Was bedeutet das Prinzip der minimalen Rechte im ERP?
Minimale Rechte (Least Privilege) bedeutet, dass jeder Benutzer nur den Zugriff besitzt, den seine dokumentierte Aufgabe verlangt, und nichts aus einer früheren Rolle oder einem vorübergehenden Bedarf. Im ERP begrenzt das sowohl gezielten Missbrauch als auch versehentliche Schäden, denn wer einen Prozess nicht erreicht, kann dessen Daten nicht beschädigen. Zugleich ist es die Annahme, die ein Prüfer nach ISO 27001 oder SOC 2 direkt testet, indem er fragt, welche Regel einer bestimmten Person ein bestimmtes Recht gegeben hat.
Ist ein Feld sicher, wenn es im Page Designer ausgeblendet ist?
Nein. Der Page Designer steuert, was der Client darstellt, nicht, was die Projection zurückgibt. Ein von einer Seite entferntes Feld bleibt per direkter OData-Anfrage abrufbar, wenn die Projection es weiter bereitstellt und der Benutzer das Recht besitzt. Die Absicherung muss an der Projection erfolgen. Das Seitenlayout ist eine Frage der Bedienbarkeit, die danach kommt.
Welche Konflikte der Funktionstrennung sollte man zuerst festlegen?
Beginnen Sie mit den Paaren, bei denen ein einziger Inhaber genügt, um Geld oder Bestand ohne zweite Person zu bewegen: Lieferantenanlage zusammen mit Zahlungsfreigabe, Erfassung von Eingangsrechnungen zusammen mit Buchung im Hauptbuch, Bestandskorrektur zusammen mit Lieferfreigabe und Änderung von Personalstammdaten zusammen mit Lohnabrechnung. Legen Sie die Paare fest, bevor Sie Permission Sets entwerfen, und prüfen Sie das fertige Modell, indem Sie die Benutzer auflisten, die beide Seiten jedes Paares halten.
Wie lange dauert die Neugestaltung von Permission Sets?
Die Dauer hängt von der Zahl der Fachrollen und der betroffenen Module ab, nicht von der Benutzerzahl, denn der Entwurf entsteht einmal je Rolle und die Zuweisung geht danach schnell. Eine Neugestaltung mit Prozessaufnahme, Konfliktmatrix, Aufbau der Sets und Abnahmetest lässt sich mit vier bis acht Wochen ansetzen. Der längste Schritt ist die Einigung darüber, was jede Rolle darf. Das ist eine fachliche und keine technische Entscheidung.
6.Über den Autor
Dariusz Myśliwiec: 18 Jahre Praxis mit IFS (Apps 7.5 bis 10 und IFS Cloud). Ich bin IFS Certified Associate Consultant und nach PRINCE2® 7 zertifiziert. Unabhängige Beratung mit Sitz in Krakau, remote tätig in Europa und darüber hinaus.
Ausgewählte Kunden: Fugro · LGC · BVI Medical · Betafence · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB.
Würden Ihre Permission Sets eine Prüfung überstehen?
Am schnellsten finden Sie es heraus, indem Sie ein Konfliktpaar herausgreifen, etwa Lieferantenanlage und Zahlungsfreigabe, und die Benutzer auflisten, die beide Rechte des Paares besitzen. Dauert diese Liste länger als einen Nachmittag, liegt das Problem im Berechtigungsbestand und nicht in der Abfrage. In einem kurzen technischen Gespräch lässt sich klären, was eine Neugestaltung in Ihrer Umgebung umfassen würde. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt.
Technisches Gespräch buchen Katalog der Sicherheitsleistungen ansehen
