Udostępnij za pośrednictwem

Sieć dla obciążeń SaaS na platformie Azure

  • Artykuł

Sieć zapewnia szkielet, w jaki sposób klienci uzyskują dostęp do aplikacji SaaS i umożliwiają komunikację między składnikami rozwiązania. Sposób projektowania sieci ma bezpośredni wpływ na zabezpieczenia, operacje, koszty, wydajność i niezawodność rozwiązania. Ustrukturyzowane podejście do strategii sieciowej staje się jeszcze ważniejsze w miarę rozwoju środowiska chmury.

Wybieranie strategii wdrażania sieci i topologii

Rozwiązania SaaS mają unikatowe wymagania dotyczące sieci. W miarę dołączania większej liczby klientów i ich użycia zmieniają się wymagania dotyczące sieci. Obsługa wzrostu może być trudna ze względu na ograniczone zasoby, takie jak zakresy adresów IP. Projekt sieci ma wpływ na bezpieczeństwo i izolację klientów. Planowanie strategii sieci pomaga zarządzać wzrostem, poprawić bezpieczeństwo i zmniejszyć złożoność operacyjną.

Uwagi dotyczące projektowania

  • Zaplanuj strategię wdrażania sieci na podstawie modelu dzierżawy. Zdecyduj, czy zasoby sieciowe będą współużytkowane przez klientów, przeznaczone dla jednego klienta, czy też kombinacji. Ten wybór wpływa na funkcjonalność, zabezpieczenia i izolację klientów aplikacji.

    Wspólne jest udostępnianie zasobów sieciowych, takich jak sieci wirtualne i profile usługi Azure Front Door, wśród wielu klientów. Takie podejście zmniejsza koszty i nakłady operacyjne. Upraszcza również łączność. Zasoby klienta można łatwo połączyć z zasobami udostępnionymi, takimi jak udostępnione konta magazynu lub płaszczyzna sterowania.

    Jednak dedykowane zasoby sieciowe dla każdego klienta mogą być konieczne do ustanowienia wysokich zabezpieczeń i zgodności. Na przykład w celu obsługi wysokiego stopnia segmentacji sieci między klientami należy używać sieci wirtualnych jako granicy. Zasoby dedykowane mogą być konieczne, gdy liczba zasobów sieciowych dla wszystkich klientów przekracza pojemność pojedynczej udostępnionej sieci.

    Zaplanuj liczbę zasobów sieciowych, których potrzebuje każdy klient, uwzględniając natychmiastowe i przyszłe wymagania. Wymagania klienta i limity zasobów platformy Azure mogą wymuszać określone wyniki. Różne zasoby mogą wymagać różnych strategii wdrażania, takich jak używanie oddzielnych sieci do komunikacji równorzędnej sieci wirtualnych z sieciami wirtualnymi należącymi do klienta.

    Aby uzyskać więcej informacji na temat udostępniania zasobów w rozwiązaniu SaaS, zobacz Organizacja zasobów dla obciążeń SaaS.

  • Omówienie topologii sieci. Topologie sieci zwykle należą do trzech kategorii:

    • Sieć płaska: pojedyncza, izolowana sieć z podsieciami na potrzeby segmentacji. Odpowiednie, gdy masz jedną aplikację wielodostępną z prostym układem sieciowym. Sieci płaskie mogą osiągać limity zasobów i wymagać większej liczby sieci w miarę skalowania, zwiększania obciążenia i kosztów. Jeśli planujesz hostować wiele aplikacji lub używać dedykowanych sygnatur wdrażania w tej samej sieci wirtualnej, może być potrzebny złożony układ sieci.

    • Piasta i szprycha: scentralizowana sieć piasty z komunikacją równorzędną z izolowanymi sieciami szprych. Nadaje się do wysokiej skalowalności i izolacji klientów, ponieważ każdy klient lub aplikacja ma własną szprychę, komunikując się tylko z koncentratorem. W razie potrzeby można szybko wdrożyć więcej szprych, aby zasoby w koncentratonie mogły być używane przez wszystkie szprychy. Przechodnia komunikacja między szprychami lub szprychami jest domyślnie wyłączona, co pomaga zachować izolację klientów w rozwiązaniach SaaS.

    • Brak sieci: służy do obsługi usług PaaS platformy Azure, w których można hostować złożone obciążenia bez wdrażania sieci wirtualnych. Na przykład usługa aplikacja systemu Azure umożliwia bezpośrednią integrację z innymi usługami PaaS za pośrednictwem sieci szkieletowej platformy Azure. Chociaż takie podejście upraszcza zarządzanie, ogranicza elastyczność wdrażania mechanizmów kontroli zabezpieczeń i możliwości optymalizacji wydajności. Takie podejście może działać dobrze w przypadku aplikacji natywnych dla chmury. W miarę rozwoju rozwiązania należy spodziewać się przejścia do topologii piasty i szprych w czasie.

      Kompromis: Złożoność i bezpieczeństwo. Rozpoczęcie bez zdefiniowanej granicy sieci może zmniejszyć obciążenie operacyjne związane z zarządzaniem składnikami sieciowymi, takimi jak grupy zabezpieczeń, przestrzeń adresowa IP i zapory. Jednak obwód sieci jest niezbędny w przypadku większości obciążeń. W przypadku braku mechanizmów kontroli zabezpieczeń sieci polegaj na silnej tożsamości i zarządzaniu dostępem, aby chronić obciążenie przed złośliwym ruchem.

  • Dowiedz się, jak architektura z wieloma regionami ma wpływ na topologie sieci. W architekturze obejmującej wiele regionów przy użyciu sieci wirtualnych większość zasobów sieciowych jest wdrażana oddzielnie w każdym regionie, ponieważ zapory, bramy sieci wirtualnej i sieciowe grupy zabezpieczeń nie mogą być współużytkowane między regionami.

