Freigeben über

Architekturansätze für Netzwerke in mehrinstanzenfähigen Lösungen

  • Artikel

Für alle in Azure bereitgestellten Lösungen ist ein Netzwerk erforderlich. Je nach Lösungsentwurf und Workload kann sich die Art Ihrer Interaktion mit den Netzwerkdiensten von Azure unterscheiden. In diesem Artikel finden Sie Überlegungen und Anleitungen zu den Netzwerkaspekten von mehrinstanzenfähigen Lösungen in Azure. Es sind Informationen zu den Netzwerkkomponenten auf niedrigerer Ebene (z. B. virtuelle Netzwerke) bis hin zu Ansätzen auf höherer Ebene und auf Anwendungsebene enthalten.

Hinweis

Azure selbst ist eine mehrinstanzenfähige Umgebung, und die Netzwerkkomponenten von Azure sind auf Mehrinstanzenfähigkeit ausgelegt. Obwohl es nicht erforderlich ist, die Details zu verstehen, um Ihre eigene Lösung zu entwerfen, können Sie mehr darüber erfahren, wie Azure den Datenverkehr Ihres virtuellen Netzwerks vom Datenverkehr anderer Kund*innen isoliert.

Wesentliche Aspekte und Anforderungen

Infrastruktur- und Plattformdienste

Die Bedenken, die Sie hinsichtlich Ihrer Netzwerkkomponenten haben, unterscheiden sich abhängig von der Kategorie der von Ihnen verwendeten Dienste.

Infrastrukturdienste

Wenn Sie Infrastrukturdienste wie virtuelle Computer oder Azure Kubernetes Service verwenden, müssen Sie virtuelle Netzwerke (auch VNets) in Betracht ziehen und entwerfen, die die Konnektivität Ihrer Dienste unterstützen. Sie müssen auch die anderen Sicherheits- und Isolationsebenen berücksichtigen, die Sie in Ihren Entwurf integrieren müssen. Vermeiden Sie es, sich ausschließlich auf Steuerelemente auf Netzwerkebene zu verlassen.

Plattformdienste

Wenn Sie Azure-Plattformdienste wie App Service, Azure Cosmos DB oder Azure SQL-Datenbank verwenden, bestimmt die spezifische verwendete Architektur die benötigten Netzwerkdienste.

Wenn Sie Ihre Plattformdienste vom Internet isolieren müssen, müssen Sie ein VNet verwenden. In Abhängigkeit von den spezifischen verwendeten Diensten können Sie mit privaten Endpunkten oder VNet-integrierten Ressourcen wie Application Gateway arbeiten. Sie können Ihre Plattformdienste jedoch auch über ihre öffentlichen IP-Adressen verfügbar machen und die eigenen Schutzmechanismen der Dienste wie Firewalls und Identitätskontrollen verwenden. In diesen Situationen benötigen Sie möglicherweise kein VNet.

Die Entscheidung, ob VNets für Plattformdienste verwendet werden, basiert auf vielen Anforderungen, einschließlich der folgenden Faktoren:

  • Konformitätsanforderungen: Sie müssen möglicherweise einen bestimmten Konformitätsstandard erfüllen. Einige Standards erfordern, dass Ihre Azure-Umgebung auf bestimmte Weise konfiguriert wird.
  • Anforderungen Ihrer Mandanten: Auch wenn Ihre eigene Organisation keine spezifischen Anforderungen an die Isolation oder Steuerung auf Netzwerkebene hat, kann dies bei Ihren Mandanten der Fall sein. Stellen Sie sicher, dass Sie genau wissen, wie Ihre Mandanten auf Ihre Lösung zugreifen und ob sie Voraussetzungen für den Netzwerkentwurf haben.
  • Komplexität: Es kann komplexer sein, virtuelle Netzwerke zu verstehen und mit ihnen zu arbeiten. Stellen Sie sicher, dass Ihr Team über ein klares Verständnis der beteiligten Prinzipien verfügt, oder Sie stellen wahrscheinlich eine unsichere Umgebung bereit.

Vergewissern Sie sich, dass Sie die Auswirkungen der Verwendung privater Netzwerke verstehen.

Dimensionierung von Subnetzen

