Planen einer Microsoft Entra Verified ID-Überprüfungslösung

Mit dem Dienst „Microsoft Entra Verified ID“ (Microsoft Entra VC) von Microsoft können Sie dem Nachweis der Benutzeridentität vertrauen, ohne Ihre Vertrauensstellunggrenze zu erweitern. Mit Microsoft Entra VC erstellen Sie Konten oder stellen einen Verbund mit einem anderen Identitätsanbieter her. Wenn eine Lösung mithilfe von Nachweisen einen Überprüfungsaustausch implementiert, ermöglicht dies Anwendungen, Anmeldeinformationen anzufordern, die nicht an eine bestimmte Domäne gebunden sind. Dieser Ansatz erleichtert das Anfordern und Überprüfen von Anmeldeinformationen im großen Stil.

Es wird empfohlen, sich die Übersicht über die Microsoft Entra Verified ID-Infrastruktur anzusehen, sofern noch nicht geschehen. Darüber hinaus wird der Artikel Planen einer Microsoft Entra Verified ID-Ausstellungslösung (Vorschau) empfohlen.

Umfang der Leitfäden

Dieser Inhalt behandelt die technischen Aspekte der Planung einer Lösung zur Überprüfung von Nachweisen, die Microsoft-Produkte und -Dienste verwendet. Die Lösung verfügt über eine Schnittstelle zu einem Vertrauenssystem, in dem derzeit DID Web unterstützt wird. DID Web ist eine zentrale Public Key-Infrastruktur.

Unterstützende Technologien, die nicht spezifisch für Überprüfungslösungen sind, gehen über den Umfang dieses Leitfadens hinaus. Websites werden beispielsweise in einer Lösung zur Überprüfung von Nachweisen verwendet, aber die Planung einer Websitebereitstellung wird nicht ausführlich behandelt.

Beim Planen Ihrer Überprüfungslösung müssen Sie berücksichtigen, welche Geschäftsfunktion hinzugefügt oder geändert wird. Sie müssen auch überlegen, welche IT-Funktionen wiederverwendet werden können, und welche Funktionen zum Erstellen der Lösung hinzugefügt werden müssen. Berücksichtigen Sie auch, welche Schulungen für die am Geschäftsprozess beteiligten Personen sowie für die Personen erforderlich sind, die die Endbenutzer und Mitarbeiter der Lösung unterstützen. Diese Artikel werden hier nicht behandelt. Wir empfehlen die Lektüre von Microsoft Azure Well-Architected Framework, um Informationen zu diesen Artikeln zu erhalten.

Komponenten der Lösung

Im Rahmen Ihrer Planung für eine Überprüfungslösung müssen Sie die Interaktionen zwischen Überprüfer, Antragsteller und Aussteller aktivieren. In diesem Artikel werden die Begriffe vertrauende Partei und Überprüfer synonym verwendet. Das folgende Diagramm zeigt die Komponenten Ihrer Überprüfungsarchitektur.

Der Dienst Microsoft Entra Verified ID

Im Kontext einer Prüflösung ist der Microsoft Entra Verified ID-Dienst die Schnittstelle zwischen den Microsoft-Komponenten der Lösung und dem Vertrauenssystem. Der Dienst stellt Key Vault den Schlüsselsatz bereit und gibt den dezentralisierten Bezeichner (DID) an.

Microsoft Entra-Mandant

Der Dienst erfordert einen Microsoft Entra-Mandanten, der eine Steuerungsebene für die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) für die Azure-Ressourcen bereitstellt, die Teil der Lösung sind. Jeder Microsoft Entra-Mandant verwendet den mehrinstanzenfähigen Microsoft Entra Verified ID-Dienst. Es wird ein einzelnes DID-Dokument ausgestellt, das den Prüfer darstellt. Wenn Ihr Überprüfungsdienst von mehreren vertrauenden Seiten verwendet wird, verwenden alle denselben Überprüfer-DID. Der Überprüfer-DID stellt Zeiger auf den öffentlichen Schlüssel bereit, mit denen Antragsteller und Aussteller Nachrichten überprüfen können, die von der vertrauenden Partei stammen.

Azure Key Vault

Der Dienst „Azure Key Vault“ speichert Ihre Prüfschlüssel, die generiert werden, wenn Sie den Microsoft Entra Verified ID-Ausstellungsdienst aktivieren. Die Schlüssel werden verwendet, um Nachrichtensicherheit zu gewährleisten. Jeder Überprüfer verfügt über einen einzelnen Schlüsselsatz, der zum Signieren, Aktualisieren und Wiederherstellen von Nachweisen verwendet wird. Dieser Schlüsselsatz wird jedes Mal verwendet, wenn Sie eine Überprüfungsanforderung bedienen. Der Microsoft-Schlüsselsatz verwendet derzeit ECC (Elliptic Curve Cryptography) SECP256k1. Wir untersuchen andere kryptografische Signaturschemas, die von der umfassenderen DID-Community übernommen werden.

