Freigeben über

Microsoft Purview-Netzwerkarchitektur und bewährte Methoden

  • Artikel

Microsoft Purview-Datengovernancelösungen sind PaaS-Lösungen (Platform-as-a-Service) für Datengovernance. Microsoft Purview-Konten verfügen über öffentliche Endpunkte, auf die über das Internet zugegriffen werden kann, um eine Verbindung mit dem Dienst herzustellen. Alle Endpunkte werden jedoch durch Azure Active Directory-Anmeldungen (Azure AD) und die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) geschützt.

Hinweis

Diese bewährten Methoden decken die Netzwerkarchitektur für einheitliche Datengovernancelösungen von Microsoft Purview ab. Weitere Informationen zu Microsoft Purview-Risiko- und Compliancelösungen finden Sie hier. Weitere Informationen zu Microsoft Purview im Allgemeinen finden Sie hier.

Für eine zusätzliche Sicherheitsebene können Sie private Endpunkte für Ihr Microsoft Purview-Konto erstellen. Sie erhalten eine private IP-Adresse aus Ihrem virtuellen Netzwerk in Azure an das Microsoft Purview-Konto und dessen verwaltete Ressourcen. Diese Adresse beschränkt den gesamten Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Microsoft Purview-Konto auf eine private Verbindung für die Benutzerinteraktion mit den APIs und das Microsoft Purview-Governanceportal oder für die Überprüfung und Erfassung.

Derzeit bietet die Microsoft Purview-Firewall Zugriffssteuerung für den öffentlichen Endpunkt Ihres Purview-Kontos. Sie können die Firewall verwenden, um den gesamten Zugriff zuzulassen oder den gesamten Zugriff über den öffentlichen Endpunkt zu blockieren, wenn Sie private Endpunkte verwenden. Weitere Informationen finden Sie unter Microsoft Purview-Firewalloptionen.

Basierend auf Ihren Netzwerk-, Konnektivitäts- und Sicherheitsanforderungen können Sie Microsoft Purview-Konten einrichten und verwalten, um auf zugrunde liegende Dienste oder die Erfassung zuzugreifen. Verwenden Sie diesen Leitfaden zu bewährten Methoden, um Ihre Netzwerkumgebung zu definieren und vorzubereiten, damit Sie auf Microsoft Purview zugreifen und Datenquellen aus Ihrem Netzwerk oder Ihrer Cloud überprüfen können.

In diesem Leitfaden werden die folgenden Netzwerkoptionen behandelt:

In diesem Leitfaden werden einige der häufigsten Netzwerkarchitekturszenarien für Microsoft Purview beschrieben. Auch wenn Sie nicht auf diese Szenarien beschränkt sind, sollten Sie die Einschränkungen des Diensts berücksichtigen, wenn Sie Netzwerke für Ihre Microsoft Purview-Konten planen.

Voraussetzungen

Um zu verstehen, welche Netzwerkoption für Ihre Umgebung am besten geeignet ist, sollten Sie zuerst die folgenden Aktionen ausführen:

Option 1: Verwenden öffentlicher Endpunkte

Standardmäßig können Sie Microsoft Purview-Konten über die öffentlichen Endpunkte verwenden, auf die über das Internet zugegriffen werden kann. Lassen Sie öffentliche Netzwerke in Ihrem Microsoft Purview-Konto zu, wenn die folgenden Anforderungen erfüllt sind:

  • Beim Scannen oder Herstellen einer Verbindung mit Microsoft Purview-Endpunkten ist keine private Konnektivität erforderlich.
  • Alle Datenquellen sind nur SaaS-Anwendungen (Software-as-a-Service).
  • Alle Datenquellen verfügen über einen öffentlichen Endpunkt, auf den über das Internet zugegriffen werden kann.
  • Geschäftsbenutzer benötigen Zugriff auf ein Microsoft Purview-Konto und das Microsoft Purview-Governanceportal über das Internet.

Integration Runtime-Optionen

Zum Überprüfen von Datenquellen, während die Microsoft Purview-Kontofirewall so festgelegt ist, dass sie öffentlichen Zugriff zulässt, können Sie sowohl die Azure Integration Runtime als auch eine selbstgehostete Integration Runtime verwenden. Wie Sie sie verwenden, hängt von der Unterstützbarkeit Ihrer Datenquellen ab.