Wenn Sie ein VNet bereitstellen müssen, ist es wichtig, die Dimensionierung und den Adressraum des gesamten VNet und der Subnetze innerhalb des VNet sorgfältig zu planen.

Stellen Sie sicher, dass Sie genau wissen, wie Sie Ihre Azure-Ressourcen in VNets bereitstellen und wie viele IP-Adressen von jeder Ressource benötigt werden. Wenn Sie mandantenspezifische Serverknoten, Datenbankserver oder andere Ressourcen bereitstellen, stellen Sie sicher, dass Sie Subnetze erstellen, die groß genug für das erwartete Mandantenwachstum und die horizontale automatische Ressourcenskalierung sind.

Ebenso ist es wichtig, dass Sie bei der Arbeit mit verwalteten Diensten verstehen, wie IP-Adressen verwendet werden. Wenn Sie beispielsweise Azure Kubernetes Service mit Azure Container Networking Interface (CNI) verwenden, basiert die Anzahl der von einem Subnetz genutzten IP-Adressen auf Faktoren wie der Anzahl der Knoten, der horizontalen Skalierung und dem von Ihnen verwendeten Dienstbereitstellungsprozess. Wenn Sie Azure App Service und Azure Functions mit der VNet-Integration verwenden, basiert die Anzahl der verwendeten IP-Adressen auf der Anzahl der Planinstanzen.

Lesen Sie die Anleitung zur Subnetzsegmentierung, wenn Sie Ihre Subnetze planen.

Öffentlicher oder privater Zugriff

Überlegen Sie, ob Ihre Mandanten über das Internet oder über private IP-Adressen auf Ihre Dienste zugreifen.

Für internetbasierten (öffentlichen) Zugriff können Sie Firewallregeln, Positiv- und Verweigerungslisten für IP-Adressen, freigegebene Geheimnisse und Schlüssel sowie identitätsbasierte Steuerelemente verwenden, um Ihren Dienst zu schützen.

Wenn Sie die Konnektivität mit Ihrem Dienst über private IP-Adressen aktivieren müssen, erwägen Sie die Verwendung des Azure Private Link-Diensts oder des mandantenübergreifenden Peerings virtueller Netzwerke. In einigen eingeschränkten Szenarios können Sie auch die Verwendung von Azure ExpressRoute oder Azure VPN Gateway in Betracht ziehen, um den privaten Zugriff auf Ihre Lösung zu ermöglichen. Dieser Ansatz ist in der Regel nur sinnvoll, wenn Sie eine kleine Anzahl von Mandanten haben und für jeden Mandanten dedizierte virtuelle Netzwerke (VNets) bereitstellen.

Zugriff auf Endpunkte von Mandanten

Überlegen Sie, ob Sie Daten an Endpunkte in den Netzwerken von Mandanten senden müssen, die sich innerhalb oder außerhalb von Azure befinden. Müssen Sie beispielsweise einen Webhook aufrufen, der von einer Kundin oder einem Kunden bereitgestellt wird, oder müssen Sie Echtzeitnachrichten an einen Mandanten senden?

Wenn Sie Daten an die Endpunkte von Mandanten senden müssen, sollten Sie die folgenden gängigen Ansätze in Betracht ziehen:

  • Initiieren Sie Verbindungen zwischen Ihrer Lösung und den Endpunkten von Mandanten über das Internet. Überlegen Sie, ob die Verbindungen von einer statischen IP-Adresse stammen müssen. Abhängig von den verwendeten Azure-Diensten müssen Sie möglicherweise eine NAT Gateway-Instanz, eine Firewall oder einen Lastenausgleich bereitstellen.
  • Stellen Sie einen Agent zum Aktivieren der Konnektivität zwischen Ihren in Azure gehosteten Diensten und den Netzwerken Ihrer Kund*innen bereit, unabhängig davon, wo sie sich befinden.
  • Erwägen Sie für das unidirektionale Messaging, einen Dienst wie Azure Event Grid in Verbindung mit Ereignisdomänen zu verwenden.

Zu berücksichtigende Ansätze und Muster

In diesem Abschnitt werden einige der wichtigsten Netzwerkansätze beschrieben, die Sie in einer mehrinstanzenfähigen Lösung berücksichtigen sollten. Zunächst werden die Ansätze auf niedrigerer Ebene für Kernnetzwerkkomponenten und anschließend Ansätze beschrieben, die Sie für das HTTP und andere Aspekte auf Anwendungsebene berücksichtigen können.

