IAM-Verantwortlichkeiten müssen klar zwischen dem Auftraggeber und dem Entwicklungspartner aufgeteilt werden. Der Auftraggeber bleibt für richtlinienbezogene Architekturentscheidungen wie die IdP-Konfiguration und die Risikoakzeptanz verantwortlich, während der Entwicklungspartner die technische Umsetzung übernimmt, einschließlich sicherer Tokenspeicherung und API-Integration. Diese Aufteilung muss formell festgelegt werden, um Audit-Blockaden und Verzögerungen zu vermeiden.
IAM-Verantwortlichkeiten in der Entwicklung mobiler Apps
Die wirksame Verteilung von IAM-Verantwortlichkeiten zwischen Auftraggeber und Entwicklungspartner ist entscheidend für den Erfolg von Enterprise-Mobile-Apps. Dieser Artikel erläutert, wie diese Verantwortlichkeiten strukturiert werden können, um technische und Compliance-Herausforderungen zu minimieren.
- Definieren Sie richtlinienbezogene und technische Verantwortlichkeiten ausdrücklich und halten Sie sie vertraglich fest.
- Stellen Sie eine klare Trennung zwischen clientseitiger und serverseitiger Autorisierung sicher, um Sicherheitsrisiken zu minimieren.
- Implementieren Sie eine formelle IAM-Matrix, um Eigentümerschaft und Verantwortlichkeiten zu verdeutlichen.
- Managen Sie Schwachstellen proaktiv mit festgelegten Behebungsfristen und kontinuierlichem Monitoring.
- Sorgen Sie für ein robustes Sitzungsmanagement und eine sichere Tokenspeicherung, um unbefugten Zugriff zu verhindern.
Warum IAM-Verantwortlichkeiten in Enterprise-Mobile-Apps entscheidend sind
Bei einer Enterprise-Mobile-App ist IAM nicht nur ein Bestandteil des Anmeldebildschirms. Es bestimmt, wer Zugriff erhält, unter welchen Bedingungen dieser Zugriff bestehen bleibt und wer nachweisen kann, dass diese Entscheidungen zum Risikoprofil der Organisation passen. Dadurch wird IAM häufig zu einem Bewertungspunkt vor einem Release. Wenn die Verantwortung für Richtlinienentscheidungen, Nachweisführung und Akzeptanz nicht im Voraus zugewiesen wird, kann ein Projekt technisch fertig sein, ohne dass die Organisation die mobile App freigeben kann.
Der Kontext bestimmt außerdem, wo die Durchsetzung erfolgen sollte. Bei zentral verwalteten B2E-Geräten über MDM kann der zentrale IdP Conditional Access die wichtigste Schicht der Zugriffskontrolle bilden. Bei externen B2B- oder BYOD-Nutzern kann die mobile App selbst zusätzliche Durchsetzung benötigen, etwa durch Biometrie und Bindung an den lokalen Keystore. Dieser Unterschied betrifft nicht nur die gewählte Maßnahme, sondern vor allem die Frage, wer die Ausgangspunkte festlegt, wer die Funktion bewertet und wer Änderungen akzeptiert. Eine Verantwortungsübersicht, die nicht zwischen diesen Nutzer- und Gerätekontexten unterscheidet, lässt Raum für widersprüchliche Erwartungen.
Die Notwendigkeit wird deutlicher, wenn die App regulierte Daten verarbeitet. Für medizinische Daten nach NEN 7510 oder Finanzdaten nach DORA ist nach den verfügbaren Grundlagen eine strenge, unwiderlegbare Nachweisführung erforderlich. Auch formelles STRIDE-Threat-Modeling und eine ausdrückliche Unterzeichnung des Restrisikos müssen dann vor der Genehmigung eines mobilen Releases erfolgen. Dabei handelt es sich um Governance-Handlungen: Ein Entwicklungspartner kann Unterlagen liefern, aber nicht stillschweigend im Namen des Auftraggebers bestimmen, welches verbleibende Risiko akzeptabel ist.
Eine ungeklärte Befugnisfrage wird bei Feststellungen sichtbar, die aus Einschränkungen mobiler Plattformen resultieren. Die interne Sicherheitsabteilung kann dann die Zustimmung verweigern, während im Projektteam niemand formell bevollmächtigt ist, einen Risk Acceptance Waiver zu unterzeichnen. Das Ergebnis ist kein rein technisches Problem, sondern eine Release-Blockade. Klare IAM-Verantwortlichkeiten machen daher im Voraus sichtbar, wer Entscheidungen trifft, wer Nachweise sammelt und wer das verbleibende Risiko trägt, wenn eine vollständige Minderung nicht möglich ist.
Die Folgen unklarer IAM-Verantwortlichkeiten
Unklarheit über IAM beginnt häufig bereits bei der Abgrenzung einer mobilen App. Wenn IAM dann als generische SSO-Anmeldefunktion beschrieben wird, entsteht ein zu enger Auftrag. Der Entwicklungspartner kann einen standardmäßigen OAuth-Flow umsetzen, während feingranulare Autorisierung auf API-Ebene unbeachtet bleibt. Der Unterschied wird erst sichtbar, wenn Auditoren und der CISO kurz vor dem Start einen Nachweis der Funktionstrennung verlangen. Zu diesem Zeitpunkt fehlen nicht nur Funktionalität oder Dokumentation, sondern auch eine zuvor gemeinsame Vereinbarung darüber, wer dieses Ergebnis hätte spezifizieren, umsetzen und prüfen lassen müssen.
Die Verzögerung ergibt sich aus der Reihenfolge, in der der Mangel ans Licht kommt. Eine App kann sich auf Grundlage der Annahme, dass eine erfolgreiche Anmeldung ausreicht, dem Release nähern. Anschließend stellt sich heraus, dass die geforderte Begründung für die Funktionstrennung nicht verfügbar ist. Das Projekt muss dann zu Entwurf, Umsetzung und Bewertung zurückkehren, mit einer möglichen Verzögerung von mehreren Wochen. Compliance-Artefakte werden dadurch nicht zu einem abschließenden administrativen Schritt, sondern zu einer späten Blockade für den geplanten Start.
Auch nach der Inbetriebnahme führt eine fehlende Rollenverteilung zum Stillstand. Ein Sicherheitsscanner kann eine kritische Schwachstelle in einem Authentifizierungs-SDK erkennen. Der Auftraggeber kann anschließend ein sofortiges Patchen innerhalb von 48 Stunden verlangen, während der Entwicklungspartner den Auftrag als abgeschlossen betrachtet, weil kein SLA für Schwachstellen vereinbart wurde. Die technische Feststellung ist dann eindeutig, nicht jedoch die Behebungspflicht, Reaktionszeit und Finanzierung. Eine Diskussion über Mehrkosten verzögert die Lösung genau in dem Moment, in dem die Gefährdung aktiv ist.
Im beschriebenen Szenario führt diese Verzögerung zu einem akuten Compliance-Verstoß nach NIS2 und DSGVO. Der Kern des Problems besteht also nicht darin, dass eine Partei zwangsläufig alle IAM-Aufgaben besitzen muss. Vielmehr bietet der Auftrag ohne ausdrückliche Grenzen keine Antwort auf zwei operative Fragen: Wer veranlasst und führt die Behebung aus, und wer trägt die Konsequenz, wenn eine Sicherheitskomponente nach dem Go-live Aufmerksamkeit erfordert? Solange diese Fragen offenbleiben, können Genehmigungen und Behebungsentscheidungen auseinanderlaufen, auch wenn beide Parteien glauben, innerhalb ihres ursprünglichen Scopes zu handeln.
Wann ist es entscheidend, IAM-Verantwortlichkeiten zu definieren?
Die Verteilung von IAM-Verantwortlichkeiten muss frühzeitig ausdrücklich geklärt werden, sobald der Auftraggeber keinen standardisierten zentralen IdP mit formeller Governance hat. Die interne IAM-Reife bestimmt in dieser Situation das Risikoniveau des Auftrags. Ohne zentrale Grundlage kann ein Entwicklungspartner in der Praxis maßgeschneiderte Autorisierungslogik entwickeln, um die App voranzubringen. Nach den verfügbaren Hinweisen kann dies später zu nicht bestandenen ISO-27001-Audits führen. Die Frage ist daher nicht nur, ob eine App Nutzer erkennen muss, sondern ob die Organisation einen Governance-Ausgangspunkt für Rollen, Autorisierung und Verwaltung hat.
Eine zweite Situation entsteht, wenn die App kryptografische Tokens sicher speichern muss. Die verfügbare Empfehlung verbindet dies mit hardwaregestützter Sicherheit über iOS Keychain und Android Keystore sowie biometrischer Authentifizierungsattestierung. In dieser Aufteilung liegt die technische Abstraktion beim Softwarepartner, während der Auftraggeber die Compliance-Definition gemäß OWASP MASVS-AUTH besitzt. Die Verantwortlichkeiten müssen daher definiert werden, bevor technische Entscheidungen als implizite Richtlinienentscheidungen wirken.
Dieser Zeitpunkt ist besonders relevant, wenn beide Parteien eine andere Vorstellung davon haben, was „sicher speichern“ bedeutet. Der Auftraggeber muss möglicherweise das gewünschte normative Ergebnis festlegen; der Partner übersetzt dieses anschließend in die technische Abstraktion in der mobilen App. Ohne diese Trennung kann der Partner unbeabsichtigt bestimmen, welches Schutzniveau ausreichend ist, während der Auftraggeber später erklären muss, warum diese Entscheidung angemessen war. Umgekehrt kann der Auftraggeber eine Anforderung nennen, ohne festzulegen, welche technische Lieferung dazugehört.
Diese Situationen zeigen, dass IAM-Verantwortlichkeiten nicht erst bei der Abnahme eines Releases zur Sprache kommen. Sie müssen geklärt werden, sobald die verfügbare zentrale Identität, die beabsichtigte Autorisierungsgovernance oder der erforderliche Schutz von Tokens unsicher ist. So bleibt sichtbar, welche Entscheidungen bei der Organisation verbleiben und welche konkrete Umsetzung der Entwicklungspartner übernimmt.
Wichtigste Kriterien zur Bewertung von IAM-Verantwortlichkeiten
Verwenden Sie die folgenden Kriterien, um zu beurteilen, ob die Aufgabenverteilung mehr umfasst als eine Anbindung an einen zentralen IdP. Die Tabelle konzentriert sich auf die überprüfbare Grenze zwischen dem, was der Auftraggeber festlegen muss, und dem, was der Entwicklungspartner nachweisbar umsetzen oder prüfen muss. Der Verweis auf AAL2/AAL3 gilt dabei für Enterprise-Anwendungen mit erhöhtem Risiko; er ist kein allgemeines Niveau für jede mobile App.
| Bewertungskriterium | Frage an den Auftraggeber | Erwartung an den Entwicklungspartner | Folge, wenn das Kriterium fehlt |
|---|---|---|---|
| Bedeutung der IdP-Anbindung | Ist festgelegt, welche Autorisierungen der zentrale IdP liefert und welche Kontrollen die App-Umgebung selbst unterstützen muss? | Machen Sie sichtbar, dass der IdP nicht nur als Anmelde-Widget verwendet wird, sondern dass eingehende Tokens auf Berechtigungen und Gültigkeit auf API-Ebene geprüft werden. | Die Organisation kann annehmen, dass die Anbindung automatisch die gesamte Autorisierung abdeckt, obwohl diese Kontrolle tatsächlich fehlt. |
| Risikostufe der Authentifizierung | Ist festgestellt, ob die Anwendung ein erhöhtes Risiko aufweist und welches Authentifizierungsniveau sich daraus ergibt? | Übersetzen Sie das vereinbarte Niveau in technische Anforderungen an Authenticatoren und Schlüsselspeicherung. | Eine Bewertung kann scheitern, weil die gewählte Authentifizierung nicht zur festgelegten Risikostufe passt. |
| Überprüfbare Authentifizierungsmethode | Ist klar, welche Methoden innerhalb der gewählten Risikoklasse zulässig sind? | Belegen Sie, dass die umgesetzte Methode zur vereinbarten Anforderung passt. | Für AAL2/AAL3 bei Enterprise-Anwendungen mit erhöhtem Risiko schließt die verfügbare Richtlinie unsichere Methoden wie SMS-OTP aus. |
| Kryptografische Bindung | Ist benannt, wer entscheidet, dass kryptografisch gebundene Authenticatoren erforderlich sind? | Zeigen Sie, wie die technische Umsetzung diese Bindung und hardwarebasierte Schlüsselspeicherung unterstützt. | Die Aufteilung verschwimmt, wenn eine Sicherheitsanforderung nur als allgemeiner Wunsch formuliert ist, ohne Verantwortlichen für Entscheidung und Umsetzung. |
| Nachweis der API-Autorisierung | Wurde ausdrücklich ein Nachweis der Berechtigungs- und Gültigkeitsprüfung außerhalb der Benutzeroberfläche verlangt? | Legen Sie die Begründung für die durchgeführten Kontrollen auf API-Ebene vor. | Eine visuell abgeschirmte App kann fälschlicherweise als vollständig autorisiert betrachtet werden. |
Quellen zu diesem Abschnitt: nist.gov
Ein strukturierter Ansatz für IAM-Verantwortlichkeiten
Eine brauchbare IAM-Matrix verteilt nicht nur Aktivitäten, sondern verknüpft jedes Thema mit einem formellen Verantwortlichen, einem technischen Ausführenden, zu liefernden Nachweisen und einem Entscheider für die Produktion. Dadurch wird verhindert, dass eine Richtlinienentscheidung als technische Aufgabe gelesen wird oder dass eine technische Lieferung mit einer formellen Risikoakzeptanz verwechselt wird.
- Halten Sie die Richtliniengrenze vertraglich fest. Der Auftraggeber besitzt die richtlinienbezogenen Architekturentscheidungen: IdP-Konfiguration, Autorisierungsmatrizen und Risikoakzeptanz. Der Entwicklungspartner verantwortet die technische Umsetzung, darunter OAuth 2.0 mit PKCE und sichere Tokenspeicherung. Beschreiben Sie diese Grenze formell in der Vereinbarung, nicht nur in einem Backlog oder in mündlichen Abstimmungen. Dadurch bleibt sichtbar, dass eine Entscheidung über Rollen oder eine Produktionsfreigabe nicht automatisch auf die Partei übergeht, die die mobile App entwickelt. Legen Sie neben dem Verantwortlichen auch fest, wer eine Entscheidung vorbereitet und welche konkrete Lieferung die Entscheidung unterstützt.
- Machen Sie das Schwachstellenmanagement zu einer eigenen Matrixzeile. Bei Schwachstellen in der Software-Lieferkette führt der Entwicklungspartner kontinuierliche Dependency-Scans durch und erstellt eine SBOM gemäß NIST SP 800-218. Der Auftraggeber genehmigt anschließend die formelle Risikoakzeptanz und die Autorisierung für die Produktionsausbringung. Diese Aufteilung unterscheidet technische Signalisierung von Governance-Genehmigung. Ein Scan oder eine SBOM ist damit keine automatische Freigabe für die Ausbringung, während die Produktionsautorisierung ebenso wenig die technische Pflicht ersetzt, Abhängigkeiten fortlaufend zu untersuchen.
- Verknüpfen Sie Behebungsfristen mit der Produktionsautorisierung. Die formelle Genehmigung durch den Auftraggeber erfolgt innerhalb vereinbarter Behebungsfristen. Nehmen Sie daher in dieselbe Matrixzeile auf, welche Behebungsfristen gelten, wer den Fortschritt dokumentiert und welche Entscheidung folgt, wenn eine Feststellung nicht innerhalb dieser Frist gelöst wird. So erhält der Partner eine abgegrenzte Ausführungsverantwortung, und der Auftraggeber behält die ausdrückliche Entscheidung über Akzeptanz und Ausbringung. Ohne diese Verknüpfung kann eine technische Feststellung zwar erfasst werden, doch bleibt unklar, ob sie die Produktion blockiert oder unter Risikoakzeptanz fällt.
- Behandeln Sie Nachweise als Teil der Lieferung. Sowohl bei der Richtliniengrenze als auch beim Schwachstellenmanagement gehören Nachweise zur zugewiesenen Aufgabe: Die SBOM und Ergebnisse der Dependency-Scans stammen vom Entwicklungspartner; die formelle Genehmigungsentscheidung kommt vom Auftraggeber. Halten Sie für jede Matrixzeile fest, wo dieser Nachweis gespeichert wird und mit welcher Produktionsausbringung er verknüpft ist. Dadurch lässt sich nachträglich nachvollziehen, welche technischen Informationen verfügbar waren und welche Entscheidung darauf folgte, ohne die Eigentümerschaft zwischen den Parteien zu vermischen.
Quellen zu diesem Abschnitt: nist.gov
Häufig gestellte Fragen zu IAM-Verantwortlichkeiten
Diese Fragen betreffen zwei wiederkehrende Grenzfälle: den Ort, an dem Autorisierung durchgesetzt wird, und die Folgen von Änderungen an zentralen Zugriffsrichtlinien. Beide Themen erfordern ausdrückliche Eigentümerschaft, da eine technisch funktionierende Anbindung keine Garantie für dauerhaften Zugriff oder wirksame Zugriffsbeschränkung bietet.
- „Kann die mobile App die Autorisierung selbst übernehmen, indem sie Teile der Benutzeroberfläche ausblendet?“ Nein, nicht als einzige Maßnahme. Ein mobiler Client läuft in einer nicht vertrauenswürdigen Laufzeitumgebung. Daher muss die Autorisierungsdurchsetzung serverseitig, im Backend oder API-Gateway erfolgen. Das bloße clientseitige Ausblenden von Komponenten auf Grundlage nicht validierter Token-Claims erzeugt direkte Umgehungsrisiken und BOLA-Schwachstellen. In der Verantwortungsverteilung bedeutet dies, dass die Vereinbarung nicht dabei enden darf, wer die Rolle in der Benutzeroberfläche sichtbar macht. Es muss auch eine zugewiesene Partei geben, die die serverseitige Autorisierung umsetzt und begründet. Der Auftraggeber kann dabei festlegen, welcher Zugriff zu welcher Rolle passt; die technische Umsetzung muss verhindern, dass ein Client diese Beschränkung eigenständig umgehen kann. Dieser Einwand betrifft somit nicht eine Präferenz für eine bestimmte Benutzererfahrung, sondern die Unterscheidung zwischen Darstellung in der App und tatsächlicher Zugriffskontrolle.
- „Wer ist verantwortlich, wenn eine Änderung im Conditional Access Nutzer plötzlich aussperrt?“ Die Änderung kann im zentralen IdP erfolgen, doch damit ist die Funktion der mobilen App nicht automatisch gewährleistet. Im beschriebenen Muster ändert der Auftraggeber die Conditional-Access-Richtlinie, bricht anschließend der Redirect-Flow durch geänderte Authentifizierungsparameter und fehlt die Eigentümerschaft für das Kompatibilitätsmonitoring. Dann verweisen beide Seiten auf die jeweils andere Partei, während operative Außendienstmitarbeiter stundenlang nicht anmelden können. Legen Sie deshalb separat fest, wer Änderungen an der zentralen Richtlinie bewertet, wer die Kompatibilität des mobilen Redirect-Flows überwacht, welche Signale als Störung gelten und wer die erste Behebungsmaßnahme koordiniert. Diese Zuweisung belässt das Eigentum an der zentralen Richtlinie beim Auftraggeber, ohne dem Partner Unklarheit über die App-Kompatibilität zu lassen, für die er verantwortlich ist.
Wichtige Überlegungen zu IAM-Verantwortlichkeiten
Die abschließende Prüfung einer IAM-Aufteilung liegt in der Verwaltung nach der Lieferung. Eine Matrix ist erst dann brauchbar, wenn sie auch beschreibt, was geschieht, wenn ein Konto entzogen wird oder sich eine Rolle später ändert. Gerade dort treffen zentrale Identitätsprozesse, mobile Sitzungen und die tägliche Rechteverwaltung aufeinander.
- Legen Sie die Eigentümerschaft für die Sitzungsbeendigung fest. Enterprise-Sitzungsmanagement erfordert eine kontinuierliche Synchronisierung zwischen dem zentralen IdP, in dem De-Provisioning und SCIM-Ereignisse stattfinden, und der mobilen App. Benennen Sie daher, wer die Ereignisse auf der Identitätsseite verwaltet, wer die Verarbeitung in der App-Umgebung pflegt und wer kontrolliert, dass die Kette funktionsfähig bleibt. Ohne ausdrückliche API-Verträge für Token Revocation und Refresh-Token-Rotation können entzogene Konten nach den verfügbaren Hinweisen über aktive Offline-Tokens tagelang unbefugten Zugriff behalten. Dies ist ein konkretes operatives Risiko: Eine Verwaltungsmaßnahme im IdP erzielt dann nicht rechtzeitig die beabsichtigte Wirkung in der mobilen App.
- Verhindern Sie ein verwaistes RBAC-Modell. Rollen und Rechte, die unter Zeitdruck fest im mobilen Backend hinterlegt werden, können sich nach der Lieferung von der zentralen Verwaltung lösen. Wenn zentrale Verwaltungsoberflächen fehlen, erfolgen Rechteänderungen manuell in Datenbanken und ohne Audit-Trail. Der Auftraggeber verfügt dann über keinen normalen Verwaltungspunkt für Autorisierungen, während der Entwicklungspartner möglicherweise keinen fortlaufenden Auftrag zur Durchführung dieser Änderungen hat. Nehmen Sie daher in die Aufgabenverteilung auf, wer das Autorisierungsmodell nach der Lieferung verwaltet, wie Änderungen beantragt werden und welche Partei das Vorhandensein einer Verwaltungsoberfläche und eines Audit-Trails überprüft.
- Verknüpfen Sie Lieferantenarbeit mit nachweisbarer Verwaltung. In einer Lieferantenbeziehung reicht die technische Lieferung nicht aus, wenn die Verwaltungsgrenze für Sitzungen und Rollen unklar bleibt. Der Auftraggeber behält die Governance-Verantwortung für die eigenen Identitäts- und Rechteentscheidungen. Der Entwicklungspartner behält eine abgegrenzte Verantwortung für die vereinbarte Verarbeitung und Verwaltbarkeit in der mobilen Lösung. Diese Grenze ermöglicht es, Änderungen anhand ihrer Auswirkung auf entzogene Konten und bestehende Rollen zu bewerten, statt nur anhand des ursprünglichen Releases. Manuelle Rechteänderungen ohne Audit-Trail bleiben andernfalls eine operative Einschränkung mit direkten Folgen für die Nachvollziehbarkeit.
Dieser Artikel stellt keine Rechtsberatung dar. Die anwendbaren Verpflichtungen hängen vom Zweck, der Funktionalität, dem Nutzerkontext und der Risikoklassifizierung des Systems ab. Lassen Sie die konkrete Anwendung vor dem Einsatz in der Produktion rechtlich prüfen.