Hier sind einige bewährte Methoden:

  • Sie können die Azure Integration Runtime oder eine selbstgehostete Integration Runtime verwenden, um Azure-Datenquellen wie Azure SQL Database oder Azure Blob Storage zu überprüfen. Es wird jedoch empfohlen, die Azure Integration Runtime nach Möglichkeit zum Überprüfen von Azure-Datenquellen zu verwenden, um Kosten und Verwaltungsaufwand zu reduzieren.

  • Verwenden Sie zum Überprüfen mehrerer Azure-Datenquellen ein öffentliches Netzwerk und die Azure Integration Runtime. Die folgenden Schritte zeigen den Kommunikationsfluss auf hoher Ebene, wenn Sie die Azure Integration Runtime verwenden, um eine Datenquelle in Azure zu überprüfen:

    Screenshot: Verbindungsfluss zwischen Microsoft Purview, der Azure-Runtime und Datenquellen

    1. Eine manuelle oder automatische Überprüfung wird vom Microsoft Purview Data Map über die Azure Integration Runtime initiiert.

    2. Die Azure Integration Runtime stellt eine Verbindung mit der Datenquelle her, um Metadaten zu extrahieren.

    3. Metadaten werden im verwalteten Microsoft Purview-Speicher in die Warteschlange eingereiht und in Azure Blob Storage gespeichert.

    4. Metadaten werden an den Microsoft Purview Data Map gesendet.

  • Das Überprüfen lokaler und VM-basierter Datenquellen erfordert immer die Verwendung einer selbstgehosteten Integration Runtime. Die Azure Integration Runtime wird für diese Datenquellen nicht unterstützt. Die folgenden Schritte zeigen den Kommunikationsfluss auf hoher Ebene, wenn Sie eine selbstgehostete Integration Runtime verwenden, um eine Datenquelle zu überprüfen. Das erste Diagramm zeigt ein Szenario, in dem sich Ressourcen in Azure oder auf einem virtuellen Computer in Azure befinden. Das zweite Diagramm zeigt ein Szenario mit lokalen Ressourcen. Die Schritte zwischen den beiden sind aus Sicht von Microsoft Purview identisch:

    Screenshot: Verbindungsfluss zwischen Microsoft Purview, einer selbstgehosteten Runtime und Datenquellen.

    Screenshot: Verbindungsfluss zwischen Microsoft Purview, einer lokalen selbstgehosteten Runtime und Datenquellen im lokalen Netzwerk.

    1. Eine manuelle oder automatische Überprüfung wird ausgelöst. Microsoft Purview stellt eine Verbindung mit Azure Key Vault her, um die Anmeldeinformationen für den Zugriff auf eine Datenquelle abzurufen.

    2. Die Überprüfung wird vom Microsoft Purview Data Map über eine selbstgehostete Integration Runtime initiiert.

    3. Der selbstgehostete Integration Runtime-Dienst vom virtuellen Computer oder dem lokalen Computer stellt eine Verbindung mit der Datenquelle her, um Metadaten zu extrahieren.

    4. Metadaten werden im Arbeitsspeicher des Computers für die selbstgehostete Integration Runtime verarbeitet. Metadaten werden im verwalteten Microsoft Purview-Speicher in die Warteschlange eingereiht und dann in Azure Blob Storage gespeichert. Tatsächliche Daten verlassen niemals die Grenze Ihres Netzwerks.

    5. Metadaten werden an den Microsoft Purview Data Map gesendet.

Authentifizierungsoptionen

Wenn Sie eine Datenquelle in Microsoft Purview überprüfen, müssen Sie Anmeldeinformationen angeben. Microsoft Purview kann dann die Metadaten der Ressourcen mithilfe der Azure Integration Runtime in der Zieldatenquelle lesen. Wenn Sie ein öffentliches Netzwerk verwenden, variieren die Authentifizierungsoptionen und -anforderungen basierend auf den folgenden Faktoren:

  • Datenquellentyp. Wenn die Datenquelle beispielsweise Azure SQL-Datenbank ist, müssen Sie eine Anmeldung mit db_datareader Zugriff auf jede Datenbank verwenden. Dies kann eine vom Benutzer verwaltete Identität oder eine verwaltete Microsoft Purview-Identität sein. Alternativ kann es sich um einen Dienstprinzipal in Azure Active Directory handeln, der SQL-Datenbank als db_datareader hinzugefügt wird.

    Wenn die Datenquelle Azure Blob Storage ist, können Sie eine verwaltete Microsoft Purview-Identität oder einen Dienstprinzipal in Azure Active Directory verwenden, der als Blob Storage-Datenleserrolle für das Azure-Speicherkonto hinzugefügt wurde. Oder verwenden Sie den Schlüssel des Speicherkontos.

  • Authentifizierungstyp. Es wird empfohlen, nach Möglichkeit eine verwaltete Microsoft Purview-Identität zum Überprüfen von Azure-Datenquellen zu verwenden, um den Verwaltungsaufwand zu reduzieren. Für alle anderen Authentifizierungstypen müssen Sie Anmeldeinformationen für die Quellauthentifizierung in Microsoft Purview einrichten:

    1. Generieren Eines Geheimnisses in einem Azure-Schlüsseltresor
    2. Registrieren Sie den Schlüsseltresor in Microsoft Purview.
    3. Erstellen Sie in Microsoft Purview mithilfe des im Schlüsseltresor gespeicherten Geheimnisses neue Anmeldeinformationen.

  • Laufzeittyp, der bei der Überprüfung verwendet wird. Derzeit können Sie keine verwaltete Microsoft Purview-Identität mit einer selbstgehosteten Integration Runtime verwenden.