Zalecenia dotyczące projektowania

Zalecenie Korzyści
Zdecyduj, które składniki sieciowe są współużytkowane i które składniki są przeznaczone dla klienta.

Udostępnianie zasobów, które są naliczane za wystąpienie, takie jak Azure Firewall, Azure Bastion i Azure Front Door.		 Korzystaj ze zrównoważonych obsługi między wymaganiami dotyczącymi zabezpieczeń i izolacji, jednocześnie zmniejszając koszty i obciążenie operacyjne.
Zacznij od płaskiej topologii lub bez podejścia do sieci.

Należy najpierw zapoznać się z wymaganiami dotyczącymi zabezpieczeń, ponieważ te podejścia oferują ograniczoną izolację i kontrolę ruchu.		 Złożoność i koszt rozwiązania można zmniejszyć, korzystając z prostszych topologii sieci.
Rozważ topologie piasty i szprych pod kątem złożonych potrzeb lub podczas wdrażania dedykowanych sieci wirtualnych na klienta. Użyj centrum do hostowania udostępnionych zasobów sieciowych w sieciach klientów. Możesz łatwiej skalować i zwiększyć efektywność kosztową, udostępniając zasoby za pośrednictwem sieci koncentratora.

Projektowanie bezpiecznego obwodu sieci

Obwód sieci ustanawia granicę zabezpieczeń między aplikacją a innymi sieciami, w tym Internetem. Dokumentując obwód sieci, można odróżnić różne typy przepływów ruchu:

  • Ruch przychodzący, który dociera do sieci ze źródła zewnętrznego.
  • Ruch wewnętrzny, który przechodzi między składnikami w sieci.
  • Ruch wychodzący, który opuszcza sieć.

Każdy przepływ obejmuje różne czynniki ryzyka i mechanizmy kontroli. Na przykład do inspekcji i przetwarzania ruchu przychodzącego potrzebne jest wiele mechanizmów kontroli zabezpieczeń.

Ważne

Najlepszym rozwiązaniem jest zawsze przestrzeganie podejścia zerowego zaufania. Upewnij się, że cały ruch jest kontrolowany i sprawdzany, w tym ruch wewnętrzny.

