Szerkesztés

Megosztás a következőn keresztül:

Bejövő és kimenő internetkapcsolatok az Azure-beli SAP-hoz

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

Ez a cikk az Azure-infrastruktúrán futó SAP bejövő és kimenő internetkapcsolatainak biztonságának javításához számos bevált gyakorlatot tartalmaz.

Architektúra

Az Azure-beli SAP internetes kommunikációjának megoldását bemutató ábra.

Töltse le a cikkben szereplő architektúrák Visio-fájlját.

Ez a megoldás egy gyakori éles környezetet mutat be. A követelményeknek megfelelően csökkentheti a konfiguráció méretét és hatókörét. Ez a csökkentés az SAP-környezetre vonatkozhat: kevesebb virtuális gép (virtuális gép), nincs magas rendelkezésre állás, vagy beágyazott SAP Web Dispatchers a különálló virtuális gépek helyett. A hálózat kialakításának alternatíváira is alkalmazható, a cikk későbbi részében leírtak szerint.

Az üzleti szabályzatok által vezérelt ügyfélkövetelmények az architektúra, különösen a hálózat kialakításának adaptálását igénylik. Lehetőség szerint alternatív megoldásokat is tartalmaztunk. Számos megoldás életképes. Válasszon egy, a vállalkozásának megfelelő megközelítést. Segítenie kell az Azure-erőforrások biztonságossá tételében, de továbbra is teljesítendő megoldást kell nyújtania.

A vészhelyreállítást (DR) ez az architektúra nem fedi le. A hálózat kialakítására ugyanazok az alapelvek és kialakítás érvényesek, amelyek az elsődleges éles régiókban érvényesek. A hálózat kialakításában a DR által védett alkalmazásoktól függően fontolja meg a DR engedélyezését egy másik Azure-régióban. További információ: Vészhelyreállítás áttekintése és az SAP számítási feladataihoz kapcsolódó infrastruktúra-irányelvek

Munkafolyamat

  • A helyszíni hálózat az Azure ExpressRoute-on keresztül csatlakozik egy központi központhoz. A központi virtuális hálózat egy átjáróalhálózatot, egy Azure Firewall-alhálózatot, egy megosztott szolgáltatási alhálózatot és egy Azure-alkalmazás Átjáró alhálózatot tartalmaz.
  • A központ virtuális hálózati társviszony-létesítésen keresztül csatlakozik egy SAP éles előfizetéshez. Ez az előfizetés két küllős virtuális hálózatot tartalmaz:
    • Az SAP szegélyhálózata egy SAP szegélyalkalmazás-alhálózatot tartalmaz.
    • Az SAP éles virtuális hálózata egy alkalmazás-alhálózatot és egy adatbázis-alhálózatot tartalmaz.
  • A központi előfizetés és az SAP éles előfizetés nyilvános IP-címeken keresztül csatlakozik az internethez.

Összetevők

Előfizetések. Ez az architektúra implementálja az Azure célzóna-megközelítést . Minden számítási feladathoz egy Azure-előfizetést használunk. Egy vagy több előfizetést használnak a központi informatikai szolgáltatásokhoz, amelyek tartalmazzák a hálózati központot és a központi szolgáltatást, megosztott szolgáltatásokat, például tűzfalakat vagy Active Directoryt és DNS-t. A rendszer egy másik előfizetést használ az SAP éles számítási feladataihoz. Az Azure-hoz készült felhőadaptálási keretrendszer döntési útmutatója alapján állapítsa meg a forgatókönyve legjobb előfizetési stratégiáját.

Virtuális hálózatok. Az Azure Virtual Network fokozott biztonsággal összekapcsolja az Azure-erőforrásokat egymással. Ebben az architektúrában a virtuális hálózat egy küllős topológia központjában üzembe helyezett ExpressRoute- vagy virtuális magánhálózati (VPN-) átjárón keresztül csatlakozik egy helyszíni környezethez. Az SAP éles környezete saját küllős virtuális hálózatokat használ. Két különálló küllős virtuális hálózat különböző feladatokat végez, az alhálózatok pedig a hálózat elkülönítését biztosítják.

Az alhálózatok számítási feladatok szerinti elkülönítése megkönnyíti a hálózati biztonsági csoportok (NSG-k) használatát az üzembe helyezett alkalmazás virtuális gépek vagy Azure-szolgáltatások biztonsági szabályainak beállításához.

Zónaredundáns átjáró. Az átjárók különböző hálózatokat kötnek össze, így a helyszíni hálózatot kiterjesztik az Azure-beli virtuális hálózatra. Javasoljuk, hogy az ExpressRoute használatával hozzon létre olyan privát kapcsolatokat, amelyek nem használják a nyilvános internetet. A helyek közötti kapcsolatot is használhatja. Zónaredundáns Azure ExpressRoute- vagy VPN-átjárókkal védheti a zónahibákat. A zónaredundáns virtuális hálózati átjárókat a zónaredundáns üzembe helyezés és a zónaredundáns üzembe helyezés közötti különbségek magyarázatához tekintse meg. Az átjárók zónatelepítéséhez standard termékváltozatú IP-címeket kell használnia.