Andere Überlegungen

  • Wenn Sie Datenquellen mithilfe öffentlicher Endpunkte überprüfen möchten, müssen Ihre selbstgehosteten Integration Runtime-VMs über ausgehenden Zugriff auf Datenquellen und Azure-Endpunkte verfügen.

  • Ihre selbstgehosteten Integration Runtime-VMs müssen über ausgehende Verbindungen mit Azure-Endpunkten verfügen.

  • Ihre Azure-Datenquellen müssen öffentlichen Zugriff zulassen. Wenn ein Dienstendpunkt für die Datenquelle aktiviert ist, stellen Sie sicher, dass Sie Azure-Diensten in der Liste der vertrauenswürdigen Dienste den Zugriff auf Ihre Azure-Datenquellen gestatten. Der Dienstendpunkt leitet Datenverkehr aus dem virtuellen Netzwerk über einen optimalen Pfad zu Azure weiter.

Option 2: Verwenden privater Endpunkte

Ähnlich wie bei anderen PaaS-Lösungen unterstützt Microsoft Purview die direkte Bereitstellung in einem virtuellen Netzwerk nicht. Daher können Sie bestimmte Netzwerkfeatures nicht mit den Ressourcen des Angebots verwenden, z. B. Netzwerksicherheitsgruppen, Routingtabellen oder andere netzwerkabhängige Appliances wie Azure Firewall. Stattdessen können Sie private Endpunkte verwenden, die in Ihrem virtuellen Netzwerk aktiviert werden können. Anschließend können Sie den öffentlichen Internetzugriff deaktivieren, um eine sichere Verbindung mit Microsoft Purview herzustellen.

Sie müssen private Endpunkte für Ihr Microsoft Purview-Konto verwenden, wenn Eine der folgenden Anforderungen erfüllt ist:

  • Sie benötigen eine End-to-End-Netzwerkisolation für Microsoft Purview-Konten und -Datenquellen.

  • Sie müssen den öffentlichen Zugriff auf Ihre Microsoft Purview-Konten blockieren.

  • Ihre PaaS-Datenquellen (Platform-as-a-Service) werden mit privaten Endpunkten bereitgestellt, und Sie haben den gesamten Zugriff über den öffentlichen Endpunkt blockiert.

  • Ihre lokalen oder IaaS-Datenquellen (Infrastructure-as-a-Service) können öffentliche Endpunkte nicht erreichen.

Überlegungen zum Entwurf

  • Um eine private und sichere Verbindung mit Ihrem Microsoft Purview-Konto herzustellen, müssen Sie ein Konto und einen privaten Endpunkt im Portal bereitstellen. Diese Bereitstellung ist beispielsweise erforderlich, wenn Sie beabsichtigen, über die API eine Verbindung mit Microsoft Purview herzustellen oder das Microsoft Purview-Governanceportal zu verwenden.

  • Wenn Sie über private Endpunkte eine Verbindung mit dem Microsoft Purview-Governanceportal herstellen müssen, müssen Sie sowohl konto- als auch portal private Endpunkte bereitstellen.

  • Zum Überprüfen von Datenquellen über private Konnektivität müssen Sie mindestens ein Konto und einen privaten Erfassungsendpunkt für Microsoft Purview konfigurieren. Sie müssen Überprüfungen mithilfe einer selbstgehosteten Integration Runtime über eine andere Authentifizierungsmethode als eine verwaltete Microsoft Purview-Identität konfigurieren.

  • Lesen Sie Unterstützungsmatrix für das Überprüfen von Datenquellen über einen privaten Erfassungsendpunkt , bevor Sie Überprüfungen einrichten.

  • Überprüfen Sie die DNS-Anforderungen. Wenn Sie einen benutzerdefinierten DNS-Server in Ihrem Netzwerk verwenden, müssen Clients in der Lage sein, den vollqualifizierten Domänennamen (FQDN) für die Microsoft Purview-Kontoendpunkte in die IP-Adresse des privaten Endpunkts aufzulösen.

  • Verwenden Sie verwaltete VNET-Runtime, um Azure-Datenquellen über private Konnektivität zu überprüfen. Anzeigen unterstützter Regionen. Diese Option kann den Verwaltungsaufwand für die Bereitstellung und Verwaltung selbstgehostete Integration Runtime-Computer reduzieren.

