Anmeldeinformations- und Berechtigungsverwaltung für App-Registrierungen in Entra ID

Sobald deine Apps klar definierte Eigentümer und Verantwortlichkeiten haben (siehe Teil 2), ist die nächste Schutzschicht die Verwaltung, wie sie sich authentifizieren und worauf sie zugreifen können.

Hier bauen sich Probleme oft still und leise auf. Anmeldeinformationen werden wiederverwendet oder vergessen. Apps sammeln Berechtigungen an, die weit über das hinausgehen, was sie benötigen. Und ohne Leitplanken kann jeder neue Registrierungen erstellen, die an der IT vorbeischlüpfen.

In diesem Artikel gehen wir drei Praktiken durch, die helfen, deine App-Identity-Landschaft unter Kontrolle zu halten:

• Sichere Verwaltung von Anmeldeinformationen und Vermeidung von Ablaufüberraschungen
• Anwendung des Prinzips der geringsten Berechtigung auf App-Berechtigungen
• Einschränkung der App-Registrierungsrechte zur Vermeidung von Schatten-IT

Jede davon adressiert einen häufigen blinden Fleck in Microsoft Entra ID. Und jede davon legt den Grundstein für eine sicherere, besser verwaltbare und vorhersehbarere Identity-Umgebung.

Best Practice 4: Wähle den richtigen Anmeldeinformationstyp für jede App

Um sich sicher in Microsoft Entra ID zu authentifizieren, benötigt eine Anwendung eine Anmeldeinformation. Diese Anmeldeinformation beweist die Identität der App und ermöglicht es ihr, Zugriffstoken für Dienste wie Microsoft Graph, SharePoint oder benutzerdefinierte APIs anzufordern.

Anmeldeinformationen können auf zwei Arten ausgeführt werden:

• Delegierte Berechtigungen (Benutzer + App-Kontext) – ermöglichen es einer Anwendung, im Namen eines angemeldeten Benutzers zu handeln. Der effektive Zugriff wird durch die Vereinigung der Berechtigungen des Benutzers und der Anwendung bestimmt, was bedeutet, dass die App nur Aktionen ausführen kann, die für beide zulässig sind.
• Anwendungsberechtigungen (Nur-App-Kontext) – ermöglichen es einer Anwendung, sich zu authentifizieren und unabhängig von einem Benutzer zu operieren. In diesem Modus läuft die App mit ihrer eigenen Identität und kann direkt auf Ressourcen zugreifen, ohne dass eine Benutzeranmeldung oder Zustimmung zur Laufzeit erforderlich ist.

Abhängig vom Setup verwendet die App entweder ein Client Secret oder ein Zertifikat, die wie ein Passwort für die Anwendung funktionieren und Authentifizierungstoken anfordern.

Microsoft Entra ID unterstützt zwei primäre Arten von Anmeldeinformationen für App-Registrierungen:

• Client Secrets (ähnlich wie Passwörter)
• Zertifikate (kryptografische Schlüssel)

Für diejenigen, die neu in diesem Thema sind, hilft es, sich diese Anmeldeinformationen wie Schlüssel vorzustellen, die die Anwendung verwendet, um die sichere Kommunikation mit Microsoft-Diensten zu entsperren. So wie du nicht denselben Hausschlüssel mit zu vielen Personen teilen oder ihn an einem unsicheren Ort lassen würdest, müssen Anwendungsanmeldeinformationen sorgfältig verwaltet werden, um Missbrauch zu vermeiden.

Microsoft empfiehlt, wann immer möglich Zertifikate anstelle von Client Secrets zu verwenden. Zertifikate bieten stärkeren Schutz, da sie schwerer zu erraten oder zu extrahieren sind und sich gut in sichere Speichersysteme integrieren lassen.

Best Practice 5: Handhabe kurze Lebensdauern für Anmeldeinformationen und verwende sichere Speicherung

• Unabhängig davon, welche Art von Schlüssel du verwendest, solltest du immer versuchen, eine kurze Gültigkeitsdauer für solche Schlüssel zu haben: setze kurze Ablauffristen (idealerweise 6 Monate oder weniger)
• Vermeide die Speicherung von Secrets im Klartext in Skripten, Dateien oder gemeinsamen Dokumentationen
• Verwende Azure Key Vault, um Secrets und Zertifikate sicher zu speichern

Kürzere Lebensdauern begrenzen deine Exposition, falls ein Secret/eine Anmeldeinformation jemals durchsickert, und sichere Speicherung hält sensible Informationen ausser Reichweite unbefugter Benutzer.

Best Practice 6: Überwache den Ablauf von Anmeldeinformationen, um Ausfälle zu verhindern

Da wir die Zeitspanne einer Anmeldeinformation reduzieren, erhöhen wir auch das Risiko von Serviceunterbrechungen, wenn eine solche Anmeldeinformation abläuft und nicht mehr verwendbar ist und unsere Anwendung keine neue Anmeldeinformation zur Authentifizierung erhalten hat. Wenn ein Secret oder Zertifikat abläuft und nicht erneuert wird, verliert die App den Zugriff und funktioniert möglicherweise nicht mehr, was potenziell Serviceausfälle verursacht.

Um dies zu verhindern:

• Überwache Ablaufdaten mit der Microsoft Graph API
• Verfolge, welche Apps Anmeldeinformationen haben, die bald ablaufen, und handle, bevor ihr Service unterbrochen wird

Ein proaktiver Ansatz vermeidet Last-Minute-Hektik und ungeplante Ausfälle.

Best Practice 7: Überprüfe Anmeldeinformationen regelmässig, um alten Zugriff zu bereinigen

Im Laufe der Zeit können Apps veraltet, ersetzt oder vergessen werden, doch ihre Anmeldeinformationen bleiben oft zurück.

Regelmässige Anmeldeinformationsüberprüfungen helfen dir:

• Veraltete oder ungenutzte Anmeldeinformationen zu entfernen
• Das Risiko zu begrenzen, dass vergessener Zugriff in die falschen Hände gerät
• Deine Exposition in der Identity-Umgebung zu reduzieren

Um diesen Prozess zu rationalisieren, bietet EasyLife 365 Identity erweiterte Anmeldeinformations-Governance-Funktionen. Es bietet zentralisierte Sichtbarkeit in alle registrierten Anwendungen, hebt ablaufende oder veraltete Anmeldeinformationen hervor und ermöglicht automatische oder halbautomatische Erneuerungs-Workflows.

Übersicht ablaufender Anmeldeinformationen im EasyLife 365 Identity-Dashboard.

Diese Fähigkeiten sind in die Anwendungseigentümerschaft und Sponsorship-Modelle integriert, die in Teil 2 dieser Serie eingeführt wurden, sodass die richtigen Personen, die für die Anwendung verantwortlich sind, benachrichtigt werden, wenn Massnahmen erforderlich sind. Dies stellt sicher, dass die Anmeldeinformationsverwaltung nicht isoliert stattfindet, sondern Teil eines breiteren, verantwortlichen Governance-Prozesses ist.

Die ordnungsgemässe Anmeldeinformationsverwaltung ist nicht nur eine technische Angelegenheit, sondern eine grundlegende Sicherheitspraxis. Wenn Anmeldeinformationen mit der gleichen Sorgfalt wie Benutzerpasswörter oder Zugriffsschlüssel behandelt werden, reduzierst du das Risiko sowohl versehentlicher Ausfälle als auch böswilligen Zugriffs.

Best Practice 8: Wende das Prinzip der geringsten Berechtigung auf App-Berechtigungen an

Wenn eine Anwendung in Microsoft Entra ID registriert wird, benötigt sie oft die Berechtigung, auf Microsoft 365-Dienste oder APIs wie Microsoft Graph zuzugreifen. Diese Berechtigungen bestimmen, was die App im Namen eines Benutzers oder der Organisation tun darf.

Eine App könnte die Berechtigung anfordern, Benutzerprofile zu lesen, E-Mails zu senden, auf Kalender zuzugreifen oder sogar Verzeichniseinstellungen zu aktualisieren. Während viele dieser Anfragen legitim und notwendig sind, können sie leicht die Tür zu einem breiteren Sicherheitsproblem öffnen: übermässig berechtigte Apps.

Hier wird das Prinzip der geringsten Berechtigung unerlässlich. Es ist ein grundlegendes Konzept in der Cybersicherheit, das besagt, dass jede Identität, sei es ein Benutzer, ein Gerät oder eine Anwendung, nur die minimale Zugriffsebene haben sollte, die zur Ausführung ihrer Funktion erforderlich ist, und nicht mehr. Wenn dieses Prinzip nicht angewendet wird, werden Anwendungen oft viel mehr Macht gewährt, als sie tatsächlich benötigen.

Zum Beispiel:

Betrachte eine Berichtsanwendung, die nur Benutzerprofilinformationen lesen muss. Wenn ihr die Berechtigung Directory.ReadWrite.All gewährt wird, hat sie jetzt die Möglichkeit, Objekte in deinem gesamten Entra ID-Mandanten zu erstellen, zu ändern oder zu löschen. Wenn die App jemals kompromittiert wird, gibt diese Zugriffsebene einem Angreifer die Möglichkeit, kritische Teile deines Verzeichnisses zu manipulieren, was potenziell zu Datenverlust, Privilegieneskalation oder lateraler Bewegung in deiner Umgebung führen kann.

Ähnlich, wenn einer falsch konfigurierten App Zugriff auf E-Mail-Postfächer von Benutzern gewährt wird, obwohl sie nur Kalenderzugriff benötigt, wird sie zu einem viel attraktiveren und gefährlicheren Ziel.

Es gibt zwei Arten von API-Berechtigungen in Microsoft Entra ID:

• Delegierte Berechtigungen, die einen angemeldeten Benutzer erfordern und es der App ermöglichen, im Namen des Benutzers zu handeln, unter Beachtung seiner Zugriffsrechte
• Anwendungsberechtigungen, die es der App ermöglichen, unabhängig von einem Benutzer zu handeln, oft mit breiterem und mächtigerem Zugriff

Wo möglich, ist es sicherer, delegierte Berechtigungen zu verwenden, da diese auf die spezifische Zugriffsebene des Benutzers und die Anwendungsberechtigungen beschränkt sind. Genauer gesagt bezieht es sich auf die Schnittmenge zwischen den einem Benutzer gewährten Berechtigungen und denen, die der App gewährt wurden. Anwendungsberechtigungen hingegen sollten nur gewährt werden, wenn absolut notwendig, und nur für Anwendungen, die gut geschützt, gut überwacht und klar im Besitz sind. Beachte, dass dies nicht bedeutet, dass du einer App keine Anwendungsberechtigungen zuweisen solltest. Es gibt viele Fälle, in denen dies für deinen Anwendungsfall angemessen ist.

Um diese Berechtigungen zu verwalten, können Administratoren die API-Berechtigungsschnittstelle in den App-Registrierungseinstellungen im Entra Admin Portal verwenden.

Entra ID-Berechtigungsbildschirm mit delegierten und Anwendungs-API-Bereichen.

Diese Schnittstelle zeigt:

• Welche Berechtigungen eine Anwendung angefordert hat
• Ob die Admin-Zustimmung erteilt wurde
• Auf welche Art von Daten die App zugreifen kann

Die regelmässige Überprüfung dieser Liste hilft sicherzustellen, dass Apps nicht still und leise gefährliche Privilegien im Laufe der Zeit ansammeln.

Die Zustimmung kann auf zwei verschiedene Arten erteilt werden:

• Durch einen Administrator – für organisationsweite Szenarien oder wenn eine App höher privilegierte Berechtigungen erfordert, die Benutzer nicht selbst genehmigen können.
• Durch einzelne Benutzer – in Fällen, in denen die App nur Berechtigungen anfordert, denen Benutzer selbst im eigenen Namen zustimmen dürfen. Dies gilt häufig für delegierte Berechtigungen mit geringer Auswirkung, wie das Lesen grundlegender Profildaten.

Es ist auch wichtig zu beachten, dass die Überprüfung der Liste in der Anwendungsschnittstelle allein nicht ausreicht. Administratoren können dort frei Einträge hinzufügen oder entfernen, aber diese Änderungen wirken sich nicht direkt darauf aus, was die Anwendung tatsächlich tun darf. Der effektive Satz von Berechtigungen wird durch den Service Principal bestimmt, der die Anwendungsinstanz in deinem Mandanten repräsentiert.

In der Praxis bedeutet dies: Die in der App-Registrierungsschnittstelle angezeigten Berechtigungen können sich von denen unterscheiden, die im Service Principal gewährt wurden.

Nur die Berechtigungen, denen entweder von einem Administrator oder von einem Benutzer zum Zeitpunkt der Nutzung ausdrücklich zugestimmt wurde, sind gültig und werden durchgesetzt. Wenn der Service Principal ältere, breitere Berechtigungen behalten hat, die in der App-Registrierungsschnittstelle nicht mehr sichtbar sind, kann die Anwendung möglicherweise noch mit höheren Privilegien operieren als erwartet.