Mandantenspezifische VNets mit vom Dienstanbieter ausgewählten IP-Adressen

In einigen Situationen müssen Sie dedizierte, mit dem VNet verbundene Ressourcen in Azure im Auftrag eines Mandanten ausführen. Beispielsweise können Sie einen virtuellen Computer für jeden Mandanten ausführen, oder Sie müssen private Endpunkte verwenden, um auf mandantenspezifische Datenbanken zuzugreifen.

Erwägen Sie die Bereitstellung eines VNet für jeden Mandanten mithilfe eines IP-Adressraums, den Sie steuern. Mit diesem Ansatz können Sie die VNets für Ihre eigenen Zwecke miteinander verbinden, beispielsweise wenn Sie eine Hub-and-Spoke-Topologie einrichten müssen, um den ein- und ausgehenden Datenverkehr zentral zu steuern.

Vom Dienstanbieter ausgewählte IP-Adressen sind jedoch nicht geeignet, wenn Mandanten eine direkte Verbindung mit dem von Ihnen erstellten VNet herstellen müssen (z. B. über VNet-Peering). Es ist wahrscheinlich, dass der von Ihnen ausgewählte Adressraum mit seinen eigenen Adressräumen nicht kompatibel ist.

Mandantenspezifische VNets mit vom Mandanten ausgewählten IP-Adressen

Wenn Mandanten ein Peering ihrer eigenen VNets mit dem VNet durchführen müssen, das Sie in ihrem Namen verwalten, sollten Sie mandantenspezifische VNets mit einem IP-Adressraum bereitstellen, den der Mandant auswählt. Mit diesem System kann jeder Mandant sicherstellen, dass sich die IP-Adressbereiche VNet Ihres Systems nicht mit ihren eigenen VNets überschneiden. Durch die Verwendung von nicht überlappenden IP-Adressbereichen können sie sicherstellen, dass ihre Netzwerke für Peering kompatibel sind.

Dieser Ansatz bedeutet jedoch, dass es unwahrscheinlich ist, dass Sie die VNets Ihrer Mandanten mittels Peering miteinander verbinden oder eine Hub-and-Spoke-Topologie übernehmen können, da es wahrscheinlich überlappende IP-Adressbereiche zwischen VNets verschiedener Mandanten gibt.

Hub-Spoke-Topologie

Die Hub-and-Spoke-VNet-Topologie ermöglicht Ihnen das Peering eines zentralisierten Hub-VNet mit mehreren Spoke-VNets. Sie können den ein- und ausgehenden Datenverkehr für Ihre VNets zentral steuern und festlegen, ob die Ressourcen im VNet der einzelnen Spokes miteinander kommunizieren können. Jedes Spoke-VNet kann auch auf freigegebene Komponenten wie Azure Firewall zugreifen und Dienste wie Azure DDoS Protection nutzen.

Wenn Sie eine Hub-and-Spoke-Topologie verwenden, stellen Sie sicher, dass Sie Grenzwerte wie die maximale Anzahl von VNets mit Peering einplanen und keine überlappenden Adressräume für das VNet jedes Mandanten verwenden.

Die Hub-and-Spoke-Topologie kann nützlich sein, wenn Sie mandantenspezifische VNets mit von Ihnen ausgewählten IP-Adressen bereitstellen. Das VNet jedes Mandanten wird zu einem Spoke und kann Ihre gemeinsamen Ressourcen im Hub-VNet freigeben. Sie können die Hub-and-Spoke-Topologie auch verwenden, wenn Sie freigegebene Ressourcen für Skalierungszwecke VNet-übergreifend skalieren oder das Muster mit Bereitstellungsstempeln verwenden.

Tipp

Wenn Ihre Lösung regionsübergreifend ausgeführt wird, ist es in der Regel eine bewährte Methode, separate Hubs und Hubressourcen in jeder Region bereitzustellen. Diese Vorgehensweise führt zwar zu höheren Ressourcenkosten, vermeidet jedoch, dass Datenverkehr unnötigerweise mehrere Azure-Regionen durchläuft, wodurch die Latenz von Anforderungen erhöht werden kann und globale Peeringgebühren anfallen können.