Integration Runtime-Optionen

  • Wenn sich Ihre Datenquellen in Azure befinden, können Sie eine der folgenden Laufzeitoptionen auswählen:

    • Verwaltete VNET-Runtime. Verwenden Sie diese Option, wenn Ihr Microsoft Purview-Konto in einer der unterstützten Regionen bereitgestellt wird und Sie planen, eine der unterstützten Datenquellen zu überprüfen.

    • Selbstgehostete Integration Runtime.

      • Wenn Sie eine selbstgehostete Integration Runtime verwenden, müssen Sie eine selbstgehostete Integration Runtime auf einem virtuellen Windows-Computer einrichten und verwenden, der in demselben virtuellen Netzwerk oder einem virtuellen Netzwerk mit Peering bereitgestellt wird, in dem private Microsoft Purview-Erfassungsendpunkte bereitgestellt werden. Die Azure Integration Runtime funktioniert nicht mit privaten Erfassungsendpunkten.

      • Zum Überprüfen lokaler Datenquellen können Sie auch eine selbstgehostete Integration Runtime entweder auf einem lokalen Windows-Computer oder auf einem virtuellen Computer in einem virtuellen Azure-Netzwerk installieren.

      • Wenn Sie private Endpunkte mit Microsoft Purview verwenden, müssen Sie netzwerkkonnektivität von Datenquellen mit der selbstgehosteten Integrations-VM im virtuellen Azure-Netzwerk zulassen, in dem private Microsoft Purview-Endpunkte bereitgestellt werden.

      • Es wird empfohlen, das automatische Upgrade der selbstgehosteten Integration Runtime zuzulassen. Stellen Sie sicher, dass Sie die erforderlichen Ausgangsregeln in Ihrem virtuellen Azure-Netzwerk oder in Ihrer Unternehmensfirewall öffnen, um automatische Upgrades zu ermöglichen. Weitere Informationen finden Sie unter Netzwerkanforderungen für selbstgehostete Integration Runtime.

Authentifizierungsoptionen

  • Sie können keine verwaltete Microsoft Purview-Identität verwenden, um Datenquellen über private Erfassungsendpunkte zu überprüfen. Verwenden Sie einen Dienstprinzipal, einen Kontoschlüssel oder eine SQL-Authentifizierung basierend auf dem Datenquellentyp.

  • Stellen Sie sicher, dass Ihre Anmeldeinformationen in einem Azure-Schlüsseltresor gespeichert und in Microsoft Purview registriert sind.

  • Sie müssen anmeldeinformationen in Microsoft Purview basierend auf jedem Geheimnis erstellen, das Sie im Azure-Schlüsseltresor erstellen. Sie müssen mindestens Zugriff auf Geheimnisse für Microsoft Purview für die Key Vault-Ressource in Azure zuweisen undauflisten. Andernfalls funktionieren die Anmeldeinformationen nicht im Microsoft Purview-Konto.

Aktuelle Einschränkungen

  • Das Überprüfen mehrerer Azure-Quellen mithilfe des gesamten Abonnements oder der Ressourcengruppe über private Erfassungsendpunkte und eine selbstgehostete Integration Runtime wird nicht unterstützt, wenn Sie private Endpunkte für die Erfassung verwenden. Stattdessen können Sie Datenquellen einzeln registrieren und überprüfen.

  • Informationen zu Einschränkungen im Zusammenhang mit privaten Microsoft Purview-Endpunkten finden Sie unter Bekannte Einschränkungen.

  • Informationen zu Einschränkungen im Zusammenhang mit dem Private Link-Dienst finden Sie unter Azure Private Link Grenzwerte.

Szenarien für private Endpunkte

Einzelnes virtuelles Netzwerk, einzelne Region

In diesem Szenario werden alle Azure-Datenquellen, selbstgehosteten Integration Runtime-VMs und private Microsoft Purview-Endpunkte im selben virtuellen Netzwerk in einem Azure-Abonnement bereitgestellt.

Wenn lokale Datenquellen vorhanden sind, wird die Konnektivität über ein Site-to-Site-VPN oder azure ExpressRoute-Konnektivität mit einem virtuellen Azure-Netzwerk bereitgestellt, in dem private Microsoft Purview-Endpunkte bereitgestellt werden.

Diese Architektur eignet sich hauptsächlich für kleine Organisationen oder für Entwicklungs-, Test- und Proof-of-Concept-Szenarien.

Screenshot: Microsoft Purview mit privaten Endpunkten in einem szenario mit einem einzelnen virtuellen Netzwerk

Einzelne Region, mehrere virtuelle Netzwerke

Um zwei oder mehr virtuelle Netzwerke in Azure miteinander zu verbinden, können Sie peering virtueller Netzwerke verwenden. Der Netzwerkdatenverkehr zwischen virtuellen Netzwerken mit Peering ist privat und wird im Azure-Backbonenetzwerk gespeichert.

Viele Kunden erstellen ihre Netzwerkinfrastruktur in Azure mithilfe der Hub-and-Spoke-Netzwerkarchitektur, wobei:

  • Freigegebene Netzwerkdienste (z. B. virtuelle Netzwerkgeräte, ExpressRoute-/VPN-Gateways oder DNS-Server) werden im virtuellen Hubnetzwerk bereitgestellt.
  • Virtuelle Spoke-Netzwerke nutzen diese freigegebenen Dienste über peering virtueller Netzwerke.