Klienci mogą również mieć określone wymagania dotyczące zgodności, które wpływają na architekturę. Jeśli na przykład potrzebują zgodności SOC 2, muszą zaimplementować różne mechanizmy kontroli sieci, w tym zaporę, zaporę aplikacji internetowej i sieciowe grupy zabezpieczeń, aby spełnić wymagania dotyczące zabezpieczeń. Nawet jeśli nie musisz natychmiast przestrzegać tych czynników rozszerzalności podczas projektowania architektury.

Zapoznaj się z tematem SE:06 Recommendations for networking and connectivity (Zalecenia dotyczące sieci i łączności)

Uwagi dotyczące projektowania

  • Ochrona ruchu przychodzącego i zarządzanie nim. Sprawdź ten ruch pod kątem zagrożeń przychodzących.

    Zapory umożliwiają blokowanie złośliwych adresów IP i wykonywanie zaawansowanych analiz w celu ochrony przed próbami włamania. Jednak zapory mogą być kosztowne. Oceń wymagania dotyczące zabezpieczeń, aby określić, czy zapora jest wymagana.

    Aplikacje internetowe są narażone na typowe ataki, takie jak wstrzyknięcie kodu SQL, wykonywanie skryptów między witrynami i inne luki w zabezpieczeniach OWASP 10. Usługa Azure Web Application Firewall chroni przed tymi atakami i jest zintegrowana z usługą Application Gateway i usługą Azure Front Door. Przejrzyj warstwy dla tych usług, aby dowiedzieć się, które funkcje zapory aplikacji internetowej są w jakich produktach.

    Ataki DDoS są zagrożeniem dla aplikacji dostępnych w Internecie. Platforma Azure zapewnia podstawowy poziom ochrony bez ponoszenia kosztów. Usługa Azure DDoS Protection zapewnia zaawansowaną ochronę, ucząc się wzorców ruchu i odpowiednio dostosowując ochronę, choć są one kosztowne. Jeśli używasz usługi Front Door, skorzystaj z wbudowanych funkcji DDoS.

    Poza zabezpieczeniami można również manipulować ruchem przychodzącym w celu zwiększenia wydajności aplikacji przy użyciu buforowania i równoważenia obciążenia.

    Rozważ użycie usługi zwrotnego serwera proxy, takiej jak Azure Front Door, na potrzeby globalnego zarządzania ruchem HTTP(S). Alternatywnie użyj usługi Application Gateway lub innych usług platformy Azure na potrzeby kontroli ruchu przychodzącego. Aby dowiedzieć się więcej na temat opcji równoważenia obciążenia na platformie Azure, zobacz Opcje równoważenia obciążenia.

  • Ochrona ruchu wewnętrznego. Upewnij się, że ruch między aplikacją a jej składnikami jest bezpieczny, aby zapobiec złośliwemu dostępowi. Chroń te zasoby i zwiększ wydajność przy użyciu ruchu wewnętrznego zamiast routingu przez Internet. Usługa Azure Private Link jest często używana do łączenia się z zasobami platformy Azure za pośrednictwem wewnętrznego adresu IP w sieci. W przypadku niektórych typów zasobów punkty końcowe usługi mogą być bardziej opłacalną alternatywą. Jeśli włączysz publiczną łączność z Internetem dla zasobów, dowiedz się, jak ograniczyć ruch przy użyciu adresów IP i tożsamości aplikacji, takich jak tożsamości zarządzane.

  • Ochrona ruchu wychodzącego. W niektórych rozwiązaniach sprawdź ruch wychodzący, aby zapobiec eksfiltracji danych, zwłaszcza w przypadku zgodności z przepisami i klientów korporacyjnych. Za pomocą zapór można zarządzać ruchem wychodzącym i przeglądać go, blokując połączenia z nieautoryzowanymi lokalizacjami.

  • Planowanie skalowania łączności wychodzącej i sieci SNAT. Wyczerpanie portów translacji adresów sieciowych (SNAT) źródła może mieć wpływ na aplikacje wielodostępne. Te aplikacje często potrzebują odrębnych połączeń sieciowych dla każdej dzierżawy i współużytkowania zasobów między klientami zwiększają ryzyko wyczerpania SNAT w miarę wzrostu bazy klientów. Możesz wyeliminować wyczerpanie translatora adresów sieciowych przy użyciu usługi Azure NAT Gateway, zapór, takich jak usługa Azure Firewall, lub kombinacji tych dwóch podejść.