Anforderungsdienst-API

Anwendungsprogrammierschnittstellen (APIs) bieten Entwicklern eine Methode zum Abstrahieren von Interaktionen zwischen Komponenten der Lösung, um Überprüfungsvorgänge auszuführen.

Vertrauenssystem

Microsoft Entra Verified ID unterstützt derzeit DID Web als Vertrauenssystem, wobei das DID-Dokument auf dem Webserver des Ausstellers gehostet wird.

Microsoft Authenticator-Anwendung

Microsoft Authenticator ist die mobile Anwendung. Der Authenticator orchestriert die Interaktionen zwischen Benutzer*innen, dem Dienst Microsoft Entra Verified ID und dem Vertrag, der zum Ausstellen von Nachweisen verwendet wird. Sie fungiert als digitales Wallet, in dem der Besitzer des Nachweises den Nachweis einschließlich des privaten Schlüssels des Antragstellers des Nachweises speichert. Microsoft Authenticator ist auch der Mechanismus, der verwendet wird, um Nachweise für die Überprüfung vorzulegen.

Vertrauende Seite

Web-Front-End

Das Web-Front-End der vertrauenden Seite verwendet die Anforderungsdienst-API, um Nachweise zu überprüfen, indem Deeplinks oder QR-Codes generiert werden, die vom Wallet des Antragstellers verwendet werden. Je nach Szenario kann das Front-End eine öffentlich zugängliche oder eine interne Website sein, um Endbenutzererfahrungen zu ermöglichen, die eine Überprüfung erfordern. Die Endpunkte, auf die das Wallet zutritt, müssen jedoch öffentlich zugänglich sein. Insbesondere wird die Umleitung an das Wallet mit bestimmten Anforderungsparametern kontrolliert.

Geschäftslogik

Sie können neue Logik erstellen oder vorhandene Logik verwenden, die spezifisch für die vertrauende Partei ist, und diese Logik mit der Präsentation von Nachweisen erweitern.

Szenariospezifische Entwürfe

Im Folgenden finden Sie Beispiele für Entwürfe für bestimmte Anwendungsfälle. Das erste Beispiel zeigt das Onboarding von Konten, um Zeit, Kosten und Risiken im Zusammenhang mit dem Onboarding neuer Mitarbeiter zu reduzieren. Die zweite Beispiel veranschaulicht die Kontowiederherstellung, die es einem Endbenutzer ermöglicht, sein Konto mithilfe eines Self-Service-Mechanismus wiederherzustellen oder zu entsperren. Die dritte ist Beispiel beschreibt den Zugriff auf hochwertige Anwendungen und Ressourcen, insbesondere für Business-to-Business-Anwendungsfälle, in denen Personen, die für andere Unternehmen arbeiten, Zugriff erteilt wird.

Kontenonboarding

Nachweise können verwendet werden, um ein schnelleres Onboarding zu ermöglichen, indem sie einige Benutzerinteraktionen ersetzen. Nachweise können verwendet werden, um Mitarbeitern, Studenten, Bürgern oder anderen Personen per Onboarding den Zugriff auf Dienste zu ermöglichen. Anstatt dass ein Mitarbeiter beispielsweise zu einer Zentrale wechseln muss, um einen Mitarbeiterbadge zu aktivieren, kann er seine Identität mithilfe eines Nachweises überprüfen lassen, um einen Badge zu aktivieren, der remote an ihn übermittelt wird. Anstatt einem Bürger einen Code zuzusenden, den er einlösen muss, um auf Behördendienste zu zugreifen, kann er mithilfe eines Nachweises seine Identität nachweisen und Zugriff erhalten.

Andere Elemente

Onboardingportal: Ein Web-Front-End, das die Aufrufe der Anforderungsdienst-API zur Präsentation und Validierung von Nachweisen sowie die Logik für das Onboarding von Konten orchestriert.

Benutzerdefinierte Logik/Workflows: Spezielle Logik mit organisationsspezifischen Schritten vor und nach dem Aktualisieren des Benutzerkontos. Beispiele hierfür sind Genehmigungsworkflows, zusätzliche Überprüfungen, Protokollierung, Benachrichtigungen usw.

Zielidentitätssysteme: Organisationsspezifische Identitätsrepositorys, mit denen das Onboardingportal beim Onboarding von Antragstellern interagieren muss. Die zu integrierenden Systeme werden basierend auf den Arten von Identitäten bestimmt, die Sie mit der Nachweisüberprüfung integrieren möchten. Häufige Szenarien zur Identitätsüberprüfung für das Onboarding sind:

• Externe Identitäten, die Microsoft Entra ID mithilfe von APIs integriert, um B2B-Einladungen (Business-to-Business) oder Berechtigungsverwaltungszuweisungen an Pakete ausstellen zu können.

• Mitarbeiteridentitäten, deren Onboarding in zentralisierten Identitätssystemen bereits über Personalsysteme erfolgt ist. In diesem Fall kann die Identitätsüberprüfung als Teil vorhandener Phasen von Personalworkflows integriert werden.

Entwurfsaspekte

• Aussteller: Das Konto-Onboarding ist eine gute Wahl für einen externen Identitätsnachweisdienst als Aussteller der Nachweise. Beispiele für Überprüfungen für das Onboarding sind: Livetest, Überprüfung durch von der Regierung ausgestellte Dokumente, Nachweis von Adresse oder Telefonnummer usw.

• Speichern von Nachweisattributen: Speichern Sie nach Möglichkeit keine Attribute von Nachweisen in Ihrem App-spezifischen Speicher. Seien Sie besonders vorsichtig mit personenbezogenen Daten. Wenn diese Informationen für bestimmte Flows in Ihren Anwendungen erforderlich sind, sollten Sie nach dem Nachweis bitten, um die Ansprüche bei Bedarf abzurufen.

• Korrelation von Nachweisattributen mit Back-End-Systemen Richten Sie beim Definieren der Attribute des Nachweises mit dem Aussteller einen Mechanismus ein, um Informationen im Back-End-System zu korrelieren, nachdem der Benutzer den Nachweis präsentiert hat. Der Mechanismus verwendet in der Regel einen zeitgebundenen, eindeutigen Bezeichner im Kontext Ihrer vertrauenden Seite in Kombination mit den empfangenen Ansprüchen. Einige Beispiele:

  • Neuer Mitarbeiter: Wenn der Personalworkflow den Punkt erreicht, an dem Identitätsnachweise erforderlich sind, kann die vertrauende Seite einen Link mit einem zeitgebundenen eindeutigen Bezeichner generieren. Die vertrauende Seite sendet ihn dann an die E-Mail-Adresse des Kandidaten im Personalsystem. Dieser eindeutige Bezeichner sollte ausreichen, um Informationen wie Vorname, Nachname aus der Nachweis-Überprüfungsanforderung mit dem Personaldatensatz oder den zugrunde liegenden Daten zu korrelieren. Die Attribute im Nachweis können verwendet werden, um Benutzerattribute im Personalsystem zu vervollständigen oder die Genauigkeit der Benutzerattribute über den Mitarbeiter zu überprüfen.

  • Externe Identitäten: Einladung: Wenn ein*e externe*r Benutzer*in zum Zielsystem eingeladen wird, kann der RP einen Link mit einem eindeutigen Bezeichner generieren, der die Einladungstransaktion darstellt. Dieser Link kann an die E-Mail-Adresse von externen Benutzer*innen gesendet werden. Dieser eindeutige Bezeichner sollte ausreichen, um die Nachweis-Überprüfungsanforderung mit dem Einladungsdatensatz oder den zugrunde liegenden Daten zu korrelieren und mit dem Bereitstellungsworkflow fortzufahren. Die Attribute im Nachweis können verwendet werden, um die Attribute externer Benutzer zu überprüfen oder zu vervollständigen.

  • Externe Identitäten – Self-Service: Wenn sich externe Identitäten per Self-Service (z. B. eine B2C-Anwendung) beim Zielsystem registrieren, können die Attribute im Nachweis verwendet werden, um die anfänglichen Attribute des Benutzerkontos aufzufüllen. Anhand der Nachweisattribute kann auch herausgefunden werden, ob ein Profil bereits vorhanden ist.

• Interaktion mit Zielidentitätssystemen: Die Dienst-zu-Dienst-Kommunikation zwischen dem Web-Front-End und Ihren Zielidentitätssystemen muss als stark privilegiertes System geschützt werden, da Konten erstellt werden können. Gewähren Sie dem Web-Front-End die Rollen mit den geringsten Berechtigungen. Beispiele hierfür sind:

  • Um einen neuen Benutzer in Microsoft Entra ID zu erstellen, kann die Website der vertrauenden Seite einen Dienstprinzipal verwenden, dem der MS Graph-Bereich User.ReadWrite.All zum Erstellen von Benutzern und der Bereich UserAuthenticationMethod.ReadWrite.All zum Zurücksetzen der Authentifizierungsmethode gewährt wird.

  • Um Benutzer per B2B-Zusammenarbeit zu Microsoft Entra ID einzuladen, kann die Website der vertrauenden Seite einen Dienstprinzipal verwenden, dem der MS Graph-Bereich User.Invite.All gewährt wird, um Einladungen zu erstellen.

  • Wenn Ihre vertrauende Seite in Azure ausgeführt wird, verwenden Sie verwaltete Identitäten, um Microsoft Graph aufzurufen. Durch die Verwendung von verwalteten Identitäten werden die Risiken im Zusammenhang mit der Verwaltung von Dienstprinzipal-Anmeldeinformationen in Code- oder Konfigurationsdateien beseitigt. Weitere Informationen zu verwalteten Identitäten finden Sie unter Verwaltete Identitäten für Azure-Ressourcen.

