Eine Anfrage zur Administratorzustimmung ist keine harmlose Installationsbestätigung. Sie kann einer Anwendung weitreichenden Zugriff auf Organisationsdaten eröffnen. Ein prüfbarer Ablauf verbindet die konkrete Anwendungsidentität, angeforderte Berechtigungen, geschäftliche Notwendigkeit, entscheidungsbefugte Rolle und einen Termin zur erneuten Bewertung. Dieser Beitrag liefert eine Entscheidungskarte für Microsoft-Entra-Anfragen, nicht bloß eine Anleitung zum Klicken auf „Genehmigen“.
Microsoft beschreibt den aktuellen Ablauf zur Prüfung von Admin-Consent-Anfragen und die Bewertung von Anwendungszustimmungen. Diese Quellen betreffen die jeweilige Plattformkonfiguration; Rollen, Ansichten und Lizenzbedingungen können sich ändern. NIST SP 800-53A bietet einen allgemeinen Rahmen zur Prüfung von Kontrollen. Ein bloßer Access-Review-Leitfaden ersetzt die Entscheidung über eine neue Zustimmungsanfrage nicht.
Den Eingangskanal und die Zuständigkeit festlegen
Wenn Nutzer nicht selbst jeder Anwendung zustimmen dürfen, benötigen sie einen verständlichen Weg für legitime Anforderungen. Erfassen Sie wer die Anwendung benötigt, für welchen Arbeitsprozess, in welchem Mandanten und bis wann. Benennen Sie einen Geschäftsverantwortlichen, der die Nutzung bestätigt, und einen Identitäts- oder Sicherheitsverantwortlichen, der die technische Berechtigung bewertet. Ohne diese Rollen kann eine dringende Anfrage faktisch durch Zeitdruck freigegeben werden.
Prüfen Sie, ob die Anfrage tatsächlich im konfigurierten Administratorzustimmungs-Workflow vorliegt oder über einen anderen Weg kam. Ein Beschaffungsticket, eine Hersteller-E-Mail und ein Entra-Eintrag sind verschiedene Belege. Microsoft erläutert, dass benannte Prüfer Anfragen sehen können, aber nur bei bestimmten zeitlichen und rollenbezogenen Voraussetzungen darüber handeln. Legen Sie den internen Entscheidungspfad daher anhand der tatsächlich zugewiesenen Rollen fest. Die Informationssicherheitsrichtlinie kann die generelle Zuständigkeit beschreiben; die einzelne Karte dokumentiert den konkreten Vorgang.
Eine nicht auffindbare Anfrage ist kein Beweis, dass kein Zugriff existiert. Bereits erteilte Zustimmungen oder andere Berechtigungswege können weiterhin wirken. Trennen Sie Prüfung neuer Anfragen von der Inventur vorhandener Berechtigungen und verweisen Sie auffällige Bestandsrechte in einen eigenen Nachprüfungsprozess.
Die Anwendung eindeutig identifizieren
Notieren Sie Anzeigenamen, Anwendungs-ID, Publisher, relevante Mandantenkennung und den Dienst, den die Anwendung bereitstellen soll. Anzeigenamen können ähnlich oder verändert sein. Fragen Sie beim Fachbereich nach Hersteller, Vertragsbeziehung und erwarteter Funktion, und gleichen Sie diese Angaben mit der tatsächlich anfragenden Registrierung ab. Eine verifizierte Publisher-Angabe kann helfen, ist aber keine Freigabe für beliebige Berechtigungen.
Wenn die Anwendung zu einem bekannten Produkt gehört, klären Sie, warum diese konkrete Registrierung verwendet wird. Anbieter betreiben gelegentlich getrennte Clients für Tests, Regionen oder Funktionen. Solche Unterschiede können legitim sein, müssen aber erklärbar sein. Fordern Sie bei Unsicherheit eine Bestätigung über einen verlässlichen Kontaktweg an, statt allein dem Logo im Zustimmungsfenster zu vertrauen.
Dokumentieren Sie die Identität so, dass später nachvollzogen werden kann, welchem Objekt zugestimmt wurde. Kopieren Sie keine Geheimnisse, Zertifikatsschlüssel oder Tokens in die Entscheidungskarte. Die SSO- und Datenschutzübersicht erläutert die allgemeinere Identitätsumgebung; hier geht es gezielt um Rechte der angebundenen Anwendung.
Angeforderte Scopes einzeln verstehen
Listen Sie Ressource und Berechtigung für jede relevante Anfrage auf. Unterscheiden Sie delegierte Berechtigungen, bei denen die Anwendung im Kontext eines angemeldeten Nutzers handelt, von Anwendungsberechtigungen, die ohne diesen Nutzerkontext wirken. Microsoft warnt, dass mandantenweite Zustimmung ein sensibler Vorgang ist und hochprivilegierte Operationen erlauben kann. Die Wirkung hängt vom konkreten Scope, weiteren Beschränkungen und der Anwendungskonfiguration ab; eine pauschale Aussage „die App liest alles“ kann ebenso falsch sein wie „sie sieht nur meine Daten“.
Bitten Sie den Antragsteller für jede weitreichende Berechtigung um eine Zuordnung zur Funktion. Warum benötigt ein Terminwerkzeug Postfachzugriff, Verzeichnisrollen oder Schreibrechte auf Dateien? Prüfen Sie, ob ein engerer Scope, eine alternative Architektur oder eine andere Integrationsart den Zweck erfüllt. Ein erfolgreicher Test mit breiten Rechten beweist nicht, dass alle angeforderten Rechte notwendig sind. Halten Sie die Antwort des Anbieters und technische Grenzen fest.
Die Bezeichnungen und Beschreibungen im Zustimmungsdialog sind ein Ausgangspunkt. Prüfen Sie die Dokumentation der jeweiligen API und konkrete Ressourcengrenzen. Wenn eine Berechtigung unklar bleibt, ist „weitere Informationen nötig“ eine bessere Entscheidung als Zustimmung unter Vorbehalt ohne Prüfauftrag.
Entscheidungskarte für eine Anfrage
Eine kompakte Karte macht die Prüfung wiederholbar:
| Feld | Eintrag und Nachweis |
|---|---|
| Identität | Anwendungs-ID, Publisher, Mandant, fachlicher Dienst |
| Zweck | Geschäftsvorgang, Nutzergruppe, Verantwortlicher |
| Berechtigungen | Ressource, delegiert oder Anwendung, Umfang |
| Risiko | Betroffene Daten, mögliche Operationen, bestehende Kontrollen |
| Alternative | Engerer Scope, andere Integration oder Ablehnung |
| Entscheider | Technischer Prüfer und berechtigte Freigaberolle |
| Beschluss | Genehmigen, ablehnen, blockieren oder nachfragen |
| Nachprüfung | Zeitpunkt, Auslöser, Bestandsprüfung und Widerrufspfad |
Die Karte ist ein redaktionelles Arbeitsmittel, keine von Microsoft vorgeschriebene Formularstruktur. Schreiben Sie die Entscheidung und ihre Gründe vor dem Klick nieder. Bei Ablehnung halten Sie fest, welche Informationen fehlen oder welches Risiko nicht akzeptiert wird. Bei Genehmigung dokumentieren Sie die tatsächlich gewährten Berechtigungen nach der Handlung, weil Antrag und Ergebnis voneinander abweichen können.
Eine reine Unterschrift des Fachbereichs reicht für eine technisch weitreichende Freigabe möglicherweise nicht. Umgekehrt kann ein Administrator die technische Berechtigung verstehen, ohne den geschäftlichen Zweck beurteilen zu können. Beide Perspektiven müssen im Ablauf zusammenkommen.
Plattformaktionen richtig auseinanderhalten
Microsoft unterscheidet im Admin-Consent-Workflow unter anderem Prüfung, Ablehnung und Blockieren. Laut Dokumentation können abgelehnte Anfragen erneut gestellt werden; Blockieren verhindert weitere Anfragen für dieselbe Anwendung auf dem beschriebenen Weg. Beide Aktionen sind etwas anderes als eine Bestandsberechtigung zu widerrufen. Prüfen Sie daher bei jeder Entscheidung, ob bereits andere Grants bestehen und ob der gewählte Knopf den beabsichtigten Effekt hat.
Eine Genehmigung kann den Zugang zur Anwendung mandantenweit ermöglichen, sofern er nicht zusätzlich etwa durch Nutzerzuweisung beschränkt wird. Gehen Sie nicht davon aus, dass die Fachabteilung automatisch die einzige Nutzergruppe bleibt. Falls nur ein kleiner Kreis den Dienst braucht, bewerten Sie die separate Zugriffsbeschränkung und prüfen Sie deren Wirkung. Die Zustimmung zu einer Berechtigung und die Zuweisung von Nutzern sind verschiedene Entscheidungen.
Die Passwortrichtlinie und Authentisierung betrifft Konten und Anmeldeverfahren. Eine starke Anmeldung macht weitreichende Anwendungsrechte nicht automatisch unproblematisch; beides sind unterschiedliche Kontrollschichten.
Beispiel: ein Projektmanagement-Connector
Ein fiktiver Fachbereich möchte einen Connector zwischen Microsoft 365 und einem Projektmanagement-Dienst aktivieren. Der Antrag nennt ein bekanntes Produkt, verlangt jedoch neben Kalenderzugriff auch Berechtigungen zum Lesen aller Dateien einer Ressource. Die Karte hält App-ID, Publisher, beantragte Scopes und den erwarteten Prozess fest. Der Fachbereich erklärt, dass nur Kalendertermine synchronisiert werden sollen. Das zusätzliche Leserecht ist zunächst nicht begründet.
Der technische Prüfer fragt den Anbieter, ob eine engere Konfiguration möglich ist, und testet diese mit einem begrenzten Konto. Wenn der Connector nur mit den breiten Rechten funktioniert, stellt die Karte den Nutzen dem Zugriffsumfang gegenüber. Der zuständige Entscheider kann die Anfrage ablehnen, bis eine Alternative vorliegt, oder eine zeitlich begrenzte Ausnahme nach internem Verfahren beschließen. „Der Nutzer braucht die App morgen“ ersetzt diese Risikoentscheidung nicht.
Nach einer zulässigen Genehmigung prüft das Team die tatsächlich erteilten Berechtigungen und den Nutzerzugriff. Es notiert einen Termin zur erneuten Bewertung nach dem Pilotprojekt. Das Beispiel behauptet keine echte Berechtigungsanforderung eines bestimmten Produkts; es zeigt, wie eine unpassende Scope-Funktion-Beziehung sichtbar wird.
Nach der Genehmigung erneut prüfen
Eine Zustimmung kann überleben, nachdem das Projekt endet, der Anbieter die Funktion ändert oder der ursprüngliche Verantwortliche das Unternehmen verlässt. Definieren Sie Auslöser für eine neue Prüfung: zusätzliche Scopes, neue Registrierung, Änderung des Publishers, geringere Nutzung, Sicherheitsvorfall oder Ende des Vertrags. Erheben Sie die vorhandenen Grants statt nur die ursprüngliche Karte zu lesen. Die Datenschutz-Management-Software-Übersicht zeigt breiteren Governance-Kontext; sie ersetzt keine genaue Inventur der Entra-Berechtigungen.
Werten Sie Nutzungsdaten mit Vorsicht aus. Keine Aktivität in einem kurzen Logfenster kann ein selten genutztes Notfallverfahren oder unvollständige Protokollierung bedeuten. Fragen Sie den fachlichen Besitzer und dokumentieren Sie die Beobachtungsdauer. Eine nachweislich entbehrliche Berechtigung kann nach einem geplanten Änderungsprozess entzogen werden. Prüfen Sie danach, ob die Anwendung weiterhin zulässige Aufgaben erfüllt und ob neue Zustimmung unter den aktuellen Tenant-Regeln möglich wäre.
Ein Widerruf kann je nach Art der Berechtigung und Plattformmechanismus unterschiedliche Schritte erfordern. Prüfen Sie die aktuelle Microsoft-Anleitung zum konkreten Grant. Versprechen Sie nicht, dass ein einzelner Klick alle bestehenden Sitzungen oder anderen Autorisierungswege sofort beseitigt.
Sonderfälle und Eskalationen
Eine dringende Anfrage kann eine bestehende Störung betreffen. Definieren Sie vorab eine Notfallroute mit engem Scope, befristeter Entscheidung und nachträglicher Prüfung. Wird dieselbe Notfallbegründung regelmäßig genutzt, liegt ein Prozessproblem vor. Einem permanenten Administratorrecht für alle Anfragen fehlt die Trennung zwischen Routine und Ausnahme. Erfassen Sie, wer die Ausnahme erteilte, welche Daten betroffen waren und wann sie endet.
Eine Anwendung kann mehrere Ressourcen anfordern. Bewerten Sie jede bedeutsame Ressource, statt einen Gesamtknopf aufgrund einer unkritischen Teilfunktion zu bestätigen. Bei sensiblen Berechtigungen kann der Identitätsverantwortliche zusätzliche technische Tests oder Vertragsinformationen verlangen. Wenn die Informationen nicht rechtzeitig kommen, bleibt die Anfrage offen oder wird nach dokumentierter Regel abgelehnt; ungeprüfte Freigabe ist keine neutrale Zwischenlösung.
Nach einer Ablehnung kommunizieren Sie dem Antragsteller einen Weg zu einer neuen, präziseren Anfrage. Microsofts Workflow-Aktionen haben eigene Benachrichtigungsdetails; die interne Kommunikation sollte den geschäftlichen Grund, eine mögliche Alternative und den Verantwortlichen erklären. So wird Sicherheit nicht zu einem undurchsichtigen Hindernis, während die technische Risikogrenze bestehen bleibt.
Kontrolle des Verfahrens selbst
Überprüfen Sie in einer Stichprobe, ob Karten zu tatsächlichen Consent-Ereignissen passen. Enthält jede Freigabe die Anwendungs-ID und die gewährten Scopes? Waren die Freigabeberechtigten in der vorgesehenen Rolle? Wurde bei Ablehnung ein Grund dokumentiert? Sind Nachprüfungstermine erreicht und bearbeitet worden? Ein Verfahren auf Papier kann gut aussehen, während Administratoren weiterhin außerhalb des vorgesehenen Kanals zustimmen.
Betrachten Sie zusätzlich bereits bestehende Anwendungen mit hohen Berechtigungen. Der neue Workflow verhindert nicht rückwirkend riskante alte Grants. Priorisieren Sie die Bestandsprüfung nach Zugriffsumfang, Daten, fehlendem Besitzer und Nutzung. Halten Sie die Reichweite der Protokolle und Exportdaten fest. Ein Dashboardwert „keine offenen Anfragen“ sagt nichts über alte Zustimmungen.
Eine belastbare Entscheidungskarte zeigt schließlich, welche konkrete Anwendung für welche Funktion welche Rechte verlangte, wer sie nach welcher Prüfung erteilte oder ablehnte und wann die Begründung erneut geprüft werden muss. Damit wird Administratorzustimmung zu einer nachvollziehbaren Risikoentscheidung statt zu einer unbemerkten Nebenwirkung der Softwareeinführung.
Rechte außerhalb des Zustimmungsfensters erfassen
Eine Entra-Anwendung kann neben den betrachteten API-Berechtigungen weitere Zugriffswege besitzen. Dazu gehören zugewiesene Verzeichnisrollen, Ressourcenzuweisungen, technische Identitäten oder separate Berechtigungen im Zielsystem. Die Entscheidungskarte sollte nicht behaupten, die gesamte Berechtigungslage zu erfassen, wenn sie nur das Consent-Fenster auswertet. Verweisen Sie für jede relevante zusätzliche Route auf den zuständigen Prüfprozess und dokumentieren Sie, wer das Ergebnis zurückmeldet. Sonst kann eine formal eng begrenzte Zustimmung durch einen anderen, ungeprüften Zugriff ergänzt werden.
Bei Anwendungen, die personenbezogene Daten berühren, ist auch die Vertrags- und Verarbeitungsseite zu betrachten. Die DSGVO-Auditkosten- und Softwareübersicht behandelt breitere Auswahlfragen; die technische Freigabe beantwortet nicht automatisch, ob der Anbieter die Daten in einer vereinbarten Rolle verarbeitet. Trennen Sie diese Prüfung von der Zustimmungsentscheidung, verbinden Sie beide aber durch einen gemeinsamen Vorgangsbezug. Eine rechtlich geklärte Datenverarbeitung macht einen überbreiten Scope nicht notwendig, und eine eng konfigurierte Anwendung ersetzt keinen erforderlichen Vertrag.
Varianten der Anfrage gegeneinander prüfen
Ein Antragsteller kann zunächst eine Anwendung mit mehreren weitreichenden Berechtigungen vorschlagen. Nach Rückfrage bietet der Hersteller möglicherweise eine Version mit geringeren Rechten oder einem anderen Betriebsmodus an. Bewahren Sie beide Varianten auf. Die Genehmigung sollte die tatsächlich geprüfte Variante bezeichnen, nicht den Produktnamen allgemein. Wird später eine neue Version eingeführt, vergleichen Sie App-ID, Ressourcen und Scopes mit dem genehmigten Stand. Eine Marketing-Mitteilung über „nur kleine Änderungen“ ist dafür kein ausreichender Nachweis.
Wird eine Anfrage im Workflow abgelehnt, prüfen Sie, ob ein Administrator außerhalb dieses Workflows dennoch Rechte erteilen kann. Die Zustimmungsrichtlinie, Administratorrollen und Auditprotokolle bilden zusammen den tatsächlichen Kontrollpfad. Eine Entscheidungskarte dokumentiert den fachlichen Prozess, kann aber eine fehlerhafte Rollentrennung nicht technisch verhindern. Zeigt eine Stichprobe Umgehungen, muss die Organisation Rollen und Prozess anpassen statt nur zusätzliche Pflichtfelder einzuführen.
Ein erneutes Prüfdatum sinnvoll wählen
Der erste Nachprüfungstermin sollte an eine erkennbare Änderung oder einen passenden Nutzungszyklus anknüpfen. Bei einem Pilotprojekt kann der Abschluss des Piloten wichtiger sein als ein starres Jahresdatum. Bei einer kritischen Dauerintegration können Vertragswechsel, neue Scopes oder ein Sicherheitsereignis eine außerplanmäßige Prüfung auslösen. Schreiben Sie, welche Daten bei der Nachprüfung verfügbar sein müssen: Bestands-Grants, Besitzer, tatsächliche Nutzung, technische Einschränkungen und etwaige Beschwerden.
Wenn der ursprüngliche Besitzer nicht mehr erreichbar ist, weisen Sie die Anfrage nicht automatisch der IT als fachlicher Eigentümerin zu. Ermitteln Sie, welcher Prozess den Dienst nutzt, und lassen Sie diesen Bereich die weitere Notwendigkeit bestätigen. Bis dahin kann eine risikobasierte Zwischenentscheidung notwendig sein. Notieren Sie deren Laufzeit und die Person, die den Zugang bei ausbleibender Klärung beschränken darf.
Bei der Stichprobe sollte auch eine abgelehnte Anfrage betrachtet werden. Wurde nur der sichtbare Workflow-Eintrag geschlossen, oder existiert ein älterer Grant für dieselbe App-ID? Welche Rückmeldung erhielt der Antragsteller, und kann er mit engeren Rechten erneut beantragen? Ein solches Negativbeispiel zeigt, ob der Ablauf einen unnötigen Zugriff verhindert und zugleich einen legitimen Bedarf bearbeitbar hält. Dokumentieren Sie den Unterschied zwischen abgelehntem Antrag und wirksam entzogenem Bestandsrecht ausdrücklich.
Die gesamte Prüfung bleibt zeitgebunden. Ein Publisher, eine Berechtigungsbeschreibung oder eine Rollenfunktion kann sich ändern. Halten Sie deshalb fest, auf welchen Dokumentationsstand und welche Tenant-Einstellungen sich die Entscheidung stützte. Bei einer späteren Revision muss nicht jede alte Annahme blind übernommen werden; die Verantwortlichen können den dann aktuellen Zustand erneut mit dem freigegebenen Geschäftszweck vergleichen.