Freigeben über

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

Alle lösungen, die in Azure bereitgestellt werden, erfordern eine Art Netzwerk. 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. Sie enthält Informationen zu Komponenten auf niedrigerer Ebene, z. B. virtuelle Netzwerke, und erweitert sich auf Ansätze auf höherer Ebene und anwendungsebene.

Hinweis

Azure ist eine mehrinstanzenfähige Umgebung, wie viele seiner Netzwerkkomponenten. 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 Computer (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. bestimmte Netzwerksteuerelemente verwenden. Weitere Informationen finden Sie unter Architekturansätze für Governance und Compliance in multiinstanzenübergreifenden Lösungen.

  • Anforderungen Ihrer Mandanten: Auch wenn Ihre Organisation keine Anforderungen für die Netzwerkschichtisolation oder -steuerelemente definiert hat, können Ihre Mandanten. Verstehen Sie, wie Ihre Mandanten auf Ihre Lösung zugreifen und ob sie annahmen, dass sie über das Netzwerkdesign verfügen.

  • Kompliziertheit: Virtuelle Netzwerke führen zu Komplexität. Stellen Sie sicher, dass Ihr Team die Prinzipien klar versteht, um die Bereitstellung einer unsicheren Umgebung zu vermeiden.

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

Größe Ihrer Subnetze

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 die Anzahl der IP-Adressen, die 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 verstehen Sie, wenn Sie mit verwalteten Diensten arbeiten, wie sie IP-Adressen nutzen. Wenn Sie beispielsweise AKS mit Azure Container Networking Interface (CNI) verwenden, basieren die Anzahl der von einem Subnetz verbrauchten IP-Adressen auf Faktoren wie der Anzahl der Knoten, der horizontalen Skalierung und des Dienstbereitstellungsprozesses. 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 Mandanten über das Internet oder über private IP-Adressen auf Ihre Dienste zugreifen müssen.

Um Ihren Dienst für den internetbasierten (öffentlichen) Zugriff zu schützen, verwenden Sie Firewallregeln, IP-Adressen-Zulassungsliste und Ablehnung, freigegebene Geheimschlüssel 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 Mehrinstanzenlösung berücksichtigt werden sollen. Sie beginnt mit Ansätzen auf niedrigerer Ebene für Kernnetzwerkkomponenten und beschreibt dann Ansätze für HTTP und andere Probleme 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 ausführen. 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 Datenverkehr zentral zu steuern und zu gehen.

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 den vorhandenen Adressräumen in Konflikt.

Mandantenspezifische virtuelle Netzwerke mit mandantenspezifischen 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 ermöglicht es Ihnen, ein zentrales virtuelles Hub-Netzwerk mit mehreren speichen virtuellen Netzwerken zu peeren. Sie können den Datenverkehr für Ihre virtuellen Netzwerke zentral steuern und steuern, ob die Ressourcen im virtuellen Netzwerk der einzelnen Speichen miteinander kommunizieren können. Jedes virtuelle Speichennetzwerk 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 Grenzwerte wie die maximale Anzahl von virtuellen Peernetzwerken. 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 einem Speichen 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 Bereitstellungsstempelmuster 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 Anforderungslatenz 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 ein Lastenausgleichsmodul oder eine Firewall sowohl für eingehende als auch für ausgehende statische IP-Adressen 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 zum Azure NAT-Gateway für mehrinstanzenfähige.

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

Damit Ihre Mandanten Nachrichten empfangen können, die von Ihrer Lösung initiiert werden oder auf Daten in den Netzwerken Ihrer Mandanten zugreifen können, sollten Sie einen Agent bereitstellen, der manchmal als lokales Gateway bezeichnet wird, das 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 Agent beseitigt die Notwendigkeit, dass Mandanten dieses Risiko übernehmen müssen.

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 Privaten Link-Dienst mit ihrem eigenen virtuellen Netzwerk verwenden, um von einer lokalen Umgebung aus auf Ihren Dienst zuzugreifen. Azure leitet den Datenverkehr sicher mithilfe privater IP-Adressen an den Dienst weiter.

Weitere Informationen finden Sie unter "Mehrinstanzenfähigkeit" und "Privater 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 Gateways. Gateways bieten Kerndienste für eine mehrinstanzenfähige Anwendung, einschließlich der folgenden Funktionen:

  • Weiterleiten von Anforderungen an mandantenspezifische Back-Ends oder Bereitstellungsstempel
  • Behandeln mandantenspezifischer Domänennamen und TLS-Zertifikate
  • Überprüfen von Anforderungen 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, Anwendungsgateway 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. Sie sollten auch verstehen, wie die Gatewaykomponente skaliert wird, um Ihr Datenverkehrs- und Mandantenwachstum zu unterstützen.

Muster für das Hosten von statischen Inhalten

Das Muster für das Hosting statischer Inhalte dient Webinhalten aus einem cloudeigenen Speicherdienst und verwendet ein Netzwerk für die Inhaltsübermittlung, um den Inhalt zwischenzuspeichern.

Sie können Azure Front Door oder ein anderes Netzwerk für die Inhaltsübermittlung 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. Indem Sie den Mandantenbezeichner in den URL-Pfad einschließen, können Sie steuern, ob Sie eine bestimmte Datei löschen, alle Dateien, die sich auf einen bestimmten Mandanten beziehen, oder alle Dateien für alle Mandanten.

Zu vermeidende Antimuster

Fehler beim Planen der Virtuellen Netzwerkkonnektivität

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 sie 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

Skalieren Sie jedes Subnetz, um die Anzahl der Ressourcen oder Instanzen von Ressourcen zu unterstützen, 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 den Client, den Anrufer oder den 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.

Kopfzeilenumschreibungen können jedoch Host Probleme für einige Back-End-Dienste 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 in mehrinstanzenfähiger Infrastruktur ausgeführt werden, z. B. App Service und Azure Functions. Weitere Informationen finden Sie unter bewährte Methoden zur Erhaltung von Hostnamen.

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.

  • Last updated on