Zugriff auf Anwendungen von großem Wert innerhalb von Organisationen

Nachweise können für den Zugriff auf sensible Anwendungen innerhalb der Organisation als weiterer Beweis verwendet werden. Nachweise können beispielsweise auch verwendet werden, um Mitarbeitern den Zugriff auf Branchenanwendungen basierend auf bestimmten Kriterien wie z. B. einer Zertifizierung zu ermöglichen.

Andere Elemente

Web-Front-End der vertrauenden Seite: Dies ist das Web-Front-End der Anwendung, erweitert durch Anforderungsdienst-API-Aufrufe zur Vorlage und Validierung von Nachweisen, basierend auf Ihren Geschäftsanforderungen.

Autorisierungslogik für den Benutzerzugriff: Logikebene in der Anwendung, die den Benutzerzugriff autorisiert. Sie kann erweitert werden, um anhand der Benutzerattribute innerhalb des Nachweises Autorisierungsentscheidungen zu treffen.

Andere Back-End-Dienste und Abhängigkeiten: Stellt den Rest der Anwendungslogik dar. Diese bleibt durch die Einbeziehung der Identitätsnachweise über Nachweise in der Regel unverändert.

Entwurfsaspekte

• Ziel: Das Ziel des Szenarios bestimmt, welche Art von Anmeldeinformationen und Aussteller erforderlich ist. Zu den typischen Szenarien gehören:

  • Autorisierung: In diesem Szenario legt der Benutzer den Nachweis vor, damit eine Autorisierungsentscheidung getroffen werden kann. Nachweise, die den Abschluss eines Trainings oder den Erwerb einer bestimmten Zertifizierung nachweisen, sind für dieses Szenario gut geeignet. Die Nachweisattribute sollten detaillierte Informationen enthalten, die Autorisierungsentscheidungen und die Überwachung ermöglichen. Die VC wird zum Beispiel verwendet, um zu bestätigen, dass die Person geschult ist und auf sensible Finanzanwendungen zugreifen kann. Die App-Logik kann den Abteilungsanspruch auf eine differenzierte Autorisierung überprüfen und die Mitarbeiter-ID zu Überwachungszwecken verwenden.

  • Bestätigung der Identitätsüberprüfung: In diesem Szenario soll bestätigt werden, dass es sich bei der Person, für die das Onboarding ursprünglich erfolgte, tatsächlich um die Person handelt, die versucht, auf die Anwendung von hohem Wert zuzugreifen. Eine Anmeldeinformation eines Identitätsüberprüfungsausstellers wäre gut geeignet. Die Anwendungslogik sollte überprüfen, ob die Attribute aus dem Nachweis mit den Benutzer*innen übereinstimmen, die sich bei der Anwendung angemeldet haben.

• Sperrung überprüfen: Wenn Sie Nachweise für den Zugriff auf vertrauliche Ressourcen verwenden, wird häufig der Status des virtuellen Nachweises beim ursprünglichen Aussteller überprüft und der Zugriff für gesperrte Nachweise verweigert. Stellen Sie bei der Arbeit mit den Ausstellern sicher, dass Sie im Rahmen des Entwurfs Ihres Szenarios explizit die Sperrung erläutern.

• Benutzererfahrung: Wenn Sie Nachweise für den Zugriff auf vertrauliche Ressourcen verwenden, können Sie zwei Muster in Betracht ziehen.

  • Schrittweise Authentifizierung: Benutzer starten die Sitzung mit der Anwendung mit vorhandenen Authentifizierungsmechanismen. Benutzer müssen für bestimmte Vorgänge von hohem Wert innerhalb der Anwendung, z. B. Genehmigungen von Geschäftsworkflows, einen Nachweis präsentieren. Dies ist eine gute Möglichkeit für Szenarien, in denen solche Vorgänge von hohem Wert innerhalb der Anwendungsflüsse leicht zu identifizieren und zu aktualisieren sind.

  • Sitzungseinrichtung: Benutzer müssen einen Nachweis als Teil der Initiierung der Sitzung bei der Anwendung präsentieren. Das Bereitstellen eines VC ist gut geeignet, wenn die Art der gesamten Anwendung einen hohen Wert aufweist.