In Hub-and-Spoke-Netzwerkarchitekturen kann das Datengovernanceteam Ihrer organization mit einem Azure-Abonnement bereitgestellt werden, das ein virtuelles Netzwerk (Hub) umfasst. Alle Datendienste können sich in einigen anderen Abonnements befinden, die über ein Peering virtueller Netzwerke oder eine Site-to-Site-VPN-Verbindung mit dem virtuellen Hubnetzwerk verbunden sind.

In einer Hub-and-Spoke-Architektur können Sie Microsoft Purview und eine oder mehrere selbstgehostete Integration Runtime-VMs im Hubabonnement und virtuellen Netzwerk bereitstellen. Sie können Datenquellen aus anderen virtuellen Netzwerken aus mehreren Abonnements in derselben Region registrieren und überprüfen.

Die selbstgehosteten Integration Runtime-VMs können innerhalb desselben virtuellen Azure-Netzwerks oder eines mittels Peering verknüpften virtuellen Netzwerks bereitgestellt werden, in dem das Konto und die privaten Erfassungsendpunkte bereitgestellt werden.

Screenshot: Microsoft Purview mit privaten Endpunkten in einem Szenario mit mehreren virtuellen Netzwerken

Optional können Sie eine weitere selbstgehostete Integration Runtime in den virtuellen Spoke-Netzwerken bereitstellen.

Mehrere Regionen, mehrere virtuelle Netzwerke

Wenn Ihre Datenquellen in einem oder mehreren Azure-Abonnements auf mehrere Azure-Regionen verteilt sind, können Sie dieses Szenario verwenden.

Zur Leistungs- und Kostenoptimierung wird dringend empfohlen, eine oder mehrere selbstgehostete Integration Runtime-VMs in jeder Region bereitzustellen, in der sich Datenquellen befinden.

Screenshot: Microsoft Purview mit privaten Endpunkten in einem Szenario mit mehreren virtuellen Netzwerken und mehreren Regionen

Überprüfen mithilfe der verwalteten VNET-Runtime

Sie können die verwaltete VNET-Runtime verwenden, um Datenquellen in einem privaten Netzwerk zu überprüfen, wenn Ihr Microsoft Purview-Konto in einer der unterstützten Regionen bereitgestellt wird und Sie planen, eine der unterstützten Azure-Datenquellen zu überprüfen.

Die Verwendung der verwalteten VNET-Runtime trägt dazu bei, den Verwaltungsaufwand für die Verwaltung der Laufzeit zu minimieren und die Gesamtüberprüfungsdauer zu reduzieren.

Um Azure-Datenquellen mithilfe der verwalteten VNET-Runtime zu überprüfen, muss ein verwalteter privater Endpunkt in Microsoft Purview Managed Virtual Network bereitgestellt werden, auch wenn die Datenquelle bereits über ein privates Netzwerk in Ihrem Azure-Abonnement verfügt.

Screenshot: Microsoft Purview mit verwaltetem VNET

Wenn Sie lokale Datenquellen oder zusätzliche Datenquellen in Azure überprüfen müssen, die von managed VNet Runtime nicht unterstützt werden, können Sie sowohl verwaltete VNet-Runtime als auch selbstgehostete Integration Runtime bereitstellen.

Screenshot: Microsoft Purview mit verwaltetem VNet und SHIR

Wenn Microsoft Purview in Ihrer primären Region nicht verfügbar ist

Microsoft Purview ist eine Azure Platform-as-a-Service-Lösung. Sie können ein Microsoft Purview-Konto in Ihrem Azure-Abonnement in allen unterstützten Azure-Regionen bereitstellen.

Wenn Microsoft Purview in Ihrer primären Azure-Region nicht verfügbar ist, sollten Sie bei der Auswahl einer sekundären Region zum Bereitstellen Ihres Microsoft Purview-Kontos die folgenden Faktoren berücksichtigen:

  • Überprüfen Sie die Latenz zwischen Ihrer primären Azure-Region, in der Datenquellen bereitgestellt werden, und Ihrer sekundären Azure-Region, in der das Microsoft Purview-Konto bereitgestellt wird. Weitere Informationen finden Sie unter Statistiken zur Roundtriplatenz im Azure-Netzwerk.
  • Überprüfen Sie Ihre Anforderungen an die Datenresidenz. Wenn Sie Datenquellen im Microsoft Purview Data Map überprüfen, werden Informationen zu Ihren Metadaten erfasst und in Ihrer Data Map in der Azure-Region gespeichert, in der Ihr Microsoft Purview-Konto bereitgestellt wird. Weitere Informationen finden Sie unter Wo werden Metadaten gespeichert.
  • Überprüfen Sie Ihre Netzwerk- und Sicherheitsanforderungen, wenn private Netzwerkkonnektivität für den Benutzerzugriff oder die Metadatenerfassung erforderlich ist. Weitere Informationen finden Sie unter Wenn Microsoft Purview in Ihrer primären Region nicht verfügbar ist.

