Connessioni Internet in ingresso e in uscita per SAP in Azure

Macchine virtuali di Azure
Rete virtuale di Azure
Gateway applicazione di Azure
Azure Load Balancer

Questo articolo fornisce un set di procedure comprovate per migliorare la sicurezza delle connessioni Internet in ingresso e in uscita per l'infrastruttura SAP in Azure.

Architettura

Diagramma che mostra una soluzione per la comunicazione con connessione Internet per SAP in Azure.

Scaricare un file di Visio delle architetture in questo articolo.

Questa soluzione illustra un ambiente di produzione comune. È possibile ridurre le dimensioni e l'ambito della configurazione in base ai requisiti. Questa riduzione può essere applicata al panorama applicativo SAP: meno macchine virtuali (VM), disponibilità elevata o dispatcher Web SAP incorporati anziché macchine virtuali discrete. Può anche essere applicata alle alternative alla progettazione di rete, come descritto più avanti in questo articolo.

I requisiti dei clienti, basati sui criteri aziendali, richiedono adattamenti all'architettura, in particolare alla progettazione della rete. Quando possibile, sono state incluse alternative. Molte soluzioni sono valide. Scegliere un approccio adatto per l'azienda. Deve essere utile per proteggere le risorse di Azure, ma offrire comunque una soluzione efficiente.

Il ripristino di emergenza non è trattato in questa architettura. Per la progettazione di rete, si applicano gli stessi principi e la progettazione validi per le aree di produzione primarie. Nella progettazione della rete, a seconda delle applicazioni protette dal ripristino di emergenza, valutare la possibilità di abilitare il ripristino di emergenza in un'altra area di Azure. Per altre informazioni, vedere l'articolo Panoramica del ripristino di emergenza e linee guida sull'infrastruttura per il carico di lavoro SAP

Workflow

  • La rete locale si connette a un hub centrale tramite Azure ExpressRoute. La rete virtuale hub contiene una subnet del gateway, una subnet Firewall di Azure, una subnet di servizi condivisi e una subnet del gateway di app Azure lication.
  • L'hub si connette a una sottoscrizione di produzione SAP tramite il peering di rete virtuale. Questa sottoscrizione contiene due reti virtuali spoke:
    • La rete virtuale perimetrale SAP contiene una subnet dell'applicazione perimetrale SAP.
    • La rete virtuale di produzione SAP contiene una subnet dell'applicazione e una subnet del database.
  • La sottoscrizione hub e la sottoscrizione di produzione SAP si connettono a Internet tramite indirizzi IP pubblici.

Componenti

Sottoscrizioni. Questa architettura implementa l'approccio della zona di destinazione di Azure. Per ogni carico di lavoro viene usata una sottoscrizione di Azure. Una o più sottoscrizioni vengono usate per i servizi IT centrali che contengono l'hub di rete e i servizi condivisi centrali, come firewall o Active Directory e DNS. Viene usata un'altra sottoscrizione per il carico di lavoro di produzione SAP. Usare la guida decisionale in Cloud Adoption Framework per Azure per determinare la strategia di sottoscrizione migliore per lo scenario.

Reti virtuali. Azure Rete virtuale connette le risorse di Azure tra loro con sicurezza avanzata. In questa architettura, la rete virtuale si connette a un ambiente locale tramite un gateway ExpressRoute o di rete privata virtuale (VPN) distribuito nell'hub di una topologia hub-spoke. Il panorama di produzione SAP usa le proprie reti virtuali spoke. Due reti virtuali spoke distinte eseguono attività diverse e le subnet forniscono la separazione di rete.

La separazione tra subnet per carico di lavoro semplifica l'uso dei gruppi di sicurezza di rete per impostare le regole di sicurezza per le macchine virtuali dell'applicazione o i servizi di Azure distribuiti.

Gateway con ridondanza della zona. Un gateway connette reti distinte, estendendo la rete locale alla rete virtuale di Azure. È consigliabile usare ExpressRoute per creare connessioni private che non usano la rete Internet pubblica. È anche possibile usare una connessione da sito a sito . Usare i gateway VPN o Azure ExpressRoute con ridondanza della zona per proteggersi dagli errori della zona. Per una spiegazione delle differenze tra una distribuzione di zona e una distribuzione con ridondanza della zona, vedere Gateway di rete virtuale con ridondanza della zona. Per una distribuzione di zona dei gateway, è necessario usare gli indirizzi IP dello SKU Standard.