Zugriff auf Anwendungen außerhalb von Organisationsgrenzen

Nachweise können auch von vertrauenden Parteien verwendet werden, die Zugriff oder Vorteile basierend auf der Mitgliedschaft oder dem Angestelltenverhältnis bei einer anderen Organisation gewähren möchten. Ein E-Commerce-Portal kann beispielsweise Vorteile wie Rabatte für Mitarbeiter eines bestimmten Unternehmens, Studenten einer bestimmten Einrichtung usw. bieten.

Die dezentralisierte Natur von Nachweisen ermöglicht dieses Szenario, ohne Verbundbeziehungen zu erstellen.

Andere Elemente

Web-Front-End der vertrauenden Seite: Dies ist das Web-Front-End der Anwendung, erweitert durch Anforderungsdienst-API-Aufrufe zur Vorlage und Validierung von Nachweisen, basierend auf Ihren Geschäftsanforderungen.

Autorisierungslogik für den Benutzerzugriff: Logikebene in der Anwendung, die den Benutzerzugriff autorisiert. Sie kann erweitert werden, um anhand der Benutzerattribute innerhalb des Nachweises Autorisierungsentscheidungen zu treffen.

Andere Back-End-Dienste und Abhängigkeiten: Stellt den Rest der Anwendungslogik dar. Diese bleibt durch die Einbeziehung der Identitätsnachweise über Nachweise in der Regel unverändert.

Entwurfsaspekte

• Ziel: Das Ziel des Szenarios bestimmt, welche Art von Anmeldeinformationen und Aussteller erforderlich ist. Zu den typischen Szenarien gehören:

  • Authentifizierung: In diesem Szenario muss ein Benutzer im Besitz eines Nachweises sein, um das Arbeitsverhältnis oder die Beziehung zu bestimmten Organisationen nachzuweisen. In diesem Fall sollte die vertrauende Seite so konfiguriert werden, dass sie von den Zielorganisationen ausgestellte Nachweise akzeptiert.

  • Autorisierung: Basierend auf den Anwendungsanforderungen können die Anwendungen die Nachweisattribute für differenzierte Autorisierungsentscheidungen und die Überwachung nutzen. Beispiel: Wenn eine E-Commerce-Website Rabatte für Mitarbeiter*innen der Organisationen an einem bestimmten Standort anbietet, können sie diese Rabattberechtigung anhand des Anspruchs für Länder/Regionen im VC überprüfen (sofern vorhanden).

• Sperrung überprüfen: Wenn Sie Nachweise für den Zugriff auf vertrauliche Ressourcen verwenden, wird häufig der Status des virtuellen Nachweises beim ursprünglichen Aussteller überprüft und der Zugriff für gesperrte Nachweise verweigert. Stellen Sie bei der Arbeit mit den Ausstellern sicher, dass Sie im Rahmen des Entwurfs Ihres Szenarios explizit die Sperrung erläutern.

• Benutzererfahrung: Benutzer können einen Nachweis als Teil der Initiierung der Sitzung bei der Anwendung präsentieren. In der Regel bieten Anwendungen auch eine alternative Methode zum Starten der Sitzung, um Fälle zu unterstützen, in denen Benutzer nicht über Nachweise verfügen.

Kontowiederherstellung

Nachweise können als Ansatz für die Kontowiederherstellung verwendet werden. Wenn ein Benutzer z. B. sein Konto wiederherstellen muss, kann er auf eine Website zugreifen, die erfordert, dass er einen Nachweis vorlegt, und eine Zurücksetzung von Microsoft Entra-Anmeldeinformationen initiieren, indem er MS Graph-APIs aufruft, wie im folgenden Diagramm dargestellt.

Hinweis

Das in diesem Abschnitt beschriebene Szenario bezieht sich zwar speziell auf die Wiederherstellung von Microsoft Entra-Konten, dieser Ansatz kann aber auch zum Wiederherstellen von Konten in anderen Systemen verwendet werden.

Andere Elemente

Kontoportal: Web-Front-End, das die API-Aufrufe für das Vorlegen und Überprüfen des Nachweises orchestriert. Diese Orchestrierung kann Microsoft Graph-Aufrufe zum Wiederherstellen von Konten in Microsoft Entra ID umfassen.

Benutzerdefinierte Logik oder Workflows: Logik mit organisationsspezifischen Schritten vor und nach dem Aktualisieren des Benutzerkontos. Benutzerdefinierte Logik kann Genehmigungsworkflows, weitere Überprüfungen, Protokollierung, Benachrichtigungen usw. umfassen.

Microsoft Graph: Stellt REST-APIs (Representational State Transfer) und Clientbibliotheken für den Zugriff auf zur Kontowiederherstellung verwendeten Microsoft Entra-Daten zur Verfügung.

