Edytuj

Udostępnij za pośrednictwem

Przychodzące i wychodzące połączenia internetowe dla oprogramowania SAP na platformie Azure

Azure Virtual Machines
Azure Virtual Network
Azure Application Gateway
Azure Load Balancer

Ten artykuł zawiera zestaw sprawdzonych rozwiązań mających na celu poprawę bezpieczeństwa przychodzących i wychodzących połączeń internetowych dla infrastruktury platformy SAP na platformie Azure.

Architektura

Diagram przedstawiający rozwiązanie do komunikacji z Internetem dla oprogramowania SAP na platformie Azure.

Pobierz plik programu Visio architektur w tym artykule.

To rozwiązanie ilustruje typowe środowisko produkcyjne. Możesz zmniejszyć rozmiar i zakres konfiguracji, aby dopasować je do wymagań. Ta redukcja może dotyczyć środowiska SAP: mniejszej liczby maszyn wirtualnych, wysokiej dostępności ani osadzonych dyspozytorów SAP Web Dispatchers zamiast dyskretnych maszyn wirtualnych. Można go również zastosować do alternatyw w projekcie sieci, zgodnie z opisem w dalszej części tego artykułu.

Wymagania klientów, oparte na zasadach biznesowych, będą wymagały adaptacji architektury, szczególnie do projektowania sieci. Jeśli to możliwe, dołączyliśmy alternatywy. Wiele rozwiązań jest realnych. Wybierz podejście odpowiednie dla Twojej firmy. Musi ona pomóc w zabezpieczeniu zasobów platformy Azure, ale nadal zapewnia wydajne rozwiązanie.

Odzyskiwanie po awarii (DR) nie zostało omówione w tej architekturze. W przypadku projektu sieci mają zastosowanie te same zasady i projekt, które są prawidłowe dla podstawowych regionów produkcyjnych. W projekcie sieci, w zależności od aplikacji chronionych przez odzyskiwanie po awarii, rozważ włączenie odzyskiwania po awarii w innym regionie świadczenia usługi Azure. Aby uzyskać więcej informacji, zobacz artykuł Omówienie odzyskiwania po awarii i wytyczne dotyczące infrastruktury dla obciążenia SAP

Przepływ pracy

  • Sieć lokalna łączy się z centralnym koncentratorem za pośrednictwem usługi Azure ExpressRoute. Sieć wirtualna piasty zawiera podsieć bramy, podsieć usługi Azure Firewall, podsieć usług udostępnionych i podsieć bramy aplikacja systemu Azure.
  • Koncentrator łączy się z subskrypcją produkcyjną SAP za pośrednictwem komunikacji równorzędnej sieci wirtualnych. Ta subskrypcja zawiera dwie sieci wirtualne będące szprychą:
    • Sieć wirtualna obwodowa SAP zawiera podsieć aplikacji obwodowej SAP.
    • Produkcyjna sieć wirtualna SAP zawiera podsieć aplikacji i podsieć bazy danych.
  • Subskrypcja centrum i subskrypcja produkcyjna SAP łączą się z Internetem za pośrednictwem publicznych adresów IP.

Składniki

Subskrypcje. Ta architektura implementuje podejście strefy docelowej platformy Azure. Jedna subskrypcja platformy Azure jest używana dla każdego obciążenia. Co najmniej jedna subskrypcja jest używana dla centralnych usług IT zawierających centrum sieci i centralne usługi udostępnione, takie jak zapory lub usługi Active Directory i DNS. Inna subskrypcja jest używana dla obciążenia produkcyjnego SAP. Skorzystaj z przewodnika po decyzjach w przewodniku Cloud Adoption Framework dla platformy Azure, aby określić najlepszą strategię subskrypcji dla danego scenariusza.

Sieci wirtualne. Usługa Azure Virtual Network łączy zasoby platformy Azure ze sobą z zwiększonymi zabezpieczeniami. W tej architekturze sieć wirtualna łączy się ze środowiskiem lokalnym za pośrednictwem bramy usługi ExpressRoute lub wirtualnej sieci prywatnej (VPN) wdrożonej w centrum topologii piasty i szprych. Środowisko produkcyjne SAP używa własnych sieci wirtualnych szprych. Dwie odrębne sieci wirtualne będące szprychami wykonują różne zadania, a podsieci zapewniają segregację sieci.

Rozdzielenie na podsieci według obciążenia ułatwia korzystanie z sieciowych grup zabezpieczeń w celu ustawiania reguł zabezpieczeń dla wdrożonych maszyn wirtualnych aplikacji lub usług platformy Azure.

Brama strefowo nadmiarowa. Brama łączy różne sieci, rozszerzając sieć lokalną na sieć wirtualną platformy Azure. Zalecamy używanie usługi ExpressRoute do tworzenia połączeń prywatnych, które nie korzystają z publicznego Internetu. Można również użyć połączenia lokacja-lokacja. Użyj strefowo nadmiarowych bram usługi Azure ExpressRoute lub bram sieci VPN, aby chronić przed awariami strefy. Zobacz Strefowo nadmiarowe bramy sieci wirtualnej, aby uzyskać wyjaśnienie różnic między wdrożeniem strefowym a wdrożeniem strefowo nadmiarowym. W przypadku wdrożenia stref bram należy użyć adresów IP jednostki SKU w warstwie Standardowa.

