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

Der Microsoft Entra Verified ID (Microsoft Entra VC)-Dienst ermöglicht es Ihnen, Identitätsnachweise der Benutzer zu vertrauen, ohne Ihren Vertrauensbereich zu erweitern. Mit Microsoft Entra VC erstellen Sie Konten oder treten Sie in Partnerschaft mit einem anderen Identitätsanbieter. Wenn eine Lösung einen Überprüfungsaustausch mit überprüfbaren Anmeldeinformationen implementiert, können Anwendungen Anmeldeinformationen anfordern, die nicht an eine bestimmte Domäne gebunden sind. Dieser Ansatz erleichtert das Anfordern und Überprüfen von Zugangsdaten in großem Maßstab.

Falls Sie dies noch nicht getan haben, empfehlen wir Ihnen, die Übersicht über die Microsoft Entra Verified ID-Architekturzu prüfen. Darüber hinaus wird der Artikel Planen einer Microsoft Entra Verified ID-Ausstellungslösung (Vorschau) empfohlen.

Umfang der Leitfäden

Diese Inhalte umfassen die technischen Aspekte der Planung einer überprüfungsfähigen Lösung für die Überprüfung von Anmeldeinformationen mithilfe von Microsoft-Produkten und -Diensten. Die Lösung interagiert mit einem Vertrauenssystem, wo derzeit DID Web unterstützt wird. DID Web ist eine zentralisierte öffentliche Schlüssel-Infrastruktur.

Die Unterstützung von Technologien, die nicht für Überprüfungslösungen spezifisch sind, liegt außerhalb des Anwendungsbereichs. Websites werden beispielsweise in einer Lösung zur Überprüfung von Nachweisen verwendet, aber die Planung einer Websitebereitstellung wird nicht ausführlich behandelt.

Wenn Sie Ihre Überprüfungslösung planen, müssen Sie überlegen, welche Geschäftsfunktion hinzugefügt oder geändert wird. Sie müssen auch berücksichtigen, welche IT-Funktionen wiederverwendet werden können und welche Funktionen zum Erstellen der Lösung hinzugefügt werden müssen. Berücksichtigen Sie außerdem, welche Schulung für die am Geschäftsprozess beteiligten Personen und die Personen erforderlich ist, die die Endbenutzer und Mitarbeiter der Lösung unterstützen. Diese Artikel werden in diesem Inhalt 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 Ihres Plans für eine Verifizierungslösung müssen Sie die Interaktionen zwischen dem Prüfer, dem Subjekt und dem Aussteller aktivieren. In diesem Artikel werden die Begriffe vertrauende Seite und Prüfer austauschbar verwendet. Das folgende Diagramm zeigt die Komponenten Ihrer Überprüfungsarchitektur.

Microsoft Entra Verified ID-Dienst

Im Kontext einer Verifier-Lö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 Identity and Access Management (IAM)-Steuerungsebene 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 Sie über mehrere vertrauende Parteien verfügen, die Ihren Überprüfungsdienst verwenden, verwenden sie alle denselben Prü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 Azure Key Vault-Dienst speichert Ihre Prüfschlüssel, die generiert werden, wenn Sie den Veröffentlichungsdienst "Microsoft Entra Verified ID" aktivieren. Die Schlüssel werden verwendet, um die Nachrichtensicherheit bereitzustellen. Jeder Prüfer verfügt über einen einzelnen Schlüsselsatz, der zum Signieren, Aktualisieren und Wiederherstellen von VCs verwendet wird. Verified ID verwendet diesen Schlüsselsatz jedes Mal, wenn Sie eine Verifizierungsanforderung 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.

Service-API anfordern

Anwendungsprogrammierschnittstellen (Application Programming Interfaces, APIs) bieten Entwicklern eine Methode zum Abstrahieren von Interaktionen zwischen Komponenten der Lösung zum Ausführen von Überprüfungsvorgängen.

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. Authenticator koordiniert die Interaktionen zwischen dem Benutzer, dem Microsoft Entra VC-Dienst und dem Vertrag, der zum Ausgeben von VCs 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 VCs für die Überprüfung vorzulegen.