Microsoft Entra-Unternehmensverzeichnis: Der Microsoft Entra-Mandant, der die Konten enthält, die über das Kontoportal erstellt oder aktualisiert werden.

Überlegungen zum Entwurf

VC-Attributkorrelation mit Microsoft Entra ID: Stellen Sie beim Definieren der Attribute des VC in Zusammenarbeit mit dem Aussteller sicher, dass Sie sich auf Ansprüche einigen, die eine*n Benutzer*in identifizieren. Wenn beispielsweise der Identitätsüberprüfungsanbieter (IdV) die Identität vor dem Onboarding von Mitarbeiter*innen überprüft, stellen Sie sicher, dass der ausgestellte VC Ansprüche enthält, die mit internen Systemen abgeglichen werden können. Solche Ansprüche können Telefonnummern, Adressen oder Geburtsdaten sein. Der RP kann im Rahmen dieses Prozesses nach Informationen fragen, die nicht im VC zu finden sind, wie z. B. die letzten vier Ziffern der US-Sozialversicherungsnummer (SSN).

Rolle von Nachweisen mit vorhandenen Microsoft Entra-Zurücksetzungsfunktionen für Anmeldeinformationen: Microsoft Entra ID verfügt über eine integrierte Self-Service-Funktion zur Kennwortzurücksetzung (Self-Service Password Reset, SSPR). Nachweise können in Fällen, in denen Benutzer nicht mehr auf die SSPR-Methode zugreifen können, verwendet werden, um eine weitere Möglichkeit zur Wiederherstellung bereitzustellen. In Szenarien, in denen Benutzer*innen sowohl ihren Computer als auch ihr Mobiltelefon verloren hat, können Benutzer*innen einen VC von einem Identitätsnachweisaussteller erhalten und vorlegen, um das Konto remote wiederherzustellen.

Auf ähnliche Weise können Sie einen Nachweis verwenden, um einen temporären Zugriffspass zu generieren, mit dem Benutzer*innen ihre MFA-Authentifizierungsmethoden ohne Kennwort zurücksetzen können.

Autorisierung: Erstellen Sie einen Autorisierungsmechanismus, z. B. eine Sicherheitsgruppe, die die vertrauende Seite überprüft, bevor sie mit der Wiederherstellung der Anmeldeinformationen fortfahren kann. Beispielsweise können nur Benutzer in bestimmten Gruppen berechtigt sein, ein Konto mit einem Nachweis wiederherzustellen.

Interaktion mit Microsoft Entra ID: Die Dienst-zu-Dienst-Kommunikation zwischen dem Web-Front-End und Microsoft Entra ID muss als stark privilegiertes System geschützt werden, da die Anmeldeinformationen der Mitarbeiter zurückgesetzt werden können. Gewähren Sie dem Web-Front-End die Rollen mit den geringsten Berechtigungen. Beispiele hierfür sind:

• Gewähren Sie der Website der vertrauenden Seite die Möglichkeit, einen Dienstprinzipal zu verwenden, dem der MS Graph-Bereich UserAuthenticationMethod.ReadWrite.All zum Zurücksetzen von Authentifizierungsmethoden gewährt wurde. Gewähren Sie nicht die Berechtigung User.ReadWrite.All, die das Erstellen und Löschen von Benutzern ermöglicht.

• Wenn Ihre vertrauende Seite in Azure ausgeführt wird, verwenden Sie verwaltete Identitäten, um Microsoft Graph aufzurufen. Durch die Verwendung von verwalteten Identitäten werden die Risiken im Zusammenhang mit der Verwaltung von Dienstprinzipal-Anmeldeinformationen in Code- oder Konfigurationsdateien beseitigt. Weitere Informationen finden Sie unter Verwaltete Identitäten für Azure-Ressourcen.

Planen der Identitätsverwaltung

Im Folgenden finden Sie einige Überlegungen zu IAM bei der Integration von Nachweisen in vertrauende Seiten. Vertrauende Seiten sind in der Regel Anwendungen.

Authentifizierung

• Der Antragsteller eines Nachweises muss ein Mensch sein.

• Ein Mensch hat den VC im Wallet und muss den VC interaktiv vorlegen. Nicht interaktive Flows wie „Im Auftrag von“ werden nicht unterstützt.

Autorisierung

• Eine erfolgreiche Präsentation des Nachweises an sich kann als undifferenziertes Autorisierungsgate betrachtet werden. Die Nachweisattribute können auch für differenzierte Autorisierungsentscheidungen verwendet werden.

