Bildquelle: extern
Kurz gesagt App-Zustimmung bedeutet, dass eine Anwendung Rechte auf Daten oder Funktionen in einer Cloud-Umgebung erhält. In Microsoft Entra ID kann dafür ein Admin-Consent-Workflow genutzt werden, damit Benutzeranfragen nicht ungeordnet bei einzelnen Administratoren landen. Für ITSM ist das ein wichtiger Punkt: Jede neue App-Zustimmung verändert Zugriff, Risiko, Supportwege und spätere Abschaltung. Ohne festen Prüfweg wird aus einem Klick schnell ein dauerhaftes Betriebsrecht.
Cloud-Anwendungen werden heute selten isoliert eingeführt. Ein Fachbereich testet ein Planungstool, ein Projekt nutzt eine Auswertungslösung, ein Entwickler verbindet einen Automatisierungsdienst, ein externer Anbieter möchte Zugriff auf Kalender, Dateien oder Benutzerprofile. Die Frage lautet dann nicht nur, ob die App technisch funktioniert. Entscheidend ist, welche Berechtigungen sie bekommt, wer sie beantragt hat, welcher Service davon abhängt und wann die Freigabe wieder überprüft wird.
Genau diese Lücke taucht im Alltag oft zu spät auf. Eine Zustimmung wird als schneller Hilfeschritt behandelt, bleibt aber nach dem Pilotbetrieb bestehen. Monate später ist unklar, ob die Anwendung noch genutzt wird, ob die angeforderten Rechte weiterhin passen und wer eine Risikoentscheidung fachlich verantwortet. Dann wird App-Governance zur Sucharbeit.
Microsoft Entra ID ist der Identitätsdienst, der in Microsoft-Cloud-Umgebungen Anmeldungen, Unternehmensanwendungen und Berechtigungen steuert. Admin Consent bedeutet, dass ein Administrator einer App Rechte für Benutzer oder die Organisation gewährt. Der Admin-Consent-Workflow sammelt solche Anfragen und führt sie in eine prüfbare Entscheidung. Damit wird aus einem spontanen Freigabeklick ein nachvollziehbarer Betriebsprozess.
Die Berechtigung ist nur der sichtbare Anfang
Microsoft beschreibt für Consent Requests ausdrücklich, dass Administratoren Anfragen prüfen, genehmigen oder ablehnen können. Diese technische Funktion löst aber noch nicht die organisatorische Frage. Wer bewertet den Zweck der App? Wer prüft die angeforderten Rechte gegen Datenklassifikation, Schutzbedarf und Fachprozess? Wer informiert den Service Desk, falls Nutzer nach der Ablehnung fragen?
Ein sauberer Prüfweg verbindet deshalb Identity, Security, Fachbereich und Serviceverantwortung. Die IT muss wissen, ob die App wirklich zu einem anerkannten Service gehört oder nur ein persönliches Hilfswerkzeug ist. Die Security muss sehen, ob weitreichende Rechte verlangt werden. Der Fachbereich muss bestätigen, welcher Nutzen dahintersteht. Der Betrieb muss dokumentieren, wie Support, Störung und Rückbau aussehen.
Ein Pilot braucht ein Ablaufdatum
Besonders riskant sind Pilotfreigaben ohne Rückkehrpunkt. Eine App wird für ein Projekt genehmigt, weil der Nutzen plausibel klingt und der Zeitdruck hoch ist. Später wird sie entweder produktiv weitergenutzt oder still vergessen. Beides ist problematisch, wenn die ursprüngliche Zustimmung nicht neu bewertet wird.
Jede App-Zustimmung sollte daher einen Status bekommen: Test, produktiv, befristete Ausnahme oder abzubauen. Für Tests braucht es ein Ablaufdatum. Für produktive Nutzung braucht es einen Service Owner und eine Dokumentation der Rechte. Für Ausnahmen braucht es eine Begründung und eine erneute Prüfung. Für Rückbau braucht es eine klare Aufgabe, damit verwaiste Enterprise Apps und alte Service Principals nicht liegen bleiben.
Der Service Desk braucht eine verständliche Antwort
App-Anfragen sind nicht nur ein Thema für Administratoren. Wenn Benutzer eine App nicht verbinden dürfen, landet die Nachfrage häufig im Support. Ohne klare Begründung klingt die Ablehnung nach Willkür. Ein Prüfweg sollte deshalb auch festlegen, welche Antwort der Service Desk geben kann: welche App betroffen ist, welcher Datenzugriff verlangt wurde, welcher alternative Weg existiert und wer bei fachlichem Bedarf erneut beantragen darf.
Das schützt auch die Administratoren. Sie müssen nicht jede Anfrage ad hoc erklären, sondern können auf einen bekannten Prozess verweisen. So entsteht weniger Schatten-IT, weil berechtigte Anfragen nicht verschwinden, sondern sichtbar bewertet werden.
Vier Kontrollen machen den Prozess belastbar
Erstens braucht jede neue App-Anfrage eine fachliche Begründung. Zweitens müssen die angeforderten Rechte in normaler Sprache beschrieben werden. Drittens braucht jede Genehmigung einen Owner und ein Reviewdatum. Viertens sollte regelmäßig geprüft werden, welche genehmigten Apps noch aktiv genutzt werden und welche Rechte zurückgebaut werden können.
Diese Kontrollen müssen nicht schwergewichtig sein. Entscheidend ist, dass sie vor dem Produktivklick greifen und nicht erst im Audit oder bei einem Vorfall gesucht werden. Ein kurzes Formular, klare Entscheidungskriterien und ein monatlicher Review reichen oft weiter als ein perfektes, aber nie genutztes Governance-Dokument.
Fazit
App-Zustimmungen wirken wie technische Kleinigkeiten, sind im Cloud-Betrieb aber echte Zugriffsentscheidungen. Wer sie nur als Admin-Klick behandelt, sammelt Rechte, Ausnahmen und unklare Verantwortlichkeiten. Ein fester Prüfweg macht den Unterschied: Er sortiert Nutzen, Risiko, Owner, Support und Rückbau, bevor aus einer Test-App ein dauerhaftes Betriebsrecht wird.