Gruppi di sicurezza di rete. Per limitare il traffico di rete da e verso la rete virtuale, creare gruppi di sicurezza di rete e assegnarli a subnet specifiche. Garantire la sicurezza per le singole subnet usando gruppi di sicurezza di rete specifici del carico di lavoro.

Gruppi di sicurezza delle applicazioni. Per definire criteri di sicurezza di rete con granularità fine nei gruppi di sicurezza di rete in base ai carichi di lavoro incentrati sulle applicazioni, usare gruppi di sicurezza delle applicazioni anziché indirizzi IP espliciti. Usando i gruppi di sicurezza delle applicazioni, è possibile raggruppare le macchine virtuali per scopo, ad esempio IL SID SAP. I gruppi di sicurezza delle applicazioni consentono di proteggere le applicazioni filtrando il traffico da segmenti attendibili della rete.

Endpoint privato. Molti servizi di Azure operano come servizi pubblici, per impostazione predefinita accessibili tramite Internet. Per consentire l'accesso privato tramite l'intervallo di rete privata, è possibile usare endpoint privati per alcuni servizi. Gli endpoint privati sono interfacce di rete nella rete virtuale. In effetti, il servizio viene inserito nello spazio di rete privato.

gateway app Azure lication. gateway applicazione è un servizio di bilanciamento del carico del traffico Web. Con la funzionalità web application firewall, è il servizio ideale per esporre le applicazioni Web a Internet con una maggiore sicurezza. gateway applicazione può essere operatore pubblico (Internet) o client privati o entrambi, a seconda della configurazione.

Nell'architettura, gateway applicazione, usando un indirizzo IP pubblico, consente connessioni in ingresso al panorama SAP tramite HTTPS. Il pool back-end è costituito da due o più macchine virtuali Sap Web Dispatcher, a cui si accede round robin e offre disponibilità elevata. Il gateway applicazione è un proxy inverso e un servizio di bilanciamento del carico del traffico Web, ma non sostituisce SAP Web Dispatcher. SAP Web Dispatcher fornisce l'integrazione dell'applicazione con i sistemi SAP e include funzionalità che gateway applicazione da solo non forniscono. L'autenticazione client, quando raggiunge i sistemi SAP, viene eseguita dal livello dell'applicazione SAP in modo nativo o tramite Single Sign-On. Quando si abilita la protezione DDoS di Azure, prendere in considerazione l'uso dello SKU di protezione di rete DDoS, come si noteranno gli sconti per gateway applicazione Web Application Firewall.

Per prestazioni ottimali, abilitare il supporto HTTP/2 per gateway applicazione, SAP Web Dispatcher e SAP NetWeaver.

Azure Load Balancer. Azure Load Balancer Standard fornisce elementi di rete per la progettazione a disponibilità elevata dei sistemi SAP. Per i sistemi in cluster, Load Balancer Standard fornisce l'indirizzo IP virtuale per il servizio cluster, ad esempio istanze e database ASCS/SCS in esecuzione nelle macchine virtuali. È anche possibile usare Load Balancer Standard per specificare l'indirizzo IP per il nome host SAP virtuale di sistemi non cluster quando gli indirizzi IP secondari nelle schede di rete di Azure non sono un'opzione. L'uso di Load Balancer Standard invece di gateway applicazione per indirizzare l'accesso a Internet in uscita è illustrato più avanti in questo articolo.

Progettazione della rete

L'architettura usa due reti virtuali discrete, entrambe reti virtuali spoke con peering alla rete virtuale dell'hub centrale. Non esiste alcun peering spoke-to-spoke. Viene usata una topologia a stella, in cui la comunicazione passa attraverso l'hub. La separazione delle reti consente di proteggere le applicazioni dalle violazioni.

Una rete perimetrale specifica dell'applicazione (nota anche come rete perimetrale) contiene le applicazioni con connessione Internet, ad esempio SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent e altre. Nel diagramma dell'architettura la rete perimetrale è denominata rete virtuale SAP perimeter - spoke. A causa delle dipendenze dai sistemi SAP, il team SAP esegue in genere la distribuzione, la configurazione e la gestione di questi servizi. Ecco perché questi servizi perimetrali SAP spesso non si trovano in una sottoscrizione e una rete hub centrale. Spesso le sfide organizzative sono dovute a tale posizionamento centrale dell'hub di applicazioni o servizi specifici del carico di lavoro.