Zalecenia dotyczące projektowania

Zalecenie Korzyści
Zachowaj wykaz punktów końcowych sieci, które są uwidocznione w Internecie. Przechwyć szczegóły, takie jak adres IP (jeśli statyczny), nazwa hosta, porty, używane protokoły i uzasadnienie połączeń.

Dokumentowanie sposobu ochrony każdego punktu końcowego.		 Ta lista stanowi podstawę definicji obwodowej, umożliwiając podejmowanie jawnych decyzji dotyczących zarządzania ruchem za pośrednictwem rozwiązania.
Omówienie możliwości usługi platformy Azure w celu ograniczenia dostępu i zwiększenia ochrony.

Na przykład uwidacznianie punktów końcowych konta magazynu klientom wymaga dodatkowych mechanizmów kontroli, takich jak sygnatury dostępu współdzielonego, zapory konta magazynu i używanie oddzielnych kont magazynu do użytku wewnętrznego i zewnętrznego.		 Możesz wybrać mechanizmy kontroli spełniające wymagania dotyczące zabezpieczeń, kosztów i wydajności.
W przypadku aplikacji opartych na protokole HTTP użyj zwrotnego serwera proxy, takiego jak azure Front Door lub Application Gateway. Odwrotne serwery proxy zapewniają szeroką gamę możliwości usprawnień wydajności, odporności, zabezpieczeń i zmniejszenia złożoności operacyjnej.
Sprawdź ruch przychodzący przy użyciu zapory aplikacji internetowej.

Unikaj uwidaczniania zasobów internetowych, takich jak usługa App Service lub usługa Azure Kubernetes Service (AKS) bezpośrednio do Internetu.		 Możesz skuteczniej chronić aplikacje internetowe przed typowymi zagrożeniami i zmniejszyć ogólną ekspozycję rozwiązania.
Ochrona aplikacji przed atakami DDoS.

Użyj usługi Azure Front Door lub Azure DDoS Protection w zależności od protokołów używanych przez publiczne punkty końcowe.		 Chroń rozwiązanie przed typowym typem ataku.
Jeśli aplikacja wymaga łączności wychodzącej na dużą skalę, użyj bramy translatora adresów sieciowych lub zapory, aby zapewnić dodatkowe porty SNAT. Możesz obsługiwać wyższe poziomy skalowania.

Łączność między sieciami

W niektórych scenariuszach może być konieczne nawiązanie połączenia z zasobami zewnętrznymi z platformą Azure, takimi jak dane w prywatnej sieci klienta lub zasoby innego dostawcy usług w chmurze w konfiguracji wielochmurowej. Te potrzeby mogą komplikować projekt sieci, wymagając różnych podejść do implementowania łączności między sieciami na podstawie określonych wymagań.