Statische IP-Adressen

Überlegen Sie, ob Ihre Mandanten Ihren Dienst benötigen, um statische öffentliche IP-Adressen für eingehenden Datenverkehr, ausgehenden Datenverkehr oder beides zu verwenden. Verschiedene Azure-Dienste ermöglichen statische IP-Adressen auf unterschiedliche Weise.

Wenn Sie mit virtuellen Computern und anderen Infrastrukturkomponenten arbeiten, sollten Sie erwägen, einen Lastenausgleich oder eine Firewall für die statische IP-Adressierung für eingehenden und ausgehenden Datenverkehr zu verwenden. Verwenden Sie NAT Gateway, um die IP-Adresse des ausgehenden Datenverkehrs zu steuern. Weitere Informationen zur Verwendung von NAT Gateway in mehrmandantenfähigen Lösungen finden Sie unter Überlegungen zu Azure NAT Gateway für die Mehrmandantenfähigkeit.

Wenn Sie mit Plattformdiensten arbeiten, bestimmt der von Ihnen verwendete Dienst, ob und wie Sie IP-Adressen steuern können. Möglicherweise müssen Sie die Ressource auf eine bestimmte Weise konfigurieren, z. B. indem Sie eine Ressource wie eine VM in einem VNet bereitstellen und dann eine NAT Gateway-Instanz oder eine Firewall nutzen. Alternativ können Sie die aktuelle Gruppe von IP-Adressen anfordern, die der Dienst für ausgehenden Datenverkehr verwendet. Beispielsweise stellt App Service eine API und eine Webschnittstelle zum Abrufen der aktuellen IP-Adressen für ausgehenden Datenverkehr für Ihre Anwendung bereit.

Agents

Wenn Sie es Ihren Mandanten ermöglichen müssen, Nachrichten zu empfangen, die von Ihrer Lösung initiiert werden, oder wenn Sie auf Daten zugreifen müssen, die in den eigenen Netzwerken von Mandanten vorhanden sind, sollten Sie die Bereitstellung eines Agents (manchmal auch als lokales Gateway bezeichnet) in Erwägung ziehen, den sie in ihrem Netzwerk zur Verfügung stellen können. Dieser Ansatz kann unabhängig davon funktionieren, ob sich die Netzwerke Ihrer Mandanten in Azure, bei einem anderen Cloudanbieter oder in einer lokalen Umgebung befinden.

Der Agent initiiert eine ausgehende Verbindung mit einem Endpunkt, den Sie angeben und steuern, und hält Verbindungen mit langer Laufzeit aufrecht oder frägt diese zeitweilig ab. Sie können Azure Relay verwenden, um Verbindungen zwischen Ihrem Agent und Ihrem Dienst herzustellen und zu verwalten. Wenn der Agent die Verbindung einrichtet, wird er authentifiziert und schließt einige Informationen zur Mandanten-ID ein, damit Ihr Dienst die Verbindung dem richtigen Mandanten zuordnen kann.

Agents vereinfachen in der Regel die Sicherheitskonfiguration für Ihre Mandanten. Es kann komplex und riskant sein, eingehende Ports zu öffnen, insbesondere in einer lokalen Umgebung. Ein Agent vermeidet, dass Mandanten dieses Risiko eingehen müssen.

Hier finden Sie Beispiele für Microsoft-Dienste, die Agents für Verbindungen mit den Netzwerken von Mandanten bereitstellen:

Der Azure Private Link-Dienst ermöglicht private Verbindungen aus der Azure-Umgebung eines Mandanten mit Ihrer Lösung. Mandanten können auch einen Private Link-Dienst mit ihrem eigenen VNet verwenden, um aus einer lokalen Umgebung auf Ihren Dienst zuzugreifen. Azure leitet den Datenverkehr mithilfe privater IP-Adressen sicher an den Dienst weiter.

Weitere Informationen zu Private Link und Mehrinstanzenfähigkeit finden Sie unter Mehrinstanzenfähigkeit und Azure Private Link.

Domänennamen, Unterdomänen und TLS

Bei der Arbeit mit Domänennamen und der Transport Layer Security (TLS) in einer mehrinstanzenfähigen Lösung müssen mehrere Punkte berücksichtigt werden. Sehen Sie sich die Überlegungen zur Mehrinstanzenfähigkeit und zu Domänennamen an.

