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

Alle Lösungen, die in Azure bereitgestellt werden, erfordern eine Form der Netzwerkanbindung. Die Interaktion mit Azure-Netzwerkdiensten hängt vom Design und der Arbeitsauslastung Ihrer Lösung ab. Dieser Artikel enthält Überlegungen und Anleitungen für die Netzwerkaspekte von Multitenant-Lösungen in Azure. Es umfasst Informationen zu netzwerktechnischen Komponenten der unteren Ebene, wie etwa virtuellen Netzwerken, und erstreckt sich bis hin zu Ansätzen auf höherer Ebene sowie auf der Anwendungsebene.

Hinweis

Azure ist eine mandantenfähige Umgebung, wie es bei vielen seiner Netzwerkkomponenten der Fall ist. Sie müssen die Details zum Entwerfen Ihrer eigenen Lösung nicht verstehen, aber Sie können mehr darüber erfahren, wie Azure Ihren virtuellen Netzwerkdatenverkehr vom Datenverkehr anderer Kunden isoliert.

Wesentliche Aspekte und Anforderungen

Infrastruktur- und Plattformdienste

Ihre Überlegungen zur Netzwerkkomponente hängen von der Kategorie der dienste ab, die Sie verwenden.

Infrastrukturdienste

Wenn Sie Infrastrukturdienste wie virtuelle Maschinen (VMs) oder Azure Kubernetes Service (AKS) verwenden, sollten Sie die virtuellen Netzwerke berücksichtigen und entwerfen, die die Konnektivität Ihrer Dienste untermauern. Berücksichtigen Sie auch die anderen Sicherheits- und Isolationsebenen, die Sie in Ihr Design integrieren müssen. Vermeiden Sie es, sich ausschließlich auf Steuerelemente auf Netzwerkebene zu verlassen.

Plattformdienste

Wenn Sie Azure-Plattformdienste wie Azure App Service, Azure Cosmos DB oder Azure SQL-Datenbank verwenden, bestimmt Ihre Architektur die erforderlichen Netzwerkdienste.

Um Ihre Plattformdienste aus dem Internet zu isolieren, verwenden Sie ein virtuelles Netzwerk. Abhängig von den diensten, die Sie verwenden, können Sie mit privaten Endpunkten oder mit integrierten virtuellen Netzwerkressourcen wie Azure Application Gateway arbeiten. Sie können Ihre Plattformdienste auch über ihre öffentlichen IP-Adressen verfügbar machen und die eigenen Schutzmaßnahmen wie Firewalls und Identitätssteuerelemente verwenden. In diesen Situationen müssen Sie möglicherweise kein eigenes virtuelles Netzwerk bereitstellen und konfigurieren.

Entscheiden Sie, ob virtuelle Netzwerke für Plattformdienste basierend auf den folgenden Faktoren verwendet werden sollen:

  • Konformitätsanforderungen: Sie müssen möglicherweise einen bestimmten Konformitätsstandard erfüllen. Einige Standards erfordern, dass Sie Ihre Azure-Umgebung auf bestimmte Weise konfigurieren, z. B. indem Sie bestimmte Netzwerksteuerelemente verwenden. Weitere Informationen finden Sie unter Architekturansätze für Governance und Compliance in mandantenfähigen Lösungen.

  • Anforderungen Ihrer Mandanten: Auch wenn Ihre Organisation keine Anforderungen für die Netzwerkschichtisolation oder -steuerelemente definiert hat, können Ihre Mandanten solche Anforderungen haben. Verstehen Sie genau, wie Ihre Mandanten auf Ihre Lösung zugreifen wollen und ob sie Annahmen über deren Netzwerkdesign haben.

  • Komplexität: Virtuelle Netzwerke führen zu Komplexität. Stellen Sie sicher, dass Ihr Team die Prinzipien klar versteht, um zu vermeiden, eine unsichere Umgebung bereitzustellen.

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

Subnetze dimensionieren

Wenn Sie ein virtuelles Netzwerk bereitstellen müssen, berücksichtigen Sie sorgfältig die Größe und den Adressraum des gesamten virtuellen Netzwerks, einschließlich der Subnetze.