Questi sono alcuni dei vantaggi dell'uso di una rete virtuale perimetrale SAP separata:

  • Isolamento rapido e immediato dei servizi compromessi se viene rilevata una violazione. La rimozione del peering di rete virtuale dal perimetro SAP all'hub isola immediatamente i carichi di lavoro perimetrali SAP e le applicazioni di rete virtuale dell'applicazione SAP da Internet. La modifica o la rimozione di una regola del gruppo di sicurezza di rete che consente l'accesso influisce solo sulle nuove connessioni e non taglia le connessioni esistenti.
  • Controlli più rigorosi sulla rete virtuale e sulla subnet, con un blocco stretto sui partner di comunicazione all'interno e all'esterno della rete perimetrale SAP e delle reti applicative SAP. È possibile estendere un maggiore controllo agli utenti autorizzati e ai metodi di accesso nelle applicazioni perimetrali SAP, con back-end di autorizzazione diversi, accesso con privilegi o credenziali di accesso per le applicazioni perimetrali SAP.

Gli svantaggi sono maggiore complessità e costi aggiuntivi di peering di rete virtuale per il traffico SAP associato a Internet (perché la comunicazione deve passare due volte attraverso il peering reti virtuali). L'impatto della latenza sul traffico di peering spoke-hub-spoke dipende da qualsiasi firewall sul posto e deve essere misurato.

Architettura semplificata

Per risolvere i suggerimenti in questo articolo, ma limitare gli svantaggi, è possibile usare una rete virtuale spoke singola sia per il perimetro che per le applicazioni SAP. L'architettura seguente contiene tutte le subnet in una singola rete virtuale di produzione SAP. Il vantaggio dell'isolamento immediato terminando il peering di rete virtuale nel perimetro SAP se non è disponibile. In questo scenario, le modifiche ai gruppi di sicurezza di rete influiscono solo sulle nuove connessioni.

Diagramma che mostra un'architettura semplificata per la comunicazione con connessione Internet per SAP in Azure.

Scaricare un file di Visio delle architetture in questo articolo.

Per le distribuzioni di dimensioni inferiori e ambito, l'architettura semplificata potrebbe essere più adatta e rispetta comunque i principi dell'architettura più complessa. Questo articolo, se non diversamente specificato, fa riferimento all'architettura più complessa.

L'architettura semplificata usa un gateway NAT nella subnet perimetrale SAP. Questo gateway offre connettività in uscita per SAP Cloud Connector e gli aggiornamenti dell'agente cloud di SAP Analytics e del sistema operativo per le macchine virtuali distribuite. Poiché SAProuter richiede connessioni sia in ingresso che in uscita, il percorso di comunicazione SAProuter passa attraverso il firewall anziché usare il gateway NAT. L'architettura semplificata inserisce anche il gateway applicazione con la propria subnet designata nella rete virtuale perimetrale SAP, come approccio alternativo alla rete virtuale hub.

Un gateway NAT è un servizio che fornisce indirizzi IP pubblici statici per la connettività in uscita. Il gateway NAT viene assegnato a una subnet. Tutte le comunicazioni in uscita usano gli indirizzi IP del gateway NAT per l'accesso a Internet. Le connessioni in ingresso non usano il gateway NAT. Le applicazioni come SAP Cloud Connector o i servizi di aggiornamento del sistema operativo delle macchine virtuali che accedono ai repository su Internet possono usare il gateway NAT invece di instradare tutto il traffico in uscita attraverso il firewall centrale. Spesso, le regole definite dall'utente vengono implementate in tutte le subnet per forzare il traffico associato a Internet da tutte le reti virtuali attraverso il firewall centrale.

A seconda dei requisiti, potrebbe essere possibile usare il gateway NAT come alternativa al firewall centrale per le connessioni in uscita. In questo modo, è possibile ridurre il carico sul firewall centrale durante la comunicazione con gli endpoint pubblici consentiti dal gruppo di sicurezza di rete. Si ottiene anche il controllo IP in uscita, perché è possibile configurare le regole del firewall di destinazione in un elenco di indirizzi IP impostati del gateway NAT. Gli esempi includono il raggiungimento di endpoint pubblici di Azure usati da servizi pubblici, repository patch del sistema operativo o interfacce di terze parti.

Per una configurazione a disponibilità elevata, tenere presente che il gateway NAT viene distribuito solo in una singola zona e non è attualmente ridondante tra zone. Con un singolo gateway NAT, non è ideale per le distribuzioni SAP che usano la distribuzione con ridondanza della zona (tra zone) per le macchine virtuali.

Uso di componenti di rete in un panorama SAP