Option 1: Stellen Sie Ihr Microsoft Purview-Konto in einer sekundären Region und alle privaten Endpunkte in der primären Region bereit, in der sich Ihre Azure-Datenquellen befinden. Für dieses Szenario gilt Folgendes:

  • Dies ist die empfohlene Option, wenn Australien, Südosten die primäre Region für alle Ihre Datenquellen ist und Sie alle Netzwerkressourcen in Ihrer primären Region bereitgestellt haben.
  • Stellen Sie ein Microsoft Purview-Konto in Ihrer sekundären Region (z. B. Australien, Osten) bereit.
  • Stellen Sie alle privaten Microsoft Purview-Endpunkte einschließlich Konto, Portal und Erfassung in Ihrer primären Region (z. B. Australien, Südosten) bereit.
  • Stellen Sie alle selbstgehosteten Integration Runtime-VMs von Microsoft Purview in Ihrer primären Region bereit (z. B. Australien, Südosten). Dies trägt dazu bei, den regionsübergreifenden Datenverkehr zu reduzieren, da die Data Map-Überprüfungen in der lokalen Region erfolgen, in der sich Datenquellen befinden und nur Metadaten in Ihrer sekundären Region erfasst werden, in der Ihr Microsoft Purview-Konto bereitgestellt wird.
  • Wenn Sie verwaltete Microsoft Purview-VNETs für die Metadatenerfassung verwenden, werden die verwaltete VNET-Runtime und alle verwalteten privaten Endpunkte automatisch in der Region bereitgestellt, in der Ihre Microsoft Purview bereitgestellt wird (z. B. Australien, Osten).

Option 2: Stellen Sie Ihr Microsoft Purview-Konto in einer sekundären Region und private Endpunkte in den primären und sekundären Regionen bereit. Für dieses Szenario gilt Folgendes:

  • Diese Option wird empfohlen, wenn Datenquellen sowohl in der primären als auch in der sekundären Region vorhanden sind und Benutzer über die primäre Region verbunden sind.
  • Stellen Sie ein Microsoft Purview-Konto in Ihrer sekundären Region (z. B. Australien, Osten) bereit.
  • Stellen Sie den privaten Endpunkt des Microsoft Purview-Governanceportals in der primären Region (z. B. Australien, Südosten) für den Benutzerzugriff auf das Microsoft Purview-Governanceportal bereit.
  • Stellen Sie ein Microsoft Purview-Konto und private Erfassungsendpunkte in Ihrer primären Region (z. B. Australien, Südosten) bereit, um Datenquellen lokal in der primären Region zu überprüfen.
  • Stellen Sie ein Microsoft Purview-Konto und private Erfassungsendpunkte in Ihrer sekundären Region (z. B. Australien, Osten) bereit, um Datenquellen lokal in der sekundären Region zu überprüfen.
  • Stellen Sie selbstgehostete Integration Runtime-VMs von Microsoft Purview sowohl in der primären als auch in der sekundären Region bereit. Dies hilft, den Datenzuordnungsscandatenverkehr in der lokalen Region beizubehalten und nur Metadaten an Microsoft Purview Data Map zu senden, wo in Ihrer sekundären Region (z. B. Australien, Osten) konfiguriert ist.
  • Wenn Sie verwaltete Microsoft Purview-VNETs für die Metadatenerfassung verwenden, werden die verwaltete VNET-Runtime und alle verwalteten privaten Endpunkte automatisch in der Region bereitgestellt, in der Ihre Microsoft Purview bereitgestellt wird (z. B. Australien, Osten).

DNS-Konfiguration mit privaten Endpunkten

Namensauflösung für mehrere Microsoft Purview-Konten

Es wird empfohlen, diese Empfehlungen zu befolgen, wenn Ihr organization mehrere Microsoft Purview-Konten mithilfe privater Endpunkte bereitstellen und verwalten muss:

  1. Stellen Sie mindestens einen privaten Endpunkt für jedes Microsoft Purview-Konto bereit.
  2. Stellen Sie mindestens einen Satz privater Erfassungsendpunkte für jedes Microsoft Purview-Konto bereit.
  3. Stellen Sie einen privaten Portalendpunkt für eines der Microsoft Purview-Konten in Ihren Azure-Umgebungen bereit. Erstellen Sie einen DNS-A-Eintrag für den privaten Endpunkt des Portals , um aufzulösen web.purview.azure.com. Der private Endpunkt des Portals kann von allen Purview-Konten im selben virtuellen Azure-Netzwerk oder virtuellen Netzwerken verwendet werden, die über VNET-Peering verbunden sind.