Verstehen Sie, wie Sie Ihre Azure-Ressourcen in virtuellen Netzwerken bereitstellen möchten und wie viele IP-Adressen jede Ressource verbraucht. Wenn Sie mandantenspezifische Computeknoten, Datenbankserver oder andere Ressourcen bereitstellen, erstellen Sie Subnetze, die für das erwartete Mandantenwachstum und die horizontale automatische Skalierung von Ressourcen groß genug sind.

Ebenso sollten Sie, wenn Sie mit verwalteten Diensten arbeiten, verstehen, wie sie IP-Adressen nutzen. Wenn Sie beispielsweise AKS mit Azure Container Networking Interface (CNI) verwenden, basiert die Anzahl der von einem Subnetz verbrauchten IP-Adressen auf Faktoren wie der Anzahl der Knoten, der horizontalen Skalierung und Ihrem Dienstbereitstellungsprozess. Wenn Sie App Service und Azure Functions mit der Integration des virtuellen Netzwerks verwenden, basiert die Anzahl der verbrauchten IP-Adressen auf der Anzahl der Planinstanzen.

Überprüfen Sie die Anleitungen zur Subnetzsegmentierung , wenn Sie Ihre Subnetze planen.

Öffentlicher oder privater Zugriff

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

Um Ihren Dienst für den internetbasierten (öffentlichen) Zugriff zu sichern, verwenden Sie Firewallregeln, Zulassungslisten für IP-Adressen und Sperrlisten, gemeinsam genutzte Geheimnisse und Schlüssel sowie identitätsbasierte Steuerelemente.

Um Mandanten das Herstellen einer Verbindung mit Ihrem Dienst mithilfe privater IP-Adressen zu ermöglichen, sollten Sie den Azure Private Link-Dienst oder mandantenübergreifendes virtuelles Netzwerk-Peering verwenden. 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. In der Regel ist dieser Ansatz nur sinnvoll, wenn Sie nur wenige Mandanten haben und dedizierte virtuelle Netzwerke für jeden Mandanten bereitstellen.

Zugriff auf Endpunkte von Mandanten

Überlegen Sie, ob Sie Daten an Endpunkte innerhalb der Mandantennetzwerke senden müssen, entweder innerhalb oder außerhalb von Azure. Sie können beispielsweise einen vom Kunden bereitgestellten Webhook aufrufen oder Echtzeitnachrichten an die Systeme eines Mandanten senden.

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

  • 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 von Ihnen verwendeten Azure-Diensten müssen Sie möglicherweise die Netzwerkadressenübersetzung (NETWORK Address Translation, NAT) verwenden, indem Sie Azure NAT-Gateway, eine Firewall oder einen Lastenausgleich bereitstellen.

  • Stellen Sie einen Agent bereit, um die Konnektivität zwischen Ihren von Azure gehosteten Diensten und den Netzwerken Ihrer Kunden unabhängig vom Standort zu ermöglichen.

  • Erwägen Sie die Verwendung eines Diensts wie Azure Event Grid, potenziell mit Ereignisdomänen, für unidirektionale Nachrichten.

Zu berücksichtigende Ansätze und Muster

In diesem Abschnitt werden einige wichtige Netzwerkansätze beschrieben, die in einer Mandantenlösung berücksichtigt werden sollen. Sie beginnen mit Ansätzen auf niedrigerer Ebene für Kernnetzwerkkomponenten und beschreibt dann Ansätze für HTTP und andere Aspekte auf Anwendungsebene.

Mandantenspezifische virtuelle Netzwerke mit vom Dienstanbieter ausgewählten IP-Adressen

In einigen Szenarien müssen Sie dedizierte mit dem virtuellen Netzwerk verbundene Ressourcen in Azure im Auftrag eines Mandanten betreiben. Sie können beispielsweise 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 virtuellen Netzwerks für jeden Mandanten mithilfe eines von Ihnen gesteuerten IP-Adressraums. Mit diesem Ansatz können Sie die virtuellen Netzwerke zu Ihren eigenen Zwecken miteinander peeren, z. B. eine Hub-and-Spoke-Topologie einrichten, um den ein- und ausgehenden Datenverkehr zentral zu steuern.

Vermeiden Sie die Verwendung von vom Dienstanbieter ausgewählten IP-Adressen, wenn Mandanten eine direkte Verbindung mit dem von Ihnen erstellten virtuellen Netzwerk herstellen müssen, z. B. mithilfe von virtuellem Netzwerk-Peering. Der von Ihnen ausgewählte Adressraum ist wahrscheinlich mit deren vorhandenen Adressräumen in Konflikt.

Mandantenspezifische virtuelle Netzwerke mit vom Mandanten ausgewählten IP-Adressen

Wenn Mandanten ihre eigenen virtuellen Netzwerke mit dem virtuellen Netzwerk peeren müssen, das Sie in ihrem Namen verwalten, sollten Sie die Bereitstellung mandantenspezifischer virtueller Netzwerke mithilfe eines vom Mandanten ausgewählten IP-Adressraums in Betracht ziehen. Mit diesem Setup kann jeder Mandant sicherstellen, dass die IP-Adressbereiche im virtuellen Netzwerk Ihres Systems nicht mit ihren eigenen virtuellen Netzwerken überlappen, was die Kompatibilität für Peering ermöglicht.

Dieser Ansatz verhindert jedoch wahrscheinlich, dass Sie die virtuellen Netzwerke Ihrer Mandanten zusammen peeren oder eine Hub-and-Spoke-Topologie übernehmen. Verbundene virtuelle Netzwerke können keine sich überschneidenden IP-Adressbereiche verwenden, und wenn Mandanten ihre eigenen IP-Adressbereiche auswählen, wählen sie wahrscheinlich Bereiche, die sich mit anderen überschneiden.

Hub-and-Spoke-Topologie

Die Hub-and-Spoke-Topologie für virtuelle Netzwerke ermöglicht es Ihnen, ein zentrales virtuelles Hub-Netzwerk mit mehreren Speichen virtuellen Netzwerken zu peeren. Sie können den ein- und ausgehenden Datenverkehr für Ihre virtuellen Netzwerke zentral steuern und steuern, ob die Ressourcen im virtuellen Netzwerk der einzelnen Spokes miteinander kommunizieren können. Jedes virtuelle Spoke-Netzwerk kann auch auf freigegebene Komponenten wie Azure Firewall zugreifen und Dienste wie Azure DDoS Protection verwenden.

Wenn Sie eine Hub-and-Spoke-Topologie verwenden, planen Sie Einschränkungen wie die maximale Anzahl von virtuellen Netzwerken mit Peering. Verwenden Sie keine überlappenden Adressräume für das virtuelle Netzwerk jedes Mandanten.

Erwägen Sie die Verwendung der Hub-and-Spoke-Topologie, wenn Sie mandantenspezifische virtuelle Netzwerke bereitstellen, die von Ihnen ausgewählte IP-Adressen verwenden. Das virtuelle Netzwerk jedes Mandanten wird zu einer Speiche und kann gemeinsame Ressourcen im virtuellen Hubnetzwerk nutzen. Sie können die Hub-and-Spoke-Topologie auch verwenden, wenn Sie freigegebene Ressourcen in mehreren virtuellen Netzwerken skalieren oder wenn Sie das Deployment Stamps pattern verwenden.

Tipp

Wenn Ihre Lösung mehrere geografische Regionen umfasst, stellen Sie separate Hubs und Hubressourcen in jeder Region bereit, um zu verhindern, dass Datenverkehr mehrere Azure-Regionen durchquert. Diese Vorgehensweise verursacht höhere Ressourcenkosten, reduziert jedoch die Anfragelatenz und reduziert globale Peeringgebühren.

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 VMs 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. Erwägen Sie die Verwendung des Azure NAT-Gateways, um die IP-Adresse des ausgehenden Datenverkehrs zu steuern. Weitere Informationen finden Sie unter Überlegungen zu Azure NAT Gateway für Mehrinstanzenfähigkeit.

Wenn Sie mit Plattformdiensten arbeiten, bestimmt der spezifische Dienst, den Sie verwenden, 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 virtuellen Netzwerk bereitstellen und dann ein NAT-Gateway oder eine Firewall verwenden. Sie können auch den aktuellen Satz 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.

Agenten

Um Ihren Mandanten zu ermöglichen, von Ihrer Lösung initiierte Nachrichten zu empfangen oder auf Daten in ihren Netzwerken zuzugreifen, sollten Sie die Bereitstellung eines Agenten, der manchmal als lokales Gateways bezeichnet wird, in Erwägung ziehen, den sie in ihrem Netzwerk bereitstellen. Dieser Ansatz kann funktionieren, ob sich die Netzwerke Ihrer Mandanten in Azure, in einem anderen Cloudanbieter oder lokal befinden.

Der Agent initiiert eine ausgehende Verbindung mit einem Endpunkt, den Sie angeben und steuern. Es hält entweder lange laufende Verbindungen lebendig oder fragt zeitweise 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 Makler erspart den Mandanten die Notwendigkeit, dieses Risiko einzugehen.

Zu den Microsoft-Diensten, die Agents für die Konnektivität mit den Netzwerken von Mandanten bereitstellen, gehören die folgenden Beispiele:

Der Private Link-Dienst bietet private Konnektivität von der Azure-Umgebung eines Mandanten zu Ihrer Lösung. Mandanten können auch den Private Link-Dienst mit ihrem eigenen virtuellen Netzwerk verwenden, um aus einer On-Premises-Umgebung auf Ihren Dienst zuzugreifen. Azure leitet den Datenverkehr sicher mithilfe privater IP-Adressen an den Dienst weiter.

Weitere Informationen finden Sie unter Multitenancy und Private Link.

Domänennamen, Unterdomänen und TLS

Wenn Sie mit Domänennamen und TLS (Transport Layer Security) in einer Mehrinstanzenlösung arbeiten, lesen Sie die wichtigsten Überlegungen.

Muster für Gatewayrouting und Gatewayabladung

Das Gatewayroutingmuster und das Gateway offloading-Muster umfassen die Bereitstellung eines Layer-7-Reverseproxys oder eines Gateways. Gateways bieten Kerndienste für eine mandantenfähige Anwendung, einschließlich der folgenden Funktionen:

  • Weiterleiten von Anfragen an mandantenspezifische Back-Ends oder Deployment Stamps
  • Umgang mit mandantenspezifischen Domänennamen und TLS-Zertifikaten
  • Überprüfen von Anfragen auf Sicherheitsbedrohungen mithilfe einer Webanwendungsfirewall (WAF)
  • Zwischenspeichern von Antworten zur Verbesserung der Leistung

Azure bietet mehrere Dienste, die einige oder alle diese Ziele erreichen können, einschließlich Azure Front Door, Application Gateway und Azure API Management. Sie können ihre eigene benutzerdefinierte Lösung auch mithilfe von Software wie NGINX oder HAProxy bereitstellen.

Wenn Sie beabsichtigen, ein Gateway für Ihre Lösung bereitzustellen, empfiehlt es sich, zuerst einen vollständigen Prototyp zu erstellen. Schließen Sie alle erforderlichen Features ein, und stellen Sie sicher, dass Ihre Anwendungskomponenten wie erwartet funktionieren. Außerdem sollten Sie verstehen, wie die Gatewaykomponente skaliert, um den Datenverkehr und das Wachstum Ihrer Mandanten zu unterstützen.

Muster für das Hosten von statischen Inhalten

Das Muster für das Hosting statischer Inhalte stellt statische Webinhalte direkt aus dem Cloudspeicher bereit, optional über ein Content Delivery Network (CDN).

Sie können Azure Front Door oder ein anderes Content Delivery Network für die statischen Komponenten Ihrer Lösung wie Einseiten-JavaScript-Anwendungen und für statische Inhalte wie Bilddateien und Dokumente verwenden.

Je nach Design Ihrer Lösung können Sie möglicherweise auch mandantenspezifische Dateien oder Daten in einem Inhaltsübermittlungsnetzwerk zwischenspeichern, z. B. JSON-formatierte API-Antworten. Diese Vorgehensweise kann Ihnen helfen, die Leistung und Skalierbarkeit Ihrer Lösung zu verbessern. Stellen Sie sicher, dass mandantenspezifische Daten ausreichend isoliert bleiben, um Datenlecks über Mandanten hinweg zu verhindern. Ü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 die Einbindung der Mandantenkennung in den URL-Pfad können Sie steuern, ob Sie eine bestimmte Datei, alle Dateien eines bestimmten Mandanten oder alle Dateien sämtlicher Mandanten bereinigen.

Zu vermeidende Antimuster

Versäumnis, die Konnektivität virtueller Netzwerke zu planen