Vertrauende Seite (RP)

Web-Front-End

Das Web-Front-End der vertrauenden Seite verwendet die Anforderungsdienst-API, um VCs 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 interne Website sein, um Endbenutzeroberflächen zu ermöglichen, die eine Überprüfung erfordern. Die Endpunkte, auf die die Brieftasche zugreift, 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 sind Beispiele für Designs aufgeführt, um bestimmte Anwendungsfälle zu erfüllen. Das erste Beispiel zeigt das Onboarding von Konten, um Zeit, Kosten und Risiken im Zusammenhang mit dem Onboarding neuer Mitarbeiter zu reduzieren. Die zweite ist für die Kontowiederherstellung vorgesehen, mit der ein Endbenutzer sein Konto mithilfe eines Self-Service-Mechanismus wiederherstellen oder entsperren kann. Der dritte Punkt betrifft 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 gewährt wird.

Onboarding von Konten

Überprüfbare Anmeldeinformationen können verwendet werden, um ein schnelleres Onboarding zu ermöglichen, indem einige menschliche Interaktionen ersetzt werden. VCs können verwendet werden, um Mitarbeitern, Studenten, Bürgern oder anderen Personen per Onboarding den Zugriff auf Dienste zu ermöglichen. Zum Beispiel, anstatt dass ein Mitarbeiter in die Zentrale gehen muss, um einen Mitarbeiterausweis zu aktivieren, kann er eine VC verwenden, um seine Identität zu überprüfen und einen Ausweis zu aktivieren, der ihm aus der Ferne zugestellt wird. Anstatt dass ein Bürger einen Code erhält, den er für den Zugriff auf staatliche Dienste einlösen muss, kann er eine VC verwenden, um seine Identität zu beweisen und Zugang zu 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: Spezifische Logik mit organisationsspezifischen Schritten vor und nach der Aktualisierung des Benutzerkontos. Beispiele hierfür sind Genehmigungsworkflows, andere Ü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 VC-Validierung 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 HR-Workflows integriert werden.

Entwurfsüberlegungen

• Aussteller: Das Konto-Onboarding ist eine gute Wahl für einen externen Identitätsnachweisdienst als Aussteller der VCs. 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 VC-Attributen: 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. Das RP sendet es dann an die E-Mail-Adresse des Kandidaten im HR-System. Dieser eindeutige Bezeichner sollte ausreichen, um Informationen wie Vorname, Nachname aus der VC-Überprüfungsanforderung mit dem HR-Datensatz oder den zugrunde liegenden Daten zu korrelieren. Die Attribute im VC können verwendet werden, um Benutzerattribute im HR-System abzuschließen oder um die Genauigkeit von Benutzerattributen über den Mitarbeiter zu überprüfen.

  • Externe Identitäten – Einladung: Wenn ein externer Benutzer zum Zielsystem eingeladen wird, kann das RP einen Link mit einem eindeutigen Bezeichner generieren, der die Einladungstransaktion darstellt. Dieser Link kann an die E-Mail-Adresse des externen Benutzers 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 in der VC können verwendet werden, um die externen Benutzerattribute zu überprüfen oder abzuschließen.

  • 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. Die VC-Attribute können auch verwendet werden, um herauszufinden, ob bereits ein Profil vorhanden ist.

• Interaktion mit Zielidentitätssystemen: Die Dienst-zu-Dienst-Kommunikation zwischen dem Web-Front-End und Ihren Zielidentitätssystemen muss als hoch privilegiertes System gesichert werden, da sie Konten erstellen kann. Gewähren Sie dem Web-Front-End möglichst wenig privilegierte Rollen. Einige Beispiele sind:

  • Um einen neuen Benutzer in Microsoft Entra ID zu erstellen, kann die RP-Website einen Dienstprinzipal verwenden, dem der MS Graph-Scope User.ReadWrite.All zum Erstellen von Benutzern und der Scope UserAuthenticationMethod.ReadWrite.All zum Zurücksetzen ihrer Authentifizierungsmethode zugewiesen wird.

  • Um Benutzer mithilfe der B2B-Zusammenarbeit zu Microsoft Entra ID einzuladen, kann die RP-Website einen Dienstprinzipal verwenden, dem die Berechtigung im MS Graph-Bereich User.Invite.All erteilt wurde, um Einladungen zu erstellen.

  • Wenn Ihr RP 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.