NSG-k. A virtuális hálózat felé és onnan érkező hálózati forgalom korlátozásához hozzon létre NSG-ket , és rendelje hozzá őket adott alhálózatokhoz. Az egyes alhálózatok biztonságának biztosítása számítási feladatspecifikus NSG-k használatával.

Alkalmazásbiztonsági csoportok. Ha részletes hálózati biztonsági szabályzatokat szeretne definiálni az NSG-kben az alkalmazásokra összpontosító számítási feladatok alapján, használjon alkalmazásbiztonsági csoportokat explicit IP-címek helyett. Alkalmazásbiztonsági csoportok használatával cél szerint csoportosíthatja a virtuális gépeket, például az SAP SID-et. Az alkalmazásbiztonsági csoportok a hálózat megbízható szegmenseiből származó forgalom szűrésével segítik az alkalmazások védelmét.

Privát végpont. Számos Azure-szolgáltatás működik nyilvános szolgáltatásként, az interneten keresztül elérhető kialakítással. A magánhálózati tartományon keresztüli privát hozzáférés engedélyezéséhez egyes szolgáltatásokhoz privát végpontokat használhat. A privát végpontok a virtuális hálózat hálózati adapterei. Hatékonyan behozzák a szolgáltatást a magánhálózati térbe.

Azure-alkalmazás átjáró. Az Application Gateway egy webes forgalom terheléselosztója. A webalkalmazási tűzfal funkciójával ideális szolgáltatás a webalkalmazások internetes elérhetővé ciójára, nagyobb biztonsággal. Az Application Gateway a konfigurációtól függően képes kiszolgálni a nyilvános (internetes) vagy a magánügyfeleket, vagy mindkettőt.

Az architektúrában az Application Gateway nyilvános IP-címmel engedélyezi a bejövő kapcsolatokat az SAP-környezethez HTTPS-en keresztül. A háttérkészlete két vagy több SAP Web Dispatcher virtuális gép, amely ciklikus időszeleteléssel érhető el, és magas rendelkezésre állást biztosít. Az Application Gateway fordított proxy és webes forgalom terheléselosztó, de nem helyettesíti az SAP Web Dispatchert. Az SAP Web Dispatcher alkalmazásintegrációt biztosít az SAP-rendszerekkel, és olyan funkciókat is tartalmaz, amelyeket az Application Gateway önmagában nem biztosít. Az ügyfélhitelesítést az SAP-alkalmazásréteg natív vagy egyszeri bejelentkezéssel hajtja végre, amikor eléri az SAP-rendszereket. Az Azure DDoS-védelem engedélyezésekor fontolja meg a DDoS hálózatvédelmi termékváltozat használatát, mivel kedvezményeket fog látni az Application Gateway webalkalmazási tűzfalára vonatkozóan.

Az optimális teljesítmény érdekében engedélyezze a HTTP/2 támogatását az Application Gatewayhez, az SAP Web Dispatcherhez és az SAP NetWeaverhez.

Azure Load Balancer. Az Azure Standard Load Balancer hálózati elemeket biztosít az SAP-rendszerek magas rendelkezésre állású kialakításához. Fürtözött rendszerek esetén a Standard Load Balancer biztosítja a fürtszolgáltatás virtuális IP-címét, például az ASCS/SCS-példányokat és a virtuális gépeken futó adatbázisokat. A Standard Load Balancer használatával megadhatja a nem fürtözött rendszerek virtuális SAP-gazdagépének IP-címét is, ha az Azure-hálózati kártyák másodlagos IP-címei nem választhatók. A cikk későbbi részében az Application Gateway helyett a Standard Load Balancer használata a kimenő internet-hozzáférés kezelésére vonatkozik.

Hálózattervezés

Az architektúra két különálló virtuális hálózatot használ, mindkettő küllős virtuális hálózatot, amelyek a központi központi virtuális hálózathoz vannak társviszonyban. Nincs küllős társviszony. A rendszer csillagtopológiát használ, amelyben a kommunikáció áthalad a központon. A hálózatok elkülönítése segít megvédeni az alkalmazásokat a biztonsági résektől.

Az alkalmazásspecifikus szegélyhálózat (más néven DMZ) tartalmazza az internetkapcsolattal rendelkező alkalmazásokat, például a SAProutert, az SAP Cloud Connectort, az SAP Analytics Cloud Agentet és más alkalmazásokat. Az architektúradiagramon a szegélyhálózat neve SAP szegélyhálózat – küllős virtuális hálózat. Az SAP-rendszerek függőségei miatt az SAP-csapat általában elvégzi ezeknek a szolgáltatásoknak az üzembe helyezését, konfigurálását és felügyeletét. Ezért ezek az SAP-szegélyszolgáltatások gyakran nem központi központi előfizetésben és hálózaton találhatók. A szervezeti kihívások gyakran a számítási feladatokhoz kapcsolódó alkalmazások vagy szolgáltatások központi központi elhelyezésének köszönhetők.