Un documento di architettura illustra in genere un solo sistema o panorama SAP. Questo li rende più facili da comprendere. Il risultato è che spesso l'immagine più grande, il modo in cui l'architettura rientra in un panorama SAP più ampio che include diversi livelli e tracce di sistema, non viene affrontato.

I servizi di rete centrali, come il firewall, il gateway NAT e i server proxy, se distribuiti, vengono usati meglio nell'intero panorama SAP di tutti i livelli: produzione, pre-produzione, sviluppo e sandbox. A seconda dei requisiti, delle dimensioni dell'organizzazione e dei criteri aziendali, è possibile prendere in considerazione implementazioni separate per livello o una produzione e un ambiente sandbox/testing.

I servizi che in genere servono un sistema SAP sono separati meglio come descritto di seguito:

  • I servizi di bilanciamento del carico devono essere dedicati ai singoli servizi. I criteri aziendali determinano la denominazione e il raggruppamento delle risorse. È consigliabile usare un servizio di bilanciamento del carico per ASCS/SCS e ERS e un altro per il database, separati per ogni SID SAP. In alternativa, un singolo servizio di bilanciamento del carico per entrambi i cluster (A)SCS, ERS e DB di un sistema SAP è anche una buona progettazione. Questa configurazione consente di garantire che la risoluzione dei problemi non sia complessa, con molti pool front-end e back-end e regole di bilanciamento del carico in un singolo servizio di bilanciamento del carico. Un singolo servizio di bilanciamento del carico per SID SAP garantisce anche che il posizionamento nei gruppi di risorse corrisponda a quello di altri componenti dell'infrastruttura.
  • gateway applicazione, ad esempio un servizio di bilanciamento del carico, consente più back-end, front-end, impostazioni HTTP e regole. La decisione di usare un gateway applicazione per più usi è più comune perché non tutti i sistemi SAP nell'ambiente richiedono l'accesso pubblico. Più usi in questo contesto includono porte di dispatcher Web diverse per gli stessi sistemi SAP S/4HANA o ambienti SAP diversi. È consigliabile almeno un gateway applicazione per livello (produzione, non di produzione e sandbox), a meno che la complessità e il numero di sistemi connessi non diventino troppo elevati.
  • I servizi SAP, ad esempio SAProuter, Cloud Connector e Analytics Cloud Agent, vengono distribuiti in base ai requisiti dell'applicazione, in modo centralizzato o suddiviso. La separazione tra produzione e non produzione è spesso desiderata.

Dimensionamento e progettazione della subnet

Quando si progettano subnet per il panorama applicativo SAP, assicurarsi di seguire i principi di dimensionamento e progettazione:

  • Diversi servizi PaaS (Platform as a Service) di Azure richiedono le proprie subnet designate.
  • gateway applicazione consiglia una subnet /24 per il ridimensionamento. Se si sceglie di limitare il gateway applicazione ridimensionare una subnet più piccola, è possibile usare almeno /26 o superiore. Non è possibile usare entrambe le versioni di gateway applicazione (1 e 2) nella stessa subnet.
  • Se si usa Azure NetApp Files per le condivisioni NFS/SMB o l'archiviazione di database, è necessaria una subnet designata. Una subnet /24 è l'impostazione predefinita. Usare i requisiti per determinare il dimensionamento corretto.
  • Se si usano nomi host virtuali SAP, è necessario più spazio indirizzi nelle subnet SAP, incluso il perimetro SAP.
  • I servizi centrali come Azure Bastion o Firewall di Azure, in genere gestiti da un team IT centrale, richiedono subnet dedicate di dimensioni sufficienti.

Usando subnet dedicate per database e applicazioni SAP, è possibile impostare gruppi di sicurezza di rete più rigidi, che consentono di proteggere entrambi i tipi di applicazioni con i propri set di regole. È quindi possibile limitare l'accesso al database alle applicazioni SAP più facilmente, senza dover ricorrere ai gruppi di sicurezza delle applicazioni per un controllo granulare. La separazione delle subnet di database e dell'applicazione SAP semplifica anche la gestione delle regole di sicurezza nei gruppi di sicurezza di rete.

Servizi SAP

SAProuter

