Bewährte Methoden für die Sicherheit von Anwendungseigenschaften in Microsoft Entra-ID

Die Sicherheit ist ein wichtiges Konzept bei der Registrierung einer Anwendung in Microsoft Entra ID und ist ein entscheidender Teil der geschäftlichen Verwendung im Unternehmen. Jede Fehlkonfiguration einer Anwendung kann zu Downtime oder Gefährdung führen. Je nach den zu einer Anwendung hinzugefügten Berechtigungen kann es zu organisationsweiten Auswirkungen kommen.

Da sichere Anwendungen für die Organisation unerlässlich sind, können sich alle Downtimes aufgrund von Sicherheitsproblemen auf das Unternehmen oder einen kritischen Dienst auswirken, von dem das Unternehmen abhängt. Es ist also wichtig, Zeit und Ressourcen zuzuordnen, um sicherzustellen, dass Anwendungen immer in einem fehlerfreien und sicheren Zustand bleiben. Führen Sie eine regelmäßige Bewertung der Sicherheit und Integrität von Anwendungen durch, ähnlich wie eine Bewertung des Sicherheitsbedrohungsmodells für Code. Einen umfassenderen Überblick über die Sicherheit für Organisationen finden Sie unter Security Development Lifecycle (SDL).

In diesem Artikel werden bewährte Methoden für die Sicherheit für die folgenden Anwendungseigenschaften und Szenarien beschrieben:

• Identitätstyp
• Anmeldeinformationen
• Umleitungs-URIs
• Implizite Flusskonfiguration
• Anwendungs-ID-URI (auch als Bezeichner-URI bezeichnet)
• Zugriffstokenversion
• Anwendungsinstanzsperre
• Anwendungsbesitz

Identitätstyp

Wahrscheinlich erfahren Sie mehr über bewährte Sicherheitsmethoden für Microsoft Entra-Anwendungen – auch als App-Registrierungen oder App-Objekte bezeichnet. Es gibt jedoch einen anderen Identitätstyp, der für den Zugriff auf entrageschützte Ressourcen verwendet werden kann, die als verwaltete Identitäten für Azure-Ressourcen bezeichnet werden.

Von Azure verwaltete Identitäten sind standardmäßig sicher und erfordern wenig bis zu keine fortlaufende Wartung oder mehr Aufwand. Erwägen Sie die Verwendung einer verwalteten Identität anstelle einer Microsoft Entra-Anwendung für Ihre App-Identität, wenn alle folgenden Bedingungen erfüllt sind:

• Der Dienst wird in der Azure-Cloud ausgeführt
• Die App benötigt keinen Anmeldevorgang für Benutzer.
• Die App muss nicht als Ressource in einem Tokenfluss fungieren (ist keine Web-API)
• Die App muss nicht in mehreren Tenants betrieben werden

Der Rest dieses Artikels befasst sich mit bewährten Sicherheitsmethoden für Eigenschaften von Entra-App-Registrierungen.

Anmeldeinformationen (einschließlich Zertifikate und Geheimnisse)

Anmeldeinformationen sind ein wichtiger Bestandteil einer Anwendung, wenn sie als vertraulicher Client verwendet wird. Unter der Seite "Zertifikate und geheime Schlüssel" für die Anwendung im Azure-Portal können Anmeldeinformationen hinzugefügt oder entfernt werden.

Beachten Sie die folgenden Hinweise zum Thema „Zertifikate und Geheimnisse“:

• Verwenden Sie nach Möglichkeit eine verwaltete Identität als Anmeldeinformation. Dies wird dringend empfohlen, da verwaltete Identitäten sowohl die sicherste Option sind als auch keine fortlaufende Anmeldeinformationsverwaltung erfordern. Befolgen Sie diese Anleitung, um eine verwaltete Identität als Anmeldedaten zu konfigurieren. Diese Option kann jedoch nur möglich sein, wenn der Dienst, in dem die App in Azure ausgeführt wird, verwendet wird.
• Wenn der Dienst, in dem die App verwendet wird, nicht auf Azure ausgeführt wird, aber auf einer anderen Plattform ausgeführt wird, die die automatisierte Verwaltung von Anmeldeinformationen bietet, erwägen Sie, eine Identität von dieser Plattform als Anmeldeinformationen zu verwenden. Beispielsweise kann ein GitHub-Aktionsworkflow als Anmeldeinformationen konfiguriert werden, sodass keine Anmeldeinformationen für die GitHub-Aktionspipeline verwaltet und gesichert werden müssen. Verwenden Sie bei diesem Ansatz Vorsicht, und konfigurieren Sie Verbundanmeldeinformationen nur von Plattformen, die Sie vertrauen. Eine App ist nur so sicher wie die Identitätsplattform, die sie als Berechtigungsnachweis konfiguriert hat.
• Wenn die Verwendung einer verwalteten Identität oder eines anderen sicheren externen Identitätsanbieters nicht möglich ist, verwenden Sie Zertifikatanmeldeinformationen. Verwenden Sie keine Kennwortanmeldeinformationen, auch als geheime Schlüssel bezeichnet. Während es praktisch ist, Kennwortgeheimnisse als Anmeldeinformationen zu verwenden, werden Kennwortanmeldeinformationen häufig falsch verwaltet und können leicht kompromittiert werden.
• Wenn ein Zertifikat anstelle einer verwalteten Identität verwendet werden muss, speichern Sie dieses Zertifikat in einem sicheren Schlüsseltresor, z. B. Azure Key Vault.
• Wenn ein Zertifikat anstelle einer verwalteten Identität verwendet werden muss, verwenden Sie ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) anstelle eines selbstsignierten Zertifikats. Konfigurieren Sie eine Richtlinie , um zu erzwingen, dass Zertifikate von vertrauenswürdigen Ausstellern stammen. Wenn die Verwendung einer vertrauenswürdigen Zertifizierungsstelle jedoch nicht möglich ist, sind selbstsignierte Zertifikate trotzdem gegenüber Passwörtern bevorzugt.
• Konfigurieren Sie Anwendungsverwaltungsrichtlinien , um die Verwendung geheimer Schlüssel zu steuern, indem Sie ihre Lebensdauer einschränken oder die Verwendung vollständig blockieren.
• Wenn eine Anwendung nur als öffentlicher oder installierter Client verwendet wird (z. B. mobile oder Desktop-Apps, die auf dem Endbenutzercomputer installiert sind), stellen Sie sicher, dass für das Anwendungsobjekt keine Anmeldeinformationen angegeben sind.
• Überprüfen Sie die in Anwendungen verwendeten Anmeldeinformationen auf Aktualität und deren Ablauf. Nicht verwendete Anmeldeinformationen für eine Anwendung können zu Sicherheitsverletzungen führen. Führen Sie regelmäßig einen Rollover der Anmeldeinformationen durch, und geben Sie sie nicht anwendungsübergreifend frei. Verwenden Sie nicht zu viele Anmeldeinformationen in einer Anwendung.
• Überwachen Sie Ihre Produktionspipelines, um zu verhindern, dass Anmeldeinformationen jeglicher Art in Coderepositorys committet werden. Credential Scanner ist ein Tool zur statischen Analyse, mit dem Sie Anmeldeinformationen (und andere sensible Inhalte) in Quellcode und Build-Ausgaben erkennen können.

Umleitungs-URIs

Die Umleitungs-URIs Ihrer Anwendung müssen immer den aktuellen Stand aufweisen. Unter Authentifizierung für die Anwendung im Azure-Portal muss eine Plattform für die Anwendung ausgewählt werden und dann kann die Eigenschaft Umleitungs-URI definiert werden.

Beachten Sie die folgenden Hinweise für Umleitungs-URIs:

• Erhalten Sie den Besitz aller URIs aufrecht. Ein fehlerhafter Besitz einer der Umleitungs-URIs kann zu einer Kompromittierung der Anwendung führen.
• Stellen Sie sicher, dass alle DNS-Einträge in regelmäßigen Abständen aktualisiert und auf Änderungen überwacht werden.
• Verwenden Sie keine Platzhalter in Antwort-URLs oder unsichere URI-Schemata wie „http“ oder URN.
• Halten Sie die Liste klein. Kürzen Sie alle unnötigen URIs. Wenn möglich, aktualisieren Sie die URLs von HTTP zu HTTPS.

Implizite Flusskonfiguration

Szenarios, die einen impliziten Flow erfordern, können jetzt den Auth-Codeflow verwenden, um das Risiko einer Kompromittierung durch den Missbrauch des impliziten Flows zu verringern. Unter Authentifizierung für die Anwendung im Azure-Portal muss eine Plattform für die Anwendung ausgewählt werden und dann kann die Eigenschaft Zugriffstoken (werden für implizite Flows verwendet) festgelegt werden.

Beachten Sie die folgenden Hinweise zum impliziten Flow:

• Feststellen, ob ein impliziter Flow erforderlich ist. Impliziten Flow nicht verwenden, es sei denn, dies ist explizit erforderlich.
• Wenn die Anwendung so konfiguriert wurde, dass sie Zugriffstoken über den impliziten Flow erhält, diese aber nicht aktiv verwendet, deaktivieren Sie die Einstellung, um sie vor Missbrauch zu schützen.
• Verwenden Sie separate Anwendungen für gültige implizite Flowszenarien.

Anwendungs-ID-URI (auch als Bezeichner-URI bezeichnet)

Die Eigenschaft Anwendungs-ID-URI der Anwendung gibt den weltweit eindeutigen URI an, der zur Identifizierung der Web-API verwendet wird. Es ist das Präfix für den Bereich in Anfragen an Microsoft Entra. Das ist auch der Wert des Anspruchs der Zielgruppe (aud) in v1.0 Zugriffs-Token. Bei Mehrinstanzenanwendungen muss der Wert auch global eindeutig sein. Er wird auch als Identifier URIbezeichnet. Unter Eine API verfügbar machen für die Anwendung im Azure-Portal kann die Eigenschaft Anwendungs-ID-URI definiert werden.

Bewährte Methoden für das Definieren der URI der Anwendungs-ID ändern sich, je nachdem, ob die App v1.0- oder v2.0-Zugriffstoken ausgeben wird. Wenn Sie nicht sicher sind, ob eine App v1.0-Zugriffstoken ausstellt, überprüfen Sie die requestedAccessTokenVersion des -App-Manifests. Ein Wert von null oder 1 gibt an, dass die App v1.0-Zugriffstoken empfängt. Ein Wert von 2 gibt an, dass die App v2.0-Zugriffstoken empfängt.

Für Anwendungen, denen v1.0-Zugriffstoken ausgegeben werden, sollten nur die Standard-URIs verwendet werden. Die Standard-URIs sind api://<appId> und api://<tenantId>/<appId>. – Konfigurieren Sie die nonDefaultUriAddition Einschränkung in Anwendungsverwaltungsrichtlinien , um diese bewährte Methode für zukünftige Updates für Anwendungen in Ihrer Organisation zu erzwingen.

Für Anwendungen, für die v2.0-Zugriffstoken ausgestellt werden, verwenden Sie die folgenden Richtlinien, wenn Sie die App ID URI definieren:

• Die api- oder https URI-Schemas werden empfohlen. Legen Sie die Eigenschaft in den unterstützten Formaten fest, um URI-Konflikte in Ihrer Organisation zu vermeiden. Verwenden Sie keine Platzhalter.
• Verwenden Sie eine überprüfte Domäne Ihrer Organisation.
• Führen Sie ein Inventar der URIs in Ihrer Organisation, um die Sicherheit zu gewährleisten.

Für Anwendungs-IDs auf Basis von API- oder HTTP-Schemas werden die folgenden URI-Formate unterstützt. Ersetzen Sie die Platzhalterwerte anhand der Liste, die im Anschluss an die Tabelle aufgeführt ist.

• <appId> - Die Eigenschaft Anwendungsbezeichner (appId) des Anwendungsobjekts.
• <string> - Der Zeichenfolge-Wert für den Host oder das API Pfad Segment.
• <tenantId> - Eine von Azure generierte GUID, die den Tenant innerhalb von Azure repräsentiert.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, wobei <tenantInitialDomain> der initiale Domänenname ist, den der Ersteller des Tenants bei der Erstellung des Tenants angegeben hat.
• <verifiedCustomDomain> - Eine verifizierte benutzerdefinierte Domäne, die für Ihren Microsoft Entra-Mieter konfiguriert wurde.

Zugriffstokenversion

Dieser Abschnitt gilt nur für Ressourcenanwendungen – d. h. Anwendungen, die als Zielgruppe in Zugriffstoken fungieren. Ressourcenanwendungen sind in der Regel Web-APIs. Wenn eine Anwendung nur als Client fungiert (d. h. token zum Senden an Ressourcen wie Microsoft Graph erwirbt), gilt dieser Abschnitt nicht.

Ressourcenanwendungen, die benutzerdefinierte Bezeichner-URIs konfiguriert haben, sollten das v2.0-Zugriffstokenformat verwenden. Um zu überprüfen, ob eine App v2.0-Zugriffstoken verwenden soll, sehen Sie sich die Eigenschaft auf der identifierUrisManifestseite der App-Registrierungen für die App an.

Wenn Werte dort konfiguriert sind, die nicht im Format api://{appId} oder api://{tenantId}/{appId} vorliegen, dann sollte die App v2.0-Zugriffstokens verwenden.

