Microsoft Entra Application Registrations: Sichere App-Identität für kleine Unternehmen in Berlin
Microsoft Entra Application Registrations — der Mechanismus zur Registrierung von Anwendungen in Ihrem Entra-ID-Mandanten für sichere Authentifizierung und Autorisierung — sind eine grundlegende, aber häufig missverstandene Komponente der Enterprise-Identity-Architektur. Für kleine und mittelständische Unternehmen in Berlin sind Anwendungsregistrierungen relevant, wann immer Sie eine intern entwickelte Anwendung, ein SaaS-Drittanbieterprodukt, eine API oder ein Automatisierungsskript mit Ihrer Entra-ID-Identitätsinfrastruktur integrieren müssen. Das Verständnis der sicheren Erstellung, Konfiguration und Verwaltung von Anwendungsregistrierungen ist für die Aufrechterhaltung der Sicherheitslage Ihrer Cloud-Umgebung unerlässlich, da schlecht konfigurierte App-Registrierungen einen der am häufigsten ausgenutzten Identitätsangriffsvektoren in modernen Cloud-Umgebungen darstellen.
Was Anwendungsregistrierungen sind und warum sie wichtig sind
Wenn Sie eine Anwendung in Entra ID registrieren, erstellen Sie zwei eng verwandte Objekte in Ihrem Mandanten: ein Anwendungsobjekt — die globale Definition der App, die im Mandanten gespeichert ist, in dem sie registriert wurde — und einen Dienstprinzipal — die lokale Instanz der Anwendung in Ihrem spezifischen Mandanten, die die Identität der App repräsentiert und wo Sie Berechtigungen gewähren, Rollen zuweisen und Conditional-Access-Richtlinien anwenden. Der Dienstprinzipal ist das, was Entra ID zur Authentifizierung der Anwendung und zur Auswertung der erlaubten Aktionen verwendet.
Anwendungsregistrierungen ermöglichen zwei grundlegende Authentifizierungsszenarien. Bei delegierten Berechtigungen handelt die Anwendung im Namen eines angemeldeten Benutzers — sie kann tun, was der Benutzer tun darf, aber nicht mehr. Eine Webanwendung, die einem Benutzer seine eigenen Microsoft-365-Daten anzeigt, verwendet delegierte Berechtigungen. Bei Anwendungsberechtigungen — auch App-only-Berechtigungen oder Daemon-Anwendungen genannt — handelt die Anwendung als sich selbst ohne Benutzerkontext. Ein automatisierter Prozess, der Compliance-Berichte generiert oder E-Mail-Warteschlangen verarbeitet, verwendet Anwendungsberechtigungen und authentifiziert sich mit seinen eigenen Anmeldedaten.
Für Berliner KMU umfassen die häufigsten Anwendungsregistrierungsszenarien: Integration intern entwickelter Webanwendungen oder APIs mit Entra ID für Single Sign-On, Verbindung von Automatisierungsskripten oder Workflow-Tools wie Power Automate mit Microsoft-365-APIs, Registrierung von Drittanbieteranwendungen, die kein modernes SSO über den Enterprise-Applications-Katalog unterstützen, und Konfiguration von Dienstkonten für Infrastrukturautomatisierung, die sich bei Azure Resource Manager oder Microsoft Graph ohne interaktive Benutzeraufforderungen authentifizieren müssen.
Authentifizierungsmethoden: Zertifikate vs. Client-Secrets
Anwendungsregistrierungen authentifizieren sich bei Entra ID mit einem von zwei Anmeldedatentypen: Client-Secrets oder Zertifikaten. Client-Secrets sind generierte Zeichenketten — im Wesentlichen Passwörter für die Anwendung — mit einem Ablaufdatum zwischen einem Monat und zwei Jahren. Zertifikate verwenden Public-Key-Kryptographie: Sie laden das öffentliche Zertifikat in die App-Registrierung hoch, und die Anwendung hält den privaten Schlüssel. Die Anwendung beweist ihre Identität, indem sie eine Authentifizierungsanforderung mit dem privaten Schlüssel signiert, den Entra ID gegen das registrierte öffentliche Zertifikat verifiziert.
Zertifikate werden aus Sicherheitsgründen Client-Secrets stark vorgezogen. Client-Secrets sind statische Zeichenketten, die von jedem mit Zugriff auf das System, auf dem die Anwendung läuft, kopiert, geteilt, im Klartext protokolliert oder aus Umgebungsvariablen und Konfigurationsdateien extrahiert werden können. Zertifikate sind wesentlich schwerer zu exfiltrieren, da der private Schlüssel typischerweise in einem geschützten Zertifikatspeicher oder Hardware-Sicherheitsmodul gespeichert wird. Microsofts Sicherheitsleitfaden und die meisten Compliance-Frameworks empfehlen inzwischen explizit Zertifikate gegenüber Client-Secrets für die Anwendungsauthentifizierung.
Für Berliner KMU, die Azure Key Vault nutzen, ist das empfohlene Anmeldedatenverwaltungsmuster, Anwendungszertifikate in Key Vault zu speichern und die Anwendung so zu konfigurieren, dass sie das Zertifikat zur Laufzeit aus Key Vault abruft, anstatt es in Anwendungscode oder Konfigurationsdateien einzubetten. Dieser Ansatz bedeutet, dass das Zertifikatmaterial nie in einer Konfigurationsdatei, Umgebungsvariable oder einem Quellcode-Repository existiert, und Zertifikaterneuerung — Ersetzen eines ablaufenden Zertifikats durch ein neues — erfordert nur die Aktualisierung des Zertifikats in Key Vault ohne Änderungen am Anwendungscode oder erneute Bereitstellung.
API-Berechtigungen und das Prinzip der minimalen Privilegierung
API-Berechtigungen definieren, auf welche Ressourcen und Operationen eine Anwendung zugreifen darf. Das Prinzip der minimalen Privilegierung — nur die für die Funktion der Anwendung erforderlichen Mindestberechtigungen zu gewähren — ist für Anwendungsregistrierungen entscheidend, da übermäßig privilegierte Apps hochwertige Ziele bei identitätsbasierten Angriffen darstellen. Eine Anwendung, die mit Mail.ReadWrite.All und User.ReadWrite.All registriert ist, kann die E-Mails jedes Benutzers im Mandanten lesen und ändern sowie jedes Benutzerkonto modifizieren — Fähigkeiten, die Angreifer bei einer Kompromittierung der Anwendungsanmeldedaten äußerst nützlich finden würden.
Admin-Consent ist für Anwendungsberechtigungen und hochprivilegierte delegierte Berechtigungen erforderlich. Dieses Einwilligungs-Gate verhindert, dass Anwendungen sich selbst auf höhere Berechtigungen eskalieren, und stellt sicher, dass ein Administrator den gewährten Zugriff explizit überprüft und genehmigt hat. Für KMU sollten alle Anwendungsberechtigungsgewährungen von einem sicherheitsbewussten Administrator überprüft werden, bevor die Einwilligung erteilt wird — die Berechtigungsanforderungs-UI zeigt genau an, welcher Zugriff angefordert wird, was gegen das tatsächlich Benötigte validiert werden sollte.
Conditional Access für Anwendungsidentitäten
Entra-ID-Conditional-Access kann auf Anwendungsregistrierungen angewendet werden und erweitert das gleiche Zugriffskontrollframework, das für Benutzeranmeldungen verwendet wird, auf Anwendungsauthentifizierungsflows. Workload-Identity-Conditional-Access — verfügbar in Entra ID P2 — ermöglicht es, zu fordern, dass Anwendungen sich nur von bestimmten IP-Adressbereichen aus authentifizieren, wodurch Anwendungsauthentifizierung von unerwarteten Quell-IPs blockiert wird, selbst wenn die Anmeldedaten der Anwendung gestohlen wurden.
Die PIM-Integration (Privileged Identity Management) ist relevant für Anwendungsregistrierungen, bei denen der Dienstprinzipal hochprivilegierte Azure-RBAC-Rollen innehat. Wenn der Dienstprinzipal einer Anwendung als Eigentümer oder Mitwirkender eines Azure-Abonnements zugewiesen ist, sollten diese Berechtigungen mit der gleichen Sorgfalt verwaltet werden wie privilegierte Benutzerkonten. PIM für Gruppen ermöglicht es, den Dienstprinzipal in eine Entra-Gruppe zu platzieren und eine zeitlich begrenzte Aktivierung für die Gruppenmitgliedschaft zu verlangen, was bedeutet, dass die Anwendung nur in den spezifischen Zeiträumen erhöhten Zugriff hat, in denen ihre erhöhten Berechtigungen explizit aktiviert werden.
Verwaltung von Anwendungsregistrierungen in Ihrem Mandanten
Eine der häufigsten Governance-Lücken in KMU-Entra-ID-Mandanten ist mangelnde Sichtbarkeit und Kontrolle über Anwendungsregistrierungen. Entwickler, IT-Mitarbeiter und sogar Geschäftsbenutzer mit entsprechenden Berechtigungen können Anwendungsregistrierungen erstellen, und im Laufe der Zeit kann ein Mandant Dutzende oder Hunderte von Registrierungen ansammeln — viele davon möglicherweise nicht mehr aktiv genutzt, mit ablaufenden Anmeldedaten, die nie rotiert wurden, oder mit mehr Berechtigungen als sie aktuell benötigen.
Das Entra-ID-Anwendungsregistrierungs-Audit umfasst die Überprüfung mehrerer Dimensionen für jede registrierte Anwendung: Wird sie noch aktiv verwendet? Wer ist Eigentümer und wer ist für ihre Wartung verantwortlich? Welche Berechtigungen hat sie, und sind all diese Berechtigungen noch erforderlich? Wann laufen ihre Anmeldedaten ab, und gibt es einen Rotationsprozess? Ist die Anwendung nur im Mandanten registriert (Einzelmandant) oder können Konten aus anderen Entra-ID-Mandanten sich ebenfalls damit authentifizieren (Mehrmandant)? Mehrmandanten-Registrierung ist eine häufige Fehlkonfiguration — die meisten internen Geschäftsanwendungen sollten Einzelmandanten sein.
Die Beschränkung, wer Anwendungsregistrierungen in Ihrem Mandanten erstellen kann, reduziert die Anhäufung nicht verwalteter Registrierungen. In Entra ID kann die Einstellung „Benutzer können Anwendungen registrieren” — in den Benutzereinstellungen zu finden — auf „Nein” gesetzt werden, was die Erstellung von App-Registrierungen auf Administratoren beschränkt. Für die meisten KMU ohne aktive Softwareentwicklungsteams ist diese Einschränkung angemessen: Sie stellt sicher, dass jede App-Registrierung absichtlich von jemandem mit administrativer Verantwortung für den Mandanten erstellt wird.
Microsoft Entra ID Protection und Entra-ID-Audit-Logs bieten Erkennungsfähigkeiten für kompromittierte Anwendungsanmeldedaten. Anmeldungen von unbekannten Standorten, hochfrequente API-Aufrufe von Dienstprinzipalen zu ungewöhnlichen Zeiten und Authentifizierungen von IP-Adressen, die bekannter bösartiger Infrastruktur zugeordnet sind, werden in ID Protection als Risikoerkennungen angezeigt. Die Weiterleitung dieser Warnungen an Microsoft Sentinel oder Azure Monitor Alerts ermöglicht automatisierte Reaktions-Playbooks zur Sperrung von Anwendungsanmeldedaten bei Erkennung anomaler Aktivitäten. Für Berliner KMU, die Anwendungen mit ihrem Entra-ID-Mandanten aufbauen oder integrieren, schafft die frühzeitige Etablierung klarer Governance-Praktiken rund um Anwendungsregistrierungen eine nachhaltige Grundlage für die Verwaltung von Anwendungsidentitäten.
Weiterführende Artikel
- Microsoft Entra Conditional Access: Workload-Identity-Conditional-Access-Richtlinien können die Anwendungsauthentifizierung auf bestimmte IP-Bereiche beschränken und so den Missbrauch von Anwendungsanmeldedaten von unerwarteten Standorten aus blockieren — eine kritische Verteidigungsschicht für hochprivilegierte Dienstprinzipale
- Microsoft Entra Privileged Identity Management: Dienstprinzipale mit privilegierten Azure-RBAC-Rollen sollten über PIM für Gruppen verwaltet werden — zeitlich begrenzte Aktivierung für privilegierte Gruppenmitgliedschaft schränkt das Zeitfenster ein, in dem eine Anwendung erhöhte Berechtigungen hat, und reduziert den Schaden bei kompromittierten Anwendungsanmeldedaten
- Microsoft Entra ID Protection: ID Protection erkennt anomale Dienstprinzipal-Anmeldemuster, einschließlich Authentifizierungen von bösartigen IP-Adressen oder ungewöhnlichen Geografien — die Weiterleitung dieser Risikoerkennungen an Sentinel ermöglicht automatisierte Anmeldedaten-Sperr-Playbooks
- Azure Key Vault: Die Speicherung von Anwendungszertifikaten und Secrets in Key Vault statt in Konfigurationsdateien eliminiert den häufigsten Anwendungsanmeldedaten-Exfiltrationsvektor — Key-Vault-referenzierte Anmeldedaten werden nie im Anwendungscode exponiert, und Key-Vault-verwaltete Zertifikate handeln die Rotation ohne Neubereitstellung automatisch