Uwagi dotyczące projektowania

  • Zidentyfikuj punkty końcowe, do których aplikacja potrzebuje połączenia. Aplikacja może wymagać komunikacji z innymi usługami, takimi jak usługi magazynu i bazy danych. Dokumentowanie ich właściciela, lokalizacji i typu łączności. Następnie możesz wybrać odpowiednią metodę, aby nawiązać połączenie z tymi punktami końcowymi. Typowe podejścia obejmują:

    Lokalizacja zasobu Właściciel Opcje łączności do rozważenia
    Azure Klient
    • Prywatny punkt końcowy (w dzierżawach usługi Microsoft Entra ID)
    • Komunikacja równorzędna sieci wirtualnych (między dzierżawami identyfikatorów entra firmy Microsoft)
    • Punkt końcowy usługi (w dzierżawach identyfikatora entra firmy Microsoft)
    Inny dostawca usług w chmurze Niezależnego dostawcy oprogramowania lub klienta
    • Sieć VPN typu lokacja-lokacja
    • ExpressRoute
    • Internet
    Lokalne Niezależnego dostawcy oprogramowania lub klienta
    • Sieć VPN typu lokacja-lokacja
    • ExpressRoute
    • Internet

    • Usługa Private Link i prywatny punkt końcowy. Zapewnianie bezpiecznej łączności z różnymi zasobami platformy Azure, w tym wewnętrznymi modułami równoważenia obciążenia dla maszyn wirtualnych. Umożliwiają one dostęp prywatny do rozwiązania SaaS dla klientów, choć są one związane z zagadnieniami dotyczącymi kosztów.

      Kompromis: Bezpieczeństwo i koszty. Usługa Private Link zapewnia, że ruch pozostaje w sieci prywatnej i jest zalecany w przypadku łączności sieciowej między dzierżawami firmy Microsoft Entra. Jednak każdy prywatny punkt końcowy wiąże się z kosztami, które można dodać w zależności od potrzeb w zakresie zabezpieczeń. Punkty końcowe usługi mogą być opłacalną alternatywą, utrzymując ruch w sieci szkieletowej firmy Microsoft, zapewniając jednocześnie pewien poziom łączności prywatnej.

    • Punkt końcowy usługi. Kieruje ruch do zasobów PaaS za pośrednictwem sieci szkieletowej firmy Microsoft, zabezpieczając komunikację między usługami. Mogą one być opłacalne dla aplikacji o wysokiej przepustowości, ale wymagają skonfigurowania i utrzymania list kontroli dostępu na potrzeby zabezpieczeń. Obsługa punktów końcowych usługi w dzierżawach identyfikatorów Entra firmy Microsoft różni się w zależności od usługi platformy Azure. Zapoznaj się z dokumentacją produktu dla każdej używanej usługi.

    • Komunikacja równorzędna sieci wirtualnych łączy dwie sieci wirtualne, umożliwiając zasobom w jednej sieci dostęp do adresów IP w drugiej. Ułatwia ona łączność z zasobami prywatnymi w sieci wirtualnej platformy Azure. Dostęp można zarządzać przy użyciu sieciowych grup zabezpieczeń, ale wymuszanie izolacji może być trudne. Dlatego ważne jest, aby zaplanować topologię sieci na podstawie konkretnych potrzeb klientów.

    • Wirtualne sieci prywatne (VPN) tworzą bezpieczny tunel przez Internet między dwiema sieciami, w tym między dostawcami chmury i lokalizacjami lokalnymi. Sieci VPN typu lokacja-lokacja używają urządzeń sieciowych w każdej sieci do konfiguracji. Oferują one opcję łączności o niskich kosztach, ale wymagają konfiguracji i nie gwarantują przewidywalnej przepływności.

    • Usługa ExpressRoute zapewnia dedykowane, wysokiej wydajności, prywatne połączenie między platformą Azure i innymi dostawcami usług w chmurze lub sieciami lokalnymi. Zapewnia przewidywalną wydajność i pozwala uniknąć ruchu internetowego, ale wiąże się z wyższymi kosztami i wymaga bardziej złożonej konfiguracji.

  • Zaplanuj na podstawie miejsca docelowego. Może być konieczne nawiązanie połączenia z zasobami w różnych dzierżawach identyfikatorów Entra firmy Microsoft, zwłaszcza jeśli zasób docelowy znajduje się w subskrypcji platformy Azure klienta. Rozważ użycie prywatnych punktów końcowych, sieci VPN typu lokacja-lokacja lub komunikacji równorzędnej sieci wirtualnych. Aby uzyskać więcej informacji, zobacz Peering virtual networks in different Microsoft Entra ID tenants (Komunikacja równorzędna sieci wirtualnych w różnych dzierżawach identyfikatorów entra firmy Microsoft).

    Aby nawiązać połączenie z zasobami hostowanymi u innego dostawcy usług w chmurze, często używa się publicznej łączności z Internetem, sieci VPN typu lokacja-lokacja lub usługi ExpressRoute. Aby uzyskać więcej informacji, zobacz Łączność z innymi dostawcami usług w chmurze.

  • Omówienie wpływu łączności na topologię sieci. Sieć wirtualna platformy Azure może mieć tylko jedną bramę sieci wirtualnej, która może łączyć się z wieloma lokalizacjami za pośrednictwem sieci VPN typu lokacja-lokacja lub usługi ExpressRoute. Istnieją jednak ograniczenia liczby połączeń za pośrednictwem bramy i izolowanie ruchu klientów może być trudne. W przypadku wielu połączeń z różnymi lokalizacjami należy odpowiednio zaplanować topologię sieci, wdrażając oddzielną sieć wirtualną dla każdego klienta.

  • Omówienie konsekwencji planowania adresów IP. Niektóre podejścia do łączności zapewniają automatyczne tłumaczenie adresów sieciowych (NAT), unikając problemów z nakładającymi się adresami IP. Jednak komunikacja równorzędna sieci wirtualnych i usługa ExpressRoute nie wykonują translatora adresów sieciowych. W przypadku korzystania z tych metod należy dokładnie zaplanować zasoby sieciowe i alokacje adresów IP, aby uniknąć nakładających się zakresów adresów IP i zapewnić przyszły wzrost. Planowanie adresów IP może być złożone, zwłaszcza w przypadku nawiązywania połączenia z firmami trzecimi, takimi jak klienci, więc rozważ potencjalne konflikty z zakresami adresów IP.

  • Omówienie rozliczeń ruchu wychodzącego sieci. Platforma Azure zwykle nalicza opłaty za wychodzący ruch sieciowy, gdy opuszcza sieć firmy Microsoft lub przenosi się między regionami platformy Azure. Podczas projektowania rozwiązań wielochmurowych lub wielochmurowych ważne jest, aby zrozumieć implikacje dotyczące kosztów. Opcje architektury, takie jak korzystanie z usługi Azure Front Door lub ExpressRoute, mogą mieć wpływ na sposób naliczania opłat za ruch sieciowy.

