Planen einer Microsoft Entra Verified ID-Ausstellungslösung
Es ist wichtig, Ihre Ausstellungslösung so zu planen, dass Sie nicht nur Anmeldeinformationen/Nachweise ausstellen können, sondern auch einen umfassenden Überblick über die Architektur und die geschäftlichen Auswirkungen Ihrer Lösung haben. Falls noch nicht erfolgt, empfiehlt es sich, sich die Übersicht über die Architektur von Microsoft Entra Verified ID zu lesen, in der Sie grundlegende Informationen finden.
Umfang der Leitfäden
In diesem Artikel werden die technischen Aspekte der Planung einer Lösung für die Ausstellung von Nachweisen beschrieben. Die Microsoft-Lösung für Nachweise folgt den vom World Wide Web Consortium (W3C) entwickelten Standards Verifiable Credentials Data Model 1.0 und Decentralized Identifiers (DIDs) v1.0, sodass die Interoperabilität mit Nicht-Microsoft-Diensten ermöglicht wird. Die Beispiele in diesem Inhalt spiegeln jedoch das Microsoft-Lösungspaket für Nachweise wider.
Außerhalb des Rahmens dieses Inhalts fallen Artikel, in denen unterstützende Technologien behandelt werden, die nicht spezifisch für Ausstellungslösungen sind. So werden beispielsweise Websites in einer Lösung für die Ausstellung von Nachweisen verwendet, aber die Planung einer Websitebereitstellung wird nicht ausführlich behandelt.
Komponenten der Lösung
Als Teil Ihres Plans für eine Ausstellungslösung müssen Sie eine Lösung entwerfen, die Interaktionen zwischen dem Aussteller, dem Benutzer und dem Prüfer ermöglicht. Im folgenden Diagramm sind die Komponenten einer Ausstellungsarchitektur dargestellt.
Architektur der Microsoft-Lösung für die Ausstellung von Nachweisen
Microsoft Entra-Mandant
Eine Voraussetzung für die Ausführung des Diensts Microsoft Entra Verified ID ist, dass er in einem Microsoft Entra-Mandanten gehostet wird. Der Microsoft Entra-Mandant stellt eine Steuerungsebene für die Identitäts- und Zugriffsverwaltung (Identity & Access Management, IAM) für die Azure-Ressourcen bereit, die Teil der Lösung sind.
Jeder Mandant nutzt den mehrinstanzenfähigen Dienst Microsoft Entra Verified ID und verfügt über einen dezentralen Bezeichner (Decentralized Identifier, DID). Der DID ist der Nachweis dafür, dass der Aussteller der Eigentümer der im DID enthaltenen Domäne ist. Der DID wird vom Antragsteller und vom Prüfer zum Überprüfen des Ausstellers verwendet.
Microsoft Azure-Dienste
Der Dienst Azure Key Vault speichert Ihre Ausstellerschlüssel, die generiert werden, wenn Sie den Ausstellungsdienst Microsoft Entra Verified ID initiieren. Die Schlüssel und Metadaten werden verwendet, um Vorgänge zur Verwaltung von Anmeldeinformationen/Nachweisen auszuführen und Nachrichtensicherheit bereitzustellen.
Jeder Aussteller verfügt über einen Schlüsselsatz, der zum Signieren, Aktualisieren und Wiederherstellen verwendet wird. Dieser Schlüsselsatz wird für jede Ausstellung der von Ihnen erstellten Nachweise verwendet.
Der Dienst Microsoft Entra Verified ID wird verwendet, um Metadaten und Definitionen für Nachweise zu speichern, insbesondere die Regeln und Anzeigedefinitionen für Ihre Nachweise.
Anzeigedefinitionen legen fest, wie die Ansprüche im Wallet des Inhabers angezeigt werden und umfassen auch Branding und andere Elemente. Die Anzeigedefinition kann in mehrere Sprachen lokalisiert werden. Weitere Informationen finden Sie unter Gewusst wie: Anpassen Ihrer Nachweise (Vorschau).
Regeln sind ein vom Aussteller definiertes Modell, das die erforderlichen Eingaben für einen Nachweis beschreibt. Regeln legen auch die vertrauenswürdigen Eingabequellen und Zuordnung von Eingabeansprüchen zu Ausgabeansprüchen im Nachweis fest. Je nach der in der Regeldefinition festgelegten Art des Nachweises können die Eingabeansprüche von verschiedenen Anbietern stammen. Eingabeansprüche können von einem OIDC-Identitätsanbieter, von id_token_hint oder selbstbestätigten Ansprüchen während der Ausgabe über die Benutzereingabe im Wallet stammen.
- Eingabe: Dabei handelt es sich um eine Teilmenge des Modells in der Regeldatei für die Clientnutzung. Die Teilmenge muss den Eingabesatz, die Quelle zum Abrufen der Eingaben und den aufzurufenden Endpunkt zum Abrufen eines Nachweises beschreiben.
Der Dienst Microsoft Entra Verified ID
Mit dem Dienst Microsoft Entra Verified ID können Sie Nachweise basierend auf Ihrer Konfiguration ausstellen und widerrufen. Der Dienst:
Stellt den dezentralisierten Bezeichner (DID) bereit. Jeder Aussteller verfügt über einen einzigen DID pro Mandant.
Stellt Schlüsselsätze für Key Vault bereit.
Speichert die Konfigurationsmetadaten, die vom Ausstellungsdienst und Microsoft Authenticator verwendet werden.
Stellt die REST-APIs-Schnittstelle für Aussteller- und Verifizierer-Web-Front-Ends bereit
Vertrauenssystem
Microsoft Entra Verified ID unterstützt derzeit Web als Vertrauenssystem, DID Web, 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.
Ausstellungsgeschäftslogik
Ihre Ausstellungslösung umfasst ein Web-Front-End, über das Benutzer einen Nachweis anfordern, einen Identitätsspeicher und/oder einen anderen Attributspeicher zum Abrufen von Werten für Ansprüche über den Antragsteller und andere Back-End-Dienste.
Ein Web-Front-End übermittelt Ausstellungsanforderungen an das Wallet des Antragstellers, indem Deep-Links oder QR-Codes generiert werden. Je nach Konfiguration des Vertrags sind möglicherweise andere Komponenten erforderlich, um die Anforderungen zum Erstellen eines Nachweises zu erfüllen.
Diese Dienste stellen unterstützende Rollen bereit, die nicht unbedingt in das mit dem Ausstellungsdienst Microsoft Entra Verified ID integriert werden müssen. Diese Ebene umfasst in der Regel Folgendes:
Mit Open ID Connect (OIDC) kompatible Dienste werden zum Abrufen von ID-Token verwendet, die zum Ausstellen des Nachweises erforderlich sind. Vorhandene Identitätssysteme wie Microsoft Entra ID oder Azure AD B2C können den OIDC-kompatiblen Dienst bereitstellen, ebenso wie benutzerdefinierte Lösungen wie Identity Server.
Attributspeicher: Die Attributspeicher können sich außerhalb von Verzeichnisdiensten befinden und stellen Attribute bereit, die zum Ausstellen eines Nachweises erforderlich sind. Beispiel: Ein Studenteninformationssystem kann Ansprüche zu erworbenen Abschlüssen bereitstellen.
Zusätzliche Dienste der mittleren Ebene, die Geschäftsregeln für Suchvorgänge, Überprüfungen, Abrechnungen und andere Laufzeitüberprüfungen und Workflows enthalten, die zum Ausstellen von Anmeldeinformationen/Nachweisen erforderlich sind.
Weitere Informationen zum Einrichten Ihres Web-Front-Ends finden Sie im Tutorial Konfigurieren Sie Ihr Microsoft Entra ID, um überprüfbare Anmeldedaten auszustellen.
Nachweisentwurfsüberlegungen
Der Nachweisentwurf richtet sich nach Ihren spezifischen Anwendungsfällen. Der Anwendungsfall bestimmt Folgendes:
Die Interoperabilitätsanforderungen
Die Art, wie Benutzer*innen ihre Identität nachweisen müssen, um ihren Nachweis zu erhalten
Die in den Anmeldeinformationen/Nachweisen erforderlichen Ansprüche
Ob Anmeldeinformationen/Nachweise jemals widerrufen werden müssen
Anwendungsfälle für Nachweise
Es folgen die gängigsten Anwendungsfälle für Nachweise mit Microsoft Entra Verified ID:
Identitätsüberprüfung: Ein Nachweis wird basierend auf mehreren Kriterien ausgestellt. Zu den Kriterien gehören beispielsweise die Überprüfung der Echtheit von Dokumenten, die von Behörden ausgestellt wurden, wie ein Pass oder ein Führerschein, und die Korrelation der Informationen in diesem Dokument mit anderen Informationen wie:
ein Selfie eines Benutzers
Lebendigkeitsprüfung
Diese Art von Nachweis eignet sich gut für Onboardingszenarien für neue Mitarbeiter, Partner, Dienstanbieter, Studenten und andere Fälle, in denen eine Identitätsüberprüfung von entscheidender Bedeutung ist.
Nachweis der Anstellung/Mitgliedschaft: Ein Nachweis wird ausgestellt, um eine Beziehung zwischen dem Benutzer und einer Einrichtung zu bestätigen. Diese Art von Nachweis eignet sich gut für den Zugriff auf lose gekoppelte Business-to-Business-Anwendungen, z. B. Einzelhändler, die Rabatte für Mitarbeiter oder Studenten anbieten. Ein wesentlicher Wert von Nachweisen ist die Portabilität: Nach der Ausstellung kann der Benutzer den Nachweis in vielen Szenarien verwenden.
Weitere Anwendungsfälle für Nachweise finden Sie unter Verifiable Credentials Use Cases (w3.org).
Interoperabilität von Nachweisen
Untersuchen Sie im Rahmen des Entwurfsprozesses branchenspezifische Schemas, Namespaces und Bezeichner, an denen Sie sich orientieren können, um die Interoperabilität und Nutzung zu maximieren. Beispiele finden Sie auf den Websites Schema.org und DIF – Claims and Credentials Working Group.
Allgemeine Schemas sind ein Bereich, in dem Standards noch weiterentwickelt werden. Ein Beispiel für diese Bemühungen ist die Verifiable Credentials for Education Task Force. Wir empfehlen Ihnen, neue Standards in der Branche Ihrer Organisation zu untersuchen und zu deren Entwicklung beizutragen.
Nachweistyp und -attribute
Nachdem Sie den Anwendungsfall für einen Nachweis bestimmt haben, müssen Sie sich für den Nachweistyp und dessen Attribute entscheiden. Prüfer können die Ansprüche in den von den Benutzern vorgelegten Nachweisen lesen.
Alle Nachweise müssen ihren Typ in ihrer Regeldefinition deklarieren. Der Typ des Nachweises unterscheidet ein Schema für Nachweise von anderen Nachweisen und gewährleistet Interoperabilität zwischen Ausstellern und Prüfern. Zum Angeben des Nachweistyps müssen Sie einen oder mehrere Typen auswählen, die für die jeweiligen Nachweise geeignet sind. Jeder Typ ist eine eindeutige Zeichenfolge. Oft dient ein URI zur Gewährleistung globaler Eindeutigkeit. Der URI muss nicht adressierbar sein. Er wird als Zeichenfolge behandelt. Für einen Diplom-Nachweis der Contoso University können beispielsweise die folgenden Typen deklariert werden:
| Typ | Zweck |
|---|---|
https://schema.org/EducationalCredential |
Deklariert, dass von Contoso University ausgestellte Diplome Attribute enthalten, die mit dem Objekt EducationaCredential von „schema.org“ definiert werden. |
https://schemas.ed.gov/universityDiploma2020 |
Deklariert, dass von Contoso University ausgestellte Diplome Attribute enthalten, die vom US-Bildungsministerium definiert werden. |
https://schemas.contoso.edu/diploma2020 |
Deklariert, dass von der Contoso University ausgestellte Diplome Attribute enthalten, die von der Contoso University definiert werden. |
Zusätzlich zu den branchenspezifischen Standards und Schemas, die für Ihre Szenarien gelten könnten, sollten Sie die folgenden Aspekte berücksichtigen:
Private Informationen minimieren: Erfüllen Sie die Anwendungsfälle unter Angabe der Mindestmenge an privaten Informationen, die erforderlich sind. Beispielsweise kann ein Nachweis, der für E-Commerce-Websites verwendet wird, die Rabatte für Mitarbeiter und Ehemalige bieten, erfüllt werden, indem der Nachweis nur mit den Vor- und Nachnamensansprüchen vorgelegt wird. Zusätzliche Informationen wie Einstellungsdatum, Position oder Abteilung sind nicht erforderlich.
Abstrakte Ansprüche bevorzugen: Jeder Anspruch sollte die Anforderungen erfüllen und gleichzeitig möglichst wenige Details enthalten. Beispielsweise ist ein Anspruch mit dem Namen „Älter als“ mit diskreten Werten wie „13, 21, 60“ abstrakter als ein Geburtsdatumsanspruch.
Widerrufbarkeit einplanen: Wir empfehlen Ihnen, einen Indexanspruch zu definieren, um Mechanismen zum Suchen und Widerrufen von Nachweisen zu ermöglichen. Pro Vertrag kann nur ein Indexanspruch definiert werden. Es ist wichtig zu beachten, dass Werte für indizierte Ansprüche nicht im Back-End gespeichert werden. Es wird nur ein Hash des Anspruchswerts gespeichert. Weitere Informationen finden Sie unter Widerrufen eines ausgestellten Nachweises.
Weitere Überlegungen zu Nachweisattributen finden Sie in der Spezifikation Verifiable Credentials Data Model 1.0 (w3.org).
Planen von Qualitätsattributen
Planen der Leistung
Wie bei jeder Lösung müssen Sie Aspekte im Hinblick auf die Leistung planen. Die wichtigsten Bereiche, auf die Sie sich konzentrieren sollten, sind Latenz und Skalierbarkeit. In den Anfangsphasen eines Releasezyklus sollte die Leistung kein Problem sein. Wenn die Einführung Ihrer Ausstellungslösung jedoch dazu führt, dass viele Nachweise ausgestellt 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“, „Australien“ und „Japan“ bereitgestellt. Wenn sich Ihr Microsoft Entra-Mandant in der EU befindet, wird der Dienst Microsoft Entra Verified ID auch in der EU angeboten.
Um Latenz zu begrenzen, stellen Sie Ihre Front-End-Website für die Ausstellung und den Schlüsseltresor in der oben aufgeführten Region bereit.
Auf Durchsatz basierendes Modell:
Für den Ausstellerdienst gelten die Grenzwerte des Azure Key Vault-Diensts.
Für Azure Key Vault sind drei Signaturvorgänge an jeder Nachweisausstellung beteiligt:
Einer für die Ausstellungsanforderung von der Website
Einer für den erstellten Nachweis
Einer für den Vertragsdownload
Sie können die Drosselung nicht steuern. Wir empfehlen Ihnen jedoch, die Anleitung zur Drosselung von Azure Key Vault zu lesen.
Wenn Sie eine sehr große Anzahl von Nachweisen einführen und integrieren möchten, sollten Sie die Batcherstellung in Betracht ziehen, um sicherzustellen, dass Sie die Grenzwerte nicht überschreiten.
Legen Sie im Rahmen Ihrer Leistungsplanung fest, was überwacht werden soll, um die Leistung der Lösung besser zu verstehen. Berücksichtigen Sie zusätzlich zur Websiteüberwachung auf Anwendungsebene Folgendes, wenn Sie Ihre Strategie zur Überwachung der Nachweisausstellung definieren:
Ziehen Sie in Bezug auf die Skalierbarkeit die Implementierung von Metriken für Folgendes in Betracht:
Definieren Sie die logischen Phasen Ihres Ausstellungsprozesses. Zum Beispiel:
Erste Anforderung
Verwaltung des QR-Codes oder Deep-Links
Attributsuche
Aufrufe an den Ausstellungsdienst Microsoft Entra Verified ID
Ausgestellte Nachweise
Definieren Sie die Metriken basierend auf den Phasen:
Gesamtanzahl der Anforderungen (Menge)
Anforderungen pro Zeiteinheit (Durchsatz)
Zeitaufwand (Latenz)
Überwachen Sie Azure Key Vault gemäß den Anleitungen im folgenden Link:
Überwachen Sie die für Ihre Geschäftslogikebene verwendeten Komponenten.
Planen der Zuverlässigkeit
Zur Planung der Zuverlässigkeit empfehlen wir Folgendes:
Nachdem Sie Ihre Verfügbarkeits- und Redundanzziele definiert haben, lesen Sie die folgenden Leitfäden, um zu verstehen, wie Sie Ihre Ziele erreichen können:
Für die Front-End- und Geschäftsebene kann sich Ihre Lösung mit einer unbegrenzten Anzahl von Möglichkeiten manifestieren. Wie bei jeder Lösung müssen Sie für die von Ihnen identifizierten Abhängigkeiten sicherstellen, dass die Abhängigkeiten resilient sind und überwacht werden.
Wenn der seltene Fall eintritt, dass der Ausstellungsdienst Microsoft Entra Verified ID oder Azure Key Vault-Dienste ausfallen, ist die gesamte Lösung nicht mehr verfügbar.
Planen der Compliance
Ihre Organisation hat möglicherweise spezielle Compliance-Anforderungen in Bezug auf Ihre Branche, die Art der Transaktionen oder das Land/die Region, in der Sie tätig sind.
Datenresidenz: Der Ausstellungsdienst Microsoft Entra Verified ID wird nur einer Teilmenge der Azure-Regionen angeboten. Der Dienst wird nur für Computefunktionen verwendet. Werte von Nachweisen werden nicht in Microsoft-Systemen gespeichert. Im Rahmen des Ausstellungsprozesses werden jedoch personenbezogene Daten gesendet und beim Ausstellen von Nachweisen verwendet. Die Verwendung des Nachweisdiensts sollte keine Auswirkungen auf die Anforderungen an Datenresidenz haben. Wenn Sie im Rahmen der Identitätsüberprüfung persönliche Informationen speichern, sollten diese in einer Art und Weise und in einer Region gespeichert werden, die Ihren Complianceanforderungen entspricht. Azure-bezogene Anleitungen finden Sie auf der Microsoft Trust Center-Website.
Widerrufen von Nachweisen: Legen Sie fest, ob Ihre Organisation Nachweise widerrufen muss. Beispielsweise muss ein Administrator möglicherweise Nachweise widerrufen, wenn ein Mitarbeiter das Unternehmen verlässt. Weitere Informationen finden Sie unter Widerrufen eines ausgestellten Nachweises.
Ablauf der Anmeldeinformationen: Bestimmen Sie den Ablauf Ihrer Anmeldeinformationen. Wenn Sie beispielsweise einen Nachweis als Bestätigung für den Besitz eines Führerscheins ausstellen, kann dieser nach einigen Jahren ablaufen. Andere VCs können eine kürzere Gültigkeit haben, um sicherzustellen, dass Benutzer*innen regelmäßig ihren virtuellen Cluster aktualisieren.
Planen von Vorgängen
Beim Planen von Vorgängen ist es wichtig, dass Sie ein Schema entwickeln, das für die Problembehandlung, Berichterstellung und Unterscheidung verschiedener Kunden verwendet werden kann, die Sie unterstützen. Darüber hinaus muss dieser Prozess definiert werden, wenn das Betriebsteam für die Ausführung des Nachweiswiderrufs zuständig ist. Jeder Schritt des Prozesses sollte korreliert werden, damit Sie bestimmen können, welche Protokolleinträge jeder eindeutigen Ausstellungsanforderung zugeordnet werden können. Für die Überwachung wird empfohlen, jeden Versuch der Ausstellung von Nachweisen einzeln zu erfassen. Dies gilt insbesondere in folgenden Fällen:
Generieren Sie eindeutige Transaktions-IDs, auf die Kunden und Supporttechniker bei Bedarf verweisen können.
Entwickeln Sie einen Mechanismus, um die Protokolle von Azure Key Vault-Transaktionen mit den Transaktions-IDs des Ausstellungsteils der Lösung zu korrelieren.
Wenn Sie Anbieter eines Identitätsüberprüfungsdiensts sind, der Nachweise im Auftrag mehrerer Kunden ausstellt, sollten Sie die Überwachung und Problembehandlung/Risikominimierung nach Kunden- oder Vertrags-ID für die kundenorientierte Berichterstellung und Abrechnung durchführen.
Wenn Sie Anbieter eines Identitätsüberprüfungsdiensts sind, der Nachweise im Auftrag mehrerer Kunden ausstellt, verwenden Sie die Kunden- oder Vertrags-ID für die kundenorientierte Berichterstellung und Abrechnung, Überwachung und Problembehandlung/Risikominimierung.
Plan für die Sicherheit
Im Rahmen Ihrer Entwurfsüberlegungen, die sich auf die Sicherheit konzentrieren, wird Folgendes empfohlen:
Für die Schlüsselverwaltung:
Erstellen Sie einen dedizierten Schlüsseltresor für die Nachweisausstellung. Beschränken Sie die Azure Key Vault-Berechtigungen auf den Ausstellungsdienst Microsoft Entra Verified ID und den Dienstprinzipal der Front-End-Website des Ausstellungsdiensts.
Behandeln Sie Azure Key Vault als System mit hohen Berechtigungen. Azure Key Vault stellt Nachweise für Kunden aus. Wir raten davon ab, menschlichen Identitäten ständige Berechtigungen für den Azure Key Vault-Dienst zuzuweisen. Administratoren sollten nur über Just-in-Time-Zugriff auf Key Vault verfügen. Weitere bewährte Methoden für die Verwendung von Azure Key Vault finden Sie unter Azure-Sicherheitsbaseline für Key Vault.
Für den Dienstprinzipal, der die Front-End-Ausstellungswebsite darstellt:
Definieren Sie einen dedizierten Dienstprinzipal, um den Zugriff auf Azure Key Vault zu autorisieren. Wenn Ihre Website in Azure gehostet wird, empfiehlt es sich, eine verwaltete Azure-Identität zu verwenden.
Behandeln Sie den Dienstprinzipal, der die Website darstellt, und den Benutzer als eine einzige Vertrauensstellungsgrenze. Es ist zwar möglich, mehrere Websites zu erstellen, es gibt jedoch nur einen Schlüsselsatz für die Ausstellungslösung.
Für die Sicherheitsprotokollierung und -überwachung wird Folgendes empfohlen:
Aktivieren Sie die Protokollierung und Warnungen für Azure Key Vault, um Nachweisausstellungsvorgänge, Schlüsselextraktionsversuche und Berechtigungsänderungen nachzuverfolgen und Konfigurationsänderungen zu überwachen und entsprechende Warnungen zu senden. Weitere Informationen finden Sie unter Aktivieren der Protokollierung in Key Vault.
Archivieren Sie Protokolle in einem SIEM-System (Security Information & Event Management) wie Microsoft Sentinel zur Langzeitaufbewahrung.
Minimieren von Spoofingrisiken mithilfe der folgenden Möglichkeiten
DNS-Überprüfung, um Kunden bei der Identifizierung des Ausstellerbrandings zu unterstützen.
Für Endbenutzer sinnvolle/aussagekräftige Domänennamen.
Vertrauenswürdiges Branding, das der Endbenutzer erkennt.
Minimieren Sie Risiken verteilter Denial-of-Service-Angriffe (Distributed Denial of Service, DDoS) und Azure Key Vault-Ressourcenauslastungsrisiken. Jede Anforderung, die eine Nachweisausstellungsanforderung auslöst, generiert Key Vault-Signaturvorgänge, die sich auf Dienstgrenzwerte auswirken. Es wird empfohlen, den Datenverkehr zu schützen, indem Sie vor dem Generieren von Ausstellungsanforderungen eine Authentifizierung oder ein Captcha integrieren.
Informationen zum Verwalten Ihrer Azure-Umgebung finden Sie in den Artikeln zur Microsoft-Benchmark für Cloudsicherheit und zum Schützen von Azure-Umgebungen mit Microsoft Entra ID. Diese Leitfäden enthalten bewährte Methoden für die Verwaltung der zugrunde liegenden Azure-Ressourcen, einschließlich Azure Key Vault, Azure Storage, Websites und anderer Azure-bezogener Dienste und Funktionen.
Weitere Überlegungen
Wenn Sie Ihren POC abschließen, sammeln Sie alle generierten Informationen und Dokumentationen, und erwägen Sie, die Ausstellerkonfiguration zu beenden.
Weitere Informationen zur Implementierung und Verwendung von Azure Key Vault finden Sie unter Bewährte Methoden zum Verwenden von Key Vault. Weitere Informationen dazu, wie Sie Azure-Umgebungen mit Active Directory schützen können, finden Sie unter Schützen von Azure-Umgebungen mit Microsoft Entra ID.
Nächste Schritte
Lesen der Übersicht über die Architektur