Business Role Owner und Application Owner: Wer im IAM fachlich entscheidet

Edouard Jacques

Managing Director, Cyber Culture

Im Audit kommt irgendwann die Frage: Wer hat entschieden, dass die Kollegin im Vertriebsinnendienst die Margenkalkulation sehen darf? In vielen Unternehmen lautet die ehrliche Antwort: der Administrator, weil sonst niemand zuständig war. Dieser Artikel beschreibt die beiden fachlichen Rollen, ohne die ein Rollenmodell und regelmäßige Berechtigungsprüfungen nicht funktionieren, grenzt sie von IT und Informationssicherheit ab und zeigt, wie Sie geeignete Personen finden und ihnen ein belastbares Mandat geben.

Business Role Owner: verantwortlich für eine Tätigkeit

Der Business Role Owner, auf Deutsch etwa Rollenverantwortliche, ist für eine oder mehrere Geschäftsrollen zuständig, zum Beispiel „Sachbearbeitung Kreditorenbuchhaltung“. Was eine Geschäftsrolle ist und wie sie aufgebaut wird, beschreibt der Artikel zum Business Role Model.

Die Aufgaben sind überschaubar, aber nicht an die IT delegierbar. Der Business Role Owner legt fest, welche Anwendungsrollen in die Geschäftsrolle gehören, und genehmigt Änderungen daran. Er bestimmt die Zuweisungsregel: automatisch für alle mit einem bestimmten Stellenschlüssel oder nur auf Antrag. Er prüft in festen Abständen, ob der Inhalt noch zur Arbeit passt und ob die Mitglieder die Rolle noch brauchen. Und er meldet, wenn sich die Tätigkeit ändert, etwa weil ein neues Lieferantenportal eingeführt wird.

Gut geeignet sind Teamleitungen oder erfahrene Fachkräfte, die die Arbeit selbst kennen. Die Bereichsleitung ist meist zu weit weg, die IT kennt die fachliche Seite nicht.

Application Owner: verantwortlich für eine Anwendung

Der Application Owner, im Deutschen oft fachlicher Anwendungsverantwortlicher genannt, ist für die Berechtigungen innerhalb einer Anwendung zuständig: ERP, CRM, Dokumentenmanagement, Lohnabrechnung. Er weiß, welche Funktionen kritisch sind, schneidet daraus Anwendungsrollen und legt fest, welche Kombinationen sich ausschließen, etwa Lieferanten anlegen und Zahlungen freigeben. Er genehmigt Anträge auf sensible Rechte in seiner Anwendung und prüft regelmäßig auch die Konten, die sonst niemand ansieht: technische Benutzer, Schnittstellenkonten und Fernzugänge des Softwarepartners.

Im Mittelstand passt diese Rolle oft zu den Key Usern. Für die Finanzmodule im ERP ist das typischerweise jemand aus dem Rechnungswesen, nicht der Systembetreuer in der IT. Der Systembetreuer hält die Anwendung technisch am Laufen, der Application Owner entscheidet, wer darin was darf.

Abgrenzung zu Führungskräften, IT und ISB

Neben den beiden fachlichen Rollen sind drei weitere beteiligt. Verwechslungen zwischen ihnen sind die häufigste Ursache für Reibung.

Die direkte Führungskraft beantwortet, ob eine Person ein Recht für ihre Aufgabe braucht, und bestätigt in der Rezertifizierung die Rechte ihres Teams. Über den Inhalt einer Rolle entscheidet sie nicht.

Die IT setzt Entscheidungen technisch um, betreibt das IAM-Werkzeug und liefert Berichte. Sie entscheidet nicht über fachliche Inhalte, und ein Administrator genehmigt nie die Rechte, die er selbst einträgt.

Der oder die Informationssicherheitsbeauftragte (ISB) setzt die Regeln in der Richtlinie zur Zugriffskontrolle, prüft, ob der Prozess funktioniert, und ist bei privilegierten Zugriffen an der Genehmigung beteiligt. Rollen zu besitzen ist nicht Aufgabe des ISB.

Diese Trennung ist kein Selbstzweck. ISO 27001:2022 verlangt in Control 5.3 die Trennung unvereinbarer Aufgaben, und die Umsetzungshilfe ISO/IEC 27002 nennt als Beispiel ausdrücklich das Beantragen, Genehmigen und Umsetzen von Zugangsrechten.

Wie viel Zeit das kostet

Der Aufwand hängt fast vollständig von der Vorbereitung ab. Wenn Rollen in Alltagssprache beschrieben sind und auf Rollenebene statt auf Ebene einzelner Gruppen geprüft wird, sollte ein Business Role Owner pro Quartal mit deutlich unter zwei Stunden auskommen, wie auf der Seite zur Access Recertification beschrieben. Kommt dagegen eine Tabelle mit 400 kryptischen Gruppennamen, wird geraten oder alles bestätigt.

Application Owner kritischer Anwendungen brauchen mehr Zeit, vor allem einmal im Jahr für die Überarbeitung der Konfliktregeln und der Anwendungsrollen. Hinzu kommen laufende Genehmigungen. Bei guten Beschreibungen sind das Minuten pro Antrag. Wie diese Genehmigungswege aufgebaut sind, steht im Beitrag zu Approval Workflows.

Das Mandat kommt von der Geschäftsleitung

Ohne ausdrücklichen Auftrag sehen viele Fachbereiche Berechtigungen als IT-Thema und klicken in der Prüfung auf „alles bestätigen“. Das Mandat muss deshalb schriftlich und von oben kommen. Die Richtlinie zur Zugriffskontrolle benennt die Rollen und ihre Aufgaben, die Geschäftsleitung setzt sie in Kraft und erklärt sie einmal persönlich in der Führungsrunde. Die konkreten Namen stehen in einer Liste, die bei jedem Personalwechsel aktualisiert wird.

Für Unternehmen, die unter NIS2 fallen, ist das keine Stilfrage. Nach § 38 BSIG muss die Geschäftsleitung die Risikomanagementmaßnahmen nach § 30 umsetzen und ihre Umsetzung überwachen. Zu diesen Maßnahmen gehören nach § 30 Absatz 2 Nummer 9 Konzepte für die Zugriffskontrolle. Benannte Verantwortliche mit klaren Aufgaben sind ein praktischer Weg, diese Pflicht zu erfüllen und nachzuweisen.

Ebenso wichtig ist die Eskalation. Wer als Owner nicht reagiert, wird nach Fristablauf an die eigene Führungskraft gemeldet. Bleibt eine Prüfung trotzdem offen, werden unbestätigte Rechte entzogen, und die Quote erscheint im Bericht an die Geschäftsleitung.

Typische Stolpersteine

• Der Owner verlässt das Unternehmen, und seine Rollen sind verwaist. Koppeln Sie die Owner-Liste an den Austrittsprozess, damit jede Rolle vor dem letzten Arbeitstag neu vergeben wird.
• Die Prüfung wird an eine Assistenz delegiert, die niemandem widersprechen will. Delegation an eine fachkundige Vertretung ja, an jemanden ohne fachliche Kenntnis nein.
• Ein externer Softwarepartner wird zum faktischen Application Owner, weil er das System am besten kennt. Er kann beraten, entscheiden muss jemand im eigenen Haus.
• Im kleineren Unternehmen werden zu viele Owner benannt. Bei 150 Mitarbeitenden reicht es oft, wenn die Abteilungsleitung alle Rollen ihres Bereichs verantwortet und je Kernanwendung ein Application Owner benannt ist.

So starten Sie

Listen Sie Ihre zehn bis fünfzehn wichtigsten Anwendungen auf und benennen Sie für jede einen Application Owner mit Vertretung. Legen Sie für einen Pilotbereich die Geschäftsrollen fest, gern auf Basis eines Role Mining, und benennen Sie die Business Role Owner. Halten Sie die Aufgaben auf einer Seite fest und lassen Sie die Geschäftsleitung unterschreiben. Die erste Rezertifizierung im Pilotbereich zeigt dann, ob Beschreibungen und Zuschnitt taugen.

Wie gut Ihr Zugriffsmanagement die Anforderungen der ISO 27001 schon abdeckt, prüfen Sie im Reifegrad-Check unter diesem Artikel.