A különálló SAP szegélyhálózat használatának néhány előnye:

  • Biztonsági rés észlelése esetén a sérült szolgáltatások gyors és azonnali elkülönítése. Ha eltávolítja a virtuális hálózatok közötti társviszonyt az SAP-szegélyről a központra, azonnal elkülöníti az SAP peremhálózati számítási feladatait és az SAP-alkalmazás virtuális hálózati alkalmazásait az internetről. A hozzáférést lehetővé tevő NSG-szabály módosítása vagy eltávolítása csak az új kapcsolatokat érinti, és nem csökkenti a meglévő kapcsolatokat.
  • Szigorúbb ellenőrzések a virtuális hálózaton és az alhálózaton, szigorúan zárolva a kommunikációs partnereket az SAP szegélyhálózatán és az SAP-alkalmazáshálózatokon. Az SAP peremalkalmazások engedélyezett felhasználóira és hozzáférési módszereire is kiterjesztheti a nagyobb felügyeletet különböző engedélyezési háttérrendszerekkel, emelt szintű hozzáféréssel vagy bejelentkezési hitelesítő adatokkal az SAP szegélyalkalmazásaihoz.

Ennek hátránya a megnövekedett összetettség és az internethez kötött SAP-forgalomhoz kapcsolódó virtuális hálózatok közötti társviszony-létesítési többletköltségek (mivel a kommunikációnak kétszer kell áthaladnia a virtuális hálózatok közötti társviszony-létesítésen). A küllő-központ küllős társviszony-létesítési forgalmára gyakorolt késés minden olyan tűzfaltól függ, amelyet meg kell mérni.

Egyszerűsített architektúra

A cikkben szereplő javaslatok kezeléséhez, de a hátrányok korlátozásához használhat egyetlen küllős virtuális hálózatot a szegélyhálózathoz és az SAP-alkalmazásokhoz is. Az alábbi architektúra egyetlen SAP éles virtuális hálózat összes alhálózatát tartalmazza. Az azonnali elkülönítés előnye a virtuális hálózatok sap-szegélyhez való társviszonyának megszüntetésével, ha az nem érhető el. Ebben a forgatókönyvben az NSG-k változásai csak az új kapcsolatokat érintik.

Az Azure-beli SAP internetes kommunikációjának egyszerűsített architektúrát bemutató ábra.

Töltse le a cikkben szereplő architektúrák Visio-fájlját.

A kisebb méretű és hatókörű üzemelő példányok esetében az egyszerűsített architektúra jobban illeszkedhet, és továbbra is megfelel az összetettebb architektúra alapelveinek. Ez a cikk, hacsak másként nem említi, az összetettebb architektúrára hivatkozik.

Az egyszerűsített architektúra NAT-átjárót használ az SAP szegélyhálózatán. Ez az átjáró kimenő kapcsolatot biztosít az SAP Cloud Connectorhoz, az SAP Analytics Cloud Agenthez és az operációs rendszer frissítéséhez az üzembe helyezett virtuális gépekhez. Mivel a SAProuter bejövő és kimenő kapcsolatokat is igényel, a SAProuter kommunikációs útvonala a NAT-átjáró használata helyett a tűzfalon halad át. Az egyszerűsített architektúra az Application Gatewayt saját kijelölt alhálózattal is az SAP peremhálózatán helyezi el alternatív megközelítésként a központi virtuális hálózathoz.

A NAT-átjárók olyan szolgáltatások, amelyek statikus nyilvános IP-címeket biztosítanak a kimenő kapcsolatokhoz. A NAT-átjáró egy alhálózathoz van rendelve. Minden kimenő kommunikáció a NAT-átjáró IP-címét használja az internet-hozzáféréshez. A bejövő kapcsolatok nem használják a NAT-átjárót. Az olyan alkalmazások, mint az SAP Cloud Connector vagy a virtuálisgép-operációs rendszer frissítési szolgáltatásai, amelyek az interneten férnek hozzá az adattárakhoz, használhatják a NAT-átjárót ahelyett, hogy az összes kimenő forgalmat a központi tűzfalon keresztül irányítanák. A felhasználó által definiált szabályok gyakran minden alhálózaton implementálva kényszerítik az internethez kötött forgalmat az összes virtuális hálózatról a központi tűzfalon keresztül.

A követelményektől függően előfordulhat, hogy a NAT-átjárót használhatja a központi tűzfal alternatívaként a kimenő kapcsolatokhoz. Ezzel csökkentheti a központi tűzfal terhelését, miközben kommunikál az NSG által engedélyezett nyilvános végpontokkal. Kimenő IP-vezérlést is kaphat, mivel a cél tűzfalszabályokat konfigurálhatja a NAT-átjáró beállított IP-listáján. Ilyenek például a nyilvános szolgáltatások, operációsrendszer-javítástárak vagy külső felületek által használt Nyilvános Azure-végpontok elérése.

Magas rendelkezésre állású konfiguráció esetén ne feledje, hogy a NAT-átjáró csak egyetlen zónában van üzembe helyezve, és jelenleg nem zónaközi redundáns. Egyetlen NAT-átjáróval nem ideális olyan SAP-üzemelő példányokhoz, amelyek zónaredundáns (zónák közötti) üzembe helyezést használnak a virtuális gépekhez.