Durch die Bereitstellung von Ressourcen in virtuellen Netzwerken können Sie erheblich steuern, wie der Datenverkehr über die Komponenten Ihrer Lösung fließt. Die Integration virtueller Netzwerke führt jedoch auch zu mehr Komplexität, Kosten und anderen Faktoren, die Sie berücksichtigen müssen, insbesondere für PaaS-Komponenten (Platform as a Service).

Testen und planen Sie Ihre Netzwerkstrategie, um Probleme zu identifizieren, bevor Sie diese in einer Produktionsumgebung implementieren.

Fehlende Planung von Grenzwerten

Azure erzwingt viele Grenzwerte, die sich auf Netzwerkressourcen auswirken. Zu diesen Grenzwerten gehören Azure-Ressourcenlimits und grundlegende Protokoll- und Plattformgrenzwerte. Wenn Sie z. B. eine hochskalige Multitenantlösung auf Plattformdiensten wie App Service und Azure Functions erstellen, müssen Sie möglicherweise die Anzahl der TCP-Verbindungen (Transmission Control Protocol) und SNAT-Ports (Source Network Address Translation) berücksichtigen. Wenn Sie mit VMs und Lastenausgleichsmodulen arbeiten, müssen Sie auch Einschränkungen für ausgehende Regeln und SNAT-Ports berücksichtigen.

Kleine Subnetze

Dimensionieren Sie jedes Subnetz so, dass es die Anzahl der Ressourcen oder Ressourceninstanzen unterstützt, die Sie bereitstellen möchten, insbesondere bei der Skalierung. Wenn Sie mit PaaS-Ressourcen arbeiten, verstehen Sie, wie sich die Konfiguration und Skalierung Ihrer Ressource auf die Anzahl der IP-Adressen auswirken, die in ihrem Subnetz erforderlich sind.

Nicht ordnungsgemäße Netzwerksegmentierung

Wenn Ihre Lösung virtuelle Netzwerke erfordert, überlegen Sie, wie Sie die Netzwerksegmentierung konfigurieren, um eingehenden und ausgehenden Datenverkehr (als Nord-Süd-Datenverkehr bezeichnet) sowie Datenverkehr innerhalb Ihrer Lösung (als Ost-West-Datenverkehr bezeichnet) zu steuern. Entscheiden Sie, ob Mandanten über eigene virtuelle Netzwerke verfügen sollen oder ob Sie freigegebene Ressourcen in freigegebenen virtuellen Netzwerken bereitstellen sollten. Das Ändern des Ansatzes kann schwierig sein, daher sollten Sie alle Anforderungen sorgfältig berücksichtigen, bevor Sie einen Ansatz auswählen, der für Ihre zukünftigen Wachstumsziele geeignet ist.

Ausschließliches Verwenden von Sicherheitskontrollen auf Netzwerkebene

In modernen Lösungen sollten Sie die Sicherheit auf Netzwerkebene mit anderen Sicherheitskontrollen kombinieren. Verlassen Sie sich nicht nur auf Firewalls oder Netzwerksegmentierung. Dieser Ansatz wird manchmal als Zero Trust Networking bezeichnet. Verwenden Sie identitätsbasierte Steuerelemente, um Clients, Aufrufer oder Benutzer 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. Ihre Optionen hängen von den azure-Diensten ab, die Sie verwenden. In AKS sollten Sie ein Dienstgitter für die gegenseitige TLS-Authentifizierung verwenden und Netzwerkrichtlinien anwenden, um den Ost-West-Datenverkehr zu steuern. 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 benutzerdefinierte Domäne und die TLS-Verwaltung an das Gateway ausgelagert werden.

Aber Host-Header-Rewrites können für einige Back-End-Dienste Probleme verursachen. Wenn Ihre Anwendung HTTP-Umleitungen oder Cookies ausgibt, kann die Nichtübereinstimmung der Hostnamen die Funktionalität der Anwendung beeinträchtigen. Insbesondere kann dieses Problem auftreten, wenn Sie Back-End-Dienste verwenden, die auf einer Multitenant-Infrastruktur ausgeführt werden, z. B. App Service und Azure Functions. Weitere Informationen finden Sie in Bewährte Methoden zur Hostname-Beibehaltung.

Testen Sie das Verhalten Ihrer Anwendung mit der Gatewaykonfiguration, die Sie verwenden möchten.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Mitwirkende:

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

  • Zuletzt aktualisiert um