Diese Unterscheidung macht es kritisch, nicht nur die App-Registrierung, sondern auch die Service Principal-Objekte in deinem Mandanten zu überprüfen. Das Übersehen davon könnte zu Schatten-Berechtigungen führen, Privilegien, die still und leise bestehen bleiben, selbst nachdem die Registrierungseinstellungen einer App verschärft wurden.

Die regelmässige Überprüfung von Service Principals, der Vergleich ihrer effektiven Berechtigungen mit denen, die in App-Registrierungen angezeigt werden, und das Entfernen ungenutzter oder nicht übereinstimmender Privilegien sind wesentliche Schritte zur Aufrechterhaltung einer Umgebung mit geringsten Berechtigungen.

Best Practice 9: Verwende Admin-Zustimmungs-Workflows zur Kontrolle des sensiblen Zugriffs

Für Anwendungen, die hochrangige oder sensible Berechtigungen anfordern, sollten Organisationen den Admin-Zustimmungs-Workflow aktivieren. Diese Funktion bietet einen integrierten Genehmigungsprozess für Apps, die Berechtigungen anfordern, die Benutzer nicht selbst gewähren dürfen.

Anstatt sich darauf zu verlassen, dass Benutzer das Risiko einer Berechtigung wie Mail.ReadWrite verstehen, leitet der Workflow die Anfrage an einen Administrator oder ein Sicherheitsteam weiter. Sie können beurteilen, ob der Zugriff gerechtfertigt ist, bevor sie ihn genehmigen. Dies hilft, versehentliche Über-Berechtigung durch Missverständnis oder Social Engineering zu verhindern.

Das Gewähren zu vieler Berechtigungen für Anwendungen kann die Angriffsfläche deiner Organisation erheblich vergrössern. Wenn nur eine App mit übermässigen Berechtigungen kompromittiert wird, sei es durch durchgesickerte Anmeldeinformationen, eine Schwachstelle oder Insider-Missbrauch, kann sie die Tür zu weitreichendem Schaden öffnen.

Deshalb ist das Prinzip der geringsten Berechtigung so wichtig. Es begrenzt die potenzielle Auswirkung, wenn eine App missbraucht wird. Durch Anwendung dieses Prinzips können Organisationen ihre Exposition gegenüber unbefugtem Zugriff, Datenverletzungen und Identitätsmissbrauch erheblich reduzieren, während sie dennoch die Apps aktivieren, auf die ihre Benutzer und Teams angewiesen sind.

Best Practice 10: Beschränke, wer Apps im Mandanten registrieren kann

In Microsoft Entra ID darf standardmässig jeder Benutzer im Mandanten App-Registrierungen erstellen. Während diese Standardeinstellung Flexibilität für Entwickler und Teams unterstützt, die mit Anwendungen experimentieren, führt sie auch erhebliche Sicherheits- und Governance-Risiken ein, insbesondere in grösseren oder stärker regulierten Umgebungen.

Wenn Benutzer Apps frei registrieren können, können sie auch Anmeldeinformationen generieren und API-Berechtigungen anfordern, die diesen Apps Zugriff auf Microsoft 365-Daten ermöglichen oder mit anderen Cloud-Diensten interagieren. Ohne Aufsicht führt dies zu einem Phänomen, das als Schatten-IT bekannt ist – Technologie-Tools und Integrationen, die ausserhalb der Sichtbarkeit und Kontrolle der IT operieren.

Schatten-IT führt eine Reihe von Risiken ein:

• Anwendungen können falsch konfiguriert sein
• Sie können übermässige oder unnötige Berechtigungen anfordern
• Secrets könnten unsicher gespeichert werden
• Apps können nach dem Testen aufgegeben werden und ungenutzte Anmeldeinformationen zurücklassen

Um dies zu verhindern, enthält Microsoft Entra ID eine Einstellung, die es Administratoren ermöglicht, einzuschränken, wer App-Registrierungen erstellen kann.

Diese Konfiguration ist unter Benutzereinstellungen im Entra Admin Center verfügbar. Von hier aus kannst du:

• Die Standardberechtigung deaktivieren, die allen Benutzern erlaubt, Apps zu registrieren
• Nur ausgewählten Mitgliedern einer Entra ID-Sicherheitsgruppe erlauben, App-Registrierungen zu erstellen und zu verwalten

Diese Sicherheitsgruppe sollte nur vertrauenswürdige Benutzer enthalten, die Best Practices für App-Registrierungen verstehen. Dies könnte einschliessen:

• Mitglieder eines DevSecOps- oder Cloud Platform Engineering-Teams
• Genehmigte Entwickler in bestimmten Abteilungen

Durch Begrenzung dieser Fähigkeit stellst du sicher, dass jede neue App-Registrierung von jemandem erstellt wird, der versteht, wie man sie sicher konfiguriert, angemessene Berechtigungen zuweist, Anmeldeinformationen verwaltet und den Governance-Richtlinien deiner Organisation folgt.

In kleineren Organisationen oder entwicklungsintensiven Umgebungen kann es angemessen sein, einen breiteren Zugriff zu ermöglichen. Aber selbst in diesen Fällen ist es wichtig, App-Erstellungsaktivitäten zu überwachen und sicherzustellen, dass Benutzer sich der Risiken und Verantwortlichkeiten bewusst sind, die mit der Verwaltung einer Anwendungsidentität verbunden sind.

Die Einschränkung, wer Apps registrieren kann, verbessert auch Überprüfbarkeit und Verantwortlichkeit. Wenn nur eine bekannte Gruppe von Benutzern App-Registrierungen erstellen kann, wird es viel einfacher, Schlüsselfragen zu beantworten:

• Wer hat diese App erstellt?
• Warum existiert sie?
• Wer ist dafür verantwortlich?

Dies reduziert das Risiko, dass Apps unverwaltet, falsch konfiguriert oder übermässig berechtigt bleiben.

Wir haben EasyLife 365 Identity gebaut, um diesen Kontrollpunkt zu stärken, weil eines der frühesten Muster, die wir sahen, klar war:

Anwendungschaos beginnt oft, wenn jeder ohne Aufsicht eine App registrieren kann.

Ohne definierte Grenzen tauchen Apps auf mit:

• Keinem Eigentümer
• Keinem Sponsor
• Keiner geschäftlichen Rechtfertigung

EasyLife 365 Identity adressiert dies, indem es dir ermöglicht, auf granularer Ebene zu definieren, wer Anwendungen erstellen oder sponsern kann, und die Registrierungsaktivität im Laufe der Zeit zu verfolgen. Mit integrierten Lifecycle Workflows stellt es auch sicher, dass jede neu erstellte App definierte Eigentümerschaft, ordnungsgemässes Tagging und einen ersten Überprüfungsprozess hat. Diese Leitplanken reduzieren die Chancen, dass unverwaltete oder risikoreiche Anwendungen unbemerkt durchschlüpfen.

Durch Begrenzung der App-Registrierungsrechte auf eine ausgewählte Gruppe verantwortlicher Benutzer können Organisationen:

• Sicherheitsrisiken reduzieren
• Unnötige Komplexität eliminieren
• Eine engere Kontrolle darüber behalten, wie Apps sich in Microsoft 365 integrieren

Fazit: Kontrolle über Anmeldeinformationen, Berechtigungen und App-Erstellung zurückbringen

Missbrauch von Anmeldeinformationen, übermässig berechtigte Apps und unkontrollierte Registrierungen schaffen nicht nur technische Schulden, sie untergraben still und leise das Vertrauen in dein Identity-Governance-Modell.

In diesem Beitrag haben wir drei wesentliche Praktiken untersucht, um dieses Modell zu stärken:

• Sichere Anmeldeinformationshandhabung
• Berechtigungen nach Bedarf festlegen
• Kontrollieren, wer Anwendungen registrieren kann

Wenn sie gut implementiert sind, reduzieren diese Kontrollen das Risiko von Fehlkonfigurationen, überexponierten Daten und identitätsbezogenen Vorfällen.

EasyLife 365 Identity unterstützt diese Bemühungen, indem es dir die Tools gibt, um ablaufende Anmeldeinformationen zu erkennen, Berechtigungswildwuchs zu identifizieren und App-Eigentümerschaft von Tag eins an durchzusetzen. Es hilft, Best Practices in wiederholbare Prozesse umzuwandeln, die in die Art und Weise integriert sind, wie deine Teams bereits arbeiten.

In Teil 4 schliessen wir die Serie ab, indem wir uns auf Bereinigung und kontinuierliche Verbesserung konzentrieren. Du wirst lernen, wie du App-Registrierungen regelmässig überprüfst, Registrierungsgrenzen mit App-Rollen definierst und ein gesundes Anwendungsverzeichnis im Laufe der Zeit pflegst.