Hálózati összetevők használata sap-környezetekben

Az architektúradokumentumok általában csak egy SAP-rendszert vagy fekvő tájolást ábrázolnak. Így könnyebben megérthetők. Ennek az az eredménye, hogy gyakran nem foglalkozunk azzal, hogy az architektúra hogyan illeszkedik egy nagyobb SAP-környezetbe, amely több rendszersávot és szintet tartalmaz.

A központi hálózati szolgáltatásokat, például a tűzfalat, a NAT-átjárót és a proxykiszolgálókat, ha üzembe helyezték, a legjobban az összes réteg sap-környezetében használják: az éles üzem, az éles üzem előtti, a fejlesztési és a tesztkörnyezet. A követelményektől, a szervezet méretétől és az üzleti szabályzatoktól függően érdemes lehet rétegenként külön implementációkat, vagy egy éles és egy tesztkörnyezetet figyelembe venni.

Az SAP-rendszert jellemzően kiszolgáló szolgáltatások az alábbiak szerint vannak a legjobban elkülönítve:

  • A terheléselosztókat külön-külön kell elosztani. A vállalati szabályzat meghatározza az erőforrások elnevezését és csoportosítását. Az ASCS-hez/SCS-hez és az ERS-hez egy terheléselosztót, egy másikat pedig az adatbázishoz, az egyes SAP SID-ekhez külön kell elválasztanunk. Másik lehetőségként egy SAP-rendszer (A)SCS, ERS és DB fürtöinek egyetlen terheléselosztója is jó kialakítású. Ez a konfiguráció segít biztosítani, hogy a hibaelhárítás ne legyen összetett, mivel számos előtér- és háttérkészlet és terheléselosztási szabály egyetlen terheléselosztón található. Az SAP SID-enként egyetlen terheléselosztó biztosítja azt is, hogy az erőforráscsoportokban való elhelyezés megegyezik a többi infrastruktúra-összetevőével.
  • Az Application Gateway a terheléselosztóhoz hasonlóan több háttérrendszert, előtér-, HTTP-beállításokat és szabályokat is lehetővé tesz. Itt gyakoribb az a döntés, hogy egy Application Gatewayt több célra is használ, mivel a környezet nem minden SAP-rendszere igényel nyilvános hozzáférést. Ebben a kontextusban több felhasználási mód is van: különböző webkonzolportok ugyanazon SAP S/4HANA-rendszerekhez vagy különböző SAP-környezetekhez. Rétegenként (éles, nem éles és tesztkörnyezet) legalább egy Application Gatewayt javasoljuk, kivéve, ha a csatlakoztatott rendszerek összetettsége és száma túl magas lesz.
  • Az SAP-szolgáltatások, például a SAProuter, a Cloud Connector és az Analytics Cloud Agent, központilag vagy felosztva, alkalmazáskövetelmények alapján vannak üzembe helyezve. A termelés és a nem éles elkülönítés gyakran kívánatos.

Alhálózat méretezése és tervezése

Ha alhálózatokat tervez az SAP-környezethez, mindenképpen kövesse a méretezési és tervezési alapelveket:

  • Számos Szolgáltatásként nyújtott Azure-platformhoz (PaaS) saját alhálózatokra van szükség.
  • Az Application Gateway egy /24-alhálózatot javasol a skálázáshoz. Ha úgy dönt, hogy korlátozza az Application Gateway skálázását, egy kisebb alhálózatot is használhat, legalább /26 vagy nagyobb méretben. Az Application Gateway (1 és 2) mindkét verzióját nem használhatja ugyanabban az alhálózatban.
  • Ha az Azure NetApp Filest használja NFS-/SMB-megosztásokhoz vagy adatbázis-tárolókhoz, egy kijelölt alhálózatra van szükség. A /24 alhálózat az alapértelmezett. A megfelelő méretezés meghatározásához használja a követelményeket.
  • Ha SAP virtuális gazdagépneveket használ, több címtérre van szüksége az SAP-alhálózatokban, beleértve az SAP szegélyhálózatát is.
  • Az olyan központi szolgáltatásokhoz, mint az Azure Bastion vagy az Azure Firewall, amelyeket általában egy központi informatikai csapat felügyel, saját, megfelelő méretű dedikált alhálózatokra van szükség.

Ha dedikált alhálózatokat használ az SAP-adatbázisokhoz és -alkalmazásokhoz, az NSG-k szigorúbbak lehetnek, ami segít megvédeni mindkét alkalmazástípust a saját szabálykészletükkel. Ezután egyszerűbben korlátozhatja az adatbázis-hozzáférést az SAP-alkalmazásokhoz anélkül, hogy alkalmazásbiztonsági csoportokat kellene igénybe vennie a részletes vezérléshez. Az SAP-alkalmazások és az adatbázis-alhálózatok elkülönítése megkönnyíti a biztonsági szabályok NSG-kben való kezelését is.

SAP-szolgáltatások

SAProuter