Zalecenia dotyczące projektowania

Zalecenie Korzyści
Preferuj metody sieci prywatnej do łączenia się między sieciami w celu nadania priorytetów bezpieczeństwu.

Należy rozważyć routing przez Internet tylko po ocenie skojarzonych implikacji dotyczących zabezpieczeń i wydajności.		 Ruch prywatny przechodzi przez zabezpieczoną ścieżkę sieciową, która pomaga zmniejszyć wiele typów zagrożeń bezpieczeństwa.
Podczas nawiązywania połączenia z zasobami klienta hostowanymi w swoich środowiskach platformy Azure użyj usługi Private Link, punktów końcowych usługi lub komunikacji równorzędnej sieci wirtualnych. Możesz zachować ruch w sieci firmy Microsoft, co pomaga zmniejszyć koszty i złożoność operacyjną w porównaniu z innymi podejściami.
Podczas nawiązywania połączenia między dostawcami chmury lub sieciami lokalnymi należy użyć sieci VPN typu lokacja-lokacja lub usługi ExpressRoute. Te technologie zapewniają bezpieczne połączenia między dostawcami.

Wdrażanie w środowiskach należących do klientów

Model biznesowy może wymagać hostowania aplikacji lub jej składników w środowisku platformy Azure klienta. Klient zarządza własną subskrypcją platformy Azure i bezpośrednio płaci koszt zasobów wymaganych do uruchomienia aplikacji. Jako dostawca rozwiązań odpowiadasz za zarządzanie rozwiązaniem, takie jak początkowe wdrożenie, stosowanie konfiguracji i wdrażanie aktualizacji w aplikacji.

W takich sytuacjach klienci często korzystają z własnej sieci i wdrażają aplikację w zdefiniowanej przestrzeni sieciowej. Aplikacje zarządzane platformy Azure oferują możliwości ułatwiające ten proces. Aby uzyskać więcej informacji, zobacz Use existing virtual network with Azure Managed Applications (Używanie istniejącej sieci wirtualnej z aplikacjami zarządzanymi platformy Azure).