NSGs. Aby ograniczyć ruch sieciowy do i z sieci wirtualnej, utwórz sieciowe grupy zabezpieczeń i przypisz je do określonych podsieci. Zapewnienie zabezpieczeń dla poszczególnych podsieci przy użyciu sieciowych grup zabezpieczeń specyficznych dla obciążenia.

Grupy zabezpieczeń aplikacji. Aby zdefiniować szczegółowe zasady zabezpieczeń sieci w sieciowych grupach zabezpieczeń na podstawie obciążeń, które są skoncentrowane na aplikacjach, użyj grup zabezpieczeń aplikacji zamiast jawnych adresów IP. Za pomocą grup zabezpieczeń aplikacji można grupować maszyny wirtualne według celu, na przykład identyfikator SID systemu SAP. Grupy zabezpieczeń aplikacji ułatwiają zabezpieczanie aplikacji przez filtrowanie ruchu z zaufanych segmentów sieci.

Prywatny punkt końcowy. Wiele usług platformy Azure działa jako usługi publiczne, zgodnie z projektem dostępne za pośrednictwem Internetu. Aby zezwolić na dostęp prywatny za pośrednictwem zakresu sieci prywatnej, możesz użyć prywatnych punktów końcowych dla niektórych usług. Prywatne punkty końcowe to interfejsy sieciowe w sieci wirtualnej. Skutecznie wprowadzają one usługę do prywatnej przestrzeni sieciowej.

aplikacja systemu Azure Gateway. Usługa Application Gateway to moduł równoważenia obciążenia ruchu internetowego. Dzięki funkcjom zapory aplikacji internetowej jest to idealna usługa do uwidaczniania aplikacji internetowych w Internecie przy użyciu ulepszonych zabezpieczeń. Usługa Application Gateway może obsługiwać klientów publicznych (internetowych) lub prywatnych albo obu, w zależności od konfiguracji.

W architekturze usługa Application Gateway korzystająca z publicznego adresu IP zezwala na połączenia przychodzące do środowiska SAP za pośrednictwem protokołu HTTPS. Pula zaplecza to co najmniej dwie maszyny wirtualne programu SAP Web Dispatcher, do których uzyskuje się dostęp i zapewnia wysoką dostępność. Brama aplikacji jest zwrotnym serwerem proxy i modułem równoważenia obciążenia ruchu internetowego, ale nie zastępuje programu SAP Web Dispatcher. Program SAP Web Dispatcher zapewnia integrację aplikacji z systemami SAP i zawiera funkcje, które sama usługa Application Gateway nie zapewnia. Uwierzytelnianie klienta, gdy dociera do systemów SAP, jest wykonywane natywnie przez warstwę aplikacji SAP lub za pośrednictwem logowania jednokrotnego. Po włączeniu ochrony przed atakami DDoS na platformie Azure rozważ użycie jednostki SKU ochrony sieci DDoS, ponieważ będą widoczne rabaty dla zapory aplikacji internetowej usługi Application Gateway.

Aby uzyskać optymalną wydajność, włącz obsługę protokołu HTTP/2 dla usługi Application Gateway, programu SAP Web Dispatcher i oprogramowania SAP NetWeaver.

Azure Load Balancer. Usługa Azure usługa Load Balancer w warstwie Standardowa udostępnia elementy sieciowe do projektowania wysokiej dostępności systemów SAP. W przypadku systemów klastrowanych usługa Load Balancer w warstwie Standardowa udostępnia wirtualny adres IP usługi klastra, taki jak wystąpienia usługi ASCS/SCS i bazy danych uruchomione na maszynach wirtualnych. Można również użyć usługa Load Balancer w warstwie Standardowa, aby podać adres IP dla wirtualnej nazwy hosta SAP systemów nieklasterowanych, gdy pomocnicze adresy IP na kartach sieciowych platformy Azure nie są opcją. Użycie usługa Load Balancer w warstwie Standardowa zamiast usługi Application Gateway do obsługi wychodzącego dostępu do Internetu zostało omówione w dalszej części tego artykułu.

Projekt sieci

Architektura korzysta z dwóch dyskretnych sieci wirtualnych, obu sieci wirtualnych szprych, które są równorzędne z centralną siecią wirtualną koncentratora. Nie ma komunikacji równorzędnej szprychy do szprych. Używana jest topologia gwiazdy, w której komunikacja przechodzi przez koncentrator. Rozdzielenie sieci pomaga chronić aplikacje przed naruszeniami zabezpieczeń.

Sieć obwodowa specyficzna dla aplikacji (znana również jako strefa DMZ) zawiera aplikacje dostępne z Internetu, takie jak SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent i inne. Na diagramie architektury sieć obwodowa nosi nazwę obwodu SAP — szprychy sieci wirtualnej. Ze względu na zależności od systemów SAP zespół SAP zwykle wykonuje wdrażanie, konfigurację i zarządzanie tymi usługami. Dlatego te usługi obwodowe SAP często nie znajdują się w centralnej subskrypcji centrum i sieci. Często wyzwania organizacyjne są spowodowane takim centralnym rozmieszczeniem aplikacji lub usług specyficznych dla obciążenia.

Oto niektóre korzyści wynikające z używania oddzielnej sieci wirtualnej obwodowej SAP:

  • Szybka i natychmiastowa izolacja naruszonych usług w przypadku wykrycia naruszenia zabezpieczeń. Usunięcie komunikacji równorzędnej sieci wirtualnych z obwodu SAP do centrum natychmiast izoluje obciążenia obwodowe SAP i aplikacje sieci wirtualnej aplikacji SAP z Internetu. Zmiana lub usunięcie reguły sieciowej grupy zabezpieczeń, która zezwala na dostęp dotyczy tylko nowych połączeń i nie wycina istniejących połączeń.
  • Bardziej rygorystyczne mechanizmy kontroli w sieci wirtualnej i podsieci z ścisłą blokadą partnerów komunikacyjnych w sieci obwodowej SAP i sieciach aplikacji SAP oraz poza nimi. Możesz rozszerzyć większą kontrolę na autoryzowanych użytkowników i metody dostępu w aplikacjach obwodowych SAP, z różnymi zapleczami autoryzacji, uprzywilejowanym dostępem lub poświadczeniami logowania dla aplikacji obwodowych SAP.

Wady są zwiększone złożoność i dodatkowe koszty komunikacji równorzędnej sieci wirtualnych dla ruchu SAP powiązanego z Internetem (ponieważ komunikacja musi przechodzić przez komunikację równorzędną sieci wirtualnych dwa razy). Wpływ opóźnienia na ruch komunikacji równorzędnej szprych-piasty i szprych zależy od każdej zapory, która jest w miejscu i musi być mierzona.

Uproszczona architektura

Aby rozwiązać problemy z zaleceniami w tym artykule, ale ograniczyć wady, możesz użyć pojedynczej sieci wirtualnej szprych zarówno dla obwodu, jak i aplikacji SAP. Poniższa architektura zawiera wszystkie podsieci w jednej produkcyjnej sieci wirtualnej SAP. Korzyść natychmiastowej izolacji przez zakończenie komunikacji równorzędnej sieci wirtualnych z obwodem SAP, jeśli zostanie naruszona, nie jest dostępna. W tym scenariuszu zmiany w sieciowych grupach zabezpieczeń mają wpływ tylko na nowe połączenia.

Diagram przedstawiający uproszczoną architekturę komunikacji internetowej dla oprogramowania SAP na platformie Azure.

Pobierz plik programu Visio architektur w tym artykule.

W przypadku wdrożeń o mniejszym rozmiarze i zakresie uproszczona architektura może być lepszym rozwiązaniem i nadal jest zgodna z zasadami bardziej złożonej architektury. Ten artykuł, chyba że określono inaczej, odnosi się do bardziej złożonej architektury.

Uproszczona architektura używa bramy translatora adresów sieciowych w podsieci obwodowej SAP. Ta brama zapewnia łączność wychodzącą dla łącznika SAP Cloud Connector i agenta w chmurze SAP Analytics oraz aktualizacji systemu operacyjnego dla wdrożonych maszyn wirtualnych. Ponieważ program SAProuter wymaga zarówno połączeń przychodzących, jak i wychodzących, ścieżka komunikacji saProuter przechodzi przez zaporę zamiast używać bramy translatora adresów sieciowych. Uproszczona architektura umieszcza również usługę Application Gateway z własną wyznaczoną podsiecią w sieci wirtualnej obwodowej SAP jako alternatywne podejście do sieci wirtualnej koncentratora.

Brama translatora adresów sieciowych to usługa, która zapewnia statyczne publiczne adresy IP na potrzeby łączności wychodzącej. Brama translatora adresów sieciowych jest przypisywana do podsieci. Cała komunikacja wychodząca używa adresów IP bramy translatora adresów sieciowych na potrzeby dostępu do Internetu. Połączenia przychodzące nie używają bramy translatora adresów sieciowych. Aplikacje, takie jak SAP Cloud Connector lub usługi aktualizacji systemu operacyjnego maszyny wirtualnej, które uzyskują dostęp do repozytoriów w Internecie, mogą używać bramy translatora adresów sieciowych zamiast kierować cały ruch wychodzący przez centralną zaporę. Często reguły zdefiniowane przez użytkownika są implementowane we wszystkich podsieciach, aby wymusić ruch związany z Internetem ze wszystkich sieci wirtualnych przez centralną zaporę.

W zależności od wymagań może być możliwe użycie bramy translatora adresów sieciowych jako alternatywy dla centralnej zapory dla połączeń wychodzących. Dzięki temu można zmniejszyć obciążenie centralnej zapory podczas komunikowania się z publicznymi punktami końcowymi dozwolonymi przez sieciową grupę zabezpieczeń. Możesz również uzyskać kontrolę wychodzącego adresu IP, ponieważ można skonfigurować docelowe reguły zapory na ustawionej liście adresów IP bramy translatora adresów sieciowych. Przykłady obejmują dotarcie do publicznych punktów końcowych platformy Azure, które są używane przez usługi publiczne, repozytoria poprawek systemu operacyjnego lub interfejsy innych firm.

W przypadku konfiguracji wysokiej dostępności należy pamiętać, że brama translatora adresów sieciowych jest wdrażana tylko w jednej strefie i nie jest obecnie nadmiarowa. W przypadku pojedynczej bramy translatora adresów sieciowych nie jest idealnym rozwiązaniem w przypadku wdrożeń SAP, które używają wdrożenia strefowo nadmiarowego (między strefami) dla maszyn wirtualnych.

Korzystanie ze składników sieciowych w całym krajobrazie systemu SAP

Dokument architektury zwykle przedstawia tylko jeden system SAP lub poziomy. Ułatwia to ich zrozumienie. Wynikiem jest to, że często większy obraz, sposób dopasowania architektury do większego krajobrazu SAP, który obejmuje kilka ścieżek i warstw systemowych, nie jest rozwiązywany.

Centralne usługi sieciowe, takie jak zapora, brama translatora adresów sieciowych i serwery proxy, jeśli zostały wdrożone, najlepiej są używane w całym środowisku SAP wszystkich warstw: produkcji, przedprodukcyjnej, programowania i piaskownicy. W zależności od wymagań, rozmiaru organizacji i zasad biznesowych warto rozważyć oddzielne implementacje na warstwę lub jedną produkcyjną i jedno środowisko piaskownicy/testowania.

Usługi, które zwykle obsługują system SAP, są najlepiej oddzielone zgodnie z opisem w tym miejscu:

  • Moduły równoważenia obciążenia powinny być przeznaczone dla poszczególnych usług. Zasady firmy określają nazewnictwo i grupowanie zasobów. Zalecamy jeden moduł równoważenia obciążenia dla usług ASCS/SCS i ERS, a drugi dla bazy danych oddzielony dla każdego identyfikatora SID systemu SAP. Alternatywnie jeden moduł równoważenia obciążenia dla obu (A)SCS, ERS i DB klastrów jednego systemu SAP jest również dobrym projektem. Ta konfiguracja pomaga zapewnić, że rozwiązywanie problemów nie jest skomplikowane, a wiele pul frontonu i zaplecza oraz reguł równoważenia obciążenia wszystkich w jednym module równoważenia obciążenia. Pojedynczy moduł równoważenia obciążenia na identyfikator SID systemu SAP zapewnia również, że umieszczanie w grupach zasobów jest zgodne z innymi składnikami infrastruktury.
  • Usługa Application Gateway, podobnie jak moduł równoważenia obciążenia, umożliwia korzystanie z wielu zapleczy, frontonów, ustawień PROTOKOŁU HTTP i reguł. Decyzja o użyciu jednej bramy aplikacji dla wielu zastosowań jest bardziej powszechna, ponieważ nie wszystkie systemy SAP w środowisku wymagają dostępu publicznego. Wiele zastosowań w tym kontekście obejmuje różne porty dyspozytora internetowego dla tych samych systemów SAP S/4HANA lub różnych środowisk SAP. Zalecamy co najmniej jedną bramę aplikacji na warstwę (produkcyjną, nieprodukcyjną i piaskownicę), chyba że złożoność i liczba połączonych systemów staną się zbyt wysokie.
  • Usługi SAP, takie jak SAProuter, Cloud Connector i Analytics Cloud Agent, są wdrażane w oparciu o wymagania aplikacji, centralnie lub podzielone. Separacja produkcji i nieprodukcyjnej jest często wymagana.

Ustalanie i projektowanie podsieci

Podczas projektowania podsieci dla środowiska SAP należy przestrzegać zasad ustalania rozmiaru i projektowania:

  • Kilka usług platformy Azure jako usługi (PaaS) wymaga własnych wyznaczonych podsieci.
  • Usługa Application Gateway zaleca podsieć /24 do skalowania. Jeśli zdecydujesz się ograniczyć skalę usługi Application Gateway, można użyć mniejszej podsieci, co najmniej /26 lub większej. Nie można używać obu wersji usługi Application Gateway (1 i 2) w tej samej podsieci.
  • Jeśli używasz usługi Azure NetApp Files dla udziałów NFS/SMB lub magazynu bazy danych, wymagana jest wyznaczona podsieć. Podsieć /24 jest domyślna. Użyj swoich wymagań, aby określić odpowiednie rozmiary.
  • Jeśli używasz nazw hostów wirtualnych SAP, potrzebujesz więcej przestrzeni adresowej w podsieciach SAP, w tym obwodu SAP.
  • Usługi centralne, takie jak Azure Bastion lub Azure Firewall, zwykle zarządzane przez centralny zespół IT, wymagają własnych dedykowanych podsieci o odpowiednim rozmiarze.

Korzystając z dedykowanych podsieci dla baz danych i aplikacji SAP, można ustawić sieciowe grupy zabezpieczeń na bardziej rygorystyczne, co pomaga chronić oba typy aplikacji przy użyciu własnych zestawów reguł. Następnie można łatwiej ograniczyć dostęp do baz danych do aplikacji SAP bez konieczności uciekania się do grup zabezpieczeń aplikacji w celu uzyskania szczegółowej kontroli. Oddzielenie podsieci aplikacji SAP i bazy danych ułatwia również zarządzanie regułami zabezpieczeń w sieciowych grupach zabezpieczeń.

Usługi SAP

SaProuter

Możesz użyć programu SAProuter, aby umożliwić innym firmom, takich jak pomoc techniczna SAP, lub partnerom uzyskiwanie dostępu do systemu SAP. Program SAProuter działa na jednej maszynie wirtualnej na platformie Azure. Uprawnienia trasy do korzystania z programu SAProuter są przechowywane w pliku płaskim o nazwie saprouttab. Wpisy saprouttab zezwalają na połączenie z dowolnego portu TCP/IP do miejsca docelowego sieci za programem SAProuter, zazwyczaj maszyn wirtualnych systemu SAP. Dostęp zdalny przez pomoc techniczną sap opiera się na programie SAProuter. Główna architektura używa opisanego wcześniej projektu z maszyną wirtualną SAProuter działającą w wyznaczonej sieci wirtualnej obwodowej SAP. Za pośrednictwem komunikacji równorzędnej sieci wirtualnych usługa SAProuter komunikuje się następnie z serwerami SAP, które działają we własnej sieci wirtualnej i podsieciach szprych.

SAProuter to tunel do oprogramowania SAP lub partnerów. W tej architekturze opisano użycie programu SAProuter z użyciem SNC w celu ustanowienia szyfrowanego tunelu aplikacji (warstwa 7) dla oprogramowania SAP/partnerów. Korzystanie z tunelu opartego na protokole IPSEC nie jest obecnie omówione w tej architekturze.

Następujące funkcje pomagają chronić ścieżkę komunikacji przez Internet:

  • Usługa Azure Firewall lub urządzenie WUS innej firmy udostępnia publiczny punkt wejścia adresu IP do sieci platformy Azure. Reguły zapory ograniczają komunikację tylko do autoryzowanych adresów IP. W przypadku połączenia z obsługą oprogramowania SAP uwaga 48243 — Integrowanie oprogramowania SAProuter ze środowiskiem zapory dokumentuje adresy IP routerów SAP.
  • Podobnie jak reguły zapory, reguły zabezpieczeń sieci zezwalają na komunikację na porcie SAProutera, zazwyczaj 3299 z wyznaczonym miejscem docelowym.
  • W pliku saprouttab należy zachować reguły zezwalania/odmowy protokołu SAProuter, określając, kto może skontaktować się z programem SAProuter i do którego systemu SAP można uzyskać dostęp.
  • Dalsze reguły sieciowej grupy zabezpieczeń są wdrażane w odpowiednich podsieciach w podsieci produkcyjnej SAP, która zawiera systemy SAP.

Aby uzyskać instrukcje dotyczące konfigurowania programu SAProuter za pomocą usługi Azure Firewall, zobacz Konfiguracja usługi SAProuter przy użyciu usługi Azure Firewall.

Zagadnienia dotyczące zabezpieczeń usługi SAProuter

Ponieważ program SAProuter nie działa w tej samej podsieci aplikacji co systemy SAP, mechanizmy logowania dla systemu operacyjnego mogą być inne. W zależności od zasad można użyć oddzielnej domeny logowania lub całkowicie poświadczeń użytkownika tylko dla hosta dla programu SAProuter. W przypadku naruszenia zabezpieczeń kaskadowy dostęp do wewnętrznych systemów SAP nie jest możliwy z powodu innej bazy poświadczeń. Separacja sieci w takim przypadku, jak opisano wcześniej, może oddzielić dalszy dostęp od naruszonego protokołu SAProuter do podsieci aplikacji. Tę izolację można osiągnąć, rozłączając komunikację równorzędną sieci wirtualnej z obwodem SAP.

Zagadnienia dotyczące wysokiej dostępności usługi SAProuter

Ponieważ SAProuter to prosty plik wykonywalny z tabelą uprawnień tras opartych na plikach, można go łatwo uruchomić. Aplikacja nie ma wbudowanej wysokiej dostępności. Jeśli wystąpi awaria maszyny wirtualnej lub aplikacji, usługa musi uruchomić się na innej maszynie wirtualnej. Użycie nazwy hosta wirtualnego dla usługi SAProuter jest idealne. Nazwa hosta wirtualnego jest powiązana z adresem IP przypisanym jako pomocnicza konfiguracja adresu IP z kartą sieciową maszyny wirtualnej lub wewnętrznym modułem równoważenia obciążenia połączonym z maszyną wirtualną. W tej konfiguracji, jeśli usługa SAProuter musi zostać przeniesiona na inną maszynę wirtualną, konfigurację adresu IP nazwy hosta wirtualnego usługi można usunąć. Następnie należy dodać nazwę hosta wirtualnego na innej maszynie wirtualnej bez konieczności zmiany tabel tras lub konfiguracji zapory. Wszystkie są skonfigurowane do używania wirtualnego adresu IP. Aby uzyskać więcej informacji, zobacz Używanie nazw hostów wirtualnych SAP z systemem Linux na platformie Azure.

Kaskadowe usługi SAProutery

Aby zaimplementować kaskadowe komputery SAProutery, można zdefiniować dowolną liczbę dwóch komputerów SAProuter dla połączeń obsługi oprogramowania SAP. Pierwszy komputer SAProuter działający w podsieci aplikacji obwodowej SAP zapewnia dostęp z centralnej zapory i z programu SAP lub partnerów SAProuters. Jedynymi dozwolonymi miejscami docelowymi są inne komputery SAProutery uruchomione z określonymi obciążeniami. Kaskadowe modele SAProutery mogą używać separacji poszczególnych warstw, poszczególnych regionów lub poszczególnych identyfikatorów SID w zależności od architektury. Drugi program SAProuter akceptuje tylko połączenia wewnętrzne z pierwszego programu SAProuter i zapewnia dostęp do poszczególnych systemów SAP i maszyn wirtualnych. Ten projekt umożliwia oddzielenie dostępu i zarządzania między różnymi zespołami, jeśli zajdzie taka potrzeba. Aby zapoznać się z przykładem kaskadowego programu SAProuters, zobacz Konfiguracja komputera SAProuter z usługą Azure Firewall.

SAP Fiori i WebGui

Oprogramowanie SAP Fiori i inne frontony HTTPS dla aplikacji SAP są często używane spoza wewnętrznej sieci firmowej. Wymagana dostępność w Internecie wymaga rozwiązania o wysokim poziomie zabezpieczeń, aby chronić aplikację SAP. Usługa Application Gateway z zaporą aplikacji internetowej jest idealną usługą do tego celu.

W przypadku użytkowników i aplikacji uzyskujących dostęp do publicznej nazwy hosta publicznego adresu IP powiązanego z usługą Application Gateway sesja HTTPS zostanie zakończona w usłudze Application Gateway. Pula zaplecza co najmniej dwóch maszyn wirtualnych programu SAP Web Dispatcher pobiera sesje działania okrężnego z usługi Application Gateway. Ta wewnętrzna brama aplikacji ruchu sieciowego do usługi Web Dispatcher może być http lub HTTPS, w zależności od wymagań. W przypadku protokołu HTTPS między usługą Application Gateway i maszynami wirtualnymi programu Web Dispatcher użyj certyfikatu i łańcucha certyfikatów dobrze znanego zespołowi SAP w celu dowolnego okresowego rotacji certyfikatów. Zapora aplikacji internetowej pomaga chronić program SAP Web Dispatcher przed atakami przychodzącymi przez Internet przy użyciu podstawowego zestawu reguł OWASP. Oprogramowanie SAP NetWeaver, często powiązane z identyfikatorem Entra firmy Microsoft za pośrednictwem logowania jednokrotnego ,wykonuje uwierzytelnianie użytkownika. Aby uzyskać instrukcje wymagane do skonfigurowania logowania jednokrotnego dla aplikacji Fiori przy użyciu usługi Application Gateway, zobacz Logowanie jednokrotne Configuration using SAML and Microsoft Entra ID for Public and Internal URL (Konfiguracja usługi Logowanie jednokrotne przy użyciu protokołu SAML i identyfikatora Entra firmy Microsoft dla publicznych i wewnętrznych adresów URL).

Należy pamiętać, że należy zabezpieczyć program SAP Web Dispatcher w dowolnej sytuacji, nawet jeśli jest otwarty tylko wewnętrznie, uzyskiwany za pośrednictwem usługi Application Gateway za pośrednictwem publicznego adresu IP lub dostępny za pośrednictwem innych środków sieciowych. Aby uzyskać więcej informacji, zobacz Security Information for SAP Web Dispatcher (Informacje o zabezpieczeniach dla programu SAP Web Dispatcher).

Usługa Azure Firewall i usługa Application Gateway

Cały ruch internetowy udostępniany przez usługę Application Gateway jest oparty na protokole HTTPS i szyfrowany przy użyciu dostarczonego certyfikatu TLS. Usługę Azure Firewall można użyć jako punktu wejścia do sieci firmowej, za pośrednictwem publicznego adresu IP, a następnie kierować ruch SAP Fiori z zapory do usługi Application Gateway za pośrednictwem wewnętrznego adresu IP. Aby uzyskać więcej informacji, zobacz Application Gateway after firewall (Usługa Application Gateway po zaporze). Ponieważ szyfrowanie tcp/IP warstwy 7 jest już włączone za pośrednictwem protokołu TLS, w tym scenariuszu istnieje ograniczona korzyść z używania zapory i nie można przeprowadzić inspekcji pakietów. Fiori komunikuje się za pośrednictwem tego samego zewnętrznego adresu IP zarówno dla ruchu przychodzącego, jak i wychodzącego, który zazwyczaj nie jest wymagany w przypadku wdrożeń sap Fiori.

Istnieją pewne korzyści wynikające z wdrożenia usługi Application Gateway i zapory w warstwie 4:

  • Możliwa integracja z zarządzaniem zasadami zabezpieczeń w całym przedsiębiorstwie.
  • Ruch sieciowy, który narusza reguły zabezpieczeń, jest już odrzucany, więc nie wymaga inspekcji.

To połączone wdrożenie jest dobrą architekturą. Metoda obsługi przychodzącego ruchu internetowego zależy od ogólnej architektury przedsiębiorstwa. Należy również rozważyć, w jaki sposób ogólna architektura sieci pasuje do metod dostępu z wewnętrznej przestrzeni adresowej IP, takich jak klienci lokalni. Ta kwestia jest omówiona w następnej sekcji.

Usługa Application Gateway dla wewnętrznych adresów IP (opcjonalnie)

Ta architektura koncentruje się na aplikacjach internetowych. Dostępne są różne opcje dla klientów uzyskujących dostęp do oprogramowania SAP Fiori, internetowego interfejsu użytkownika systemu SAP NetWeaver lub innego interfejsu HTTPS sap za pośrednictwem wewnętrznego, prywatnego adresu IP. Jednym ze scenariuszy jest traktowanie całego dostępu do Fiori jako dostępu publicznego za pośrednictwem publicznego adresu IP. Inną opcją jest użycie bezpośredniego dostępu sieciowego za pośrednictwem sieci prywatnej do dyspozytorów SAP Web Dispatchers, pomijając całkowicie usługę Application Gateway. Trzecią opcją jest użycie zarówno prywatnych, jak i publicznych adresów IP w usłudze Application Gateway, zapewniając dostęp zarówno do Internetu, jak i sieci prywatnej.

Podobną konfigurację można użyć z prywatnym adresem IP w usłudze Application Gateway, aby uzyskać dostęp sieciowy tylko do środowiska sap. Publiczny adres IP w tym przypadku jest używany tylko do celów zarządzania i nie ma skojarzonego z nim odbiornika.

Alternatywą dla korzystania z usługi Application Gateway jest użycie modułu równoważenia obciążenia wewnętrznie. Możesz użyć standardowego wewnętrznego modułu równoważenia obciążenia z maszynami wirtualnymi usługi Web Dispatcher skonfigurowanymi jako zaplecze okrężne. W tym scenariuszu standardowy moduł równoważenia obciążenia jest umieszczany z maszynami wirtualnymi usługi Web Dispatcher w podsieci aplikacji produkcyjnej SAP i zapewnia aktywne/aktywne równoważenie obciążenia między maszynami wirtualnymi usługi Web Dispatcher.

W przypadku wdrożeń dostępnych z Internetu zalecamy użycie usługi Application Gateway z zaporą aplikacji internetowej zamiast modułu równoważenia obciążenia z publicznym adresem IP.

SAP Business Technology Platform (BTP)

SAP BTP to duży zestaw aplikacji SAP, SaaS lub PaaS, do których zazwyczaj uzyskuje się dostęp za pośrednictwem publicznego punktu końcowego za pośrednictwem Internetu. Łącznik SAP Cloud Connector jest często używany do zapewniania komunikacji dla aplikacji działających w sieciach prywatnych, takich jak system SAP S/4HANA uruchomiony na platformie Azure. Łącznik SAP Cloud Connector działa jako aplikacja na maszynie wirtualnej. Wymaga ona wychodzącego dostępu do Internetu w celu ustanowienia tunelu HTTPS szyfrowanego protokołem TLS za pomocą protokołu SAP BTP. Działa jako zwrotny serwer proxy wywołania między zakresem prywatnych adresów IP w sieci wirtualnej a aplikacjami SAP BTP. Z powodu tej obsługi wywołania odwrotnego nie ma potrzeby otwierania portów zapory ani innego dostępu do połączeń przychodzących, ponieważ połączenie z sieci wirtualnej jest wychodzące.

Domyślnie maszyny wirtualne mają natywny dostęp do Internetu dla ruchu wychodzącego na platformie Azure. Publiczny adres IP używany do ruchu wychodzącego, gdy nie ma dedykowanego publicznego adresu IP skojarzonego z maszyną wirtualną, jest losowo wybierany z puli publicznych adresów IP w określonym regionie świadczenia usługi Azure. Nie można go kontrolować. Aby upewnić się, że połączenia wychodzące są wykonywane za pośrednictwem kontrolowanej i możliwej do zidentyfikowania usługi i adresu IP, można użyć jednej z następujących metod:

  • Brama translatora adresów sieciowych skojarzona z podsiecią lub modułem równoważenia obciążenia i jego publicznym adresem IP.
  • Serwery proxy HTTP, które działają.
  • Trasa zdefiniowana przez użytkownika, która wymusza przepływ ruchu sieciowego do urządzenia sieciowego, takiego jak zapora.

Diagram architektury przedstawia najbardziej typowy scenariusz: routing ruchu powiązanego z Internetem do sieci wirtualnej koncentratora i przez centralną zaporę. Aby nawiązać połączenie z kontem SAP BTP, należy skonfigurować dalsze ustawienia w programie SAP Cloud Connector.

Wysoka dostępność łącznika SAP Cloud Connector

Wysoka dostępność jest wbudowana w łącznik SAP Cloud Connector. Łącznik chmury jest instalowany na dwóch maszynach wirtualnych. Wystąpienie główne jest aktywne, a wystąpienie w tle jest z nim połączone. Współużytkują konfigurację i są synchronizowane natywnie. Jeśli wystąpienie główne nie jest dostępne, pomocnicza maszyna wirtualna próbuje przejąć główną rolę i ponownie ustanowić tunel TLS do protokołu SAP BTP. Środowisko łącznika chmury o wysokiej dostępności jest wyświetlane w architekturze. W przypadku konfiguracji nie potrzebujesz żadnych innych technologii platformy Azure, takich jak moduł równoważenia obciążenia lub oprogramowanie klastra. Aby uzyskać szczegółowe informacje na temat konfiguracji i operacji, zobacz dokumentację systemu SAP.

SAP Analytics Cloud Agent

W przypadku niektórych scenariuszy aplikacji agent SAP Analytics Cloud Agent to aplikacja zainstalowana na maszynie wirtualnej. Korzysta z łącznika SAP Cloud Connector na potrzeby łączności SAP BTP. W tej architekturze maszyna wirtualna agenta sap Analytics Cloud Agent działa w podsieci aplikacji obwodowej SAP wraz z maszynami wirtualnymi łącznika SAP Cloud Connector. Aby uzyskać przepływ ruchu z sieci prywatnych, takich jak sieć wirtualna platformy Azure do systemu SAP BTP za pośrednictwem agenta SAP Analytics Cloud Agent, zobacz dokumentację systemu SAP.

Oprogramowanie SAP udostępnia usługę Private Link dla oprogramowania SAP BTP. Umożliwia ona połączenia prywatne między wybranymi usługami SAP BTP i wybranymi usługami w ramach subskrypcji platformy Azure i sieci wirtualnej. W przypadku korzystania z usługi Private Link komunikacja nie jest kierowana przez publiczny Internet. Pozostaje ona w globalnej sieci szkieletowej platformy Azure o wysokim poziomie zabezpieczeń. Komunikacja z usługami platformy Azure odbywa się za pośrednictwem prywatnej przestrzeni adresowej. Ulepszona ochrona eksfiltracji danych jest wbudowana w przypadku korzystania z usługi Private Link, ponieważ prywatny punkt końcowy mapuje konkretną usługę platformy Azure na adres IP. Dostęp jest ograniczony do zamapowanej usługi platformy Azure.

W przypadku niektórych scenariuszy integracji sap BTP preferowane jest podejście usługi Private Link. W przypadku innych użytkowników łącznik SAP Cloud Connector jest lepszy. Aby uzyskać informacje ułatwiające podjęcie decyzji o użyciu, zobacz Running Cloud Connector and SAP Private Link side-by-side (Uruchamianie łącznika chmury i usługi SAP Private Link).

SAP RISE/ECS

Jeśli system SAP obsługuje system SAP w ramach kontraktu SAP RISE/ECS, sap jest partnerem usług zarządzanych. Środowisko SAP jest wdrażane przez system SAP. W architekturze sap architektura przedstawiona w tym miejscu nie ma zastosowania do systemów uruchomionych w rozwiązaniu RISE z oprogramowaniem SAP/ECS. Aby uzyskać informacje na temat integrowania tego typu oprogramowania SAP z usługami platformy Azure i siecią, zobacz dokumentację platformy Azure.

Inne wymagania dotyczące komunikacji z oprogramowaniem SAP

Dodatkowe zagadnienia dotyczące komunikacji powiązanej z Internetem mogą mieć zastosowanie do środowiska SAP działającego na platformie Azure. Przepływ ruchu w tej architekturze używa centralnej zapory platformy Azure dla tego ruchu wychodzącego. Reguły zdefiniowane przez użytkownika w sieciach wirtualnych szprych kierują żądania ruchu powiązanego z Internetem do zapory. Alternatywnie można użyć bram translatora adresów sieciowych w określonych podsieciach, domyślnej komunikacji wychodzącej platformy Azure, publicznych adresów IP na maszynach wirtualnych (niezalecane) lub publicznego modułu równoważenia obciążenia z regułami ruchu wychodzącego. Typowe scenariusze docierają do publicznych punktów końcowych identyfikatora Firmy Microsoft Entra, interfejsów API zarządzania platformy Azure w management.azure.com oraz usług aplikacji innych firm lub aplikacji dla instytucji rządowych za pośrednictwem dostępu do sieci wychodzącej.

Ze względu na zmiany domyślnego dostępu wychodzącego na platformie Azure upewnij się, że zdefiniowany jest skalowalny dostęp wychodzący. W przypadku maszyn wirtualnych, które znajdują się za standardowym wewnętrznym modułem równoważenia obciążenia, podobnie jak w środowiskach klastrowanych, należy pamiętać, że usługa Load Balancer w warstwie Standardowa modyfikuje zachowanie łączności publicznej. Aby uzyskać więcej informacji, zobacz Łączność z publicznym punktem końcowym dla maszyn wirtualnych korzystających z usługi Azure usługa Load Balancer w warstwie Standardowa w scenariuszach wysokiej dostępności oprogramowania SAP.

Aby uzyskać więcej informacji na temat domyślnej łączności wychodzącej z maszyn wirtualnych, zobacz Routing options for VMs from Private Subnets (Opcje routingu dla maszyn wirtualnych z podsieci prywatnych) w blogu Dotyczącym sieci platformy Azure.

Aktualizacje systemu operacyjnego

Aktualizacje systemu operacyjnego są często zlokalizowane za publicznym punktem końcowym i dostępne za pośrednictwem Internetu. Jeśli nie istnieją żadne repozytoria przedsiębiorstwa i zarządzanie aktualizacjami, dublowanie aktualizacji systemu operacyjnego od dostawców na prywatnych adresach IP/maszynach wirtualnych, obciążenie SAP musi mieć dostęp do repozytoriów aktualizacji dostawców.

W przypadku systemów operacyjnych Linux możesz uzyskać dostęp do następujących repozytoriów, jeśli uzyskasz licencję systemu operacyjnego z platformy Azure. Jeśli zakupisz licencje bezpośrednio i dodasz je do platformy Azure (BYOS), skontaktuj się z dostawcą systemu operacyjnego, aby uzyskać informacje o sposobach nawiązywania połączenia z repozytoriami systemu operacyjnego i ich odpowiednimi zakresami adresów IP.

Zarządzanie klastrem o wysokiej dostępności

Systemy o wysokiej dostępności, takie jak klastrowane systemy SAP ASCS/SCS lub bazy danych, mogą używać menedżera klastra z agentem ogrodzenia platformy Azure jako urządzeniem STONITH. Te systemy zależą od dotarcia do usługi Azure Resource Manager. Usługa Resource Manager służy do wykonywania zapytań o stan zasobów platformy Azure i operacji w celu zatrzymywania i uruchamiania maszyn wirtualnych. Ponieważ usługa Resource Manager jest publicznym punktem końcowym, dostępnym w obszarze management.azure.com, komunikacja wychodząca maszyny wirtualnej musi być w stanie nawiązać z nim połączenie. Ta architektura opiera się na centralnej zaporze z regułami zdefiniowanymi przez użytkownika routingu ruchu z sieci wirtualnych SAP. Aby uzyskać alternatywy, zobacz poprzednie sekcje.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Inny współautor:

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Społeczności

Rozważ użycie tych społeczności, aby uzyskać odpowiedzi na pytania i uzyskać pomoc dotyczącą konfigurowania wdrożenia:

Następne kroki