A SAProuter használatával engedélyezheti harmadik felek, például az SAP-támogatás vagy partnerei számára az SAP-rendszerhez való hozzáférést. A SAProuter egy Azure-beli virtuális gépen fut. A SAProuter használatára vonatkozó útvonalengedélyek egy saprouttab nevű egybesimított fájlban vannak tárolva. A saprouttab-bejegyzések lehetővé teszik bármely TCP/IP-portról a SAProuter mögötti hálózati célhoz való csatlakozást, jellemzően az SAP-rendszer virtuális gépeihez. Az SAP-támogatás által nyújtott távelérés az SAProuterre támaszkodik. A fő architektúra a korábban ismertetett kialakítást használja, és egy SAProuter virtuális gép fut a kijelölt SAP szegélyhálózaton belül. A virtuális hálózatok közötti társviszony-létesítés révén az SAProuter ezután kommunikál a saját küllős virtuális hálózatukban és alhálózataikban futó SAP-kiszolgálókkal.

A SAProuter egy alagút az SAP-hez vagy a partnerekhez. Ez az architektúra az SAProuter és az SNC használatát ismerteti egy titkosított alkalmazásalagút (7. hálózati réteg) létrehozására az SAP/partnerek számára. Az IPSEC-alapú alagút használatát jelenleg nem fedi le ez az architektúra.

Az alábbi funkciók segítenek megvédeni a kommunikációs útvonalat az interneten keresztül:

  • Az Azure Firewall vagy egy külső NVA biztosítja a nyilvános IP-belépési pontot az Azure-hálózatokba. A tűzfalszabályok csak az engedélyezett IP-címekre korlátozzák a kommunikációt. Az SAP-támogatással való kapcsolathoz az SAP 48243– A SAProuter szoftver tűzfalkörnyezetbe való integrálása az SAP-útválasztók IP-címeit dokumentálja.
  • A tűzfalszabályokhoz hasonlóan a hálózati biztonsági szabályok lehetővé teszik az SAProuter portján való kommunikációt, általában a 3299-et a kijelölt célhelyen.
  • A SAPProuter engedélyezési/megtagadási szabályait a saprouttab fájlban tartja fenn, megadva, hogy ki léphet kapcsolatba a SAProuterrel, és melyik SAP-rendszer érhető el.
  • További NSG-szabályok vannak érvényben az SAP éles alhálózatának megfelelő alhálózatán, amely tartalmazza az SAP-rendszereket.

Az SAProuter Azure Firewalllal való konfigurálásának lépéseit lásd: SAProuter-konfiguráció az Azure Firewall használatával.

SAProuter biztonsági megfontolások

Mivel a SAProuter nem ugyanabban az alkalmazásalhálózatban működik, mint az SAP-rendszerek, az operációs rendszer bejelentkezési mechanizmusai eltérőek lehetnek. A szabályzatoktól függően használhat külön bejelentkezési tartományt vagy teljesen csak gazdagépes felhasználói hitelesítő adatokat a SAProuterhez. Biztonsági incidens esetén a belső SAP-rendszerekhez való kaszkádolt hozzáférés nem lehetséges a különböző hitelesítőadat-alap miatt. Ilyen esetben a hálózatelválasztás a korábban ismertetett módon leválaszthatja a sérült SAProuter további hozzáférését az alkalmazás alhálózataihoz. Ezt az elkülönítést az SAP szegélyhálózat-társviszonyának leválasztásával teheti meg.

SAProuter magas rendelkezésre állási szempontok

Mivel a SAProuter egy fájlalapú útvonalengedély-táblával rendelkező egyszerű végrehajtható fájl, könnyen elindítható. Az alkalmazásnak nincs beépített magas rendelkezésre állása. Ha virtuális gép vagy alkalmazáshiba történik, a szolgáltatásnak egy másik virtuális gépen kell elindulnia. A SAProuter szolgáltatás virtuális gazdagépnevének használata ideális. A virtuális gazdagép neve egy IP-címhez van kötve, amely másodlagos IP-konfigurációként van hozzárendelve a virtuális gép hálózati adapterével vagy a virtuális géphez csatlakoztatott belső terheléselosztóhoz. Ebben a konfigurációban, ha a SAProuter szolgáltatást át kell helyezni egy másik virtuális gépre, a szolgáltatás virtuális gazdanevének IP-konfigurációja eltávolítható. Ezután hozzáadhatja a virtuális gazdagép nevét egy másik virtuális géphez anélkül, hogy módosítania kellene az útvonaltáblákat vagy a tűzfal konfigurációját. Mindegyik a virtuális IP-cím használatára van konfigurálva. További információ: SAP virtuális gazdagépnevek használata Linuxon az Azure-ban.

Kaszkádolt SAProuters

A kaszkádolt SAProuters implementálásához akár két SAProutert is meghatározhat az SAP támogatási kapcsolataihoz. Az első SAProuter, amely az SAP peremalkalmazás alhálózatán fut, hozzáférést biztosít a központi tűzfalról és az SAP-ból vagy a partner SAProutersből. Az egyetlen engedélyezett célhely más SAProuters, amelyek meghatározott számítási feladatokkal futnak. A kaszkádolt SAProuters az architektúrától függően rétegenkénti, régiónkénti vagy SID-alapú elkülönítést is használhat. A második SAProuter csak az első SAProuter belső kapcsolatait fogadja el, és hozzáférést biztosít az egyes SAP-rendszerekhez és virtuális gépekhez. Ez a kialakítás lehetővé teszi a hozzáférés és a felügyelet elkülönítését a különböző csapatok között, ha szükséges. Egy kaszkádolt SAProutersre példa: SAProuter-konfiguráció az Azure Firewall használatával.

SAP Fiori és WebGui

Az SAP Fiori és az SAP-alkalmazások egyéb HTTPS-előtéreit gyakran a belső vállalati hálózaton kívülről használják fel. Az interneten való rendelkezésre álláshoz magas biztonsági megoldásra van szükség az SAP-alkalmazás védelme érdekében. Erre a célra az Application Gateway és a Web Application Firewall ideális szolgáltatás.

Az Application Gatewayhez kapcsolódó nyilvános IP-cím nyilvános gazdanevéhez hozzáférő felhasználók és alkalmazások esetében a HTTPS-munkamenet le van állítva az Application Gatewayen. Két vagy több SAP Web Dispatcher virtuális gép háttérkészlete ciklikus időszeleteléses munkameneteket kap az Application Gatewayről. A webküldő felé irányuló belső forgalomalkalmazás-átjáró http vagy HTTPS lehet a követelményektől függően. Az Application Gateway és a Web Dispatcher virtuális gépek közötti HTTPS használatával az SAP-csapat által jól ismert tanúsítvány- és tanúsítványláncot használhatja a tanúsítványok rendszeres rotálásához. A webalkalmazás tűzfala segít megvédeni az SAP Web Dispatchert az interneten keresztül érkező támadásoktól az OWASP alapvető szabálykészletével. Az SAP NetWeaver, amely gyakran egy egyszeri bejelentkezéssel (SSO) kapcsolódik a Microsoft Entra-azonosítóhoz, felhasználói hitelesítést végez. A Fiori SSO Application Gateway használatával történő konfigurálásához szükséges lépésekért tekintse meg Egyszeri bejelentkezés nyilvános és belső URL-címek SAML- és Microsoft Entra-azonosítóját használó konfigurációt.

Ne feledje, hogy az SAP Web Dispatchert minden helyzetben védenie kell, még akkor is, ha csak belsőleg van nyitva, az Application Gatewayen keresztül nyilvános IP-címen keresztül érhető el, vagy más hálózati eszközökkel érhető el. További információkért tekintse meg az SAP Web Dispatcher biztonsági adatait.

Azure Firewall és Application Gateway

Az Application Gateway által biztosított összes webes forgalom HTTPS-alapú, és a megadott TLS-tanúsítvánnyal van titkosítva. Az Azure Firewallt belépési pontként használhatja a vállalati hálózathoz a nyilvános IP-címén keresztül, majd egy belső IP-címen keresztül átirányíthatja az SAP Fiori-forgalmat a tűzfalról az Application Gatewayre. További információ: Application Gateway after firewall. Mivel a TCP/IP-réteg-7 titkosítás már a TLS-en keresztül van érvényben, ebben a forgatókönyvben a tűzfal használata korlátozott, és nem végezhet csomagvizsgálatot. A Fiori ugyanazon a külső IP-címen keresztül kommunikál mind a bejövő, mind a kimenő forgalom esetében, ami általában nem szükséges az SAP Fiori-üzemelő példányokhoz.

A tandem Application Gateway és a 4. rétegbeli tűzfal üzembe helyezésének néhány előnye van:

  • Lehetséges integráció a nagyvállalati szintű biztonsági szabályzatkezeléssel.
  • A biztonsági szabályokat sértő hálózati forgalom már el van vetve, így nem igényel ellenőrzést.

Ez a kombinált üzembe helyezés jó architektúra. A bejövő internetes forgalom kezelésére szolgáló módszer a teljes vállalati architektúrától függ. Azt is figyelembe kell vennie, hogy a teljes hálózati architektúra hogyan illeszkedik a belső IP-címtér hozzáférési módszereihez, például a helyszíni ügyfelekhez. Ezt a szempontot a következő szakasz ismerteti.

Application Gateway belső IP-címekhez (nem kötelező)

Ez az architektúra az internetes alkalmazásokra összpontosít. Az SAP Fiori-t, egy SAP NetWeaver-rendszer webes felhasználói felületét vagy egy másik SAP HTTPS-felületet egy belső, privát IP-címen keresztül elérő ügyfelek számára különböző lehetőségek állnak rendelkezésre. Az egyik forgatókönyv a Fiorihoz való minden hozzáférés nyilvános hozzáférésként való kezelése a nyilvános IP-címen keresztül. Egy másik lehetőség a közvetlen hálózati hozzáférés használata a magánhálózaton keresztül az SAP Web Dispatchershez, teljes mértékben megkerülve az Application Gatewayt. A harmadik lehetőség a privát és a nyilvános IP-címek használata az Application Gatewayen, amely hozzáférést biztosít mind az internethez, mind a magánhálózathoz.

Hasonló konfigurációt használhat egy privát IP-címmel az Application Gatewayen a csak privát hálózati hozzáféréshez az SAP-környezethez. Ebben az esetben a nyilvános IP-cím csak felügyeleti célokra használható, és nincs hozzá figyelő társítva.

Az Application Gateway használata helyett belső terheléselosztót is használhat. Normál belső terheléselosztót használhat a webküldő virtuális gépek ciklikus időszeleteléses háttérrendszerként konfigurálva. Ebben a forgatókönyvben a standard terheléselosztót a webküldő virtuális gépek helyezik el az SAP éles alkalmazás alhálózatán, és aktív/aktív terheléselosztást biztosítanak a webküldő virtuális gépek között.

Internetes üzemelő példányok esetén javasoljuk, hogy az Application Gatewayt webalkalmazási tűzfallal használja a nyilvános IP-címmel rendelkező terheléselosztó helyett.

SAP Business Technology Platform (BTP)

Az SAP BTP az SAP-alkalmazások, saaS vagy PaaS széles halmaza, amelyek általában nyilvános végponton keresztül érhetők el az interneten keresztül. Az SAP Cloud Connectort gyakran használják a magánhálózatokon futó alkalmazások, például az Azure-ban futó SAP S/4HANA rendszerek kommunikációjának biztosítására. Az SAP Cloud Connector alkalmazásként fut egy virtuális gépen. Ahhoz, hogy TLS-titkosított HTTPS-alagutat hozzon létre az SAP BTP-vel, kimenő internetkapcsolatra van szükség. Fordított meghívási proxyként működik a virtuális hálózat privát IP-tartománya és az SAP BTP-alkalmazások között. A fordított meghívás támogatása miatt nincs szükség nyitott tűzfalportokra vagy más hozzáférésre a bejövő kapcsolatokhoz, mert a virtuális hálózatból kimenő kapcsolat van.

Alapértelmezés szerint a virtuális gépek natív módon rendelkeznek kimenő internet-hozzáféréssel az Azure-ban. A kimenő forgalomhoz használt nyilvános IP-címet, ha nincs dedikált nyilvános IP-cím társítva a virtuális géphez, véletlenszerűen választja ki a rendszer az adott Azure-régióban lévő nyilvános IP-címek készletéből. Nem irányíthatja. Annak érdekében, hogy a kimenő kapcsolatok ellenőrzött és azonosítható szolgáltatáson és IP-címen keresztül történjenek, az alábbi módszerek egyikét használhatja:

  • Az alhálózathoz vagy terheléselosztóhoz és nyilvános IP-címéhez társított NAT-átjáró.
  • Az Ön által üzemeltetett HTTP-proxykiszolgálók.
  • Felhasználó által megadott útvonal , amely arra kényszeríti a hálózati forgalmat, hogy egy hálózati berendezésre, például tűzfalra áramoljon.

Az architektúradiagram a leggyakoribb forgatókönyvet mutatja be: az internethez kötött forgalom átirányítása a központi virtuális hálózathoz és a központi tűzfalon keresztül. További beállításokat kell konfigurálnia az SAP Cloud Connectorban az SAP BTP-fiókhoz való csatlakozáshoz.

Magas rendelkezésre állás az SAP Cloud Connectorhoz

A magas rendelkezésre állás az SAP Cloud Connectorba van beépítve. A Cloud Connector két virtuális gépen van telepítve. A fő példány aktív, és az árnyékpéldány csatlakozik hozzá. Megosztják a konfigurációt, és natív szinkronban maradnak. Ha a fő példány nem érhető el, a másodlagos virtuális gép megpróbálja átvenni a főszerepkört, és újra létrehozni a TLS-alagutat az SAP BTP-nek. Az architektúra egy magas rendelkezésre állású Cloud Connector-környezetet jelenít meg. A konfigurációhoz nincs szükség más Azure-technológiákra, például terheléselosztóra vagy fürtszoftverre. A konfigurációval és a működéssel kapcsolatos részletekért tekintse meg az SAP dokumentációját.

SAP Analytics Cloud Agent

Bizonyos alkalmazási helyzetekben az SAP Analytics Cloud Agent egy virtuális gépre telepített alkalmazás. SAP Cloud Connectort használ az SAP BTP-kapcsolatokhoz. Ebben az architektúrában az SAP Analytics Cloud Agent virtuális gép az SAP peremalkalmazás alhálózatán fut az SAP Cloud Connector virtuális gépek mellett. A magánhálózatok, például egy Azure-beli virtuális hálózat és az SAP BTP közötti, SAP Analytics Cloud Agenten keresztüli forgalomról az SAP dokumentációjában olvashat.