Zugreifen auf hochwertige Anwendungen innerhalb von Organisationen

Nachweisbare Anmeldeinformationen können als anderer Nachweis für den Zugriff auf vertrauliche Anwendungen innerhalb der Organisation verwendet werden. Beispielsweise können VCs auch verwendet werden, um Mitarbeitern Zugriff auf Branchenanwendungen zu gewähren, die auf der Erreichung bestimmter Kriterien, z. B. einer Zertifizierung, basieren.

Andere Elemente

Das Web-Frontend der vertrauenden Partei ist das Web-Frontend der Anwendung, das durch Anforderungsdienst-API-Aufrufe für die Präsentation und Validierung von VCs auf Basis Ihrer geschäftlichen Anforderungen erweitert wird.

Benutzerzugriffsautorisierungslogik ist die Logikebene der Anwendung, die den Benutzerzugriff autorisiert. Es wird erweitert, um die Benutzerattribute innerhalb der VC zu nutzen, um Autorisierungsentscheidungen zu treffen.

Andere Back-End-Dienste und Abhängigkeiten: Stellt die restliche Logik der Anwendung dar, die normalerweise durch die Einbeziehung der Identitätsnachweise über VCs unverändert ist.

Entwurfsüberlegungen

• Ziel: Das Ziel des Szenarios bestimmt, welche Art von Anmeldeinformationen und Aussteller erforderlich ist. Typische Szenarien sind:

  • Autorisierung: In diesem Szenario legt der Benutzer den Nachweis vor, damit eine Autorisierungsentscheidung getroffen werden kann. VCs, die für den Nachweis der Durchführung einer Schulung oder der Durchführung einer bestimmten Zertifizierung entwickelt wurden, eignen sich gut für dieses Szenario. Die Nachweisattribute sollten detaillierte Informationen enthalten, die Autorisierungsentscheidungen und die Überwachung ermöglichen. Beispielsweise wird die VC verwendet, um die Ausbildung der Person zu zertifizieren und den Zugriff auf sensible Finanzanwendungen zu ermöglichen. 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 des VC mit dem Benutzer übereinstimmen, der sich bei der Anwendung angemeldet hat.

• Sperrung überprüfen: Wenn Sie VCs für den Zugriff auf vertrauliche Ressourcen verwenden, wird häufig der Status des virtuellen VCs 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 VCs für den Zugriff auf vertrauliche Ressourcen verwenden, gibt es zwei Muster, die Sie berücksichtigen können.

  • Stärkere Authentifizierung: Benutzer starten die Sitzung mit der Anwendung mit vorhandenen Authentifizierungsmechanismen. Benutzer müssen für bestimmte kritische Vorgänge innerhalb der Anwendung, wie z. B. die Genehmigung von Geschäftsabläufen, eine VC vorlegen. Dies eignet sich gut für Szenarien, in denen solche hochwertigen Vorgänge 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.

Zugreifen auf Anwendungen außerhalb der 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. Beispielsweise kann ein E-Commerce-Portal Vorteile wie Rabatte für Mitarbeiter eines bestimmten Unternehmens, Studenten einer bestimmten Einrichtung usw. bieten.

Die dezentrale Natur überprüfbarer Anmeldeinformationen ermöglicht dieses Szenario, ohne föderale Beziehungen herzustellen.

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 die restliche Logik der Anwendung dar, die normalerweise durch die Einbeziehung der Identitätsnachweise über VCs unverändert ist.

Entwurfsüberlegungen

