--- title: "IFS Cloud RBAC und Funktionstrennung in SCM" date: 2026-10-17 description: "IFS Cloud RBAC und Funktionstrennung: Wie Permission Sets wirken, welche SCM-Konflikte Prüfer zuerst testen und wie Custom Objects Rechte umgehen." author: "Dariusz Mysliwiec" intro_image: "https://www.ifs-erp.com/images/articles/85-de-d9a3ab75.webp" fulltext_image: "https://www.ifs-erp.com/images/articles/85-de-d9a3ab75.webp" categories: - name: "Blog" url: "https://www.ifs-erp.com/blog-de.md" tags: - name: "SCM" url: "https://www.ifs-erp.com/tags/scm.md" - name: "Permission Sets" url: "https://www.ifs-erp.com/tags/permission-sets.md" - name: "IFS Cloud" url: "https://www.ifs-erp.com/tags/ifs-cloud-de.md" - name: "Funktionstrennung" url: "https://www.ifs-erp.com/tags/funktionstrennung-de.md" - name: "RBAC" url: "https://www.ifs-erp.com/tags/rbac-de.md" --- # IFS Cloud RBAC und Funktionstrennung in SCM ![IFS Cloud RBAC und Funktionstrennung in SCM](https://www.ifs-erp.com/images/articles/85-de-d9a3ab75.webp) IFS Cloud Sicherheit · RBAC · Funktionstrennung (SoD) · Lieferkette ## Berechtigungen in IFS Cloud SCM, die der Prüfer nicht beanstandet Kann dieselbe Person einen Lieferanten anlegen und dessen Rechnungen freigeben, steht der Befund im Prüfbericht. Dieser Beitrag zeigt, wie Permission Sets in IFS Cloud funktionieren, wo die Konflikte in Einkauf, Lager und Rechnungsprüfung tatsächlich liegen und wie Sie ein Modell entwerfen, das eine Prüfung besteht, ohne dass ein Custom Object eine Hintertür öffnet. ## Auf einen Blick - Der Zugriff in IFS Cloud entsteht aus Permission Sets, die Benutzern zugewiesen werden. Eine saubere rollenbasierte Zugriffssteuerung (RBAC) ordnet Rollen Tätigkeiten zu und keinen Einzelpersonen. - Funktionstrennung (Segregation of Duties, SoD) heißt: Keine Person steuert einen Geschäftsvorfall von Anfang bis Ende. Anlegen und Freigeben, Bestellen und Wareneingang, Stammdaten und Zahlung bleiben getrennt. - Die gravierendsten SCM-Konflikte sind Lieferant anlegen mit Rechnung freigeben sowie Bestellung anlegen mit Wareneingang buchen. - Custom Objects können das Standard-Sicherheitsmodell umgehen: Eine ungesicherte Projektion oder ein ungesichertes Custom Event ist eine unsichtbare Lücke in der Funktionstrennung. - Entwerfen Sie die Rollen entlang einer dokumentierten Konfliktmatrix und prüfen Sie gegen diese Matrix bei jeder Änderung und bei jedem Release. ## 1.Wie funktioniert RBAC in IFS Cloud? IFS Cloud vergibt Zugriff nicht an Personen, sondern an **Permission Sets**: benannte Bündel von Rechten auf Projektionen, Entitäten und Aktionen, die anschließend Benutzern zugewiesen werden. Das ist rollenbasierte Zugriffssteuerung (RBAC): Das Recht hängt an der Rolle, die Rolle hängt an der Person. Gut gebaut, entspricht ein Permission Set einer *Tätigkeit*, etwa „Einkäufer“, „Wareneingang“ oder „Rechnungsfreigabe“. Ein Benutzer erhält die Sets, die seine Aufgabe braucht, und keine weiteren. Schlecht gebaut, wachsen Sets zu „Einkauf“-Sammelsets heran, die jede Aktion des Moduls erlauben, und die Grenze zwischen dem, der bestellt, und dem, der zahlt, verschwindet. Zwei Grundsätze halten RBAC belastbar: das **Minimalprinzip** (nur das gewähren, was die Tätigkeit verlangt) und **Rolle statt Person** (keine Einzelrechte auf einen Benutzer legen, denn sie sind bei der nächsten Prüfung unsichtbar). Alles Weitere setzt dieses saubere Fundament voraus. ## 2.Was bedeutet Funktionstrennung in der Lieferkette? Funktionstrennung verhindert, dass eine Person einen Geschäftsvorfall von Anfang bis Ende allein verantwortet. Kann derselbe Benutzer einen Lieferanten anlegen *und* dessen Rechnungen freigeben, kann er einen Zahlungsempfänger erfinden und bezahlen. Kann derselbe Benutzer eine Bestellung erfassen *und* den Wareneingang bestätigen, kann er eine Lieferung vortäuschen, die nie ankam. In IFS Cloud SCM gelten diese klassischen Trennungen: - **Stammdaten** und **Zahlung** - wer den Lieferanten anlegt, gibt dessen Rechnungen nicht frei. - **Bestellung** und **Wareneingang** - wer die Bestellung erfasst, bestätigt nicht den Wareneingang. - **Anforderung** und **Freigabe** - wer anfordert, gibt nicht frei. - **Bestandsbuchung** und **Abstimmung** - wer den Bestand korrigiert, zählt ihn nicht. Funktionstrennung unterstellt kein Misstrauen. Sie ist eine strukturelle Kontrolle, die die Gelegenheit beseitigt, damit weder ein einzelner Fehler noch ein einzelner Täter einen betrügerischen Ablauf allein abschließen kann. ## 3.Welche SoD-Konflikte tauchen in Prüfungen auf? Diese Kombinationen testet ein Prüfer zuerst. Hat ein Benutzer beide Rechte, ist das ein Befund, unabhängig davon, ob jemand es missbraucht hat. | Tätigkeit A | Tätigkeit B (im Konflikt) | Risiko bei Kombination | Schweregrad | | --- | --- | --- | --- | | Lieferant anlegen / ändern | Lieferantenrechnung freigeben | Fiktiver Lieferant wird von seinem Ersteller bezahlt | Hoch | | Bestellung anlegen | Wareneingang buchen | Scheinwareneingang auf eine selbst erfasste Bestellung | Hoch | | Anforderung erfassen | Anforderung freigeben | Nicht genehmigte Ausgabe wird selbst freigegeben | Hoch | | Rechnung freigeben | Zahlung freigeben | Der gesamte Zahlungsablauf liegt bei einer Person | Hoch | | Bestand korrigieren | Inventur durchführen | Schwund wird hinter selbst geprüften Zählungen verborgen | Mittel | | Preisliste pflegen | Bestellung freigeben | Überhöhter Preis wird ungeprüft gesetzt und freigegeben | Mittel | Halten Sie diese Paare in einer dokumentierten **Konfliktmatrix** fest, bevor Sie ein einziges Permission Set entwerfen. Die Matrix ist die Vorgabe, die Ihre Rollen erfüllen müssen, und die Checkliste, nach der jede Prüfung bei Ihnen vorgeht. ## 4.Wie umgehen Custom Objects das Sicherheitsmodell? Ein einziges Custom Object kann ein sauberes RBAC-Konzept zum Prüfungsbefund machen, selbst wenn die Standard-Permission-Sets einwandfrei sind. Eine eigene Projektion, die Aktionen der Bestellung freigibt, ohne die Standard-Sicherheit zu erben, ein Custom Event, das unter einem Servicekonto einen Rechnungsstatus schreibt, oder eine Schnittstelle, die mit höheren Rechten läuft als jede menschliche Rolle: Jedes davon ist eine unsichtbare Lücke im SoD-Modell. Deshalb sind Sicherheit und Clean Core dasselbe Thema. Jede Erweiterung gehört in das IFS Extensibility Framework und wird mit denselben Permission Sets gesichert wie Standardfunktionen, ohne Umgehung und ohne gemeinsames privilegiertes Konto. Kann ein Custom Object etwas, das eine Rolle nicht darf, verliert Ihre Konfliktmatrix ihre Aussagekraft. Prüfen Sie Ihre Custom Objects gegen dieselbe Matrix wie die Standardtätigkeiten. Update-sichere Erweiterungen sind auch sicherheitskonform, weil sie das Standardmodell respektieren, statt es zu umgehen. Das ist ein Grund, weshalb der [Clean-Core-Ansatz](https://www.ifs-erp.com/de/blog-de/clean-core-ifs-cloud-einkauf-lagerbestand) für IFS Cloud SCM existiert. ## 5.So entwerfen und prüfen Sie Berechtigungen Ob Sie neu aufbauen oder ein laufendes System bereinigen: Dieselbe Abfolge trägt. 1. **Konfliktmatrix dokumentieren** - mit Rechnungswesen und Revision festlegen, welche Tätigkeitspaare nie zusammenfallen dürfen. 2. **Rollen nach Tätigkeit definieren** - ein Permission Set je Tätigkeit, nach dem Minimalprinzip zugeschnitten und an der Matrix ausgerichtet. 3. **Benutzer den Rollen zuordnen** - nur die Sets zuweisen, die die Aufgabe braucht, und Einzelrechte entfernen. 4. **Auf Konflikte testen** - jeden Benutzer gegen die Matrix prüfen; wer beide Seiten eines Paares besitzt, ist ein Treffer. 5. **Custom Objects sichern** - bestätigen, dass jede Erweiterung die Standard-Permission-Sets erbt und kein Umgehungskonto existiert. 6. **Bei Änderung neu prüfen** - jede neue Rolle, jeder Eintritt und jedes Release lässt die Matrix erneut laufen. Binden Sie das in Ihre Upgrade-Routine ein. Legen Sie die Sicherheitsprüfung in die [Upgrade-Vorbereitung](https://www.ifs-erp.com/de/blog-de/ifs-cloud-upgrade-checkliste-zehn-punkte), damit sie nicht entfällt. Neue Projektionen und geänderte Aktionen in einem Release können verschieben, was ein Permission Set tatsächlich gewährt. [Technisches 30-Minuten-Gespräch zur Sicherheit buchen](https://www.ifs-erp.com/de/kontakt-de) ## 6.FAQ Worin unterscheiden sich RBAC und Funktionstrennung in IFS Cloud? RBAC ist der Mechanismus: Zugriff wird an Permission Sets (Rollen) vergeben, die Benutzern zugewiesen werden. Funktionstrennung ist eine Regel, die Sie über diesen Mechanismus durchsetzen: Keine Rolle und kein Benutzer darf zwei unvereinbare Tätigkeiten ausüben, etwa einen Lieferanten anlegen und dessen Rechnungen freigeben. RBAC regelt, wie Rechte vergeben werden, Funktionstrennung regelt, welche Rechte nie zusammen vergeben werden. Welche SoD-Konflikte sind im IFS-Cloud-Einkauf am gravierendsten? Am gravierendsten sind die Paare Lieferant anlegen mit Rechnung freigeben sowie Bestellung anlegen mit Wareneingang buchen. Beide erlauben einer Person, einen Zahlungsablauf ungeprüft abzuschließen. Dicht dahinter folgen Anforderung erfassen mit Anforderung freigeben und Rechnung freigeben mit Zahlung freigeben. Diese Kombinationen testet ein Prüfer zuerst. Kann ein Custom Object mein Sicherheitsmodell in IFS Cloud aushebeln? Ja. Eine eigene Projektion, ein Custom Event oder eine Schnittstelle, die die Standard-Permission-Sets nicht erbt oder unter einem gemeinsamen privilegierten Konto läuft, kann Aktionen ausführen, die Ihre Rollen verbieten. Das ist eine unsichtbare Lücke in der Funktionstrennung. Bauen Sie jede Erweiterung im Extensibility Framework, sichern Sie sie mit denselben Permission Sets wie Standardfunktionen und prüfen Sie sie gegen Ihre Konfliktmatrix. Wann sollte ich die Berechtigungen in IFS Cloud prüfen? Lassen Sie die SoD-Konfliktmatrix bei jeder wesentlichen Änderung neu laufen: bei einer neuen Rolle, einem Eintritt oder Wechsel, einem neuen Custom Object und bei jedem IFS-Cloud-Release. Ein Release kann Projektionen ergänzen oder Aktionen ändern, wodurch sich verschiebt, was ein bestehendes Permission Set gewährt. Liegt die Prüfung in der Upgrade-Vorbereitung, entfällt sie nicht. ## 7.Über den Autor Ich bin **Dariusz Myśliwiec** und habe 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, Umsetzung remote in Europa und weltweit. Sie sprechen direkt mit dem Berater, der die Arbeit ausführt. **Ausgewählte Kunden:** Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm. IFS ist eine eingetragene Marke der IFS AB. Diese Beratung steht in keiner Verbindung zur IFS AB. ## Bestehen Sie die Prüfung zu Ihren Bedingungen Erzählen Sie mir, wie Ihre IFS-Cloud-Rollen heute aufgebaut sind. In einem 30-Minuten-Gespräch zeige ich Ihnen, wo die SoD-Konflikte liegen, bei Standard und bei Custom Objects, und wie Sie sie im Standard-Sicherheitsmodell schließen. [Technisches 30-Minuten-Gespräch zur Sicherheit buchen](https://www.ifs-erp.com/de/kontakt-de)