Az SAP Private Link szolgáltatást biztosít az SAP BTP-hez. Privát kapcsolatokat tesz lehetővé a kiválasztott SAP BTP-szolgáltatások és az Azure-előfizetés és a virtuális hálózat kiválasztott szolgáltatásai között. A Private Link szolgáltatás használatakor a kommunikáció nem a nyilvános interneten keresztül lesz irányítva. Továbbra is a magas biztonságú Azure globális hálózat gerincén marad. Az Azure-szolgáltatásokkal való kommunikáció privát címtéren keresztül történik. A Private Link szolgáltatás használatakor továbbfejlesztett adatkiszivárgás elleni védelem jön létre, mivel a privát végpont egy IP-címre leképezi az adott Azure-szolgáltatást. A hozzáférés a leképezett Azure-szolgáltatásra korlátozódik.

Egyes SAP BTP-integrációs forgatókönyvek esetében a Private Link szolgáltatás megközelítését részesíti előnyben. Mások számára az SAP Cloud Connector jobb. Ha segítségre van szüksége annak eldöntéséhez, hogy melyiket szeretné használni, olvassa el a Cloud Connector és az SAP Private Link egymás melletti futtatását ismertető témakört.

SAP RISE/ECS

Ha az SAP SAP RISE/ECS-szerződéssel működteti az SAP-rendszert, az SAP a felügyelt szolgáltatási partner. Az SAP-környezetet az SAP telepíti. Az SAP architektúráján az itt látható architektúra nem vonatkozik az SAP/ECS használatával futtatott RISE rendszerben futó rendszerekre. Az ilyen típusú SAP-környezet Azure-szolgáltatásokkal és a hálózattal való integrálásáról az Azure dokumentációjában olvashat.

Egyéb SAP-kommunikációs követelmények

Az internethez kötött kommunikációval kapcsolatos további szempontok az Azure-ban működő SAP-környezetekre is vonatkozhatnak. Ebben az architektúrában a forgalom egy központi Azure-tűzfalat használ ehhez a kimenő forgalomhoz. A küllős virtuális hálózatok felhasználó által definiált szabályai az internethez kötött forgalomkéréseket a tűzfalra irányítják. Alternatív megoldásként nat-átjárókat is használhat adott alhálózatokon, alapértelmezett Azure-kimenő kommunikációhoz, virtuális gépeken lévő nyilvános IP-címekhez (nem ajánlott), vagy kimenő szabályokkal rendelkező nyilvános terheléselosztóhoz. A tipikus forgatókönyvek a Microsoft Entra ID nyilvános végpontjait, az Azure felügyeleti API-kat management.azure.com, valamint külső alkalmazások vagy kormányzati alkalmazások szolgáltatásait érik el kimenő hálózati hozzáféréssel.

Az Azure-ban az alapértelmezett kimenő hozzáférés módosítása miatt győződjön meg arról, hogy skálázható kimenő hozzáférés van definiálva. A standard belső terheléselosztó mögötti virtuális gépek esetében, például a fürtözött környezetekben, ne feledje, hogy a Standard Load Balancer módosítja a nyilvános kapcsolatok viselkedését. További információ: Nyilvános végpontkapcsolat az Azure Standard Load Balancert használó virtuális gépekhez az SAP magas rendelkezésre állású forgatókönyveiben.

A virtuális gépekről érkező alapértelmezett kimenő kapcsolatról további információt az Azure Networking blog privát alhálózatokról származó virtuális gépek útválasztási beállításai című témakörben talál.

Operációsrendszer-frissítések

Az operációs rendszer frissítései gyakran nyilvános végpont mögött találhatók, és az interneten keresztül érhetők el. Ha nincs vállalati adattár és frissítéskezelés, az operációs rendszer frissítéseinek tükrözése a magánHÁLÓZAT-címeken/ virtuális gépeken lévő szállítóktól, az SAP-számítási feladatnak hozzá kell férnie a szállítók frissítési adattáraihoz.

Linux operációs rendszerek esetén az alábbi adattárakat érheti el, ha beszerezi az operációsrendszer-licencet az Azure-ból. Ha közvetlenül vásárol licenceket, és az Azure-ba (BYOS) hozza őket, forduljon az operációsrendszer-gyártóhoz az operációsrendszer-adattárakhoz és a hozzájuk tartozó IP-címtartományokhoz való kapcsolódás módjáról.

Magas rendelkezésre állású fürtkezelés

Az olyan magas rendelkezésre állású rendszerek, mint a fürtözött SAP ASCS/SCS vagy adatbázisok, stonith-eszközként használhatnak fürtkezelőt az Azure kerítésügynökével. Ezek a rendszerek az Azure Resource Manager elérésétől függenek. A Resource Manager az Azure-erőforrások állapot-lekérdezéseihez, valamint a virtuális gépek leállításához és elindításához használható. Mivel a Resource Manager egy nyilvános végpont, amely elérhető a virtuális gép kimenő kommunikációja alatt management.azure.com, el kell érnie azt. Ez az architektúra egy központi tűzfalra támaszkodik, amely felhasználói szabályokkal irányítja át a forgalmat az SAP virtuális hálózatokról. Alternatív megoldásokat az előző szakaszokban talál.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerzők:

Egyéb közreműködő:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Közösségek

Fontolja meg az alábbi közösségek használatát a kérdések megválaszolásához és az üzembe helyezés beállításához szükséges segítségért:

Következő lépések