• Ziel: Das Ziel des Szenarios bestimmt, welche Art von Anmeldeinformationen und Aussteller erforderlich ist. Typische Szenarien sind:

  • Authentifizierung: In diesem Szenario muss ein Benutzer eine VC besitzen, um seine Beschäftigung oder seine/ihre Beziehung zu einer bestimmten Organisation oder Organisationen zu beweisen. In diesem Fall sollte das RP so konfiguriert werden, dass von den Zielorganisationen ausgestellte VCs akzeptiert werden.

  • Autorisierung: Basierend auf den Anwendungsanforderungen können die Anwendungen die Nachweisattribute für differenzierte Autorisierungsentscheidungen und die Überwachung nutzen. Wenn z. B. eine E-Commerce-Website Rabatten für Mitarbeiter der Organisationen an einem bestimmten Standort anbietet, können sie die Berechtigung des Rabatts basierend auf dem Land/der Region-Anspruch im VC (sofern vorhanden) überprüfen.

• Sperrung überprüfen: Wenn Sie VCs für den Zugriff auf vertrauliche Ressourcen verwenden, wird häufig der Status des virtuellen VCs 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

Nachweisbare Anmeldeinformationen können als Ansatz für die Kontowiederherstellung verwendet werden. Wenn ein Benutzer beispielsweise sein Konto wiederherstellen muss, kann er auf eine Website zugreifen, die verlangt, dass er eine VC vorlegt. Er kann eine Microsoft Entra-Anmeldeinformationen-Zurücksetzung einleiten, indem er MS Graph-APIs aufruft, wie im folgenden Diagramm dargestellt.

Anmerkung

Während das szenario, das in diesem Abschnitt beschrieben wird, spezifisch für die Wiederherstellung von Microsoft Entra-Konten ist, kann dieser Ansatz auch zum Wiederherstellen von Konten in anderen Systemen verwendet werden.

Andere Elemente

Kontoportal: Webfrontend, das die API-Aufrufe für die VC-Präsentation und -Validierung koordiniert. Diese Orchestrierung kann Microsoft Graph-Aufrufe zum Wiederherstellen von Konten in der Microsoft Entra-ID enthalten.

Benutzerdefinierte Logik oder Workflows: Logik mit organisationsspezifischen Schritten vor und nach dem Aktualisieren des Benutzerkontos. Benutzerdefinierte Logik kann Genehmigungsprozesse, andere Validierungen, Protokollierung, Benachrichtigungen usw. umfassen.

Microsoft Graph: Stellt REST-APIs (Representational State Transfer) und Clientbibliotheken bereit, um auf die Microsoft Entra-Daten zuzugreifen, die für die Kontowiederherstellung verwendet werden.

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

Entwurfsüberlegungen

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 Mitarbeitern überprüft, stellen Sie sicher, dass die ausgestellte VC Behauptungen enthält, die mit den internen Systemen abgeglichen werden können. Solche Ansprüche können eine Telefonnummer, Adresse oder Geburtsdatum 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 VCs mit vorhandenen Funktionen zum Zurücksetzen von Anmeldeinformationen von Microsoft Entra: Microsoft Entra ID verfügt über eine integrierte Self-Service-Kennwortzurücksetzungsfunktion (SSPR). Prüfbare Anmeldeinformationen können verwendet werden, um eine weitere Möglichkeit zum Wiederherstellen in Fällen bereitzustellen, in denen Benutzer keinen Zugriff auf die SSPR-Methode haben oder die Kontrolle verloren haben. In Szenarien, in denen der Benutzer sowohl den Computer als auch das Mobilgerät verloren hat, kann er eine VC von einem Identitätsnachweisherausgeber erneut abrufen und diese vorlegen, um sein Konto aus der Ferne wiederherzustellen.

Ebenso können Sie eine VC verwenden, um ein temporäres Zugriffstoken zu generieren, mit dem Benutzer ihre MFA-Authentifizierungsmethoden zurücksetzen können, ohne ein Kennwort zu benötigen.

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 der Microsoft Entra-ID muss als hoch privilegiertes System gesichert werden, da die Anmeldeinformationen der Mitarbeiter zurückgesetzt werden können. Gewähren Sie dem Web-Front-End die Rollen mit den geringsten Berechtigungen. Einige Beispiele 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 Ihr RP 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.

Plan zur Identitätsverwaltung

Im Folgenden finden Sie einige Überlegungen zu IAM bei der Integration von VCs 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.

Ermächtigung

• 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 das Ablaufdatum nicht relevant ist, ist das Erfordernis eines von der Regierung ausgestellten Dokuments, wie z.B. eines Führerscheins, um zu überprüfen, ob die betreffende Person älter als 18 Jahre ist. Das Geburtsdatum ist gültig, auch wenn der Nachweis abgelaufen ist.

• Ermitteln Sie, ob eine widerrufene VC für Ihre Autorisierungsentscheidung Bedeutung hat.

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

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

Benutzerprofile

Sie können Informationen in präsentierten VCs 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. VCs 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, die Datenschutzrisiken im Zusammenhang mit dem Speichern ruhender Benutzereigenschaften zu verringern. Ihre Anwendung muss möglicherweise die Attribute des Betreffs lokal speichern. Falls ja, speichern Sie nur die Ansprüche, die Ihre Anwendung benötigt. Speichern Sie nicht den gesamten VC.

• Wenn für die Anwendung ein beständiger Benutzerprofilspeicher erforderlich ist:

  • 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.

Planen der Leistung

Wie bei jeder Lösung müssen Sie Aspekte im Hinblick auf die Leistung planen. Fokusbereiche sind Latenz, Durchsatz und Skalierbarkeit. Während der ersten Phasen eines Veröffentlichungszyklus sollte die Leistung kein Problem sein. Wenn die Einführung Ihrer Lösung jedoch dazu führt, dass viele überprüfbare Berechtigungsnachweise verifiziert 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 Microsoft Entra Verified ID-Ausstellungsdienst wird 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.

• Modell basierend auf dem Durchsatz:

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

  • Jede Überprüfung einer VC erfordert einen Key Vault-Signaturvorgang.

  • Sie können die Drosselung nicht steuern. Wir empfehlen jedoch, den Azure Key Vault-Drosselungsleitfaden zu lesen, damit Sie verstehen, wie sich die Drosselung auf die Leistung auswirken kann.

Planen der Zuverlässigkeit

Um eine hohe Verfügbarkeit und Notfallwiederherstellung am besten zu planen, schlagen wir die folgenden Elemente vor:

• Der Microsoft Entra Verified ID-Dienst wird in den Azure-Regionen "Westeuropa", "Nordeuropa", "West-USA 2" und "West Central US", "Australien" und "Japan" bereitgestellt. Erwägen Sie die Bereitstellung Ihrer unterstützenden Webserver und die Unterstützung von Anwendungen in einer dieser Regionen, insbesondere in den Regionen, aus denen sie den größten Teil Ihres Validierungsdatenverkehrs erwarten.

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

Plan für Sicherheit

Beachten Sie bei der Gestaltung im Bereich der Sicherheit Folgendes:

• Alle vertrauenden Seiten (RPs) 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.

• Überprüfen Sie „Sichern von Azure-Umgebungen mit Microsoft Entra ID“, um bewährte Methoden für die Verwaltung der unterstützenden Dienste für Ihre Lösung zu erhalten.

• Mindern Sie Spoofingrisiken durch:

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

  • Verwenden Sie Domänen, die für Endbenutzer aussagekräftig sind.

• Verringern Sie die Risiken für verteilte Denial-of-Service-Angriffe (DDoS) und Key Vault-Ressourceneinschränkungen. 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.

Plan für Operationen

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. Darüber hinaus sollten Sie eindeutige Transaktions-IDs (IDs) generieren, auf die Kunden und Supporttechniker bei Bedarf verweisen können.

Berücksichtigen Sie im Rahmen Ihrer Betriebsplanung die Überwachung des Folgenden:

• Für 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.

• Für 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.

• Für Sicherheit:

  • Aktivieren Sie die Protokollierung für Key Vault zum Nachverfolgen von Signaturvorgängen und zum Überwachen und Benachrichtigen von Konfigurationsänderungen. 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 VC-Lösungen

• Übersicht über Microsoft Entra Verified ID

• Planen einer Microsoft Entra Verified ID-Ausstellungslösung

Umsetzung verifizierbarer Berechtigungsnachweise

• Einführung in Microsoft Entra Verified ID

• Erste Schritte mit Nachweisen

häufig gestellte Fragen