Screenshot: Behandeln privater Endpunkte und DNS-Einträge für mehrere Microsoft Purview-Konten

Dieses Szenario gilt auch, wenn mehrere Microsoft Purview-Konten über mehrere Abonnements und mehrere VNETs bereitgestellt werden, die über VNET-Peering verbunden sind. Der private Portalendpunkt rendert hauptsächlich statische Ressourcen im Zusammenhang mit dem Microsoft Purview-Governanceportal. Daher ist er unabhängig vom Microsoft Purview-Konto. Daher ist nur ein privater Portalendpunkt erforderlich, um alle Microsoft Purview-Konten in der Azure-Umgebung zu besuchen, wenn VNETs verbunden sind.

Screenshot: Behandeln privater Endpunkte und DNS-Einträge für mehrere Microsoft Purview-Konten in mehreren VNETs

Hinweis

Möglicherweise müssen Sie separate private Portalendpunkte für jedes Microsoft Purview-Konto in Szenarien bereitstellen, in denen Microsoft Purview-Konten in isolierten Netzwerksegmentierungen bereitgestellt werden. Das Microsoft Purview-Portal ist statische Inhalte für alle Kunden ohne Kundeninformationen. Optional können Sie ein öffentliches Netzwerk (ohne privates Portalendpunkt) zum Starten web.purview.azure.com verwenden, wenn Ihre Endbenutzer das Internet starten dürfen.

Option 3: Verwenden von privaten und öffentlichen Endpunkten

Sie können eine Option auswählen, bei der eine Teilmenge Ihrer Datenquellen private Endpunkte verwendet. Gleichzeitig müssen Sie eine der folgenden Optionen überprüfen:

  • Andere Datenquellen, die mit einem Dienstendpunkt konfiguriert sind
  • Datenquellen mit einem öffentlichen Endpunkt, auf den über das Internet zugegriffen werden kann

Wenn Sie einige Datenquellen mithilfe eines privaten Erfassungsendpunkts und einige Datenquellen mithilfe öffentlicher Endpunkte oder eines Dienstendpunkts überprüfen müssen, haben Sie folgende Möglichkeiten:

  1. Verwenden Sie private Endpunkte für Ihr Microsoft Purview-Konto.
  2. Legen Sie Öffentlicher Netzwerkzugriff auf Aktiviert von allen Netzwerken in Ihrem Microsoft Purview-Konto fest.

Integration Runtime-Optionen

  • Zum Überprüfen einer Azure-Datenquelle, die mit einem privaten Endpunkt konfiguriert ist, müssen Sie eine selbstgehostete Integration Runtime auf einem virtuellen Windows-Computer einrichten und verwenden, der innerhalb desselben virtuellen Netzwerks oder eines mittels Peering verknüpften virtuellen Netzwerks bereitgestellt wird, in dem das Microsoft Purview-Konto und private Erfassungsendpunkte bereitgestellt werden.

    Wenn Sie einen privaten Endpunkt mit Microsoft Purview verwenden, müssen Sie netzwerkkonnektivität von Datenquellen zu einer selbstgehosteten Integrations-VM im virtuellen Azure-Netzwerk zulassen, in dem private Microsoft Purview-Endpunkte bereitgestellt werden.

  • Zum Überprüfen einer Azure-Datenquelle, die für die Zulassung eines öffentlichen Endpunkts konfiguriert ist, können Sie die Azure Integration Runtime verwenden.

  • Um lokale Datenquellen zu überprüfen, können Sie auch eine selbstgehostete Integration Runtime auf einem lokalen Windows-Computer oder auf einem virtuellen Computer in einem virtuellen Azure-Netzwerk installieren.

  • Es wird empfohlen, automatische Upgrades für eine selbstgehostete Integration Runtime zuzulassen. Stellen Sie sicher, dass Sie die erforderlichen Ausgangsregeln in Ihrem virtuellen Azure-Netzwerk oder in Ihrer Unternehmensfirewall öffnen, um automatische Upgrades zu ermöglichen. Weitere Informationen finden Sie unter Netzwerkanforderungen für selbstgehostete Integration Runtime.

Authentifizierungsoptionen

  • Zum Überprüfen einer Azure-Datenquelle, die für die Zulassung eines öffentlichen Endpunkts konfiguriert ist, können Sie eine beliebige Authentifizierungsoption basierend auf dem Datenquellentyp verwenden.

  • Wenn Sie einen privaten Erfassungsendpunkt verwenden, um eine Azure-Datenquelle zu überprüfen, die mit einem privaten Endpunkt konfiguriert ist:

    • Sie können keine verwaltete Microsoft Purview-Identität verwenden. Verwenden Sie stattdessen einen Dienstprinzipal, einen Kontoschlüssel oder eine SQL-Authentifizierung basierend auf dem Datenquellentyp.

    • Stellen Sie sicher, dass Ihre Anmeldeinformationen in einem Azure-Schlüsseltresor gespeichert und in Microsoft Purview registriert sind.

    • Sie müssen anmeldeinformationen in Microsoft Purview basierend auf jedem Geheimnis erstellen, das Sie in Azure Key Vault erstellen. Weisen Sie mindestens get- und list-Zugriff für Geheimnisse für Microsoft Purview auf der Key Vault-Ressource in Azure zu. Andernfalls funktionieren die Anmeldeinformationen nicht im Microsoft Purview-Konto.