Um ein Upgrade auf v2.0-Zugriffstoken durchzuführen, stellen Sie zunächst sicher, dass die App v2.0-Tokenansprüche verarbeiten kann. Aktualisieren Sie dann die Version des Zugriffstokens, die der Anwendung mit dem Manifest-Editor zugewiesen wird.

Nachdem die Anwendungskonfiguration für die Verwendung von v2.0-Token aktualisiert wurde, stellen Sie sicher, dass die Logik der Zielgruppenvalidierung der Anwendung dahingehend geändert wird, dass sie nur ihre eigene appId akzeptiert.

Eigenschaften der Anwendungsinstanz sperren

Wenn eine Anwendung einen Dienstprinzipal in einem Mandanten bereitgestellt hat, kann dieser Dienstprinzipal von einem Mandantenadministrator angepasst werden. Dies gilt unabhängig davon, ob es sich bei diesem Mandanten um den Hausmandanten der Anwendung oder um einen ausländischen Mandanten handelt. Diese Anpassungsfähigkeiten können Änderungen zulassen, die der App-Besitzer nicht erwartet hat, was zu Sicherheitsrisiken führt. Beispielsweise können dem Dienstprinzipal Anmeldeinformationen hinzugefügt werden, obwohl Anmeldeinformationen normalerweise dem App-Entwickler und Besitzer gehören und von diesem gesteuert werden sollten.

Um dieses Risiko zu verringern, sollten Anwendungen die App-Instanzsperre konfigurieren. Beim Konfigurieren der App-Instanzsperre sperren Sie immer alle verfügbaren vertraulichen Eigenschaften. Die Konfiguration dieser Eigenschaft ist besonders wichtig für mandantenfähige Anwendungen - d.h. Anwendungen, die in mehreren Mandanten oder Organisationen verwendet werden - kann und sollte aber von allen Anwendungen konfiguriert werden.

Erlaubnisse

Möglicherweise muss Ihrer Anwendung Berechtigungen für den Zugriff auf geschützte Ressourcen oder APIs erteilt werden. Stellen Sie beim Anfordern von Berechtigungen immer Folgendes sicher:

• Befolgen Sie die Grundsätze der geringsten Rechte . Fordern Sie nur die Berechtigung an, die den geringsten Zugriff gewährt, der zum Ausführen der Aktion erforderlich ist, die die App ausführen muss. Verwenden Sie beim Aufrufen von Microsoft Graph die API-Dokumentation , um die geringste Berechtigung für einen bestimmten API-Aufruf zu identifizieren. Überprüfen Sie regelmäßig die Berechtigungen Ihrer App, um zu überprüfen, ob eine weniger privilegierte Option verfügbar ist. Wenn eine App keine Berechtigung mehr benötigt, entfernen Sie sie.
• Verwenden Sie nach Möglichkeit delegierten Zugriff anstelle des reinen App-Zugriffs.
• Überprüfen Sie die Berechtigungs- und Zustimmungsdokumentation , um sicherzustellen, dass Sie die Grundlagen der Berechtigung verstehen.

Konfiguration des App-Besitzes

Besitzer können alle Aspekte einer registrierten Anwendung verwalten. Es ist wichtig, regelmäßig zu überprüfen, wer die Verantwortung für alle Anwendungen in der Organisation trägt. Weitere Informationen finden Sie unter Microsoft Entra-Zugriffsüberprüfungen. Unter Besitzer für die Anwendung im Azure-Portal können die Besitzer der Anwendung verwaltet werden.

Beachten Sie die folgenden Hinweise zur Angabe der Besitzer der Anwendung:

• Für die Anwendung sollte eine minimale Anzahl von Besitzer innerhalb der Organisation festgelegt werden.
• Ein Administrator sollte die Liste der Besitzer alle paar Monate überprüfen, um sicherzustellen, dass die Besitzer immer noch Teil der Organisation sind und immer noch eine Anwendung besitzen sollten.

Entra-Empfehlungen überprüfen

Das Feature Microsoft Entra Empfehlungen hilft Ihnen, den Status Ihres Mieters zu überwachen, damit Sie es nicht tun müssen. Diese Empfehlungen tragen dazu bei, dass Ihr Mandant sicher und fehlerfrei ist, und ermöglichen Ihnen, den größtmöglichen Nutzen aus den in Microsoft Entra ID verfügbaren Features zu ziehen. Überprüfen Sie regelmäßig alle aktiven Microsoft Entra-Empfehlungen, die sich auf App-Eigenschaften oder App-Konfiguration beziehen, um Ihr App-Ökosystem in einem fehlerfreien Zustand zu halten.