Uwagi dotyczące projektowania

  • Zakresy adresów IP i konflikty. Gdy klienci wdrażają sieci wirtualne i zarządzają nimi, są odpowiedzialni za obsługę konfliktów sieci i skalowania. Należy jednak przewidzieć różne scenariusze użycia klientów. Zaplanuj wdrożenia w środowiskach z minimalną przestrzenią adresów IP dzięki wydajnemu użyciu adresów IP i unikaj kodowania zakresów adresów IP, aby zapobiec nakładaniu się na zakresy klientów.

    Alternatywnie wdróż dedykowaną sieć wirtualną dla swojego rozwiązania. Możesz użyć usługi Private Link lub komunikacji równorzędnej sieci wirtualnych, aby umożliwić klientom łączenie się z zasobami. Te podejścia opisano w temacie Łączność między sieciami. Jeśli zdefiniowano punkty ruchu przychodzącego i wychodzącego, oceń translator adresów sieciowych jako metodę eliminowania problemów spowodowanych nakładającymi się adresami IP.

  • Zapewnianie dostępu do sieci na potrzeby zarządzania. Przejrzyj zasoby wdrażane w środowiskach klientów i zaplanuj sposób uzyskiwania do nich dostępu w celu monitorowania, zarządzania lub ponownego konfigurowania tych zasobów. Po wdrożeniu zasobów z prywatnymi adresami IP w środowisku należącym do klienta upewnij się, że masz ścieżkę sieciową, aby uzyskać do nich dostęp z własnej sieci. Zastanów się, jak ułatwić zmiany aplikacji i zasobów, takie jak wypychanie nowej wersji aplikacji lub aktualizowanie konfiguracji zasobów platformy Azure.

    W niektórych rozwiązaniach można używać funkcji udostępnianych przez aplikacje zarządzane platformy Azure, takich jak dostęp just in time i wdrażanie aktualizacji aplikacji. Jeśli potrzebujesz większej kontroli, możesz hostować punkt końcowy w sieci klienta, z którym może się łączyć płaszczyzna sterowania, zapewniając dostęp do zasobów. Ta metoda wymaga dodatkowych zasobów platformy Azure i programowania, aby spełnić wymagania dotyczące zabezpieczeń, operacji i wydajności. Aby zapoznać się z przykładem implementacji tego podejścia, zobacz Przykład aktualizacji aplikacji zarządzanych platformy Azure.

Zalecenia dotyczące projektowania

Zalecenie Korzyści
Wdrażanie zasobów wdrożonych przez klienta i zarządzanie nimi za pomocą aplikacji zarządzanych platformy Azure. Aplikacje zarządzane platformy Azure udostępniają szereg funkcji, które umożliwiają wdrażanie zasobów i zarządzanie nimi w ramach subskrypcji platformy Azure klienta.
Zminimalizuj liczbę adresów IP używanych w przestrzeni sieciowej klienta. Klienci często mają ograniczoną dostępność adresów IP. Minimalizując ślad i odsuając skalowanie na podstawie użycia adresów IP, możesz rozszerzyć liczbę klientów, którzy mogą korzystać z rozwiązania, i zwiększyć poziom wzrostu.
Zaplanuj, jak uzyskać dostęp sieciowy do zarządzania zasobami w środowiskach klientów, biorąc pod uwagę monitorowanie, zmiany konfiguracji zasobów i aktualizacje aplikacji. Możesz bezpośrednio skonfigurować zarządzane zasoby.
Zdecyduj, czy chcesz wdrożyć dedykowaną sieć wirtualną, czy zintegrować z istniejącą siecią wirtualną klienta. Planując z wyprzedzeniem, upewnij się, że możesz spełnić wymagania klientów dotyczące izolacji, zabezpieczeń i integracji z innymi systemami.
Domyślnie wyłącz dostęp publiczny w zasobach platformy Azure. Preferuj prywatny ruch przychodzący, jeśli jest to możliwe. Ograniczysz zakres zasobów sieciowych, które musisz chronić i klienci.

Dodatkowe zasoby

Multitenancy to podstawowa metodologia biznesowa projektowania obciążeń SaaS. Te artykuły zawierają więcej informacji dotyczących projektowania sieci:

Następny krok

Dowiedz się więcej o zagadnieniach dotyczących platformy danych dotyczących integralności danych i wydajności obciążeń SaaS na platformie Azure.

Obszar projektowania: dane dla obciążeń SaaS na platformie Azure