Option 4: Verwenden privater Endpunkte nur für die Erfassung

Sie können diese Option auswählen, wenn Sie Folgendes benötigen:

  • Überprüfen Sie alle Datenquellen mithilfe eines privaten Erfassungsendpunkts.
  • Verwaltete Ressourcen müssen so konfiguriert werden, dass das öffentliche Netzwerk deaktiviert wird.
  • Aktivieren Sie den Zugriff auf das Microsoft Purview-Governanceportal über ein öffentliches Netzwerk.

So aktivieren Sie diese Option:

  1. Konfigurieren Sie den privaten Erfassungsendpunkt für Ihr Microsoft Purview-Konto.
  2. Legen Sie für Ihr Microsoft Purview-Kontoöffentliches Netzwerkzugriff auf Deaktiviert für die Erfassung (Vorschau) fest.

Integration Runtime-Optionen

Befolgen Sie die Empfehlung für Option 2.

Authentifizierungsoptionen

Befolgen Sie die Empfehlung für Option 2.

Netzwerk- und Proxyempfehlungen für selbstgehostete Integration Runtime

Zum Überprüfen von Datenquellen in Ihren lokalen und Azure-Netzwerken müssen Sie möglicherweise einen oder mehrere selbstgehostete Integration Runtime-VMs in einem Azure-VNet oder einem lokalen Netzwerk für jedes der weiter oben in diesem Dokument erwähnten Szenarien bereitstellen und verwenden.

  • Um die Verwaltung zu vereinfachen, verwenden Sie nach Möglichkeit die Azure-Runtime und die verwaltete Microsoft Purview-Runtime , um Azure-Datenquellen zu überprüfen.

  • Der Selbstgehostete Integration Runtime-Dienst kann über ein öffentliches oder privates Netzwerk über Port 443 mit Microsoft Purview kommunizieren. Weitere Informationen finden Sie unter Netzwerkanforderungen für selbstgehostete Integration Runtime.

  • Eine selbstgehostete Integration Runtime-VM kann zum Überprüfen einer oder mehrerer Datenquellen in Microsoft Purview verwendet werden. Die selbstgehostete Integration Runtime darf jedoch nur für Microsoft Purview registriert sein und kann nicht gleichzeitig für Azure Data Factory oder Azure Synapse verwendet werden.

  • Sie können eine oder mehrere selbstgehostete Integration Runtimes in einem Microsoft Purview-Konto registrieren und verwenden. Es wird empfohlen, mindestens eine selbstgehostete Integration Runtime-VM in jeder Region oder in jedem lokalen Netzwerk zu platzieren, in dem sich Ihre Datenquellen befinden.

  • Es wird empfohlen, eine Baseline für die erforderliche Kapazität für jede selbstgehostete Integration Runtime-VM zu definieren und die VM-Kapazität je nach Bedarf zu skalieren.

  • Es wird empfohlen, nach Möglichkeit eine Netzwerkverbindung zwischen selbstgehosteten Integration Runtime-VMs und Microsoft Purview und den verwalteten Ressourcen über ein privates Netzwerk einzurichten.

  • Lassen Sie ausgehende Verbindungen download.microsoft.com zu, wenn die automatische Aktualisierung aktiviert ist.

  • Der selbstgehostete Integration Runtime-Dienst erfordert keine ausgehende Internetverbindung, wenn selbstgehostete Integration Runtime-VMs in einem Azure-VNet oder im lokalen Netzwerk bereitgestellt werden, das über eine ExpressRoute- oder Site-to-Site-VPN-Verbindung mit Azure verbunden ist. In diesem Fall kann der Scan- und Metadatenerfassungsprozess über ein privates Netzwerk erfolgen.

  • Die selbstgehostete Integration Runtime kann Microsoft Purview und die zugehörigen verwalteten Ressourcen direkt oder über einen Proxyserver kommunizieren. Vermeiden Sie die Verwendung von Proxyeinstellungen, wenn sich die selbstgehostete Integration Runtime-VM in einem Azure-VNet befindet oder über ExpressRoute oder site-to-Site-VPN-Verbindung verbunden ist.

  • Überprüfen Sie unterstützte Szenarien, wenn Sie eine selbstgehostete Integration Runtime mit Proxyeinstellung verwenden müssen.

Nächste Schritte