Muster für Gatewayrouting und Gatewayabladung

Die Muster Gatewayrouting und Gatewayabladung umfassen die Bereitstellung eines Layer-7-Reverseproxys oder -Gateways. Gateways sind nützlich, um Kerndienste für eine mehrinstanzenfähige Anwendung zu bieten, einschließlich der folgenden Funktionen:

  • Weiterleiten von Anforderungen an mandantenspezifische Back-Ends oder Bereitstellungsstempel
  • Verarbeiten von mandantenspezifischen Domänennamen und TLS-Zertifikaten
  • Überprüfen von Anforderungen auf Sicherheitsbedrohungen mithilfe einer Web Application Firewall (WAF)
  • Zwischenspeichern von Antworten zur Verbesserung der Leistung

Azure bietet mehrere Dienste, die zum Erreichen einiger oder aller dieser Ziele verwendet werden können, einschließlich Azure Front Door, Azure Application Gateway und Azure API Management. Sie können auch Ihre eigene benutzerdefinierte Lösung bereitstellen, indem Sie Software wie NGINX oder HAProxy verwenden.

Wenn Sie planen, ein Gateway für Ihre Lösung bereitzustellen, ist es eine bewährte Methode, zunächst einen vollständigen Prototyp zu erstellen, der alle benötigten Features enthält, und zu überprüfen, ob Ihre Anwendungskomponenten weiterhin wie erwartet funktionieren. Außerdem sollten Sie verstehen, wie die Gatewaykomponente skaliert wird, um den Datenverkehr und das Wachstum Ihrer Mandanten zu unterstützen.

Muster für das Hosten von statischen Inhalten

Das Muster für das Hosten von statischen Inhalten umfasst die Bereitstellung von Webinhalten aus einem cloudnativen Speicherdienst und die Verwendung eines Content Delivery Network (CDN), um den Inhalt zwischenzuspeichern.

Sie können Azure Front Door oder ein anderes CDN für die statischen Komponenten Ihrer Lösung (z. B. Single-Page-JavaScript-Anwendungen) und für statische Inhalte wie Bilddateien und Dokumente verwenden.

Je nachdem, wie Ihre Lösung entworfen wurde, können Sie möglicherweise auch mandantenspezifische Dateien oder Daten in einem CDN zwischenspeichern (z. B. JSON-formatierte API-Antworten). Diese Vorgehensweise kann Ihnen helfen, die Leistung und Skalierbarkeit Ihrer Lösung zu verbessern, aber es ist wichtig zu berücksichtigen, ob mandantenspezifische Daten ausreichend isoliert sind, um zu vermeiden, dass Daten mandantenübergreifend verteilt werden. Überlegen Sie, wie Sie mandantenspezifische Inhalte aus Ihrem Cache löschen möchten, beispielsweise wenn Daten aktualisiert werden oder eine neue Anwendungsversion bereitgestellt wird. Durch das Einschließen des Mandantenbezeichners in den URL-Pfad können Sie steuern, ob Sie eine bestimmte Datei, alle Dateien, die sich auf einen bestimmten Mandanten beziehen, oder alle Dateien für alle Mandanten löschen.

Zu vermeide Antimuster

Fehler beim Planen der VNet-Konnektivität

Durch die Bereitstellung von Ressourcen in VNets haben Sie umfassende Kontrolle darüber, wie Datenverkehr die Komponenten Ihrer Lösung durchläuft. Die VNet-Integration führt jedoch auch zu zusätzlicher Komplexität, Kosten und anderen Faktoren, die Sie berücksichtigen müssen. Dies gilt insbesondere für PaaS-Komponenten (Platform as a Service).

Es ist wichtig, Ihre Netzwerkstrategie zu testen und zu planen, damit Sie Probleme ermitteln, bevor Sie sie in einer Produktionsumgebung implementieren.

Fehlende Planung von Grenzwerten