È possibile usare SAProuter per consentire a terze parti come il supporto SAP o i partner di accedere al sistema SAP. SAProuter viene eseguito in una macchina virtuale in Azure. Le autorizzazioni di route per l'uso di SAProuter vengono archiviate in un file flat denominato saprouttab. Le voci saprouttab consentono la connessione da qualsiasi porta TCP/IP a una destinazione di rete dietro SAProuter, in genere le macchine virtuali di sistema SAP. L'accesso remoto da parte del supporto SAP si basa su SAProuter. L'architettura principale usa la progettazione descritta in precedenza, con una macchina virtuale SAProuter in esecuzione all'interno della rete virtuale perimetrale SAP designata. Tramite il peering di rete virtuale, SAProuter comunica quindi con i server SAP eseguiti nella propria rete virtuale spoke e subnet.

SAProuter è un tunnel per SAP o per i partner. Questa architettura descrive l'uso di SAProuter con SNC per stabilire un tunnel applicazione crittografato (livello di rete 7) a SAP/partner. L'uso del tunnel basato su IPSEC non è attualmente trattato in questa architettura.

Le funzionalità seguenti consentono di proteggere il percorso di comunicazione tramite Internet:

  • Firewall di Azure o un'appliance virtuale di rete di terze parti fornisce il punto di ingresso IP pubblico nelle reti di Azure. Le regole del firewall limitano la comunicazione solo agli indirizzi IP autorizzati. Per la connessione al supporto SAP, nota SAP 48243 - Integrazione del software SAProuter in un ambiente firewall documenta gli indirizzi IP dei router SAP.
  • Come le regole del firewall, le regole di sicurezza di rete consentono la comunicazione sulla porta saProuter, in genere 3299 con la destinazione designata.
  • Le regole di autorizzazione/negazione di SAProuter vengono mantenute nel file saprouttab , specificando chi può contattare SAProuter e a quale sistema SAP è possibile accedere.
  • Altre regole del gruppo di sicurezza di rete sono presenti nelle rispettive subnet della subnet di produzione SAP che contiene i sistemi SAP.

Per i passaggi per la configurazione di SAProuter con Firewall di Azure, vedere Configurazione di SAProuter con Firewall di Azure.

Considerazioni sulla sicurezza di SAProuter

Poiché SAProuter non funziona nella stessa subnet dell'applicazione dei sistemi SAP, i meccanismi di accesso per il sistema operativo potrebbero essere diversi. A seconda dei criteri, è possibile usare un dominio di accesso separato o credenziali utente completamente solo host per SAProuter. In caso di violazione della sicurezza, l'accesso a catena ai sistemi SAP interni non è possibile a causa della diversa base di credenziali. La separazione di rete in questo caso, come descritto in precedenza, può separare ulteriormente l'accesso da un SAProuter compromesso nelle subnet dell'applicazione. È possibile ottenere questo isolamento disconnettendo il peering di rete virtuale perimetrale SAP.

Considerazioni sulla disponibilità elevata di SAProuter

Poiché SAProuter è un semplice file eseguibile con una tabella delle autorizzazioni di route basata su file, può essere facilmente avviato. L'applicazione non ha disponibilità elevata predefinita. In caso di errore di una macchina virtuale o di un'applicazione, il servizio deve essere avviato in un'altra macchina virtuale. L'uso di un nome host virtuale per il servizio SAProuter è ideale. Il nome host virtuale è associato a un indirizzo IP, assegnato come configurazione IP secondaria con la scheda di interfaccia di rete della macchina virtuale o a un servizio di bilanciamento del carico interno connesso alla macchina virtuale. In questa configurazione, se il servizio SAProuter deve essere spostato in un'altra macchina virtuale, è possibile rimuovere la configurazione IP del nome host virtuale del servizio. Si aggiunge quindi il nome host virtuale in un'altra macchina virtuale senza dover modificare le tabelle di route o la configurazione del firewall. Sono tutti configurati per l'uso dell'indirizzo IP virtuale. Per altre informazioni, vedere Usare i nomi host virtuali SAP con Linux in Azure.

Cascading SAProuters

Per implementare SAProuter a catena, è possibile definire fino a due SAProuter per le connessioni al supporto SAP. Il primo SAProuter, in esecuzione nella subnet dell'applicazione perimetrale SAP, fornisce l'accesso dal firewall centrale e da SAP o da SAProuter partner. Le uniche destinazioni consentite sono altri SAProuter, in esecuzione con carichi di lavoro specifici. SaProuter a catena può usare la separazione per livello, per area o per SID, a seconda dell'architettura. Il secondo SAProuter accetta solo connessioni interne dal primo SAProuter e fornisce l'accesso a singoli sistemi SAP e macchine virtuali. Questa progettazione consente di separare l'accesso e la gestione tra team diversi, se necessario. Per un esempio di SAProuter a catena, vedere Configurazione di SAProuter con Firewall di Azure.

SAP Fiori e WebGui

SAP Fiori e altri front-end HTTPS per le applicazioni SAP vengono spesso utilizzati dall'esterno della rete aziendale interna. La necessità di essere disponibile su Internet richiede una soluzione a sicurezza elevata per proteggere l'applicazione SAP. gateway applicazione con Web Application Firewall è il servizio ideale per questo scopo.

Per gli utenti e le applicazioni che accedono al nome host pubblico dell'indirizzo IP pubblico associato a gateway applicazione, la sessione HTTPS viene terminata in gateway applicazione. Un pool back-end di due o più macchine virtuali Sap Web Dispatcher ottiene sessioni round robin dal gateway applicazione. Questo gateway applicazione del traffico interno verso Web Dispatcher può essere HTTP o HTTPS, a seconda dei requisiti. Con HTTPS tra le macchine virtuali gateway applicazione e Web Dispatcher, usare un certificato e una catena di certificati ben nota al team SAP per qualsiasi rotazione periodica dei certificati. Il web application firewall consente di proteggere SAP Web Dispatcher da attacchi provenienti da Internet con il set di regole di base OWASP. SAP NetWeaver, spesso associato all'ID Microsoft Entra tramite Single Sign-On (SSO), esegue l'autenticazione utente. Per i passaggi necessari per configurare l'accesso Single Sign-On per Fiori usando gateway applicazione, vedere Configurazione dell'accesso Single Sign-On con SAML e Microsoft Entra ID per URL pubblici e interni.

Tenere presente che è necessario proteggere SAP Web Dispatcher in qualsiasi situazione, anche se è aperto solo internamente, accessibile tramite gateway applicazione tramite ip pubblico o accessibile da altri mezzi di rete. Per altre informazioni, vedere Security Information for SAP Web Dispatcher (Informazioni sulla sicurezza per SAP Web Dispatcher).

Firewall di Azure e gateway applicazione

Tutto il traffico Web fornito da gateway applicazione è basato su HTTPS e crittografato con il certificato TLS fornito. È possibile usare Firewall di Azure come punto di ingresso alla rete aziendale, tramite il relativo indirizzo IP pubblico e quindi indirizzare il traffico SAP Fiori dal firewall a gateway applicazione tramite un indirizzo IP interno. Per altre informazioni, vedere gateway applicazione dopo il firewall. Poiché la crittografia TCP/IP di livello 7 è già attiva tramite TLS, è possibile usufruire di un vantaggio limitato all'uso di un firewall in questo scenario e non è possibile eseguire l'ispezione dei pacchetti. Fiori comunica tramite lo stesso indirizzo IP esterno per il traffico in ingresso e in uscita, che in genere non è necessario per le distribuzioni SAP Fiori.

Esistono alcuni vantaggi di una distribuzione di firewall gateway applicazione e di livello 4 in tandem:

  • Possibile integrazione con la gestione dei criteri di sicurezza a livello aziendale.
  • Il traffico di rete che viola le regole di sicurezza è già stato rimosso, quindi non richiede l'ispezione.

Questa distribuzione combinata è un'architettura ottimale. Il metodo per gestire il traffico Internet in ingresso dipende dall'architettura aziendale complessiva. È anche necessario considerare il modo in cui l'architettura di rete complessiva si adatta ai metodi di accesso dallo spazio di indirizzi IP interno, ad esempio i client locali. Questa considerazione è illustrata nella sezione successiva.

gateway applicazione per gli indirizzi IP interni (facoltativo)

Questa architettura è incentrata sulle applicazioni con connessione Internet. Sono disponibili varie opzioni per i client che accedono a SAP Fiori, all'interfaccia utente Web di un sistema SAP NetWeaver o a un'altra interfaccia HTTPS SAP tramite un indirizzo IP interno e privato. Uno scenario consiste nel considerare tutti gli accessi a Fiori come accesso pubblico, tramite l'INDIRIZZO IP pubblico. Un'altra opzione consiste nell'usare l'accesso diretto alla rete tramite la rete privata ai dispatcher Web SAP, ignorando completamente gateway applicazione. Una terza opzione consiste nell'usare indirizzi IP privati e pubblici in gateway applicazione, fornendo l'accesso sia a Internet che alla rete privata.

È possibile usare una configurazione simile con un indirizzo IP privato in gateway applicazione per l'accesso di rete solo privato all'ambiente SAP. L'indirizzo IP pubblico in questo caso viene usato solo a scopo di gestione e non ha un listener associato.

In alternativa all'uso di gateway applicazione, è possibile usare un servizio di bilanciamento del carico internamente. È possibile usare un servizio di bilanciamento del carico interno standard con macchine virtuali Web Dispatcher configurate come back-robin round robin. In questo scenario, il servizio di bilanciamento del carico standard viene inserito con le macchine virtuali Web Dispatcher nella subnet dell'applicazione di produzione SAP e fornisce il bilanciamento del carico attivo/attivo tra le macchine virtuali del dispatcher Web.

Per le distribuzioni con connessione Internet, è consigliabile gateway applicazione con Web Application Firewall invece di un servizio di bilanciamento del carico con un indirizzo IP pubblico.

BTP (Business Technology Platform) di SAP

SAP BTP è un set di grandi dimensioni di applicazioni SAP, SaaS o PaaS, a cui si accede in genere tramite un endpoint pubblico tramite Internet. SAP Cloud Connector viene spesso usato per fornire comunicazioni per le applicazioni in esecuzione in reti private, ad esempio un sistema SAP S/4HANA in esecuzione in Azure. SAP Cloud Connector viene eseguito come applicazione in una macchina virtuale. Richiede l'accesso a Internet in uscita per stabilire un tunnel HTTPS crittografato tls con SAP BTP. Funge da proxy di richiamo inverso tra l'intervallo IP privato nella rete virtuale e le applicazioni SAP BTP. A causa di questo supporto per il richiamo inverso, non è necessario aprire le porte del firewall o altri accessi per le connessioni in ingresso, perché la connessione dalla rete virtuale è in uscita.

Per impostazione predefinita, le macchine virtuali hanno accesso a Internet in uscita in modo nativo in Azure. L'indirizzo IP pubblico usato per il traffico in uscita, quando alla macchina virtuale non è associato alcun indirizzo IP pubblico dedicato, viene scelto in modo casuale dal pool di indirizzi IP pubblici nell'area di Azure specifica. Non è possibile controllarlo. Per garantire che le connessioni in uscita vengano effettuate tramite un servizio controllato e identificabile e un indirizzo IP, è possibile usare uno dei metodi seguenti:

  • Un gateway NAT associato alla subnet o al servizio di bilanciamento del carico e all'indirizzo IP pubblico.
  • Server proxy HTTP che vengono eseguiti.
  • Route definita dall'utente che forza il traffico di rete a fluire in un'appliance di rete come un firewall.

Il diagramma dell'architettura illustra lo scenario più comune: routing del traffico associato a Internet alla rete virtuale hub e attraverso il firewall centrale. È necessario configurare altre impostazioni in SAP Cloud Connector per connettersi all'account SAP BTP.

Disponibilità elevata per SAP Cloud Connector

La disponibilità elevata è integrata in SAP Cloud Connector. Cloud Connector viene installato in due macchine virtuali. L'istanza principale è attiva e l'istanza shadow è connessa. Condividono la configurazione e vengono mantenute sincronizzate in modo nativo. Se l'istanza principale non è disponibile, la macchina virtuale secondaria tenta di assumere il ruolo principale e ristabilire il tunnel TLS in SAP BTP. Nell'architettura viene illustrato un ambiente Cloud Connector a disponibilità elevata. Non sono necessarie altre tecnologie di Azure, ad esempio un servizio di bilanciamento del carico o un software cluster, per la configurazione. Per informazioni dettagliate sulla configurazione e sull'operazione, vedere la documentazione di SAP.

SAP Analytics Cloud Agent

Per alcuni scenari di applicazione, SAP Analytics Cloud Agent è un'applicazione installata in una macchina virtuale. Usa SAP Cloud Connector per la connettività SAP BTP. In questa architettura, la macchina virtuale sap Analytics Cloud Agent viene eseguita nella subnet dell'applicazione perimetrale SAP, insieme alle macchine virtuali di SAP Cloud Connector. Per il flusso del traffico da reti private come una rete virtuale di Azure a SAP BTP tramite SAP Analytics Cloud Agent, vedere la documentazione di SAP.

SAP fornisce collegamento privato servizio per SAP BTP. Consente connessioni private tra i servizi SAP BTP selezionati e i servizi selezionati nella sottoscrizione di Azure e nella rete virtuale. Quando si usa collegamento privato servizio, la comunicazione non viene instradata attraverso la rete Internet pubblica. Rimane nel backbone della rete globale di Azure ad alta sicurezza. La comunicazione con i servizi di Azure avviene tramite uno spazio indirizzi privato. La protezione dell'esfiltrazione dei dati migliorata è incorporata quando si usa collegamento privato servizio, perché l'endpoint privato esegue il mapping del servizio di Azure specifico a un indirizzo IP. L'accesso è limitato al servizio di Azure mappato.

Per alcuni scenari di integrazione di SAP BTP, è preferibile l'approccio al servizio collegamento privato. Per altri, SAP Cloud Connector è meglio. Per informazioni su come decidere quale usare, vedere Running Cloud Connector e SAP collegamento privato side-by-side.

SAP RISE/ECS

Se SAP gestisce il sistema SAP con un contratto SAP RISE/ECS, SAP è il partner del servizio gestito. L'ambiente SAP viene distribuito da SAP. Nell'architettura di SAP, l'architettura illustrata di seguito non si applica ai sistemi eseguiti in RISE con SAP/ECS. Per informazioni sull'integrazione di questo tipo di ambiente SAP con i servizi di Azure e la rete, vedere la documentazione di Azure.

Altri requisiti di comunicazione SAP

Considerazioni aggiuntive sulle comunicazioni associate a Internet possono essere applicate a un panorama applicativo SAP in Azure. Il flusso di traffico in questa architettura usa un firewall di Azure centrale per questo traffico in uscita. Le regole definite dall'utente nelle reti virtuali spoke instradano le richieste di traffico associato a Internet al firewall. In alternativa, è possibile usare i gateway NAT in subnet specifiche, le comunicazioni in uscita predefinite di Azure, gli indirizzi IP pubblici nelle macchine virtuali (non consigliato) o un servizio di bilanciamento del carico pubblico con regole in uscita. Gli scenari tipici raggiungono endpoint pubblici di Microsoft Entra ID, API di gestione di Azure in management.azure.com e servizi di applicazioni di terze parti o applicazioni per enti pubblici tramite l'accesso alla rete in uscita.

A causa delle modifiche apportate all'accesso in uscita predefinito in Azure, assicurarsi che sia definito un accesso in uscita scalabile. Per le macchine virtuali che si trovano dietro un servizio di bilanciamento del carico interno standard, ad esempio quelle in ambienti in cluster, tenere presente che Load Balancer Standard modifica il comportamento per la connettività pubblica. Per altre informazioni, vedere Connettività degli endpoint pubblici per le macchine virtuali che usano Azure Load Balancer Standard in scenari a disponibilità elevata SAP.

Per altre informazioni sulla connettività in uscita predefinita dalle macchine virtuali, vedere Opzioni di routing per le macchine virtuali da subnet private nel blog rete di Azure.

Aggiornamenti del sistema operativo

Gli aggiornamenti del sistema operativo si trovano spesso dietro un endpoint pubblico e accedono tramite Internet. Se non sono presenti repository aziendali e gestione degli aggiornamenti, il mirroring degli aggiornamenti del sistema operativo dai fornitori in indirizzi IP privati/macchine virtuali, il carico di lavoro SAP deve accedere ai repository di aggiornamento dei fornitori.

Per i sistemi operativi Linux, è possibile accedere ai repository seguenti se si ottiene la licenza del sistema operativo da Azure. Se si acquistano direttamente le licenze e le si porta in Azure (BYOS), contattare il fornitore del sistema operativo per informazioni sui modi per connettersi ai repository del sistema operativo e ai rispettivi intervalli di indirizzi IP.

Gestione dei cluster a disponibilità elevata

I sistemi a disponibilità elevata, ad esempio SAP ASCS/SCS cluster o database, possono usare un gestore cluster con l'agente di isolamento di Azure come dispositivo STONITH. Questi sistemi dipendono dal raggiungimento di Azure Resource Manager. Resource Manager viene usato per le query sullo stato sulle risorse di Azure e per consentire alle operazioni di arrestare e avviare le macchine virtuali. Poiché Resource Manager è un endpoint pubblico, disponibile in management.azure.com, la comunicazione in uscita della macchina virtuale deve essere in grado di raggiungerla. Questa architettura si basa su un firewall centrale con regole definite dall'utente che instradano il traffico dalle reti virtuali SAP. Per le alternative, vedere le sezioni precedenti.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altro collaboratore:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Community

Prendere in considerazione l'uso di queste community per ottenere risposte alle domande e per assistenza nella configurazione di una distribuzione:

Passaggi successivi