• Bestimmen Sie, ob ein abgelaufener Nachweis sich auf Ihre Anwendung auswirkt. Falls ja, überprüfen Sie den Wert des Anspruchs exp (die Ablaufzeit) des Nachweises im Rahmen der Autorisierungsüberprüfungen. Ein Beispiel, bei dem der Ablauf nicht relevant ist, ist die Anforderung, dass ein von der Regierung ausgestelltes Dokument verwendet werden muss, z. B. ein Führerschein, um zu überprüfen, ob ein*e Antragsteller*in älter als 18 ist. Das Geburtsdatum ist gültig, auch wenn der Nachweis abgelaufen ist.

• Bestimmen Sie, ob ein widerrufener Nachweis für Ihre Autorisierungsentscheidung eine Bedeutung hat.

  • Wenn er nicht relevant ist, überspringen Sie den Aufruf der Statusüberprüfungs-API (standardmäßig aktiviert).

  • Wenn er relevant ist, fügen Sie die ordnungsgemäße Behandlung von Ausnahmen in Ihrer Anwendung hinzu.

Benutzerprofile

Sie können Informationen in den dargestellten Nachweisen verwenden, um ein Benutzerprofil zu erstellen. Wenn Sie Attribute nutzen möchten, um ein Profil zu erstellen, beachten Sie Folgendes.

• Wenn der Nachweis ausgegeben wird, enthält er eine Momentaufnahme von Attributen zum Zeitpunkt der Ausstellung. Nachweise können über lange Gültigkeitsdauern verfügen. Sie müssen daher bestimmen, wie alt die Attribute maximal sein dürfen, um sie als Teil des Profils zu verwenden.

• Wenn der Antragsteller zum Starten einer Sitzung mit der vertrauenden Seite jedes Mal einen Nachweis vorlegen werden muss, sollten Sie in Betracht ziehen, die Ausgabe der Nachweis-Präsentation zu verwenden, um ein nicht persistentes Benutzerprofil mit den Attributen zu erstellen. Ein nicht persistentes Benutzerprofil trägt dazu bei, datenschutzbedingte Risiken im Zusammenhang mit dem Speichern von Benutzereigenschaften in ruhenden Daten verringern. Ihre Anwendung muss die Antragstellerattribute möglicherweise lokal speichern. Falls ja, speichern Sie nur die Ansprüche, die Ihre Anwendung benötigt. Speichern Sie nicht den gesamten VC.

• Wenn die Anwendung einen persistenten Benutzerprofilspeicher erfordert:

  • Erwägen Sie, den Anspruch sub als unveränderlichen Bezeichner des Benutzers zu verwenden. Dies ist ein nicht transparentes eindeutiges Attribut, das für ein bestimmtes Paar aus Antragsteller und vertrauender Seite konstant ist.

  • Definieren Sie einen Mechanismus zum Deaktivieren der Bereitstellung des Benutzerprofils aus der Anwendung. Aufgrund des dezentralisierten Charakters des Microsoft Entra Verified ID-Systems gibt es keinen Lebenszyklus für die Bereitstellung von Anwendungsbenutzer*innen.

  • Speichern Sie keine persönlichen Datenansprüche, die im Nachweistoken zurückgegeben werden.

  • Speichern Sie nur Ansprüche, die für die Logik der vertrauenden Seite erforderlich sind.

Leistungsplanung

Wie bei jeder Lösung müssen Sie Aspekte im Hinblick auf die Leistung planen. Zu den Schwerpunktbereichen gehören Latenz, Durchsatz und Skalierbarkeit. In den Anfangsphasen eines Releasezyklus sollte die Leistung kein Problem sein. Wenn die Einführung Ihrer Lösung jedoch dazu führt, dass viele Nachweise überprüft werden, kann die Leistungsplanung zu einem wichtigen Bestandteil Ihrer Lösung werden.

Im Folgenden werden die bei der Leistungsplanung zu berücksichtigenden Bereiche aufgeführt:

• Der Ausstellungsdienst Microsoft Entra Verified ID ist in den Azure-Regionen „Europa, Westen“, „Europa, Norden“, „USA, Westen 2“ und „USA, Westen-Mitte“ bereitgestellt. Um Latenz zu begrenzen, stellen Sie Ihr Front-End (Website) für die Überprüfung und den Schlüsseltresor in der nächstgelegenen Region bereit.

• Auf Durchsatz basierendes Modell:

  • Die Nachweisüberprüfungskapazität unterliegt den Grenzwerten des Azure Key Vault-Diensts.

  • Jede Überprüfung eines Nachweises erfordert einen Schlüsseltresors-Signaturvorgang.

  • Sie können die Drosselung nicht steuern. Es wird jedoch empfohlen, die Anleitung zur Azure Key Vault-Drosselung zu lesen, damit Sie verstehen, wie sich die Drosselung auf die Leistung auswirken kann.

Planen der Zuverlässigkeit

Um eine optimale Planung im Hinblick auf Hochverfügbarkeit und Notfallwiederherstellung zu erzielen, empfehlen wir Folgendes:

• Der Dienst Microsoft Entra Verified ID wird in den Azure-Regionen „Europa, Westen“, „Europa, Norden“, „USA, Westen 2“, „USA, Westen-Mitte“, „Australien“ und „Japan“ bereitgestellt. Erwägen Sie die Bereitstellung Ihrer unterstützenden Webserver und Anwendungen in einer dieser Regionen, insbesondere in den Regionen, von denen Sie erwarten, dass der größte Teil Ihres Überprüfungsdatenverkehrs stammt.

• Überprüfen und integrieren Sie bewährte Methoden aus Azure Key Vault-Verfügbarkeit und -Redundanz bei der Planung Ihrer Verfügbarkeits- und Redundanzziele.

Planen der Sicherheit

Berücksichtigen Sie beim Entwerfen der Sicherheitsaspekte Folgendes:

• Alle vertrauenden Seiten in einem einzelnen Mandanten verfügen über die gleiche Vertrauensgrenze, da sie den gleichen DID verwenden.

• Definieren Sie einen dedizierten Dienstprinzipal für eine Website, die auf den Schlüsseltresor zugreift.

• Nur der Microsoft Entra Verified ID-Dienst und die Websitedienstprinzipale sollten über Berechtigungen verfügen, Key Vault zum Signieren von Nachrichten mit dem privaten Schlüssel zu verwenden.

• Weisen Sie Key Vault keine administrativen Berechtigungen für menschliche Identitäten zu. Weitere Informationen zu bewährten Methoden für Key Vault finden Sie unter Sicherheitsbaseline für Azure Key Vault.

• Unter Schützen von Azure-Umgebungen mit Microsoft Entra ID finden Sie bewährte Methoden für die Verwaltung der unterstützenden Dienste für Ihre Lösung.

• Mindern Sie Spoofingrisiken durch:

  • Implementieren der DNS-Überprüfung, um Kunden bei der Identifizierung des Ausstellerbrandings zu unterstützen.

  • Verwenden von Domänen, die für Endbenutzer von Bedeutung sind.

• Minimieren von Risiken verteilter Denial-of-Service-Angriffe (DDoS) und Azure Key Vault-Ressourcendrosselungsrisiken. Jede Anforderung zur Nachweispräsentation generiert Schlüsseltresor-Signierungsvorgänge, die sich auf Dienstgrenzwerte auswirken. Es wird empfohlen, den Datenverkehr zu schützen, indem Sie vor dem Generieren von Ausstellungsanforderungen eine alternative Authentifizierung oder ein Captcha integrieren.

Planen von Vorgängen

Bei der Planung von Vorgängen empfiehlt es sich, jeden Versuch der Überprüfung von Anmeldeinformationen im Rahmen der Überwachung zu erfassen. Verwenden Sie diese Informationen für die Überwachung und Problembehandlung. Erwägen Sie außerdem, eindeutige Transaktionsbezeichner (IDs) zu generieren, auf die Kunden und Supporttechniker bei Bedarf verweisen können.

Ziehen Sie im Rahmen Ihrer operativen Planung die Überwachung der folgenden Aspekte in Betracht:

• Skalierbarkeit:

  • Überwachen Sie fehlgeschlagene Überprüfungen von Nachweisen als Teil der End-to-End-Sicherheitsmetriken von Anwendungen.

  • Überwachen Sie die End-to-End-Latenz der Überprüfung von Nachweisen.

• Zuverlässigkeit und Abhängigkeiten:

  • Überwachen Sie die zugrunde liegenden Abhängigkeiten, die von der Überprüfungslösung verwendet werden.

  • Folgen Sie Überwachung und Warnungen für Azure Key Vault.

• Sicherheit:

  • Aktivieren Sie die Protokollierung für Azure Key Vault, um Signaturvorgänge nachzuverfolgen sowie Konfigurationsänderungen zu überwachen und entsprechende Warnungen zu generieren. Weitere Informationen finden Sie unter Aktivieren der Azure Key Vault-Protokollierung.

  • Archivieren Sie Protokolle in einem SIEM-System (Security Information & Event Management) wie Microsoft Sentinel zur Langzeitaufbewahrung.

Nächste Schritte

Erfahren Sie mehr über die Architektur von Nachweislösungen.

• Übersicht über Microsoft Entra Verified ID

• Planen einer Microsoft Entra Verified ID-Ausstellungslösung

Implementieren von Nachweisen

• Einführung in microsoft Entra Verified ID

• Erste Schritte mit Nachweisen

Häufig gestellte Fragen (FAQs)