Azure erzwingt eine Reihe von Grenzwerten, die sich auf Netzwerkressourcen auswirken. Zu diesen Grenzwerten gehören Azure-Ressourcenlimits und grundlegende Protokoll- und Plattformgrenzwerte. Wenn Sie beispielsweise eine mehrinstanzenfähige Lösung für hohe Skalierung auf Plattformdiensten wie Azure App Service und Azure Functions erstellen, müssen Sie möglicherweise die Anzahl der TCP-Verbindungen und SNAT-Ports berücksichtigen. Wenn Sie mit virtuellen Computern und Lastenausgleichen arbeiten, müssen Sie auch Einschränkungen für Ausgangsregeln und SNAT-Ports beachten.

Kleine Subnetze

Es ist wichtig, die Größe jedes Subnetzes zu berücksichtigen, um die Anzahl der Ressourcen oder Instanzen von Ressourcen zuzulassen, die Sie bereitstellen werden, vor allem, wenn Sie skalieren. Wenn Sie mit PaaS-Ressourcen (Platform as a Service) arbeiten, stellen Sie sicher, dass Sie verstehen, wie sich die Konfiguration und Skalierung Ihrer Ressource auf die Anzahl der IP-Adressen auswirken, die im Subnetz erforderlich sind.

Nicht ordnungsgemäße Netzwerksegmentierung

Wenn Ihre Lösung virtuelle Netzwerke erfordert, sollten Sie überlegen, wie Sie die Netzwerksegmentierung konfigurieren, damit Sie den ein- und ausgehenden Datenverkehrsfluss (Nord-Süd) und die Datenflüsse in Ihrer Lösung (Ost-West) steuern können. Entscheiden Sie, ob Mandanten über eigene VNets verfügen sollen oder ob Sie freigegebene Ressourcen in freigegebenen VNets bereitstellen möchten. Das Ändern des Ansatzes kann schwierig sein. Stellen Sie daher sicher, dass Sie alle Ihre Anforderungen berücksichtigen und dann einen Ansatz auswählen, der für Ihre zukünftigen Wachstumsziele geeignet ist.

Ausschließliches Verwenden von Sicherheitskontrollen auf Netzwerkebene

In modernen Lösungen ist es wichtig, die Sicherheit auf Netzwerkebene mit anderen Sicherheitskontrollen zu kombinieren, und Sie sollten sich nicht nur auf Firewalls oder Netzwerksegmentierung verlassen. Dies wird manchmal als Zero-Trust-Netzwerk bezeichnet. Verwenden Sie identitätsbasierte Steuerelemente, um Clients, Aufrufer*innen oder Benutzer*innen auf jeder Ebene Ihrer Lösung zu überprüfen. Erwägen Sie die Verwendung von Diensten, mit denen Sie zusätzliche Schutzebenen hinzufügen können. Es hängt von den verwendeten Azure-Diensten ab, welche Optionen verfügbar sind. Erwägen Sie in AKS die Verwendung eines Dienstnetzes für die gegenseitige TLS-Authentifizierung und Netzwerkrichtlinien zur Steuerung des Ost-West-Datenverkehrs. In App Service sollten Sie die Verwendung der integrierten Unterstützung für die Authentifizierung und Autorisierung sowie Zugriffsbeschränkungen in Betracht ziehen.

Umschreiben von Hostheadern ohne Tests

Wenn Sie das Muster „Gatewayabladung“ verwenden, können Sie in Erwägung ziehen, den Host-Header von HTTP-Anforderungen umzuschreiben. Diese Vorgehensweise kann die Konfiguration Ihres Back-End-Webanwendungsdiensts vereinfachen, indem die Verwaltung der benutzerdefinierten Domäne und der Transport Layer Security an das Gateway übertragen werden.

Das Umschreiben des Host-Headers kann jedoch zu Problemen bei einigen Back-End-Diensten führen. Wenn Ihre Anwendung HTTP-Umleitungen oder Cookies ausgibt, kann die Nichtübereinstimmung der Hostnamen die Funktionalität der Anwendung beeinträchtigen. Dieses Problem kann insbesondere auftreten, wenn Sie Back-End-Dienste verwenden, die selbst mehrinstanzenfähig sind (z. B. Azure App Service, Azure Functions und Azure Spring Apps). Weitere Informationen finden Sie in der Bewährten Methode zur Erhaltung des Hostnamens.

Stellen Sie sicher, dass Sie das Verhalten Ihrer Anwendung mit der Gatewaykonfiguration testen, die Sie verwenden möchten.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte