Delen via

Netwerken voor SaaS-workloads in Azure

  • Artikel

Uw netwerk biedt de backbone voor de manier waarop klanten toegang hebben tot uw SaaS-toepassing en maakt communicatie mogelijk tussen de onderdelen van uw oplossing. De manier waarop u uw netwerk ontwerpt, heeft een direct effect op de beveiliging, bewerkingen, kosten, prestaties en betrouwbaarheid van uw oplossing. Een gestructureerde benadering van uw netwerkstrategie wordt nog belangrijker naarmate uw cloudomgeving groeit.

Beslissen over een netwerkimplementatiestrategie en -topologie

SaaS-oplossingen hebben unieke netwerkvereisten. Naarmate u meer klanten onboardt en hun gebruik toeneemt, veranderen de netwerkvereisten. Het verwerken van groei kan lastig zijn vanwege beperkte resources, zoals IP-adresbereiken. Uw netwerkontwerp is van invloed op beveiliging en klantisolatie. Het plannen van uw netwerkstrategie helpt bij het beheren van groei, het verbeteren van de beveiliging en het verminderen van de operationele complexiteit.

Ontwerpoverwegingen

  • Plan uw netwerkimplementatiestrategie op basis van uw tenancymodel. Bepaal of uw netwerkbronnen worden gedeeld tussen klanten, toegewezen aan één klant of een combinatie. Deze keuze is van invloed op de functionaliteit, beveiliging en klantisolatie van uw toepassing.

    Het is gebruikelijk om netwerkresources, zoals virtuele netwerken en Azure Front Door-profielen, te delen tussen meerdere klanten. Deze aanpak vermindert de kosten en operationele overhead. Het vereenvoudigt ook de connectiviteit. U kunt eenvoudig de resources van een klant verbinden met gedeelde resources, zoals gedeelde opslagaccounts of een besturingsvlak.

    Toegewezen netwerkresources voor elke klant kunnen echter nodig zijn om hoge beveiliging en naleving tot stand te brengen. Als u bijvoorbeeld een hoge mate van netwerksegmentatie tussen klanten wilt ondersteunen, gebruikt u virtuele netwerken als grens. Toegewezen resources kunnen nodig zijn wanneer het aantal netwerkbronnen voor alle klanten de capaciteit van één gedeeld netwerk overschrijdt.

    Plan het aantal netwerkbronnen dat elke klant nodig heeft door onmiddellijk en toekomstige vereisten te overwegen. Klantvereisten en Azure-resourcelimieten kunnen specifieke resultaten afdwingen. Voor verschillende resources zijn mogelijk verschillende implementatiestrategieën vereist, zoals het gebruik van afzonderlijke netwerken voor peering van virtuele netwerken met virtuele Azure-netwerken die eigendom zijn van de klant.

    Zie De resourceorganisatie voor SaaS-workloads voor meer informatie over het delen van resources in een SaaS-oplossing.

  • Inzicht in netwerktopologieën. Netwerktopologieën vallen doorgaans in drie categorieën:

    • Plat netwerk: een enkel, geïsoleerd netwerk met subnetten voor segmentatie. Geschikt wanneer u één multitenant-toepassing met een eenvoudige netwerkindeling hebt. Platte netwerken kunnen resourcelimieten bereiken en meer netwerken vereisen wanneer u schaalt, waardoor de overhead en kosten toenemen. Als u van plan bent om meerdere toepassingen te hosten of speciale implementatiestempels binnen hetzelfde virtuele netwerk te gebruiken, hebt u mogelijk een complexe netwerkindeling nodig.

    • Hub en spoke: een gecentraliseerd hubnetwerk met peering naar geïsoleerde spoke-netwerken. Geschikt voor hoge schaalbaarheid en klantisolatie, omdat elke klant of toepassing een eigen spoke heeft en alleen communiceert met de hub. U kunt zo nodig snel meer spokes implementeren, zodat resources in de hub door alle spokes kunnen worden gebruikt. Transitieve of spoke-to-spoke-communicatie via de hub is standaard uitgeschakeld, waardoor klantisolatie in SaaS-oplossingen behouden blijft.

    • Geen netwerk: wordt gebruikt voor Azure PaaS-services waar u complexe workloads kunt hosten zonder virtuele netwerken te implementeren. Azure-app Service maakt bijvoorbeeld directe integratie met andere PaaS-services mogelijk via het Backbone-netwerk van Azure. Hoewel deze aanpak het beheer vereenvoudigt, beperkt het de flexibiliteit bij het implementeren van beveiligingscontroles en de mogelijkheid om de prestaties te optimaliseren. Deze benadering kan goed werken voor cloudeigen toepassingen. Naarmate uw oplossing zich ontwikkelt, verwacht u dat u in de loop van de tijd overstapt naar een hub-and-spoke-topologie.

      Compromis: Complexiteit en beveiliging. Beginnen zonder een gedefinieerde netwerkgrens kan de operationele last van het beheren van netwerkonderdelen, zoals beveiligingsgroepen, IP-adresruimte en firewalls, verminderen. Een netwerkperimeter is echter essentieel voor de meeste workloads. Als er geen netwerkbeveiligingscontroles zijn, vertrouwt u op sterk identiteits- en toegangsbeheer om uw werkbelasting te beschermen tegen schadelijk verkeer.

  • Begrijpen hoe architectuur voor meerdere regio's van invloed is op netwerktopologieën. In een architectuur met meerdere regio's met behulp van virtuele netwerken worden de meeste netwerkresources afzonderlijk geïmplementeerd in elke regio, omdat firewalls, virtuele netwerkgateways en netwerkbeveiligingsgroepen niet kunnen worden gedeeld tussen regio's.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Bepaal welke netwerkonderdelen worden gedeeld en welke onderdelen aan de klant zijn toegewezen.

Resources delen die per exemplaar in rekening worden gebracht, zoals Azure Firewall, Azure Bastion en Azure Front Door.		 Ervaring met evenwichtige ondersteuning tussen uw vereisten voor beveiliging en isolatie, terwijl u uw kosten en operationele lasten verlaagt.
Begin met een platte topologie of geen netwerkbenadering.

Controleer eerst de beveiligingsvereisten, omdat deze benaderingen beperkte isolatie en verkeerscontroles bieden.		 U kunt de complexiteit en kosten van uw oplossing verminderen met behulp van eenvoudigere netwerktopologieën.
Overweeg hub- en spoke-topologieën voor complexe behoeften of bij het implementeren van toegewezen virtuele netwerken per klant. Gebruik de hub voor het hosten van gedeelde netwerkbronnen in klantnetwerken. U kunt eenvoudiger schalen en uw kostenefficiëntie verbeteren door resources te delen via uw hubnetwerk.

Een beveiligde netwerkperimeter ontwerpen

Uw netwerkperimeter bepaalt de beveiligingsgrens tussen uw toepassing en andere netwerken, waaronder internet. Door uw netwerkperimeter te documenteren, kunt u onderscheid maken tussen verschillende typen verkeersstromen:

  • Inkomend verkeer, dat vanuit een externe bron binnenkomt in het netwerk.
  • Intern verkeer, dat tussen onderdelen binnen uw netwerk gaat.
  • Uitgaand verkeer, dat het netwerk verlaat.

Elke stroom omvat verschillende risico's en controles. Er zijn bijvoorbeeld meerdere beveiligingscontroles nodig om inkomend verkeer te inspecteren en te verwerken.

Belangrijk

Als algemene best practice volgt u altijd een benadering van nul vertrouwen. Zorg ervoor dat al het verkeer wordt beheerd en geïnspecteerd, inclusief intern verkeer.

Uw klanten hebben mogelijk ook specifieke nalevingsvereisten die van invloed zijn op uw architectuur. Als ze bijvoorbeeld SOC 2-naleving nodig hebben, moeten ze verschillende netwerkcontroles implementeren, waaronder een firewall, webtoepassingsfirewall en netwerkbeveiligingsgroepen, om te voldoen aan de beveiligingsvereisten. Zelfs als u niet onmiddellijk hoeft te voldoen, moet u rekening houden met deze uitbreidbaarheidsfactoren bij het ontwerpen van uw architectuur.

Raadpleeg aanbevelingen voor SE:06 voor netwerken en connectiviteit

Ontwerpoverwegingen

  • Inkomend verkeer beveiligen en beheren. Inspecteer dit verkeer op binnenkomende bedreigingen.

    Met firewalls kunt u schadelijke IP-adressen blokkeren en geavanceerde analyses uitvoeren om te beschermen tegen inbraakpogingen. Firewalls kunnen echter kostbaar zijn. Beoordeel uw beveiligingsvereisten om te bepalen of een firewall is vereist.

    Webtoepassingen zijn kwetsbaar voor veelvoorkomende aanvallen, zoals SQL-injectie, cross-site scripting en andere OWASP top 10 beveiligingsproblemen. Azure Web Application Firewall beschermt tegen deze aanvallen en is geïntegreerd met Application Gateway en Azure Front Door. Bekijk de lagen voor deze services om te begrijpen in welke WAF-mogelijkheden zich bevinden in welke producten.

    DDoS-aanvallen zijn een risico voor internetgerichte toepassingen. Azure biedt gratis basisbeveiligingsniveau. Azure DDoS Protection biedt geavanceerde beveiliging door uw verkeerspatronen te leren en de beveiligingen dienovereenkomstig aan te passen, hoewel ze tegen een prijs komen. Als u Front Door gebruikt, profiteert u van de ingebouwde DDoS-mogelijkheden.

    Naast beveiliging kunt u ook inkomend verkeer manipuleren om de prestaties van uw toepassing te verbeteren door caching en taakverdeling te gebruiken.

    Overweeg om een reverse proxy-service zoals Azure Front Door te gebruiken voor globaal HTTP(S)-verkeerbeheer. U kunt ook Application Gateway of andere Azure-services gebruiken voor inkomend verkeer. Zie Opties voor taakverdeling voor meer informatie over opties voor taakverdeling in Azure.

  • Intern verkeer beveiligen. Zorg ervoor dat verkeer tussen uw toepassing en de bijbehorende onderdelen veilig is om schadelijke toegang te voorkomen. Beveilig deze resources en verbeter de prestaties met behulp van intern verkeer in plaats van routering via internet. Azure Private Link wordt vaak gebruikt om verbinding te maken met Azure-resources via een intern IP-adres in uw netwerk. Voor sommige resourcetypen kunnen service-eindpunten een rendabeler alternatief zijn. Als u openbare internetverbinding voor uw resources inschakelt, moet u begrijpen hoe u verkeer beperkt met behulp van IP-adressen en toepassingsidentiteiten, zoals beheerde identiteiten.

  • Uitgaand verkeer beveiligen. In sommige oplossingen inspecteert u uitgaand verkeer om gegevensexfiltratie te voorkomen, met name voor naleving van regelgeving en zakelijke klanten. Gebruik firewalls om uitgaand verkeer te beheren en te controleren, waardoor verbindingen met niet-geautoriseerde locaties worden geblokkeerd.

  • Plan hoe u uitgaande connectiviteit en SNAT schaalt. Poortuitputting van bronnetwerkadresomzetting (SNAT) kan van invloed zijn op multitenant-toepassingen. Deze toepassingen hebben vaak afzonderlijke netwerkverbindingen nodig voor elke tenant en het delen van resources tussen klanten verhoogt het risico op SNAT-uitputting naarmate uw klantenbestand groeit. U kunt SNAT-uitputting beperken met behulp van Azure NAT Gateway, firewalls zoals Azure Firewall of een combinatie van de twee benaderingen.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Onderhoud een catalogus met de netwerkeindpunten die beschikbaar zijn voor internet. Leg details vast, zoals IP-adres (indien statisch), hostnaam, poorten, gebruikte protocollen en reden voor verbindingen.

Documenteer hoe u elk eindpunt wilt beveiligen.		 Deze lijst vormt de basis van uw perimeterdefinitie, zodat u expliciete beslissingen kunt nemen over het beheren van verkeer via uw oplossing.
Meer informatie over de mogelijkheden van De Azure-service om de toegang te beperken en de beveiliging te verbeteren.

Het beschikbaar maken van eindpunten voor opslagaccounts aan klanten vereist bijvoorbeeld aanvullende besturingselementen, zoals handtekeningen voor gedeelde toegang, firewalls voor opslagaccounts en het gebruik van afzonderlijke opslagaccounts voor intern en extern gebruik.		 U kunt besturingselementen selecteren die voldoen aan uw behoeften op het gebied van beveiliging, kosten en prestaties.
Gebruik voor HTTP(S)-toepassingen een omgekeerde proxy, zoals Azure Front Door of Application Gateway. Omgekeerde proxy's bieden een breed scala aan mogelijkheden voor prestatieverbeteringen, tolerantie, beveiliging en om de operationele complexiteit te verminderen.
Inspecteer inkomend verkeer met behulp van een webtoepassingsfirewall.

Vermijd het beschikbaar maken van webbronnen zoals een App Service of Azure Kubernetes Service (AKS) rechtstreeks op internet.		 U kunt uw webtoepassingen effectiever beschermen tegen veelvoorkomende bedreigingen en de algehele blootstelling van uw oplossing verminderen.
Bescherm uw toepassing tegen DDoS-aanvallen.

Gebruik Azure Front Door of Azure DDoS Protection, afhankelijk van de protocollen die worden gebruikt door uw openbare eindpunten.		 Bescherm uw oplossing tegen een veelvoorkomend type aanval.
Als voor uw toepassing uitgaande connectiviteit op schaal is vereist, gebruikt u NAT Gateway of een firewall om extra SNAT-poorten te bieden. U kunt hogere schaalniveaus ondersteunen.

Onderlinge netwerkconnectiviteit

Voor sommige scenario's moet u mogelijk verbinding maken met resources buiten Azure, zoals gegevens binnen het privénetwerk van een klant of assets in een andere cloudprovider in een installatie met meerdere clouds. Deze behoeften kunnen uw netwerkontwerp bemoeilijken, waarbij verschillende benaderingen nodig zijn om connectiviteit tussen netwerken te implementeren op basis van uw specifieke vereisten.

Ontwerpoverwegingen

  • Identificeer de eindpunten waarmee de toepassing verbinding nodig heeft. De toepassing moet mogelijk communiceren met andere services, zoals opslagservices en databases. Documenteer hun eigenaar, locatie en verbindingstype. Vervolgens kunt u de juiste methode kiezen om verbinding te maken met deze eindpunten. Veelvoorkomende benaderingen zijn:

    Resourcelocatie Eigenaar Connectiviteitsopties om rekening mee te houden
    Azure Customer
    • Privé-eindpunt (tussen Microsoft Entra ID-tenants)
    • Peering van virtuele netwerken (tussen Microsoft Entra ID-tenants)
    • Service-eindpunt (tussen Microsoft Entra ID-tenants)
    Andere cloudprovider ISV of klant
    • Site-naar-site-VPN
    • ExpressRoute
    • Internet
    On-premises ISV of klant
    • Site-naar-site-VPN
    • ExpressRoute
    • Internet

    • Private Link en privé-eindpunt. Veilige connectiviteit bieden met verschillende Azure-resources, waaronder interne load balancers voor virtuele machines. Ze maken privétoegang tot uw SaaS-oplossing mogelijk voor klanten, hoewel ze kostenoverwegingen hebben.

      Compromis: Beveiliging en kosten. Private Link zorgt ervoor dat uw verkeer binnen uw privénetwerk blijft en wordt aanbevolen voor netwerkconnectiviteit tussen Microsoft Entra-tenants. Voor elk privé-eindpunt worden echter kosten in rekening gebracht, die kunnen worden opgetellen op basis van uw beveiligingsbehoeften. Service-eindpunten kunnen een rendabel alternatief zijn, waardoor verkeer op het Microsoft backbone-netwerk wordt behouden en tegelijkertijd een bepaald niveau van privéconnectiviteit wordt geboden.

    • Service-eindpunt. Routeert verkeer naar PaaS-resources via het backbone-netwerk van Microsoft, waardoor service-naar-service-communicatie wordt beveiligd. Ze kunnen rendabel zijn voor toepassingen met hoge bandbreedte, maar vereisen het configureren en onderhouden van toegangsbeheerlijsten voor beveiliging. Ondersteuning voor service-eindpunten in Microsoft Entra ID-tenants verschilt per Azure-service. Raadpleeg de productdocumentatie voor elke service die u gebruikt.

    • Peering van virtuele netwerken verbindt twee virtuele netwerken, waardoor resources in het ene netwerk toegang hebben tot IP-adressen in het andere netwerk. Het vereenvoudigt de connectiviteit met privé-resources in een virtueel Azure-netwerk. Toegang kan worden beheerd met behulp van netwerkbeveiligingsgroepen, maar het afdwingen van isolatie kan lastig zijn. Daarom is het belangrijk om uw netwerktopologie te plannen op basis van specifieke behoeften van klanten.

    • Virtuele particuliere netwerken (VPN's) maken een beveiligde tunnel via internet tussen twee netwerken, waaronder tussen cloudproviders en on-premises locaties. Site-naar-site VPN's maken gebruik van netwerkapparaten in elk netwerk voor configuratie. Ze bieden een voordelige connectiviteitsoptie, maar vereisen installatie en garanderen geen voorspelbare doorvoer.

    • ExpressRoute biedt een toegewezen, krachtige privéverbinding tussen Azure en andere cloudproviders of on-premises netwerken. Het zorgt voor voorspelbare prestaties en vermijdt internetverkeer, maar wordt geleverd met hogere kosten en vereist complexere configuratie.

  • Plan op basis van de bestemming. Mogelijk moet u verbinding maken met resources in verschillende Microsoft Entra ID-tenants, met name als de doelresource zich in het Azure-abonnement van een klant bevindt. Overweeg het gebruik van privé-eindpunten, een site-naar-site-VPN of door virtuele netwerken te peeren. Zie Peering virtual networks in verschillende Microsoft Entra ID-tenants voor meer informatie.

    Als u verbinding wilt maken met resources die worden gehost in een andere cloudprovider, is het gebruikelijk om openbare internetverbinding, een site-naar-site-VPN of ExpressRoute te gebruiken. Zie Connectiviteit met andere cloudproviders voor meer informatie.

  • Inzicht in de gevolgen van connectiviteit op uw netwerktopologie. Een virtueel Azure-netwerk kan slechts één virtuele netwerkgateway hebben, die via site-naar-site-VPN of ExpressRoute verbinding kan maken met meerdere locaties. Er gelden echter limieten voor het aantal verbindingen via een gateway en het isoleren van klantverkeer kan lastig zijn. Plan voor meerdere verbindingen met verschillende locaties uw netwerktopologie dienovereenkomstig, mogelijk door een afzonderlijk virtueel netwerk voor elke klant te implementeren.

  • Inzicht in de implicaties voor het plannen van IP-adressen. Sommige connectiviteitsmethoden bieden automatisch NAT (Network Address Translation), waardoor problemen met overlappende IP-adressen worden vermeden. Peering van virtuele netwerken en ExpressRoute voeren echter geen NAT uit. Wanneer u deze methoden gebruikt, moet u uw netwerkbronnen en IP-adrestoewijzingen zorgvuldig plannen om overlappende IP-adresbereiken te voorkomen en toekomstige groei te garanderen. Het plannen van IP-adressen kan complex zijn, met name wanneer u verbinding maakt met derden zoals klanten, dus houd rekening met mogelijke conflicten met hun IP-bereiken.

  • Meer informatie over facturering via uitgaand netwerk. Azure factureert doorgaans voor uitgaand netwerkverkeer wanneer het microsoft-netwerk verlaat of tussen Azure-regio's wordt verplaatst. Bij het ontwerpen van oplossingen voor meerdere regio's of multiclouds is het belangrijk om inzicht te krijgen in de gevolgen voor de kosten. Architectuurkeuzen, zoals het gebruik van Azure Front Door of ExpressRoute, kunnen van invloed zijn op de kosten voor netwerkverkeer.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Geef de voorkeur aan privénetwerken om verbinding te maken tussen netwerken om prioriteit te geven aan beveiliging.

Overweeg alleen routering via internet na het evalueren van de bijbehorende gevolgen voor beveiliging en prestaties.		 Privéverkeer doorkruist een beveiligd netwerkpad, wat helpt bij het verminderen van veel soorten beveiligingsrisico's.
Wanneer u verbinding maakt met klantbronnen die worden gehost in hun Azure-omgevingen, gebruikt u Private Link, service-eindpunten of peerings voor virtuele netwerken. U kunt verkeer op het Microsoft-netwerk houden, wat helpt kosten en operationele complexiteit te verminderen in vergelijking met andere benaderingen.
Wanneer u verbinding maakt tussen cloudproviders of on-premises netwerken, gebruikt u site-naar-site VPN's of ExpressRoute. Deze technologieën bieden beveiligde verbindingen tussen providers.

Implementeren in omgevingen die eigendom zijn van klanten

Voor uw bedrijfsmodel moet u mogelijk de toepassing of de bijbehorende onderdelen hosten in de Azure-omgeving van een klant. De klant beheert zijn eigen Azure-abonnement en betaalt rechtstreeks de kosten van resources die nodig zijn om de toepassing uit te voeren. Als oplossingsprovider bent u verantwoordelijk voor het beheren van de oplossing, zoals de eerste implementatie, het toepassen van configuratie en het implementeren van updates voor de toepassing.

In dergelijke situaties brengen klanten vaak hun eigen netwerk mee en implementeren ze uw toepassing in een netwerkruimte die ze definiëren. Azure Managed Applications biedt mogelijkheden om dit proces te vergemakkelijken. Zie Bestaand virtueel netwerk gebruiken met Azure Managed Applications voor meer informatie.

Ontwerpoverwegingen

  • IP-adresbereiken en conflicten. Wanneer klanten virtuele netwerken implementeren en beheren, zijn ze verantwoordelijk voor het afhandelen van netwerkconflicten en schalen. U moet echter verschillende scenario's voor klantgebruik verwachten. Plan implementaties in omgevingen met minimale IP-adresruimte door efficiënt IP-adressen te gebruiken en vermijd hardcoderings-IP-adresbereiken om overlappingen met klantbereiken te voorkomen.

    U kunt ook een toegewezen virtueel netwerk voor uw oplossing implementeren. U kunt Private Link of peering van virtuele netwerken gebruiken om klanten in staat te stellen verbinding te maken met de resources. Deze benaderingen worden beschreven in connectiviteit tussen netwerken. Als u inkomend en uitgaand verkeer hebt gedefinieerd, evalueert u NAT als een benadering om problemen te voorkomen die worden veroorzaakt door overlappingen van IP-adressen.

  • Netwerktoegang bieden voor beheerdoeleinden. Bekijk de resources die u implementeert in klantomgevingen en plan hoe u ze opent om ze te bewaken, beheren of opnieuw te configureren. Wanneer resources worden geïmplementeerd met privé-IP-adressen in een omgeving die eigendom is van de klant, moet u ervoor zorgen dat u een netwerkpad hebt om ze te bereiken vanuit uw eigen netwerk. Overweeg hoe u zowel toepassings- als resourcewijzigingen faciliteert, zoals het pushen van een nieuwe versie van de toepassing of het bijwerken van een Azure-resourceconfiguratie.

    In sommige oplossingen kunt u mogelijkheden van Azure Managed Applications gebruiken, zoals Just-In-Time-toegang en implementatie van updates voor toepassingen. Als u meer controle nodig hebt, kunt u een eindpunt hosten binnen het netwerk van de klant waarmee uw besturingsvlak verbinding kan maken, waardoor u toegang krijgt tot uw resources. Voor deze methode zijn extra Azure-resources en -ontwikkeling vereist om te voldoen aan de beveiligings-, operationele en prestatievereisten. Zie Het voorbeeld van het bijwerken van azure beheerde toepassingen voor een voorbeeld van hoe u deze aanpak implementeert.

Ontwerpaanaanvelingen

Aanbeveling Voordeel
Azure Managed Applications gebruiken om door de klant geïmplementeerde resources te implementeren en te beheren. Azure Managed Applications biedt een scala aan mogelijkheden waarmee u resources binnen het Azure-abonnement van een klant kunt implementeren en beheren.
Minimaliseer het aantal IP-adressen dat u gebruikt binnen de ruimte van het virtuele netwerk van de klant. Klanten hebben vaak beperkte beschikbaarheid van IP-adressen. Door uw footprint te minimaliseren en uw schaal te ontkoppelen van het IP-adresgebruik, kunt u het aantal klanten uitbreiden dat uw oplossing kan gebruiken en hogere groeiniveaus mogelijk maken.
Plan hoe u netwerktoegang krijgt voor het beheren van resources in klantomgevingen, rekening houdend met bewaking, wijzigingen in de resourceconfiguratie en toepassingsupdates. U kunt de resources die u beheert rechtstreeks configureren.
Bepaal of u een toegewezen virtueel netwerk wilt implementeren of wilt integreren met het bestaande virtuele netwerk van een klant. Door van tevoren te plannen, zorgt u ervoor dat u aan de vereisten van uw klanten voor isolatie, beveiliging en integratie met hun andere systemen kunt voldoen.
Openbare toegang op Azure-resources standaard uitschakelen. Geef waar mogelijk de voorkeur aan privé-inkomend verkeer. U beperkt het bereik van netwerkbronnen die u en uw klanten moeten beveiligen.

Aanvullende bronnen

Multitenancy is een kernbedrijfsmethodologie voor het ontwerpen van SaaS-workloads. Deze artikelen bevatten meer informatie over het netwerkontwerp:

Volgende stap

Meer informatie over de overwegingen voor het gegevensplatform voor gegevensintegriteit en prestaties voor SaaS-workloads in Azure.

Ontwerpgebied: Gegevens voor SaaS-workloads in Azure